daniel jacksonmit lab for computer science

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

04/19/23 daniel jackson 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!

04/19/23 daniel jackson 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 designpoint 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

04/19/23 daniel jackson 4

relation to other courses

what this course is not· a graduate reading seminar

we’re going to do research, not just talk about itmajor tutorial component: you’ll be a better designer by the end

· a survey coursenot comprehensive or balanced: i’ve distilled what i think is most

excitingextensive 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

· 6170focus on components, their specs and implementationsless concern for large-scale issues (eg, problem domain)

· 6033case study approach, rather than broad principlesemphasis on global system properties not software structure

04/19/23 daniel jackson 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 NASAtutorial 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

04/19/23 daniel jackson 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:written30:30:30:10 by phasereverse engineering matters a lot!

04/19/23 daniel jackson 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

04/19/23 daniel jackson 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)

04/19/23 daniel jackson 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 novicescommunicate 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)

04/19/23 daniel jackson 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.

04/19/23 daniel jackson 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 codecan analyze before making major commitmentsmany errors found in process of modelling itself

· making design process concreteresults in simpler, better designs

04/19/23 daniel jackson 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]

04/19/23 daniel jackson 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?

04/19/23 daniel jackson 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

04/19/23 daniel jackson 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

04/19/23 daniel jackson 16

GOF representation of Observer pattern

Subject

Attach (Observer)Detach (Observer)Notify ()

Concrete Subject

GetState ()SetState ()

subjectState

Concrete Observer

Update ()

observerState

Observer

Update ()

subject

observers

for all o in observers { o.Update (); }

observerState = subject.GetState ()

return subjectState

*

!

04/19/23 daniel jackson 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 (); }

04/19/23 daniel jackson 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 constructorwhat if subject is deleted?

· BROADCAST should hold after subject’s notify method is calledwhen is that?

04/19/23 daniel jackson 19

object model for Observer

Subject Observer

SubState ObsState

observers

subjectstate state

*

??

04/19/23 daniel jackson 20

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

requirements code

want help to expressdesign here!

04/19/23 daniel jackson 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 ordersetState 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)*

04/19/23 daniel jackson 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

04/19/23 daniel jackson 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

04/19/23 daniel jackson 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 stuffon web (from 6894 home page), or hardcopies in Neena’s office

· by next wednesdayread chapter from Catalysis book (hardcopy in Neena’s office)