SW & System Modeling with Graph Transformations manuscript No.
(will be inserted by the editor)
A Transformation-Based Approach to Context-Aware Modeling
Degrandsart, Sylvain
1,2
, Demeyer, Serge
1
, Van den Bergh, Jan
3
, Mens, Tom
2
1
Department of Mathematics and Computer Science, Universiteit Antwerpen,
Universiteitsplein 1, B-2610 Antwerpen, Belgium
e-mail: {sylvain.degrandsart, serge demeyer}@ua.ac.be
2
Institut d’Informatique, Universit´e de Mons
Place du Parc 20, B-7000 Mons, Belgium
e-mail: tom.mens@umons.ac.be
3
Hasselt University – tUL – IBBT,
Expertise Centre for Digital Media, Wetenschapspark 2, B-3590 Diepenbeek, Belgium
e-mail: jan.vandenbergh@uhasselt.be
DRAFT — The final accepted article is available at http://www.springerlink.com/content/l1718p7035852610/
Abstract Context-aware computing is a paradigm for
governing the numerous mobile devices surrounding us.
In this computing paradigm, software applications con-
tinuously and dynamically adapt to different “contexts”
implying different software configurations of such de-
vices. Unfortunately, modeling a context-aware appli-
cation for all possible contexts is only feasible in the
simplest of cases. Hence, tool support verifying certain
properties is required. In this article, we introduce the
Context-Aware Application model (CAA), in which con-
text adaptations are specified explicitly as model trans-
formations. By mapping this model to graphs and graph
transformations, we can exploit graph transformation
techniques such as critical pair analysis to find contexts
for which the resulting application model is ambiguous.
We validate our approach by means of an example of
a mobile city guide, demonstrating that we can iden-
tify subtle context interactions that might go unnoticed
otherwise.
Key words context-aware model – model transforma-
tion – critical pair analysis – context adaptation – con-
text coverage
1 Introduction
Context-aware computing refers to the idea that mobile
devices (such as smart phones and tablet PCs) can sense
what is happening around them and respond accord-
ingly. One example application is a mobile city guide:
city visitors are carrying a portable device that alerts
them when they approach a point of interest (e.g. an
architectural curiosity, a special restaurant, . . . ). While
alerting the visitors, the city guide adapts itself to the
visitor’s preferences (e.g., language of use — English or
Arabic), profiles (e.g., child or adult) and abilities (e.g.,
pedestrian, bike, wheel-chair, . . . ).
Modeling such context-aware applications is a real
challenge, certainly given the rapidly increasing num-
ber of sensors in mobile devices (e.g., light, compass,
GPS, accelerometer, gyroscope, . . . ). Separation of con-
cerns remains a guiding design principle for such appli-
cations, hence good designers will model the applica-
tion such that the variables composing the contexts are
as independent as possible. For example, in the mobile
city guide, the choice of landscape or portrait mode for
the display screen is independent from the type of net-
work connection used to retrieve data to be displayed.
Nevertheless, the very nature of context-aware appli-
cations implies that some variables will affect one an-
other. For example, the mobile city guide should adapt
its data download behaviour depending on the available
network connection: using a wifi-connection with unlim-
ited download capacity should result in videos about the
nearby points of interest, while with a paying mobile
data connection the device should restrict itself to show-
ing low-resolution pictures only.
In that sense, a context-aware application can be
represented as a multi-dimensional design space where
the axes represent the variations that may occur for a
given context variable, and where each point in the de-
sign space represents the expected behaviour of an ap-
plication for a given configuration of context variables.
A model of a context-aware application then specifies
what happens when a given context variable changes,
i.e. what happens when we move from one point to an-
other. Making the realistic assumption that the number
of dimensions is large, it should be clear that even when
most axes of the design space are effectively indepen-
2 Degrandsart, Sylvain et al.
dent, exploring and analyzing such a multi-dimensional
design space is a real challenge.
In this article, we present the Context-Aware Ap-
plication model (CAA), where context adaptations are
specified explicitly as graph transformation rules and
critical pair analysis [1] is used as a verification tool.
Starting from an initial application model (named the
origin context), the critical pair analysis allows to enu-
merate all reachable contexts, this way exploring the
context design space. Moreover, for those context vari-
ables that depend on one another, the critical pair analy-
sis also identifies the transformation sequences resulting
in conflicts, this way revealing contexts for which the
resulting application model is ambiguous.
The paper itself is set up as a feasibility study, where
we investigate how one could use critical pair analysis to
find contexts for which the resulting application model
is ambiguous. To that extent, we validate the Context-
Aware Application model (CAA) using a “proof-by-con-
struction” of a mobile city guide application which has
been deployed on an Android phone. Starting from a
non-trivial application model specifying the behaviour
of the mobile city guide in a single context called the ori-
gin context (1 UML class diagram specifying 18 classes;
3 UML activity diagrams specifying 12 tasks; 1 user-
interface model specifying 4 screen layouts) we define 11
context adaptations, each one of them specifying what
should happen when a single context variable changes.
With these transformations, we perform a critical pair
analysis, which reveals that 131 out of 256 contexts of
the 5 dimensional context space can be reached. The
remaining 125 contexts are unreachable because their
context-specific models are ambiguous: the sequence of
context transformations needed to obtain them contains
conflicts. As such, we demonstrate that using the CAA
model, a designer can identify subtle context interactions
that might go unnoticed otherwise.
The remainder of this article is structured as follows:
Section 2 presents the exemplar that is used through-
out the article to illustrate the core elements composing
the CAA model. Next, Section 3 provides a definition of
a context and relates it to other definitions drawn from
the literature. This serves as an introduction to the CAA
model in Section 4, which is then mapped onto graphs
and graph transformations in Section 5. To validate the
exploration and analysis mechanism, we demonstrate the
critical pair analysis on the exemplar of the mobile city
guide in Section 6. We discuss about the lessons learned,
the limitations of our approach and some design choices
in Section 7 leading to Section 8 that relates the CAA
model to existing model-driven engineering solutions for
specifying and verifying context-aware applications. Sec-
tion 9 concludes by summarising the contributions of this
article.
2 A Specification Exemplar: The Mobile City
Guide
The archetypical example for context-aware computing
is a mobile museum guide, where “museum visitors are
endowed with a portable device which reacts to changes
of contexts, [. . . ] alerting visitors with hints and stimuli
on what is going on in each particular ambient” [2]. In
that sense, the mobile museum almost obtained the sta-
tus of a “specification exemplar”: a self-contained, infor-
mal description of a problem in some application domain
proposed as unique input for the specification process [3].
Unfortunately, the mobile museum guide in its current
incarnation lacks the necessary reality check to make it
a true specification exemplar.
Indeed, on the one hand a good specification exem-
plar should be sufficiently small to allow for condensed
representation in academic papers and textbooks and al-
low for manual inspection and comparison of results. In
this respect, the mobile museum guide clearly qualifies,
as it has been used to demonstrate modelling practices
for context-aware applications [2,4]. On the other hand,
in spite of miniaturization, a good exemplar should also
represent a real-world specification task in such a way
that it has properties which are not immediately obvious
by inspection. This reality check also avoids the problem
that specifiers interpret reality in order to better suit
the specification. Reviewing the original mobile museum
guide exemplars (i.e. [2,4]) this reality check is some-
how missing as the example so far was mainly used to
illustrate the advantages of a single modelling approach.
Consequently, three Belgian research groups aiming to
facilitate the development of context-aware applications
have contacted the City of Mons tourism office, which
—in preparation of the Cultural Capital of Europe 2015
event— is preparing a mobile city guide. These three
research groups have mixed the touch of realism pro-
vided by the city of Mons with the archetypical mobile
museum guide example to deduce the mobile city guide
as a more realistic specification exemplar “promoting re-
search and understanding among multiple researchers or
research groups” [3].
In this section we list those elements of the exem-
plar relevant for the remainder of the article. Since we
do not have the space to provide a complete and de-
tailed description of the mobile city guide we refer the
interested reader to http://lore.ua.ac.be/Research/
Artefacts/mobilecityguide.
2.1 Mobile City Guide — Scope Description
The mobile city guide is an interactive application run-
ning on mobile devices (such as a smart phone or a tablet
PC) that presents information about points of interest
in the vicinity of the person carrying the device. To in-
crease interactivity, this information is displayed when
A Transformation-Based Approach to Context-Aware Modeling 3
Fig. 1 Mobile city guide presenting information about a
point of interest.
the user is approaching one of these points of interest.
The presented information can be of various kinds: pic-
tures, text, video, sound,. . . When approaching a point
of interest, the application should quasi-instantaneously
present a picture, a name and a small description and
allow a user to request more information if necessary.
Video and sound may be played on demand, depend-
ing on the availability of a connection to an external
database and memory available on the device.
Figure 1 shows a screenshot of how such a mobile ap-
plication might display a particular point of interest (in
this case, a church). The display shows active buttons
linking to video and music content concerning this point
of interest because there is an open connection to the
database providing extra media files. To guide the user
towards other points of interest situated in the neigh-
borhood, the mobile city guide displays the name, direc-
tion and distance to all points of interest in the vicinity.
In this particular case, Figure 2 illustrates what hap-
pens when the connection to the maps database is not
available; the application then uses information from the
global positioning system (GPS) to have arrows pointing
in the general direction.
2.2 Mobile City Guide — Context Variables
The mobile city guide is context-aware and therefore
tries to optimize its interactivity by taking into account
its current context of use. In this exemplar the mobile
city guide must adapt itself to the following variables:
Fig. 2 Mobile city guide guiding the user to other points of
interest.
User language preference: All texts and menus of the
mobile application should be presented depending on
the language preferences selected by the user. De-
pending on the language, texts might flow from left
to right (e.g., French, English) or right to left (e.g.,
Hebrew and Arabic). The mobile city guide must sup-
port at least one language in each category.
Screen orientation: the orientation of the device on which
the mobile city guide is running should affect the way
in which the information is displayed. The mobile city
guide must support at least portrait and landscape
mode.
Mobile data connection: Many (but not all) of the mo-
bile devices use a mobile data connection to connect
to the Internet over the mobile phone network. De-
pending on the tariff plan of the mobile data connec-
tion the mobile city guide may adapt how much data
is downloaded over this connection and whether it
should open/close the connection as quickly as pos-
sible, or leave it open for long periods of time. There-
fore, the mobile city guide must at least support the
following modes: (a) no data connection available; (b)
a pay per connection fee; (c) a pay per Mb connection
with restricted download capacity; (d) a connection
with unlimited download capacity.
Wifi availability: The availability of a wifi connection
may be exploited to proactively download and cache
information about points of interest in the vicinity,
in order to enhance and speed up user interaction,
and to reduce the need of using a slower and more
expensive mobile data connection. A wifi connection
can either be available or unavailable.
4 Degrandsart, Sylvain et al.
Precision of geo-positioning: To guide the user to nearby
points of interest (An example is shown in Figure 2)
the precision of the built-in geo-positioning hardware
(GPS or GPRS) is a crucial factor. To adapt the be-
haviour for optimal guidance, the mobile application
guide must at least support the following precision
modes: 2 meters, 5 meters, 10 meters or 20 meters.
2.3 Mobile City Guide — Platform Independent Model
With the above requirements, the design space for the
context-aware model consists of five dimensions; each di-
mension representing between 2 and 4 possible values for
a context variable. As a result, the design space for the
complete mobile city guide spans 4 × 2 × 4 × 2 × 4 = 256
configurations of context variables. A complete require-
ments specification should state for each combination
what the desired application behaviour should be.
One possible way to describe the desired behaviour
for each of these configurations is modelling each configu-
ration in a so-called platform-independent model (PIM) [5].
Such a platform-independent model is suited for a re-
quirements specification for a mobile platform, as it al-
lows to abstract away from the device specific details
(operating system, display, . . . ) yet describes precisely
how an application should behave in each context.
Three aspects of a mobile application are especially
relevant in the context of such a platform-independent
model.
1. Structure model: Describing the structure of the ap-
plication in terms of classes and their relations; UML
class diagrams are well suited for this purpose. Fig-
ure 3 shows an example.
2. User Interface model: Describing the graphical user
interface independently of the particular widgets to
be used. Since the UML does not provide a nota-
tion for screen layouts, we relied on a special pur-
pose modeling language named CAP3 [6]. Figure 4
shows an example; we elaborate on the use of CAP3
in Section 7.
3. Activity model: Describing how the application may
be used to perform activities in order to reach users
goals; UML activity diagrams are well suited for de-
scribing these. Figure 5 shows an example.
Given that the design space for the complete mobile
city guide spans 256 configurations of context variables
and that each of these configurations in principle con-
tains an entire platform-independent model of the mo-
bile city guide, it is clear that automated support is desir-
able. We adopt a transformation-based approach, which
is explained in the following sections.
Fig. 3 The part of the class diagram CD
0
specifying the
classes used to display information about a point of interest.
Fig. 4 The part of the CAP3 model CA
0
specifying that
when the application is in the vicinity of a point of interest,
the display screen in portrait mode should include an icon, a
title, a description and a link to a video or sound clip.
3 Definition of Context
When people interact, they are using more than the ex-
plicit information that is exchanged. People are able to
capture and understand surrounding information, the
context of the discussion, and use it to interact more ef-
fectively. But when humans-computers takes place, this
crucial surrounding information has to be defined pre-
cisely in order for the application to understand it. A lot
of research has been conducted in the field of human-
computer interaction to define and model contexts as
well as its implication on software artifacts [2,7,8,9,10,
A Transformation-Based Approach to Context-Aware Modeling 5
Fig. 5 The part of the activity diagram AD
0
used to ac-
tivate or deactivate the buttons when the video or sound
information is available.
11]. It is not the purpose of this article to discuss or
condense all the classifications of context, but it is im-
portant to elicit some of them to position the context
representation we propose to use. Therefore, it is impor-
tant to stress that we focus on context-awareness that
results in context adaptation impacting the interaction
between an application and its users.
The notion of context was introduced by Schilit and
Theimer [7] as location, identities of nearby people and
objects, and changes to those objects. Brown et al. [12]
define context as location, identities of the people around
the user, the time of day, season, temperature,. . . Preu-
veneers et al. [8] define context as the user, environ-
ment, platform and services. Elicitation definitions are
discussed in more detail by Dey and Abowd [9] who come
up with the following generalized definition:“Context is
any information that can be used to characterize the sit-
uation of an entity. An entity is a person, place, or object
that is considered relevant to the interaction between a
user and an application, including the user and appli-
cations themselves”. Bolchini et al. [2] expose a general
analysis framework for comparing these context models.
In contrast to these definitions, we are not interested in
the meaning or important entities nor the way context
information is collected, but more on its concrete repre-
sentation.
Bolchini et al. [2] propose a context classification
framework and use it to classify what they consider the
most interesting approaches to describe context available
in literature. We refer to their work for a more elaborate
overview of context modeling techniques. The context-
representation mechanism used in this paper falls in their
category E, “Context as a matter of selecting relevant
data, functionalities and services (data or functionality
tailoring)” for which they state among others the follow-
ing “Context definition is typically centralized, context
history and reasoning are often not provided” and “the
application as subject, the possibility to express both
variable context granularity, valid context constraints,
and multi-context models” [2]. Similar to the context
representation presented in this paper, they take a for-
mal approach. Most of these statements correspond to
our description and use of context.
We define context in a variable perspective, that does
not define entities that are considered part of the con-
text, but instead focuses on their status representation
in terms of variables. For a given application and at a
given time, the context will be unique. If two entities are
relevant for the application, the values of the variables
representing the state of these two entities are compos-
ing the context. Schmidt et al. [10] already use a vari-
able perspective, but at a lower level of abstraction, as
they are mapping each device sensor to a variable. They
aggregate different variables in order to obtain meaning-
ful contexts. They are considering that an application
can be in a multitude of contexts at the same time and
that these contexts do not interfere with one another.
Schmidt et al. group their contexts into sets of exclu-
sive contexts depending on their impact on the system,
which is closely related to our definition of variable.
Coutaz and Rey [11] also define context in terms of
variables, but they consider context to be a composition
of situations observed between a reference time t
0
and
the actual time t. Each situation at a time t is related to
a user performing a certain task. This definition formal-
izes several important aspects of the definition by Dey
and Abowd and introduces the time dimension. All these
aspects are important when trying to build a runtime
infrastructure, but are less relevant for the goal of this
article, which focuses on design time and merely con-
siders the size of the composition of all these situations.
We thus use a more generic version of the definition of
Coutaz and Rey. Our definition of context is as follows:
Definition 1 [Context and context domain]
Let n ∈ N be the finite number of variables that repre-
sent the state of the entities relevant for a context-aware
application. For all i ∈ [1, n], each variable is defined
by a finite set V
i
that represents all possible values. The
context domain is defined by C = V
1
× V
2
× . . . × V
n
. A
context c = (v
1
, v
2
, . . . v
n
) ∈ C is a tuple of n values, one
for each variable domain V
i
. Using the projection oper-
ator π
i
: V
1
× V
2
× . . . × V
n
→ V
i
one can obtain the i-th
value of a context π
i
(c) = v
i
.
For the mobile city guide, the context domain is C =
Language × Orientation × Data
connection× W if i ×
P ositioning precision where:
Language = {English, Dutch, F rench, Arabic},
Orientation = {portrait, landscape},
