Guard Evaluation and Synchronization Issues in Causal Semantics for

UML2.X Sequence Diagrams

Fatma Dhaou

, Ines Mouakher

, J. Christian Attiogb

and Khaled Bsaies

University Tunis El Manar, Lipah, Faculty of Sciences Tunis, Tunis, Tunisia

LS2N, University of Nantes, Nantes, France

Keywords:

UML2.X Sequence Diagrams, Semantics, Combined Fragments, Guard Evaluation.

Abstract:

UML2.X sequence diagrams (SD) permit the modelling of behaviours of systems. With the combined frag-

ments (CF) that can be nested and aggregated in a single SD more complex behaviours can be created. How-

ever the standard interpretation and the consideration of all the aspects related to the CF are not obvious to

handle, this represses their proper use. We proposed in a previous work, a causal semantics based on partial

order theory, which is suitable for the computation of all possible valid traces for UML2.X sequence diagrams

with nested CF modelling behaviours of distributed systems. In this work, we deal with an important aspect

that is the guard evaluation and the synchronization between the lifelines that are complex issues.

1 INTRODUCTION

Context. The context of our work is the use of the

UML2.X sequence diagrams (SD) as a privileged

language that are adopted by the engineering and

designers in the modelling of behaviours of systems

due its intuitive use and its intuitive graphical repre-

sentation.

However, the standard semantics of SD that is deﬁned

by the Object Management Group (OMG) (Group,

2015) leaves several intentional variations points

to adopt the use of this language in the modelling

of different kinds of systems. These intentional

variations points lead sometimes to ambiguities that

induce some issues, which repress the proper use of

SD.

Motivation. We interested especially on the compu-

tation of partial order between the events for UML2.X

SD modelling behaviours of distributed systems. We

reported the inadequacy and the ambiguities of the

deﬁnitions of the standard semantics whose its rules

did not take into account of the independence of

the components involved into an interaction. For

the other works, they proposed two approaches

for the computation of the partial order. The ﬁrst

approach consists in ﬂattening the SD into several

basic SDs that are semantically equivalent ((Cengarle

and Alexander, 2004), (Knapp and Wuttke, 2006),

(øystein Haugen et al., 2005), (Harald, 2003)). The

second approach uses the concept of locations that is

borrowed from the Live Sequence charts formalism

((Cavarra and Filipe, 2004), (Juliana, 2006), (Harel

and Maoz, 2008)).

We have considered the most popular CF SEQ, ALT,

OPT and LOOP that permit to model respectively

sequential, alternative, optional and iterative be-

haviours. The standard deﬁnes weak sequencing

as the default composition operator for CF. Ac-

cordingly, most semantics retain this operator to

compose a combined fragment with the rest of the

diagram ((Harald, 2003), (øystein Haugen et al.,

2005), (Cengarle et al., 2005)). However the weak

sequencing operator can lead to non intuitive orders

between events. This explains that the most of the

existing semantics interpret the some of CF as in the

structured programming language. For instance the

ALT CF is considered as the IF-Then-Else construct

and in the loop CF strict sequencing is applied

between iterations. These non-standard interpretation

limit considerably the expressive power of CF and

some order between events is lost. Moreover, the

most of the existing approach did not deal explicitly

with nested CF whose complicate the determination

of the precedence relations between the events. In

our previous work, we proposed an extension of the

causal semantics to remedy to the insufﬁciencies of

the existing works and to deal with some issues of the

standard semantics. Indeed we have ﬁrstly interested

on computation of partial order between the events

of UML2.X SD that model behaviours of distributed

systems.

In this paper we interested on issues that are re-

lated to the consideration of constraints interactions

Dhaou, F., Mouakher, I., Attiogbé, J. and Bsaies, K.

Guard Evaluation and Synchronization Issues in Causal Semantics for UML2.X Sequence Diagrams.

DOI: 10.5220/0006708102750282

In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2018), pages 275-282

ISBN: 978-989-758-300-1

275

that guard some combined fragments. Indeed this as-

pect is often ignored by the most of the existing se-

mantics, (Aredo, 2002), (Harald, 2003), (Li et al.,

2004), (Grosu and Smolka, 2005), (Cengarle et al.,

2005), since it causes several inconsistencies. The

few semantics that have considered guards, have ei-

ther proposed approaches that are not convenient for

all kind of systems or they adopt some strict hypoth-

esis. In the semantics where only synchronous mes-

sages are considered, the guard evaluation does not

raise any issue. However, in the distributed systems

where the communication is mainly asynchronous it

must be handled with caution. Indeed, after the guard

evaluation in the case of an ALT, a synchronization

between the lifelines (that model the objects involved

in the interaction) must be ensured in order to prevent

a parallel execution of several operands.

Contribution. This paper extends our previous work

(Dhaou et al., 2015), (Dhaou et al., 2016), (Dhaou

et al., 2017). In (Dhaou et al., 2015), (Dhaou et al.,

2016) we have extended an existing semantics pro-

posed for UML 1.X (O.Tahir et al., 2005) to deal

with SD with the most popular combined fragments

(ALT, OPT and LOOP), by processing the SD as a

whole (without parsing the SD). We have proposed

several rules to derive the partial order between the

events. In (Dhaou et al., 2017), we have updated the

formalization of sequence diagrams in order to sup-

port nested CF, and we have generalized the previ-

ous rules for the derivation of partial order between

events.

We now propose some additional contributions

that consist, in proposing an approach to deal with

guard evaluation and synchronization issue in our

causal semantics that is dedicated to SD with nested

CF modelling behaviours of distributed systems.

Organization. The remainder of the article is struc-

tured as follows. In Section 2, we propose an

overview on our previous work. Section 3 is devoted

to the approach that we propose for guard evalua-

tion for SD with nested CF modelling behaviours of

distributed systems. In Section 4, we deﬁne the be-

haviour of SD. Then in Section 5, we we deal with

the synchronization issue. Before concluding in Sec-

tion 7, we present some related works in Section 6.

2 OVERVIEW ON THE

PREVIOUS WORK

The extended causal semantics (Dhaou et al., 2017) is

based on precedence relations that permit to compute,

for each event of an SD with nested CF its preceding

events, without parsing the SD and without making

syntactic restrictions on the considered CF (especially

for LOOP CF or nested structure that contains LOOP

CF that requires a special processing).

To deﬁne and formalize these precedence rela-

tions, we have proceeded as follows.

• We ﬁrst proposed a formalization of UML2.X

that is based on set theory notations. Thus an SD is

deﬁned as a tuple:

SD :

L,M,EV T,FCT s, FCT r,FCT l,OP,F,<

caus

,tree OP

where the elements depict respectively the set of

lifelines, the set of asynchronous messages, the set of

events, the function that permits to associate to each

message one sent event, the function that permits to

associate to each message one received event, the

function that associates to each event one lifeline (the

transmitter or the receiver), the set of the operands,

the set of the combined fragments, the causal relation

and the function that allows to structure the SD in the

form of a tree of operands,

• then we have encoded the SD into a tree structure,

such that the tree is composed by a set of linked

operands. Indeed, we consider the whole SD as a

root operand that we note OP

; we deﬁne the set

OP = (

i={1..n}

) ∪ {OP

}; where n is the number

of operands of the considered SD. The ﬁgure 2

represents the tree associated to the SD of the ﬁgure

1. The idea consists to associate a node to each CF

or operand. When building the tree of an SD, we

always have a root node that represents the complete

SD; the process is then breadth-ﬁrst. Note that the

operands of the CF ALT are independent, i.e they

have disjoint executions. Therefore, to simplify

the tree representation of the SD, we substitute the

node which should stand for these fragments with

the nodes representing their operands. They are

moved to the upper level. However, to distinguish

them, the operands of the same fragment have their

indexes built with the same preﬁx (it’s the case of the

operands OP21 and OP22 that belong to the same CF

ALT (see Fig.1). From the node of a current SD, the

consecutive fragments of the SD become the nodes of

the current node. Each fragment is either represented

as a node or it is represented by the nodes of its

operands. A node is associated to each CF that has

only one operand (for instance loop or opt). A CF

with more than one operand (for instance ALT CF) is

replaced with the nodes associated to its operands.

Each operand in an SD has a weight. For instance,

each operand of a SEQ, an ALT and an OPT CF have

a weight equal to 1, and an operand of a LOOP CF

has a weight equal to a value max, where max is

the maximum number of iteration of the considered

LOOP CF. The general deﬁnition of an operand in a

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

276

loop

alt

[0,3]

[G2]

[G3]

[G1]

L2 L3

loop

[0,2]

OP4.1

[G5]

OP00

OP11

OP21

OP22

opt

OP31

loop

[0,3]

OP5.1

[G6]

[G4]

Figure 1: Example of SD with nested CF.

combined fragment is given as follows:

Deﬁnition 1. (Operand in Combined Fragment)

We deﬁne a set of operands OP

in a CF F

as follows:

= {OP

i, j={1..k}

i j



guard

i j

,weight

i j

,EV T D

i j



}

where: i) k is the number of operands in CF Fi,

ii) weight

i j

is the weight of the operand OP

i j

, iii)

EV T D

i j

are the events that are directly contained in

an operand OP

i j

• ﬁnally we have deﬁned several relations and

functions that are required for the formalization of

the precedence relations. For instance some functions

permit to return some important informations in the

tree : i) the function ancestor permits to associate to

each operand all the operands where it is nested (its

ancestor operands in the tree); ii) the function brother

permits to identify the operands that belong to the

same CF ALT. In a given tree the brother operands

are the operands that belong to the same level and

that have the same index i. Hence, the operands of

the same sibling are not all necessarily brothers, since

some of them came from lower level when built the

tree. This function is used in the precedence relations

to enforce that the events that belong to different

operands of an ALT CF, or that have in their ancestor

operands that are brothers, must not be ordered.

Illustration 1: in Fig.1, ancestor[{OP

}] =

0, and

ancestor[{OP

}] = {OP

,OP

Illustration 2: in Fig.1, the operands OP

,OP

belong to the same CF ALT, thus they are brothers.

Figure 2: Tree associated to the SD of the ﬁgure 1.

brother[{OP

}] = {OP

}

The other functions and relations permit to return

some informations about the operands.

In the sequel we resume some of them that are re-

quired in this paper and we deﬁne a new ones.

We use the following functions to manipulate the

operands:

• EV T D permits to get the events that are directly

contained in each operand,

• EV T G permits to get all the events that are con-

tained in an operand including those which are

contained in its nested operands.

In the following we need to deﬁne a function that

is required later to deal with the evaluation of guards

and the synchronization issues.

We assume that each operand of a CF has only one

ﬁrst event. Intuitively, a ﬁrst event is an event that has

not a preceding events in the considered operand. We

deﬁne the function f irst that permits to get the ﬁrst

event of each operand: f irst : OP → EV T

ﬁrst={(X,e)|X ∈ OP ∧ e ∈ EV T G(X) ∧

(∀ e

)[e

∈ EV T ∧ e

∗

caus

e ⇒ e

/∈ EV T G(X)]}

The causal semantics (Dhaou et al., 2017) is based on

fourth precedence relations:

1. the synchronization relation < Sync allows to each

lifeline to synchronize its behaviour; it expresses

that a given message m is received if it was sent

previously,

2. the emission-emission relation < EE permits to

order two successive events emitted by the same

lifeline,

3. the reception emission < RE relation expresses

that the reception of an event by a lifeline causes

the emission of the event that is successive to it,

4. the hidden relations < Hcaus are the relations be-

tween the events of LOOP CF of the current it-

eration and the events of the previous iterations.

These relations appear when the LOOP operand is

Guard Evaluation and Synchronization Issues in Causal Semantics for UML2.X Sequence Diagrams

277

ﬂatten at least one time. They are due to the over-

lapping between the occurrence of the events of

different iterations of a loop CF.

In this paper, we propose to cover an important

aspect of CF that should not be disregarded: it is

the constraint interaction that guards CF. Indeed, the

evaluation of guards constraints the occurrence of the

events. There are two aspects to consider for the

guards: their evaluations and the effects of their eval-

uations on the occurrence of the events of the same

operand and the events of the other operands; this is

the synchronization issue.

3 GUARD EVALUATION

All kind of CF can be guarded. There are several

features that must be considered. They lie on how

to, and who must, evaluate the guard, when and how

many time the guard evaluation should be done.

The standard semantics states that the guard has to

be evaluated before the occurrence of the ﬁrst event

of each operand. This deﬁnition is ambiguous. More-

over the ﬁrst event of an operand was not clearly de-

ﬁned. We propose an approach for guard evaluation

that is faithful with the standard semantics. In our

approach we have deﬁned the ﬁrst event with some

restrictions. We consider the guard evaluation as an

internal operation that is not visible from the envi-

ronment. Hence, we use ﬁctitious events (τ events)

to deal with guard evaluation as well as the synchro-

nization issue. Moreover the ﬁctitious events will en-

sure the synchronisation between the operands once

the guard is evaluated.

For each operand, every ﬁctitious event belongs to

the same lifeline of the ﬁrst event of the considered

operand; it is placed above the ﬁrst event. For each

guarded operand, the guard is evaluated one time by

the lifeline of its ﬁctitious event. For an ALT CF,

the guard of each operand is evaluated one time by

the corresponding ﬁctitious event. If we have, si-

multaneously, several operands with true guards and

whose their ﬁctitious events satisfy the precedence

constraints, only one ﬁctitious event will be chosen to

occur in a non-deterministic way. This is guaranteed

by our semantics since it is an interleaving

seman-

tics.

In the sequel we provide the formal deﬁnition of

the ﬁctitious events as well as the precedence relations

that are caused by their introduction in the SD.

i.e. two events may not occur at exactly the same time.

3.1 Formal Deﬁnition of Fictitious

Events

For each guarded operand OP

i j

, we opted for the use

of two ﬁctitious events (positive and negative) (as de-

picted in (Fig.3), since they have distinct execution

effects. The positive ﬁctitious event (τ

i j

) occurs when

the guard is evaluated to True, and permits to the

events of the corresponding operand to occur; the neg-

ative ﬁctitious event (τ

−

i j

) occurs when the guard is

evaluated to False, and permits to prohibit the occur-

rence of the events of the concerned operand. In the

following, we deﬁne some sets and functions that are

used in the sequel.

• Fic pos and Fic neg represent, respectively the

sets of positive and negative ﬁctitious events, such

that Fic = Fic pos ∪ Fic neg

• We deﬁne two partial bijective functions that per-

mit to associate respectively to each operand its

positive and negative ﬁctitious events.

– Fct τ pos : OP 7→ Fic pos: for each operand

we associate a positive ﬁctitious event,

– Fct τ neg : OP 7→ Fic neg: for each operand

we associate a negative ﬁctitious event,

• Fct lτ : Fic → L permits to associate to each ﬁc-

titious event its correspondent lifeline. Each ﬁcti-

tious event belongs to the lifeline of the ﬁrst event

of the considered operand,

• <

: denotes the partial order relationship that con-

tains the precedence relationships that are caused

by the addition of the ﬁctitious events. This rela-

tion is detailed in the sequel.

3.2 The Precedence Relations Induced

by the Introduction of Fictitious

Events

The ﬁctitious events are inserted between the ﬁrst

event of an operand and its preceding events. This

causes new precedence relations (i.e new couples of

events) between them and the events of the SD.

The precedence relation <

is decomposed into

two precedence relations <

τ1

and <

τ2

that are

detailed in the following.

For an operand OP

i j

, the ﬁctitious events τ

i j

and

−

i j

are both located between the ﬁrst event of OP

i j

and all its preceding events. Consequently, they

inherit all the preceding events of the ﬁrst event of the

considered operand. These new precedence relations

are computed from a relation noted <

τ1

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

278

Illustration: in Fig.3, according to the <

relation-

ship, the event !m1 precedes the ﬁrst event !m2 of the

LOOP operand ; by inserting the ﬁctitious events (τ+

and τ−), to evaluate the guard of the LOOP operand,

the event !m1 becomes the preceding event of both τ+

and τ− events.

τ1

{(e,e

)|e ∈ EV T ∧ e

∈ Fic ∧ (∃X)[(X ∈ OP)

∧ (e

= Fct τ pos(X) ∨ e

= Fct τ neg(X))

∧ ((e, f irst(X )) ∈<

caus

)]}

Moreover, the positive ﬁctitious event τ

i j

becomes

the only preceding event of the ﬁrst event, this is com-

puted from <

τ2

relation.

Illustration: in Fig. 3, τ

becomes the only preced-

ing event of the event !m2.

τ2

{(e,e

)|e ∈ Fic pos ∧ (∃X)

[X ∈ OP ∧ e = Fct τ pos(X ) ∧ (e

= f irst(X))]}

To recapitulate, the relation <

τ2

permits to

generate new precedence relations that must be

added to <

caus

relationships, however the relations

hcaus

are overloaded with <

τ1

relation-

ship. Up to now, we deﬁne a new relation <

causG

follows.

causG

Sync

∪ <

REG

∪ <

EEG

∪ <

hcausG

∪ <

τ2

The relations <

REG

, <

EEG

, <

hcausG

are obtained

by overloading the <

, <

hcaus

relations with

the <

τ1

relation. That means the ordering of events

depends on the cumulative rules of the relationships.

The valid traces are those which can be generated

satisfying these orders.

The deﬁnitions provided by the standard for the

computation of traces of an SD are not formalized.

The rules that we deﬁned in this paper can be adjusted

to formalize the deﬁnitions of the standard by restor-

ing some constraints that we relaxed. In the same way,

these rules can be adapted for any kind of semantics

by strengthening or weakening some constraints. The

ordering of events depends on the cumulative rules of

the relationships. The valid traces are those which can

be generated with respect to these orders.

The semantics deﬁned in this paper assumes that all

the behaviour is explicitly speciﬁed in the diagram.

The behaviour that is not modelled is considered as

invalid.

4 BEHAVIOUR OF SEQUENCE

DIAGRAMS

The behaviour of a given SD is a set of traces. The

trace is a set of events occurrences. The checking

L1 L2

loop

[0,2] G

OP00

OP11

Figure 3: Fictitious Events.

of the occurrence of all the preceding events for an

event constraints its occurrence. However its occur-

rence depends on other constraints, such as the value

of its state, that we need to deﬁne precisely, and the

guard evaluation if it is about an event that belongs to

guarded CF.

4.1 The State of an Event

According to a run, an event which belongs to a ba-

sic SD can have two obvious basic states: occurred

or not yet occurred. However, these basic states are

not sufﬁcient to express the state of an event in an

SD with sophisticated structures (nested CF). Indeed,

each event that belongs to such SD can be: either not

yet occurred, or occurred or ignored one or several

times (if it belongs to LOOP operand of nested CF

that contains LOOP operand), or consumed. Then, the

variable state is deﬁned as follows.

state : EV T → NAT

Depending on the precedence relations on events, we

can deﬁne which event should be run according to

their state. The initial value of the state of each event

corresponds to its maximal value of occurrence in

each run. The state of an event is decreased when-

ever it is occurred or ignored. To describe the state

of an event e, we use the following vocabulary: i) not

yet occurred, ii) occurred: if the event e is executed or

ignored one or several times, iii) consumed: when the

state of the event is equal to zero. During its execu-

tion, an SD can be in one state among the following

states: i) an initial state, when all its events are not

yet occurred, ii) an intermediate state, iii) a ﬁnal state,

when all its events are consumed.

The notion of state is very important, indeed, it con-

straints the occurrence of a given event (for instance

we decrement the state of an event whenever it is oc-

curred, or if we want to prohibit its occurrence); it

also serves to indicate the location of the considered

event; this information is useful especially when we

have several nested LOOP CF. This notion is also used

for other purposes that we precise in the sequel.

Guard Evaluation and Synchronization Issues in Causal Semantics for UML2.X Sequence Diagrams

279

4.2 The Occurrence of Events

An event occurs under some trigger conditions

and produces some execution effects. The textual

description of the deﬁnition of an event in a given SD

with nested CF is done as follows.

The Occurrence of a Normal Event: the trigger

conditions consist in checking that:

i) the preceding events of the current event are

occurred (executed or ignored),

ii) the current event is not yet consumed.

The Occurrence of a Fictitious Events: The ﬁcti-

tious events (positive and negative) have additional

executions effects, indeed we must add a trigger

condition in which we check the value of guard of the

considered operand.

The execution effects consist in:

i) updating the state of the event,

ii) updating the lifeline of the current event.

The ﬁctitious events of an ALT or a LOOP CF have

additional execution effects to deal with the synchro-

nization issue that we explain in the sequel.

5 SYNCHRONIZATION ISSUE

For an ALT and a guarded LOOP CF, an important

issue should be handled after the guard evaluation,

is the synchronization between the lifelines covered

by them. Indeed, the standard semantics of an ALT

CF imposes that only one operand must be executed

among several potential operands. When none guard

is True, the CF is omitted. In the context of SD mod-

elling behaviours of distributed system, since the life-

lines involved in the interactions are independent, a

synchronization issue arises. Therefore, in the context

of distributed components, when the guard is evalu-

ated, the decision must be propagated properly to the

other lifelines to prevent a parallel execution of events

that belongs to distinct operands, and the emergence

of unspeciﬁed behaviours in the implementation.

Moreover, for the guarded LOOP operand, the events

inside the operand are executed while the guard is

evaluated to True and the maximal number of itera-

tions is not reached. The LOOP CF represents a recur-

sive application of the WEAK SEQUENCING operator,

thus the traces that contain an overlapping between

the occurrence of the events of different iterations are

possible. Hence, once the guard become False, the

events of the previous iterations that are not yet oc-

curred must occur, while the events of the remaining

iterations must not occur.

In the sequel we explain how the ﬁctitious events

are used to ensure the synchronization.

1. The execution effect of a positive ﬁctitious event

of a given operand of an ALT CF should: i) update

its state, and its lifeline; ii) update the state of the

negative ﬁctitious event of the same operand for

which it belongs, iii) decrease the state of each

event of the brother operands in order to prohibit

the occurrence of the events that are contained in

them (i.e to ignore them),

2. The execution effect of a negative ﬁctitious event

of an ALT CF should decrease the state of all the

events of the considered operand in order to ig-

nore them.

3. The execution effect of a positive ﬁctitious event

of a LOOP CF should: i) update its state by de-

creasing it, ii) update its lifeline, iii) update the

state of the of the negative ﬁctitious event of the

same operand,

4. The execution effect of a negative ﬁctitious event

of a LOOP operand should decrease the state of

each event of the considered operand in the two

following cases:

i) if the guard is false from the beginning: none it-

eration of the LOOP operand is executed, hence we

decrement the state of each event of the operand

including the state of the events that belong to the

nested operands of the considered operand (if they

exist); ii) if the guard changes its value and be-

comes false during the iterations: the events of

the current iteration must ﬁnish their occurrences

(if we have some messages that are already sent,

then their corresponding received events must oc-

cur), and the events of the remaining iterations

must not occur.

The use of ﬁctitious events causes new precedence re-

lations that must be handled. However the ﬁctitious

events give us a high ﬂexibility in deﬁning execution

strategies of the events. Moreover by ensuring the

tasks of evaluating guard and the synchronization be-

tween the lifelines, this permits us to deﬁne for the

events of the SD a same shape (same trigger condi-

tions and same execution effects).

6 RELATED WORK

The deﬁnitions that are given by the standard seman-

tics (Group, 2015) concerning the guard evaluation

are imprecise. This opens the door to the proposition

of several approaches by the existing semantics that

deal differently with this issue. However these ap-

proaches are not convenient for all kinds of systems.

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

280

The existing semantics that are proposed in the litera-

ture for SD are of two categories (Zolt

an and H

ene,

2011): the semantics of the ﬁrst category are compo-

sitional ((Cengarle and Alexander, 2004), (Knapp and

Wuttke, 2006), (øystein Haugen et al., 2005), (Harald,

2003), (Eichner et al., 2005), (Youcef, 2006), (Fer-

nandes et al., 2007), (Shen et al., 2008)) such that they

proceed to the parsing of the SD with CF into several

basic SDs, then the semantics of an SD is mechani-

cally built from the semantics of its constituent. The

constituents are ordered and combined by the weak

sequencing operator. In these semantics the guards

are implicitly evaluated, hence several hidden issues

are not treated explicitly.

In the semantics of the second category ((Cavarra

and Filipe, 2004), (Juliana, 2006), (Harel and Maoz,

2008)), the SD is treated as a whole, and guards

are explicitly evaluated. However some of them ap-

ply syntactic restrictions to avoid many inconsisten-

cies. For instance, in the approach of (øystein Hau-

gen et al., 2005), the guards are handled as local con-

straints. Contrarily to our approach their semantics

allows non-local choices. However, it is not speciﬁed

how to handle constraints if several guards are true

simultaneously. In the works of (Cavarra and Filipe,

2004), (Juliana, 2006), (Shen et al., 2008), each life-

line can make its choice independently, however they

impose an ordered guard evaluation of the operands

(from top to bottom, and the ﬁrst one evaluated as true

be chosen). In (Eichner et al., 2005), the authors use

a black box semantics to interpret CF, that consists to

consider the CF as an atomic event, thus the behaviour

of a CF does not interfere with the behaviours out-

side the CF. In some works, the authors adopt a non-

standard interpretation of the ALT and the LOOP CF.

In (Youcef, 2006), (Huszerl et al., 2008), (Cavarra and

Filipe, 2004), (Maoz et al., 2011), the authors trans-

form the ALT CF into an IF − T HEN − ELSE con-

struct, hence there is no problem of synchronization

between the lifelines; moreover they do not consider

LOOP operand with guard that requires a special pro-

cessing. In (Group, 2005), the authors deﬁne a deter-

ministic ALT. In (Youcef, 2006), the authors use strict

sequencing rather than weak for the LOOP CF to avoid

a pathological case of divergence in LOOP combina-

tion when using asynchronous communication. Simi-

larly, in (Knapp and Wuttke, 2006), the authors deﬁne

a new CF SLOOP that enforces strict sequencing be-

tween the iterations. Hence a synchronization on en-

tering and exiting CF is imposed. In (Juliana, 2006),

the proposed approach considers a smaller number of

CF (ALT, PAR, SEQ, and state invariants). The authors

did not deal with synchronization issue and they did

not consider the LOOP CF that requires a special pro-

cessing for the deﬁnition of preceding events of each

event. In our approach, we interpret the LOOP and

ALT CF as in the standard semantics, differently of

the interpretation in the structured programming lan-

guages. We deal with ALT CF having several true

guards simultaneously and we deal with guarded loop

CF. The guard evaluation is explicit. For an ALT CF

the guard evaluation is done in one step to ensure that

only one of the operands is chosen.

7 CONCLUSION

The causal semantics that we have proposed in our

previous work (Dhaou et al., 2017), the meaning of

SD with nested CF (ALT, OPT, LOOP) modelling be-

haviours of distributed systems is unambiguously in-

terpreted using the partial order relations. The prece-

dence relations allow to compute all possible valid

traces for SDs with nested CF that model behaviours

of distributed systems, by avoiding the parsing of SD

equipped with (ALT, OPT, LOOP) CF, hence the com-

pact syntactic representation is preserved. The pro-

posed semantics can serves as basis for the derivation

of traces of UML2.X SD, as well as for the deﬁnition

of an operational semantics that facilitates the analy-

sis of the SD.

In this paper we extended our semantics to cover

an important aspect that is the guard evaluation and

it consequences. This aspect is tackled with different

manners by the existing semantics that are not usually

appropriate in our context where the components are

distributed. We are developing a plug-in for autom-

atizing the computation of precedence relationships

between the events of SD with nested CF. We plan to

implement the semantics above in Event-B (Abrial,

1996), (Butler, 2008) to enable rigorous model analy-

sis, the checking of the correctness of the model and

some properties using the formal techniques of Event-

B and its various tools Rodin: with a theorem-prover,

and with ProB model-checker.

REFERENCES

Abrial, J.-R. (1996). The B Book. Cambridge University

Press.

Aredo, D. B. (2002). A framework for semantics of uml se-

quence diagrams. in PVS Journal of Universal Com-

puter Science (JUCS), pages 674–697.

Butler, M. (2008). Incremental design of distributed sys-

tems with event-b. Lecture Notes in Marktoberdorf

Summer School.

Cavarra, A. and Filipe, J. K. (2004). Formalizing liveness-

enriched sequence diagrams using asms. In Abstract

Guard Evaluation and Synchronization Issues in Causal Semantics for UML2.X Sequence Diagrams

281

State Machines 2004. Advances in Theory and Prac-

tice, 11th International Workshop, Lutherstadt Witten-

berg, Germany, Proceedings, pages 62–77.

Cengarle, M. V. and Alexander, K. (2004). Uml 2.0 interac-

tions: semantics and reﬁnement. Technische Univer-

sitat M

unchen, pages 85–99.

Cengarle, M. V., Graubmann, P., Wagner, S., and M

unchen,

T. U. (2005). Semantics of uml 2.0 interactions with

variabilities.

Dhaou, F., Mouakher, I., Attiogb

e, C., and Bsaies, K.

(2015). Extending causal semantics of uml2.0 se-

quence diagram for distributed systems. Proceedings

of the 10th International Conference on Software En-

gineering and Applications, Colmar, Alsace, France,

pages 339–347.

Dhaou, F., Mouakher, I., Attiogb

e, C., and Bsaies, K.

(2016). Reﬁnement of UML2.0 sequence diagrams

for distributed systems. In Proceedings of the 11th

International Joint Conference on Software Technolo-

gies (ICSOFT 2016) Lisbon, Portugal, pages 310–

318.

Dhaou, F., Mouakher, I., Attiogb

e, C., and Bsaies, K.

(2017). A causal semantics for UML2.0 sequence dia-

grams with nested combined fragments. pages 47–56.

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:133148.

Fernandes, M., Tjell, S., Jorgensen, J. B., and Ribeiro, O.

(2007). Designing tool support for translating use

cases and uml 2.0 sequence diagrams into a coloured

petri net. In 6th Int.Wsh. on Scenarios and State Ma-

chines. IEEE Computer Society.

Grosu, R. and Smolka, S. (2005). Safety-liveness semantics

for uml 2.0 sequence diagrams. In 5th Int. Conf. on

Application of Concurrency to System Design, pages

6–14.

Group, O. M. (2005). Omg uniﬁed modeling language (omg

uml), superstructure version 2.5.

Group, O. M. (2015). Omg uniﬁed modeling language (omg

uml), superstructure version 2.2.

Harald, S. (2003). Semantics of interactions in uml 2.0. In

HCC, pages 129–136.

Harel, D. and Maoz, S. (2008). Assert and negate revis-

ited: modal semantics for uml sequence diagrams. In

Software and System Modeling, pages 237–253. John

Wiley & Sons, Inc.

Huszerl, G., Waeselynck, H., and Zolt

Egel, Andr

as Kvi,

Z. M. (2008). Reﬁned design and testing framework,

methodology and application results.

Juliana, K. F. (2006). Modelling concurrent interactions.

Theor. Comput. Sci., pages 203–220.

Knapp, A. and Wuttke, J. (2006). Model checking of uml

2.0 interactions. In K

uhne, T., editor, Models in Soft-

ware Engineering, pages 42–51. Springer.

Li, X., Liu, Z., , and He., J. (2004). A formal semantics

of uml sequence diagram. In Australian Software En-

gineering Conference IEEE Computer Society, pages

168–177.

Maoz, S., Harel, D., and Kleinbort, A. (2011). A compiler

for multimodal scenarios: transforming lscs into as-

pectj. ACM Trans. Softw. Eng. Methodol., pages 18:1–

18:41.

O.Tahir, C.Sibertin-Blanc, and J.Cardoso (2005). A

causality-based semantics for uml sequence siagrams.

In 23rd IASTED International Conference on Soft-

ware Engineering, pages 106–111. Acta Press.

øystein Haugen, Husa, K. E., Runde, R. K., and STAIRS

(2005). Towards formal design with sequence dia-

grams. In Software and System Modeling, volume 4,

pages 355–357. John Wiley & Sons, Inc.

Shen, H., Virani, A., and Niu, J. (2008). Formalize uml2

sequence diagrams. 11th IEEE High Assurance Sys-

tems Engineering Symposium, Nanjing, China, pages

437–440.

Youcef, H. (2006). Branching time semantics for uml

2.0 sequence diagrams. Lecture Notes in Computer

Science: Formal Techniques for Networked and Dis-

tributed Systems, pages 259–274.

Zolt

an, M. and H

ene, W. (2011). The many meanings

of uml2.0 sequence diagrams: a survey. Software &

Systems Modeling, pages 489–514.

ENASE 2018 - 13th International Conference on Evaluation of Novel Approaches to Software Engineering

282