Le diagramme de classes & l'architecture logique

Même notation que le modèle du domaine, et un tout autre document. Celui-ci ne décrit plus le monde : il décrit le logiciel qu'on va écrire, classe par classe, trait par trait. Et chaque chose qu'il ajoute est une décision — donc quelque chose qu'on peut prendre autrement, et qu'il faudra savoir défendre.

Ce que la conception ajoute, et pourquoi c'est une décision

Le diagramme de classes de conception — on l'abrège DCC, et Larman l'appelle design class diagram — emploie exactement la même notation que le modèle du domaine. Des boîtes, des traits, des nombres aux extrémités. C'est précisément ce qui le rend piégeux : rien dans le dessin n'annonce qu'on a changé de monde.

Ce qui a changé, c'est le lecteur. La section Du domaine à la conception du module Le modèle du domaine dresse le tableau des sept différences, et sa dernière ligne explique les six autres : le modèle du domaine se montre au client, le DCC ne se montre qu'à l'équipe. On ne va pas le refaire ici. On va faire l'inverse : regarder chacun de ces ajouts comme ce qu'il est vraiment — une décision.

Reprends la classe Emprunt du module précédent. En analyse, elle porte datePret et dateRetourPrevue, et rien d'autre. En conception, elle porte - datePret : Date. Trois choses se sont ajoutées à cette seule ligne, et chacune est un choix :

• Le type Date — on aurait pu prendre un entier de secondes, ou trois entiers jour/mois/année. Le choix engage tout le reste : comparer deux dates, les afficher, les stocker.
• La visibilité - — on décide que personne d'autre qu'Emprunt ne touche à cette date. Ce n'est pas une évidence : c'est l'affirmation qu'on veut pouvoir changer sa représentation plus tard sans casser personne.
• Le fait qu'elle soit là — un attribut du domaine peut très bien ne jamais devenir un attribut de classe. S'il se recalcule à partir des autres, on écrit une opération à la place.

Voilà la vraie nature du passage à la conception. Le modèle du domaine te disait quels mots existent ; le DCC répond à des questions que le domaine ne pose pas, et à chacune il y avait plusieurs réponses acceptables. C'est aussi pour ça qu'un examen peut te demander de justifier un choix de conception, ce qu'il ne demanderait jamais d'un modèle du domaine.

Une chose, en revanche, ne change pas et ne doit pas changer : les noms. Si le métier dit « emprunt », la classe s'appelle Emprunt, du modèle du domaine jusqu'au fichier Emprunt.java. C'est tout le bénéfice d'avoir fixé le vocabulaire au début, et il se perd en une seule renommage malheureux.

La boîte, ligne par ligne

La boîte a trois compartiments : le nom, les attributs, les opérations. Tu les as déjà vus au module Le modèle du domaine, où le troisième restait vide. Ici il se remplit, et chaque ligne des deux compartiments du bas suit une grammaire précise. C'est cette grammaire que l'examen te demandera d'écrire sans hésiter — et sans notes.

VISIBILITÉ   +  public       accessible de partout
             -  privé        accessible dans la classe seule
             #  protégé      la classe et ses sous-classes
             ~  paquetage    les classes du même paquetage

ATTRIBUT     visibilité nom : Type [multiplicité] = valeurParDefaut
                -  solde : double = 0.0
                -  lignes : LigneCommande [1..*]

OPÉRATION    visibilité nom(param : Type, ...) : TypeRetour
                +  calculerTotal() : double
                +  ajouterLigne(plat : Plat, quantite : int) : void

             souligné = membre de CLASSE       italique = ABSTRAIT

Quelques précisions qui reviennent en examen. La multiplicité d'un attribut, entre crochets, dit qu'il en contient plusieurs : lignes : LigneCommande [1..*] annonce une collection, et c'est souvent une autre façon d'écrire une association — on y revient dans la section « La navigabilité, ou le trait qui devient un attribut ».

Le soulignement marque ce qui appartient à la classe et non aux objets — static en Java. + nombreDeComptes() : int souligné veut dire qu'on l'appelle sur la classe CompteBancaire elle-même, sans avoir de compte sous la main. L'italique, lui, marque l'abstrait : une classe en italique ne s'instancie pas, une opération en italique n'a pas de corps et doit être redéfinie plus bas. Ces deux marques sont typographiques et non symboliques, ce qui est leur seul défaut : sur une copie manuscrite, souligne franchement.

              CompteBancaire
  -----------------------------------------
    numero : String
  - solde
  # tauxInteret : double
  -----------------------------------------
  + deposer(montant : double)
  - validerMontant(m : double) : boolean
  + nombreDeComptes : int

D'où viennent les opérations

Voici la question que les cours sautent presque toujours, et sur laquelle on bute dès qu'on est devant une copie blanche : qui décide qu'Emprunt a une opération estEnRetard() ? Pas le client, on vient de le voir. Pas le modèle du domaine, qui n'en porte aucune. Il y a une réponse, et elle vient en trois temps.

Premier temps : les opérations système. La section Les opérations système du module Cas d'utilisation & DSS le dit déjà : chaque flèche entrante d'un DSS est une opération que le système doit rendre, et cette liste est le contrat que la conception doit réaliser. C'est l'entrée de ce module. Si ton DSS d'emprunt donne identifierLecteur(numero), identifierLivre(isbn) et confirmerEmprunt(), tu as trois obligations, et pas une de plus.

Deuxième temps : une opération système n'est pas une méthode de classe. C'est la marche qu'on rate. confirmerEmprunt() est une opération du système entier, vu de l'extérieur comme une boîte noire. Elle doit maintenant être attribuée à une classe, qui devra en appeler d'autres pour faire le travail — et chacun de ces appels devient à son tour une opération de la classe appelée.

Troisième temps : c'est le diagramme d'interaction qui fait cette distribution. On y dessine les objets qui collaborent et les messages qu'ils s'envoient ; tout message reçu par un objet est une opération de sa classe. C'est mécanique, et c'est la seule source complète des opérations.

Reste ce qu'on peut écrire tout de suite, sans avoir tracé un seul message, et qui suffit largement pour un premier livrable :

1. Les opérations qui découlent des attributs. Un Emprunt qui connaît sa dateRetourPrevue sait dire s'il est en retard. Une Commande qui connaît ses lignes sait calculer son total. La règle qui les trouve est simple : quelle question peut-on poser à cet objet à laquelle lui seul peut répondre ?
2. Les opérations qui viennent d'une règle du métier. « Un lecteur qui doit plus de 5 $ ne peut pas emprunter » donne + estEnRegle() : boolean sur Lecteur. La règle existait dans l'énoncé ; elle n'avait simplement nulle part où aller en analyse.
3. Les opérations système, posées sur un contrôleur. On leur donne une classe d'accueil — voir la section « Les classes que le métier n'a jamais eues » — quitte à ce que son contenu se précise plus tard.

1. identifierLecteur(numero)
2. identifierLivre(isbn)
3. confirmerEmprunt()

Classes disponibles : ControleurEmprunt, Lecteur, Livre, Emprunt

La navigabilité, ou le trait qui devient un attribut

Dans le modèle du domaine, une association est un fait : « un emprunt concerne un livre ». Le fait n'a pas de direction — il est vrai des deux côtés à la fois. En conception, ce confort disparaît, parce qu'un objet en mémoire ne connaît que ce qu'il garde. Il faut décider qui garde la référence de qui, et cette décision s'appelle la navigabilité.

Elle se note par une flèche ouverte à l'extrémité qu'on peut atteindre. Et il faut connaître la convention du cours avant tout le reste, parce qu'elle est contre-intuitive et qu'elle tombe en examen : une association sans aucune flèche se lit comme bidirectionnelle — chacun peut atteindre l'autre. Ne pas trancher n'est donc pas neutre : c'est choisir par défaut l'option la plus coûteuse.

Le code rend cette traduction évidente, et c'est la raison pour laquelle ce module montre du Java alors qu'il parle de diagrammes : la flèche est l'attribut.

public class Emprunt {
  private Date datePret;
  private Date dateRetourPrevue;

  // LA FLÈCHE « Emprunt ──▶ Livre » EST CETTE LIGNE.
  // Multiplicité 1 du côté Livre : un seul champ, pas une collection.
  private Livre livre;

  // Rien dans Livre ne pointe vers Emprunt : la flèche ne va que
  // dans un sens, donc Livre ignore par quels emprunts il est passé.
  public boolean estEnRetard(Date aujourdhui) {
    return aujourdhui.after(dateRetourPrevue);
  }
}

Une association navigable donne un champ dont le type est la classe visée. C'est la seule chose que la flèche veut dire — et c'est aussi pourquoi une flèche tracée à la légère devient une dépendance qu'on traîne jusqu'au dernier livrable.

La troisième ligne de la figure mérite qu'on s'y arrête, parce qu'elle est le cas que le code rate le plus souvent. Si l'extrémité visée porte 0..* ou 1..*, l'attribut n'est plus une référence unique : c'est une collection. Une Commande navigable vers ses LigneCommande en multiplicité 1..* donne private List<LigneCommande> lignes; — et sur le diagramme, on a le droit d'écrire la même chose dans le compartiment des attributs, - lignes : LigneCommande [1..*]. Les deux notations disent exactement la même chose ; on choisit le trait quand la classe visée est importante, l'attribut quand elle est secondaire.

Comment décide-t-on du sens ? Par les besoins réels, jamais par symétrie. La question à poser est : y a-t-il un scénario où un objet de cette classe doit envoyer un message à l'autre ? Si oui, il faut la flèche ; si non, elle ne sert à rien et coûte quelque chose. Trois indices classiques qu'une flèche est nécessaire : A crée B, A doit lire ou modifier B, ou A reçoit un message qui l'y oblige.

public class Commande {
  private LigneCommande ligne;
  private Client client;
}

public class LigneCommande {
  private Commande commande;
}

La dépendance, et ce qu'un pointillé avoue

Il existe un quatrième trait, qu'on n'a pas encore croisé parce qu'il n'a aucun sens en analyse : la dépendance. Elle se dessine par une flèche en pointillé, et elle dit quelque chose de plus faible qu'une association : « cette classe a besoin de connaître l'autre, mais elle ne la garde pas ».

Le critère est la durée. Une association vit aussi longtemps que l'objet : le champ est là, entre deux appels, tant que l'objet existe. Une dépendance ne vit que le temps d'un appel de méthode. Trois formes, et ce sont les trois que l'examen montre :

• la classe reçoit l'autre en paramètre d'une de ses opérations ;
• elle la retourne ;
• elle l'utilise localement, ou appelle une de ses opérations de classe (une méthode static).

Pourquoi consacrer une section à un trait aussi discret ? Parce qu'il est le lien le plus faible avec lequel deux classes peuvent encore collaborer, et que c'est exactement ce qu'on cherche. Deux classes reliées par une association sont soudées : on ne peut plus toucher à l'une sans risquer l'autre. Deux classes reliées par une dépendance ne se rencontrent que le temps d'un appel.

D'où une habitude qui vaut pour tout le reste de la session : quand une association peut se remplacer par une dépendance, on le fait. Si le contrôleur n'a besoin du livre que pendant confirmerEmprunt(), il ne doit pas le stocker ; il le reçoit, l'utilise, l'oublie. Ce réflexe porte un nom qu'on te donnera formellement en semaine 6 — le faible couplage, l'un des Les principes GRASP —, et tu peux commencer à l'appliquer avant de connaître son nom.

Les classes que le métier n'a jamais eues

Le modèle du domaine ne contenait que des concepts prononçables par le client. Le DCC en contient d'autres, et ces autres sont souvent la majorité des boîtes. Le client ne reconnaîtrait ni ControleurEmprunt, ni FenetreEmprunt, ni EmpruntDAO — et c'est très bien, parce que ce sont des réponses à des questions qu'il ne se pose pas.

Pour les ranger, UML permet de coller une étiquette sur une classe : un stéréotype, écrit entre chevrons doubles. Trois d'entre eux forment le vocabulaire de base de la conception orientée objet, hérités de l'analyse dite « robuste » d'Ivar Jacobson.

Le contrôleur mérite qu'on s'y arrête, parce que c'est la classe qui répond à la question laissée ouverte plus haut : où atterrit une opération système ? Elle atterrit sur un contrôleur, et il y a deux façons d'en choisir un. Soit un contrôleur par cas d'utilisation — ControleurEmprunt, ControleurRetour —, soit un contrôleur unique qui représente le système entier ou l'organisation. Le premier choix est le plus sûr dès que le système a plus d'une poignée de cas d'utilisation.

La frontière est plus large que ce que son nom courant laisse croire : ce n'est pas seulement l'interface graphique. Une classe qui parle à une passerelle de paiement est une frontière, une classe qui lit un lecteur de codes-barres aussi. C'est la même idée que les acteurs non humains du module Cas d'utilisation & DSS, descendue d'un niveau.

Et il en manque une quatrième dans le trio classique, que tout projet réel possède : la persistance. Les classes en DAO (data access object) ou en Repository savent aller chercher une entité dans une base de données et l'y remettre. On les traite en pratique comme une frontière — la base est un système externe comme un autre.

Si ce trio te rappelle quelque chose, c'est normal : MVC — Modèle-Vue-Contrôleur — est l'application de ces trois rôles aux interfaces graphiques. La vue est une frontière, le modèle une entité, et le contrôleur porte le même nom des deux côtés. MVC n'est donc pas une notion de plus à apprendre : c'est le vocabulaire que le monde du logiciel a retenu de ces stéréotypes.

(A) FormulaireConnexion
(B) Lecteur
(C) ControleurRetour
(D) LecteurCodeBarres
(E) ControleurPrincipal
      + emprunter()  + retourner()  + inscrire()
      + payerAmende()  + reserver()  + imprimerRapport()

L'architecture logique : regrouper en paquetages

Une trentaine de classes tiennent encore sur une feuille. Deux cents, non — et le vrai problème n'est même pas le dessin : c'est qu'on ne sait plus dire ce qui dépend de quoi. L'architecture logique répond à ça. Elle est l'organisation des classes en paquetages et les dépendances entre ces paquetages, et c'est la seconde moitié de ton Livrable 2.

Le mot est resté sans définition jusqu'ici, alors même qu'il apparaissait dans le tableau de visibilité de la formule. Un paquetage est un regroupement nommé de classes — rien de plus, et c'est déjà beaucoup : il crée une frontière, donc un intérieur et un extérieur. Sa notation UML est un rectangle avec un onglet en haut à gauche, comme une chemise cartonnée, et les dépendances entre paquetages se tracent en pointillé, exactement comme entre classes.

En Java, la correspondance est directe et c'est ce qui la rend facile à retenir : un paquetage est un dossier, et chaque fichier annonce le sien par une ligne package. L'arborescence de ton dépôt est ton architecture logique.

src/
└── bibliotheque/
    ├── presentation/     FenetreEmprunt, FenetreRetour
    ├── application/      ControleurEmprunt, ControleurRetour
    ├── domaine/          Emprunt, Livre, Lecteur
    └── persistance/      EmpruntDAO, LivreDAO

Quatre paquetages, quatre dossiers, et la même chose vue de deux façons. Le diagramme de paquetages du livrable ne dit rien de plus que cette arborescence, plus les flèches qui disent qui a le droit d'appeler qui.

Le ~ de la formule prend enfin son sens : une visibilité paquetage rend un membre accessible aux classes du même paquetage et à personne d'autre. En Java, c'est ce qu'on obtient en n'écrivant aucun mot-clé devant un membre — le défaut du langage. C'est utile pour laisser deux classes voisines collaborer étroitement sans ouvrir la porte au reste du système.

Reste la question qui décide de tout : selon quoi découpe-t-on ? Deux réponses s'affrontent dans la vraie vie. Par couche technique — présentation, application, domaine, persistance — ou par fonctionnalité — emprunt, retour, inscription, chacune contenant sa fenêtre, son contrôleur et ses entités. Le cours, et Larman avec lui, enseignent le découpage par couche : c'est celui que ton livrable doit montrer, et celui que la section suivante explique.

Une seule règle est absolue, quel que soit le découpage : pas de cycle entre paquetages. Si presentation dépend de domaine et que domaine dépend de presentation, les deux ne forment plus qu'un seul bloc qu'on ne peut ni compiler, ni tester, ni comprendre séparément — et on a perdu exactement ce qu'on était venu chercher.

Les couches, et la règle qui les tient

Le découpage en couches range les paquetages en strates horizontales, de l'écran vers le disque. Quatre suffisent à décrire presque tous les systèmes de gestion, et ce sont celles que ton livrable doit nommer.

La règle qui les tient tient en une phrase : une couche n'appelle que celle qui est immédiatement sous elle. Pas au-dessus, et pas en sautant. Le corollaire le plus utile en pratique : une fenêtre ne parle jamais directement à une entité. Elle s'adresse au contrôleur, qui s'adresse aux entités — c'est ce qui permet à la même règle de tourner ensuite derrière une autre interface.

Les manuels justifient cette règle par quatre mots — découplage, testabilité, réutilisation, clarté — qui sont vrais et qui n'expliquent rien. La vraie raison est plus simple, et une fois vue elle ne se réoublie pas : appeler, c'est dépendre. Si A appelle B, alors tout changement de B peut casser A. Le sens des flèches est donc le sens dans lequel les changements se propagent.

Or les quatre couches ne changent pas à la même vitesse. L'écran change tout le temps — un client vous demandera trois refontes. La base change souvent. Les règles du métier, elles, changent rarement : une bibliothèque prête des livres pour trois semaines depuis toujours. On oriente donc les dépendances de l'instable vers le stable, jamais l'inverse. Une couche métier qui connaît la fenêtre est une règle durable rendue fragile par un écran qui ne durera pas six mois.

Le test qui vérifie tout ça en une question : peux-tu remplacer l'interface graphique par une ligne de commande sans toucher au métier ? Si oui, l'architecture tient. Si non, quelqu'un a tracé une flèche vers le haut.

Classes :  FenetreCommande     ServiceCalculTaxe
           ControleurPaiement  CommandeRepository
           Commande            PasserelleStripe

Appels :  1. ControleurPaiement  →  Commande
          2. Commande            →  CommandeRepository
          3. ControleurPaiement  →  CommandeRepository

Relire son diagramme avant de le rendre

Tout ce qui précède se perd si le diagramme rendu oublie ses visibilités. Cette dernière section n'apporte donc aucune notion neuve : elle donne la relecture à faire, dans l'ordre, avant de remettre une copie ou un livrable. Elle prend trois minutes et elle rapporte plus que n'importe quel raffinement de conception.

1. Chaque boîte a-t-elle ses trois compartiments ? Et le troisième est-il rempli ? Une classe sans opération, dans un diagramme de conception, est soit une erreur, soit un aveu — on n'a pas encore décidé ce qu'elle fait.
2. Chaque attribut et chaque opération porte-t-il sa visibilité ? C'est le premier point que le correcteur balaie, parce qu'il se vérifie sans lire.
3. Chaque attribut et chaque opération porte-t-il son type ? Retour compris — : void s'écrit.
4. Chaque association porte-t-elle ses deux multiplicités ? Le module Le modèle du domaine l'appelait déjà l'erreur la plus fréquente du cours ; elle ne disparaît pas en conception, elle s'y ajoute la navigabilité.
5. Chaque flèche correspond-elle à un besoin que tu peux nommer ? Et les bidirectionnelles, les as-tu vraiment voulues ?
6. Chaque classe est-elle dans une couche, et chaque dépendance descend-elle ? Une seule flèche qui remonte suffit à casser l'architecture qu'on annonce.
7. Les noms viennent-ils du modèle du domaine ? Si une entité s'est fait renommer en chemin, remets son nom d'origine.

Une dernière chose, qui n'est pas de la relecture mais qui vaut d'être dite ici. Un diagramme de conception n'a pas à être complet pour être bon. Montrer trois classes et leurs vraies relations vaut mieux que trente boîtes dont on n'a rempli aucun troisième compartiment. Ce qu'on évalue est la cohérence des décisions, pas le nombre de rectangles.