1. Mathieu
Acher,
Benoit
Combemale,
Olivier
Barais
Model-­‐Based
Variability
Management

2. 2
Research
in
so6ware
engineering.
-­‐ 8
faculty
members
-­‐ 35
researchers
and
engineers
on
projects

3. We’re
hiring!
engineers,
PhD
students,
post-­‐docs
Variability
/
Product
lines
Model-­‐driven
Engineering
Language
Engineering
(e.g.,
DSLs)
Scala
3
3
European
Projects
Industrial
CollaboraCons
Academics
partners

4. Acknowledgments
(la
famille)
Marianela
Ciolfi
Felice
Joao
Bosco
Ferreira
Filho
Guillaume
Bécan
Suresh
Pilay
Sana
Ben
Nasr
(MSc/PhD
students,
University
of
Rennes
1)
Prof.
Philippe
Collet
Prof.
Philippe
Lahire
(University
of
Nice
Sophia
AnWpolis)
Prof.
Robert
B.
France
(Colorado
State
University)
Prof.
Patrick
Heymans
(University
of
Namur)

5. Audience
• No
pre-­‐requisite
background!
• Targeted
Audience
• Academics
or
pracWWoners
• Curious
guys:
e.g.,
PhD
students
or
modellers
unaware
of…
– Variability
and
so6ware
product
lines
(SPLs)
– Variability
modelling
– ConfiguraWon
• MDE
guys:
people
involved
or
interested
in
the
development
of
model
management
tools
– e.g.,
model
composiWon/decomposiWon
• SPL
guys:
advances
that
want
to
learn
new
techniques
5

6. At
the
end
of
the
tutorial…
• You
will
have
an
overview
of
what’s
going
on
in
the
field
of
variability
and
model-­‐based
so6ware
product
line
engineering
• You
will
be
able
to
go
further
with
the
languages
and
modelling
techniques
• so
to
reuse
them
in
pracWcal
or
academic
contexts
• SupporWng
material:
hbps://github.com/FAMILIAR-­‐project/familiar-­‐documentaWon/blob/
master/presentaWons/EC2013/README.md
• slides
of
the
tutorial
• related
arWcles,
• FAMILIAR
scripts,
• CVL
models,
• and
packaged
tools
to
interacWvely
play
with
the
models
during
the
tutorial
6

7. Differences
with
previous
tutorials
at
SPLC’12
/
MODELS’12
• Larger
perspecWve/moWvaWon
• Including
modelling/language/architectural
examples
• Not
only
about
feature
models
• not
only
about
FAMILIAR
• but
new
techniques
for
reverse
engineering
(VaMoS’13)
and
composing
(MODELS’13)
feature
models
will
be
presented
• Model-­‐based
product
line
engineering
• Common
Variability
Language
(CVL)
FAMILIAR
is
now
a
project
not
only
a
language
for
managing
feature
models!
7

8. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
maber
(30’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h45’)
[SOLUTION
FOR
MODEL-­‐BASED
DERIVATION
OF
PRODUCT]
Model-­‐based
variability
engineering:
examples,
support
and
open
issues
(45’)
8
Plan

9. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
maber
(30’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h45’)
[SOLUTION
FOR
MODEL-­‐BASED
DERIVATION
OF
PRODUCT]
Model-­‐based
variability
engineering:
examples,
support
and
open
issues
(45’)
9
Plan

10. 10
So6ware-­‐intensive
systems
come
in
many
variants

11. 11

12. Linux
Kernel

13. Database
Engine

14. Printer
Firmware

15. Features
in
MicrosoS
Office
15

17. 17

18. Variability
“the
ability
of
a
system
to
be
efficiently
extended,
changed,
customized
or
configured
for
use
in
a
parCcular
context”
Mikael
Svahnberg,
Jilles
van
Gurp,
and
Jan
Bosch
(2005)

19. «
A
set
of
programs
is
considered
to
consWtute
a
family,
whenever
it
is
worthwhile
to
study
programs
from
the
set
by
first
studying
the
common
properCes
of
the
set
and
then
determining
the
special
properCes
of
the
individual
family
members
»
David
L.
Parnas
—
‘‘On
the
design
and
development
of
program
families’’
in
TransacCons
on
SoSware
Engineering,
SE-­‐2(1):1–9,
1976
19
aka
Variability

20. Variability
“the
ability
of
a
system
to
be
efficiently
extended,
changed,
customized
or
configured
for
use
in
a
parCcular
context”
Mikael
Svahnberg,
Jilles
van
Gurp,
and
Jan
Bosch
(2005)
20

21. 21
21
Extensible
architectures
(eg
plugins-­‐based)
ConfiguraCon
files
System
Preferences
Configurators
Source
code
Build
systems
Comparison
of
*
Structural
or
behavorial
models
External
Variability
Internal
Variability
Variability
@
run.Cme

22. 22
«
Feature
Model
ExtracWon
from
Large
CollecWons
of
Informal
Product
DescripWons
»
Jean-­‐Marc
Davril,
Edouard
Delfosse,
Negar
Hariri,
Mathieu
Acher,
Jane
Cleland-­‐Huang,
Patrick
Heymans
(ESEC/FSE’13)

23. 23
«
The
Anatomy
of
a
Sales
Configurator:
An
Empirical
Study
of
111
Cases
»
Ebrahim
Khalil
Abbasi,
Arnaud
Hubaux,
Mathieu
Acher,
QuenWn
Boucher,
and
Patrick
Heymans
(CAiSE’13)

24. 24
«
ExtracWon
and
EvoluWon
of
Architectural
Variability
Models
in
Plugin-­‐based
Systems
»
Mathieu
Acher,
Anthony
Cleve,
Philippe
Collet,
Philippe
Merle,
Laurence
Duchien,
Philippe
Lahire
ECSA/SoSyM’13

25. If
you’re
able
to
master
variability…
• Reduce
development
costs
• Reduce
cerWficaWon
costs
• Shorten
Wme-­‐to-­‐market
• But,
are
you
able?
– developing,
verifying,
cerWfying
billions
of
variants
is
challenging!
25

26. Variability = Complexity
ChrisWan
Kästner
slide

27. a
unique
variant
for
every
person
on
this
planet
33
features
opWonal,
independent
ChrisWan
Kästner
slide

28. 320
features
more
variants
than
esWmated
atoms
in
the
universe
opWonal,
independent

29. 2000
features
10000
features
ChrisWan
Kästner
slide

30. 30
Avoid
solving
the
same
problem!
2,
3…n
Cmes
AutomaCon?

31. 31
Unused
flexibility

32. 32
Illegal
variant

33.
Goal:
So6ware
mass
customizaWon
/
AdapWve
and
configurable
systems
Problem:
Variability
=
Complexity
Approach:
Model-­‐based
variability
management
33
Why
managing
Variability
does
(and
will)
maier

34. 34
So6ware-­‐intensive
systems
come
in
many
variants
Model-­‐based
Variability
Management

35.
Modeling
Variability
CommunicaCve
AnalyCc
GeneraCve
35

36. 36

38. 38
Factoring
out
commonaliCes
for
Reuse
[Krueger
et
al.,
1992]
[Jacobson
et
al.,
1997]
Managing
variabiliCes
for
So6ware
Mass
CustomizaCon
[Bass
et
al.,
1998]
[Krueger
et
al.,
2001],
[Pohl
et
al.,
2005]

39. Mobile
3G+ 3G GPS
Maps
Camera
ü
ü
ü
Mobile
3G+ 3G GPS
Maps
Camera
Domain/Variability
Model
ConfiguraCon
SoSware
Generator
Domain
Artefacts
Domain
Engineering
ApplicaCon
Engineering
«
the
investments
required
to
develop
the
reusable
arBfacts
during
domain
engineering,
are
outweighed
by
the
benefits
of
deriving
the
individual
products
during
applica.on
engineering
»
Jan
Bosch
et
al.
(2004)

40. 40
99%
domain
engineering,
1%
applicaCon
engineering?
– specifies
what
you
want
(click,
click,
click)
a
customized
product
is
automaWcally
built
for
you
– Iterate
the
process
for
n
products
Amount
of
effort
Application
Engineering
More Sophisticated
Technology
Domain
Engineering

41. Variability
AbstracCon
Model
(VAM)
ConfiguraCon
(resoluCon
model)
Domain
Artefacts
(e.g.,
models)
SoSware
Generator
(derivaCon
engine)
ü
ü
Variability
RealizaCon
Model
(VRM)

42. 42

43. Configurations
Derivation
Process
Models of
the
“system”
Feature
Model
How to
realize the
variability

44. (another
research
area/applicaWon:
adapWve
systems
aka
dynamic
so6ware
product
lines
Models@run.Wme)
hip://www.kevoree.org
from
Cloud
stack
to
embedded
devices

46. Variability
Handling
in
AUTOSAR
Body
control
Low-­‐end
light-­‐
control
AdapWve-­‐curve
light-­‐control
Feature
Modeling
(Variability
abstracWon)
Generic
Template
(Variability
RealizaWon)
LightType
…
System
constant
Low
End
High
End
Car
1..1
Feature
v.
4.04
(upcoming)
v.
4.03
Low
End
==
1
High
End
==
1
VariaWon
point
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

47. Variability
Handling
in
AUTOSAR
(2)
Feature
Modeling
(Variability
abstracWon)
Generic
Template
(Variability
RealizaWon)
Low
End
High
End
Car
1..1
Body
control
Low-­‐end
light-­‐control

48. VariaCon
Point
Types
• Variability
is
applied
to
different
parts
of
the
metamodel
– AggregaWon,
associaWon,
abribute
value,
property
set
• ResulWng
variability
– OpWonal
component
– OpWonal
port
– OpWonal
connector
– Parameter
variability
Component
Port
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

49. 49
«
Mapping
Features
to
Models:
A
Template
Approach
Based
on
Superimposed
Variants»
Krzysztof
Czarnecki
and
Michal
Antkiewicz
GPCE’05

50. 50
«
Mapping
Features
to
Models:
A
Template
Approach
Based
on
Superimposed
Variants»
Krzysztof
Czarnecki
and
Michal
Antkiewicz
GPCE’05

51. 51
«
Mapping
Features
to
Models:
A
Template
Approach
Based
on
Superimposed
Variants»
Krzysztof
Czarnecki
and
Michal
Antkiewicz
GPCE’05

52. 52
«
Mapping
Features
to
Models:
A
Template
Approach
Based
on
Superimposed
Variants»
Krzysztof
Czarnecki
and
Michal
Antkiewicz
GPCE’05

53. Safe
composiWon?
No!
53
«Verifying
Feature-­‐Based
Model
Templates
Against
Well-­‐Formedness
OCL
Constraints
»
Krzysztof
Czarnecki
Krzysztof
Pietroszek
GPCE’06

54. Ooops
54
«Verifying
Feature-­‐Based
Model
Templates
Against
Well-­‐Formedness
OCL
Constraints
»
Krzysztof
Czarnecki
Krzysztof
Pietroszek
GPCE’06

55. Another
approach
55
«
Reconciling
AutomaWon
and
Flexibility
in
Product
DerivaWon
»
Gilles
Perrouin,
Jacques
Klein,
Nicolas
Guelfi,
Jean-­‐Marc
Jézéquel
SPLC’08

56. 56
«
Reconciling
AutomaWon
and
Flexibility
in
Product
DerivaWon
»
Gilles
Perrouin,
Jacques
Klein,
Nicolas
Guelfi,
Jean-­‐Marc
Jézéquel
SPLC’08
Merging-­‐based
DerivaCon
of
Product

58. Variability
at
the
language
level
58
Variability
in
Metamodeling
• SemanWc
variaWon
point
• DSML
Families
• Knowledge
capitalizaWon
• Language
Engineering
Variability
in
Modeling
Variability
Variability

59. 

 










Engineering
SemanCcs
in
Modeling
Languages
59
Abstract
Syntax
(AS)
Concrete
Syntax
(CS)
Semantics
Domain
(SD)
Mac
Mas
• Variability
in
metamodeling
(DSML
families,
variaWon
point...):
– Abstract
syntax:
staWc
introducWon
(AOM),
inheritance
(OOP)
– Concrete
syntax:
view
point
(OBEO
Designer)
– SemanWcs:
sWll
a
problem!
how
to
define
and
manage
semanBc
variability
(in
the
DSML
and
the
associated
tools)?

60. DSL4
DSL3
DSL2
DSL1
Language
Family
(expresiveness,
semanWc
variaWon
point,
implementaWon
variaWon
point,
viewpoints,
tooling,
etc.)
RM
dsl1
RM
dsl2
RM
dsl3
RM
dsl4
Challenge1:
Modular
Language
Design
Challenge3:
Language
ComposiWon
Challenge2:
Variability
Modeling
«
Variability
Management
in
Modeling
Languages
»
Suresh
Pilay
PhD
thesis
(ongoing)

61. DSL
Variability
model
CVL
Base
model
Generic
&
Standardized
resoluCon
models
Focused
on
a
domain
Execute
CVL
Resolved
models
DescripWon
of
possible
variaWons
in
the
system
Domain
model
of
a
parWcular
family
of
system
SelecWon
of
a
set
of
opWons
in
the
variaWon
model
Family
of
systems
fully
described
in
the
domain
specific
language.
All
regular
DSL
tools
can
be
applied
to
these
models
61
RealizaCon
model
Language
Units
Language
Features
how to realize
the features
Configuration
of languages
Derivation
Process
Languages
«
Variability
Management
Modeling
Languages
»
Suresh
Pilay
PhD
thesis
(ongoing)

63. 63
«
ExtracWon
and
EvoluWon
of
Architectural
Variability
Models
in
Plugin-­‐based
Systems
»
Mathieu
Acher,
Anthony
Cleve,
Philippe
Collet,
Philippe
Merle,
Laurence
Duchien,
Philippe
Lahire
ECSA/SoSyM’13

64. 64
«
ExtracWon
and
EvoluWon
of
Architectural
Variability
Models
in
Plugin-­‐based
Systems
»
Mathieu
Acher,
Anthony
Cleve,
Philippe
Collet,
Philippe
Merle,
Laurence
Duchien,
Philippe
Lahire
ECSA/SoSyM’13
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-
Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascati
http requires MMTuscany
FM1
Variability
Model

65. 65
Variability
Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-
Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascati
http requires MMTuscany
FM1
FraSCAC
Architecture
Set
of
Safe
Variants
authorized
by
FraSCAC
Scope
is
too
large

66. Illegal
Variant
66

67. 67
FraSCAC
Architecture
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-
Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascati
http requires MMTuscany
FM1
Feature
Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-
Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascati
http requires MMTuscany
FM1
ConfiguraCon
Derived
FraSCAC
Architecture

68. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
maber
(30’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h45’)
[SOLUTION
FOR
MODEL-­‐BASED
DERIVATION
OF
PRODUCT]
Model-­‐based
variability
engineering:
examples,
support
and
open
issues
(45’)
68
Plan

69. Variability
Model
ConfiguraCon
Domain
Artefacts
(e.g.,
source
code)
SoSware
Generator
Modeling
variability
is
crucial
ü
ü

70. 70
Unused
flexibility

71. 71
Illegal
variant

72. 72
72
Extensible
architectures
(plugins-­‐based)
ConfiguraCon
files
System
Preferences
Configurators
Source
code
Build
systems
Comparison
of
Product

73.
Variability
AbstracCon
Model
(VAM)
CommunicaCve
AnalyCc
GeneraCve
73
not, and, or, implies

74. Variability
Model
Feature
Model:
de
facto
standard
• Research
– 2500+
citaWons
of
[Kang
et
al.,
1990]
on
Google
Scholar
– Central
to
many
generaWve
approaches
• at
requirements
or
code
level
– Tools
&
Languages
(GUIDSL/FeatureIDE,
SPLOT,
FaMa,
etc.)
• Industry
– Tools
(Gears,
pure::variants),
• Common
Variability
Language
(CVL)
74

76. Feature
Models
76

77. Feature
Models
(Background)
77
Hierarchy:
rooted
tree
Variability:
• mandatory,
• opWonal,
• Groups:
exclusive
or
inclusive
features
• Cross-­‐tree
constraints
Optional
Mandatory
Xor-Group
Or-Group

78. 78
Hierarchy
+
Variability
=
set
of
valid
configuraCons
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondiWoning,
FrontFogLights}
configuraCon
=
set
of
features
selected
Optional
Mandatory
Xor-Group
Or-Group

79. 79
Hierarchy
+
Variability
=
set
of
valid
configuraCons
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondiWoning}
configuraCon
=
set
of
features
selected
Optional
Mandatory
Xor-Group
Or-Group

80. 80
Hierarchy
+
Variability
=
set
of
valid
configuraCons
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondiWoning,
AutomaWcHeadLights}
configuraCon
=
set
of
features
selected
ü
ü
ü
ü
ü
ü

81. 81
Hierarchy
+
Variability
=
set
of
valid
configuraCons
Optional
Mandatory
Xor-Group
Or-Group
{AirCondiWoning,
FrontFogLights}
{AutomaWcHeadLights,
AirCondiWoning,
FrontFogLights}
{AutomaWcHeadLights,
FrontFogLights,
AirCondiWoningFrontAndRear}
{AirCondiWoningFrontAndRear}
{AirCondiWoning}
{AirCondiWoningFrontAndRear,
FrontFogLights}
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing}
X

82. Feature
Models
82

84. (FeAture
Model
scrIpt
Language
for
manIpulaWon
and
AutomaWc
Reasoning)
not, and, or, implies
φTVL
DIMACS
hip://familiar-­‐project.github.com/
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
A
Domain-­‐Specific
Language
for
Large-­‐
Scale
Management
of
Feature
Models
»
Science
of
Computer
Programming
(SCP),
2013

85. 85
Optional
Mandatory
Xor-Group
Or-Group

86. 86
Optional
Mandatory
Xor-Group
Or-Group

87. 87
Optional
Mandatory
Xor-Group
Or-Group
{AirCondiWoning,
FrontFogLights}
{AutomaWcHeadLights,
AirCondiWoning,
FrontFogLights}
{AutomaWcHeadLights,
FrontFogLights,
AirCondiWoningFrontAndRear}
{AirCondiWoningFrontAndRear}
{AirCondiWoning}
{AirCondiWoningFrontAndRear,
FrontFogLights}
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing}
X

88. 88

90. (FeAture
Model
scrIpt
Language
for
manIpulaWon
and
AutomaWc
Reasoning)
imporCng,
exporCng,
composing,
decomposing,
ediCng,
configuring,
reverse
engineering,
compuCng
"diffs",
refactoring,
tesCng,
and
reasoning
about
(mulCple)
variability
models
not, and, or, implies
φTVL
DIMACS
hip://familiar-­‐project.github.com/
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
A
Domain-­‐Specific
Language
for
Large-­‐
Scale
Management
of
Feature
Models
»
Science
of
Computer
Programming
(SCP),
2013

91. #1
Automated
Analysis
91

92. #2
MulCple
Feature
Models
92

93. 93
93
MulC-­‐*
variability
*systems,
perspecCves,
or
stakeholders

94. • #1
Automated
analysis
– Aka
support
to
beber
understand
and
play
with
your
feature
model
(TVL
model)
• #2
Managing
mulCple
feature
models
– Composing
/
Decomposing
/
Diff
and
Reasoning
about
their
relaWonships
– Combining
these
operators
94
Two
Key
Requirements

95. language
and
environment
And-Group
Optional
Mandatory
Xor-Group
Or-Group
constraints
……..
DirectX
V10 V10.1 v11
Outputs
VIVO DVI HDMI
S-Video Composite
VGA
GraphicCard And-Group
Optional
Mandatory
Xor-Group
Or-Group
TV output
constraints
VGA excludes TV output
HDMI implies v10.1 or v11
constraints
……..
constraints
……..
constraints
……..
//
foo.fml
fm1
=
FM
(“foo1.tvl”)
fm2
=
FM
(“foo2.m”)
fm3
=
merge
intersecCon
{
fm1
fm2
}
c3
=
counCng
fm3
renameFeature
fm3.TV
as
“OutputTV”
fm5
=
aggregate
{
fm3
FM
(“foo4.xml”)
}
assert
(isValid
fm5)
fm6
=
slice
fm5
including
fm5.TV.*
export
fm6
True/False
8759
“OutputTV”,
“TV”
Interoperability
Language
faciliCes
Environment

96. 96
Interoperability
fm1
=
FM(“foo.tvl”)
fm2
=
FM
(“foo.m”)
serialize
fm4
into
SPLOT
serialize
fm1
into
featureide
fm3
=
FM
(“foo.xmi”)
fm4
=
FM
(A
:
B
….)
De/ComposiCon
merge
diff
intersecWon
sunion
aggregate
map
unmap
extract
slicing
EdiCng
renameFeature
removeFeature
accessors
copy
Reasoning
counWng
configs
isValid
deads
cores
falseOpWonals
cleanup
configuraWon
select
deselect
asFM
compare
setOpWonal
setMandatory
setAlternaWves
setOr
Language
FaciliCes
fm1.*
fm1.B
modular
mechanisms
restricted
set
of
types
iterator/condiWonal
asserWon
insert
features

97. Hello
World
97
helloworld.fml
Optional
Mandatory
Xor-Group
Or-Group

98. Typed
language
• Domain-­‐specific
types
– Feature
Model,
– ConfiguraWon,
– Feature,
– Constraint
• Other
types
include
– Set
– String
– Boolean,
– Enum,
– Integer
and
Real.
• A
set
of
operaWons,
called
operators,
are
defined
for
a
given
type.
98
basics2.fml

99. Typed
language
99
basics2.fml

100. Typed
language
100
basics2.fml
Optional
Mandatory
Xor-Group
Or-Group

101. ImporCng/ExporCng
feature
models
101
FAMILIAR
S2T2
TVL
feature-model-synthesis
(visual configurator)
(language)
(language)FaMa
Internal
notaWon
or
by
“filename
extensions”
basics3.fml

102. Feature
Accessors
(1)
102
6Accessors.fml
Optional
Mandatory
Xor-Group
Or-Group

103. Other
constructs
103
6Accessors2.fml
Optional
Mandatory
Xor-Group
Or-Group

104. ConfiguraCon
104
conf.fml
Optional
Mandatory
Xor-Group
Or-Group

105. 105
φ FM
A
^
A
ó
B
^
C
=>
A
^
D
=>
A
Optional
Mandatory
Xor-Group
Or-Group

106. OperaCons
for
Feature
Models
(1)
106
φ
operatorsFM.fml
Optional
Mandatory
Xor-Group
Or-Group

107. OperaCons
for
Feature
Models
(2)
107
φ
operatorsFM2.fml
Optional
Mandatory
Xor-Group
Or-Group

108. OperaCons
for
Feature
Models
(3)
108
operatorsFM3.fml
Optional
Mandatory
Xor-Group
Or-Group

109.
SoC
support
=
ComposiCon/DecomposiCon
for
managing
large,
complex
and
mulCple
feature
models
FORM
1998,
Tun
et
al.
2009
(SPLC),
Hartmann
2008
(SPLC),
Lee
et
al.
2010,
Czarnecki
2005,
Reiser
et
al.
2007
(RE
journal),
Hartmann
et
al.
2009
(SPLC),
Thuem
et
al.
2009
(ICSE),
Classen
et
al.
2009
(SPLC),
Mendonca
et
al.
2010
(SCP),
Dunghana
et
al.
2010,
Hubaux
et
al.
2011
(SoSyM),
Zaid
et
al.
2010
(ER),
She
et
al.,
2011
(ICSE),
etc.

110. Composing
Feature
Models
(1)
110
aggregateBasics.fml
Optional
Mandatory
Xor-Group
Or-Group

111. Composing
Feature
Models
(2)
111
aggregate1.fml
Previous
version
Optional
Mandatory
Xor-Group
Or-Group

112. Composing
Feature
Models
(3)
112
mergeMI.fml
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
Comparing
Approaches
for
ImplemenWng
Feature
Model
ComposiWon
»
ECMFA’10

113. see
also
Thuem,
Kastner
and
Batory,
ICSE’09
Comparing
Feature
Models
113
compare.fml
Optional
Mandatory
Xor-Group
Or-Group

115. Merge
IntersecCon:
Available
Suppliers
115
∩
∩
A
customer
has
some
requirements
Suppliers?
Products?

116. In
FAMILIAR
116
suppliersExample0.fml

117. Merge
Union:
Availability
Checking
117
Can
suppliers
provide
all
products?
Yes!
“compare”
∩
Optional
Mandatory
Xor-Group
Or-Group

118. In
FAMILIAR
118
suppliersExample.fml

119. Merging
operaCon:
implementaCon
issues
119
How
to
synthesise
a
feature
model
that
represents
the
union
of
input
sets
of
configuraCons?
Optional
Mandatory
Xor-Group
Or-Group
T2
MRI
Medical Image
HeaderAnonymized
T1
DICOM
Header excludes DICOM
Header implies Anonymized
Anonymized v Header v ~DICOM v ~T1 v ~T2
Anonymized v Header v DICOM v ~T1 v ~T2

120. 120
Merging
operaCon:
semanCc
issues
(2)
φ
Union
IntersecWon
Diff
How
to
synthesise
a
feature
model
that
represents
the
union
of
input
sets
of
configuraCons?

121. Merging
operaCon:
algorithm
121
φ1
φ2
φ3
φ123
merged
proposiWonal
formula
T2
MRI
Medical Image
HeaderAnonymized
T1
DICOM
merged
hierarchy
+
Set
mandatory
features
Detect
Xor
and
Or-­‐groups
Compute
“implies/excludes”
constraints
How
to
synthesise
a
feature
model
that
represents
the
union
of
input
sets
of
configuraCons?
see
also
[Czarnecki
SPLC’07
or
SPLC’12]
Optional
Mandatory
Xor-Group
Or-Group

122. Merging
operaCon:
back
to
hierarchy
122
mergeNonPC.fml
>
configs
fm4
res12:
(SET)
{{C;A};{A;B};{A};{A;B;C}}
?
Mathieu
Acher,
Benoit
Combemale,
Philippe
Collet,
Olivier
Barais,
Philippe
Lahire,
Robert
B.
France
«
Composing
your
ComposiWons
of
Variability
Models
»
MODELS’13
Optional
Mandatory
Xor-Group
Or-Group

123. see
also
[Acher
et
al.,
ECMFA’10
/
MODELS’13]
– Well-­‐defined
semanWcs
– Guarantee
semanWcs
properWes
by
construcWon
– More
compact
feature
models
than
reference-­‐based
techniques
[Schobbens
et
al.,
2007],
[Hartmann
et
al.,
2007]
• Easier
to
understand
• Easier
to
analyze
(e.g.,
compare
with
another)
– Applicable
to
any
proposiWonal
feature
models
• Full
support
of
proposiWonal
constraints
• Different
hierarchies
[Van
Den
Broek
et
al.,
SPLC’2010/2012]
– SyntacWcal
strategies
fail
[Alves
et
al.,
2006],
[Segura
et
al.,
2007]
123
Related
Works

125. 125
Problem:
mulCple
„car
models“

126. 126
Problem:
mulCple
„car
models“

127. 127
Problem:
mulCple
„car
models“

128. 128
Problem:
mulCple
„car
models“
#2
–
boiom-­‐up:
elaborate
a
feature
model
for
each
model
line
and
merge
them
Two
modeling
approaches
#1
–
top-­‐down:
specify
constraints
(e.g.,
excludes)
of
all
model
lines
upfront

129. 129
#1
top-­‐down

130. 130
#1
boiom-­‐up
FM_1
FM_2
FM_3
FM_r
merge

131. 131
#1
boiom-­‐up
(FAMILIAR)
FM_1
FM_2
FM_3
FM_r
merge
audiMerge.fml

133. 133
Building
“views”
of
a
feature
model

134. • Problem:
given
a
feature
model,
how
to
decompose
it
into
smaller
feature
models?
• SemanWcs?
– What’s
the
hierarchy
– What’s
the
set
of
configuraWons?
134
Building
“views”
of
a
feature
model

135. A
first
try
A3 => P1
P2 => A5
R
A2
A5 A6
A1
A3 A4
A
fm0
P3P2P1
P
P1 => P2
A2
A5 A6
A1
A3 A4
A
fmExtraction1
A2
A5 A6
A1
A3 A4
A
fmExtraction2
A3 => A5
A4 => A6
Problem:
You
can
select
A3
without
A5
Hierarchy
and
ConfiguraCon
maier!
135

136. Slicing
Operator
W
constraints
E implies D
R implies E
D excludes F
S implies (F and not E)
P
R S
fm1
AV
T U
B C D
E F
Optional
Mandatory
Xor-Group
Or-Group
T
S E D
constraints
E implies D
D implies E
slicing
criterion
:
an
arbitrary
set
of
features,
relevant
for
a
feature
model
user
slice
:
a
new
feature
model,
represenWng
a
projected
set
of
configuraWons
136

137. Slicing
operator:
going
into
details
projected
set
of
configuraCons
137
fm1
=
{
{A,B,C,D,E,P,R,T,U,W},
{A,B,C,F,P,S,T,U,W},
{A,B,C,D,E,P,R,T,W},
{A,B,C,F,P,S,T,V,W},
{A,B,C,F,P,S,T,U,V,W},
{A,B,C,F,P,S,T,W},
{A,B,C,D,E,P,R,T,V,W},
}
fm1
=
{
{A,B,C,D,E,P,R,T,U,W},
{A,B,C,F,P,S,T,U,W},
{A,B,C,D,E,P,R,T,W},
{A,B,C,F,P,S,T,V,W},
{A,B,C,F,P,S,T,U,V,W},
{A,B,C,F,P,S,T,W},
{A,B,C,D,E,P,R,T,V,W},
}
fm1p
=
{
{D,E,T},
{S,T},
{D,E,T},
{S,T},
{S,T},
{S,T},
{D,E,T}
}
fm1p
=
{
{D,E,T},
{S,T},
}
W
constraints
E implies D
R implies E
D excludes F
S implies (F andnot E)
P
R S
fm1
AV
T U
B C D
E F
Optional
Mandatory
Xor-Group
Or-Group

138. +
T
S E D
constraints
E implies D
D implies E
φs1
existenBal
quanBficaBon
of
features
not
included
in
the
slicing
criterion
138
fm1p
=
{
{D,E,T},
{S,T}
}
Slicing
operator:
going
into
details
synthesizing
the
corresponding
feature
model
S
E
D
T
W
constraints
E implies D
R implies E
D excludes F
S implies (F andnot E)
P
R S
fm1
AV
T U
B C D
E F
φ1
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
SeparaWon
of
Concerns
in
Feature
Modeling:
Support
and
ApplicaWons
»
AOSD’12
Optional
Mandatory
Xor-Group
Or-Group

139. T
S E D
constraints
E implies D
D implies E
139
Slicing
operator
with
FAMILIAR
(1)
W
constraints
E implies D
R implies E
D excludes F
S implies (F andnot E)
P
R S
fm1
AV
T U
B C D
E F
slicingOp2.fml
Optional
Mandatory
Xor-Group
Or-Group

140. 140
Slicing
with
FAMILIAR
(2)
slicingOp.fml

141. From
marke.ng,
customers,
product
management
From
exis.ng
so@ware
assets
(technical
variability)
Metzger,
Heymans
et
al.
“DisambiguaBng
the
DocumentaBon
of
Variability
in
Sofware
Product
Lines:
A
SeparaBon
of
Concerns,
FormalizaBon
and
Automated
Analysis“
(RE’07)

142. V1 ⬄ f1
V2 ⬄ f2
V3 ⬄ f3
From
marke.ng,
customers,
product
management
From
exis.ng
so@ware
assets
realizability
usefulness
Optional
Mandatory
Xor-Group
Or-Group

143. Realizability
checking
aggregate
{{V1,V3,V2,VP1},
{V1,VP1},
{V3,VP1},
{VP1}}
merge
diff
(“unrealizable
products”
φ
1
slice
(“realizable
part”)
2
3 compare
4
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
SeparaWon
of
Concerns
in
Feature
Modeling:
Support
and
ApplicaWons
»
AOSD’12
Optional
Mandatory
Xor-Group
Or-Group

144. With
FAMILIAR
144
realizibility.fml

146. 146
RevisiCng
Merge:
Aggregate
+
Slice
Optional
Mandatory
Xor-Group
Or-Group

147. 147
RevisiCng
Aggregate,
Merge
and
Slice:
mergeWithAggregateMI.fml
Mathieu
Acher,
Benoit
Combemale,
Philippe
Collet,
Olivier
Barais,
Philippe
Lahire,
Robert
B.
France
«
Composing
your
ComposiWons
of
Variability
Models
»
MODELS’13
Optional
Mandatory
Xor-Group
Or-Group

148. 148
Mathieu
Acher,
Benoit
Combemale,
Philippe
Collet,
Olivier
Barais,
Philippe
Lahire,
Robert
B.
France
«
Composing
your
ComposiWons
of
Variability
Models
»
MODELS’13

149. 149
φ FM
Feature
Model
Synthesis
Problem
[Czarnecki
et
al.,
SPLC’07]
[She
et
al.,
ICSE’11]
[Andersen
et
al.,
SPLC’12]
A
^
A
ó
B
^
C
=>
A
^
D
=>
A

150. φ
« How to synthesise an
accurate (w.r.t. the set of constraints/configurations)
meaningful (maintainable by a user), and
unique
feature model? »
hip://familiar-­‐project.github.com/

151. φ(SAT solvers or
Binary Decision Diagrams)
The
knowledge
can
be:
inconsistent
(e.g.,
root
feature
specified
is
not
possible)
consistent
and
incomplete
(i.e.,
synthesis
algorithm
needs
addiWonal
informaWon)
consistent,
«
parCal
»
(e.g.,
not
all
the
hierarchy
is
specified)
and
actually
complete
Mathieu
Acher,
Patrick
Heymans,
Anthony
Cleve,
Jean-­‐Luc
Hainaut,
Benoit
Baudry
«
Support
for
Reverse
Engineering
and
Maintaining
Feature
Models
»
VaMoS’13

152. #1
Reverse
Engineering
Scenarios
• [Haslinger
et
al.,
WCRE’11],
[Acher
et
al.,
VaMoS’12]
φ
V
DAd OT M KAe CP R S
C requires T
Ae requires T
S equals M
V
DAd OT KAe SP R M
C requires T
S equals M
C
0..1

153. #2
Refactoring
• [Alves
et
al.,
GPCE’06],
[Thuem
et
al.,
ICSE’09]
φ
V
DAd OT M KAe CP R S
C requires T
Ae requires T
S equals M

154. #3
Re-­‐Engineering
Feature
Models
of
repository
• For
each
FM
we
execute
the
following
FAMILIAR
script…
• …
And
we
«compare»
syntacWcally
fm1
and
fm2
• semanWcal
comparison
is
not
needed:
we
know
that
they
are
refactoring
by
construcWon
(good
test
case
though
;-­‐))
• Results:
– 147
synthesised
FMs
(69
%)
were
exactly
the
same
as
input
FMs
;
– 40
synthesised
FMs
(19%)
were
correcWons
of
input
FMs
;
– 24
synthesised
FMs
(12%)
were
different
(knowledge
needed)
• another
set
of
cross-­‐tree
constraints
was
synthesised.
• feature
group
conflicts
in
six
cases
SpecificaCon
of
the
hierarchy
is
the
main
issue
φ

155. φ
FAMILIAR
« Give me a formula
and some knowledge,
I will synthesise
an accurate,
meaningful,
unique
feature model »
#1
Breathing
knowledge
into
feature
model
synthesis
formal
specificaWon
(consistency
and
completeness)
concrete
syntax
and
tooling
suport
#2
PracCcal
applicaCons
reverse
engineering,
refactoring/re-­‐engineering
of
feature
models
hip://familiar-­‐project.github.com/
Automated
support
is
highly
needed
(ongoing
work)

156. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
maber
(30’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h45’)
[SOLUTION
FOR
MODEL-­‐BASED
DERIVATION
OF
PRODUCT]
Model-­‐based
variability
engineering:
examples,
support
and
open
issues
(45’)
156
Plan

157. Variability
AbstracCon
Model
(VAM)
ConfiguraCon
(resoluCon
model)
Domain
Artefacts
(e.g.,
models)
SoSware
Generator
(derivaCon
engine)
ü
ü
Variability
RealizaCon
Model
(VRM)

158. Configurations
Derivation
Process
Models of
the
“system”
Feature
Model
How to
realize the
variability

159. Printer
´Blockª
mainSupply:MainPower1
Attributes
Operations
powerCtrl
emgSupply:EmgPower1
Attributes
threshold:int
Operations
powerCtrl
inputSection1
highSpeedConnector1
Attributes
Operations
MainPowerCtrl EmgPowerCtrl
MainPower
´Blockª
Values
Operations
powerCtrl
EmgPower
´Blockª
Values
threshold:int
powerCtrl
VariaCon
Points
over
base
model
:ObjectExistence
:SlotValueAssignment
CVL variation points
SYSML (base model) elements
:ObjectExistence
:ObjectExistence
§ Variability
in
this
example:
 Part
EmergencySupply
is
opWonal
 Part
HighSpeedConnector
is
opWonal
 Port
EmgPowerCtrl
on
block
Printer
is
opWonal
 Value
of
abribute
threshold
in
block
EmergencyPower
is
variable
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

160. Printer
´Blockª
mainSupply:MainPower1
Attributes
Operations
powerCtrl
emgSupply:EmgPower1
Attributes
threshold:int
Operations
powerCtrl
inputSection1
highSpeedConnector1
Attributes
Operations
MainPowerCtrl EmgPowerCtrl
MainPower
´Blockª
Values
Operations
powerCtrl
EmgPower
´Blockª
Values
threshold:int
powerCtrl
(Aiributed)
Feature
Model
Printer
EmergencyPower
threshold:Int
Variation
points
HighSpeed
&
threshold>100

EmergencyPower
HighSpeed
:ObjectExistence
:SlotValueAssignment
:ObjectExistence
:ObjectExistence
Based
Model
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

161. Variability
RealizaCon
Layer
VariaCon
points
in
CVL
• VariaWon
Points
refer
to
Base
objects
• VariaWon
Points
define
the
base
model
modificaWons
precisely
• There
are
different
kinds
of
VariaWon
Points
– Existence
(object
or
link)
– Value
assignment
– SubsWtuWon
– Opaque
variaWon
point
– Configurable
Unit
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

162. Derivation of Traffic Lights
Models
Joao
Bosco
Ferreira
Filho
(PhD
student)

163. Traffic Lights

164. . Traffic Lights' behaviour can be modelled using Finite
State Machines
Traffic Lights FSM

165. Traffic Lights FSM
OBJECTIVE:
Produce the finite state machine associated with
each traffic light configuration
. Simplification:
- Green Light
- Red Light
- Yellow Light

166. Base model
. Define the DSL:
1. Create an Ecore modelling project
2. Define the metamodel
3. Generate the model, the edit and the editor code
4. Export them as plugins

167. DSL metamodel

168. Base model
. Create the base model:
1. Create a Modelling project
2. Create a new model in the DSL

169. Base model
. Create the base model:
1. Create a Modelling project
2. Create a new model in the DSL

170. CVL model
. Create the CVL model:
1. Create a new CVL model in the modelling project.
Select VPackage as the Model object
2. Right click on the project, select Viewpoints selection.
Check the three of them
3. Define the VAM, Resolution model and VRM

171. VAM

172. Resolution model

173. Resolution model

174. VRM

175. VRM

176. Product derivation

177. Derived FSM

178. Visualisation of products in a
web configurator
Marianela Ciolfi Felice
(MSc student)

180. Marks
&
Spencer
web
configurator

181. § High visual quality
§ Coherence and stability
§ Interactiveness
§ Performance
§ Automatic and comprehensive
update method
Marianela Ciolfi Felice and Joao Bosco Ferreira Filho and Mathieu Acher and Arnaud
Blouin and Olivier Barais « Interactive Visualisation of Products in Online Configurators:
A Case Study for Variability Modelling Technologies » MAPLESCALE’13 (to appear)

182. Anticipating all possible
combinations
§ 10 configuration options
§ 10 possible values for each of
them
10.000.000.000 combinations!
Composing the
visualisation

183. PRODUCT CONFIGURATION VISUAL REPRESENTATION
Models
HTML
jpg,
png,
...,
files
SVG
files
Javascript
3D
models
Feature
models

184. Configurations
Derivation
Process
Visual
representation
of a product
Feature
Model
How to
realize the
variability
Visual
elements

185. . Simplification:
- Fabric
- Collar
- Pocket (optional)
- Handkerchief (optional)
Shirts web configurator

186. Shirts web configurator
OBJECTIVE:
Produce the visual representation associated with
each shirt configuration
. Simplification:
- Fabric
- Collar
- Pocket (optional)
- Handkerchief (optional)

187. Feature model
- Implicit boolean attribute existence
- No constraints

188. Base model
. Define the DSL:
1. Create an Ecore modelling project
2. Define the metamodel
3. Generate the model, the edit and the editor code
4. Export them as a plugin

189. DSL metamodel

190. Base model
. Create the base model:
1. Create a Modelling project
2. Create a new model in the DSL

191. Base model
. Create the base model:
1. Create a Modelling project
2. Create a new model in the DSL

192. CVL model
. Create the CVL model:
1. Create a new CVL model in the modelling project. Select VPackage as the Model
object
2. Right click on the project. Select Viewpoints selection. Check the three of them
3. Define the VAM, Resolution model and VRM

193. VAM

194. VAM

195. VAM
Suggestion:
Set the choices' default resolution
to:
- True for mandatory features
- False for optional features

196. Resolution model

197. Resolution model

198. VRM

199. VRM

200. Product derivation

201. Product derivation

202. Summary:
Variability
Model
Management
202
202
202

203. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
maber
(30’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h45’)
[SOLUTION
FOR
MODEL-­‐BASED
DERIVATION
OF
PRODUCT]
Model-­‐based
variability
engineering:
examples,
support
and
open
issues
(45’)
203
Key
Insights

204. (ongoing)
Comprehensive
model-­‐based
product
line
support
Reverse
engineering
Automated
Analysis
Languages,
API/DSLs
EvaluaCon
(European
projects,
long-­‐term
collaboraCon
with
Thales,
open
source
systems)
204
204

205.
?
205