Dynamic Software Product Line (DSPL) Engineering has gained interest through its promise of being able to unify software adaptation whereby software can be con gured at compile time and runtime. Just like conventional adaptive software, software dynamism can confuse the user, and lower user trust. Variability knowledge expressed in a feature model though may not be understandable to the end user. Explanations have been shown to improve intelligibility of the software, and improve user trust. In this work, we consider how explanations can be used in DSPLs, by adding explanatory knowledge to feature models that can be used to generate explanations at runtime.
Smart phones in recent years have seen high proliferation, allowing more users to stay productive while away from the desktop. It has become common for these devices to have an array of sensors including GPS, accelerometers, digital compass, proximity sensors, sound etc. Using these sensors with other equipment already found in phones, a wide set of contextual information can be acquired.
This contextual information can be used in Context-Aware Self Adaptive
(CASA) software. This software can monitor di erent contextual parameters
and dynamically adapt at runtime to satisfy the user's current needs [
Dynamic Software Product Lines (DSPL) enables the SPL to be recon
gurable at runtime [
Feature Modelling has become the de facto method of variability representation, used in software product lines. In feature models, the adaptation of the product, be it static, or dynamic, are modelled, enabling a wide variety of products and product behaviours. While feature modelling is of great use in the development, the dynamics within feature modelling can be confusing to endusers. To amend the seemingly unpredictable and thus confusing nature of the behaviour of a dynamic system and the results it produces, it is desirable to enable the system to explain its behaviour as well as the results it produces to the end-user. As we will detail further on in this paper explanations are very useful to justify results a system produces and thus help to rebuild the trust an end-user has in the systems behaviour and results. So explanations are useful to the end-user as they can counter the mentioned non-transparency of DSPL end-products and their dynamic behaviours.
In our previous work [18], on enabling a system we developed to
generate explanations, we investigated the integration of explanations into a
context acquisition engine, used for developing context-aware applications. We did
this with regard to mobile applications were one has to adhere to many
constraints. We developed a ContextEngine to easier deal with such limitations and
situation-speci c information across applications [
The rest of the paper is structured as follows: We introduce the feature modelling background of our work in the following section and based on the technological possibilities described there motivate our approach to use an extended feature model for explanation generation in Section 3. We then interlink our approach with related work on feature modelling, explanation generation and the use of explanations itself in the following section. We then introduce our approach to explanation generation from explanatory knowledge stored in an extended feature model and demonstrate our concept of explanation generation in Section 5 . After discussing the advantages and possible disadvantages of our approach in Section 6 a summary and outlook on future aspects of our work concludes the paper. 2
The purpose of a feature model is to represent all possible products from a SPL
in terms of features, and the relationships between them. An example feature
model for a content store application is shown in Figure 1. A feature of a system
has been described in a number of variations [
Feature models have been applied not only to modelling system features, but
also context [
Extended feature models extend basic feature models by the ability to attach
additional information about features to the model. This additional
information is included by the use of feature attributes, which are attached to features
within the feature model. Feature attributes normally consist of a name,
domain, and value. Feature attributes have been used in previous work for
specifying extra-functional information [
The GUI of an application, or even more intriguing, the behaviour of an application generated by the use of SPL can be rather dynamic. This dynamic behaviour can be confusing if not daunting to the end-user of the application. The end-user might not be aware of why the GUI has adapted and the factors in uencing how it changes. Furthermore, the dynamic behaviour of the application, producing di erent results while receiving identical inputs just under di erent circumstances (for example a network being available or not), is a challenge to the trust the user develops towards the applications results. As the feature model, being the component responsible for the dynamic behaviour of the application, is a black box system to the end-user the need for explanations of this black box systems behaviour arises.
The bene ts of being able to explain the behaviour of an application and subsequently its GUI are plenty. According to [17] there are a number of bene ts explanations can provide to the end-user. The main bene ts of interest with regard to our problem at hand are the generation of trust into the results the application generates and justi cation of and guidance on the changes in the GUI of the application.
As [
To illustrate our motivation, consider a DSPL example of a content store application for a mobile device. This application may provide di erent content for the user including applications, movies, music etc. Di erent content is organised into di erent categories. A simpli ed feature model of the DSPL can be seen in Figure 1. This application provides content for di erent age groups, and also the application can be tailored to suit these di erent groups.
In the feature model, we can see that the features Payment, ContentTypes, History, and Retrieval are required in every con guration of this DSPL. The Payment feature handles all payment transactions when content is bought or rented. The ContentTypes feature contains the di erent components for browsing, and buying di erent types of content. Because di erent regions in the world may require di erent content distribution licenses, it may not be possible to sell content in every region, so depending on the location of the user, di erent content type features including Video, Music, and Applications will be bound or unbound. In the History feature, all bought content is found, which can be retrieved in Retrieval. There are two primary methods in which content can be retrieved, downloaded or streamed. Certain content including video maybe downloaded or streamed. Depending on how much storage is available on the device, it may be not be possible to download the movie, so only the Streaming feature is bound. In Figure 2, we can see the variability of the screen according to content type features. If you consider the video feature, there is a button that takes the user to a set of screens for video content, and also a containership of widgets for advertising popular movies. 4
Explanations and feature models have been used before, but more to aid the
analysis process and error analysis of feature models [20] as well as in automated
feature model analysis in general as Benavides et al. describe in [5]. As we
already mentioned there are a number of goals that can be reached by providing
explanations to the user of a, then, explanation aware system. An explanation
aware system is a system that is able to provide explanations of the results it
produces as well as of the means it employs to produce these results [
The goals pursued by enabling a system to provide explanations [19] are the following: Increase the transparency of a systems reasoning process to increase the users trust into the system. Justifying results the system produces. This goal aims at explaining the quality and applicability of results the system produced to the end-user. Another goal of explanation provision is to provide relevance explanations of either question asked by the system or on information provided by the system. Conceptualisation, thus explanations of the concepts the system is working on, directly aids the last goal of providing explanations, learning. By explaining the concepts the system works on to the end-user the end-user is enabled to learn about the domain in which the system works.
Our approach to providing applications needs, next to the knowledge used
by the feature model system, additional explanatory knowledge to create the
explanations we want the system to be able to provide to the end-user. It is always
necessary to provide explanatory knowledge in any system that is intended to
provide explanations on its reasoning [
In our approach the explanatory knowledge needed to generate explanations
in our system will be broken down into `atomic' canned explanatory knowledge
artefacts that will be paired with each feature of the feature model as well as
additional `atomic' canned explanatory knowledge artefacts that will be attached
to the relationship descriptors within our feature model. The aim of this
`enrichment' or `dotation' of the feature model with `micro' or `atomic' explanatory
knowledge artefacts is it to reuse the artefacts `bound' to the features and their
relationship descriptors in the nal product to synthesise complex explanations
based on the available `bound' atomic explanatory knowledge artefacts. We
focus our approach especially on the issue of explaining a dynamic GUI to the
end-user. As for example [
In our approach, we attempt to enable explanations in DSPLs. By adding
explanations to DSPLs, we see two bene ts. Firstly, explanations have been shown
in other work to improve user understanding of a system which can be
applied to DSPL systems [
Just as the rest of the system is modelled using feature models, so too are the explanations. To add explanations to the feature model, we use extended feature models. As introduced earlier in the paper, with extended feature models, extra explanatory information can be attached to features using feature attributes. These feature attributes can be used for storing the speci c explanation snippets for each feature. For each feature attribute there is a name, domain, and value. The domain of the attribute holds what type of explanation it is, with the value holding the explanation fragment.
Mapping explanatory knowledge fragments to features is not just enough; we also need to map explanatory knowledge fragments to feature model relationships. Examples of explanatory knowledge fragments mapped to relationships include: { Mandatory - \in all con gurations". { Optional - \which is optional". { Or - \which can be".
{ Alternative - \which is either". 5.2
Once we have the explanations added to the feature model, we can compose complex explanations. These complex explanations are made up of the concatenation of explanations added to the features and the relationship explanations.
Lets take the example of considering a con guration where content is streamed to the user instead of downloaded as shown in Figure 3. If the user wanted to know why streaming is active, to generate an explanation we rstly follow the tree from the streaming feature to the root. We then get the conceptual explanation of the root, in this case \The content store". Next we add the conceptual explanation for the \History" feature, in this case \Stores historical content purchases", and because it is a mandatory feature, we add \in all con gurations". Following this, we add the conceptual explanation for the \Retrieval" feature, in this case \of which can be retrieved", and add \in all con gurations" because the feature is mandatory. Then because the sub features of \Retrieval" are alternatives, we add \either", and the two conceptual explanations joined with an \or". Lastly, because in the con guration, the \Stream" feature is active, we add \in this case, streamed". We therefore can `reuse' the structural information encoded in the feature model representation directly for the composition of complex explanations by simply `re-tracing' the explanatory knowledge artefacts, stored in feature and relationship nodes, along a path in the feature model. 6
The implementation e ort is expected to be minor, given the fact that our
approach just adds three additional feature attributes to the feature and
relationship descriptions. The intention of `piggyback' riding the inherent logical
structure encoded in the feature model graph to also derive complex explanations
from it is still open to be tested for its actual quality of generated explanations
as well as for its scalability. With regard to the scalability of our approach we
intend it to be limited. Once a feature model exceeds a certain complexity the
coherent concatenation of explanatory knowledge artefacts described in the
feature and relation nodes along a path in such a model will fail or become too much
of a computational e ort. However we assume that for small to medium scale
feature models our relatively `practical' approach of concatenating explanatory
knowledge artefacts stored in the models nodes is relatively e cient compared
to existing more complex approaches of explanation generation explained, for
example, in [
In this paper we presented how the variability of SPL based products and their behaviours could be explained to their end-users using explanations composed from explanatory knowledge added to enhanced feature model nodes. Based on the feature modelling background of our work we motivated our approach to use an extended feature model for swift explanation generation. We reviewed and compared our approach with related work on feature modelling, explanation generation and the use of explanations itself, especially inspecting approaches employing relatively complex abductive reasoning. We then introduced our approach to explanation generation from explanatory knowledge stored in extended feature model nodes explaining features themselves and their relationships. By tracing an example graph in a feature model we showed the working of our approach. Given the fact that we are in the early stage of further examining our approach we then discussed its possible limitations but also its possible advantages given by the fact that our approach promises to be easily implemented base on existing work on enhanced feature models and is very easy to use for explanation composition in small to medium sized feature models, compared to more complex approaches like abductive reasoning.
As we cannot yet predict the e ectiveness of our seemingly `pragmatic' approach, we have to implement the enhanced node generation in our existing enhanced feature model and then perform a series of experiments on this enhanced feature model. The aim of these experiments will be to establish our approaches boundaries with regard to parameters such as quality and usability of generated explanations as well as the scalability of our approach. We also have to measure the computational e ort necessary for explanation composition and then measure it against the gain in usability to establish the worthiness of further researching our approach of reusing extended feature model structures for explanation generation from explanatory knowledge artefacts stored in the nodes of the feature model.
An additional feature of the reuse of an enhanced feature models structure for explanation generation not yet investigated further is the reuse of propositional logic formulae derived from the feature model. We plan to investigate the possibilities of this reuse in our immediate follow up research. 18. Sauer, C., Kocurova, A., Kramer, D., Roth-Berghofer, T.: Using canned explanations within a mobile context engine. Explanation-aware Computing ExaCt 2012 p. 26 (2012) 19. S rmo, F., Cassens, J., Aamodt, A.: Explanation in case-based reasoning{ perspectives and goals. Arti cial Intelligence Review 24(2), 109{143 (2005) 20. Trinidad, P., Benavides, D., Duran, A., Ruiz-Cortes, A., Toro, M.: Automated error analysis for the agilization of feature modeling. J. Syst. Softw. 81(6), 883{896 (Jun 2008)