ec2013 tutorial-mb variability-final

Mathieu Acher, Benoit Combemale, Olivier Barais

Model-‐Based Variability Management

2

Research in so6ware engineering. -‐  8 faculty members -‐  35 researchers and

engineers on projects

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

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

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 –  ConfiguraWon

•  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

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

Differences 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

[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



9

Plan

10

So6ware-‐intensive systems

come in many variants

Linux Kernel

Database Engine

Printer Firmware

Features in MicrosoS Office

15

Variability “the ability of a system to be efficiently extended, changed, customized or configured for use in a parCcular context”

Mikael Svahnberg, Jilles van Gurp, and Jan Bosch (2005)

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

Variability “the ability of a system to be efficiently extended, changed, customized or configured for use in a parCcular context”

Mikael Svahnberg, Jilles van Gurp, and Jan Bosch (2005)

20

21 21

Extensible architect

ures

(eg plugins-‐based)

ConfiguraCon

files

System

Preferences

Configurators

Source code Build

systems

Comparison of *

Structural or behav

orial

models

External Variability Internal Variability Variability @ run.Cme

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)

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

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

If you’re able to master variability…

•  Reduce development costs •  Reduce cerWficaWon costs •  Shorten Wme-‐to-‐market

•  But, are you able? – developing, verifying, cerWfying billions of variants is challenging!

25

Variability = Complexity

ChrisWan Kästner slide

a unique variant for every

person on this planet

33 features opWonal, independent


320 features

more variants than esWmated

atoms in the universe

opWonal, independent

2000 features 10000 features


30

Avoid solving the same problem!

2, 3…n Cmes

AutomaCon?

31

Unused flexibility

32

Illegal variant

Goal: So6ware mass customizaWon / AdapWve and configurable systems Problem: Variability = Complexity Approach: Model-‐based variability management

33

Why managing Variability does (and will) maier

34

So6ware-‐intensive systems come in many variants

Model-‐based Variability Management

Modeling Variability CommunicaCve AnalyCc GeneraCve 35

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]

Mobile

3G+ 3G GPS

Maps

Camera

ü ü ü

Mobile

3G+ 3G GPS

Maps

Camera

Domain/Variability Model

ConfiguraCon SoSware Generator

Domain Artefacts

Domain Engineering

ApplicaCon 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)

40

99% domain engineering, 1% applicaCon engineering?

–  specifies 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

Variability AbstracCon Model (VAM)

ConfiguraCon (resoluCon model)

Domain Artefacts (e.g., models)

SoSware Generator (derivaCon engine)

ü ü

Variability RealizaCon Model (VRM)

Configurations Derivation Process

Models of the “system”

Feature Model

How to realize the variability

(another research area/applicaWon: adapWve systems aka dynamic so6ware product lines [email protected])

hip://www.kevoree.org

from Cloud stack to embedded devices

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

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

VariaCon Point Types

•  Variability is applied to different parts of the metamodel – AggregaWon, associaWon, abribute value, property set

•  ResulWng variability – OpWonal component – OpWonal port – OpWonal connector – Parameter variability

Component

Port


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

Safe composiWon? No!

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

Ooops

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

Another approach

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

56 « Reconciling AutomaWon and Flexibility in Product DerivaWon » Gilles Perrouin, Jacques Klein, Nicolas Guelfi, Jean-‐Marc Jézéquel SPLC’08

Merging-‐based DerivaCon of Product

Variability at the language level

58

Variability in Metamodeling •  SemanWc variaWon point •  DSML Families •  Knowledge capitalizaWon •  Language Engineering

Variability in Modeling

Variability

Variability

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 define and manage semanBc variability (in the DSML and the associated tools)?

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)

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 specific 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)

63


64


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

65

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

FraSCAC Architecture

Set of Safe Variants

authorized by FraSCAC

Scope is too large

Illegal Variant

66

67

FraSCAC 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

ConfiguraCon Derived FraSCAC Architecture



68

Plan

Variability Model

ConfiguraCon

Domain Artefacts (e.g., source code)

SoSware Generator

Modeling variability is crucial ü ü

70

Unused flexibility

71

Illegal variant

72 72

Extensible architect

ures

(plugins-‐based)

ConfiguraCon

files

System

Preferences

Configurators

Source code

Build systems

Comparison of Product

Variability AbstracCon Model (VAM) CommunicaCve AnalyCc GeneraCve 73

not, and, or, implies

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

Feature Models

76

Feature Models (Background)

77

Hierarchy: rooted tree Variability: •  mandatory, •  opWonal, •  Groups: exclusive or inclusive features •  Cross-‐tree constraints

Optional

Mandatory

Xor-Group

Or-Group

78

Hierarchy + Variability =

set of valid configuraCons

ü

{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning, FrontFogLights}

configuraCon = set of features selected

Optional

Mandatory

Xor-Group

Or-Group

79



ü

{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning}


Optional

Mandatory

Xor-Group

Or-Group

80



ü

Optional

Mandatory

Xor-Group

Or-Group

{CarEquipment, Comfort, DrivingAndSafety, Healthing, AirCondiWoning, AutomaWcHeadLights}


ü ü

ü

ü

ü

ü

81



ü

ü

Optional

Mandatory

Xor-Group

Or-Group

{AirCondiWoning, FrontFogLights} {AutomaWcHeadLights, AirCondiWoning, FrontFogLights} {AutomaWcHeadLights, FrontFogLights, AirCondiWoningFrontAndRear} {AirCondiWoningFrontAndRear} {AirCondiWoning} {AirCondiWoningFrontAndRear, FrontFogLights}

{CarEquipment, Comfort, DrivingAndSafety, Healthing} X

Feature Models

82

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

85

Optional

Mandatory

Xor-Group

Or-Group

86

Optional

Mandatory

Xor-Group

Or-Group

87

Optional

Mandatory

Xor-Group

Or-Group

{AirCondiWoning, FrontFogLights} {AutomaWcHeadLights, AirCondiWoning, FrontFogLights} {AutomaWcHeadLights, FrontFogLights, AirCondiWoningFrontAndRear} {AirCondiWoningFrontAndRear} {AirCondiWoning} {AirCondiWoningFrontAndRear, FrontFogLights}

{CarEquipment, Comfort, DrivingAndSafety, Healthing}

X

(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


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

91

#2 MulCple Feature Models

92

93 93

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

•  #1 Automated analysis –  Aka support to beber understand and play with your feature model (TVL model)

•  #2 Managing mulCple feature models –  Composing / Decomposing / Diff and Reasoning about their relaWonships

–  Combining these operators 94

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

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

Hello World

97

helloworld.fml Optional

Mandatory

Xor-Group

Or-Group

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

Typed language

99

basics2.fml

Typed language

100

basics2.fml

Optional

Mandatory

Xor-Group

Or-Group

ImporCng/ExporCng feature models

101

FAMILIAR

S2T2TVL

feature-model-synthesis

(visual configurator)

(language)

(language)FaMa

Internal notaWon or by “filename extensions”

basics3.fml

Feature Accessors (1)

102

6Accessors.fml

Optional

Mandatory

Xor-Group

Or-Group

Other constructs

103

6Accessors2.fml

Optional

Mandatory

Xor-Group

Or-Group

ConfiguraCon

104

conf.fml Optional

Mandatory

Xor-Group

Or-Group

105

φ FM

A ^ A ó B ^ C => A ^ D => A

Optional

Mandatory

Xor-Group

Or-Group

OperaCons for Feature Models (1)

106 φ

operatorsFM.fml

Optional

Mandatory

Xor-Group

Or-Group


107

φ

operatorsFM2.fml

Optional

Mandatory

Xor-Group

Or-Group


108

operatorsFM3.fml

Optional

Mandatory

Xor-Group

Or-Group

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.

Composing Feature Models (1)

110

aggregateBasics.fml

Optional

Mandatory

Xor-Group

Or-Group


111

aggregate1.fml

Previous version

Optional

Mandatory

Xor-Group

Or-Group


112

mergeMI.fml

Mathieu Acher, Philippe Collet, Philippe Lahire, Robert B. France « Comparing Approaches for ImplemenWng Feature Model ComposiWon » ECMFA’10

see also Thuem, Kastner and Batory, ICSE’09

Comparing Feature Models

113

compare.fml

Optional

Mandatory

Xor-Group

Or-Group

Merge IntersecCon: Available Suppliers

115

∩ ∩

A customer has some

requirements

Suppliers? Products?

In FAMILIAR

116

suppliersExample0.fml

Merge Union: Availability Checking

117

Can suppliers provide all products? Yes!

“compare”

∩

Optional

Mandatory

Xor-Group

Or-Group

In FAMILIAR

118

suppliersExample.fml

Merging operaCon: implementaCon issues

119

How to synthesise a feature model that represents the union of input sets of configuraCons?

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

120

Merging operaCon: semanCc issues (2)

φ Union IntersecWon Diff How to synthesise a feature model that represents

the union of input sets of configuraCons?

Merging operaCon: algorithm

121

φ1

φ2

φ3

φ 123

merged proposiWonal 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 configuraCons?

see also [Czarnecki SPLC’07 or SPLC’12]

Optional

Mandatory

Xor-Group

Or-Group

Merging operaCon: back to hierarchy

122

mergeNonPC.fml

> configs 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

see also [Acher et al., ECMFA’10 / MODELS’13]

– Well-‐defined 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 •  Different hierarchies [Van Den Broek et al., SPLC’2010/2012]

– SyntacWcal strategies fail [Alves et al., 2006], [Segura et al., 2007] 123

Related Works

125

Problem: mulCple „car models“

126


127


128


#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

129

#1 top-‐down

130

#1 boiom-‐up FM_1

FM_2

FM_3

FM_r merge

131

#1 boiom-‐up (FAMILIAR) FM_1

FM_2

FM_3

FM_r merge

audiMerge.fml

133

Building “views” of a feature model

•  Problem: given a feature model, how to decompose it into smaller feature models?

•  SemanWcs? – What’s the hierarchy – What’s the set of configuraWons?

134

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 ConfiguraCon maier! 135

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, represenWng a projected set of configuraWons

136

Slicing operator: going into details projected set of configuraCons

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

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

138

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 « SeparaWon of Concerns in Feature Modeling: Support and ApplicaWons » AOSD’12

Optional

Mandatory

Xor-Group

Or-Group

T

S E D


139

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

140

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 Sofware 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 « SeparaWon of Concerns in Feature Modeling: Support and ApplicaWons » AOSD’12

Optional

Mandatory

Xor-Group

Or-Group

With FAMILIAR

144

realizibility.fml

146

RevisiCng Merge: Aggregate + Slice

Optional

Mandatory

Xor-Group

Or-Group

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

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

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

φ

« 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 addiWonal informaWon) consistent, « parCal » (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» 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

φ

φ

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 specificaWon (consistency and completeness) concrete syntax and tooling suport

#2 PracCcal applicaCons reverse engineering, refactoring/re-‐engineering of feature models


Automated support is highly needed (ongoing work)



156

Plan

Variability AbstracCon Model (VAM)

ConfiguraCon (resoluCon model)

Domain Artefacts (e.g., models)

SoSware Generator (derivaCon engine)

ü ü

Variability RealizaCon Model (VRM)


Models of the “system”

Feature Model


Printer´Blockª

mainSupply:MainPower1

Attributes

Operations

powerCtrl

emgSupply:EmgPower1

Attributes

threshold:int

Operations

powerCtrl

inputSection1

highSpeedConnector1

Attributes

Operations

MainPowerCtrl EmgPowerCtrl

MainPower´Blockª

Values

Operations

powerCtrlEmgPower´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


Printer´Blockª

mainSupply:MainPower1

Attributes

Operations

powerCtrl

emgSupply:EmgPower1

Attributes

threshold:int

Operations

powerCtrl

inputSection1

highSpeedConnector1

Attributes

Operations

MainPowerCtrl EmgPowerCtrl

MainPower´Blockª

Values

Operations

powerCtrlEmgPower´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


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


Derivation of Traffic Lights Models

Joao Bosco Ferreira Filho (PhD student)

Traffic Lights

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

Traffic Lights FSM

Traffic Lights FSM

OBJECTIVE:

Produce the finite state machine associated with each traffic light configuration

. Simplification:

- Green Light - Red Light - Yellow Light

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

DSL metamodel

Base model

. Create the base model:

1. Create a Modelling project

2. Create a new model in the DSL

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

Resolution model

Product derivation

Derived FSM

Visualisation of products in a web configurator

Marianela Ciolfi Felice (MSc student)

Marks & Spencer web configurator

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

Anticipating all possible combinations

§  10 configuration options §  10 possible values for each of

them

10.000.000.000 combinations!

Composing the visualisation

PRODUCT CONFIGURATION VISUAL REPRESENTATION

Models

HTML

jpg, png, ..., files SVG files

Javascript

3D models

Feature

models


Visual representation of a product

Feature Model


Visual elements

. Simplification:

- Fabric - Collar - Pocket (optional) - Handkerchief (optional)

Shirts web configurator

Shirts web configurator

OBJECTIVE:

Produce the visual representation associated with each shirt configuration

. Simplification:

- Fabric - Collar - Pocket (optional) - Handkerchief (optional)

Feature model

- Implicit boolean attribute existence - No constraints

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

DSL metamodel

Base model

. Create the base model:

1. Create a Modelling project

2. Create a new model in the DSL

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

VAM

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

Resolution model

Product derivation

Summary: Variability Model Management

202 202 202



203

Key Insights

(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