1. Software Product Line Engineering Andrew Burmester SE 4110 Section 2 4/14/11

2. Introduction Product Lines Auto Industry Need a way to produce a large variety of vehicles within a short time period. Answer: Create a standard family and modify this basis to meet customers needs. Can we apply these techniques to Software Engineering?

3. Software Product Lines Before defining the Software Product Line, a few concepts need to be addressed. Before defining the Software Product Line, a few concepts need to be addressed. Mass Customization – Large-scale production of goods tailored to individual customers’ needs Mass Customization – Large-scale production of goods tailored to individual customers’ needs Platform – Any base of technologies on which other technologies or processes are built. Platform – Any base of technologies on which other technologies or processes are built.

4. Software Product Lines Definition of Software Product Line Engineering: Definition of Software Product Line Engineering: “Software product line engineering is a paradigm to develop software applications (software intensive systems and software products) using platforms and mass customization.” “Software product line engineering is a paradigm to develop software applications (software intensive systems and software products) using platforms and mass customization.”

5. Software Product Lines Two main parts of a software product line: Domain Platform “A software platform is a set of subsystems and interfaces that form a common structure from which a set of derivative products can be efficiently developed and produced” Derivative Applications Distinct products that were realized by using the platform.

6. Software Product Lines Motivations to use software product lines Reduction of development costs Enhanced quality Platform heavily tested Platform heavily tested A lot of reuse A lot of reuse Reduction of time to market

7. Software Product Lines Limitations First few projects take much greater time Team issues Inexperience with the domain Poor platform design

8. Engineering the Product Line Broken into two distinct processes: domain engineering and application engineering Reusability is key Strong emphasis on documenting variability Strong emphasis on documenting variability

9. Engineering the Product Line

10. Variability in the Product Line Managed variability Support activities concerned with defining variability Managing variable artifacts Support activities concerned with resolving variability Storing information to fulfill these tasks

11. Variability in the Product Line Types Types Variability in Time Variability in Time Variability in Space Variability in Space Where can Variability Come from? Where can Variability Come from? External External Variability needed to meet customer satisfaction Variability needed to meet customer satisfaction Internal Internal Variability caused by introducing external variation Variability caused by introducing external variation

12. Variability in the Product Line

13. How to Document Variability What needs to be documented? What varies? Why does it vary? How does it vary? For whom is it documented?

14. How to document Variability It is necessary to document It is necessary to document Can hold variation information directly in UML diagrams Can hold variation information directly in UML diagrams Feature Diagrams Feature Diagrams Orthogonal Variation Model (OVM) Orthogonal Variation Model (OVM)

15. Feature Diagram

16. Problems With These Methods Documenting Variability in UML Documenting Variability in UML Difficult to show to customer Difficult to show to customer Hard to find where all variation points are Hard to find where all variation points are Documenting Variability in Feature Models Documenting Variability in Feature Models Difficult to integrate into commonly used diagrams Difficult to integrate into commonly used diagrams The Orthogonal Variability Model captures all the information of variability while presenting it in a straight forward syntax and allowing the variation to be included in standard diagrams The Orthogonal Variability Model captures all the information of variability while presenting it in a straight forward syntax and allowing the variation to be included in standard diagrams

17. Orthogonal Variability Model (OVM) Definition: Definition: – “An orthogonal variability model is a model that defines the variability of a software product line. It relates the variability defined to other software product line. It relates the variability defined to other software development models such as feature models, use case models, design models, component models, test models.”

18. Orthogonal Variability Model (OVM)

19. Sample OVM Diagram

20. Domain Engineering Definition - “Process of software product line engineering in which the commonality and the variability of the product line are defined and realized.” Goal of developing a stable, flexible, maintainable platform Goal of developing a stable, flexible, maintainable platform

21. Domain Specification Commonality analysis: Commonality analysis: – Find requirements that are common to all applications Variability analysis: Variability analysis: – Find requirements that are variable Modeling Variability Modeling Variability – Finding variation points and variants – Generating the OVM

22. Use Case Diagram with OVM

23. Domain Design Support OVM variation points, mass customization Support OVM variation points, mass customization Use architectural patterns where necessary Use architectural patterns where necessary Command Pattern, MVC, Flyweight... Command Pattern, MVC, Flyweight... Time to start looking for commercial off the shelf software Time to start looking for commercial off the shelf software

24. Domain Design Reference Architecture Definition - “Core architecture that captures the high level design for the applications of the software product line.” Includes OVM Variation Points and Variants Provides limits on applications Determines what subsystems are reusable

25. Class Diagram and OVM

26. Package Diagram and OVM

27. Domain Implementation Generate common subsystems Generate common subsystems Create Interfaces that will be used by applications Create Interfaces that will be used by applications Purely abstract, no executables Purely abstract, no executables

28. Application Engineering Definition - “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.” Definition - “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.” High reuse of domain artifacts High reuse of domain artifacts Exploit commonality and variability of the software product line Exploit commonality and variability of the software product line

29. Application Specification Most requirements are derived from domain requirements Additional requirements need to be analyzed and estimated to ensure that they can be met by the product line

30. Application Design & Implementation Design: Modify reference architecture to meet application requirements Implementation: Setting up Interfaces Both: Add additional components where necessary Find objects to add into platform

31. Testing the Product Line Domain testing Domain testing Couple Options: Couple Options: Create simple applications Create simple applications Quicker validation Quicker validation Similar to single system testing Similar to single system testing Better Option: Better Option: Create test artifacts Create test artifacts Used to vary test applications Used to vary test applications

32. Testing the Product Line Application Testing Tests are usually derived from domain test artifacts Additional tests are necessary to ensure that variability is correct Test Coverage needs to take into account common and variable parts of the system

33. Testing the Product Line Guide Lines for dealing with Variability in the Product Line Guide Lines for dealing with Variability in the Product Line Structure the set of testing processes to test each artifact as early as possible Structure the set of testing processes to test each artifact as early as possible Structure test artifacts to accommodate the product line variation Structure test artifacts to accommodate the product line variation Maintain test artifacts Maintain test artifacts Structure testing software for traceability Structure testing software for traceability Automate regression testing Automate regression testing

34. Organization Structure Company may need restructuring to deal with software product lines Company may need restructuring to deal with software product lines Traditional team organization may not be adequate Traditional team organization may not be adequate Redundant roles across multiple projects Redundant roles across multiple projects Difficult to incorporate new members Difficult to incorporate new members Need to deal with domain development

35. Organization Structure Ways to deal with platform development Distribute domain engineers across all teams More difficult to decide common artifacts More difficult to decide common artifacts Decisions are decided more on a product to product basis Decisions are decided more on a product to product basis No specific place to bring platform ideas to No specific place to bring platform ideas to Create a dedicated team to develop the platform Platform covers all products Platform covers all products Place to bring new ideas to the platform Place to bring new ideas to the platform

36. Organization Structure Matrix Organizations Teams are organized by project and function

37. References [1] Bockle, G., Pohl, K., & van der Linden, F. (2010).Software product line engineering. Germany: Springer. [1] Bockle, G., Pohl, K., & van der Linden, F. (2010).Software product line engineering. Germany: Springer. [2] Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009). Engineering web applications [pp. 205-207]. Retrieved from http://www.scribd.com/doc/49704889/111/Software-Product-Line-Engineering doi: 10.1007/978-3-540-92201-8 [2] Casteleyn, S., Daniel, F., Dolog, P., & Matera, M. (2009). Engineering web applications [pp. 205-207]. Retrieved from http://www.scribd.com/doc/49704889/111/Software-Product-Line-Engineering doi: 10.1007/978-3-540-92201-8 [3] Schaefer, I., & Hahnle, R. (2011). Formal methods in software product line engineering. Computer, 44(2), Retrieved from http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5713307 [3] Schaefer, I., & Hahnle, R. (2011). Formal methods in software product line engineering. Computer, 44(2), Retrieved from http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5713307 [4] Metzger, A., & Pohl, K. (2007). Variability management in software product line engineering.Proceedings of the 29th International Conference on Software Engineering, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4222738 10.1109/ICSECOMPANION.2007.83. [4] Metzger, A., & Pohl, K. (2007). Variability management in software product line engineering.Proceedings of the 29th International Conference on Software Engineering, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4222738 10.1109/ICSECOMPANION.2007.83. [5] Li, D., & Chang, C.K. (2009). Initiating and institutionalizing software product line engineering: from bottom-up approach to top-down practice. Proceedings of the Computer Software and Applications Conference, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5254280 10.1109/COMPSAC.2009.17. [5] Li, D., & Chang, C.K. (2009). Initiating and institutionalizing software product line engineering: from bottom-up approach to top-down practice. Proceedings of the Computer Software and Applications Conference, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=5254280 10.1109/COMPSAC.2009.17. [6] Jaring, M., Krikhaar, R.L., & Bosch, J. (2008). Modeling variability and testability interaction in software product line engineering mode.Proceedings of the Composition-Based Software Systems, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4464016 10.1109/ICCBSS.2008.9. [6] Jaring, M., Krikhaar, R.L., & Bosch, J. (2008). Modeling variability and testability interaction in software product line engineering mode.Proceedings of the Composition-Based Software Systems, http://ieeexplore.ieee.org.ezproxy.uwplatt.edu/stamp/stamp.jsp?tp=&arnumber=4464016 10.1109/ICCBSS.2008.9. [7] A framework for software product line practice, version 5.0. (2009). Retrieved from http://www.sei.cmu.edu/productlines/frame_report/testing.htm [7] A framework for software product line practice, version 5.0. (2009). Retrieved from http://www.sei.cmu.edu/productlines/frame_report/testing.htm