MODULE No 14

Titre : Noms des extrémités d’association et classes d’association

But : Approfondir les associations de UML et « toucher » avec ses idées les choix multiples dans la modélisation.

Antécédents : Module 9

Corps :

1. Introduction

Rappelons qu’une association « est une relation entre deux ou plusieurs classes qui décrit les connections entre leurs instances. (…) Chaque instance d’une association qui s’appelle lien (link en anglais) est une liste ordonnée de références à des objets. (…) Une association a un nom optionnel. ».

 

 

Une association a un nom optionnel. Dans la figure précédent le nom pourrait être « Prête » mais, dans ce cas, il n’ajoute pratiquement pas d’information. Le lecteur qui voit Prêteur associé à Disque dans un contexte comme celui d’un système pour gérer des prêts de disques  n’a pas de doutes que l’association est Prête (ou Emprunte si on la lit dans l’autre sens). En UML lorsque l’association n’a pas une flèche qui indique une direction, la direction est celle qui est normale en Occident : de gauche à droite.

2 Nom d’extrémité d’association.

Les extrémités d’une association aussi peuvent avoir un nom. Ce nom « permet d’identifier le bout d’une association et de naviguer d’un objet à l’autre via l’association. » Dans la version 1 de UML ce nom était appelé nom du rôle et dans la version 2 est appelé nom d’extrémité d’association. Nous emploierons les deux car nom du rôle est désormais entré dans les habitudes de ceux qui travaillent avec UML.

Le nom d’extrémité d’association est optionnel (comme le nom de l’association) mais lorsqu’une association met en relation une classe avec elle-même elle devient obligatoire : dans ce cas-ci, c’est la manière d’identifier l’association car « normalement » l’association est identifiée par les noms des classes à ses bouts. Lorsqu’il y a plusieurs associations sans nom entre deux classes, les noms d’extrémité d’association sont nécessaires

Ci-dessous un diagramme qui transcrit en UML le paragraphe suivant : « Une Personne ayant le rôle de professeur Travaille pour une Université qui est son employeur. Une université emploie 1 ou plusieurs Professeurs. L’État joue le rôle de pourvoyeur et Finance les universités qui sont ses clients. »

Comme on peut le noter les noms d’extrémité d’association rendent le diagramme plus facilement lisible : on voit le rôle qu’un objet joue dans le lien avec les objets à l’autre bout de ses liens.

La figure suivante tiré du manuel de UML montre comment les objets naviguent le long des associations à l’aide des noms d’extrémité d’association.

Si bb est un objet de la classe B alors bb.theA est un ensemble d’objet de A à cause de la multiplicité de A (1 ou plusieurs) : bb via l’unique association entre B et A (identifiée par +theA et +theB) peut « voir » plusieurs objets de classe A.

Le signe « + » indique que l’élément est publique et « the » est le préfixe par défaut du nom de l’extrémité d’association

Le même objet bb, via l’association entre la classe B et la classe C, voit un seul objet de type C à cause de la multiplicité qui vaut 1.

bb voit aussi un seul objet de type E car B est un D et l’association entre D et E a une multiplicité de 1 côté E.

Par contre, un objet dd de classe D ne peut pas « voir » un objet de type C. Un objet d’une classe dérivée peut « voir » ce que « voient » les objets de la classe de laquelle sa classe dérive mais l’inverse n’est pas vrai. Exemple : si tous les petits des éléphants boivent du lait (comme tous les mammifères) ce n’est pas vrai que tous les mammifères portent des branches avec leur trompe !

Continuons avec l’exemple des profs et des universités et considérons la phrase suivante : « Les professeurs qui travaillent pour une université ont un bon salaire. »

Combien de concepts y a-t-il dans la phrase ? Si on suit la règle « un nom commun = un concept », alors on a trois concepts : Professeur, Université et Salaire.

Combien d’associations ? En prenant la règle « un verbe = une association », on obtient deux associations : Travaille pour et Ont.

Mais un étudiant qui se croit malin pourrait penser qu’il ne vaut pas la peine de considérer le salaire comme une classe et de le considérer un simple attribut. Et, puisqu’il se croit malin il considère que, même si dans la phrase proposée il n’y a pas de concept d’adresse il vaut la peine de l’introduire (il a vu les adresses dans tellement de cours !).

Voilà ce que propose notre étudiant malin :

Dans le diagramme il a aussi voulu nous montrer qu’il sait ce qu’est un rôle et il a considéré la classe Personne au lieu de Professeur et il a considéré le Professeur comme rôle de Personne. Est-ce correct ? Oui. Est-ce qu’il aurait été correct de dire que Professeur est dérivé de Personne au lieu de dire que c’est un rôle ? Bien sûr ! Laquelle des deux solutions est préférable ? Ça dépend.

Ça dépend de quoi ? Des objectifs du produit que vous devez réaliser et du contexte dans lequel il est inséré. Si les professeurs ne sont pas les seules personnes qui gagnent un salaire dans une université et s’ils ont un comportement et des attributs différents des autres personnes alors il est sans doute préférable de dériver.

Mais retournons à nos moutons (les professeurs ?). Considérons l’association Travaille pour qui met en relation Personne et Université. L’association a un nom (Travaille pour) et deux noms d’extrémité (Professeur et employeur). Est-ce que le nom optionnel de l’association est superflu ? Dans ce diagramme non : il aurait été superflu si le rôle de Personne avait été Employé, dans ce cas Travaille pour découle pratiquement automatiquement des deux rôles (Employé et employeur). Mais le fait que le rôle est Professeur, Travaille pour n’est pas complètement inutile : c’est-à-dire qu’il augmente la clarté de la description UML.

Note. Lors de l’analyse la clarté et la facilité de lecture des diagrammes sont très importantes. Les diagrammes, au début du cycle de vie, sont dessinés surtout pour faire communiquer les humains. Fin de la note.

On pourrait soulever une autre critique à cette association : les professeurs ne sont pas les seules personnes qui travaillent pour l’université. Il est vrai mais on peut supposer que notre application ne concerne que les professeurs. Il est clair que, si tel est le cas, il faudrait se demander dans quel but Personne a été introduit (La réponse « pour expliquer les noms d’extrémités d’association » tout étant vraie n’est pas la bonne si on se met dans la situation que le cours essaye de décrire). Personne peut avoir été introduite parce que l’on veut réutiliser des concepts que l’on connaît bien (par exemple on a déjà l’association entre personne et adresse). Dans ce cas là on pourrait bien sûr dire que Employé est une Personne et que Professeur est un Employé et qu’un Employé Travaille pour une Entreprise et que l’Université est une Entreprise… Cela serait plus général.

Note Toutes ces considérations ont été faites pour vous montrer qu’il est difficile, sinon impossible, de comparer deux descriptions (Modèles) si on ne connaît pas le contexte et les objectifs du produit. Fin de la note.

3 Classe d’association et réification

Et le Salaire ? Nous avons oublié le Salaire ! Il est plus facile d’oublier le salaire dans un modèle que dans le monde réel ! Le Salaire est devenu un attribut de Personne. Est-ce correct ? Encore une fois, ça dépend. Salaire peut être un attribut si la seule chose qui importe est, par exemple, de connaître la Richesse d’une Personne et que Richesse = Salaire. Mais dans un cas comme le nôtre, même si on ne connaît pas bien le contexte, puisque on met en relation un employé (« habillé » en professeur) avec son employeur il est préférable de considérer le Salaire comme un concept et le mettre… le mettre où ? Le mettre… l’« accrocher » à l’association entre Université et Personne car le Salaire est le résultat de l’association. Même si tous les quinze jours il va dans les poches du Professeur (ou dans son compte bancaire) il est « partagé » avec l’université, il caractérise leur relation (on espère que cette relation ne soit pas la seule !). En UML on relie avec une ligne pointillée la classe à l’association :

 

Salaire est donc une classe qui caractérise une certaine relation entre l’Université et la Personne (professeur).

On peut donner une représentation équivalente à la précédente en faisant ce que l’on appelle une réification de l’association : c’est-à-dire en rendant l’association une classe qui est « mise à la place de l’association ». Dans notre cas Salaire devient une classe à laquelle sont reliées Personne et Université :

 

Laquelle des deux représentation est la plus claire : sans doute la première (le dessin est plus simple)

Mais il y a quelques paragraphes nous avions écrit : « Les professeurs qui travaillent pour une université ont un bon salaire. » Et « Bon » ? Nous l’avons fait disparaître, et nous n’avons pas le droit de le faire. Étant donné que Bon est très flou (parmi vous il y a, sans doute, autant de « bons salaires » que de têtes) il faut le préciser.

Note La réalisation d’un produit n’est, au fond, que le passage du flou au précis, de l’ambigu au toujours moins ambigu. Un adjectif comme « Bon » ne peut apparaître qu’au tout début d’un projet. Même dans un ConOps il est préférable de ne pas l’employer. Fin de la note

Faisons l’hypothèse que « Bon » indique un salaire supérieur à 1 000 $ par semaine. Il faut maintenant se demander d’où vient ce 1 000. Mais avant de se demander cela il faudrait se demander d’où vient la valeur du salaire (le salaire vient de l’université, cela on le sait). La valeur est établie par une convention collective entre l’université et le Syndicat des professeurs. Donc on pourrait modifier le diagramme comme suit :

Salaire et Convention sont deux classes d’association ayant une relation (sans noms dans notre diagramme) entre elles.

Donc la convention établit la valeur du salaire. (Notre diagramme est un peu trop simple car la Convention établit le salaire en fonction de certaines caractéristiques du professeur). Mais nous avons toujours une question ouverte : qui et comment a établi que Bon = 1000 ? Il s’agit d’un problème sociologique, politique et psychologique qui dépasse notre pauvre modélisation et qui est dans le monde réel ou si vous préférez le monde concret de l’économie (un sociologue pourrait sans doute être tenté de modéliser tout cela !)

Conséquents :

  • Avoir une bonne idée des rôles, des multiplicités et des classes d’association.
  • Ne pas douter sur la difficulté de juger de la qualité d’un modèle

Note 01 :