The Software Product Line Architectures

1. The Software Product Line Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

2. outline • What is software Product Line. • http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm • Product Line Architecture Development Process • http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf • Examples

3. What is software Product Line? • Re-use of asset architecture for some systems can maximize company investment. • Mature organization keeps their architecture as an intellectual asset which is very valuable and able to increase turn over and reduce cost. • Software Product Line – discipline, and re-use strategy sharing of asset in producing a group of products. • Objective – able to re-use asset from the previous projects such as basic architecture, the same element, designs, documentations, user manual, artifact project management such as budgeting and scheduling, and test plan & test cases. • When the product line produced, the assets will be kept in asset library to be used for other projects.

4. What is Software Product Line? • Software product line is defined as “A set of software-intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission” • These Systems are developed from a common core of assets (e.g. a common architecture) in a prescribed way. • The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems.

5. outline • What is software Product Line. • http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm • Product Line Architecture Development Process • http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf • Examples

6. PLA Development Process Creating Product Line Architectures1: Joachim Bayer, Oliver Flege, and Cristina Gacek Fraunhofer Institute for Experimental Software Engineering (IESE) Sauerwiesen 6, D-67661 Kaiserslautern, Germany {bayer, flege, gacek}@iese.fhg.de, http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf

7. PuLSE-DSSA Process • The PuLSE-DSSA is a customizable process that integrates product line architecture creation and evaluation • The input is a scope definition and a domain model, • The scope definition determines the commonalities and variations of applications within the product line.

8. PuLSE-DSSA Process: Scope Definition as input • Ideally, the scope definition is based on a process that seeks to estimate the economic value each distinct feature would have for the product line • Determining which system functions are essential in the product line, and which are not. • Presenting organization scope about product types which will be developed now and in the future. • Input for the production of scopes comes from organization strategic planner, marketing staff, domain analysis and technology experts. • Scope of product line is one of the critical factors in determining the success of the product line. • The major problem in determining the scope is identifying the similarity in the systems that will reduce development cost of a system for an organization.

9. PuLSE-DSSA Process: The Domain Model as input, • In the PuLSE product line development process, the input domain model would be a product line model consisting of generic workproducts (i.e., products describing requirements in terms of commonalities and variabilities) and a decision model. • As an example of a generic workproduct can be defined on GUIs based on the commonalities and variabilities of different users

10. PuLSE-DSSA Process: The Domain Model’s Decision Model • A decision model captures variability in a product line in terms of open decisions and possible resolutions. • In a decision model instance, all decisions are resolved. • As variabilities in generic workproducts refer to these decisions, a decision model instance defines a specific instance of each generic workproduct and thus specifies a particular product line member.

11. PuLSE-DSSA Process Steps • 1. Create Scenarios • Determine the most important requirements captured in scenarios that describe critical use-cases • Conventional scenarios are described on an instance level, which makes it difficult to convey the variability information needed for product line requirements • We need to create generic scenarios that represent commonalities and variabilities

12. PuLSE-DSSA Process Steps • 2. Group and Sort Scenarios • This step yields the architecture creation plan that defines the iterations in which the architecture development is performed. • The first iteration deals with the most important group of scenarios, the second one with the second most important group and so forth • The order in which scenarios are addressed is highly significant, because • Each iteration’s design decisions impose constraints on the architecture that delimit its further evolution.

13. PuLSE-DSSA Process Steps • 3. Define Test Cases • For each group of scenarios, test cases are defined that will be used to evaluate the architecture at the end of each iteration. • Specifying test cases before the actual development begins has a number of benefits, including a better understanding of the requirements and • avoidance of creating tests that, due to a fixed perspective, merely support what has been developed. • evaluating the architecture is based on specific kinds of system level quality objectives such as maintainability, understandability, and reusability.

14. PuLSE-DSSA Process Steps • 4. Apply Scenarios • The group of scenarios associated with the current iteration is used to create the initial architecture or to refine/extend an already existing, partial architecture. • This step also includes the possible integration of existing components (legacy or COTS) as well as prototyping. • The result is a (partial) architecture description and possibly a prototype. • During architecture development some variabilities might become apparent that are not driven by the problem domain, but rather by the solution

15. PuLSE-DSSA Process Steps • 5. Evaluate Architecture • In this step, the architecture resulting from the previous step is evaluated according to the architecture evaluation plan • Evaluation has to address instance-specific as well as family specific aspects and relies on a defined instantiation mechanism. • The ease with which instances can be created allows to draw conclusions on critical family-specific characteristics • A range of possible instantiations is used to ensure that the intended products are indeed covered by the reference architecture

16. PuLSE-DSSA Process Steps • 6. Analyze Problems • In this step, the underlying problems from the evaluation step are examined in order to determine how the architecture development process can be continued. • The examination focuses on whether the current group of scenarios could be applied successfully to the architecture that resulted from the previous iterations. • Some design decisions from an earlier iteration are presumed to impose constraints that are too stringent for the current set of scenarios. • Therefore, extended backtracking is needed, which may include reformulating, regrouping, and reordering of some scenarios and then reentering the process in the appropriate iteration

17. Product Line Architecture variation points • The most important tasks that need to be done to define the architecture in product lines: • Identifying variation points. • Supporting variation points.

18. Identifying the Variation Point • Continuous task because: • Variation maybe identified in development process. • Variation maybe identified during the creation process, product line requirement like: purpose, platform, interface, quality, and target market. • During the architecture design such as: choose as whether to perform the identified variation at the requirement analysis phase or architecture. • During implementation.

19. Supporting Variation Point • Architecture will support variation points in the form of: • Using or eliminating elements. • Using the same elements with variant attributes. • Choosing the element which has same interface but different implementation or different quality attribute. • Implementation Techniques: • In OO system, the use of specialization and generalization for class. • Developing extension points at the element. • Using the same parameter within the component. • Over loading – using the same function in different type of data.

20. SPL Instantiation Process • The instantiation process involves using and adapting a product line to deliver a working product that meets the product specific requirements. The process typically involves the following steps: • Identifying product specific requirements • Initial screening of the components and selecting the ones that can be reused for the product • From the component selected in the previous step, select only those components that are reusable after some adaptation

21. SPL Instantiation Process (cont.) • Binding and adding variants for the variability points in the selected components • Implementing new components to fulfill new requirements (product specific requirements). Some of these might end up being included in the product line architecture • Integrating the resulting components and perform product specific development • Finally, maintaining the product after deployment

22. outline • What is software Product Line. • http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm • Product Line Architecture Development Process • http://www.cs.ncl.ac.uk/publications/inproceedings/papers/574.pdf • Examples

23. Example 1: PLA for a Microwave Oven

24. Definition of Terms Used in the Example Class Diagram • Kernel: Kernel in product lines represents the mandatory features for the product line members. i.e.: they cannot be omitted in products. • The stereotype <<kernel>> is used to specify Kernel in UML class diagrams. • Optional: Optionality in product lines means that some features are elective for the product line members, which means they can be omitted in some products and included in others. • The stereotype <<optional>> is used to specify optionality in UML class diagrams. • The optionality can concern classes, packages, attributes or operations. So the <<optional>> stereotype can be applied to Classifier, Package and Feature meta-classes. • Variant: Variant classes are modeled using UML inheritance and stereotypes. Each variation point will be defined by an abstract class and a set of subclasses. • The abstract class will be defined with the stereotype <<variant>> and • each subclass will be stereotyped <<variant>>, or <<optional>>, the default value being variant.

25. Example 1(cont.): Microwave Sample Sequence Diagram

26. Example 2: Library Class Diagram

27. Example 3: Ecommerce Class Diagram

28. Evaluating the Architecture to Suit Product Lines • Product Line architecture is analyzed for: • Robustness. • Generality. • How and why and When to evaluate: • How: Focus on the variation point – ensure suitability, flexibility, faster product development. • Why: Identifying the quality of scenarios involved. • When: Evaluate when a new product falls out of the scope, or needs components not included in the PLA

29. Creating and DevelopingProduct Line • From time to time, organization will add new member in product line based on the products that has been developed. • Problem in managing product line evolution that always increasing. • Product evolution comes from 2 sources: • External Source. • New element from produce/ manufacturer to be included in the product line and new product will be produce from it. • Internal Source. • For product function in the scope of product line will be using the existing function. If not, new function will be developed, and it needs to be analyzed as whether it needs to be added in the product line or not.

30. Conclusions • This lectures introduced the concepts of product line architectures using 3 examples. • We also discussed issues related to evaluating and implementing product line architectures