On the Development of Program
Families
D. L. Parnas
Presentation by
Sagnik Bhattacharya
Siddharth Dalal
Overview



Families – sets of programs having
extensive common properties, better to
study than individual programs
Methods – sequential development,
stepwise refinement, module specification
Comparison of new methods and their
complementary advantages
-A bug in the code is worth two in the documentation.
Introduction

Example Program Families




OS Versions
Similar to hardware families
Traditional Methods – Single Program
Comparison of programming techniques in
suitability to develop families
-Adding manpower to a late software project makes it later.
Why Families



Versions for different applications, different
hardware
Improvement
Difficult non-trivial problem so need
methods/tools geared towards design of
families
-Alpha. Software undergoes alpha testing as a first step in
getting user feedback. Alpha is Latin for "doesn't work."
Classical Method



Sequential Completion –
Think like a computer
Family members are
derived from complete
programs
Descendants may share
undesirable characteristics 9
of ancestors
1
2
3
4
7
5
-Any program that runs right is obsolete.
6
8
Example: Sorting

First, we decide to use Bubble sort :
1.
2.
3.
4.
5.
6.
7.
8.
9.
Read the list.
while not at end of list
compare adjacent elements
if second is greater than first
switch them
get next two elements
if at least one switch takes place
repeat for entire list
Output the sorted list.
Example: Sorting

If we decide to use Insertion sort :
1.
2.
3.
4.
5.
6.
7.
8.
9.
Read the list.
while not at end of list
compare adjacent elements
if second is greater than first
switch them
get next two elements
if at least one switch takes place
repeat for entire list
Output the sorted list.
Example: Sorting

If we decide to use Insertion sort :
1.
2.
3.
4.
5.
6.
Read the list.
i = 0;
while not at end of list
find ith smallest element and put in ith position
repeat for entire list
Output the sorted list.
New Techniques



Older version may
not be ancestor of
newer ones
Common design
decisions taken early
Subfamilies can be
developed in parallel
-Bug? That's not a bug, that's a feature.
Classical vs. New (’76 new)
Intermediate stages not
well defined
Intermediate stages are
completely specified
Earliest common ancestor Unlikely to be the case
is a complete program
Intermediate stages are
non-deliverable
Intermediate stages,
though incomplete can be
offered as a contribution
-Computers can never replace human stupidity.
Stepwise Refinement (SR)



Intermediate stages are programs which are
complete except for the definition of
certain operators and operand types
Design decision = refinement step
Possible solutions = leaves = families
-Beta. Software undergoes beta testing shortly before it's
released. Beta is Latin for "still doesn't work."
Example: Sorting
Step
1:
1.Read
unsorted list
2.Sort the list
3.Output sorted list.
Step
2:
Step
2a. Scan through list
2b. Perform sorting ops.
Bubble sort
Insertion sort
2:
2a. Divide into 2 sublists.
2b. Sort sublists.
2c. Merge sublists
Merge sort
Module Specification (MS)


Intermediate stages are specifications of
externally visible collective behavior of
program groups called modules
Decisions which cannot be common
properties are identified and a module is
designed to hide the decision
-My software never has bugs. It just develops random features.
Example: Sorting

Modules :





List storage
Input
Sorting module
Output
Master Control
How MSs Define a Family

Implementation methods used within modules


Variation in external parameters


Create family members by further sub-modules or
stepwise refinement
Family of specifications for different parameters
Use of subsets


Programs consisting of a subset of programs
described by the set of module specs
e.g. OS versions like Win2k pro/server/advanced
server
-Computer and car salesmen differ in that the latter know when they are lying.
Example: Chess

By Stepwise Refinement
1.
2.
3.
Input: Current State of board
Select Next Move
Change State of Board
-Computer analyst to programmer: "You start coding. I'll go find out what they want."
Example: Chess

By Stepwise Refinement
Input: Current State of board
1.

Look ahead n positions (20 billion positions in 3 mins
if you’re the 1997 Deep Blue)

3.
Select best position
Change State of Board
-Computer analyst to programmer: "You start coding. I'll go find out what they want."
Example: Chess

By Module Specification
1.
List Design Decisions
a.
b.
c.
2.
Internal representation of board
Chess playing module
Master Control module
Hide Design Decisions
a.
Chess playing algorithm
etc.
-Computers are unreliable, but humans are even more unreliable.
Comparison



MS – broader family because design
decisions are hidden and can be changed
SR – Bound by decisions and so narrower
family
MS – greater effort – perfect module
interface specs required – grants the
flexibility to change design decisions later
-Build a system that even a fool can use, and only a fool will use it.
Issues for discussion





Cost
Reusability
Effort
Size of software
Testing
Families vs. System Generators



MS and SR are not intended to replace
system generators.
These methods can simplify a generator’s
work.
However, a simulator program would not
be efficient.
-Failure is not an option, it comes bundled with the software.
Which to Use?





Two methods not equivalent or
contradictory, but complementary
SR – make sequencing decisions early
MS – sequencing decisions????
Effort – MS>SR – large/small family
Hybrid method?
-Hardware: The parts of a computer system that can be kicked.
Conclusion



One cannot conclude that modularization is
better than stepwise refinement.
Lack of evaluation methods.
Modular specification implies more cost,
but permits production of a broader
program family.
-It's not a bug; it's an undocumented feature
Tools





SEI Product Line Initiative –
http://www.sei.cmu.edu/plp/
FAST http://www.hep.net/chep95/html/slides/it14
/it14.pdf
RAD Tools
Version Control?
LEX, YACC????
Links

N. Wirth, Program Development by
Stepwise Refinement –
http://www.acm.org/classics/dec95/
-Beware of Programmers who carry screwdrivers.

“... program structure should be such as to
anticipate its adaptations and modifications. Our
program should not only reflect (by structure) our
understanding of it, but it should also be clear
from its structure what sort of adaptations can be
catered for smoothly.Thank goodness the two
requirements go hand in hand.”

Djikstra
-Don't document the program; program the document.