Designing Software for Ease of Extension and Contraction

Designing Software for Ease of Extension and Contraction David Parnas Presented by Kayra Hopkins IEEE Transactions on Software Engineering, Vol. , No. 1, March 1979 pp. 128 -138.

Presentation Outline n n n n Problem Motivation Observations Contribution Example Impact Questions

Problem and Motivation n Problem ¨ n How can we design software so that is is easily extended and contracted? Motivation ¨ Complaints that most software systems as commonly/intuitively designed are not flexible. n Changes require a lot of code rewriting

Overview of Contribution n Observations n Recognizing how the lack of Subsets and extensions manifests itself n The Technique: Steps towards a better structure

Observations n A software solution isn’t a single program ¨ n Software as a family of programs Change is inevitable ¨ So why not anticipate it with preparation?

How the lack of subsets and extensions manifests itself n Excessive Information Distribution n A Chain of Data Transforming Components n Components That Perform More Than One Task n Loops in “Uses” Relation

Steps towards a better structure n Identify Subsets first Solves problem of components with more than one function ¨ Makes system more flexible to change ¨ n Information Hiding: Define Interfaces and Modules ¨ n Virtual Machine Concept ¨ n Solves problem of excessive information distribution Addresses chain of data problem Design the “Uses” Structure ¨ Eliminates loops in the “uses” relation

Steps towards a better structure(2) n n Design the “Uses” Structure ¨ Program A “uses” program B if function of A depends on correct implementation of B. ¨ Structure has hierarchy. Consequences A is simpler because it uses B. ¨ B doesn’t use A, so it doesn’t increase its complexity. ¨ There exists a useful subset containing B and not A. ¨ There isn’t a practical subset containing A but not B. ¨

Example: Address Processing Subsystem n Assumptions: ¨ Specific address information is to be processed ¨ Input formats are subject to change. Likewise with output formats. ¨ For each system the format for input and output may be done in one of three ways. ¨ Representations of address may be different for each system. ¨ Only a subset of the addresses are needed in main memory at any given time.

An Address Processing Subsystem n Design Decisions ¨ Input and Output will be table driven ¨ Representations of addresses in core will be the “secret” of an address storage module(ASM) ¨ When the number of addresses to be stored exceeds the capacity of ASM, programs will use an address file module (AFM) ¨ Implementation of AFM will use ASM as a submodule along with a block file module (BFM)

An Address Processing Subsystem n Component Programs ¨ Address Input Module ¨ Address Output Module ¨ Address Storage Module ¨ Block File Module ¨ Address File Module

An Address Processing Subsystem n Uses Relation

Impact n Modern Programming Languages n Class Diagrams n More Flexibility!

Open Questions n What is a universal message that we can take away from this problem? n Could planning for change not be cost-effective? /Is there ever a situation that you would not want to plan for change? n Should this technique be modified for today’s problems and applications? If so, how?