Presented at BENEVOL, the Belgian-Netherlands Software Evolution Seminar, on 4 December 2015 in Lille, France.

1. BREAKING DOWN THE WALLS
A UNIFIED VISION ON
CONTEXT-ORIENTED SOFTWARE ENGINEERING
Kim Mens, Nicolás Cardozo, Anthony Cleve & Bruno Dumas
Presented at BENEVOL 2015, 3-4 December 2015, Lille, France

2. “Traditionally, hardware and software were
input-output systems that took input
explicitly given to them by a human, and
acted upon that input alone to produce an
explicit output. Now, this view is seen as
too restrictive. …
-Henry Lieberman & Ted Selker
Out of Context: Computer Systems That Adapt To, and Learn From, Context.
IBM Systems Journal, Vol 39, Nos 3&4, p.617-631, 2000
system
input output

3. “… Smart computers, intelligent agent
software, and digital devices of the future
operate on data that is not explicitly given
to them, data that they observe or gather
for themselves. These operations may be
dependent on time, place, weather, user
preferences, or the history of interaction. In
other words: context.
-Henry Lieberman & Ted Selker
Out of Context: Computer Systems That Adapt To, and Learn From, Context.
IBM Systems Journal, Vol 39, Nos 3&4, p.617-631, 2000

4. “Computer systems will increasingly need to
be sensitive to their context to serve their
users better.
-Eli Rohn
Predicting Context Aware Computing Performance.
Ubiquity, p.1-17, Feb. 2003

5. FROM “CONTEXT-BLIND” SOFTWARE DEVELOPMENT
system
input output
Traditional software development approaches are mostly oblivious of the physical,
technical and human environment in which the software will be used.
Many chances of delivering improved services are thus missed.

6. TO DEVELOPING SYSTEMS WITH “CONTEXT” IN MIND
system
input output
Dedicated development approaches are needed that help overcoming this limiting
vision by putting developers in the right state of mind to build dynamically
adaptable software systems from the ground up.

7. TOWARDS A UNIFIED VISION ON
CONTEXT-ORIENTED SOFTWARE ENGINEERING
Presentation goals:
➤ quick overview of research on context-aware software
➤ from different research perspectives
➤ conceptual and implementation framework
Framework is our research vehicle
➤ framework, simulator and case study being implemented
➤ focus mainly on user, PL, UI and DB perspectives
➤ validate on real case studies (mainly web and mobile)
Relevance to BENEVOL:
context-oriented
software systems can
adapt and evolve

8. SOME DEFINITIONS
A software system is context-aware if it can extract, interpret
and use context information and adapt its functionality to the
current context of use. [Rohn2003]
Context is everything but the explicit input and output to a
system. [Lieberman&Selker2000]
A context-oriented software system is a context-aware system
that has an explicit representation of context and contextual
variations as first class citizens. [our definition]

9. CONTEXT-AWARE SYSTEMS
Idea appeared ~ late 1980s; increasingly studied since ~ 2000.
Fig. 2. Classification of articles by publication year.
Table 3
Classification of arti
Journal articles
IEEE Pervasive Com
Personal and Ubiqu
IEEE Internet Comp
Wireless Personal C
IEEE Intelligent Sys
Mobile Networks a
IEEE Transactions o
The Others
Expert Systems wit
Computer Commun
Journal of Systems
Pervasive and Mobi
World Wide Web
IEEE Wireless Comm
Interacting with Co
Total
J.-y. Hong et al. / Expert Systems with Applications 36 (2009
Jong-yi Hong, Eui-ho Suh, Sung-Jin Kim
Context-Aware Systems: A literature review and classification.
Expert Systems with Applications 36, 2009

10. CONTEXT-AWARE SYSTEMS
From a variety of research angles [Hong&al2009]:
➤ conceptual: guidelines, frameworks, algorithms, context
reasoning and context data management
➤ networks: network protocols, sensor networks, …
➤ middleware for distributed context-aware applications
➤ applications: studies and
development of dedicated
context-aware applications
(e.g., a smart tour guide)
➤ user-interface technology
and usability studies
systems Ranganathan, Campbell, Ravi, and Mahaja
(2002), Sumi and Mase (2000), Sumi and N
Chen (2007)
M-commerce Anagnostopoulos, Tsounis, and Hadjiefthy
Frank, and Hansen (2003), Broens, Haltere
Santoro (2006), Kwon (2003), Kwon and S
Mitteregger (2007), Mandato, Kovacs, Hoh
(2005), Skov and Høegh (2006), Stylianos
Broens (2007), Wohltorf, Cissée, and Riege
Web service Blake, Kahan, and Nowlan (2007), Debaty,
(2004), Kanter (2003), Kwon (2006b), Kw
Pearce (2003)
Table 9
References of user infrastructure layer.
Classification criteria References
User infrastructure Interface Alexander and Matth
(2005), Hong, Dickso
Salovaara, and Lopez
(2003), Rehman, Sta
Usability Barnard, Yi, Jacko, an

11. CONTEXT-ORIENTED PROGRAMMING
Focusses on the programming angle:
Enabling context-aware software adaptability
through a programming language engineering approach:
➤ dedicated programming languages to express
context-driven behaviour adaptation
➤ contexts and behavioural variations to context
as first class language citizens

12. SOME CONTEXT-ORIENTED PROGRAMMING LANGUAGES
Subjective-CAmbience
Context Traits
2008 20132011
Sebastián Gonzalez, Kim Mens, Alfredo Cádiz
Context-Oriented Programming with the Ambient Object System.
Universal Computer Science 14(20), 2008.
Sebastián Gonzalez, Nicolás Cardozo, Kim Mens,
Alfredo Cádiz, Jean-Christophe Libbrecht, Julien Goffaux
Subjective-C: Bringing Context to Mobile Platform Programming.
Software Language Engineering (SLE), 2010.
Sebastián Gonzalez, Kim Mens, Marius Coluacioiu, Walter Cazzola
Context Traits: Dynamic Behaviour Adaptation through Run-Time Trait Recomposition.
Aspect-Oriented Software Development (AOSD), 2013.

13. MOTIVATING EXAMPLE: ON-BOARD CAR SYSTEM
Context Traits
Nicolás Cardozo, Kim Mens, Sebastián González, Pierre-Yves Orban, Wolfgang De Meuter
Features on Demand.
Variability Modelling of Software-intensive Systems (VaMoS), 2014

14. MOTIVATING EXAMPLE: AN ON-BOARD CAR SYSTEM
Context Traits
Pierre-Yves Orban
Using Context-Oriented Programming for Building
Adaptive Feature-Oriented Software for Car On-Board Systems.
Master thesis in Computer Science, Université catholique de Louvain, 2013

15. MOTIVATING EXAMPLE: ON-BOARD CAR SYSTEM
Context-specific features
location = EU
Display speed reading using the
metric system units

16. MOTIVATING EXAMPLE: ON-BOARD CAR SYSTEM
Context changes trigger behavioural adaptation
location = UKlocation = EU

17. MOTIVATING EXAMPLE: ON-BOARD CAR SYSTEM
Context changes trigger behavioural adaptation
location = UKlocation = EU
Display speed reading using the
imperial system units
Display speed reading using the
metric system units

18. MOTIVATING EXAMPLE: ON-BOARD CAR SYSTEM
But need to consider UI aspect too:
If display not refreshed, nothing
may happen, or only value would
change but not the unit.
location = UK
Display speed reading using the
imperial system units
ImperialSystem = Trait({
var CONV_RATIO = 0.621371192;
getSpeed: function(msg) {
_val = this.proceed();
Math.round _val * CONV_RATIO; }
getHtml: function() {
display.setGaugeDisplay(this.proceed().replace("km/h", "mph")); }
});
Context Traits

19. TOWARDS A UNIFIED VISION ON [RECALL]
CONTEXT-ORIENTED SOFTWARE ENGINEERING
➤ Our ambition …
➤ is to provide a software development approach to support the
development of software systems that can dynamically adapt
their behaviour to the current context of use, to provide the
most appropriate behaviour according to that context
➤ But our case studies so far showed that this cannot be achieved
without taking the user, database and user interface aspects into
account as well
➤ Hence the need for a more unified vision on context-oriented
software engineering
➤ To achieve this we are currently developing a conceptual and
implementation framework

20. LAYERED ARCHITECTURE OF CONTEXT-AWARE SYSTEMS
➤ To achieve a unified vision on context-oriented software
engineering we are developing a conceptual and
implementation framework
➤ Context-aware systems typically adopt a layered software
architecture. [Miraoui&al2008]
➤ separates context sensing from context use
➤ to increase the level of context abstraction
➤ hides the physical abstraction sensing complexity
➤ enhances both reusability and extensibility
Moeiz Miraoui, Chakib Tadj, Chokri ben Amar
Architectural Survey of Context-Aware Systems in Pervasive Computing Environment.
Ubiquitous Computing and Communication 3(3), 2008.

21. LAYERED ARCHITECTURE OF CONTEXT-AWARE SYSTEMS
Composed of following components [Miraoui&al2008]:
Sensor: physical sensing of contextual information
Interpretation: transformation of raw information
into a more significant and useful information
Reasoning: deduces and predicts new contextual
information
Storage and management: basic management of
contextual information
Adaptation: adaptation of provided services
according to the current context
Adaptation
Reasoning
Storage
Management
Interpretation
Sensor
Context

22. CONTEXT
The context of use can be decomposed into three facets:
➤ end-users who interact with the system
➤ physical environment in which they and the system are
working
➤ hardware and software computing platform on which
the users and the system carry out their actions
Gaëlle Calvary, Joëlle Coutaz, David Thevenin,
Quentin Limbourg, Laurent Bouillon, Jean Vanderdonckt.
A Unifying Reference Framework for Multi-Target User Interfaces
Interacting with Computers 15(3), 2003
Physical
environment
Computing platform
(hardware and software)
User
Context =
+ +

23. LAYERED ARCHITECTURE OF CONTEXT-AWARE SYSTEMS
Storage Layer
Management Layer
Interpretation Layer
Physical ComputingUser
Adaptation Layer
Context
Sensor Layer
External environment
Internal environment
Reasoning Layer

24. LAYERED ARCHITECTURE OF CONTEXT-AWARE SYSTEMS
RELABELLED
Execution
Representation
Discovery
Physical ComputingUser
Context
External environment
Internal environment
Handling
ReasoningInterpretation
Interaction Sensors

25. TOWARDS ARCHITECTURE OF CONTEXT-ORIENTED SYSTEMS
Representation
Handling
Discovery
ReasoningInterpretation
Physical
environment
Computing platform
(hardware and software)
Execution
User
Interaction
Actuators
External environment
Internal environment
Output Device SensorsInput Device API APIAPI

26. OUR CONTEXT-ORIENTED ARCHITECTURE
Representation
Handling
Discovery
Context–Variants
Mapping
ReasoningInterpretation
Computing platform
(hardware and software)
Context & Feature
Representation
Execution
User
Interaction
Actuators
External environment
Internal environment
Output Device SensorsInput Device API APIAPI
Context
Activation
Variant Selection
Variant Declaration
& Composition
Context Physical
environment

27. HANDLING LAYER
➤ Context Activation
➤ in response to detected context changes
➤ selects what contexts and features become (de)activated
➤ updates context & feature representation accordingly
➤ to store information on activation status
➤ takes into account context & feature dependencies
➤ Feature & Variant Selection
➤ (de)selects context-specific behaviour
according to currently (in)active contexts & features
Handling
Context
Activation
Feature and Variation
Selection

28. REPRESENTATION LAYER
➤ Context & Feature Representation
➤ possible contexts & features of the system
➤ currently active contexts and selected features
➤ declaration of dependencies between contexts & features
➤ Context-Variants Mapping
➤ mapping of chosen contexts & features to corresponding behavioural variants
➤ Variant Declaration & Composition
➤ behaviour of the different variants
➤ composition of variants into bigger ones
➤ tagging of some variants as “features”
Representation
Context–Variants
Mapping
Context & Feature
Representation
Variant Declaration
& Composition

29. CONTEXT & FEATURE REPRESENTATION
➤ Idea: Using feature diagrams … [HartmannTrew2008]
➤ to represent possible contexts and features
➤ and the dependencies between them
➤ optional/mandatory,
“implies”, “requires”, “excludes”,
sub features and cardinalities
➤ plus a rationale for these dependencies
➤ Features are just a special kind of context
➤ represents the contextual information that this feature
is desired by the user
➤ Plus information on the activation status
➤ (in)active; (de)activation requested; being (de)activated
Context & Feature
Representation
range and the dependencies between different features.
By making this separation, a feature model contains
the possible features, with dependencies that capture
the (technical) dependencies between the features.
The dependencies related to the context are
modeled as dependencies between the Context
Variability model and the feature model, as shown in
figure 1. These dependencies are captured in the same
way as dependencies within a conventional feature
model.
Context
Variability
Model
FeatureModel
<<1..2>>
MPL-FeatureModel
Dependencies
Context
Variability
Model
FeatureModel
<<1..2>>
MPL-FeatureModel
Dependencies
Fig. 1. MPL-Feature Diagram
The types of dependencies between the Context
Variability model and the Feature Model include
“requires” and “excludes”, as is common with
conventional Feature models. Besides these
dependency relations we will introduce a new relation.
This type of relation narrows the cardinality of either a
feature or a group, as will be illustrated in section 3.3.
Furthermore, each dependency can be annotated with a
rationale for the constraint imposed by the context. It
is important that the rationale is captured, e.g. to assess
the impact of requirements changes. For instance a

30. CONTEXT & FEATURE REPRESENTATION
model with a graphical representation of the
dependencies between the Context Model and the
Feature Model (for reasons of clarity only a subset of
the dependencies are shown).
Blue-
Tooth
Context
Continent
Type
Car-Brand
Budget Mid High
CarAEurope Asia USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
<<excludes>>
<<requires>>
<<sets cardinality>>
Protocol
Flexray ZigBee
Interface
USBCard-
Slot
Maps
Features
EU USA ….
Connections
….
<<1..n>>
<<0..2>>
<<excludes>>
Blue-
Tooth
Context
Continent
Type
Car-Brand
Budget Mid High
CarAEurope Asia USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
<<excludes>>
<<requires>>
<<sets cardinality>>
Protocol
Flexray ZigBee
Interface
USBCard-
Slot
Maps
Features
EU USA ….
Connections
….
<<1..n>>
<<0..2>>
<<excludes>>
Fig. 4. MPL-Feature Diagram of the
infotainment system
Herman Hartmann, Tim Trew
Using Feature diagrams with Context Variability
to model Multiple Product Lines for Software Supply Chains
Software Product Line (SPLC), 2008
model and the feature model represent the specific
requirement of each classifier. Some examples of
dependencies and their rationales are presented below,
using a textual notation.
European Maps are part of the Navigation system
and in Europe DVDs with region 2 must be supported:
Continent.Europe <<requires>>
European Maps {Rationale: Obvious}
Continent.Europe <<requires>> DVD-
region 2 {Rationale: Standard}
Manufacturer CarA may not support a specific
communication protocol:
Car-Brand.CarA <<excludes>> FlexRay
protocol
The budget (small) configuration can only support a
USB interface or a Card Slot, not both, because the
size of the front panel is too small.
Type.Budget <<sets group cardinality
of >> MP3 interface >> << to>> [0..1]
{Rationale: Technical; Too small size
of front}
Context: The infotainment manufacturer creates
products for different Car manufacturers: CarA, CarB,
CarC and CarD, for different continents: USA, Asia
and Europe, and has three product types: budget, mid-
range, high-end. The budget, with a small feature set,
fits into the space used for ordinary car radios. The
mid-range type contains more features, is larger and
therefore needs more cabin space. The high-end
contains many possible features, is significantly larger
then the mid-range, so needs space in the trunk.
A diagram of the Context Variability model is shown
in figure 3.
Context
Continent
Type
Car-Brand
Budget Mid High-end
CarAEurope ASIA USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
Context
Continent
Type
Car-Brand
Budget Mid High-end
CarAEurope ASIA USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
Fig. 3. Context Variability Diagram of the
infotainment system
The dependencies between the context variability
model and the feature model represent the specific
requirement of each classifier. Some examples of
dependencies and their rationales are presented below,
Dependencies can also relate to different context
classifiers: In the USA, CarA does not sell budget:
Continent.USA AND car type.CarA
<<exclude>> budget {Rationale:
Logistics}
Or become even more complex: In the Asian market,
CarB only sells midrange without Memory-Card slot:
Car Type.CarB AND Continent.Asia AND
Type. Mid-range <<exclude>> Memory-
Card. {Rationale: Commercial}
Figure 4 shows a diagram of the MPL-Feature
model with a graphical representation of the
dependencies between the Context Model and the
Feature Model (for reasons of clarity only a subset of
the dependencies are shown).
Context
Continent
Type
Car-Brand
Budget Mid High
CarAEurope Asia USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
<<excludes>> Maps
Features
Connections
<<excludes>>
Context
Continent
Type
Car-Brand
Budget Mid High
CarAEurope Asia USA CarB CarC CarD
<<0..n>>
<<0..n>>
<<0..n>>
<<excludes>> Maps
Features
Connections
<<excludes>>

31. CONTEXT-VARIANTS MAPPING
➤ Mapping contexts (and features)
➤ to variants that implement behaviour specific to that context
➤ Could be a simple mapping of the form
➤ context —> { variant1, …, variantn }
➤ though more complex conditions could be considered as well
➤ ( contextA OR contextB ) AND ( NOT contextC ) => { … }
➤ Add a structured Rationale for each mapping rule as well
➤ useful to understand the rule, to resolve conflicts, to offer
user feedback
➤ Mapping could also contain declaration of transitions
Context–Variants
Mapping

32. VARIANT DECLARATION & COMPOSITION
➤ Adaptation:
➤ the process of changing to fit some purpose of
situation; the process of adapting
➤ Variation:
➤ a change in the form, position, condition or amount
of something
➤ Variant:
➤ something that is different in some way from others
of the same kind
➤ Feature:
➤ some variants can be tagged as feature if they
represent “an interesting or important part or
ability”
Variation
Variation
ø
Adaptation
Adaptation
Variant
Variant
Variant Declaration
& Composition

33. VARIANT DECLARATION & COMPOSITION
➤ Variation declarations contain
➤ a code, UI and DB component
➤ a prologue and epilogue
➤ definition of possible transitions
➤ Composition mechanism can
➤ compose variations into bigger “variants”
➤ (some variants can be tagged as "features")
➤ refine and adapt earlier behaviour
➤ define conflict resolution policies
Variant Declaration
& Composition
Variation

34. OUR CONTEXT-ORIENTED ARCHITECTURE
Representation
Handling
Discovery
Context–Variants
Mapping
ReasoningInterpretation
Computing platform
(hardware and software)
Context & Feature
Representation
Execution
User
Interaction
Actuators
External environment
Internal environment
Output Device SensorsInput Device API APIAPI
Context
Activation
Variant Selection
Variant Declaration
& Composition
Context Physical
environment
context & feature diagram
active contexts & features
dependencies between contexts & features
Mapping of contexts and features
to corresponding variants
Declaration of different variants
and how they are composed

35. “To be continued…
-Kim Mens