Représenter une "attente jusqu'à" dans un diagramme d'activité en UML
Comment puis-je représenter un "attendre que le représentant du client soit disponible" dans le diagramme d'activité UML ci-dessous? Une solution en UML 1 ou UML 2 est acceptable.
Proposition 1
La simple ligne de retour à la deuxième condition "semble" fausse.
Proposition 2
J'ai également trouvé cette solution "plus propre".
(Je sais que le dernier point manque.)
À mon humble avis, il n'est en fait pas nécessaire d'inclure une conditionnelle ou une "boucle" pour l'état "d'attente":
Toute activité a besoin d'un certain temps jusqu'à ce qu'elle soit terminée. Si un représentant du client est disponible immédiatement, le temps de l'activité d'attente est nul, sinon, l'activité ne prendra que quelques minutes ou peut-être des heures. Mais le pouvoir du "zéro" est qu'il peut souvent être traité comme n'importe quel autre nombre, sans avoir besoin de distinctions artificielles.
Bien sûr, si vous souhaitez modéliser explicitement l'activité "Attendre", car dans votre système, quelque chose d'essentiellement différent se produira pendant une "attente réelle", optez pour votre solution 2.
Vos diagrammes sont-ils corrects?
La garde sur un nœud de décision doit être placée sur la queue de la ligne et non sur les nœuds ( voir UML 2.5 section 15.2.4). Ainsi, [free customer representative available] Sur le dessus du diamant doit être supprimé et les [yes] Et [no] Sortants deviennent [customer representative available] Et [customer representative not available].
Après cela, les deux diagrammes seraient formellement corrects:
La proposition 2 produirait le résultat escompté si et seulement s'il est garanti qu'un représentant client est disponible lorsque l'activité
waitest terminée. Ce n'est pas évident, il vaut donc mieux se diriger vers la gauche et placer le diamant de fusion en amont du diamant de décision, pour être sûr de ne pas continuer jusqu'à ce qu'un représentant soit disponible.La proposition 1 est tout à fait correcte. Les nœuds de contrôle dans un diagramme d'activité sont soit des nœuds de décision avec plusieurs flux sortants, soit des nœuds de fusion avec plusieurs flux entrants ( voir UML 2.5 section 15.3.2), mais heureusement, les deux peuvent être combinés en un seul diamant sur le diagramme ( voir UML 2.5 figure 15.34 dans la section 15.3.4.3). Il est cependant un peu moins lisible que des nœuds distincts.
Vous le savez déjà, mais vous auriez besoin d'un nœud final après le
order.
Mais est-ce vraiment le meilleur moyen?
Vos diagrammes reposent sur la compréhension humaine de l'activité wait (for representative). Mais je pense que nous convenons que l'attente n'est pas vraiment une activité mais plutôt une non activité.
Alternative 1: utilisez une approche événementielle à l'aide d'une accept-event-action appelée Customer representative available qui représente ce que vous attendez. Fusionnez le flux qui en sort avec votre flux normal. Attention: n'utilisez pas le TimeEvent tentant (symbole du sablier): il est destiné aux événements se produisant à un moment précis ( voir UML 2.5 section 13.4.10.1)
Alternative 2: représente ce que vous faites vraiment: vous trouvez un représentant client. C'est la manière simple de le montrer.
Alternative 3 (ma préférée): représente la vraie complexité d'un monde multitâche, avec l'utilisation de n fork et un contrôle de jointure =, et entre tout ce qui se passe en parallèle:
Si vous utilisez des couloirs de natation, je pense que vous n'avez besoin d'aucun mécanisme d'attente. Cela implique que le représentant du client doit être prêt à effectuer la tâche.
Voici une suggestion faite avec PlantUML/PlantText :
[~ # ~] modifier [~ # ~] Voici une autre suggestion ( source ) avec une sémantique d'attente plus explicite qui permet pour raccrocher.
Avoir un état "attendre", ou une activité d'attente, n'est pas invraisemblable, et selon le domaine, ce n'est pas rare non plus. Marquez-le comme tel et définissez la durée pendant laquelle l'État sera actif (c.-à-d. Combien de temps il retournera au point de décision).
Si le point de décision ne doit pas être explicitement exposé, vous pouvez reporter la décision et attendre l'état en une seule activité qui dépend de la disponibilité d'un opérateur.
Sur une note latérale; si le PO est une "démo" du flux réel évalué dans votre projet, il existe d'autres options pour les modèles et la modélisation de ce comportement qui peuvent être intéressantes à étudier, telles que;
- FSM, un état avec un événement qui fait passer la machine à l'état "passer commande"
- S'il y a plusieurs flux qui nécessitent une synchronisation, une jointure peut être une meilleure idée
Parfois, d'autres solutions peuvent être simplement un autre modèle, ou une refonte d'une sorte qui supprime l'état d'attente. Cela dit, la solution n'est souvent que l'état d'attente, car c'est le comportement du flux de processus modélisé (que ce soit par conception ou par analyse).
Sur la deuxième option ajoutée, le "attendre jusqu'à" nécessite intrinsèquement un test pour déterminer si la condition requise est remplie, je ne suis pas sûr que la deuxième option modélise cela de manière appropriée.
Vous devez utiliser un ReceiveSignalAction pour représenter la réception d'un signal qu'un consultant est prêt.
Désolé, aucun outil de modélisation disponible pour le moment, j'ajouterai le diagramme lorsque je serai assis sur mon ordinateur.