![](https://csdnimg.cn/release/download_crawler_static/10703113/bg5.jpg)
ISRN Software Engineering 5
Riebisch proposed to explicitly represent cardinalities
in Feature Diagram and thus extends them with UML
multiplicities [46]. Group cardinalities are introduced and
denote the minimum and maximum number of features that
can be selected from a feature group. There are two other
changes: first a feature is allowed to have multiple parents
and second, it is no longer features that are optional or
mandatory, but edges.
Czarnecki and Eisenecker adapted Feature Diagrams in
the context of Generative Programming [35] by adding an
OR feature decomposition and defining a graphical represen-
tation of features dependencies. More recently, this notation
was extended with new concepts: staged configuration (used
for product derivation) and group and feature cardinalities
[47].
Product Line Use Case modeling for System and Software
engineering (PLUSS) [ 48] is another approach based on Fea-
tuRSEB [44] that combines Feature Diagrams and Use Cases.
The originality of this approach is that the decomposition
operator is made explicit to compose feature: two new types
of nodes are introduced: single adapters (represent XOR-
decomposition) and multiple adapters (OR decomposition).
Many other extensions to feature modeling have been
proposed to increase their expressiveness. Deursen a nd Klint
in [49] defines an abstract syntax and semantics for Feature
Diagrams. Batory [50] introduces propositional constraints
defined between features. Ferber et al. [51] defines a separate
view to represent feature dependencies and interactions.
Figure 2 from [52] provides a synthesis of the concepts
used to capture variability and how they are graphically
represented by the feature modeling languages described in
this section. The figure shows what each feature modeling
dialect is able to represent, as well as its limitations.
Despite their popular ity and widespread use, all these
Feature Models variants only provide a hierarchical structur-
ing of high-level product functionalities [53], with very little
connection with the actual software products. Since there
is no indication of what the concrete representations of the
features are, Feature Models only allow the SPL engineer to
make a simple configuration of products through a feature
selection. It is thus clear that more than a simple Feature
Model is required for performing product derivation.
These limitations generated the need for other more
expressive mechanisms for representing variability and link-
ing it to the base assets.
3. An Overview on Representative
Variability Modeling Methods
3.1. Introduction. Since SPLs revolve around the ideas of
capturing commonalities and variations, a SPL can be fully
modeled as
an assests model that models a set of core assets, that
is, reusable components used for the development of
new products;
avariabilitymodelthat represent the commonality
and variability between product line members.
Since standard languages are generally not developed to
explicitly represent all types of variability, SPL models are
frequently expressed by extending or annotating standard
languages (models). The annotated models are unions of all
specific models in a model family and contain all necessary
variability concepts.
In MDE, the structure of a domain is explicitly captured
in a metamodel. So it is clear that we need two different
metamodels (i.e., two different sets of concepts) to handle
both aspects of SPLs, but we also need to somehow connect
these two sets of concepts to manipulate models of SPLs.
Consequently, as noted by [54], there are two categories of
techniques to handle variability: amalgamated and separated.
The amalgamated approach proposes to connect the asset
model and the variability model at metamodel level, that is,
to augment the asset metamodel with variability concepts,
while the separated approach proposes to connect them at
model level, that is, the two modeling languages remain
independent and the connection is made across model
elements of either metamodels.
In turn, each of these two main styles of approaches
decomposes into several threads that we are going to
overview in the next subsections, taking into account issues
such as addressing behavioral variability or handling vari-
ability at s everal stages in the software lifecycle (requirements
time, design time, deployment time, and runtime).
Table 1 summarizes the classification proposed in [52]. It
outlines what does happen at metamodel and model level for
the identified classes and subclasses of var iability modeling
techniques.
3.2. Amalgamated Approach. Techniques using an amalga-
mated approach extend a language or a general purpose
metamodel with specific concepts that allow designers to
describe variability. Their core char acteristic is the mix
of variability and product line assets concepts into a
unique model. Concepts regarding variability and those that
describe the assets metamodel are combined into a new
language, that may either have a new, mixed syntax, or one
based on that of the base model extended by the syntax of
the variability language. This applies at both metamodel and
model level. We further distinguish 3 subcategories: ad hoc
extensions to existing languages, generic extensions that can
be woven into any language, and finally ad hoc languages.
3.2.1. Annotate a Base Model by Means of Extensions. Clauss
[55, 56], first proposed to apply variability extensions to
UML Class Diagrams, leveraging the UML of extension
mechanism that allows designers to describe generic models.
Clauss uses such generic models in which he explicitly defines
variability at par ticular points called hot spots. The extensions
proposed are based on the notions of variation points and
variants: variation points help locate variability; each variant
denotes a concrete way to realize that variability.
Variation points and variants are explicitly marked with
the stereotypes
variation Point,respectivelyvar iant,
specified for the Generalizable Element UML metaclass.
Therefore the variation p oint notion can be applied to