product line engineering lecture – pl … line engineering lecture – pl infrastructures i (3)...

© Fraunhofer IESE

0

Product Line Engineering Lecture –PL Infrastructures I (3)

Dr. Martin [email protected]

© Fraunhofer IESE

1

Schedule - Lectures

© Fraunhofer IESE

2

Schedule - Exercises

© Fraunhofer IESE

Product Line Scoping

--- Recap ---Scoping

© Fraunhofer IESE

4

Scoping

Scoping :== process of identifying and bounding

areas (subdomains, existing assets)

and capabilities (features)

of the product line where investment into reuse is economically useful and beneficial to

product development.

© Fraunhofer IESE

5

Common concepts/questions of all scoping approaches

Products:Which products do I want to have in my product line? What is their market, when will they be released?

Domains:Which subdomains will my product line have? Which information do they carry? What are „good“, what are „bad“ domains for the product line (in terms of knowledge, stability etc)?

FeaturesWhich features will my product line have? Which product will have what kind of features? Which are easy, which are risky features?

AssetsWhich assets do I have in my product line? Which components, documentation etc exists already in a reusable form, which ones do I have to (re-)implement?

© Fraunhofer IESE

6

A generic scoping process

Scoping

Preparatio

n

IdentifyProducts

Domain Experts(Architects, Developers,Managers, Marketing etc)

Product Line Engineer(s)

IdentifySubdomains

IdentifyFeatures

IdentifyAssets

AssessProducts

AssessSubdomains

PrioritizeFeatures

PrioritizeAssets

OptimizeProducts

Wrap

up

release p

lann

ing

A concrete scoping process = a combination of these activities

© Fraunhofer IESE

7

Scoping Process - Overview

© Fraunhofer IESE

8

Product Release Plan

Market

Time

<<is derived from>>

Product M

Product XS

Product XL

Product L

Product S

Product smart

© Fraunhofer IESE

9

Scoping – Product Feature Matrix

Products

Sub-domains

Feature is supported by a product?

© Fraunhofer IESE

Product Line Scoping

--- Product Line Infrastructure Part I: Variability Modeling ---

© Fraunhofer IESE

11

Product Line Infrastructure

Domain

Product Line Life Cycle

Domain

Family Engineering

ProductLine

Artifact Base

Feedback

Documentation

Identification

Classification Evolution

Coordination

Evaluation

Integration

Adaptation

Application Engineering

ProductProduct

Requirements

Requirements CRequirements B

Product Requirements A

Quality

Productivity

© Fraunhofer IESE

12


Product Line Infrastructure :==

System of facilities,

equipment and services

needed for the operation of a product line [specialization of ISO9000:2005-12]

Note: The product line infrastructure comprises the core asset base (aka. Product Line Artifact Base)

© Fraunhofer IESE

13

Goal of a Product Line Infrastructure


Products

Goal of a product line infrastructure is to facilitate the derivationof products, i.e the members of the product line

© Fraunhofer IESE

14

Product Line Infrastructure = Artifact Database

ProductLine

Artifact Base

ReusableArtifacts

Instances ofReusableArtifacts

Product-specificArtifacts

FamilyEngineering

ApplicationEngineering

A product line infrastructure implements the necessary operations

© Fraunhofer IESE

15

Passive against Active Operations

Passive Operations

Active Operations

identify

evaluatedocument

classify

adaptintegrate

synchronize

coordinate

Deriveproducts

Selectartifacts

© Fraunhofer IESE

16

Product Line Infrastructure Operations

PASSIVEOPERATIONS

ACTIVEOPERATIONS

Evaluation

Documentation

Classification

Adaptation

Integration

Coordination

Evolution

Identification

ManageVariability

© Fraunhofer IESE

17

Variability Management

Variability management is a central component of every Product Line Engineering approach

It allows managing common and varying parts as well as their interdependencies

Specification, Realisation

It allows configuring, building and managing product line members

Production

22

ProductMandatoryFeature

optional Features

Feature dependencies

9

0..3

© Fraunhofer IESE

18

On Variability

Variability := a characteristicthat is differentfor some members of a category [Bassett97]

Notes:

Counterpart commonality: … same … all

A kind of feature

Delayed (design) decision: FE -> AE

Variability Decision

© Fraunhofer IESE

19

Variability in Product Lines

Mobile Phones:

Different Characteristics:

System: functions, form factor, housing, interaction, CPU, SW-platforms

Context: User groups, markets, regulations

© Fraunhofer IESE

20

Engineering Artifacts

Most of the artifacts are models, some with textual representationapproaches to manage variability in models / texts can be applied

© Fraunhofer IESE

21

Further Examples

© Fraunhofer IESE

22

Variability Lifecycle

Irrelevant

Identified

Scoped

Bound

Resolved

© Fraunhofer IESE

23

Variability Specification vs. Variability Realization

Spec

ifica

tion

Concepts FunctionsLevels

Rea

lizat

ion

AnalysisSpecificationDocumentationConfiguration

ImplementationApplication

Viewpoint

V1,...,Vn

Variability Binding time

Dependency

Origin Profile

Variant

Rationale

Range

Domain Model

Reusable Asset

VariationPoint

Mechanism

Local Dependency

Resolution

RationaleSpecific solution

Feature

«Product Line»

V1,...,Vn

© Fraunhofer IESE

24

Variability in Space and Time

T2 Tn-1... Time(Versions)

Space(Variants)

P1,1 P2,1

P2,2P1,2

P2,3

Pn-1,m-1

Pn-1,m

Tn

Pn-1,2

1

2

3

m-1

m Pn,m

Pn,m-1

T1

Pn-1,1

Pn-1,3 Pn,3

Pn,1

Pn,2...

...

...

Evolvability

© Fraunhofer IESE

25

Variability Types (1/2)

Optional Variability

Boolean

Select 0..1 out of 1 possibility

Alternative Variability

XOR

Enumeration

Select 1 out of n possibilities

Text EditorSpelling Checker

StandardOptional

Network Type

GSM

CDMA

{XOR}is a

© Fraunhofer IESE

26

Variability Types (2/2)

Multiple Coexisting Possibilities

OR

Set

Select 1..m out of n possibilities

Message Type

Text Message

Multimedia Msg

{OR}

Voice Message

{OR}

is a

© Fraunhofer IESE

27

Constraints

Constraints are extremely important in variability management

They describe dependencies between variability decisions

Constraints lead to automated resolution of decisions when a product is derived

Constraint maintenance is a majorchallenge

Typical: Includes, excludes

Background:

Hard facts: Norms / regulations / physics

Soft facts: Organisation standards, technology

© Fraunhofer IESE

28

Constraintformalisms

IF (Condition) THEN (Action) or

IF (Condition) THEN

(Action is not allowed)

CONSTRAINT (Feature_1, Feature_2, …, Feature_N) {

Combination_1 {(Feature_1 = Value_1_1)(Feature_2 = Value_1_2)...(Feature_N = Value_1_N)

}//END Combination_1Combination_2 {

(Feature_1 = Value_2_1)(Feature_2 = Value_2_2)...(Feature_N = Value_2_N)

}//END Combination_2...Combination_N {

(Feature_1 = Value_N_1)(Feature_2 = Value_N_2)…(Feature_N = Value_N_N)

}//END Combination_N}//END CONSTRAINT

Rule-based Systems

Constraint-based Systems

© Fraunhofer IESE

29

Binding Time of Variability

Binding time refers to the time at which the decisions for a variation point are made

SourceSource ...

compilation

ExecutableExecutable

linkpreprocessing deploy

Intermediate

code

Intermediate

code

compilation

SourceSource BinaryBinary ExecutableExecutable

compilation

Preprocess time Compile time Link time Deploy time

Build time

Run time

Development SourceSource ...

compilation

ExecutableExecutable

linkpreprocessing deploy

Intermediate

code

Intermediate

code

compilation

SourceSource BinaryBinary ExecutableExecutable

compilation

Preprocess time Compile time Link time Deploy time

Construction time

Run time

Development

© Fraunhofer IESE

30

RunTime

StartupTime

LinkTime

InstallTime

CompileTime

PreprocessingTime

DevelopmentTime

Binding – The Act of Assigning a Variable in a Module

time

Archi-tecture

Deve-loper

SourceCode

Prepro-cessor

SourceCode

Com-piler

ObjectCode Linker

ExecutableCode

InstallerInstalled

Code

EndUser

ExecutingProgram

Construction Time Execution TimeConfiguration

(adaptation possible only here!)Composition

(code remains fixed here!)

=> avoid binding variations at a later time than required

© Fraunhofer IESE

31

Variability is a cross-cutting concern

Low Abstraction

Functional and Non- FunctionalRequirements

SystemUse Cases

SystemArchitecture

SystemComponent

Detail DesignSoftware & HardwareArtefacts

Problem Space

Solution Space

Variability

High Abstraction

Variability

Vp

VpVp

VpVp

Vp

Simple Decision

Variability Information

© Fraunhofer IESE

32

Example: Crosscutting Variability

Requirements

Architecture

...

...

Components

«Variability»User Interface

GUI

Text

Elementar

© Fraunhofer IESE

33

Specifying / Modellingthe variability

VARIATION POINTS – INTERNAL VIEWpositions in the artifact that can be adapted when the artifact is being reusedparameters, optional text blocks, place holders,…

Artifact

VariabilityModel

VARIABILITY – EXTERNAL VIEW“configurator” view on the artifactinformation aboutdependencies between variations

DecisionModel

FeatureModel

ConfigurationModel

© Fraunhofer IESE

34

Decision Models

A decision model is a model that captures variability in a product line in terms of open decisions and possible resolutions

Decision models can be used regardless the type of the artifact (documents, models, code) => orthogonal variability modeling

© Fraunhofer IESE

35

Decision Models: Example

ID Decision Question VP Resol.

S1 Presence Is there a presence sensor? presence {Y,n}

S2 Position Is there a position sensor? position {N,y}

S3 Actuator Is there an actuator? Actuator, triggerAct.

{N,y}

© Fraunhofer IESE

38

Example Feature Model

Text

heatingsystem

heatingunit

temperaturesensor control

valve radiator convector

actuator

motordrive

automatic manual

Describes the features (mandatory, optional,

alternative) of a product line member

© Fraunhofer IESE

39

Structure of Feature (Variability) Models

• Usage, Region, RegulationsEnvironment Layer

• Services, Operations, NF PropertiesCapabilities Layer

• HW, SWDomain Technologies Layer

ImplementationTechniques Layer

[Source: Lee et al.: Concepts and Guidelines of Feature Modeling for Product Line Software Engineering, ICSR-7, 2002]

© Fraunhofer IESE

43

Discussion on Decision and Feature Models

Feature Models

broader adoption in the practice

also enable the description of commonality (mandatory features)

more intuitive and thus better suited for documentation

Decision Models

focus on the variability

commonality can be modeled as an already taken decision

standard traceability to artifacts – each decision has an effect

© Fraunhofer IESE

44

Variability Management Tooling

Variability Management Tools

GEARS

pure::variants

PLUM

DecisionKing

fmp-plugin and various other feature modeling tools

Configuration Tools

Linux Kernel Configurator (based on the configuration menu language)

make-based configuration

Special-purpose Configurators

camos.Develop

K-Config

© Fraunhofer IESE

45

Further Reading

Pohl, Klaus ; Böckle, Günter ; Linden, Frank van der:Software Product Line Engineering : Foundations, Principles, and Techniques Berlin : Springer-Verlag, 2005. - ISBN 3-540-24372-0

Krueger, C. W. (2002), Variation Management for Software Production Lines, in 'SPLC 2: Proceedings of the Second International Conference on Software Product Lines', Springer-Verlag, London, UK, pp. 37--48.

Yoshimura, K.; Forster, T.; Muthig, D. & Pech, D. (2008), Model-based Design of Product Line Components in the Automotive Domain, in SPLC Proceedings of the 12th International Conference on Software Product Lines, 170-179.

(2009), Common Variability Language (CVL), Request For Proposal Document: ad/2009-12-03, Object Management Group.

product line engineering lecture – pl … line engineering lecture – pl infrastructures i (3)...

Documents