Feature Model Management: Smart Operations and Language Support The tutorial has been presented at MODELS'13 conference: http://models2013.lcc.uma.es/tutorials.html#TT7

1. Philippe
Collet,
Philippe
Lahire,
Mathieu
Acher,
Robert
France
Feature
Model
Management:
Smart
Opera7ons
and
Language
Support

2. Acknowledgments
Simon
Urli
(PhD
student,
Université
Nice
Sophia
An@polis)
Marianela
Ciolfi
Felice,
Joao
Bosco
Ferreira
Filho,
Guillaume
Bécan,
Suresh
Pilay
,
Sana
Ben
Nasr
(MSc/PhD
students,
University
of
Rennes
1)
Ass.
Prof.
Olivier
Barais,
Ass.
Prof.
Benoit
Combemale
(University
of
Rennes
1)
Prof.
Patrick
Heymans
(University
of
Namur)

3. Audience
• No
pre-­‐requisite
background!
• Targeted
Audience
• Academics
or
prac@@oners
• Curious
guys:
e.g.,
PhD
students
or
modellers
unaware
of…
– Variability
and
soXware
product
lines
(SPLs)
– Variability
modelling
– Configura@on
• MDE
guys:
people
involved
or
interested
in
the
development
of
model
management
tools
– e.g.,
model
composi@on/decomposi@on
• SPL
guys:
advances
that
want
to
learn
new
techniques
3

4. At
the
end
of
the
tutorial…
• You
will
have
an
overview
of
what’s
going
on
in
the
field
of
variability
and
model-­‐based
soXware
product
line
engineering
• You
will
be
able
to
go
further
with
the
languages
and
modelling
techniques
• so
to
reuse
them
in
prac@cal
or
academic
contexts
• Suppor@ng
material:
h^ps://github.com/FAMILIAR-­‐project/familiar-­‐documenta@on/blob/
master/presenta@ons/MODELS2013/README.md
• slides
of
the
tutorial
• related
ar@cles,
• FAMILIAR
scripts,
• and
packaged
tools
to
interac@vely
play
with
the
models
during
the
tutorial
4

5. Differences
with
previous
tutorials
at
SPLC’12
/
MODELS’12
• Larger
perspec@ve/mo@va@on
• Including
modelling/architectural
examples
&
applica@ons
• Focus
on
FAMILIAR
support
• More
details
on
smart
opera@ons
• New
techniques
for
• reverse
engineering
(VaMoS’13)
and
• composing
(MODELS’13)
feature
models
FAMILIAR
is
now
a
project
not
only
a
language
for
managing
feature
models!
5

6. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
ma^er
(45’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h30’)
[APPLICATION
FOR
MODEL-­‐BASED
SPL
ENGINEERING]
Model-­‐based
variability
engineering:
applica@ons,
advanced
topics,
support
(45’)
6
Plan

7. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
ma^er
(45’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h30’)
[APPLICATION
FOR
MODEL-­‐BASED
SPL
ENGINEERING]
Model-­‐based
variability
engineering:
applica@ons,
advanced
topics,
support
(45’)
7
Plan

8. Everybody
raise
your
phone!
8

9. 9
SoXware-­‐intensive
systems
come
in
many
variants

10. 10

11. Linux
Kernel

12. Database
Engine

13. Printer
Firmware

14. Features
in
MicrosoN
Office
14

16. 16

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

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

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

20. 20
«
Feature
Model
Extrac@on
from
Large
Collec@ons
of
Informal
Product
Descrip@ons
»
Jean-­‐Marc
Davril,
Edouard
Delfosse,
Negar
Hariri,
Mathieu
Acher,
Jane
Cleland-­‐Huang,
Patrick
Heymans
(ESEC/FSE’13)

21. 300+
Products
Comparison
Matrices
in
Wikipedia
«
From
Comparison
Matrix
to
Variability
Model:
The
Wikipedia
Case
Study
»
Nicolas
Sannier,
Mathieu
Acher,
and
Benoit
Baudry
(ASE’2013)

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

23. 23
«
Extrac@on
and
Evolu@on
of
Architectural
Variability
Models
in
Plugin-­‐based
Systems
»
Mathieu
Acher,
Anthony
Cleve,
Philippe
Collet,
Philippe
Merle,
Laurence
Duchien,
Philippe
Lahire
ECSA/SoSyM’13

24. If
you’re
able
to
master
variability…
• Reduce
development
costs
• Reduce
cer@fica@on
costs
• Shorten
@me-­‐to-­‐market
• But,
are
you
able?
– developing,
verifying,
cer@fying
billions
of
variants
is
challenging!
24

25. Variability = Complexity
Chris@an
Kästner
slide

26. a
unique
variant
for
every
person
on
this
planet
33
features
op@onal,
independent
Chris@an
Kästner
slide

27. 320
features
more
variants
than
es@mated
atoms
in
the
universe
op@onal,
independent

28. 2000
features
10000
features
Chris@an
Kästner
slide

29. 29
Avoid
solving
the
same
problem!
2,
3…n
7mes
Automa7on?

30. 30
Unused
flexibility

31. 31
Illegal
variant

32.
Goal:
SoXware
mass
customiza@on
/
Adap@ve
and
configurable
systems
Problem:
Variability
=
Complexity
Approach:
Model-­‐based
variability
management
32
Why
managing
Variability
does
(and
will)
maker

33. 33
SoXware-­‐intensive
systems
come
in
many
variants
Model-­‐based
Variability
Management

34.
Modeling
Variability
Communica7ve
Analy7c
Genera7ve
34

36. 36
Factoring
out
commonali7es
for
Reuse
[Krueger
et
al.,
1992]
[Jacobson
et
al.,
1997]
Managing
variabili7es
for
SoXware
Mass
Customiza7on
[Bass
et
al.,
1998]
[Krueger
et
al.,
2001],
[Pohl
et
al.,
2005]

37. Mobile
3G+ 3G GPS
Maps
Camera
ü
ü
ü
Mobile
3G+ 3G GPS
Maps
Camera
Domain/Variability
Model
Configura7on
SoNware
Generator
Domain
Artefacts
Domain
Engineering
Applica7on
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)

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

39. Variability
Abstrac7on
Model
(VAM)
Configura7on
(resolu7on
model)
Domain
Artefacts
(e.g.,
models)
SoNware
Generator
(deriva7on
engine)
ü
ü
Variability
Realiza7on
Model
(VRM)

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

42. Variability
Handling
in
AUTOSAR
Body
control
Low-­‐end
light-­‐
control
Adap@ve-­‐curve
light-­‐control
Feature
Modeling
(Variability
abstrac@on)
Generic
Template
(Variability
Realiza@on)
LightType
…
System
constant
Low
End
High
End
Car
1..1
Feature
v.
4.04
(upcoming)
v.
4.03
Low
End
==
1
High
End
==
1
Varia@on
point
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

43. Variability
Handling
in
AUTOSAR
(2)
Feature
Modeling
(Variability
abstrac@on)
Generic
Template
(Variability
Realiza@on)
Low
End
High
End
Car
1..1
Body
control
Low-­‐end
light-­‐control

44. Varia7on
Point
Types
• Variability
is
applied
to
different
parts
of
the
metamodel
– Aggrega@on,
associa@on,
a^ribute
value,
property
set
• Resul@ng
variability
– Op@onal
component
– Op@onal
port
– Op@onal
connector
– Parameter
variability
Component
Port
Adapted
from
the
CVL
tutorial
at
SPLC’12
by
Oystein
Haugen,
Andrezj
Wasowski,
Krzysztof
Czarnecki

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

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

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

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

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

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

52. 52
«
Extrac@on
and
Evolu@on
of
Architectural
Variability
Models
in
Plugin-­‐based
Systems
»
Mathieu
Acher,
Anthony
Cleve,
Philippe
Collet,
Philippe
Merle,
Laurence
Duchien,
Philippe
Lahire
ECSA/SoSyM’13

53. 53
«
Extrac@on
and
Evolu@on
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

54. 54
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
FraSCA7
Architecture
Set
of
Safe
Variants
authorized
by
FraSCA7
Scope
is
too
large

55. Illegal
Variant
55

56. 56
FraSCA7
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
Configura7on
Derived
FraSCA7
Architecture

57. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
ma^er
(45’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h30’)
[APPLICATION
FOR
MODEL-­‐BASED
SPL
ENGINEERING]
Model-­‐based
variability
engineering:
applica@ons,
advanced
topics,
support
(45’)
57
Plan

58. Variability
Model
Configura7on
Domain
Artefacts
(e.g.,
source
code)
SoNware
Generator
Modeling
variability
is
crucial
ü
ü

59. 59
Unused
flexibility

60. 60
Illegal
variant

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

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

64. Feature
Models
64

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

66. 66
Hierarchy
+
Variability
=
set
of
valid
configura7ons
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondi@oning,
FrontFogLights}
configura7on
=
set
of
features
selected
Optional
Mandatory
Xor-Group
Or-Group

67. 67
Hierarchy
+
Variability
=
set
of
valid
configura7ons
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondi@oning}
configura7on
=
set
of
features
selected
Optional
Mandatory
Xor-Group
Or-Group

68. 68
Hierarchy
+
Variability
=
set
of
valid
configura7ons
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing,
AirCondi@oning,
Automa@cHeadLights}
configura7on
=
set
of
features
selected
ü
ü
ü
ü
ü
ü

69. 69
Hierarchy
+
Variability
=
set
of
valid
configura7ons
Optional
Mandatory
Xor-Group
Or-Group
{AirCondi@oning,
FrontFogLights}
{Automa@cHeadLights,
AirCondi@oning,
FrontFogLights}
{Automa@cHeadLights,
FrontFogLights,
AirCondi@oningFrontAndRear}
{AirCondi@oningFrontAndRear}
{AirCondi@oning}
{AirCondi@oningFrontAndRear,
FrontFogLights}
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing}
X

71. (FeAture
Model
scrIpt
Language
for
manIpula@on
and
Automa@c
Reasoning)
not, and, or, implies
φTVL
DIMACS
hkp://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

72. 72
Optional
Mandatory
Xor-Group
Or-Group

73. 73
Optional
Mandatory
Xor-Group
Or-Group

74. 74
Optional
Mandatory
Xor-Group
Or-Group
{AirCondi@oning,
FrontFogLights}
{Automa@cHeadLights,
AirCondi@oning,
FrontFogLights}
{Automa@cHeadLights,
FrontFogLights,
AirCondi@oningFrontAndRear}
{AirCondi@oningFrontAndRear}
{AirCondi@oning}
{AirCondi@oningFrontAndRear,
FrontFogLights}
{CarEquipment,
Comfort,
DrivingAndSafety,
Healthing}
X

75. 75

77. (FeAture
Model
scrIpt
Language
for
manIpula@on
and
Automa@c
Reasoning)
impor7ng,
expor7ng,
composing,
decomposing,
edi7ng,
configuring,
reverse
engineering,
compu7ng
"diffs",
refactoring,
tes7ng,
and
reasoning
about
(mul7ple)
variability
models
not, and, or, implies
φTVL
DIMACS
hkp://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

78. #1
Automated
Analysis
78

79. #2
Mul7ple
Feature
Models
79

80. 80
80
Mul7-­‐*
variability
*systems,
perspec7ves,
or
stakeholders

81. • #1
Automated
analysis
– Aka
support
to
be^er
understand
and
play
with
your
feature
model
• #2
Managing
mul7ple
feature
models
– Composing
/
Decomposing
/
Diff
and
Reasoning
about
their
rela@onships
– Combining
these
operators
81
Two
Key
Requirements

82. 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
intersec7on
{
fm1
fm2
}
c3
=
coun7ng
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
facili7es
Environment

83. 83
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/Composi7on
merge
diff
intersec@on
sunion
aggregate
map
unmap
extract
slicing
Edi7ng
renameFeature
removeFeature
accessors
copy
Reasoning
coun@ng
configs
isValid
deads
cores
falseOp@onals
cleanup
configura@on
select
deselect
asFM
compare
setOp@onal
setMandatory
setAlterna@ves
setOr
Language
Facili7es
fm1.*
fm1.B
modular
mechanisms
restricted
set
of
types
iterator/condi@onal
asser@on
insert
features

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

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

86. Typed
language
86
basics2.fml

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

88. Impor7ng/Expor7ng
feature
models
88
FAMILIAR
S2T2
TVL
feature-model-synthesis
(visual configurator)
(language)
(language)FaMa
Internal
nota@on
or
by
“filename
extensions”
basics3.fml

89. Feature
Accessors
(1)
89
XAccessors.fml
Optional
Mandatory
Xor-Group
Or-Group

90. Other
constructs
90
XAccessors2.fml
Optional
Mandatory
Xor-Group
Or-Group

91. Configura7on
91
conf.fml
Optional
Mandatory
Xor-Group
Or-Group

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

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

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

95. Opera7ons
for
Feature
Models
(3)
95
operatorsFM3.fml
Optional
Mandatory
Xor-Group
Or-Group

96.
SoC
support
=
Composi7on/Decomposi7on
for
managing
large,
complex
and
mul7ple
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.

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

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

99. Composing
Feature
Models
(3)
99
mergeMI.fml
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Robert
B.
France
«
Comparing
Approaches
for
Implemen@ng
Feature
Model
Composi@on
»
ECMFA’10

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

102. Merge
Intersec7on:
Available
Suppliers
102
∩
∩
A
customer
has
some
requirements
Suppliers?
Products?

103. In
FAMILIAR
103
suppliersExample0.fml

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

105. In
FAMILIAR
105
suppliersExample.fml

106. Merging
opera7on:
implementa7on
issues
106
How
to
synthesise
a
feature
model
that
represents
the
union
of
input
sets
of
configura7ons?
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

107. 107
Merging
opera7on:
seman7c
issues
(2)
φ
Union
Intersec@on
Diff
How
to
synthesize
a
feature
model
that
represents
the
union
of
input
sets
of
configura7ons?

108. Merging
opera7on:
algorithm
108
φ1
φ2
φ3
φ123
merged
proposi@onal
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
configura7ons?
see
also
[Czarnecki
SPLC’07
or
SPLC’12]
Optional
Mandatory
Xor-Group
Or-Group

109. see
also
[Acher
et
al.,
ECMFA’10
/
MODELS’13]
– Well-­‐defined
seman@cs
– Guarantee
seman@cs
proper@es
by
construc@on
– 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
proposi@onal
feature
models
• Full
support
of
proposi@onal
constraints
• Different
hierarchies
[Van
Den
Broek
et
al.,
SPLC’2010/2012]
– Syntac@cal
strategies
fail
[Alves
et
al.,
2006],
[Segura
et
al.,
2007]
109
Related
Works

110. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
ma^er
(45’)
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
(1h30’)
[APPLICATION
FOR
MODEL-­‐BASED
SPL
ENGINEERING]
Model-­‐based
variability
engineering:
applica@ons,
advanced
topics,
support
(45’)
110
Plan

112. 112
Problem:
mul7ple
„car
models“

113. 113
Problem:
mul7ple
„car
models“

114. 114
Problem:
mul7ple
„car
models“

115. 115
Problem:
mul7ple
„car
models“
#2
–
bokom-­‐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

116. 116
#1
top-­‐down

117. 117
#1
bokom-­‐up
FM_1
FM_2
FM_3
FM_r
merge

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

120. 120
Building
“views”
of
a
feature
model

121. • Problem:
given
a
feature
model,
how
to
decompose
it
into
smaller
feature
models?
• Seman@cs?
– What’s
the
hierarchy
– What’s
the
set
of
configura@ons?
121
Building
“views”
of
a
feature
model

122. 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
Problem:
You
can
select
A3
without
A5
Hierarchy
and
Configura7on
maker!
122
A3
=>
A5

123. 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,
represen@ng
a
projected
set
of
configura@ons
123

124. Slicing
operator:
going
into
details
projected
set
of
configura7ons
124
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

125. +
T
S E D
constraints
E implies D
D implies E
φs1
existenBal
quanBficaBon
of
features
not
included
in
the
slicing
criterion
125
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
«
Separa@on
of
Concerns
in
Feature
Modeling:
Support
and
Applica@ons
»
AOSD’12
Optional
Mandatory
Xor-Group
Or-Group

126. T
S E D
constraints
E implies D
D implies E
126
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

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

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

129. 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

130. 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
«
Separa@on
of
Concerns
in
Feature
Modeling:
Support
and
Applica@ons
»
AOSD’12
Optional
Mandatory
Xor-Group
Or-Group

131. With
FAMILIAR
131
realizibility.fml

133. Modeling
Variability
From
Requirements
to
Run7me
The
case
of
video
surveillance
processing
chains
Adap7ve
systems
Mathieu
Acher,
Philippe
Collet,
Philippe
Lahire,
Sabine
Moisan,
and
Jean-­‐Paul
Rigault.
«
Modeling
Variability
from
Requirements
to
Run@me
ICECCS’11

134. SoXware
Product
Line
(SPL)
approach
Video
surveillance
processing
chains
Adap7ve
systems
Adap7ve
systems
large
number
of
soNware
configura7ons
for
a
large
number
of
requirements

135. constraints
……..
constraints
……..
constraints
……..
constraints
……..
SoNware
Pla}orm
Configura7ons
SoXware
Product
Line
(SPL)
approach
Video
surveillance
processing
chains
constraints
……..
constraints
……..
constraints
……..
Video
Surveillance
Applica7on
Requirements
Scene
Context
Objects
of
Interest
Specific
Task
Adap7ve
systems

136. Implementa@on:
under
the
hood
Video surveillance applica0on
Task QoS Object of
interest
Scene
context
Coun0ng Intrusion
Precision Response
,me
Quality Scene
descrip0on
Environment
Ligh0ng Camera
Person
Ar0ficial Indoors View Frame
rate
Video surveillance plaIorm
Acquisi0on Segmenta0on Classifica0on
Clustering
Grid step With
window
Traversal
algorithm
Kernel
func0on
Edge Region
Model
Ellipse Gravity Grey Color (a) Task model (b) PlaIorm model
mandatory feature
op0onal feature
alterna0ve features (XOR)
or‐features (OR)
cross‐model constraint
internal constraint
specifica0on feature
imposed by the applica0on
specifica0on feature deduced
from internal constraints
implementa0on feature deduced
from cross‐constraints (transforma0on)
”neutral” implementa0on feature
136

138. 138
Revisi7ng
Merge:
Aggregate
+
Slice
Optional
Mandatory
Xor-Group
Or-Group

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

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

141. 141
φ 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

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

143. φ(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
addi@onal
informa@on)
consistent,
«
par7al
»
(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

144. #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

145. #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

146. #3
Re-­‐Engineering
Feature
Models
of
repository
• For
each
FM
we
execute
the
following
FAMILIAR
script…
• …
And
we
«compare»
syntac@cally
fm1
and
fm2
• seman@cal
comparison
is
not
needed:
we
know
that
they
are
refactoring
by
construc@on
(good
test
case
though
;-­‐))
• Results:
– 147
synthesised
FMs
(69
%)
were
exactly
the
same
as
input
FMs
;
– 40
synthesised
FMs
(19%)
were
correc@ons
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
Specifica7on
of
the
hierarchy
is
the
main
issue
φ

147. φ
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
specifica@on
(consistency
and
completeness)
concrete
syntax
and
tooling
suport
#2
Prac7cal
applica7ons
reverse
engineering,
refactoring/re-­‐engineering
of
feature
models
hkp://familiar-­‐project.github.com/
Automated
support
is
highly
needed
(ongoing
work)

148. FAMILIAR
console
Ranking
list
Ontological
Heuris@cs
Logical
clusters
(interac@ve
synthesis)
Clusters
of
conceptually
similar
features
«
Breathing
Ontological
Knowledge
into
Feature
Model
Management
»
Guillaume
Bécan,
Mathieu
Acher,
Benoit
Baudry,
Sana
Ben
Nasr
State-­‐of-­‐the-­‐art
support
for
assis@ng
users:
hkp://7nyurl.com/OntoFMExperiments

149. Summary:
Variability
Model
Management
149
149
149

150. [MOTIVATION/PROBLEM]
Why
modeling
and
managing
Variability
does
and
will
ma^er
[SOLUTION
FOR
MANAGING
FEATURE
MODELS]
Managing
Variability
Models
with
FAMILIAR
[APPLICATION
FOR
MODEL-­‐BASED
SPL
ENGINEERING]
Model-­‐based
variability
engineering:
applica@ons,
advanced
topics,
support
150
Key
Insights

151. (ongoing)
Comprehensive
model-­‐based
product
line
support
Reverse
engineering
Automated
Analysis
Languages,
API/DSLs
Evalua7on
(European
and
french
projects,
long-­‐term
collabora7on
with
Thales,
open
source
systems)
151

152. (personal
vision)
lightweight
variability
capture
&
understanding
Coupling
with
reverse
engineering
techniques
Beyond
mul7ple
viewpoints
Languages,
API/DSLs
The
Scala
way…
Evalua7on,
empirical
studies
(French
and
European
projects,
collabora7on
with
IT
companies)
152

153.
?