1. An Integrated Framework for Scenarios and State Machines Bikram Sengupta IBM Research India Rance Cleaveland Department of Computer Science University of Maryland, College Park

2. Outline Background  Motivation  Triggered Message Sequence Charts (TMSCs)  Communicating State Machines (CSMs)  Acceptance Trees Combining TMSCs and CSMs  An Integrated Framework  Semantics Case Study  Automated Resuscitation and Stabilization System (ARSS) Conclusions and Future Work

3. Motivation Heterogeneous specifications, featuring a mixture of high-level requirements and lower-level design artifacts, are motivated by several development methodologies  In spiral system development processes, requirements elicitation and system design often proceed hand-in-hand  Intermediate stages of refinement-based strategies contain a mixture of design elements and requirements  UML supports notations for both requirements modeling and operational design However, research in the area of heterogeneous specifications has remained confined to the more theoretical domains of process algebra, temporal logic and mu-calculus  We need to explore how these ideas may be adapted to more accessible notations used in practice We propose a framework for heterogeneous system specifications consisting of a mix of  Higher-level scenario-based requirements, expressed as Triggered Message Sequence Charts (TMSCs)  State-machine-based subsystem designs, given as Communicating State Machines (CSMs)

4. Triggered Message Sequence Charts (TMSCs) P Q a b trigger action extensible terminates Conditional Scenario Partial Scenario

5. Communicating State Machines out(I 1,I 2,a) loc(I 1,p 1 ) end(I 1 ) loc(I 1,p 2 ) in(I 1,I 2,a) end(I 2 ) A1A1 A2A2

6. Acceptance Trees: the “must” pre-order ab {{c}{d}} cd {{a}} {{c}} {{}} a c <must {{a}{b}} P <must Q, if Q is “more deterministic” than P P1 P2 {{}} acceptance set

7. Combining TMSCs and CSMs TMSCs and CSMs both specify system behavior in terms of sequences of events that may occur  A scenario shows only one possible interaction between instances, and is inherently “incomplete” Conditional and partial TMSC scenarios make the behavior even more “incomplete”  In CSMs, the individual behavior of each instance is generally given over all interactions, hence they are more “complete” Any common account of TMSCs and CSMs should  Be able to express both underspecified as well as fully specified behavior in a uniform manner  Provide operators to weave together multiple scenarios and to allow “networks” of CSMs to be formed  Prescribe when a CSM “correctly” implements a TMSC specification, or, more generally, when one heterogeneous specification “refines” another An acceptance tree-based framework will have the right ingredients  Execution-based  Behavior may be expressed at various levels of detail through “acceptance sets”  “Must-preorder” may be used to check the relationship between scenarios, state- machines, and a mixture of these notations, once they are expressed as acceptance trees

8. Example: From TMSCs to Acceptance Trees PQ a b a b PQ a {{b}} b b c {{a}} {{b}} a b <must X Y {{a}{b}{c}…}

9. A Common Framework H ::= M (single TMSC) | S (single ISM) | X (variable) | H H (communicating parallel comp) | H || H (interleaving parallel comp) | H + H (delayed choice) | H * H (internal choice) | H /\ H (logical AND) | H ; H (sequential composition) | recX. H (recursive operation)

10. Semantics of Heterogeneous Expressions /\ => a p b q a p b q Combine acceptance trees of sub-expressions Semantics is compositional  If P <must Q then P op R <must Q op R

11. Case Study: Automated Resuscitation and Stabilization System D R B P Blood Pressure Patient Infusion Pump Control Unit Display/Alarm

12. Initial System Requirements RB = M 1 + M 2 RP= M 3 * M 4 RD= M 5 * M 6 BS = RB; RP; RD RS = BS /\ T1

13. Initial Design RB <must C 1, RP <must C 2, RD <must C 3 BS = RB;RP;RD <must C 1 ;C 2 ;C 3 RB = M1 + M2 <must C1 C1 C2 C3

14. Intermediate Heterogeneous Design C1;C2;C3 <must ID <must ID /\ T1 Initial Design ID

15. Refined Design & New Requirement ID <must RD HS2 = RD /\ T2 Refined Design RD

16. Final Design RD /\ T 2 <must FD RS = BS /\ T 1 <must C1;C2;C3 /\ T 1 <must RD <must RD /\ T 2 <must FD

17. Conclusions Requirements and design phases often overlap in practice  Need for a common framework that would allow requirements and design notations to inter-operate We presented a framework for heterogeneous specifications involving  Requirements expressed as TMSCs  Design elements represented as CSMs Semantics is based on acceptance trees  Precise notion of refinement in terms of the “must” pre-order Supports principled evolution of higher-level requirements to lower-level operational specifications Future Work  Extend framework to cater to other notations  Synthesize state-machines from TMSC expressions