handling variations in system families - a survey_3

8/3/2019 Handling Variations in System Families - A Survey_3

1/25

Handling variations in system families: A survey

1. Introduction

The Software Engineering Institute (SEI) defines Software Product Line (SPL), also known as System

Family, as a set of software-intensive systems sharing a common, managed set of features that satisfy

the specific needs of a particular market segment or mission and that are developed from a common set

of core assets in a prescribed way [1]. The motivation behind SPL practice is that organizations are

finding that the practice of building sets of related systems (system family) from common assets can

yield remarkable quantitative improvements in productivity, time to market, product quality, and

customer satisfaction [1]. Software product line engineering distinguishes two subprocesses: domain

engineering and application engineering. During the domain engineering subprocess, product line

commonality (i.e. features that are common to all products in the family) and variability (i.e. features

that vary among products in the family) are identified and core assets are developed to be reused in

application engineering subprocess to develop individual products in the family. As product line

concerns a family of products, domain artifacts (developed during domain engineering) such asrequirements, architectures and components must incorporate variability to deal with variation among

those products and to enable the development of those different products. Variability is the main

characteristic that distinguishes system families development from other approaches of software

development [2].

1.1 Running example: Coffee Machine Family

We take the Coffee Machine Family presented in [3] as a running example to illustrate different

concepts introduced throughout the paper. The requirements for this family are as follows:

1) A coffee machine is activated by a coin. The only accepted coins are the one euro coin (1

),exclusively for the European products and the one dollar coin (1$), exclusively for the US

products;

2) After inserting a coin, the user has to choose whether or not (s)he wants sugar, by pressing

one of two buttons, after which (s)he may select a beverage;

3) The choice of beverages (coffee, tea, cappuccino) varies between the products. However,

delivering coffee is a must for every product of the family, while cappuccino is only offered

by European products;

4) After delivering the appropriate beverage, optionally, a ringtone is rung. However, a ringtone

must be rung whenever a cappuccino is delivered;

5) The machine returns to its idle state when the cup is taken by the user.

1.2 Product line and variability related concepts

This section presents general concepts concerning product line and variability. Software Product Line

(SPL), domain engineering, application engineering, commonality and variability are already defined

in section 1, introduction. We would like to distinguish between variability in time and variability in

space. Variability in time is the existence of different versions of an artifact that are valid over time

while variability in space is an existence of an artifact in different shapes at the same time [4]. While


2/25

variability in time concerns single software development as well as SPL development, variability in

space concerns specifically SPL development. In the rest of this paper, we use the term variability to

refer to variability in space.

Halmans defines two categories of variability: essential and technical variability [5]. Essential

variability describes variability of the product family from the customer/user viewpoint, i.e. from a

system usage perspective while a variability is considered as technicalvariability when it deals withaspects about the realization/implementation of the variability and/or if it states consequences on the

IT-infrastructure. For the coffee machine example, the ability to choose between 1$ coin and 1 coin to

activate the machine is considered as essential variability and the ability to choose between different

database types to record purchase behavior of customers can be considered as technical variability.

Similar categorization is defined by Bckle [4] in which external (resp. internal) variability is used

instead of essential (resp. technical) variability.

Becker distinguishes two levels of variability: on the specification and the realization level [6].

Variability on the specification level concerns externally visible characteristics of variability, ignoring

the realization detail. Variability on the realization level is the variability that must be introduced in

product line assets or core assets to realize variability specified on the specification level. For example

one variability on the specification level for the coffee machine family can be: use of 1$ coin or 1 coin

to activate the machine. To realize this variability different variabilities must be introduced in product

line assets (e.g. introduce two alternative transitions in behavioral model: one labeled with event of

inserting 1$ coin and another labeled with event of inserting 1 coin). In [7], similar distinction of

variability level is introduced: Product Line (PL) variability which corresponds to variability on the

specification level andsoftware variability which corresponds to variability on the realization level.

The most common type of variabilities are optional variability (i.e. a property may or may not be

present in a product) and alternative variability (i.e. choose one among n variants). For the coffee

machine family example, the fact that the ringing of the ringtone is an optional represents optionalvariability while the use of 1$ coin or 1 coin to activate the machine represent an alternative

variability.

Software product line development starts with the high level description of the product line to be

developed. In [4], this high level description is also called product roadmap which determines the

major common and variable features of the future products as well as schedule with their planned

release date. We refer to this high level description of product line as high level product line

description. Variability on the specification level is actually the variability concerning high level

product line description. From that high level description, core assets (requirements, architecture,

design, code...) are created. Core assets are product line assets that can be reused to develop individualproducts. Variability in core assets is variability on the realization level. Instances of high level product

line description are called high level products description which can be derived from high level

product line description. High level products description is used to select and configure core assets to

develop individual products.

Variability concerning high level product line description is usually captured in feature model or

dedicated variability model which is detailed in the next section.


3/25

Variability, introduced in core assets to realize variability on the specification level, is modeled using

variation point. A variation point is a spot in software asset where variation will occur [8]. A set of

variants can be associated with a variation point to provide different options for the corresponding

variability. Variation point acts as placeholder to be replaced by a number of variants chosen from the

set of variants associated with the variation point when developing a particular product. In the coffee

machine family, an example of a variation point can be coin type with two associated variants 1$

coin and 1 coin. When developing a particular product, coin type variation point can be replacedwith 1$ coin variant or 1 coin variant depending on whether it is the US product or the European

product.

In the life cycle stages before the design of the variation point, the variation point is considered to be

implicit. At or after the stage at which the variation point is designed, the variation point is explicit. An

explicit variation point can be boundto a number of variants chosen from the provided set of variants.

For example, coin type variation point is bound to 1 coin variant for the European product. For

each variation point, the set of variants may be open, i.e. more variants can be added (e.g. 1 coin

variant can be added to coin type variation point), or closed, i.e. no more variants can be added (e.g.

no more coin type such as 1 coin variant can be added to coin type variation point) [9]. Timewhen we bind a variability to a particular variant is called binding time. Typical binding times are

design time, compile time, link time and runtime.

When developing individual products (also called product derivation or product configuration), the

variability have to be resolved. Resolving a variability is to make decision concerning that variability

(e.g. whether or not to include an optional variant, choose one feature among many variants to be

included). Choosing a particular variant for a variability is also referred to as binding the variability to

that variant. Some variants may not be independent from others (e.g. when one variant is chosen

another variant must also be chosen to make a valid product). Constraints between those variants can

be defined to represent those dependencies. The most common constraints are require (i.e. the selection

of one variant requires the selection of another variant) and exclude (i.e. if one variant is selected

another variant must not be selected and vice versa). An example of a require constraint is the fact that

the coffee machine that can provide cappuccino must have the capability to ring a ringtone (cappuccino

requires ringtone). An example of exclude constraint is the fact that the US coffee machine can not

provide cappuccino (US coffee machine excludes cappuccino).

The first step in developing individual products is to derive high level products description from high

level product line description by deciding for each variability which variant to choose. So this concerns

essentially the decision-making process. For that reason, the model (e.g. feature model) used to

represent variability concerning high level product line description is also called decision model.

Instances of decision model are calledproduct models. Product model is used to resolved variability incore assets.

1.3 Outline

In this paper, we survey approaches used to handle variations in system families in the context of

requirements engineering. The rest of the paper is organized as follows. Section 2 shows how variability

on the specification level can be modeled. In section 3, we present different methods used to describe


4/25

variability in requirements artifacts (variability on the realization level). Section 4 describes how

variability on the specification and variability on the realization (in requirements artifacts) are

interrelated. Deriving product artifacts from product line artifacts is described in section 5. Section 6

presents analyses that can be performed on the described variability models. Elaboration techniques for

different variability models are presented in section 7. Finally, section 8 concludes the paper.

2. Variability on the specification level

In this section we present different approaches used to model variability on the specification level.

2.1 Feature model

Feature model:

Feature model is used to capture common and variable features in a system. Feature diagram (FD)

which is a graphical representation of feature model was first introduced by Kang as part of FODA

(Feature-Oriented Domain Analysis) method in which feature is defined as a prominent or distinctive

user-visible aspect, quality or characteristic of a software system or systems [10]. After the introduction

of FODA FD, various extensions of it were introduced to compensate for a purported ambiguity and

lack of precision and expressiveness [11].

Figure 1 shows FODA feature digram of the coffee machine. It is a tree-like structure that captures

various features of the coffee machine and relationships between them. Nodes represent features. Root

node represents concept being described. Features at higher level (parent features) is related to features

at lower level (child features) by consists of relationships which is represented by edges. Optional and

alternative features are represented by hollow circle and small arc respectively. For example in fig. 1,

the 1$ and 1 are alternative features and the Ringtone is optional feature. Features which are not

optional or alternative are mandatory features. Mandatory feature must be selected if its parent isselected. Optional feature can be selected if its parent is selected. Exactly one of the alternative features

belonging to the same parent must be selected if that parent is selected. Composition rules can be used

to express additional constraints between features. There are two types of such constraints: requires

and mutually exclusive with or excludes. FeatureA requires featureB means that if feature A is

selected then featureB must also be selected. mutually exclusive with constraint between two features

means that if one feature is selected the other feature must not be selected. For example in fig. 1,

Cappuccino requires Ringtone and 1$ excludes Ringtone.

Extensions to FODA feature model include representing feature diagram using directed acyclic graph

(DAG) instead of tree [12,13,14,15,16], the ability to choose one or more features from a group of

features instead of choosing only one feature [8,13,14,17,18,19,20,21,22,23], feature cardinalities also

called feature cloning (i.e. multiple copies of a same feature may exist in a product) [18,19,20,22,23],

feature group cardinalities (the ability to choose at least min and at most max features from a group of

features) [14,19,20,22,23], the ability to use logical formulas or OCL (Object Constraint Language) to

express additional constraints between features [20], using textual language instead of diagrammatic

language [17,23].


5/25

Figure 1. Feature diagram FODA: Coffee Machine

Use of feature model to model variability on the specification level:

Many approaches [10,12,14,15,16,17,19,24,25,26] use feature model to model variability on the

specification level. With this approach, high level description of the product line is described in term offeatures available for the products in the family. Variability is captured in term of variable features (i.e.

optional and alternative features). For the coffee machine family, feature diagram in fig. 1 models the

following variabilities: alternative choice of coin type between 1$ and 1 (the machine can be

activated using 1$ coin or 1 coin), optional beverage types Tea and Cappuccino (the machine can

optionally serve tea and cappuccino) and optional ringtone Ringtone (the machine may or may not

ring the ringtone). It also captures constraints between features, that is Cappuccino requires

Ringtone (the machine that serves cappuccino must have a ringtone) and 1$ excludes

Cappuccino (cappuccino is only offered by European product which uses 1 coin type).

2.2 Orthogonal variability model (OVM)

Orthogonal variability model:

Orthogonal Variability Model (OVM) is used to document variability in separate model, meaning that

variability is not directly incorporated in base models. In SPL engineering context, models forming

core assets such as requirements models, architecture models or test models are called base models. In

[27], they use OVM models to document PL variability (variability on the specification level) and relate

those OVM models to base models.

In OVM [27], variability is modeled using variation points and variants. A variation point (VP)

represents a variable item. Variants (V) documents possible instances of a VP and thus are related toVP. Fig. 2 shows graphical notation for OVM and fig. 3 shows OVM model documenting variability on

the specification level of the coffee machine. VP is represented by triangle (e.g. Coin in fig. 3) and

variant is represented by rectangle (e.g. 1$ in fig. 3). Variants linked to VP through dashed lines

(resp. solid lines) are optional variants (resp. mandatory variants). In fig. 3, Tea is an optional variant

while Coffee is a mandatory variant for Beverage variation point. Mandatory variant must be

selected if its VP is selected. Optional variant can but does not have to be selected if its VP is selected.

Alternative choice can be used to group optional variants and cardinality in the form of [ min..max] can

be specify for the group to indicate that at least min and at most max variants must be selected from the


6/25

group if their VP is selected. The default range, [1..1], is omitted in the diagram. For example, variants

1$ and 1 form an alternative choice with cardinality [1..1] which is omitted in fig. 3. Constraints

between variation points, between variants, and between variant and variation can be modeled using

various constraint dependencies: requires_V_V (a variant requires another variant), requires_V_VP (a

variant requires a variation point), requires_VP_VP (a variation point requires another variation point),

excludes_V_V (a variant excludes another variant), excludes_V_VP (a variant excludes a variation

point) and excludes_VP_VP (a variation point excludes another variation point). As examples, fig. 3shows requires_V_V constraint between variant Cappuccino and variant Ringtone which means

that if Cappuccino is selected Ringtone must also be selected, and excludes_V_V constraint

between variant 1$ and variant Cappuccino which means that if variant 1$ is selected

Cappuccino must not be selected and vice versa. Artifact dependency (resp. VP artifact dependency)

is used to relate variant (resp. VP) to elements in base models. For example, there can be artifact

dependency link from variant 1$ to transition labeled with event of inserting 1$ coin in behavior

model.

Figure 2. Graphical notation for variability model [27]

Figure 3. OVM model of the coffee machine

Use of Orthogonal Variability Model to model variability on the specification level:

Variability concerning high level product line description can be documented using OVM. Unlike

feature model which contains both variable features and common features, OVM model contains only

variability information. In this approach, variability is described in term of variable item (which is

modeled using variation point) and instances of variable item (which are modeled using variants). For

example, in fig. 3, the variability in coffee machine is modeled using three variation points: Coin,


7/25

Beverage and Notification. The fact that only one coin type (1$ or 1) can be selected is modeled using

alternative choice with default range ([1..1]). The optional beverages (tea and cappuccino) served by the

coffee machine are modeled using optional variants. Optional variant Ringtone model the fact that

the machine may or may not have ringtone. Finally, the fact that ringtone must be rung after serving

cappuccino which means that the machine must have ringtone is modeled using requires_V_V link

from Cappuccino to Ringtone and the fact that cappuccino is offered only by European products

which means that cappuccino is not offered by US products (use 1$ coin) is modeled usingexcludes_V_V between 1$ and Cappuccino.

2.3 Goal model

Goal model:

Goal model captures how the system's functional and non-functional goals contribute to each other

through refinement links down to software requirements and environment assumptions where goal is

defined as a prescriptive statement of intent that the system should satisfy through the cooperation of its

agents [28]. It is graphically represented by an AND/OR graph called a goal diagram. Fig. 4 shows

example of portion of a goal diagram for the coffee machine. The top goals are the highest level ones

still in the system scope while the bottom goals represent software requirements or domain

assumptions. A goal may be AND-refined into multiple subgoals denoted by arrow joining subgoals to

the parent goal. The meaning of AND-refinement is that a parent goal can be satisfied by satisfying all

its subgoals. For example, the goal BeverageServed (to serve beverage) in fig. 4 can be satisfied by

satisfying goals CoinInserted (to insert coin), BeverageChosen (to choose beverage) and also other

goals that are not mentioned like BeverageDelivered (to deliver beverage) and BeverageTaken (to

take beverage). A goal can be OR-refined into multiple AND-refinements denoted by multiple

incoming arrows. Each of these AND-refinements is called an alternative for achieving the parent goal.

The meaning of OR-refinement is that the parent goal can be satisfied by satisfying the conjoined

subgoals in any of the alternative refinements [29]. As example, in fig. 4, the goal CoinInserted (to

insert coin) can be satisfied by either 1$CoinInserted (to insert 1$ coin) or 1CoinInserted (toinsert 1 coin).

Figure 4. Portion of goal graph for the coffee machine

Use of Goal Model to Model Variability on the Specification Level:

In this approach, high level product line description is captured in term of goal. Variability is modeled

using OR-refinement that capture different ways to satisfy a goal. For the coffee machine example,

variability concerning the coin type is captured by OR-refining the goal CoinInserted into two

subgoals 1$CoinInserted and 1CoinInserted. Similarly, the variability concerning beverage type

may be captured by OR-refining the goal BeverageChosen into multiple subgoals each representing

goal to choose beverage from a set beverages (i.e. {Coffee}, {Coffee, Tea}, {Coffee, Cappuccino},


8/25

{Coffee, Tea, Cappuccino}) that can be served by the machine. Constraints can be expressed directly

using goals. Constraint stating that cappuccino is only offered by European products may be

represented with the goal g1: CappuccinoOnlyForEuropean. With that goal, choosing g2:

1$CoinInserted and g3: BeverageChosenFromCoffeeCappuccino (choose one beverage from the

set {Coffee, Cappuccino}) together can be prevented because that choice causes conflicts among the

three goals g1, g2 and g3. The three goals are in conflict because g2 is satisfied by US products, g3 can

be satisfied by choosing cappuccino which means that US products can serve cappuccino, causingconflict with g1. Another constraint stating that ringtone must be rung if cappuccino is served may be

expressed using goal g4: RingtoneRungIfCappuccinoServed. There are two alternative ways to satisfy

that goal: cappuccino is not served denoted by g5: CappuccinoNotServed or ringtone is rung denoted

by g6: RingtoneRung. So if, for example, the goal g3 is chosen (g3 can be satisfied by choosing

cappuccino), alternative choice g5 can not be chosen for g4 as g5 is in conflict with g3.

2.4 Decision model

Decision model:

Decision model consists of a set of decisions along with possible options for each decision. Models

presented above like feature model, OVM model and goal model may also be considered as decision

model because each of those model contains decisions to make but those decisions are implicit. In this

section, we consider decision model in which decisions are explicit. In [30], decision model consists of

a set of decision variables. A decision variable corresponds to a variability. Table 1 shows decision

model of the coffee machine. Each row contains a decision variable. A decision variable has a unique

name that serves as its identity, a description describing the variability represented by this variable, a

range that give possible values for that variable, a constraint specifying constraint concerning that

variable and binding times showing possible stages at which to take decision about this variable. For

example, consider the decision variable Ringtone. Its description specify the variability on whether

the machine has ringtone or not which is specified by the range (TRUE, FALSE). Constraintconcerning this variable is that if the machine can serve Cappuccino (Cappuccino in Beverage), it has

to have ringtone (Ringtone=TRUE). The value must be assigned to this variable at or before design

time. There is another column Relevance (not shown in table 1) in which we can put condition

concerning the relevance of the variable. If the condition evaluates to false, the variable is not relevant

and thus does not need to be considered. For instance, the variable MEMORY_SIZE (decision variable

concerning the size of the memory) is relevant only if HAS_MEMORY = True (decision variable

concerning whether to include memory or not).

Use of decision model to model variability on the specification level:

With this approach, variability is modeled in term of decision variable with range representing possible

instances of the variability. For example, variability in the coffee machine (table 1) is modeling using

three decision variables: Coin (variability concerning coin type), Beverage (variability concerning

beverage type) and Ringtone (variability concerning ringtone). The range of each decision variable

provides possible options for the corresponding variability. Constraints can be expressed in constraint

column.


9/25

Name Description Range Constraint Binding

Times

Coin Type of coin used to activate

the machine (1$ for US product

and 1 for European product)

1$,

1

Cappuccino in

Beverage =>

Coin = 1

Compile

Time

Beverage Set of beverages served by themachine

{Coffee},{Coffee, Tea},

{Coffee, Cappuccino},

{Coffee, Tea, Cappuccino}

Coin = 1$ =>Cappuccino not

in Beverage

Installation

Ringtone Does the machine have

ringtone?

TRUE,

FALSE

Cappuccino in

Beverage =>Ringtone = TRUE

Design

Time

Table 1. Decision model of coffee machine

2.5 Commonality and variability analysis

Commonality and variability analysis (CVA) [31] is used to document requirements common to all

products in the product line (i.e. the commonality) and requirements specific to only some products (i.e.

variability or variation). The CVA document has three parts: commonality, variation and dependency.

With this approach, product line description is described using textual requirements which are split into

three parts corresponding to the three parts of the CVA document. Variability is provided in variations

section. Table 2 shows excepts from coffee machine family commonality and variability analysis.

Commonalities

C1. The machine shall be able to serve coffee.C2. The user shall be able to choose whether she wants the sugar or not.

C3. The machine shall display done message after delivering the beverage.

Variations

V1. Coin used to activate the machine may be 1$ coin or 1 coin. [1$, 1]

V2. The machine may include ringtone. [TRUE, FALSE]

V3. The machine may serve tea. [TRUE, FALSE]

V4. The machine may serve cappuccino. [TRUE, FALSE]

Dependencies

D1. The machine that is able to serve tea must include ringtone.

D2. Only European product (use 1 coin) can serve cappuccino.

Table 2. Excepts from coffee machine family commonality and variability analysis

3. Variability on the realization level

This section describes how variability on the realization level for various requirements models can be


10/25

expressed. Requirements are documented using natural language text (textual requirements

documentation) or a requirements modeling language such as data models, behavioral models or

functional models [32].

3.1 Textual requirements documentation

Variability can be expressed directly in natural language. Due to the ambiguous nature of naturallanguage, it is not suitable to express variability using natural language alone. For example from this

requirement the coffee machine can be activated by 1$ coin or 1 coin, it is not clear whether the or

is inclusive or or exclusive or. Pohl proposes to either document variability of textual requirements

in a separate model using OVM or document variability using XML [32]. Fig. 5 shows example of

documenting variability of textual requirements of the coffee machine family using OVM. There is one

variation point Coin with two variants: 1$ and 1. Each variant points to the corresponding text

fragments.

Figure 5. Orthogonal variability model in textual requirements

The variability in textual requirements in fig. 5 can also be documented by enriching textual document

with XML tags as shown below:

The coffee machine shall be activated with

1$ coin

1coin

3.2. Requirements model

This section presents methods to document variability in requirements model. First, methods that can

be applied to all requirements models are presented. After that, methods to model variability only in

specific requirements model are presented in each sub section.

Bachmann and Pohl propose to use OVM to document variability in all requirements models [33], [32].

Similar to what is shown in fig. 5, variability is modeled using OVM models. Requirements are

modeled using classic models like structural, functional or behavioral models. Those OVM models, that


11/25

model variability, are related to requirements models to highlight variability in requirements model.

In [14], stereotype is used to mark UML model elements as variable elements, and tagged

value with the key feature ({ feature = feature_name}) to relate model element to feature in feature

model. An element is present in the model of a particular product if the corresponding feature (tagged

value in that element) is selected for the product. Fig. 6 show portion of structural model of the coffee

machine in UML class diagram using stereotype to mark variable elements. In this figure,variable classes 1$Coin, 1Coin and Ringtone are marked with stereotype and are

tagged with the corresponding features taken from feature diagram presented in fig. 1. So for instance,

if the feature 1$ is chosen for a particular product, the class 1$Coin is included in the model of that

product.

Figure 6. Portion of structural model of the coffee machine using

Czarnecki annotates model elements with presence condition expressed in term of features to model

variable elements [34,35]. As shown in fig. 7, each presence condition is associated with different color

accompanied by a unique number in case the model is viewed in the environment that does not support

viewing color. Those presence conditions are expressed in term of features in feature diagram of fig. 1.

Common elements are represented by black color (with condition True) without number annotatingthem. As an example of a variable element, in fig. 7, the presence condition 1$ (this condition

evaluates to True iff the feature 1$ is selected) is associated with blue color and the number 1. The

class 1$Coin is shown in blue color with number 1 annotating it and thus corresponds to that

presence condition.

Figure 7. Portion of structural model of the coffee machine using presence condition

Becker uses XML to describe variability in core assets [36]. As an example, the variability concerning

the coin type in coffee machine can be represented as shown below (vsl stands for variability


12/25

specification language):

Schmid uses variation point to represent variability in requirements models in which variation point is

expressed in term of decision variables [30]. As an example, the portion of the textual requirements of

the coffee machine concerning coin type variability is shown below:

The machine shall be activated using

In this example, the variation point is expressed using decision variable Coin in decision model

presented in table 1. If the Coin variable takes value 1$ this variation point will be replaced with1$ coin, otherwise it will be replaced with 1 coin.

In the following subsections, we present approaches to document variability in specific requirements

model.

3.2.1 Structural model

Structural model can be represented using UML class diagram. Variability can be expressed in UML

class diagram using cardinality in relationship (e.g. [0..1] can be used to model optionality) and built-in

specialization relationship (to represent alternative option). Variability expressed in this way is notexplicit. We can't distinguish between normal use of cardinality and use of cardinality to represent

variability. The same is true for specialization relationship.

Clauss uses , and stereotypes to represent variability in

class diagram [37]. Class representing variation point is marked with while class

representing variant is marked with . class is linked to

class through specialization relationship. Optional class is marked with . In this approach,

tagged values are also used to provide additional variability related information like multiplicities,

binding times and conditions on whether or not to choose a particular variant. Similar to this approach,

in [38] is used instead of . For example, the class Coin in fig. 8 is

marked with to represent a variation point in class diagram. Binding time andmultiplicity are also specified for this variation point. Multiplicity=1 means that only one variant can be

chosen for this variation point from the set of variants containing 1$Coin and 1Coin marked with

. Similarly, optional variability Ringtone is marked with .


13/25

Figure 8. Portion of structural model of the coffee machine using

3.2.2 Use case model

In [39], stereotype is used to mark variable use case and variable actor in use case diagram

while variable text fragments in use case scenario are marked with explicit XML-like tags

and . Whether a use case is optional or alternative and how to select a variable use case is

captured in the decision model. For the coffee machine example, use case Insert 1 coin might bemarked with stereotype to indicate that it is variable use case, and the text fragment Insert

1 coin into the machine in use case scenario might be enclosed with and . The

decision model for coffee machine might say that if 1$ coin is chosen for the coin type, then remove

use case Insert 1 coin and remove text fragment Insert 1 coin into the machine in use case

scenario.

Bertolino inserts tags into use case scenario to identify and specify the variations [40]. Tags act as

placeholders. Different options that can be used to replace the tags are supplied directly in use case. As

example, in the coffee machine, there might be a tag to specify which coin type to insert into the

machine (e.g. insert {[V0] coin} into the machine) in the use case scenario for Buy beverage. The

two alternative options to choose for the tag {[V0] coin} might also be specified in the scenario (e.g.V0: alternative; option 1: 1$ coin; option 2: 1 coin meaning that we can choose 1 of the 2 options to

replace the tag {[V0] coin}).

Halmans introduces additional graphical notation triangle in use case diagram to explicitly represent

variation point [5]. Black triangle represents mandatory variation point while gray triangle represents

optional variation point. Variation point is associated with one or more use cases using the

relationship. Variant use case is marked with . A variation point can be

associated with a set of variants. Cardinalities [min..max] is used to indicate that at least min and at

most max variants have to be selected for the variation point. For the coffee machine example, the

variability concerning coin type in use case Insert Coin can be represented in scenario of the use caseor in the use case itself as shown in fig. 9. The variation point Coin Type is associated with two

variant use cases Insert 1$ Coin and Insert 1 Coin which are marked with . The

cardinality 1..1 indicates that one of the two variants must be chosen. Note that, in the fig. 9, the

variability in use case Choose Beverage is not shown in the use case itself and thus is supposed to be

modeled in the scenario.


14/25

Figure 9. Use case diagram of the coffee machine including variation points and variants

In [21], the step identifier in use case scenario is extended to express variability. A step identified with a

number is mandatory step as in classic scenario. Several steps identified by the same number

correspond to a number of mutually exclusive alternatives for one mandatory step. Several steps

identified with the same number and a consecutive letter identify a number of alternatives for one

mandatory step in the scenario out of which at least one must be selected. A step identified by a numberwithin parenthesis identifies an optional step in the scenario. Several steps identified with the same

number within parenthesis and a consecutive letter identify a number of alternative for one optional

step in the scenario out of which at least one must be selected. Several steps identified with the same

number within parenthesis identify a number of mutually exclusive alternatives for one optional step in

the scenario. Those variable steps are related to features in the feature model. Table 3 shows how to

represent variability in scenario of use case Buy Beverage of the coffee machine using this approach.

Step Action

1 User inserts 1$ coin into the machine

1 User inserts 1 coin into the machine

2 User chooses whether or not she wants the sugar by pressing one of

the two buttons

3 User chooses beverage from the set {Coffee}

3 User chooses beverage from the set {Coffee, Tea}

3 User chooses beverage from the set {Coffee, Cappuccino}

3 User chooses beverage from the set {Coffee, Tea, Cappuccino}

4 The machine delivers the beverage

5 The machine displays done message

(6) The machine ring a ringtone

7 User takes the beverage

Table 3. Scenario of use case Buy Beverage of the coffee machine

Mutually alternative

steps

Mandatory step

Optional step


15/25

3.2.3 Behavioral model

Kang uses feature as condition on transition of statechart diagram to model variability in statechart

diagram [10]. For the coffee machine example, the condition 1$ (which evaluates to True iff the

feature 1$ from feature diagram in fig. 1 is chosen) might be added to the transition fired when the

event of inserting 1$ coin occurs.

Extension to UML sequence diagram is proposed in [38] to represent variability in sequence diagram.

For that extension, stereotype is used mark optionality for object and

stereotype is used to mark optional interactions. Alternative interaction (i.e.

only one interaction can be present is a given product) can be modeled using and

stereotypes. An interaction encloses a set of sub-interaction. Each alternative variant is

marked with stereotype. A set of alternative interactions forming alternative option is

enclosed in an interaction marked with stereotype. stereotype is used to

defined virtual part in sequence diagram that can be replace by another sequence diagram for each

product. Fig. 10 shows portion of sequence diagram Buy Beverage of the coffee machine. Interaction

sd Coin marked with represents a variation point with two variant interaction sd 1$

and sd 1 marked with and tagged value showing the variation point they are associated

with. :Ringtone is an optional object and thus is marked with while Ring

Ringtone is marked with to represent optional interaction.

Figure 10. Portion of sequence diagram Buy Beverage of the coffee machine


16/25

Labeled Transition System (LTS) is one of the most popular formal methods for modeling and

reasoning about system behavior for single systems development. Modal Transition Systems (MTSs)

have been proposed to model a family of such LTSs [41]. There are two types of transitions in MTS:

mustand may transitions.Musttransitions must be present in every LTSs derived from the MTS while

may transitions can but don't have to be present in LTSs derived from MTS. Variability in MTS is

modeled using may transitions. Fig. 11 shows behavioral model of the coffee machine using MTS.

may transition is represented by dashed line while must transition is represented by solid line. Asexample, transitions labeled with 1$ and 1 are may transitions because they may or may not be

present in some products. Similarly, transitions labeled with tea and cappuccino are may

transitions. In contrast, transition labeled with coffee is must transition because it must be present

in every product.

Figure 11. Behavioral model of the coffee machine using MTS [3]

Larsen describes the use of Modal I/O Automata to model behavior of a product line [42]. Like MTS,

Modal I/O Automata has two types of transitions: mustand may transitions in which may transitions are

used to model variability in behavior. Fantechi proposes Extended Modal Transition System (EMTS),

an extension of MTS to add the capability to model the fact that at least one of n transitions and at most

one ofn transitions must be present in any product of the family [43]. Shortly after EMTS, Generalized

Modal Transition System (GEMTS) is proposed by the same author to express at least kofn transitions

and at most k of n transitions must be present in any product of the family [44]. Asirelli shows howdeontic logic can express variability of a family by showing the capability of a deontic logic formula to

finitely characterize a finite state Modal Transition System [45]. Deontic logic is able to express both

the evolution in time of a system by means of an action (e.g. from state 0 to state 1 in fig. 11), and the

fact that certain actions are obligatory or not in a given state (e.g. in fig. 11 the action 1$ is not

obligatory while the action pour_coffee is) and thus can characterize a MTS. Moreover, properties

such as it is permitted to get a coffee with 1 and it is possible to ask for sugar can be expressed

using deontic operators. Hence, those properties can be checked against deontic formula characterizing

a MTS by using axiom system of deontic logic.


17/25

Featured Transition System is proposed in [46] to model behavioral variability in a family. In this

approach, variability is modeled by labeling each transition with a feature in feature model and defining

priority relation over the labeled transitions. Transitions labeled with features at higher hierarchy

(ancestor features) have less priority than transitions labeled with features at lower hierarchy

(descendant features) in feature diagram. Priority relation between two transitions is not defined if one

transition labeled with one feature (f1) and another transition labeled with another feature (f2), and f1 isnot descendant or ancestor of of f2. The behavior of one particular product is obtained by removing all

transitions associated with features not included in that product and for a set of transitions coming from

the same state, keeping only transition with the highest priority. The idea is that because ancestor

feature represents more generalized feature and descendant feature represents more specialized feature,

transition labeled with more specialized feature (higher priority) overrides transition labeled with more

generalized feature (lower priority).

4. Traceability link between variability on the specification and on the realization level

Feature model:

Variability on the specification level is expressed using feature model. Links from features to

requirements artifacts can be explicit or implicit. In the former case, there are explicit links between

features and requirements artifacts [13,21]. In the later case, the links between features and

requirements artifacts are described implicitly by associating condition expressed in term of features

with requirements artifacts [14,34,37]. Artifacts with condition that evaluates to false with regard to

features selected for a particular product are not considered for the development of that product.

Orthogonal Variability Model:

With this approach, variability on the specification level is documented in OVM model and explicit

links from that OVM model to base models are used to highlight variability in base models (variabilityon the realization level) and thus can serve as traceability link between variability on the specification

level and on the realization level [27].

Goal model:

Variability on the specification level is modeled in goal model. Various links between goal and other

models (requirements models) can be used to trace variability between goal and other models:

Obstruction link is used to trace goal to obstruction, Concern link is used to trace goal to object,

Responsibility link is used to trace goal to agent, Operationalization link is used to trace goal to

operation and Coverage link is used to trace goal to behavior [28].

Decision model:

For this approach, variability on the specification level is modeled in decision model. Traceability links

between decision model and requirements models are described implicitly by expressing variation

points in requirements models in term of decisions in decision model (see section 4.2, the part

concerning use of variation point to model variability in requirements model) [30].


18/25

5. Deriving individual products

Deriving individual products in done in application engineering subprocess. First, high level product

description is derived from high level product line description. After that high level product description

is used to selected and configure various artifacts to be used to develop individual products.

5.1 Deriving product description

Feature model:

In this case, the product is described in term of features. Product derivation is also referred to as

product configuration. Classic derivation of product description consists of navigating through feature

graph and select the desired features by respecting feature dependencies and constraints. In [19],

product description can be derived in several stages. Each stage produces a more specialized feature

diagram from the previous stage by making decision for some variabilities. Eventually all variabilities

are resolved after the last stage where product description can be obtained. The same author has later

proposed to split feature diagram into related chunks called levels [47]. The number of stages and levels

are equal. For n levels, at stagej ( j < n), feature diagram at level j is configured manually followed by

automatic specialization of feature diagram at level j+1 based on choices made at level j. At the last

stage, stage n, feature diagram at level n is manually configured to obtain feature diagram representing

the product description. This configuration process is done sequentially i.e. stage j+1 is done after stage

j. To allow more sophisticated process instead of sequential one, Hubaux suggests to use YAWL (Yet

Another Workflow Language), a workflow language, to represent the configuration workflow of feature

diagrams at different levels [48].

Yu proposes to configure feature diagram taking into account stakeholders' goals [49]. To this end,

hard-goal is converted into feature. That feature is labeled with soft-goals to which the corresponding

hard-goal contribute positively or negatively. The stakeholders can then used soft-goals information to

decide which features to select.

Orthogonal Variability Model:

With OVM, high level product description can be obtained by choosing a number of variants from a

given set of variants for each variation point while respecting constraints and dependencies in that

OVM model. To help in the derivation process, use case scenario is used along with OVM to derive

product description taking into account stakeholders' requirements [50]. Variants in OVM that are of

interest to stakeholders are discussed in detail by employing the associated scenarios. From scenarios,

additional variants can be identified in OVM by using association between scenarios and variants. This

process continues recursively until all variabilities are resolved.

Goal model:

For this approach, product is described in term of goals. To derive the product description, we need to

navigate through goal graph and make choice between different alternatives which satisfy the same

goal. Lamsweerde describes how to choose variant that contributes best to a particular soft-goal using

qualitative and quantitative approaches for single system [28]. To support software product line, he

proposes to label each variant with a list of products to which the variant belongs. With those labels,

deriving goal model for a particular product P consists of traversing goal model representing product

family top down and breadth first. At each variation point, the upwards commonalities and the


19/25

successor variant whose label includes P are kept and all other successors are discarded.

Decision model:

For this approach, product description is derived by answering question concerning each decision in the

decision model while taking into account dependencies between decisions.

5.2 Selecting and configuring product line artifacts

From product description, product line artifacts can be selected and configured using traceability links

between variability on the specification and on the realization level as discussed in section 5. For

explicit traceability links, we take all artifacts related to elements in product description by traceability

links. In the case of implicit links, artifacts with the associated condition that evaluates to false with

regard to the product description are discarded. Some elements in product description may be used as

parameters to configure some artifacts.

6. Analyses

Mannion proposes to convert requirements variability and dependencies into propositional formula (for

example, requirement R1 requires requirement R2 is converted to R1 => R2, requirement R1 is

mutually exclusive with requirement R2 is converted to R1 R2) and to use propositional calculus

to analyze properties of the product line such as 1) does there exist any single system that satisfies the

relationship in the product line model? 2) given a subset of product line requirements, can we know if it

forms a valid single system? 3) How many valid single system can be built using this product line

model? 4) what requirements do valid single systems contain? [51], [52].

In [53], feature diagram is converted into grammar from which a parser can be generated to serve as

configuration validator. For example, feature diagram in fig. 1 can be converted to the followinggrammar (? marks optional term):

CoffeeMachine: Coin Beverage Ringtone?

Coin: 1$ | 1

Beverage: Coffee Tea? Cappuccino?

Batory shows the connexion between feature diagram, grammar and propositional formulas by

converting feature diagram to grammar and then from grammar to propositional formulas [54]. For

example, the grammar Coin: 1$ | 1 can be converted into the following formula:

(Coin => (1$ xor 1)) /\ (1$ => Coin) /\ (1=> Coin)

With those propositional formulas, Logic-Truth Maintenance System (LTMS) can be used to propagate

constraints as users select features in product specification and SAT solvers can be used to help debug

feature model.

Mendonca explores possibilities to improve BDD and SAT-Solver for analysis of large scale feature

model [55]. He defined heuristics for BDD variables ordering that yield better BDD. For SAT-Solver,

he found that the logical formulas derived from the structure of feature diagram can be analyzed

efficiently using SAT-Solver even though SAT is NP-Complete. However, additional constraints


20/25

expressed using logical formulas can pose performance problem for the analyses of large models.

In [35], a method to verify the well-formedness of feature-based model template is proposed. The

model template meta-model must be expressed in Meta-Object Facility (MOF) and well-formedness

constraints are expressed in Object Constraint Language (OCL). For example, the check can ensure that

a binary relationship between two classes must be removed if one or both of the classes are removed.

Liu describes how to verify safety properties against behavioral model in product line expressed in state

chart [56]. In this method, product line state model represented in statechart and product line scenarios

satisfying or violating safety properties are built. After that, for each product P, each customized state

model (derived from product line state model for P) is executed against the corresponding customized

scenarios (derived from product line scenarios for P) using TestConductor tool to check whether any

safety properties are violated. Note that the check is done at the product level not product line level.

Classen uses Featured Transition System (FTS) to model behavior in product line and describes

algorithms to check regular and omega properties against FTS [46]. Asirelli defines DHML, a novel

deontic extension of Hennessy-Milner and CTL-like logic for product families that allows both static

constraints over the products and constraints over behaviors to be expressed in a single framework [3].Model checking can be used to check those constraints against behavioral model expressed in MTS.

7. Elaboration technique

Kang describes the elaboration process of feature model consists of (1) collecting source documents,

(2) identifying features, (3) abstracting and classifying the identified features as a model, (4) defining

the features and (5) validating the model [10]. Czarnecki proposes method to construct feature diagram

from propositional formulas [57]. Use of OpenOME tool to generate initial feature diagram from goal

graph is described in [49]. Antnio extends i* framework by adding cardinality to the intentionalelements, making it easier to derive a feature model from i* models [58].

Commonality and Variability Analysis (CVA) which is the process to identity commonality (i.e.

requirements common to all product in the product line) and variability (i.e. requirements specific to

only some products) is presented in [31].

An approach for elicitation and specification of Use Cases for product lines based on existing user

documentation is described in [59].

Kim proposes method to identify domain requirements through goals and scenarios [60]. Liaskos

describe goal-based variability acquisition by associating goal to a set of concerns from whichalternative refinements of goal can be introduced [61]. For example, for the goal Send a Message,

there are a set of associated concerns each described with question such as Who will Send a

Message?, To Whom?, When?, Where?, How fast?, What Message?. Answering those

questions result in alternative refinements of the goal. For instance, answering the question Who will

Send a Message? can yield two alternatives: the user or the machine.

Gomaa describes the process of building state machines for software product line using inherited state


21/25

machines and parameterized state machines [62]. For inherited state machines approach, base state

machine (state machine common to all products in the family) called kernel state machine is built and

then state machine for individual product can be obtained by specializing kernel state machine by

adding new states, new events and new transitions, and by adding or removing actions and activities

corresponding to features in that product. With parameterized state machines approach, state machine is

designed with all the states, transitions, events, actions, and activities corresponding to all the features.

Transitions, actions and activities that depend on some features are guarded with conditions expressedin term of those features. The notation {feature = feature_name} state_name is used to indicate that

the state state_name is dependent on the featurefeature_name for its existence.

8. Conclusion

We described different approaches used to model variability on the specification level and on the

realization level in requirements engineering context. OVM and decision model represent variability

using very abstract concepts namely variabilities for OVM and decisions for decision model. Moreover,

there is no structuring mechanism besides basic constraints such as requires and excludes in OVM and

constraints expressed using set and logical operators in decision model. Therefore, we can not do much

analyses on those models. Commonality and Variability Analysis (CVA) is described using textual

document and thus is not suitable for analysis. Because of its compact representation and the fact that

stakeholders are familiar with features, feature model is the most popular approach used to model

variability. Despite its popularity, feature model does have some disadvantages. On the one hand,

features are just strings without any semantic. On the other hand, decompositions of features into sub-

features are arbitrary, there is no precise rule to check decomposition adequacy. Moreover, because

feature model lacks information on why a particular feature exists, using feature model alone make

feature configuration process difficult. KAOS (Keep All Objectives Satisfied), Goal-oriented

requirements engineering method, described in [28] provides an approach covering the entire

requirements life cycle that provides modeling notations as well as whole set of techniques forelicitation, evaluation, specification, analysis and evolution for single systems development. Even

though or-refinement can be used to model variability in system families, goal model is originally

intended for single systems development, hence most of system families related issues have not yet been

explored in goal model.

One direction in handling variability in system families is to explore feature model because it is the

most used approach to model variability. To cope with the lack of semantic in features, we can

investigate how, by labeling other models with features like in Featured Transition System (FTS) [46],

we can provide semantic to features. Similarly, we can investigate how, by relating features to others

models, adequacy of features decomposition or feature model correctness can be verified and how

feature configuration can be made easier. Among those other models, goal model is worth considering.

As KAOS provides an approach covering the entire requirements life cycle, another direction might be

to explore goal-based requirements engineering method to see how variability related issues can be

handled. In section 2.3, we have shown how constraints expressed in term of goals can be used to

eliminate alternative options that do not satisfy the constraints (goals) when selecting goals for a

particular product.


22/25

References

[1] "Software Product Lines," http://www.sei.cmu.edu/productlines/.

[2] C. Krueger, "Variation management for software production lines," Software Product Lines, 2002,

pp. 1-13.

[3] P. Asirelli, M. ter Beek, S. Gnesi, and A. Fantechi, "A deontic logical framework for modellingproduct families," matrix.isti.cnr.it, 2010, pp. 37-44.

[4] G. Bckle, K. Pohl, and F. Linden, "Software Product Line Engineering," Software Product Line

Engineering, Berlin/Heidelberg: Springer-Verlag, 2005, pp. 19-38.

[5] G. Halmans and K. Pohl, "Communicating the variability of a software-product family to

customers," Software and Systems Modeling, vol. 2, 2003, p. 1536.

[6] M. Becker and G. Kaiserslautern, "Towards a general model of variability in product families,"

Software Variability Management, 2003.

[7] G.S. Andreas Metzger, Klaus Pohl, Patrick Heymans, Pierre-Yves Schobbens, "Disambiguating the

Documentation of Variability in Software Product Lines: A Separation of Concerns,Formalization and Automated Analysis," 15th IEEE International Requirements Engineering

Conference, 2007, pp. 243-253.

[8] J. van Gurp, J. Bosch, and M. Svahnberg, "On the notion of variability in software product lines,"

Proceedings Working IEEE/IFIP Conference on Software Architecture, 2001, pp. 45-54.

[9] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, J.H. Obbink, and K. Pohl, "Variability issues in

software product lines," Software Product-Family Engineering, 2002, pp. 13-21.

[10] K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson, Feature-oriented domain analysis

(FODA) feasibility study, Technical Report CMU/SEI-90-TR-21, SEI, 1990.

[11] P. Schobbens, P. Heymans, and J. Trigaux, "Feature diagrams: A survey and a formal semantics,"14th IEEE International Requirements Engineering Conference (RE'06), 2006, pp. 139-148.

[12] K. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh, "FORM: A feature-oriented reuse method

with domain-specific reference architectures,"Annals of Software Engineering, vol. 5, 1998, p.

143168.

[13] M. Griss, J. Favaro, and M. D'Alessandro, "Integrating feature modeling with the RSEB,"

Software Reuse, 1998. Proceedings. Fifth International Conference on, IEEE Comput. Soc,

1998, p. 7685.

[14] M. Riebisch, K. Bllert, D. Streitferdt, and I. Philippow, "Extending feature diagrams with UML

multiplicities," 6th Conference on Integrated Design & Process Technology (IDPT 2002),Pasadena, California, USA, 2002.

[15] K. Lee, K. Kang, and J. Lee, "Concepts and guidelines of feature modeling for product line

software engineering," Software Reuse: Methods, Techniques, and Tools, 2002, p. 6277.

[16] D. Fey, R. Fajta, and A. Boros, "Feature modeling: a meta-model to enhance usability and

usefulness," Software Product Lines, 2002, p. 198216.

[17] A. van Deursen and P. Klint, "Domain-Specific Language Design Requires Feature Descriptions,"

Journal of Computing and Information Technology, vol. 10, 2002, pp. 1-17.


23/25

[18] K. Czarnecki, T. Bednasch, P. Unger, and U. Eisenecker, "Generative programming for embedded

software: An industrial experience report," Generative Programming and Component

Engineering, Springer, 2002, p. 156172.

[19] K. Czarnecki, S. Helsen, and U. Eisenecker, "Staged configuration using feature models," Software

Product Lines, 2004, p. 266283.

[20] K. Czarnecki and C. Kim, "Cardinality-based feature modeling and constraints: A progress report,"International Workshop on Software Factories, Citeseer, 2005.

[21] M. Eriksson, J. Brstler, and K. Borg, "The pluss approach-domain modeling with features, use

cases and use case realizations," Software Product Lines, 2005, p. 3344.

[22] M. Reiser and M. Weber, "Multi-level feature trees," Requirements Engineering, vol. 12, 2007, pp.

57-75.

[23] Q. Boucher, A. Classen, P. Faber, and P. Heymans, "Introducing TVL, a Text-based Feature

Modelling Language," Proceedings of the Fourth International Workshop on Variability

Modelling of Software-intensive Systems (VaMoS10), Linz, Austria, January, 2010, p. 2729.

[24] C. Krueger, "The Pragmatic 3-Tiered Software Product Line Methodology," 2007, pp. 1-12.[25] C. Schwanninger, I. Groher, C. Elsner, and M. Lehofer, "Variability modelling throughout the

product line lifecycle,"Model Driven Engineering Languages and Systems, 2009, p. 685689.

[26] F. Bachmann and L. Northrop, "Structured Variation Management in Software Product Lines,"

hicss, IEEE Computer Society, 2009, p. 17.

[27] K. Lauenroth and K. Pohl, "Software Product Line Engineering," Software Product Line

Engineering, Berlin/Heidelberg: Springer-Verlag, 2005, pp. 57-88.

[28] A.V. Lamsweerde,Requirements Engineering: From System Goals to UML Models to Software

Specifications, Wiley, 2009.

[29] A.V. Lamsweerde, "Requirements engineering: from craft to discipline," on Foundations ofsoftware engineering, 2008.

[30] K. Schmid and I. John, "A customizable approach to full lifecycle variability management,"

Science of Computer Programming, vol. 53, 2004, pp. 259-284.

[31] M.a. Ardis and D.M. Weiss, "Defining families: The Commonality Analysis," Proceedings of the

19th international conference on Software engineering - ICSE '97, 1997, pp. 649-650.

[32] K. Pohl and T. Weyer, Software Product Line Engineering, Berlin/Heidelberg: Springer-Verlag,

2005.

[33] F. Bachmann, M. Goedicke, J. Leite, R. Nord, K. Pohl, B. Ramesh, and A. Vilbig, "A meta-model

for representing variability in product family development," Software Product-Family

Engineering, 2004, p. 6680.

[34] K. Czarnecki and M. Antkiewicz, "Mapping features to models: A template approach based on

superimposed variants," Generative Programming and Component Engineering, Springer, 2005,

p. 422437.

[35] K. Czarnecki and K. Pietroszek, "Verifying feature-based model templates against well-

formedness OCL constraints," of the 5th international Conference on, 2006, p. 211.


24/25

[36] M. Becker and G. Kaiserslautern, "XML-Enhanced product family engineering," Proceedings of

the Sixth Biennial World Conference on Integrated Design and Process Technology (IDPT2002),

Pasadena, USA, 2002.

[37] M. Clau, "Generic Modeling using UML extensions for variability,"DSVL 2001, 2001.

[38] T. Ziadi, L. Hlout, and J. Jzquel, "Towards a UML profile for software product lines,"

Software Product-Family Engineering, vol. 29, 2004, p. 129139.[39] I. John and D. Muthig, "Tailoring use cases for product line modeling," Proceedings of the

International Workshop on Requirements Engineering for product lines, Citeseer, 2002, p. 26

32.

[40] A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, and A. Maccari, "Use case description of

requirements for product lines," Proceedings of the International Workshop on Requirements

Engineering for Product Lines, Citeseer, 2002, p. 2002033.

[41] D. Fischbein, S. Uchitel, and V. Braberman, "A foundation for behavioural conformance in

software product line architectures,"International Symposium on Software Testing and Analysis,

2006.

[42] K. Larsen, U. Nyman, and A. W\kasowski, "Modal I/O automata for interface and product line

theories," Programming Languages and Systems, 2007, p. 6479.

[43] A. Fantechi and S. Gnesi, "A behavioural model for product families," Foundations of Software

Engineering, 2007.

[44] A. Fantechi and S. Gnesi, "Formal modeling for product families engineering," Software Product

Line Conference, 2008. SPLC'08. 12th International, Ieee, 2008, p. 193202.

[45] P. Asirelli, M. ter Beek, A. Fantechi, and S. Gnesi, "Deontic Logics for Modeling Behavioural

Variability," Proceedings of the Third International Workshop on Variability Modelling of

Software-intensive Systems (VaMoS09), ICB Research Report, 2009, p. 7176.

[46] A. Classen, P. Heymans, P. Schobbens, A. Legay, and JF, "Model checking lots of systems:

Efficient verification of temporal properties in software product lines," Conference on Software,

2010.

[47] K. Czarnecki, S. Helsen, and U. Eisenecker, "Staged configuration through specialization and

multilevel configuration of feature models," Software Process: Improvement and Practice, vol.

10, 2005, pp. 143-169.

[48] A. Hubaux, A. Classen, and P. Heymans, "Formal Modelling of Feature Configuration

Workflows,"fundp.ac.be, SPLC, 2009.

[49] Y. Yu, J.C. do Prado Leite, A. Lapouchnian, and J. Mylopoulos, "Configuring features with

stakeholder goals," Proceedings of the 2008 ACM symposium on Applied computing - SAC '08,

New York, New York, USA: ACM Press, 2008, p. 645.

[50] S. Bhne, G. Halmans, K. Lauenroth, and K. Pohl, Software Product Lines, Berlin, Heidelberg:

Springer Berlin Heidelberg, 2006.

[51] M. Mannion, "Using first-order logic for product line model validation," Software Product Lines,

2002, p. 149202.

[52] M. Mannion and J. Camara, "Theorem proving for product line model verification," Software


25/25

Product-Family Engineering, 2004, p. 211224.

[53] M. de Jonge, J. Visser, and A. CWI, "Grammars as feature diagrams," ICSR7 Workshop on

Generative Programming, Citeseer, 2002, p. 2324.

[54] D. Batory, "Feature models, grammars, and propositional formulas," Software Product Lines,

2005, p. 720.

[55] M. Mendonca, "Efficient reasoning techniques for large scale feature models," Ph.D. dissertation,University of Waterloo, 2009.

[56] J. Liu, J. Dehlinger, and R. Lutz, "Safety analysis of software product lines using state-based

modeling ," Journal of Systems and Software, vol. 80, 2007, pp. 1879-1892.

[57] K. Czarnecki and A. Wasowski, "Feature Diagrams and Logics: There and Back Again,"

International Conference on Software Product Line, 2007.

[58] S. Antnio, J. Arajo, and C. Silva, "Adapting the i* Framework for Software Product Lines,"

Lecture Notes In Computer Science; Vol. 5833, 2009.

[59] A. Fantechi, S. Gnesi, I. John, G. Lami, and J. Drr, "Elicitation of use cases for product lines,"

Software Product-Family Engineering, 2004, p. 152167.

[60] J. Kim, M. Kim, and S. Park, "Goal and scenario based domain requirements analysis

environment,"Journal of Systems and Software, vol. 79, 2006, pp. 926-938.

[61] S. Liaskos, A. Lapouchnian, Y. Yu, E. Yu, and J. Mylopoulos, "On goal-based variability

acquisition and analysis," 14th IEEE International Conference Requirements Engineering, Ieee,

2006, p. 7988.

[62] H. Gomaa, "Designing Software Product Lines with UML," 29th Annual IEEENASA Software

Engineering Workshop Tutorial Notes SEW05, 2005, pp. 160-216.

handling variations in system families - a survey_3

Documents