On the Development of Program Families

1. On the Development of Program Families D. L. Parnas Presentation by Sagnik Bhattacharya Siddharth Dalal

2. 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.

3. 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.

4. 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."

5. 1 2 3 4 9 7 5 6 8 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.

6. Example: Sorting • First, we decide to use Bubble sort : • 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.

7. Example: Sorting • If we decide to use Insertion sort : • 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.

8. Example: Sorting • If we decide to use Insertion sort : • 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.

9. 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.

10. Classical vs. New (’76 new) -Computers can never replace human stupidity.

11. 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."

12. Example: Sorting • Step 1: • Read unsorted list • Sort the list • 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 Merge sort Insertion sort

13. 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.

14. Example: Sorting • Modules : • List storage • Input • Sorting module • Output • Master Control

15. 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.

16. Example: Chess • By Stepwise Refinement • 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."

17. Example: Chess • By Stepwise Refinement • 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 • Change State of Board -Computer analyst to programmer: "You start coding. I'll go find out what they want."

18. Example: Chess • By Module Specification • List Design Decisions • Internal representation of board • Chess playing module • Master Control module • Hide Design Decisions • Chess playing algorithm etc. -Computers are unreliable, but humans are even more unreliable.

19. 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.

20. Issues for discussion • Cost • Reusability • Effort • Size of software • Testing

21. 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.

22. 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.

23. 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

24. 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????

25. Links • N. Wirth, Program Development by Stepwise Refinement – http://www.acm.org/classics/dec95/ -Beware of Programmers who carry screwdrivers.

26. “... 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.