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.
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.
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.
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
- Nommer l’activité et définir ses entrées, son début et son résultat attendu.
- Écrire le parcours nominal avant d’ajouter les variantes.
- Transformer les étapes en actions portant un verbe précis.
- Placer les décisions et écrire leurs gardes, notamment aux seuils.
- Distinguer les alternatives des traitements parallèles.
- Ajouter les responsabilités et les données utiles.
- Parcourir les chemins d’échec, d’annulation et de reprise.
- Vérifier la cohérence avec les cas, les classes, les séquences et les états.
| Règle | Vues à confronter | Vérification concrète |
|---|---|---|
| R1 : un propriétaire | Classes, objets, cas | Le client B ne peut pas consulter la demande de A. |
| R2 : une version acceptée au plus | Classes, séquence, états | Deux confirmations concurrentes ne créent pas deux accords. |
| R4 : accord au-delà du seuil | Cas, états, activités | Comparer 999 999, 1 000 000 et 1 000 001 FCFA. |
| R5 : reprise de notification | Séquence, activités | Simuler 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.
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é.
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.