Designing Software for Ease of Extension and Contraction

1
Designing Software for Ease of Extension and
Contraction

• Group 1
• Lisa Anthony
• Erik Hayes
• Luiza Da Silva
• Diana Tetelman

Fall 2001
Drexel University
CS575 Software Design
2
Design for change is here to stay

• Idea Software design that eases identification
  of working system subsets and addition of
  extensions is a special case of design for
  change, and therefore should be pursued.
• How Parnas suggests methodology that helps
  achieve better, more flexible design structure
• Key points
• Family of Programs
• Uses Relations
• Information Hiding
• Virtual Machines

3
Motivation

• Common Complaints about Software Systems
• Subset of capabilities not possible because
  subsets do not work on their own.
• Adding a capability (no matter how simple)
  implies major code rewriting.
• Removing a capability also implies major code
  rewriting.

4
Software As a Family of Programs

• A set of programs is considered a family if they
  have so much in common that it pays to study
  their common aspects before looking at their
  differences. Parnas
• Ways members of a program family can differ
• Run on different hardware configurations
• Same functions, but different format in
  input/output, data structures, algorithms etc
• Some users may require only a subset of the
  services or features that other uses need gt
  FOCUS of PAPER

5
Obstacles when trying to extend or shrink systems

• Excessive information distribution
• Chain of data-transforming components
  (pipe-and-filter deficiency)
• Components that perform more than one function
• Loops in the Uses Relation

6
Steps Toward a Better Structure

• Requirements definitionsIdentify subsets first
  Search for minimal useful subsets and increments
  to the system Include them in requirements
• Information HidingDuring module definition, try
  to isolate changeable parts in modules and create
  interfaces between module and rest of system
  Modules should not be aware of other modules
  existence
• The Virtual Machine Concept
• Think module responsibility assignment Create
  set of VMs so problem can be broken into smaller
  parts, and subsets found more easily Each VM
  must be a useful subset
• Designing the Uses Structure (detail next slide)

7
Designing the Uses Structure

• The relation uses
• A uses B if correct execution of B is necessary
  for A to complete task described in its
  specification.
• Uses is NOT the same as invokes
• Unrestricted usage causes module
  interdependency
• Criteria to be used when allowing one program to
  use another
• A is simpler because it uses B
• B is not more complex because it is not allowed
  to use A
• There is a useful subset containing B and not A
• There is no conceivable useful subset containing
  A but not B.
• Sandwiching technique used when criteria cannot
  be followed, but programs can benefit from using
  each other.

8
Family Concept

• Some users may require only a subset of the
  services or features that other users need.
  These less demanding users may demand that they
  not be forced to pay for the resources consumed
  by the unneeded features.
• Parnas
• Subsets Extensions
• Minimal subsets of a useful nature minimal
  possible increments
• Develop family of programs, not individual
  one-off systems
• Common functionalities
• Share code
• Reduces maintenance cost

9
Sample Family Graph

• Text editor contains most basic functionality.
  No frills. Can be used without the other
  modules, if needed.
• Design each module so system can function
  properly with or without that module
• Different subgroups of modules can define a
  target system

Text Editor
Dictionary
GUI
Word Count
Spell Check
Thesaurus
Picture Objects
Tables
Search
10
Example System Specification Text Editor

• Display and edit text
• Copy/Cut/Paste
• Select
• Add/Remove
• Spell-check text
• Using Dictionary database
• Words/Definitions
• Correction suggestion heuristics

11
Design and Decomposition Decisions

• Determine module secrets - items most likely to
  change
• Separate/isolate them in modules
• Information hiding/encapsulation
• Some modules should interact via a bland
  intermodule interface
• Doesnt give away details of implementation
• Doesnt reveal any internal design decisions
• Apply Virtual Machine approach when possible
• Input and output
• Data representation

12
Design Decisions for Example Systems

• Parnas design decision suggestions may not be
  detailed enough for todays complex systems.
• Any suggestions from the class about what design
  and decomposition decisions could be made?
• Use Text Editor as example system

13
High-Level Modules and Their Secrets

• Main Text Editor module
• Representation of text
• Editing methods
• Spell-checker module
• Searching/checking algorithm
• Heuristics for Correction Suggestions
• Dictionary module
• Arrangement of records
• Language

14
Text EditorHigh Level Decomposition
15
Low-Level Modules

• Text Editor
• Base system, bare-bones functionality
• Input/Output modules (through interfaces)
• Input/output format
• OS specific calls
• Selection Module
• Text selection mechanism
• Editing Module
• Text manipulation (cut/copy/paste operations)
• File Handling (through interface)
• File manipulation (open/close/save operations)

16
Text EditorLower Level Decomposition
17
Uses Hierarchy

• NO LOOPS in the uses hierarchy!
• Avoid module coupling when possible to ease
  contraction and extension.
• Parnas uses relation diagram too detailed.
  Need only show class level uses relations.
• Weighted uses diagrams more interesting for
  todays OO systems.

18
Uses Relation Diagram for Text Editor System
Text Editor
WindowsOutput
WindowsInput
WindowsFileStream
Editing
Spellchecker
Selection
SpellingDictionary
GenericDictionary
19
Summary Conclusions

• Early subset identification
• Meet variety of needs
• Handle scheduling problems
• Use of the virtual machine
• Extensible
• Removable

20
Summary Continued

• Generality vs. flexibility
• General implies variable use
• Run-time cost
• Easier maintenance (single version)
• Flexible implies ease of change
• Design-time cost
• Multiple versions

21
Summary Still Continued

• Modules, subprograms, and levels
• Modules encompass several subprograms
• Unit of change
• Modules can form abstractions without forming
  levels
• Programs within modules can span levels of the
  uses hierarchy

22
Summary Continued Again

• Avoiding duplication
• Given proper use of structured programming
• Allow for subsets and extensions
• Provide convenience without extra cost
• No development of support software
• Consider design vs. run-time trade-offs at later
  point in time

23
Summary Finally Continued

• Value of a design model
• Allows consistent development
• More design in less time