Comment dessiner un diagramme de classes UML

L'étape un consiste à écrire comment le domaine se raconte à voix haute et à souligner les noms."Un patient prend rendez-vous avec un médecin, et le médecin peut délivrer une ordonnance" donne quatre candidats immédiatement. Gardez ceux qui ont trois propriétés : une identité (deux d'entre eux se distinguent), un état qui change dans le temps, et une durée de vie propre. Un nom qui échoue aux trois - une couleur, un montant, un statut - est un attribut de quelque chose d'autre.

L'étape deux, c'est un trait par phrase que vous pouvez dire sur le domaine. Pas par jointure de base ni par appel de méthode : un trait signifie que les deux classes se connaissent au sens métier. Le diagramme ci-dessus est là que cela s'arrête, et il vaut déjà la peine d'être posé devant quelqu'un qui connaît le domaine, parce que la discussion que vous voulez porte sur l'appartenance d'une ordonnance à un rendez-vous ou à un patient - et cette discussion est disponible maintenant, avant qu'un seul attribut ait été tapé.

Chaque trait reçoit un nombre à chaque extrémité avant qu'un seul attribut soit ajouté. C'est l'étape que l'on saute et celle qui paie, parce qu'une multiplicité est une décision sur ce que le système autorise et qu'un attribut est un détail qui en découle.

Lisez chaque extrémité comme une phrase et dites-la à voix haute. "Un patient a zéro ou plusieurs rendez-vous" : très bien. "Un rendez-vous a exactement un patient" : très bien, et à vérifier, car un cabinet qui prend un jour un créneau familial vient de vous dire le contraire. Les trois questions à poser à chaque extrémité sont : cela peut-il valoir zéro, cela peut-il valoir plus d'un, et cela change-t-il un mauvais jour ?

Choisissez ensuite la sorte de relation, et seules deux décisions méritent qu'on s'y attarde. La partie est-elle supprimée avec le tout : si oui, composition. Quelque chose détient-il le type parent sans se soucier du sous-type : si oui, généralisation. Tout le reste est une association simple, et les exemples traités montrent les deux jugements à l'oeuvre.

Les attributs viennent en quatrième, et chacun doit avoir une source. Si vous ne pouvez pas dire d'où vient une valeur - un formulaire, un autre système, un calcul -, c'est une supposition, et les suppositions sont ce qui fait qu'un modèle cesse de correspondre à ce qu'il décrit. Écrire les types en vaut la peine : startsAt: Instant tranche une question que startsAt: Date laisse ouverte.

Les opérations viennent en cinquième, et la plupart des classes n'en reçoivent aucune. Une opération appartient à une classe quand le comportement a réellement besoin de l'état propre de cette classe : cancel() a besoin du statut du rendez-vous, donc il y a sa place. Tout ce qui a besoin de trois autres objets pour faire son travail est un service, et le mettre ici est la façon dont un modèle de domaine devient discrètement un diagramme du code plutôt qu'un diagramme du domaine.

Puis arrêtez-vous. Le diagramme fini ci-dessus a quatre classes et répond à une question ; ajouter Clinic, Room, Invoice et Insurer le rendrait plus complet et moins utile. Si une seconde question doit être traitée, dessinez une seconde vue sur le même modèle : c'est à cela que servent les vues.