Modeling Variability VARIETE,DFFSAPERE AUDE Andrzej W ˛Asowski

Role of Flanders Make Look forward, follow trends 1 and define research roadmaps

Anticipate, help formulate and tackle challenges 2 and opportunities, to inspire companies

Strengthen companies’ competences through a 3 dynamic, collaborative innovation ecosystem

4 Create & transfer knowledge

Connect companies, research 5 institutions and knowledge centres Innovation

Technology readiness level From lab to industrial environment UNIVERSITIES Competence through development / Market technology From collaboration technology readiness leaders to early INDUSTRY adopters level additional Involvement VALORISATION PARTNER companies of of 3 2 1 technology productThe develop Universities development and Flanders offers new Make and knowledge lay reaches ideas the market involves & foundation, technologies for readiness partners further FLANDERS MAKE MEMBER COMPANY ECOSYSTEM

2014: NUMBER OF 2019: #56 MEMBERS #134 3 co-creation centres and labs at the 5 Flemish Universities

- Lommel

- Kortrijk @

- Leuven € 60 mln @ @ turnover 600 highly specialised researchers 3 co-creation centres

Co-creation Centre Co-creation Centre Co-creation Centre Vehicle Machine Customised production - development development Industry 4.0 Lommel Leuven Kortrijk 4200 m² 3500 m² 6000 m² Fields of application

1 2 3

Production Machines Vehicles Research supporting the digitalisation of the manufacturing industry clustered around 4 competences

Decision Design & Motion Flexible & Control optimisation products assembly Design & optimisation HOW AND WHICH TECHNOLOGIES? Research track Simultaneous model-based design 1 of hardware & software for smart GOAL systems

Model-based design of assembly 2 systems enabling high product Methods and tools variability to manage design complexity & efficiency Design that takes into account 3 the (financial) impact of product Design & lifecycle phases optimisation Efficient design of product 4 variants & product families Modelling Variability in Mechatronics Systems Design Smart, interconnected products and production systems

Daimler (press release 2015) Mercedes-Benz E-class 100 mio lines of code

Mechanical system Mechatronic system

Increase in components, functions, technologies & disciplines => higher COMPLEXITY Customized products

One product Product family Mass customisation

Increase in variants => higher COMPLEXITY Managing Variability

https://www.youtube.com/watch?v=nd4tPauouQk DSM-TP 2016 — Modeling Variability VARIETE,DFFSAPERE AUDE Andrzej W ˛asowski

PROCESS AND SYSTEM MODELS GROUP Drowning in Clone-And-Own

blue.cc blue.cc blue.cc ? CHANGE

BUG FOUND INDEPENDENT INDEPENDENTLY BUG FIXES blue.cc

green.cc green.cc green.cc

c Andrzej W ˛asowski, IT University of Copenhagen 2 Opportunistic Reuse Does Not Work

I Common scenario: version the code, reuse when opportunity appears

I If the ﬁle to be reused needs change, copy it You clone-and-own it

I Beneﬁt from quickly available functionality

I But have to test, debug, change and product build code system evolve the ﬁle yourself

I Product speciﬁc code grows product build I Platform code diminishes code system shared and degrades platform code product build code system

product build code system

c Andrzej W ˛asowski, IT University of Copenhagen 3 SUCCESSFUL REUSE IS

PROACTIVE PLANNED MANAGED

c Andrzej W ˛asowski, IT University of Copenhagen 4 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 5 Domain vs Application Processes Pohl et. al. Software Product Line Engineering

c Andrzej W ˛asowski, IT University of Copenhagen 6 A Simple Product Line Architecture variability variability abstraction

# configured against conforms # CPUFreq processor drivers # CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K6=y CONFIG_X86_POWERNOW_K7=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_GX_SUSPMOD=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=y CONFIG_X86_LONGRUN=y CONFIG_X86_LONGHAUL=y variability variability resolution CONFIG_X86_E_POWERSAVER=m build system

core assets platform product specific assets variability variability realization

I Less product speciﬁc = more reuse: development/tests/debugging/build

I Model of commonality and variability.

I Scope under control. Explicit feature life cycle

c Andrzej W ˛asowski, IT University of Copenhagen 7 Exploit commonality Manage variability

c Andrzej W ˛asowski, IT University of Copenhagen 8 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 9 Spectrum of Variability Architectures Stay as close to the left as possible only product specific code (no reuse) frameworks + framework completion code domain specific languages + code generation

feature models + product specific code feature models + build system property & configuration files + build system

c Andrzej W ˛asowski, IT University of Copenhagen 10 Implementation Technologies

I Variability abstraction: FMs, DSLs, or none

I Variability resolution: XML property file FM configuration Domain specific model (DSM)

I Variability realization: general purpose code w/ variability techniques code generators model transformers

parts may use DSLs variability abstraction

# configured against conforms # CPUFreq processor drivers # etc. CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K6=y CONFIG_X86_POWERNOW_K7=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_GX_SUSPMOD=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=y CONFIG_X86_LONGRUN=y CONFIG_X86_LONGHAUL=y variability variability resolution CONFIG_X86_E_POWERSAVER=m build system

core assets platform variability variability realization

c Andrzej W ˛asowski, IT University of Copenhagen 11 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 12 Problem Space Solution Space

features

SMS notification on transaction variation points SMSLoggerAspect paid services Phone No. in data model

invoice code.cs

int sort (int[] A, comp ope) { if (A == null) return -1;

for (int i = 0; i < A.size(); I++) { print (A[i].toString()); } }

c Andrzej W ˛asowski, IT University of Copenhagen 13 CVL Architecture for Dummies The degree of coupling can be controlled by moving the mapping

Variability Abstraction Feature/Decision Models

Variability Realization Feature Mapping

Base (model) Source Code

CVL submitters. Common Variability Language, OMG Revised Submission. 2012

c Andrzej W ˛asowski, IT University of Copenhagen 14 Feature Modeling (I)

feature: a single variability increment in the problem domain (decision)

variation point: a single variability increment in the solution space

c Andrzej W ˛asowski, IT University of Copenhagen 15 Feature Modeling (II) Example from Czarnecki’02

car

mandatory

optional body engine transmission pulls trailer exclusive choice

inclusive choice electric gasoline automatic manual

I Hierarchy constraints, for example: manual requires transmission (each child node requires its parent node)

I Groups constraints: engine is electric or gas driven or both

I Not all constraints in hierarchy & groups, cross-tree constraints in text: electric requires automatic

I Attributes are added like to classes (eg. engine volume)

c Andrzej W ˛asowski, IT University of Copenhagen 16 Feature Modeling (III) Conﬁguration

car

mandatory

optional body engine transmission pulls trailer exclusive choice

inclusive choice electric gasoline automatic manual

electric requires automatic + + + + + + +

c Andrzej W ˛asowski, IT University of Copenhagen 17 Feature Models (IV) An example meta-model from Janota’08 meta-model (abstract syntax)

0..* 1 1 Sub-feature Group 1 Feature Relation Type

is sub-feature 0..* Grouped Solitary Mandatory Optional OR-group XOR-group Root Feature 2..* Feature Feature Sub-feature Sub-feature a. The metamodel

Root Feature or-group car Mandatory xor-group Sub-feature I Note a singleOptional generic kind of relations: subfeature Sub-feature

I No distinction betweenpower-locks kind-ofcar-body(inheritance)gearshift and part-of e(containment),ngine like class modeling does

I A characteristic feature of conﬁgurationmanual andautomatic constraintgas languageselectric (as opposed to structural modeling languages) b. An example of a feature diagram, inspired by [7] I Clafer (as a structural modeling langauge) supports the distinction, but so doFig. other 6. The feature Language modeling of Propositional languages Feature Diagrams

c Andrzej W ˛asowski, IT University of Copenhagen 18 4 Background: Propositional Feature Models

Let us recall the language of feature models, exploited as an example in the upcoming sections. Feature models [15] are used to systematically describe variability and commonality in product line engineering [4]. In a nutshell, a feature corresponds to a specific functionality of a system. A feature model records available features, together with constraints and dependencies relating them. A variety of feature diagram languages is found in the literature, mostly with propositional semantics [21]. We should note, however, that other semantics ex- ist, for instance using grammars [2], higher-order [12] and probabilistic [8] logic. In this article we operate on the combinatorial core of feature models, the propositional models [7]. A propositional feature model comprises a feature diagram and a constraint. The diagram is the centerpiece. It records the features and dependencies in a graph-based notation. An additional constraint is appended if it cannot be expressed in the diagrammatic language itself. A feature diagram organizes features in a tree, containing a node for each feature. A child node, or a sub-feature, is either optional, mandatory, or grouped. A grouped feature belongs either to an or-group or an xor-group with other sub-features of the same parent. Fig. 6a shows the metamodel of this language. Apart from hierarchically organizing the features, the purpose of the diagram is to determine which combinations of features, so-called feature configurations, are permitted. The root feature must be present in all configurations. A sub- feature must not be selected into a configuration not containing its parent. A mandatory feature is required by its parent, whereas an optional one is not. From features grouped in an or-group (resp. xor-group) at least one (resp. exactly one) must be selected whenever the parent is selected. The feature diagram in Fig. 6b describes possible configurations of a car. Each car must have a body, gearshift, and engine; an engine is electric or gas (selecting both corresponds to a hybrid engine); a gearshift is either automatic or manual. Feature Modeling and FODA Feature Oriented Design and Analysis by Kang et al. 1990

I FODA succeeds for its simplicity

I Probably best intro in Czarnecki’s Generative Programming (Chpt. 4)

I 3950+ citations, never formally published

c Andrzej W ˛asowski, IT University of Copenhagen 19 Feature Modeling vs Class Modeling A feature model in Product Variant Master Notation (Hvam) A feature model

A roughly equivalent class diagram

More on this: B ˛ak. Czarnecki. W ˛asowski. Feature and Meta-Models in Clafer: Mixed, Specialized, and Coupled. SLE 2010 Above models from: Haug. Degn. Poulsen. Hvam. Creating a documentation system to support the development and maintenance of product conﬁguration systems

c Andrzej W ˛asowski, IT University of Copenhagen 20 Applications of Feature Models

Design & Management

domain product line scoping modeling product line mngmt

code generation driving driving build system testing

Development & Test

c Andrzej W ˛asowski, IT University of Copenhagen 21 How To Build Feature Models? Two strategies, but only one good :)

top-down bottom-up

I Identify a cloned component I Big-bang adoption Find the patches that describe Perform careful domain I I differences analysis Translate diffs to variation Document concepts, I I points abstractions and relations between them in a FM I Organize variation points into features, and a hierarchy

I Works well with incremental adoption

I See SPLC07 paper by Danfoss

Hans Peter Jepsen, Jan Gaardsted Dall, Danilo Beuche. Minimally Invasive Migration to Software Product Lines. SPLC 2007 c Andrzej W ˛asowski, IT University of Copenhagen 22 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 23 Variability Modeling is The Success Story of Modeling

c Andrzej W ˛asowski, IT University of Copenhagen 24

A Laboratory Feature Model

Czarnecki, W ˛asowski. Feature Diagrams and Logics: There and Back Again. In: 11th International Software Product Line Conference (SPLC 2007) Kyoto, Japan, 10-14 September, 2007 c IEEE Press. c Andrzej W ˛asowski, IT University of Copenhagen 27 A Healthy Wild Feature Model Cub ToyBox project, 71 features

ToyBox

Global settings Toys

DEBUG FREE TOYBOX ONEIT DIRNAME MKFIFO PATCH TTY TOYSH BASENAME UNAME MKSWAP BZCAT SLEEP CKSUM CHROOT TEE ECHO SED CP WHICH PWD SEQ RMDIR MKE2FS FALSE COUNT SHA1SUM TRUE TOUCH DF CAT CHVT HELP SORT READLINK DMESG HELLO NETCAT YES SYNC MDEV CATV

PIPES FLOWCTL CD EXIT P QUOTES BUILTINS TTY GEN EXTENDED JOURNAL LABEL PEDANTIC LONG BIG F LISTEN CONF

WILDCARDS PROCARGS ENVVARS JOBCTL PROFILE

LOCALS

ARRAYS

The Linux Kernel has 6-12K features, depending how you count! But maximum depth is 8, most leaves are at 4!

↓ this is the Linux kernel model ﬁt to the slide width ↓

Berger, She, Lotufo, W ˛asowski, Czarnecki. A Study of Variability Models and Languages in the Systems Software Domain. IEEE Transactions in Software Engineering, 2013 c Andrzej W ˛asowski, IT University of Copenhagen 28 Is FODA special? Not really! eCos conﬁgurator

I Linux kernel and eCos operating system use similar conﬁgurator, controlled by textual variability models

I Trees become unwieldy very fast

I Many tools used linearized trees, like above

I Nice trees are good for PowerPoint, whiteboard and brainstorming

c Andrzej W ˛asowski, IT University of Copenhagen 29 It is easy to design a textual syntax Kconﬁg of Linux kernel, designed by non-experts, with no tools CDL of eCos, designed by non-experts, with no tools

c Andrzej W ˛asowski, IT University of Copenhagen 30 CVL Architecture for Dummies The degree of coupling can be controlled by moving the mapping

Variability Abstraction Feature/Decision Models

Variability Realization Feature Mapping

Base (model) Source Code

CVL submitters. Common Variability Language, OMG Revised Submission. 2012

c Andrzej W ˛asowski, IT University of Copenhagen 31 CVL Architecture for Linux Junkies

Variability Abstraction KConﬁg ﬁles

Variability Realization KBuild ﬁles + CPP

Base (model) C-code

c Andrzej W ˛asowski, IT University of Copenhagen 32 Grid View in Pure•Variants

I Commercial tools support multiple views of the same model

I Some vendors: Pure Systems (DE), Big Lever (US), most PLM tools

I Clafer also has the grid view

c Andrzej W ˛asowski, IT University of Copenhagen 33 Are all variability models trees? A Fire Alarm System

I detection zones

I alarm zones

I wiring

I three different structures

I Modeled as constrained class diagrams!

I Sometimes called topological variability

Berger. Stanciulescu. Øgård. Haugen. Larsen. W ˛asowski. To connect or not to connect: experiences from modeling topological variability. SPLC 2014 Fantechi. Topologically conﬁgurable systems as product families. SPLC 2013 c Andrzej W ˛asowski, IT University of Copenhagen 34 Modeled using class diagrams in Papyrus A model view showing two model hierarchies

Installation A home grown

logical structure conﬁgurator used [1] to instantiate mod- [*] els Domain OperationZone Group [*] [1]

[1] [1] [1] [*] [1] [1]

[1..*] [1..*] AlarmZone DetectionZone physical AutroSafePanel structure

ExternalComs OperationPanel AutroFieldBus AFB_Unit [1] [1] [1..32]

[0..7] [1] [1]

[1]

[1..32] IO_Module AL_ComInterface AFB_PowerControl PowerLoopDriver [1]

[*]

c Andrzej W ˛asowski, IT University of Copenhagen 35 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 36 Connect Abstraction to Realization Most of the school is about it :) variability variability abstraction

core assets platform product specific assets variability variability realization

c Andrzej W ˛asowski, IT University of Copenhagen 37 Feature Models vs DSLs

Misc. Filesystems

Journalling Flash File System

Debug Level :int Compress Data

Support ZLIB Default Compression

None Priority Size Feature Model DSL Meta- Model

conforms to conforms to

# # CPUFreq processor drivers # CONFIG_X86_PCC_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K6=y CONFIG_X86_POWERNOW_K7=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_GX_SUSPMOD=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y CONFIG_X86_SPEEDSTEP_ICH=y CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_CPUFREQ_NFORCE2=y CONFIG_X86_LONGRUN=y CONFIG_X86_LONGHAUL=y Configuration CONFIG_X86_E_POWERSAVER=m DSL Model

I Feature models are ready and simple (no design effort, deep insight)

I DSL requires design effort, but rewards with more expressiveness

I Effort also translates to maintenance

I FM effort is offset by existing feature modeling tools

I DSL development effort is offset by language workbenches

c Andrzej W ˛asowski, IT University of Copenhagen 38 Advice on Realization [Stahl and Völter]

I Choose functional domain concepts as features / DSL concepts

I Start a small domain model and grow it iteratively

I Keep the build automatic at all times

I Generate/synthesize legible code/models

I We follow these principles in the Clafer tutorial on railway stations

c Andrzej W ˛asowski, IT University of Copenhagen 39 c Andrzej W ˛asowski, IT University of Copenhagen 40 c Andrzej W ˛asowski, IT University of Copenhagen 41 I SPL Method, Architecture

I Variability Implementation Spectrum

I Variability Abstraction: Feature Modeling

I Variability Modeling in Practice

I Variability Realization AGENDA

c Andrzej W ˛asowski, IT University of Copenhagen 42 FLANDERS MAKE making the industry stronger and more competitive

Interested to join our team? Find our open positions and apply at

https://jobs.flandersmake.be Bart Meyers [email protected]