Introduction

Sequence diagrams are verv often used as behaviour specification of developed systcrrs. Thcy becorne very popular with advcnt of the UML specification languagc. UML scquence diagrams were adopted from message sequence charts 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 sequence diagrams. Sequcnce diagrams arc used to specify scenarios as sequences of messages passing betwcen objects. A sequence diagram represents an interactiona 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. Scquence diagrams 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 devclopers the most important factor should be quick validation of systetn's behaviour defined by a given set of sequence diagrams. Scquencc diagrams still have an informal scmantics, therefore the most 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 potential configuratioru of thc systema 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 sequence diagrams. 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. only asynchronous messages are allowed, combined fragments only with three main operator typcs: alt, loop and strict.

Additionally, to rnaintain consistency of the specification the following conditions should be hold:

objects belonging to the initial object diagram are not crcated on nonc of scquence diagrams, othcr objects may be created only once via create operation and on one of the sequence dia,grarrts, otherwise they a,re considered to be different objects, objects and their messagcs can 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. -The sct of states of thc resulting state machine is minimized.

The idea, of the first step of the tra,nsforma,tion is expla,ined fbr the specification example from the previous section. Messages on the sequence diagram 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 mcssages become cvents triggering transitions between states, whereas the outcoming messages become 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 conditionan interaction may be continued by thc object provided if the state satisfies the invariant condition 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 posscsscs objects 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 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 efficiency rcdundant statcs should be removed but still maintaing the statc machinc deterministic.

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 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 [5] of which created system makes use. It gives flexibility while performing some changes in specification (st,at,es act,ivities) which result,s in code modifications. State dcsign patt,ern also provides the architccture of Java classcs. UML state machines and Java programming language are based on 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 skeleton of executable prototype. -------llSi' : Testing condition in if-else statement is derivcd from a transition condition. If satisfied the transition is executed, otherwisc an exception arises.

II. t--5i-t..-- --*---'---1 f-------- ----l | | t----------" ', l"

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^s an 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. 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 system that supports developing proccss in software. First of all, cxecutablc prototvpe enables validal,ion of a specificat,ion on a preliminary st;age of the project.

Additionally, it provides the first vision of the developed systern 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 machinesmachines 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 correctness regarding 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 messages in the system specification. This approach allows only asynchronous messages wirich 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).

'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 preaud 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 scenarios 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,tion basing on sequence diagrams 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 minimum, at the same timc being in full compliance with the UML 2.0 notation standard.