On the design and development of program families

1. On the design and development of program families Presented by: M. Deng and J. Zhang 4/15/2002 CSE870 Advanced Software Engineering, Spring 2002

2. Overview • Objective • Definition of program families • A set of programs • First common features of these programs • Then variation of each program • Example: Microsoft Office Family • Three techniques • Traditional method: Sequential development method • Two new methods: • Stepwise refinement method • Specification of information hiding modules method [Parnas76] David Parnas, “On the design and development of program families,” IEEE Transactions on Software Engineering, SE-2(1), 1-9, 1976.

3. Overview (cont’d) • Technique Overview • Sequential Method • Features • Disadvantages

4. Overview (cont’d) • Stepwise Method Vs. Specification Method • Features • Combination

5. Impact • Product line • Definition: a group of products that share a set of commonalities that meet the requirements of the market • CMU/SEI: a Framework of Software Product Line Practice • CMU/SEI: 1st Software Product Line Conference (SPLC1) in 2000 • Information hiding design principle in Object-Oriented programming languages • And so on

6. Related 1: Commonality Analysis • Objective • To identify the common features and variations among family members • Technique Overview • FAST (Family-oriented Abstraction, Specification and Translation) process • An early step of the FAST process • Participants: • Moderator, recorder, family analysis experts [Weiss98] David Weiss, “Commonality Analysis: A Systematic Process for Defining Families,” in 2nd International Workshop on Development and Evolution of Software Architectures for Product Families, February 1998.

7. Related 1 (cont’d) • Result: Commonality Analysis Document • Form: to hold a series of meetings • Five stages: • Prepare • Plan • Analyze: central part • Quantify • Review • Applicability: • Has been practiced in Lucent Technologies • How it extends Parnas’ work? • Provide a process

8. Related 2: Adaptable Components • Objective • One component represents a family of components • Technique Overview • An adaptable component has a group of parameters of adaptability [Campbell99] Grady Campbell, “Adaptable Components,” in Proceeding of 21st International Conference on Software Engineering (ICSE99), ACM, 685-686, 1999.

9. Related 2 (cont’d) • Two models of reuse: • Usual reuse model • Select from a library of components • Customize and then construct a new component • Time-consuming, error-prone • Adaptable component based reuse model • Select from the name of adaptable component • Make the decisions of parameters • How it extends Parnas’ work? • A component family

10. Related 3: Combining Product Line Engineering with Options Thinking • Objective • To introduce an appropriate economic model to justify the use of product line approach • Technique Overview • Product line approach needs more initial investment • The DCF Model can be used to justify the use of product line in cell phone companies • The DCF is not suitable to justify product line approach in an evolutionary product • The BSOP Model is a Model used in stock market to value the option. It is more suitable to justify an evolutionary product [Geppert01] Birgit Geppert and Frank Roessler, “Combining Product Line Engineering with Options Thinking,” in Proceedings of Product Line Engineering: The Early Steps (PLEES’01), September 2001.

12. Related 3 (cont’d) • How it extends Parnas’ work • Product line is an extension of program family • This work introduces an economic model to justify the use of the product line

13. Uncited: Multi-Staged Scoping for Software Product Lines • Objective • To propose a scoping method for the product line approach • Technique Overview • Why we need scoping? • What requirements a sound scoping method should meet? • Three components of the proposed scoping method • Product line mapping, domain based scoping, feature based scoping [Schmid00] Klaus Schmid, “Multi-Staged Scoping for Software Product Lines,” in Proceedings of Software Product Lines: Economics, Architecture, and Implications, June 2000.

14. Why it should have cited the paper • This paper should have cited Parnas’ paper for the same reason as the previous paper • Product line is a industrial interpretation of program family • This paper proposes a scoping method in product line

15. References • D. Parnas, “On the design and development of program families,” IEEE Transactions on Software Engineering, SE-2(1), 1-9, 1976. • http://www.sei.cmu.edu/plp/product_line_overview.html. • http://www.sei.cmu.edu/plp/conf/SPLC.html. • http://www.sei.cmu.edu/plp/framework.html. • D. Weiss, “Commonality Analysis: A Systematic Process for Defining Families,” in 2nd International Workshop on Development and Evolution of Software Architectures for Product Families, February 1998. • G. Campbell, “Adaptable Components,” in Proceeding of 21st International Conference on Software Engineering (ICSE99), ACM, 685-686, 1999.

16. References • B. Geppert and F. Roessler, “Combining Product Line Engineering with Options Thinking,” in Proceedings of Product Line Engineering: The Early Steps (PLEES’01), September 2001. • K. Schmid, “Multi-Staged Scoping for Software Product Lines,” in Proceedings of Software Product Lines: Economics, Architecture, and Implications, June 2000.