Designing Software for Ease of Extension and Contraction

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. 128-138.
2
Presentation Outline

• Problem
• Motivation
• Observations
• Contribution
• Example
• Impact
• Questions

3
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

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 isnt 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 doesnt use A, so it doesnt increase its
  complexity.
• There exists a useful subset containing B and not
  A.
• There isnt 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 todays
  problems and applications? If so, how?