tion 4, we define the causality semantics of SD in terms of partial order between ac4 tions. Section 5 applies this definition on a traditional alarm clock example ...
126
Interpretation of UML Sequence Diagrams as Causality Flows C Sibertin-Blanc, O Tahir, and J Cardoso Université Toulouse 1 / IRIT 21 allée de Brienne F-31042 Toulouse cedex {sibertin,otahir,jcardoso}@univ-tlse1.fr
Abstract. UML Interaction diagrams (Sequence diagrams (SD), Collaboration diagrams or Communication diagrams) lack a formal semantics; they include some amount of ambiguity so that formal techniques cannot be applied e.g. for automatically deriving the behavior of the objects (as Statecharts or StateTransition diagrams) from the SD where they appear. To overcome this situation, this paper first analyses and simplifies the semantic relationships among the concepts that intervene in the definition of SDs: synchronous / asynchronous, activator and return messages. Then it proposes an interpretation of the precedence association among messages that yields to an operational semantics of SDs that orders the actions of emitting and receiving messages according to a causality relationship.
1 Introduction UML is a semi-formal language widely used in software development processes for the specification, design and documentation of systems. It proposes a tool-kit of diagrams to describe the structure and behavior of a system according to different aspects and views. A UML-based modeling process begins with the identification of use cases with their scenarios describing the executions of interest. Each use case corresponds to a system function and it is accompanied with one or several scenarios. Scenarios are used in system requirement phase to illustrate how the use case is performed. Each one describes a sequence of interaction between the system’s components and its external actors, and it may be graphically represented by a sequence diagram (SD) which shows message exchanges arranged along a time sequence. From this functional specification, it would be very interesting to assist a part of the design activities by automatically deriving the statechart diagrams of the objects within the system, that is an abstract executable specification of their observable behavior. Computer support for this translation from specification to design is important for successful application developments. Unfortunately, UML lacks a formal semantics and does not offer semantic relationships between the diagrams of dynamics. In particular, SDs do not have an operational semantics describing formally how to carry out such diagrams. The definition of SD in UML deals only with the scheduling of messages and does not say anything about the scheduling of the actions of sending (!m) and receiving (?m) a message m. In the case of SDs having a single thread of control, the message ordering directly defines the scheduling of the message sending and receiving actions; only one object F.F. Ramos et al. (Eds.): ISSADS 2005, LNCS 3563, pp. 126–140, 2005. © Springer-Verlag Berlin Heidelberg 2005
Interpretation of UML Sequence Diagrams as Causality Flows
127
being active at any moment, no concurrency is possible and there is no scheduling issue. This does not hold in the case of distributed systems where several objects can be active simultaneously. For instance, the SD depicted in Fig. 1 says that message m has to precede message m', but it does not specify e.g. whether the receiving action ?m must precede the send action !m'. O1
O2
O3
1: m 2: m'
Fig. 1. A simple UML Sequence Diagram
To provide SDs with an operational semantics consists in defining a partial order relation among the actions of sending and receiving messages. Any such scheduling of actions has to account for the fact that a message can not be received before it has been sent, thus we always have for any message m: !m before ?m. Then, there are several ways to schedule the sending and receiving actions of a SD. The first one is to read a SD as a Message Sequence Chart (MSC) [3], that is to ignore the UML global ordering of messages and to just consider the local ordering of actions performed by each object along its life-line. According to this definition, we just have for the SD of Fig. 1: !m before ?m, !m' before ?m' and ?m before ?m'. A second way to schedule the actions is defined and studied in [1]. This semantics just considers the ordering of messages: if a message m precedes a message m', m exists before m' and thus we must have !m before !m'. As a consequence, this semantics imposes a total serialization on the set of emission actions, even for those sent by different objects. According to this definition, we have for the SD of Fig. 1: !m before ?m, !m' before ?m' and !m before !m'. In this paper, we introduce a third way to schedule the actions of a SD; it accounts for the UML global ordering of messages while also dealing with the causality relationship among the actions, that means that two actions a1 and a2 are serialized only if a1 causes a2 in some way. According to this latter conception, we just have for the SD of Fig. 1: !m before ?m and !m' before ?m'. Indeed, there is nothing that enables to relate !m performed by o1 and !m' performed by o3, and as a result there is no way to causally relate the receptions ?m and ?m' performed by o2. The main property of this new scheduling of actions is that it orders two actions only if there is a necessity reason for that. Any requirement on actions ordering is a constraint put on the executions of the system. Thus, the main quality of this new operational semantics for SDs is to alleviate the behavior of a system from the execution constraints that are not rigorously justified. Provided with such a well-defined scheduling of the message sending and receiving actions, the functional requirements expressed by a set of SDs may be used to design the system’s components. Indeed, SD become provided with an operational semantics as Message Sequence Charts do. This allow to apply the results concerning the “realization” of a set of MSCs [6, 7, 9], that consists in synthesizing from a set of MSC an automaton for each of the objects involved in these MSCs. This automaton includes all the sequences of message sending and receiving that the object must be able to perform in order to fulfill the requirement expressed by the MSCs. In [8], an
128
Christoph Sibertin-Blanc, Omar Tahir, and José Luis Cardoso
informal way is given to derive the statecharts of the objects appearing in a set of SDs. The remainder of this paper is organized as follow: section 2 introduces the basic concepts of UML SDs. Section 3 discusses the interpretation of these concepts in order to start from a well-founded definition of UML Sequence diagrams. In section 4, we define the causality semantics of SD in terms of partial order between actions. Section 5 applies this definition on a traditional alarm clock example and, before to conclude, section 6 presents some related works.
2 The UML Definition of SD Any formal semantics has to be based on the abstract syntax of the interaction diagrams, i.e. on their definition in term of the metamodel of UML [2]. Fig. 2 shows how interactions are defined in the UML 1.5 metamodel. Message +activator 0..1
*
*
*
+predecessor
* * +receiver 1
Action +action
1
* 1 +sender
ClassifierRole
CallOperationAction
ReturnAction
isAsynchronous : Boolean
Fig. 2. Extract of the UML metamodel
An interaction is a unit of behavior that focuses on the observable exchange of information between a set of participating objects. More precisely, it contains a set of partially ordered messages, each specifying one communication. Graphically, an interaction is represented either as a SD to emphasize the chronology of the exchanges of messages, or as a Collaboration Diagrams (CD) to stress the organization of the system. A SD shows a temporal view of the interactions by putting the accent on the scheduling of the messages between objects, while a CD shows a structural view of the interactions by stressing links between the participating objects. These two diagrams are semantically equivalent since they are described by the same concept – collaboration – in the metamodel. Many UML tools automatically translate one diagram type to the other. 2.1 Message A message is the specification of a communication between two objects, or an object of the system and its environment. It unifies invocation of operation, send of signal, return of a result after an operation call, creation and destruction of an object. Each message has a sender and a receiver, which is an instance of a class of objects, or more precisely the role that plays this instance in the interaction. Each message is sent by an action, which specifies the statement that causes the communication specified by the message.
Interpretation of UML Sequence Diagrams as Causality Flows
129
The attribute isAsynchronous associated with an action indicates whether the message sending is asynchronous or synchronous. In the case of an asynchronous invocation, the sender continues its execution immediately without concern for the behavior launched by the message at the receiver object side; in the case of a synchronous invocation, the sender is blocked as long as the receiver does not send a ReturnMessage that is a result or an acknowledgement of delivery. A signal is always asynchronous, whereas an operation call can be either synchronous or asynchronous [2]. Graphically, an asynchronous message is represented with a stick arrowhead while a synchronous message is represented with a filled solid arrowhead. Finally, each message has a set of predecessor messages and, optionally, an activator message. The following sections explain the meaning of the predecessor and activator associations. 2.2 The Predecessor Association The messages of a SD are partially ordered by the predecessor association. The scheduling of those messages is based on the execution thread they belong to. Within each thread, messages are sent in sequential order whereas messages belonging to different threads are sent in parallel or in arbitrary order. This partial order among messages is defined by the association predecessor. For each message, its predecessors are “The set of Messages whose completion enables the execution of the current message. All of them must be completed before execution begins.” [2]. In the concrete notation [4], this predecessor association is expressed by the sequential numbering of messages: message 2.4:m1 precedes message 2.5:m2, whereas messages 2.A:m1 and 2.B:m2 belong to different threads: they are independent and thus concurrent. Sensor
Database
Control
Actuator
1: On 2: Pressure 3: Query 4: Data 5: Command 6: Off
Fig. 3. Scenario for a Boiler Control system
2.3 The Activator Association An interaction also specifies the activator of each message. The activator of a message is the message that invoked the procedure that in turn invokes the current message. In fact, the set of messages activated by a message constitutes a transaction, or a procedure. The execution of this procedure is triggered by the reception of the activator message, and it ends at the sending of the last of these messages; it must be sent by ReturnAction, i.e. an action that returns a result or a control flow to the sender of the activator message.
130
Christoph Sibertin-Blanc, Omar Tahir, and José Luis Cardoso
In the concrete notation, the activation association is expressed by the hierarchization of the sequence number associated with messages: a message of form 2.4.1:m2 is activated by a message 2.4:m1. 2.4 Definition of an Interaction As a conclusion, a UML SD may be defined as a sextuple (O, M, to, from, ℜPre , ℜAct), where: − is a finite set of instances or objects; − M is a finite set of messages, each message being either isSynchronous or isAsynchronous, and some of them being additionally tagged as ReturnMessage; − From and To are two functions from M to O. From(m) denotes the instance which sends message m, while To(m) denotes the instance which receives message m; − ℜPre is an order relation defined on M, it corresponds with the predecessor association defined in the UML metamodel; − ℜAct is a function from M to P(M), the powerset of M. For each message m, ℜAct(m) denotes the set (possibly empty) of messages activated by m. It corresponds to the activation association defined in the UML metamodel. Beyond this formal definition, there are several constraints on these predecessor and activator relations; with M the set of messages of an interaction. The following constraints have to be satisfied [2, 10]. a) The graph (M, ℜPre) with ℜPre the predecessor relation is acyclic, b) For m', m" ∈ M, if m' transitively precedes m" then either both have the same activator m ∈ M or both have no activator, c) For m ∈ M, if the action of m is synchronous call then there is an r ∈ M such that (1) the action of r is ReturnAction, (2) m activates r and (3) m' transitively precedes r for all m' ∈ M such that m activates m; thus each synchronous message is activator such as the last activated message is sent by a ReturnAction. Moreover, we say that a SD is locally controllable iff for all messages m, m' ∈ M, m ℜPre m' => From(m) = From(m') or To(m) = From(m'), i.e., for two directly consecutive messages, either they are sent by the same object or the second message is sent by the recipient of the first. In a locally controllable SD, each object has enough information to know when a send action must be performed, so that the global ordering of actions is ensured by the local controls in each object. The SD depicted in Fig. 3 extracted from [9] describes a scenario for a Boiler Control System. The Control unit operates a Sensor and an Actuator to control the pressure of a steam boiler. A Database is used as a repository to buffer Sensor information while the Control unit performs calculations and sends commands to the Actuator. This SD states that there must be some pressure registered into the Database before any queries is treated. This SD is not locally controllable. The Control object cannot know whether the sensor has registered pressure in the Database, it does not have enough local information to know at which time it must emit the request Query. Thus, in order to ensure that any request is treated after pressure has been registered, there is a need either for a centralized controller that activates each object when it has a send action to perform
Interpretation of UML Sequence Diagrams as Causality Flows
131
or for the addition of a synchronization message from the Sensor to the Control as described in [1]. Another solution is to consider a new operational semantics that does not impose a total serialization on the emission and reception actions of successive messages sent by different objects. Since the Pressure and Query messages are not causally related, it imposes no constraint on the ordering of their reception; instead, it considers that the sending of a message is caused by the reception of the precedent messages and thus imposes that the sending of a message is postponed after the reception of all these precedent messages. According to this causally based semantics, we have for the Boiler Control system: the send and receive actions of the two messages Pressure and Query are not ordered, that is the Control object can send the Query message without regard for the sending of the Pressure message by the Sensor, and the Database can receive these two messages in any order. On the other hand the emission of the Data message is conditioned by the reception of both the Pressure and the Query messages. As a matter of fact, this SD has exactly the same semantics than the SD where the Pressure and Query messages are in the inverse order, Query being numbered 2 and Pressure 3. This semantics will be formally described in section 4.
3 Interpretation of the UML Associations in Terms of Actions In order to give a formal semantics to SD, we need a more simple definition of UML SD that especially clarifies the relationships between the predecessor association, the activator association and the isAsynchronous property. To this end, we will integrate the three in a precede relation among all the messages. The main difficulty results from the ambiguity in the definition of the predecessor relationship given in the manual reference [2], since the meaning of “message completion” is not specified. Among all reasonable and tractable interpretations we can quote that given by [5]: the completion of a message means the termination of the action related to the sending of the message and performed by the sender. In case of asynchronous communication, the termination of the message is simply sending the message, while in case of synchronous communication it includes the resumption of the sender execution that was blocked after the sending of the message. Nevertheless, we adopt a finer interpretation that takes into account both the sending and the receiving actions of the message. Indeed, each emission of message goes with a send action realized by the sender object and a reception action realized by the receiver object, which corresponds to the activity carried out after the reception of the message. Thus the message completion concerns the two objects, the completion relating to sender object means the end of the execution of the send action and in the case of a synchronous message the reception of the expected result, whereas the completion related to the receiver object means the end of the activity carried out by the receiver object. For each message m we will consider its sending action !m and also its receiving action ?m. Thus, we complete the UML definition of SD that only identifies the send action and does not say anything on the reception of the message.
132
Christoph Sibertin-Blanc, Omar Tahir, and José Luis Cardoso
The predecessor association in the UML metamodel only relates messages which belong to a same activation. Indeed, UML contains the following constraint [2] :"the predecessors of a message have the same activator as it", therefore the activator of a message does not precede it. It is however necessary to schedule the set of all the messages, including those which are in different hierarchical levels. Thus, we translate the activator association into the predecessor association by defining a new exe tended predecessor association ℜ Pre between the messages which extends the ℜPre predecessor relation. This translation accounts for the synchronous or asynchronous character of the message activator. 3.1 The Synchronous Case Let m be a synchronous message (then m is an activator message according to the assumption (c) stated in section 2.4 and m' be any message activated by m, that is m' ∈ ℜAct(m). Then: (a) If m' is without predecessor, then m ℜ ePre m'; that means that a activator message precedes necessarily the first message of an activation. In other words, the actions of an activation are carried out after the beginning of this activation. (b) if m1 is a successor of m and m’ is without successors, then m' ℜ ePre m1; that means that if a message activator m is synchronous then all the actions of this activation must be carried out before a message m1 which succeeds m can be sent. 3.2 The Asynchronous Case Let m be an asynchronous message and m' be a message activated by m, that is m' ∈ ℜAct(m). Then (a) If m' is without predecessors, then m ℜ ePre m', as in the previous synchronous case (a). (b) if m1 is a successor of m, m' is without successor and From(m1) ≠ From(m), then m' ℜ ePre m1. The synchronous character of a message sending characterizes the behavior of the sender object and not the activity carried out by the reception of the message. In the case of an asynchronous activator, the activity carried out at the receiver side is concurrent with that at the sender object side. These rules express that (a) the actions of an activation must be carried out after the beginning of the activation. But (b) the end of the activation of an asynchronous message must be carried out before the messages which succeed the message activator is sent, except for the messages transmitted by the same object as the message activator. Once the activator relation is transcribed in a predecessor relation, and taking into account the constraints stated in section 2.4, in particular (c), the synchronous messages are considered and treated exactly as the asynchronous messages, since we considerer that each synchronous message is also an activator for which the last activated message is sent by a ReturnAction that is explicitly shown. So we can consider a SD as defined by a 5-uple (O, M, to, from, ℜ ePre) where no additional property is associated to the messages of M.
Interpretation of UML Sequence Diagrams as Causality Flows
133
4 A Causality Based Semantics for SD We are now provided with a single acyclic precede relation ℜ ePre among the set of messages that catches the meaning of the UML predecessor and activator associations together with the isAsynchronous property. In this section we define an order relation on the set of the actions that send and receive these messages. This order is a balance between on the one hand the MSC-order that ignores the UML global ordering of messages and only considers the local ordering of actions along the life-line of each object; and on the other hand the predecessor-order that funds the scheduling of local actions only on the global ordering of messages. This latter ordering considers that “message m precedes message m'” always implies “action !m precedes action !m'” and it is counter intuitive in the case of SDs that are not locally controllable since the correct execution of these SD requires either the use of a centralized controller or the addition of hidden messages. Thus the causality-based order relation defined in this section accounts for the precede relation among messages as far as all the synchronization between objects are realized by the exchanged messages, without the use of a global controller or the addition of other messages. It is founded on the synchronizations between objects operated by the messages – the sending precedes necessarily the reception – and on the local scheduling of actions in each object. 4.1 Local Scheduling of Messages We start by defining a local ordering of the messages sent or received by each object o. This relation, denoted
