Le modèle du domaine

Le premier diagramme qu'on dessine, et le seul qui ne parle pas du logiciel. Il décrit le monde tel qu'il est avant qu'on écrive une ligne — les choses dont le métier parle, et les liens que le métier tient pour vrais.

Pourquoi un vocabulaire avant le code

Reprends la réservation de salles. Le client dit : « quand quelqu'un réserve, la salle n'est plus disponible ». Phrase banale, et pourtant elle ne dit pas si une réservation peut être annulée, si deux personnes peuvent réserver la même salle pour des créneaux qui se chevauchent, ni ce qui se passe quand personne ne se présente.

Tu peux poser ces questions au client — c'est même ce qu'il faut faire. Mais tu ne les poseras que si tu les vois, et on ne voit pas ce qu'on n'a pas nommé. Écrire « Réservation » dans une boîte, la relier à « Salle » et devoir écrire un nombre à chaque bout du trait force les questions à sortir. Le diagramme n'est pas la réponse ; c'est la machine à fabriquer les bonnes questions.

Il y a un bénéfice moins visible et qui compte autant : le vocabulaire du modèle devient celui du code. Si le métier dit « emprunt », la classe s'appellera Emprunt et pas PretDocument. Quand le client signale un bogue sur « les emprunts en retard », tu sais immédiatement où regarder. Ce n'est pas de la coquetterie : une équipe qui traduit mentalement à chaque conversation perd du temps et introduit des malentendus, et personne ne s'en aperçoit avant qu'ils coûtent.

Ce que le modèle du domaine est, et n'est pas

Formellement : le modèle du domaine est un diagramme de classes UML qui représente les concepts métier d'un domaine, leurs attributs et leurs associations. C'est un artefact d'analyse, pas de conception : il décrit ce que le métier est, jamais comment le logiciel va le manipuler.

Cette dernière phrase a l'air d'une nuance de vocabulaire. C'est en réalité la règle qui décide de tout le reste, et la façon la plus rapide de la comprendre est de regarder la même classe dans les deux mondes.

De là découle une liste courte et non négociable. Le modèle du domaine contient des concepts métier, leurs attributs significatifs, les associations entre eux avec leurs multiplicités, et les trois relations particulières que sont la généralisation, l'agrégation et la composition.

Il ne contient ni opérations — pas de calculerTotal() —, ni classes techniques — pas de ControleurEmprunt, pas de EmpruntDAO, pas de VueEmprunt —, ni visibilité — pas de + ni de - —, ni détail d'implémentation — pas de pointeur, pas de clé étrangère.

(A) Commande      : date, montantTotal
(B) CommandeDAO   : sauvegarder(), charger()
(C) Client        : numero, nom
(D) Panier        : ajouterArticle(), viderPanier()
(E) LigneCommande : quantite

Trouver les concepts : une méthode, pas une astuce

La technique qu'on enseigne partout tient en trois mots : souligne les noms communs. Elle est juste, et elle est très insuffisante — parce que le travail difficile ne commence qu'après avoir souligné. Une description d'une page contient trente noms ; il en restera peut-être six.

Voici la méthode complète, en quatre passes. Elle a l'air lourde et elle prend cinq minutes.

1. SOULIGNER  tous les noms communs de l'énoncé, sans juger.

2. TRIER      chacun en trois tas :
                · CONCEPT  — il a une identité propre, on peut en avoir plusieurs
                             et les distinguer          → une boîte
                · ATTRIBUT — c'est une valeur simple qui appartient à autre chose
                                                        → une ligne dans une boîte
                · BRUIT    — synonyme, mot du système, ou concept hors sujet
                                                        → on le raye

3. RELIER     une association par FAIT du métier, nommée par un VERBE
              (« emprunte », « contient », « réfère »), avec son sens de lecture.

4. COMPTER    la multiplicité à chaque bout, en posant à chaque fois
              la même question : « combien de X pour UN SEUL Y ? »

Prenons la description que le cours emploie, et déroulons les deux premières passes.

« Un lecteur emprunte des livres. Chaque livre a un titre, un auteur et
  un ISBN. Un emprunt enregistre la date de prêt et la date de retour
  prévue. Un lecteur peut avoir plusieurs emprunts simultanés. »

Deux catégories de bruit méritent d'être nommées, parce qu'elles reviennent à chaque énoncé. Le premier bruit, ce sont les synonymes : si la description dit tantôt « client », tantôt « acheteur », ce n'est presque jamais deux concepts — c'est une seule chose mal nommée, et le modèle est l'occasion de fixer lequel des deux mots on garde.

Le second, ce sont les mots du système : « écran », « formulaire », « base de données », « utilisateur ». Ils apparaissent parce que le client décrit souvent son besoin en décrivant un logiciel imaginaire. Ils ne sont pas du domaine : une bibliothèque avait des lecteurs, des livres et des emprunts bien avant qu'un écran n'existe.

Il reste un problème que la méthode ne résout pas : les concepts que l'énoncé ne nomme pas. Une description est écrite par quelqu'un qui connaît son métier et qui saute donc l'évident. Rien ne te dit qu'il manque un concept — c'est l'absence, et l'absence ne se souligne pas.

Le remède est une liste de catégories qu'on passe en revue une fois le tri fait, en se demandant à chaque ligne : en ai-je un de cette sorte ? Elle ne remplace pas la lecture, elle rattrape les oublis.

La dernière ligne mérite un mot, parce qu'elle produit le concept le plus souvent oublié et qu'elle tombe régulièrement en examen. Une bibliothèque possède trois exemplaires du même livre. Sont-ce trois Livre, ou un Livre et trois Exemplaire ? La question se tranche par l'usage : si le système doit savoir lequel des trois est emprunté, il faut les deux concepts — l'un décrit l'œuvre (titre, auteur, ISBN), l'autre l'objet physique qu'on met dans un sac. Confondre les deux rend le modèle incapable de répondre à « reste-t-il un exemplaire disponible ? ».

Concept ou attribut : le choix qui structure tout

C'est la décision de la passe 2, et elle mérite sa propre section parce qu'elle décide de la forme du modèle entier. Se tromper ici ne produit pas une erreur locale : ça produit un modèle qui ne peut pas répondre aux questions qu'on lui posera.

La règle courte : si une valeur simple suffit — un texte, un nombre, une date —, c'est un attribut. Si la chose a sa propre identité, ses propres attributs, ou peut être liée à plusieurs autres, c'est un concept.

Les trois critères se testent, et voici comment. Identité : peux-tu avoir deux exemplaires différents qui portent la même valeur, et as-tu besoin de les distinguer ? Deux clients peuvent s'appeler Tremblay et rester deux clients — Client est un concept. Deux prix de 12,99 $ sont le même prix — le prix est un attribut. Attributs propres : la chose a-t-elle elle-même des données ? Une adresse a un numéro, une rue, un code postal — ça penche vers le concept. Liens multiples : la même chose peut-elle être rattachée à plusieurs autres en même temps ? Un auteur pour plusieurs livres, oui — donc concept.

Facture : numero, dateEmission, nomClient, adresseClient, montantTotal

Client  : numero, nom, adresse

Les associations : nommer le fait, pas le lien

Une association est un lien sémantique entre deux concepts qui exprime un fait du métier. Elle se dessine par un trait, et elle porte un nom.

Ce nom n'est pas décoratif. Une association mal nommée est une association qu'on ne peut pas vérifier auprès du client — et c'est tout l'intérêt du modèle que de pouvoir la lui lire à voix haute. Trois règles : un verbe, jamais un nom (« emprunte », pas « emprunt ») ; un verbe qui dit le fait, pas la mécanique (« réfère », pas « a un lien vers ») ; et un sens de lecture, marqué par un petit triangle, parce que « Lecteur emprunte Livre » et « Livre emprunte Lecteur » ne se valent pas.

Le test qui sépare une bonne association d'une mauvaise : lis-la à voix haute en suivant la flèche. Si tu obtiens une phrase française que le client confirmerait, l'association est bonne. Si tu obtiens du charabia, ce n'est pas le dessin qui est mauvais — c'est que tu n'as pas encore compris le fait.

Il y a un cas où une association ne suffit pas, et l'exemple de la bibliothèque le contient déjà — tu l'as peut-être remarqué. On a écrit « Lecteur emprunte Livre », et pourtant Emprunt est aussi un concept, avec ses propres attributs. Pourquoi les deux ?

Parce que le fait lui-même porte des données. La date de prêt n'appartient ni au lecteur ni au livre : elle appartient au fait qu'un tel a emprunté tel livre ce jour-là. Un trait ne peut rien porter ; dès qu'un lien a des attributs, il doit devenir une boîte. On dit qu'on réifie l'association — littéralement, qu'on en fait une chose.

Le second signe est l'identité, et il est décisif : le même lecteur peut emprunter le même livre deux fois, en janvier puis en mars. Ce sont deux emprunts distincts. Une association simple ne sait pas exprimer ça — entre deux concepts, elle existe ou n'existe pas. Une boîte, si.

Le test, en deux questions : ce lien a-t-il des données à lui ? Peut-il exister plusieurs fois entre les deux mêmes exemplaires ? Un seul « oui » suffit à en faire un concept. C'est ainsi que naissent Emprunt, Inscription, Réservation et Affectation — quatre mots que tu retrouveras dans presque tous les énoncés, et qui sont tous des associations devenues des choses.

Les multiplicités, et le sens où on les lit

La multiplicité dit combien d'instances d'un concept sont liées à une instance de l'autre. Elle s'écrit à l'extrémité du trait, et c'est l'information la plus dense du diagramme — un chiffre y remplace une phrase entière.

Reste la question qui fait perdre le plus de points de tout le cours : de quel côté écrit-on quoi ? Il y a une seule formulation à retenir, et elle marche toujours.

La multiplicité écrite près d'un concept dit combien d'exemplaires de ce concept-là sont liés à UN SEUL exemplaire de l'autre. Autrement dit, pour la lire, place-toi à l'autre bout du trait et compte.

(A) Un employé peut être affecté à plusieurs projets, ou à aucun.
    Un projet compte au moins un employé.

(B) Un compte bancaire appartient à exactement un client.
    Un client peut avoir plusieurs comptes.

(C) Un médecin suit plusieurs patients, ou aucun.
    Un patient n'a qu'un seul médecin traitant.

Agrégation, composition, et pourquoi on en use peu

Deux associations particulières expriment le rapport « partie de », et se distinguent par un losange à l'extrémité du tout.

L'agrégation — losange vide — est faible : la partie peut exister sans le tout. La composition — losange plein — est forte : la partie n'a pas d'existence propre, et si le tout disparaît, elle disparaît avec lui.

Le test habituel est donc : si le tout disparaît, la partie continue-t-elle d'exister de façon significative ? Oui, agrégation. Non, composition.

Et maintenant, ce que les manuels disent rarement et qui vaut la peine d'être su : on en abuse énormément, et Larman lui-même conseille d'y aller doucement. La raison est que le test ci-dessus n'a pas toujours de réponse. Une roue de voiture meurt-elle avec la voiture ? Dans le modèle, oui ; physiquement, on la démonte et on la revend. La réponse dépend de ce que le système doit faire, et pas du monde.

La règle pratique : en cas de doute, une association simple suffit. Elle est toujours correcte, elle ne perd aucune information essentielle, et elle n'engage pas une décision qu'on n'a pas encore les moyens de prendre. Passer d'une association simple à une composition plus tard coûte un losange ; défendre une composition fausse en soutenance coûte plus cher.

(A) Voiture     — Roue
(B) Université  — Étudiant
(C) Personne    — Étudiant
(D) Auteur      — Livre
(E) Maison      — Pièce

La généralisation, et quand elle ment

La généralisation est la relation « est un » entre un concept général et un concept spécialisé. Elle se dessine par un trait terminé d'un triangle vide pointant vers le général, et la spécialisation hérite des attributs et des associations du général.

Étudiant et Professeur sont des Personne : ils en héritent le nom et la date de naissance, et ajoutent chacun ce qui leur est propre. Le test est celui de la phrase : « un étudiant est une personne » fonctionne, « une commande est une ligne de commande » non.

Le piège de la généralisation n'est pas syntaxique — le triangle est facile à dessiner — il est conceptuel, et il porte un nom : elle ment quand la catégorie peut changer. Dans une université, une même personne peut être étudiante cette année et employée l'an prochain, ou les deux à la fois. Modélisée en généralisation, elle devrait alors changer de classe, ce qu'un objet ne fait pas. Le bon modèle est souvent tout autre : une Personne, et des concepts Inscription ou Contrat qui portent le rôle et sa durée.

La question à se poser avant de tracer un triangle est donc : cette catégorie est-elle permanente, ou est-ce un rôle ? Ce qui est permanent se généralise ; ce qui est un rôle se modélise par une association. C'est un des rares endroits de ce cours où la bonne réponse est presque toujours « pas de généralisation ».

Deux précisions qui reviennent en examen. D'abord, la spécialisation hérite des attributs et des associations, pas seulement des attributs : si Personne est associée à Adresse, alors Étudiant l'est aussi, sans qu'on redessine le trait. C'est ce qui rend la généralisation économique — et ce qui la rend coûteuse quand elle est fausse, puisqu'on hérite aussi de ce qu'on ne voulait pas.

Ensuite, une généralisation ne se justifie que si l'enfant a quelque chose à lui : un attribut, une association, ou une règle qui ne vaut que pour lui. Si la seule différence entre deux « sortes » est leur nom, tu n'as pas besoin de deux boîtes — un attribut suffit. Trois classes LivrePapier, LivreNumerique et LivreAudio qui ne diffèrent par rien deviennent un seul Livre avec un attribut format. La question à se poser avant de tracer le triangle : qu'est-ce que l'enfant a que le parent n'a pas ? Si la réponse est « rien », il n'y a pas de spécialisation, seulement une valeur.

Du domaine à la conception

Le modèle du domaine n'est pas un brouillon du diagramme de classes : c'est un document différent, avec un autre but et un autre lecteur. Il sert pourtant de point de départ, et savoir ce qui change entre les deux est une question d'examen classique.

La dernière ligne explique toutes les autres. Un modèle du domaine se montre au client et se fait valider par lui ; tout ce qu'il contient doit donc lui être compréhensible. Un diagramme de classes de conception ne se montre pas au client, parce qu'il répond à des questions qu'il ne se pose pas.

Concrètement, voici où atterrit un concept du domaine une fois passé en conception, puis en code. Le bloc ci-dessous n'est pas là pour t'apprendre Java — il est là pour te montrer que les noms du métier survivent jusqu'au bout, ce qui est tout l'intérêt d'avoir fixé le vocabulaire au début.

public class Emprunt {
  // Les deux attributs viennent DIRECTEMENT du modèle du domaine.
  private Date datePret;
  private Date dateRetourPrevue;

  // L'association « Emprunt concerne un Livre » devient un champ.
  // C'est la conception qui décide de sa DIRECTION : ici on navigue
  // de l'emprunt vers le livre, et pas l'inverse.
  private Livre livre;

  // Cette opération n'existait pas au modèle du domaine : elle répond
  // à un besoin du logiciel, pas à une propriété du métier.
  public boolean estEnRetard(Date aujourdhui) {
    return aujourdhui.after(dateRetourPrevue);
  }
}

Le nom de la classe, ceux des attributs et celui de l'association viennent du modèle du domaine. Ce qui s'ajoute — les types, la visibilité, la direction de navigation, l'opération — est de la conception.

Reservation
  - id : Long
  - salleId : Long
  - dateDebut : Date
  + confirmer() : void
  + annuler() : void