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

Problem Motivation Observations Contribution Example Impact Questions

Problem and Motivation

Problem 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

Overview of Contribution

Observations

Recognizing how the lack of Subsets and extensions manifests itself

The Technique: Steps towards a better structure

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?

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

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

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.

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.

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)

An Address Processing Subsystem

Component Programs Address Input Module

Address Output Module

Address Storage Module

Block File Module

Address File Module

An Address Processing Subsystem Uses Relation

Impact

Modern Programming Languages

Class Diagrams

More Flexibility!

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?