Information hiding • Information hiding is perhaps the most CSE503: Software Engineering important intellectual tool developed to support software design [Parnas 1972] – Makes the anticipation of change a centerpiece David Notkin in decomposition into modules University of Washington Department of Computer Science & Engineering • Provides the fundamental motivation for Winter 2002 abstract data type (ADT) languages – And thus a key idea in the OO world, too 1 2 Basics of information hiding Anticipated changes • Modularize based on anticipated change • The most common anticipated change is – Fundamentally different from Brooks’ approach in “change of representation” OS/360 (see old and new MMM) – Anticipating changing the representation of • Separate interfaces from implementations data and associated functions (or just functions) – Implementations capture decisions likely to change – Again, a key notion behind abstract data types – Interfaces capture decisions unlikely to change – Clients know only interface, not implementation •Ex: – Implementations know only interface, not clients – Cartesian vs. polar coordinates; stacks as linked • Modules are also work assignments lists vs. arrays; packed vs. unpacked strings 3 4 Claim Other anticipated changes? • We less frequently change representations than we used to • Information hiding isn’t only ADTs – We have significantly more knowledge about data structure design than we did 25 years ago • Algorithmicchanges – Memory is less often a problem than it was previously, since it’s – (These are almost always part and parcel of ADT-based much less expensive decompositions) • Therefore, we should think twice about always anticipating – Monolithicto incremental algorithms that representations will change – Improvements in algorithms – This is important, since we can’t simultaneously anticipate all changes • Replacement of hardware sensors – Ex: Changing the representation of null-terminated strings in Unix – Ex: better altitude sensors systems wouldn’t be sensible • And this doesn’t represent a stupid design decision •More? 5 6 1 Ubiquitous computing domain Central premise I • Portolano is a UW CSE project on this topic • We can effectively anticipate changes – Devices everywhere, handhelds, on-body devices, – Unanticipated changes require changes to interfaces or automated laboratories, etc. (more commonly) simultaneous changes to multiple modules • The set of anticipated changes is significantly • How accurate is this premise? different than in many other domains – Wehavenoidea – Data is more stable than computations – There is essentially no research about whether – Must accommodate diversity in communication speed, anticipated changes happen reliability, etc. – Nor do we have disciplined ways to figure out how to • Interesting domain for information hiding better anticipate changes 7 8 The A-7 Project Central premise II • In the late 1970’s, Parnas led a project to redesign • Changing an implementation is the best change, the software for the A-7 flight program since it’s isolated – One key aspect was the use of information hiding • This may not always be true • The project had successes, including a much – Changing a local implementation may not be easy improved specification of the system and the – Some global changes are straightforward • Mechanically or systematically definition of the SCR requirements language – VanHilst’s work showed an alternative • But little data about actual changes was gathered • Using parameterized classes with a deferred supertype [ISOTAS, FSE, OOPSLA] – Griswold’s work on information transparency 9 10 Central premise III Central premise IV • The semantics of the module must remain • One implementation can satisfy multiple unchanged when implementations are clients replaced – Different clients of the same interface that need – Specifically, the client should not care how the different implementations would be counter to interface is implemented by the module the principle of information hiding • But what captures the semantics of the • Clients should not care about implementations, as module? long as they satisfy the interface – The signature of the interface? Performance? – Kiczales’ work on open implementations What else? 11 12 2 Information hiding reprise Information Hiding and OO • It’s probably the most important design • Are these the same? Not really technique we know – OO classes are chosen based on the domain of the problem (in most OO analysis approaches) • And it’s broadly useful – Not necessarily based on change • It raised consciousness about change • But they are obviously related (separating • But one needs to evaluate the premises in interface from implementation, e.g.) specific situations to determine the actual • What is the relationship between sub- and benefits (well, the actual potential benefits) super-classes? 13 14 Layering [Parnas 79] The uses relation • A focus on information hiding modules • A program A uses a program B if the isn’t enough correctness of A depends on the presence of a correct version of B • One may also consider abstract machines • Requires specification and implementation – In support of program families of A and the specification of B • Systems that have “so much in common that it pays to study their common aspects before looking at the • Again, what is the “specification”? The aspects that differentiate them” interface? Implied or informal semantics? • Still focusing on anticipated change –Canuses be mechanically computed? 15 16 uses vs. invokes Parnas’ observation • These relations ipAddr := cache(hostName); • A non-hierarchical uses relation makes it often but do not if wrong(ipAddr,hostName) then difficult to produce useful subsets of a always coincide ipAddr := lookup(hostName) • Invocation without endif system use: name service – It also makes testing difficult with cached hints – (What about upcalls?) • Use without invocation: • So, it is important to design the uses examples? relation 17 18 3 Criteria for uses(A,B) Layering in THE (Dijkstra’s layered OS) •Ais essentially simpler because it uses B • OK, those of you who took OS •Bis not substantially more complex because • How was layering used, and how does it it does not use A relate to this work? • There is a useful subset containing B but not A • (For thinking about off-line, or for email • There is no useful subset containing A but discussion) not B 19 20 Modules and layers interact? Language support Segment ADT • Information Segment Mgmt. • We have lots of language support for information hiding hiding modules modules and Process Mgmt. – C++ classes, Ada packages, etc. layers are Process ADT • We have essentially no language support for distinct Segment Creation layering concepts – Operating systems provide support, primarily for •Howand Process reasons of protection, not abstraction Creation where do they – Big performance cost to pay for “just” abstraction overlapina system? 21 22 Next lecture • Implicit invocation – Essentially, event-based design 23 4.