designing software for ease of extension and contraction n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Designing Software for Ease of Extension and Contraction PowerPoint Presentation
Download Presentation
Designing Software for Ease of Extension and Contraction

Loading in 2 Seconds...

play fullscreen
1 / 14

Designing Software for Ease of Extension and Contraction - PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Designing Software for Ease of Extension and Contraction' - lacy-faulkner


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
Presentation Outline
  • Problem
  • Motivation
  • Observations
  • Contribution
  • Example
  • Impact
  • Questions
problem and motivation
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
Overview of Contribution
  • Observations
  • Recognizing how the lack of Subsets and extensions manifests itself
  • The Technique: Steps towards a better structure
observations
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
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
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
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
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
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 subsystem1
An Address Processing Subsystem
  • Component Programs
    • Address Input Module
    • Address Output Module
    • Address Storage Module
    • Block File Module
    • Address File Module
impact
Impact
  • Modern Programming Languages
  • Class Diagrams
  • More Flexibility!
open questions
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?