CSE403 Software Engineering Autumn 2001 Design (Information Hiding)

1. CSE403 Software Engineering Autumn 2001Design (Information Hiding) Gary Kimura Lecture #8 October 17, 2001

2. Today • Design Specs and Design Reviews • Understand information hiding as a principle for decomposing systems into modules • Be able to distinguish module decompositions that are based on information hiding from those that aren’t

3. Design Specs • What it needs to cover • Typical outline for dev • Introduce and motivate the problem again • Fairly in-depth environment and API description • General design approach “the 60,000’ view” • Some of the fundamental data structures, algorithms, and organization that is going to be used in the implementation • Milestones and time schedule • Level of detail • Enough that a competent practitioner of the art can implement the design • Almost like a Patent in the detail needed

4. Design Reviews There are both internal and external reviews • Internal design reviews are typically done among team members • External design reviews are done by inviting outside experts to review and critique your design • External reviews can be external to your group or external to your company. The latter is often done under an NDA • Some groups used both types of reviews • Goal is to sanity check your design and get constructive feedback • Need to boil it down to its essence when you present your design

5. Project Design Reviews • Plan for approximately 40 minutes of presentation followed by 10 minutes of Q & A • Presentation needs to include the project design, internal dev design, testing and documentation that you’ll be using in the project • One group on Thursday November 1st, and the other on Friday November 2nd • Use of slides, PowerPoint, etc. is fine and even encouraged. Whatever it takes to communicate effectively • Remember that documentation also needs quality control

6. Information hiding principle, motivation • A fundamental cost in software engineering is accommodating change • A change that requires modifying multiple modules is more costly than a change that is isolated in a single module • Therefore • Anticipate likely changes • Define interfaces that capture the stable aspects and implementations that capture the changeable aspects

8. Small examples • double sqrt (int) • Can be implemented using bisection methods, factoring methods, Newton’s method • The client doesn’t care, and this can change (requiring only relinking—and not even that for some dynamic linking systems) • Very low level example, of course • An historical aside: what was the original goal of procedures (with parameters) • Most people answer, “For this kind of abstraction, of course!” • It’s not true: the original goal was to save memory, which was the most precious resource

9. Another simple example type intSet is intSet create();insert(intSet,int);delete(intSet,int); bool member(intSet,int); int size(intSet);end intSet;

10. Hiding secrets • These two examples show specific kinds of secrets that modules hide • Algorithms • Data representations • The interfaces capture stable decisions • Clients depend on these interfaces • The implementations encode the changeable parts • Clients do not depend on these

11. Interface • An interface has two parts • The signature: the names and type information about the exported functions • The specification: a precise description of the semantics of the elements in the module • Most commonly, the signature is in a programming language and the specification is in natural language • But you cannot neglect the specification

12. Examples • double sqrt (int x) { a legitimate different implementation} • double sqrt (int x) { return 3.14159;} • bool member (intSet s,int i) { return IsOdd(i)} • Ridiculous examples, you say? • Sorry, that’s not true (although these examples are indeed extreme) • At the very least, many assumptions are made when interfaces are not fully defined

13. Design Level • Information hiding is a design principle, not a coding principle • Obviously, it can be reflected in code that is based on the design

14. Anticipating change • It’s “easy” to anticipate algorithmic and representational changes • But you cannot and should not do this and only this • By blithely anticipating these changes, you may not think about another kind of change that is more likely and potentially costly • In general, you cannot build a design that effectively anticipates all changes • A standard (albeit weak) analogy is that you can’t make everything in a car engine easily accessible • It’s expensive to replace a clutch not because it’s inherently hard, but rather because you have to yank out lots of the engine to get it • This is intelligent design, because clutches tend to last a long time, so making them expensive to replace is OK • Making it expensive to replace an oil filter would not be sensible

15. Data isn’t always abstracted • Unix byte streams are pervasive • Imagine trying to change Unix’s data model from byte streams to fixed width records • good or bad decision?

16. Other kinds of secrets • An information hiding module can hide other secrets • Characteristics of a hardware device • Ex: whether an on-line thermometer measures in Fahrenheit or Centigrade • Where information is acquired • Ex: the Metacrawler (www.metacrawler.com) might hide what other web search engines it uses • Other examples?

17. The classic decomposition • Top-down functional decomposition • Stepwise refinement • Based on the steps the actual computation will take

18. The data decomposition • Not based on the actual computation steps • Hides decisions about data representation • Could they be hidden in the previous decomposition? • Hides decisions about the granularity of sorting • The “sequence” relationship is hazy

19. Next time • Project Management