Software Product Line Engineering with the UML: Deriving Products

TLDR: This chapter investigates the product derivation in the context of the product line engineering with the UML using a UML model transformation and proposes a set of extensions to model product line variability in two types of UML: class diagrams and sequence diagrams.

Abstract: Software product line engineering introduces two new dimensions into the traditional engineering of software-based systems: the variability modeling and the product derivation. The variability gathers characteristics that differ from one product to another, while the product derivation is defined as a complete process of building products from the product line. Software Product Line Engineering with the UML has received a lot of attention in recent years. However most of these works only concern variability modeling in UML static models and few works concern behavioral models . In addition, there is very little research on product derivation. This chapter investigates the product derivation in the context of the product line engineering with the UML. First, a set of extensions are proposed to model product line variability in two types of UML mo dels: class diagrams (t he static aspect) and sequence diagrams (the behavioral aspect). Then we formalize product derivation using a UML model transformation. An algorithm is give n to derive a static model for a product and an algebraic approach is proposed to derive product-specific statecharts from the sequence diagrams of the product line. Two simple case studies are presented, based on a Mercure product line and the banking product line, to illustrate the overall process, from the modeling of the product line to the product derivation.

Figures

Fig. 7. UML2.0 Sequence Diagrams for the Banking PL.

Fig. 1. The FODA diagram for the Mercure PL.

Table 1. The Banking PL Members.

Fig. 5. Static aspect derivation: the derivation algorithm.

Fig. 6. The CustomMercure model, automatically derived from the Mercure PL model.

Fig. 13 shows the flat statecharts generated from the twelve basic SDs from Fig. 9 for the Bank object.

Full text

Software Product Line Engineering with the UML:
Deriving Products
Tewfik Ziadi and Jean-Marc Jézéquel
Abstract.
Software product line engineering introduces two new dimensions into the traditional engi-
neering of software-based systems: the variability modeling and the product derivation. The
variability gathers characteristics that differ from one product to another, while the product
derivation is defined as a complete process of building products from the product line. Soft-
ware Product Line Engineering with the UML has received a lot of attention in recent years.
However most of these works only concern variability modeling in UML static models and
few works concern behavioral models. In addition, there is very little research on product
derivation. This chapter investigates the product derivation in the context of the product line
engineering with the UML. First, a set of extensions are proposed to model product line va-
riability in two types of UML models: class diagrams (the static aspect) and sequence dia-
grams (the behavioral aspect). Then we formalize product derivation using a UML model
transformation. An algorithm is given to derive a static model for a product and an algebraic
approach is proposed to derive product specific statecharts from the sequence diagrams of
the product line. Two simple case studies are presented, based on a Mercure product line and
the banking product line, to illustrate the overall process, from the modeling of the product
line to the product derivation.
999.1. Introduction
Rather than describing a single software system, the model of a software product line (PL)
describes the set of products in the same domain. This is done by distinguishing elements
shared by all the products of the line, and elements that may vary from one product to an-
other. Concepts of commonality and variability are respectively used to designate com-
mon and variable elements in a product line [39] Variability can concern two main as-
pects: optionality or variation [7, 18]. An optional element only concerns some products
and it can be omitted in others. Variation elements define alternatives (variants) to choose
from. Beyond variability modeling, the product derivation process is defined as a com-
plete process of constructing products from the software product line [12].
UML (Unified Modeling Language) [33] is an object-oriented notation for software sys-
tem modeling. It proposes a set of models to specify several aspects of systems. Class dia-
grams are UML models that can be used to specify static aspects of systems, while se-

2 Tewfik Ziadi, Jean-Marc Jézéquel
quence diagrams and statechart diagrams are examples of models describing behavioral
aspects. Software Product Line Engineering with the UML has received a lot of attention
in recent years [3, 5, 9, 10, 13, 14, 18 26, 27, 37, 38]. Subchapter 999.4 presents a study
on these works and shows that the most of existing works only concern UML static mod-
els and few works concern behavioral models [3, 14, 17]. In addition, there is very little
research on product derivation [3, 13]. The product derivation support is a significant cri-
terion for determining the utility for users of any product line approach. The approaches
that only model variability in UML models without product derivation support have only
a descriptive utility. This means that these approaches are only useful for product line ar-
chitecture description.
In this work we defend the idea that any approach of PL engineering should go beyond the
descriptive utility and propose supports for resolving the variability and obtaining product
models. For this, we investigate the product derivation process in the context of PL engi-
neering with the UML. We give an overview of product line design by first presenting
structural variability involved in class diagrams, then how behavioral aspects may be de-
signed using UML sequence diagrams. We then formalize product derivation as UML
model transformations. First, a transformation algorithm is given to automatically derive
the static product model from the PL model. Secondly, an algebraic approach is proposed
to derive product-specific statecharts from PL sequence diagrams.
To present these design techniques, subchapter 999.2 will focus on static aspects of the
product line design, its constraints and its derivation process into specific products; this
part also stresses the need to check derived products with respect to variability constraints.
Next, subchapter 999.3 proposes an algebraic approach to derive product specific state-
charts from the sequence diagrams of the product line. Here product line behaviors are
specified as algebraic expressions on basic UML2.0 sequence diagrams, where variability
is introduced by means of three new algebraic constructs. Our derivation approach is de-
fined in two steps: we first define an algebraic way to derive product expressions from the
PL expression and then statecharts are generated by transforming product sequence dia-
grams given as an expression into a composition of statecharts. Subchapter 999.4 dis-
cusses related work, and finally subchapter 999.5 draws some conclusions and perspec-
tives.
999.2. Deriving Static Aspects
999.2.1. The Mercure Product Line
As a case study for describing static aspect derivation, we consider the Mercure PL which
is a line of SMDS (Switched Multi-Megabit Data Service) servers whose design and im-
plementation have been described in [23, 24]. It can abstractly be described as a commu-
nication software delivering, forwarding, and relaying messages from and to a set of net-
work interfaces connected into an heterogeneous distributed system. The Mercure PL

999 Software Product Line Engineering with the UML: Deriving Products 3
must handle variants for five variation points: any number of specialized processors (En-
gines), network interface boards (NetDriver), levels of functionality (Manager), user inter-
face (GUI) and support for languages (Language). Fig. 1 shows a feature diagram of the
Mercure PL (we follow FODA notations [28]). The Mercure consists of Engine, Net
Driver, Manager, GUI, and Language. The Mercure product may support one or more of
Engine 1,..Engine N, the selection being represented by FODA alternative features. In the
same way, we define all NetDriver, Manager, GUI, and Language dimensions.
The FODA [28] notations allow us to specify dependency relationships, called composi-
tion rules, between domain features. FODA supports two types of composition rules: the
"require" rule that expresses the presence implication of two or more features, and the
"mutually-exclusive" rule that captures the mutual exclusion constraint on feature combi-
nations. A "require" rule is identified in the context of the Mercure PL: it specifies that the
choice of the NetDriver1 implies the choice of the Engine1 (see Fig. 1).
Fig. 1. The FODA diagram for the Mercure PL.
999.2.2. PL Static architecture as UML class diagrams
To describe the PL static architecture, we use UML class diagrams. In [42], we have pro-
posed a UML profile for PL. This profile includes mechanisms to specify variability
within two types of UML 2.0 diagrams: class diagrams and sequence diagrams. For class
diagrams, we proposed to specify variability using two mechanisms: optionality and varia-
tion.

4 Tewfik Ziadi, Jean-Marc Jézéquel
• Optionality. Optionality in PL means that some features are optional for the PL mem-
bers, i.e. they can be omitted in some products. To specify optionality in class dia-
grams, we introduced the <<optional>> stereotype. This stereotype can be applied
to classes, packages, attributes or operations [42].
•
Variation. Inheritance in UML allows defining variability in class diagrams [2]. The
idea is to define a variation point as an abstract-class and variants as concrete sub-
classes. Each sub-class defines the implementation of the abstract-class in a specific
way. However, this variability is only resolved at run-time and it is not explicit in the
model. To explicitly specify the variation in UML class diagram, we introduced two
stereotypes <<variation>> and <<variant>> [42]. The <<variation>> ste-
reotype is associated with the abstract-class while <<variant>> is associated with
sub-classes. Each product can choose one or more sub-classes [42]. Fig. 2 shows an e-
xample of a variation point specified using the <<variation>> and <<vari-
ant>> stereotypes. Notice that the sub-class A
in Fig. 2 is not stereotyped <<vari-
ant>>; this means that this sub-class is mandatory for all products.
Fig. 2. Example of a variation point.
Let us now apply these extensions to the Mercure PL. As previously specified in the
FODA diagram of the Mercure PL, the Mercure product may support a set of Engines
among Engine1, Engine2, EngineN. Using the variation mechanism presented
above, we define an abstract class called Engine and stereotyped <<variation>>
and the several dimensions as sub-classes stereotyped <<variant>> In the same way
we specify other variation points: NetDriver, Manager, GUI, and Language. Fig. 3
shows the UML class diagram of the Mercure PL. It basically says that a Mercure system
is an instance of the Mercure class, aggregating an Engine (that encapsulates the work that
Mercure has to do on a particular processor of the target distributed system), a collection
of NetDrivers, a collection of Managers (that represent the range of functionalities avail-
able), and the GUI that encapsulates the user preference variability factor. A GUI has it-
self a collection of supported languages (see Fig. 3).

999 Software Product Line Engineering with the UML: Deriving Products 5
Mercure
<<variation>>
Engine
<<variation>>
NetDriver
<<variant>>
Engine 1
<<variant>>
Engine N
<<variant>>
NetDriver 1
<<variant>>
NetDriver N
<<variation>>
Manager
<<variant>>
Manager 1
<<variant>>
Manager N
Message
<<variation>>
GUI
<<variant>>
GUI 1
<<variant>>
GUI N
<<variation>>
Language
<<variant>>
Language 1
<<variant>>
Language N
Buffers
1..*
1
Watch
1
*
Observe 1..*
1..*
1..*
1..*
1
1..*
Use 1..*
Available
1
1..*
Use 1
1
..........
..........
..........
..........
..........
Fig. 3. The Mercure Product Line UML class diagram.
999.2.3. Product Line Constraints
In addition to variability, the product line architecture is defined as a standard architecture
with a set of constraints [4]. In this context, we have identified in [45] two types of PL
constraints that guide the product derivation process. We proposed to define them as OCL

Frequently asked questions

Q1. What are the contributions mentioned in the paper "Software product line engineering with the uml: deriving products" ?

In this paper, a set of extensions are proposed to model product line variability in two types of UML models: class diagrams and sequence diagrams. 

Q2. What are the future works in "Software product line engineering with the uml: deriving products" ?

The authors used their approach in several case studies ; however they hope in the future to use it in an industrial context. 

Q3. What are the types of constraints that can be used to improve genericity?

The introduction of variability using the <<variant>>, <<variation>>, and <<optional>> stereotypes improves genericity but can generate some inconsistencies. 

Q4. What is the algebraic composition of statecharts?

Using their algebraic framework for statecharts, translating product UML sequence diagrams to statecharts is defined in two steps: synthesis from basic sequence diagrams and synthesis from combined sequence diagrams. 

Q5. What is the method for generating statecharts from basic sequence diagrams?

For each object O, a REST is constructed by replacing in the RESD seq, alt, and loop respectively by statecharts operators seqs, alts and loops, and each reference to a SD S by the statechart P(S,O). 

Q6. What is the role of behavior modeling in the traditional engineering of software-based systems?

In addition to static aspect description, behavior modeling plays an important role in the traditional engineering of software-based systems; it is the basis for systematic approaches to requirements capture, specification, design and simulation, code generation, testing, and verification. 

Q7. What is the definition of the presence constraint in the Mercure PL?

The presence constraint in the Mercure PL is formalized as an invariant for the Model meta-class as follows:context Model inv:self.presenceClass(’NetDriver1’) implies self.presenceClass(’Engine1’)presenceClass(C) is an auxiliary operation indicating if a specific class called C is present in the model. 

Q8. What is the definition of a variation point in a Mercure class diagram?

It basically says that a Mercure system is an instance of the Mercure class, aggregating an Engine (that encapsulates the work that Mercure has to do on a particular processor of the target distributed system), a collection of NetDrivers, a collection of Managers (that represent the range of functionalities available), and the GUI that encapsulates the user preference variability factor. 

Q9. What other approaches have been used to generate statecharts from mscs?

Several other approaches [31, 35, 36] study statechart synthesis from Message Sequence charts (MSC) [22], a scenario formalism similar to sequence diagrams. 

Q10. What is the definition of a dependency in the PL class diagram?

As shown previously, the PL class diagram is defined by a set of variation points and to derive a specific-product class diagram, some decisions (or choices) associated with these variation points are needed. 

Q11. What are the mechanisms to specify variability in a Mercure diagram?

This profile includes mechanisms to specify variability within two types of UML 2.0 diagrams: class diagrams and sequence diagrams. 

Q12. What is the approach to statechart synthesis?

Their approach does not use variables, and structures the statecharts and transitions based on information provided by lifeline orderings and SD operators. 

Q13. What is the purpose of statechart synthesis?

As discussed in [44], statechart synthesis should be considered more as a step towards implementation rather than as a definitive bridge from user requirements to code. 

Q14. What is the factory method that is used to generate the product class diagram?

It takes as input the PL class diagram, and the concrete factory from the decision model and it generates as output the product class diagram. 

Q15. What are the constraints of the derivation algorithm?

The generic constraints represent the pre-conditions of the derivation algorithm while specific constraints represent the post-conditions:DeriveProductModels(PL_classDiagram:Model, aConcreteFactory:Class)pre: check Generic Constraints on PL classDiagram post: check Specific Constraints on the Product classDiagram result. 

Q16. What is the composition mechanism of the ML2.0 statechart?

This composition mechanism is very close to that of current SDs in UML2.0 and their approach can be used to generate statecharts from MSCs. 

Q17. What is the factory method that corresponds to the GUI variation point?

The Factory Method that corresponds to the GUI variation point is new_gui(), so the authors add two stereotypes <<GUI1>> and <<GUI2>> to this factory method (see Fig. 4 ).