1. Designing Software for Ease of Extension and Contraction Presented by William Greenwell February 27, 2002

2. Volunteer Today!

3. About This Paper Written to address a real industry need. ICSE Most Influential Paper Award, 1991  Parnas: Was is really that influential? [1] Published in 1978, but many software professionals still don’t get it. [1] Parnas, D.L., “On ICSE’s ‘Most Influential Papers’”, ACM Software Engineering Notes, vol. 20, no 3, July 1995, pp. 29-32.

4. Software Flexibility Software should be written so that it can easily be extended and contracted. Programmers should think in terms of a family of programs, not a single product. Anticipate the likely changes, and design to be flexible toward them.

5. Why bother with all this?

6. Flexibility vs. Generality Generality – the ability of a system, without modification, to be valid for several applications. Flexibility – the ability of a design to be easily changed to accommodate new applications.

7. Extension & Contraction We extend software to add new features to existing versions. Why subset software?  Need to meet delivery deadline  Remove unneeded functionality  Test & debug prototypes

8. Inhibiting Factors Excessive information distribution Chain of data-transforming components  Typical consequence of flow-chart method Multi-function components Loops in the “uses” relation

9. Parnas’ Four-Step Plan 1. Identify possible subsets during requirements elicitation. 2. Exploit information hiding in interface and module descriptions. 3. Implement the system as several levels of virtual machines. 4. Make the “uses” structure a DAG.

10. Identifying the Subsets First identify the minimal useful subset of functionality, then add incremental extensions. Benefits:  Easier to create prototypes  System more adaptive to changes

11. Information Hiding Revisited 1. Identify the items likely to change. Parnas calls these secrets. 2. Locate each secret in its own module. 3. Design module interfaces that are insensitive to perceived changes. Q: If these are secrets, who/what are they being hidden from?

12. Virtual Machine Methodology 0 1 2 3

13. Defining the Uses Relation Program A uses Program B if there exist situations in which the correct functioning of A depends on the availability of a correct implementation of B. How uses differs from invokes:  A does not use B if A must only invoke B to satisfy A’s specification.  A does use B if A may implicitly invoke B (e.g. as an interrupt handler)

14. The Uses Hierarchy 0 1 2 3

15. When should A use B? 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; and There is no conceivably useful subset containing A but not B.

16. Sandwiching A B1B1 B2B2 B

17. Advice Include subsets & extensions in the requirements document. Design software as a set of virtual machines layered on top one another. Remember that flexibility ≠ generality. In general, isolate design decisions (secrets) into their own modules.