Discussion :

[marlene2110]

Bonjour,
je débute tout juste en UML, quelqu'un pourrait-il m'expliquer la différence entre composition et agrégation??
j'ai beau lire des définitions ds les bouquins et sur le net, ce n'est toujours pas clair. Si j'ai bien compris dans l'agregation il y a une idée de partie(de possession) comme dans l'exemple du moteur ds une voiture mais pour moi on pourrait dire aussi qu'une voiture est composée entre autre d'un moteur. Donc en fait je n'arrive pas à déterminer quand est ce qu'on dit que c'est une relation d'agregation ou de composition.

merci d'essayer de m'éclairer

[wiztricks]

Salut,
La différence entre agrégation et composition est subjective car elle dépend des choix fait dans la modélisation des entités/objets du domaine.

Prenez moteur et voiture.
Pour se déplacer, une voiture sans moteur ne permettra pas d'aller bien loin. De ce point de vue, il y a une association forte entre moteur et voiture qui peut se traduire par une "composition". Et qui fait que sans moteur, la chose ne mérite pas d'être "voiture", mais juste une épave.

Ceci dit, le mécanicien peut considérer le moteur comme un composant remplaçable d'une voiture... De son point de vue, la relation est "agrégat" et il peut fabriquer une voiture à partir de deux épaves.

Dans tous les cas, l'agrégation est une relation asymétrique qui peut se traduire comme relation entre un tout et (une de) ses parties.
Si le modèle doit traduire la vie de cette relation (faire et défaire), ce sera probablement 'agrégation' car contenant et contenu pourront être dissociés et avoir des cycles de vie différents.
Si le modèle ne doit pas descendre à ce niveau de détail, on pourra se contenter d'une composition. Et dans ce cas, les "composites" sont crées et détruits en même temps que le tout.
- W

[wafiwafi]

Bonsoir,
On peut donc dire qu'une composition est un cas particulier d'une agrégation.

On peut également prétendre que si un objet A est une partie d'un objet B alors :
Ou l'objet B ne peut communiquer avec le reste des objets sans l'objet A; dans cas c'est une relation de composition.
Ou l'objet B peut communiquer avec ou sans la présence de l'objet A (valeur Null par exemple), dans ce cas c'est une agrégation.

Merci

[wafiwafi]

Voila enfin la définition que je donnerais à la relation de composition.

Relation de composition :

Il s’agit d’un cas particulier de la relation d’agrégation. On applique donc la relation «*est une partie de» mais en se posant la question sur la pertinence de cette dernière. Si le fait de «*défaire*» l’objet contenu de l’objet contenant rend l’analyse impossible ou d’une façon générale compromise, il s’agira dans ce cas d’une composition.
On peut prendre l’exemple d’une fiche d’adhésion à la bibliothèque qui ne peut «*se passer*» des données concernant l’adhérent.

[Hephaistos007]

Ceci dit, le mécanicien peut considérer le moteur comme un composant remplaçable d'une voiture... De son point de vue, la relation est "agrégat" et il peut fabriquer une voiture à partir de deux épaves.

Ce n'est pas trop ca le problème : chaque objet a une vie qui lui est propre. Un moteur peut avoir "plusieurs vies" successives, dans plusieurs voitures. En revanche, un même moteur ne peut pas appartenir à deux objets voitures en même temps. C'est ce critère de non-partageabilité qui impose une relation de composition et non d'agrégation.

[hors-sujet]
Bref, ces relations sont source d'ambiguïtés pour des retombées quasi-nulles dans le code source. A moins de repenser complètement ces relations, elles finiront par disparaitre de la norme UML.
[/hors-sujet]

[wiztricks]

Ce n'est pas trop ca le problème : chaque objet a une vie qui lui est propre. Un moteur peut avoir "plusieurs vies" successives, dans plusieurs voitures. En revanche, un même moteur ne peut pas appartenir à deux objets voitures en même temps. C'est ce critère de non-partageabilité qui impose une relation de composition et non d'agrégation.

Heu?
Dans les deux cas, l'aggrégation traduit une notion de "tout" - la voiture - et d'une de ses parties "le moteur" - c'est de là que vient le non partage et non de la promotion en "composition".
Ce qui fait la différence avec une association "simple" est dans cette notion de "tout" et de "partie" qui est avant tout "conceptuelle" - on pourrait s'en passer sauf peut être si "voiture" et "moteur" doivent avoir leur vie propre.
=> l'association entre "voiture" et "moteur" sur la chaine de fabrication ne devient aggrégat qu'après que le "robot" ait mis le moteur dans le chassis.

[hors-sujet]
Bref, ces relations sont source d'ambiguïtés pour des retombées quasi-nulles dans le code source. A moins de repenser complètement ces relations, elles finiront par disparaitre de la norme UML.
[/hors-sujet]

Ce qui est "important" derrière l'aggrégation est qu'elle traduit une hiérarchie. Si elle est effective, elle a des conséquences significatives sur la chronologie, les arités et le sens de l'association et donc sur le code associé.

Mais je suis d'accord, nombre de codeurs font de telles impasses sur la conception qu'ils préfèreront mettre *---* partout: çà marche, çà permet de livrer plus vite - la conception c'est quand même le boulot qui consiste à confronter son modèle aux réalités du métier... Et se prendre des baffes et des retards parce qu'ils vont toujours discutailler sur les détails - vu comment sont considérés les développeurs, ils seraient maso!
Reste que çà augmente grandement la dette technique de la réalisation et compromet la facilité des évolutions.

- W

[Hephaistos007]

Heu?
Dans les deux cas, l'aggrégation traduit une notion de "tout" - la voiture - et d'une de ses parties "le moteur" - c'est de là que vient le non partage et non de la promotion en "composition".
Ce qui fait la différence avec une association "simple" est dans cette notion de "tout" et de "partie" qui est avant tout "conceptuelle" - on pourrait s'en passer sauf peut être si "voiture" et "moteur" doivent avoir leur vie propre.
=> l'association entre "voiture" et "moteur" sur la chaine de fabrication ne devient aggrégat qu'après que le "robot" ait mis le moteur dans le chassis.

Heu ? de même.

Je faisait remarquer que le critère essentiel pour choisir entre composition et agrégation (parfois appelé composition faible) repose sur le critère de non-partageabilité. Ou alors quels sont tes critères pour choisir entre composition forte et composition faible car la sémantique ne suffit pas !

Concernant notre exemple, si on parle bas-niveau, cela signifiera qu'il ne pourra pas exister deux objets voitures en mémoire qui auront chacun un pointeur vers un même objet moteur en mémoire. Comme tu le remarqueras, aucun langage de programmation ne propose de construction/mécanisme pour garantir cet invariant. D'où ma seconde remarque : l'effort passé au moment de la conception sera perdu au moment du codage.

Enfin, ma troisième remarque concernait la légitimité de ces deux relations en UML. La tendance qui se profile est de supprimer ces relations car soit on fait les choses correctement et dans ce cas UML offrira bien plus que ces deux relations à travers une étude complète de la méronymie (la relation "tout-partie"), soit on s'abstient.

[wiztricks]

Je faisait remarquer que le critère essentiel pour choisir entre composition et agrégation (parfois appelé composition faible) repose sur le critère de non-partageabilité. Ou alors quels sont tes critères pour choisir entre composition forte et composition faible car la sémantique ne suffit pas !

UML ne définit pas vraiment de sémantique autre que celle d'une association "simple". Donc on peut dire ce qu'on veut - et avoir "raison".

Personnellement, composition et agrégation matérialisent le "non partage".
La sémantique de ce "non partage" est que:

• le "tout" est responsable du cycle de vie de ses parties,
• les parties d'un tout ne sont pas accessibles sans passer par le "tout".

Raconté autrement, le moteur qui a été placé dans une voiture ne peut pas être placé dans une autre. De plus, impossible d'accéder au moteur d'une voiture sans avoir 'la main' sur la voiture qui le contient.
Entre shared et composite, il faut voir côté cycle de vie.
Techniquement c'est assez "bourrin" à réaliser, voir plus loin.

Concernant notre exemple, si on parle bas-niveau, cela signifiera qu'il ne pourra pas exister deux objets voitures en mémoire qui auront chacun un pointeur vers un même objet moteur en mémoire. Comme tu le remarqueras, aucun langage de programmation ne propose de construction/mécanisme pour garantir cet invariant.

Peu de langage de programmation proposent quoi que ce soit permettant d'assurer que les contraintes d'une relation seront satisfaites. C'est la structure et la dynamique qui assurent cela pas le langage.

Par exemple, dans le cas composite, la création d'une voiture crée son moteur et que sa destruction le détruit. On s'interdit de modifier l'état d'un moteur sans accéder/verrouiller la voiture qui le contient.
Pour l'utilisateur d'une instance de voiture, il ne verra que l'état du moteur de cette instance et effectuera des opérations sur la voiture qui pourront avoir un effet 'indirect' sur l'état du "moteur".
Comme il n'est pas possible de créer de moteur sans "voiture", l'invariant est satisfait.

Dans le cas 'shared', on raconte qu'on sait fabriquer les moteurs avant de les intégrer dans des voitures. Mais on s'interdit toujours de toucher à l'état du moteur - au moins certains - sauf en passant par "voiture".

=> si les moteurs qui ont été intégrés dans une voiture ne sont plus accessibles - ne font pas partie d'une collection de moteurs - impossible d'en allouer un à plusieurs voitures à la fois.

Ce qui n'interdit pas d'avoir un pool de moteurs prêts à être intégrés dans une voiture: leur allocation les "sort" du pool et on le "rend" via le destructeur de la voiture.

=> Si on est capable de dire qu'une association est agrégation (shared ou composite), le code correspondant est assez contraint et "simple".

Si c'est seulement une association, les deux objets ont leur vie propre et le boulot pour assurer la cohérence des combinaisons des différents états peut être importante.

D'où ma seconde remarque : l'effort passé au moment de la conception sera perdu au moment du codage.

La quantité de code à produire pour réaliser des agrégations est moindre que pour une association quelconque. Compte tenu des ratios standards de temps passés à concevoir, coder, tester,... un peu de temps perdu à la conception pour "simplifier" est toujours un gain de temps au "global".

Enfin, ma troisième remarque concernait la légitimité de ces deux relations en UML. La tendance qui se profile est de supprimer ces relations car soit on fait les choses correctement et dans ce cas UML offrira bien plus que ces deux relations à travers une étude complète de la méronymie (la relation "tout-partie"), soit on s'abstient.

la méronymie est empruntée à la linguistique qui fait un joli retour depuis qu'on parle de web sémantique et d'ontologies. Et je reconnais qu'essayer de donner du sens à n'importe quoi est un "vrai boulot".

Il n'est pas interdit de penser qu'il sera utile d'avoir des langages de représentation graphiques tels qu'UML ou construit de façon similaire à...
UML adressant une classe bien définie de problèmes, je ne suis pas certain que "l'étendre" ne produise d'autres effets que de "l'obscurcir".
Bon courage,
- W