1. On the Design and Development of Program Families Roy Mammen Jerry Cheng Sharan Mudgal Doug Paida

2. Overview What is a “program family”? Classical method Newer techniques Comparison of classical method to the newer techniques Conclusions

3. What is a “program family”? Set of programs with so much in common that it pays to study their common properties first, before analyzing the individual members. A typical example is the set of editions of an application or operating system.

4. Why are program families of interest? Multiple versions are unavoidable. - Varying hardware configurations. - Varying demands of users. - Opportunity to improve a program. Production and maintenance of multiversion programs can be expensive. Planning to develop as a program family from the start can help cut these costs, decrease time to get a new product to market.

5. Software Product Lines Groups of software products sharing a common set of features that satisfy the needs of a particular market. Develop common, reusable components that can be tailored using parameters or other means. Build as much of a product using existing components first, then do a minimal amount of new programming. Benefits: faster time to market, increased reliability, reduced costs.

6. Product Line Example Cummins, Inc. Manufacturer of diesel engines and engine control system software. 1993 – needed to produce 20 new systems, but had staff to produce just 6. Brought together developers from different geographic markets to create a common set of software components. Development time for new engine control system reduced from a year to just days.

7. How are families produced? The “classical” method - Develop a working program. - Make some design decisions - Apply these to the working program to produce next version. - And so on …

8. Disadvantages Removal of decisions is not easily done. Therefore, some descendants may contain the results of decisions made early on that no longer apply to later versions. You have to completely finish a program before being able to produce the next family member.

9. New Techniques Stepwise Refinement Module Specification

10. Stepwise Refinement Basic Idea Develop the system “step by step” as a series of working prototypes, with each one having greater functionality than the previous one.

11. Stepwise Refinement Intermediate Stages Working prototypes with abstract implementations of some operators and operand types. Design Decision = Refinement step. Implementation decisions are postponed to later stages. Sequencing of events are made early in this technique.

12. Example: Virtual Memory Management Step 1: Action.1If (page fault), then (save the status & switch to kernel mode). Action.2“Run page fault replacement algorithm”, to find the old page. Action.3If (old page has been changed), then (modify the corresponding disk space). Action.4“Update the page table entry” for the old page ( bit valid=0). Action.5“Load the new page in to the memory” form the disk. Action.6“Update the page table entry” for the new page. (bit valid=1). Refinement Step2: (Two possible Design Decisions for Action.2) Least Recently Used FIFO Not recently used 2a Linked list of all pages 2b Array of all pages with R, M bits

13. How SRs Defines a family Each possible implementation of an operator defines a family member.

14. Module specification Basic Idea (Information Hiding) Design Decisions that differentiate family members are identified and hidden in modules. Rest of the program can be written independently of design decision that differentiate members.

15. Module Specification Intermediate Stages Specifications of externally visible behavior of multi-procedure modules. Implementation decisions and sequencing of events are postponed.

16. Module Specification Unambiguous specification of a module’s functions. What does it depend on? (input/state). What does it produce? (outputs/side effects). What does it do exactly? (I/O correspondence). What can go wrong? (exceptions/error outputs).

17. Example: Virtual Memory Management Modules Page_Replacement module. Update_PageTable module. Read_Disk module. Contains procedures to load the requested page from the disk to memory (RAM). Write_Disk module. Modifies the actual content of the old page in the disk, if it has been changed before replacement. Master Control.

18. How MSs Defines a Family Implementation methods used within modules. Variation in external parameters. Use of subsets. Applications that make use of subset of programs described by the set of module specifications. Example: OS Versions.

19. Classical Method Sequential Completion Particular member is developed to working stage Each decision reduces the set of possible programs Modify the working program to get another Descendants could share some of its ancestor’s characteristics which are not appropriate Could result in performance deficiencies

20. Example Program families for sorting. First develop a program to sort for a given input of integers. Read the list Sort the list Print the output Just by changing the parameters for the program to include float, double and strings, program families for sorting can be obtained.

21. Classical vs. New Methods Intermediate stages not well defined Intermediate stages are completely specified Earliest common ancestor is a complete program Unlikely to be the case Intermediate stages are non-deliverable as they are not represented precisely Intermediate stages, though incomplete can be offered as a contribution

22. Stepwise Refinement Technique Advantages No overhead involve in designing first complete program “Rollback” feature Disadvantages Possible overhead caused by design decision changes Narrower family

23. Module Specification Technique Advantages Shorter Development time Minimal overhead in maintenance/changes to a module Broader family Disadvantages All decisions must be well specified Overhead in initial specification

24. Conclusion Which is better? They’re complementary of each other. They may be used together to develop a program family. Example (Simulation of a simple memory management system)

25. Simulation of a simple memory management system Requirements Parse through a list of pid with its corresponding request of memory size/block to allocate or de-allocate. Allocate memory block using 3 different allocation policy. First fit, Best fit & Buddy system (Power of 2) De-allocate memory block. Buddy up after de-allocation and etc.

26. Example (cont.) Main() {…. While (not finishing reading line) { Read line() allocate() or deallocate() if deallocate buddy up memory blocks Log fail/sucess goto next line } …. }

27. Example (cont.) Deallocate Allocate Alloc_firstfit() Alloc_bestfit() Alloc_binarysystem() Dealloc_firstfit() Dealloc_bestfit() Dealloc_binarysystem() Buddy-up Buddyup_firstfit() Buddyup_bestfit() Buddyup_binarysystem()

28. Questions?