UML: Komposition und Aggregation

[Gast]

Hallo, ich versuche gerade zu verstehen, was eigentlich der Unterschied zwischen oben genanntem und einer normalen Assoziation ist? Ich habe so in etwa die Definition gelesen, wenn die Klasse Teile der anderen Klasse darstellt. Ich meine wenn eine Klasse mit 3 Instanzen auf andere Klassen habe, sind das doch auch Teile der Klassen, oder? Wo ist da der Unterschied (zb. in C++ oder Java) von einer normalen Assoziation zu einer Komposition und Aggregation?


danke

[Monger]

Afaik gibt es in Java keinen syntaktischen Unterschied zwischen Komposition und Aggregation. Man könnte mit den WeakReferences argumentieren, aber alles in allem besteht in Java nur eine Verbindung zwischen zwei Objekten, wenn sie einander anhand von Referenzen enthalten.

Es ist wohl eher eine Designfrage, um klar zu machen wie stark die Abhängigkeit zwischen zwei Elementen sein soll, und ob z.B. die Referenzen bestehen sollen, oder ob sie auf- und wieder abgebaut werden dürfen.

[darph]

Ich würde das einerseits wirklich über die Teil/Ganzes-Beziehung definieren. Das Ganze hat einen Teil. Dann stellt sich die Frage, ob das Teil existenzabhängig vom Ganzen ist (Komposition), oder ob das Teil unabhängig vom Ganzen stehen kann (Aggregation).

Einfaches Beispiel, Klasse Auto. Ein Auto hat einen Motor. Der Motor ist integraler Bestandteil des Autos - wird das Auto zerstört, geht der Motor auch mit über den Jordan, also existenzabhängige Komposition.

Das Auto hat aber auch Reifen(sets). Sommerreifen, sowie Winterreifen. Das könnte man als Aggregation modellieren, wird das Auto zerstört, bleibt ja mindestens ein Reifensatz übrig.

Also

class Car {
private Motor m;
private Wheelsets[] w;
}
Macht in Java jetzt nicht so den Unterschied. Wichtig wäre also hier zu beachten, daß die einzelnen Reifen noch irgendwie referenziert werden, damit der GC sie nicht mitnimmt.


Jetzt hat ein Auto natürlich auch einen Fahrer. Er ist aber nicht Bestandteil des Autos, sondern ist ihm nur zugeordnet.

Was hier imho signifikant ist, ist, daß es durchaus sinnvoll sein kann, dies nicht über Attribute in der Klasse Auto selbst zu implementieren (wie eben), sondern die Assoziation von außerhalb zu modellieren - zum Beispiel durch eine Map roster = new Map<Driver, Car>. Die beiden Klassen (Fahrer und Auto) wissen auf Codebene voneinander nichts, stehen aber trotzdem in einer Beziehung zueinander. Assoziation

[del_4901]

Ganz einfach, den Motor kann man nicht gleichzeitig in 2 Autos packen und damit fahren -> Komposition. Man kann ihn ausbauen und in ein Anderes Auto verfrachten, das ist erlaubt.
Bei einer Aggregation können sich die Klassen ihren Partner "teilen". So hat jeder Soldat einen Oberst. Die funktionieren auch parallel.
Und bei Der Assoziation besteht einfach nur eine Beziehung zwischen den Klassen, ohne das der eine dem Anderen gehören muss. (über Delegate z.B)

Dazu muss ich noch sagen: Eine Komposition ist immer auch eine Aggregation ist immer auch eine Assoziation.

[Gast]

Afaik gibt es in Java keinen syntaktischen Unterschied zwischen Komposition und Aggregation.


Bei der Aggregation werden Referenzen auf Objekte als Teile gespeichert, die agierende Klasse ist nicht für die Erzeugung der aggregierten Teile zuständig.
Bei der Komposition werden die Objekte selbst erschaffen und gespeichert, zerstört man das Objekt Auto, dann fliegt auch das Objekt Motor raus.
Bei der Aggregation bleibt das Objekt Sommerreifen erhalten, wenn man das Objekt Auto zerstört, weil das Objekt Sommerreifen nicht vom Objekt Auto erzeugt wurde, sondern außerhalb z.B. in der Main Methode.

Und das kann man auch in Java so als Code realisieren.

[Monger]

Und das kann man auch in Java so als Code realisieren.
Ja, aber es gibt rein syntaktisch nichts womit man das eine vom anderen abgrenzen könnte. Klar: man kann es dementsprechend implementieren, d.h. alle Attribute auf Private und keine Getter darauf, so dass ein bestimmter Motor der von einem Auto erzeugt wurde, nur in dessen Kontext existiert.

Rein logisch kann man das schon umsetzen, aber es gibt kein Sprachelement in Java, was diesen Unterschied zwischen Aggregation und Komposition festlegen könnte.

[del_4901]

Ja, aber es gibt rein syntaktisch nichts womit man das eine vom anderen abgrenzen könnte. Klar: man kann es dementsprechend implementieren, d.h. alle Attribute auf Private und keine Getter darauf, so dass ein bestimmter Motor der von einem Auto erzeugt wurde, nur in dessen Kontext existiert.

Rein logisch kann man das schon umsetzen, aber es gibt kein Sprachelement in Java, was diesen Unterschied zwischen Aggregation und Komposition festlegen könnte.
Das gibs auch in den mir bekannten Anderen Sprachen nicht. Die ganze Geschichte ist total Sprachunabhänig, hier geht es allein ums SW-Design.

[Monger]

Das gibs auch in den mir bekannten Anderen Sprachen nicht. Die ganze Geschichte ist total Sprachunabhänig, hier geht es allein ums SW-Design.
Ich bin mir grad unsicher - lebt in C++ ein Objekt weiter, wenn sein "Erzeuger" vernichtet wird?

[del_4901]

Ich bin mir grad unsicher - lebt in C++ ein Objekt weiter, wenn sein "Erzeuger" vernichtet wird?
Das ist implementierungsabhängig. (z.B kann ich die Objekte im Destruktor sichern oder löschen) Und ich kann bei der Komposition auch das Objekt vom Erzeuger vor der Zerstörung "abbauen". (z.B die Ref/Zeiger kopieren und auf 0 setzen) Das hat echt nichts mit der Sprache zu tun, das sagt dem Programmierer nur wie er was zu implementieren hat.

Wenn ich lustig bin mach ich nachher mal ein paar Beispiele wo es klar werden sollte, warum es da Unterschiede gibt.

[Grestorn]

Das gibs auch in den mir bekannten Anderen Sprachen nicht. Die ganze Geschichte ist total Sprachunabhänig, hier geht es allein ums SW-Design.

Doch sicher. In C++ geht dass:


class xy
{
eineKlasse DiesIstEineAggregation;

eineKlasse *DiesIstEineKomposition;
}


Die Aggregation ist Teil der Klasse xy, die Instanz wird immer zusammen mit einer aufgebaut und angebaut. Man kann sie nicht getrennt instantiieren oder freigeben.

Die Komposition dagegen schon: Sie muss nicht existieren, sie kann immer wieder angelegt und freigegeben werden.

[del_4901]

Doch sicher. In C++ geht dass:


class xy
{
eineKlasse DiesIstEineAggregation;

eineKlasse *DiesIstEineKomposition;
}


Die Aggregation ist Teil der Klasse xy, die Instanz wird immer zusammen mit einer aufgebaut und angebaut. Man kann sie nicht getrennt instantiieren oder freigeben.

Die Komposition dagegen schon: Sie muss nicht existieren, sie kann immer wieder angelegt und freigegeben werden.
Das war wohl niks, denn wenn dann ist es andersrum.
Aber auch dann ist es implemtierungsabhänig, sprich man kann Kompositionen auch mit Referenzen/Zeigern aufbauen.

[Grestorn]

Das war wohl niks, denn wenn dann ist es andersrum. Aber auch dann ist es implemtierungsabhänig, sprich man kann Aggregationen auch mit Referenzen/Zeigern aufbauen.

Stimmt, ist andersrum. Wo ist nur meine Birne... :redface:

Aggregationen kannst Du in jeder mir bekannten Sprache machen, auch Java.

Aber Kompositionen sind in Java bestenfalls logisch über eine "final"-Deklaration möglich. Und technisch sind es dann immer noch Aggregationen.

[del_4901]

Stimmt, ist andersrum. Wo ist nur meine Birne... :redface:

Aggregationen kannst Du in jeder mir bekannten Sprache machen, auch Java.

Aber Kompositionen sind in Java bestenfalls logisch über eine "final"-Deklaration möglich. Und technisch sind es dann immer noch Aggregationen.
Das ist doch Quark, wenn nur eine Referenz in der Erzeuger-Klasse besteht, dann sammelt der gc auch automatisch die "Kompostion" mit ein. Das ist wie gesagt implentierungsabhänig (kann es sein, dass ich mich wiederhohle) und nicht durch etweilige Sprachfeatures bestimmt. Die UML soll ja gerade das wegabstrahieren. Ich verdiene damit mein Geld, ich muss es wissen.

[Grestorn]

Das ist doch Quark, wenn nur eine Referenz in der Erzeuger-Klasse besteht, dann sammelt der gc auch automatisch die "Kompostion" mit ein. Das ist wie gesagt implentierungsabhänig (kann es sein, dass ich mich wiederhohle) und nicht durch etweilige Sprachfeatures bestimmt. Die UML soll ja gerade das wegabstrahieren. Ich verdiene damit mein Geld, ich muss es wissen.

Eine einfache Referenz kann zur Laufzeit nach Belieben ausgetauscht werden, ja kann sogar null sein.

Das alles ist bei einer Komposition nicht erlaubt. Komposition ist "Teil des Ganzen", also integraler, nicht austauschbarer Teil.

Wann es freigegeben wird, ist ja nur ein Teilaspekt.

In C++ ist eine Komposition tatsächlich im Speicher genau an der Stelle, an der sie deklariert wurde, im Vater-Objekt enthalten, nicht als Referenz auf eine im Speicher unabhängige Entität.

[del_4901]

Eine einfache Referenz kann zur Laufzeit nach Belieben ausgetauscht werden, ja kann sogar null sein.

Das alles ist bei einer Komposition nicht erlaubt. Komposition ist "Teil des Ganzen", also integraler, nicht austauschbarer Teil.

Wann es freigegeben wird, ist ja nur ein Teilaspekt.

In C++ ist eine Komposition tatsächlich im Speicher genau an der Stelle, an der sie deklariert wurde, im Vater-Objekt enthalten, nicht als Referenz auf eine im Speicher unabhängige Entität.
Ja natürlich, kann man eine Referenz/Pointer austauschen. Und das ist auch bei einer Komposition erlaubt. Wichtig ist das es nicht gleichzeitig verwendet werden darf. Reifen am Auto kann ich austauschen. (Sommer/ Winterreifen) Beide werden mit der Komposition angeschlossen. Der wichtige Unterschied ist das ich nicht einen Satz Reifen an 2 Fahrzeugen gleichzeitig montieren kann.
Das Verhalten, was passiert wenn man ein Objekt löscht war auch nur ein Beispiel. Wer die Teile erzeugt ist auch total Latte, das kann das Objekt selber machen, das kann aber auch eine Factory sein, etc...

Ich glaube ich sollte wirklich mal "aufzeichnen" was mit UML Diagrammen im Laufe ihrer Entwicklung passiert, und warum es da diese Unterschiede gibt. An der Stelle herscht wie immer derber Nachhohlebedarf.


Bei der Aggregation bleibt das Objekt Sommerreifen erhalten, wenn man das Objekt Auto zerstört, weil das Objekt Sommerreifen nicht vom Objekt Auto erzeugt wurde, sondern außerhalb z.B. in der Main Methode.
Sommerreifen werden auch zerstört solange sie gerade montiert sind. (Ist mir nur grade als ich nach Beispielen gesucht habe wieder aufgefallen.)

[del_4901]

Ich mach mal ein Beispiel für eine Aggregation, in Zhg. mit unserem Auto.

Ein Autoradio besitzt keinen oder einen Sender, der gerade eingestellt ist.

Diese Beziehung können sich mehrere Autos teilen.

[Monger]

Jaja, schon klar. UML soll den Zusammenhang in objektorientierten Prozessen darstellen, und zwar unabhängig von der Implementierung.

Aber genau darum drehte sich ja die Ausgangsfrage: um die konkrete Umsetzung.
Und da gibt es eben kein starres Muster, wie etwas umzusetzen ist. UML Diagramme müssen interpretiert werden, deshalb funktioniert das ja auch mit den Code Generatoren eher schlecht als recht! ;)

[del_4901]

jaja == ??
:udevil:

[Grestorn]

Ja natürlich, kann man eine Referenz/Pointer austauschen. Und das ist auch bei einer Komposition erlaubt. Wichtig ist das es nicht gleichzeitig verwendet werden darf. Reifen am Auto kann ich austauschen. (Sommer/ Winterreifen) Beide werden mit der Komposition angeschlossen. Der wichtige Unterschied ist das ich nicht einen Satz Reifen an 2 Fahrzeugen gleichzeitig montieren kann.
Das Verhalten, was passiert wenn man ein Objekt löscht war auch nur ein Beispiel. Wer die Teile erzeugt ist auch total Latte, das kann das Objekt selber machen, das kann aber auch eine Factory sein, etc...

Ich glaube ich sollte wirklich mal "aufzeichnen" was mit UML Diagrammen im Laufe ihrer Entwicklung passiert, und warum es da diese Unterschiede gibt. An der Stelle herscht wie immer derber Nachhohlebedarf.

Sommerreifen werden auch zerstört solange sie gerade montiert sind. (Ist mir nur grade als ich nach Beispielen gesucht habe wieder aufgefallen.)

Irgendwie habe ich das anders gelernt. Wenns auch schon ne Weile her ist. Aber ich müsste mich schon sehr täuschen, wenn Kompositionen während der Lebzeit des Vaters neu angelegt und ausgetauscht werden dürfen.

Deine "gehört zu" Relation, die Du mit den montierten Autoreifen skizzierst, würde ich ohnehin immer als Stereotyp mit angeben. Denn andere Relationen auf den Reifen kann es natürlich schon geben (der Reifen kann z.B. aus der Finanzbuchaltung referenziert werden, obwohl er gerade am Auto montiert ist).

Dass es auf ein und die selbe Instanz nicht mehrere Aggregationen geben kann - egal ob als Komposition oder Aggregation - gilt grundsätzlich, dafür brauche ich keine Raute auszufüllen.

Aber die Diskussion ist ohnehin sehr akademisch.

Bei einem UML Diagramm male ich Aggregat-Rauten um festzulegen, dass eine Instanz die referenzierten Objekte kontrolliert (also anlegt und abbaut). Einen Grund die Raute auszumalen habe ich noch nie gesehen.

[del_4901]

Irgendwie habe ich das anders gelernt. Wenns auch schon ne Weile her ist. Aber ich müsste mich schon sehr täuschen, wenn Kompositionen während der Lebzeit des Vaters neu angelegt und ausgetauscht werden dürfen.
Dann hast du das falsch gelernt oder falsch verstanden. Das ist allerdings nach meiner Erfahrung nichts ungewöhnliches, denn viele Profs haben es selber nicht soweit verstanden, dass Sie es anderen beibringen können.

Deine "gehört zu" Relation, die Du mit den montierten Autoreifen skizzierst, würde ich ohnehin immer als Stereotyp mit angeben. Denn andere Relationen auf den Reifen kann es natürlich schon geben (der Reifen kann z.B. aus der Finanzbuchaltung referenziert werden, obwohl er gerade am Auto montiert ist). Der Stereotyp hat damit überhaupt nichts zu tun, der beschreibt nur die Anzahl. Und bei der Finanzbuchhaltung denkst du schonwieder zuweit. Wenn ich das einmal soweit modeliert habe (Stufe 'x), kann es sein dass sich aus einer Kompostion eine Aggregation entwickelt. Weil eine Komposition ist immer auch Aggregation.


Dass es auf ein und die selbe Instanz nicht mehrere Aggregationen geben kann - egal ob als Komposition oder Aggregation - gilt grundsätzlich, dafür brauche ich keine Raute auszufüllen.
Nein das stimmt nicht. Da kann ich dir nachher ein super Gegenbeispiel bringen.


Aber die Diskussion ist ohnehin sehr akademisch.
Nicht wirklich, ich muss da sehr praktisch mit entwickeln.

Bei einem UML Diagramm male ich Aggregat-Rauten um festzulegen, dass eine Instanz die referenzierten Objekte kontrolliert (also anlegt und abbaut). Einen Grund die Raute auszumalen habe ich noch nie gesehen.
Das unterscheidet einen SW-Architekten vom Programmierer. Eigentlich findet man in unserer aus Dingen zusammengesetzen Welt mehr Kompositionen als Aggregationen. Erst im laufe der Entwicklung lösen sich einige Kompostionen auf. Sprich ich würde mal behaupten, das du mit einem zu niedrigen Abstraktionsgrad deine Entwicklung anfängst.

[Grestorn]

Der Stereotyp hat damit überhaupt nichts zu tun, der beschreibt nur die Anzahl.

Entschuldige, aber das stimmt nun überhaupt nicht.

Die Anzahl wird durch die Kardinalität festgelegt. Der Stereotyp ist ein allgemeines Mittel, um Relationen oder sonstige Entitäten genauer zu klassifizieren.

Stereotyp: http://de.wikipedia.org/wiki/Stereotyp_%28UML%29

Ich bin kein Freund von zu abstrakten, zu sehr von der Technik entfernten Modellen. Man verbringt sehr viel Zeit damit, nur um festzustellen, dass sie für die Umsetzung ohnehin untauglich sind.

Meiner Ansicht nach muss ein SW-Architekt nahe genug an der Technik bleiben, um den Blick für die Realisierung nicht zu verlieren.

[Gast]

Bei Komposition/Aggregation geht es doch nur um "logische" Relationen von "logischen" Entitäten, nicht um irgendwelche sprachl. gebundenen Objekt Referenzen.

[del_4901]

Entschuldige, aber das stimmt nun überhaupt nicht.

Die Anzahl wird durch die Kardinalität festgelegt. Der Stereotyp ist ein allgemeines Mittel, um Relationen oder sonstige Entitäten genauer zu klassifizieren.

Stereotyp: http://de.wikipedia.org/wiki/Stereotyp_%28UML%29

Stimmt, du verwirrst mich die ganze Zeit. Aber was hat denn bitte der Stereotyp(mir war das Wort entfallen) mit der Art der Assoziation zu tun?
Das was du meinst schreibt man an die Assoziation dran. Denn der Stereotyp beschreibt nur eine Klasse/Objekt, aber nicht die Beziehung dazwischen.

Ich bin kein Freund von zu abstrakten, zu sehr von der Technik entfernten Modellen. Man verbringt sehr viel Zeit damit, nur um festzustellen, dass sie für die Umsetzung ohnehin untauglich sind.

Meiner Ansicht nach muss ein SW-Architekt nahe genug an der Technik bleiben, um den Blick für die Realisierung nicht zu verlieren.

Wie alle Programmierer, den Blick für die Reallisierung verliert man ganz bestimmt nicht. Stattdessen behält man den Überblick. Meiner Ansicht nach, verliert man, wenn man von Anfang an zuviel an die Implementierung denkt, diesen Überblick. Und dann vergisst man schnell etwas. Deine Variante mag bei 0815 Programmen noch gut gehen, aber nicht bei großer SW, wo 20 Mann dran arbeiten. Und untauglich sind die garantiert nicht, die werden in vielen Schritten zur entgültigen (und implementierungsfähigen) Beschreibung transformiert.

Das würde mich tatsächlich interessieren. Ich kann auf alles Verweisen, auch wenn es Teil etwas größeren ist.

Dein Kopf gehört unzweifelhaft fest zu Dir, er ist Teil des ganzen AlphaTiers, oder? Er ist also eine Kompositionselement von Dir.
Jo, Keiner kann sich meinen Kopf mit mir teilen. Ausßnahme Siamesische Zwillinge (aber die nehmen wir mal raus)

Dennoch kann es eine Methode "getKopfRef()" geben, die von Dir implementiert wird. Und ich kann mir eine Liste mit den Kopf-Referenzen aller Foren-Mitglieder halten. Es gibt nichts was da dagegen spricht.
Klar kann ich das machen, in dem Moment tranformiert man die Komposition zu einer Aggregartion. Wobie ich hier Abstriche machen würde und das getrennt voneinader beschreiben würde, um dadurch die Komposition zu erhalten. (das ist persöhnlicher Geschmack)

[Grestorn]

Stimmt, du verwirrst mich die ganze Zeit. Aber was hat denn bitte der Stereotyp(mir war das Wort entfallen) mit der Art der Assoziation zu tun?
Das was du meinst schreibt man an die Assoziation dran. Denn der Stereotyp beschreibt nur eine Klasse/Objekt, aber nicht die Beziehung dazwischen.

Stereotypen kann man bei allen Elementen eines UML Diagrams anfügen.

Gerade bei Assoziationen (ich sage gewohnheitsmäßig immer Relationen) wird der Stereotyp sehr gerne verwendet, um die Art der Assoziation genau zu beschreiben, wie eben ein "gehört zu", "wird verwendet" oder "kennt" usw.

[del_4901]

Stereotypen kann man bei allen Elementen eines UML Diagrams anfügen.

Gerade bei Assoziationen (ich sage gewohnheitsmäßig immer Relationen) wird der Stereotyp sehr gerne verwendet, um die Art der Assoziation genau zu beschreiben, wie eben ein "gehört zu", "wird verwendet" oder "kennt" usw.

Stereotypen (weilche man Immer in spitzen Klammern angibt) gibt es nur bei Klassen/Objekten/Paketen und Abhänigkeiten (Dependencys)
Assoziationen kennen unter anderem nur Navigierbarkeit (Navigability) und Spezialisierung (Specialization). Das hat aber nichts, aber auch gar nichts mit Stereotypen zu tun. (bei der OMG nachgeschlagen) http://www.uml.org/
Ich musste auch erst nachschlagen wie das genau heißt, aber dazu weiß man ja wo es steht.

BTW: Mal ganz davon abgesehen, dass Stereotypen von der OMG vorgegeben werden.

[Grestorn]

Stereotypen (weilche man Immer in spitzen Klammern angibt) gibt es nur bei Klassen/Objekten/Paketen und Abhänigkeiten (Dependencys)
Assoziationen kennen unter anderem nur Navigierbarkeit (Navigability) und Spezialisierung (Specialization). Das hat aber nichts, aber auch gar nichts mit Stereotypen zu tun. (bei der OMG nachgeschlagen) http://www.uml.org/
Ich musste auch erst nachschlagen wie das genau heißt, aber dazu weiß man ja wo es steht.

BTW: Mal ganz davon abgesehen, dass Stereotypen von der OMG vorgegeben werden.

Stereotypen werden in spitzen Klammern angegeben, stimmt.

Und in bisher jedem Tool mit dem ich gearbeitet habe, konnte man sie frei eingeben und an jede Assoziation binden (u.a. Rational Rose und Together). Und auch der Gamma beschreibt sie so, sonst müsste ich mich schon sehr schwer täuschen.

/edit: Sieht so aus, als käme dieser Unterschied durch UML 1.x und 2.0.

[del_4901]

Stereotypen werden in spitzen Klammern angegeben, stimmt.

Und in bisher jedem Tool mit dem ich gearbeitet habe, konnte man sie frei eingeben und an jede Assoziation binden (u.a. Rational Rose und Together). Und auch der Gamma beschreibt sie so, sonst müsste ich mich schon sehr schwer täuschen.

/edit: Sieht so aus, als käme dieser Unterschied durch UML 1.x und 2.0.
Gamma arbeitet sogar noch mit OMT.
Rational Rose und Together sind nun wirklich nicht die besten Tools.
Enterprise Architekt ist das Maß aller Dinge. (Ich habe alle schon durch)

[Gast]

Sommerreifen werden auch zerstört solange sie gerade montiert sind. (Ist mir nur grade als ich nach Beispielen gesucht habe wieder aufgefallen.)

Das mit den Sommerreifen und Auto ist auch sowieso ein schlechtes Beispiel.

In meinem UML Buch gibt es als Beispiel Restaurant und Stühle und die Stühle sind vom Restaurant unabhängig -> Aggregation.

[del_4901]

Das mit den Sommerreifen und Auto ist auch sowieso ein schlechtes Beispiel.

In meinem UML Buch gibt es als Beispiel Restaurant und Stühle und die Stühle sind vom Restaurant unabhängig -> Aggregation.
Das ist auch ein schlechtes Beispiel, weil die Stühle nicht in 2 Restaurants gleichzeitig stehen können. In unserer realen Welt sind einfach sehr viele Dinge zusammengesetzt -> Komposition. Das relativiert sich dann, jeh mehr man das Design "verfeinert".

[Gast]

Das ist auch ein schlechtes Beispiel, weil die Stühle nicht in 2 Restaurants gleichzeitig stehen können. In unserer realen Welt sind einfach sehr viele Dinge zusammengesetzt -> Komposition. Das relativiert sich dann, jeh mehr man das Design "verfeinert".

Aggregationen müssen nicht von 2 Objekten gleichzeitig benutzt werden können
und das ist auch nicht der Sinn einer Aggregation.
Und wenn du 2 Restaurants hast, dann bekommt jedes Restaurant seine Stühle Objekte.

Der Unterschied zwischen einer Aggregation und einer Komposition ist der,
festzulegen ob ein Objekt mit zertört wird, wenn das Hauptobjekt zerstört wird.
Aggregationen sind als locker gebunden und es ist nicht deren Sinn zu sagen, daß sie von 2 Hauptobjekten gleichzeitig verwendet werden.

[del_4901]

Aggregationen müssen nicht von 2 Objekten gleichzeitig benutzt werden können
und das ist auch nicht der Sinn einer Aggregation.
Und wenn du 2 Restaurants hast, dann bekommt jedes Restaurant seine Stühle Objekte. Ein "aggegiertes" Objekt kann von mehreren anderen Objekten gleichzeitig benutzt werden, ein "zusammengesetztes" kann das nicht.
Siehe OMG Definition.

Der Unterschied zwischen einer Aggregation und einer Komposition ist der,
festzulegen ob ein Objekt mit zertört wird, wenn das Hauptobjekt zerstört wird.
Aggregationen sind als locker gebunden und es ist nicht deren Sinn zu sagen, daß sie von 2 Hauptobjekten gleichzeitig verwendet werden.


Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.

Seite 57

[Gast]

Seite 57

Was will ich mit dem Komposition Beispiel?
Wir reden gerade über Aggregationen.

[del_4901]

Was will ich mit dem Komposition Beispiel?
Wir reden gerade über Aggregationen.
Ich habe nur gezeigt, dass diese Aussage allein falsch ist:

Der Unterschied zwischen einer Aggregation und einer Komposition ist der,
festzulegen ob ein Objekt mit zertört wird, wenn das Hauptobjekt zerstört wird.
Aggregationen sind als locker gebunden und es ist nicht deren Sinn zu sagen, daß sie von 2 Hauptobjekten gleichzeitig verwendet werden.
BTW: es ist zwar nicht falsch anstatt einer Komposition eine Aggregation zu nehmen. (Eine Komposition ist immer auch eine Aggregation) Aber es ist halt einfach ungenau, und der zukünftigen Entwicklung zuliebe sollte man eine Komposition einsetzen.