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 1970’s and 1980’s.

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 Principle:Information-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.

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 client’s 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 module—in precise English • Give specific operations and describe syntax and semantics of each operation—in 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 Perspective:Abstract 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 Perspective:Program 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 onSoftware 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