an integrated framework for scenarios and state machines
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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