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. 2 Program Family Set of programs sharing many common properties sharing many common properties worthwhile to study as a group before each individually 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. 3 Our Viewpoint Students should : learn to design program families learn to design program families –also known as software frameworks or product lines be taught appropriate development principles and techniques be taught appropriate development principles and techniques see examples of both good and bad designs see examples of both good and bad designs apply what they are taught on relevant exercises 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. 4 How Much Progress? In 1976, Parnas published the seminal article “On the Design and Development of Program Families.” In 1976, Parnas published the seminal article “On the Design and Development of Program Families.” In 2001, Parnas wrote: 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. 5 Parnas Principles Information hiding modules Information hiding modules Abstract interfaces Abstract interfaces Program families Program families

6. 6 Parnas Principle: Information-Hiding Modules Module Work assignment given to a programmer or group of programmers Work assignment given to a programmer or group of programmers Information hiding Design modules around assumptions that are likely to change Design modules around assumptions that are likely to change Hide a design decision within a module Hide a design decision within a module –as its secret

7. 7 Table Framework Example Table ADT collection of records collection of records –each a finite sequence of data fields –key field value uniquely identifies record within collection Operations Operations –insert –delete –retrieve –etc. key1data1 key2data2 key3data3 key4data4

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

9. 9 Table Framework Modules Table Access Table Access –enables key-based access to records Secret: set of data structures and algorithms used in accessing records Record Storage Record Storage –manages physical storage Secret: detailed nature of storage medium Client Record Client Record –provides key and record data types Secret: structure of the client’s record

10. 10 Teaching Perspective: Information Hiding What Parnas says: “consider it the most important and basic software design principle” “consider it the most important and basic software design principle” “mentioned in very many textbooks, but it is treated in a very shallow manner” “mentioned in very many textbooks, but it is treated in a very shallow manner” “can be explained in 40 minutes” “can be explained in 40 minutes” “takes at least a semester of practice to learn how to use” “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. 11 Parnas Principle: Abstract Interfaces Interface set of assumptions a programmer needs to make about another program to demonstrate correctness of his program 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 module interface that does not change when one module implementation is substituted for another

12. 12 Abstract Interface Design Parnas two-phase approach List assumptions common to all implementations of the module—in precise English 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 Give specific operations and describe syntax and semantics of each operation—in programming notation

13. 13 Table Framework Design: Client Record Module Interface Assumption list 1. Records are objects from which the keys can be extracted and compared using a total ordering. 2. 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. 14 Table Framework Design: Client Record Module Interface Programming interface interface Comparable to represent totally ordered keys interface Comparable to represent totally ordered keys int compareTo(Object key)  from Java API interface Keyed to represent records for table access interface Keyed to represent records for table access Comparable getKey() interface Record to represent storable records interface Record to represent storable records void writeRecord(DataOutput) void readRecord(DataInput) int getLength()

15. 15 Teaching Perspective: Abstract Interfaces Concept not difficult to introduce, but takes much practice to learn to use well 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 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. 16 Parnas Principle: Program Families Set of programs sharing many common properties sharing many common properties worthwhile to study as a group before each individually worthwhile to study as a group before each individually Specification approach Identify “design decisions which cannot be common properties of the family” Identify “design decisions which cannot be common properties of the family” Hide each decision as the secret of a module Hide each decision as the secret of a module Define an abstract interface suitable for all likely variants of module Define an abstract interface suitable for all likely variants of module

17. 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. 18 Teaching Perspective: Program Families Give strong foundation in design of information- hiding modules with abstract interfaces 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 Teach to recognize and define scope of possible families Introduce techniques for commonality/variability analysis of families Introduce techniques for commonality/variability analysis of families Start by using software frameworks Start by using software frameworks –hotspot analysis and systematic generalization techniques

19. 19 Conclusion Students should learn to design program families Students should learn to design program families Design principles publicized by Parnas 30 years ago are still valuable Design principles publicized by Parnas 30 years ago are still valuable Good software design is hard work requiring understanding and practice 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 The approach to design of software families can be stated as keeping secrets within a family

20. 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. 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. 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 5 th International Conference on Software Engineering, pp. 195-204, March 1981. K. H. Britton, R. A. Parker, and D. L. Parnas. “A Procedure for Designing Abstract Interfaces for Device Interface Modules,” In Proceedings of the 5 th International Conference on Software Engineering, pp. 195-204, March 1981.

22. 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. 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. 23 Acknowledgements Acxiom Corporation grant: Acxiom Corporation grant: –The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE). Students in ENGR 660 Software Engineering class in Fall 2003 Students in ENGR 660 Software Engineering class in Fall 2003