web-dev-qa-db-fra.com

Pourquoi un message <<créer>> est-il asynchrone dans les diagrammes de séquence UML?

Autant que je sache, la bonne façon de montrer une création d'objet dans un diagramme de séquence est avec une flèche asynchrone, par exemple,

enter image description here

Cependant, dans Java (et autres OO langages que j'ai utilisés), autant que je sache, une opération new() est bloquante.

J'ai remarqué que certaines références (Craig Larman) utilisent un message hybride (ligne pointillée avec flèche pleine), par exemple,

enter image description here

Surtout lorsqu'un constructeur est impliqué, il est important qu'un create soit un appel synchrone . Autrement dit, il reviendra lorsque le constructeur aura terminé. D'après ma compréhension des messages asynchrones en UML, le :A l'objet n'attendrait pas le constructeur de :B pour finir.

Mes étudiants posent souvent cette question, et je soupçonne qu'il y a une histoire derrière cela. Je suis curieux de savoir pourquoi il y a cette incohérence apparente.

umlsequence-diagram
7
Fuhrmanator

Chaque message UML dans un diagramme d'interaction a un MessageSort unique, qui s'excluent mutuellement (section 17.4.2):

synchCall
asynchCall
asynchSignal
créer un message
deleteMessage
répondre

La notation graphique du message est définie en fonction de MessageSort (section 17.4.4.1):

  • Un message asynchrone (messageSort est égal à asynchCall ou asynchSignal) a une tête de flèche ouverte.
  • Un message synchrone (messageSort est égal à synchCall) a une tête de flèche pleine.
  • Un message de réponse (messageSort est égal à réponse) a une ligne pointillée avec une tête de flèche ouverte ou remplie.
  • Un message de création d'objet (messageSort est égal à createMessage) a une ligne pointillée avec une tête de flèche ouverte.
  • Un message de suppression d'objet (messageSort est égal à deleteMessage) doit se terminer par un
  • ...

Donc, cette représentation graphique est une convention et vous ne serez pas trompé pour en tirer une sémantique! Si vous voyez un « create » message avec une tête de flèche ouverte, ce n'est pas parce que ce serait asynchrone, mais simplement parce que c'est la façon dont UML a décidé de représenter la création.

Je suis d'accord que c'est ambigu: cela ressemble à un message de réponse, et ce n'est pas cohérent avec le sens donné aux têtes de flèches. Peut-être une amélioration à suggérer au comité standard UML? Le marché n'a pas attendu: il existe déjà certains outils qui utilisent des flèches de messages synchrones normales.

8
Christophe