An Integrated Framework for Scenarios and State Machines

1. An Integrated Framework forScenarios 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) Q P a trigger Conditional Scenario b action terminates extensible Partial Scenario

5. out(I1,I2,a) in(I1,I2,a) loc(I1,p2) loc(I1,p1) end(I2) end(I1) end(I1) Communicating State Machines A2 A1

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

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. P Q b c a {{b}} a b b <must <must P Q {{a}} a a b {{b}} b Example: From TMSCs to Acceptance Trees {{a}{b}{c}…} X Y

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. a b a b => /\ p q q p Semantics of Heterogeneous Expressions Combine acceptance trees of sub-expressions • Semantics is compositional • If P <must Q then P op R <must Q op R

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

12. Initial System Requirements RB = M1 + M2 RP= M3 * M4 RD= M5* M6 BS = RB; RP; RD RS = BS /\ T1

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

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

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

16. Final Design RD /\ T2 <must FD RS = BS /\ T1 <must C1;C2;C3 /\ T1 <must RD <must RD /\ T2 <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