Ordering actions in sequence diagrams of UML - Information ...

3

Ordering actions in Sequence Diagrams of UML J. Cardoso - C. Sibertin-Blanc Universitt Toulouse 1 - IRE Manufacture des Tabacs - 21 Allte de Brienne 31042 TOULOUSE CEDEX {jcardoso, sibertin}Ouniv-tlsel.fr

Abstract: The Unified object Modeling Language (UML) proposes a set of models but does not have a methodology that clearly fix both the use of these various models (diagrams) and the semantic links being able to exist between them. In particular, the Interaction Diagrams of LJh4L do not have, according to the current metamodel, an operational semantics defining formally how such a diagram is executed. The objective of this article is twofold i) to propose a step towards a formal semantics to the Interaction Diagrams of-UMLby defining a partial order between messages and actions, ii) to generate a Petri net that defines a semantic of this diagram. Such a semantics.can help the designer in the validation of his specifications, establishing a link between the Interaction-Diagramsand the Activity Diagrams and also allowing to generate code. Keywords: Interaction diagram in UML, Petri nets, formal semantics.

1 Introduction UML (Unified Modeling Language) is a standard notation for the specification of objectoriented systems. Namely, UML proposes several models and notations for the specification of the behavioral aspects of a system by a description of the interactions - Collaborations Diagrams and Sequences Diagrams - and of the internal activity of an active class State/Transitions Diagrams and Activity Diagrams. However, UML does not have a precise semantics associated to the components of these models. The relation between items of the metamodel are neither clearly defined, for example between Collaboration and Sequence Diagrams. Thanks to such a semantics, it would be possible to verify whether the behavior defined by the State Diagram of each object is coherent with e.g. the Sequence Diagrams where these objects participate. A formal semantic can also help in the validation of some properties of the system (e.g. lack of deadlock). In addition, it allows to simulate the specification of the system and also to automatically generate the code. Another important question concerns the execution model of the specified system. Can the control be implemented in a distributed way? In this case, the interaction results from the concurrent execution of objects and the lifeline of each object defines its behavior. In this paper we propose a formal semantics of Sequence Diagrams by defining a partial order between the messages and the actions of sending (!m)and receiving (?m)a message m. As a

23'd Int. Conf. information Technology interfaces IT/ 2007,June 19-22, 2001, Pula, Croatia

4

result, we give a means to check whether a Collaboration Diagram is implementable through a local control or if its implementation requires a global controller.We also propose an algorithm that automatically translated this partial order obtained from a sequence diagram (SD) into a Petri net. This net represents, on the one hand, the interactions of all objects of the SD and, on the other, the dynamical behavior of each object of the. It can be simulated and also translated to C code for example.

2 The Interaction Diagrams of UML Our approach is based on the abstract syntax of the Interaction Diagrams, i.e. on their definition in terms of the metamodel of UML,instead of being based on their concrete syntax as in the form of Collaboration Diagrams or Sequence Diagrams. Indeed, this concrete syntax is relatively complex - what makes its interpretationxatherhard -,whereas the transcription of a Interaction Diagram in the form of an instantiation of the metamodel is much simpler, and especially, better defined. Figure 1 shows how the interactions are defined in the metamodel. Each message has a sender and a receiver, which is one instance of a class of objects, or more precisely the role that plays this instance in the interaction. Message

t--l=Y I

I I *

.

+activator

0..1

I* I +receiver I

I1

*I

+action

i

* I

t

1I +sender I

I

Action recurrence : ExpressionIteraction isAsynchronous :Boolean I

A----

I

I

Figure 1. Extract of the metamodel of UML concerning the interactions. Each message is sent by an action; the attribute recurrence indicates if the action is guarded by a condition or is iterated, whereas the attribute isAsynchronous indicates if the sending message is asynchronous or synchronous: in the latter, the sender is blocked as long as the receiver does not return a result or an acknowledgement of delivery. The association Activation between the messages determines a whole of trees (a forest): a message Activator (non-terminal node in the tree structure) can be synchronous or asynchronous and its children messages constitute a transaction, or a procedure. When the execution of this procedure is triggered by the reception of a synchronous message, this execution is completed only after sending the last of these messages (this message must be ActionReturn, i.e. an action which returns a result to the sender of the message activator).

In the concrete notation of the Interaction Diagrams, the Activation association is expressed by the hierarchization of the numbers associated with the messages: a message of form 2.4.1 : m2 is a child of message 2.4: m l (and thus activated by it).

23rdInt. Conf. information Technology interfaces IT/ 2001, June 19-22, 2001, Pula, Croatia

5

Finally, the association of precedence defines a partial order between the messages of a same activation. In the concrete notation, this association is expressed by the numbering of the messages; thus, message 2.4: precede message 2.5, whereas messages 2.A: and 2.B: are not ordered and are thus concurrent. Beside the sender, a message is emitted by an action specified in the metamodel. Beside the receiver, the activity started by the reception of a message depends on the type of the sent action: call of an operation, sends of a signal, return of a result, creation or destruction of an instance. By convenience, we will qualify also action this activity started by the reception of a message. Thus, for each message m we will consider its transmitting action !m and its receiving action ?m. Unfortunately, the definition of Interaction Diagrams of UML deals only with the scheduling of the messages and does not say anything on .the scheduling of actions. Moreover, the association precede in the UML metamodel does not relate messages which belong to different activation. Indeed, UML contains only the following constraint ([OMG 2000],2.10.3, rule [3] concerning the messages): The predecessors of a message have the same activator as it. It is however essential to schedule the set of all the messages, including those which are on different hierarchical levels, and moreover all actions, those of message sending as well those of message reception; this will be done in section 3.

By showing the lifeline of the objects which take part in the interaction, a Sequence Diagram suggests that each object locally controls its message sending and reception. The Collaboration Diagrams do not allow us to visualize this sequence of actions which is expressed only by the numeration associated with each message. These diagrams suggest, in fact, that the scheduling of the actions is ensured by a centralized control which indicates to each object at which moment it must send a message. In fact, the metamodel of UML allows to define an Interaction Diagram such as the one of figure 2, whose implementation requires either a centralized control, or the addition of synchronization messages between the objects (for example, from 01 towards 03,to indicate to it that it can emit m2, and from 03 towards 01,to indicate that it can emit m3).

2:m2 3:m3

Figure 2. A UML Sequence Diagram

3 Actions Scheduling As we have said in the introduction, one of the goals of this paper is to give a formal semantic to Interaction Diagrams, formalizing the intuitive meaning of them. In order to do this, we must to deal with these key issues: a. action scheduling: to go from the message scheduling to the action scheduling; b. procedures: let be -begin, -end the actions of beginning and ending a procedure. If a message m activates a procedure, what is the relation-between ?m and -begin? 23'' Int. Conf. Information Technology lnterfaces IT/ 2001, June 19-22, 2001, Pula, Croatia

6

c. control localization: can the control be locally implemented, or, is it possible to schedule the set of actions an object must realize? Considering issues a and b above lead us to define a minimal order denoted c. Adding the issue c leads to the definition of a execution order denoted Zg
14

We do not have dealt here with recurrence, nor alternatives. Processing the alternatives .(represented in UML by different diagrams of sequence, because different scenarios) implies the fusion of the Interaction Diagrams of a same Use Case and the definition of an algorithm of superposition of the obtained Petri nets. That is what we intend to investigate now.

6 Bibliography [Cardoso 011 CARDOSOJ., SIBERTIN-BLANC C., SOULE-DuPUY C., "Une sbmantique formelle des diagrarrirnes d'interaction d'UML via les rbseaux de Petri", In proceedings of Formalisation des Activitks Concurrentes, 25-26 April 2001, Toulouse, France, pg 133-152. [Genrich 811 GENRICH H., LAUTENBACH K., System modelling with High Level Petri Nets ". Theoretical Computer Science 13, North Holland, 1981. [Gehrke 981 GEHRKET., GoLm U., WHRHEIMH., "Ttle dynamic models of UML :towards a Semantics and its Application in the Development Process". ISSN 0941-3014. [Lee...981 LEE W.L., CHAS.D., KWONY.R., Integration and Analysis of Use Cases Using Modular Petri Nets in Requirements Engineering ",IEEE Trans. on Software Engineering 24,12, Dec. 1998. [Murata 891 MURATA T., Petri Nets: Properties, Analysis and Applications "; In Roc. of the IEEE, vol77, n"84, April 1989. [OMG 20001 UML V 1.3, http://www.omg.org/technology/umVindex.htm, Juin 2000 [Paludetto 991 PALUDETTO M., DELATOUR J., UML et les rkseaux de Petri : vers une skmantique des modkles dynamiques et une mkthodologie de dkveloppement des systktnes temps rkei Revue Lobjet, Vo1.5, N"3-4, pp.443-467, Dec. 1999. [Pettit 001 PE= R.G., GOMAAH., "Validation of Dynamic Behavior in UML Using Colored Petri Nets", In proc. of UML'2000,2000. C., "Communicative and Cooperative Nets". In Proceedings of the [Sibertin 941 SIBERTIN-BLANC 15th International Conference on Application and Theory of Petri Nets, Zaragoza (Sp), LNCS 815, Springer-Verlag, 1994. "

"

"

"

".

23'' Int. Conf. Information Technology lnterfaces~lTlZOO7,June 19-22, 2001, Pula, Croatia