Proceedings oI the International MulticonIerence on ISBN 978-83-60810-14-9

Comuter Science and InIormation Technolog, . 17 24 ISSN 1896-7094

Abstract - Model driven approach for program development
can assist in quick generation of complex and highly reliable
applications. Framework for eXecutable UML (FXU) trans
forms UML models into C source code and supports execution
of the application reflecting the behavioral model. The
framework consists of two parts code generator and run time
library. The generated and executed code corresponds to
structural model specified in class diagrams and behavioral
model described by state machines of these classes. All single
concepts of state machines included in the UML .0
specification (and further) are taken into account, including all
kinds of events, states, pseudostates, submachines etc. The
paper discusses the correctness issues of classes and state
machine models that have to be decided in the framework in
order to run a modelrelated and high quality C application.
The solution was tested on set of UML models.
I. INTROUCTION
OEL riven Engineering (ME) reresents soIt-
ware develoment aroaches in which creation and
maniulation oI models should result in building oI an exe-
cutable sstem |1|.
M
Industrial roduct develoment uts a lot oI attention on
Iast imlementation oI the needed Iunctionalities. Model-
driven aroach to rogram develoment oIIers a romising
solution to these roblems. The comlex behavioral models
can be designed and veriIied at the earl stages oI the whole
roduct creation ccle and automaticall transIormed into
the code reserving the desired behavior.
State machines, also in the Iorm oI statecharts incoro-
rated in the UML notation |2|, are a widel used concet Ior
seciIication oI concurrent reactive sstems. Proosal Ior ex-
ecution oI behavioral UML models suIIers Irom the roblem
that no generall acceted Iormal semantics oI UML models
is available. ThereIore, validation oI UML transIormation
and model behavior deicted in the resulting code is diIIi-
cult. Rather than comletel Iormalizing UML models, we
tr to deal with selected asects oI the models.
Checking oI models is imortant in Model riven Archi-
tecture (MA) aroaches |3|, |4| where new diagrams and
code are automaticall snthesized Irom the initial UML

This work was suorted b the ean oI the eartment oI Electronics

and InIormation Technolog, Warsaw Universit oI Technolog under
grant no 03/G/1032/4300/008
model: all the constructed artiIacts would inherit the initial
inconsistenc ||.
Inconsistenc and incomleteness allowed b UML can be
a source oI roblems in soItware develoment. A basic te
oI design Iaults is concerned with the well-Iormedness oI di-
agrams |2|. Ticall, comleteness oI a design reuires that
introduced model elements are seciIied with their Ieatures
and usage oI one element can iml a usage oI another, di-
rectl related model element. In the current modeling CASE
tools some comleteness conditions can be assured automati-
call (e.g., deIault names oI roles in associations, attributes,
oerations etc.). Incomleteness oI models can be to be
strongl related to their inconsistenc, because it is oIten im-
ossible to conclude whether diagrams are inconsistent or in-
comlete |6|. ThereIore, within this aer we will reIer to
model deIects as to correctness issues.
The ramework Ior eecutable UML (U) oIIers a
Ioundation Ior aling MA ideas in automation oI soIt-
ware design and veriIication. The U Iramework was the
Iirst solution that suorted generation and execution oI all
elements oI state machine UML 2.0 using C language |7|.
In order to build an alication reIlecting the modeled
classes and their behaviors seciIied b state machines, we
resolved necessar semantic variation oints |8|. Semantic
variation oints are asects that were intentionall not deter-
mined in the seciIication |2| and its interretation is leIt Ior
a user.
It was also necessar to rovide some correctness check-
ing oI a model. This aer is devoted to these issues. To
resent otential roblems we selected one target alication
environment, i.e., creation oI alication in C language.
The veriIication oI an inut UML model is based on a set oI
hard coded rules. Some oI the rules are general and can be
alied Ior an obect-oriented language, as the originate
directl Irom the UML seciIication |2|. Other rules are
more environmental seciIic because the take also into ac-
count the Ieatures oI the target language - C. The veriIica-
tion is erIormed during transIormation oI class and state
machine models into the corresonding code it is so-called
static veriIication. Other set oI rules is used during execution
oI the code corresonding to given state machines so-called
dnamic veriIication. or all correctness rules the arori-
ate reaction on the detected Ilaws were seciIied.
978-83-60810-14-9/08/2.00 2008 IEEE 17
Correctness issues of UML Class and tate Machine Models
in the C Code Generation and Execution Framework
Anna ereziska
Institute oI Comuter Science Warsaw Universit oI
Technolog, ul. Nowowieska 1/19 00-66
Warszawa, Poland
Email: A.erezinskaii.w.edu.l
Romuald Pilitowski
Institute oI Comuter Science Warsaw Universit oI
Technolog, ul. Nowowieska 1/19 00-66
Warszawa, Poland
18 PROCEEINGS O TE IMCSIT. OLUME 3, 2008
In the next section we discuss the related works. Next, the
U Iramework, eseciall solutions used Ior state machines
realization, will be resented. In Sec. I we introduce cor-
rectness issues identiIied in the transIormation rocess and
during execution oI state machines. Remarks about exeri-
ments erIormed and the conclusions Iinish the aer.
II. RELATE WOR
A huge amount oI research eIIorts is devoted to Iormaliza-
tion oI UML models, seciIication oI their semantics and
veriIication methods |9|-|13|. owever the are usuall not
resolving the ractical roblems which are Iaced while build-
ing an executable code, because oI man variation semantic
oints oI the UML seciIication.
An attemt Ior incororation oI diIIerent variation oints
into one solution is resented in |14|. The authors intend to
build models that seciI diIIerent variants and combine
them with the statechart metamodel. iIIerent olicies
should be imlemented Ior these variants.
Our work relates also to the Iield oI consistenc oI UML
models. The consistenc roblems in UML designs were ex-
tensivel studied in man aers. It could be mentioned
workshos co-located to the Models (Iormer UML) series oI
conIerences, and other works ||, |6|, |1|-|17|.
An interesting investigation about deIects in industrial
roects can be Iound in |18|. owever the stud takes into
account onl class diagrams, seuence diagrams and use case
diagrams, mostl the relations among elements Irom diIIer-
ent diagram tes. The state machines were not considered.
Solutions to consistenc roblems in class diagrams were
resented in |19|. The roblem reIers to constrains seciI-
ing generalization sets in class diagram, which is still not
commonl used in most oI UML designs.
Current UML case tools allow constructing incorrect mod-
els. The rovide artial checking oI selected model Iea-
tures, but it is not suIIicient iI we would like to create auto-
maticall a reliable alication. More comrehensive check-
ing can be Iound in the tools aimed at model analsis. or
examle, the OO design measurement tool SMetrics |20|
gives the rules according to which the models are checked.
We used the exeriences oI the tool (Sec. I), but it does not
deal with state machine execution nor with C language.
Man modeling tools have a Iacilit oI transIorming the
models into code in diIIerent rogramming languages. ow-
ever, the most oI them consider onl class models. We com-
ared Iunctionalit oI twelve tools that could also generate
code Irom state machines. Onl Iew oI them took into ac-
count more comlex Ieatures oI state machines, like choice
seudostates, dee and shallow histor seudostates, de-
Ierred events or internal transitions. The most comlete su-
ort Ior state machines UML 2.0 is imlemented in the
Rhasod tool |21| oI IBM Telelogic (Iormerl I-Logix).
owever it does not consider C language.
iIIerent aroaches to generation oI the code Irom be-
havioral UML models can be used. The semantics oI a state
machine can be directl imlemented in the generated code
|22|. Another solution is usage oI a kind oI a run-time envi-
ronment, Ior examle a run-time librar as alied in the
U Iramework.
The consistenc roblems remain also using tools Ior
building executable UML models |23|, |24|. iIIerent sub-
sets oI UML being used and we cannot assure that two inter-
changed models will behave in the same wa. SeciIication
oI a common subset oI UML secialized Ior execution is still
an oen idea.
III. COE GENERATION AN EECUTION IN U
TransIormation oI UML models into executable alica-
tion can be realized in the Iollowing stes.
1.A model, created using a CASE modeling tool, is ex-
orted and saved as an ML Metadata Interchange
(MI) Iile.
2.The model (or its arts) is transIormed b a generator
that creates a corresonding code in the target ro-
gramming language.
3.The generated code is modiIied (iI necessar), com-
iled and linked against a Runtime Librar. The Run-
time Librar contains realization oI diIIerent UML
meta-model elements, eseciall reIerring to behav-
ioral UML models.
4.The Iinal alication, reIlecting the model behavior,
can be executed.
It should be noted, that stes 1) and 2) can be merged, iI
the considered code generator is associated with the
modelling tool.
The rocess resented above is realized in the U
Iramework |7|. The target imlementation language is C.
The art oI UML model taken into account comrises
classes and state machines. The inut models are acceted in
UML2 Iormat, an MI variant suorted b Eclise.
ThereIore it is not directl associated with an modelling
tool. owever, all exeriments mentioned in Sec. were
erIormed with UML models created using IBM Rational
SoItware Architect |2|.
The U Iramework consists oI two comonents - U
Generator and U Runtime Librar. The Generator is
resonsible Ior realization oI ste 2. The U Runtime Li-
brar includes over Iort classes that corresond to diIIerent
elements oI UML state machines. It imlements the general
rules oI state machine behavior, indeendent oI a considered
model, e.g., rocessing oI events, execution oI transitions,
entering and exiting states, realization oI diIIerent seu-
dostates. It is also resonsible Ior the runtime veriIication oI
certain Ieatures oI an executed model.
TransIorming class models into C code, all model ele-
ments are imlemented b aroriate C elements. The
temlate oI a resulting rogramming class can be Iound in
|7|. Princiles oI code generation Irom the class models are
similar to other obect-oriented languages and analogues to
solutions used in other tools.
A distinctive Ieature oI U is dealing with all UML state
machine elements and their realization in C alication.
ThereIore we resent selected concets oI state machines
with their imlementation in C. We oint out diIIerent C
seciIic mechanisms used in the generated alication.
Using selected solutions we would like to obtain an eIIicient
and reliable alication.
ANNA EREINSA ET. AL.: CORRECTNESS ISSUES O UML CLASS AN STATE MACINE MOELS 19
State machines can be used at diIIerent levels oI
abstraction. The can model behavior oI an interIace, a com-
onent, an oeration. Protocol state machines are intended to
model rotocols. The rimar alication oI behavioral state
machine in an obect-oriented model is descrition oI a class.
A class can have attributes keeing inIormation about a cur-
rent state oI an obect. Classes have oerations that can trig-
ger transitions, send and receive events. ThereIore, we as-
sumed that the code will be generated and Iurther executed
onl Ior behavioral state machines that are deIined Ior cer-
tain classes that are resent in the structural model.
An exemlar UML model is shown in ig. 1. A given
class has an attribute, Iour oerations and its behavior seci-
Iied b a state machine. The state machine consists oI simle
state S1 and comlex state S2 including two orthogonal re-
gions. In guard conditions and triggers the oerations and at-
tribute oI the class are used. Extracts oI the C code corre-
sonding to the examle and created b the U generator
are given in the Aendix.
or an state machine oI a class, a new attribute oI
StateMachine te is created. Each class having a state ma-
chine has also two additional methods InitFXU and Start-
FXU. Method InitFXU is resonsible Ior creation and initial-
ization oI all obects corresonding to all elements oI state
machine(s) associated with the class, such as regions, states,
seudostates, transitions, activities, events, triggers, guards,
actions, etc. Method StartFXU is used Ior launching a behav-
ior oI state machine(s).
An state can have u to three tes oI internal activities
do, entrv, exit. The activities oI a state are realized using a
delegate mechanism oI C. Three methods DoBodv, Entrv-
Bodv and ExitBodv with emt bodies are created Ior an
state b deIault. II an activit exists a corresonding method
with its bod is created, using inIormation taken Irom the
model. Aling delegate mechanism allows deIining the
methods Ior states without using oI inheritance or overloaded
methods. ThereIore the generated code can be simle, and
generation oI a class Ior an single state can be avoided. A
state machine is not generated as a state design attern |26|,
because we would like to revent an exlosion oI number oI
classes.
Three transition kinds can be seciIied Ior a transition, ex-
ternal, internal and local transitions. Triggering an internal
transition imlies no change oI a state, exit and entr activi-
ties are not invoked. II an external transition is triggered it
will exit its source state (a comosite one), i.e. its exit activ-
it will be executed. A local transition is a transition within a
comosite state. No exit Ior the comosite (source) state will
be invoked, but the aroriate exits and entries oI the sub-
states included in the state will be executed.
A kind oI a transition can be seciIied in a model, but in
raxis this inIormation is rarel udated and oIten inaccu-
rate. ThereIore we assumed that in case oI comosite states a
kind oI generated transition is determined using a Iollowing
heuristics:
II the target state is diIIerent than the source state oI a
transition and the source state is a comosite state, the
transition is external.
Else, the transition is deIined in a model as internal it is
treated as an internal transition.
Otherwise, the transition is local.
A transition can have its guard condition and actions.
The are created similarl to activities in states, using dele-
gate mechanism oI C. II a bod oI an aroriate guard
condition or action is nonemt in a model, it is ut in the
generated code. It should be noted that veriIication oI logical
conditions written in C is ostoned to the comilation
time.
States, seudostates, transitions and events are created as
local variables. Signals are treated in diIIerent wa. The are
created as classes, because the can be generalized and se-
cialized building a signals hierarch. II a certain signal can
trigger an event also all signals that are its descendants in the
signal hierarch can trigger the same event. This Ieature oI
signals was imlemented using the reIlection mechanism oI
C |27|.
Events should have some identiIiers in order to be man-
aged. Change events and call events are identiIied b uniue
natural numbers assigned to the events. A time event is iden-
tiIied b a transition which can be triggered b this event. A
comletion event is identiIied b a state in which the event
was generated. inall, Ior a signal event the class oI the sig-
nal, i.e., its te, is used as its identiIier.
There are some elements oI a UML model that include a
descrition in a Iorm not recisel seciIied in the standard,
but deendent on a selected notation, usuall a rogramming

ig. 1 Examle - a class and its state machine
20 PROCEEINGS O TE IMCSIT. OLUME 3, 2008
language. There are, Ior examle, guard conditions,
imlementation oI actions in transitions or in states, bod oI
oerations in classes. The can be written directl in a target
imlementation language (e.g., C). uring code generation
these Iragments are inserted into the Iinal code. eriIication
oI the sntax and semantics oI such code extracts is er-
Iormed during the code comilation and execution according
to a selected rogramming language.
Interreting diIIerent concets oI state machines we can
use arallel execution. In the U RunTime Librar it is im-
lemented b multithreading. Multithreading is used Ior ro-
cessing oI man state machines which are active in the same
time, e.g., state machines oI diIIerent classes. It is used also
Ior handling submachine states and orthogonal regions work-
ing within states, and Ior other rocessing oI events. In the
Aendix, arts oI an outut trace generated during execu-
tion oI the exemlar state machine (ig. 1) are shown. We
can observe diIIerent threads, identiIied b number in brack-
ets, that were created to deal with encountering events. or
examle, realization oI transition Irom the seudostate Iork
to substate S3in S2 launched thread |11|. Thread |12|
was created to imlement transition Irom the Iork seu-
dostate to substate S1inS2. In other execution run oI the a-
lication the numbers and ordering oI threads can be diIIer-
ent.
Event rocessing during state machine execution is er-
Iormed according to the rules given in UML seciIication
|2|. Basic algorithms oI U realization, like execution oI a
state machine, entr to a state, exit Irom a state, were re-
sented in |7|. or ever state a ueue was imlemented that
ools incoming events. Events can be broadcasted or sent di-
rectl to the selected state machines. Events trigger transi-
tions that have an active source state and their guard condi-
tions evaluate to true. II man transitions can be Iired, transi-
tion riorities are used Ior their selection. We had roosed
and imlemented an extended deIinition oI transitions rior-
it, in order to resolve all conIlicts in case man transitions
can be Iired. This could not be achieved based onl on the
riorit deIinition given in |2|. The detailed algorithm oI se-
lecting non-conIlicting transitions can be Iound in |8|. Also
resolving oI other variation oints, eseciall dealing with
entering and exiting orthogonal states, is shown in |8|.
I. ERIICATION O MOEL CORRECTNESS
While generating valid C code Irom UML class and state
machine diagrams the certain conditions should be satisIied.
There are man ossible shortcomings resent in the models
that are not excluded b the modeling tools, or should be not
rohibited due to ossible model incomleteness at diIIerent
evolution stages. The were analzed taking into account the
ractical weaknesses oI model develoers.
The reared correctness rules were based on three main
sources: the seciIication oI UML |2|, the rules discussed in
related works and other comarable tools, in articular in
|20|, and Iinall the own stud, eseciall taking into ac-
count the Ieatures oI C language - the target oI the model
transIormation |27|.
arious shortcomings can be detected during diIIerent
stes oI alication realization (Sec. 3). Man oI them can
be identiIied directl in the model, and thereIore detected
during model to code transIormation ste (ste 2). eriIica-
tion oI such roblems will be called static, as it corresonds
to an automated insection oI a model. Other Ilaws are de-
tected onl during execution oI the resulting alication
(ste 4). Such dnamic veriIication will be comleted b the
aroriate classes oI the U Runtime Librar.
In tables I-III deIects identiIied in classes and state ma-
chines are resented. The last column shows severit associ-
ated to the shortcomings. Three classes oI severit are distin-
guished. II a deIect detected in a model is called as critical
the model is treated as invalid and the code generation is in-
terruted without roducing the outut. Later cases are clas-
TABLE I.
DEFECTS DETECTED IN UML CLASS DIAGRAMS (STATIC)
o Detected defects Reaction everity
1 A generalization oI an interIace Irom a class was detected Sto code generation critical
2 A name oI an element to be generated (e.g. a class, an interIace, an oeration,
an attribute) is a keword oI C language
Sto code generation critical
3 A class relates via generalization to more than one general class Sto code generation critical
4 A ccle in class generalization was detected Sto code generation critical
A name oI an element to be generated is missing Generate the element attern without its
name. The element name has to be
sulemented in the generated code.
medium
6 A name oI an element to be generated is not a valid C name. It is assumed
that white characters are so common shortcoming that the should be
automaticall substituted b an underline character.
As above medium
7 An interIace visibilit is private or protected . Use package visibilit . low
8 A class visibilit is private or protected . Use package visibilit . low
9 An interIace is abstract. Treat the interIace as no abstract. low
10 An interIace has some attributes. Ignore attributes oI the interIace. low
11 An interIace has nested classes Ignore classes nested in the interIace. low
12 A class that is no abstract has abstract oerations. Treat the class as abstract. low
ANNA EREINSA ET. AL.: CORRECTNESS ISSUES O UML CLASS AN STATE MACINE MOELS 21
siIied as medim and low. In both cases the code generation
is roceeded, although Ior medim severit it can reuire
corrections beIore comilation. In all cases inIormation
about all detected shortcomings is delivered to a user. A de-
tailed reaction to the Iound deIect is described in the third
column. While assigning severit levels and reactions to
given deIects we took into account general model correct-
ness Ieatures but also reuirements seciIic Ior C alica-
tions.
.Jerification of lass Models
Class diagrams describe a static structure oI a sstem,
thereIore man their Ieatures can be veriIied staticall beIore
code generation. Table I summaries deIects that are checked
during static analsis oI UML class models. It was assumed
that some imrovements can be added more convenientl in
the generated code than in a model. The class models can be
incomlete to some extend and we can still generate the
code. Admission oI certain model incomleteness can be
racticall ustiIiable because oI model evolution.
It should be noted that not all reuirements oI generated
code are checked b the generator. Some elements are veri-
Iied later b the comiler. It concerns eseciall elements
that are not directl deIined b the UML seciIication, like
the bodies oI oerations.
B.Jerification of State Machines
Similarl to class diagrams, diIIerent deIects oI state ma-
chines can be detected staticall in the models. The are
listed in Tab. II. Static detection oI shortcomings in state ma-
chines is realized twice. irst, it is made beIore model to
source transIormation (ste 2). Second correctness checking
is IulIilled beIore state machine execution. It is a art oI ste
4, during the initialization oI the structure oI a state machine.
or examle, a static veriIication can be illustrated using a
state machine Irom ig. 1. Transition outgoing state S3inS
has an event trigger - calling oI an oeration finishoper().
owever, this transition targets the oin seudostate. There-
Iore neither a trigger nor a guard condition can be associated
with the transition. It violates the correctness rule 18 (Tab.
II). This model Ilaw is uite oIten and is not critical. The
TABLE II.
DEFECTS DETECTED IN UML STATE MACHINES (STATIC)
o Detected defects Reaction everity
1 A ccle in signal generalization was detected Sto code generation critical
2 A signal inherits aIter an element that is not another signal Sto code generation critical
3 A signal relates via generalization to more than one general signal Sto code generation critical
4 A region has more than one initial seudostate Sto code generation critical
A state has more than one dee histor seudostate or shallow histor
seudostate
Sto code generation critical
6 There are transitions Irom seudostates to the same seudostates (diIIerent
than a choice seudostate)
Sto code generation critical
7 There are imroer transitions between orthogonal regions Sto code generation critical
8 A transition trigger reIers to an nonexistent signal Sto code generation critical
9 An entr oint, oin or initial seudostate has no incoming transition or more
than one incoming transition
Sto code generation critical
10 A dee or shallow histor seudostate has more than one outgoing transition Sto code generation critical
11 A transition Irom an entr/exit oint to an entr/exit oint Sto code generation critical
12 An exit oint has no an incoming transition Sto code generation critical
13 Transitions outgoing a Iork seudostate do not target states in diIIerent regions
oI an orthogonal states
Sto code generation critical
14 Transitions incoming to a oin seudostate do not originate in diIIerent regions
oI an orthogonal state
Sto code generation critical
1 There is a transition originating in an initial seudostate or a dee/shallow
histor seudostate and outgoing a nested orthogonal state
Sto code generation critical
16 The region at the tomost level (region oI a state machine) has no initial
seudostate
Warn a user medium
17 A transition outgoing a seudostate has a trigger Ignore the trigger medium
18 A tgransition outgoing a seudostate (diIIerent Irom a choice or unction
vertex) has a nonemt guard condition
Ignore the guard condition medium
19 A transition targeting a oin seudostate has a trigger or nonemt guard
condition
Ignore the trigger and/or condition medium
20 A trigger reIers to a non-existing oeration The transition will be generated but it
cannot be triggered b this event
medium
21 A trigger reIer to an abstract oeration or to an oeration oI an interIace as above medium
22 A time event is deIerred Treat the event as not being deIerred medium
23 A Iinal state has an outgoing transition Warn a user medium
24 A terminate seudostate has an outgoing transition Warn a user low
22 PROCEEINGS O TE IMCSIT. OLUME 3, 2008
trigger will be omitted in the generated code and the designer
will be warned about this exclusion.
State machines model sstem behavior thereIore not all
their elements can be staticall veriIied. A art oI deIects is
detected dnamicall, i.e., during execution oI state ma-
chines. or examle, a situation that two enabled transitions
are outgoing the same choice seudostate can be detected aI-
ter evaluation oI aroriate guard conditions, namel dur-
ing rogram execution. eIects detected dnamicall in state
machines are resented in Tab. III.
. EPERIMENTS
The resented aroach Ior building the C code and exe-
cuting the automaticall created alications was tested on
over IiIt models. The Iirst grou oI ten models was aimed at
classes. In exeriments the correct and incorrect construc-
tions encountering in class diagrams were checked, concern-
ing eseciall association and generalization. Moreover, two
bigger roects were tested. The Iirst one was a art oI MA
roect called Acceleo |28|. The model described a design oI
a web age. The second one resented a metamodel oI an
obect-oriented modeling language |29|.
Models Irom the next grou (above Iort models) com-
rised diIIerent diagrams, including both classes and state
machines. All ossible constructs oI UML 2.x state machines
were used in diIIerent situations in the models. The biggest
design included Iive state machines with about 80 states and
110 transitions, using comlex and orthogonal states, diIIer-
ent kinds oI seudostates and submachine states.
The rograms realizing state machines were run taking
into account diIIerent seuences oI triggering events. The
behavior modeled b state machines was observed and veri-
Iied using detailed traces generated during rogram runs.
The heled to test whether the obtained rogram behavior
conIorms to desired state machine semantics. or comlex
models, Iiltered traces that included selected inIormation
were also used.
The erIormed exeriments have showed that an alica-
tion realizing a behavior seciIied in state machine models
can be develoed in an eIIective and reliable wa.
CONCLUSION
In this aer we discussed the roblems oI creation oI
valid C alications realizing ideas modeled b classes and
their state machines. iIIerent C mechanisms were eIIec-
tivel used Ior imlementation oI the Iull state machine
model deIined in the UML 2.x seciIication. We showed
which correctness issues oI models have to be checked dur-
ing model transIormation (static veriIication) and during a-
lication execution (dnamic veriIication). The detailed cor-
rectness rules hel a develoer to coe with ossible Ilaws
resent in UML models. In the diIIerence to other tools, us-
ing U the state machines including an comlex Ieatures
can be eIIectivel transIormed into corresonding C ali-
cation. The tool suort seeds u building oI reliable ali-
cations including comlex behavioral seciIications. It can
be eseciall useIul Ior develoing rograms in which non-
trivial state machines are intensel used, e.g., deendable
sstems, embedded reactive sstems.
APPENI
The aendix includes extracts oI C code generated Ior
an exemlar class and its state machine shown in ig. 1.
Code oI class oerations are omitted (line 3). Method Init-
Fx() creates aroriate structure oI the state machine.
Method StartFx() initializes behavior oI the state machine.
1 public class A_class {
2 private int x_attrA;
3 // operations of A_class (omitted)
4 StateMachine sm1 new
StateMachine(OwnedStateMachine1);
5 public void nitFxu(){
6 egion r1 new egion(egion1);
7 sm1Addegion(r1);
8 nitialPseudostate v2 new
nitialPseudostate();
9 r1AddVertex(v2);
10 FinalState v3 new FinalState();
11 r1AddVertex(v3);
12 State v4 new State(S1);
13 v4EntryBody delegate(){ init_x(); };
14 r1AddVertex(v4);
15 State v5 new State(S2);
16 v5DoBody delegate(){ work_operA(); };
17 r1AddVertex(v5);
18 egion r2 new egion(egion1);
19 v5Addegion(r2);
20 egion r3 new egion(egion2);
21 v5Addegion(r3);
22 State v6 new State(S2_inS2);
23 v6EntryBody delegate()
{SystemThreadingThreadSleep(10000); };
24 r2AddVertex(v6);
TABLE III.
DEFECTS DETECTED IN UML STATE MACHINES (DYNAMIC)
o Detected defects Reaction everity
1 There is no enabled and no else transition outgoing a choice or unction
seudostate
Susend execution - terminate critical
2 A dee or shallow histor seudostate was entered that has no outgoing
transitions and is emt, i.e. either a Iinal state was a last active substate or
the state was not visited beIore
Susend execution - terminate critical
3 More than one transition outgoing a choice or unction seudostate is enabled Select one enabled transition and ignore
the others
medium
4 There is no enabled transition outgoing a choice or unction seudostate and
there is one or more else transition outgoing this seudostate
Select onr else transition and ignore
other transitions
medium
More than one transition outgoing the same state is enabled Select one transition and ignore the
others
medium
ANNA EREINSA ET. AL.: CORRECTNESS ISSUES O UML CLASS AN STATE MACINE MOELS 23
25 State v7 new State(S1_inS2);
26 r2AddVertex(v7);
27 State v8 new State(S3_inS2);
28 r3AddVertex(v8);
29 Fork v9 new Fork();
30 r1AddVertex(v9);
31 FinalState v10 new FinalState();
32 r1AddVertex(v10);
33 Join v11 new Join();
34 r1AddVertex(v11);
35 Transition t1 new Transition(v2, v4);
36 Transition t2 new Transition(v4, v9);
37 t2GuardBody delegate(){return x_attrA>0;};
38 Transition t3 new Transition(v4, v10);
39 t3GuardBody delegate(){return x_attrA<0;};
40 Transition t4 new Transition(v6, v11);
41 Transition t5 new Transition(v7, v6);
42 t5AddTrigger(new CallEvent(suspend_operA,
1));
43 Transition t6 new Transition(v8, v11);
44 t6AddTrigger(new CallEvent(finish_operA,
2));
45 t6ActionBody delegate(){finish_operA(); };
46 Transition t7 new Transition(v9, v8);
47 Transition t8 new Transition(v9, v7);
48 Transition t9 new Transition(v11,v3);
49} //End of nitF
50 public void StartFxu()
51 { sm1Enter(); }
2
ragments oI a detailed execution trace oI the exemlar
state machine (ig. 1) are shown below. Time stams oI all
log items are omitted Ior the brevit reasons. The trace was
created under condition oI two call events occurrences, sus-
endoerA() and IinishoerA(). A number in brackets de-
notes a number oI a thread that realizes a considered art oI
machine execution.
|1| WARN - State diagram OwnedStateMachine1: Entered.
|1| INO - State diagram OwnedStateMachine1: Execution oI
entr-activit started. State is now active.
|1| EBUG - State diagram OwnedStateMachine1: Execution oI
entr-activit Iinished.
|7| INO - Initial seudostate OwnedStateMachine1::
Region1::UnNamedertex: Entered.
|7| EBUG - Transition Irom Initial seudostate OwnedStateMa-
chine1::Region1::UnNamedertex to State OwnedStateMa-
chine1::Region1::S1: Traversing started.
|7| INO - State OwnedStateMachine1::Region1::S1: Execu-
tion oI entr-activit started. State is now active.
(...) //art omitted
|3| EBUG - State diagram OwnedStateMachine1: Comletion
event generated b State OwnedStateMachine1::Region1::S1
has been disatched.
|9| EBUG - State OwnedStateMachine1::Region1::S1: Execu-
tion oI exit-activit started.
|9| INO - State OwnedStateMachine1::Region1::S1: Execu-
tion oI exit-activit Iinished. State is now inactive.
|10| EBUG - Transition Irom State OwnedStateMachine1 ::Re-
gion1::S1 to ork OwnedStateMachine1::Region1 ::UnNamed-
ertex: Traversing started.
|10| INO - ork OwnedStateMachine1::Region1 ::UnNamed-
ertex: Entered.
|11| EBUG - Transition Irom ork OwnedStateMachine1 ::Re-
gion1::UnNamedertex to State OwnedStateMachine1:: Re-
gion1::S2::Region2:: S3inS2: Traversing started.
|11| INO - State OwnedStateMachine1::Region1::S2: Execu-
tion oI entr-activit started. State is now active.
|11| EBUG - State OwnedStateMachine1::Region1 ::S2: Exe-
cution oI entr-activit Iinished.
|13| INO - State OwnedStateMachine1::Region1::S2: Execu-
tion oI do-activit started.
|13| EBUG - State OwnedStateMachine1::Region1 ::S2: Exe-
cution oI do-activit Iinished.
|11| INO - State OwnedStateMachine1::Region1::S2::
Region2::S3inS2: Execution oI entr-activit started. State is
now active.
|11| EBUG - State OwnedStateMachine1::Region1:: S2::Re-
gion2::S3inS2: Execution oI entr-activit Iinished.
|12| EBUG - Transition Irom ork OwnedStateMachine1 ::Re-
gion1::UnNamedertex to State OwnedStateMachine1:: Re-
gion1::S2::Region1::S1inS2: Traversing started.
|12| INO - State OwnedStateMachine1::Region1::S2::
Region1::S1inS2: Execution oI entr-activit started. State is
now active.
(...) //art omitted
|3| EBUG - State diagram OwnedStateMachine1: Comletion
event generated b State OwnedStateMachine1
::Region1::S2::Region2::S3inS2 has been disatched.
|3| EBUG - State diagram OwnedStateMachine1: Comletion
event generated b State OwnedStateMachine1
::Region1::S2::Region1::S1inS2 has been disatched.
|3| EBUG - State diagram OwnedStateMachine1: Call-event
susendoerA |I1|. has been disatched.
|16| EBUG - State OwnedStateMachine1::Region1:: S2::Re-
gion1::S1inS2: Execution oI exit-activit started.
|16| INO - State OwnedStateMachine1::Region1::
S2::Region1::S1inS2: Execution oI exit-activit Iinished. State
is now inactive.
|17| EBUG - Transition Irom State OwnedStateMachine1 ::Re-
gion1::S2::Region1::S1inS2 to State OwnedStateMachine1
::Region1::S2::Region1:: S2inS2: Traversing started.
|17| INO - State OwnedStateMachine1::Region1::S2::
Region1::S2inS2: Execution oI entr-activit started. State is
now active.
|17| EBUG - State OwnedStateMachine1::Region1 ::S2::Re-
gion1::S2inS2: Execution oI entr-activit Iinished.
|18| INO - State OwnedStateMachine1::Region1::S2
::Region1::S2inS2: Execution oI do-activit started.
|3| EBUG - State diagram OwnedStateMachine1: Call-event
IinishoerA |I2|. has been disatched.
(...) //art omitted
|22| INO - oin OwnedStateMachine1::Region1 ::UnNamed-
ertex : Entered.
|22| EBUG - Transition Irom oin OwnedStateMachine1:: Re-
gion1::UnNamedertex to inal state
OwnedStateMachine1::Region1::UnNamedertex: Traversing
started.
|22| INO - inal state OwnedStateMachine1::Region1 ::Un-
Namedertex: Entered.
|22| WARN - State diagram OwnedStateMachine1: Exiting.
REERENCES
|1| R. rance, B. Rume, Model-driven eveloment oI Comlex SoIt-
ware: A Research Roadma in uture oI SoItware Engineering at
ICSE07, IEEE Soc., 2007, . 37-4.
|2| OMG UniIied Modeling Language Suerstructure v. 2.1.2, OMG
ocument Iormal/2007-11-02, 2007, htt://www.uml.org
|3| MA Guide, er. 1.0.1, Obect Management Grou ocument omg/
2003-06-01, 2003.
|4| S. rankel, Model riven Architecture: Aling MA to enterrise
comuting. Wile Press, oboken, N, 2003.
|| A. Baruzzo, M. Comini, Static veriIication oI UML model consis-
tenc, roc. of the 3rd Workshop on Model DEvelopment, Jalida-
tion and Jerification, co-located. at MoDELS06, Genoa, Ital, 2006,
. 111-126.
|6| C. Lange, M. R. . Chaudron, . Muskens, L. . Somers and
. M. ortmans, An emirical investigation in uantiIing inconsis-
24 PROCEEINGS O TE IMCSIT. OLUME 3, 2008
tenc and incomleteness oI UML designs, in Proc. oI
nd
Workshop
on onsistencv roblems in UML-based Software Development co-
located atUML03 onf. , San rancisko, USA, Oct 2003, . 26-34.
|7| R. Pilitowski, A. erezinska, Code Generation and Execution
ramework Ior UML 2.0 Classes and State Machines, in: T. Sobh
(eds.) Innovations and Advanced Techniues in Comuter and
InIormation Sciences and Engineering, Sringer, 2007, . 421-427.
|8| erezinska, R. Pilitowski, Event Processing in Code Generation and
Execution ramework oI UML State Machines, in L. Madeski, M.
Ochodek, . Weiss, . endulka (eds.) SoItware Engineering in
rogress, Nakom, Pozna, 2007, .80-92.
|9| arel, . ugler, The Rhasod Semantics oI Statecharts (or On the
Executable Core oI the UML) (reliminar version), in SoItSez
inal Reort, LNCS, vol. 3147, Sringer, eidelberg, 2004, .
32-34.
|10| STL: UML 2 Semantics Proect, ReIerences, ueens Universit
htt://www.cs.ueensu.ca/home/stl/internal/uml2/reIs.htm
|11| M. Crane, . ingel, UML vs. Classical vs. Rhasod Statecharts:
Not All Models are Created Eual, in: MoELS/UML 200, LNCS,
vol. 3713, Sringer, eidelberg, 200, . 97-112.
|12| . in, R. Esser and . W. anneck, A Method Ior escribing the
Sntax and Semantics oI UML Statecharts, SoItware and Sstem
Modeling, vol. 3 no 2, Sringer, 2004, . 10-163.
|13| . echer, . Schnborn, UML 2.0 state machines: Comlete Iormal
semantics via core state machines, in MICS and PMC 2006,
LNCS vol. 4346, Sringer, ildelberg, 2007, . 244-260.
|14| Chauvel, -M. ezeuel, Code Generation Irom UML Models with
Semantic ariation Points, in MoELS/UML 200, LNCS, vol.
3713, Sringer, eidelberg 200, . 97-112.
|1| A. Eged, ixing inconsistencies in UML designs, in Proc. oI 29th
Intern. ConI. on SoItware Engineering, ICSE07, IEEE Com. Soc.,
2007.
|16| S. Prochanow, R. von anxleden, Statecharts develoment beond
WSIWIG, in G. Engels et al. (Eds.) MOELS 2007, LNCS 473,
Sringer, Berlin eidelberg, 2007, . 63-649.
|17| a L-., ang B-W., Meta-alidation oI UML Structural iagrams
and Behavioral iagrams with Consistenc Rules, Proc. oI IEEE
PaciIic Rim ConI on Communications, Comuters and Signal
Processing, PACRIM,ol. 2., 28-30 Aug. (2003) 679-683.
|18| . . Lange, M. R. . Chaudron, eIects in industrial UML models -
a multile case stud, roc. of the nd Workshop on Qalitv in
Modeling, co-located. at MoDELS07, Nashville, TN, USA, 2007, .
0-64.
|19| Maraee, M. Balaban, EIIicient decision oI consistenc in UML
diagrams with constrained generalization sets, in , roc. of the 1st
Workshop on Qalitv in Modeling, co-located. at MoDELS06,
Genoa, Ital, 2006, . 1-14.
|20| . Wuest, SMetrics - the UML design measurement tool,
htt://www.sdmetrics.com/manualLORules.html
|21| Rhasod, htt://www.telelogic.com/ (2008)
|22| A. Niaz, . Tanaka, Maing UML Statecharts into ava code, in
Proc. oI the IASTE Int. ConI. SoItware Engineering, 2004 , .
111-116.
|23| S. . Mellor, M. . Balcer, Executable UML a oundation Ior Model-
riven Architecture, Addison-Wesle, 2002.
|24| . Carter, iUMLite - xUML modeling tool, htt://www.kc.com
|2| IBM Rational SoItware Architect, htt://www-306.ibm.com/soItware/
rational
|26| E. Gamma, R. elm, R. ohnson, . lissides, Design patterns. ele-
ments of resable obfect-oriented software, Boston Addison-Wesle,
199.
|27| . Libert, Programming C, OReill Media, 200.
|28| Acceleo roect htt://www.acceleo.org
|29| Booch, Metamodel oI obect-oriented modeling language,
htt://www.booch.com.architecture