6894 · workshop in software design lecture 1 · september 9, 1998 · introduction

1. 6894 · workshop in software designlecture 1 · september 9, 1998 · introduction

2. today’s lecture • introduction • my background • topics for today • course motivation & organization • approach to design • an illustrative example • where to find course info • http://sdg.lcs.mit.edu/~dnj/6894 • course administrator is Neena Lyall, lyall@lcs • readings available in NE43-523 • signup questionnaires • everyone here please hand one in!

3. why this course? • agenda to expand software design education at MIT • MIT students not familiar with modern design notions • what design notion can you articulate? for many, ADTs alone? • sometimes haven’t even heard of things that industry talks a lot about • design patterns, object models, UML, CMM? • should at least know current language of design, else can’t even critique! • MIT students should be leaders in design • point of most leverage • started introducing some ideas from this course in 6170 last spring • new kind of research project • design notions need to be evaluated on industrial-scale problems • historically, the best research ideas came from case studies (eg, Parnas’s A7 project) • research impact amplified by importance of application • build bridges to other departments, esp. aero/astro • computer scientists do too much navel gazing • hard to understand software problems if you only work on software for computer scientists • other engineering departments should benefit from EECS expertise

4. relation to other courses • what this course is not • a graduate reading seminar • we’re going to do research, not just talk about it • major tutorial component: you’ll be a better designer by the end • a survey course • not comprehensive or balanced: i’ve distilled what i think is most exciting • extensive hands-on experience (including me!) • how it differs in spirit from some undergraduate courses • 6001 • traditional view of program structure (layered, abstract machines) • code is the only language spoken • 6170 • focus on components, their specs and implementations • less concern for large-scale issues (eg, problem domain) • 6033 • case study approach, rather than broad principles • emphasis on global system properties not software structure

5. course organization • class • 2/week, 90 mins each • two kinds of lecture: tutorial (mostly early on), research topics • student presentations • puzzles • readings • reading list on web page, but don’t expect you to read all this! • most papers will be handed out • CTAS documentation on web and hard copies • what i do expect you to read (see schedule for details): • CTAS overviews by NASA • tutorial papers and excerpts • project • in teams of 2-4 • 4 phases: reverse eng, design, implementation, reflection • presentations & discussion in class, and meetings of teams individually with DNJ • final presentation (Dec 7) to NASA software development manager

6. student obligations & grading policy • what i expect you to do • attend lectures and participate critically • do required readings in advance of lecture • at least one presentation in the course of the term • guru roles: please volunteer • course webmaster • reverse engineering tool prep • source code control (know athena too?) • Java/C wrapping • grading policy • 80% project work, 20% class participation • on project work • 50:50 for oral:written • 30:30:30:10 by phase • reverse engineering matters a lot!

7. why CTAS? • it’s an important system • ATC is vital part of national infrastructure • CTAS is first step towards ‘free flight’ • CTAS offers more than modernization (cf. Advanced Automation System) • major development by CSC underway, which we might influence • it’s a good system • user interface is especially impressive • appears to be quite robust • won NASA Software of the Year Award, 1998 • it’s a hard problem • ATC is notoriously difficult • FAA’s Advanced Automation System • expected to pay $500/line (industry average was $100) • paid $700-900 • $144M of work discarded

8. software & infrastructure • a recent report • Interim Report of President’s IT Advisory Committee (Aug 98) • chaired by Bill Joy & Ken Kennedy • http://www.ccic.gov/ac/interim/ • findings • “The Nation depends on fragile software” • “Demand for software far exceeds the Nation’s ability to produce it” • “Major recommendation: Make fundamental software research an absolute priority” • “Recommendation: fund more fundamental research in software development methods and component technologies” (3.1.2)

9. design = modelling + patterns • this course’s approach to design • design = modelling + patterns • modelling • notation: how to say things • abstraction: how to avoid saying things • patterns • systematize common idioms to • distill experience, & convey expertise to novices • communicate designs • first step in theory of design? • lightweight modelling • biggest bang/$ • extensive use of visual representations • model : code ~ 1 : 100 (in size and effort to record) • safety-critical systems need more heavy weight stuff (eg, formal spec, proof)

10. not top-down design! • “In this respect, top-down development appears as an almost impossible recipe. Since the architecture is hierarchical, and built from the top, you are asked to make the most important decisions at the very beginning -- when you have the least information at your disposal to avoid design errors … Only a genius could do this.” • Bertrand Meyer; Object-oriented Software Construction; • Prentice-Hall, 1988, p325. • “... Until the foolishness of top-down design has been dropped in a fit ofcommon sense, the harrowing succession of flawed designs will continueto appear in high-tech, high-cost public projects.” • Eugene S Ferguson; Engineering and the Mind's Eye, pp188-189; MIT 1992. • Original in: Richard P Feynman; "What Do You Care what Other People Think?"; • New York 1988, pp226-232.

11. why modelling? • a model is… • an abstract representation of a system or component • usually very partial, but not vague • analyzable • what are models good for? • communicating ideas succinctly • without OMT, design patterns would not have happened? • can’t delegate effectively if code is the only precise representation • finding errors early on • models easier to analyze than code • can analyze before making major commitments • many errors found in process of modelling itself • making design process concrete • results in simpler, better designs

12. general principles • risk-driven approach • focus on the tricky bits! • but don’t gild the lily • some principles • principle of commensurate care • “The care taken in each aspect of a development should be proportional to P x D, where P is the probability that it will go wrong, and D is the size of the disaster if it does.” • principle of dispassionate methodology • “Don’t get your advice from a method enthusiast. The best advice comes from people who care more about your problem than about their solution.” • principle of deferred invention • “Invention should be delayed until description of what is already given has been completed.” • principle of beneficent difficulty • “Difficulties, explicitly characterized and diagnosed, are the medium in which a method captures its central insights into a problem” • generalities are generally wrong • principles from [Jac95]

13. common gripes • the programming linguist • artifacts disconnected from the code have no enduring use • can model in PL anyway • for now, no PL can express what a model can • the process evangelist • process matters more than product; technology is only a second-order effect • process is necessary but not sufficient, and most process is overkill • the artisan • problem isn’t really that hard • pick really smart hackers & customize approach to problem • no intellectual reuse, costs are often huge, poor utilization of resources, code may be inflexible • usually underestimates problem domain complexity • the pessimist • problem is too hard • plan to throw one away – you will anyway [Brooks 75] • some systems have to get built the first time! a self-fulfilling prophecy?

14. a taste of what’s to come • problem • you’re building a CAD tool for home architecture • elements (eg, walls) have ‘autodimensions’ associated with them • how are elements and their dimensions kept in sync? • a candidate design • just embed dimension object in each element object • make explicit call to dimension object in each mutating element method • class Wall { Dim dim; void stretch (int x) { length += x; this.dim.update (length);}… } • why this is bad • Wall and Dim are strongly coupled: can’t reuse Wall without Dim • gets worse as we add other dimension-like things: paint volume, eg • would like to make Wall independent of Dim

15. a better design: abstract coupling • basic scheme • Wall and Dim objects are linked in Subject-Observer pair • Wall’s reference to Dim is abstract: Wall only depends on minimal properties of observer • linking functionality separated from update functionality • protocol for transferring subject state to observer • observer is linked to subject by calling subject’s attach method • change to subject is followed by call to subject’s notify method • notify method calls observer’s update method • update method calls subject’s getState method • diagram (next slide) • abstract classes have italic names • arrows denote associations: ! means one, * means zero or more • triangles denote subclassing

16. GOF representation of Observer pattern Subject Attach (Observer)Detach (Observer)Notify () Observer Update () observers * for all o in observers { o.Update (); } observerState = subject.GetState () Concrete Subject GetState ()SetState () subjectState Concrete Observer Update () observerState ! subject return subjectState

17. sample code • abstract class Subject { Observer-set observers; void attach (Observer o) {observers.insert (o);} void detach (Observer o) {observers.delete (o);} void notify () {forall o in observers {o.update ();}} } • interface Observer { void update (); } • Wall extends Subject { int length; int getLength () {return length;} void stretch (int x) { length = length + x; notify (); } • Dim implements Observer { int length; Wall subject; void update () { length = subject.getLength (); }

18. why does it work? • why object model (next slide)? • code representation only shows namespace issues • object model exposes fundamental (computational) structure • crucial invariants • REGISTRATION all s: Subject, o: Observer | o in s.observers <-> o.subject = s • BROADCASE all s: Subject | all o: s.observers | o.state = F(s.state) • when do they hold? • REGISTRATION should always hold • pass subject in observer’s constructor • what if subject is deleted? • BROADCAST should hold after subject’s notify method is called • when is that?

19. object model for Observer observers * Subject Observer subject state state ? ? SubState ObsState

20. want help to expressdesign here! requirements code going for the hump • why are abstract models useful? • problem is getting from requirements to code • need technology to tackle hump in the middle • if too close to one end, much less useful • paradox • resistance to hump technology, because it’s unfamiliar

21. protocol issues • to maintain BROADCAST invariant • invent methods and allocate to objects • specify order in which methods are executed • subject • methods are • attach, detach, notify, getState, setState • ordering constraints • attach and detach in any order • setState followed by notify • specify as two ‘roles’ • REG-ROLE = (attach | detach)* • BCAST-ROLE = (getState | setState notify)* • granularity of updates • how often should notify be called? • might want to batch setState calls into ‘transactions’ • BCAST-ROLE = (getState | setState+ notify)*

22. complications • more than one subject • suppose living area or bill of materials are shown • these depend on many elements! • one solution: update method takes subject as argument • (java.util.Observer works like this) • observers as subjects • might use this pattern to decouple elements from their graphical presentation • then Dim observers Wall, but is subject for DimGraphic observer! • how do chains of updates work? cycles? • complex subjects • observer may need to do a lot of work to determine what changed • eg, Dim observer, unlike View observer, doesn’t depend on Wall’s finish • might register observers for different ‘aspects’ of subject • implementation snags • if #subjects >> #observers, may not want a ref in every subject • eg, subjects are stocks on NYSE, observers are watches placed by user • keep hash table separately

23. connections to course topics • abstract state & invariants • example of object modelling • more on idioms, expressing dynamic aspects • protocols for method calls • example of entity life histories • most useful in analyzing problem domain • ignoring rep of observers data structure • example of data abstraction • more on exposure, relation to subclassing, specification • class design • example of a design pattern • more patterns, concurrent too • if notify/update/getState were the only communication mechanism • we would have an ‘implicit invocation’ style • more on style when we discuss software architecture

24. for next time… • plan • monday: Prof John Hansman giving background lecture on ATC • wednesday: object modelling tutorial • thursday/friday: teams meet with DNJ to go over strategy for reverse engineering • your tasks • at end of lecture • hand in questionnaires • by this friday • send me email about team preferences • by next monday • look over CTAS background stuff • on web (from 6894 home page), or hardcopies in Neena’s office • by next wednesday • read chapter from Catalysis book (hardcopy in Neena’s office)