Discussion :

[GrandFather]

Bonjour,

je m'initie actuellement à UML 2, et je voudrais grâce vos lumières m'assurer que je saisis bien ce que je lis.

On dispose, dans un diagramme de classes, de deux manières pour faire apparaître les attributs : en ligne ou par relation. Dans le deuxième cas, peut-on assimiler cette relation à une composition ou une aggrégation ? Si la sémantique est la même, dans quel cas doit-on utiliser l'une ou l'autre ?

A ce point de ma réflexion, je suppose que, pour une classe donnée, durant la phase d'analyse on privilégie les relations d'aggrégation/composition, plus lisibles, et que durant la phase de conception, on utilise plutôt les attributs par relation, du fait qu'ils apportent plus de détail sur l'implémentation de la classe. Suis-je dans le vrai, ou complètement à l'ouest ?

[bruno_pages]

Bonjour,

je ne sais pas si tu voulais dire 'relation' ou 'en ligne' pour la phase de conception (tu as dis deux fois 'relation' mais la tournure de la phrase semble insiter à l'autre choix ), mais cela n'est pas très important.

Pour moi les diagrammes sont les mêmes dans les deux phases, le fait d'avoir une composition ou une aggrégation est important dans les deux phases. De plus, suivant comment on travaille et/ou les cas, les classes créées lors de la phases d'analyse peuvent toujours être présentes (au sens 'pointeur', ie pas 'recopiées') en phase de conception, et dans ce cas une relation ne devient pas un attribut 'en ligne'.

Un modeleur qui tient la route doit permettre de générer le code désiré pour les relations et les attributs 'en ligne'. Bref ta discrimination sur le fait qu'ils apportent plus de détail sur l'implémentation de la classe ne devrait pas exister, mais peut être que le modeleur que tu utilises à de telles limitations ?

Lorsque la valeur d'un attribut n'est pas une classe mais un entier par exemple, tu n'as pas le choix et tu dois utiliser des attributs 'en ligne' et non des relations. Dans les autres cas je prefère les relations car elles sont plus visibles dans les diagrammes, c'est pour cela que le reverse de http://bouml.fr les privilégie par rapport aux attributs 'en ligne'.

[Soutou]

UML 2 distingue 3 types de relation entre 2 classes (sans parler d'héritage).
agrégation - composition - simple (ni agreg ni compo).
Les attributs peuvent se trouver soit dans une classe soit dans une classe association (suivant leur dépendance avec la ou les classes).
Exemple : Classes Etudiant et Matière, attribut moyenne.
Si tu veux stocker la moyenne générale de l'étudiant : dans la classe Etudiant,
si c'est la moyenne de la matière : dans la classe Matiere, si c'est la moyenne de l'étudiant pour une matière donnée : dans la classe-asso qui relie Etudiant à Matiere.

[Nip]

Je ne suis pas sur de bien comprendre ce que tu entends par attribut en ligne ou par relation. Si j'en crois la reponse de Christian Soutou, tu parles d'attributs de classe (en ligne) et d'attributs de classe d'association (par relation) et dans ce cas l'explication que donne Christian devrait etre claire.

Ensuite comme l'a indique Bruno, il n'y a pas a retoucher ton diagramme de quelque maniere que ce soit en passant a la conception, puisque normalement le modeleur se charge de tout traduire dans ton langage prefere. De plus une classe d'association et une classe composite ou agregee n'ont pas la meme semantique, ce n'est donc pas la bonne facon de proceder.

Une precision supplementaire: effectivement UML distingue 3 types de relation. Cependant tous les types ne sont pas representables avec par les langages objet actuels, ainsi agregation et relation (simple) sont implementees de la meme maniere.

[GrandFather]

Merci pour vos explications, qui clarifient par la même occasion d'autres aspects qui étaient restés un peu nébuleux pour moi.

Je n'ai peut-être pas été assez explicite par ce que j'entendais par attribut en ligne et attribut par relation ; en fait, j'ai repris mot pour mot la terminologie employée dans "UML 2 en concentré" de chez O'Reilly, qui est mon ouvrage de référence actuel. Dans cet ouvrage, un attribut en ligne est un attribut figurant dans le compartiment ad hoc de la classe. Un attribut par relation est lui symbolisé par une relation d'association, et n'a pas de rapport avec une classe d'association. Ainsi, pour dire qu'une Automobile a un attribut moteur de type Moteur, on modélisera comme ceci :


En fait, mon interrogation première portait sur la subtile différence sémantique entre cette représentation et celle d'une aggrégation ; j'imagine qu'elle porte sur le cycle de vie de l'objet instance de Moteur ?

[bruno_pages]

j'imagine qu'elle porte sur le cycle de vie de l'objet instance de Moteur ?

Absolument, cela permet d'indiquer si la vie de l'objet pointe est liée a la vie du contenant.

Comme le dit Nip, cette distinction est ou non visible au niveau code en fonction des langages :

• en Java on ne voit rien car on ne manipule que des pointeurs,
• en C++ si tu as T * x; tu ne sais pas, mais on le sait avec T x;

En tout cas, meme si le langage utilise le meme code pour des cas differents, il est fort conseille d'utiliser quand meme les representations UML differentiant les differents cas.

[Soutou]

L'aggrégation a été un des concepts les + discutés de UML. C'est assez subjectif malgré tout et il peut exister pas mal de couplages différents entre 2 classes en association. Dans ton diagramme, l'attribut de relation devrait selon moi ne pas apparaître dans le lien mais devra être déduit automatiquement du lien en question.
Concernant ton bouquin, préfère des ouvrages français qui traduisent souvent mieux la sémantique que les ricains le font.
La flèche indique que tu peux naviguer (connaître) d'une voiture à son moteur mais pas l'inverse.

[GrandFather]

Dans ton diagramme, l'attribut de relation devrait selon moi ne pas apparaître dans le lien mais devra être déduit automatiquement du lien en question.

Dans ce cas, est-ce qu'on pourrait utiliser cette représentation implicite (lien sans attribut) lors de l'analyse, et ne faire apparaître l'attribut dans le lien que dans le diagramme produit lors de la phase de conception, au moment où on se préoccupe des détails d'implémentation ? La démarche est-elle bonne ?

En tout cas, meme si le langage utilise le meme code pour des cas differents, il est fort conseille d'utiliser quand meme les representations UML differentiant les differents cas.

A condition de pouvoir les différencier sans ambiguïté, et c'est là où je patauge un peu...

[bruno_pages]

Dans ton diagramme, l'attribut de relation devrait selon moi ne pas apparaître dans le lien mais devra être déduit automatiquement du lien en question.

j'ai rien compris, tu peux reformuler ta phrase stp ?

Dans ce cas, est-ce qu'on pourrait utiliser cette représentation implicite (lien sans attribut) lors de l'analyse, et ne faire apparaître l'attribut dans le lien que dans le diagramme produit lors de la phase de conception, au moment où on se préoccupe des détails d'implémentation ?

Concernant la phase d'analyse la première question serait déjà de savoir si tu dois montrer la relation, à priori il est préférable de d'abord penser à l'interface que présentent tes classes, les relations/attributs c'est déjà de la conception ... sauf bien-sûr si le problème à résoudre est du type BD (au sens data). Ceci dit tout dépend de ta facon de penser, le tout est que tu arrives a tes fins, il n'y a pas une bonne méthode absolue, juste des recommandations.

Mais pour répondre plus précisément à ta question, par définition l'analyse ne donne pas de résultats précis, ce que fera la conception (là on n'a pas le choix ). Tu peux egalement utiliser d'autres types de relations, par exemple il y a de forte chance que tu es une dependance entre ta voiture et un moteur, et donc en premier lieu tu peux avoir Voiture - - -> Moteur, qui plus tard deviendra peut etre Voiture ----> Moteur ... ou peut etr pas, suivant l'implementation.

A condition de pouvoir les différencier sans ambiguïté, et c'est là où je patauge un peu...

Si B n'existe que tant que A existe alors tu as A <>-----> B ou A <*>------> B (la difference entre une aggreg par ref ou par valeur est tres implementatoire et n'a pas d'importance en face d'analyse)

P.S. j'espère que ne ne depasse pas les limites de mon savoir

[Bba_M]

• en Java on ne voit rien car on ne manipule que des pointeurs,

vous étes sur. à mon avis java ne permet pas de manipuler les pointeurs.

[bruno_pages]

vous étes sur. à mon avis java ne permet pas de manipuler les pointeurs.

Oui je suis sure, mis a part les types de base type entier (sauf lorsqu'il y a objectification) il n'y a pas de passage de parametre par valeur, toujours par reference. C'est assez deroutant lorsqu'on a des habitudes C++ ou par defaut (ie sans modifier) le passage des parametres ce fait par valeur.

Donc tu ne le vois pas (ie pas de '*'), mais tu ne manipule que des pointeurs (reference si tu preferes, c'est la meme chose : une adresse)

La raison est tres simple : passer des objets par valeur voudrait dire les recopier avec allocation dans le tas puis garbage, ce qui serait tres chere a l'execution. Ce probleme n'existe pas en C++ ou la copie des objets se fait en pile (en tout cas leur enveloppe) ou l'allocation/desallocation se fait a cout nul.

[Soutou]

Dans ce cas, est-ce qu'on pourrait utiliser cette représentation implicite (lien sans attribut) lors de l'analyse, et ne faire apparaître l'attribut dans le lien que dans le diagramme produit lors de la phase de conception, au moment où on se préoccupe des détails d'implémentation ? La démarche est-elle bonne ?

Je voulais dire qu'il est redondant de lier deux classes et d'ajouter en plus un attribut de liaison.

En gardant Automobile (c'est un peu bizarre d'avoir une classe vide) et Moteur avec ces 3 attributs, quand tu vas générer un modèle Java ou autre (je sais pas ce que tu vas utiliser comme modèle cible), l'outil que tu vas utiliser va ajouter automatiquement des éléments (généralement référence ou collection) qui vont permettre de relier les classes entre elles.

[Nip]

D'ailleurs, l'exemple du livre que tu donnes, GrandFather, est la parfaite illustration de l'attribut par relation totalement inutile: un attribut moteur pour lier une classe ...moteur, ca surcharge inutilement le diagramme UML.
Mais bon je suppose que c'est pour l'exemple .

[bruno_pages]

Ah d'accord, maintenant je comprends ce que tu voulais dire Soutou, mais je ne crois pas que GrandFather voulait mettre la relation et l'attribut ... enfin j'espère

c'est un peu bizarre d'avoir une classe vide

mais non, la classe n'est pas vide : il y a justement la relation/attribut vers moteur dont on parle

[GrandFather]

D'ailleurs, l'exemple du livre que tu donnes, GrandFather, est la parfaite illustration de l'attribut par relation totalement inutile: un attribut moteur pour lier une classe ...moteur, ca surcharge inutilement le diagramme UML.

Ca a l'avantage pour moi de spécifier le nom de l'attribut tout en visualisant l'association entre la classe Moteur et la classe Automobile. En fait, et j'aurais dû le préciser plus tôt, je n'utilise pas d'AGL ; je dois donc, pour que les diagrammes obtenus lors de la conception soient au maximum en phase avec le code, rendre explicite ce que les AGL font implicitement lors de la génération du code (la création de l'attribut et son typage). C'est dans ce contexte que j'envisage leur utilisation.