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

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

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

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

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 1 st, and the other on Friday November 2 nd Use of slides, PowerPoint, etc. is fine and even encouraged. Whatever it takes to communicate effectively Remember that documentation also needs quality control

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

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

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

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

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

Examples double sqrt (int x) { a legitimate different implementation } double sqrt (int x) { return ; } 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

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

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

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?

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 ( ) might hide what other web search engines it uses Other examples?

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

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

Next time Project Management