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

2. Presentation Outline Problem Motivation Observations Contribution
Example
Impact
Questions

3. Problem and Motivation
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.
Changes require a lot of code rewriting

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

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

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

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

8. Steps towards a better structure(2)
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.

9. Example: Address Processing Subsystem
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.

10. An Address Processing Subsystem
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)

11. An Address Processing Subsystem
Component Programs
Address Input Module
Address Output Module
Address Storage Module
Block File Module
Address File Module

12. An Address Processing Subsystem
Uses Relation

13. Impact
Modern Programming Languages
Class Diagrams
More Flexibility!

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