From a requirements engineering point of view, the elicitation of context-aware functionalities calls for context modeling, an early step aimed at understanding the application contexts and how it may influence user tasks. In practice, however, context modeling activities have been overlooked by practitioners due to their high complexity. To improve this situation, we implemented xPACE and TASC Modeler, which are tools that support the automation of context modeling based on existing contextual data. In this demonstration paper, we present our implementation of a data-driven context modeling approach, which is composed of a contextual data processor (xPACE) and a context model generator (TASC Modeler). We successfully evaluated the results provided by the tools in a software development project.
Computers have become increasingly ubiquitous, and we are witnessing the rise of applications,
sensors, and networks that together deliver smart behaviors to users. Context awareness plays
a key role in this game as a core characteristic of ubiquitous computing [
Context-aware functionalities are functionalities that consider context to produce a certain
system behavior, typically an adaptation or recommendation. From a requirements engineering
point of view, the elicitation of context-aware functionalities requires context modeling, an
early step involving identification of contextual elements, analysis of accessibility (i.e., which
contextual elements have available sources from which their values can be read), analysis of the
relevance of these contextual elements for user tasks of interests, and analysis of combinations of
contextual elements for these user tasks [
We approached this problem by automating context modeling for the elicitation of
contextaware functionalities. For this purpose, we designed a data-driven context modeling process
(first introduced in [
To come alive, the proposed automation in the process requires the implementation of two software components. One is the Contextual Data Processor, which is responsible for analyzing a contextual dataset. Its output is used by the other component, the Context Model Generator, which is responsible for creating the concrete context model that is expected to support requirements engineers in the elicitation of context-aware functionalities. In this paper, we present our implementations of these software components: xPACE and TASC Modeler 1, and briefly discuss its application in a software development project at Fraunhofer IESE.
Once a user task of interest has been chosen and corresponding contextual data has been collected, a contextual dataset is available. Then the requirements engineer uses TASC Modeler to generate the desired context model, providing the contextual dataset as input, in addition to a metadata file that configures the behavior of both the context model generator – how the contexts will be presented in the model – and the contextual data processor – how the dataset should be analyzed. The detailed specification of the input files can be found with the source code1. TASC Modeler forwards the dataset and the metadata to xPACE, which analyzes the data and returns the findings in a data structure named standardized task-specific contexts , which is created to decouple the data analysis from the context model generation. Then TASC Modeler translates the standardized task-specific contexts provided by xPACE into a context model representation. Figure 1a shows the component diagram of the solution.
In our case, the context model is represented as a directed acyclic graph with one root node. This representation supports data-driven context modeling approaches, expressing how the context influences individual user tasks. Each path from the root node towards a leaf describes how a context influences a user task of interest. Figure 2 shows an example. Consider the user task “Prepare a cup of cofee”. Each of the two paths contains a set of instantiated contextual elements that, together, were found to influence the task (e.g., “When location = WORK and time = AFTERNOON then user prepares a cup of cofee”, i.e., the context “location =WORK and time = AFTERNOON” influences the user task “Prepare a cup of cofee”, according to the model). Note in the example how the model structure diferentiates intrinsic contextual elements (those that intrinsically characterize the entity “cup of cofee”, which is the object of the task), from extrinsic ones.
3. xPACE – eXtended Pairwise Analysis of Contextual Elements The eXtended Pairwise Analysis of Contextual Elements (xPACE) was implemented using a strategy that can be divided into two parts. First, it uses statistical methods to search for correlations between pairs of contextual elements (CEs) in the contextual dataset. Whenever correlations are found, the algorithm identifies which CE instances (i.e., concrete values of the CEs) are correlated. This is necessary because it is not enough to know that two CEs relate to each other (e.g. “location” and “time”), but it also needs to be know which instances relate to each other (e.g., “at home” and “evening”). After that, the pair is ordered to express the direction of the relationship. After analyzing all pairs of CEs, we end up with a list of pairwise relations, which is a set of directed pairwise relations among CE instances. The second part of the strategy takes the list of pairwise relations and builds a graph by treating each pair as an edge of the graph. When all pairs have been added to , each path in the graph starting from a root node and ending on a leaf node will represent a relevant combination of CEs that were found by xPACE to influence the user task. Figure 3 contains an activity diagram that illustrates the data processor algorithm. The employed statistical methods are named in the corresponding steps.
The algorithm is implemented using the R language2, and a Web API component implemented in Java provides handy access to it. The core takes as input the name of the user task and two ifles: a contextual dataset and a metadata file that describes the dataset; as output, it produces a standardized task-specific contexts file, which can be used by any context model generator lca sd i t o ttsaS tehmCombine CEs in i
pairs h iss no yes no iasvnaeilxatbplea?ir yes Te(Ksrtucskoarlr-Welaaltisio,n
Cramer's V) correlation? yes (ISdtaenndtairfdyiziendsrteasnidcuealss, is there
Conover's Test)
Order CEs (Kruskal-Wal is,
Theil's U)
Add relation to list of pairwise
relations does relation start with root element?
Add all paths yes from root until leaves into list of contexts
Create standardized
task-specific contexts file from list of contexts that complies with its layout. Figure 1b shows the internal structure of xPACE. The principal ifle in the core is main.R. It contains the algorithm that we implemented to analyze contextual data to identify potential relevant contexts for the user task in focus. The other R files are helpers (“load_libraries.R” loads the necessary packages into the memory, “util.R” defines some functions, and “load_data.R” reads the input files into the memory).
The Task-specific Context Modeler (TASC Modeler) is responsible for creating the graphical representation of the context model. The requirements engineer interacts directly with TASC Modeler, providing the contextual dataset, the metadata, and the task name as input. TASC Modeler then interfaces with a contextual data processor to provide the input data and receive the standardized task-specific context files as response. In our case, TASC Modeler uses xPACE, but it could be any other contextual data processor implementation able to generate the standardized task-specific context file via a REST API. TASC Modeler reads from a configuration file the information about which contextual data processor it should use.
PE.1(n=5) PE.2(n=5) PE.3(n=5) 20.0%
80.0% 100% 80% 60% 40% 20% 0% 20% 40% 60% 80% 100%
(a) Performance expectation.
We implemented TASC Modeler as a single-page application written in Typescript using the React Library3. When the application is loaded, the user is presented a form where they can provide the dataset file, the metadata file, and the name of the user task in focus. When the button “Generate” is pressed, the application sends the input data to xPACE through its Web API. Then xPACE returns its implementation of the standardized task-specific contexts file, which is used by TASC Modeler to build the context model.
We used TASC Modeler and xPACE to support the elicitation of context-aware functionalities
for DorfFunk4, a live communication app with approx. 25,000 active users developed and
maintained by Fraunhofer IESE. We chose a user task (“create a comment”), collected contextual
data (approx. 56,000 tuples from 15 contextual elements), and used the tools. Figure 4 shows a
screenshot of TASC Modeler with an excerpt of the data-driven context model generated using
DorfFunk data. The generated context model was evaluated in a controlled experiment with
professional software engineers (because elicitation of context-aware functionalities is often not
limited to requirements engineers [
While the details of the experiment can be found in our previous paper [
100.0% 100.0%
AT.1(n=5)
(Unified Theory of Acceptance and Use of Technology [
Context modeling to support the elicitation of context-aware functionalities has been disregarded by practitioners due to its high complexity. To improve this scenario, we designed and implemented a data-driven context modeling process that automates the analysis of combinations of contextual elements that influence user tasks and the generation of the context model. The automation of this process is supported by two tools: the Contextual Data Processor and the Context Model Generator. In this demo paper, we presented our implementation of these tools: xPACE and TASC Modeler.
As future work, we plan to apply the tools in diferent projects and evaluate their quality
attributes, in particular time behavior, capacity, and scalability, when they have to deal with
much bigger contextual datasets. So far, our evaluation has focused on the results produced
by the tools and not on their usage, so we will now also evaluate their usability, which is a
essential step towards enabling adoption by practitioners. Moreover, since data processing
and context model representation are decoupled, we also want to check to which extent other
representations (such as CGM [