1 / 23

Keeping Secrets Within a Family: Rediscovering Parnas

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. Program Family.

staciem
Download Presentation

Keeping Secrets Within a Family: Rediscovering Parnas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related