Selon le risque (financier, humain, juridique…) la rédaction d’un cahier des charges peut impliquer de concevoir un diagramme de classe UML. En faisant cela, vous ‘ »assurez » la parfaite gestion des données à manipuler lors du projet. Plus de « trou dans la raquette » que l’on constate en fin de projet. On sécurise tranquillement, mécaniquement.
Vous pouvez obtenir la norme ici (source : www.omg.org : The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium.)
On donne également un autre nom à ce diagramme de classe, qui change un peu dans la forme, mais dont la finalité est la même. C’est le « modèle conceptuel de données » selon l’appellation de la norme Merise, plutôt franco-française. Vous avez dans le même esprit la notation Pattes de Corneille « Crow’s Foot » de nos amis anglais.
Or, si l’on n’est pas familier avec ce fameux diagramme de classe et / ou si l’on n’a pas la possibilité de se faire relire par un collaborateur plus expérimenté en modélisation de données, il y a de fortes chances pour que l’on fasse des erreurs de conception. Si elles échapperont probablement au « Métier » qui vous validera votre cahier des charges, elles ne manqueront pas de sauter aux yeux du fournisseur (MOE) qui cherche (normalement) à développer la meilleure solution.
Par conséquent, cet article propose des conseils pratiques pour apprendre à relire un diagramme de classe, détecter les erreurs éventuelles et les corriger. En revanche, compte tenu des spécificités de chaque projet, il ne vous aidera peut-être pas à contrôler sa cohérence « fonctionnelle ». Il faudrait que vous soumettiez votre schéma à votre prestataire en conception et que vous puissiez échanger avec lui de vive voix.
Les diagrammes de classe que l’on produit ont pour vocation première de nous aider, en tant que MOA (celui qui a un besoin) ou aMOA (celui qui l’aide), à comprendre un domaine métier. Cela creuse efficacement un besoin et à assure la complétude fonctionnelle. Chacun des points pourraient d’ailleurs faire l’objet d’un article, n’hésitez pas à me le signaler si vous êtes intéressés. Cependant, ils seront également intégrés à nos cahiers des charges et donc lus. Voici quelques règles pour qu’ils le soient vraiment.
1) Diagramme de classe lisible = polices de caractères lisibles
Ne pas pouvoir lire « physiquement » un schéma est déjà un grave problème , vous ne pensez pas ? Alors commençons par le commencement :
la taille de police des schémas doit être supérieure à l’équivalent 8 pt en Arial.
En dessous, cela est illisible, donc d’une faible plus-value (si c’est illisible, cela ne servait à rien de le mettre en fait 🙂 )
2) le diagramme de classe tient sur 1 page
le schéma doit tenir sur une page A4, de préférence en orientation portrait.
Au pire, en orientation paysage mais jamais plus, sinon on perd la vision globale, vous noyez tout le monde sur des détails et on perd le sens du projet.
Que faire si le diagramme est trop volumineux pour respecter l’une voire les deux de ces contraintes ? Il faut tout simplement le découper en unités thématiques cohérentes et ne mettre dans le cahier des charges que les unités. On pourra bien entendu insérer l’image du schéma complet mais en Annexe, afin de tout de même montrer qu’il existe et qu’on a fait le travail jusqu’au bout.
3) Rangez vos classes !
Faites des regroupements thématiques, avec un titre et une couleur unique.
diagramme de classe av.
diagramme de classe après
Pour vous donner un exemple vu de loin, sans dévoiler la conception de mon client dans le détail (d’où le flou), j’ai réalisé ce diagramme de classe dans le cadre d’un projet au forfait. Il est d’une complexité relative (une trentaine de classes) et donc difficilement lisible / compréhensible pris dans son ensemble.
Les regroupements thématiques via un code couleur et des titres (formation, tiers, remboursement, etc.), m’ont permis de décrire le diagramme de façon phrasée, progressive, logique et par petits bouts plus facilement appréhendables.
Si vous avez déjà anticipé le fait que la description textuelle d’un diagramme de classe est encore plus efficace, faites-le savoir en commentaire 🙂 ! Il y a plein de bonnes pratiques très faciles à assimiler que je serai ravi de partager avec vous.
Le bénéfice immédiat de ce découpage est que le métier comprend mieux les choses du fait de la décomposition de la complexité. De plus, le cahier des charges est plus aéré, plus agréable à lire. En effet, au lieu d’avoir une seule grosse image peu exploitable suivie d’un long texte descriptif, nous en avons mis cinq plus petites. Celles-ci étant toutes décrites, cela permet une bonne alternance entre texte et dessin et donc un accroissement de l’agréabilité du document.
4) Nommez les classes par un nom commun, unique et au singulier
Chaque nom de classe est un nom commun.
Il ne peut pas y avoir de nom propre. Cela signifie que si nous devions, par exemple, refondre le Système Informatique du lycée Chateaubriand, « Lycée Chateaubriand » ne serait pas nommé.
Un nom de classe est unique sur le schéma.
On ne peut pas mettre deux classes nommées de façon identique sans fausser complètement la compréhension.
Par exemple: si dans le diagramme que vous représentez,
la classe « Client » a un type (client de type « particulier », « professionnel », etc.)
et que la classe « Produit » en a également un (produit de type « électroménager », « textile », « téléphonie », etc.)
alors ces deux classes doivent porter des noms différents : « Type de client » et « Type de produit ».
Toutes les classes doivent être écrites au singulier.
C’est ainsi, écrire « Clients » est une erreur de formalisme.
5) les classes ont un « sens métier »
Les noms que j’utilise pour représenter les classes sont validées par le Métier.
Toujours dans le cadre de notre SI scolaire, si mes interlocuteurs parlent de professeurs, je ne représenterai pas cela par une classe « Enseignant ». Le diagramme doit reprendre exactement le vocabulaire du Métier.
Pars ailleurs, je dois
donner une définition et un exemple pour chaque classe du diagramme.
En effet, cela garantit la compréhension et permet de s’assurer que chaque classe est utile au projet. Il arrive de manière assez récurrente que le métier décrive un besoin un peu fantôme, fantasmagorique. Pour le démasquer, le procédé est simple : demandez lui un exemple. S’il n’en n’a pas…
6) les classes servent à quelques chose !
Le diagramme de classe représente uniquement des classes qui ont des occurrences.
Autrement dit, dans le cadre de la refonte du SI de notre fameux lycée Chateaubriand, « Lycée » ne pourrait pas être une classe étant donné qu’il n’y en a qu’un seul. En revanche, s’il fallait administrer tous les lycées d’un département ou d’une région, alors « Lycée » serait une classe car il y en a plusieurs.
Bien entendu,
Chaque classe s’associe à une autre.
Il ne peut pas y avoir de classe isolée. Sinon, posez-vous la question du périmètre du projet qui semble vouloir embarquer des données qui ne se rattachent à rien. Est-ce dans le bon projet ?
Attention, appliquer ces points ne veut pas dire que votre diagramme de classe sera parfaitement juste d’un point de vue fonctionnel. Cependant il le sera du point de vue du formalisme, et du fait qu’il soit plus lisible par tous, vous vous auto-améliorerez rapidement.
7) Multiplicités et attributs du diagramme de classe
Bon je dois vous avouer que l’on ne va pas finir à seulement 7 points clefs en abordant ces sujets. Cela nécessite clairement un autre article dédié en raison de certaines subtilités dans la maîtrise du diagramme de classe. Je vous invite donc à vous abonner pour vous tenir informer de la suite de ce travail de simplification, qui prend un certain temps. 🙂
Ce que je peux déjà vous écrire, c’est que j’aborderai les multiplicités UML vs Merise, les valeurs dans les attributs, etc.
Cet article vous à plus (ou pas) ? Vous avez des commentaires ? N’hésitez pas à vous exprimer sous cette publication, je réponds à tous les commentaires. Sinon, contactez-moi ici.
D’autres articles de blog liés aux cahiers des charges ici
