Exemples de diagrammes d'activité

Un pipeline de build est le premier exemple le plus clair parce que la concurrence y est réelle et non théorique. Les tests unitaires, le linting et l'analyse de dépendances tournent vraiment en même temps, rien en aval ne peut démarrer avant que les trois soient finis, et tout le monde l'a déjà vu se produire.

Le travail est fait par les deux barres pleines. Celle du haut est une bifurcation : un jeton arrive et trois repartent, donc les trois branches s'exécutent. Celle du bas est une jonction : elle attend qu'un jeton soit arrivé sur chaque arête entrante avant d'en laisser un continuer. Remplacez l'une ou l'autre par un losange et le diagramme affirme désormais quelque chose de faux - un losange se déclenche au premier jeton et n'attend jamais.

Notez les deux noeuds finaux distincts. Un build en échec et un build déployé sont deux fins différentes, et les dessiner en deux disques cerclés est à la fois légal et plus clair que de les ramener tous deux vers un seul. UML ne limite pas le nombre de noeuds finaux d'activité qu'une activité possède.

La plupart des processus métier ne sont pas concurrents. Ce sont des décisions à plusieurs issues qui se rejoignent ensuite, et c'est la forme ci-dessous.

Trois choses de ce diagramme sont délibérées. Les gardes sont exhaustives : [sev 1], [sev 2 or 3] et [else] couvrent à elles trois tous les tickets, donc aucun jeton ne peut arriver au losange sans issue. Un jeton sans arête sortante activée est un processus bloqué, et c'est un défaut qui vaut la peine d'être attrapé sur le papier.

Le losange du bas est une fusion, pas une jonction, et la différence compte : un seul des trois chemins porte jamais un jeton, donc attendre les trois se bloquerait immédiatement. La règle est facile à retenir - un losange ferme ce qu'un losange a ouvert, et une barre ferme ce qu'une barre a ouvert.

Enfin, chaque action est une locution verbale à l'impératif : « Alerter l'astreinte », pas « Alerte de l'astreinte ». Les substantifs s'infiltrent quand quelqu'un décrit un système plutôt qu'un processus, et un diagramme de substantifs est un diagramme de classes qui a pris la mauvaise forme.

La paire de noeuds de fin est le détail que la plupart des premiers diagrammes ratent, et l'erreur est invisible : le diagramme a toujours l'air juste.

Après la bifurcation, deux jetons circulent. La branche d'audit atteint une fin de flux - le cercle barré - qui consomme ce jeton et rien d'autre. La branche client atteint une fin d'activité, le disque cerclé, qui termine toute l'activité et abandonne tous les autres jetons.

Mettez le disque cerclé sur la branche d'audit à la place, et le diagramme dit maintenant que la commande est abandonnée dès que la ligne de journal est écrite. Rien n'y paraît faux, et c'est exactement pourquoi cette distinction vaut d'être apprise une fois : une fin de flux pour une branche latérale qui se termine simplement, et une fin d'activité seulement là où vous voulez dire « nous avons fini ».

Ces trois-là couvrent les formes dont presque tout diagramme d'activité est fait. Ce qui change entre eux et le vôtre, ce sont les étiquettes ; ce qui ne devrait pas changer, c'est la discipline sur le périmètre.

Si le public est composé d'analystes métier plutôt que d'ingénieurs, le même processus gagne en général à être dessiné en BPMN, qui a une sémantique d'événements plus riche et qui est ce qu'un moteur de processus exécutera. Les deux notations répondent à la même question pour des salles différentes.