1. 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

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 => 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 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)

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 Spell Check Thesaurus Picture Objects Tables DictionaryGUI Search Word Count

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 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

12. 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

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 Editor: High Level Decomposition Text Editor _______________ Char[] textBuffer _______________ WriteBuffer() ReadBuffer() Spellchecker __________________ spellWord() correctWord() suggestWord() GenericDictionary __________________ getWord() getDefinition() compareWord() SpellingDictionary __________________ getWord() compareWord()

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 Editor: Lower Level Decomposition Text Editor _______________ Char[] textBuffer _______________ WriteBuffer() ReadBuffer() > Output WindowsOutput _______________ toFront() toBack() > Input WindowsInput _______________ getChar() > FileStream WindowsFileStream __________________ fileOpen() fileClose() Editing __________________ cutText() copyText() pasteText() Selection __________________ selectText() deselectText()

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

18. “Uses” Relation Diagram for Text Editor System Text Editor WindowsOutputWindowsInputWindowsFileStreamEditing Selection Spellchecker GenericDictionary SpellingDictionary 5410153 7 3

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