Exemples de diagrammes de classes UML

Le diagramme ci-dessus mérite d'être lu relation par relation. Book et DVD généralisent LibraryItem, ce qui se dessine par un triangle creux pointant vers le parent - et la raison de le dessiner ainsi plutôt qu'en deux classes sans lien aux attributs dupliqués est l'association en dessous. Loan pointe vers exactement un LibraryItem, et comme il pointe vers le parent abstrait, il peut prêter l'un ou l'autre sous-type sans savoir lequel.

C'est tout le test de l'héritage dans un modèle de domaine : non pas "ces deux choses se ressemblent-elles", mais y a-t-il quelque part dans le modèle quelque chose qui veut tenir l'une ou l'autre sans se soucier de laquelle. Si rien ne le fait, deux classes séparées sont la réponse la plus petite et la plus honnête.

Notez les multiplicités sur l'association Member-Loan : 1 à 0..*. Un membre sans emprunt est un membre ; un emprunt sans membre est un bug. Cette asymétrie est un fait réel du domaine et elle est inscrite sur le trait plutôt que laissée à un commentaire. L'article sur le diagramme de classes explique comment chacun de ces symboles se dessine.

Celui-ci ne contient aucun héritage, et c'est justement pourquoi il est montré à côté de la bibliothèque. Il a à la place une composition et une interface, et chacune est là pour une raison dont l'autre diagramme n'avait pas l'usage.

Le losange plein entre Basket et BasketLine est une affirmation : supprimez le panier et les lignes partent avec lui, parce qu'une ligne de panier n'a aucun sens toute seule. Comparez avec l'association simple de BasketLine vers Product, où le produit survit manifestement à la ligne - même forme de relation, deux durées de vie différentes, et la notation les distingue.

PricingRule est le point d'extension. Deux réalisations sont dessinées parce qu'une seule réalisation n'est pas une abstraction, c'est une classe avec une étape en plus - et dès qu'il y en a deux, ajouter une troisième promotion devient une nouvelle classe plutôt qu'une nouvelle branche dans une méthode existante.

Les deux diagrammes récompensent le même ordre de lecture, et ce n'est pas de gauche à droite. Commencez par les multiplicités, car ce sont les décisions : elles disent ce que le système autorise et sont le plus difficile à changer ensuite. Lisez ensuite les losanges, qui disent ce qui est supprimé avec quoi. Puis les triangles, qui disent ce qui peut tenir lieu de quoi. Les attributs en dernier, et seulement ceux dont vous doutez.

Un diagramme qui survit à cette lecture mérite d'être gardé. Un diagramme aux multiplicités vides n'est pas terminé, quel que soit le nombre d'attributs qu'il liste - et c'est de loin l'état dans lequel on trouve le plus souvent un diagramme de classes.

Ensuite : comment en dessiner un de zéro, et la référence des symboles pour vérifier une marque dont vous n'êtes pas sûr.