Designing Software for Ease of Extension and Contraction

Designing Software for Ease of Extension and Contraction D. L. Parnas © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 1

Introduction Design for extension and contraction is a special case of “design for change” Designing the “uses” relation is of great importance towards realizing the extension and contraction goals Identification of minimal subsets and minimal extensions in design can lead towards creating software that is flexible to change © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 2

Problems Then (and Now) Difficulty in creating early releases with a subset of functionality Difficulty adding simple features without extensive changes to the code base Difficulty optimizing the system by removing inefficient code or unnecessary program features © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 3

Program Families (Revisited) Program Families are sets of related programs n n Appear often in large software development projects Important to study the similarities between family members Useful model for thinking about commonality and things that are likely to change n n According to Parnas engineers are trained to think about design for change but software engineers are not Patterns help us out these days with helping to think about change, especially for designing flexible software solutions Program families promote “subsetting” n Members are subsets of other members, or several members share a common subset © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 4

Parnas & Software Architecture “I discuss an earlier stage of design, the stage when one identifies the major components of the system and defines the relations between those components. We focus on the early stage because the problems described in the introduction result from failure to consider early design decisions carefully. ” Sounds like software architecture, and the software architecture community commonly recognizes that making an early bad architecture decision is very difficult to recover from… © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 5

What Makes Design for Extension and Contraction Difficult Excessive Information Distribution n Based on assumptions made about a feature being present (or not present) A Chain of Data Transforming Components n n Pipe and filter approaches are hard to extend Also occurs from a “flowcharting” design approach Components that Perform more than One Function n Hard to “subset” thick components Loops in the “Uses” Relation n Nothing works until everything works © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 6

The Methodology STEP 1: Identify the subsets first n n As part of requirements identify the minimal subsets, and then incrementally refine. Get users thinking in terms of minimal specification STEP 2: Design w/ Information Hiding n n n Identify the “secrets” – Things that are likely to change Locate specialized components in separate modules Define inter-module interfaces that are insensitive to the anticipated changes © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 7

The Methodology STEP 3: The Virtual Machine Concept n n n Stop thinking about systems in terms of components that correspond to steps in the processing. The VM contains extended software instructions The programmer should not distinguish between facilities provided by the hardware and the facilities provided by the VM © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 8

The Methodology STEP 4: Designing the “Uses” Hierarchy n n n The “Uses” relation: A uses B if the correct execution of B is required by A Constraining the “Uses” relation to a hierarchy helps create independently testable and useable subsets of the system Designing the “Uses” hierarchy is a major design milestone © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 9

The Methodology Criteria for the “Uses” relation n n A is essentially simpler because it uses B B is not substantially more complex because it is not allowed to use A There is a useful subset containing B and not A (otherwise we would combine them) There is no conceivably useful subset containing A but not B All of the above should hold for allowing A to use B © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 10

Paper Takeaways The requirements include subsets and extensions n Flexibility cannot be an afterthought it’s a requirement Advantages of the VM approach n Designing software as if it will run on a VM breaks the flowcharting mentality Differences between flexibility and generality n n n General software can be used in a variety of situations without change Flexible software can be changed easily This is a design tradeoff © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 11

Paper Takeaways Differences between modules and subprograms n n n A module includes all subprograms that must be changed together A unit of change extends beyond a subprogram Consider the relation between components and objects Avoiding Duplication n Duplication generally infers a design error © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 12

Summary: Paper Goals Provide concepts and suggestions that allow programmers to design software so that subsets and extensions are easily obtained Programmers are not accustomed to thinking about designing software for change and extension A methodology is presented to help programmers take a different approach towards constructing software systems © Drexel University Software Engineering Research Group (SERG) http: //serg. cs. drexel. edu 13