Symboles du diagramme de classes UML

La règle qui rend tout cela mémorisable : l'extrémité décorée est celle qui compte - le triangle pointe vers le classifieur le plus général, le losange se pose sur le tout qui possède, et la flèche ouverte pointe vers ce qui est utilisé. Si vous retenez quelle extrémité porte la marque, vous reconstituez généralement le sens.

La moitié des marques d'un diagramme de classes est sur les traits, l'autre sur les boîtes, et c'est la seconde que l'on saute. Un rectangle avec un nom est une classe ; tout ce qui suit change la nature que ce rectangle prétend avoir, et un lecteur qui ignore la différence lit une interface comme une classe et s'étonne qu'elle n'ait pas d'attributs.

Une interface a une seconde notation, plus petite, qui ne coûte aucune boîte : une sucette - un cercle sur une tige - dessinée sur le classifieur qui la fournit, et une douille correspondante, un demi-cercle ouvert, sur celui qui en a besoin. Emboîtez les deux et vous avez la boule-et-douille dont sont faits les diagrammes de composants. Elle dit exactement ce que dit le triangle pointillé, dans un dixième de la place, et c'est le bon choix dès qu'un diagramme porte plus de trois interfaces environ.

Une boîte de classe est un bandeau de nom avec jusqu'à deux compartiments dessous : les attributs, puis les opérations. Les deux sont facultatifs, et une boîte réduite à un nom est parfaitement légale - souvent la bonne chose sur un diagramme qui parle de relations.

La multiplicité s'écrit à l'extrémité d'une relation, et la syntaxe est courte : 1 exactement un, 0..1 facultatif, * ou 0..* un nombre quelconque y compris zéro, 1..* au moins un, et 2..5 un vrai intervalle. Une multiplicité absente signifie non spécifiée et non « un » : la laisser vide est un manque, pas une valeur par défaut.

Une opération s'écrit + place(customer: Customer, at: Instant): Order - visibilité, nom, paramètres avec leurs types, puis le type de retour après les deux-points. Deux décorations reviennent assez souvent pour être reconnues : un paramètre peut porter une direction, comme out receipt: Receipt, et un attribut une valeur par défaut, comme - status: Status = DRAFT. Ni l'une ni l'autre n'est obligatoire, et un modèle du domaine se porte généralement mieux sans.

Une relation porte du sens à ses deux extrémités, et presque tout ce qu'un diagramme de classes rate en relecture se joue à une extrémité et non au milieu. Le trait dit que deux classes sont reliées ; les extrémités disent qui peut atteindre qui, combien, dans quel ordre et sous quel nom.

Le dernier groupe de marques est celui qui porte les règles qu'un dessin de boîtes et de traits ne sait pas exprimer seul. Un diagramme de classes est une structure, et la moitié de ce que sait un expert métier est une condition sur cette structure - un total qui ne peut jamais être négatif, une paire de relations dont exactement une peut être remplie.

Une convention hors de ce tableau mérite d'être connue parce qu'elle ressemble à un diagramme de classes sans en être un : un nom souligné de la forme order1: Order est une instance, et un diagramme fait de ceux-là est un diagramme d'objets - la même notation montrant un instant plutôt que tous les instants possibles. Un soulignement à l'intérieur d'une boîte de classe veut dire tout autre chose : c'est le marqueur statique du tableau des compartiments ci-dessus.

Du texte entre guillemets français - «interface», «enumeration», «entity» - est un stéréotype : une extension du vocabulaire standard qui dit quelle sorte de chose est ce classifieur au-delà de « classe ». Une poignée sont définis par UML lui-même ; le reste vient d'un profil, le mécanisme pour inventer les vôtres sans quitter le langage.

Les guillemets font deux choses différentes, et la spécification les distingue même si rien sur la page ne le fait. «interface» et «enumeration» sont des mots-clés : partie d'UML, au sens fixé, légaux dans n'importe quel outil. «aggregate root» ou «pii» sont des stéréotypes : votre vocabulaire, défini dans un profil, porteur de sens uniquement pour un lecteur à qui on l'a expliqué. Les deux méritent d'être utilisés. Il vaut la peine de savoir lequel vous venez d'écrire, car le second a besoin d'une légende sur le diagramme et le premier non.

Un stéréotype peut aussi porter des valeurs étiquetées - {owner = payments-team, retention = 7y} sous une classe stéréotypée - et c'est ainsi qu'un modèle se met à contenir les métadonnées qu'un tableur contenait mal. C'est le mécanisme qu'un profil existe pour définir.

Pour voir tout cela sur de vrais modèles, lisez les exemples détaillés ; pour le raisonnement derrière les marques plutôt que les marques elles-mêmes, l' article sur le diagramme de classes.