Les diagrammes d'interaction

Le DSS s'arrêtait à la porte du système : une flèche entrait, une réponse sortait, et ce qu'il y avait derrière restait volontairement noir. Ce module ouvre la boîte. On va regarder des objets se parler pour réaliser une seule opération, dans l'ordre exact où ils le font — et récolter, en sortant, les opérations que ton diagramme de classes attend encore.

Ce que le DSS laissait en blanc

Reprends le diagramme de séquence système de l'emprunt, celui du module Cas d'utilisation & DSS. Il contenait un acteur, un rectangle nommé Système, et trois flèches entrantes :

Usager ──▶ Système
   identifierLecteur(numero)
Usager ──▶ Système
   identifierLivre(isbn)
Usager ──▶ Système
   confirmerEmprunt()

Les trois opérations système de l'emprunt, telles que la section Les opérations système les a relevées : une par flèche entrante, et rien de plus.

Ce diagramme dit ce que le système doit savoir faire. Il ne dit pas un mot de la façon dont il s'y prend, et c'était le but : à ce stade, on n'avait rien décidé. Le moment est venu de décider. Un diagramme d'interaction montre les objets qui collaborent pour réaliser UNE opération système, et les messages qu'ils s'échangent.

Retiens le mot une. On ne dessine pas « le diagramme d'interaction du système » — ça n'existe pas. On en dessine un par opération système : un pour identifierLecteur, un pour identifierLivre, un pour confirmerEmprunt. Trois flèches entrantes au DSS, trois diagrammes. C'est aussi mécanique que ça, et c'est la première chose qu'un correcteur vérifie : le message qui entre dans ton diagramme est-il bien une opération système ?

UML offre deux notations pour cette même partition. Le diagramme de séquence range les messages sur un axe du temps qui descend ; le diagramme de communication les pose sur un réseau d'objets, et les numérote. Le module Le processus unifié & UML l'a déjà annoncé, et il faut le prendre au pied de la lettre : les deux contiennent exactement la même information. Ce module apprend d'abord la séquence, parce que c'est celle que le cours dessine le plus, puis montre comment la même chose s'écrit en communication.

Les pièces d'un diagramme de séquence

Un diagramme de séquence n'a que quatre pièces, et tout le reste du module n'est que leurs combinaisons. Le vocabulaire compte ici plus qu'ailleurs : un correcteur qui lit « la ligne de vie de :Livre s'arrête après le retour » sait immédiatement que la notion n'est pas acquise.

La ligne de vie est l'objet, vu sur toute la durée du scénario : une boîte en haut de la page, et sous elle un long trait pointillé qui descend. Ce trait est le temps. Rien n'y est à l'échelle — deux messages séparés d'un centimètre ne durent pas plus longtemps qu'à un millimètre : la seule chose que la verticale affirme, c'est l'ordre.

Le contenu de la boîte suit une règle qui tombe souvent, et qui tient au deux-points. :Livre se lit « un objet quelconque de la classe Livre » : le deux-points n'est pas de la ponctuation, c'est lui qui dit « instance de ». Quand il faut distinguer deux objets de la même classe, on les nomme : emprunte:Livre. Et Livre tout court, sans deux-points, ne désigne pas un objet mais la classe elle-même — on ne s'en sert que pour lui envoyer une opération de classe.

Le message est une flèche horizontale qui va de l'émetteur au destinataire et porte le nom de l'opération demandée, avec ses arguments. Le retour est ce que le destinataire renvoie. Et la barre d'activation — un rectangle étroit posé sur la ligne de vie — dit que cet objet est en train de travailler.

Cette dernière pièce est celle qu'on lit mal, alors elle mérite sa phrase : le trait pointillé dit que l'objet existe, la barre dit qu'il exécute. Un objet passe toute la page sur le diagramme ; il ne travaille que par intervalles, et chacun commence quand il reçoit un message, se termine quand il a fini de répondre.

LIGNE DE VIE
   :Livre          un objet de Livre
   emprunte:Livre  un objet nommé
   Livre           la CLASSE, pas un objet
   Usager          un acteur, sans boîte

   sous la boîte, un trait POINTILLÉ :
   c'est le TEMPS. Rien n'est à l'échelle,
   seul l'ORDRE compte.

BARRE D'ACTIVATION
   posée sur le trait = l'objet EXÉCUTE
   début : la réception ; fin : la réponse

MESSAGE
   [garde] valeur := nom(arg : Type)
      estDisponible()
      [en regle] no := emprunter(livre)

RETOUR
   flèche pointillée, portant la VALEUR

1  Usager ──▶ :ControleurEmprunt
      confirmerEmprunt()
2  :ControleurEmprunt ──▶ :Livre
      estDisponible()
3  :Livre - -▶ :ControleurEmprunt
      vrai
4  :ControleurEmprunt ──▶ :Emprunt
      «create»
5  :ControleurEmprunt - -▶ Usager
      dateRetour

Les trois traits, et ce que chacun décide

Toutes les flèches d'un diagramme de séquence ne se valent pas, et ce qui les distingue tient à deux détails de tracé : le trait est plein ou pointillé, la pointe est un triangle plein ou deux simples traits. Trois combinaisons servent, et chacune dit quelque chose de précis.

Le message synchrone — trait plein, pointe pleine — est celui que tu traceras presque toujours. Il veut dire : l'émetteur s'arrête et attend la réponse. C'est exactement ce que fait un appel de méthode ordinaire : quand tu écris livre.estDisponible() en Java, la ligne suivante ne s'exécute pas tant que la méthode n'a pas rendu sa valeur.

Le message asynchrone — trait plein, pointe fine — dit l'inverse : l'émetteur poste son message et continue immédiatement. On s'en sert pour un traitement lancé en arrière-plan, une notification, un autre fil d'exécution. Dans un projet en Java comme celui de la session, il est rare ; il faut savoir le lire, et savoir qu'on ne le trace pas par défaut.

Le retour — trait pointillé, pointe fine — remonte vers l'appelant et porte une valeur, jamais un nom d'opération. On écrit vrai, dateRetour, montant ; écrire retournerLaDate() serait un contresens — personne n'appelle rien, quelque chose revient.

Reste une question qui revient à chaque diagramme : faut-il tracer tous les retours ? Non, et Larman est explicite là-dessus. Un retour se note de deux façons — la flèche pointillée, ou la forme valeur := message() écrite directement sur la flèche d'appel — et on ne fait jamais les deux à la fois. Quand la réponse va de soi ou ne sert à rien de la suite, on l'omet. Ce qu'on ne peut pas omettre, c'est la valeur dont le reste du diagramme se sert : le lecteur ne saurait alors pas d'où elle sort.

Naître et mourir pendant la séquence

Les objets d'un diagramme n'étaient pas tous là au début. Réaliser confirmerEmprunt(), c'est précisément fabriquer un Emprunt qui n'existait pas — et la notation a de quoi le montrer.

La création se note par un message portant le stéréotype «create», tracé non pas vers une ligne de vie mais vers la boîte de l'objet créé ; et cette boîte se dessine plus bas que les autres, à la hauteur du message qui la fait naître. C'est encore la position verticale qui parle : au-dessus de sa boîte, l'objet n'existe pas.

La destruction se note par un grand × qui ferme la ligne de vie, précédé au besoin d'un message «destroy». En Java, on ne détruit rien à la main — le ramasse-miettes s'en charge quand plus personne ne tient l'objet —, donc tu traceras rarement ce symbole. Il faut savoir le lire, et savoir qu'il signifie « à partir d'ici, cet objet n'est plus », pas « le scénario se termine ».

L'auto-appel est le troisième cas particulier : un objet s'envoie un message à lui-même. La flèche part de sa ligne de vie et y revient un peu plus bas, et une seconde barre d'activation se pose sur la première, légèrement décalée vers la droite. On s'en sert quand une opération publique délègue une partie du travail à une opération de la même classe — c'est fréquent, et c'est une façon honnête de montrer qu'un objet fait deux choses distinctes.

Reste l'acteur, et il tend un piège de vocabulaire. Il se dessine en bonhomme, sans boîte et sans deux-points, il a bien une ligne de vie — mais ce n'est pas un objet du système. Il est dehors : c'est lui qui déclenche l'opération et lui qui en reçoit le résultat, jamais lui qui exécute quoi que ce soit à l'intérieur. La question d'examen « combien d'objets ce diagramme contient-il ? » se joue exactement là.

1  Client ──▶ :ControleurGuichet
      retirer(500)
2  :ControleurGuichet ──▶ :Compte
      verifierSolde(500)
3  :Compte ──▶ :Compte
      soldeDisponible()
4  :Compte - -▶ :ControleurGuichet
      vrai
5  :ControleurGuichet ──▶ :Distributeur
      delivrer(500)
6  :ControleurGuichet - -▶ Client
      recu

Quand le diagramme doit dire « si » et « tant que »

Tout ce qui précède décrit une exécution où chaque message part, une fois, dans l'ordre. Un vrai scénario n'est jamais aussi docile : le livre peut être indisponible, le lecteur peut emprunter trois ouvrages d'un coup. Il faut donc pouvoir écrire un si et un tant que dans un diagramme, et UML 2 le fait avec les fragments combinés.

Un fragment est un cadre tracé autour d'une portion du diagramme. En haut à gauche du cadre, un petit onglet porte l'opérateur — le mot qui dit quelle sorte de contrôle on applique. À l'intérieur, une garde entre crochets donne la condition. Et les messages, eux, ne changent pas : c'est tout l'intérêt de la notation, on entoure ce qu'on avait déjà.

Les trois premiers sont ceux qu'on trace et ceux qui tombent en examen. par ne sert que si ton système a réellement des traitements simultanés, et ref est un outil de mise en page : il évite de recopier dans dix diagrammes la même sous-séquence d'authentification.

opt [solde >= montant]
      :ControleurGuichet ──▶ :Compte
         debiter()
      :ControleurGuichet ──▶ Usager
         erreur()

Les mêmes messages, vus en réseau

Le diagramme de communication raconte exactement la même chose que le diagramme de séquence, avec une seule différence : il n'a pas d'axe du temps. Les objets sont posés où l'on veut sur la page, reliés par des traits nus — des liens —, et chaque message s'écrit le long du lien qu'il emprunte, avec une petite flèche pour le sens.

Une question devient alors urgente : si rien n'est en haut ni en bas, comment sait-on lequel part en premier ? Par le numéro. C'est lui, et lui seul, qui porte la chronologie. Un diagramme de communication sans numéros n'est pas incomplet, il est illisible : on voit qui connaît qui, on ne voit plus rien de ce qui se passe.

Et ce numéro dit plus que l'ordre : il dit la profondeur d'appel. Le message qui déclenche tout porte 1. Ceux qui partent pendant son traitement portent 1.1, 1.2, 1.3 ; si 1.2 en déclenche un autre à son tour, ce sera 1.2.1. La numérotation est donc l'exact équivalent des barres d'activation emboîtées de la séquence — la même information, écrite au lieu d'être dessinée.

Deux marques complètent la notation. L'astérisque signale la répétition : 1.3*: emprunter(livre) remplace le cadre loop. Et la garde s'écrit entre crochets avant les deux-points : 1.3 [disponible]: emprunter(livre). Un diagramme de communication n'a pas de cadres ; tout ce que les fragments portaient se replie dans la ligne du message.

:ControleurRetour ▶ :Emprunt
   1.2 : estEnRetard(aujourdhui)
   1.4 : cloturer()
:ControleurRetour ▶ :Amende
   1.3 [en retard] : calculer()
Usager ▶ :ControleurRetour
   1 : retournerLivre(isbn)
:ControleurRetour ▶ :RegistreEmprunts
   1.1 : trouver(isbn)

Alors, lequel des deux dessiner ? Le cours demande de savoir lire et produire les deux, et le choix se fait sur ce qu'on veut faire ressortir. La séquence gagne dès que le scénario est long ou plein de conditions : l'ordre y saute aux yeux et les fragments s'y voient. La communication gagne quand on veut voir qui est relié à qui — et c'est loin d'être un détail esthétique : chaque lien du diagramme annonce une association ou une dépendance à venir dans le diagramme de classes.

Construire le diagramme d'une opération système

Devant une copie blanche, la notation ne sert à rien si l'on ne sait pas par où commencer. Voici l'ordre des gestes, déroulé sur confirmerEmprunt() — la troisième opération système du DSS de l'emprunt.

1. Le message initial est l'opération système. Il part de l'acteur et arrive sur une seule classe : le contrôleur. Le module Le diagramme de classes & l'architecture logique a déjà tranché ce point — une opération système arrive de l'extérieur, et l'extérieur ne connaît qu'une porte d'entrée. Tu n'as donc rien à décider ici : Usager ──▶ :ControleurEmprunt : confirmerEmprunt().
2. Écris en français ce qu'il faut faire. Pour confirmer un emprunt : vérifier que le livre est disponible, créer l'emprunt, marquer le livre sorti, rendre la date de retour. Quatre choses. Cette liste ne se dessine pas encore, elle se pose à côté.
3. Pour chacune, demande-toi qui possède l'information. C'est la seule question qui distribue, et elle a toujours la même forme : quel objet sait déjà ce qu'il faut savoir pour faire ça ? La disponibilité d'un livre est une affaire de livre. La date de retour est une affaire d'emprunt. Le contrôleur, lui, ne sait rien — il n'a que la liste des choses à faire.
4. Chaque délégation devient un message, tracé du contrôleur vers l'objet qui sait. Et le dernier geste est le retour vers l'acteur : ce que le DSS avait promis qu'il recevrait, et que ton diagramme doit bien finir par produire.

Ce raisonnement — confier une responsabilité à qui détient l'information — porte un nom, il a sa semaine dans le cours, et tu viens de l'appliquer sans le connaître. Ce sont Les principes GRASP, la matière de la semaine 6.

Le résultat, une fois écrit en Java, montre à quel point la correspondance est serrée : un diagramme de séquence est le corps d'une méthode, dessiné. Ce bloc-ci est l'exact équivalent du diagramme qu'on vient de construire.

public class ControleurEmprunt {
  private RegistreEmprunts registre;

  public Date confirmerEmprunt(Lecteur lecteur, Livre livre) {
    // MESSAGE 1.1 — le contrôleur ne SAIT pas si un
    //   livre est disponible : il le demande à celui
    //   qui le sait. Un appel de méthode ordinaire est
    //   un message SYNCHRONE — la ligne d'après attend.
    if (!livre.estDisponible()) {
      return null;      // la branche [else] du alt
    }

    // MESSAGE 1.2 — «create» : l'objet naît ICI, et sa
    //   boîte se dessine plus bas que les autres.
    Emprunt emprunt = new Emprunt(lecteur, livre);

    // MESSAGE 1.3 — c'est encore le livre qui change
    //   son propre état.
    livre.emprunter();
    registre.ajouter(emprunt);

    // LE RETOUR vers l'acteur : la flèche pointillée
    //   qui remonte tout en haut du diagramme.
    return emprunt.getDateRetour();
  }
}

Chaque appel de méthode est une flèche, l'accolade de la méthode est la barre d'activation du contrôleur, et le if est le fragment alt. Une seule ligne n'apparaîtrait pas sur le diagramme : getDateRetour(), parce que le module précédent l'a rangée parmi les accesseurs triviaux qu'on ne trace pas — on écrit plutôt la valeur sur la flèche de retour.

1  Bibliothecaire ──▶ :ControleurAmende
      payerAmende(no, 5.00)
2  :ControleurAmende ──▶ :RegistreLecteurs
      trouver(no)
3  :ControleurAmende ──▶ :Lecteur
      getAmendeDue()
4  :ControleurAmende ──▶ :ControleurAmende
      soustraire(5.00)
5  :ControleurAmende ──▶ :Lecteur
      setAmendeDue(reste)
6  :ControleurAmende - -▶ Bibliothecaire
      reste

Ce que le diagramme renvoie au diagramme de classes

On arrive à la raison d'être de tout ce qui précède. Le module Le diagramme de classes & l'architecture logique laissait une question ouverte : d'où viennent les opérations des classes ? Il donnait une réponse partielle — celles qui découlent des attributs, celles qui viennent d'une règle du métier — et renvoyait le reste à cette semaine. Voici la règle qui manquait, et elle est purement mécanique :

Tout message reçu par un objet est une opération de sa classe. Pas le message qu'il envoie : celui qu'il reçoit. La flèche pointe vers celui qui devra savoir faire.

Le geste, une fois le diagramme dessiné, se fait donc au crayon et sans réfléchir : on relève chaque flèche, on regarde où sa pointe arrive, et on inscrit une ligne dans la boîte correspondante.

La visibilité se déduit du même dessin. Une opération que quelqu'un d'autre appelle est publique : +. Une opération qui n'apparaît que dans un auto-appel n'est utile qu'à sa propre classe, et elle peut donc être privée : -. C'est un des rares endroits du cours où une décision de conception se lit directement sur un dessin, sans avoir à en discuter.

Et les liens remontent aussi. Pour envoyer un message à un objet, il faut pouvoir l'atteindre : chaque lien de ton diagramme de communication annonce donc une association navigable ou une dépendance dans le diagramme de classes. Si :ControleurEmprunt parle à :Livre, une flèche devra exister entre les deux boîtes — et c'est aussi comme ça qu'on s'aperçoit qu'un diagramme d'interaction trop bavard produira un diagramme de classes trop couplé.

1  :ControleurEmprunt ──▶ :Lecteur
      estEnRegle()
2  :Lecteur - -▶ :ControleurEmprunt
      vrai
3  :Lecteur ──▶ :Lecteur
      totalAmendes()

Le dessiner sur une copie, sans notes

Un mot sur la forme de ce module avant de finir, parce qu'elle n'est pas celle de l'examen. Ici, les messages s'écrivent en pile — une ligne chacun, de haut en bas —, parce qu'un diagramme à quatre colonnes ne tient pas sur un écran de téléphone. Sur ta copie, tu dessineras des colonnes. La correspondance est directe et il suffit de l'avoir vue une fois : chaque nom d'objet qui apparaît dans la pile devient une boîte en haut de la feuille, et chaque ligne de la pile devient une flèche horizontale entre deux colonnes, tracée d'autant plus bas qu'elle vient plus tard.

L'ordre des gestes compte, parce qu'il évite de tout gommer :

1. Les lignes de vie d'abord, de gauche à droite : l'acteur, puis le contrôleur, puis les entités dans l'ordre où elles entreront en jeu. Cette disposition n'est pas obligatoire, mais elle rend les flèches presque toutes orientées vers la droite — donc lisibles.
2. Les messages ensuite, du haut vers le bas, un par un, sans sauter de ligne. Nomme-les complètement dès le premier passage : c'est ce qu'on oublie quand le temps manque.
3. Les barres d'activation en avant-dernier. Elles se déduisent des messages — chacune commence à une réception et finit à une réponse —, donc les tracer avant oblige à les corriger.
4. Les cadres, les gardes et les retours pour finir. Un cadre se dessine plus facilement quand on sait déjà quels messages il doit entourer.

Puis la relecture, qui prend une minute et rapporte plus que n'importe quel raffinement. Six questions, dans cet ordre :

1. Le premier message est-il l'opération système ? Et arrive-t-il bien sur le contrôleur ?
2. Chaque objet porte-t-il le deux-points ? Livre sans deux-points n'est pas un objet, c'est la classe.
3. Chaque flèche part-elle de celui qui demande ? Une flèche à l'envers change complètement qui devra savoir faire.
4. Chaque condition est-elle dans une garde ? Et chaque garde dans un cadre ?
5. Les barres s'emboîtent-elles ? Celle de l'appelant doit couvrir celle de l'appelé, du début à la fin.
6. L'acteur reçoit-il quelque chose à la fin ? Le DSS lui avait promis une réponse ; ton diagramme doit la produire.