(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

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

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 RohnPredicting 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

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 SelkerOut 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

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?

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

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

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

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.)

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

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]

EXAMPLE

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, 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}

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).

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

3.4. Extendibility and Scalability

In theory, all kinds of requirements can be captured. The car infotainment manufacturer could use this type of information, for instance, to exclude this combination from the test set or to analyze the commonality and variability in their product families.

However, some of the dependencies shown in the example of section 3.3 are more likely to be maintained and used by the car manufacturers, i.e. the downstream participant in the supply chain. It is their

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, 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}

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).

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

3.4. Extendibility and Scalability

In theory, all kinds of requirements can be captured. The car infotainment manufacturer could use this type of information, for instance, to exclude this combination from the test set or to analyze the commonality and variability in their product families.

However, some of the dependencies shown in the example of section 3.3 are more likely to be maintained and used by the car manufacturers, i.e. the downstream participant in the supply chain. It is their

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, 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}

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).

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

3.4. Extendibility and Scalability

In theory, all kinds of requirements can be captured. The car infotainment manufacturer could use this type of information, for instance, to exclude this combination from the test set or to analyze the commonality and variability in their product families.

However, some of the dependencies shown in the example of section 3.3 are more likely to be maintained and used by the car manufacturers, i.e. the downstream participant in the supply chain. It is their

Herman Hartmann, Tim Trew Using Feature diagrams with Context Variability

to model Multiple Product Lines for Software Supply Chains Software Product Line (SPLC), 2008

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

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

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 ?

A HOLISTIC APPROACH TOWARDS CONTEXT-ORIENTATION(ONGOING WORK)

A CONTEXT-ORIENTED SOFTWARE ARCHITECTURE(ONGOING WORK)

Representation

Handling

Discovery

Context–FeatureMapping

ReasoningInterpretation

Computing platform(hardware and software)

ContextRepresentation

Execution

User

InteractionActuatorsOutput Device SensorsInput Device API APIAPI

ContextActivation

Feature Selection& Composition

Feature Definition

External environment Physicalenvironment