170 likes | 242 Views
An Integrated Framework for Scenarios and State Machines. Bikram Sengupta IBM Research India. Rance Cleaveland Department of Computer Science University of Maryland, College Park. Outline. Background Motivation
E N D
An Integrated Framework forScenarios and State Machines Bikram Sengupta IBM Research India Rance Cleaveland Department of Computer Science University of Maryland, College Park
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
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)
Triggered Message Sequence Charts (TMSCs) Q P a trigger Conditional Scenario b action terminates extensible Partial Scenario
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
{{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
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
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
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)
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
Control Unit R B D P Blood Pressure Display/Alarm Infusion Pump Patient Case Study: Automated Resuscitation and Stabilization System
Initial System Requirements RB = M1 + M2 RP= M3 * M4 RD= M5* M6 BS = RB; RP; RD RS = BS /\ T1
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
Intermediate Heterogeneous Design Initial Design ID C1;C2;C3 <must ID <must ID /\ T1
Refined Design & New Requirement Refined Design RD ID <must RD HS2 = RD /\ T2
Final Design RD /\ T2 <must FD RS = BS /\ T1 <must C1;C2;C3 /\ T1 <must RD <must RD /\ T2 <must FD
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