=Paper=
{{Paper
|id=Vol-252/paper-9
|storemode=property
|title=Deriving prototypes from UML 2.0 sequence diagrams
|pdfUrl=https://ceur-ws.org/Vol-252/paper09.pdf
|volume=Vol-252
|dblpUrl=https://dblp.org/rec/conf/isim/HuzarL07
}}
==Deriving prototypes from UML 2.0 sequence diagrams==
https://ceur-ws.org/Vol-252/paper09.pdf
Deriving prototypes from UML 2.0 sequence
diagrams
Zbigniew Huzarr and Grzegorz Loniewskil
Institute of Applied Informatics, Department of Computer Scicncc and Managcmcnt,
Wroclaw Univcrsity of Technology, Poland
zbigniew. huzar@pwr . wroc . p1, grzegorz . l-oniewski@student . plrr . wroc . pI
Abstract. Executable prototypcs generatcd on early stages of software
development bring many benefits, first of all they help to develop and
validate systcm's spccification. The paper prcsents an approach to au-
tomatic systcm prototype generation based on a collection of UML 2.0
scquerrce diagrams. In thc approach a set of sequcnce diagrams rcpresent-
ing behavior of a specified systenr is transforrned into a state machirre
and next a Java code is generated for the state machine. Thc trarrs-
formatiorm arc described inforrnally by presentation of simplc examples.
Architecture of the system implementing the transformation is briefly
describcd.
Keywords: Sequence diagram, statc machine, prototype,
code gcncration
Introduction
Sequencediagrams are verv often used as behaviour specification of developed
systcrrs. Thcy becorne very popular with advcnt of the UML specification lan-
guagc. UML scquence diagrams were adopted from messagesequencecharts that
wcre known already in other visual languages developed long ago by the Interna-
tional Telecommunication Union. UML 2.0 also uses other diagrams to specify
bchaviour, e.g. communication and collaboration diagrams. All those diagrams
express similar all,hough not, identical information and show il, in a way dillerent
from thc sequence diagrams. Sequcnce diagrams arc used to specify scenarios as
sequences of messagespassing betwcen objects. A sequence diagram represents
an interaction - a sct of communications among objects arranged visually in time
order. They can exist in a descriptor form (describing all possible scenarios) and
in an instance form (describing onc actual scenario). In thc paper wc deal with
an instancc form only.
Scquencediagrams have some practical limitations. Neverthclcss, they are used
at vcry early stage of softwarc development for rapid but usually partial speci-
fication of systern's bchaviour. For devclopers the most important factor should
be quick validation of systetn's behaviour defined by a given set of sequencedi-
agrams. Scquencc diagrams still have an informal scmantics, therefore the most
74 Z. Huzar and G. Loniewski
effective way of such a validation is generabing system prototype and next its
intensive testing.
The aim of the paper is prcsentation of an approach [3] to generating the system
prototype on the basis of a set of sequence diagrams. The paper is organized
as follows. Section 2 explains our definition of software systcm specification. In
Section 3 the algoribhm transforming such a specification into a state machine is
described. Scction 4 outlincs the structure of a programming system generating
prototypes, and describes generation of Java code. Thc last Section 5 evaluatcs
the obtained results and points out some future works.
2 Systems specification
Spccification of a system consists of two parts I7lt8]
The first one representing static aspect of the system, consists of two elements:
a class diagram and an object diagram. The class diagram reflects the set of po-
tential configuratioru of thc system - a sct of linked objects. The object diagraur
ref'ers to an initial configuration of the system.
The second one represents dynamic aspect of the system and includes a set SD
of sequencediagrams. The set is partially ordered by relation (, which is dcfirred
as follows: for sd1,sd2 € SD, sd1 1sd2 mcans that interaction represented by
sd1 should occur beforc interaction rcpresentedby sd2.
The dynamic part strould be consisteut with static part of the specification. It
entails that each scquencediagram should bc consistent with class diagram, i.c.
the objccts that appcar in the scquencediagram are to be elemcnts of an object
diagram bcing an instance of the class diagram. At least one sequcnce diagram
should act in accordancc with the initial object diagram.
Wc use UML 2.0 sequencediagrams [6] with the following restrictions:
- only asynchronous messagesare allowed,
- combined fragments only with three main operator typcs: alt, loop and
strict.
Additionally, to rnaintain consistencyof the specification the following conditions
should be hold:
- objects belonging to the initial object diagram are not crcated on nonc of
scquencediagrams,
- othcr objects may be created only once via create operation and on one of
the sequencedia,grarrts,otherwise they a,reconsideredto be different objects,
- objects and their messagcscan not cause inconsistencies,e.g. they have to
keep thc time ordering resulting from objects creations and destructions
times,
- at lcast one guard condition in a combined fragmcnt should always be ful-
filled,
- conditions in ncstcd combined fragmcnts should not be contradictory.
Spccification exa,mplc is presented in Fig. 1. The oval areas on thc figure
that reprcscnt some objects' activities will be used further to explain the idea of
scquence diagrams transformations.
Deriving Prototypesfrom UML 2.0 SequenceDiagrams 75
-l
l-,* l--e I
l.iil. t- uc rrn.eioii'r.-lir : ..
[ . !|!9 9t3!o I
l:'-:l*:*-:::"J -- -
---
tc=f . o1
tl ''
Fig. 1. Example of a sequence diagram
3 TYansformation of sequence diagrams into state
machines
Deriving of system prototype consists of two phases: first a state machine is
crcatcd and next Java codc is generatcd. The transformation of a set of scquence
diagrams into a single state machine should prescrve determinism as well as
consistency. The transformation works in the following steps:
- F-or each sequencediagram from the given specification and for each object,
on this diagram a state machine is gencrated. Thc machine represents a
fragmcnt of behaviour of thc classto which the object belongs. The machines
arc rcpresentcd in form of UML statecharts.
- Thc state machines gcnerated for the same class instances appearing on
different scquence diagrams are rnerged into a single, global state machinc.
The merging has to maintain transitions bctween statcs located on each of
compositc machinc. States of the whole system are reprcsented by states of
the global state machine.
- The sct of states of thc resulting state machine is minimized.
The idea, of the first step of the tra,nsforma,tionis expla,ined fbr the speci-
fication example from the previous section. Messageson the sequencediagram
which can change the object statc are recognized. It is assumed that only re-
ceiving evcnts on the object lifeline may causc changing of its state. The areas
between marked messages (oval areas in Fig. 1.) are distinguished and states
from these arcas are derived.
Incoming mcssagesbecome cvents triggering transitions between states, whereas
the outcoming messagesbecome actions cxecuted as entry actions of a particular
state. There are also other sequencc diagram elements that produce new states
like statc invariant (e-transition, i.c. internal transition, with state invariant con-
ditionr), and combined fragment (for object that begins the interaction within
Tt"t" t"""ttarrt condition - an interaction may be continued by thc object provided
if the state satisfiesthe invariant condition
76 Z. Huzar and G. Loniewski
Statc mchine for olrject ,/A" State lmchlne for object ,.C"
OI O
I
a'----go-'--'1 r***5-d-\
I
t..;t;;;ii;i ) i;;ffi;;t
-----;T-
.{corldftion-trugl/ \.11co^dition-falsel
/..
. . . . . . . . . . . - . . 2 . . - . . . ........ 1 . . .
\"4
r' .....9.r.....t {..-.-.....ql' .: sr. i
I entryre4,i
---f - - -* f-eiiilt;.7"-:
leG
1 ..
." /
[ '.---\ "t )
,/ /.t'
e-( \
t t
isa"i
t.,
_l
Fig.2. Example statecharts for derived from sequencediagram
the fragment c-transition with opcrand condition for other objects taking part
in thc combined fragment interaction new statcs triggercd by a proper events).
Statecharts created by thc algorithm possessonly simple states (simple - in sense
of UML statecharts), and therefbre they are called flat statecharts. Example of
state machines generated out of a given scenario from Fig. f . is shown in Fig. 2.
Thc sccond step of the transformation merges state machines representing
behaviour of the same class. The transformation has to maintain partial ordering
between statc machines which results from sequcnce diagrams.
The state machine for a given class is constructed as follows. First, the state
machine derived from a scenario which posscsscsobjects in their default states
(i.e. objects belonging to the initial object diagram) is taken as an initial state
machine. Second, othcr state machines are attachcd to the initial one. The syn-
thcsis proceeds as follows. At the beginning equivalence betwccn initial states of
the initial state machine and the joining state machine is examined.
If state machines can not bc joined by their initial statcs system looks for other
states in thc initial state machine that arc similar to the initial state of the
mcrgcd machine. If there are two cquivalent states2 and joining thcm will not
cause indetcrminist situation a synthcsis decision can be taken.
Howcvcr, a situation whcn no merging state has bccn found might occur. In
such a casc a new transition betwccn the initial state of the initial state ma-
chine and thc initial state of the merging state machine is addcd and marked
as )-transition3. This sort of transition can be cxccuted if no other transitions
are triggered and user will decide to continue the prototype execution with the
)-transition path. Two state machincs merging procedures of aforementioned
description are shown on simple examples in Fig. 3.
2
states described by equal attributes valucs of the corresponding class and equal set
of executirrg actions
" )-transition - transitiorr triggered only by the user decision about execution path
no othcr transitions are possiblc
Deriving Prototypesfrom UML 2.0 SequenceDiagrams 77
l'i1 c)
-.
ti4lU|'1? |i]1UId? fti1U|'42
1..,r.T-
;-i
.el
sr ,
e?
g I
---,-
*l''l sr .5
'_--.-'-r 51 t--e.{r z?z
f'llllf ' , . . . . . \e t
'' -\
a*, S0 l-->iS1S0'j f-'i s0.l
,i..iir)-i
Cl ."---_\
-a'
hi s0''-'-->i t ^ ' : ,
sI
a l
l--| e1'\;l_q -*l'
-::,' i t el " - --', -.9!,
l-l-i--*'i-u,
M2
Fig. 3. State machine synthcsisproccss:
A) initial statc machincsM1 and M2;
B) rncrging through equivalerrtinitial srares;
C) rrrergingthrough equivalerrtstates (state machinesordcrcd);
D) rnerging by adding ncw )-transition
The third step of transformation is thc minimization process.State machines
generated fbr objects on the base of different sequence diagrarns may possess
similar states. Such states are derived from identical interactions which wcre
located on different sequence diagrams. For that reason applying the concept
of iritera,ction use is recornmended. When creating system specification sirnilar.
interactions can be dcsigned on a separate scquencc diagram. Synthesis proccss
docs not dcal with removing similar states. To improve the state machinc effi-
ciency rcdundant statcs should be removed but still maintaing the statc machinc
deterministic.
4 Code generation and system design
Codc generation out of statechart diagrams is based on the following schema:
- state is transformcd to a class wherc its behaviour consists of methods
de-
rived from actions that state activity consists of,
- cvents and rcspectivc actions are transformed into method calls,
- for each class a statc variable indicating current state of its instances
is
implemcnted; assignments of that statc variable corrcspond to transitions
from a statc machine,
- transitions conditions are convertcd into if-else statemcnts in gcneratcd
event
methods, etc.
Gathering of a bchaviour associated with a single state and its encapsulation in
one class is an idea taken from state design pattern [5] of which created system
makes use. It gives flexibility while performing some changes in specification
(st,at,esact,ivities) which result,sin code modifications. State dcsign patt,ern also
provides the architccture of Java classcs.
UML state machines and Java programming language are based on different con-
cepts. For that reason code gcneration is not an casy, straightforward mapping
of statc machine elements into thc codc. Howcver, object-oriented programming
and dcsign patterns enable gencration the code skeleton of executable prototype.
18 Z. Huzar and G. Loniewski
,..s--!3!-e-..............
..
. sta!.9- . - , c)rlntext conte"ti....................
| + abstract void entry(): l
: ...
.:l
,t st o_ - . - . . , I
tI l l
I *+s o o ;
t-- 5i
t..--
|
I l"stt):
.. . .. ......1.........
Ir I .
- - *-------- llS
---'- --1 i'
f--------
ll*st't)'
l
. - . 1 - . _ ,t i _s-a-
-- -- : t s 2
| t- ---------" ', llr
| . s2(); I s30;
'l
I voidentryO: I | " void entryO. I i . vordentry0. I + void enrry0t I i + void entry(j
uoi':er (): r I | + vDid e70:
+
i | void eg(i:
I
I" i I void e40;
Li | .---"-,d-:-911i I I : -*11::o,!1,
I l
i 1..................................
J i l
Fig. 4. Exarnplc of classes structure based on state pattern
An cxample of such a skeleton for the state machinc for object "Att from Fig.
2., is shown in Fig. 4.
Mcthods deriving from state transitions are implcmented as follows:
public void transitionMethodO throws Exception {
if (condition == TRUE) {
executeStateTransition ( ) ;
) else {
throw new ExceptionO i
)
);
Testing condition in if-else statement is derivcd from a transition condition.
If satisfied the transition is executed, otherwisc an exception arises.
On the basis of above mcntioned code generation and transformations rules,
systcm for prototypes automatic gcneration was created[S]. It gets as an input
system specification and produces executablc Java code a^san output. Function-
ing of the system described by UML activity diagram is presented in Fig. 5.
Each action from the activity diagram corresponds to a system modulc. These
modulcs work in a cascadc each of which taking as its input the output of the
previous module demonstrates the data flow on demonstrated acbivity diagram.
The system includes also a graphical user interface for sequencc diagrams creat-
ing and cditing.
iad Systdan worktlow
\/t _-,,_ /-
i s!qu.nc. I
idlagroms lhta
I xML rr.hrliriol
___,1
Fig.5. System workflow activity diagram
Deriving Prototypesfrom UML 2.0 SequenceDiagrams 79
All the neccssary data present during its transformation process is storcd in XMI
format. This enablcs exchanging the specification information with other UML
modclline tools.
D Summarv
Thc main motivation for automatic prototype generation is constructing a sys-
tem that supports developing proccss in software. First of all, cxecutablc proto-
tvpe enables validal,ion of a specificat,ionon a preliminary st;ageof the project.
Additionally, it provides the first vision of the developed systern that can bc fur-
ther expanded and modified. It can also help project managers in project time
estimations.
The systetr presented in the paper was tested by a set of simple specification
examples. It appears that current version of the system may be effectively used
onlv for non-complex specifical,ions.This is not causcd bv the transformat,ion
algorithm that may cope with the system complexity but by clarity of generatcd
codc skeleton. The skeletons in prcsent forms are not easy for extension or mod-
ification as their stmcture reflccts final, rninirnally intcgrated state machine but
thcre is not clear tracing to sequence diagrams or component state machines -
machines rcpresenting individual classes.Solution of this discrepancy seems to
be possible by another structuring of state machine intergration.
In addition it seems that within future works thc system may be cnhanccd by
new functionalities. Hcre arc cxamplcs of issues worth to be considercd:
- Providing systern input not only with behavioural specification but also wittr
prototype structurc skeleton. Applied in created system state pattern for
structuralizing the implementation is clear to understand but lack of readable
class structure leads to illegibility of gencrated code. Providing the systcm
with additional information about prototype architecturc can facilitate its
furthcr expansion or rrrodification.
- Such systcm should havc a testing module which aftcr generation
of the
final state machine will test its correctnessregarding all the execution paths
located on the scenarios provided as system input. On thc basis of that
module Java unit testing proccdures can be created in order to ensure that
generating based on statc machines code executes properly as designed on
sequence diagrams.
- Thc idea of expanding the system with gencrating graphical user interfacc
can be taken into account. In [1] exists an approach of describing GUI by
sequcnce diagrams. That work shows the power of UML sequence diagrams
in describing systems complete specificaLions.
- Other idea is taking into consideration synchronous messagesin
the system
specification. This approach allows only asynchronousmessageswirich uncler
certain assumptions facilitates thc algorithm of constructing state machines.
Objects synchronization is not necessary assuming that all objects are in
proper states to receive messages from other objects (cspecially important
when entering combined fragments).
80 Z. Huzar and G. Loniewski
'Ihere
are also other mebhods that use sequence diagrams fbr specification of
devcloped systcms. Within them construction of state machine and further code
generation often rely either on specification of additional assumptions or on a
dialog with thc system uscr providing ad hoc decisions. Such complctc system
(SCtrD) is prcsented in [2]. Morcover, to facilitate thc process ccrtain notation
bcsides thc UML standard is frequently used.
Whittlc and Schumann in their work [9] make the most of OCL for messages
pre- aud post-conditions which makes thc specification creation process rnuch
morc intricatc. An algcbraic approach prcscnted by Ziadi, Helouct and Jezcquel
in [10] cxpects that not only particular scenarios are dcscribed, but also one
scquence diagram that collects and shows the connections between all other sce-
narios provided. In fact the final state machine is transformed from one sequence
diagram. This is again the kind of user limitation to be applicd when prcparing
system specifica,tion.Arrothcr statechart gencra,tionbasing on sequencediagrams
is presentcd by Makinen and Systa in MAS project [a]. This approach proposcs
intcraction with user in accepting or rcjecting generated state machines.
One of the aims of this work was making the system as self-reliant as possible
which is to effect in limiting the system interaction with the user to the min-
imum, at the same timc being in full compliance with the UML 2.0 notation
standard.
References
1. P. Biecek and Z. Htnar. Graphical user interface and sequencc diagrarns in proto-
typc gerreration. In Z. Hrzar and Z. Maztr, editors, Problemy i ,metody inynieri.i.
opr-ogT'arrlo'wanza. WNT, 2003.
2. K. Koskirnies, T. Md,nnisto, T. Systd, and J. T\omi. SCED: A tool for dynamic
rnodclling of object systcms. Technical Rcport 4-1996-4, 1996. Available frorn:
citeseer'.ist.psu. edu/koskimicsg6sced. html.
3. G. Loniewski. State machirre prototype gcneration on the basis of urrrl 2.0 scquence
diagrarns. Master's thcsis, Wroclaw Univcrsity of Techrrology, Poland, September
2006.
4. E. Makinen and T. Systa. Mas - an interactivc synthesizcr to support behav-
ioral nrodcling in uml. In 23rd Internat'iortal Conference on Software Engineering
(ICSE'}I), pages 0-15, 2001.
5. L A. Niaz and J. Tanaka. Mapping uml statccharts to java code, 2004. Available
fronr: citcseer. ist.psu. eduI 635242.htm1.
o . object Managcment Group. UML 2.0 oMG STteci,li,cati,on,, 200b. Available from:
www. omg. org/technology/documents/formal/uml. htm.
7 T. Pcnder. UML Bible. John Wiley & Sons, 2003.
8 . P. Roques. UML i.n Practice. John Wilcy & Sons, 2005.
9 . J. Whittlc and J. Schumann. Gencrating statechart designs from scenarios. In
Internati,onul Conference on Software Eng'ineering, pages 3r4 828,2000. Availablc
from: citcseer.ist.psu. edu/whittle0Ogenerating.lrtrnl.
1 0 . T. Ziadi, L. Hclouet, and J.-M. Jezequel. Revisiting statechart synthcsis with an
algebraic approach. rn 26th Internat'iono,l Conference on Software E,ngineering
ICSE 0l), Edi,nburgh, (JK, pagc 242251, 2004.