Review of David L. Parnas’ “Designing Softwarefor Ease of Extension and Contraction”Alexander Sverdlov <[email protected]>March 12th, 2004AbstractThis talk reviews David L. Parnas’ paper titled “Designing Software forEase of Extension and Contraction”, discusses some of the key ideas, andrelates them to current times.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [1]Introduction• A way of viewing software requirements.• Spotting subset requirements.• Guessing extensions.• Building software as a family of programs, with each program solving somedistinct problem.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [2]Requirement Sub-setsAssuming reasonable requirement variation, what pieces are ‘constant’? (orare least impacted) by likely changes.• Finding sub-sets.• Starting implementation from these sub-sets.• ‘Uses’ Relationtheparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [3]Requirement ExtensionsAfter implementing the sub-sets, what other possible likely c hanges (orextensions) to requirements do we normally have to care about.• We cannot predict these (no more than we can predict the future).• Need to design system to be flexible.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [4]Family of Programs• Build software as many programs instead of one monolithic solution.• Let programs use each other: the Uses Relationtheparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [5]Use RelationWe don’t want to duplicate functionality that may be common to manyprograms in the family-of-programs.• If program A needs functionality found in program B, then program A shoulduse program B to accomplish the task.• This needs clear inter-program interfaces (a real world example may be U NIXpipes)theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [6]Use Relation, Cont.• The ‘uses’ relation must not create cycles. If a program A is used by programB, then program A shouldn’t use program B.• The used programs should be very generally written to handle a specific task.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [7]Chain of ProgramsA software system may do processing by passing data from one program tothe next, with each doing its own bit of processing before passing it on to anotherprogram (until it reaches the end of the line, which would be the output).• Successfully implemented in UNIX, via ‘pipes’.• Can cause problems if format is transformed (then pipe components aren’tremovable—even if they’re not needed).theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [8]Comparison to Modern DayDid the world improve?• Most operating systems have many small programs to do distinct tasks.• Sub-programs are generally not used (nor applicable) in s imple situations(especially those presented in the article; the address book).• Use of libraries instead of ‘programs’.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [9]Not much ProgressAs great as this paper is, and with many having tried these approaches (OOP,etc.) the software industry is still very much faced with exactly the same issuesthis paper is trying to address.Software is still very difficult to develop in such a way that makes it easy tochange in face of changing requirements, and easily expandable if needed.This is the holy grail of software development.theparticle.comSoftware Engineering Designing Software for Ease of Extension and Contraction [10]ConclusionGreat educational & enlightening paper. Not very ‘real world’ practical dueto its age, and the general lack of applicability to the way software is built today(very few people think of creating a few dozen separate executables to solve asingle