Upload
seangmeng-long
View
219
Download
0
Embed Size (px)
Citation preview
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
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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].
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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,
8/3/2019 Handling Variations in System Families - A Survey_3
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/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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 .
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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].
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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.
8/3/2019 Handling Variations in System Families - A Survey_3
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
8/3/2019 Handling Variations in System Families - A Survey_3
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.