SEMANTICS
AND REFINEMENT OF BEHAVIOR STATE
MACHINES
Kevin Lano and David Clark
Department of Computer Science, King’s College London, Strand, London, U.K.
Keywords:
UML, state machines, refinement, model transformations.
Abstract:
In this paper we present an axiomatic semantics for UML 2 behavior state machines, and give transformation
rules for establishing refinements of behavior state machines, together with proofs of the semantic validity of
these rules, based on a unified semantics of UML 2.
1 INTRODUCTION
The state machine notation of UML is widely used
and supports dynamic modelling of applications. It is
perhaps the most complex of the UML notations, and
can be used to express most forms of UML activity
diagrams (Chapter 12 of (OMG, 2007)), in addition
to providing a semantic basis for verification of inter-
action diagrams.
In previous papers we have introduced an ax-
iomatic semantics for UML class diagrams, OCL
and flat state machines (Lano, 2008a), and extended
this to structured protocol state machines (Lano and
Clark, 2007) and sequence diagrams (Lano, 2007).
In this paper we complete the semantics of UML
2 state machines by considering structured behavior
state machines, with communication between state
machines. We apply the semantics to prove the va-
lidity of refinement transformations on behavior state
machines.
In Section 2 we define the syntax of UML 2 state
machines, Sections 3 and 4 define their semantics.
Section 5 gives a definition of refinement. Section
6 gives several refinement transformations and proves
these correct using the semantics.
2 UML 2 STATE MACHINES
Figure 1 shows the version of the UML 2 behavior
metamodel which we consider here. State invariants
will be allowed for both protocol and behavior state
machines.
Behavior
Region
Vertex
subvertex
*
1 source
1 target
Behavior
(duplicate)
(duplicate)
incoming
*
0..1 effect
state
* region
region1..*
0..1
*
outgoing
*
transition
container
1
0..1 stateMachine
0..1
trigger
guard
stateInvariant 0..1
0..1
container
0..1
0..1
specification
method
0..1
*
context
0..1
StateMachine
(duplicate)
(duplicate)
0..1
Behavioral
Feature
isAbstract: Boolean
concurrency:
CallConcurrency
Kind
*
isReentrant: Boolean
Message
Event
CallEvent
1 event
*
operation1
0..1
Actor
UseCaseInterface
Protocol
Transition
0..1
postCondition
0..1
0..1
Behaviored
Classifier
Namespace
State
FinalState
Constraint
Operation
Transition
Event
Trigger
classifierBehavior
0..1
0..1
0..1
0..1
protocol
Class
isActive: Boolean
ParameterDirectionKind = in
direction:
Parameter
* *
ownedParameter {ordered}
ownedParameter {ordered}
Pseudostate
deepHistory
shallowHistory
join
fork
initial
<<enumeration>>
PseudostateKind
*
owningState
0..1
0..1
0..1
0..1
doActivity
0..1
exit
0..1
0..1
entry
NamedElement
NamedElement
kind: PseudostateKind
deferrable
Trigger
Classifier
<<enumeration>>
CallConcurrency
Kind
sequential
guarded
concurrent
Figure
1: UML behaviour metamodel.
A basic state is a state with
regi≫≪.size = 0, other states are com-
posite states. A composite state with one region is
termed an OR state, and a composite state with more
than one region is termed an AND state. Each OR
state/region s contains a unique initial pseudo-state,
and a unique transition from this to a normal state of
the OR state/region, termed the default initial state of
the OR state or region, and denoted i≪itial
s
.
The notation s v s
0
means that s = s
0
or s is
a (recursive) substate of s
0
.
42
Lano K. and Clark D. (2008).
SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 42-49
DOI: 10.5220/0001683700420049
Copyright
c
SciTePress
3 SEMANTICS FOR UML STATE
MACHINES
We give first the semantics for simple state machines
as used in (Lano, 2008a), and then extend this to the
full metamodel of Figure 1. The semantics of pro-
tocol and behavior state machines for a class C are
incorporated into theories representing the semantics
of C. This enables semantic checks of the consistency
of the state machine models compared to the class di-
agram model.
The semantics is expressed in terms of temporal
logic theories using the notation of Real-time Logic
(RTL) and Real-time Action Logic (RAL) (Lano,
1998). The reason for using this general framework
is that related notations of UML, such as interactions,
require explicit treatment of the times of events.
Each UML class and model is represented as a
temporal logic theory, which has semantic elements
(attributes and actions) representing structural and be-
havioral features of the class or model, and axioms
defining their properties. A generic instance of C is
represented as a theory I
C
, the class itself by a theory
Γ
C
, and models M by a theory Γ
M
composed from the
theories of the classes of M.
Refinement of model M1 by model M2 means that
the theory Γ
M2
proves each axiom of M 1, under some
interpretation of the elements of M1 in M2. This corre-
sponds to state-based concepts of refinement, such as
the weakening of preconditions and strengthening of
postconditions (Morgan, 1990), and to concepts based
on behavioural compatibility (Simons, 2005).
The following temporal logic notations are used to
define the semantics:
1. The times (≫p(p),i), (≫p(p),i),
(≫p(p),i), (≫p(p), i) of sending, request
arrival, activation and termination of an operation
execution (≫p(p),i). These have values in a
set TIME (normally N) and are enumerated by
the index i : N
1
in order of the reception times
(≫p(p),i).
2. Formulae P}t, denoting that formula P holds at
time t, and expressions e~t denoting the value
of expression e at time t.
From these, other notations such as the RTL
event-occurrence operators (ψ := true,i)
“the i-th time that ψ becomes true”, and
#active(≫p(x)), the number of currently
executing occurrences of ≫p(x), can also be
defined.
To define transition actions and other actions
within a state machine, we use a generic procedural
language with assignment, conditionals, loops, etc.
Composite statements in this notation correspond to
(structured) activities in UML 2.
The semantics of such statements is given by cor-
responding semantic actions v := e, α; β, etc, in
RAL. Each action has a write frame, which is the set
of attributes it may change.
We can express that one action always calls an-
other when it executes:
α β
i : N
1
· j : N
1
·
(α,i) = (β,j)
(α,i) = (β,j)
α calls β”. This is also used to express that α is
defined by a (composite) action β.
Assignment t
1
:= t
2
can be defined as the action
α
t
1
:=t
2
where t
1
is an attribute symbol, the write
frame of this action is {t
1
}, and
i : N
1
· t
1
~(α
t
1
:=t
2
,i) = t
2
~(α
t
1
:=t
2
,i)
Similarly, sequential composition ; and parallel
composition || of actions can be expressed as derived
combinators.
The ; and || composite actions have write frames
the union of the write frames of their component ac-
tions.
Occurrences of if E the≪ S
1
else S
2
are
either occurrences of S
1
if E holds at commencement
of this action, or occurrences of S
2
, if ¬ E holds. This
action has write frame the union of those of S
1
and
S
2
.
Occurrences of while E d≫ S are a se-
quence of occurrences (S,i
1
),... ,(S,i
) of S,
where E holds at the commencement of each of these
actions, and where E fails to hold at termination of
(S,i
). The while action has the same write
frame as S.
Some important properties of are that it is tran-
sitive:
(α β) (β γ) (α γ)
and that statement constructs such as ; and
if the≪ else are monotonic with respect to
it:
(α
1
α
2
) (β
1
β
2
) (α
1
; β
1
α
2
; β
2
)
and
(α
1
α
2
) (β
1
β
2
)
if E the≪
α
1
else
β
1
if E the≪ α
2
else β
2
SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES
43
3.1 Unstructured Behavior State
Machines
The semantics of a flat behavior state machine SC
can be defined in the instance theory I
C
of its associ-
ated class, C, using composite actions (Lano, 2008a).
The transitions of such state machines have an
action which executes when the transition is taken,
instead of a postcondition. The transition actions
acts are sequences
≫bj
1
.≫p
1
(e
1
); ...; ≫bj
.≫p
(e
)
of operation calls on supplier objects, sets of sup-
plier objects, or on the self object. Such state-
ments have a direct interpretation as composite ac-
tions acts
0
in RAL:
≫bj
0
1
.≫p
1
(e
0
1
); ...; ≫bj
0
.≫p
(e
0
)
where the ≫bj
0
i
and e
0
j
are the interpretations of
these expressions in RAL.
In addition to state invariants, there may be en-
try and exit actions of states, e≪try
s
, exit
s
,
and do activities d≫
s
of state s. Entry actions of
a state should establish the state invariant, and do ac-
tions preserve the invariant.
The axiomatic representation of a flat behavior
state machine is then:
1. The set of states is represented as a new enumer-
ated type State
SC
.
2. A new attribute c state of this type is
added to I
C
, together with the initialisation
c state := i≪itial
SC
of this attribute
to the initial state of SC. An entry action
e≪try
i≪itial
SC
executes prior to this
update, if present. Local attributes of the state ma-
chine are represented as attributes of I
C
.
3. If the transitions triggered by an operation ≫p(x)
of C in SC are tr
i
, i : 1..k, from states
src
i
to states trg
i
, with guard G
i
and ac-
tions acts
i
, then the behavior of ≫p(x) is
defined as a composite action C≫de
≫p
:
α(x)
if (c state = src
1
G
0
1
)
the≪ exit
0
src
1
; acts
0
1
; e≪try
0
trg
1
;
c state := trg
1
else if....
else if (c state = src
k
G
0
k
)
the≪ exit
0
src
k
; acts
0
k
; e≪try
0
trg
k
;
c state := trg
k
where α represents ≫p.
Entry actions of a state must complete before the
state machine is considered to properly enter the
state (“before commencing a run-to-completion
step, a state machine is in a stable state configura-
tion with all entry ... activities completed”, page
561 of (OMG, 2007)). An entry action will often
be used to ensure that the state invariant holds.
If there is already an existing procedural definition
D
≫p
of ≫p in the class C, the complete defi-
nition of ≫p is D
0
≫p
; C≫de
≫p
(page 436 of
(OMG, 2007); we assume that an existing pre/post
specification should however always refer to the
entire span of execution of ≫p).
We also need to define the effect of do-actions.
These can only execute while their state is occu-
pied:
#active(d≫
0
s
) > 0 c state = s
and they initiate execution at the point where their
state is entered (Page 548 of (OMG, 2007)):
i : N
1
· (d≫
0
s
,i) = ((c state = s) := true, i)
4. The axioms (StateI≪v) :
c state = s I≪v
0
s
The semantics defined here corresponds to the usual
‘run to completion’ semantics of UML state ma-
chines: a transition only completes execution when
all of its generated actions do so (page 546 of (OMG,
2007)).
A flat behavior state machine SC attached to an
operation ≫p defines an explicit algorithm for ≫p.
It can be formalised as a while loop action (Lano,
2008a).
4 SEMANTICS FOR
STRUCTURED STATE
MACHINES
We extend the semantics of flat state machines to state
machines with OR and AND composite states, com-
pound transitions and history and final states.
For each OR state s in the state machine, we de-
fine a state attribute s state : State
s
where
State
s
represents the set of normal states (includ-
ing final states) directly contained in s. Regions of
an AND state are also represented by a type and an
attribute in the same manner (and so must be named).
Each such OR state/region has a default initial state
i≪itial
s
and each s state is initialised
ICEIS 2008 - International Conference on Enterprise Information Systems
44
to this value. If a final state is present, it is denoted by
fi≪al
s
.
The top level states of a state machine SC are also
represented by an attribute SC state : State.
For each state s in the state machine diagram, a
predicate ϕ
s
can be defined, which expresses that s
is part of the current state configuration of the state
machine (Table 1).
Table 1: State predicate.
State/region s State predicate ϕ
s
Top-level state SC state = s
Region of AND state p ϕ
p
Immediate substate of
OR state/region r ϕ
r
r state = s
A predicate I≪itialState
s
similarly
expresses that the (recursive) initial state of s is oc-
cupied.
Using these predicates, the state-changing be-
haviour of transitions can be expressed as pre and post
conditions. The enabling condition e≪c(tr,s)
of a transition tr
s
≫p[G]/P≫st
t
from a state s is ϕ
s
G
0
, conjoined with ¬ (ϕ
ss
G1
0
) for each different transition
ss
≫p[G1]/P≫st1
tt
triggered by ≫p on a state ss, ss 6= s, ss v
s.
This expresses that tr is only enabled on s if
higher-priority transitions for the same trigger opera-
tion/event are not enabled.
The complete enabling condition of tr is
the conjunction of the enabling conditions from
each explicit source of tr (tr may be a
compound transition with multiple source states
s≫urces(tr)):
e≪c(tr) =
ss≫urces(tr)
e≪c(tr,s)
The precondition derived from a transition tr
triggered by ≫p is then e≪c(tr).
The enabling condition is a critical semantic as-
pect which can be defined in different ways to
produce different semantic profiles for state ma-
chines. We could use instead an alternative defi-
nition e≪cs(tr), which is the conjunction of
e≪c(tr,s) for each explicit and implicit source
s of tr. Implicit sources are those AND state re-
gions which contain no explicit source of tr but will
be exited when it takes place.
For the postcondition, there are several cases. A
predicate Target
tr
expresses what state(s) are
directly entered because of the transition tr (Lano
and Clark, 2007).
For transitions with multiple targets, the conjunc-
tion of the Target predicate for each target is
taken.
In addition to the postcondition describing the di-
rect target, the transition may also cause other states
to be reinitialised. After taking account of the effect
of history and final states, for each AND composite
state x, if transition tr causes x to be entered, then
all the regions of x which do not contain an explicit
target of tr must be reinitialised. This additional ef-
fect (which may apply to several AND compositions)
is expressed by a predicate ReI≪it
tr
.
The complete postcondition Π
tr
of tr is the
conjunction of its explicit postcondition, its target
state predicate(s), and ReI≪it
tr
.
4.1 Structured Behavior State Machines
The semantics for structured behavioral state ma-
chines defines the sequence of actions caused by the
firing of a transition, in addition to the target state
predicate. In general these actions are all the actions
caused by exiting the source state(s), followed by the
explicit actions on the transition, followed by the ac-
tions caused by entering the target state.
A transition tr causes a state sto be (explicitly)
entered if tr has s as an explicit target, or it has a
target contained in s, and some source not contained
in or equal to s. It causes a region r of an AND
state p to be implicitly entered (at its initial state) if p
or another region of p is explicitly entered because of
tr and there is no explicit target of tr in r.
Internal transitions of a state do not cause any state
entry or exit.
Table 2 shows the definition of the complete action
executed when a state s is entered.
Table 2: Entry actions.
State s Entry actions E≪try
s
basic state e≪try
s
OR state/region,
one direct substate trg
is explicitly entered e≪try
s
; E≪try
trg
OR state/region
implicitly entered e≪try
s
; i≪it
s
;
or explicit target E≪try
i≪itial
s
AND state e≪try
s
;
with regions (E≪try
r1
|| ... || E≪try
r≪
)
r1, ..., r≪
SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES
45
i≪it
s
is the action on the default initial tran-
sition of s, in the 3rd case (cf., page 551 of (OMG,
2007)).
The parallel combinator || is used in this defini-
tion because UML 2 does not prescribe any relative
ordering of the combined actions (page 551 of (OMG,
2007)).
A transition tr causes a state sto be (explicitly)
exited if tr has s or a substate of s as an explicit
source, and some target which is not contained in s.
It causes a region r of an AND state p to be implicitly
exited (at its current state) if p or another region of
p is explicitly exited because of tr and there is no
explicit source of tr in r. If an OR state p is exited
because of tr, the currently occupied substate of p
will be exited.
Table 3 shows the definition of the complete action
executed when a state s is exited.
Table 3: Exit actions.
State s Exit actions Exit
s
basic state exit
s
OR state/region,
one direct substate src
is explicitly exited Exit
src
; exit
s
OR state/region
implicitly exited Exit
s state
;
or explicit source exit
s
AND state (Exit
r1
|| ... || Exit
r≪
);
with regions exit
s
r1, ..., r≪
The following axiom, axiom 3, defines the be-
haviour of an operation resulting from all the transi-
tions for it.
If the transitions triggered by ≫p(x) are tr
i
,
i : 1..k, with actions acts
i
, then the behavior of
≫p(x) is defined as a composite action C≫de
≫p
:
||
j:1..k
(if e≪c(tr
j
) the≪ Exit
0
j
;
acts
0
j
; E≪try
0
j
)
where each Exit
j
are the exit actions caused by
tr
j
(Table 3), and E≪try
j
the entry actions
(Table 2).
This definition chooses a maximal set of enabled
transitions to execute at each step (page 563 of (OMG,
2007)). If no transition is enabled, a skip is performed
(in accordance with the UML semantics of behavior
state machines, page 561 of (OMG, 2007)).
If we know that the e≪c(tr
j
) are mutually
exclusive, this can be simplified to:
if e≪c(tr
1
)
the≪ Exit
0
1
; acts
0
1
; E≪try
0
1
else if ....
else if e≪c(tr
k
)
the≪ Exit
0
k
; acts
0
k
; E≪try
0
k
because (if E
1
the≪ C
1
) || (if E
2
the≪ C
2
)
is equivalent to
if E
1
E
2
the≪ C
1
|| C
2
else if E
1
the≪ C
1
else if E
2
the≪ C
2
For each transition tr triggered by an operation
≫p(x), the pre-post behaviour due to tr is:
i : N
1
· e≪c(tr)}(≫p(x),i) Π
tr
}(≫p(x),i)
The axiom for do-actions holds with ϕ
s
in place
of c state = s.
Axiom 4 holds in the form
ϕ
s
I≪v
0
s
for each state s.
The semantics of behavior state machines attached
to operations is generalised to structured state ma-
chines in the same way.
The above semantics can be used to give a mean-
ing to models which extend the UML 2 standard, eg,
where there are transitions which cross from one re-
gion of an AND state to another (page 572 of (OMG,
2007)).
5 REFINEMENT OF STATE
MACHINES
Refinements of state machines are relationships be-
tween state machine models which establish that one
state machine (the refined model) correctly imple-
ments all the behaviour of the other, abstract, model.
Often the relationship between a refined state ma-
chine C of a class CC, and an abstract state machine
A of a class AC can be expressed by a morphism f
from C to A, with the properties of refinement and ad-
equacy (Lano et al., 2000; Lano et al., 2002; Simons,
2005).
The condition for a model D to refine a model C
is that the theory of D should prove each axiom of the
theory of C, possibly under some interpretation σ of
the symbols of C in terms of those of D:
Γ
D
` σ(ψ)
for each axiom ψ of Γ
C
. Typically σ is defined in
terms of some abstraction morphism f.
ICEIS 2008 - International Conference on Enterprise Information Systems
46
6 REFINEMENT
TRANSFORMATIONS
Using the above definition of refinement, we can ver-
ify that many refinement transformations on state ma-
chines are semantically correct:
1. A protocol statemachine can be refined into a be-
havior statemachine by replacing transition post-
conditions by actions which establish the postcon-
dition. This is termed protocol conformance in
(OMG, 2007).
2. Exit and entry and transition actions can be ex-
tended to invoke operations on new orthogonal re-
gions/OR states (page 550 of (OMG, 2007)).
3. A supplier state machine can be refined, this will
produce a refinement of the complete model, if
the calling relationship between state machine
regions/OR-states is non-cyclic.
4. A do-action of a state can be refined into a com-
posite activity.
Other transformations, such as moving entry and exit
actions from states onto transitions, can also be di-
rectly verified using our semantics.
Once a transformation has been proved correct, it
can be used as required to produce or verify correct
refinements, without requiring repetition of the proof.
6.1 Refinement of Supplier State
Machines
This transformation involves the refinement of one
composite state/region within a state machine, whilst
leaving unchanged other states/regions.
Figure 2 shows an example of this transformation.
The axioms of the original model are:
≫p() if sm1 state = s1 the≪ m() else
if sm1 state = s2 the≪ m()
i : N
1
· (sm1 state = s1)}(≫p,i)
(sm1 state = s2)}(≫p, i)
i : N
1
· (sm1 state = s2)}(≫p,i)
(sm1 state = s1)}(≫p, i)
i : N
1
· (sm2 state = ss1)}(m,i)
(sm2 state = ss2)}(m, i)
i : N
1
· (sm2 state = ss2)}(m,i)
(sm2 state = fi≪al
sm2
)}(m,i)
When sm2 is replaced by its refinement sm3, the
s1
s2
op()/m()op()/m()
s1
s2
op()/m()op()/m()
ss1
ss2
m()
m()
ss1
m()
m()[att <= 0]
ss4
m()
ss3
m()[att > 0]
sm1 sm2
sm1 sm3
Figure 2: Refining a supplier state machine.
axioms of sm2 are replaced by:
i : N
1
· (sm3 state = ss1 att > 0)}(m, i )
(sm3 state = ss3)}(m,i)
i : N
1
· (sm3 state = ss1 att 0)}(m, i )
(sm3 state = ss4)}(m,i)
i : N
1
· (sm3 state = ss3)}(m,i)
(sm3 state = fi≪al
sm3
)}(m,i)
i : N
1
· (sm3 state = ss4)}(m,i)
(sm3 state = fi≪al
sm3
)}(m,i)
to form the semantics of the complete refined model.
But these axioms establish the axioms of the original
model, under the interpretation σ of sm2 state
as f(sm3 state), where f is the abstraction
mapping:
ss1 7− ss1
ss4 7− ss2
ss3 7− ss2
fi≪al
sm3
7− fi≪al
sm2
Therefore the new model is a refinement of the orig-
inal model. The same reasoning can be used in other
cases of this transformation. If the state of the re-
gion which is being refined is referred to in the re-
gion which invokes its operations, then these ref-
erences must be replaced by the equivalent expres-
sions in terms of the refined state. Eg, a guard
i≪ ss2 for a transition of sm1 must be re-
placed by i≪ ss3 ≫r i≪ ss4 in the refined
model, in the above example.
SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES
47
6.2 Adding New Regions and
Concurrent Generations
A new region can be added to an existing AND state,
provided this region does not invoke operations of
other states (it is a leaf module of the calling hier-
archy). The actions of existing transitions can be ex-
tended to invoke operations of the new module, in par-
allel with their existing actions. Likewise, the entry
and exit actions of existing states can be extended in
this way.
This transformation yields a refinement since
α || β α
so that axiom 3 in the new system implies axiom 3 of
the unrefined system, due to the monotonicity of the
action constructions wrt .
6.3 Refining Do-actions Into Composite
Activities
This transformation replaces a do-action α of a state
by an activity expressed as an internal state machine
of the state.
Figure 3 shows an example of the transformation.
s1
s2
s1
s2
do/ search
s3
then found := true
entry/ if sq[i]=x
[found=true]
[found=false & i = sq.size]
[found=false &
i < sq.size]/
i := i+1
SearchState
/i := 1; found := false
SearchState
Figure 3: Refining a do-action.
In this transformation the original do action α is
interpreted by the new composite action Act. Any
axiom
≫p(x) Ac
defining the behavior of an operation ≫p in terms
of a composite action Ac derived from the original
model is still valid in the new model, because in inter-
preted form it is
≫p(x) Ac[Act/α]
which is the corresponding axiom of the new model.
Likewise for the other axioms of do actions.
7 CONCLUSIONS
We have defined an axiomatic semantics for a large
part of UML 2 state machine notation, using the infor-
mal OMG superstructure definition of the semantics
as the basis. Our semantics supports verification of
internal consistency of state machines, of refinement
between state machines, and verification of the con-
sistency of sequence diagrams with state machines.
Other elements of UML 2 state machine notation,
such as deferred states, can also be given a semantics
in this formalism (Lano and Clark, 2007).
The axiomatic semantics approach has the advan-
tage of expressing UML semantics in a high-level
manner, in a formalism which is similar to, but in-
dependent of, UML. The semantics presented here is
used as the basis for the code generation process of
the UML-RSDS tools (Lano, 2008b), so ensuring the
correctness of the generated code with respect to the
specification.
In contrast to the approach of (Damm et al., 2005;
Merseguer et al., 2002), we do not flatten UML
state machines, but retain the structure of the ma-
chines. This enables analysis results and generated
code structure to be directly related to the specifica-
tions.
As far as possible, our semantics represents the
meaning of state machines in notations which are
close to UML class diagram and OCL notations.
The semantics may therefore be more accessible to
UML users than semantics which use external for-
malisms such as Petri Nets (Merseguer et al., 2002)
or term algebras (Lilius and Paltor, 1999). An ax-
iomatic semantics is also well-suited for use with
logic-based semantic analysis tools such as B. Com-
pared to (Lilius and Paltor, 1999) we do not represent
sync states, however we can express the semantics of
time-triggered transitions using the RAL formalism
(Lano, 2008a), extending (Lilius and Paltor, 1999).
The approach of (Le et al., 2006) is close to ours,
but translates directly into B from statecharts, instead
of utilising an underlying axiomatic semantics. Ele-
ments of UML state machine notation such as time
triggers, which require a temporal logic semantics,
are not handled by this approach.
Although this paper has been concerned with the
semantic problems of UML, the fact that a relatively
simple and coherent semantics can be assigned to
UML state machines does show that the notation is
suitable for developments where semantic correctness
is important.
ICEIS 2008 - International Conference on Enterprise Information Systems
48
REFERENCES
Damm, W., Josko, B., Pnueli, A., and Votintseva, A. (2005).
A discrete-time UML semantics for concurrency and
communication in safety-critical applications. Science
of Computer Programming, 55:81–115.
Lano, K. (1998). Logical specification of reactive and real-
time systems. Journal of Logic and Computation,
8(5):679–711.
Lano, K. (2007). Formal specification using interaction di-
agrams. In SEFM ’07.
Lano, K. (2008a). A compositional semantics of UML-
RSDS. SoSyM.
Lano, K. (2008b). Constraint-driven development. Infor-
mation and Software Technology.
Lano, K. and Clark, D. (2007). Direct semantics of ex-
tended state machines. Journal of Object Technology.
Lano, K., Clark, D., and Androutsopolous, K. (2002). From
implicit specifications to explicit designs in reactive
system development. In IFM ’02.
Lano, K., Clark, D., Androutsopolous, K., and Kan, P.
(2000). Invariant-based synthesis of fault-tolerant sys-
tems. In FTRTFT. Springer-Verlag.
Le, D., Sekerinski, E., and West, S. (2006). Statechart veri-
fication with istate. In FM 06.
Lilius, J. and Paltor, I. (1999). The semantics of UML state
machines. Turku Centre for Computer Science, TUCS
technical report 273.
Merseguer, J., Campos, J., Bernardi, S., and Donatelli, S.
(2002). A compositional semantics for UML state ma-
chines aimed at performance evaluation. In Silva, M.,
Giua, A., and Colom, J., editors, 6 Int. Workshop on
Discrete Event Systems (WODES 2002).
Morgan, C. (1990). Programming from Specifications: The
Refinement Calculus. Prentice Hall.
OMG (2007). UML superstructure, version 2.1.1. OMG
document formal/2007-02-03.
Simons, A. (2005). A theory of regression testing for be-
haviourally compatible object types. In 3rd Conf.
UK Software Testing Research (5-6 September), pages
103–121.
SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES
49