Assoziation, Aggregation und Komposition

netrobot

ich habe neulich per programm C++ source code anhand klassendiagram generiert, um genau zu sehen, welche Unterschiede gibts unter den 3 Beziehungen.
4 Klassen:
Professor,
Student,
ProfessorHandle,
Mitarbeiter

Assozialtion zwischen Professor und Mitarbeiter(Pfeil auf Mitarbeiter)
Generation:

class Professor
{
  Mitarbeit *OneMitarbeit;
}

Aggregation zwischen Professor und Student(Pfeil auf Student)
Generation:

class Professor
{
  Student *OneStudent;
}

Komposition zwischen Professor und ProfessorHandle(Pfeil auf ProfessorHandle)

class Professor
{
  ProfessorHandle handle;
}

d.h. Assoziation und Aggregation sind gleich, aber wenn ich in dem D'tor den Pointer lösche, es ist wieder eine Komposition, nur mann kann zur Laufzeit den Zeiger auf verschiedene Objekte zeigen(polymophie). Aber bei der Kompostion ist das Object von vorne rein fest.

verstehe ich es richtig?

norman_timo

Hallo netrobot,

also eine Assoziation ist im Grunde lediglich irgend eine Beziehung zwischen Objekten, die zunächst nicht näher spezifiziert ist. Als Beziehung kann es eine Komposition oder eine Aggregation geben.

Der einzige Unterschied scheint nur in der Menge der "benutzten" Partner zu sein. Also eine Komposition hat nur einen "Partner", eine Aggregation kann mehrere "Partner" haben.

Detaiilierter beschrieben findest Du es auch unter WikiPedia:

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

Dass eine Assoziation automatisch mit einer Aggregation verwirklicht wird, das wird wohl von dem Generator festgelegt sein.

Gruß
Norman-Timo

Ich versuchs mal so:

Eine Assoziation ist eine "kennt"-Beziehung. Die brauchts nicht unbedingt, und sie ist für keines der Objekte von großer Bedeutung. Sie kennen einander halt. Sagen wir: Der Hut eines Studenten. Der Prof hat ihn gesehen und wahrgenommen, im Wesentlichen ist er ihm aber egal.

Eine Aggregation ist eine "kann eins haben"-Beziehung. Ein Professor kann mehrere Studenten haben. Das ist normalerweise auch Standard, wenn es keinen Studenten gibt, muss man Vorsicht walten lassen (nachsehen, ob des Rektorat besetzt ist), aber im Notfall kann der Prof auch ohne.

Eine Komposition ist eine "hat ein / enthält ein" Beziehung. Der Professor hat ein Herz. Wenn die Lebensspanne des Herzens erreicht ist, stirbt auch der Professor. Das Herz ist essentieller, unverzichtbarer Bestandteil des Professors.

Das ist eine sehr abstrakte Erklärung, das gebe ich zu. Und sie ist auch nicht 100% exakt.

Das Problem ist: Die UML definiert diese drei Beziehungsarten sehr genau. Aber sprich mit 4 UML-Tutoren und du bekommst 4 Antworten.

Der einzige Unterschied scheint nur in der Menge der "benutzten" Partner zu sein. Also eine Komposition hat nur einen "Partner", eine Aggregation kann mehrere "Partner" haben.

Falsch. Eine Komposition ist eine Spezialform der Aggregation. Komposita liegt vor, wenn die Lebenszeit der assoziierten Instanz an die des Objekts gebunden ist. Beispiel: Bei der Assoziation Auto <--> Rad handelt es sich um eine Aggregation. Das Rand kann beliebig Ausgetauscht werden. Wird das Auto verschrottet, bedeutet das aber _nicht_, dass auch das Rad entsorgt wird. Zweites Beispiel: Die Beziehung Baum <--> Blatt ist eine Komposition. Ein Blatt existiert nicht ohne Baum.

CStoll

lucky_tux schrieb:

Ein Blatt existiert nicht ohne Baum.

Bist du sicher Meine Erinnerungen an den letzten Herbst sagen das Gegenteil.

@ CStoll:

Ok. Stimmt da gib ich dir recht. Sagen wir ein Blatt kann nicht ohne Baum leben. Theoretisch sollte das so sein

CStoll schrieb:

lucky_tux schrieb:

Ein Blatt existiert nicht ohne Baum.

Bist du sicher Meine Erinnerungen an den letzten Herbst sagen das Gegenteil.

Das Blatt wartet nur auf den Garbage Collector

CStoll

Hey, wir reden hier von C++, da gibt es keinen Garbage Collector

THX 1138

Darum liegt das Laub noch im Frühling im Wald am Boden

JDHawk

Muss bei diesen alten Thread nochmal nachhaken sorry.

Also nochmal:

Komposition: das assoziierte Objekt ist an das Objekt gebunden, und sirbt mit ihm.
Aggregation: das assoziierte Objekt ist auch ohne das Objekt lebensfähig.

Ok im UML Klassendiagramm kann man die entsprechenden Pfeilchen mit schwarzen oder weissen Viereck an der Spitze nehmen usw.

Meine Frage: Wie ist das in der Implementierung gedacht. Sagen wir in C++:
gilt dann folgendes:
Komposition: Vererbung? (Da sterben ja die abgeleiteten Klassen auch wenn die Basisklasse stirbt.) Nur für Vererbung gibt es ja das "realize"-Pfeilchen, das ist es also nicht. Bei welcher Beziehung stirbt denn sonst das andere Objekt mit?

Aggregation: Zeiger auf ein Obj einer anderen Klasse? Dann kann ja das andere Objekt immer noch weiterleben auch wenn die eine stirbt.

Kann das jemand erklären bitte

CStoll

JDHawk schrieb:

Komposition: Vererbung? (Da sterben ja die abgeleiteten Klassen auch wenn die Basisklasse stirbt.) Nur für Vererbung gibt es ja das "realize"-Pfeilchen, das ist es also nicht. Bei welcher Beziehung stirbt denn sonst das andere Objekt mit?

Element-Beziehung:
[cpp]class komposition
{
string element;
};

Aggregation: Zeiger auf ein Obj einer anderen Klasse? Dann kann ja das andere Objekt immer noch weiterleben auch wenn die eine stirbt.

Entweder Zeiger oder auch Referenzen.

JDHawk

Stimmt das Objekt string würde ja mitsterben, danke.
Wenn wir schon beim Thema UML sind, hab ich eine Frage, wenn ich darf:

Ich schreibe eine C++ Anwendung, die Daten mit einer C Anwendung austauscht.
Kann ich irgendwie meine C Funktionen auch ins Klassendiagramm miteinmodellieren?
Beide Anwenungen tauschen ja miteinenader Daten aus.

Ich weis sehr dumme Frage aber ist halt blöd wenn ich nur die C++ Seite im Klassendiagramm vorstellen kann. :p

CStoll

Das wird schwierig - UML ist für die Darstellung von objektorientierten Strukturen vorgesehen. Du könntest den Anteil "C Anwendung" eventuell als eigenständige Klasse darstellen und die C Funktionen als Member dieser Klasse.

(btw, ist es überhaupt nötig, jeden sch*** in UML zu quetschen?)

JDHawk

Danke für den Tip.

Eine Frage noch:

Wenn ich über einen Zeiger ein Objekt dyn mit "new" erzeuge und es im Destruktor mit "delete" explizit sterben lasse, habe ich eine Komposition erzwungen oder?

Einfach gesagt ja.

Es ist nicht so ganz einfach in C++ Assoziation, Aggregation und Komposition auseinander zu halten, weil C++ diese Beziehungsarten in der Form nicht kennt und man die Eigenschaften selbst nachprogrammieren muss.
So kann eine Assoziation, eine Aggregation als auch eine Komposition mit Hilfe eines Zeigers abgebildet sein. Erst die Art wie der Pointer verwaltet wird definiert um welche Beziehung es sich handelt.