Discussion :

[YuGiOhJCJ]

Bonjour,

dans un diagramme de séquence UML, on a un ordre partiel sur les spécifications d'occurrence comme on peut le lire dans [1] :
"A partial order of OccurrenceSpecifications is defined by a set of GeneralOrdering."

Par contre, il serait possible d'obtenir un ordre total en simplifiant ces diagrammes de séquence d'après [2] :
"There is a total ordering among OccurrenceSpeciations of a
basic sequence diagram because concurrency, branches and
loops do not appear in basic sequence diagrams."

Le problème, c'est que je ne suis pas d'accord avec [2].
En effet, la simplification des diagrammes de séquence proposée est telle que seuls les éléments suivants apparaissent :
-lignes de vie
-spécifications d'occurrence
-spécifications d'exécution
-messages synchrones
Je parviens avec ces seuls éléments à ne pas obtenir un ordre total.
Il suffit de prendre un exemple avec 3 lignes de vie et 2 messages :
(A)

(B)

On nomme les spécifications d'occurrence ainsi :
-om1s: pour la propriété sendEvent du message m1
-om1r: pour la propriété receiveEvent du message m1
-om2s: pour la propriété sendEvent du message m2
-om2r: pour la propriété receiveEvent du message m2
Dans (A), on se retrouve avec un ordre total :
car pour tout x et y appartenant aux spécifications d'occurrence, on a x<=y ou y<=x
Dans (B), on se retrouve avec un ordre partiel :
car pour x=om1s et y=om2s on ne sait pas si x<=y ou y<=x

Qu'est-ce que vous en pensez?

Merci.

[1] OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.4.1, http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF/
[2] Detecting Duplications in Sequence Diagrams Based on Suffix Trees, http://sei.pku.edu.cn/~liuhui04/publ...ceDiagrams.pdf

[bruno_pages]

je ne comprends pas votre remarque, le temps s'écoule du haut vers le bas, il n'y a donc aucune ambiguïté sur l'ordre des messages dans vos deux diagrammes.

De plus vous semblez supposez dans A que send-m2 est la conséquence de receive-m1, mais rien ne l'indique à cause de l'absence des spécifications d'exécution

[YuGiOhJCJ]

Sur une même ligne de vie, je suis d'accord que l'ordre des messages est respecté comme le dit [1] :
"The order of OccurrenceSpecifications along a Lifeline is significant denoting the order in which these
OccurrenceSpecifications will occur."
ou encore :
"OccurrenceSpecifications are ordered along a Lifeline."

Mais lorsqu'on considère plusieurs lignes de vie, d'où partent des messages, rien ne dit que le message partant de la première ligne de vie part avant l'autre comme on peut le lire dans [1] :
"The semantics of the Lifeline (within an Interaction) is the semantics of the Interaction selecting only OccurrenceSpecifications of this Lifeline."

Ainsi, (B) pourrait être représenté ainsi :
(C)

Et la sémantique serait la même.

Je n'ai pas trouvé une information sur le standard UML disant que l'ordre des spécifications d'occurrence est respecté de façon globale sur toutes les lignes de vie à la fois. Si quelqu'un peut citer un passage qui le dit je suis preneur.

Non, je ne suppose pas forcément que send-m2 est la conséquence de receive-m1 dans (A). Il est possible de ne pas écrire les spécifications d'exécution. Il y a beaucoup d'exemples dans [1] qui n'affichent aucune spécification d'exécution (figures 14.16, 14.22, ...).

Est-ce que vous êtes d'accord qu'il y aurait un ordre total comme le dit [2] ?