Diskussion:Assoziation (UML)

Komposition und Aggregation

"Das einzige eindeutige Unterscheidungsmerkmal betrifft die Multiplizität. Teile, die über eine Komposition mit einem Ganzen verbunden sind, dürfen jeweils in höchstens einem (0..1) Ganzen vorkommen. Falls es sich bei der Assoziation um eine Komposition handelt, kann ein Teil auch mehrere "Väter" haben." Ah ja. Da haben wir ihn also: Den Unterschied zwischen Komposition und Komposition. Eins von beiden sollte sohl Aggregation heißen, aber welches? --Blah 10:12, 29. Mär 2005 (CEST)

Ich habs korrigiert. Die mit den mehreren "Vätern" ist die Aggregation. --Gubaer 20:24, 29. Mär 2005 (CEST)

Irgendwann muss man auchmal einsehen dassmans schlicht nicht weiss, dann sollte man aber auch nicht versuchen darüber zu schreiben. (nicht signierter Beitrag von 77.58.108.143 (Diskussion) 15:03, 21. Mär. 2011 (CET))

"Sie wird dann als binäre Assoziation bezeichnet und spezifiziert, dass beide beteiligten Klassen zueinander in Beziehung stehen." Es sollte wohl heißen "Sie wird dann [...], wenn [...]" -- Halder 08:30, 17. Aug 2006 (CEST)

Das Beispiel mit dem Buch und der Seite ist doch Unfug, oder? Eine Seite kann doch auch ohne Buch "sein", Sinnvoller wäre glaube ich im Beispiel "Kapitel" als Komposition zum Buch zu nehmen, oder? --Konqi 23:42, 13. Nov. 2006 (CET)

Das Beispiel mit dem Buch und der Seite enthält einen Fehler: Da es sich um eine Komposition handelt, muss eine Seite immer GENAU zu einem Buch gehören und nicht zu (0..1). -- stefan & max (nicht signierter Beitrag von 77.9.71.230 (Diskussion | Beiträge) 19:48, 13. Mai 2009 (CEST))

Um es anders auszudrücken: Assoziationen könne Graphen erzeugen. Kompositionen können nur Bäume erzeugen und Aggregationen ebenso Bäume, wobei ein Teilbaum auch gleichzeitig an einem anderen Baum hängen darf. (BE)

Falls es euch auch so geht wie mir: es ist gar nicht so leicht eine echte Komposition zu finden. Fast immer kann etwas auch vom übergeordneten Element in irgendeiner Form getrennt existieren. Meine Überlegung: untrennbar kann etwas nur im Geiste sein. Z.B. existiert ein Knopfloch nur wenn auch ein umgebender Stoff existiert. Das Loch existiert nur im Gedanken. In Wirklichkeit gibt es überhaupt kein Loch. Hemd->Knopflöcher ist also eine echte Komposition, würde ich sagen. Ein Knopfloch alleine kann nicht sein. Vielleicht könnte man ja dies (oder ähnliches) als Beispiel nehmen. Robert Schneider 80.120.10.114 16:04, 14. Sep. 2015 (CEST)

Es kommt immer auf den Kontext an. Wenn du lösgelöst von tatsächlicher Softwareentwicklung, gewissermaßen philosophisch genau etwas modellieren willst, ist tatsächlich eine echte Komposition selten. Umgekehrt ist aber in der Welt der realen Softwareprobleme die Komposition viel häufiger als die nicht existenzabhängige Aggregation. Hemd->Knopfloch ist natürlich eine Komposition. Allerdings ist auch das wieder kontextabhängig. Man kann durchaus Software modellieren, bei bei Es sich hier nicht um eine Komposition, sondern nur um eine Aggregation handelt. Angenommen, du schreibst eine Software, bei der du Schnittmuster für Hemden erstellen kannst. Da müssen Knopflöcher rein und die soll der User per Drag and Drop platzieren können. Und hierbei kann man sich durchaus vorstellen, dass man ein Knopfloch aus dem Hemd "herauszieht" und neben hin legt. Es kommt immer auf den Kontext an. Du baust ein Modell und ein Modell ist immer eine Abstraktion, eine Vereinfachung der Wirklichkeit.--Der Hâkawâti ✉ 19:46, 15. Sep. 2015 (CEST)

Unklarer Zusatz

Der Zusatz: "Zudem ist das Teil (im Falle der Komposition) oft existenzabhängig vom Ganzen, falls das Ganze die Kardinalität 1 und nicht [0..1] trägt" scheint nicht logisch zu sein. Die Tatsache, dass bei einer Komposition das Teil nur im Zusammenhang mit dem Ganzen existieren kann, ist auch dann gültig, wenn das Ganze eine Kardinalität von [0..1] hat (und damit nicht nur dann, falls sie 1 ist).

Habe den Satz entfernt. Gubaer 11:19, 8. Okt 2006 (CEST)

Verwirrung bzgl. Kardinalität auf Aggregatseite

Leider bin ich nun ganz verwirrt, was die Kardinalität auf der Aggregatseite betrifft. In dem Beispiel ist 0..1 gezeigt. Demnach existiert ein Teil auch ohne sein Ganzes. Auf der anderen Seite findet man in der Literatur auch Sätze wie "Die Kardinalität auf der Aggregatseite kann nur 1 sein." (s. beispielsweise [[1]]).

hi, das Beispiel wo von du redest stellt eine Aggregation dar (Überschrift). Mit "Die Kardinalität auf der Aggregatseite kann nur 1 sein." meinen die die Komposition. Also eine Komposition hat eine Aggregatseite deren Kardinalität nur 1 sein kann ;) (nicht signierter Beitrag von 77.24.18.26 (Diskussion | Beiträge) 21:54, 13. Sep. 2009 (CEST))

Die Verwirrung ist sogar bei Autoren von Büchern vorhanden. Dennoch ist die richtige Antwort ganz einfach zu finden. In der UML-Spezifikation http://www.omg.org/spec/UML/ auf Seite 25 sind schon zwei Beispiele dafür abgebildet. Ich habe den Artikel entsprechend korrigiert und ein Beispiel hinzugefügt, bei dem es gar nicht anders geht. AxelScheithauer 18:16, 25. Mär. 2011 (CET)

Lebensdauer von Teilen bei Komposition

Die Lebensdauer der Teile ist bei der Komposition an die Lebensdauer des Aggregats gebunden. Es macht ja keinen Sinn diese Objekte allein da stehen zu lassen, weil sie keine anderen Väter mehr haben (erzwungen durch die Kardinalität 0..1) und sie ohne ein einziges Aggregat sinnlos sind.

Das stimmt so nicht: Die Teile können auch allein da stehen, genau das wird ja mit der Multiplizität (nicht Kardinalität, das ist die Mächtigkeit einer konkreten Menge) 0..1 ausgedrückt. Nur so lange sie zu einem Aggregat gehören ist ihre Lebensdauer vom Aggregat abhängig. --AxelScheithauer 16:41, 17. Jun. 2011 (CEST)

Beispiel für Komposition: Ein Anwendungsbeispiel für eine 0..1 Komposition wäre eine Verbindung die erzeugt wird mit einer zu 0 Beziehung. Daher, man hat keine Verbindung und kann sein Objekt problemlos wieder löschen, da keine Beziehungen aufgebaut wurden. Sobald man aber eine Verknüpfung aufbaut für dieses Objekt, ist dieses an "das Ganze" gebunden. Soll es gelöscht werden, muss es zwangsläufig mit dem Ganzen gelöscht werden, oder gar nicht. Ein Alltags Beispiel wäre dafür wohl so etwas wie eine Perlenkette. Jede Perle wird einzeln hergestellt, man hat also durchaus eine 0..1 Beziehung von der Perle zur Perlenkette, in einem frühen Stadium des Herstellungsprozess der Perlenkette. Aber sobald die Beziehung aufgebaut ist, hat man eine Komposition und darf die einzelnen Perlen nicht mehr aus der Kette entfernen, ohne die Perlenkette damit auch zu löschen. Bildet man diese Beziehung als Aggregation ab, kann die Perlenkette jederzeit wieder getrennt werden. Demnach, die Komposition bedeutet das die Beziehung die Teile "zusammenschweißt" , sie also untrennbar macht, wenn die Beziehung aufgebaut wird. (nicht signierter Beitrag von 213.30.245.2 (Diskussion) 17:45, 7. Nov. 2016 (CET))

Ich bin anderer Meinung als die vorherigen zwei Diskussionsbeiträge und denke, dass der aktuelle Artikelteil zu Komposition irreführend ist. Im Abschnitt "Komposition" wird zuerst erklärt, dass die Teile existenzabhängig vom Ganzen sind und daher beim Löschen des Ganzen ebenfalls gelöscht werden müssen. Das ist auch meine Vorstellung von Komposition (insbesondere in Abgrenzung zur Aggregation, bei der ja keine Existenzabhängigkeit besteht). Der Artikel fährt dann aber fort und behauptet, dass ein Teil auch unabhängig von seinem Ganzen werden kann. Ich denke, dass es sich dann nicht mehr um Komposition handelt (und von Anfang nicht um Komposition, sondern um Aggregation gehandelt hat). Wenn ein Teil von einem Ganzen existenzabhängig ist, aber in die Unabhängigkeit entlassen werden kann, ist es meines Erachtens eben nicht existenzabhängig vom Ganzen, da "existenzabhängig" eben genau bedeutet, dass etwas nicht unabhängig von etwas anderem existieren kann.

Ebenfalls glaube ich daher nicht, dass eine Kardinalität von 0 möglich ist: Ein Teil, das existenzabhängig vom Ganzen ist, kann zu keinem Zeitpunkt ohne sein Ganzes existieren. Auch das "Umhängen" von Teilen, die von einem Ganzen existenzabhängig sind, zu einem anderen Ganzen, erscheint mir nur bei Aggregation möglich zu sein. Der Artikel zu Komposition in der englischen Wikipedia sieht das übrigens ähnlich. Ich werde den deutschen Artikel daher mal anpassen.

Für den Fall, dass sich hier eine längere Diskussion entwickeln sollte: Generell bin ich bei modellierungstechnischen Fragen der Ansicht, dass ein vollständiges Modell der Welt unmöglich ist. Ich bin überzeugt, dass es möglich ist, die Beziehung zwischen zwei Dingen in einem Kontext als Aggregation und in einem anderen Kontext als Komposition betrachtet werden kann. Ich glaube, dass es wichtig ist, das bei einer Diskussion im Kopf zu behalten, insbesondere wenn man Beispiele sucht. Vermutlich lässt sich fast jedes Beispiel einer Beziehung zwischen zwei Dingen bei geeigneter Argumentation sowohl als Beispiel für Komposition als auch als Beispiel für Aggregation sehen: Ein Handyhändler könnte zwischen "Kamera des Handys" und "Handy" beispielsweise eine Komposition sehen (in seinem Kontext existieren Kameras immer nur als Teil eines Handys, wird dieses entsorgt, so wird automatisch auch die Kamera mit entsorgt), während ein Reparaturdienstleister diese Beziehung natürlich als Aggregation betrachten würde - schließlich ist er in der Lage, Kameras in Handys ein- und auszubauen und hat vermutlich zu jeder Zeit ein paar Kameras als Ersatzteile im Lager liegen. Ich denke, dass beide gleichermaßen Recht haben und ein Streit darüber, wofür sich dieses Beispiel eignet, einfach durch Einigung auf einen Kontext gelöst werden kann. --TuringTux (Diskussion) 18:37, 5. Mai 2019 (CEST)

Nicht nur UML

Ich finde das "(UML)" im Titel unschön, da es Assoziationen auch in der nicht OO Welt gibt. Sowohl Relationale und Hierachische Datenstrukturen kennnen eine Assoziation und man muss nicht mit UML Modellieren und Assoziationen zu haben. Ich fände "Assoziation (Informatik)" einen besseren Titel. Leider weiss ich nicht wie man in Wikipedia refaktoring macht. Gruss --Arcudaki 12:55, 5. Feb. 2008 (CET)

Da wär' ich eher für einen weiteren Artikel "Assoziation (Datenbank)" o.ä., hier geht's halt speziell um selbige in UML. --arilou (Diskussion) 10:32, 25. Mai 2012 (CEST)

Grafik Repository-Modell

Die Grafik ist IMHO fehlerhaft- die PropertyObjekte sind nicht unten den entsprechenden Assoziationsenden. (nicht signierter Beitrag von 84.175.66.25 (Diskussion) 09:01, 29. Okt. 2010 (CEST))

Raum ohne Gebäude?

rein mathematisch/logisch/physikalisch unlogisch!

lieber "Zimmer" nehmen ;) (nicht signierter Beitrag von 141.20.21.160 (Diskussion) 12:11, 18. Apr. 2011 (CEST))

Nur weil das Wort "Raum" noch andere Bedeutungen hat, muss man es ja nicht gleich meiden. Insbesondere da Raum hier besser passt. Ein Maschinenraum ist z.B. kein Zimmer. Man sollte die in der Anwendungsdomäne gebräuchlichen Begriffe verwenden... --Der Hâkawâti ✉ 18:57, 18. Apr. 2011 (CEST)

Unklare Definition

Ich habe ein gewisses Problem, den Satz "...im häufigsten Fall eine Verbindung zwischen zwei Objekten der Klassen" zu verstehen. Klassen in bestimmter Form heißt doch, dass sie schon vorher erwähnt wurden. Wäre nicht "zwei Instanzen von unterschiedlichen Klassen" besser? Sae1962 10:26, 31. Mai 2011 (CEST)

Ich hab mal den gesamten Abschnitt neu formuliert und dabei einige Unklarheiten und Fehler ausgebaut. Ist immer noch nicht perfekt, aber IMHO deutlich besser, als das bisherige. --Der Hâkawâti ✉ 14:17, 1. Jun. 2011 (CEST)

Kleine Dreiecke

"Die beiden kleinen Dreiecke unterstützen den Leser". Sind diese Dreiecke ein vorgesehener Bestandteil der Syntax von UML oder eine ergänzende Notation, die mit UML selbst nichts zu tun hat? Elektrolurch Kontakt 09:49, 23. Okt. 2013 (CEST)

Balzert, Helmut definiert es so im Lehrbuch für SW-Technik

1 Für eine Komposition gilt: � Es liegt eine Ist-Teil-von-Beziehung vor. � Die Multiplizität bei der Aggregatklasse beträgt 0..1 oder 1 (unshared aggregation, strong ownership). � Die Lebensdauer der Teile ist an die des Ganzen gebunden. Ein Teil darf jedoch zuvor explizit entfernt werden. � Die Funktionen des Ganzen werden automatisch auf seine Teile angewendet. � Muster bilden eine gute Orientierungshilfe (siehe »OOA-Muster«, S. 550). Dazu gehören � Liste (Bestellung – Bestellposition), � Baugruppe (Auto – Motor) und � Stückliste mit physikalischem Enthaltensein (Verzeichnis – Verzeichnis). 2 Für eine Aggregation gilt: � Es liegt eine Ist-Teil-von-Beziehung mit shared aggregation (ein Teilobjekt kann mehreren Aggregatobjekten zugeordnet werden) vor. � Sie ist selten. 3 Im Zweifelsfall immer eine einfache Assoziation verwenden.