Mar 14, 2016 - A software system is context-aware if it can extract, interpret and use context ... they support, from non-contextual features to context-aware:.
KIM MENS — UCL / ICTEAM — BELGIUM WITH: RAFAEL CAPILLA, NICOLÁS CARDOZO & BRUNO DUMAS
(TOWARDS)
A TAXONOMY OF CONTEXT-AWARE SOFTWARE VARIABILITY APPROACHES
LASSY 2016 — WORKSHOP ON LIVE ADAPTATION OF SOFTWARE SYSTEMS 14 MARCH 2016, MÁLAGA, SPAIN — COLOCATED WITH MODULARITY 2016
TOWARDS LIVE SOFTWARE VARIABILITY
CONTEXT-ORIENTED PROGRAMMING LANGUAGES
FEATURE-ORIENTED PROGRAMMING
DYNAMIC
SOFTWARE PRODUCT LINES
CONTEXT-AWARE SOFTWARE VARIABILITY
FEATURE MODELS WITH
CONTEXT VARIABILITY
SOFTWARE FEATURES
AS A SERVICE
SELF-ADAPTIVE
SOFTWARE SYSTEMS RUNTIME
RECONFIGURATION
CONTEXT-AWARENESS 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 Eli Rohn
Predicting Context Aware Computing Performance.
Ubiquity, p.1-17, Feb. 2003
•
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 Gaëlle Calvary, Joëlle Coutaz, et al.
A Unifying Reference Framework for Multi-Target User Interfaces
Interacting with Computers 15(3), 2003
FEATURES & CONTEXTS DEFINITIONS •
Context is everything but the explicit input and output to 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
•
A feature is an end-user-visible characteristic of a system. Kyo C. Kang, Sholom G. Cohen, et al.
Feature-Oriented Domain Analysis (FODA) – Feasibility Study
Technical Report CMU/SEI-90-TR-21, 1990
CONTEXT-AWARE SYSTEMS C HARACTERIS TICS •
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 •
•
Dynamic Variability •
•
what types of (dynamic) system adaptation do they require or support?
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?
TOWARDS A TAXONOMY DIMENSIONS
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
TOWARDS A TAXONOMY A PATTERN-BASED FORMAT •
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
TOWARDS A TAXONOMY EXAMPLE OF A PATTERN •
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
TOWARDS A TAXONOMY SUPPORTED VARIABILIT Y MEC HANISMS •
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.)
TOWARDS A TAXONOMY T YPES OF FEATURES •
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
TOWARDS A TAXONOMY DEPENDENCIES 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 contextoriented programming languages such as Subjective-C [Gonzalez et al. 2011]
model with a graphical representation of model the and the feature model represent the specific of each classifier. Some examples of dependencies between the manufacturer Context Model the Context: The infotainment creates andrequirement dependencies and their rationales Dependencies can also relate are to presented different below, context products for different Car manufacturers: CarA, CarB, Feature Model (for reasons of clarity only a subset of using a textual notation. classifiers: In the USA, CarA does not sell budget: and CarD, for different continents: USA, Asia EXAMPLE theCarC dependencies are shown). European Maps are part of the Navigation system and Europe, and has three product types: budget, midrange, 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 Context 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.
and in Europe DVDs with must be supported: Continent.USA AND region car 2type.CarA budget {Rationale: Continent.Europe Logistics} European Maps {Rationale: Obvious} Continent.Europe DVDOr become even more complex: In the Asian market, region 2 {Rationale: Standard} CarB only sells midrange without Memory-Card slot:
Type
Context
Continent
Europe
Car-Brand Budget
Mid
High
Features
CarA CarB CarC
Asia USA
model with a graphical representation of the The budget (small) configuration can Model only support a Connections dependencies between the Context and the USB interface Card Slot, not both, Feature Model or (fora reasons of clarity onlybecause a subsetthe of size of the front panel is too small. the dependencies are shown).
CarD
Type
Car-Brand
Europe
Maps
Continent
ASIA
Fig. 3.
Budget
USA
Mid
High-end
CarA
EU CarB
Manufacturer CarA AND may Continent.Asia not support a specific Car Type.CarB AND communication protocol: MemoryType. Mid-range Card. {Rationale: Commercial} Car-Brand.CarA FlexRay protocol Figure 4 shows a diagram of the MPL-Feature
….
CarC
CarD
USA
Protocol
Context Flexray ZigBee infotainment system
….
Type.Budget MP3 interface >> > [0..1] Context {Rationale: Technical; Too small size Interface of front} CardSlot
USB
BlueTooth
Type
Herman Hartmann, Tim Trew
Car-Brand Features Continent The dependencies between the context variability Using Feature diagrams with Context Variability
Budget Mid High model and model to represent theMultiple specific Fig.the 4. feature MPL-Feature Diagram of the Product Lines for Software Supply ChainsConnections model
Europe Asia USA requirement of each classifier. Some examples of CarA CarB CarC CarD infotainment system Software Product Line (SPLC), 2008
dependencies and their rationales are presented below,
Maps
CONCLUSIONS ABOUT THE TAXONOMY •
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
ABOUT THE WORKSHOP WHAT DO I WANT TO GET OUT OF THIS ? •
Feedback on taxonomy •
•
•
taxonomy dimensions + additional patterns
Collaboration opportunities •
A common case study
•
A joint book
•
Improved taxonomy
Feedback on our ongoing work
ABOUT THE WORKSHOP WHAT DO I WANT TO GET OUT OF THIS ? •
(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)
External environment User
Physical environment
Computing platform (hardware and software)
Interaction Output Device
Input Device
Actuators
Sensors
API
API
Discovery
Execution
Handling
Representation Feature Definition
Interpretation
Reasoning
Feature Selection & Composition
Context Activation
Context–Feature Mapping
Context Representation
API
