On the Design and Development of Program Families

Roy MammenJerry Cheng

Sharan MudgalDoug Paida

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

newer techniques Conclusions

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.

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.

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.

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.

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 …

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.

New Techniques

Stepwise Refinement Module Specification

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.

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.

Example: Virtual Memory ManagementStep 1:Action.1 If (page fault), then (save the status & switch to kernel mode).

Action.2 “Run page fault replacement algorithm”, to find the old page.

Action.3 If (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

How SRs Defines a family

Each possible implementation of an operator defines a family member.

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.

Module Specification

Intermediate Stages

Specifications of externally visible behavior of multi-procedure modules.

Implementation decisions and sequencing of events are postponed.

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).

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.

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.

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

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.

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

Stepwise Refinement Technique

Advantages No overhead involve in designing first

complete program “Rollback” feature

Disadvantages Possible overhead caused by design

decision changes Narrower family

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

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)

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.

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}….}

Example (cont.)

Deallocate

Allocate

Alloc_firstfit()

Alloc_bestfit()

Alloc_binarysystem()

Dealloc_firstfit()

Dealloc_bestfit()

Dealloc_binarysystem()

Buddy-upBuddyup_firstfit()

Buddyup_bestfit()

Buddyup_binarysystem()

Questions?