requirements engineering for software product lines › rerg › amadeus › staff › ... ·...
Post on 06-Jun-2020
2 Views
Preview:
TRANSCRIPT
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)
top related