J'ai récemment passé beaucoup de temps à effectuer des conceptions de UML détaillées de divers composants SO que j'ai depuis écriture. En regardant ce que j'ai récemment terminé et comparant que lorsque j'ai appris à UML, je vois que j'utilise maintenant presque strictement les relations d'agrégation et de composition, et j'ai pratiquement abandonné les relations "vanille" non dirigées / dirigées. J'utilise toujours bien sûr des généralisations et des réalisations, mais celles-ci sont distinctement différentes de celles ci-dessus et ne sont pas considérées comme faisant partie de cette question.
Il me semble que l'agrégation / la composition implique la même signification d'associations "vanille", etc. L'agrégation et la composition impliquent naturellement une direction et tout programme moderne UML vous permettra toujours de définir la multiplicité sur une relation d'agrégation / de composition et d'appliquer également un verbe à la relation. À ce stade, je vois peu de but aux associations de vanille.
Je comprends que certaines personnes ont du mal à comprendre la différence entre l'agrégation et la composition. Tôt, j'avais un peu difficile de saisir la façon dont ils diffèrent et je crois que la confusion faisait partie de la raison pour laquelle j'ai utilisé des associations de vanille. Je suis au point où je vois peu ou pas d'utilisation pour les associations de vanille et je n'aime pas les voir utiliser comme je pense qu'ils laissent des choses à la question (en particulier une relation de cycle de vie forte ou faible entre deux objets). Je crois que la seule utilisation pratique des associations de vanille est lorsque votre compréhension du problème à la main n'est pas encore suffisamment développée pour déterminer la différence de cycle de vie entre l'agrégation et la composition. Dans un tel cas, il est préférable d'ajouter au moins show que la relation existe et vous pouvez ensuite revenir et le changer de manière appropriée lorsque vous comprenez mieux le problème.
Longue histoire courte, je crois que la grande majorité du temps que les gens utilisent des associations de vanille, elles pourraient être décrites plus avec précision comme une agrégation, et parfois comme une composition. Suis-je terriblement tort dans ma croyance? Est-ce que je manque quelque chose? Laissez-moi l'entendre!
5 Réponses :
Les agrégations et les compositions impliquent qu'un participant à la relation "domine" l'autre (dans des compositions la domination est plus forte), tandis que les associations normales n'ont pas cette implication. Par conséquent, j'utilise des associations normales lorsque les deux participants ont la même importance dans la relation
Sur un diagramme de classe, vous pensez aux relations statiques entre les classes. Vous n'avez probablement pas vraiment besoin de penser aux aspects comportementaux de ces relations sur le diagramme de la classe, il ne fait que confirmer les eaux et témoigne de la sur-analyse. (IMho bien sûr)
Vous avez frappé sur la tête quand vous dites, 'Les associations de vanille' L'utilisation pratique est uniquement lorsque votre compréhension du problème n'est pas encore développée pour déterminer la différence de cycle de vie et < EM> Montrez que la relation existe et vous pouvez ensuite revenir et le changer de manière appropriée lorsque vous comprenez mieux le problème à la main .
Le UML Meta-Model définit l'agrégation et la composition comme extensions d'association. Une association peut être considérée comme une relation non raffinée entre les objets de domaine, de la même manière qu'un objet de domaine est une classe non raffinée. J'utilise généralement des associations simples à la scène de modélisation de domaine et je l'affinez dans la composition ou l'agrégation, le cas échéant, lorsque je résolvez le modèle de classe détaillé.
Bien expliquée de réponse concise. Logique. Merci Martin!
L'argument est évident: le fait que l'agrégation et la composition étendent le concept d'association à UML ne justifie pas l'opinion selon laquelle "l'association est une relation non raffinée entre les objets de domaine". Il existe de nombreux cas où une association n'est ni une agrégation ni une composition. Voir ma réponse ci-dessous.
En fait, la plupart des cas d'associations de modèles de classe UML ne sont ni des agrégations ni des compositions. Par exemple, l'association entre les classes Un agrégation est une forme spéciale d'association avec la signification souhaitée d'une relation entièrement entière, mais sans sémantique précise (la spécification UML indique: "La sémantique précise de l'agrégation partagée varie selon la zone d'application et la modéleuse"). Par exemple, nous pouvons modéliser une agrégation entre les classes Une composition (également appelée "agrégation composite" dans la spécification UML) est une forme d'agrégation spéciale, dans laquelle une instance de composant fait partie de l'une des nombreuses instances d'agrégat à la fois (c'est-à-dire qu'il ne peut pas être partagé entre plusieurs agrégats. ). Cela signifie que l'agrégation entre En plus de ces caractéristiques principales d'une composition (pour avoir des pièces exclusives), une composition peut également être une dépendance du cycle de vie entre un agrégat et ses composants impliquant que lorsqu'un agrégat est supprimé, toutes ses pièces sont supprimées. avec ça. Cependant, cela ne s'applique qu'à certains cas de composition, et non aux autres, et ce n'est donc pas une caractéristique déterminante. L'UML Spec STATS: "Une partie peut être retirée d'une instance composite avant que l'instance composite soit supprimée et ne soit donc pas supprimée dans le cadre de l'instance composite." Dans notre exemple de la composition du moteur de la voiture, il est clair que le boîtier que le moteur puisse être retiré de la voiture avant la destruction de la voiture, auquel cas le moteur n'est pas détruit et peut être réutilisé. éditeur et book pour attribuer les livres publiés par un éditeur à cet éditeur n'est ni une agrégation ni une composition car les livres publiés par un éditeur ne sont pas des pièces ou des composants de cet éditeur.
voiture et Moteur et entre les classes cours et conférence car Un moteur fait partie d'une voiture et une conférence fait partie d'un cours.
voiture et moteur est une composition (car un moteur ne peut pas être partagé entre deux voitures en même temps), tandis qu'une agrégation entre le cours et La vérification n'est pas nécessairement une composition car une conférence peut être partagée entre deux cours (par exemple, un cours de gestion de base de données et un cours d'ingénierie logicielle pourraient partager une conférence sur UML). Cela implique que la multiplicité d'une association de composition se termine au côté agrégat est soit 1OR 0..1, alors qu'elle peut également être * dans le cas d'une agrégation non composite.
Votre compréhension de la composition (ou au moins votre citation de la spécification UML) est fausse. Voir Spécification de la superstructure UML, v2.4.1 , page 38 Lequel dit ".Composite agrégation est une forme d'agrégation forte nécessitant une instance de pièce d'être incluse dans la plupart des composites à la fois. ". Où dit-il "..is une partie de la plupart des agrégats."
@XMOJMR: Ni mon compréhension ni ma citation ne sont pas fausses. Je viens d'utiliser "agrégat" comme synonyme de "composite". Alors, veuillez annuler votre vote injustifié.
Là est Quelque chose ne va pas avec votre utilisation de mot "agrégat" comme synonyme de "composite". Ils ne sont pas des synonymes et vous dessinez une conclusion, ce qui donne une impression que vous citez la spécification UML. Et puis vous avez utilisé votre mauvaise citation comme justification pour la bownvoting Stackoverflow.com/a/25236323/2626313 Où votre "citation simplifiée" " Ne s'applique pas. Je peux renverser mon vote si vous inversez votre vote et améliorez votre argument. Vous êtes "citant" quelque chose d'un livre qui ne contient pas votre citation du tout. J'ai examiné ma réponse après votre commentaire. Pouvez-vous faire la même chose?
Les associations de vanille, l'aggregration et les compositions sont parfois expliquées avec la sémantique suivante:
La différencation principalement de l'agrégation et de la composition se déplacent autour de la question "Si l'objet maître est parti - ce qui arrive aux objets de la pièce?".
L'idée est donc d'avoir une certaine contrainte d'intégrité comme "sur la cascade de suppression", être décrite à l'aide d'une différenciation dans l'utilisation de l'une des trois options. UML a trois symboles différents pour cette
Le problème avec ces trois options est que la sémantique n'est pas assez précise pour des situations de vie réelles, surtout si vous regardez des situations qui changent au fil du temps
E.g. Essayer de répondre à la question simple voir
Combien de ces roues seront parties quand la voiture est partie?
Si vous essayez de modéliser cette situation avec les trois symboles UML propose de vous retrouver avec beaucoup de discussion et de négociation ce que votre modèle signifie vraiment. Je pense qu'il est bien préférable de ne jamais utiliser l'aggeation et les symboles de composition, mais décrivez toujours la sémantique de l'association comme
précisément que possible avec quelques lignes de texte. De cette façon, vous pouvez préciser les personnes qui lisent votre modèle ce que vous voulez vraiment.
Je pense que c'est même o.k. écrire "une voiture est une composition de pièces qui comprend les roues ...."
Mais maintenant, vous n'utilisez pas de symbole de composition, mais vous référencez vraiment l'acte de composer quelque chose.
Voir aussi
http://de.wikipedia.org/wiki/assoziation_%28uml%29# Aggregation_und_komposition (allemand)
