Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering

BREAKING DOWN THE WALLS A UNIFIED VISION ON

CONTEXT-ORIENTED SOFTWARE ENGINEERINGKim Mens, Nicolás Cardozo, Anthony Cleve & Bruno Dumas

Presented at BENEVOL 2015, 3-4 December 2015, Lille, France

https://www.researchgate.net/profile/Kim_Mens

“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

systeminput output

http://dl.acm.org/citation.cfm?id=1011431

“… 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

http://dl.acm.org/citation.cfm?id=1011431

“ 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

http://delivery.acm.org/10.1145/770000/764011/e_rohn_1.pdf?ip=80.200.228.14&id=764011&acc=OPEN&key=4D4702B0C3E38B35.4D4702B0C3E38B35.4D4702B0C3E38B35.6D218144511F3437&CFID=564923533&CFTOKEN=16120874&__acm__=1448916439_c25575c64c3fb8aef61ed62b9ad24e8f

FROM “CONTEXT-BLIND” SOFTWARE DEVELOPMENT

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

TO DEVELOPING SYSTEMS WITH “CONTEXT” IN MIND

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

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

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]

CONTEXT-AWARE SYSTEMS

Idea appeared ~ late 1980s; increasingly studied since ~ 2000.

3. The general characteristics of the articles

3.1. Classification of articles by publication year

The number of articles by publication year is depicted in Fig. 2.Numerous context-aware articles have grown considerably since2000. The number of articles in 2007 have becomes 7 times morethan the number of articles in 2000. The number of articles from2001 to 2004 had been increased continuously, and the numberof articles from 2004 to 2006 has been almost the same. It is abso-lute that the concern about context-aware systems was increasedand will be continued.

3.2. Classification of articles by online database

The article by online database is categorized in Table 2. Thereare a total of 181 articles from online databases. We use 7 onlinedatabases to search the articles. In Table 2, IEEE Xplore is the high-est percentage of articles (74 articles, 31%), because it offers arti-cles of many journals (IEEE Pervasive Computing, IEEE InternetComputing, IEEE Wireless Communications and IEEE Transactionson Software Engineering) which have subject relevant to context-aware systems. Science Direct stores journal articles of variousstudy fields, therefore this database is the second highest of articles(60 articles, 25.6%). Other online databases are Springer Link On-line Libraries (57 articles, 23.9%), Ingenta Journals (18 articles,8%), ACM Digital Library (16 articles, 7%), Wiley InterScience (9articles, 4%) and EBSCO (Electronic Journal Service) (3 articles,1%). When the same article is found repetitively among differentonline database, the article number of database having more num-ber of articles is increased.

3.3. Classification of articles by journal

The articles by journal articles are categorized in Table 3. Therewere 65 journals that published context-aware articles. Most of

them were related to the computer science, electronic engineeringand information management. Table 3 specifies journals that pub-lished four or more context-aware articles and the others that pub-lished only one article or no more than 3 related with context-aware systems are omitted. Pervasive computing and ubiquitouscomputing is closely connected with context-aware computing.Therefore, journals which focus on pervasive computing or ubiqui-tous computing have published articles relevant to context-awaresystems. As Table 3 shows, IEEE Pervasive Computing publishedthe most articles on context-aware systems (23 articles, 10%). Ex-pert Systems with Applications and Personal and Ubiquitous Com-puting published 10 articles (4%). Distribution of articles accordingto the journal shows that various journals have published articlesrelevant to context-aware systems.

4. Classification framework

4.1. Abstract architecture of context-aware systems

The abstract architecture of context-aware systems is drawnbased on the literature that explores the context-aware prototype,systems, and application to offer classification criteria for dividingthe literature appropriately. To make the abstract architecture, SO-CAM, ACAI, NAMA, PeCAN, X-CAF, CyberDesk, WebPADS, CAPIAs,Hycon service framework, Culliver’s Genie, Intelligent Agentframework, context-aware agent architecture, reference frame-work for multi-target user interfaces, etc. are reviewed in detail.As the results of literature review related with context-awarearchitecture, we present general abstract layer architecture of con-text-aware systems. As Fig. 3 shows, this architecture consists offour layers: (1) network layer involves a network supporting con-text-aware systems and sensor collecting low-level of contextinformation; (2) middleware layer manages processes and storescontext information; (3) based below layers, application layer pro-vides users with appropriate service; and (4) to offer suitable inter-

Fig. 2. Classification of articles by publication year.

Table 2Classification of articles by publication year.

Online database Number of articles

IEEE Xplore 74Science Direct 60Springer Link Online Libraries 57Ingenta Journals 18ACM Digital Library 16Wiley InterScience 9EBSCO (Electronic Journal Service) 3

Total 237

Table 3Classification of articles based on the journal.

Journal articles Number of articles

IEEE Pervasive Computing 23Personal and Ubiquitous Computing 10IEEE Internet Computing 6Wireless Personal Communications 5IEEE Intelligent Systems 5Mobile Networks and Applications 5IEEE Transactions on Software Engineering 4The Others 139Expert Systems with Applications 10Computer Communications 6Journal of Systems and Software 6Pervasive and Mobile Computing 5World Wide Web 5IEEE Wireless Communications 5Interacting with Computers 4

Total 237

Fig. 3. Abstract layer architecture of context-aware systems.

J.-y. Hong et al. / Expert Systems with Applications 36 (2009) 8509–8522 8511

Jong-yi Hong, Eui-ho Suh, Sung-Jin Kim Context-Aware Systems: A literature review and classification.

Expert Systems with Applications 36, 2009

https://www.researchgate.net/publication/220219749_Context-aware_systems_A_literature_review_and_classification

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 anddevelopment of dedicatedcontext-aware applications(e.g., a smart tour guide)

➤ user-interface technologyand usability studies

! Facilitating knowledge sharing and reuse in an open anddynamic distributed systems (Kwon, Choi, et al., 2005; Kwon,Yoo, et al., 2005; Gruber, 1993).

! Deriving fresh knowledge and facts based on reasoning contex-tual data and information by using inference engines.

! Allowing devices and agents not expressly designed to worktogether to interoperate, achieving ‘‘serendipitous interoperabil-ity” (Wang, Dong, Chin, Hettiarachchi, & Zhang, 2004).

Although some research only focuses on ontology, the numberis very few. Ontology is generally used for reasoning and express-ing context data. Therefore, they do not need to have a separatecategory for ontology.

5.2. Network layer

As shown in Table 6, we categorize the network infrastructurelayer into internet protocol, handoff management, sensing, net-work requirements and network implementation. Context-awarecomputing needs to dynamically adapt to changes in this contextand connect entities based on network. Therefore, many researchesare conducted to offer appropriate network for providing context-aware computing. Internet protocol category involves presentingmechanisms and design of session initiation protocol (SIP), mobileIPv6, an integral part of constructing self-configuring mobile adhoc networks and object discovery. Handoff management categoryhas article about the process of transferring an ongoing call or datasession from one channel connected to the core network to an-other. Article topic of handoff management category is treatingheterogeneous network for seamless communication environ-ments. The sensing category is responsible for capturing, abstract-ing and acquiring context information of the situations in theenvironment. When implementing context-aware systems, the ba-sic idea is to use the sensor data and predict the current situation.Therefore, the sensing category consists of sensing algorithm, sens-ing technology and wearable sensing mechanism. Networkrequirements category means collecting requirements for theadaptation method which can support seamless computing infra-structures, framework for integration for user services out to the

Table 8References of application and service layer.

Classification criteria References

Applications andservices

Smartspace

Home Baek, Lee, Lim, and Huh (2005), Intille (2002), Schulzrinne, Wu, Sidiroglou, and Berger (2003)Hospital Agarwal, Joshi, Finin, Yesha, and Ganous (2007), Bottazzi, Corradi, and Montanari (2006), Favela, Rodríguez, Preciado, and

González (2004), Favela et al. (2007), Kjeldskov and Skov (2007), Muñoz, Rodriguez, Favela, Martinez-Garcia, and González(2003), Rodríguez, Favela, Martínez, and Muñoz (2004)

Classroom

Sung et al. (2005)

Tour guide Bellotti, Berta, De Gloria, and Margarone (2005), Cano, Manzoni, and Toh (2006), Cheverst, Mitchell, Davies, and Smith (2000),Cheverst, Smith, Mitchell, Friday, and Davies (2001), O’Hare and O’Grady (2003), Pashtan, Heusser, and Scheuermann (2004)

Informationsystems

Celentano and Gaggi (2006), Kwon (2006a), Kwon, Yoo, et al. (2005), Kwon, Yoo, and Suh (2006), Norrie et al. (2007), Signer,Grossniklaus, and Norrie (2007), Wilson, Doyle, Weakliam, Bertolotto, and Lynch (2007)

Communicationsystems

Fogarty, Lai, and Christensen (2004), Goularte, Pimentel, and Moreira (2006), Raento, Oulasvirta, Petit, and Toivonen (2005),Ranganathan, Campbell, Ravi, and Mahajan (2002), Schmidt, Takaluoma, and Mantyjarvi (2000), Schilit, Hilbert, and Trevor(2002), Sumi and Mase (2000), Sumi and Nishida (2001), Udugama, Kuladinithi, Gorg, Pittmann, and Tionardi (2007), Yuan andChen (2007)

M-commerce Anagnostopoulos, Tsounis, and Hadjiefthymiades (2007), Becerra-Fernandez, Cousins, and Weber (2007), Bouvin, Christensen,Frank, and Hansen (2003), Broens, Halteren, Sinderen, and Wac (2007), Chakraborty et al. (2007), Genco, Sorce, Reina, andSantoro (2006), Kwon (2003), Kwon and Sadeh (2004), Kwon, Shin, and Kim (2006), Maiden, Omo, Seyff, Grunbacher, andMitteregger (2007), Mandato, Kovacs, Hohl, and Amir-Alikhani (2002), Riva and Toivonen (2007), Roussos, Marsh, and Maglavera(2005), Skov and Høegh (2006), Stylianos, Nikia, Kia, and Christos (2007), Syukur and Loke (2006),Wac, Halteren, Bults, andBroens (2007), Wohltorf, Cissée, and Rieger (2005), Yu et al. (2006)

Web service Blake, Kahan, and Nowlan (2007), Debaty, Goddi, and Vorbau (2005), Ceri, Daniel, Facca, and Matera (2007), Gandon and Sadeh(2004), Kanter (2003), Kwon (2006b), Kwon, Choi, et al. (2005), Kwon, Yoo, et al. (2005), Lee (2007), Pashtan, Kollipara, andPearce (2003)

Table 9References of user infrastructure layer.

Classification criteria References

User infrastructure Interface Alexander and Matthias (2006), Bell, Feiner, and Höllerer (2002), Calvary et al. (2003), Hatala and Wakkary(2005), Hong, Dickson, Chiu, Shen, and Kafeza (2007), Korhonen et al. (2007), Kurvinen, Lähteenmäki,Salovaara, and Lopez (2007), Lieberman and Chu (2007), Lum and Lau (2002), Mäntyjärvi and Seppänen(2003), Rehman, Stajano, and Coulouris (2007), Selker (2004), Smailagic and Siewiorek (2002)

Usability Barnard, Yi, Jacko, and Sears (2005), Burrell and Gay (2002), Kaasinen (2003)

Fig. 5. Distribution of articles number by year and classification framework.

J.-y. Hong et al. / Expert Systems with Applications 36 (2009) 8509–8522 8515

CONTEXT-ORIENTED PROGRAMMING

Focusses on the programming angle:

Enabling context-aware software adaptability

through a programming language engineering approach:

➤ dedicated programming languages to expresscontext-driven behaviour adaptation

➤ contexts and behavioural variations to contextas first class language citizens

SOME CONTEXT-ORIENTED PROGRAMMING LANGUAGES

Subjective-CAmbienceContext 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.

https://www.researchgate.net/publication/220349673_Context-Oriented_Programming_with_the_Ambient_Object_System

https://www.researchgate.net/publication/221055377_Subjective-C__Bringing_Context_to_Mobile_Platform_Programming

https://www.researchgate.net/publication/237202189_Context_Traits_Dynamic_Behaviour_Adaptation_through_Run-Time_Trait_Recomposition

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

https://www.researchgate.net/publication/261703622_Features_on_Demand

MOTIVATING EXAMPLE: AN ON-BOARD CAR SYSTEM

Context Traits

Pierre-Yves OrbanUsing Context-Oriented Programming for Building

Adaptive Feature-Oriented Software for Car On-Board Systems. Master thesis in Computer Science, Université catholique de Louvain, 2013


Context-specific features

location = EU

Display speed reading using the metric system units


Context changes trigger behavioural adaptation

location = UKlocation = EU


Context changes trigger behavioural adaptation

location = UKlocation = EU

Display speed reading using the imperial system units

Display speed reading using the metric system units


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

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

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.

http://www.ubicc.org/files/pdf/survey_231_231.pdf


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

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

Physicalenvironment

Computing platform(hardware and software)User

Context = + +

http://www.sciencedirect.com/science/article/pii/S0953543803000109


Storage Layer

Management Layer

Interpretation Layer

Physical ComputingUser

Adaptation Layer

Context

Sensor Layer External environment

Internal environment

Reasoning Layer

LAYERED ARCHITECTURE OF CONTEXT-AWARE SYSTEMSRELABELLED

Execution

Representation

Discovery

Physical ComputingUserContext

External environment

Internal environment

Handling

ReasoningInterpretation

Interaction Sensors

TOWARDS ARCHITECTURE OF CONTEXT-ORIENTED SYSTEMS

Representation

Handling

DiscoveryReasoningInterpretation

Physicalenvironment

Computing platform(hardware and software)

Execution

User

InteractionActuators


Internal environmentOutput Device SensorsInput Device API APIAPI

OUR CONTEXT-ORIENTED ARCHITECTURE

Representation

Handling

Discovery

Context–VariantsMapping



Context & Feature Representation

Execution

User




ContextActivationVariant Selection

Variant Declaration& Composition

Context Physicalenvironment

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 behaviouraccording to currently (in)active contexts & features

Handling ContextActivation

Feature and Variation Selection

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–VariantsMapping



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 featureis desired by the user

➤ Plus information on the activation status

➤ (in)active; (de)activation requested; being (de)activated


classifiers are not features. It may include sub-“features” (meaning sub-classifiers), cardinalities and dependencies between classifiers.

For cardinality or group cardinality the minimum value is always 0 (e.g., [0..x]). In other words, a context variation point cannot be mandatory. 3.2. Multiple-Product-Line-Feature Model

The Context Variability Model is combined with a conventional feature model to create a new model, which will be called the Multiple Product Line Feature Model, or for short, the MPL-Feature model.

The feature model is used in the classical way, and describes the commonality and variability for a product 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 VariabilityModel

Feature Model

<<1..2>>

MPL-Feature Model

Dependencies

Context VariabilityModel

Feature Model

<<1..2>>

MPL-Feature Model

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

purely “commercial” rationale can always be changed, but is valuable for a software supplier to record. In contrast, it may not be possible to change a dependency with “technical” rationale, if it were a property of the domain, or it might have a major impact on the product line architecture.

Because of the size of the Feature Model for realistic product lines and the complexity of the constraints, it is therefore necessary to create a model, rather than relying on static diagrams, supported by appropriate tooling. Consequently, we will represent dependencies in textual form, and display filtered graphical views. 3.3. Example

To illustrate our concept we will use a fictitious example. Imagine a manufacturer of car infotainment systems, a tier-1 supplier in the automotive industry.

Features: The software of the infotainment system consists of several optional features for information and entertainment purposes. For instance: a navigation system, a radio, MP3 player, DVD player, interface to external MP3 player dock, a USB connector and memory card slot, Bluetooth connections, etc. Several standards are support such as various DVD-regions, broadcasting and communication protocols (FlexRay, ZigBee and Bluetooth). Figure 2 shows a subset of the infotainment system, using the FODA notation.

Protocol

Flexray ZigBee Blue-Tooth

Interface

USBCard-Slot

Maps

Features

EU USA ….

Connections

…….<<1..n>>

Protocol

Flexray ZigBee Blue-Tooth

Interface

USBCard-Slot

Maps

Features

EU USA ….

Connections

…….<<1..n>>

Fig. 2. Feature Diagram infotainment system

CONTEXT & FEATURE REPRESENTATION

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


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


<<0..n>>

<<0..n>>

<<0..n>>

<<excludes>>

<<requires>>


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



Context

Continent

Type

Car-Brand

Budget Mid High-end


<<0..n>>

<<0..n>>

<<0..n>>

Context

Continent

Type

Car-Brand

Budget Mid High-end


<<0..n>>

<<0..n>>

<<0..n>>







Blue-

Tooth

Context

Continent

Type

Car-Brand

Budget Mid High


<<0..n>>

<<0..n>>

<<0..n>>

<<excludes>>

<<requires>>


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


<<0..n>>

<<0..n>>

<<0..n>>

<<excludes>>

<<requires>>


Protocol

Flexray ZigBee

Interface

USBCard-

Slot

Maps

Features

EU USA….

Connections

….<<1..n>>

<<0..2>>

<<excludes>>







Context

Continent

Type

Car-Brand

Budget Mid High-end


<<0..n>>

<<0..n>>

<<0..n>>

Context

Continent

Type

Car-Brand

Budget Mid High-end


<<0..n>>

<<0..n>>

<<0..n>>







Blue-

Tooth

Context

Continent

Type

Car-Brand

Budget Mid High


<<0..n>>

<<0..n>>

<<0..n>>

<<excludes>>

<<requires>>


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


<<0..n>>

<<0..n>>

<<0..n>>

<<excludes>>

<<requires>>


Protocol

Flexray ZigBee

Interface

USBCard-

Slot

Maps

Features

EU USA….

Connections

….<<1..n>>

<<0..2>>

<<excludes>>





http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4626836&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4626836

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


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

➤ 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


Variation

OUR CONTEXT-ORIENTED ARCHITECTURE

Representation

Handling

Discovery





Execution

User




ContextActivationVariant Selection


Context Physicalenvironment

context & feature diagramactive contexts & features

dependencies between contexts & features

Mapping of contexts and features to corresponding variants

Declaration of different variantsand how they are composed

“To be continued…

-Kim Mens

Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering

Software

Transcript of Breaking the Walls: A Unified Vision on Context-Oriented Software Engineering