Grundlagen des Software Engineering Fundamentals of Software Engineering

Transcription

1 Software Engineering Research Group: Processes and Measurement Fachbereich Informatik TU Kaiserslautern Grundlagen des Software Engineering Fundamentals of Software Engineering Winter Term 2011/12 Prof. Dr. Dr. h. c. Dieter Rombach Chapter 5.4: Software System Engineering - Software Product Line Last update: 10/01/2012

2 Goals The goals of this chapter are to be able to: Define product line engineering Understand the concept of commonalities and variabilities Understand SPL architectural concepts Understand variation modeling Characterize development approach Literature C. Atkinson, J. Bayer, C. Bunse, O. Laitenberger, R. Laqua, E. Kamsties, D. Muthig, B. Paech, J. Wüst, and J. Zettel. Component-based Product Line Engineering with UML, Component Series, Addison-Wesley, 2001 I. John and M. Eisenbarth, "A decade of scoping: a survey," in Proceedings of the 13th International Software Product Line Conference, ser. SPLC '09. Pittsburgh, PA, USA: Carnegie Mellon University, 2009, pp J. Lee and D. Muthig, "Feature-oriented variability management in product line engineering," Commun. ACM, vol. 49, no. 12, pp , Dec D. Muthig and C. Atkinson, "Model-Driven product line architectures," in Software Product Lines, ser. Lecture Notes in Computer Science, G. Chastek, Ed. Berlin, Heidelberg: Springer Berlin / Heidelberg, Jul. 2002, vol. 2379, ch. 8, pp K. Pohl, G. Böckle, and F. J. Linden, Software Product Line Engineering: Foundations, Principles and Techniques. Secaucus, NJ, USA: Springer-Verlag New York, Inc., D. Weiss and C. Lai. Software Product Line Engineering - A Family-Based Software Development Process, Addison-Wesley, 1999 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 1

3 Motivation: Typical Challenges For System-Developing Organizations Series of development projects (leverage on commonalities, reuse) Increasing complexity of systems (avoid complexity explosion) Need for reducing cost, effort, and time-to-market (can be reduced via reuse) Increasing request for quality solutions (certification hard w/o reuse) Increasing demand for customized products (easy adaptation if anticipated) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 2

4 Variability in Time vs. Variability in Space [bachmann+05] Variability the ability of a core asset to adapt to usages in the different product contexts that are within the product line scope Variability in Time (releases, dominant in IS) the existence of different versions of an artifact that are valid at different times Variability in Space (variants, dominant in ES) the existence of an artifact in different shapes at the same time Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 3

5 What is "Software Product Line Engineering" (SPLE)? Software Product Line Engineering a paradigm to develop software applications using platforms and mass customization. [Pohl+05] Family/Domain Engineering (creating reusable artifacts) the process of software product line engineering in which the commonality and the variability of the product line are defined and realized. [Pohl+05] Application Engineering (creating customer applications from reusable artifacts) the process of software product line engineering in which the applications of the product line are built by reusing domain artifacts and exploiting the product line variability. [Pohl+05] = + P2 P2 P1 P2 P3 SPLE Family Engineering Application Engineering Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 4

6 Life Cycle of a Software Product Line Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 5

7 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 6 Product Line Life Cycle Product Requirements Application Engineering Product Product Requirements A Requirements B Requirements C Domain Domain Evaluation Identification Classification Product Line Artifact Base Documentation Adaptation Integration Coordination Evolution Family Engineering Product Line Infrastructure Feedback

8 Scoping Product Line Scoping is the process of identifying and bounding capabilities (products, features) and areas (subdomains, existing assets) of the product line where investment into reuse is economically useful and beneficial to product development. [John+09] [John+09] Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 7

9 Scoping Example Product Feature Matrix Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 8

10 Goals of Software Product Line Engineering Reduction in the time to market required for individual products Reduction in required development effort per application (product) Reduction in overall development effort per product line Increase in quality etc. [Weiss+ 99] Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 10

11 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 11 Product Line Economics Development Effort Effort Single System Development PL Instance Investment Single System [Weiss/Lai], [Fraunhofer PuLSE ], etc. Product Line Approach Rule of thumb: Investment ranges between development efforts for 1 and 2 systems. Rule of thumb: Savings begin between 2nd and 3rd product # Delivered System

12 Product Line Strategy Product Line Economics (Revisited) Effort (~ TTM -1 ~Cost) PL Engineering (proactive) Single-system Development (independent) Successful Product Lines # Delivered Products PL Engineering (reactive) Single-system Development (clone-and-own) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 12

13 SW is the first artifact that translates the problem into in the solution space Provides an overview on the system Enables early discussion and assessment of design alternatives is the output of the software design process Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 13

14 PL System as a Mediator Specification & decomposition of a whole family of systems covering the most important common design decisions supporting SW variations for system customization Constraints & guidance of PL Implementation allowing parallelization of work in family and application engineering ensuring that the quality attributes can be achieved in all members of the PL Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 14

15 What offers a product line architecture? Enables making considerations about variability early on Product Line enables encapsulating the variability [Mann+ 09] Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 15

16 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 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 16

17 Usage Scenarios and who are the stakeholders? Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 17

18 stakeholders General stakeholders Additional stakeholders in a PL Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 18

19 Fraunhofer Process Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 19

20 Planning Incremental definition of an architecture Align with project plan System increments Availability of necessary non-software components or artifacts First iteration typically addresses complete systems at a high level of abstraction (conceptual view) Scope of Iterations Document all required decisions (revisit if backtracking is necessary) Constrain decisions as little as possible (but as much as necessary) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 20

21 Realization Refining quality requirements Define main qualities Identify categories of requirements Identify and apply architectural scenarios Identifying subsystems, components, and connectors Check consistency, conformity, and completeness with respect to quality requirements Handling of constraints and alternatives Analyzing and mitigating risks Prototyping Reverse Engineering Recording of design decisions and rationales Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 21

22 Documentation: Views, Models, Diagrams Idea: View-based Design and Analyses Architectural View A representation of a system from the perspective of a related set of concerns Benefits Separation of Concerns Complexity reduction Communication with stakeholders Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 22

23 in UML Unified Modeling Language (UML) is commonly used to describe software architectures at least for object-oriented systems UML does not support the description of PLAs UML tools do not support it, either some UML tools support UML extensibility mechanisms Stereotypes Tagged Values (Properties) Constraints Find a workaround using UML extensibility options allows to use existing tools product line architectures comply to the UML standard Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 23

24 Typical variant elements in UML Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 24

25 Feature Modeling Feature modeling is the activity of identifying externally visible characteristics of products in a product line and organizing them into a feature model. [Lee+06] Features can be services, operations, non-functional characteristics, and technologies of a particular product line. [Lee+06] requires Trunk Car Type [1..1] Truck Vehicle Wheel excludes Electricity Engine Petrol [1..1] Seat Diesel Variability Dependencies Mandatory Optional Alternative requires excludes [min..max] Constraint Dependencies Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 25

26 Decision Modeling Decisions are variation points that typically constrain the resolution of other variation points. [Muthig+02] Each Decision defines a question that captures the essence of the related variability A Decision Model includes id decision name question variation point resolution & default Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 26

27 KobrA Generic Component Model Suite KobrA a systematic method that integrates component-based development with product line engineering [Atkinson+01] makes use of the extension mechanisms of the UML [Muthig+02] Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 27

28 Basic Goals [Atkinson+01] Simple a method with separate concerns Systematic concepts and guidelines defined in the method should be precise and unambiguous tell developers what they should do, rather than what they may do Scalable be able to accommodate large-scale and small-scale problems in the same manner the method should be applicable incrementally Practical compatible with commonly used technologies Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 28

29 Role of a Component Specification To describe the externally visible properties of a component Defines a component s supplied services (supplied interface) acquired services (components) Provides the basis for the contract between the component and its clients Is defined in the context of the parent component s realization (or the context realization if the root) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 29

30 Primary Specification Models Structural model data manipulated by the component, its environment, and any externally visible structure one or more class diagrams zero or more object diagrams Functional model computations performed by the component one operation specification for each operation Behavioral model states exhibited by the component and the events that change them zero or more state chart diagrams Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 30

31 Example: Structural Model Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 31

32 Example: Functional Model Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 32

33 Example: Behavioral Model Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 33

34 Role of a Component Realization To describe the way in which a component realizes the services specified in the specification Defines a component s private subcomponents architecture and design Is defined in the context of the component s specification the realization models expand upon the information in the specification model Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 34

35 Example: Phone Component Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 35