Modern software systems demand more and more smart capabilities depending on their context of use, as well as the ability to dynamically adapt these capabilities according to sensed context changes. This requires appropriate techniques for modelling, representing and handling context-aware software variability. While traditional variability modelling approaches like feature orientation and software product lines are evolving to address the increased dynamicity and context specificity required for this new generation of software systems, new paradigms such as context-oriented programming have emerged. Although developed independently, since they address similar issues, many similarities exist between these approaches. The purpose of this work is to define, categorise and compare key concepts shared by these approaches. Such a taxonomy is a first step towards a better understanding of the differences and similarities between different approaches for managing context-aware software variability, and to achieve a cross-fertilisation between them.

1. (TOWARDS)
A TAXONOMY OF CONTEXT-AWARE
SOFTWARE VARIABILITY APPROACHES
KIM MENS — UCL / ICTEAM — BELGIUM
WITH: RAFAEL CAPILLA, NICOLÁS CARDOZO & BRUNO DUMAS
LASSY 2016 — WORKSHOP ON LIVE ADAPTATION OF SOFTWARE SYSTEMS
14 MARCH 2016, MÁLAGA, SPAIN — COLOCATED WITH MODULARITY 2016

2. CONTEXT-ORIENTED
PROGRAMMING
LANGUAGES
TOWARDS LIVE SOFTWARE VARIABILITY
CONTEXT-AWARE
SOFTWARE VARIABILITY
DYNAMIC
SOFTWARE PRODUCT LINES
SOFTWARE FEATURES
AS A SERVICE
SELF-ADAPTIVE
SOFTWARE SYSTEMS
RUNTIME
RECONFIGURATION
FEATURE MODELS
WITH
CONTEXT VARIABILITY
FEATURE-ORIENTED
PROGRAMMING

3. SOME DEFINITIONS
CONTEXT-AWARENESS
• 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
• The context of use can be decomposed into three facets:
• the end-users who interact with the system
• the physical environment in which they and the system are working
• the hardware and software computing platform on which the users and
the system carry out their actions
Eli Rohn
Predicting Context Aware Computing Performance.
Ubiquity, p.1-17, Feb. 2003
Gaëlle Calvary, Joëlle Coutaz, et al.
A Unifying Reference Framework for Multi-Target User Interfaces
Interacting with Computers 15(3), 2003

4. DEFINITIONS
FEATURES & CONTEXTS
• Context is everything but the explicit input and output to a
system.
• A feature is an end-user-visible characteristic of a system.
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
Kyo C. Kang, Sholom G. Cohen, et al.
Feature-Oriented Domain Analysis (FODA) – Feasibility Study
Technical Report CMU/SEI-90-TR-21, 1990

5. CHARACTERISTICS
CONTEXT-AWARE SYSTEMS
• Software systems featuring run-time context-aware adaptation can activate or
modify features dynamically upon observed context changes
• Their context-awareness varies according to various characteristics
• Adaptation Type
• what types of (dynamic) system adaptation do they require or support?
• Dynamic Variability
• what mechanisms do they use for implementing/achieving dynamic variability?
• Dependencies
• how do they model, represent or manage dependencies between contexts and/
or features modelled, represented and managed?

6. DIMENSIONS
TOWARDS A TAXONOMY
Different kinds of context-aware software variability approaches
can be classified according to different dimensions :
1. Supported variability mechanisms
according to their binding time
2. Types of features
according to their context-awareness
3. Dependencies
between features and contexts

7. A PATTERN-BASED FORMAT
TOWARDS A TAXONOMY
• TYPE
a unique descriptive name of the classified approach
• INTENT
goal behind the approach and reason for using it
• SCENARIO
scenario of a problem when this approach can or should be used
• APPLICABILITY
different situations under which this approach is usable
• TRADE OFFS
trade offs of using this approach w.r.t. others in the taxonomy

8. EXAMPLE OF A PATTERN
TOWARDS A TAXONOMY
• TYPE : Contextual features
• INTENT : features that vary slightly with context-specific data, but these
variations are internalised in the feature
• SCENARIO : a smart home system switching between three different
temperature modes depending on the temperature in the home
• APPLICABILITY : systems that need to react to or change some basic
behaviour according to data sensed from the environment, using a set of
pre-defined options
• TRADE OFFS : contextual features are not difficult to implement (e.g., as
if-statements inside the feature), but they rely on a connection to a
specific context using contextual data

9. SUPPORTED VARIABILITY MECHANISMS
TOWARDS A TAXONOMY
• Software variability approaches can vary from very static to very
dynamic, for example:
• Traditional static variability approaches
• Closed dynamic variability approaches where all features and their
contextual variations are predefined up front. (Closed to new
variants; does not support unforeseen contexts or features.)
• Open dynamic variability approaches where features can be
added, removed or modified dynamically. (Even features that
were not originally foreseen.)

10. TYPES OF FEATURES
TOWARDS A TAXONOMY
• Software variability approaches can vary by the kind of features
they support, from non-contextual features to context-aware:
• Non-contextual features: features are chosen based on a static
selection or configuration of features (e.g., chosen language is
preselected by a user)
• Contextual features: features can vary slightly with context-specific
data, but these variations are internalised in the feature (e.g., a
smart home with three predefined temperature modes)
• Context features: different contextual variants of a feature,
relevant to particular contexts only, have an explicit representation

11. DEPENDENCIES
TOWARDS A TAXONOMY
Variability approaches can vary by how they model and represent dependencies
between features and contexts.
• Traditional feature models: allow to model explicit dependencies between features
such as “requires” and “excludes”
• Two-branches context tree: feature-like model for representing both features and
models but in two separate subtrees
• One-branch context tree: contextual and non-contextual features are entangled in a
single feature model
• Implicit dependencies: when run-time dependencies between contexts and features
exist but they haven’t been modelled explicitly
• Explicit programmer-declared dependencies: as supported by some context-
oriented programming languages such as Subjective-C [Gonzalez et al. 2011]

12. EXAMPLE
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
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>>
Herman Hartmann, Tim Trew
Using Feature diagrams with Context Variability
to model Multiple Product Lines for Software Supply Chains
Software Product Line (SPLC), 2008

13. ABOUT THE TAXONOMY
CONCLUSIONS
• ongoing work: taxonomy is not fully mature nor complete
• dimensions and patterns could be improved or added
• could be used to stir and structure discussions
on context-aware software variability approaches
• we are actively seeking input to improve our taxonomy
(or to collaborate on it)
• future work: complete the taxonomy and use it as a vehicle to
compare context-aware software variability approaches

14. WHAT DO I WANT TO GET OUT OF THIS ?
ABOUT THE WORKSHOP
• Feedback on taxonomy
• taxonomy dimensions + additional patterns
• Collaboration opportunities
• A common case study
• A joint book
• Improved taxonomy
• Feedback on our ongoing work

15. WHAT DO I WANT TO GET OUT OF THIS ?
ABOUT THE WORKSHOP
• (Feedback on our) ongoing work
• a holistic approach towards context-oriented software adaptation
• reconciling the behavioural, user interfaces and database angle
• a unified context-oriented software architecture
• the link between context-orientation and feature modelling
• how to represent features, contexts and their (intra- and inter-)
dependencies ?

16. A HOLISTIC APPROACH TOWARDS CONTEXT-ORIENTATION
(ONGOING WORK)

17. A CONTEXT-ORIENTED SOFTWARE ARCHITECTURE
(ONGOING WORK)
Representation
Handling
Discovery
Context–Feature
Mapping
ReasoningInterpretation
Computing platform
(hardware and software)
Context
Representation
Execution
User
Interaction
ActuatorsOutput Device SensorsInput Device API APIAPI
Context
Activation
Feature Selection
& Composition
Feature Definition
External environment Physical
environment