Software Product Line Engineering with ABS

Radu Muschevici

Software Engineering Group, Department of Computer Science, TU Darmstadt (Germany)

Fakultas Ilmu Komputer, Universitas Indonesia

FASILKOM RSE Lab Training, 8 January 2016

1 / 54
Software Engineering Challenges

Different customers (users)…

▶ Have individual requirements.
▶ Need individual software solutions based on their requirements.

(Custom) software development is challenging and expensive.

▶ The nature of programming is inherently complex.
▶ Skilled developers are expensive and hard to come by.

2 / 54
Software Engineering Challenges
Traditional Solutions

How to satisfy all customer’s individual requirements … efficiently?

“Traditional” methods
▶ Build individual software product from scratch for each customer.
▶ Too inefficient, costly

▶ Provide standard software that includes all features any

customer might require.
▶ Contains far more functionality that any individual user needs.
Complex, slow, bug-ridden, high resource demands.

3 / 54
Software Engineering Challenges: SPLE
Software Product Lines (SPL), a.k.a. Software Product Families
Development Effort
▶ Develop collection of similar software products from a shared set
of software assets.

Effort/Costs
Traditional
Development

Software
Product
Lines

# Variants
1 2 3 4
37

▶ How is this reduced effort achieved?

4 / 54
Software Product Line Engineering (SPLE)

SPLE makes the development of software variants more efficient by

systematic sharing of common features.

▶ Software variants are individual software solutions based on

individual customer requirements.
▶ Software variants are built from reusable parts (artifacts).
▶ Software variability is modelled explicitly.

Advantages over standard software:

▶ Reduced complexity and resource usage, better performance
▶ Better fit for systems with limited resources: embedded, mobile

5 / 54
Software Variability

The set of reusable components in an SPL is variable:

▶ Optional components: can be part of a product but not another.
▶ Alternatives: some components have the same purpose but are
implemented differently.

Software variability is the ability to derive different software products

from a common set of artifacts.
[Apel et al. 2013]

6 / 54
Features

SPLE uses features to distinguish different software products.

Features are familiar notion when talking about software. Examples:

▶ “My text editor provides a spell-checking feature.”
▶ “Database system A provides multi-user support,
database system B does not.”
▶ “Email client A supports IMAP and POP3,
client B supports only POP3.”
▶ “The game we are developing will run on Android and iOS.”
▶ “Both financial software products support international
transactions.”

7 / 54
The SPLE Process

Basic principle: Two engineering processes

1. Domain engineering:
Build repository of reusable software artefacts.
2. Application engineering:
Build individual products by reusing these artefacts.

8 / 54
The SPLE Process
Diagram

1. Domain Engineering

Reusable Software Artefacts

2. Application Engineering

Software Product
9 / 54
The SPLE Process
Diagram

Problem Space Solution Space

Feature Model 1. Domain Engineering

Reusable Software Artefacts

Feature Selection 2. Application Engineering

Software Product
10 / 54
The SPLE Process using ABS
Diagram

Problem Space Solution Space

Feature Model (µTVL) 1. Domain Engineering

Core + ABS Deltas

Feature Selection
2. Application Engineering
(Product)

Software Product
11 / 54
The SPLE Process: Problem Space

Problem Space Solution Space

Feature Model (µTVL) 1. Domain Engineering

Core + ABS Deltas

Feature Selection
2. Application Engineering
(Product)

Software Product

1. Features
2. Feature Models
3. Feature Selection
4. µTVL: The feature modelling language of ABS

12 / 54
What is a Feature in SPLE?

A feature is an abstraction in the problem space – usually a name.

▶ Derived from customer requirements.

▶ Expresses variability: used to distinguish the products (variants) of
an SPL from each other.
▶ Means to communicate between stakeholders.
▶ Means to specify variants: feature selection as input for variant
generation.
▶ Mapped to reusable software artefacts in the solution space.

13 / 54
Feature Modelling

Features relate to other features. Examples:

▶ Secure email download requires SSL protocol
▶ Spell checking requires at least one natural language dictionary
▶ The game variant for Android is incompatible with iOS

Feature Model
▶ Models the variability of an SPL.
▶ Describes relationships between features
⇒ which feature combinations (selections) are valid?
▶ Model elements: features and their relationships (constraints).

14 / 54
Feature Selection

A feature selection is a subset of the features defined by a feature

model.

▶ A feature selection is valid if it satisfies the constraints defined by

the feature model.
▶ A valid feature selection determines a software product of the
SPL.

15 / 54
Feature Model Example

Feature model for a product line of cars:

1. Four features: engine, gasoline tank, electric motor, battery.
2. Feature dependencies:
▶ An engine requires a gasoline tank;
▶ A gasoline tank requires an engine;
▶ An electric motor requires a battery;
▶ A battery requires an electric motor.

Desired (valid) feature selections according to feature model:

▶ engine + gasoline tank
▶ electric motor + battery
▶ engine + gasoline tank + electric motor + battery
These feature selections describe the products of the product line, i.e.
the car variants.

16 / 54
Feature Selection Example

“Build me an electric car!”

▶ “Electric car” is the name (handle) for the feature selection

{electric motor, battery} – a.k.a. product.
▶ The feature selection satisfies the feature model constraints.
▶ Build requested product by composing the implementations of
the selected features.

17 / 54
Feature Diagrams

Feature diagrams are a common graphical notation to describe

feature models.

Example: feature model of an SPL of chat programs

▶ Features: text, voice, video communication; file transfer

▶ What are some valid feature selections of this feature model?

18 / 54
Feature Diagrams (cont.)

▶ Tree structure
▶ Nodes represent features (optional feature denoted by circle)
▶ Edges represent standard constraints, such as choice
(one-out-of-many, some-out-of-many, all-out-of-many)
▶ More general constraints (“cross-tree” constraints) need to be
specified with additional propositional logic formulas,
E.g. Video ⇒ (Voice ∧ Text)

19 / 54
Feature Diagram Semantics: Propositional Formula

▶ Features diagrams map to propositional formulas.

▶ Features represented as Boolean variables (true if selected)
▶ Constraints represented using logical connectors

▶ Example: propositional formula for the chat feature diagram:

Chat ∧ (Mode ⇔ Chat) ∧ (FileTransfer ⇒
Chat) ∧ ((Text ∨ Voice ∨ Video) ⇔ Mode)

▶ Enables automated reasoning

▶ Check validity of given feature selection (does it satisfy the
propositional formula?)
▶ Find all valid feature selections (= all solutions of the formula)
▶ Compare feature models, etc.

20 / 54
sjunctive combinations. notations for disjunctive combinations.
In Fig.and
he edges between a parent feature 2.3,athe edges
group between
of child a parent
features feature and a group of child features fi are
fi are
Feature Diagram Semantics (cont.)
connected
n empty arc. This graphical elementvia
featureone
outfrom
an empty
denotes
of a {feature
arc. This
a choice graphical
of exactly one element denotes a choice of exactly one
(that is, choose one from {f1 . . . fn }). In propositional
feature group (that is, choose f1 . . . fgroup
n }). In propositional
logic,
eralization of an exclusive it is a generalization
disjunction. Typical examples of an of
exclusive
exclusivedisjunction. Typical examples of exclusive
disjunctions of of
features are different implementations features
the same are functionality
different implementations
or of the same functionality or
Mandatory Optional
al notation 2.3Fig.Feature Modeling
2.2 Graphical notation 29
manda- for optional and manda-
lled bullet tory features. A filled bullet
Fig. 2.3 Graphical notation
ry feature, denotes a mandatory feature,
et denotes
forand
a one-out-of many
an empty bullet choice.
denotes
This choicefeature
an optional corresponds to a
generalized xor operator

f⇔p f⇒p
29
Choice: one-out-of-many Choice: some-out-of-many
Fig. 2.4 Graphical notation
for a some-out-of-many
choice. This choice corre-
sponds to the logical or
operator

∧
((f1 ∨ . . . ∨ fn ) ⇔ p) ∧ ¬(fi ∧ fj ) (f1 ∨ . . . ∨ fn ) ⇔ p
i<j
different technical platforms such as the choice of the supported operating system.
This construct is called alternative or mutually exclusive choice.
Figure 2.4 shows child features connected via a filled arc. This graphical element 21 / 54
Feature Modelling in ABS

Based on “standard” feature modelling approach, with few extensions:

▶ Support for feature attributes (Integers and Booleans)
▶ Support for defining cross-tree constraints
▶ Support for cardinalities (more precise specification of choice:
how many features out of a group of features)
▶ Feature models are expressed using textual language µTVL.

22 / 54
Feature Model Example1
Feature Diagram for an SPL of Bank Accounts

Account

Type Overdraft Fee

Int interest Int amount in [0..5]

excludes
Checking Savings
0≤interest≤1 interest>1

1
[Hähnle 2013]
23 / 54
Feature Model Example: ABS Implementation

ABS implementation of bank accounts feature model:

root Account {
group allof {
Type {
group oneof {
Checking {ifin: Type.interest == 0 || Type.interest == 1;},
Savings {ifin: Type.interest > 1; exclude: Overdraft;}
}
Int interest; // interest rate of account
},
opt Fee {Int amount in [0..5];},
opt Overdraft
}
}

24 / 54
 define additional constraints,
Specific if the
graphical child features
elements define of a
additional constraints, if the child features of a
Feature Diagrams to ABS-µTVL
cted independently.
common Figures
parent2.3 and 2.4
cannot show graphical
be selected
inations. notations for disjunctive combinations.
independently. Figures 2.3 and 2.4 show graphical

en a parent feature and2.3,

In Fig. a group of child
the edges features
between fi arefeature and a group of child features fi are
a parent
his graphicalconnected
element denotes a choice
via an empty arc.ofThis
exactly one element denotes a choice of exactly one
graphical
that is, choose one from
feature . . . fn }).
out of{fa1feature In propositional
group (that is, choose one from {f1 . . . fn }). In propositional
n exclusive disjunction.
logic, it is a Typical examples
generalization of exclusive disjunction. Typical examples of exclusive
of an
fferent implementations
disjunctions of the sameare
features functionality or
different implementations of the same functionality or
Mandatory feature f Optional feature f
Fig. 2.2 Graphical notation
for optional and manda-
tory features. A filled bullet
denotes a mandatory feature,
and an empty bullet denotes
an optional feature

ABS: ABS:
p group allof { f } p group allof { opt f }

25 / 54
 Feature Diagrams to ABS-µTVL (2)

g 29
Choice: one-out-of-many
otation
y choice.
nds to a
ator

otation
anyABS:
corre-p group oneof { f1, f2, ..., fn }
l or

26 / 54
 Feature Diagrams to ABS-µTVL (3)

Choice: some-out-of-many
otation
ny
orre-
or

ABS:
platforms such as the choice of the supported operating system.
p group [1..*] { f1, f2, ..., fn }
alled alternative or mutually exclusive choice.
s child features connected via a filled arc. This graphical element 2 – a more
ABS-
cted µTVL
choice of onesupports cardinality-based
or more features out of a feature feature
group. It modelling
is
oneflexible notation
feature of to express
the collection choice.
has to be selected,Example: zero-to-two-out-of-n:
but there are no
Mathematically, it denotes an inclusive
p group [0..2] { f1, f2, ..., fn } disjunction.
cting one
2 or several supported data types for storage is an example
[Czarnecki, Helsen, and Eisenecker 2004]
choice in the domain of embedded data management. For the 27 / 54
Feature Model Semantics

Straightforward translation of ABS feature model to propositional logic

formula over booleans and integers.

ABS compiler includes constraint solver that can:

▶ find all solutions (=valid feature selections) for a feature model,
▶ check whether given feature selection satisfies the feature model.

28 / 54
Products

Products are named feature selections, where feature attributes are

assigned concrete values. Examples:

// Checking Accounts
product Basic (Type{interest=0}, Checking, Overdraft, Fee{amount=1});

product Earner (Type{interest=1}, Checking, Overdraft);

product Student (Type{interest=0}, Checking);

// Savings Accounts
product BasicSaver (Type{interest=2}, Savings);

product BonusSaver (Type{interest=6}, Savings);

// an invalid feature selection (does not satisfy feature model)

product SavingsWithOverdraft (Type{interest=1}, Savings, Overdraft);

29 / 54
Product Expressions

Thanks to Triando3 it will soon be possible to declare products based

on already declared products using product expressions.

Example:
product Basic (Type{interest=0}, Checking, Overdraft, Fee{amount=1});
product Student = Basic - {Overdraft, Fee};

▶ More concise
▶ Establish dependencies between products

3
[Triando 2015]
30 / 54
The SPLE Process: Solution Space

Problem Space Solution Space

Feature Model (µTVL) 1. Domain Engineering

Core + ABS Deltas

Feature Selection
2. Application Engineering
(Product)

Software Product

1. Deltas Modules (Deltas)

2. SPL Configuration: Connecting Problem and Solution Space
3. Automated Software Product Derivation

31 / 54
Delta-Oriented Programming

ABS supports Software Product Line Engineering by implementing

Delta-Oriented Programming (DOP)4 .

Basic idea: describe differences between variants in a modular way.

Central concept: delta modules, a.k.a. deltas

4
[Schaefer et al. 2010]
32 / 54
Delta Modules (Deltas)

ABS deltas are code modules. They can add, remove or modify…
▶ Classes
▶ Interfaces
▶ Functions
▶ Algebraic Data Types
▶ Type synonyms
▶ Module imports & exports

Permitted class modifications:

▶ addition and removal of fields
▶ addition, removal and modification of methods
▶ extending the list of implemented interfaces

33 / 54
Code Reuse with Deltas

ABS has
▶ No subclassing, only subtyping (no extends, only implements)
▶ No traits, mixins, aspects, context layers, …

Instead: Deltas

▶ Base product (the core) with minimal (common) functionality

▶ Variants (products) obtained by applying deltas to base product
▶ Deltas allow code reuse across software products but not within
individual products.

34 / 54
Application of Deltas

Delta1 ··· Deltan

apply deltas

Core Software Product

▶ Given a product, the compiler determines the applicable deltas

and generates the corresponding software product.

35 / 54
Example: Core of Accounts SPL

module Account;

interface Account {
Int deposit(Int x);
}

class AccountImpl(Int aid, Int balance) implements Account {

Int deposit(Int x) {
balance = balance + x;
return balance;
}
}

36 / 54
Example: Deltas of Accounts SPL

delta DFee (Int fee); // Implements feature Fee

uses Account;
modifies class AccountImpl {
modifies Int deposit(Int x) {
Int result = x;
if (x >= fee)
result = original(x-fee);
else
result = original(x);
return result;
}
}

delta DSave (Int i); // Implements feature Savings

uses Account;
modifies class AccountImpl {
removes Int interest; // field removed & added with new initial value
adds Int interest = i;
}

37 / 54
Accessing “Previous” Behaviour

▶ Methods can be modified in several steps by applying several

deltas in sequence.
▶ The “previous” method behaviour can be accessed by calling
original.

As in previous example:
delta DFee (Int fee); // Implements feature Fee
uses Account;
modifies class AccountImpl {
modifies Int deposit(Int x) {
Int result = x;
if (x >= fee)
result = original(x-fee); // call previous version of deposit method
else
result = original(x); // call previous version of deposit method
return result;
}
}

38 / 54
Mapping Features to Deltas
Problem space: Feature model Solution space: Core + Deltas

Modules
Feature Core
Model Deltas

SPL Configuration

How are they connected? SPL Configuration:

▶ application conditions to associate features and delta modules
▶ temporal delta ordering (partial)
▶ feature attribute value passing to delta modules

39 / 54
Mapping Features to Deltas
SPL Configuration Example

productline Accounts;
features Type, Fee, Overdraft, Check, Save;

delta DType (Type.interest) when Type ;

delta DFee (Fee.amount) when Fee ;

delta DOverdraft after DCheck when Overdraft ;

delta DSave (Type.interest) after DType when Save ;

delta DCheck after DType when Check ;

▶ application condition (ensure suitable feature implementation)

▶ order of delta application (conflict resolution)
▶ feature attribute value passing
40 / 54
Mapping Features to Deltas (cont.)

Application conditions…
▶ Associate deltas with features.
▶ Are boolean formulas over features and feature attributes:
▶ when formula evaluates to true, given delta is applied.
▶ Enable flexible mapping of feature to deltas: 1:1, 1:n, n:1, n:m

Examples:
productline ExampleSPL;
features A, B, C, F;

delta D1 when A; // Mapping feature A to delta D1 (1:1)

delta D2 when !A && (B || (C && F)); // features A, B, C, F to delta D2 (4:1)
delta D3 when C; // Mapping feature C to deltas D3...
delta D4 when C; // ...and D4 (1:2)
delta D5 when F.a >= 0; // Mapping feature attributes to deltas...
delta D6 when F.a < 0;

41 / 54
Delta Application Order

The order in which deltas are applied is important; deltas applied later
in the sequence may depend on elements that have been added (or
removed) earlier. Example:

delta D1;
modifies class C {
removes Unit foo(); // remove method foo from class C
}
delta D2;
modifies class C {
adds Int x=0;
adds Int foo() { ... return x; } // re−add method foo in class C
}

Delta ordering ensures that delta D2 is always applied after D1:

delta D1 when ...;
delta D2 after D1 when ...;

42 / 54
Automated Product Derivation

Traceability of user requirements

Thanks to the SPL configuration, ABS deltas (code) can be traced to
features (requirements).

Automated product derivation

▶ User selects a product.
▶ ABS compiler automatically…
1. Determines the set of desired features,
2. Selects corresponding deltas,
3. Determines a valid order of delta application,
4. Generates source code of product by applying sequence of deltas
to the core (“flattening”),
5. Compiles product to executable format.

43 / 54
Automated Product Derivation Example

Example: generate product P3 based on feature selection FS and

delta sequence DS:

P1

P2
FS, DS
P3
core

..
.

Pn

44 / 54
DOP in Practice: Resolving Feature Interactions

A feature interaction is a situation in which two or more features

exhibit unexpected behavior that does not occur when the features are
used in isolation.

Classic example: doubly linked list

LinkedList

ForwardLink BackwardLink

When both ForwardLink and BackwardLink features are selected, the

list does not work correctly.
45 / 54
Resolving Feature Interactions
Example: Doubly linked list

ForwardLink feature: BackwardLink feature:

delta DForwardLink; delta DBackLink;
modifies class MyList { modifies class MyList {
adds Node first; adds Node last;
adds Unit insertAtEnd(Node n) { adds Unit insertAtBeginning(Node n) {
n.next = first; first = n; n.prev = last; last = n;
} }
} }
modifies class Node { modifies class Node {
adds Node next; adds Node prev;
} }

46 / 54
Feature Interaction Example

After applying both features to a (bare-bones) core program:

class MyList {
Node first; Node last;
Unit insertAtEnd(Node n) {
n.next = first; first = n;
}
Unit insertAtBeginning(Node n) {
n.prev = last; last = n;
}
}
class Node {
Node prev; Node next;
}

▶ When adding an element with method insertAtEnd, the

backward reference prev is not adjusted accordingly and the
reference to last is not set properly in the case the list is empty.
▶ MyList does not behave as intended: the two features interact.

47 / 54
Feature Interaction Example (2)

Corrected behaviour:
class MyList {
Node first; Node last;
Unit insertAtEnd(Node n) {
if (first == null) last = n; else first.prev = n;
n.next = first; first = n;
}
Unit insertAtBeginning(Node n) {
if (last == null) first = n; else last.next = n;
n.prev = last; last = n;
}
}
class Node {
Node prev; Node next;
}

▶ Highlighted code needs to be added to fix the problem.

▶ How to add it?

48 / 54
Feature Interaction Example (3)

Deltas can be used to resolve conflicts among other deltas.

In our example:
▶ Define a third delta DDoubleLinkthat fixes our doubly linked list.
▶ Delta DDoubleLink is only applied when both ForwardLink and
BackwardLink features are selected, as specified in the SPL
configuration:

productline ListPL;
features ForwardLink, BackLink;
delta DForwardLink when ForwardLink;
delta DBackLink when BackLink;
delta DDoubleLink after DForwardLink, DBackLink when ForwardLink && BackLink;

49 / 54
Feature Interaction Example (4)

The conflict-resolving delta DDoubleLink:

delta DDoubleLink;
modifies class MyList {
modifies Unit insertAtEnd(Node n) {
if (first == null) last = n; else first.prev = n;
original(n);
}
modifies Unit insertAtBeginning(Node n) {
if (last == null) first = n; else last.next = n;
original(n);
}
}

50 / 54
 Developing Product Lines with 
Summary: SPLE with ABS
Feature Modules
1:1 Mapping
[1,n]:[1,n] Mapping
Features to Feature
Features to DeltaModules
Modules Core
Feature Modules
Feature Model Delta1

Delta2
Delta Modules

Delta3

Delta...

Feature Selection
As Input

Variant
Feature Selection Composition Mechanism
61

51 / 54
Summary: Delta-Oriented Programming

▶ Feature traceability: Features are traceable between problem

and solution space.

▶ Mapping features to code modules: Flexibility thanks to

application conditions: a delta may implement more than one
feature, but may also implement only fragments of features.

▶ Composition: Delta application order can be controlled explicitly

from within the language.

▶ Conflict resolution: Conflicts, such as feature interactions, can

be easily resolved with conflict-resolving deltas.

52 / 54
References I

Apel, Sven, Don Batory, Christian Kästner, and Gunter Saake (2013).
Feature-Oriented Software Product Lines: Concepts and
Implementation. Springer.
Czarnecki, Krzysztof, Simon Helsen, and Ulrich Eisenecker (2004).
“Staged Configuration Using Feature Models”. In: Software Product
Lines. Springer, pp. 162–164.
Hähnle, Reiner (2013). “The Abstract Behavioral Specification
Language: A Tutorial Introduction”. In: Formal Methods for
Components and Objects. Vol. 7866. LNCS. Springer, pp. 1–37.
Krueger, Charles W. (2002). “Easing the Transition to Software Mass
Customization”. In: Software Product-Family Engineering.
Vol. 2290. LNCS. Springer, pp. 282–293.

53 / 54
References II
Schaefer, Ina, Lorenzo Bettini, Ferruccio Damiani, and Nico Tanzarella
(2010). “Delta-oriented programming of software product lines”. In:
International Software Product Line Conference. SPLC ’10.
Springer, pp. 77–91.
Triando (2015). “Extending the Product Selection Language of ABS
with Product Expressions”. B.Sc. Thesis. Universitas Indonesia.

54 / 54