Diagrammes de classes UML

Une classe est un rectangle à trois compartiments au plus, empilés. Seul le premier est obligatoire.

• Nom. Le nom du type, centré et en gras. Si la classe est abstraite, le nom est en italique. Un mot-clé entre guillemets français au-dessus - «interface», «enumeration» - précise de quel type de classificateur il s'agit.
• Attributs. Un par ligne, écrits visibilité nom : Type [multiplicité] = valeur par défaut. Tout sauf le nom est facultatif.
• Opérations. Une par ligne, écrites visibilité nom(paramètres) : TypeDeRetour.

Le symbole de tête de chaque membre est sa visibilité : + public, - privé, # protégé et ~ paquet. Un membre souligné est statique : il appartient à la classe et non à une instance.

Presque tout le sens d'un diagramme de classes est dans les traits, et il n'y en a que six à retenir. L'extrémité qui porte la décoration est significative dans tous les cas.

Le nombre au bout d'un trait dit combien d'instances participent. Il se place à l'extrémité opposée à la classe qu'il contraint, ce qui déroute : en lisant Merchant 1 —— 0..* Payment, le 0..* à côté de Payment signifie qu'un marchand a zéro ou plusieurs paiements.

• 1 - exactement une. La valeur par défaut quand rien n'est écrit, même s'il est plus clair de l'écrire.
• 0..1 - facultative. C'est la notation d'une référence pouvant être vide.
• * ou 0..* - un nombre quelconque, y compris aucun.
• 1..* - au moins une. Une contrainte utile et souvent oubliée.
• 2..4 - un intervalle explicite.

La multiplicité est le gain de justesse le moins cher de toute la notation. « Est-ce que ça peut être vide ? » et « peut-il y en avoir plusieurs ? » sont les deux questions qui font remonter les vrais désaccords en revue de conception, et la réponse tient en trois caractères.

Ces trois-là sont la même forme de relation à trois intensités, et la différence porte sur le cycle de vie, pas sur l'intensité du lien ressenti entre les deux choses.

Une association simple n'affirme rien sur la propriété. Deux choses sont reliées. C'est tout, et c'est le bon choix par défaut.

L'agrégation - le losange creux - affirme une relation tout-partie où la partie est indépendante. Conseil honnête : l'agrégation ne porte presque aucune sémantique formelle en UML 2.5.1, et les lecteurs ne s'accordent pas sur ce qu'elle implique. Si vous hésitez entre association et agrégation, dessinez l'association.

La composition - le losange plein - est celle qui dit quelque chose de fort et de vérifiable. La partie appartient à exactement un tout et est détruite avec lui. Dans le modèle de paiement, un Refund n'existe que dans un Payment ; il n'y a pas de remboursement flottant. C'est une vraie contrainte, qui vaut la peine d'être consignée, et elle se traduit directement par une suppression en cascade ou une collection possédée dans le code.

Les diagrammes de classes les plus utiles sont petits en pratique. Sept à douze classes, des attributs sur celles dont on discute et omis partout ailleurs, et chaque trait portant une multiplicité. Un tel diagramme se lit en réunion et tranche des débats. Un diagramme de classes à cent boîtes est un artefact, pas une communication.

1. Des flèches à l'envers. Généralisation et réalisation pointent vers l'abstraction. Si votre triangle est sur la sous-classe, le diagramme dit le contraire de ce que vous vouliez.
2. La composition pour dire « fortement lié ». Le losange plein est une affirmation sur le cycle de vie. Ne l'utilisez que lorsque détruire le tout détruit vraiment la partie.
3. Aucune multiplicité. Un trait sans rien à ses extrémités a jeté l'information la plus précieuse que le diagramme pouvait porter.
4. Mélanger les altitudes. Classes métier et classes de framework sur la même page. Séparez ; chaque diagramme doit être lisible par un seul public.
5. Modéliser chaque accesseur. Les opérations ont leur place quand elles portent du sens. getName() n'en porte pas.

Pour confronter un modèle de classes à la réalité, dessinez un diagramme d'objets - un unique instantané concret d'instances. Les multiplicités qui paraissaient correctes dans l'abstrait s'effondrent en général dès qu'on essaie de les remplir avec de vraies valeurs.