Extending Causal Semantics of UML2.0 Sequence Diagram for
Distributed Systems
Fatma Dhaou
1
, Ines Mouakher
1
, Christian Attiogb
´
e
2
and Khaled Bsaies
1
1
Faculty of Sciences of Tunis, Tunis, Tunisia
2
University of Nantes, LINA UMR 6241, Nantes, France
Keywords:
Causal Semantics, Sequence Diagram UML2.0, Event-B.
Abstract:
The imprecision of the definitions of UML2.0 sequence diagrams, given by the Object Management
Group (OMG), does not allow the obtention of all the possible valid behaviours for a given distributed system,
when communicating objects are independent. We choose the causal semantics, which is suitable for this kind
of systems; we propose its extension to support complex behaviours, expressed with combined fragments. We
propose the implementation of our approach with Event-B in order to check later on some properties of safety,
liveness and fairness.
1 INTRODUCTION
Context. A meticulous development of distributed
systems may begin by writing the scenarios which de-
scribe the most significant behaviours.
The speed of design, the intuition and the ease of
graphical representation make UML2.0 sequence di-
agrams (SD) a privileged language often used by the
engineers in the software industries. The long term
goal of our work is the verification of consistency of
refined SDs. The current state of the works related to
UML2.0 semantics for distributed systems does not
propose such a verification framework. The use of the
formal method Event-B with the Rodin/ProB frame-
work is motivated by the availability of tools allowing
refinement checking.
The operational semantics, defined by OMG, for
UML2.0 SD still suffer from some problems. One
of these problems arises from their lack of precision,
which represses their convenient use.
Motivation. The rules defined by the OMG for deriv-
ing partial order in a given SD, state that the events
which belong to each lifeline must occur exactly in
the same order, as they are specified, this is restric-
tive when the objects are independent, and do not al-
low the obtention of all possible valid behaviours of
a distributed system. Moreover, the category of com-
bined fragments (CF), like ALT, OPT and LOOP, used
to represent compactly the SD must be flattened for
the computation of traces; it is like if we handle basic
SD, and we lose the utility of compact representation.
The weak sequencing is applied for the obtention of
traces, and the synchronisation point for the entry to,
or for the exit from, a CF is not specified. These two
points are considered as the source of the problem of
counterintuitive orderings (Micskei and Waeselynck,
2011). We choose the causal semantics which is suit-
able for modelling distributed systems. And we ex-
tend its rules, since it was proposed only for basic SD
of UML1.x. Consequently, the rules defined, in our
approach, allow the obtention of intuitive traces. In
fact, the events of SD are ordered, only, if there is a
logical reason to do so. The causal semantics is not
equipped with tools for its implementation. Thus, the
use of formal method offering tools seems a neces-
sity in our work. There is some formal frameworks
(ex. Input/Output automata) supporting the refine-
ment, which can be used as target formalism for the
implementation. However, there is a very limited sup-
port for this approach. The powerful tools support-
ing the refinement, the similarity between both for-
malisms, SD UML2.0 and Event-B, making a transla-
tion straightforward justify our choice of the Event-B
formalism.
Contribution. Our first contribution is the exten-
sion of causal semantics for SD UML2.0 equipped
with CF (ALT, OPT and LOOP). The second contribu-
tion is the implementation in Event-B of SD equipped
with extended causal semantics. Accordingly, we can
use the resulting B-machines for refinement checking
purpose, and for verifying some properties that may
be either intrinsic to SD or related to the considered
339
Dhaou F., Mouakher I., Attiogbé C. and Bsaies K..
Extending Causal Semantics of UML2.0 Sequence Diagram for Distributed Systems.
DOI: 10.5220/0005517703390347
In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 339-347
ISBN: 978-989-758-114-4
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
system.
Organisation. The remainder of the article is struc-
tured as follows. Section 2 is devoted to the UML2.0
semantics and causal semantics; their insufficiencies
are underlined. Then, in Section 3, we propose the
extension of causal semantics for the SD of UML2.0
equipped with the most popular CF like ALT, OPT and
LOOP. Section 4 is dedicated to the implementation
of SD that are equipped by extended causal semantics
with Event-B approach. In Section 5, we provide an
overview on the methodology that allows us to verify
the refinement between two sequence diagrams. Be-
fore concluding in Section 7, we present some related
works in Section 6.
2 UML2.0 SEMANTICS, CAUSAL
SEMANTICS AND
INSUFFICIENCIES
2.1 UML2.0 Semantics
According to the OMG, the UML2.0 semantics pro-
posed for a basic SD imposes that the events of the
same lifeline are ordered even if they are received
from different lifelines, and synchronise the events of
each message. More constraints may be added to es-
tablish a general ordering, and to restrict the set of
possible traces. A given message m is identified by a
pair of events (!m, ?m), where !m, ?m denotes respec-
tively send and receive event
1
. The trace of SD is a
sequence of event occurrences, and it is obtained by
satisfying the order imposed by a given semantics.
In this paper, we focus on the ALT, OPT
and LOOP CFs allowing to model complex behaviours
of the considered system compactly. A CF has an
interaction constraint (CI), it is a boolean expression
which guards an operand, and it can be explicit or im-
plicit. The ALT CF indicates a choice of behaviours.
It allows to model two or more possible behaviours.
However, neither the exact time nor the number of
times of the evaluation of the guard are indicated.
Moreover, when several CI are evaluated to true, at
most one of the operands will be chosen. However,
the OMG standard does not specify exactly which
operand will be chosen. The OPT fragment is equiv-
alent to an alternative fragment with an empty ELSE
operand. The LOOP CF allows to model a set of iter-
ations running in a loop. The CI may include a lower
and an upper number of iterations of the loop as well
1
we adopt this notation to be compliant with the widely
used inter-action formalism.
as a boolean expression.
Insufficiencies. The traces obtained by the rules de-
fined by the standard UML2.0 semantics of SD do
not reflect the behaviours which can be produced by
a distributed system during its execution, this can be
questionable. Having a semantics which provides the
possible valid behaviours of a given SD is crucial to
analyse the properties of safety. We choose the causal
semantics, which is an appropriate SD semantics ba-
sis for modeling distributed systems, and we extend it
to support SD with the CF ALT, OPT and LOOP with-
out flattening them.
2.2 Causal Semantics
With the causal semantics (Sibertin-Blanc et al.,
2005), the scheduling of sent and received events
is well-defined and is suitable for diagrams mod-
elling distributed systems. The causal semantics
is mainly based on three relations: 1) Synchronisa-
tion relation <
sync
. This relation allows each life-
line to synchronize its behaviour; it expresses that
a given message m is received if it was sent previ-
ously. 2) Reception-Emission relation <
RE
. Receiv-
ing a message causes the sending of the message
directly consecutive to it. 3) Emission-Emission rela-
tion <
EE
. If two messages are sent by the same life-
line, their sending events are ordered. In some partic-
ular cases of distributed system, if these messages are
addressed to the same lifeline, their received events
are also ordered. The global order relation <
∗
G
is
defined as the transitive closure of the three relations
<
∗
G
=<
SY NC
∪ <
RE
∪ <
EE
. To obtain a local order in-
side a lifeline o, noted <
o
, we project the global or-
der <
G
∗
on the lifeline o. In the following, we show
that the relations of causal semantics are not sufficient
to support SD with CF.
Insufficiencies. The causal semantics (Tahir
et al., 2005) was proposed only for SD UML1.x.
The application of its relations for SD with CF
generates some anomalies such as generation of
aberrant relations (aberrant relations), deadlocks
events (deadlocks events). These two anomalies are
caused by relations which must not exist between
events (example of two events which do not belong to
the same operand of the ALT CF). Another anomaly is
the inadvertent triggering. It is the case of an event fol-
lowing a CF LOOP, that can be triggered after one it-
eration of its preceding event inside the CF; normally,
the triggering must occur after all the interactions of
the CF LOOP.
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
340
3 EXTENSION OF THE CAUSAL
SEMANTICS
As indicated in the Sec. 2.1, the behaviour of the SD
with the CF is deducted by flattening them and by
applying weak sequencing. Accordingly, we obtain
basic SD, and we face again the problem of the loss
some behaviours and the inadequacy of standard se-
mantics UML2.0 for the distributed systems. In our
approach, the default composition operator, which is
applied to CF, follows the causal sequencing. The par-
tial order derived between the events is justified be-
cause we define the rules which govern the computa-
tion of this order. Moreover, with this partial order we
obtain all possible behaviours for a given distributed
system. The extension of causal semantics which we
propose lies: i) in new rules of causal semantics for
SD with CF and their formalization; ii) the definition
of an event definition which belongs to a given SD
with CF. The obtained traces are sequences of event
occurrences. Each event is described by a definition
and its occurrence depends on defined rules. In (Tahir
et al., 2005), they propose rules of causal semantics
only for basic diagram, and an event which belongs to
a given SD can be executed if its preceding events are
executed. We have extended the precedence relation-
ship since for example, a given event which belongs
to SD with an ALT or an OPT CF can have preceding
events which can be executed only once or which can
be ignored; a given event which belongs to SD with
a LOOP CF can have preceding events which can be
executed several times.
3.1 Formalization of the Causal
Semantics
Our proposed specification supports SD containing
sequential CF. In a SD with an ALT CF, we can have
several CI evaluated to true at the same time, only one
of them will be executed in a nondeterministic way.
In the following, we give a formal definition of SD
and different concepts used in this paper.
Well Formed Messages. We define M a set of mes-
sages, and EV T a set of events that is associate to
messages. The set M is well formed if every message
is identified by a pair of events: a sent event and a re-
ceived event.
Conditional Combined Fragment (ALT, OPT).
A conditional CF is a sequence of couples
F =< (guard
1
, OP
1
), (guard
2
, OP
2
), ..., (guard
j
, OP
l
) > where: guard
i
is the constraint which guards the i
th
operand, OP
i
is
the set of events covered by the i
th
operand.
Combined Fragment (LOOP). A CF LOOP is a quadru-
ple F = [guard, min, max, OP] where: guard is the constraint
which guards the loop operand, min is the minimum
number of iteration, max is the maximum number of
iteration and OP is the set of events covered by a
LOOP CF. ran(E) and card(E) denote respectively
the range and the cardinal of a set E.
Sequence Diagram. A sequence diagram is a tuple
SD : [O, M, EV T, FCT s, FCT r, FCT o, F, <
Caus
] where:
• O, M, EV T are respectively a finite and non-empty
set of lifelines, messages and events,
• E s, E r denote respectively the set of sent events
and the set of received events,
• FCT s, FCT r are two bijective functions that asso-
ciate respectively for each message a sent event
and a received event,
• FCT o: is total surjective function that associates
for each event one lifeline representing the trans-
mitter or the receiver,
• F =< F
1
, F
2
, ..., F
k
> is the sequence of k CF ALT, OPT,
and LOOP,
• <
Caus
: denotes the partial order relationship which
is transitive, acyclic and non-reflexive.
We define the local order relation between events
within each lifeline noted <
∗
DS,o
, such that <
∗
DS,o
is the
set of pair of events e, e
0
, such that the events e, e
0
be-
long to the set EV T ; they are directly consecutive,
and are sent or received by the lifeline o. The local
relation <
∗
DS,o
is a minimal acyclic and non-transitive
relation.
3.2 Case Study
We illustrate our approach through a case study de-
picted in Fig. 1. We model the interactions in a restau-
rant with UML2.0 sequence diagrams. The restau-
rant system is a distributed system since its compo-
nents are independent: the client, the head cook, the
waiter1 and the waiter2. The client orders meal to
waiter1 which transmits the order to the head cook.
Once the meal is ready, the head cook alerts the
waiter at most 3 times. The client orders a drink to
waiter2 which will serve it. Then, the client asks for
the bill for the waiter1 which in turn asks for the type
of payment the client wants to make. The client has
several alternatives: he can pay by cash, by card or by
cheque. In the first case, if the paid amount is greater
than the amount of the bill, the waiter1 gives change
to the client. Once the bill was paid, the waiter deliv-
ers a receipt to the client.
ExtendingCausalSemanticsofUML2.0SequenceDiagramforDistributedSystems
341
[0,3]
loop
alt
opt
client
waiter1
waiter2
Head_cook
order_meal
transmit_order
alert_waiter
order_drink
serve_meal
serve_drink
ask_for_bill
bring_bill
reequest_type_payment
[not_served]
pay_bill_cash
return_rest
pay_bill_card
pay_bill_cheque
[rest<>0]
[type=1]
[type=2]
[type=3]
issue_a_receipt
Figure 1: SD Restaurant.
3.3 The Partial Order Relationship <
Caus
The event occurrence depends on the partial order re-
lationship <
Caus
. We extend this relationship by re-
defining the causal rules to support CF.
We consider an example of SD with two CF
F =< F
1
, F
2
> where: i) F
1
= < (guard
1
, OP
1
), (guard
2
, OP
2
) >
is an ALT CF which models only two possible be-
haviours however, the proposed solution is valid for
an ALT CF with k operand. ii) F
2
= < guard, 0, N, OP3 > is
the LOOP CF. We consider the set OP = OP
1
∪ OP
2
∪ OP
3
.
We define the total function F
op
, that associate to
each operand, in a given SD, the corresponding CF.
We define the new relation <
guard
, such that if the CI
of CF depends on the execution of an event, which
precedes CF then, we add a causality relation between
this event and the first event authorized for execution
in the ALT CF. Note that, the first event of the CF au-
thorized to be execute is not necessarily the event
which appears the first in the CF. For the rest of paper,
we designate this event by the first event of the CF.
In SD with sequential CF, the events may be located
outside or inside the CF (ALT, OPT or LOOP). The
events located outside the CF are of two categories:
they can precede or succeed the CF. The events suc-
ceeding the CF may belong to lifelines covered or not
by the CF. The proposed categorization of events will
help us to define the causal rules for a SD with CF.
3.3.1 Computation of Causal Relationship
The causal semantics is defined as the union of these
relations:<
Caus
=<
sync
∪ <
RE
∪ <
EE
∪ <
guard
. For a given SD
with sequential CF, the computation of causal rela-
tion is done in several steps. First of all, we apply
the obvious rule which synchronizes the sending and
receiving of each message (<
sync
). Then, we omit all
the CF of the SD, and we apply the rules of causal
semantics; indeed as we have mentioned before, if
the CI(the guard) is evaluated to False, then, none
event inside the operand occurs. The case where all
the guards of each CF are False is possible. Accord-
ing to the ALT CF, for every operand we omit the other
operand of the CF, and we compute the relationships
between the events which are inside the CF and other
events. For the LOOP CF, there is no special treatment
as for ALT CF. Following this approach, we solve
the aberrant relations) and (deadlocks events) prob-
lems that we have already mentioned.
3.4 The Causal Rules
In this section, we give the conditions which must be
satisfied by all pairs of events in both relations <
RE
,
<
EE
. For each relation, we identify four rules.
<
RE
= {(e, e
0
|rule1.1 ∨ rule1.2 ∨ rule1.3 ∨ rule1.4}
<
EE
= {(e, e
0
|rule2.1 ∨ rule2.2 ∨ rule2.3 ∨ rule2.4}
Where in rulei. j, i denotes the relation (1 denotes the
relation <
RE
, 2 denotes the relation <
EE
), j denotes the
rule. We explicit these rules in the following. We
identify four situations, for both relation, depending
on the localisation of the events to be ordered. For all
rules, the events e, e
0
belong to the same lifeline.
• The first situation is defined when the events e, e
0
to be ordered are located outside the CF.
Rule 1.1: <
RE
. If an event e” exists between the
events e, e
0
, it is necessarily either a received event
or it belongs to a CF, located between e, e
0
(since
the events of the CF can be ignored, in the case
where the CI is False).
(∀e)(∀e
0
)[(e, e
0
) ∈ (EV T \ OP)
2
∧ ∃ o ∈ O ∧
FCT
o(e) = FCT o(e
0
) = o ∧ e ∈ ran(FCT r) ∧ e
0
∈ ran(FCT s) ∧
e <
∗
DS,o
e
0
∧ (∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒
e” ∈ ran(FCT r) ∨ e” ∈ OP)].
Rule 2.1: <
EE
. If an event e” exists between e, e
0
,
it belongs necessarily to the CF located between e,
e
0
.
(∀e)(∀e
0
)[(e, e
0
) ∈ (EV T \ OP)
2
∧ ∃ o ∈ O ∧
FCT o(e) = FCT o(e
0
) = o ∧ (e, e
0
) ∈ (ran(FCT s))
2
∧
e <
∗
DS,o
e
0
∧ (∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒ e” ∈ OP))]
• The second situation is defined when the event e
is inside to the operand OP
i
, for which the CF is
True, and the event e
0
succeeds the CF.
Rule 1.2: <
RE
. If an event e” exists between e, e
0
,
it is necessarily a received event or it belongs to
one operand different from OP
i
, if it is related to a
CF ALT.
(∀e)(∀e
0
)[e ∈ OP
i
∧ e
0
∈ (EV T \ OP) ∧ ∃ o ∈ O ∧ FCT o(e) =
FCT o(e
0
) = o ∧ e ∈ ran(FCT r) ∧ e
0
∈ ran(FCT s) ∧ e <
∗
DS,o
e
0
∧
∧ (∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒ e” ∈ ran(FCT r) ∨e” ∈
(OP \ OP
i
))]
Rule 2.2: <
EE
. If an event e” exists between e, e
0
,
it belongs necessarily to another operand different
from OP
i
of the considered CF.
(∀e)(∀e
0
)[e ∈ OP
i
∧ e
0
∈ (EV T \ OP) ∧ ∃ o ∈ O ∧
FCT o(e) = FCT o(e
0
) = o ∧ (e, e
0
) ∈ (ran(FCT s))
2
∧ e <
∗
DS,o
e
0
∧
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
342
∀(e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒ e” ∈ (OP \ OP
i
))]
The third and the fourth situation concern SD
with CF ALT or OPT.
• The third situation is defined when either e, e
0
are
both in the same operand OP
i
, for which the CF
is True, or the event e precedes the CF, and the
event e
0
is inside to OP
i
.
Rule 1.3: <
RE
. If an event e” exists between the
events e, e
0
, it is necessarily a received event or it
belongs to an operand different from OPi.
(∀e)(∀e
0
)[e ∈ (EV T \ (OP \ OP
i
)) ∧ e
0
∈ OP
i
∧ ∃ o ∈ O ∧
FCT o(e) = FCT o(e
0
) = o ∧ e ∈ ran(FCT r) ∧
e
0
∈ ran(FCT s) ∧ e <
∗
DS,o
e
0
∧ (∀e”)(e” ∈ EV T ∧
(e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒ e” ∈ ran(FCT r) ∨ e” ∈ (OP \ OP
i
))].
Rule 2.3: <
EE
. If an event e” exists between e, e
0
,
it belongs to an operand different from OPi.
(∀e)(∀e
0
)[e
0
∈ (EV T \ (OP \ OP
i
)) ∧ e ∈ OP
i
∧ ∃ o ∈ O ∧
FCT o(e) = FCT o(e
0
) = o ∧ (e, e
0
) ∈ (ran(FCT s))
2
∧ e <
∗
DS,o
e
0
∧ (∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e) ⇒ e” ∈ (OP \ OP
i
))].
• The fourth situation is where the events e, e
0
belong to operands OP
i
, OP
j
, for which the CFis
True, of two sequential CF.
Rule 1.4: <
RE
. If an event e” exists between the
events e, e
0
, it is necessarily a received event or it
belongs to other operands of CF different from OP
i
and OP
j
.
(∀e)(∀e
0
)[e ∈ OP
j
∧ e
0
∈ OP
i
∧ F
op
(OP
j
) 6= F
op
(OP
i
) ∧ ∃ o ∈ O ∧
FCT o(e) = FCT o(e
0
) = o ∧ e ∈ ran(FCT r) ∧ e
0
∈ ran(FCT s) ∧
e <
∗
DS,o
e
0
∧ (∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
)
⇒ e” ∈ ran(FCT r) ∨ e” ∈ (OP \ (OP
i
∪ OP
j
)))].
Rule 2.4: <
EE
. If an event e” exists between e, e
0
,
it necessarily belongs to the other operand of CF
different from OP
i
and OP
j
.
(∀e)(∀e
0
)[e ∈ OP
j
∧ e
0
∈ OP
i
∧ F
op
(OP
j
) 6= F
op
(OP
i
) ∧ ∃ o ∈ O ∧
FCT
o(e) = FCT o(e
0
) = o ∧ (e, e
0
) ∈ (ran(FCT s))
2
∧ e <
∗
DS,o
e
0
∧
(∀e”)(e” ∈ EV T ∧ (e <
∗
DS,o
e” <
∗
DS,o
e
0
) ⇒ e” ∈ (OP \(OP
i
∪ OP
j
)))].
3.5 Behaviour of Sequence Diagrams
The behaviour of a given SD is a set of traces. The
set of traces which defines a choice is the union of
the guarded traces of the operands. The trace is a set
of events occurrences. The occurrence of an event
depends on its definition.
3.5.1 The State of Event
In the standard semantics and in the causal seman-
tics, an event which belongs to a basic SD is either
executed or not yet executed. Therefore, we define a
function to assign to each event a state. The state of
an event which is not yet executed is 1. After its ex-
ecution the event is consumed, and its state becomes
0. For an event which belongs to a SD with a CF , we
extend the state to allow us to deal with CF compactly.
Each event which belongs to a SD with an ALT CF ,
can have one state among three: either 1 if it is not
yet executed, or 0 if it is executed, or −1 if it is ig-
nored. Initially, the state of the events which belongs
to the LOOP CF is N, such that N denotes the maximal
number of iteration. After the execution of each event
of the LOOP CF, the state of each of them is decreased.
If these events may be executed N times, or may not
finish all the iterations, where the CI becomes False,
their state must be 0, to allow the events which follow
the CF to occur. Thus, an event must have one of the
state values 0,1, −1 or N.
3.5.2 The Fictitious Event
The LOOP CF has exactly one operand, we choose to
evaluate the CI only once in the first event which is au-
thorized to occur; however, the ALT CF may contain
several operands, we choose to evaluate the CI only
once in the first event which is authorized to occur.
Thus, if the CI is evaluated to True, and the causality
constraints are satisfied then, this first event will occur
and the events which depend on it may occur. Other-
wise, if the CI is evaluated to False, and the causality
constraints are satisfied, then the events which follow
the CF must be executed, and the events of the CF will
be ignored. Regarding the ALT CF, if it is ignored,
then all its events must be disabled (state = −1). Hence,
the need to use the fictitious events, which will occur
when the CI is evaluated to False. The effects of their
execution consist in disabling the events of the CF.
For the LOOP CF, if the CI is False, the fictitious event
allows the other events inside the LOOP CF to finish
their iteration, and to prevent them from executing the
remaining iterations by decreasing their states.
3.5.3 The Definition of an Event
The behaviour of a SD, observed through, is the oc-
currence of its events. An event occurs under some
conditions, and produces effects. Each event which
belongs to a SD with CF has trigger conditions and ex-
ecution effects. The trigger conditions include causal-
ity with other events (which must be formalized).
For an event, which does not belongs to none CF,
the trigger conditions consist in i) the precedent
events of the current event are executed or ig-
nored, ii) the current event is not yet executed. The
execution effect consist in updating the state of the
event. For the other identified kind of events, in addi-
ExtendingCausalSemanticsofUML2.0SequenceDiagramforDistributedSystems
343
tion to these trigger conditions and the execution ef-
fects, we have other ones.
For the CF ALT, we distinguish two special kinds
of events. The first one, is the first event of each
operand of the CF, for which, we must add a trigger
condition to evaluate the CF. And the execution effect,
for modifying the state of the events, which belong to
the second operand to −1, in order to ignore them (if
it is about the first event of the first operand, other-
wise we modify the state of the events which belong
to the first operand to −1 in order to ignore them).
The second one, is the fictitious event, for which,
the second trigger condition consists in verifying that
the CI of the CF is False. The execution effect consists
only to modify the state of the events which belong to
the CF to −1 to ignore them. For the CF LOOP, we dis-
tinguish three special kinds of events. The first one,
is the first event of the CF, for which, we must add
two trigger conditions, which consists in, evaluating
the CI, and verifying that the current event was ex-
ecuted a number strictly greater than 0. The second
kind are the other events inside the CF, for which, the
second trigger condition is different and consists in
verifying that the current event was executed a num-
ber strictly greater than 0. Moreover, we add the trig-
ger condition which consists in verifying that the it-
eration number of the preceding events of the current
event is lower than its number of iteration. The third
kind is the fictitious event, for which, the second trig-
ger condition consists in verifying that the iteration
number of the preceding events of the current event is
lower than its number of iteration. Moreover, we add
the trigger condition which consists in verifying that
the CI of the CF is False. The execution effect consists
in updating the state of all events of the CF.
Up to now, we have extended the causal seman-
tics, and defined accordingly the behaviour of SD
with CF.
4 IMPLEMENTATION IN
EVENT-B
In this section, we show how we proceed to imple-
ment in Event-B the SD which is equipped with ex-
tended causal semantics.
4.1 The Proposed Generic Event-B
Specification
In an Event-B model we have two parts: a static part
composed by the context and a dynamic part com-
posed by the B-machine.
4.1.1 Construction of Contexts CTX and CTXP
We define two contexts. In the first context CTXP,
we define the configuration which is appropriate to
the considered SD. In the second context CTX, which
extends the first context, we define the sets, the con-
stants, the axioms and the theorems which allow to
define the typing of constants or to express general
properties of the SD. We detail them in the follow-
ing. The contents of this context are unchanged for
any SD. The constants OBJECTS, MESSAGES, EVT
represent respectively the lifelines, messages and the
events of SD. The sent events and the received events
are represented respectively by the set EVT SEND and
EVT REC. In the constant BEGIN, we specify the first
event authorized for execution in the SD.
4.1.2 Construction of Event-B Machine for
Basic Sequence Diagram
The derivation of the SD in Event-B is straight-
forward. Indeed, we have the following similari-
ties between the two formalisms: (Triggers condi-
tions, Guards) and (Executions Effect, Substitu-
tion). In Event-B, a guard has a label (like G1, G2...);
in the same way, the substitutions have a label (like
S1, S2...). The clause SEES allows the B-machine to
have a visibility on the static declarations which are
made in the context. B-machine is composed by:
1) Variables and Invariants: we define two variables
with invariants: i) state a total bijective function that
expresses the state of each event: state ∈ EV T → Z, and
ii) current ob ject expresses the transmitter or the re-
ceiver of the current event: current ob ject ∈ OBJECT S;
2) the initialization: initially all the events are not yet
executed: state :=EVT∗{1}. The variable current ob ject
is initialized to the lifeline of the event authorized to
be executed;
3) the events of B-machine are the same events of the
SD; therefore, the B specification generated and the
SD have the same trace (equivalence of traces).
4.1.3 Event-B Specification for Sequence
Diagram with Combined Fragment
We consider the example of the SD, depicted in Fig. 1,
with two sequential combined fragments LOOP, ALT;
the ALT CF is composed from three operands, and
its first operand contains an OPT CF. However,
the B specification which we propose is suitable for
a SD with several sequential CF and notably where
the ALT CF contains several operands. We keep the
same structure as that proposed for basic SD, we out-
line what will change in the content of contexts and
machine. We add in the contexts CTX and CTXP,
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
344
three constants EVT OP1, EVT OP2, EVT OP3 repre-
senting respectively the events of the first, the second
and the third operand of the ALT CF. We add a con-
stant EVT LOOP representing the events located inside
the LOOP CF. The state of the event, which are inside
the LOOP CF, must be initialized to N, and the events
which are not inside the LOOP CF must be initialized
to 1: state :=(EVT\ EVT LOOP)∗{1}∪ EVT LOOP∗{N}
In the following, we give the implementation of
the definition of an event, that we have already infor-
mally explained in the Sec. 3.5.3. An event is defined
by its guards and substitutions.
As example of an event, which does not
belong to a CF, we have R ordermeal. The
guards are: G1. ran(Caus
−1
[{R ordermeal}] / state) ⊆ {−1, 0}
and G2. state(R ordermeal) ≥ 1. The substitutions
are: S1. state(R ordermeal) := state(R ordermeal) − 1 and
S2. current instance := FCT o(R ordermeal).
For the other identified kind of events, in addition
to these obvious guards and substitutions cited
above, we have the following ones. Regarding
the CF ALT, as we have mentioned we distin-
guish two special kinds of events: for the first
kind of event, which is the first event of each
operand of the CF, example E paybillcash, we
add the guard to evaluate the CI. And the substi-
tution: S3. state := state C−(((EV T ALT 2 ∪ EV T ALT 3) ∗ {−1})∪
{(E paybillcash 7→ (state(E paybillcash) − 1))}). For the
second kind of event, which is the fictitious
event, example E paystop, its guards are:
G1. ran(Caus
−1
[E paystop] \ (EV T OP1 ∪ EV T OP2 ∪ EV T OP3) /
state) ⊆ {−1, 0}, and G2. C = FALSE. Its substitution is
S1. state := state C−(EV T OP1 ∪ EV T OP2 ∪ EV T OP3) ∗ {−1}.
Concerning the CF LOOP, as we have mentioned
we distinguish three special kinds of events: for
the first kind of event, which is the first event of
the CI, example E alertwaiter, we add a guard to
evaluate the CF G3. taking into account = 0 ; and a guard
G4. ∀(ee)(((ee ∈ EV T LOOP) ∧ (ee ∈ Caus
−1
[{E alertwaiter}]))
=⇒ (state(ee) < state(E alertwaiter))). For the second kind of
event, which is, the other events inside the CF, we add
the guard G3. (∀ee) · ((ee ∈ EV T ∧Caus
−1
[x]) ⇒ state(ee) < state(x)).
For the third kind of event, which is, the
fictitious event, we must add two guards
G3. (∀ee) · ((ee ∈ EV T LOOP ∧ ee ∈ (Caus
−1
[{E alertwaiter}])) =⇒
(state(ee) < state r1(E alertwaiter))), G4. taking into account = 1.
The substitution is S1. state := state C− {x 7→ y|x ∈
EV T LOOP ∧ y = state(E alertwaiter) − state(E alertwaiter))}.
The current results on the implementation of SD in
Event-B allow us to start studying properties, and
to check the relation of refinement between two
SD, which model complex behaviours of a given
distributed system.
5 TOWARDS THE REFINEMENT
OF SEQUENCE DIAGRAMS
Event-B offers a powerful tool (Rodin), which can
check the refinement relation between two given mod-
els, by generating proof obligations that must be
proved. Consider two sequence diagrams SD1 and
SD2 equipped with the proposed extended causal se-
mantics; in order to verify that SD2 refines SD1 with
Event-B: we translate independently each SD into
a B-specification; we define the rules of refinement
as well as the refinement properties which must be
proved. The latter will be expressed as theorems. The
proof of the refinement properties, and the validation
of both obtained models allow to deduce, or not, that
SD2 is the refinement of SD1.
Properties. The checking of properties is made
conjointly by the tools Rodin and ProB, which are
complementary. Rodin generates proof obligations
(PO) that can be checked automatically or interac-
tively. With Rodin, we checked especially static prop-
erties, that allow to prove the well formedness of
the SD. These properties are expressed in the con-
text of B-machine as theorems. For example, we
verify that the SD is not empty: Finite(OBJECT S),
Card(OBJECT S) > 2, (OBJECT S) 6= ∅, MESSAGES 6=
∅, EV T 6= ∅; each event belongs to one lifeline:
Fct o ∈ EVT OBJECT S; the causal relation is acyclic
and non-reflexive Caus ∩ EV T /id = ∅. Dynamic prop-
erties are expressed in the clause invariant of B-
machine. We check some safety properties such as
all sent messages are received; each received event
must be send before: ∀ee · (ee ∈ EV T REC ∧ state(ee) = 0 =⇒
state(FCT EV T s(FCT r)
−1
(ee)))) = 0)). We have not deadlock
(liveness property): at any moment we have an event
authorized to be executed (this property is expressed
by the disjunction of guards of all the events). The
property of non-divergence of the events, which be-
long to LOOP CF, consist in ensuring that these events
do not take infinitely the control. It is done by using
the PO for refinement checking, and by defining an
expression named variant, that must by decreased by
the events running in the LOOP CF. In the given case
study, the variant is: state(E alertwaiter) + state(R alertwaiter).
We export the B-specification from Rodin to the ProB
for the further checking. ProB supports automated
checking of B-machines by model checking, and pro-
vides counter-examples when there is a violation of
the invariant. In ProB, we can express fairness prop-
erties by means of linear temporal logic (LTL) formu-
las.
ExtendingCausalSemanticsofUML2.0SequenceDiagramforDistributedSystems
345
6 RELATED WORKS
Many researchers proposed semantics for sequence
diagram for various purposes. In (Micskei and Wae-
selynck, 2011) a survey on semantics of SD to over-
come problems that are not yet resolved by OMG.
Other semantics (Aredo, 2000), (Cengarle et al.,
2006), (Haugen et al., 2005), (St
¨
orrle, 2003) were
proposed to verify some SD properties such as safety
properties like deadlock freedom, or to verify the
properties of the relation of refinement of sequence
diagrams, like in (?), (Haugen et al., 2005), (St
¨
orrle,
2003). There are approaches which have defined se-
mantics by translating the SD into other formalisms to
benefit from their advantages. In (Whittle and Schu-
mann, 2000) statecharts were generated from a set
of SD and a set of OCL constraints. In (Cardoso
and Sibertin-Blanc., 2001), (Eichner et al., 2005) SD
were translated into Petri nets formalism. In (Grosu
and Smolka, 2005) SD were translated into B ¨uchi au-
tomata. However, by making the translation some
essential features of the SD are lost. These seman-
tics are not suitable for modeling all types of systems
especially for distributed systems. This mismatch
has motivated the work of (Sibertin-Blanc et al.,
2005), (Tahir et al., 2005) who proposed a causal
semantics for basic SD. Many works (Laleau R.,
2002), (Akram, 2006) have coupled UML and B-
method, in two ways, either to ensure the traceabil-
ity between the two formalisms or to check some
properties and to eliminate inconsistency of UML di-
agrams ((Lano et al., 2001), (Ledang and Souqui
`
eres,
2002)). The existing approaches provide semantics
closely related to the target translation formalisms.
In our approach, regardless of the translation lan-
guage, we have considered an existing semantics
for UML1.x SD, which is adequate for modeling of
the behaviours of distributed systems; we have ex-
tended it to support UML2.0 SD with the most popu-
lar CF (ALT, OPT, LOOP). We take care in the trans-
lation to preserve all the essential aspects of the SD,
by considering set theory and equivalence of traces
shared by the formalisms.
7 CONCLUSION AND
PERSPECTIVES
To help in preliminaries design steps of distributed
systems, we have equipped UML2.0 sequence dia-
grams with an appropriate causal semantics. We have
underlined the limitations of the existing UML2.0
semantics, which consists in i) imposing a total or-
der on events in each lifeline, ii) flattening the com-
bined fragments and, iii) the application of the weak
sequencing to derive the traces of SD. Therefrom,
we opted for the causal semantics initially proposed
for basic SD in the setting of distributed systems.
The causal semantics is based on partial order. We
have proposed an extension of this causal seman-
tics to cover the ALT, OPT and LOOP combined frag-
ments. We overcome the insufficiencies of the stan-
dard UML2.0 semantics by proposing a treatment
of CF which preserves their compact description: new
behavioural rules are described and formalized. We
have proposed an implementation in Event-B of the
SD equipped with this extended causal semantics.
The behaviour of SD (defined by their traces) can then
be checked by analysing the Event-B models. The
latter will also serve as the support for safety, live-
ness and fairness analysis. Several combinations of
nested CF must be studied in order to generalize, and
to extend our proposal to support nested CF; to cover
other concepts like the gates, and the state invariants,
which allow one to express more complex behaviours,
and to cover other CF, in particular those dedicated
to model invalid behaviours such as the NEG opera-
tor. Meanwhile, the current extension of causal se-
mantics serves as the basis of our work on the ver-
ification of the refinement relation between sequence
diagrams. The Rodin platform is extendable with plu-
gins. We currently creating a plugin for checking the
well-formedness of a given SD equipped with the ex-
tended causal semantics and for checking other prop-
erties. We are already conducting some experimenta-
tions on the refinement of SD.
REFERENCES
Akram, I. (2006). Couplage de sp
´
ecifications B et de
descriptions UML pour l’aide aux d
´
eveloppements
formels des syst
`
emes d’information: Approche par
m
´
eta-mod
´
elisation. In Actes du 24
`
eme congr
´
es IN-
FORSID, Tunisie.
Aredo, D. B. (2000). Semantics of UML sequence diagram
in PVS. Technical report, Online Proc. of UML2000
Workshop on Dynamic Behavior in UML models: Se-
mantic Questions.
Cardoso, J. and Sibertin-Blanc., C. (2001). Ordering actions
in sequence diagrams of UML. In 23rd Int. Conf. on
Information Technology Interfaces, pages 3–14.
Cengarle, M. V., Graubmann, P., Wagner, S., and Munchen,
T. U. (2006). Semantics of UML 2.0 Interactions with
Variabilities.
Eichner, C., Fleischhack, H., Meyer, R., Schrimpf, U., and
Stehno, C. (2005). Compositional semantics for UML
2.0 sequence diagrams using Petri Nets. Lecture Notes
in Computer Science, 3530:133–148.
Grosu, R. and Smolka, S. (2005). Safety-liveness semantics
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
346
for UML 2.0 sequence diagrams. In 5th Int. Conf. on
Application of Concurrency to System Design, pages
6–14.
Haugen, Ø., Husa, K. E., Runde, R. K., and Stølen, K.
(2005). STAIRS towards formal design with sequence
diagrams. In Software and System Modeling, vol-
ume 4, pages 355–357. John Wiley & Sons, Inc.
Laleau R., P. F. (2002). Coming and Going from UML to
B : A Proposal to Support Traceability in Rigorous IS
Development. In 2nd International Conference of B
and Z Users, number 2272, pages 517–534. Springer.
Lano, K., Clark, D., and Androutsopoulos, K. (2001). UML
to B: Formal verification of object-oriented models.
In Proc. 4th Intl. Conf. Integrated Formal Methods
(IFM2004), number 2999, pages 187–206. Springer.
Ledang, H. and Souqui
`
eres, J. (2002). Contributions for
Modelling UML State-Charts in B. Lecture Notes in
Computer Science, (2335):109127.
Micskei, Z. and Waeselynck, H. (2011). The many mean-
ings of UML2.0 Sequence Diagrams: a survey. Soft-
ware & Systems Modeling, 10(4):489–514.
Sibertin-Blanc, C., Tahir, O., and Cardoso, J. (2005). In-
terpretation of UML Sequence Diagrams as Causal-
ity Flows. In Advanced Distributed Systems, 5th Int.
School and Symposium (ISSAD), number 3563, pages
126–140. Acta Press.
St
¨
orrle, H. (2003). Semantics of Interactions in UML 2.0.
In HCC, pages 129–136.
Tahir, O., Sibertin-Blanc, C., and Cardoso, J. (2005). A
Causality-Based Semantics for UML Sequence Dia-
grams. In 23rd IASTED International Conference on
Software Engineering, pages 106–111. Acta Press.
Whittle, J. and Schumann, J. (2000). Generating statechart
designs from scenarios. In ICSE ’00: Proceedings of
the 22nd international conference on Software engi-
neering, pages 314–323. ACM Press.
ExtendingCausalSemanticsofUML2.0SequenceDiagramforDistributedSystems
347
