Diagramme d’activités

Page 8 sur 8. Modéliser les traitements, les décisions, les flux et le travail parallèle.

1. Représenter le déroulement d’un travail

Le diagramme d’activités représente un comportement sous forme de flux entre actions. Il est adapté à une procédure métier, à un traitement applicatif ou à un algorithme. L’activité « Traiter une demande commerciale » traverse plusieurs responsabilités ; elle ne décrit pas seulement le statut d’un devis.

Une action, dessinée comme un rectangle aux angles arrondis, représente une étape de travail au niveau choisi : qualifier la demande, calculer le total, préparer le dossier technique. Une activité peut appeler une autre activité pour détailler une étape sans rendre la figure principale illisible.

La lecture s’appuie sur des jetons : les flux offrent des possibilités de progression, et les nœuds consomment ou transmettent des jetons selon leur nature. Une flèche ne signifie pas simplement « en rapport avec ». Elle participe au déroulement du comportement.

Parcours pédagogique condensé : l’approbation est supposée obtenue dans sa branche. Les corrections et reprises sont décrites dans le cours. Après accord, un fork lance deux travaux ; le join attend les deux avant la fin « dossier prêt ».
Parcours pédagogique condensé : l’approbation est supposée obtenue dans sa branche. Les corrections et reprises sont décrites dans le cours. Après accord, un fork lance deux travaux ; le join attend les deux avant la fin « dossier prêt ». Cliquer pour agrandir.

2. Nœuds initiaux, actions et fins

Le nœud initial est un disque noir. Il amorce un flux de contrôle. Les flèches relient les étapes dans le sens de progression. Une action ne commence que lorsque ses conditions d’exécution et ses entrées nécessaires sont réunies.

Le nœud final d’activité, en forme de cible, arrête l’activité et ses flux encore actifs. Le nœud final de flux, cercle avec une croix, termine uniquement le flux qui l’atteint. Dans un processus parallèle, choisir le mauvais symbole peut interrompre un traitement encore nécessaire.

Dans l’exemple, la cible après « Dossier prêt » termine le processus de préparation. Le travail d’intervention lui-même n’est pas développé. Le parcours UML se termine sur cette page, conformément au périmètre fixé.

3. Décision et fusion : sélectionner une branche

Un losange de décision distribue le flux vers une sortie admissible. Les gardes s’écrivent entre crochets : [total > seuil] et [else]. Pour un choix exclusif prévisible, on utilise des conditions qui ne se recouvrent pas et qui couvrent les cas attendus.

Un losange de fusion rassemble des chemins alternatifs sans les synchroniser. Il laisse progresser le flux qui arrive. Il ne faut pas le remplacer par une barre de jonction, car cette dernière attend normalement les branches parallèles définies par sa règle.

Chez NKILItech, un devis élevé passe par l’approbation du PDG, tandis que l’autre rejoint directement le chemin d’envoi. Les deux alternatives doivent être fusionnées avant la suite commune. En cas de correction demandée, une boucle retourne à la préparation du devis ; le nouveau total doit être recalculé.

4. Fork et join : exécuter et synchroniser

Une barre de fork répartit un flux vers plusieurs branches pouvant progresser en parallèle. Une barre de join les synchronise : avec la règle habituelle, elle attend un jeton sur chaque entrée avant de poursuivre. Les branches peuvent finir à des moments différents.

Après acceptation du devis, l’équipe prépare le dossier technique pendant que l’équipe commerciale informe le client du calendrier. Le dossier est déclaré prêt après les deux branches. Aucune branche ne doit être abandonnée silencieusement si la jonction l’attend.

Piège classique. Si une décision envoie le jeton dans une seule de deux branches, un join qui attend les deux peut bloquer. Des chemins exclusifs se réunissent avec une fusion ; des chemins parallèles se réunissent avec une jonction adaptée.
Une fusion rassemble des alternatives ; une jonction synchronise les flux parallèles. Utiliser la mauvaise réunion peut bloquer le processus.
Une fusion rassemble des alternatives ; une jonction synchronise les flux parallèles. Utiliser la mauvaise réunion peut bloquer le processus. Cliquer pour agrandir.

5. Partitions et responsabilités

Les partitions, souvent appelées couloirs, regroupent les actions selon un critère annoncé : rôle, service ou unité organisationnelle. Elles ne créent pas, à elles seules, de synchronisation. Une flèche peut traverser une frontière de partition pour indiquer le passage du travail.

Notre seconde figure répartit la soumission chez le Client, la qualification et le chiffrage chez le Chargé d’affaires, puis l’approbation chez le PDG lorsque le seuil est dépassé. Le nom du PDG est indiqué dans le contexte du cours ; la partition représente le rôle, afin de rester valable si la personne change.

Une partition « Portail » peut recevoir les traitements automatisés. Cette distinction aide à repérer une décision qui doit rester humaine et une vérification que le système doit imposer. Il faut néanmoins éviter de confondre une responsabilité métier avec un serveur de déploiement.

Extrait avec partitions : le client exprime le besoin, le chargé d’affaires prépare la proposition et le PDG approuve les montants supérieurs au seuil. Les sorties rejoignent ensuite la procédure d’envoi.
Extrait avec partitions : le client exprime le besoin, le chargé d’affaires prépare la proposition et le PDG approuve les montants supérieurs au seuil. Les sorties rejoignent ensuite la procédure d’envoi. Cliquer pour agrandir.

6. Flux d’objets, événements et exceptions

Un flux de contrôle exprime la progression sans transporter une donnée métier. Un flux d’objets transporte des valeurs ou des objets entre nœuds. Un rectangle nommé devis : Devis, éventuellement avec un état comme [envoyé], peut rendre la donnée échangée visible. Des pins représentent les entrées et sorties des actions.

Une action « Calculer le total » reçoit des lignes et produit un montant ; « Envoyer le devis » consomme une proposition validée selon les règles. Cette distinction évite une activité dont les étapes existent mais dont les données nécessaires n’arrivent jamais.

Une action d’acceptation d’événement attend par exemple la réponse du client. Une action d’envoi de signal émet une information sans imposer le traitement immédiat de son destinataire. Une attente temporelle peut déclencher une relance. Un gestionnaire d’exception ou une région interruptible peut décrire une sortie contrôlée ; il faut préciser les flux interrompus et la reprise attendue.

Pour R5, on conserve d’abord l’acceptation, puis on traite la notification avec reprise si nécessaire. Une erreur d’envoi ne doit pas renvoyer arbitrairement le devis à l’état Envoyé. Une notification technique et une décision métier ne portent pas la même signification.

7. Méthode complète et bilan du parcours

  1. Nommer l’activité et définir ses entrées, son début et son résultat attendu.
  2. Écrire le parcours nominal avant d’ajouter les variantes.
  3. Transformer les étapes en actions portant un verbe précis.
  4. Placer les décisions et écrire leurs gardes, notamment aux seuils.
  5. Distinguer les alternatives des traitements parallèles.
  6. Ajouter les responsabilités et les données utiles.
  7. Parcourir les chemins d’échec, d’annulation et de reprise.
  8. Vérifier la cohérence avec les cas, les classes, les séquences et les états.
RègleVues à confronterVérification concrète
R1 : un propriétaireClasses, objets, casLe client B ne peut pas consulter la demande de A.
R2 : une version acceptée au plusClasses, séquence, étatsDeux confirmations concurrentes ne créent pas deux accords.
R4 : accord au-delà du seuilCas, états, activitésComparer 999 999, 1 000 000 et 1 000 001 FCFA.
R5 : reprise de notificationSéquence, activitésSimuler une panne après enregistrement de l’accord.

Le dossier forme maintenant une chaîne cohérente : les cas expriment les objectifs, les classes organisent les informations, les objets donnent des exemples, les interactions répartissent les échanges, les états protègent le cycle de vie et les activités expliquent le travail. La qualité se mesure à la capacité de ces vues à expliquer ensemble le même comportement.

Scénarios illustrés : comparer les situations

Boucler sans bloquer le processus

La boucle de correction revient sur une fusion. À chaque passage, le devis est recalculé et réexaminé. Ce schéma zoome sur les devis qui nécessitent l’approbation du PDG ; le contrôle du seuil reste décrit dans l’activité générale.

La branche correction revient à une fusion avant la préparation. Il ne faut pas une jonction à cet endroit : les chemins initial et de reprise sont alternatifs, pas parallèles.
La branche correction revient à une fusion avant la préparation. Il ne faut pas une jonction à cet endroit : les chemins initial et de reprise sont alternatifs, pas parallèles. Cliquer pour agrandir.

Reprendre une notification sans annuler l’accord

Le compteur est initialisé une fois puis augmenté à chaque tentative. Un envoi réussi termine le traitement ; après trois échecs, l’équipe reçoit un signalement. La reprise réelle peut être effectuée par un worker avec temporisation : le dessin se concentre sur la décision de reprise et l’accord conservé.

L’activité distingue l’accord métier de la notification. Une panne conduit à une reprise bornée ou à un signalement ; elle ne révoque jamais l’accord déjà enregistré.
L’activité distingue l’accord métier de la notification. Une panne conduit à une reprise bornée ou à un signalement ; elle ne révoque jamais l’accord déjà enregistré. Cliquer pour agrandir.

Exercices corrigés

Exercice 1 - Fusion ou jonction ?

Une décision choisit soit une validation simple, soit une approbation du PDG. Comment réunir les branches ?

Voir le corrigé détaillé

Utiliser une fusion, car une seule branche est empruntée. Un join avec une attente sur les deux entrées pourrait bloquer. Après un fork qui crée effectivement deux branches, utiliser une jonction pour attendre les deux.

Exercice 2 - Choisir une fin

Deux branches travaillent en parallèle ; l’une abandonne seulement une relance devenue inutile. Quelle fin convient ?

Voir le corrigé détaillé

Une fin de flux termine cette branche seule. Une fin d’activité mettrait fin à tous les flux de l’activité. Il faut ensuite vérifier que les autres branches n’attendent pas à une jonction le jeton de la branche abandonnée.

Exercice 3 - Mini-projet final

Produire les vues de l’acceptation d’un devis et expliquer une panne de notification.

Voir le corrigé détaillé

Livrer le cas UC-04, les classes et contraintes R1-R2, un exemple d’objets avant/après, une séquence avec refus, la transition Envoyé vers Accepté et une activité qui enregistre l’accord avant la notification. La panne conduit à une reprise d’envoi ; elle n’annule pas l’accord métier.

Cours et schémas originaux, étude pédagogique NKILItech. Référence de lecture : Benoît Charroux, Aomar Osmani et Yann Thierry-Mieg, UML 2 : pratique de la modélisation, 2e édition, Pearson, 2009. Les explications, exemples et figures ont été rédigés pour ce parcours. Référence de notation : spécification UML de l’OMG.