In this paper we present a visualisation tool that is intricately related to a featurebased context-oriented programming language. Context-oriented programming languages allow programmers to develop software systems of which the behaviour evolves dynamically upon changing contexts. In our language, the software behaviour as well as the contexts to which the behaviour adapts, are encoded in terms of separate feature models. Due to the highly dynamic nature of such software systems and the many possible combinations of contexts to which they may adapt, developing such systems is hard. To help programmers manage the complexity of developing such software systems, we created a tool to help them visualise the contexts and features, even at runtime. The visualisation tool confronts two hierarchical models: the context model and the feature model, and highlights the dependencies between them. We conduct an initial user study of the visualisation tool to assess its usefulness and usability.
Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
Context-aware systems [
The notion of context has also been explored in the
eld of feature modelling [
Inspired by this idea, we proposed a
contextoriented software architecture [
Building upon this context-oriented software architecture, and taking the analogy with Hartmann et al.'s modelling approach a step further, we extended the proposed architecture by explicitly representing contexts and features in terms of two separate feature models that are used at runtime to guide the selection and activation of both contexts and features. Nevertheless, keeping track of all possible contexts, features and their intra- and inter-dependencies remains a daunting task for developers of context-oriented systems. It is not easy for a developer to know what contexts or features are available, are currently active, what the impact of activating or deactivating them is, or whether the system exhibits the intended behaviour in a particular situation.
We therefore developed a visualisation tool that can help developers keep an overview of all existing contexts and features, by displaying the context and feature models and their dependencies. The tool o ers more than a mere static visualisation of the context and feature models. It can also depict dynamically what context and features are active or get activated, and what program code this a ects.
To assess whether the tool's visual metaphor helps understanding the programming paradigm and programs written in it, we conducted an initial user study with master students in software engineering. We conclude that our tool helps understanding the underlying approach, despite its complexity for programmers developping context-oriented applications.
The remainder of this paper is structured as follows. Section 2 introduces the case study of a contextoriented system used as running example throughout the paper. Section 3 then introduces our contextoriented software architecture and programming language, as well as corresponding background material. Our visualisation tool is presented in Section 4. Section 5 discusses the initial user study and discusses its results. Related work is exposed in Section 6. Section 7 concludes the paper and presents some future work. 2
Before introducing our visualisation tool and the
underlying context-oriented software architecture upon
which it relies, in this section we brie y describe the
case study that will serve as running example
throughout the paper: a `risk information system' [
The system provides instructions to citizens on what to do in case of certain emergency situations or risks, like earthquakes or oods. The actual instructions given to a citizen may depend on a variety of contexts, such as the user's age, location or vicinity, weather conditions, or the status of an emergency (the emergency has been announced but has not yet a ected the user, the emergency is actually occurring, or being in the aftermath of an emergency situation).
The instructions issued by the context-aware risk information system can be either static or dynamic. Static instructions are just instructions that a user can consult about what to do in case of certain risks.
The system can also display information and characteristics about actual emergencies as they occur. For example, when an earthquake is detected, its severity would be computed on the Richter scale and its location shown to citizens as a circular impact zone determined by its epicentre and its radius.
When an actually emergency is observed, the authorities will actively issue instructions speci c to the emergency at hand, and speci c to the current situation and user pro le. For instance, if an earthquake warning has been issued, and a citizen is stuck at home, an adult may get a speci c instruction to \Hide under a table, desk, bed or any other sturdy piece of furniture", while a child may just see a pictogram representing this speci c instruction instead. 3
A feature-based context-oriented
approach
Context-oriented programming languages and
frameworks help programmers build context-oriented
systems. We proposed one such framework [
Fig. 1 shows a simpli ed feature model depicting a subset of the functionalities of the case study.1 A user of the risk information system can edit his or her prole (age and location) and the system can display the characteristics of an emergency such as its severity or impact zone.
A feature model highlights the commonalities and
variabilities of a system [
A feature model is represented as a tree, where the nodes represent features and the hierarchical edges represent constraints between these features. Whenever a child feature is selected, all of its ancestor features must be selected. A mandatory constraint, depicted with a black circle, means that if the parent feature is selected, the subfeature must be present in the system as well. An optional constraint, depicted with a white circle, states that the subfeature may or may not be present. As such, the Profile edition feature must always be present in a risk information system, whereas the emergency information is optional (it is only needed when there is an actual emergency).
An or (resp. xor ) constraint, depicted by a black (resp. white) triangle, means that at least one (resp. exactly one) of the child nodes participating in this constraint should be selected in the system. In our example, the features Display severity and Show impact zone can coexist (and often do) in a same version of the system, as well as their subfeatures (this can happen if two emergencies, for example a ood and an earthquake, happen at the same time).
A particular instantiation of the system is correct only if the selection of features that adapt the system, respects the constraints imposed by the feature model. It is not allowed to activate or deactivate features if that would violate the constraints of the feature model. In Fig. 1, a valid con guration could be Risk Information System, Emergency information, Display severity, Richter, Profile edition, Age, Location, and would correspond to a con guration where the system can display the severity of an earthquake emergency (using the Richter scale) and where the user can edit his age and decide if the system can use his current location or not. 3.2
Not only features, but also contexts, are key notions
in feature-based context-oriented systems. While
contexts are characteristics of the surrounding
environment in which a system runs [
Notwithstanding their complementarity and di
erences, it has been observed that the feature modelling
notation can also be used to model contexts [
MPL-Feature Model Context Variability
Model
Feature Model Now that we have discussed how to model contexts and features, we still need to discuss how to program context-oriented systems that can adapt to changes in their surrounding environment.
Context-oriented programming (COP) is a
paradigm that provides dedicated programming
language abstractions to adapt the behaviour of a
software system dynamically upon changing contexts.
The paradigm was introduced about a decade ago by
Hirschfeld et al [
Sensors
Context Handling
Feature Handling
Code Adaptation
This architecture senses the surrounding environment in which the system executes. Whenever changes in the environment are detected, the Context Handling layer interprets and reasons about the raw data representing these changes, in order to reify them into contexts and (de)activate them. After the contexts are (de)activated, the Feature Handling layer (un)selects and (de)activates the features corresponding to the (de)activated contexts. Finally, the Code Adaptation layer (un)installs the code corresponding to these features to adapt dynamically the system behaviour. 3.4
In earlier work, we proposed a rst visualisation
tool [
This tool depicts the currently active dependencies between the contexts, features and (object-oriented) classes of the system. For example, when an earthquake emergency is detected, the Earthquake context gets activated, and appears in the visualisation as a yellow rounded rectangle. This context activation then causes the selection and activation of the corresponding features SeverityRichter and CircleImpactZone, which contain speci c functionality to display information about an earthquake emergency. When these features are activated, they get displayed as green rounded rectangles. Finally, these features adapt the code of some classes in the system, depicted as blue rounded rectangles (in this case, it is the Earthquake class that gets altered).
However, as can be seen from Fig. 4, this visualisation does not represent the contexts and features as separate hierarchical feature models, but rather as a single large graph of active contexts, features, classes and their dynamic intra- and inter-dependencies. 3.5
One of the contributions of our current work is to
model the possible contexts, features they trigger, and
classes they adapt, as separate but interconnected
hierarchical models, as depicted schematically in Fig. 5.
This approach combines our context-oriented software
architecture with the multiple-product-line-feature
modelling approach of Hartmann and Trew [
Context Model
Feature Model Sensors
Context Handling
Feature Handling
Class Diagram Class * 1 Class
Class Class
Code Adaptation Now that we have introduced our feature-based context-oriented programming approach, in this section we present the tool we built to help programmers visualise and animate the underlying hierarchical context and feature models and their interdependencies, allowing them to better understand and handle the complexity and dynamicity of systems built using that approach. We will describe the visualisation tool through di erent usage scenarios from a programmer's perspective. Before doing so, we brie y revisit and expand upon the case study.
Flood Earthquake
Flood Earthquake Show impacted zone Child friendly Senior friendly Alert Warn Inform
Age Location
Risk concerns Description Instructions in case of already mentioned above, is the use of colouring to show active contexts, features and classes in green. A second one, which will be explained in the next subsection, is to use particular lters to show only activated contexts, features, dependencies, and currently adapted classes. The nal and probably most powerful functionality provided by the tool is to show changes to the diagrams as they occur. To explore these dynamic changes, the tool provides the ability to replay the changes step by step (by activating the Step-by-step mode and using the Next step button in the Con guration pane, as showed in the bottom right of Fig. 7), so that a programmer can inspect the state of the diagrams after each change. 4.2
In addition to providing a static overview of a contextoriented system, the tool should support programmers in understanding and exploring the dynamic aspects of such a system. The tool should help them inspect what contexts and features are currently active and how that a ects the behaviour, in terms of what classes are currently being adapted. For example, suppose that during testing and simulation of the system a programmer discovers that, when an earthquake warning is issued, the system starts displaying instructions related to a ood instead of an earthquake. To understand such undesired behaviour he needs to explore what contexts are currently active, what feature were triggered in response to that, and how the classes were then adapted by those features. A possible cause of this bug may be for example a wrong dependency between the earthquake context and its corresponding features.
The visualisation tool provides several ways of exploring the system dynamics. A rst one, which was
To help programmers manage the complexity of understanding big systems consisting of many di erent context and features, the tool comes with a set of lters and prede ned views that a programmer can select to focus on particular concerns, as depicted in the bottom left of Fig. 7.
These lters (called `Customized views') allow a programmer to indicate whether he is more interested in the contexts, the features, the code, or the dependencies between them, and whether he is currently more interested in exploring the active or inactive entities or dependencies. The lters can be combined in many di erent ways. In addition to that some `Predened views' are provided, which are prede ned combinations of lters, often selected together. For example the \Active mode" shows all entities and dependencies that are currently `active', as depicted in Fig. 8. As the number of possible contexts, features, classes and dependencies can become quite large, in addition to ltering the diagrams to only show certain elements of interest, highlighting is another interesting way to help programmers navigate through the diagrams. Suppose for example that a programmer is trying to understand why a particular feature, say the Active During Earthquake feature, does not seem to exhibit the expected behaviour. By simply clicking on that feature, it will be highlighted in yellow, together with the contexts that triggered its selection (by following the dependencies that have this feature as target) and the classes it adapts (by following the dependencies that have this feature as source). In this example, the contexts During and EarthquakeEmergency will be highlighted, as well as the Earthquake class. This highlighting is illustrated by the yellow borders and yellow arrows in Fig 7. 4.5
Finally, a programmer can customise his visualisation at an even more ne-grained level. For example, Fig. 9 shows a reduced feature model obtained by hiding and collapsing particular features, using the corresponding buttons to hide an element, collapse all elements above, or all elements below. 5
In this section, we describe and analyse the user study we conducted to assess the usability and usefulness of our visualisation tool and underlying approach. The subjects of our study were 34 master-level students in computer science or engineering following a software engineering course. They were aged 20 to 27 years old and 4 of them were female. To evaluate the tool, we asked them to play the role of programmers working on a context-oriented system. To initiate them to the di erent technologies used in the project, they participated in two preparatory sessions before the actual user study. Since the study was carried out during a course, in order not to bias the results we made it clear to the students that this user study would not be related to the course evaluation and would be entirely dedicated to our research and performed anonymously. In the remainder of this section, we rst describe the preparatory sessions preceding the study, then describe the user study itself, present the results we gathered from the study, and nally brie y discuss some threats to validity. 5.1
Before conducting the user study, we initiated our master-level students with two sessions of two hours each. The rst session was an introduction to the Ruby programming language, the language used to develop our feature-based context-aware approach. The second session was to explain our approach in which we exempli ed it with an earthquake-speci c risk information system. 5.2
After these preparatory sessions, during a third twohour session we performed the actual user study, where our students were asked to assess the usability and usefulness of our visualisation tool. To help them in their evaluation task, they had to perform two tasks. These tasks aimed to extend the earthquake-speci c variant of the risk information system with a new kind of risk and emergency: oods. Task 1 concerned the characteristics of a ood. In this task, they had to implement the ne-grained features to manage and display the `standard severity' feature and the `polygon impacted zone' feature needed to represent a ood emergency. Task 2 was about implementing the ood-speci c instructions (either static or dynamic) that citizens must follow before, during or after a ood. We conducted the user study as follows: Students were rst asked to provide some information about themselves (age, knowledge of object-oriented programming, contextoriented programming and so on). They had to evaluate their knowledge on a ve-level Likert scale, where a value of 1 meant they had no expertise in the eld up to a value of 5 meaning they considered themselves as an expert in the eld. Then we split the students/programmers in two separate groups (A and B) to perform their assigned task during a 25-minute time slot. Group A had to start implementing Task 1 whereas group B had to develop Task 2. During this rst task, they were not allowed to use the visualisation tool. Next, they received a quick introduction to the visualisation tool as a preparation for their second task. For this second task, we switched the tasks. Group A now had to develop Task 2 while group B had to implement Task 1. Again, both groups received at most 25 minutes to nish their assigned task. Finally, all subjects were asked to answer some questions regarding how they perceived the usability and usefulness of our visualisation tool. We also asked them to provide some open feedback on how we could improve the visualisation tool. 5.3
Despite the complexity of our feature-based contextoriented programming approach, the participants in our study seemed to agree that our visualisation tool is interesting for developers when learning our approach or during debugging.
Fig. 10 illustrates the background knowledge of our participants at the beginning of our user study. We can observe that our students have quite a good knowledge of programming and object-oriented programming in particular. But they did not feel as comfortable with more dynamic programming technologies such as the context-oriented programming paradigm or our feature-based context-oriented approach. Their weak knowledge of the Ruby programming language can be justi ed by the fact that only a few of the students had prior experience (beyond what they saw in the two-hour preparatory session) in Ruby.
Nevertheless, despite the di culty of our approach, our participants do seem to be interested by the visualisation tool when they must develop a context-oriented system using our approach. Fig. 11 depicts their opinions about the tool. The rst two questions concern whether they believed the static or dynamic representation of the models and their dependencies to be easy to understand. The ve values ranged from hard to understand to easy to understand. For each representation, more or less 58% (taking into account only the positive values) of our participants considered the representations as understandable. For the question about which aspect (static or dynamic) is most interesting in this tool, 50% (considering only the positive values) of our participants consider the dynamic view as more interesting than the static view, as opposed to only 20% (computing only the negative values) who believed the static view to be more interesting. 30% liked the dynamic aspect as much as the static one. In addition, almost 56% of our participants agreed that our visualisation tool is helpful to learn the approach. The ease to use our tool is more mitigated however. Whereas almost 40% of the participants believed our tool to be easy to use, more or less 26% of them did not. This result could be explained by the complexity of our approach. Indeed, assessing the usability of a visualisation tool such as the one described in this paper is intrinsically linked to the understandability of the underlying programming approach. Finally, in our open question about which functionality is most useful, several participants answer that the ability to replay changes dynamically using the Next step button is really useful. In the received feedback, two main requests may be noted: the addition of a previous step button to step back in the process and better support for visualising larger context and feature models. 5.4
The case study performed in this paper should not be considered as a full- edged in-depth user study but rather as an initial exploratory study to help us identify the main strengths and weaknesses of the proposed approach and visualisation before developing it further. In particular we wanted to nd out if the proposed visualisation tool could help programmers in coping with the inherent di culty of building contextoriented programs of which the behaviour can change dynamically upon changing contexts. Although our initial ndings were promising they are still premature and a more rigorous validation study of the form of a controlled experiment with proper task completion metrics would be needed to avoid biased conclusions. In particular, the study should be set up in such a way that the opinions of the subjects are not in uenced by possible bias implanted by the context or preparation of the user study. 6
In Section 3 we already presented some background work on feature and context modelling, in order to introduce our feature-oriented context-aware approach. In this section we will explore some further related work, in particular on context-oriented and featureoriented programming approaches, as well as on other visualisation tools related to these approaches.
Programming in general
Object-oriented programming
Whereas feature-oriented programming [
To create dynamic software systems sensitive to
their environment, several approaches exist. One
approach is to extend feature models with contextual
information, so that the system can be recon gured by
selecting features at runtime depending on sensed
context information [
However none of these approaches separate clearly
the features from the contexts, which is why we
proposed a novel feature-based context-oriented approach
based on top of our earlier context-oriented software
architecture [
Several visualisation tools have been created for visualising di erent aspects of the context- and featureoriented modelling or programming approaches that have been mentioned either above or earlier in Section 3. Many of these works state that visual support is essential especially when trying to understand and manage large and complex feature (or context) models.
To visualise feature models, programmers can use
a tool like FeatureIDE [
Nieke et al. created a tool suite for integrating
modelling in context-aware software product lines [
In Section 3, we showed our Feature Visualiser [
To create context-oriented software systems, in this paper we presented a feature-based context-oriented approach, where both the contexts and features are modelled in terms of feature diagrams. Managing these di erent models and their dependencies is a daunting task, due to the potentially high number of contexts and features, as well as the high dynamicity of such systems. To address this issue, we created a dedicated visualisation tool for this feature-based contextoriented approach, which confronts two hierarchical models (the context model and feature model) and highlights the dependencies between them. In addition, it shows the dependencies from the feature model to the code (i.e., the classes of the system). This visualisation tool not only allows programmers to inspect the models and their dependencies statically, but also to explore what happens dynamically as contexts and features are being (de)activated during system execution. For understanding and manipulating larger models, the tool also comes with lters, prede ned views, and functionality to highlight, collapse or hide speci c elements, allowing programmers to focus the visualisation only on speci c parts of interest.
To assess the usefulness and usability of our visualisation tool, we conducted an initial user study with 34 master-level students in the context of a software engineering course. The participants of this study considered that our tool was easy to understand in terms of the di erent representations it provides. They felt in particular that the dynamic representation of the models helped them understand how the system adapted over time. However, the participants were less convinced when it came to usability of the tool. However, this can be explained by the fact that the complexity tool is strongly linked to the complexity of the underlying approach.
As future work we will rst integrate the useful
comments and feedback received from the participants in
our study. To deal with the scalability problem of
large models, we will address this issue by relying on
other visualisations such as for example a more
compact tree-like view a la S.P.L.O.T. [
We are grateful to Jean Vanderdonckt for the many fruitful discussions on this topic.