On the Design and Development
of Program Families
Roy Mammen
Jerry Cheng
Sharan Mudgal
Doug 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
Management
Step 1:
Action.1
Action.2
Action.3
Action.4
Action.5
If (page fault), then (save the status & switch to kernel mode).
“Run page fault replacement algorithm”, to find the old page.
If (old page has been changed), then (modify the corresponding disk space).
“Update the page table entry” for the old page ( bit valid=0).
“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)
2a Linked list of all pages
Least Recently Used
FIFO
2b Array of all pages with R, M bits
Not recently used
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
What
What
What
does it
does it
does it
can go
depend on? (input/state).
produce? (outputs/side effects).
do exactly? (I/O correspondence).
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 Unlikely to be the case
a complete program
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.)
Allocate
Alloc_firstfit()
Buddy-up
Buddyup_firstfit()
Alloc_bestfit()
Buddyup_bestfit()
Alloc_binarysystem()
Buddyup_binarysystem()
Deallocate
Dealloc_firstfit()
Dealloc_bestfit()
Dealloc_binarysystem()
Questions?