6894 · workshop in software design lecture 1 · september 9, 1998 · introduction
DESCRIPTION
6894 · workshop in software design lecture 1 · september 9, 1998 · introduction. 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 - PowerPoint PPT PresentationTRANSCRIPT
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)