Designing Software for Ease of Extension and Contraction

Group 1:Lisa Anthony

Erik Hayes

Luiza Da Silva

Diana Tetelman

CS575 – Software Design Fall 2001 Drexel University

“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

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.

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 => FOCUS of PAPER

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

Steps Toward a Better Structure

Requirements definitions:Identify subsets first; Search for minimal useful subsets and increments to the system; Include them in requirements

Information Hiding:During 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 module’s 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)

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.

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

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

SpellCheck

ThesaurusPicture Objects

Tables

Dictionary GUI

Search

WordCount

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

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

Doesn’t give away details of implementation Doesn’t reveal any internal design decisions

Apply Virtual Machine approach when possible Input and output Data representation

Design Decisions for Example Systems

Parnas’ design decision suggestions may not be detailed enough for today’s complex systems.

Any suggestions from the class about what design and decomposition decisions could be made?

Use Text Editor as example system

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

Text Editor:High Level Decomposition

Text Editor_______________Char[] textBuffer_______________

WriteBuffer()ReadBuffer()

Spellchecker____________________________________

spellWord()correctWord()suggestWord()

GenericDictionary____________________________________

getWord()getDefinition()

compareWord()

SpellingDictionary____________________________________

getWord()compareWord()

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)

Text Editor:Lower Level Decomposition

Text Editor_______________Char[] textBuffer_______________

WriteBuffer()ReadBuffer()

<<interface>>Output

WindowsOutput_______________

_______________toFront()toBack()

<<interface>>Input

WindowsInput_______________

_______________getChar()

<<interface>>FileStream

WindowsFileStream____________________________________

fileOpen()fileClose()

Editing____________________________________

cutText()copyText()pasteText()

Selection____________________________________

selectText()deselectText()

“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 today’s OO systems.

“Uses” Relation Diagram for Text Editor System

Text Editor

WindowsOutputWindowsInputWindowsFileStreamEditing

Selection

Spellchecker

GenericDictionary

SpellingDictionary

5 4 10 15 3

7

15

3

Summary & Conclusions

Early subset identification Meet variety of needs Handle scheduling problems

Use of the virtual machine Extensible Removable

Summary Continued

Generality vs. flexibility General implies variable use

Run-time costEasier maintenance (single version)

Flexible implies ease of changeDesign-time costMultiple versions

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

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

Summary Finally Continued

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