Comme promis dans l’article précédent : Diagramme de classe 7 clefs pour être compris, voici l’article dédié aux multiplicités et autres conseils pour que le diagramme de classe puisse être compris par tous. Soit dit en passant, l’audience m’a surpris et montre que les sujets de fonds sont toujours d’actualité. N’hésitez donc pas à vous maintenir informé en vous inscrivant à la newsletter en bas et à droite de cet article. Inscription garantie 100% sans spam :-D. Obtenez au passage notre bonus gratuit pour bien commencer un cahier des charges.
Qu’est-ce que les multiplicités dans un diagramme de classe ?
Intéressons-nous aux multiplicités dans un diagramme de classe. Pour rappel, si vous êtes nouveaux sur le blog, il s’agit de transcrire combien de fois on peut itérer un concept métier vis à vis d’un autre.
Par exemple, sous Excel, chaque feuille de calcul contient plusieurs cellules. Un arbre peut avoir aucun ou plusieurs fruits… mais chaque fruit n’appartient qu’à un seul arbre.
Les multiplicités du diagramme de classe sont ce qui est souligné (aucun, plusieurs, un seul). Cela nous indique le nombre d’occurrences minimum et maximum d’un concept (fruit) vis à vis d’un autre (arbre).
L’embêtant, c’est que suivant les normes, on n’écrit pas les nombres de la même façon…
UML ou Merise, choisissez votre camp !
Rappel : Vous pouvez obtenir la norme UML ici (source : www.omg.org : The Object Management Group® (OMG®) is an international, open membership, not-for-profit technology standards consortium.)
L’idée n’est pas de proposer ici un cours sur Merise, UML et leur origine respective. Ce sont deux méthodologies extrêmement riches, la première française et la seconde internationale.
Les multiplicités en MERISE
Soit l’on est de l’école « Merise », soit l’on est de l’école « UML ». Les multiplicités du diagramme de classe doivent donc représenter ce choix. Par conséquent, si je fais du Merise, j’utiliserai :
- 0,1 ce qui signifie « aucun au minimum et au maximum 1 ». Par exemple, un élève peut être dans aucune (un élève peut s’inscrire dans un établissement et n’être, pendant un certain laps de temps, affecté à aucune classe) ou une seule classe.
- 1,1 ce qui signifie « 1 au minimum et au maximum 1 ». Par exemple, un produit appartient à une et une seule famille de produits.
- 0,n ce qui signifie « aucun au minimum et au maximum plusieurs », qu’il y ait ou non une restriction. Par exemple, un client peut passer aucune ou plusieurs commandes sur un site de e-commerce sans être limité en nombre alors que l’on pourrait dire qu’une classe comporte plusieurs élèves dans une limite de 30.
- 1,n ce qui signifie « 1 au minimum et au maximum plusieurs ». Par exemple, un client peut passer une à plusieurs commandes.
Bien choisir sa multiplicité minimum dans un diagramme de classe
Je me permets une petite digression pour tenter de clarifier le choix entre 0 ou 1 en multiplicité minimum. En effet, quelle différence entre un client passant aucune commande et un client devant en passer au moins une pour être justement considéré comme « client » ?
C’est tout simplement une question de définition du terme selon la vision métier ! Dans certains contextes, un client est celui qui s’inscrit sans rien acheter (pas de commandes, pas de souscription à un contrat, il est juste référencé) et dans d’autres, un client fait obligatoirement une action : passer une commande, souscrire un contrat, etc.
Cela ne s’invente donc pas, ça se questionne !
Les multiplicités en UML
Si je modélise en UML, j’utiliserai plutôt :
- 0..1 dont la signification est la même que 0,1
- 1..1 qui peut aussi s’écrire 1 et dont la signification est la même que 1,1
- 0..* qui peut aussi s’écrire * et dont la signification est la même que 0,n
- 1..* et dont la signification est la même que 1,n
Donc, pas de « 1,* », de « 1..n », etc. La modélisation des données est une langue dont il s’agit de respecter les codes, la syntaxe.
En résumé :
- en Merise 0,1 = 0..1 en UML = « 0 au minimum et 1 au maximum »
- 1,1 = 1..1 ou 1
- 0,n = 0..* ou * = « 0 au minimum et pas de maximum : une infinité »
- 1,n = 1..*
Le sens de lecture des multiplicités dans un diagramme de classe
On remarque très vite que c’est plutôt proche non ? Et bien en fait pas du tout…. Il y a une grosse subtilité qui change tout : on ne les interprète pas pareil sur le schéma car il faut les lire à l’envers si on change de norme.


Sur ce diagramme de classe UML, on peut lire que la Formation est proposée par plusieurs Organismes de Formation (OF) grâce à la notation * en Face de « OF ».
Et bien figurez-vous qu’en Merise, non seulement on ne met pas d’étoile (*), on mettrait donc « 0,n » mais, surtout, ce n’est pas en face de Formation mais à côté qu’il faudrait le noter car le sens de lecture est inversé. Je ne m’attarde pas sur cette base (nous pourrons y revenir dans un futur article), mais pensez-y sinon, il va y avoir des dégâts dans la réalisation ! De toute façon, décrivez textuellement chaque liaison dans votre cahier des charges, ajoutez-y un exemple et vous pourrez dormir tranquille. 😉
Quelques règles fondamentales sur les multiplicités
Je m’assure que j’ai bien des multiplicités sur chaque branche de l’association, sans quoi mon schéma est incomplet. Si elles n’y sont pas, ce sont autant de questions fonctionnelles à poser au métier.
Une classe association ne peut exister que s’il y a « * » (ou « n ») en multiplicité maximum de chaque côté de l’association.
Il ne peut que très rarement y avoir « 1 » en multiplicité maximum de chaque côté d’une association. Par exemple, dans le cadre d’une course de bateaux en solitaire, il ne pourrait pas y avoir les deux classes « Navigateur » et « Bateau » car cela signifierait « Navigateur 1..1 (pilote) 1..1 Bateau » : Un navigateur pilote un bateau et un bateau est piloté par un navigateur. Ce sont en fait un seul et même concept, il resterait à définir lequel fait sens pour les organisateurs de la course.
Exemple pertinent de relation avec 1 en multiplicité maximum de chaque côté d’une association entre deux classes


Dans le cadre de la RGPD (https://www.cnil.fr/fr/comprendre-le-rgpd) il pourrait être nécessaire de devoir supprimer les données personnelles d’un client. Mais si ce client a par exemple passé des commandes chez vous, vous avez aussi besoin de conserver cette information et de pouvoir faire le lien entre « Client » et « Commande« . Il serait donc envisageable de créer une classe « Personne » qui porterait les données personnelles et que l’on pourrait supprimer sans impacter la relation « Client – Commande. »
Attribut calculé et attribut occursé : c’est non 🙂
Le diagramme de classe ne contient pas d’attribut déduit ou calculé.
Qu’est-ce qu’un attribut déduit ?
Cela nécessiterait de plus amples explications mais retenons juste que si un attribut peut être déduit d’un ou plusieurs autres, il n’a pas à être représenté dans le diagramme de classe.
Pour illustrer cela, prenons la classe « Client ». Sur chaque fiche client, nous souhaitons voir apparaître son âge. Bien évidemment, les utilisateurs de ce fichier ne vont pas passer manuellement chaque année sur chaque fiche pour mettre l’âge à jour, cette information doit donc être déduite (ou calculée) à partir d’une donnée fixe comme la date de naissance.
Par conséquent, la classe « Client » aura pour attribut « Date de naissance » mais pas « Age » et ce même si la fiche présente bien l’âge.
Le diagramme ne contient pas d’attributs occursés.
Qu’est-ce qu’un attribut occursé ?
Terme barbare s’il en est, cela signifie juste qu’un attribut ne peut prendre qu’une seule valeur à la fois ou, dit différemment, qu’une classe ne peut pas contenir plusieurs fois le même attribut qui serait alimenté avec des valeurs différentes.
Cas pratique 1
Pour rendre les choses plus concrètes, postulons que vous soyez un élève qui passe des contrôles notés. Si, pour représenter cela, je mettais la note comme attribut de la classe « Elève », cela signifierait que je devrais soit écrire « notes », au pluriel donc et signifiant qu’un élève a plusieurs notes dans l’année, soit tenir un registre des notes obtenues (un élève a plusieurs notes puisque il réalise plusieurs contrôles)
Ce qui donnerait :
- Elève :
- Note 1 : 12/20
- Note 2 : 8/20
- Note 3 : 17/20
- Etc.
Dans les deux cas (pluriel ou liste), cela constituerait un attribut occursé, qui est une erreur de formalisme. Pour résoudre cela, il faudrait faire de la note une classe à part entière. Un élève a aucune ou plusieurs notes, chaque note ayant une valeur unique.
Cas pratique 2
Autre exemple, un livre qui ferait l’objet de multiples rééditions.
Ce serait faux de mettre plusieurs attributs « date de réédition » (une valeur de date pour chaque réédition) dans la classe « Livre ». Comment faire alors pour représenter cela ? Généralement, si vous êtes face à ce problème, cela signifie dans la plupart des cas que l’on a affaire à une classe et non pas à un attribut. Un livre peut faire l’objet d’aucune à plusieurs rééditions, caractérisées par une date.
Une valeur n’est pas un attribut
Une valeur n’est pas un attribut.
Pour illustrer cela, prenons la classe « Type de client ». Si vous collectez l’information comme quoi un client peut être de type « professionnel », « particulier » ou encore « association », sachez que ce n’est pas cela qu’il faut indiquer dans votre schéma mais bien l’attribut « Libellé du type » ou « Nom du type ».
Les valeurs possibles de cet attribut sont à indiquer dans la description littéraire du schéma.
Autres points à garder en tête
Enfin, pour terminer cet article, quelques conseils supplémentaires :
Dans un premier temps, je vous conseille d’éviter d’utiliser les compositions et les agrégations. Non pas parce que ce n’est pas utile mais tout simplement parce que, dans un premier temps, il n’est pas nécessaire d’ajouter de la complexité.
Mieux vaut d’abord acquérir des bases solides avant de s’attaquer aux subtilités.
De plus, la description littéraire du schéma exprimera naturellement ces deux éléments et ce qu’ils représentent.
Enfin, si votre schéma contient des héritages, la flèche doit toujours être dirigée vers le haut et sa pointe est vide, creuse, pas pleine.
Le mot de la fin
Je vous remercie pour votre attention, en espérant que cet article vous a plu et surtout qu’il vous sera utile.
Vous êtes libres de télécharger gratuitement notre Guide bonus pour bien démarrer un cahier des charges en dessous de cet article. Si vous avez des questions ou que vous souhaitez que certains des thèmes abordés ici soient développés, n’hésitez pas à me faire part de vos demandes en commentaires !
A bientôt.