6894 · workshop in software design lecture 4 · september 23, 1998 · entity life histories

1. 6894 · workshop in software designlecture 4 · september 23, 1998 · entity life histories

2. introduction • two kinds of aspect models • object model: abstract states • entity life histories: event sequences • sample entity life history (ELH) • MIT course: • [preregister] (register | add) (complete | drop) • very partial • describes one student and one course • registration aspect only • doesn’t say what causes events to occur • lecture topics • abstract notion of ELH • notations • regexps, grammars, machines • all describe regular languages: equivalent to finite automaton • refinements: roles and event classification

3. what is an ELH? • an ELH is defined by • an alphabet • set of events that the entity might participate in • often implicit • sequences • set of all possible sequences of events • each sequence represents a complete lifetime • finiteness • alphabet is finite and small (eg, < 20 events) • sequence set is almost always infinite (because of ‘loops’) • sequences are always finite • composition of behaviours • how does a system of entities behave? • a sequence of events can happen if allowed by every entity • entities ignore events not in their alphabet • but never ignore events in their alphabet • the entity that has one event e and no sequences prevents e from occurring

4. comparison to CSP • what is CSP? • Communicating Sequential Processes, Hoare 1985 • a model of concurrency and communication • inspired Ada rendezvous (and the occam language) • processes communicate and synchronize by participating in shared events • first simple theory of concurrency • notion of traces: sequences of events • internal and external choice • algebraic rules for reasoning about processes • how our approach differs • more interested in description than theory • in CSP, traces are ‘prefix-closed’ • if s ^ t is a trace, so is s • but our sequences are complete • in CSP, hard to put sequential processes together • essential for ELHs

5. notation 1: regular expressions • basic idea • an expression is a specification • it denotes the set of sequences satisfying the spec • elements expression what satisfies it e a seq consisting of just the event e E F a seq consisting of a seq satisfying E, then one satisfying F E | F a seq satisfying E or F [E] a seq satisfying E or the empty sequence E* the empty sequence, or a seq consisting of a series of seqs, each satisfying E E+ a seq consisting of a series of one or more seqs, each satisfying E

6. sample regexps • coke machine session • coin+ (refund | select receive) • coin+ (select-coke getcoke | select-sprite getsprite) • bank account • open (payin | withdraw)* close • windows laptop session • unpack boot coffee login coffee (reademail | getquotes)* shutdown curse pack

7. notation 2: regular grammar • basic idea • sequences are those that can be ‘derived’ • during derivation, a sequence may contain SYMBOLs as well as events • a symbol represents a sequence of events • to derive a sequence • start with the special start symbol (usually the first) • apply its production, obtaining a sequence of events and symbols • apply a production to each symbol • stop when sequence contains only events • productions kind written like this derivation rule sequence symbol ::= S1 S2 … replace symbol by S1 followed by S2 selection symbol ::= S1 | S2 | … replace symbol by S1 or S2 iteration symbol ::= S* replace symbol by zero or more copies of S S is event, symbol or special empty sequence marker  • note • really just regexps with names for all subexprs, not a traditional regular grammar

8. sample grammars • how I’d like my printer to work • PRINTER ::= warmup JOBS shutdown • JOBS ::= JOB* • JOB ::= seltray printcover PAGES notify • PAGES ::= printpage* • journal submission process • SUBMISSION ::= FAILURE | SUCCESS • FAILURE ::= receive GOAROUNDS REVIEW reject • SUCCESS ::= receive GOAROUNDS REVIEW accept • GOAROUNDS ::= GOAROUND* • GOAROUND ::= REVIEW say-revise resubmit • REVIEW ::= DISTRIBUTE COLLECT • DISTRIBUTE ::= send-out* • COLLECT ::= receive-review* • questions • what if send-outs and receive-reviews are interleaved? • what if reviewer never responds?

9. PRINTER warmup JOBS shutdown JOB * seltray printcover PAGES notify printpage * diagrammatic form of grammar

10. notation 3: machines • basic idea • nodes of graph represent states • special start and end states • arcs are labelled with events • a sequence is allowed if it takes you on a path from start to end state • hicharts • useful elaboration from Statecharts [Harel, 1999] • in addition to basic states • allow sets of states • show as contour (like Venn diagram) • arc leaving a state contour is short for • collection of arcs leaving each internal state

11. sample machine • cruise control • OFF is start and end state • what if brake in READY state? READY on set cancel set off OFF CRUISE brake resume SUSPEND

12. comparison of notations • expression • very succinct, awkward to read if big • good for simple ELHs • grammar • naming of subsequences useful • structure more apparent • jumps are hard to express • good for highly structured, complex ELHs • machine • no sequence structure • good for complex ELHs with jumps (reversal, abort, etc) • examples • CD player controller? • workflow system? • aircraft handoff protocol?

13. stylistic issues • choosing events • scope: which to include? • abstraction: at what level? • example: phone call • is connect event relevant? • is dialling a single event? • expressing structure • any ELH can be expressed as (e1 | e2 | … )* • but no use! • want to express as much structure as you can • without ELH becoming obscure • common mistake of novices • don’t recognize subsequences • too many special cases, single event selections • example: text justification • input structure is: space* alpha* (space+ alpha+)* space*

14. roles • problem • sequencing constraints apply to subsets of the events • constructing a single grammar is awkward • solution • express ELH as several concurrent processes • each is called a role • example • film star life has four events • marry, divorce, hire, fire • marry/divorce alternate, hire/fire alternate • express as two roles • EMPLOYMENT-ROLE ::= (hire fire)* • MARRIAGE-ROLE ::= (marry divorce)* • more useful than machine • consider elaborating a role • eg, (hire pay fire)* divorce unmarriedunemployed marriedunemployed marry hire fire hire fire unmarriedemployed marriedemployed marry divorce

15. roles with shared events • a complication • roles are not always independent • if roles share events, they are viewed as happening simultaneously • event cannot occur in one role and not in the other • example: runway usage • RESERVE-ROLE ::= (reserve block unblock)* • BLOCKING-ROLE ::= ((block unblock) | land | enter)* • OCCUPANCY-ROLE ::= ((land taxi) | (enter leave) | (enter takeoff))* • is this realistic? • no, because we can’t prevent aircraft from landing when runway is blocked

16. event classification • problem • only some occurrences of an event are relevant to an entity or role • which depends on context (ie, occurrence of events previously) • resolving context would complicate process description • can’t just abstract, because • solution • separate classification of event from its effect and constraints • express classification in a description that does not constrain the event • examples • classify land and enter events when blocked as violations: • BLOCKING-ROLE ::= ((block [land/violation | enter/violation] unblock) | land | enter)* • classify hook flash depending on whether call is waiting • (flash/req-tone)* … connect … callwaitsig (flash/switch)* • classify braking et al as cancellations in cruise control • in a separate role, accept brake with self transition in every state • for CRUISE state, mark self transition with brake/cancel • semantics for event classification is a research problem

17. example: assignment of aircraft to RAs (OM) ACTIVE holds RA * AIRCRAFT * INACTIVE ! owns ASSIGNED UNASS *

18. example: assignment of aircraft to RAs (ELH) • events • receive_FP • become_active • assign_to_RA • unassign • become_inactive • grammar • AC-RA-ROLE ::= receive_fp become_active ASSIGNMENTS become_inactive • ASSIGNMENTS ::= ASSIGNMENT* • ASSIGNMENT ::= assign_to_RA unassign • problems • what if receive_fp and become_active occur simultaneously? • become_active may occur before receive_fp, but not assigned until both have occurred • may become active again • aircraft may become inactive during assignment

19. lackwit • what it does • given a variable, lists other variables that may share the same value • ie, shows where values go and come from • by variable, i mean any C expression for a memory location • eg, globalStruct->foo.bar[0] • can name arguments and locals of functions • funcName:argument • will produce textual list, or graph showing flows • how it differs from grep • no lexical snags • will find relevant vars even if names don’t match • only includes var if there is some path in the code between the vars • how to use it • execute lackwit/bin/BackEnd • type • searchlocal funName:expr

20. sample lackwit run • > BackEnd • … • Enter your command ('help' for help): searchlocal remove_flight_plan:ac->ra_index • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/update_aircraft.c:1525) set_inactive:ac->ra_index • … • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c:345) get_index_of_next_available_ra:j • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c:343) /net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c#last_ra_index • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c:228) /net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c#assign_ac_to_the_ra_with_the_fewest_ac:min_ra_index • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c:227) /net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c#assign_ac_to_the_ra_with_the_fewest_ac:ac->ra_index • (/net/geyer/g2/ctas/lackwit/ctas-src/realtime_procs/comm_mgr/distribute_ac.c:180) decrement_number_of_ac_in_one_active_ra:ra_index • Enter your command ('help' for help):

21. example: aircraft in center (unused slide) • aircraft life • AIRCRAFT ::= • receiveFP • GHOSTCOMPS • becomeActive • COMPUTES • allocateRunway • freeze • LEAVE • GHOSTCOMPS ::= COMPUTES HOVERS • HOVERS ::= hovers* • COMPUTES ::= COMPUTE* • COMPUTE ::= compFixSTA compRunwaySTA adjustFixSTA compOMASTA • LEAVE ::= depart | land • elaborations • ac becomes active before FP is received? • redo runway allocations after freeze? • becomes active after freeze horizon?