Diagramme d'activités UML
Le diagramme d'activités UML modélise le déroulement d'un traitement à l'intérieur d'un seul système: la suite des actions, les décisions qui les aiguillent, les branches qui s'exécutent en parallèle et les objets qui circulent. Il appartient au modèle UML, où il réalise un cas d'utilisation, et il repose sur une sémantique de jetons: chaque nœud offre puis accepte un jeton le long des arêtes. Trois traits le séparent d'un logigramme qui lui ressemble: les gardes s'écrivent entre crochets sur les arêtes, les barres de bifurcation et de jonction expriment une concurrence réelle et un flux d'objets suit le flux de contrôle. On le lit à trois niveaux d'abstraction, de la vue d'entreprise à la vue système, et sa valeur se concentre dans les niveaux bas, là où un modèle devient assez précis pour être simulé ou exécuté.
Objectif
Le diagramme spécifie de manière formelle comment un cas d'utilisation s'accomplit à l'intérieur d'un système: l'ordre des actions, les conditions qui aiguillent le flux, les traitements simultanés qui doivent se resynchroniser et les objets qui passent d'une action à l'autre. C'est un artefact de modèle, rattaché à un cas d'utilisation dans le modèle UML. Sa sémantique de jetons le rend exploitable jusqu'au détail exécutable, et c'est aussi ce qui le sépare d'un logigramme qui aurait la même allure.
Usage
Quand l'utiliser
- Réalisation d'un cas d'utilisation: montrer le comportement interne qui tient la promesse du cas.
- Concurrence réelle dans la logique: deux traitements simultanés qui doivent se resynchroniser, portés par une barre de bifurcation.
- Aiguillage par conditions gardées: la condition, décidée en amont, s'inscrit entre crochets sur l'arête.
- Artefact intégré au modèle UML: la logique se trace vers le cas d'utilisation et le modèle de classes autour.
Quand ne pas l'utiliser
- Audience non technique à mettre d'accord sur le processus: la formalité n'achète rien dans ce cas, prendre le logigramme.
- Des participants indépendants échangent des messages par-delà une frontière organisationnelle: c'est une collaboration, prendre BPMN.
- La question porte sur ce qui gouverne et exécute une fonction: prendre IDEF / IGOE.
Description
Un flux de contrôle et d'objets dans un seul système
Le diagramme est un graphe de nœuds reliés par des arêtes, animé par une sémantique de jetons: un nœud offre un jeton, le suivant l'accepte, et c'est cette circulation qui porte le sens. Le flux part d'un nœud initial, traverse des actions et s'achève sur un nœud de fin d'activité; les décisions sont des losanges, les barres de bifurcation et de jonction des traits épais et un nœud d'objet montre un objet qui passe d'une action à l'autre. C'est l'une des notations de la modélisation des processus, celle qui vit dans le modèle d'un système.
Deux propriétés le séparent d'un logigramme qu'il imite. La garde décide, le losange ne fait qu'aiguiller: la condition, écrite entre crochets sur l'arête, dirige le flux sur la branche dont elle est vraie. Et la barre de bifurcation exprime une concurrence réelle, deux branches qui s'exécutent en même temps et se rejoignent à la jonction, là où un logigramme ne sait que poser deux séquences côte à côte. S'y ajoutent le flux d'objets et l'appartenance au modèle UML, où le diagramme réalise un cas d'utilisation. Les partitions, ou couloirs, nomment qui exécute une action mais ne distinguent pas la notation: le logigramme, BPMN et le diagramme d'activités les acceptent tous.
Les trois niveaux
Un modèle de processus se construit à trois niveaux d'abstraction, et le diagramme d'activités n'a pas la même valeur à chacun. Au niveau haut, d'entreprise ou de contexte, le modèle donne une compréhension générale du processus et de ses rapports avec les processus voisins; la sémantique formelle n'y sert à rien, et une cartographie de processus ou un logigramme conviennent mieux. Au niveau opérationnel, le modèle détaille les activités et nomme tous les aboutissements, exceptions et chemins alternatifs compris: c'est là que le diagramme gagne sa place, les décisions gardées aiguillant les exceptions et une barre de bifurcation montrant les branches réellement parallèles. Au niveau système, le plus bas, le modèle devient assez précis pour servir de base à une simulation ou à une exécution, et la sémantique de jetons rend ce niveau atteignable.
Le diagramme d'activités est donc un artefact des niveaux opérationnel et système: il élabore une conception retenue et la pousse jusqu'au détail exécutable, sans cadrer le contexte d'entreprise.
Considérations IA
Deux usages tiennent. La première ébauche: à partir de la description écrite d'un cas d'utilisation, un modèle de langage propose un graphe d'actions, de décisions et de fins que l'analyste corrige. Et la vérification de forme, mécanique, se délègue bien: toute bifurcation a-t-elle sa jonction, toute décision porte-t-elle des gardes sur ses sorties, une action reste-t-elle sans arête entrante?
Ce qui ne se délègue pas tient au sens. Décider que deux branches sont réellement concurrentes engage une connaissance de la façon dont le travail s'exécute. Et la question qui précède tout, un seul système ou des participants qui échangent des messages, décide entre ce diagramme et BPMN: elle se règle sur le terrain.
Vous trouverez plus de détails dans notre tutoriel BPMN.
Exemples
La validation d'une commande chez un détaillant suisse en ligne, à l'intérieur de ses propres systèmes. Le concept que le dessin rend visible est la concurrence réelle: sur une commande en stock, deux traitements se lancent en même temps et doivent se rejoindre avant la confirmation.
La commande, nœud d'objet portant un total de CHF 1'250, circule d'une action à l'autre. Réserver le stock et encaisser n'ont pas à s'attendre, quand un logigramme n'aurait pu que les mettre en séquence.
Un seul point décide que ce dessin est un diagramme d'activités: le paiement est traité dans le système du détaillant. Si le prestataire de paiement échangeait des messages par-delà une frontière organisationnelle, il faudrait passer à BPMN, avec deux pools et un flux de message.
Visualisations
La géométrie est le contenu. Le rôle d'une arête se lit dans sa forme: une garde entre crochets énonce la condition qui aiguille, une barre épaisse affirme une concurrence qu'un simple trait ne saurait porter, une cible marque la fin d'activité et une tête de flèche ouverte signe le flux de contrôle.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Le cas d'utilisation et la conception retenue doivent exister avant de tracer: c'est la matière du dessin. |
| Exécution | Faible | Un cas d'utilisation tient en un diagramme, tracé en une séance. Le coût monte avec le nombre de branches gardées et de traitements concurrents; la taille du système n'y change rien. |
| Documentation | Moyen | Le diagramme vit dans le modèle UML et se met à jour quand le cas d'utilisation ou le modèle de classes change. Sa valeur tient à cette cohérence entretenue. |
Outils
Un tableau blanc suffit à une première ébauche: un flux d'actions et deux branches gardées tiennent sur une feuille. Les outils de dessin généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits corrects, mais leur apport s'arrête au dessin, et le rattachement au cas d'utilisation ne subsiste alors que dans la tête de l'auteur. Les ateliers de modélisation UML, Enterprise Architect, Visual Paradigm ou Modelio, tiennent le diagramme comme un objet du modèle: il se trace vers le cas d'utilisation qu'il réalise et vers les classes qu'il manipule, et l'outil signale une bifurcation sans jonction ou une décision sans garde.
Sources
- OMG, Unified Modeling Language (UML), Version 2.5.1, la clause Activities: la sémantique de jetons, les nœuds de contrôle (nœud initial, décision et fusion, bifurcation et jonction, fin d'activité), les gardes, le flux d'objets et les partitions.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: le diagramme d'activités parmi les notations de modélisation des processus et les trois niveaux d'un modèle de processus.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.5 UML: le diagramme d'activités comme usage secondaire pour la modélisation des processus métier, dans le domaine des technologies de l'information.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: les couloirs sont une addition notationnelle.