Model-based Variability Management (tutorial at ECOOP/ECMFA/ECSA)

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Acknowledgments (la famille) Marianela Ciolﬁ 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)

Slide 5

Slide 5 text

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 –  ConﬁguraWon •  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

Slide 6

Slide 6 text

At the end of the tutorial… •  You will have an overview of what’s going on in the ﬁeld 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

Slide 7

Slide 7 text

Diﬀerences 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

Slide 8

Slide 8 text

[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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 So6ware-‐intensive systems come in many variants

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Linux Kernel

Slide 13

Slide 13 text

Database Engine

Slide 14

Slide 14 text

Printer Firmware

Slide 15

Slide 15 text

Features in MicrosoS Oﬃce 15

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Variability “the ability of a system to be eﬃciently extended, changed, customized or conﬁgured for use in a parCcular context” Mikael Svahnberg, Jilles van Gurp, and Jan Bosch (2005)

Slide 19

Slide 19 text

« A set of programs is considered to consWtute a family, whenever it is worthwhile to study programs from the set by ﬁrst 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

Slide 20

Slide 20 text

Variability “the ability of a system to be eﬃciently extended, changed, customized or conﬁgured for use in a parCcular context” Mikael Svahnberg, Jilles van Gurp, and Jan Bosch (2005) 20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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)

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Variability = Complexity ChrisWan Kästner slide

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

2000 features 10000 features ChrisWan Kästner slide

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31 Unused ﬂexibility

Slide 32

Slide 32 text

32 Illegal variant

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Modeling Variability CommunicaCve AnalyCc GeneraCve 35

Slide 36

Slide 36 text

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

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]

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

40 99% domain engineering, 1% applicaCon engineering? –  speciﬁes 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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

VariaCon Point Types •  Variability is applied to diﬀerent 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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

              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 deﬁne and manage semanBc variability (in the DSML and the associated tools)?

Slide 60

Slide 60 text

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)

Slide 61

Slide 61 text

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 speciﬁc 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)

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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 rest http Binding MMFrascati Component Factory Metamodel MMTuscany constraints rest requires MMFrascati http requires MMTuscany FM1 Variability Model

Slide 65

Slide 65 text

65 Variability Model FraSCAti SCAParser Java Compiler JDK6 JDT Optional Mandatory Alternative- Group Or-Group Assembly Factory rest http 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

Slide 66

Slide 66 text

Illegal Variant 66

Slide 67

Slide 67 text

67 FraSCAC Architecture FraSCAti SCAParser Java Compiler JDK6 JDT Optional Mandatory Alternative- Group Or-Group Assembly Factory rest http 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 rest http Binding MMFrascati Component Factory Metamodel MMTuscany constraints rest requires MMFrascati http requires MMTuscany FM1 ConﬁguraCon Derived FraSCAC Architecture

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

70 Unused ﬂexibility

Slide 71

Slide 71 text

71 Illegal variant

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

Feature Models 76

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

78 Hierarchy + Variability = set of valid conﬁguraCons {CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning, FrontFogLights} conﬁguraCon = set of features selected Optional Mandatory Xor-Group Or-Group

Slide 79

Slide 79 text

79 Hierarchy + Variability = set of valid conﬁguraCons {CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning} conﬁguraCon = set of features selected Optional Mandatory Xor-Group Or-Group

Slide 80

Slide 80 text

80 Hierarchy + Variability = set of valid conﬁguraCons Optional Mandatory Xor-Group Or-Group {CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning, AutomaWcHeadLights} conﬁguraCon = set of features selected ü ü ü ü ü ü

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

Feature Models 82

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

(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-‐Speciﬁc Language for Large-‐ Scale Management of Feature Models » Science of Computer Programming (SCP), 2013

Slide 85

Slide 85 text

85 Optional Mandatory Xor-Group Or-Group

Slide 86

Slide 86 text

86 Optional Mandatory Xor-Group Or-Group

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

(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

Slide 91

Slide 91 text

#1 Automated Analysis 91

Slide 92

Slide 92 text

#2 MulCple Feature Models 92

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

Typed language 99 basics2.fml

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

ConﬁguraCon 104 conf.fml Optional Mandatory Xor-Group Or-Group

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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.

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

No content

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

In FAMILIAR 116 suppliersExample0.fml

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

In FAMILIAR 118 suppliersExample.fml

Slide 119

Slide 119 text

Merging operaCon: implementaCon issues 119 How to synthesise a feature model that represents the union of input sets of conﬁguraCons? Optional Mandatory Xor-Group Or-Group T2 MRI Medical Image Header Anonymized 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

Slide 120

Slide 120 text

120 Merging operaCon: semanCc issues (2) φ Union IntersecWon Diﬀ How to synthesise a feature model that represents the union of input sets of conﬁguraCons?

Slide 121

Slide 121 text

Merging operaCon: algorithm 121 φ 1 φ 2 φ 3 φ 123 merged proposiWonal formula T2 MRI Medical Image Header Anonymized 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 conﬁguraCons? see also [Czarnecki SPLC’07 or SPLC’12] Optional Mandatory Xor-Group Or-Group

Slide 122

Slide 122 text

Merging operaCon: back to hierarchy 122 mergeNonPC.fml > conﬁgs 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

Slide 123

Slide 123 text

see also [Acher et al., ECMFA’10 / MODELS’13] – Well-‐deﬁned 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 •  Diﬀerent hierarchies [Van Den Broek et al., SPLC’2010/2012] – SyntacWcal strategies fail [Alves et al., 2006], [Segura et al., 2007] 123 Related Works

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

125 Problem: mulCple „car models“

Slide 126

Slide 126 text

126 Problem: mulCple „car models“

Slide 127

Slide 127 text

127 Problem: mulCple „car models“

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

129 #1 top-‐down

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

133 Building “views” of a feature model

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

A ﬁrst try A3 => P1 P2 => A5 R A2 A5 A6 A1 A3 A4 A fm0 P3 P2 P1 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 ConﬁguraCon maier! 135

Slide 136

Slide 136 text

Slicing Operator W constraints E implies D R implies E D excludes F S implies (F and not E) P R S fm1 A V 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 conﬁguraWons 136

Slide 137

Slide 137 text

Slicing operator: going into details projected set of conﬁguraCons 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 A V T U B C D E F Optional Mandatory Xor-Group Or-Group

Slide 138

Slide 138 text

+ T S E D constraints E implies D D implies E φ s1 existenBal quanBﬁcaBon 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 A V 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

Slide 139

Slide 139 text

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 A V T U B C D E F slicingOp2.fml Optional Mandatory Xor-Group Or-Group

Slide 140

Slide 140 text

140 Slicing with FAMILIAR (2) slicingOp.fml

Slide 141

Slide 141 text

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)

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

Realizability checking aggregate {{V1,V3,V2,VP1}, {V1,VP1}, {V3,VP1}, {VP1}} merge diﬀ (“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

Slide 144

Slide 144 text

With FAMILIAR 144 realizibility.fml

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

φ « 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/

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

#1 Reverse Engineering Scenarios •  [Haslinger et al., WCRE’11], [Acher et al., VaMoS’12] φ V D Ad O T M K Ae C P R S C requires T Ae requires T S equals M V D Ad O T K Ae S P R M C requires T S equals M C 0..1

Slide 153

Slide 153 text

#2 Refactoring •  [Alves et al., GPCE’06], [Thuem et al., ICSE’09] φ V D Ad O T M K Ae C P R S C requires T Ae requires T S equals M

Slide 154

Slide 154 text

#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 φ

Slide 155

Slide 155 text

φ 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 speciﬁcaWon (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)

Slide 156

Slide 156 text

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

Printer ´Blockª mainSupply:MainPower 1 Attributes Operations powerCtrl emgSupply:EmgPower 1 Attributes threshold:int Operations powerCtrl inputSection 1 highSpeedConnector 1 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

Slide 160

Slide 160 text

Printer ´Blockª mainSupply:MainPower 1 Attributes Operations powerCtrl emgSupply:EmgPower 1 Attributes threshold:int Operations powerCtrl inputSection 1 highSpeedConnector 1 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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

Traffic Lights

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

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

Slide 167

Slide 167 text

DSL metamodel

Slide 168

Slide 168 text

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

Slide 169

Slide 169 text

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

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

VAM

Slide 172

Slide 172 text

Resolution model

Slide 173

Slide 173 text

Resolution model

Slide 174

Slide 174 text

VRM

Slide 175

Slide 175 text

VRM

Slide 176

Slide 176 text

Product derivation

Slide 177

Slide 177 text

Derived FSM

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

No content

Slide 180

Slide 180 text

Marks & Spencer web conﬁgurator

Slide 181

Slide 181 text

§  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)

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

Feature model - Implicit boolean attribute existence - No constraints

Slide 188

Slide 188 text

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

Slide 189

Slide 189 text

DSL metamodel

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

VAM

Slide 194

Slide 194 text

VAM

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

Resolution model

Slide 197

Slide 197 text

Resolution model

Slide 198

Slide 198 text

VRM

Slide 199

Slide 199 text

VRM

Slide 200

Slide 200 text

Product derivation

Slide 201

Slide 201 text

Product derivation

Slide 202

Slide 202 text

Summary: Variability Model Management 202 202 202

Slide 203

Slide 203 text

Slide 204

Slide 204 text

(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

Slide 205

Slide 205 text

? 205