Partie B-NOTATION DES ASSOCIATIONS

   B1- Lorsqu'un bout est nommé possède une multiplicité, le nom et la multiplicité représente un champ de la classe adjacente (Merise/Datarun), et non une champ de la classe opposée (IE/UML)

     L'endroit où placé la multiplicité est un peu contreversé, et plusieurs formalismes l'ont résolu de manières différentes.  Merise et Datarun (de Silverrun) ont résulu le problème en plaçant le client du côté adjacent et le fournisseur (supplier) du côté opposé.
 

Multiplicité sous Merise/Datarun

  Note: client et fournisseur sont des termes utilisé pat Together: @clientCardinality 0..n et @supplierCardinality 0..n sont des tags générés dans les javadoc comments.

   La multiplicité 1,1 est adjente à Employee, est représente un champ appartenant à Employee; ce champ, que nous pouvons appeller employer, a une multiplicité de 1,1, c'est-à-dire qu'un employé a un et un seul employeur.  La multiplicité 0,N représente un champ caché de Company, que nous pouvons appellé employees; les cardinalités 0 et N indiquent qu'une compagnie peut avoir plusieurs employés, un seul, ou aucun.

   Voyons maintenant la façon de faire d'Information Engineering :
 

  Enfin, voici la façon UML :
 

Remarquez que si l'on désire savoir pour combien de compagnie(s) un employé peut travailler, il faut partir de la boîte Employee, puis suivre le lien jusqu'à la boîte opposée; juste avant un trouve la multiplicité 1, ce qui veut dire qu'un employé ne peut travailler que pour une et une seule compagnie.  À l'inverse, une compagnie peut embaucher plusieurs employés, la multiplicité '*' indiquant 0 ou plusieurs en UML.  Dans un diagramme simple, il n'y a pas de problème suivre le lien jusqu'à la classe opposée pour connaître la multiplicité de l'association; mais dans un diagramme contenant des centaines de classes où les classes associées ne sont pas toujours contigues, cela peut ralentir la lecture du diagramme.  Cela contrevient au principe de la perception immédiate (principe 1).

On le voit, la façon UML de représenter les multiplicités est contre-intuitive. Ceci est tellement vrai que dans la première version de Rational Rose, les programmeurs avaient implantés les multiplicités à l'endroit (de la façon Merise/Datarun)!  Après s'être sans doute fait remettre ''à l'ordre'' par les trois amigos, la seconde version de Rose implantaient les multiplicités à l'envers (de la façon préconisée par les auteurs de UML).

La façon de représenter les multiplicités étant error-prone (nous verrons plus tard pourquoi), il serait bon dans une nouvelle approche de supporter les multiplicités ''à l'endroit'', au pire en concurrence avec la façon traditionnelle de UML.  Mais comment alors représenter les multiplicités?  L'étoile (*) étant utilisée pour représenter la cardinalité plusieurs dans les diagrammes, nous aurions pu choisi le N de Merise/Datarun pour représenter les multiplicité ''à l'endroit''.  Malheureusement, Rose a ré-introduit la cardinalité noté par N de Merise/Datarun en concurrence avec l'étoile, mais pour représenter une multiplicité ''à l'envers''.  Le symbole infini est utilisé dans les produits Microsoft (ex: Access) pour représenter également une multiplicité ''à l'envers''.  Pour éviter les confusions avec ces formalismes, il faut choisir un autre symbole.  Pourquoi pas les crochets "[ ]"?

En effet, les crochets sont utilisés dans les langages OO (Java, C++) pour représenter un tableau de N éléments. Les D'ailleurs les crochets sont utilisés dans UML pour représenter une cardinalité plusieurs dans le compartiment champ des classes: il ne s'agit donc pas d'un formalisme complètement étranger à UML.  Comme les rôles sont finalement des champs d'une classe, pourquoi ne pas utiliser le même formalisme.  Une relation un-vers-plusieurs serait donc représentée comme ceci:
 

Vous avez remarqué que dans le premier exemple, un employé est rattaché à une et une seule compagnie, alors qu'une compagnie peut compter plusieurs (possiblement aucun) employé(s). Dans le second, une unité de regroupement intermédiaire a été ajoutée : le département.  La multiplicité 1 d'employé et la multiplicité 0..plusieurs restent à la même position dans le diagramme, alors que la partie en jaune représente ce qui a été ajouté (la classe département et ses deux multiplicités):
 

On pourrait répondre que le même raisonnement s'applique avec le formalisme traditionnel de UML.
 

Selon ce raisonnement, les multiplicités d'employé et de compagnie restent aux même endroits, et ce qui est en jaune représente la partie ajoutée au diagramme:
 

Ce raisonnement décrit plus haut est pourtant inexacte.  En réalité, voilà comment les choses se passent : la multiplicité (*) appartient à compagnie, pas à employé; elle est simplement notée à l'opposé de la classe compagnie; ainsi, à l'ajout de la classe département, la multiplicité est déplacée à droite de département, comme l'indique la première flèche verte, de façon à rester à l'opposé de la classe compagnie.  Pareillement, la multiplicité 1 rattachée à employé est déplacée à gauche de département.  Les zones indiquées en jaune indiquent ce qui a été ajouté au diagramme.
 

Vous avez mal saisi le raisonnement?  C'est normal, puisque la façon de représenter les multiplicités dans UML est contre-intuitive.  Prenons un exemple plus simple.  Nous avons une classe étudiant, un class cours, et un lien plusieurs-vers-plusieurs entre les deux.  Ainsi, un étudiant peut suivre plusieurs cours, et un cours peut être suivi par plusieurs étudiants.  Nous souhaitons introduire une classe intermédiaire entre les deux: c'est la classe note; une note est attribuée à un seul étudiant pour un seul cours.  L'association peut être représentée comme ceci:
 

Nous voyons qu'avec la nouvelle approche, les multiplicité plusieurs d'étudiants et de cours restent à leur place, et la partie en jaune représente la classe ajoutés ainsi que ses multiplicités:
 

Voyons maintenant comment la même chose aurait été modélisé en UML:
 

Ici, aucune erreur possible.  On voit très bien que l'ajout de la nouvelle classe provoque le déplacement graphique des multiplicités associés aux deux premières classes.
 

   Un autre avantage des [], c'est qu'on élimine l'ambiguité amenée avec le '*'; une multiplicité '*', est-ce équivalent à '0..*' ou encore à '1..*' ? Dans les faits selon UML, c'est bien équivalent à '0..*', mais c'est pas clair pour tout le monde. Même dans la doc UML, on mélange les deux notations pourtant équivalentes, comme ce diagramme (Figure 2-30 Activity Graphs), tiré de la section 2.13 du OMG UML Specification, version 1.4, september 2001.  Faut dire qu'avec UML, on n'en est pas à une absurdité près...

B2- Pas de nom sur l'association, mais sur les bouts.
 
 

Voici un exemple tiré de (); un peut le lire comme suit : Une compagnie emploie plusieurs personnes.  Le sens commun nous indique que c'est la compagnie qui emploie les personnes, pas le contraire.  Le problème c'est qu'il n'y a rien dans le diagramme qui indique que la compagnie est l'entité qui emploie; bref l'information employs est une information sémantique (interprété par l'usager) et non syntaxique (non-ambigue).

On pourrait dire que puisque que Company est à gauche de employs, c'est lui le sujet et Employee le complément. Si le diagramme était fixé une fois pour toute, cela irait.  Mais c'est le propre des ateliers de génie logiciel de permettre à l'usager de manipuler graphiquement les boîtes représantant les classes.  Que ce passerait-il si on plaçait Company au-dessus de Employee (et non à gauche).  Ou comment interpréter un diagramme comme celui-ci:
 

    Bien sûr on peut dire : on sait bien que ce ne peut être un employé qui emploie la compagnie; cependant cet exemple n'est évident que parce que l'on connaît bien le domaine d'application.  Prenons un exemple moins trivial:
 

      Est-ce que l'acétone qui dissous le chlorure de calcium? ou le contraire?  Pour le savoir, il faut consulter un chimiste, ou se rappeller nos cours de chimie du secondaire: le diagramme ne nous apprend rien.  Or un diagramme qui suppose que le lecteur connaît bien le domaine d'application est un mauvais diagramme.

      Pour palier ce manque, UML a ajouté un petit élément graphique, le triangle noir plein apposé près du nom de l'association pointant dans la direction dans laquelle le nom de l'association s'applique.  Selon UML, la présence de cette petite flèche n'est pas obligatoire:  on l'affiche seulement pour clarifier une ambiguité.  Ainsi, le diagramme aurait l'aspect suivant:
 

Ce n'est pas la grande trouvaille du siècle.  D'une part, ce n'est pas très commode dans le cadre d'un outil d'atelier de génie logiciel (en fait, cet élément n'est implanté dans aucun outil de génie logiciel) : que se passerait-il si on renomme l'association employs par is employed ?  Il faudrait manuellement changer la direction de la flèche; je dis manuellement puisque le logiciel n'a aucun moyen de déterminer la sémantique du nom de l'association.

En cas de forward engineering, l'information serait perdu puisqu'aucun langage objet de supporte la nomenclature des association (à moins de conserver cette information dans des commentaires, comme le fait Rational Rose, ce qui est peut-être une solution encore pire : chaque fois qu'un programmeur ferait du copier/coller de code, ce qui arrive dans le monde réel, le nom de l'association et sa direction seront copiés;  et quant à ceux qui affirment qu'un programmeur de devrait pas faire de copier/coller de code, je ne sais pas sur quelle planète ils vivent, mais c'est sûrement une planète où on ne fait pas de logiciel..).

En cas de reverse engineering, comme l'information est absente des langages objets, elle doit être généré automatiquement, ce qui ne donne jamais de bons résultats : dans Rose, les noms des associations sont formés de la concaténation des noms de classes associées, ce qui nous donne Employee-Company, Acetone-Calcium Chloride, et ainsi de suite.

Ensuite, la flèche est un élément graphique surutilisé dans UML : elle sert déjà à marquer les spécialisations, les réalisations, les instantiations et certains rôles (ceux qui sont navigables quand les rôles opposés ne le sont pas).   Enfin, comment devrait-on interpréter un cas où deux associations se croisent (exemple suivant) ou un cas d'association à plusieurs segments (non illustrée).
 

Il serait sans doute plus pratique de nommer les rôles de chaque associations, plutôt que les associations elles-même.  Ainsi, même sans flèche, la lecture du diagramme n'est pas ambigue: une compagnie a plusieurs employés, et une personne a une seule employeur, du moins selon ce diagramme:
 

Vous noterez l'apparition des [], introduit au point précédent, qui pourrait être utilisé après le nom du rôle (par exemple de employees) pour indiquer la multiplicité.  Comme nous avons choisi au point 1 de mettre les [] près des classes auquelles elle s'appliquent, la multiplicité des rôles et leur nomenclature sont deux concepts qui se marient très bien, puisqu'à l'implémentation en code objet, la classe Company aura bel et bien un attribut nommé employees[].

Pour spécifier si une compagnie doit avoir aucun employé, ou doit en avoir au moins un, il suffit de le représenter par employees[0..n] ou employee[1..n] selon le cas.

Cette façon de faire facilite la lecture du diagramme, particulièrement d'un diagramme complexe.  Ainsi, si on demande quels sont les dix attributs de Class dans avec la nouvelle approche (diagramme de gauche), la lecture est instantanée: il s'agit des trois champs à l'intérieur de la classe (name, visibility et isAbstract) et des sept noms de rôles à proximité de la classe: fields[], methods[], constructors[], initBlocks[], subclasses[], superclass et superinterfaces[]. Ainsi un classe a un nom, une visibilité (public, package), peut être abstraite, peut avoir une superclasse et plusieurs superinterfaces, peut avoir plusieurs champs, méthodes et constructeurs, et ainsi de suite.  On aurait pu ajouter d'autres attributs comme la finalité.

Avec l'approche traditionnelle, les noms de rôles à proximité de la classe sont non-pertinents à une lecture immédiate, et il faut suivre les associations jusqu'au bout pour connaître les noms des cinq rôles, ce qui rend la lecture difficile, particulièrement si le diagramme est complexe.

Unicité des noms de rôles : En UML tout comme en Java, deux champs appartenant à la même classe ne peuvent avoir le même nom; de lorsque deux rôles rattachés à la même classe portent le même nom, nous avons un conflit. Dans l'exemple ci-haut, imaginons que le rôle fields[] soit renommé members[], et que le rôle methods[] soit également renommé members[].  En générant du Java, nous aurions deux méthodes appellés getMembers(), ce qui serait conflictuel.

UML dit :
2.5.3 Well-Formedness Rules
2.5.3.1 Association: [1] The AssociationEnds must have a unique name within the Association.

Cette contrainte est completement inutile, puisque deux classes peuvent tres bien avoir chacune un champ avec le meme nom, ceci n'est est rien conflictuel dans le modele objet (est-ce que les auteurs de UML comprennent bien le modele objet; si oui, où ont-ils peché cette contrainte???). A la rigueur, on aurait pu dire should au lieu de must. Par contre, UML pose aussi les contarintes suivantes:

2.5.3.8 Classifier
[3] No opposite AssociationEnds may have the same name within a Classifier.
[4] The name of an Attribute may not be the same as the name of an opposite AssociationEnd or a ModelElement contained in the Classifier.

Essayer de verifier une contrinte pareille avec un diagramme comme la figure 3.20!  Avec la nouvelle approche (3.19), cette contrainte est facilement détectable pusique tous les bouts d'associations et tous les champs devant etre uniques entre eux sont placés de maniere contigues dans le diagramme.

Avec un diagramme complexe basé sur l'approche UML (figure 3.20), nous aurions du mal à nous apercevoir du conflit de nom; avec la nouvelle approche (figure 3.19) le conflit de noms serait évident.

Une autre contrainte que donne les auteurs de UML se lit comme suit :

2.5.3.3 AssociationEnd
[1] The Classifier of an AssociationEnd cannot be an Interface or a DataType if the association is navigable away from that end.

Encore une fois, essayez de valider ce genre de contrainte avec l'approche traditionnel!  Avec l'approche nouvelle, l'erreur sautera aux yeux si on voit des bouts d'associations (donc des champs) adjacents a une interface.

En fait, la contrainte donnee par les auteurs est inexacte par rapport au modele objet.  Un bout d'association peut tres bien etre adjacent a une interface, il faut juste qu'il soit statique, et final (encore une fois, cela semble suggerer que les auteurs de UML ne maitrisent pas bien les concepts relies a l'orienté-objet).

   B3- Un bout nommé est navigable

  En UML traditionnel, chaque rôle d'association est réputé navigable, à moins d'indication contraire (mais dans les faits, la très grande majorité des associations implantés en Java ou C++ sont navigables que sur un seule côté).  Ainsi un trait d'association sans flèche signifier que chaque bout est navigable!  Or, dans une première version d'un diagramme de classe, les modeleurs laissent d'abord les traits sans flèches, puis décident dans une itération ultérieur de déterminer quels bouts seront navigables.

La note suivante tiré de UML est intéressante:

3.43.3 Presentation Options
Presentation option 3: Suppress arrows for associations with navigability in both directions, show arrows only for associations with one-way navigability. In this case, the two-way navigability cannot be distinguished from no-way navigation; however, the latter case is normally rare or nonexistent in practice. This is yet another example of a situation in which some information is suppressed from a view.

Les auteurs d'UML eux-meme admettent que la meme notation sert a noter une navigabilité a double sens et une association sans navigabilité! Pas fort.

Voici un diagramme UML tiré d'une soutenance de mémoire de maîtrise de génie logiciel à l'école Polytechnique de Montréal.  Il y a quelque chose d'illogique avec ce diagramme, la voyez-vous?

  Le bout d'association nommé outputs est correct.  On peut naviguer d'Activity vers Role, et outputs est un champ d'Activity. Par contre, le bout nommé inputs présente un problème. Pourquoi nommer un bout d'association alors qu'aucune référence vers Role ne sera conservée dans Activity, puisque Activity n'est pas navigable vers Role en utilisant l'association de gauche.  En outre, comment sera nommée la référence dans Role permettant de naviguer vers Activity?  La nommera-t-on activities (un nom par défaut déduit à partir du nom de la classe Activity), ou tout simplement inputs?  Si on la nomme activities, alors que faire si on a deux associations navigables de Role vers Activity?

  En fait, on le voit, inputs aurait dû être placé du coté non-navigable de l'association de gauche (c'est-à-dire adjacent à la flèche).  Et pourtant, ni l'étudiant soutenant sa thèse de matrise, ni aucun des quatre professeurs de génie logiciel composant le jury ne s'est rendu compte de l'erreur (signe du manque de sérieux de l'école Polytechnique en matière de génie logiciel).  UML viole donc encore une fois le principe 3 (principe de contrainte). Le probleme est que le nom d'un bout d'association et sa navigabilité sont des concepts se chevauchant.  Ceci viole egalement le principe : tout concept doit être representé que par une seule caractéristique graphique; seule la couleur peut servir à mettre en évidence un concept.

Comment corriger tous ces problemes?  Eliminons les fleches!  Dans un premier temps, le modeleur determinera ces classes, et ensuite les associations entre classes. A ce stade preliminaire, il n'y aura donc aucun nom ni aucune fleche sur les traits, rien que des traits seuls. On dira alors que la navigabilité est indéfinie (peut-etre a double sens, peut-etre a sens unique, ceci sera determiné dans une version ulterieure du modele).  Lorsque qu'on nomme un bout d'association, on spécifie en meme temps sa navigabilité. La figure suivante (3.21) montre trois associations, la premiere navigable de Person vers Company, la seconde a double-sens et la troisieme de Company vers Person.  A remarquer que lorsqu'on nomme un bout (par exemple employer), on specifie un champ de classe adjacente a ce bout (le champ employer appartient a la classe Person).
 
 

Avec UML traditionnel, rien n'empêche de fixer une navigabilité Company vers Person sur le diagramme du centre de la figure 3.21 (une compagnie connait ses employés, mais un employé ne connait pas son employeur). Dans ce cas, le rôle employer serait inutile, puisque jamais généré.  Ainsi les concepts de rôles et de navigabilité sont redondants, ce qui viole le principe 5 de complétude.  Les flèches de navigabilité doivent donc être retirées de UML.

   B4- Un bout nommé t2: genere un champ prive t2 dans T1, et des getter/setter dans T1

Les associations n-aires (n-ary associations)

UML permet de créer des associations impliquant trois classes ou plus; cette construction est rendue par un lozange.

Ce formalisme ne présente pas réelement d'intérêt : il complexifie la lecture d'un diagramme, et les associations binaires sont suffisantes pour représenter tout ce qui peut être représenté par des associations n-aires.  En fait, la plupart des modélisateurs préfèrent ne pas utiliser ce construit. Une association n-aire peut être remplacée par une classes d'intersection et trois associations binaire (figure 3.23). Le principe de complitude (règle 5) préconise le retrait de cette représentation graphique.

Les associations n-aires amenent plusieurs problemes; tout d'abord nom apparaissant au dessus du lozange n'est pas orienté : est-ce le professeur qui donne un enseignement, ou la classe qui donne un enseignement? Le bon sens nous dit que c'est le professeur qui donne l'enseignement parce que le domaine d'application est connu de tous, mais si nous aurions a modeliser une application de chimie organique, les associations n-aires pourrait être une source d'erreur d'interprétation. Ensuite, la navigabilité est limitée sur une association n-aire; problème résolu avec la gigure 3.23.  Enfin, au niveau de l'implémentation, si la conception n'est pas completement terminée lorsque le développement commence, alors on peut demander aux développeurs d'implanter les classes Teaching, Course et Class et poursuivre parallelement la conception de la classe Teacher.  Avec l'approche n-aire, le développement doit commencer que lorsque que la conception de l'association n-aire est terminée.

A noter que les multiplicités entre associations binaires sont interverties suite à l'insertion d'une classe d'intersection. Ceci est du au fait que les multiplicités sont indiquées à l'envers dans UML, une autre source d'erreur d'interprétation.  La figure 3.23 permet aussi de spécifier une multiplicité plusieurs-vers-plusieurs entre Teaching et Teacher (plusieurs professeurs peuvent être impliqués dans le même enseignement), un information qui ne pouvait être représentée avec une association n-aire.

La représentation de la figure 3.23 amène cependant un probleme : il y a conflit de nom sur deux rôles nommés taught.  En ramenant les rôles près de la classe qui contient ces rôles, ces conflits de noms sont plus facilement détectable. La figure 3.24 est donc la figure qui si lit le mieux (avec le moins d'erreur d'interprétation de la part des développeurs): Un professeur donne un ou plusieurs enseignements; une charge d'enseignement peut être donnée par plusieurs professeurs (ou même par aucun selon le modèle), une charge d'enseignement implique un et un seul cours et est donnée à une et une seule classe.  Que c'est limpide par rapport aux associations n-aires!

Les classes d'associations

Une classe d'association est une classe qui est rattachée à une association dans le but d'y associer un champ (ici la note); en effet le note n'est ni donné à l'étudiant, ni à une cours, mais bien à l'association étudiant-cours.

Tout comme les associations n-aires, une classe d'association peut être remplacée par une classe d'association; ce construit est donc non-essentiel et doit doit retiré de UML (principe 5 de complétude). Le diagramme résultant dans la figure 3.36 est plus informatif.  A noter, toujours a cause que les rôles sont représentés à l'envers dans UML, que la multiplicité * adjacente à Student dans 3.25 se retrouve maintenant adjacente à Examination et opposée à Cours dans 3.26; de meme la multiplicité1..*, adjacente à Course dans 3.25, se retrouve maintenant opposé à Student dans 3.26.

Représenté à l'aide de la nouvelle approche (NA), le diagramme de la figure 3.27 est le plus clair de tous.

Les qualificateurs (qualifiers)

UML permet de spécifier des qualificateurs de rôle dans le but de réduire la multiplicité d'une association. Les qualificateurs sont peu utilisés parce que peu de gens comprennent leur utilité.  Prenons l'exemple suivant : nous avons à modeliser deux stations de trains (la station de Montréal et la station de Québec).  La station de Montréal comporte dix quais d'embarquement, numerotés de 0 à 9.  La station de Québec en comprend cinq, numerotés 1, 3, 5, 7 et 9.

Une façon de réduire la multiplicité de * à 0..1, on peut retirer le champ no de Ramp pour en faire un qualificateur d'association, rattaché à Station (figure 3.29).  Attention en UML le rôle ramp est placé à l'envers (à l'opposé de Station), or le qualificatif sert à qualifier le rôle ramp (rôle placé à l'opposé du qualificateur) et non le rôle station, adjacent au qualificateur.  La représentation UML des qualificateur est error-prone.

On peut comprendre facilement l'utilité d'un qualificateur en examinant le code généré.  Dans le cas 3.28, nous aurions un getter retournant un tableu de Ramp:

class Station {
  Ramp[] getRamps();
}

Pour obtenir le quai 5 de Québec, il faut parcourir tableau retourné, et pour chaque élément du tableau, vérifier si son numéro de quai est égale à 5.  Une façon plus efficace d'obtenir le quai est de faire appel à un qualificatif pour obtenir le quai.  Ainsi, dans le cas de 3.29, nous aurions le code suivant:

class Station {
  Ramp getRamp(int n);
}

où n represente le numero du quai; ainsi getRamp(5) nous retournera le quai demandé, alors que getRamp(6) nous retournera une valeur nulle, puisqu'il n'y a pas de quai numéroté par un chiffre pair à Québec.  Internement, un qualificateur est souvent implanté avec un HashTable dans le code généré.

On pourrait représenter un qualificateur non pas par un champ dans une petite boite adjacente a la class, mais par un parametre placé sur un rôle, comme dans la figure 3.30.  Cette facon de faire serait plus facile de lecture pour un developpeur (principe 1 de perceptibilité).  De plus un qualificateur est non-significatif s'il y a une navigabilité Ramp vers Station. Cette inconsistance est facilement perceptible, puisque la fleche de la navigabilité et le qualificateur sont placées sur la même extremité de l'association, et devrait etre impossible a representer graphiquement (principe 3).

Avec la nouvelle approche (figure 3.30), puisque la navigabilité Station vers Ramp est indiquée par la présence du rôle ramp(int n), on se débarasse d'un concept inutile (fleche de navigalitité), ce qui est conforme au principe 5; et de plus il est impossible de représenter a la fois un qualificateur n sur le rôle ramp et une navigabilité Station vers Ramp, concept de tout facon impossible à implanter, ce qui est conforme au principe 5 (principe de complétude).

Conclusion : Inconvénients des formalismes traditionnels

Infomation Engineering (plus bas) :
  Inconvénient : le symbolisme (cercle, traits, pieds-de-poule) n'est pas intuitif pour un non-initié.

Merise (plus bas) :
  Inconvénient : La navigabilité n'est pas représentée.
  Avantage : Les cardinalités (0, 1, n) sont très intuitives; les associations (Employer, Employee) sont du bon côté.

OMT (plus bas) :
  Inconvénient : La navigabilité n'est pas représentée; les cardinalités (cercles pleins) sont très peu intuitives; les associations sont à l'envers, ce qui force l'utilisation d'une classe d'association (Work).

Figure 3.33

Nouvelle approche (plus bas) :
    Avantage : Les cardinalités (0, 1, n), toujours associées aux noms d'associations (posts, jobs) sont très intuitives et empêche toute erreur d'interprétation; les associations sont à l'endroit, ce qui enlève l'obligation d'utilisere une classe d'association (Work), celle-ci peut tout de même être noté par le stéréotype <<Association>> si cela rend plus clair le diagramme.

Figure 3.34