Diagramme de communication

1. Une autre lecture de la même collaboration

Le diagramme de communication présente une interaction en mettant l’accent sur l’organisation des participants et sur les chemins empruntés par leurs messages. À la différence d’une séquence, il ne s’appuie pas principalement sur un axe vertical du temps. L’ordre est indiqué par les numéros des messages.

La séquence répond facilement à « que se passe-t-il ensuite ? ». La communication aide à répondre à « qui doit pouvoir collaborer avec qui ? ». Pour un même scénario, les deux représentations peuvent décrire les mêmes échanges. Elles ne doivent pas raconter deux comportements contradictoires.

Nous reprenons l’acceptation d’un devis. Client échange avec Portail ; Portail sollicite ServiceDevis ; ServiceDevis utilise DepotDevis. Le dessin permet de repérer rapidement qu’un écran ne doit pas modifier directement une donnée persistante en contournant les règles du service.

2. Lire les liens et les numéros

Un trait entre participants fournit un chemin de communication. Les messages s’écrivent à proximité de ce chemin avec leur sens et leur numéro. Le numéro 1 désigne un premier appel ; 1.1 indique un appel imbriqué pendant le traitement de 1 ; 1.2 est un autre appel de ce même niveau.

1 : confirmer(reference)
1.1 : accepter(reference, clientId)
1.1.1 : charger(reference)
1.1.2 : enregistrerAcceptation(devis)

Les points expriment l’imbrication, pas une quantité décimale. « 1.10 » peut suivre « 1.9 ». Une garde peut compléter un message ; une itération peut être signalée avec une expression de répétition. Lorsque l’imbrication devient difficile à lire, il vaut mieux détailler l’échange dans une séquence séparée.

3. Construire la vue à partir d’une séquence

1. Conserver le même scénario et le même résultat attendu.
2. Reporter les participants sans en ajouter seulement pour remplir la figure.
3. Tracer les chemins réellement nécessaires aux échanges.
4. Numéroter les appels en conservant leur ordre et leur imbrication.
5. Ajouter les conditions utiles et une description textuelle des retours omis.
6. Comparer le résultat à la séquence originale.

Les retours de chargement et de confirmation peuvent être laissés implicites si cela est annoncé. Une communication allégée ne doit pas faire croire que le dépôt n’a rien renvoyé. Elle expose une sélection d’échanges pour une question précise.

Ne pas ajouter un lien entre tous les objets au motif qu’ils appartiennent à la même application. Chaque accès accroît les dépendances à comprendre et à maintenir. Le diagramme doit montrer les collaborations utiles, pas une toile de connexions hypothétiques.

4. Utiliser la vue pour discuter la conception

Un participant relié à presque tous les autres mérite une relecture : il peut centraliser trop de responsabilités. Ce constat n’est pas une erreur automatique ; un service de coordination peut légitimement orchestrer plusieurs étapes. Il faut examiner la cohésion de ses tâches et les raisons des dépendances.

Dans notre cas, ServiceDevis organise l’acceptation, mais le calcul du total et les transitions propres au devis restent des responsabilités métier. DepotDevis connaît la persistance ; il ne décide pas si le PDG doit approuver un montant.

Une interface de notification permet de changer le moyen d’envoi sans modifier les règles d’acceptation. La communication rend ce point de variation visible. Elle reste toutefois une vue de collaboration : elle ne décrit pas l’architecture de déploiement du système.

5. Séquence ou communication : décider simplement

On ne produit pas les deux vues par obligation documentaire. On les utilise quand chacune aide à résoudre une question. Dans ce cours, les deux sont présentées pour apprendre leur lecture et vérifier leur cohérence sur le même fil conducteur.

Scénarios illustrés : comparer les situations

Séparer l’accord et son traitement différé

Le message 1 programme un travail après la validation de l’accord ; le message 2 appartient à un traitement ultérieur. La numérotation 2.1 décrit un appel imbriqué dans ce traitement. La file et le worker sont des choix de conception de l’exemple, pas une exigence du langage UML.

Exercices corrigés