© Fraunhofer IESE
0
Product Line Engineering Lecture –PL Architectures I
Dr. Martin [email protected]
© Fraunhofer IESE
1
Schedule - Lectures
© Fraunhofer IESE
2
Schedule - Exercises
© Fraunhofer IESE
Product Line Scoping
--- Requirements Engineering ---
How to identify, analyze, model, and instantiate common and variable
requirements?
© Fraunhofer IESE
4
RE Phases
The RE Activities can be divided into five phases, which are more or
less standard for the requirements process:
Requirements elicitation
Requirements analysis
Requirements specification/documentation
Requirements verification and validation
Requirements management
© Fraunhofer IESE
5
Product Line Infrastructure
Domain
RE in Product Line Life Cycle
Domain
Family Engineering
ProductLine
Artifact Base
Feedback
Documentation
Identification
Classification Evolution
Coordination
Evaluation
Integration
Adaptation
Application EngineeringApplication Engineering
ProductProductProductRequirements
ProductRequirements
Requirements CRequirements B
Product Requirements A
Scopin
g
© Fraunhofer IESE
6
Usage of RE Documents
for variability specification
High level Variability (Feature, Decision) Models can be managed in RM-Tools
Structuring
Traceability
Management
Use abstract requirements, i.e. Features, to specify variability
Vertical traceability can be used to represent constraints
Req. Doc
© Fraunhofer IESE
7
Text based representation
Customisation of textual requirements
Environment: Textual requirements with Word template (basic use cases)
Specific mapping: Introduction of new text elements
<<opt expr1 / text >>.
<<alt expr2 / value-1 / text1/ value-2 / text2 >>.
<<mult decision-variable / value-1 / text1/ value-2 / text2 .....>>
<<value decision-variable>>
expr: logical expressionswith decision variables
© Fraunhofer IESE
8
Extending UML
• Many approaches to UML extensionsexist
• Example: Stereotypes• Advantage:
- stereotypes are supported by most UML-tools
• Disadvantages:- there is no instantiation/
application engineering support- stereotypes are meant for
domain specific extensions
«variability»Engine
Diesel Engine Gasoline Engine
«variability»Start Car
Car Driver
Preheat Engine Start Engine
«uses»«uses»
© Fraunhofer IESE
9
Conclusion
RE is of key relevance of Single Systems Engineering and PLE
Traceability support is helpful esp. for constistency in case of changes
RE approach is different in different PLE approaches
Variability models can be represented as requirements as well
Several mechanisms can be applied to handle variation points on the artefact level
© Fraunhofer IESE
Product Line Scoping
--- Intro ---
What is architecture?Who needs it?
Single System Architecture vs. Product Line Architecture?
© Fraunhofer IESE
11
The Need for Software Architecture
The rise of software architecture has resulted from two trends[1] :
Large and complex systems
The importance of quality attributes (increasingly “time to market” is critical)
© Fraunhofer IESE
12
Software Complexity
Just one subsystem out of 20!
Components and interdependencies
© Fraunhofer IESE
13
High Quality
Quality is NOT only about correctness of functionality
Successful software systems have to assure additional properties:
Performance
Security
Availability
Maintainability
Customizability
Flexibility
Run-time maintainability or configurability
These properties are the so-called Quality Attributes
© Fraunhofer IESE
14
Architecture as a Tool
Conceptual tool to cope with complexity in Software Engineering needed
Architecture
Architecture is a set of concepts allowing to control complexity
© Fraunhofer IESE
15
“Structure or structures of the system, which comprise software elements,
the externally visible properties of those elements,
and the relationships among them.”[Bass et al., Software Architecture in Practice]
© Fraunhofer IESE
16
“A software system’s architecture is the set of
principal design decisions made about the system”
[Taylor et al.]
© Fraunhofer IESE
17
Architecture
Architecture is the first artefact that translates the problem into in the solution space
Provides an overview on the system
Enables early discussion and assessment of design alternatives
Architecture is an output of the software design process
RequirementsEngineering Design Implementation
Requirements Architecture Code Legend:
work product
process
control flow
product flow
© Fraunhofer IESE
18
(Single-System) Architecture as an Artifact
The architecture of a software system …
covers the most important design decisions
ensures that the quality attributes can be achieved
decomposes the system into manageable pieces
allows parallelization of work in teams
allows communication to and among stakeholders
© Fraunhofer IESE
19
Single-System Architecture as a Mediator
Technology (Technology (--specific) Levelspecific) Level
Business LevelBusiness Level
EarlyDecisions
LateRealization Testing
PredictionSeparate analysis of system characteristics
IntegratedSystem
ArchitectureArchitecture
Stakeholder-specificNotations
ProgrammingLanguage
© Fraunhofer IESE
20
Mission of (Single-System) Architecture
Reasoning and prediction (predictive)
Will the system properties meet the requirements?
Vehicle for communication (descriptive)
Why are the things as they are?
What is the role of a architecture element?
Constrain and guide implementation (prescriptive)
What is allowed/forbidden?
How do the components interface each other?
© Fraunhofer IESE
21
Architectural Drivers
Business goals
Customer organization
Developing organization
Quality attributes
System in use
System under development
Key functional requirements
Unique properties
Make system viable
Constraints
Organizational and technical
Cost and time
cause complexity
might be competing
Product Line Context:
Customizability is a major driver
© Fraunhofer IESE
22
Where Architectural Drivers Originate … Stakeholders
SoftwareArchitect
Developer
Project ManagerCustomerManagement
Tester
End User
Maintainer
DeveloperManagement
Product Manager
© Fraunhofer IESE
23
Architecture Usage Scenarios
ArchitectureArchitecture
Communication
Changeimpactanalysis
Riskdetection
Testplanning
Technicalprototyping
Developmentplanning
Qualityprediction
Integrationplanning
Reusedecisions
Evolutionplanning
Development
© Fraunhofer IESE
24
Types of Architectures
Ultra Large Scale System Architectures
Ecosystem Architectures
Enterprise Architectures
System-of-System Architectures
System Architectures
Software Architectures
Product Line Architectures
Reference Architectures
Platform ArchitecturesBusiness Architectures
© Fraunhofer IESE
25
A Product Line Architecture goes a step further
The architecture of a whole family of systems …
covers the most important common design decisions
ensures that the quality attributes can be achieved in all members of the product line
decomposes a family of systems into manageable pieces
allows parallelization of work in family and application engineering
allows communication to and among stakeholders enables customers to see customization possibilities
© Fraunhofer IESE
26
Product Line System Architecture as a Mediator
Product Line ImplementationProduct Line Implementation
Product Line Scope and RequirementsProduct Line Scope and Requirements
EarlyDecisions
LateRealization Testing
PredictionSeparate analysis of system characteristics
IntegratedSystem
Product LineProduct Line ArchitectureArchitecture
Stakeholder-specificNotations
ProgrammingLanguage
© Fraunhofer IESE
27
Mission of Product Line Architecture (1/2)
Reasoning and prediction (predictive)
Will all members of the product line meet the common requirements?
Vehicle for communication (descriptive)
Why should I reuse this component?
What is the reason behind a variation point?
What is the role of a reusable architecture element?
Constrain and guide implementation (prescriptive)
What is allowed/forbidden when I customize for a customer?
What different interface implementations and combinations are available
© Fraunhofer IESE
28
Mission of Product Line Architecture (2/2)
Reasoning and prediction (predictive)
How does Product A differ from Product B?
What must be changed to get Product C?
What are the constraints and dependencies on Component D?
Vehicle for communication (descriptive)
What are the advantages of Product B?
Which team develops when the Variant Feature F?
Constrain and guide implementation (prescriptive)
What parameters are supported by Component D?
How to adapt and integrate the components
How to manage the variant components?
© Fraunhofer IESE
29
Some major additional stakeholders in a product line
ProductLineArchitect
ProductLineManager
ConfigurationManager
ProductionManager
Product Line Adoption Manager
© Fraunhofer IESE
30
Example System Structures
Mechanic Component
Electronic Component
Software Component
Subystem
…
……
© Fraunhofer IESE
31
Architecture as the Key-Enabler for Reuse-in-the-Large
Reuse-in-the-Small Reuse-in-the-Large
Avoid identification, evaluation, integration, coordination efforts
Order of magnitude efficiency improvement
vs
© Fraunhofer IESE
32
Common confusion
Platform architecture
Reference architecture
Product Line architecture = =
explicit variationpoints and dependencies
Low level ofdetail /close totechnology
no finalimplementationincluded(only reference)
e.g. Standard Template Library(although low-level)
e.g. Microsoft’sPlatform Architecturefor SOA
e.g. Java PlatformEnterprise Edition
© Fraunhofer IESE
33
What can Differ in a Product Line Architecture?
© Fraunhofer IESE
34
Excerpts of Product Line Architectures
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
35
Excerpts of Product Line Architectures [3]
Data flowin anautomotivesystem
DependentPort
OptionalComponent
IndependentPort
MandatoryComponent
OptionalPort
© Fraunhofer IESE
36
Excerpts of Product Line Architectures [4]
© Fraunhofer IESE
37
Excerpts of Product Line Architectures [4]
EAST-ADL
© Fraunhofer IESE
38
“A Product Line Architecture is a description of the structural properties for building a group of related systems, typically the components and
their interrelationships.
The inherent guidelines about the use of components must capture the means for
handling required variability among the systems.[2]
© Fraunhofer IESE
39
What offers a product line architecture
Enables making considerations about variability early on
Product Line Architecture enables encapsulating the variability
In so doing the impact of variability across the software is reduced
© Fraunhofer IESE
40
Who needs a product line architecture?
Application designers: PLAs as common assets
customized to yield individual product architectures.
customizations happen at predefined VPs.
Family designers: PLAs help to make assumptions about the architectural context in which core assets will be reused
highlighting the essential product line concepts.
suppressing non-essential product line concepts (i.e., product-specific ones).
Both: PLAs facilitate sharing assets and provide feedback opportunities.
© Fraunhofer IESE
41
References
1. Paul Clements, Software Engineering Institute, Carnegie Mellon University, RiSE summer school 2008
2. P. Clements, L.M. Northrop: Software Product Lines: Practices and Patterns. Addison-Wesley, 2001
3. Mann, S. & Rock, G. (2009), Dealing with Variability in Architecture Descriptions to Support Automotive Product Lines, in 'VaMoS', Universitat Duisburg-Essen, ICB Research Report, Third International Workshop on Variability Modelling of Software-Intensive Systems, Seville, Spain, January 28-30, 2009. Proceedings, , pp. 111-120.
4. ATTEST2 project, overview of variability concepts in EAST-ADL2, retrieved from http://www.atesst.org/
5. Schmid, K. (2004), A Quantitative Model of the Value of Architecture in Product Line Adoption, in Frank van der Linden, ed.,'Software Product-Family Engineering', Springer Berlin / Heidelberg, , pp. 32-43.
© Fraunhofer IESE
42
References
6. Henkel, J. & Diwan, A. (2005), CatchUp!: capturing and replaying refactorings to support API evolution, in 'ICSE '05: Proceedings of the 27th international conference on Software engineering', ACM, New York, NY, USA, pp. 274--283.
7. Raine Kauppinen, Juha Taina and Antti Tevanlinna, Hook and Template Coverage Criteria for Testing, Framework-based Software Product Families, Proceedings of SPLIT 2004 International Workshop on Software Product Line Testing
8. Jan Bosch: Design and Use of Software Architectures. Addison-Wesley, 2000.
9. Caroline Nyholm: Product Line Development – an Overview. Extended Report for I. Crnkovic and M. Larsson (editors), “Building Reliable Component-Based Systems”, Artech House, July 2002, ISBN 1-58053-327-2.
10. F. van der Linden, K. Schmid, E. Rommes: Software Product Lines in Action. Springer-Verlag, 2007.
© Fraunhofer IESE
43
References
11. Nick Rozanski and Eoin Woods: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional, 2005.
12. Maarit Harsu : A survey of product-line architectures, Technical report 23, Institute of Software Systems, Tampere University of Technology, 2001.
13. D. Perry,. E. 1998. Generic Architecture Descriptions for Product Lines. In Proceedings of the Second international ESPRIT ARES Workshop on Development and Evolution of Software Architectures For Product Families (February 26 - 27, 1998). F. v. Linden, Ed. Lecture Notes In Computer Science, vol. 1429. Springer-Verlag, London, 51-56.
14. Jaejoon Lee, Dirk Muthig, Feature-oriented Analysis and Design, in Applied Software Product Line Engineering, CRC Press, 2010
15. Etxeberria, L.; Sagardui,G.;, “Product line architecture: new issues for evaluation”, in: Proceedings of the 9th International Conference on Software Product Lines, 2005, pp. 174-185