On the Design and Development of Program Families David Parnas Presented by Gregory Brown IEEE Transactions on Software Engineering, VOL SE-2, NO. 1, March 1976

Ouline Problem and Motivation Overview of Contribution –Stepwise Refinement –Module Specification Example Application –Stepwise Refinement –Module Specification Impact Open Questions

Problem and Motivation Problem –Investigated production of program families –“Classical Method”: sequential completion –Each member was a full working program –Each one built from an ancestor –Each inherits the design decisions of ancestors Motivation: –Make good, common design decisions up front –Parallel development of family members

Overview of Contribution Stepwise Refinement Each member is a functioning program Successive steps add funcitonality Each step represents design decision(s) No unnecessary functionality No performance degradation Revert back to previous step

Overview of Contribution Module Specification Intermediate steps not programs Steps are specifications of collections of functionality Modules made to hide design decisions Early work designed to postpone decisions Make a wide program family possible

Overview of Contribution Module method avoids disadvantages of stepwise refinement Stepwise refinement does make design decisions - rollback can lose this The two are complementary Stepwise refinement lower complexity Module method requires more work

Example application Stepwise refinement Dijkstra’s prime problem Step 1: bestyet := null while not all.spaces considered do begin find next item from list of free spaces bestyet := bestof(bestyet,candidate) end if bestyet = null then erroraction allocate(best yet):remove(best yet)

Example application Stepwise refinement Step 2: bestyet := 0 candidate := 0 while candidate != N do begin candidate := candidate+1 bestyet := bestof(bestyet,candidate) end if bestyet = 0 then erroraction allocate(best yet) remove(best yet)

Example application Module Specification Dijkstra’s prime problem Split into information-hiding modules Modules: –Free space list –Allocation –Selection criterium

Impact Stepwise refinement is often used –Add functionality to existing software –Using modules and patterns –General strategy to developing systems Revision control systems Module specification part of OO design –Encapsulation to hide implementation –Commonly taught and used practice Module specification allowed for development of patterns

Impact Stepwise refinement and module specification complementary Can create software in stages, but using modules Complementary approaches Use strategy pattern among others to ease work

Open Questions How could the two best be combined to enhance software development? When is it a good idea to not use stepwise refinement or module specification? Does the classic approach Parnas described not have a place at all?