Transcript Designing Software for Ease of Extension and Contraction David Parnas

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


Virtual Machine Concept


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)


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?