Analysing UML Active Classes and Asso ciated State

Machines

A Lightweight Formal Approach

G Reggio E Astesiano C Choppy and H Hussmann

DISI Universita di Genova Italy

LIPN Institut Galilee Universite Paris XI I I France

Department of Computer Science Dresden University of Technology Germany

Abstract We consider the problem of precisely dening UML active classes with

an asso ciated state chart We are convinced that the rst step to make UML

precise is to nd an underlying formal mo del for the systems mo delled by UML

We argue that lab elled transition systems are a sensible choice indeed they have

worked quite successfully for languages as Ada and Java Moreover we think that

this mo delization will help to understand the UML constructs and to improve

their use in practice Here we present the lab elled transition system asso ciated

with an active class using the algebraic sp ecication language CASL

The task of making precise this fragment of UML raises many questions ab out

b oth the precise meaning of some constructs and the soundness of some allowed

combination of constructs

Intro duction

The Unied Mo deling Language UML is an industry standard language for sp eci

fying software systems This language is unique and imp ortant for several reasons

UML is an amalgamation of several in the past comp eting notations for ob ject

oriented mo delling For a scientic approach it is an ideal vehicle to discuss funda

mental issues in the context of a language used in industry

Compared to other pragmatic mo delling notations in Software Engineering UML

is very precisely dened and contains large p ortions which are similar to a formal

sp ecication language as the OCL language used for the constraints

It is an imp ortant issue in Software Engineering to nally close the gap b etween prag

matic and formal notations and to apply metho ds and results from formal sp ecication

to the more formal parts of UML This pap er presents an approach contributing to this

goal and has b een carried out within the Europ ean Common Framework Initiative

CoFI for the algebraic sp ecication of software and systems partially supp orted by

the EU ESPRIT program Within the CoFI initiative which brings together research

institutions from all over Europ e a sp ecication language called Common Algebraic

Sp ecication Language CASL was develop ed which intends to set a standard unifying

the various approaches to algebraic sp ecication and sp ecication of abstract data typ es

It is a goal of the CoFI group to closely integrate its work into the world of practical

engineering As far as sp ecication languages are concerned this means an integration

with UML which may form the basis for extensions or exp erimental alternatives to the

use of OCL That would allow for instance to sp ecify userdened data typ es that just

have values but do not b ehave like ob jects to use algebraic axioms as a constraints

These new constraints may cover also b ehavioural asp ects b ecause there exist extensions

of algebraic languages that are able to cover with them whereas OCL do es not seem

to have any supp ort for concurrency The longterm p ersp ective of this work is to build

a bridge b etween UML sp ecications and the p owerful animation and verication to ols

that are available for algebraic sp ecications

To this end we need to precisely understanding formally dening the most relevant

UML features In this pap er we present the results of such formalization work which was

guided by the following ideas

Real UML Our concern is the real UML ie all or b etter almost all its features

without simplications and or idealizations We are not going to consider a small OO

language with a UML syntax but just what it is presented in the ocial OMG do cu

mentation shortly UML from now on

Based on an underlying mo del We are convinced that the rst step to make UML

precise is to nd an underlying formal mo del for the systems mo delled by UML in the

following called UMLsystems

Our conviction also comes from a similar exp erience the two rst authors had many

years ago when tackling the problem of the full formal denition of Ada within the

ocial EU pro ject see There to o an underlying mo del was absolutely needed to

clarify the many ambiguities and unanswered questions in the ANSI Manual

We argue that lab elled transition systems could b e a sensible mo del choice indeed

they were used quite successfully to mo del concurrent languages as Ada but also a

large part of Java

Lightweight formalization By lightweight we mean made by using the most

simple formal to ols and techniques precisely lab elled transition systems algebraically

sp ecied using a small subset of the sp ecication language CASL conditional sp ecica

tion with initial semantics

Integrated with the formalization of the other fragments of UML In contrast

to many other pap ers on UML semantics we more or less ignore the issue of class diagram

1

semantics here and concentrate on the state machines However the ultimate goal of this

work is to have an approach by which it is easily p ossible to integrate semantically the

most relevant diagram typ es For this reason we are using an algebraic approach to the

semantics of state machines since it is well known that class diagrams can b e mapp ed

relatively easily onto algebraic sp ecications The algebraic semantics describ ed here

enables an algebraic access to the semantics also of active not only of passive classes

Usually an active class is statically describ ed in the class diagram and dynamically

describ ed in an asso ciated statechart diagram

The formalization of active classes and state machines has lead to p erform a thor

ough analysis of them uncovering many problematic p oints Indeed the ocial informal

semantics of UML rep orted in UML is in some p oints either incomplete or ambigu

ous or inconsistent or dangerous ie the semantics is clearly formulated but the allowed

usages seem problematic from a metho dological p oint of view To stress this asp ect and

PROBLEM to highlight them to help the reader we have used the mark pattern

In Sect we dene the subset of the active classes with state machines that we con

sider Then in Sect and we intro duce the used formal techniques lab elled transition

1

Following UML terminology state machine is the abstract name of the construct whereas

state chart is the name of the corresp onding diagram here we always use the former

systems and algebraic sp ecications and present step after step how we have built the

lts mo delling the ob jects of an active class with an asso ciated state machine Due to

lack of ro om part of the denition is rep orted in App endix A while the complete formal

mo del rather short and simple is in

Intro ducing UML Active Classes and State Machines

The UML denes a visual language consisting of several diagram typ es These diagrams

are strongly interrelated by a common abstract syntax and are also related in their

semantics The semantics of the diagrams is currently dened by informal text only

The most imp ortant diagram typ es for the direct description of ob jectoriented soft

ware systems are the following

Class diagrams dening the static structure of the software system ie essentially

the used classes their attributes and op erations p ossible asso ciations relationships

b etween them and the inheritance structure among them Classes can b e passive in

which case the ob jects are just data containers For this pap er we are interested in

active classes where each ob ject has its own threads of control

Statechart diagrams state machines dening the dynamic b ehaviour of an individ

ual ob ject of a class over its lifetime This diagram typ e is very similar to traditional

Statecharts However UML has mo died syntax and semantics according to its over

all concepts

Interaction diagrams illustrating the interaction among several ob jects when carrying

out jointly some use case Interaction diagrams can b e drawn either as sequence

diagrams or as collab oration diagrams with almost identical semantics but dierent

graphical representation

A UML state machine is very similar to a classical nite state machine It depicts

states drawn as rounded b oxes carrying a name and transitions b etween the states A

transition is decorated by the name of an event p ossibly followed by a sp ecication of

some action after a slash symb ol The starting p oint for the state machine is indicated

by a solid black circle an end p oint by a solid circle with a surrounding line

The complexity of UML state machines compared to traditional nite state machines

comes from several origins

The states are interpreted in the context of an ob ject state so it is p ossible to make

reference eg in action expressions to ob ject attributes

There are constructs for structuring state machines in hierarchies and even concur

rently executed regions

There are many sp ecialized constructs like entry actions which are red whenever a

state is entered or state history indicators

In order to simplify the semantical consideration in this pap er we assume the follow

ing restrictions of dierent kinds Please note that none of these assumptions restricts

the basic applicability of our semantics to full UML state machines

We do not consider the following UML state machine constructs b ecause they can

b e replaced by equivalent combinations of other constructs

Submachines We can eliminate submachines by replacing each stub state with the

corresp onding submachine as UML p states It is a shorthand that implies

a macrolike expansion by another state machine and is semantically equivalent to a comp osite state

Entry and exit actions Entry and exit actions asso ciated with a state are a kind of

shortcut with metho dological implication see eg p but semantically

they are not relevant indeed we can eliminate them by adding such actions to all

transitions enteringleaving such state

Internal transitions An internal transition diers from a transition whose source and

target state coincide only for what concerns entryexit actions Because we have

dropp ed entryexit actions we can drop also internal transitions

The following picture shows on an example how to eliminate entry actions and

internal transitions

S S

E E / a

S1 is equivalent to entry / a E1 / a2 E2 / a1 S1 E1 / a2 ; a E2 / a1

E E

Dierent transitions leaving the same state having the same event trigger We

can replace these transitions with comp ound transitions using junction states The

latter presentation seems b etter from a metho dological p oint of view and makes the

semantics clearer what to do when dispatching an event is explained in UML by

considering the transitions with the same trigger leaving a state all together The

picture b elow shows on an example of this simplication

S S E

E [g1] / a1 E [g2] / a2 is equivalent to [g1] / a1 [g2] / a2

S2 S3

S2 S3

Multiple initialnal states We assume that there is always one unique initial state

at the top level used to determine the initial situation of the class ob jects and

one unique nal state at the top level when it is active the ob ject will p erform a

self destruction The remaining initialnal states can b e replaced by using com

plex transitions The picture b elow shows an example of equivalent state machines

diering only in the numb er of initialnal states

E S1 S2 E S S S1 S2 E1 E1 E1 E1 E1 E1 S3 E S3

E

Comp ound transitions We assume there are no comp ound transitions except the com

plex one and comp ounds of length two eg as those needed in the two cases ab ove

Indeed comp ound transitions are used only for presentation reasons and can b e re

placed by sets of simpler transitions

Terminate action in the state machine Indeed it can b e equivalently replaced by a

destroy action addressed to the self

We do not consider the following features just to save space indeed we think that

they could b e mo delled without much trouble

Op erations with return typ e and return actions

Synch and history states

Generalization on the signals typ e hierarchy on signals

Activities in states doactivities

Mo delling Active Ob jects with Lab elled Transition Systems

Lab elled Transition Systems

A labeled transition system shortly lts is a triple ST LAB where ST and LAB are

0

two sets and ST LAB ST is the transition relation A triple s l s is said

l

0

to b e a transition and is usually written s s

Given an lts we can asso ciate with each s ST the tree transition tree whose ro ot

0

is s where the order of the branches is not considered two identically decorated subtrees

0

with the same ro ot are considered as a unique subtree and if it has a no de n decorated

l

0 0 0

with s and s s then it has a no de n decorated with s and an arc decorated with l

0

from n to n

We mo del a pro cess P with a transition tree determined by an lts ST LAB and

an initial state s ST the no des in the tree represent the intermediate interesting

0

situations of the life of P and the arcs of the tree the p ossibilities of P of passing from

l

0

one situation to another It is imp ortant to note here that an arc a transition s s

has the following meaning P in the situation s has the capability of passing into the

0

situation s by p erforming a transition where the lab el l represents the interaction with

the environment during such a move thus l contains information on the conditions on

the environment for the capability to b ecome eective and on the transformation of such

environment induced by the execution of the transition

Notice that here by pro cess we do not mean sequential pro cess indeed also con

current pro cesses which are pro cesses having co op erating comp onents that are in turn

other pro cesses concurrent or not can b e mo delled through particular lts named struc

tured lts A structured lts is obtained by comp osing other lts describing such comp onents

say clts its states are built by the states of clts and its transitions are determined by

comp osing those of clts

An lts may b e formally sp ecied by using the algebraic sp ecication language CASL

see with a sp ecication of the following form

sp ec Lts

State and Label then

free f pred StateLabelState

axioms

g end

whose axioms have the form where for i n is a

1 n n+1 i

p ositive atom ie either a predicate application or an equation The CASL construct

free requires that the sp ecication has an initial semantics

some words on CASL and initial semantics

Assume to have a given active class ACL with a given asso ciated state machine SM

b elonging to the subset of UML intro duced in Sect and assume that ACL and SM are

statically correct as stated in UML

We have built the lts L mo delling the ob jects of the class ACL following the steps

b elow which will b e rep orted in the following sections

check whether L is simple or structured

determine the grain of the Ltransitions

if L is structured determine its comp onents and the lts mo delling them

determine the lab els of L

determine the states of L

determine the transitions of L by means of conditional rules in this case b ecause

we are using CASL by conditional axioms

The constraints attached either to ACL or to SM are treated apart in Sect b ecause

they do not dene a part of L but just prop erties on it

To avoid confusion b etween the states and the transitions of the state machine SM

with those of the lts L we will write from now on Lstates and Ltransitions when

referring to those of L

Is L simple or structured

The rst question is to decide whether L is simple or structured this means in terms of

UML semantics to answer the following question

PROBLEM Do es an active ob ject corresp ond to a single thread of control running

concurrently with the others or to several ones

Unfortunately UML is rather ambiguousinconsistent for what concerns this

p oint Indeed somewhere it seems to suggest that there is exactly one thread as in

UML p p p

It is possible to dene state machine semantics by al lowing the runtocompletion

steps to be applied concurrently to the orthogonal regions of a composite state

rather than to the whole state machine This would al low the event serialization

constraint to be relaxed However such semantics are quite subtle and dicult

to implement Therefore the dynamic semantics dened in this document are

based on the premise that a single runtocompletion step applies to the entire

state machine and includes the concurrent steps taken by concurrent regions in

the active state conguration

Otherwise UML seems to assume that there are many threads as in p p

p

A concurrent transition may have multiple source states and target states It

represents a synchronization andor a splitting of control into concurrent threads

without concurrent substates

and in p

An event instance can arrive at a state machine that is blocked in the midd le

of a runtocompletion step from some other object within the same thread in a

circular fashion This event instance can be treated by orthogonal components of

the state machine that are not frozen along transitions at that time

In this pap er we stick to the interpretation suggested in so each active ob ject

corresp onds to one thread However a p erhaps b etter way to solve this p oint is to in

tro duce two stereotyp es onethread and manythreads to allow the user to decide the

amount of parallelism inside an active ob ject

Determining the granularity of the Ltransitions

Using lts means that we mo del the b ehaviour of pro cesses by splitting it into atomic

pieces the Ltransitions so to dene L we must determine the granularity of this

splitting ie of the Ltransitions

PROBLEM By lo oking at UML we see that there are two p ossibilities corresp onding

to dierent semantics

each Ltransition corresp onds to p erforming a group of transitions of the state ma

chine triggered by the o ccurrence of the same event starting from a set of active con

current states Because Ltransitions are mutually exclusive this choice corresp onds

to a semantics where Ltransitions are implicitly understo o d as critical regions

each Ltransition corresp onds to p erforming a part of a state machine transition the

atomicity of transitions runtocompletion condition required by UML is guar

anteed by the fact that while executing the various parts of the transition triggered

by an event an ob ject cannot dispatch another event In this case the parts of the

state machine transitions p erformed by the same or dierent ob jects may b e executed

concurrently

The example in Fig where we assume here that there is another ob ject O with an

op eration OP resulting in a printable value shows an instance of this problem

Choice corresp onds to say that in any case pairs of identical values will b e printed

whereas choice allows for pairs of p ossibly dierent values b ecuase the value returned

by OP can b e dierent in the two o ccasions due to the activity of other ob jects

S

E

S1

E1 / PRINTER.print(O2.OP(3));

PRINTER.print(O2.OP(3));

Fig A simple State Machine

We think that choice is b etter however we could similarly mo del also

Determining the LLab els

The Llab els lab els of the lts L describ e the p ossible interactionsinterchanges b etween

the ob jects of the active class ACL and their external environment the other ob jects

comprised in the mo del By lo oking at UML we nd that the basic ways the ob jects

of an active class interact with the other ob jects are the following distinguished by us

in input and output

input

to receive a signal from another ob ject

to receive an op eration call from another ob ject

to read an attribute of another ob ject

to have an attribute up dated by another ob ject

to b e destroyed by another ob ject

to receive from some clo ck the actual time see p

output

to send a signal to another ob ject

to call an op eration of another ob ject

to up date an attribute of another ob ject

to have an attribute read by another ob ject

to createdestroy another ob ject

UML do es not consider explicitly the interactions marked by and do es not

say anything ab out when they can b e p erformed eg they are not considered by the

state machines

PROBLEM When may an ob ject b e destroyed

A way to settle this p oint is to make to b e destroyed an event which may dispatched

when the machine is not in a runtocompletionstep and may app ear on the transitions

the state machine

PROBLEM The interactions corresp onding to readup date attributes of other ob jects

raise a lot of questions ab out the UML semantics

May an ob ject have its attributes up dated by some other ob ject

If the answer is yes then when such up dates may take place For example is it allowed

during a runtocompletionstep

Are there any mutual exclusion prop erties on such up dates or may it happ en that an

ob ject O up dates an attribute A of O while O is up dating it in a dierent way or that

O and O up dates simultaneously A in two dierent ways

May an active ob ject have a b ehaviour not describ ed by the asso ciated state machine

see UML p b ecause another ob ject up dates its attributes

In the following example another ob ject may p erform OX OX changing

completely the b ehaviour sp ecied by this state machine

S

START / X = 0;

DEC / [ X > 0] X = X-1; S1 INC / [ X < 100] X = X+1;

STOP

Notice also that readingup dating attributes of the other active ob jects is an implicit

communication mechanism thus yielding a dep endency b etween their b ehaviours that is not explicitly stated

A way to overcome this p oint may b e to fully encapsulate the attributes with the

op erations ie an attribute of a class may b e read and up dated only by the class op er

ations As consequence the expressions and the actions app earing in the state machine

may use only the ob ject attributes and not those of other ob jects

Then an Llab el will b e a triple consisting of a set of events received from outside

the received time and a set of events sent outside b ecause due to the ab ove choice the

are no more the interactions marked by

Determining the LStates

The Lstates states of the lts L describ e the intermediate relevant situations in the life

of the ob jects of class ACL

By lo oking at UML we found that to decide what an ob ject has to do in a given

situation we surely need to know

the ob ject identity

the set of the states of the state machine SM that are active in such situation

whether the ob ject is in a runtocompletion step and in such case which are the

states that will b ecome active at the end of such step each one accompanied by the

actions to b e p erformed to reach such states

the values of ob ject attributes

the status of the event queue

Thus the Lstates must contain such informations successively when dening the tran

sitions we discovered that to handle change and time events we need also to know

the sequence of the Lstates reached by the ob ject during its past life

The Lstates are thus sp ecied by this CASL sp ecication

sp ec LState

Queue and Time then Ident and Configuration and Attributes and Event

free typ es

Queuei j State Ident hConguration Attributes History Event

Ident terminated

History j hState Timei History

where Ident terminated are sp ecial elements representing terminated ob jects

A conguration contains the set of the states that are active in a situation and of

those states that will b ecome active at the end of current runtocompletion step if any

the latter are accompanied by the actions to b e p erformed to reach such states

sp ec Event Queue

SetEvent then

Queue sort Event

preds no dispatchable event Event Queue

checks whether there is no a dispatchable event

EventEvent Queue

checks whether a given event in the queue may b e selected for dispatching

Queue Event Queue ops put SetEventEvent

adds some events to the queue

remove EventEvent Queue Event Queue

removes an event from the queue

PROBLEM UML explicitly calls the ab ove structure a queue but it also clearly

states that no order must b e put on the queued events UML p and so it is

really a multiset This choice of terminology is problematic b ecause it can induce a user

to assume that some order on the received events will b e preserved

The fact that the event queue is just a bag causes other problems an event may remain

for ever in the queue time and change events may b e dispatched disregarding the order

in which happ ened eg after dispatched b efore after a change event is

dispatched when its condition is false again two signal or call events generated by the

same state machine in some order are dispatched in the reverse order

To x this p oint we can either change the name of the event queue in the UML

do cumentation in something recalling its true semantics or dene a p olicy for deciding

which event to dispatch rst

In an UML mo del we cannot assume anything on the order with which some events

are received by an ob ject as the signal and op eration calls we conjecture that this was

the motivation for avoiding to order the events in the queue However we think that it

is b etter to have a mechanism ensuring that when two events are received in some order

they will b e dispatched in the same order also if in many cases we do not know such

order

The sp ecications of the other comp onents of the Lstates are rep orted in

Determining the LTransitions

An Ltransition ie a transition of the lts L corresp onds to

either to dispatch an event

or to execute an action

or to receive some events such events are either received from outside signals and

op eration calls or generated lo cally self sent signals and op eration calls change and

time events

or to b e destroyed by dispatching a sp ecial event

Moreover may b e also p erformed simultaneously to and b ecause we cannot

delay the reception of events

It is imp ortant to notice that the Ltransitions of and the transitions of the state

machine SM are dierent in nature and are not in a bijective corresp ondence To clarify

such relationship we partly rep ort in Fig the lab elled transition tree asso ciated with

the simple state machine of Fig where it is p ossible to see that one state machine

transitions corresp ond to many Ltransitions

The Ltransitions are formally dened by the axioms of this algebraic sp ecication

sp ec LSpec

LLabel and LState then

StateLabelState free f pred

l

axioms cond s s

In the following subsections we give the axioms corresp onding to the four cases ab ove To

master complexity and to improve readability we use several auxiliary functions in such

axioms whose name is written in sans serif font Some relevant problems come to light

when dening some of such functions and thus we consider them explicitly in Sect The others are rep orted in the App endix A S, {} receiving E <{E},t,{}> <{E1},t,{}> receiving E1

S, {E} S, {E1}

dispatching E <{},t',{}> <{E},t',{}> receiving E

S1, {} S, {E1,E} <{},t"',{}> <{},t",{}> dispatching E1 dispatching E

S, {E}

Fig A fragment of a lab elled transition tree

Dispatching an Event

If the ob ject is not in a runtocompletion step checked by predicate not frozen an

event ev is in the event queue ready to b e dispatched ev e queue then there is an

Ltransition with the lab el resulting from the events received from outside in evs and

the time t where the history has b een extended with the current state and all received

events are put in the event queue as describ ed by Receive Events

0

0

Recall that Dispatch ev conf e queue conf e queue means that dispatching event

0

0

ev in the conguration conf changes it to conf and changes e queue to e queue

not frozenconf ev e queue Dispatchev conf e queue conf e queue

hin evsti

queuei id hattrs conf history e queue i id hconf attrs history e

where

e queue Receive Eventse queue in evs attrs history t

history hid hconf attrs history e queuei ti history

Executing an action

If the ob ject is in a runtocompletion step checked by predicate frozen and p erforms

an action then there is an Ltransition with the lab el resulting from the events received

evs the time t and the set of events generated in the action to b e from outside in

propagated outside out evs where the attributes are up dated due to executed action

the history has b een extended with the current state and all received events are put in

the event queue as describ ed by Receive Events

0

0

Exec id attrs conf conf attrs out evs loc evs means that the ob ject id with con

0

guration conf executes an action changing its conguration to conf up dating its at

0

tributes to attrs and pro ducing the set of output events out evs and the set of lo cal

events loc evs

evs loc evs frozenconf Execid attrs conf conf attrs out

hin evstout evsi

queuei id hattrs conf history e queue i id hconf attrs history e

where

queuei ti history history hid hconf attrs history e

e queue Receive Eventse queue in evs loc evs attrs history t

Receiving some Events

frozen the If the ob ject is not in a runtocompletion step checked by predicate not

event queue is empty then there is an Ltransition with the lab el resulting from the

set of events received from outside in evs and the time t where the history has b een

extended with the current state and all received events are put in the event queue as

describ ed by Receive Events

not frozenconf no dispatchable evente queue

hin evsti

queuei queue i id hconf attrs history e id hattrs conf history e

where

e queue Receive Eventse queue in evs attrs history t

history hid hconf attrs history e queuei ti history

Being destroyed

We consider a destruction request as an event and assume that an ob ject cannot b e

destroyed while is in a runtocompletion step

frozenconf destroy e queue not

hin evsti

queuei id terminated id hconf attrs history e

Auxiliary functions

Events Event Queue SetEvent AttributesHistoryTime ! Event Queue Receive

0 0

Receive Events e queue evs attrs history t e queue means that e queue is e queue

up dated by putting in it all received events the signal and op eration call events are

given by a function parameter evs the time events are detected using t and history by

the function TimeOccur and the change events are detected by using attrs and history

by the function ChangeOccur

PROBLEM May op eration calls to other ob jects app ear within the expressions of

change and time events

If the answer is yes then we can have more hidden constraints on the mutual b ehaviour

of ob jects eg a synchronous op eration call in the expression of a change event may

blo ck an ob ject

Events We assume no and this is the reason for the ab ove simple functionality of Receive

Receive Eventse queue evs attrs history t

putTimeOccur t history ChangeOccur attrs history evs e queue

We rep ort the denitions of TimeOccur and of ChangeOccur in App endix A

Dispatch Event Conguration Event Queue ! CongurationEvent Queue

0

0

Dispatch ev conf e queue conf e queue means that dispatching event ev in the con

0

0

guration conf changes it to conf and changes e queue to e queue

It is dened by cases and here we rep ort the most relevant ones the others are

rep orted in App endix A

Some transitions triggered by an event Assume that in the state machine SM there are

the following branched transitions triggered by E starting from the states b elonging to Sset S 1 S r

E (X 1 ,...,Xn ) E (X 1 ,...,Xn ) 1 1 1 1 ...... r r r r [cond 1 ] / act1 [cond ] / actk [cond ] / act 1 [cond ] / actk k1 1 1 k r r

S 1 S 1 S r S r 1 ...... k1 1 ...... k r

Note that inheritance of transitions b etween nested states and overriding may b e handled

here by deciding which transitions to consider

i

holds for i h h r then the ob ject If the active states are Sset and cond

q

i

i

i

and to reach state S will start a runtocompletion step going to p erform act for

q q

i i

i h the actual parameters of the event are substituted for its formal parameters

within the actions to b e p erformed

h i

active statesconf Sset Evalcond p x attrs T r ue

j j

q

i=1

i

queue conf removeEp p e queue DispatchEp p conf e

1 n 1 n

where

1 1 h h

conf run runconf act p x S act p x S

j j j j

q q q q

1 1

h h

states and run are op erations of the sp ecication Configuration returning active

resp ectively the active states of the state machine and recording the start of a runto

completion step going from an active state into another one p erforming a given action

PROBLEM What to do when the dispatched event is an op eration call for whom also

a metho d has b een dened in the class ACL

The solution in this case is just to prohibit to have a metho d for the op eration app earing

in some transition and it is supp orted eg by p and other UML sources

PROBLEM A similar problem is p osed by the case b elow what will happ en when

someone calls metho d Op whose b o dy is describ ed by the note attached to its name in

the class diagram On one hand assuming that such call is never answered may lead to

pro duce wrong UML mo dels b ecause the other classes assume that Op is an available

service since it app ears in the class icon On the other hand answering to it p erhaps

only when the machine is not in a runtocompletionstep seems in contrast with the

role of the state machine UML p

C S int X = 0; Op1(n,m) / Op1(n,m) / { X = X - n; Op(int n) X = m+n; X = m * n; O1.Op'(n); }

Op1(int n, int m) S1

In general op erations with an asso ciated metho d seem to b e problematic for the active

classes and so it could b e sensible to drop them

No transitions triggered by a deferred event Assume that in the state machine SM there

are no transitions starting from states b elonging to Sset triggered by E and that E is

deferred in some elements of Sset

PROBLEM UML do es not say what to do when dispatching E in such case The

p ossible choices are

remove it from the event queue

put it back in the event queue

put it back in the event queue but only for the states in which it was deferred

Here we assume that it is deferred and that after it will b e available for any state

however notice that we could formally handle also the rst cases whereas to consider

the last we need to assume that there are many threads in an ob ject with the relative

event queues one for each active state

If the active states are Sset then the event Ep p is left in the event queue for

1 n

future use

active statesconf Sset

DispatchEp p conf e queue conf e queue

1 n

Constraints

Constraints may b e attached to any element of a UML mo del For what concerns the

fragment of UML considered in this pap er we have constraints attached to the class icon

eg invariants and to the op erations eg prep ost conditions in the class diagram

and attached to the state machine eg invariants The language for expressing the

constrains is not xed in UML also if OCL is the most used however the semantics of

the constraints is precisely settled indeed UML p states

A constraint is a semantic condition or restriction expressed in text In the meta

model a Constraint is a BooleanExpression on an associated ModelElements

which must be true for the model to be wel l formed Note that a Constraint is

an assertion not an executable mechanism It indicates a restriction that must

be enforced by correct design of a system

Such idea of constraint may b e easily formalized in our setting the semantics of a con

straint attached either to ACL or to SM is a prop erty on L The formulae of CASL allow

to express a rich set of relevant prop erties recall that the underlying logic of CASL is

many sorted rstorder logic and that CASL extensions with temp oral logic combina

tors based on are under development Moreover the constraints expressed using OCL

may b e translated in CASL without to o many problems

Assume we have the constraints C C attached either to ACL or to SM then

1 n

then the UML mo del containing ACL and SM is well formed i for i n L j

i

where is the CASL formula corresp onding to C Techniques and to ols develop ed for

i i

algebraic sp ecication languages may help to verify the well formedness of UML mo dels

PROBLEM The use of constraints without a prop er discipline may b e problematic as

in the following case where the constraint attached to the icon of class C is an invariant

that must hold always and so must b e resp ected also by the transitions triggered by

the calls to OP and OP These inconsistencies may b e hard to detect b ecause the

problematic constraints are in the class diagram while state machine violating them is

given elsewhere

S C

int X, Y = 0; state chart: Op1/ Op(n) / class diagram: Y = Y+1 X = n; Op(int n); { X > Y } Op1();

S1

In UML there are also other constraintlike constructs p osing similar problems as the

query qualication for op eration requiring that an op eration do es not mo dify the state

of the ob ject or the sp ecications for signal receptions expressing prop erties on the

eects of receiving such signal Also in these cases the b ehaviour describ ed by the state

machine may b e in contrast with them

We think that a way to settle those problems is to develop a precise metho dology for

using these constraints making precise their role and when to use them in the develop

ment pro cess

Conclusions and related work

The task of formalizing UML has b een addressed using various available formal tech

niques as we will discuss b elow Most of these attempts are complementary b ecause

they approach the task from dierent viewp oints and aims

In this resp ect our work has several distinguishing features First of all we are using

a very elementary and wellknown machinery namely lts which are at the basis of for

malisms like CCS and conditional algebraic sp ecications As happ ened for Ada

this simple mo del provides a p owerful setting for revealing ambiguities incompleteness

and p erhaps questionable features b oth from the purely technical and the metho dolog

ical p oint of view For example we have discussed several naturally arising questions

concerning UML such as what is the b ehaviour of an ob ject with several active sub

threads and do es the run to completion execution of a state machine transition imply

that a transition is a kind of critical region

Furthermore we have used a mo dular framework where the various p ossible interpre

tations of the asp ects of UML and of its many variants may b e made precise and the

various problems exemplied and discussed also with users lacking a formal background

a lightweight formal metho d approach

Within the Precise UML group and also outside several prop osals for formalizing

UML or parts of them have b een presented we briey rep ort on some paradigmatic

directions

Some pap ers are addressing sp ecic questions for example shows how to use graph

rewriting techniques to transform UML state machines into another simplied machine

a kind of normal form but eg the execution of actions is not considered That pap er

could b e seen as providing a metho d for eliminating what we called shortcuts in Sect

Some other pap ers try to formalize UML by using a particular sp ecication language

for example as in using RealTime Action Logic a form of real time temp oral logic

With resp ect to these approaches we put less emphasis on the sp ecication language and

more on the underlying mo del b ecause we think that in this setting it is easier to explain

UML features also the p ossible problems and to derive a revised informal presentation

The relevance of the underlying mo del for making precise UML has b een considered

in where a dierent mo del a kind of stream pro cessing function is used But the

main aim there is metho dological how a software engineering metho d can b enet from

an integrative mathematical foundation While one of the main results of our work could

b e a basis for a revised reference manual for UML

Finally we have not considered the large numb er of pap ers on the semantics of clas

sical state machines as those supp orted by the Statemate to ol b ecause the semantics

of the UML state machines is rather dierent eg in the former many events may o ccur

simultaneously whereas that cannot happ en in UML see page

We plan to go on analysing UML to give a sound basis for our work in the CoFI

pro ject trying to give an underlying formal lightweight mo del to the other constituents

of a UMLsystem ie to instances of passive classes and the system itself and to consider

the other kinds of diagrams as class sequence and collab oration

References

E Astesiano A Giovini F Mazzanti G Reggio and E Zucca The Ada Challenge for New

Formal Semantic Techniques In Ada Managing the Transition Proc of the AdaEurope

International Conference Edimburgh University Press Cambridge

R Breu R Grosu F Hub er B Rump e and W Schwerin Systems Views and Mo dels

of UML In The Unied Modeling Language Technical Aspects and Applications Physica

Verlag Heidelb erg

E Coscia and G Reggio A Prop osal for a Semantics of a Subset of MultiThreaded Go o d

Java Programs Technical rep ort Imp erial College London

G Costa and G Reggio Sp ecication of Abstract Dynamic Data Typ es A Temp oral Logic

Approach TCS

M Gogolla and F ParisiPresicce State Diagrams in UML A Formal Semantics using

Graph Transformation In Proc ICSE Workshop on Precise Semantics of Modeling

TechniquesPSMT Technical Rep ort TUMI

K Lano and J Bicarregui Formalising the UML in Structured Temp oral Theories In

Proc of Second ECOOP Workshop on Precise Behavioral Semantics ECOOP Munich

Germany

PD Mosses CoFI The Common Framework Initiative for Algebraic Sp ecication and

Development In Proc TAPSOFT numb er in Lecture Notes in Computer Science

Berlin Springer Verlag

The CoFI Task Group on Language Design Casl Summary Version Technical rep ort

Available on httpwwwbricsdkProjectsCoFIDocumentsCASLSummary

G Reggio E Astesiano C Choppy and H Hussmann A CASL Formal Denition of UML

Active Classes and Asso ciated State Machines Technical Rep ort DISITR DISI

Universita di Genova Italy

J Rumbaugh Some questions relating to actions and their parameter and relating to

signals Private communication

J Rumbaugh I Jacobson and G Bo o ch The Unied Modeling Language Reference Man

ual Ob ject Technology Series AddisonWesley

UML Revision Task Force OMG UML Specication Available at

httpumlshlcom

A Auxiliary Functions

TimeOccur Time History ! SetEvent

Assume that the time events app earing in the state machine SM are TE TE

1 n

TimeOccur t history tev t history tev t history

1 n

where for i n tev is an op eration of sort SetEvent corresp onding to TE dened

i i

by cases on the form of TE

i

TE after exp absolute time event This event o ccurs when the dierence b e

i

tween the actual time and the time the ob ject entered the source state of the transi

tion in which app ear the event S is equal to the value of exp

statehistory S t tev t history fTE g Evalexp attrs t t entered

i i

statehistory S t tev t history Evalexp attrs t t entered

i

TE after exp since S relative time event This event o ccurs when the dier

i

ence b etween the actual time and the time the ob ject entered state S is equal to the

value of exp

Evalexp attrs t t entered statehistory S t tev t history fTE g

i i

Evalexp attrs t t entered statehistory S t tev t history

i

ChangeOccur AttributesHistory ! SetEvent

Assume that the change events app earing in the state machine SM are CE CE

1 n

ChangeOccur attrs history cev attrs history cev attrs history

1 n

where for i n cev is an op eration of sort SetEvent corresp onding to CE dened

i i

as follows

Assume CE change bexp This event o ccurs when the value of bexp is true in the

i

current state and was false in the previous state

statehistory F al se Evalbexp attrs T r ue Evalbexp attrsprevious

cev bexp attrs fCE g

i i

Evalbexp attrs F al se cev bexp attrs

i

statehistory T r ue Evalbexp attrs T r ue Evalbexp attrsprevious

cev bexp attrs

i

Dispatch

Here we rep ort the lacking cases of the denition of Dispatch

No transitions triggered by a nondeferred event Assume that in the state machine SM

there are no transitions starting from the states b elonging to Sset triggered by E and

that E is not deferred in any element of Sset

If the active states are Sset then event Ep p is just removed from the event

1 n

queue

active statesconf Sset

queue conf removeEp p e queue DispatchEp p conf e

1 n 1 n

Some transitions triggered by the event Assume that in the state machine SM there are

the following branched transitions triggered by E starting from the states b elonging to Sset S 1 S r

E (X 1 ,...,Xn ) E (X 1 ,...,Xn ) 1 1 1 1 ...... r r r r [cond 1 ] / act1 [cond ] / actk [cond ] / act 1 [cond ] / actk k1 1 1 k r r

S 1 S 1 S r S r

1 ...... k1 1 ...... k r

inheritance of transitions and overriding may b e handled here by deciding which tran

sition to consider

If the active states are Sset E is not deferred in any of the states in Sset and for

i

do es not hold then such event is removed from the i r j k cond

i

j

queue

k

r i

i

p x attrs F al se statesconf S Evalcond active

j j

i=1 j

j =1

DispatchEV p p conf e queue conf removeEp p e queue

1 n 1 n

If the active states are Sset E is deferred in some of the states in Sset and for

i

i r j k cond do es not hold then such event is left in the queue

i

j

k

j

r

active statesconf S Evalcond p x attrs F al se

i j j

i=1

j =1

queue conf e queue DispatchEV p p conf e

1 n

Exec Ident AttributesConguration !

Conguration AttributesSetEvent SetEvent

0

0

Execid attrs conf conf attrs out evs loc evs means that the ob ject id with cong

0

uration conf may execute an action changing its conguration to conf up dating its

0

attributes to attrs and pro ducing the set of output events out evs and the set of lo cal

events loc evs

Exec is dened by cases on the form of the action to b e executed

calling an op eration

Self calling

n

execute conf idOpexp exp S Evalexp attrs v to

i

1 n i

i=1

Execid attrs conf

executeconf idOpexp exp S attrs fOpv v g

1 n

1 n

Calling another ob ject

0

to execute conf id Opexp exp S

1 n

0

n

id Evalexp attrs v id

i

i

i=1

Execid attrs conf

executeconf idOpexp exp S attrs fidOpv v g

1 n

1 n

sending a signal

Sig is a signal for whom ACL has a reception self sending Notice that Sig is

sent also outside b ecause it must b e received also by the other ob jects of the

same class and by the ob jects of other classes having a reception for it

n

to executeconf Sigexp exp S Evalexp attrs v

i

i=1

1 n i

Execid attrs conf

executeconf Sigexp exp S attrs fSigv v g fSigv v g

1 n 1 n

1 n

Sig is a signal for whom ACL has not a reception sending outside

n

to executeconf Sigexp exp S Evalexp attrs v

i

i=1

1 n i

Execid attrs conf executeconf Sigexp exp S attrs fSigv v g

1 n

1 n

destroy

Self destruction

to executeconf iddestroy S

Execid attrs conf executeconf iddestroy S attrs fdestroyg

Destroying another ob ject

to executeconf id destroy S id id

Execid attrs conf executeconf id destroy S attrs fid destroyg

assignment to one of its attributes as an example of uninterpreted action

executeconf x exp S Evalexp attrs v to

Execid attrs conf executeconf x exp S attrsv x

Eval Expression AttributesSetInputs ! Value

Evalexp attrs v means that the value of exp calculated using attrs is v

attribute of the ob ject

Evalx attrs value ofattrs x

data op erator

n

Evalexp attrs v EvalOP exp exp attrs opv v

i 1 n

i 1 n

i=1