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, reﬁnement, model transformations.

Abstract:

In this paper we present an axiomatic semantics for UML 2 behavior state machines, and give transformation

rules for establishing reﬁnements of behavior state machines, together with proofs of the semantic validity of

these rules, based on a uniﬁed 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 veriﬁcation of inter-

action diagrams.

In previous papers we have introduced an ax-

iomatic semantics for UML class diagrams, OCL

and ﬂat 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 reﬁnement transformations on behavior state

machines.

In Section 2 we deﬁne the syntax of UML 2 state

machines, Sections 3 and 4 deﬁne their semantics.

Section 5 gives a deﬁnition of reﬁnement. Section

6 gives several reﬁnement 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)

incoming

0..1 effect

state

* region

region1..*

0..1

outgoing

transition

container

0..1 stateMachine

0..1

trigger

guard

stateInvariant 0..1

0..1

container

0..1

specification

method

0..1

context

0..1

StateMachine

(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

Behaviored

Classifier

Namespace

State

FinalState

Constraint

Operation

Transition

Event

Trigger

classifierBehavior

0..1

protocol

Class

isActive: Boolean

ParameterDirectionKind = in

direction:

Parameter

* *

ownedParameter {ordered}

Pseudostate

deepHistory

shallowHistory

join

fork

initial

<<enumeration>>

PseudostateKind

owningState

0..1

doActivity

0..1

exit

0..1

entry

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

The notation s v s

means that s = s

or s is

a (recursive) substate of s

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

 SciTePress

3 SEMANTICS FOR UML STATE

MACHINES

We give ﬁrst 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

deﬁning their properties. A generic instance of C is

represented as a theory I

, the class itself by a theory

, and models M by a theory Γ

composed from the

theories of the classes of M.

Reﬁnement of model M1 by model M2 means that

the theory Γ

proves each axiom of M 1, under some

interpretation of the elements of M1 in M2. This corre-

sponds to state-based concepts of reﬁnement, 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

deﬁne 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

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

deﬁned.

To deﬁne 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

· ∃j : N

↑(α,i) = ↑(β,j) ∧

↓(α,i) = ↓(β,j)

“α calls β”. This is also used to express that α is

deﬁned by a (composite) action β.

Assignment t

:= t

can be deﬁned as the action

:=t

where t

is an attribute symbol, the write

frame of this action is {t

}, and

∀i : N

· t

~↓(α

:=t

,i) = t

~↑(α

:=t

,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

else S

are

either occurrences of S

if E holds at commencement

of this action, or occurrences of S

, if ¬ E holds. This

action has write frame the union of those of S

and

Occurrences of while E d≫ S are a se-

quence of occurrences (S,i

),... ,(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:

(α

⊃ α

) ∧ (β

⊃ β

) ⇒ (α

; β

⊃ α

; β

)

and

(α

⊃ α

) ∧ (β

⊃ β

) ⇒

if E the≪

else

⊃

if E the≪ α

else β

SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES

3.1 Unstructured Behavior State

Machines

The semantics of a ﬂat behavior state machine SC

can be deﬁned in the instance theory I

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

.≫p

); ...; ≫bj

≪

.≫p

≪

)

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

in RAL:

≫bj

.≫p

); ...; ≫bj

≪

.≫p

≪

)

where the ≫bj

and e

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

, exit

and do activities d≫

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 ﬂat behavior

state machine is then:

1. The set of states is represented as a new enumer-

ated type State

2. A new attribute c state of this type is

added to I

, together with the initialisation

c state := i≪itial

of this attribute

to the initial state of SC. An entry action

e≪try

i≪itial

executes prior to this

update, if present. Local attributes of the state ma-

chine are represented as attributes of I

3. If the transitions triggered by an operation ≫p(x)

of C in SC are tr

, i : 1..k, from states

src

to states trg

, with guard G

and ac-

tions acts

, then the behavior of ≫p(x) is

deﬁned as a composite action C≫de

≫p

α(x) ⊃

if (c state = src

∧ G

)

the≪ exit

src

; acts

; e≪try

trg

;

c state := trg

else if....

else if (c state = src

∧ G

)

the≪ exit

src

; acts

; e≪try

trg

;

c state := trg

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 conﬁgura-

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 deﬁnition

≫p

of ≫p in the class C, the complete deﬁ-

nition of ≫p is D

≫p

; C≫de

≫p

(page 436 of

(OMG, 2007); we assume that an existing pre/post

speciﬁcation should however always refer to the

entire span of execution of ≫p).

We also need to deﬁne the effect of do-actions.

These can only execute while their state is occu-

pied:

#active(d≫

) > 0 ⇒ c state = s

and they initiate execution at the point where their

state is entered (Page 548 of (OMG, 2007)):

∀i : N

· ↑(d≫

,i) = ♣((c state = s) := true, i)

4. The axioms (StateI≪v) :

c state = s ⇒ I≪v

The semantics deﬁned 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 ﬂat behavior state machine SC attached to an

operation ≫p deﬁnes 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 ﬂat state machines to state

machines with OR and AND composite states, com-

pound transitions and history and ﬁnal states.

For each OR state s in the state machine, we de-

ﬁne a state attribute s state : State

where

State

represents the set of normal states (includ-

ing ﬁnal 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

and each s state is initialised

ICEIS 2008 - International Conference on Enterprise Information Systems

to this value. If a ﬁnal state is present, it is denoted by

fi≪al

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 ϕ

can be deﬁned, which expresses that s

is part of the current state conﬁguration of the state

machine (Table 1).

Table 1: State predicate.

State/region s State predicate ϕ

Top-level state SC state = s

Region of AND state p ϕ

Immediate substate of

OR state/region r ϕ

∧ r state = s

A predicate I≪itialState

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

from a state s is ϕ

∧ G

, conjoined with ¬ (ϕ

∧

) for each different transition

ss →

≫p[G1]/P≫st1

triggered by ≫p on a state ss, ss 6= s, ss v

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) = ∧

s∈s≫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 deﬁned in different ways to

produce different semantic proﬁles for state ma-

chines. We could use instead an alternative deﬁ-

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

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 ﬁnal 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

The complete postcondition Π

of tr is the

conjunction of its explicit postcondition, its target

state predicate(s), and ReI≪it

4.1 Structured Behavior State Machines

The semantics for structured behavioral state ma-

chines deﬁnes the sequence of actions caused by the

ﬁring 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 deﬁnition of the complete action

executed when a state s is entered.

Table 2: Entry actions.

State s Entry actions E≪try

basic state e≪try

OR state/region,

one direct substate trg

is explicitly entered e≪try

; E≪try

trg

OR state/region

implicitly entered e≪try

; i≪it

;

or explicit target E≪try

i≪itial

AND state e≪try

;

with regions (E≪try

|| ... || E≪try

r≪

)

r1, ..., r≪

SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES

i≪it

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 deﬁni-

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 deﬁnition of the complete action

executed when a state s is exited.

Table 3: Exit actions.

State s Exit actions Exit

basic state exit

OR state/region,

one direct substate src

is explicitly exited Exit

src

; exit

OR state/region

implicitly exited Exit

s state

;

or explicit source exit

AND state (Exit

|| ... || Exit

r≪

);

with regions exit

r1, ..., r≪

The following axiom, axiom 3, deﬁnes the be-

haviour of an operation resulting from all the transi-

tions for it.

If the transitions triggered by ≫p(x) are tr

i : 1..k, with actions acts

, then the behavior of

≫p(x) is deﬁned as a composite action C≫de

≫p

j:1..k

(if e≪c(tr

) the≪ Exit

;

acts

; E≪try

)

where each Exit

are the exit actions caused by

(Table 3), and E≪try

the entry actions

(Table 2).

This deﬁnition 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

) are mutually

exclusive, this can be simpliﬁed to:

if e≪c(tr

)

the≪ Exit

; acts

; E≪try

else if ....

else if e≪c(tr

)

the≪ Exit

; acts

; E≪try

because (if E

the≪ C

) || (if E

the≪ C

)

is equivalent to

if E

∧ E

the≪ C

|| C

else if E

the≪ C

else if E

the≪ C

For each transition tr triggered by an operation

≫p(x), the pre-post behaviour due to tr is:

∀i : N

· e≪c(tr)}↑(≫p(x),i) ⇒ Π

}↓(≫p(x),i)

The axiom for do-actions holds with ϕ

in place

of c state = s.

Axiom 4 holds in the form

⇒ I≪v

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

Reﬁnements of state machines are relationships be-

tween state machine models which establish that one

state machine (the reﬁned model) correctly imple-

ments all the behaviour of the other, abstract, model.

Often the relationship between a reﬁned 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 reﬁnement and ad-

equacy (Lano et al., 2000; Lano et al., 2002; Simons,

2005).

The condition for a model D to reﬁne 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:

` σ(ψ)

for each axiom ψ of Γ

. Typically σ is deﬁned in

terms of some abstraction morphism f.

ICEIS 2008 - International Conference on Enterprise Information Systems

6 REFINEMENT

TRANSFORMATIONS

Using the above deﬁnition of reﬁnement, we can ver-

ify that many reﬁnement transformations on state ma-

chines are semantically correct:

1. A protocol statemachine can be reﬁned 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 reﬁned, this will

produce a reﬁnement 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 reﬁned into a com-

posite activity.

Other transformations, such as moving entry and exit

actions from states onto transitions, can also be di-

rectly veriﬁed using our semantics.

Once a transformation has been proved correct, it

can be used as required to produce or verify correct

reﬁnements, without requiring repetition of the proof.

6.1 Reﬁnement of Supplier State

Machines

This transformation involves the reﬁnement 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

· (sm1 state = s1)}↑(≫p,i) ⇒

(sm1 state = s2)}↓(≫p, i)

∀i : N

· (sm1 state = s2)}↑(≫p,i) ⇒

(sm1 state = s1)}↓(≫p, i)

∀i : N

· (sm2 state = ss1)}↑(m,i) ⇒

(sm2 state = ss2)}↓(m, i)

∀i : N

· (sm2 state = ss2)}↑(m,i) ⇒

(sm2 state = fi≪al

sm2

)}↓(m,i)

When sm2 is replaced by its reﬁnement sm3, the

op()/m()op()/m()

ss1

ss2

m()

ss1

m()

m()[att <= 0]

ss4

m()

ss3

m()[att > 0]

sm1 sm2

sm1 sm3

Figure 2: Reﬁning a supplier state machine.

axioms of sm2 are replaced by:

∀i : N

· (sm3 state = ss1 ∧ att > 0)}↑(m, i ) ⇒

(sm3 state = ss3)}↓(m,i)

∀i : N

· (sm3 state = ss1 ∧ att ≤ 0)}↑(m, i ) ⇒

(sm3 state = ss4)}↓(m,i)

∀i : N

· (sm3 state = ss3)}↑(m,i) ⇒

(sm3 state = fi≪al

sm3

)}↓(m,i)

∀i : N

· (sm3 state = ss4)}↑(m,i) ⇒

(sm3 state = fi≪al

sm3

)}↓(m,i)

to form the semantics of the complete reﬁned 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 reﬁnement 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 reﬁned 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 reﬁned state. Eg, a guard

i≪ ss2 for a transition of sm1 must be re-

placed by i≪ ss3 ≫r i≪ ss4 in the reﬁned

model, in the above example.

SEMANTICS AND REFINEMENT OF BEHAVIOR STATE MACHINES

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 reﬁnement since

α || β ⊃ α

so that axiom 3 in the new system implies axiom 3 of

the unreﬁned system, due to the monotonicity of the

action constructions wrt ⊃.

6.3 Reﬁning 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.

do/ search

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: Reﬁning a do-action.

In this transformation the original do action α is

interpreted by the new composite action Act. Any

axiom

≫p(x) ⊃ Ac

deﬁning 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 deﬁned an axiomatic semantics for a large

part of UML 2 state machine notation, using the infor-

mal OMG superstructure deﬁnition of the semantics

as the basis. Our semantics supports veriﬁcation of

internal consistency of state machines, of reﬁnement

between state machines, and veriﬁcation 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

speciﬁcation.

In contrast to the approach of (Damm et al., 2005;

Merseguer et al., 2002), we do not ﬂatten 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 speciﬁca-

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

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 speciﬁcation of reactive and real-

time systems. Journal of Logic and Computation,

8(5):679–711.

Lano, K. (2007). Formal speciﬁcation 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 speciﬁcations 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-

ﬁcation 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 Speciﬁcations: The

Reﬁnement 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