Diagramme d'activité : actions, décisions, parallélisme et couloirs

Le diagramme d'activité décrit un enchaînement d'actions : un processus métier, le déroulement d'un cas d'utilisation ou un algorithme. Il part d'un nœud initial, suit des flèches entre des actions, se divise aux décisions, se dédouble aux bifurcations (actions en parallèle) et se termine à un nœud final. Des couloirs (swimlanes) montrent qui fait chaque action. Ce chapitre présente ses éléments, le distingue de l'algorigramme et du diagramme de séquence, et construit l'activité de la campagne mensuelle de validation d'AppliFrais.

Les éléments du diagramme

Les gardes

Chaque sortie d'une décision porte une garde, une condition entre crochets. Les gardes d'une même décision doivent être exclusives (deux ne peuvent pas être vraies en même temps) et complètes (l'une d'elles est toujours vraie). La garde [sinon] (ou [else]) garantit la complétude : [montant > 100] et [sinon], plutôt que [montant > 100] et [montant < 100], qui oublie le cas « égal à 100 ».

Les couloirs

Les couloirs (partitions d'activité, en anglais swimlanes) découpent le diagramme en colonnes, une par acteur ou par service : le comptable, l'application, le service de paie. Chaque action est placée dans le couloir de celui qui la réalise. Le diagramme montre alors non seulement l'ordre des actions, mais aussi les passages de relais entre les participants : chaque flèche qui traverse une frontière de couloir est un échange, souvent une source d'attente ou d'erreur dans le processus réel.

La campagne mensuelle de validation d'AppliFrais

Le diagramme suivant décrit le processus mensuel, du point de vue de l'organisation : qui fait quoi, dans quel ordre, avec quels choix.

Quelques lectures utiles :

• le sablier marque le déclenchement par le temps : c'est le planificateur du diagramme de cas d'utilisation ;
• la boucle n'a pas de symbole propre : c'est une décision dont une sortie (« reste des fiches ») remonte vers une fusion placée juste avant l'action à répéter. La fusion est indispensable : une action qui reçoit directement deux flèches attendrait les deux, comme une jonction, et l'activité se bloquerait ;
• la décision suivie d'une fusion encadre une action optionnelle (refuser un frais) : c'est l'équivalent d'un if sans else ;
• la bifurcation dit que les virements et l'envoi des avis de paiement se font en parallèle ; la jonction attend que les deux soient terminés avant de marquer les fiches remboursées.

Les nœuds d'objet

Un nœud d'objet montre un objet qui circule entre les actions, avec son état entre crochets. Dans la campagne, on pourrait placer fiche [clôturée] entre « Clôturer les fiches du mois écoulé » et « Ouvrir la fiche clôturée suivante », puis fiche [validée] après « Valider la fiche ». C'est un bon moyen de relier le diagramme d'activité au diagramme d'états-transitions : les états qui apparaissent entre crochets doivent exister dans la machine à états de la classe.

Diagramme d'activité, algorigramme et diagramme de séquence

Le diagramme d'activité ressemble à l'algorigramme (l'organigramme de programmation) : des actions, des losanges de décision, des flèches. Il va plus loin avec le parallélisme, les couloirs, les objets et les signaux. Pour décrire un algorithme simple, l'un vaut l'autre ; le cours Algorithmique utilise surtout le pseudo-code.

Le diagramme d'activité met l'accent sur le flot (ce qui se passe ensuite), le diagramme de séquence sur la collaboration (qui demande quoi à qui). Pour un processus métier vu par les utilisateurs, l'activité est plus lisible ; pour la conception du code, la séquence est plus précise.

Construire un diagramme d'activité

1. Fixe le niveau : un processus d'organisation, un cas d'utilisation ou une méthode.
2. Liste les participants et trace un couloir par participant, si le processus en a plusieurs.
3. Écris les actions du chemin principal, dans l'ordre, chacune avec un verbe à l'infinitif, chacune dans son couloir.
4. Ajoute les décisions avec des gardes exclusives et complètes, et referme chaque décision par une fusion (pour une boucle, fais remonter une sortie vers une fusion placée juste avant l'action à répéter : une action qui reçoit deux flèches attendrait les deux).
5. Cherche le parallélisme : les actions qui ne dépendent pas l'une de l'autre et peuvent se faire en même temps vont entre une bifurcation et une jonction.
6. Vérifie que chaque chemin mène au nœud final, et qu'aucune jonction n'attend une branche qui n'arrivera jamais.

Exercices

Exercice 1 sur 3 Décision ou bifurcation ? Réussi À revoir

Pour chaque situation, indique s'il faut une décision ou une bifurcation, et dessine la structure en texte.

1. Après l'inscription, le site envoie un courriel de bienvenue et crée l'espace de stockage de l'utilisateur, en même temps.
2. Si le panier dépasse 50 €, la livraison est gratuite ; sinon, elle coûte 4,90 €.
3. Une commande est préparée par l'entrepôt pendant que le service comptable édite la facture ; l'expédition attend les deux.
4. Un utilisateur a trois tentatives pour saisir le bon code.

Voir la réponseMasquer la réponse de l'exercice 1

1. Bifurcation : [Inscrire] → fork → (Envoyer le courriel de bienvenue ‖ Créer l'espace de stockage) → join → …. Si rien n'attend la fin des deux actions, chaque branche peut aussi se terminer par un nœud final de flot.
2. Décision : ◇ [total > 50 €] → Appliquer la livraison gratuite ; [sinon] → Ajouter 4,90 € de livraison ; puis fusion ◇.
3. Bifurcation et jonction : fork → (Préparer la commande ‖ Éditer la facture) → join → Expédier. La jonction est indispensable : l'expédition attend les deux.
4. Décision avec boucle : Saisir le code → ◇ [code correct] → Accéder ; [code faux et tentatives < 3] → retour, par une fusion, à Saisir le code ; [code faux et tentatives = 3] → Bloquer le compte. Trois gardes exclusives et complètes, dont une remonte vers une fusion placée juste avant « Saisir le code ».

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Corriger un diagramme Réussi À revoir

Un diagramme d'activité de commande en ligne contient : un nœud initial ; « Saisir l'adresse » ; une décision [client connu] vers « Pré-remplir l'adresse » et [client nouveau] vers « Créer le compte » ; les deux branches arrivent sur une barre épaisse ; puis « Payer » ; une décision [paiement accepté] vers « Confirmer la commande » ; puis le nœud final. Relève les erreurs.

Voir la réponseMasquer la réponse de l'exercice 2

• Les deux branches de la décision arrivent sur une jonction (barre) : elle attendrait les deux branches, alors qu'une seule est prise. L'activité se bloquerait. Il faut une fusion (losange).
• « Saisir l'adresse » est placée avant la décision qui pré-remplit l'adresse : l'ordre est incohérent. Le chemin logique est : décision, puis « Pré-remplir l'adresse » ou « Créer le compte », fusion, puis « Saisir ou vérifier l'adresse ».
• La décision [paiement accepté] n'a qu'une sortie : il manque [sinon], par exemple vers « Afficher le refus » puis un retour à « Payer » ou un nœud final. Les gardes doivent être complètes.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Dessiner un processus avec couloirs Réussi À revoir

Dessine (en texte, couloir par couloir) le diagramme d'activité du traitement d'un ticket d'assistance : « L'utilisateur déclare un incident sur le portail. Le portail crée le ticket et l'affecte automatiquement au technicien de niveau 1 disponible. Le technicien diagnostique l'incident. S'il le résout, il décrit la solution ; sinon, il escalade le ticket au niveau 2, qui le résout et décrit la solution. Dans les deux cas, le portail envoie la solution à l'utilisateur, qui confirme la résolution ou rouvre le ticket ; un ticket rouvert revient au diagnostic de niveau 1. Un ticket confirmé est clôturé par le portail. »

Voir la réponseMasquer la réponse de l'exercice 3

Quatre couloirs : Utilisateur, Portail, Technicien N1, Technicien N2.

1. Utilisateur : nœud initial → « Déclarer un incident ».
2. Portail : « Créer le ticket » → « Affecter au technicien N1 disponible ».
3. Technicien N1 : une fusion, qui reçoit le ticket affecté et les tickets rouverts → « Diagnostiquer l'incident » → décision : [résolu au niveau 1] → « Décrire la solution » ; [sinon] → « Escalader au niveau 2 ».
4. Technicien N2 : « Résoudre l'incident » → « Décrire la solution ».
5. Les deux « Décrire la solution » rejoignent une fusion dans le couloir Portail → « Envoyer la solution à l'utilisateur ».
6. Utilisateur : décision : [résolution confirmée] → (Portail) « Clôturer le ticket » → nœud final ; [sinon] → « Rouvrir le ticket » → retour, par la fusion de l'étape 3, à « Diagnostiquer l'incident » (couloir Technicien N1).

Le processus réel suit souvent le référentiel ITIL ; le cours Support et ITIL détaille la gestion des incidents.

Tu avais trouvé ?

Oui, j'avais bonPas encore