Embed Size (px)
Citation preview
What is needed to handle Variability?
• Define mandatory properSes and funcSonaliSes • Define opAonal choices: 0, 1..N, choice among n • Variants • Constraints
– Dependency – Mutual exclusion
How to express variability?
• Inheritance (design, implementaSon) • Genericity (design, implementaSon) • Design Pa\ern (design, implementaSon) • Aspect-‐Oriented Design & Programming (design, implementaSon)
• Model TransformaSon (design) • Model ComposiSon (design) • Feature Models (requirement engineering, design, also implementaSon) – Similar technique : Decision Modeling
Variability Model Feature Model: de facto standard
• Research – 2500+ citaSons of [Kang et al., 1990] on Google Scholar – Central to many generaSve approaches
• at requirements or code level – Tools & Languages (GUIDSL/FeatureIDE, SPLOT, FaMa, etc.)
• Industry – Tools (Gears, pure::variants), – Will be Part of Common Variability Language (CVL), future OMG standard
43
excludes
Feature Models
47
Feature Models (Background)
48
Hierarchy: rooted tree Variability: • mandatory, • opSonal, • Groups: exclusive or inclusive features • Cross-‐tree constraints
Optional
Mandatory
Xor-Group
Or-Group
49
Hierarchy + Variability =
set of valid configuraAons
ü
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiSoning, FrontFogLights}
configuraAon = set of features selected
ü ü
ü
ü ü
ü
50
Hierarchy + Variability =
set of valid configuraAons
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiSoning}
configuraAon = set of features selected
ü ü
ü
ü
ü
51
Hierarchy + Variability =
set of valid configuraAons
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiSoning, AirCondiSoningFrontAndRear, FrontFogLights}
configuraAon = set of features selected
ü ü
ü
ü ü
52
Hierarchy + Variability =
set of valid configuraAons
Optional
Mandatory
Xor-Group
Or-Group
{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiSoning, AutomaScHeadLights}
configuraAon = set of features selected
ü ü
ü
ü
ü
ü
53
Hierarchy + Variability =
set of valid configuraAons
Optional
Mandatory
Xor-Group
Or-Group
{AirCondiSoning, FrontFogLights} {AutomaScHeadLights, AirCondiSoning, FrontFogLights} {AutomaScHeadLights, FrontFogLights, AirCondiSoningFrontAndRear} {AirCondiSoningFrontAndRear} {AirCondiSoning} {AirCondiSoningFrontAndRear, FrontFogLights}
{CarEquipment, Comfort, DrivingAndSafety, Healthing} X
Feature Models
54
Managing variability models with FAMILIAR
55
#1 Automated Analysis
56
#2 MulAple Feature Models
57
• #1 Automated analysis – Aka support to be\er understand and play with your feature model (TVL model)
• #2 Managing mulAple feature models – Composing / Decomposing / Diff and Reasoning about their relaSonships
– Combining these operators 58
Two Key Requirements
FAMILIAR language and environment
FAMILIAR
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 intersecAon { fm1 fm2 } c3 = counAng 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 faciliAes Environment
60
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/ComposiAon merge diff intersecSon sunion
aggregate map unmap
extract slicing
EdiAng renameFeature
removeFeature accessors
copy
Reasoning counSng configs
isValid deads cores falseOpSonals
cleanup
configuraSon select deselect asFM compare
setOpSonal setMandatory
setAlternaSves setOr
Language FaciliAes fm1.* fm1.B
modular mechanisms
restricted set of types iterator/condiSonal
asserSon
insert
FAMILIAR … features
Hello World
61
helloworld.fml
Typed language • Domain-‐specific types
– Feature Model, – ConfiguraSon, – Feature, – Constraint
• Other types include – Set – String – Boolean, – Enum, – Integer and Real.
• A set of operaSons, called operators, are defined for a given type. 62
basics2.fml
Typed language
63
basics2.fml
Typed language
64
basics2.fml
ImporAng/ExporAng feature models
65
FAMILIAR
S2T2TVL
feature-model-synthesis
(visual configurator)
(language)
(language)FaMa
Internal notaSon or by “filename extensions”
basics3.fml
Feature Accessors (1)
66
@Accessors.fml
Other constructs
67
@Accessors2.fml
ConfiguraAon
68
conf.fml
OperaAons for Feature Models (1)
69 φ
operatorsFM.fml
OperaAons for Feature Models (2)
70
φ
operatorsFM2.fml
OperaAons for Feature Models (3)
71
operatorsFM3.fml
FAMILIAR 72
constraints
……..
SPL/internal/so#ware variability (Pohl et al. 2005, Metzger 2007)
constraints
……..
PL/external variability (Pohl et al. 2005, Metzger 2007)
constraints
……..
context variability (FORM 1998, Tun et al. 2009 (problem world), Hartmann 2008 (CVM), Lee et al. 2010
Stakeholder 1, 2, 3, …, n (Czarnecki 2005, Reiser et al. 2007, Hartmann et al. 2009, Classen et al. 2009, Mendonca et al. 2010)
constraints
……..
constraints
……..
constraints
……..
constraints
……..
Concern 1, 2, 3, …, n View 1, 2, 3, …, n (Dunghana et al. 2010, Hubaux et al. 2010, Zaid et al. 2010)
constraints
……..
constraints
……..
constraints
……..
constraints
……..
constraints
……..
MulAple Feature Models
SoC support = ComposiAon/DecomposiAon for managing large, complex and mulAple 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)
74
aggregateBasics.fml
Composing Feature Models (2)
75
aggregate1.fml
Previous version
Merging Feature Models
76
mergeMI.fml
see also Thuem, Kastner and Batory, ICSE’09
Comparing Feature Models
77
compare.fml
Puxng all together: Example 1
78
Merge IntersecAon: Available Suppliers
79
∩ ∩
A customer has some
requirements
Suppliers? Products?
In FAMILIAR
80
suppliersExample0.fml
Merge Union: Availability Checking
81
Can suppliers provide all products? Yes!
“compare”
∩
In FAMILIAR
82
suppliersExample.fml
Merging operaAon: implementaAon issues
83
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
How to synthesise a feature model that represents the union of input sets of configuraAons?
84
Merging operaAon: semanAc issues (2)
φ Union IntersecSon Diff How to synthesise a feature model that represents
the union of input sets of configuraAons?
Merging operaAon: algorithm
85
φ1
φ2
φ3
φ 123
merged proposiSonal 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 configuraAons?
see also [Czarnecki SPLC’07 or SPLC’12]
86
Building “views” of a feature model
• Problem: given a feature model, how to decompose it into smaller feature models?
• SemanScs? – What’s the hierarchy – What’s the set of configuraSons?
87
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
A2
A5 A6
A1
A3 A4
AfmExtraction2
A3 => A5A4 => A6
Problem: You can select A3 without A5
Hierarchy and ConfiguraAon maJer! 88
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, represenSng a projected set of configuraSons
89
Slicing operator: going into details projected set of configuraAons
90
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
91
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
see also [Acher et al., ASE’11/AOSD’12]
T
S E D
constraintsE implies DD implies E
92
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
93
Slicing with FAMILIAR (2) slicingOp.fml
Puxng all together: Example 2
94
From marke.ng, customers, product management
From exis.ng so@ware assets (technical variability)
V1 ⬄ f1V2 ⬄ f2V3 ⬄ f3
From marke.ng, customers, product management
From exis.ng so@ware assets
realizability
usefulness
Metzger, Heymans et al. “DisambiguaBng the DocumentaBon of Variability in Sodware Product Lines: A SeparaBon of Concerns, FormalizaBon and Automated Analysis“ (RE’07)
Realizability checking aggregate
{{V1,V3,V2,VP1}, {V1,VP1}, {V3,VP1}, {VP1}}
merge diff (“unrealizable products”)
φ
1
slice (“realizable part”) 2
3 compare 4
see also [Acher et al. AOSD’12 and CAiSE’12
With FAMILIAR
98
realizibility.fml
Puxng all together: Example 3
99
#1 Reverse Engineering Architectural Feature Models
Case Study: FraSCAA Architecture
CollaboraAon with Anthony Cleve (University of Namur / PRECISE, Belgium), Philippe Collet and Philippe Lahire (University of Nice Sophia AnApolis), Philippe Merle and Laurence Duchien (University of Lille / INRIA)
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
[Acher et al., ECSA’11] [Acher et al., BENEVOL’11] [Acher et al., GDR GPL’12]
101
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
1 2
Philippe Merle, so@ware architect of FraSCAS
CombinaSon of plugin dependencies and hierarchical component model to synthesise a feature model
ExtracAon process
Highlights
• Automated Procedure – ExtracSng and Combining Variability Sources (incl. so@ware architect knowledge) – Advanced feature modeling techniques have been developed (tool supported with FAMILIAR)
• Some Lessons Learned – ExtracSon procedure yields promising results – EssenSal role of so@ware architect
• To validate the extracted feature model • To integrate knowledge
• Extensions – EvoluSon of FraSCAS with DIFF (v1.3, v1.4, etc.)
102
#2 from product descripAons to feature models
103
CollaboraAon with Patrick Heymans, Anthony Cleve, Gilles Perrouin (University of Namur / PRECISE, Belgium), Philippe Collet and Philippe Lahire (University of Nice Sophia AnApolis),
[Acher et al., VaMoS’12]
104
WikiMatrix
RSSStorage LicenseLicenseCostFee
US CommunityDifferent Licenses
LanguageUnicode
Java Python PHP PerlCommercial GPL GPL2NoLimitFiles Database FileRCS
Xor
Mandatory
Optional
640 configuraSons (634 counter examples)
Exact set of configuraSons, each configuraSon corresponding to at least one product
Manual extracSon of a feature model from product descripSon(s) is not possible
AutomaAon • Each product descripSon is encoded as a feature model
• Feature models {fm1, fm2,…,fm8} are merged – Output: a new feature model
• ConfiguraSon: union of input sets of configuraSons • Hierarchy: by default, we exploit the structure of the tabular data
– Can be overridden by specific user direcSves
– VariCell • DSL built on top of FAMILIAR
105
fm1 fm2 fm3 fm4 fm5 fm6 fm7 fm8
Puxng all together: Example 4
106
Modeling Variability From Requirements to RunAme
The case of video surveillance processing chains
CollaboraAon with Sabine Moisan and Jean-‐Paul Rigault (INRIA)
AdapAve systems
So@ware Product Line (SPL) approach
Video surveillance processing chains
AdapAve systems
AdapAve systems
large number of so#ware configuraAons for a large number of requirements
constraints
……..
constraints
……..
constraints
……..
constraints
……..
So#ware Pla�orm ConfiguraAons
So@ware Product Line (SPL) approach
Video surveillance processing chains
constraints
……..
constraints
……..
constraints
……..
Video Surveillance ApplicaAon Requirements
Scene Context Objects of Interest Specific Task
AdapAve systems
ImplementaAon: 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
110
Puxng all together: Example 5 & Demo…
111
Realizing a Car Crash Management System SPL
112
Scenario
• ConstrucSon of a domain feature model for the bCMS – AggregaSon of funcSonal and non funcSonal parts
• Reasoning on the resulSng bCMS FM • RelaSng it to a pla�orm feature model (J2EE from SPLOT repository)
• Checking realizability – While refining both feature models (bCMS / J2EE)
113
Summary: Variability Model Management
114 114 114
[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: applicaSons, advanced topics, support 115
Key Insights
(ongoing) Comprehensive model-‐based product line support Reverse engineering Automated Analysis Languages, API/DSLs EvaluaAon (European and french projects, long-‐term collaboraAon with Thales, open source systems)
116
(personal vision) lightweight variability capture & understanding Coupling with reverse engineering techniques Beyond mulAple viewpoints Languages, API/DSLs
The Scala way… EvaluaAon, empirical studies (French and European projects, collaboraAon with IT companies)
117
?
