31. feature models and mda for product lines -...

Fakultät Informatik - Institut Software- und Multimediatechnik - Softwaretechnologie – Prof. Aßmann - Softwaretechnologie II

31. Feature Models and MDA for Product Lines

Prof. Dr. U. Aßmann

Technische Universität Dresden

Institut für Software- und Multimediatechnik

Gruppe Softwaretechnologie

http://st.inf.tu-dresden.de/teaching/swt2

Version 16-0.1, 14. Januar 2017

1. Feature Models

2. Product Linie Configurationwith Feature Models

3. Multi-Stage Configuration

4. Multi-Stage Configurationof Transformations

Softwaretechnologie II

Literature

Ø Florian Heidenreich, Jan Kopcsek, and Christian Wende. FeatureMapper: Mapping Features to Models. In Companion Proceedings of the 30th International Conference on Software Engineering (ICSE'08), Leipzig, Germany, May 2008.• http://featuremapper.org/files/ICSE08-FeatureMapper--Mapping-Features-to-

Models.pdf

Ø Paul C. Clements, Linda M. Northrop: Software Product Lines: Practices and Patterns. Addison-Wesley Professional, 2001.

Ø Sven Apel, Don Batory, Christian Kästner, Gunter Saake:Feature-Oriented Software Product Lines – Concepts and Implementation. Springer, 2013.

Pro

f. U

. Aßm

ann

2


References

Ø [Aßm03] U. Aßmann. Invasive Software Composition. Springer, 2003.Ø [TraCo] Florian Heidenreich, Jan Kopcsek, and Uwe Aßmann. Safe composition of

transformations. Journal of Object Technology, 10:7: 1-20, 2011. Ø [Cza05] K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template

Approach Based on Superimposed Variants. In R. Glück and M. Lowry, editors, Proceedings of the 4th International Conference on Generative Programming and Component Engineering (GPCE'05), volume 3676 of LNCS, pages 422-437. Springer, 2005.

Ø [Cza06] K. Czarnecki and K. Pietroszek. Verifying Feature-Based Model Templates Against Well-Formedness OCL Constraints. In Proceedings of the 5th International Conference on Generative Programming and Component Engineering (GPCE'06), pages 211-220, New York, NY, USA, 2006. ACM.

Ø [Hei08a] F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Mapping Features to Models. In Companion Proceedings of the 30th International Conference on Software Engineering (ICSE'08), pages 943-944, New York, NY, USA, May 2008. ACM.

Ø [Hei08b] Florian Heidenreich, Ilie Şavga and Christian Wende. On ControlledVisualisations in Software Product Line Engineering. In Proc. of the 2nd Int‘l Workshop on Visualisation in Software Product Line Engineering (ViSPLE 2008), collocated with the12th Int‘l Software Product Line Conference (SPLC 2008), Limerick, Ireland, September 2008.

Ø [Hei09] Florian Heidenreich. Towards Systematic Ensuring Well-Formedness of Software Product Lines. In Proceedings of the 1st Workshop on Feature-Oriented Software Development (FOSD 2009) collocated with MODELS/GPCE/SLE 2009. Denver, Colorado, USA, October 2009. ACM Press

Pro

f. U

. Aßm

ann

Slide 3


Software Development in the V-Model

Ø The most simple software development process is the V-model, but for software product lines (SPL) we need other processes

Ø Software Product Line Engineering (SPLE) is the discipline of creating product lines

© P

rof.

U. A

ßman

n

4

Pre-Study•Product concept catalogue(Lastenheft)

Requirements Analysis•Software Requirement Specification(SRS)

Achitectural Design•Architecture (Grobentwurf)

Detailed Design•(Feinentwurf)

Implementation

Acceptance Test

Installation, Beta Test

System Test (in-house)

Component, Subsystem Test

Contracts, Class Tests

System test cases

Unit testcases

Acceptancetest cases


analysismodel

domainmodel

usecases

textualrequirements(stories)

architectural design

detailed design

analysismodel

contextmodel

requirementsspecification

Object-Oriented Analysis vs Object-Oriented Design

Prof. U. Aßmann


Extended to Model-Driven Architecture (MDA)

Ø Horizontal product line: one product idea in several markets

Pro

f. U

. Aßm

ann

6

analysismodel

usecases

textualrequirements(stories)

Platformindependentmodel

Platform-1specific model


Platform-(1,.., n)specific model

domainmodel

contextmodel

analysismodel(CIM)


usecases

textualrequirements(stories) Product 1

Product 2


Product n

domainmodel

contextmodel

Software Product Lines (Software Product Families)P

rof.

U. A

ßman

n

7

analysisModel

FeatureModel(varabilitymodel)


Model weaving

Platform-1 specificmodel (PIM)

Platform-1-specificextension (PSE)

Platform independentmodel (PIM)

Model weaving

Platform-(1+2) specificmodel (PSM)

Platform-2 specificextension (PSE)

Adding Extensions to Abstract Models in the MDA

Ø In the following, we extend the MDA (below) with configuration

Pro

f. U

. Aßm

ann

8


Variants

VariantsVariants

Analysis Model

Product Line Model(Framework, VIM)

Product PSM

Product PIM

Domain Model

Variants

ConfigurationWithFeatureModel

Configuration of Variabilities in Vertical Product Lines (MDA for Vertical Product Lines)

► Vertical product line: several products (different feature sets) in one or several markets

► The VIM (variant independent model) is the common model of the product family

Prof

. U. A

ßman

n

9

Product DesignVariants

ConfigurationWithFeatureModel

PSM Extensions

Model weaving

Model weaving

Product PSMProduct PSM


31.1 PRODUCT LINES WITH FEATURE TREES AND FEATURE MODELS

Prof. U. Aßmann Feature-driven SPLE10


Feature Models for Product Configuration

Ø Feature models are used to expressvariability in Product LinesØ alternative,Ø mandatory,Ø optional features, andØ their relations

Ø A variant model represents a concrete product (variant) from the product lineØ The variant model results from a selection of a subgraph of the feature

modelØ The variant model can be used to parameterize and drive the product

instantiation process

Pro

f. U

. Aßm

ann

11

OR

XOR


Feature Models

Ø The Feature Tree Notation is derived from And-Or-Trees

Pro

f. U

. Aßm

ann

12

Group of ANDFeatures

Group ofAlternative (XOR)

Features

FeatureA FeatureB

MandatoryFeature

Group ofOR Features

OptionalFeature

FeatureC FeatureD

PhD Thesis, Czarnecki (1998)based on FODA-Notation by Kang et al. (1990)


Example

Ø A1 or A2 or A3Ø B1; B2 xor B3Ø B4; optional B5Ø B1; B7

Pro

f. U

. Aßm

ann

13

A1 A2 A3

B1 B2 B4 B5 B6 B7B3


A Feature Model for Computer-Aided Cognitive Rehabilitation

Ø [K. Lehmann-Siegemund, Diplomarbeit]

Pro

f. U

. Aßm

ann

14

FM

A/K

K J E S CE CU NO NM

K J E S CE CU NO NM

gE gZ IS IT gE gZ gE gZ IS IT gE gZ IS IT

gE IS ITT A

[c1]T A

[c1]

gE gZ IS IT T A

[c1]

IS IT T A

[c1]

T A T A T A T A

. . .

IS IT

. . .

IS ITIS IT

[1-2] [1-2] [1-2] [1-2]

[1-2] [1-2] [1-2] [1-2]


Feature Models form a Specific Concern space

Ø Remember: Aspect-oriented modeling means to separate a concernspace from a component space

Ø In SPLE, the feature space forms a concern space; the component spaceis usually called the solution space

15

Concern Space(Aspektraum)

Concern 1

Concern 2

Aspekt 3

Component Space(Solution Space)

Concern mapping(Sichtenabbildung)

Perspective P

Perspective Q


Ex: Plugins have Features (in Eclipse)

Prof. U. Aßmann Feature-driven SPLE 16


31.1.2 MODEL-BASED PRODUCTLINES

Prof. U. Aßmann

Feature-driven SPLE 17


Mapping Features to Model Fragments (Model Snippets)

Ø Feature mapping bridges the gap between configuration space and solution space

Ø Possible artefacts in the solution space:Ø Models defined in DSLs; Model fragments (snippets)Ø Architectural artefacts (components, connectors, aspects)Ø Source code, Files

Ø A Model-based Product Line is a SPL with models in the component space

Pro

f. U

. Aßm

ann

18

Feature space

Feature 1

Feature 2

Feature 3

Component Space(Solution Space)

Feature mapping


31.2 PRODUCT-LINE CONFIGURATIONWITH FEATURE MODELS



Different Approaches of Variant Selection in an SPLAdditive approach

Ø Map all features to model fragments (model snippets)Ø Compose them with a core model based on the presence of the feature in

the variant model

Ø Pros: Ø conflicting variants can be modelled correctlyØ strong per-feature decomposition

Ø Cons:Ø traceability problemsØ increased overhead in linking the different fragments

Pro

f. U

. Aßm

ann

20


Different Approaches of Variant Selection (2)Subtractive approach

Ø Model all features in one modelØ Remove model elements based on absence of the feature in the variant

model

Ø Pros: Ø no need for redundant links between artifactsØ short cognitive distance

Ø Cons:Ø conflicting variants can't be modelled correctlyØ huge and inconcise models

Pro

f. U

. Aßm

ann

21


The Mapping Problem between Features and Solution Elements

Creation

Visualisation

Validation

Derivation

Pro

f. U

. Aßm

ann

Slide 22

FeatureA

FeatureCFeatureB

FeatureEFeatureD

ProblemSpace SolutionSpace

D

E

A B

F G


Mapping Features to Models

Ø FeatureMapper - a tool for mapping of feature models to modellingartefacts developed at the ST Group

Ø Screencast and paper available at http://featuremapper.org

Ø Advantages:Ø Explicit representation of mappings Ø Configuration of large product lines from selection of variants in feature trees

Ø Customers understandØ Consistency of each product in the line is simple to checkØ Model and code snippets can be traced to requirements

Pro

f. U

. Aßm

ann

23


FeatureMapperP

rof.

U. A

ßman

n

Slide 24


Mapping Features to Models

Ø We chose an explicit Mapping Representation in our tool FeatureMapperØ Mappings are stored in a mapping model that is based on a mapping

metamodel

Pro

f. U

. Aßm

ann

Slide 25

FeatureA

FeatureCFeatureB

FeatureEFeatureD

DFeatureC

EFeatureC

GFeatureE

FFeatureC

FeatureE

SolutionModelsFeatureModel MappingModel

D

E

A B

F G


From Feature Mappings to Model TransformationsP

rof.

U. A

ßman

n

26


Visualisation of Mappings (1)

Ø Visualisations of Feature Mappings by colors (as in AOP)Ø View construction: In many cases, developers are interested only in a

particular aspect of the connection between a feature model and realising artefacts• How a particular feature is realised?• Which features communicate or interact in their realisation?• Which artefacts may be effectively used in a variant?

Ø Solution of the FeatureMapper: MappingViews, a visualisation technique that provides four basic visualisations• Realisation View• Variant View • Context View• Property-Changes View

Pro

f. U

. Aßm

ann

Slide 27


Realisation View

Ø For one Variant Model, the realisation in the solution space is shown

Pro

f. U

. Aßm

ann

Slide 28

System

RelationshipFeatureB

Relationship

Relationship

FeatureModel Mapping


Variant View

Ø The variant view shows different variant realisations (variant models) in parallel

Pro

f. U

. Aßm

ann

Slide 29

System

Relationship

Relationship

Relationship


Address

Address


Context View

Ø The Context View draws the variants with different colors• Aspect-separation: each variant forms an aspect

Pro

f. U

. Aßm

ann

Slide 30

System

RelationshipAddress

Relationship

Relationship


Address

Address

Group

Group

Group

...

...

...


OtherFeature

Property-Changes ViewP

rof.

U. A

ßman

n

Slide 31

System

ArbitraryDepth

ArbitraryDepth


Recordedchange-setofchangingthecardinalityofthereflexiveassociationofGroup to

itselffrom1tomany


Textual Languages Support (1)

Ø Unified handling of modelling languages and textual languages by liftingtextual languages to the modelling level with the help of EMFText

Ø All >80 languages from the EMFText Syntax Zoo are supported, includingJava 5

Ø http://emftext.org

Pro

f. U

. Aßm

ann

Slide 32


Textual Languages Support (2)

Ø Aspect-related color markup of the code

Pro

f. U

. Aßm

ann

Slide 33


Mapping-based Derivation of Transformations

Ø Transformations in the solution space build the product

Pro

f. U

. Aßm

ann

Slide 34

FeatureA

FeatureCFeatureB

FeatureEFeatureD

DFeatureC

EFeatureC

GFeatureE

FFeatureC

FeatureE

SolutionModelsFeatureModel

MappingModel

D

E

A B

F G

DerivationOf Transformations

<<in>> <<out>>

FeatureA

FeatureCFeatureB

FeatureD

VariantModel

D

E

A B

<<in>><<in>>

Variant


31.3 MULTI-STAGE CONFIGURATION



FEASIPLE: A Multi-Stage Process Architecture for PLE

Ø Chose one variant on each levelØ Feature Tree as input for the configuration of the model weavings

Pro

f. U

. Aßm

ann

36


FEASIPLE: A Multi-Stage Process Architecture for PLE

Ø Goal: a staged MDSD-framework for PLE where each stage produces the software artefacts used for the next stage

Pro

f. U

. Aßm

ann

37


Advantages of FEASIPLE

Ø Characteristic feature 1:Ø Variability on each stage

Pro

f. U

. Aßm

ann

38



Ø Characteristic feature 2:Ø Different modelling languages, component systems and composition

languages per stage

Pro

f. U

. Aßm

ann

39



Ø Characteristic feature 3:Ø Different composition mechanisms per stage

Pro

f. U

. Aßm

ann

40



Ø Characteristic feature 4:Ø Composition mechanisms are driven by variant selection

Pro

f. U

. Aßm

ann

41


31.4 MULTI-STAGE CONFIGURATION OF TRANSFORMATIONS

Feature-driven SPLE 42


Multi-Staged Derivation of Transformations

Ø How do we compose transformations? Between different stages?

Pro

f. U

. Aßm

ann

Folie 43

VariantIndependentModelfunctionalFeatureModel

platformFeatureModel

contextFeatureModel

M2C Generators

PlatformSpecificCode

M2M Trafos

M2M Trafos

Platform Independent ModelsPlatform Independent ModelsPlatformIndependentModels

Platform Specific ModelsPlatform Specific ModelsPlatformSpecificModels

VIM Mapping

PIM Mapping

PSMMapping


TraCo: A Framework for Safe Multi-Stage Composition of Transformations

Ø TraCo encapsulates transformations into composable components [TraCo] • Arranges them with composition programs of parallel and sequential transformation

steps (multi-threaded transformation

Pro

f. U

. Aßm

ann

Folie 44

T1M1V1

SA1

SA2

T2M2V2

SA3

SA1*

T1* M1* V1*

SA2*

…

TnMnVn

SAn

SAn-1

V1 Feature SelectionM1 MappingSA1 Solution ArtefactT1 Transformation

Functional variant

Platform variant

Context variant


Steps in Multi-Staged Derivation of Transformations

1. In TraCo, Transformations are represented as composable components2. Definition and Composition of Transformation Steps

• A Composition System is needed (course CBSE): Allows for reuse of arbitrary existing transformation techniques

3. Validation of each transformation and composition step• Type-checking• Invariant- and constraint-checking• Correctness of port and parameter binding• Static and dynamic analysis

4. Execution of composition program

Pro

f. U

. Aßm

ann

Slide 45

Component

Adapter

ActualTransformation

Code

references

Component instances

Connectors

Constant value


Multi-Staged Derivation of Transformations

Ø Implemented in our tool TraCo

• Component Model,• Composition Language,• Composition Technique

Pro

f. U

. Aßm

ann

Slide 46


Composition Programs can be Configured (Metacomposition)

„Anything you can do, I do meta“ (Charles Simonyi)

Ø The composition program shown in the last slide can be subject to transformation and composition

Ø If we build a product line with TraCo, platform variability can be realised by different transformation steps

Ø A TraCo composition program can be used with FeatureMapper• Multi-Staged transformation steps• Even of composition programs

Ø More about metacomposition in CBSE course

Pro

f. U

. Aßm

ann

Folie 47


Janu

ary

2011

Folie 48Load Domain Model

Load Actions Model

Load ApplicationState

Model

Load User Interface Model

Load Navigation Model

VIM to VSM Domain Model to UML

Attributes to Properties UML to Java

Add EJB Semantics

VIM to VSM

Actions Model to SimpleImpl UML

Actions Model to SimpleDelegateUML

UML to Java

UML to Java

Actions to EJB UML

Actions to EJB Delegate UML

Add EJB Persistence Semantics

Add Local Memory Semantics

UML to Java

UML to Java

VIM to VSM ApplicationState Model to UML

Attributes to Properties UML to Java

VIM to VSM

Ensure Control IDs SWT User Interface

JSP User Interface

VIM to VSM Navigation Model to Java

Navigation Model to JSP

Presentation

SWT

JSP

Business Logic

JavaEJB

Persistence

Mixed

In-Memory

EJB Persistence

EJB + In-Memory

EJB + EJB Persistence

Domain

Actions

ApplicationState

User Interface

Navigation

Loading FunctionalVariability

PlatformVariability


The final frontier: Ensuring Well-formedness of SPLs

Ø Motivation: Make sure that well-formedness of all participating models is ensured • Feature Model• Mapping Model• Solution Models

Ø Well-formedness rules are described using OCL

Ø Constraints are enforced during mapping time

Pro

f. U

. Aßm

ann

Slide 49


Case Studies with FeatureMapper, TraCo, and FEASIPLE

Ø Simple Contact Management Application Software Product Line• FeatureMapper used to map features to UML2 model elements• Both static and dynamic modelling

Ø Simple Time Sheet Application Software Product Line• FeatureMapper used to tailor ISC composition programs• ISC used as a universal variability mechanism in SPLE• Meta Transformation

Ø SalesScenario Software Product Line• FeatureMapper used to tailor models expressed in Ecore-based DSLs• was developed in project feasiPLe (http://www.feasiple.de)

Ø TAOSD AOM Crisis Management System

Pro

f. U

. Aßm

ann

Slide 50


Summary

Ø Configuration of product lines with mapping of feature models to solution spaces

Ø Mapping of Features to models in Ecore-based languagesusing FeatureMapper

Ø Visualisations of those mappings using MappingViews• Realisation View • Variant View • Context View • Property-Changes View

Ø Derivation of solution models based on variant selection and mappingØ Multi-Staged derivation using TraCoØ Ensuring well-formedness of SPLs

http://featuremapper.org

Pro

f. U

. Aßm

ann

Slide 51


The End

Ø Many slides are courtesy Florian Heidenreich

Pro

f. U

. Aßm

ann

52

31. feature models and mda for product lines -...

Documents