Requirements Engineering forRequirements Engineering forSoftware Product LinesSoftware Product Lines

Seminar Talk at the City University LondonSeminar Talk at the City University London

London, UK, 26. March 2010London, UK, 26. March 2010Reinhard StoiberReinhard StoiberPh.D. Supervisor: Ph.D. Supervisor: Martin GlinzMartin Glinz

An Aspect and Decision Based ApproachAn Aspect and Decision Based Approach

3/26/10 R Stoiber, RE for Software Product Lines 2

OverviewOverview

Current techniques Open problems / shortcomings Our approach in a nutshell A real-world example, and view generation Deriving products from the product line

stepwise, incremental product derivation Support for creating a product line model

feature unweaving (presented if enough time is left) Conclusion

3/26/10 R Stoiber, RE for Software Product Lines 3

Current techniques (1)Current techniques (1)

Modeling product line requirements UML and feature modeling Textual requirements, UML and OVM

3/26/10 R Stoiber, RE for Software Product Lines 4

Current techniques (2)Current techniques (2)

UML and feature modeling

Reference:Czarnecki and Antkiewicz.Mapping Features to Models:A Template Approach Basedon Superimposed Variants.GPCE'05, 2005.

Variability modeling• Mapping variability tomodelsProduct derivation• Pruning models withelements not selectedfor a product variant

A feature tree todefine products

Feature => colour

3/26/10 R Stoiber, RE for Software Product Lines 5

Current techniques (3)Current techniques (3)

Reference:Pohl, Böckle, v.d.Linden.Software Product LineEngineering. Springer. 2005.

One orthogonalvariability modelAn UML class

diagram

A state machine

Etc.

Requirements modeling and OVM

3/26/10 R Stoiber, RE for Software Product Lines 6

Current techniques (4)Current techniques (4)

Variability modeling• Mapping variability tomodelsProduct derivation• Pruning models withelements not selectedfor a product variant

Reference:Pohl, Böckle, v.d.Linden.Software Product LineEngineering. Springer.2005.

Requirements modeling and OVM

3/26/10 R Stoiber, RE for Software Product Lines 7

Open problems /Open problems /shortcomingsshortcomings

Information scattering A feature is specified in multiple diagrams and

documents (i.e. UML) Efforts for specifying mappings

Creating all mappings from variability model torequirements needs discipline and effort

Impact comprehension of variability bindingdecisions The impact of a variability decision can not be

shown efficiently in one view

3/26/10 R Stoiber, RE for Software Product Lines 8

Our Approach in aOur Approach in aNutshell (1)Nutshell (1)

The ADORA* approach - core elements Integration: one integrated diagram Hierarchy: hierarchical decomposition Generated views: abstraction and filtering

* Analysis and Description of Requirements andArchitecture

URL: http://www.researchportal.ch/unizh/p622.htm

3/26/10 R Stoiber, RE for Software Product Lines 9

Our Approach in aOur Approach in aNutshell (2-1)Nutshell (2-1)

A requirementsmodel

3/26/10 R Stoiber, RE for Software Product Lines 10

Our Approach in aOur Approach in aNutshell (2-2)Nutshell (2-2)

A requirementsmodel

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 11

Our Approach in aOur Approach in aNutshell (2-3)Nutshell (2-3)

A requirementsmodel

An equivalent aspect-oriented model

variability modeled with aspects

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 12

Our Approach in aOur Approach in aNutshell (2-4)Nutshell (2-4)

A requirementsmodel

An equivalent aspect-oriented model

A product line model

boolean decision items (D1-D3) added

variability modeled with aspects

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 13

Our Approach in aOur Approach in aNutshell (2-5)Nutshell (2-5)

A requirementsmodel

An equivalent aspect-oriented model

A product line modelalternatives

boolean decision items (D1-D3) added

variability modeled with aspects

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 14

Our Approach in aOur Approach in aNutshell (2-6)Nutshell (2-6)

A requirementsmodel

An equivalent aspect-oriented model

A product line model

boolean decision items (D1-D3) added cardinality-constraint added

variability modeled with aspects

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 15

Our Approach in aOur Approach in aNutshell (2-7)Nutshell (2-7)

A requirementsmodel

An equivalent aspect-oriented model

A product line model

boolean decision items (D1-D3) added cardinality-constraint added

variability modeled with aspects

Feature 1 Feature 2 Feature 3

variability woven or removed

Derived product models

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 16

Our Approach in aOur Approach in aNutshell (2-8)Nutshell (2-8)

A requirementsmodel

An equivalent aspect-oriented model

Feature 1 Feature 2 Feature 3

Derived product modelsA product line model

boolean decision items (D1-D3) added cardinality-constraint added

Feature 1 Feature 2 Feature 3

variability modeled with aspects

variability woven or removed

some elementsare variable

3/26/10 R Stoiber, RE for Software Product Lines 17

Our Approach in aOur Approach in aNutshell (3)Nutshell (3)

Integrated modeling with aspects avoids information scattering eases the specification of variability*

Aspect weaving automates the composition of product models shows the impact of variability binding decisions

Explicit boolean decision modeling allows specifying details and constraints supports arbitrarily complex boolean constraints enables automated reasoning and constraint

propagation using a SAT solver

3/26/10 R Stoiber, RE for Software Product Lines 18

A Real-World Example (1)A Real-World Example (1)

3/26/10 R Stoiber, RE for Software Product Lines 19

A view showing only- commonality- variable features

View Generation (1)View Generation (1)

3/26/10 R Stoiber, RE for Software Product Lines 20

A view showing only- commonality- variable features- and constraints

View Generation (2)View Generation (2)

3/26/10 R Stoiber, RE for Software Product Lines 21

ChallengesChallengesfor for Product DerivationProduct Derivation

Meaning and impact of features Which requirements belong to which variability? What is the impact if a feature is chosen or not?

Satisfying variability constraints What are the consequences when a concrete

variability decision is bound? How can one verify that intermediate or full

configurations are valid?

3/26/10 R Stoiber, RE for Software Product Lines 22

Stepwise, IncrementalStepwise, IncrementalProduct DerivationProduct Derivation

The already bound variability

The unbound variabilityand constraints;

All variability is bound;constraints are satisfied

Building a consistent andreduced product line modelwhenever a variabilitybinding decision is taken.

3/26/10 R Stoiber, RE for Software Product Lines 23

Product DerivationProduct DerivationAn ExampleAn Example (1)(1)

Constraint propagation andweaving are automated by ADORA.

3/26/10 R Stoiber, RE for Software Product Lines 24

Product DerivationProduct DerivationAn Example An Example (2)(2)

3/26/10 R Stoiber, RE for Software Product Lines 25

Product DerivationProduct DerivationAn Example An Example (3)(3)

3/26/10 R Stoiber, RE for Software Product Lines 26

Product DerivationProduct DerivationAn Example An Example (4)(4)

3/26/10 R Stoiber, RE for Software Product Lines 27

Product DerivationProduct DerivationAn Example An Example (5)(5)

3/26/10 R Stoiber, RE for Software Product Lines 28

Product DerivationProduct DerivationAn Example An Example (6)(6)

A fully derivedapplicationproduct.Correct byconstruction.

3/26/10 R Stoiber, RE for Software Product Lines 29

ConclusionConclusion

Benefits Reduced effort for creating product line models* Improved understanding of variability and its impact Guarantee that derived products are valid Efficient and interactive derivation of product models

Semi-automated (decision-taking is still manual)

Future work Tool refinements Empirical validation (focus)

3/26/10 R Stoiber, RE for Software Product Lines 30

Creating Product LineCreating Product LineModelsModels

Such modeling and support may be beneficial

But, modeling aspects requires considerableclerical and intellectual efforts many mouse-clicks are necessary for adding aspects the weaving semantics needs to be understood well

Feature unweaving can automate ...

3/26/10 R Stoiber, RE for Software Product Lines 31

Feature Unweaving (1)Feature Unweaving (1)

A reference model thatcontains all requirements

3/26/10 R Stoiber, RE for Software Product Lines 32

Feature Unweaving (2)Feature Unweaving (2)

These elements only apply for a device that implementsa “supervisory unit”;Thus, they are variable

3/26/10 R Stoiber, RE for Software Product Lines 33

Feature Unweaving (3)Feature Unweaving (3)

Right-click -> context menu ->extract into variant

3/26/10 R Stoiber, RE for Software Product Lines 34

Feature Unweaving (4)Feature Unweaving (4)

Point a location where to extracted to

3/26/10 R Stoiber, RE for Software Product Lines 35

Feature Unweaving (5)Feature Unweaving (5)An equivalent aspect-oriented model is created automatically

A new decision item is added automatically

This works equally forall other variable features

3/26/10 R Stoiber, RE for Software Product Lines 36

ConclusionConclusion

Benefits

Reduced effort for creating product line models Improved understanding of variability and its impact Guarantee that derived products are valid Efficient and interactive derivation of product models

Semi-automated (decision-taking is still manual)

Future work

Tool refinements Empirical validation (focus)