6894

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 weeks 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 Eshows 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
  ETAs 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
TIMEDEVENT
TIMEDEVENT
send
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-outCLIENTTYPE
INCOMINGMSG
OUTGOINGMSG
HANDLER
state
STATE
9
message handler, ctd

• questions
• stickiness of relations
• sticky and fixed sets
• multiplicity of relations
• candidate constraints
• cant 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 cant 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) -gt (some
  mt.handler-outct)

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 -gt 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
EVENTTYPE
HANDLERTYPE
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
first cut at module structure
20
dependence diagram syntax

• strong dependence
• solid arrow
• A gt 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 - - gt B means that A requires the presence of B
• eg, A stores Bs and passes them around
• interface
• CLIENT -gt 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