160 likes | 304 Views
On the design and development of program families. Presented by: M. Deng and J. Zhang 4/15/2002. CSE870 Advanced Software Engineering, Spring 2002. Overview. Objective Definition of program families A set of programs First common features of these programs Then variation of each program
E N D
On the design and development of program families Presented by: M. Deng and J. Zhang 4/15/2002 CSE870 Advanced Software Engineering, Spring 2002
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.
Overview (cont’d) • Technique Overview • Sequential Method • Features • Disadvantages
Overview (cont’d) • Stepwise Method Vs. Specification Method • Features • Combination
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
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.
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
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.
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
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.
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
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.
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
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.
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.