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 of ancestors 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 i th smallest element and put in i th 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: Sorting Step 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 Decisions a. Internal representation of board b. Chess playing module c. Master Control module 2. 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 – FAST - /it14.pdf /it14.pdf RAD Tools Version Control? LEX, YACC????

Links N. Wirth, Program Development by Stepwise Refinement – -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.