IEEE TRANSACTIONS 128 ON SOFTWARE decrease in mental effort or increase in comprehensibility appears to motivate the purification of algorithms 8 9 10 REFERENCES 1 N Bulut and M H Halstead Impurities found in algorithm implementations ACM SIGPLAN Notices vol 9 pp 9 12 Mar 1974 2 L 1 Chmura and H F Ledgard Cobol With Style Programming Proverbs Rochelle Park Nl Hayden 1976 3 0 1 Dahl E W Dijkstra and C A R Hoare Strnctured Programming New York Academic 1972 4 1 L Elshoff Measuring commercial PL I programs using Halstead s criteria ACM SIGPLAN Notices vol 11 pp 38 46 May 1976 5 M H Halstead Natural laws controlling algorithm structure ACM SIGPLAN Notices vol 7 pp 19 26 Feb 1972 6 Elements of Software Science New York Elsevier 1977 7 I D Hill R S Scowen and B A Wichmann Writing algorithms in ALGOL 60 Software Practice and Experience vol 5 pp 223 224 luly Sept 1975 II 12 Ronald p 90 ENGINEERING VOL SE 5 NO 2 MARCH 1979 B W Kernighan and P J Plauger The Elements ofProgramming Style New York McGraw Hill 1974 Programming style Examples and counterexamples ACM Computing Surveys vol 6 pp 303 319 Dec 1974 D E Knuth A review of structured programming Dep Comput Sci Stanford Univ Stanford CA Tech Rep 371 June 1973 D E Knuth and R W Floyd Notes on avoiding GO TOstatements Inform Process Lett vol 1 pp 23 31 Feb 1971 J M Yohe An overview of programming practices ACM Computing Surveys vol 6 pp 221 245 Dec 1974 D Gordon for a photograph and biography see this issue DAVID L PARNAS Abstract Designing software to be extensible and easily contracted is discussed as a special case of design for change A number of ways that extension and contraction problems manifest them lves in urrent software are explained Four steps in the design of software that is more flexible are then discussed The most critical step is the design of a software structure called the uses relation Some criteria for design decisions are given and illustrated using a small example It is shown that the identification of minimal subsets and minimal extensions can lead to software that can be tailored to the needs of a broad variety of users Index gineering Terms Contractibi1ity subsets extensibility modularity software en supersets Manuscript received June 7 1978 revised October 26 1978 The earliest work in this paper was supported by NV Phillips Computer Industrie Apeldoorn The Netherlands This work was also supported by the National Science Foundation arid the German Federal Ministry for Research and Technology BMFT This paper was presented at the Third International Conference on Software Engineering Atlanta GA May 1978 The author is with the Department of Computer Science University of North Carolina Chapel Hill NC 27514 He is also with the Information Systems Staff Communications SciencesDivision Naval Research Laboratory Washington DC I INTRODUCTION T HIS paper is being written because the following complaints about software systemsare so common I We were behind schedule and wanted to deliver an early releasewith only a proper subset of intended capabilities but found that that subset would not work until everything worked 2 We wanted to add simple capability but to do so would have meant rewriting all or most of the current code 3 We wanted to simplify and speed up the system by removing the unneeded capability but to take advantageof this simplification we would have had to rewrite major sections of the code 4 Our SYSGEN was intended to allow us to tailor a system to our customers needs but it was not flexible enough to suit us After studying a number of such systems I have identified some simple concepts that can help programmers to design software so that subsetsand extensionsare more easily obtained These concepts are simple if you think about software in the way suggestedby this paper Programmers do not commonly do so 0098 558917910300 0128 00 75 1979 IEEE PARNAS EXTENSION AND CONTRACTION OF SOFTWARE II SOFTWAREAs A FAMILY OF PROGRAMS When we were first taught how to program we were given a specific problem and told to write one program to do that job Later we compared our program to others considering such issues as space and time utilization but still assuming that we were producing a single product Even the most recent literature on programming methodology is written on that basis Dijkstra s A Discipline of Programming 1 uses predicate transformers to specify the task to be performed by the program to be written The use of the defmite article implies that there is a unique problem to be solved and but one program to write Today the software designer should be aware that he is not designing a single program but a family of programs As discussed in an earlier paper 2 we consider a set of programs to be a program family if they have so much in common that it pays to study their common aspectsbefore looking at the aspects that differentiate them This rather pragmatic definition does not tell us what pays but it does explain the motivation for designing program families We want to exploit the commonalities share code and reduce maintenance costs Some of the ways that the members of a program family may differ are listed below 1 They may run on different hardware configurations 2 They may perform the same functions but differ in the format of the input and output data 3 They may differ in certain data structures or algorithms becauseof differences in the available resources 4 They may differ in some data structures or algorithms because of differences in the size of the input data sets or the relative frequency of certain events 5 Some users may require only a subset of the servicesor features that other users need These less demanding users may demand that they not be forced to pay for the resources consumed by the unneeded features Engineers are taught that they must try to anticipate the changesthat may be made and are shown how to achieve designs that can easily be altered when these anticipated changes occur For example an electrical engineer will be advised that the world has not standardized the 60 cycle IIO V current Televi sion designers are fully aware of the differing transmission conventions that exist in the world It is standard practice to design products that are easily changed in those aspects Unfortunately there is no magic technique for handling unanticipated changes The makers of conventional watches have no difficulty altering a watch that shows the day so that it displays MER instead of WED but I would