Workshop on Software Design Lecture

1. 6894 · workshop in software designlecture 9 · november 9, 1998 · CM redesign discussion

2. topics for today • outcome of NASA visit • object models & constraints • scenarios • module dependence diagram • allocation, milestones, etc

3. NASA visit • last week’s visit • 3 teams presented design ideas to Michelle Eshow and Karen Tung • (software development manager & assistant manager for CTAS) • ideas generally well received • main CM issues • based on Eshow’s comments • buffering is largest source of bugs • workaround for blocking writes • results in bad message ordering: eg, radar data before associated FP • recent RA assignment bug: assigned before FP, no ETA’s ever obtained • code generally obscure, esp. for new developers • message handling a problem • nobody (except us) really looking hard at CM architecture • all research effort focused on algorithms

4. CTAS development process • teams • NASA Ames, about 20 developers (led by Eshow) • CSC, about 80 in total, including 20 developers (FAA pays $12M/year) • Lincoln Labs and others too • process • Ames and CSC share a ClearCase repository • work divided into ‘problem reports’ • integration every 8 weeks • in one 8-week period recently Ames did 60-70 PRs, CSC did 2 PRs • reviews • CSC presents code to Ames for review • pseudocode and structure charts • Ames does code reviews of CSC work • CSC claims CMM level 3

5. robustness • bugs • Ames finds about 3 or 4 bugs/month • failure rate • in typical installation • CTAS runs for 14 hours/day • restarted every day • 6-8 months since last crash • used to fail much more often (during rushes) • in lab • CTAS runs continuously • fails after 3-4 weeks • all failures so far due to software • FAA wants • 99% availability • robustness in face of single failure • independent ‘monitoring & control’ (being implemented by CSC) • requires FAA version of mil standard s/w process 2167A

6. outline of design • messages • message handlers • compiler for domain-specific message language • queueing • application-level infinite queues • scheduling • proxies for each client are polled by scheduler • proxies execute handlers • timed events registered in scheduler • aircraft database • a hash table • design allows persistence to be added later • dongles, some associated with aircraft • GUI • separated from CM in distinct process, communicates by messages

7. architecture (from team B) MSGPROCESSOR send TIMEDEVENT TIMEDEVENT timeout SCHEDULER receive CLIENT PROXIES creates send/fwd INQ OUTQ CONNTHREAD READ TH WRITETH NETWORK

8. message handler CLIENT CLIENTTYPE type for creates MSG MSGTYPE HANDLERTYPE type type handle-out[CLIENTTYPE] INCOMINGMSG OUTGOINGMSG HANDLER state STATE

9. message handler, ctd • questions • stickiness of relations • sticky and fixed sets • multiplicity of relations • candidate constraints • can’t register two handlers of same type for given message type • all mt: MSGTYPE, ct: CLIENTTYPE, ht: HANDLERTYPE |sole (mt.handler-out [ct] & ht.~type) • handler for outgoing message can’t create message • all om: OUTGOINGMSG, ct: CLIENTTYPE | • no (om.type.handle-out [ct].type.creates) • every message created has a handler • all mt: MESSAGETYPE |(some mt.~creates) -> (some mt.handler-out[ct])

10. alloy constraint notation (1) • why constraints? • graphical notation not expressive enough • want to express extra invariants • simple constraint language • expressions denote sets of objects • scalars treated as sets containing one element • expressions • sets from sets • s1 + s2 union • s1 - s2 difference • s1 & s2 intersection • sets from sets and relations • s.r image of s under r • s.~r image of s under transpose of r • s.r* image of s under closure of r • sets from formulas • {v | f} set comprehension

11. alloy constraint notation(2) • formulas • elementary formulas • e1 = e2 equality • e1 in e2 subset or membership • formulas • f1 && f2 conjunction • f1 || f2 disjunction • f1 -> f2 implication • quantified formulas • all v | f universal quantification • some v | f existential quantification • no v | f same as (not some v | f) • sole v | f at most one value of v such that f • one v | f same as ((sole v | f) and (some v | f)) • quantifier shorthands • some e short for (some v | v in e) • no e short for (no v | v in e)

12. aircraft database ACID AIRCRAFT AIRCRAFTDONGLE ac dongle state AIRCRAFTSTATE DONGLE type DONGLETYPE

13. aircraft database, ctd • candidate constraints • aircraft and non-aircraft dongle may not have same type • two non-ac dongles must have distinct types

14. scheduler EVENT TIME NOW time type HANDLERTYPE EVENTTYPE creates_ev creates_h

15. scenarios • message handling • handle incoming message • create outgoing message • create handler for incoming & outgoing • change handler for message type • database • set/read fields • create new aircraft • change aircraft activeness state • scheduling • reschedule event • create new event • event creates message and executes handler • event changes handler registration • …

16. gross structure • major packages • compiler • engine (scheduler, handler, client proxies) • database (aircraft, configuration, dongles) • event and handler instances • handlers written in scripting language • virtual input and output queues • user interface (separate process)

17. proposed allocation & milestones task est size / effort team compiler 20kloc / 300 hours B engine 2 kloc / 30 hours F database 2 kloc / 20 hours D events & handlers 3 kloc / 60 hours E virtual queues 2 kloc / 10 hours D GUI 3 kloc / 30 hours C major milestones november 16 first version ready for integration november 23 first version running november 30 running with refinements

18. load estimate • my estimate of work available this week • 8.5 weeks into term, so by end of this week expect 9.5 weeks of work ~ 85 hours • assume total so far of 45 hours: • 6 reading • 24 rev engineering • 15 design • so 40 hours/student left • plan • week 1 (this week, 11/9 – 11/16) • detailed design complete and interfaces resolved by Tuesday 11/10, 5pm • send email to me by midnight on Thursday 11/12 with progress • integrate first version next Monday • week 2 (11/16 – 11/23) • get it running • week 3 (11/23 – 11/30) • add refinements, prepare presentations • 12/7 • NASA (and maybe CSC and FAA) coming to final presentations

19. HANDLER_i EVENT SCHEDULER HANDLER CLIENTGROUP CLIENT CLIENTID ACID engine INQ OUTQ DB AIRCRAFTSTATE MSG database queue first cut at module structure

20. dependence diagram syntax • strong dependence • solid arrow • A –> B means that a change in the spec of B might require A to be changed • eg, A calls a method in B • weak dependence • dotted arrow • A - - > B means that A requires the presence of B • eg, A stores B’s and passes them around • interface • CLIENT -> HANDLER - HANDLER_i • means that CLIENT depends on HANDLER_i, but views it as having specgiven by interface HANDLER

21. notes on modules • CLIENTGROUP • handles assignment of aircraft to RAs • provides broadcast ops: ‘send to all RAs’ • provides access to client by type: ‘send to the DP’ • CLIENTID • avoid making DB dependent on CLIENT • also good for persistence • HANDLER_i • one class for each handler type • issues • message types missing • creation of clients • handlers/events creating handlers/events • aircraft activeness state: CLIENTGP - DB coupling