Models2013 tutorial-smart featuremodeling-final

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êr (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



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


320 features

more variants than es@mated

atoms in the universe

op@onal, independent

2000 features 10000 features


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




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


53


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


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


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


FM1

Configura7on Derived FraSCA7 Architecture



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



{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondi@oning}


Optional

Mandatory

Xor-Group

Or-Group

68



Optional

Mandatory

Xor-Group

Or-Group

{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondi@oning, Automa@cHeadLights}


ü ü

ü

ü

ü

ü

69



ü

ü

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


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êr 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


94

φ

operatorsFM2.fml

Optional

Mandatory

Xor-Group

Or-Group


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


98

aggregate1.fml

Previous version

Optional

Mandatory

Xor-Group

Or-Group


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



Plan

112

Problem: mul7ple „car models“

113


114


115


#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


φ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


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


126

Slicing operator with FAMILIAR (1)

W


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? »


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


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êr

[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

?