Diagramme de classes (UML)
Un diagramme de classes UML montre la structure d'un domaine sous forme de classes, les catégories d'objets sur lesquelles l'organisation garde de l'information. Chaque classe porte les attributs qui la décrivent, les opérations qui disent ce que l'on peut en faire et les associations qui la relient à d'autres, chaque association annotée d'une multiplicité qui fixe le nombre d'occurrences admises à chacun de ses bouts. C'est la notation de modélisation de données propre à la conception orientée objet: là où le diagramme entités-relations sert le schéma d'une base relationnelle, le diagramme de classes sert la structure d'un logiciel, et il est le seul des deux à porter le comportement en plus de la structure. La notation est définie par la spécification UML de l'OMG. La notation se lit au niveau conceptuel et d'analyse, celui qui revient au business analyst.
Objectif
Le diagramme de classes donne une représentation partagée et non ambiguë de la structure d'un domaine destiné à un logiciel orienté objet: quelles classes existent, ce qu'elles portent en attributs et en opérations et comment elles se relient. Il l'écrit dans un vocabulaire que le métier peut confirmer et que le développeur peut implémenter. La décision qu'il soutient est celle de la structure du code, les classes du domaine et leurs associations, au moment où ce choix est encore discutable et peu coûteux à défaire, avant l'implémentation.
Le livrable est un diagramme accompagné d'un texte qui le documente. Au niveau qui concerne le business analyst, c'est un modèle conceptuel et d'analyse: les classes du domaine, leurs attributs essentiels, les opérations métier significatives, les associations nommées dans les mots du métier et les multiplicités posées à leurs bouts. Le BABOK situe le diagramme de classes comme l'une des deux notations du modèle de données, celle qui soutient un développement orienté objet, et il l'oppose au diagramme entités-relations, qui sert le schéma d'une base relationnelle. Le hub de la modélisation des données pose ce partage et oriente vers la notation qui convient.
Usage
Quand l'utiliser
- Conception d'un logiciel orienté objet: l'artefact conçu est la structure du code, les classes et leurs associations le cadrent.
- Le comportement compte autant que la structure: la classe porte des opérations que le diagramme entités-relations ne sait pas exprimer.
- Développeur comme lecteur en aval: le diagramme de classes est la notation que l'équipe de développement lit couramment.
- Système orienté objet existant à documenter: reconstruire les classes et leurs liens réels avant une évolution ou une reprise.
Quand ne pas l'utiliser
- Artefact conçu = schéma d'une base relationnelle: c'est le schéma persistant qui se conçoit, non le code, prendre le diagramme entités-relations.
- Vocabulaire du domaine encore disputé: fixer le sens d'abord avec un modèle de concepts, la structure ensuite.
- Public strictement métier, sans culture informatique: le formalisme rebute, tenir un glossaire pour ce public.
Description
Un business analyst n'a pas à dessiner tout UML pour se servir d'un diagramme de classes. Il lui faut savoir lire une poignée d'éléments et les combiner. Le reste de la notation appartient au niveau de conception détaillée et sort du périmètre du business analyst.
La classe et ses trois compartiments
Une classe est un rectangle à trois compartiments empilés. Le nom de la classe occupe le compartiment du haut, au singulier et dans les mots du métier. Les attributs occupent le compartiment du milieu, les opérations celui du bas. Le nom seul suffit tant que le reste n'est pas encore posé, et les deux compartiments inférieurs se remplissent au fur et à mesure.
Un attribut est une information retenue sur la classe, écrite sous la forme nom: Type, par exemple prixCHF: Décimal ou dateDébut: Date. Le type est facultatif au niveau conceptuel et se précise vers le niveau logique. L'attribut dit quelle information est retenue, ses valeurs admises et son format, mais les définitions détaillées relèvent du dictionnaire de données. Une opération dit ce que l'on peut faire de la classe, écrite au bas du rectangle, par exemple valider() ou renouveler(dateFin). C'est elle qui sépare la classe de l'entité d'un diagramme entités-relations: l'entité porte des attributs et des relations, elle ne porte pas de comportement.
L'association, la multiplicité, la généralisation
Une association est une ligne entre deux classes, qui dit qu'elles se relient et comment. On la nomme volontiers par un verbe, détient ou couvre. Dans un modèle de classes on parle d'association là où un modèle de données parle de relation.
La multiplicité est l'annotation portée à chaque bout de l'association. Elle fixe le nombre minimal et maximal d'occurrences admises du côté où elle est écrite. Les valeurs usuelles sont 1 pour exactement un, 0..1 pour zéro ou un donc facultatif, * ou 0..* pour un nombre quelconque et 1..* pour au moins un. On parle de multiplicité là où un modèle de données parle de cardinalité, pour la même idée de bornes. Ce qui piège le plus souvent est le sens de lecture: la borne écrite à un bout se lit sur ce bout. Dans « un client détient 0..* abonnements », le 0..* est écrit du côté abonnement et décrit le nombre d'abonnements, non le nombre de clients. Lire 0..* comme « obligatoire » est l'autre erreur courante, alors que le 0 dit que le lien est facultatif.
La généralisation est le lien « est-un ». On la dessine par une ligne terminée d'un triangle creux qui pointe vers la classe générale, la super-classe. Les sous-classes héritent des attributs, des opérations et des associations de la super-classe et ajoutent les leurs. Le triangle creux la distingue de l'association: le triangle marque un héritage, la ligne simple un lien structurel. Prendre l'un pour l'autre fausse la lecture du modèle. Pour composer un diagramme, on pose les classes du domaine, on remplit leurs attributs et leurs opérations métier significatives, on les relie par des associations annotées de multiplicités et l'on factorise ce qui est commun à plusieurs classes dans une super-classe reliée par généralisation.
Le niveau qui revient au business analyst
Un diagramme de classes existe à plusieurs niveaux, comme tout modèle de données. Le niveau conceptuel et d'analyse est celui du business analyst: classes du domaine nommées dans les mots du métier, attributs essentiels, opérations métier, associations et multiplicités. Il est indépendant de la technologie et le métier peut le confirmer ou l'infirmer. Les niveaux logique et physique, la visibilité des membres, les types techniques, les signatures de méthodes, les interfaces et les classes d'infrastructure, sont ceux des experts de l'implémentation. Le BABOK réserve ces niveaux à ceux qui implémentent la solution orientée objet.
De là vient le piège central pour un business analyst: sur-modéliser vers l'implémentation. Ajouter des marqueurs de visibilité +/-, des accesseurs getX et setX, des types techniques ou des patrons de conception empiète sur un autre métier et alourdit un modèle de détail que le métier ne peut plus valider. Le second piège est de confondre le diagramme de classes avec le diagramme entités-relations. Les deux modélisent le même contenu conceptuel du domaine, mais ils servent des artefacts différents et parlent deux vocabulaires: la classe porte des opérations et parle d'association et de multiplicité, l'entité ne porte pas de comportement et parle de relation et de cardinalité. Le critère qui les départage est donc l'artefact conçu, code orienté objet ou schéma relationnel. Une application orientée objet posée sur une base relationnelle, cas ordinaire en Suisse, produit les deux modèles.
Considérations IA
Un modèle de langage rend deux services sur cette technique. Le premier est la dérivation d'un modèle candidat: il lit un corpus d'exigences, des comptes rendus d'entretiens ou du code existant et propose des classes, des attributs, des opérations et des associations. Sur un système hérité sans documentation, le gain est réel, et le brouillon obtenu se corrige plus vite qu'une page blanche ne se remplit. Le second est le repérage des manques: une classe orpheline sans association, une association plausible qui n'a pas été dessinée ou un attribut répété dans plusieurs classes qui suggère une généralisation à factoriser.
La limite est ferme et de nature métier. La multiplicité correcte, qu'un client puisse détenir plusieurs abonnements ou qu'une police ne couvre qu'un assuré, est un fait métier que le texte ne livre pas de façon fiable, et une borne fausse fait mentir le modèle. La sémantique du domaine, ce qu'une classe signifie pour l'organisation et le fait qu'une association existe réellement dans son activité, se confirme auprès des experts. Et un modèle de langage tend à sur-modéliser vers l'implémentation. Toute proposition de l'IA est un brouillon soumis aux experts du domaine et au business analyst qui tient le niveau d'analyse.
Exemples
Le concept que l'exemple rend visible est l'assemblage de trois éléments sur un seul petit diagramme: la classe à trois compartiments, l'association annotée de multiplicités et la généralisation. Le cas retenu est celui des abonnements de transport public suisse, où l'abonnement général et le demi-tarif sont deux types d'un même abonnement.
Deux points sont faciles à manquer. La multiplicité 0..* est écrite du côté Abonnement et se lit là: un client détient zéro, un ou plusieurs abonnements, tandis que le 1 du côté Client dit qu'un abonnement appartient à exactement un client. Le triangle creux qui pointe vers Abonnement marque un héritage: AbonnementGénéral et DemiTarif héritent de numéro, dateDébut, dateFin et prixCHF ainsi que des opérations valider() et renouveler(), et chacun n'ajoute que son attribut propre, la classe pour l'abonnement général, le taux de rabais pour le demi-tarif. Quatre classes, une association et une généralisation suffisent à porter toute la notation qu'un business analyst a besoin de lire.
Visualisations
La forme porte le sens. Le rectangle à trois compartiments dit qu'un objet a un nom, des attributs et des opérations. La ligne dit une association, et la borne écrite à son bout se lit sur ce bout. Le triangle creux dit une généralisation et pointe vers la classe générale. Un lecteur qui connaît ces trois signes lit sans légende un diagramme de classes complet, comme celui des abonnements.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Moyen | Rassembler les sources, exigences, comptes rendus d'entretiens, code ou schéma existant, puis identifier les experts qui confirment avec autorité les classes, les associations et leurs multiplicités. |
| Exécution | Faible à moyen | Le niveau d'analyse se pose en quelques séances avec les experts du domaine. Le coût croît avec le nombre de classes et d'associations. Le détail d'implémentation reste hors du périmètre du business analyst. |
| Documentation | Moyen | Le modèle d'analyse vit avec le domaine et se met à jour à chaque évolution des classes ou des liens. Il reste plus léger que les modèles logique et physique, tenus par l'implémentation. |
Outils
Un tableau blanc suffit à une première ébauche: quelques classes et leurs liens tiennent sur une surface et se corrigent debout, ce qui est souvent la bonne échelle pour le niveau d'analyse. Les outils de schéma généralistes, diagrams.net, Lucidchart ou Visio, portent des gabarits UML et donnent un dessin propre et partageable, adaptés tant que le diagramme reste un support de discussion. Les ateliers de modélisation UML dédiés, Enterprise Architect, Visual Paradigm, StarUML ou Modelio, tiennent le diagramme de classes comme une vue d'un modèle cohérent: ils vérifient le modèle, le relient aux autres diagrammes UML et, du côté de l'implémentation, génèrent le code depuis les classes ou rétro-conçoivent les classes depuis un code existant. Cette rétro-conception est utile pour documenter un système orienté objet hérité, à condition de ramener ensuite le résultat au niveau d'analyse plutôt que de laisser le détail technique saturer le modèle. Les outils à génération textuelle, comme PlantUML, décrivent le diagramme en quelques lignes de texte versionnables, ce qui convient à un modèle tenu à côté du code.
Sources
- OMG (Object Management Group), Unified Modeling Language (UML) Specification, version 2.5.1: la spécification qui définit le diagramme de classes et sa notation, classes à trois compartiments, attributs, opérations, associations, multiplicité et généralisation. C'est l'ancre normative de la notation.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling: le diagramme de classes parmi les deux notations du modèle de données, la définition de classe, attribut, opération et association et la règle de routage qui l'emploie pour un développement orienté objet.