On the Design and Development of Program Families

1. On the Design and Development of Program Families D. L. Parnas

2. Program Families Program families are defined as sets of programs whose common properties are so extensive that it is advantageous to study the common properties of the programs before analyzing individual members.

3. Program Families • A program family is a set of programs: • Where it is adventitious to identify the common properties of the set of programs prior to determining the properties of the individual programs • But programming techniques were designed to develop individual programs and not program families • Program families are common, but informal techniques are often used to build them

4. Why Program Families • The desire not to start from scratch when creating a new program • Some programming families naturally result from environmental constraints • Example: The need to run the same or similar programs on multiple OS: • Application Servers – must support common functionality on different operating systems

5. Developing Program Families the Classical Way… • Build a working program • Make some design decisions • Modify the working program to create the next member in the family • Each design decision can either constrain or expand the set of possible programs in the family

6. Developing Program Families the Classical Way… Start d1 Design Decision’smay lead to anexpansion in possible programs Design Decision’smay lead to anexpansion in possibleprograms d2 d3 d4 p1 d5 p4 p3 p2

7. Problems with the “Classical Technique” • Program families members tend to be direct ancestors of each other • Program family members tend to “inherit” undesirable or inappropriate aspects from their ancestors • Hard to remove undesirable design decisions from earlier versions that don’t apply any longer

8. A New Way for Program Family Development Start Consider a technique wereprogram family members arenot direct descendants, but arebased on a common ancestorinstead. d1 d2 d3 d4 Program family membersare at the leafs of the tree d5 d6 d7 d8 d9 dA dB p2 p3 p4 p7 p8 p5 p6

9. Advantages of the Alternative Approach Towards Creating Program Families • Forces designers to layout the software architecture first • Don’t have to inherit as much of the “bad” in program family members • Creates the notion of subfamilies – a further refinement level useful for understanding and management • Program family versions don’t need to be built sequentially

10. Why is Classical Technique Commonly Used • The newer technique requires the intermediate stages to be precisely specified so that it can be used for the basis of a branch point to create another program in the program family • The classical technique tends allows the intermediate stage not to be well-defined • Modifying something that is “finished” is more in line with human intuition • Its hard to maintain a disciplined approach where the intermediate stages are depicted as partially designed programs rather than a set of design decisions.

11. An Alternative Approach:Stepwise Refinement • With a Stepwise Refinement approach: • Intermediate stages are functionally complete • Key operators and operands are left “abstract” – to be defined at a later stage • Assumes these operators and operands are “built into” the design • The program family is created from a current state where there are multiple alternatives for implanting the operators and operands • A stepwise refinement approach is one where a design decision is a refinement step

12. An Alternative Approach:Stepwise Refinement • Assumes that a top-down approach is feasible for the entire program family • Family members are created for each possible implementation of an “abstract” operator defined at earlier steps • The overall framework must be designed early in this technique, and remain relatively constant over the evolution of the program families

13. An Alternative Approach:Module Specification • This approach is based on information hiding • Design decisions that differentiate program family members are identified and hidden in modules • Intermediate representations are not partially implemented programs – they are specifications of the externally visible behavior (modules)

14. An Alternative Approach:Module Specification • Characteristics of the Module Specification Approach • Implementation decisions are hidden inside of modules and postponed to later stages • Modules can encapsulate both unique and common properties of individual program family members • Sequencing and program flow-of-control decisions don’t have to be defined early

15. What’s in a Module Specification • Description of module dependencies – e.g., what does it depend on, what depends on it • What output does the module produce • What inputs does the module require • What are the module interfaces • What are the input/output formats • What are the “exceptional” events that can the module can produce or that it must deal with • …

16. Module Specifications and Program Families • Implementation Methods • Each implementation of a module specification is a member of the program family • Subfamilies may be defined by dividing a module into submodules • Variation in the External Parameters • The module specification can be parameterized so that a family of specifications results – each implementation of one of the specifications is a member of the program family • Use of subsets • Applications in the program family that are based on using only a subset of the overall set of module specifications

17. Commonality in the New Techniques • Stepwise Refinement and Module Specification techniques share certain characteristics: • Precise representation of the intermediate stages is required • Certain design decisions can be postponed while continuing to make progress to the overall goal

18. Differences in the New Techniques • Stepwise Refinement (SR) and Module Specification (MS) techniques have some significant differences: • Sequencing Decisions: generally they must be made early in SR, and very late in MS • Time to Market: SR enables working families to be developed faster than MS • Applicability: SR is only appropriate for a limited set of program families, MS is more general and can be applied widely • Adaptability: Its hard to recover from an early bad design decision in SR, and much easier to adopt in MS since information hiding is used In a nutshell, SR and MS are complementary(not competitive) approaches

19. Today’s “Program Families” – Software Product Lines According to the SEI… A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. http://www.sei.cmu.edu/plp/product_line_overview.html

20. “Software Product Lines” • Buy a set of core functions and then customize • Create a number of 1-off implementations customized to specific user/company requirements • Advantages: • Common set of core functions • Core functions develops over time • Not starting from scratch • Reduce the risk of a complicated system implementation failing

21. “Software Product Lines” • All companies must perform a set of similar services • Billing, Ordering, Inventory Management, Asset Management, Customer Service, etc. • These services are common to some extent but require customization • Software product lines are not “out of the box” solutions but are “almost out of the box” solutions • Its been a very profitable business – consider the success of SAP, Peoplesoft, Oracle

22. Summary: Program Families • Provides a way to consider program structure more objectively by focusing on similarities in the program family • Recognizes the need to hide design and implementation decisions when creating a family – not to do so will negatively influence the programs in the program family • Concepts in program families are used today in software product lines (e.g., ERP systems)