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)

P Q

a

b

trigger

action

extensible

terminates

ConditionalScenario

Partial Scenario

Communicating State Machines

out(I1,I2,a)

loc(I1,p1)

end(I1)end(I1)

loc(I1,p2)

in(I1,I2,a)

end(I2)

A1A2

Acceptance Trees: the “must” pre-order

ab

{{c}{d}}

c d

{{a}}

{{c}}

{{}} {{}}{{}}

a

c

<must

{{a}{b}}

P <must Q, if Q is “more deterministic” than P

P1 P2

{{}}

acceptance set

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

Example: From TMSCs to Acceptance Trees

P Q

a

b

a

b

P Q

a

{{b}}b

b c

{{a}}

{{b}}a

b

<must <mustX

Y

{{a}{b}{c}…}

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)

Semantics of Heterogeneous Expressions

/\ =>a

p

b

q

a

p

b

q

Combine acceptance trees of sub-expressions

Semantics is compositionalIf P <must Q then P op R <must Q op R

Case Study: Automated Resuscitation and Stabilization System

D

R

BP

Blood Pressure

Patient

Infusion Pump

Control Unit

Display/Alarm

Initial System Requirements

RB = M1 + M2 RP= M3 * M4 RD= M5* M6

BS = RB; RP; RD

RS = BS /\ T1

Initial Design

RB <must C1, RP <must C2, RD <must C3

BS = RB;RP;RD <must C1;C2;C3

RB = M1 + M2 <must C1

C1

C2

C3

Intermediate Heterogeneous Design

C1;C2;C3 <must ID <must ID /\ T1Initial Design ID

Refined Design & New Requirement

ID <must RD

HS2 = RD /\ T2

Refined Design RD

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