On the Development of Program Families

D. L. Parnas

Presentation bySagnik 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 of ancestors

1

2

3

7

4

659 8

-Any program that runs right is obsolete.

Example: Sorting First, we decide to use Bubble sort :

1. Read the list.

2. while not at end of list

3. compare adjacent elements

4. if second is greater than first

5. switch them

6. get next two elements

7. if at least one switch takes place

8. repeat for entire list

9. Output the sorted list.

Example: Sorting If we decide to use Insertion sort :

1. Read the list.

2. while not at end of list

3. compare adjacent elements

4. if second is greater than first

5. switch them

6. get next two elements

7. if at least one switch takes place

8. repeat for entire list

9. Output the sorted list.

Example: Sorting If we decide to use Insertion sort :

1. Read the list.

2. i = 0;

3. while not at end of list

4. find ith smallest element and put in ith position

5. repeat for entire list

6. 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 is a complete program

Unlikely to be the case

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: SortingStep 1:

1.Read unsorted list

2.Sort the list

3.Output sorted list.

Step 2:2a. Scan through list

2b. Perform sorting ops.

Step 2:2a. Divide into 2 sublists.

2b. Sort sublists.

2c. Merge sublists

Bubble sort Insertion sort 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

Create family members by further sub-modules or stepwise refinement

Variation in external parameters 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. Input: Current State of board

2. Select Next Move

3. Change State of Board

-Computer analyst to programmer: "You start coding. I'll go find out what they want."

Example: Chess By Stepwise Refinement

1. Input: Current State of board Look ahead n positions (20 billion positions in 3 mins

if you’re the 1997 Deep Blue)

Select best position

3. 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 Decisionsa. Internal representation of board

b. Chess playing module

c. Master Control module

2. Hide Design Decisionsa. 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.