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 automatic systcm prototype generation based on a collection of UML 2.0 scquerrce diagrams. In thc approach a set of sequcnce diagrams rcpresenting behavior of a specified systenr is transforrned into a state machirre and next a Java code is generated for the state machine. Thc trarrsformatiorm arc described inforrnally by presentation of simplc examples. Architecture of the system implementing the transformation is briefly describcd.
Sequencediagrams are verv often used as behaviour specification of developed systcrrs. Thcy becorne very popular with advcnt of the UML specification languagc. UML scquencediagrams were adopted from messagesequencecharts that wcre known already in other visual languages developed long ago by the International 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 sequencediagrams. Sequcnce diagrams arc used to specify scenarios as sequencesof 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 specification of systern's bchaviour. For devclopersthe most important factor should be quick validation of systetn's behaviour defined by a given set of sequencediagrams. Scquencc diagrams still have an informal scmantics, therefore the most effective way of such a validation is generabingsystem prototype and next its intensive testing.
The aim of the paper is prcsentation of an approach [
The first one representing static aspect of the system, consists of two elements: a classdiagram and an object diagram. The classdiagram reflects the set of potential configuratioru of thc system - a sct of linked objects. The object diagraur ref'ersto 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 representedby 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 accordanccwith 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 s t r i c t .
Additionally, to rnaintain consistencyof the specificationthe 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,grarrtso,therwise 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 fulfilled, - 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. 7 5 l - , * - l l - - e
I l[.iil.. t- !u|!c9 rr9nt.3e!oioii'r.-lir :I ..
l:'-:l*:*-:::"J - - tc=f . o1--
t l ' ' 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-oreach 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,inedfbr the specification example from the previous section. Messageson the sequencediagram which can change the object statc are recognized. It is assumed that only receiving 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 conditionr), 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 invariantcondition Statc mchine
for olrject ,/A" O
I a'----goI-'--'1) t..;t;;;ii;i .{corldftiorIn.'-.t-r.u-e...g.-n..l/f..tr..y.9-.r./.er--.4...-.,.2i*.....t-..\f{..-..1e..1.-ic.i.oi-l^.t1d;...i.t7..i.o."qn-:-lf'als.e:l . " 1l e G . . / [ ' . -"-t - \ ) ,//.t' e-( \ t t ti.,s a " i _l State lmchlne
for object ,.C" O
I r***5-d-\ i;;-f-fi-;-;-t;Tthe 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 synthcsis 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 machine 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 l'i1 M2
. e l - .sr , e ? 1..,r.T;--i hi s0''-'C-l->i t ."--s^-_'\I: , l--|a-al' 7 7 c)
|i]1UId? ti4lU|'1? f'll'l_l-f-.-'g-rI - -5,-1 t--e.{r a*, ',.....\et z ? z
S0 l-->iS''1S0-'j \ ,i..iir)-i e1'\;-l:_:q,' fti1U|'42
*l''l sr .5 f-'i s0.l
-*l' el " - --',-.9!, i t l-l-i--*'i-u,
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 sequencediagrams. For that reason applying the concept of iritera,ction use is recornmended.When creating system specification sirnilar. interactions can be dcsigned on a separate scquenccdiagram. Synthesis proccss docs not dcal with removing similar states. To improve the state machinc efficiency rcdundant statcs should be removed but still maintaing the statc machinc deterministic. 4
Codc generation out of statechart diagrams is based on the following schema: - state is transformcd to a class wherc its behaviour consists of methods derived 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 [
UML state machines and Java programming language are basedon different concepts. 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 skeletonof executableprototype. . sta!.9- . - ,,c.).rsln-te-x!t3!c-oent-e.".ti................................
|: + ab.s..tract .v:olid entry(): l
Ir I... . . . . . . . . . 1 . . . . . . . . . t,st o_ - . - . . , I t - - 5- -i*-------' -- ---- 1-ll S i ' . - . 1 - . _ ,t i _s-aIIIItLl*"+lisuvoooiiod':ee;rn(t)r:yO: iII |l|I|t"."r.-.s-vv-"too--tii,dd)d-:ee:4n- 90tr;1y1Oi. IIlI| l *i|tfIs-:-+.t---vv'*-Do-t1-r-)i-1dd'--:ee-:-7no--0t,-r:!y1--0--,."- -' ,lii: ||It1l.s++.l..2vvs.r.oo2..ii(.dd).;.ee..ng.r.(.ri.y:.0..t.......JIII....lii..+..vso3id0;entry(j I l 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. Functioning 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 creating and cditing. iad Systdan worktlow \ iiI/tdxsl!MaqgLu_r.o-nm,cr,r.s_.hrliriollhta/- I 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
Thc main motivation for automatic prototype generation is constructing a system that supports developing proccss in software. First of all, cxecutablc prototvpe enables validal,ion of a specificat,ionon a preliminary st;ageof the project. Additionally, it provides the first vision of the developedsystern that can bc further 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 modification 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 seemsto 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 issuesworth 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 [
Whittlc and Schumann in their work [