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
4
6
5
start
0
start point
1
an incomplete program
2
a complete program
3
7
8
Overview (cont’d)
– Stepwise Method Vs. Specification Method
• Features
• Combination
start
0
1
start point
2
3
an incomplete program
6
a complete program
4
5
7
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 ObjectOriented 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.