© Fraunhofer IESE

0

Product Line Engineering Lecture –PL Architectures I

Dr. Martin Beckermartin.becker@iese.fraunhofer.de

© 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