Program Families

1. Program Families CSE870 Discussion

2. Family of Programs • Grouping/finding COMMON functionality • Reuse of designs/code across family members • “Pushing design decisions as late as possible”

3. 3 Approaches • Classical Sequential : • Develop specific program completely • Subsequent programs are derived from original program • Identify specific points to be changed • Complete design process BEFORE making changes for other family members

4. Stepwise Refinement • Top-down approach • Start with abstract designs • Refine each point until you reach concrete functionality • Partial design • Intermediate points can have deviations • Intermediate points may not be implemented • Programming for change • Keep intermediate nodes flexible • Pattern Usage: Strategy, Template • Tree Shape: Long and skinny

5. Stepwise Refinement • Advantages: • No extra cost: no extra specifications • Because you reverse design decisions, you can still reuse all of the ancestors prior to that intermediate point • Clean development cycle: • Top-down advantages: narrowing the implementation space; no synthesis problem • Disadvantages • Early decisions: have to make many design decisions early in the process • Changes to the ancestor tree can have major impact on more of the final designs • Narrow family: variation among family members may be quite small

6. Module Specification • Basic idea: Decompose functionality into modules • Module: • Collection of functions to perform specific service • interface (group together collection of operations/data into one entity) • Approach: • Bottom clustering of functionality into modules • Intermediate stage is a module specification • Can be realized by “body implementations” for specification • Module specification is not part of final program code for any family member • Tree Shape: • Broader: delay design decisions until very late in process

7. Module Specification • Advantages: • More choices early (I.e., delay design decisions) • Gain independence among module implementations • Parallel development • Information Hiding (via specifications) • Exploits OO properties (modularity, encapsulation, reuse, abstraction, etc.) • Documentation (via specifications) • Intermediate node: comprise multiple module specifications, thus allowing for choice among the modules for final functionality.

8. Module Specification • Disadvantages: • Cost: of developing specifications • Overhead in initial specification – each functionality must be specified (well-understood) • More difficult: abstract the services/data across many possible designs/implementation • Requires “master” programmer experience

9. When to use • Module specification: • Use to specify services and abstract data types without commitments to design • Use stepwise refinement for the parts that you have a clear understanding of a majority of the design

10. Applications of Program Families • Operating Systems : different versions • Web browsers: across vendors and within vendor • Wysiwig vs command-line editors • Product-line engineering • Domain analysis/engineering

11. Frameworks: • Customize frameworks to achieve program families • Module Specification: • Whitebox: • Delaying design decisions until late, designer implement as appropriate • Stepwise Refinement: • Graybox: • Design structure is already known • At intermediate node, you can branch to a different decision, but you don’t need to backtrack to previous design decisions.