Keeping Secrets Within a Family: Rediscovering Parnas

1
Keeping Secrets Within a Family Rediscovering
Parnas

• H. Conrad Cunningham
• Computer Information Science, University of
  Mississippi
• Cuihua Zhang
• Computer Information Systems, Northwest Vista
  College
• Yi Liu
• Computer Information Science, University of
  Mississippi

2
Program Family

• Set of programs
• sharing many common properties
• worthwhile to study as a group before each
  individually
• David Parnas
• If you are developing a family of programs, you
  must do that consciously, or you will incur
  unnecessary long-term costs.

3
Our Viewpoint

• Students should
• learn to design program families
• also known as software frameworks or product
  lines
• be taught appropriate development principles and
  techniques
• see examples of both good and bad designs
• apply what they are taught on relevant exercises
• Parnas and others articulated many elegant and
  useful ideas in the 1970s and 1980s.

4
How Much Progress?

• In 1976, Parnas published the seminal article On
  the Design and Development of Program Families.
• In 2001, Parnas wrote
• Although there is now growing interest and
  some evidence of success in applying the idea,
  the majority of industrial programmers seem to
  ignore it in their rush to produce code.

5
Parnas Principles

• Information hiding modules
• Abstract interfaces
• Program families

6
Parnas PrincipleInformation-Hiding Modules

• Module
• Work assignment given to a programmer or group of
  programmers
• Information hiding
• Design modules around assumptions that are likely
  to change
• Hide a design decision within a module
• as its secret

7
Table Framework Example

• Table ADT
• collection of records
• each a finite sequence of data fields
• key field value uniquely identifies record within
  collection

• Operations
• insert
• delete
• retrieve
• etc.

key1 data1
key2 data2
key3 data3
key4 data4
8
Table Framework Requirements

• Provide Table ADT functionality (in Java)
• Support large domain of client-definable records
  and keys
• Enable many possible implementations of Table ADT
• Separate key-based record access mechanisms from
  storage mechanisms

9
Table Framework Modules

• Table Access
• enables key-based access to records
• Secret set of data structures and algorithms
  used in accessing records
• Record Storage
• manages physical storage
• Secret detailed nature of storage medium
• Client Record
• provides key and record data types
• Secret structure of the clients record

10
Teaching Perspective Information Hiding

• What Parnas says
• consider it the most important and basic
  software design principle
• mentioned in very many textbooks, but it is
  treated in a very shallow manner
• can be explained in 40 minutes
• takes at least a semester of practice to learn
  how to use
• Thus explain thoroughly, give illustrative
  examples, assign meaningful exercises, and
  evaluate student work rigorously

11
Parnas Principle Abstract Interfaces

• Interface
• set of assumptions a programmer needs to make
  about another program to demonstrate correctness
  of his program
• Abstract Interface
• module interface that does not change when one
  module implementation is substituted for another

12
Abstract Interface Design

• Parnas two-phase approach
• List assumptions common to all implementations of
  the modulein precise English
• Give specific operations and describe syntax and
  semantics of each operationin programming
  notation

13
Table Framework Design Client Record Module
Interface

• Assumption list
• Records are objects from which the keys can be
  extracted and compared using a total ordering.
• As needed, records can be converted to and from a
  sequence of bytes. It is possible to determine
  the number of bytes in the record.

14
Table Framework Design Client Record Module
Interface

• Programming interface
• interface Comparable to represent totally ordered
  keys
• int compareTo(Object key) ? from Java API
• interface Keyed to represent records for table
  access
• Comparable getKey()
• interface Record to represent storable records
• void writeRecord(DataOutput)
• void readRecord(DataInput)
• int getLength()

15
Teaching PerspectiveAbstract Interfaces

• Concept not difficult to introduce, but takes
  much practice to learn to use well
• use case studies to illustrate
• give design guidelines
• assign relevant exercises
• evaluate student designs rigorously
• Little-used two-phase procedure is good approach
  for education
• no new notations or technologies to learn
• students consider explicit assumptions about
  module in design of programming interface

16
Parnas Principle Program Families

• Set of programs
• sharing many common properties
• worthwhile to study as a group before each
  individually
• Specification approach
• Identify design decisions which cannot be common
  properties of the family
• Hide each decision as the secret of a module
• Define an abstract interface suitable for all
  likely variants of module

17
Table Framework Design

• Table Access module implementations
• Simple in-memory index
• Hashed index
• Record Storage module implementations
• In-memory array
• Random-access file on disk
• Challenge
• Design of abstract interface for Record Storage
  with sufficient capability for Table Access but
  realizable on multiple media

18
Teaching PerspectiveProgram Families

• Give strong foundation in design of
  information-hiding modules with abstract
  interfaces
• build on capabilities of OOP language
• Teach to recognize and define scope of possible
  families
• Introduce techniques for commonality/variability
  analysis of families
• Start by using software frameworks
• hotspot analysis and systematic generalization
  techniques

19
Conclusion

• Students should learn to design program families
• Design principles publicized by Parnas 30 years
  ago are still valuable
• Good software design is hard work requiring
  understanding and practice
• The approach to design of software families can
  be stated as keeping secrets within a family

20
References Information-Hiding

• D. L. Parnas. On the Criteria to Be Used in
  Decomposing Systems into Modules, Communications
  of the ACM, Vol. 15, No.12, pp.1053-1058, 1972.

21
References Abstract Interfaces

• K. H. Britton, R. A. Parker, and D. L. Parnas.
  A Procedure for Designing Abstract Interfaces
  for Device Interface Modules, In Proceedings of
  the 5th International Conference on Software
  Engineering, pp. 195-204, March 1981.

22
References Program Families

• D. L. Parnas. On the Design and Development of
  Program Families, IEEE Transactions on Software
  Engineering, Vol. SE-2, No. 1, pp. 1-9, March
  1976.

23
Acknowledgements

• Acxiom Corporation grant
• The Acxiom Laboratory for Software Architecture
  and Component Engineering (ALSACE).
• Students in ENGR 660 Software Engineering class
  in Fall 2003