Diagramme de séquence UML - comment représenter la réponse asynchrone
Si A envoie un message asynchrone à B comme par exemple, pour charger des images asynchrones dans l'interface utilisateur à partir du Web. Où doit aller le message de réponse?
Doit-il être également incliné ou direct? Et où serait l'activation de l'expéditeur (A)?
Il y a deux questions ici: 1. L'inclinaison de la ou des flèches et 2. Que faire de l'activation.
Les flèches doivent être inclinées si vous voulez représenter dans votre diagramme qu'il faut du temps pour que le message passe de A à B ou vice versa.
Si vous voulez simplement indiquer que le message est traité de manière synchrone, il suffit d'utiliser une tête de flèche ouverte sur le message.Lorsqu'un message (envoyé de A à B) est traité de manière synchrone, l'activation de A se termine dès que le message a été envoyé et recommence lorsque la réponse de B est reçue.
Cela suppose que A ne bloque pas en attendant la réponse, mais il pourrait effectuer un autre traitement en attendant la réponse.
Je les dessinais dans le cadre de mon travail. Nous avions une façon fixe de les faire. Je ne vais pas vous dire comment parce que chaque magasin Dang a sa propre façon de le faire. Je peux le prouver avec un recherche d'images google .
Une chose que vous remarquerez est que presque personne n'incline les flèches. Dans cette métaphore, une inclinaison serait un décalage et non une asynchronicité.
L'axe des y représente le temps. Async ne rentre pas vraiment dans ce diagramme car être async signifie que vous avez votre propre foutu axe y. Donc, tout ce que vous dessinez ici est une supposition. Mais nous essayons quand même.
Votre ligne "réponse ici" me dit que lorsque B se termine, vous vous attendez à ce que A soit toujours en cours de traitement et, parce que vous le mettez à la fin, à se terminer quand il voit que B répond.
Votre ligne "ou ici" me dit que lorsque B se termine, vous vous attendez à ce que A soit déjà terminé.
Vous ne savez probablement même pas ce qui se passera. Dans ces cas, la représentation la plus sûre n'est pas du tout une flèche de retour. Si vous avez un rappel vers A, il est plus logique d'avoir une flèche de retour. Vraiment, vous avez deux flux de contrôle différents marchant à travers A à ce point.
Traditionnellement, les diagrammes de séquence ont eu deux tâches. Pour illustrer le flux de contrôle et prévoir la durée de vie des objets afin de savoir quand il est sûr de les supprimer. Lorsque l'async est impliqué, la prévision de la durée de vie d'un objet devient très compliquée.
La chose la plus importante est que votre boutique ait une façon standard de le faire afin que vous puissiez vous comprendre. Si cette norme sort d'une version d'un livre UML, tant mieux. Cela signifie que vous avez un livre à disposition des nouveaux employés. Mais nous ne sommes pas dans votre boutique. Nous sommes sur des programmeurs.
Le terme async ne s'applique pas vraiment à ce niveau. Async décrit un événement (message ou autre) qui se produit indépendamment du flux principal du programme (ici, A ou B). Il s'agit d'un adjectif qui décrit les détails de mise en œuvre et le calendrier des événements externes par rapport à la conception de thread interne d'un client ou d'un serveur, et évoque des stratégies pour gérer de tels événements car le programme principal peut faire autre chose à l'époque.
Au niveau élevé lorsque nous parlons de messages entre le client et le serveur ou deux serveurs (et nous ne plongons pas dans les détails d'implémentation interne de l'un ou l'autre), nous pouvons parler de messages à sens unique, de demandes/commandes (c'est-à-dire de messages librement lancés) et de réponses. L'envoi d'un message asynchrone sur le Web n'existe pas - il s'agit simplement d'envoyer un message sur le Web, qui est soit une demande/commande ou une réponse, si vous voulez.
Premièrement, nous devons nous concentrer sur le comportement (y a-t-il une ou plusieurs réponses pour une demande/commande donnée) et le timing (combien de retard attendons-nous); c'est le haut niveau à retenir de l'interaction entre A et B.
Si nous voulons décrire le filetage interne de l'un ou de l'autre, nous pouvons illustrer, disons, une réponse reçue hors de l'activation. Cependant, pour être clair, ce n'est pas une propriété de la messagerie ou de l'interaction entre les deux, mais plutôt des détails internes de la façon dont A, dans ce cas, est mis en œuvre, qui peut en fait être hors sujet en fonction de ce que le diagramme est censé représenter.