models2013 tutorial-smart featuremodeling-final
DESCRIPTION
Feature Model Management: Smart Operations and Language Support The tutorial has been presented at MODELS'13 conference: http://models2013.lcc.uma.es/tutorials.html#TT7TRANSCRIPT
Philippe Collet, Philippe Lahire, Mathieu Acher, Robert France
Feature Model Management: Smart Opera7ons and Language Support
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)
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
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
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
[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
[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
Everybody raise your phone!
8
9
SoXware-‐intensive systems
come in many variants
10
Linux Kernel
Database Engine
Printer Firmware
Features in MicrosoN Office
14
16
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)
« 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
Extensible architect
ures
(eg plugins-‐based)
Configura7on
files
System
Preferences
Configurators
Source code Build
systems
Comparison of *
Structural or behav
orial
models
External Variability Internal Variability Variability @ run.7me
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)
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 « 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
« 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
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
Variability = Complexity
Chris@an Kästner slide
a unique variant for every
person on this planet
33 features op@onal, independent
Chris@an Kästner slide
320 features
more variants than es@mated
atoms in the universe
op@onal, independent
2000 features 10000 features
Chris@an Kästner slide
29
Avoid solving the same problem!
2, 3…n 7mes
Automa7on?
30
Unused flexibility
31
Illegal variant
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
SoXware-‐intensive systems come in many variants
Model-‐based Variability Management
Modeling Variability Communica7ve Analy7c Genera7ve 34
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]
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
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
Variability Abstrac7on Model (VAM)
Configura7on (resolu7on model)
Domain Artefacts (e.g., models)
SoNware Generator (deriva7on engine)
ü ü
Variability Realiza7on Model (VRM)
Configurations Derivation Process
Models of the “system”
Feature Model
How to realize the variability
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
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
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 « Mapping Features to Models: A Template Approach Based on Superimposed Variants» Krzysztof Czarnecki and Michal Antkiewicz GPCE’05
46 « Mapping Features to Models: A Template Approach Based on Superimposed Variants» Krzysztof Czarnecki and Michal Antkiewicz GPCE’05
47 « Mapping Features to Models: A Template Approach Based on Superimposed Variants» Krzysztof Czarnecki and Michal Antkiewicz GPCE’05
48 « Mapping Features to Models: A Template Approach Based on Superimposed Variants» Krzysztof Czarnecki and Michal Antkiewicz GPCE’05
Safe composi@on? No!
49 «Verifying Feature-‐Based Model Templates Against Well-‐Formedness OCL Constraints » Krzysztof Czarnecki Krzysztof Pietroszek GPCE’06
Ooops
50 «Verifying Feature-‐Based Model Templates Against Well-‐Formedness OCL Constraints » Krzysztof Czarnecki Krzysztof Pietroszek GPCE’06
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
« 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 MMFrascatihttp requires MMTuscany
FM1
Variability Model
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 MMFrascatihttp requires MMTuscany
FM1
FraSCA7 Architecture
Set of Safe Variants
authorized by FraSCA7
Scope is too large
Illegal Variant
55
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 MMFrascatihttp 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 MMFrascatihttp requires MMTuscany
FM1
Configura7on Derived FraSCA7 Architecture
[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
Variability Model
Configura7on
Domain Artefacts (e.g., source code)
SoNware Generator
Modeling variability is crucial ü ü
59
Unused flexibility
60
Illegal variant
61 61
Extensible architect
ures
(plugins-‐based)
Configura7on
files
System
Preferences
Configurators
Source code
Build systems
Comparison of Product
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
Feature Models
64
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
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
Hierarchy + Variability =
set of valid configura7ons
{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondi@oning}
configura7on = set of features selected
Optional
Mandatory
Xor-Group
Or-Group
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
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
(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
Optional
Mandatory
Xor-Group
Or-Group
73
Optional
Mandatory
Xor-Group
Or-Group
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
(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
#1 Automated Analysis
78
#2 Mul7ple Feature Models
79
80 80
Mul7-‐* variability *systems, perspec7ves, or stakeholders
• #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
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 outputHDMI 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
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
Hello World
84
helloworld.fml Optional
Mandatory
Xor-Group
Or-Group
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
Typed language
86
basics2.fml
Typed language
87
basics2.fml
Optional
Mandatory
Xor-Group
Or-Group
Impor7ng/Expor7ng feature models
88
FAMILIAR
S2T2TVL
feature-model-synthesis
(visual configurator)
(language)
(language)FaMa
Internal nota@on or by “filename extensions”
basics3.fml
Feature Accessors (1)
89
XAccessors.fml
Optional
Mandatory
Xor-Group
Or-Group
Other constructs
90
XAccessors2.fml
Optional
Mandatory
Xor-Group
Or-Group
Configura7on
91
conf.fml Optional
Mandatory
Xor-Group
Or-Group
92
φ FM
A ^ A ó B ^ C => A ^ D => A
Optional
Mandatory
Xor-Group
Or-Group
Opera7ons for Feature Models (1)
93 φ
operatorsFM.fml
Optional
Mandatory
Xor-Group
Or-Group
Opera7ons for Feature Models (2)
94
φ
operatorsFM2.fml
Optional
Mandatory
Xor-Group
Or-Group
Opera7ons for Feature Models (3)
95
operatorsFM3.fml
Optional
Mandatory
Xor-Group
Or-Group
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.
Composing Feature Models (1)
97
aggregateBasics.fml
Optional
Mandatory
Xor-Group
Or-Group
Composing Feature Models (2)
98
aggregate1.fml
Previous version
Optional
Mandatory
Xor-Group
Or-Group
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
see also Thuem, Kastner and Batory, ICSE’09
Comparing Feature Models
100
compare.fml
Optional
Mandatory
Xor-Group
Or-Group
Merge Intersec7on: Available Suppliers
102
∩ ∩
A customer has some
requirements
Suppliers? Products?
In FAMILIAR
103
suppliersExample0.fml
Merge Union: Availability Checking
104
Can suppliers provide all products? Yes!
“compare”
∩
Optional
Mandatory
Xor-Group
Or-Group
In FAMILIAR
105
suppliersExample.fml
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
DICOMHeader excludes DICOMHeader implies AnonymizedAnonymized v Header v ~DICOM v ~T1 v ~T2Anonymized v Header v DICOM v ~T1 v ~T2
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?
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
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
[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
Problem: mul7ple „car models“
113
Problem: mul7ple „car models“
114
Problem: mul7ple „car models“
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
#1 top-‐down
117
#1 bokom-‐up FM_1
FM_2
FM_3
FM_r merge
118
#1 bokom-‐up (FAMILIAR) FM_1
FM_2
FM_3
FM_r merge
audiMerge.fml
120
Building “views” of a feature model
• 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
A first try
A3 => P1P2 => A5
R
A2
A5 A6
A1
A3 A4
A
fm0
P3P2P1
P
P1 => P2
A2
A5 A6
A1
A3 A4
AfmExtraction1
Problem: You can select A3 without A5
Hierarchy and Configura7on maker! 122
A3 => A5
Slicing Operator
W
constraintsE implies DR implies E D excludes FS 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
constraintsE implies DD 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
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
constraintsE implies DR implies E D excludes FS implies (F andnot E)
P
R S
fm1
AV
T U
B C D
E F
Optional
Mandatory
Xor-Group
Or-Group
+ T
S E D
constraintsE implies DD 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
constraintsE implies DR implies E D excludes FS 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
T
S E D
constraintsE implies DD implies E
126
Slicing operator with FAMILIAR (1)
W
constraintsE implies DR implies E D excludes FS 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
Slicing with FAMILIAR (2) slicingOp.fml
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)
V1 ⬄ f1V2 ⬄ f2V3 ⬄ f3
From marke.ng, customers, product management
From exis.ng so@ware assets
realizability
usefulness
Optional
Mandatory
Xor-Group
Or-Group
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
With FAMILIAR
131
realizibility.fml
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
SoXware Product Line (SPL) approach
Video surveillance processing chains
Adap7ve systems
Adap7ve systems
large number of soNware configura7ons for a large number of requirements
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
Implementa@on: under the hood Videosurveillanceapplica0on
Task QoS Objectof
interest
Scene
context
Coun0ng Intrusion
Precision Response
,me
Quality Scene
descrip0on
Environment
Ligh0ngCamera
Person
Ar0ficial IndoorsViewFrame
rate
VideosurveillanceplaIorm
Acquisi0on Segmenta0on Classifica0on
Clustering
Gridstep With
window
Traversal
algorithm
Kernel
func0on
Edge Region
Model
Ellipse GravityGreyColor
(a)Ta
skm
odel
(b)P
laIorm
model
mandatoryfeature
op0onalfeature
alterna0vefeatures(XOR)
or‐features(OR)
cross‐modelconstraint
internalconstraint
specifica0onfeature
imposedbytheapplica0on
specifica0onfeaturededuced
frominternalconstraints
implementa0onfeaturededuced
fromcross‐constraints(transforma0on)
”neutral”implementa0onfeature
136
138
Revisi7ng Merge: Aggregate + Slice
Optional
Mandatory
Xor-Group
Or-Group
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 Mathieu Acher, Benoit Combemale, Philippe Collet, Olivier Barais, Philippe Lahire, Robert B. France « Composing your Composi@ons of Variability Models » MODELS’13
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
φ
« 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/
φ(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
#1 Reverse Engineering Scenarios • [Haslinger et al., WCRE’11], [Acher et al., VaMoS’12]
φ
V
DAd OT M KAe CP R S
C requires TAe requires TS equals M
V
DAd OT KAe SP R M
C requires TS equals M
C
0..1
#2 Refactoring • [Alves et al., GPCE’06], [Thuem et al., ICSE’09]
φ V
DAd OT M KAe CP R S
C requires TAe requires TS equals M
#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
φ
φ
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)
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
Summary: Variability Model Management
149 149 149
[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
(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
(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
?