Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
1 Einleitung
2 Die Basis der Objektorientierung
3 Die Prinzipien des objektorientierten Entwurfs
4 Die Struktur objektorientierter Software
5 Vererbung und Polymorphie
6 Persistenz
7 Abläufe in einem objektorientierten System
8 Module und Architektur
9 Aspekte und Objektorientierung
10 Objektorientierung am Beispiel: Eine Web-Applikation mit PHP 5 und Ajax
A Verwendete Programmiersprachen
B Literaturverzeichnis
Stichwort
Ihre Meinung?

Spacer
 <<   zurück
Objektorientierte Programmierung von Bernhard Lahres, Gregor Rayman
Das umfassende Handbuch
Buch: Objektorientierte Programmierung

Objektorientierte Programmierung
2., aktualisierte und erweiterte Auflage, geb.
656 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1401-8
Pfeil 4 Die Struktur objektorientierter Software
  Pfeil 4.1 Die Basis von allem: das Objekt
    Pfeil 4.1.1 Eigenschaften von Objekten: Objekte als Datenkapseln
    Pfeil 4.1.2 Operationen und Methoden von Objekten
    Pfeil 4.1.3 Kontrakte: Ein Objekt trägt Verantwortung
    Pfeil 4.1.4 Die Identität von Objekten
    Pfeil 4.1.5 Objekte haben Beziehungen
  Pfeil 4.2 Klassen: Objekte haben Gemeinsamkeiten
    Pfeil 4.2.1 Klassen sind Modellierungsmittel
    Pfeil 4.2.2 Kontrakte: die Spezifikation einer Klasse
    Pfeil 4.2.3 Klassen sind Datentypen
    Pfeil 4.2.4 Klassen sind Module
    Pfeil 4.2.5 Sichtbarkeit von Daten und Methoden
    Pfeil 4.2.6 Klassenbezogene Methoden und Attribute
    Pfeil 4.2.7 Singleton-Methoden: Methoden für einzelne Objekte
  Pfeil 4.3 Beziehungen zwischen Objekten
    Pfeil 4.3.1 Rollen und Richtung einer Assoziation
    Pfeil 4.3.2 Navigierbarkeit
    Pfeil 4.3.3 Multiplizität
    Pfeil 4.3.4 Qualifikatoren
    Pfeil 4.3.5 Beziehungsklassen, Attribute einer Beziehung
    Pfeil 4.3.6 Implementierung von Beziehungen
    Pfeil 4.3.7 Komposition und Aggregation
    Pfeil 4.3.8 Attribute
    Pfeil 4.3.9 Beziehungen zwischen Objekten in der Übersicht
  Pfeil 4.4 Klassen von Werten und Klassen von Objekten
    Pfeil 4.4.1 Werte in den objektorientierten Programmiersprachen
    Pfeil 4.4.2 Entwurfsmuster »Fliegengewicht«
    Pfeil 4.4.3 Aufzählungen (Enumerations)
    Pfeil 4.4.4 Identität von Objekten


Rheinwerk Computing - Zum Seitenanfang

4.3 Beziehungen zwischen Objekten  Zur nächsten ÜberschriftZur vorigen Überschrift

In Abbildung 4.10 haben wir bereits eine ganze Reihe von Beziehungen zwischen handelnden Personen der griechischen Mythologie dargestellt. Dabei haben Sie gesehen, dass Objekte in den unterschiedlichsten Beziehungen zueinander stehen können.

Wenn man in der objektorientierten Welt von Beziehungen spricht, unterscheidet man grundsätzlich drei Arten von Beziehungen:

Beziehungen zwischen Klassen und Objekten

  • Beziehungen zwischen Klassen und Objekten Eine solche Beziehung, die Klassifizierung, haben wir in Abschnitt 4.2.1 kennengelernt. Die Klassifizierung beschreibt eine Beziehung zwischen einer Klasse und ihren Exemplaren. Das Objekt Plato steht zum Beispiel in so einer Beziehung mit der Klasse Mann, denn Plato ist ein Mann (oder auch ein Exemplar der Klasse Mann). In Abbildung 4.21 sehen Sie diese Beziehung an Markierung .

Beziehungen zwischen Klassen

  • Beziehungen zwischen Klassen untereinander Weil Plato ein Mann ist, und ein Mann eine Person, ist Plato sterblich, denn jede Person ist sterblich. Es besteht also eine Beziehung zwischen der Klasse der sterblichen Objekte und der Klasse Person – die Klasse Person ist eine Unterklasse der Klasse Sterblich. Und da jeder Mann eine Person ist, ist die Klasse Person eine Oberklasse der Klasse Mann. In Abbildung 4.21 wird dieser Zusammenhang an Markierung dargestellt.
    • Den Beziehungen zwischen den Ober- und Unterklassen werden wir uns in Abschnitt 5.1.1, »Hierarchien von Klassen und Unterklassen«, widmen.

Beziehungen zwischen Objekten

  • Beziehungen zwischen Objekten untereinander Aristoteles hatte einen Lehrer, Plato, und einen bekannten Schüler, Alexander den Großen. Dies sind Beispiele einer Beziehung zwischen konkreten Objekten, denen wir uns jetzt widmen werden. In Abbildung 4.21 sehen Sie diese Beziehungen an den Markierungen und .

Abbildung 4.21    UML-Darstellung der Beziehungen von Aristoteles

Assoziation, Aggregation und Komposition

Beziehungen zwischen verschiedenen Objekten werden ganz allgemein auch Assoziation genannt. [Obwohl in UML eine Assoziation als eine Linie zwischen den Klassenkästchen dargestellt wird, ist eine Assoziation eine Beziehung zwischen Objekten – den Exemplaren dieser Klassen. Ein Beispiel einer Beziehung zwischen Klassen wäre die Generalisierung, der wir uns in Abschnitt 5.1.1, »Hierarchien von Klassen und Unterklassen«, widmen werden. ] Außerdem gibt es spezielle Formen von Assoziationen.

Beziehungen zwischen einem Objekt und seinen Teilen werden Aggregation beziehungsweise Komposition genannt. Die Unterscheidung zwischen Aggregation und Komposition ist recht subtil und hängt häufig nur von der Betrachtungsweise des Entwicklers ab. Wir werden uns der Aggregation und der Komposition in Abschnitt 4.3.8 näher widmen.

Assoziationen zwischen Objekten

Schauen wir uns im Folgenden an, was wir über die Assoziationen zwischen Objekten sagen können.

Eine Assoziation hat immer eine semantische Bedeutung. Zwei oder mehrere Objekte können zueinander in verschiedenen Beziehungen stehen. So wie im Leben zwei Menschen in der Beziehung Elternteil – Kind und unabhängig davon in der Beziehung Lieferant – Kunde zueinander stehen können. [Wir werden uns in diesem Buch nicht allen Details der Fähigkeiten der UML widmen, eine tiefer gehende Beschreibung können Sie in [Kecher 2006] finden. ]


Assoziationen in UML

In UML-Klassendiagrammen werden mögliche Assoziationen zwischen Exemplaren von zwei Klassen als eine Linie zwischen den Klassenkästchen dargestellt. Besteht die Beziehung zwischen Exemplaren genau einer Klasse, wird sie durch eine Linie dargestellt, die in dem Kästchen der Klasse sowohl beginnt als auch endet.

Wenn man in einem UML-Diagramm einzelne Objekte darstellt, kann man eine existierende Beziehung zwischen diesen Objekten als eine Linie zwischen den Objektkästchen darstellen. Eine solche Darstellung einer existierenden Beziehung zwischen zwei einzelnen Objekten nennt man einen Link.

Die Bedeutung der Beziehung wird meistens durch den Namen der Beziehung ausgedrückt. In UML wird der Name der Beziehung als Text in der Nähe der Linie dargestellt.



Rheinwerk Computing - Zum Seitenanfang

4.3.1 Rollen und Richtung einer Assoziation  Zur nächsten ÜberschriftZur vorigen Überschrift

Die Beziehungen zwischen Objekten sind meistens nicht symmetrisch, das heißt, dass jedes Objekt eine unterschiedliche Rolle in der Beziehung einnimmt. Wir können sagen, dass Zeus auf dem Olymp wohnt, nicht aber der Olymp auf dem Zeus. Die Bezeichnung einer Beziehung hat also eine Richtung.


Rollen in UML

In UML-Klassendiagrammen15  werden die Rollen der Objekte als Text in der Nähe der jeweiligen Klasse angegeben. Die Leserichtung der Bezeichnung der Beziehung wird durch ein kleines Dreieck angegeben.


Abbildung 4.22    Rolle und Richtung einer Assoziation


Rheinwerk Computing - Zum Seitenanfang

4.3.2 Navigierbarkeit  Zur nächsten ÜberschriftZur vorigen Überschrift

Eine weitere wichtige Eigenschaft einer Beziehung ist ihre Navigierbarkeit. Nehmen wir an, es besteht eine Assoziation schickt Werbung zwischen den Exemplaren der Klasse Firma und der Klasse Person. Die Firma kann alle Personen auflisten, denen sie Werbung zuschickt. Eine Person hat aber keine Liste der Firmen, die sie mit Werbung belästigen. Wir sagen, dass die Assoziation schickt Werbung in der Richtung Firma-Person navigierbar ist, nicht jedoch in der Richtung Person-Firma. Die Navigierbarkeit wird meistens in den Designmodellen angegeben, in den Analysemodellen spielt die Navigierbarkeit selten eine Rolle.

Abbildung 4.23    Navigierbarkeit einer Assoziation


Navigierbarkeit in UML

In UML wird eine Beziehung, die nur in einer Richtung navigierbar ist, durch einen Pfeil an dem Ende, zu dem wir navigieren können, angezeigt. Ist eine Beziehung in beide Richtungen navigierbar, wird dies meistens durch die Abwesenheit der Pfeile dargestellt, es ist aber auch möglich, einen Doppelpfeil zu verwenden.



Rheinwerk Computing - Zum Seitenanfang

4.3.3 Multiplizität   Zur nächsten ÜberschriftZur vorigen Überschrift

Die Multiplizität einer Beziehung sagt aus, wie viele Objekte des jeweiligen Typs in dieser Beziehung stehen können.

Icon Beispiel Dateien im Dateisystem

Nehmen Sie zum Beispiel ein Modell für ein einfaches Dateisystem, in dem jede Datei immer in genau einem Verzeichnis liegt. Ein Verzeichnis kann aber leer sein, oder es kann eine oder mehrere Dateien enthalten. Der Bereich für die mögliche beziehungsweise nötige Anzahl der Objekte in einer solchen Beziehung wird als die Multiplizität dieser Beziehung bezeichnet.


Icon Hinweis Multiplizität

Die Multiplizität einer Beziehung zwischen Klassen legt die mögliche Anzahl der an der Beziehung beteiligten Exemplare fest.

Dabei sprechen wir von der Multiplizität einer Rolle in der Beziehung, wenn wir nur eine der beteiligten Klassen sowie deren Rolle in der Beziehung betrachten.

In UML wird die Multiplizität einer Klasse in einer Beziehung als eine Auflistung der möglichen Anzahl von Exemplaren angegeben. Diese Angabe wird einfach in der Nähe des einen Endes der Beziehung bei der betroffenen Klasse dargestellt. Intervalle werden als »min .. max« angegeben. Ein Stern bedeutet dabei »beliebig viele«. Das Intervall »0..*« kann also auch als »*« angegeben werden.

Neben den Multiplizitäten in einer Beziehung gibt es auch noch die reine Multiplizität einer Klasse. Diese legt fest, wie viele Exemplare dieser Klasse überhaupt existieren können oder müssen. So ist die Multiplizität einer Singleton-Klasse16 in der Regel 0 ... 1, das heißt es kann maximal ein Exemplar davon existieren.


In Abbildung 4.24 wird das Konzept der Multiplizität und deren Darstellung in UML verdeutlicht.

An Markierung ist eine Assoziation liegt in zwischen Exemplaren der Klasse Stadt und der Klasse Land dargestellt. Die Assoziation wird durch eine Linie repräsentiert, die an der Klasse Stadt anfängt und an der Klasse Land endet. Eine Stadt liegt nach unserem Modell in genau einem Land. In einem Land muss es mindestens eine Stadt geben, nach oben ist die Zahl der Städte aber unbegrenzt. Damit ist die Multiplizität der Rolle Stadt in der beschriebenen Beziehung 1..*, die Multiplizität der Rolle Land ist genau 1. Die Multiplizität der gesamten Beziehung liegt in ist damit 1..* zu 1.

Abbildung 4.24    Mehrwertige Beziehungen in UML

Ein weiteres Beispiel ist die Beziehung Elternteil-Kind, die an Markierung von Abbildung 4.24 dargestellt ist. Diese Beziehung besteht zwischen Exemplaren der Klasse Person. Solche Beziehungen zwischen Exemplaren derselben Klasse werden reflexiv genannt. Die Multiplizität der Rolle Kind ist * (also beliebig viele), denn es gibt Menschen, die keine Kinder haben, und Menschen, die ein oder mehrere Kinder haben. Wie sieht es aber mit der Multiplizität der Rolle Elternteil aus? Wenn wir zum Beispiel eine genealogische Anwendung schreiben, würde man spontan sagen, dass sie 2 ist, denn jeder Mensch hat genau eine biologische Mutter und genau einen biologischen Vater. In der Abbildung sehen Sie aber, dass die Multiplizität der Rolle Elternteil als 0..2 modelliert ist.

Dies liegt daran, dass Sie in der praktischen Verwendung der Beziehung in ein logisches Problem laufen, wenn Sie für jede Person fordern, dass auch die zugehörigen Eltern bekannt sein sollen. Da für jeden eingefügten Elternteil (auch wieder eine Person) gefordert würde, dass auch für diesen bereits die Eltern bekannt sind, kommen Sie beim Versuch, einen konsistenten Datenbestand zu erstellen, in eine nicht terminierende Rekursion. Deshalb wird die Beziehung so modelliert, dass zu einer Person die Eltern auch einfach unbekannt sein können, also die Rolle Elternteil die Multiplizität 0..2 erhält.

Mögliche Multiplizitäten

Im Beispiel haben Sie bereits einige der möglichen Multiplizitäten gesehen. Am häufigsten werden Sie in Modellen auf Beziehungen mit folgenden Multiplizitäten treffen:

Ein Objekt steht in einer Beziehung mit

  • genau einem anderen Objekt.
  • keinem oder einem anderen Objekt.
  • mindestens einem anderen Objekt.
  • beliebig vielen anderen Objekten.

Es kann aber durchaus Beziehungen mit anderen Multiplizitäten geben. Zum Beispiel in der Beziehung Tennismatch-Spieler, die ebenfalls in Abbildung 4.24 dargestellt ist, ist die Multiplizität der Spieler zwei oder vier.


Kardinalität und Multiplizität

In UML wird klar zwischen der Multiplizität und der Kardinalität einer Beziehung unterschieden: Die Multiplizität legt die möglichen Kardinalitäten einer Beziehung fest, meist indem die minimale und maximale Kardinalität angegeben wird.

Die tatsächliche Kardinalität einer Beziehung kann nur für konkret bekannte Objekte angegeben werden. So gibt es in Deutschland zum Beispiel genau 2076 Städte. Die Kardinalität der Rolle Stadt in dieser Beziehung wäre also 2076. Die zugehörige Multiplizität der Rolle ist aber 1..*. Diese beschreibt einfach die möglichen Kardinalitäten, von denen die 2076 eben auch eine ist.

Die begriffliche Trennung zwischen Multiplizität und Kardinalität ist nicht immer so klar, wie sie innerhalb der UML definiert wird. Insbesondere bei den im Bereich der relationalen Datenbanken verwendeten Modellen (z. B. Entity-Relationship-Diagramme) wird der Begriff der Kardinalität häufig analog zur Multiplizität in UML verwendet17.


Mehrwertige Beziehungen

Wenn die obere Schranke der Multiplizität einer Beziehung größer als 1 ist (z. B. *), die Beziehung also mehrwertig ist, können wir uns Gedanken über die Struktur der Objekte am mehrwertigen Ende der Beziehung machen. Wenn die Objekte in dieser Beziehung eine definierte Reihenfolge haben, sagt man, dass die Beziehung geordnet ist.

Eine weitere Frage, die wir uns stellen können, ist die Frage, ob ein Objekt in der Beziehung mehrfach aufgelistet sein kann. Ein Team kann aus mehreren Spielern bestehen, ein konkreter Spieler kann aber nicht mehrfach in einem Team auftauchen. Eine Reiseroute kann durch mehrere Städte führen, dabei kann eine Stadt in einer Route mehrfach durchlaufen werden.

Mehrwertige Beziehungen als Menge

Wenn nichts Abweichendes angegeben ist, verstehen wir eine mehrwertige Beziehung üblicherweise als eine Menge (englisch Set) ohne definierte Ordnung, in der ein Objekt nur einmal auftreten kann. Ist die Reihenfolge definiert, gilt für die Beziehung die Einschränkung {ordered} oder {ordered set}, je nachdem, ob ein Objekt mehrfach auftreten kann. Es gibt auch den Fall, in dem ein Objekt zwar mehrfach auftreten kann, die Ordnung aber trotzdem keine Rolle spielt. Diese Art der Beziehung wird im Englischen als Bag, im Deutschen als Korb bezeichnet. Ein Beispiel einer solchen Beziehung wäre die Liste der Abonnenten einer Zeitschrift, wenn der Verlag kein Aussortieren von Dubletten vorgenommen hat. Ein Kunde kann eine Zeitschrift mehrfach abonniert haben, die Reihenfolge, in der die Zeitschrift versendet wird, spielt aber keine Rolle.


Einschränkungen von Beziehungen in UML

In UML können auch andere Informationen bei einer Beziehung angegeben werden. Die Einschränkungen werden in geschweiften Klammern angegeben. Neben den Einschränkungen {ordered} oder {bag} kann man zum Beispiel angeben, ob eine Beziehung azyklisch ist oder eine Hierarchie abbildet.


Abbildung 4.25    Zusatzinformationen zu Beziehungen in UML


Rheinwerk Computing - Zum Seitenanfang

4.3.4 Qualifikatoren  Zur nächsten ÜberschriftZur vorigen Überschrift

Manchmal kann man über die Multiplizität einer Beziehung eine genauere Aussage treffen. Zum Beispiel kann ein Mensch im Laufe seines Lebens mehrere Ehepartner haben. Doch zu einem Zeitpunkt, zumindest in unserem Kulturkreis, kann ein Mensch höchstens einen Ehepartner haben. Ein anderes Beispiel ist die Beziehung zwischen einer Firma und ihren Kunden. Eine Firma kann viele Kunden haben, aber durch eine Kundennummer kann sie einen ihrer Kunden eindeutig identifizieren. Pro Kundennummer hat eine Firma also genau einen Kunden.

Diese Informationen über die Multiplizität einer mehrwertigen Beziehung können wir durch die Angabe der Qualifikatoren ausdrücken. Mithilfe eines Qualifikators kann man aus vielen Objekten an einem mehrwertigen Ende einer Beziehung bestimmte Objekte auswählen.

Abbildung 4.26    Qualifikatoren der Beziehungen in UML

In der Beziehung Ehe ist zum Beispiel ein Zeitpunkt ein Qualifikator, der es uns ermöglicht, einen konkreten Ehepartner eines mehrmals verheirateten Menschen genau zu bestimmen. Die Kundennummer ist wiederum ein solcher Qualifikator in der Beziehung zwischen einer Firma und seinen Kunden.


Qualifikatoren in UML

In UML-Diagrammen werden die Qualifikatoren als Kästchen an dem Ende der Beziehung dargestellt, von dem wir mit Hilfe des Qualifikators navigieren. Die Namen der Qualifikatoren können entweder im Kästchen oder in seiner Nähe angegeben werden. Am anderen Ende der Beziehung gibt man dann die Multiplizität der qualifizierten Beziehung an.



Rheinwerk Computing - Zum Seitenanfang

4.3.5 Beziehungsklassen, Attribute einer Beziehung  Zur nächsten ÜberschriftZur vorigen Überschrift

Schauen wir uns jetzt die Beziehung Job zwischen den Klassen Person und Firma an.

Abbildung 4.27    Beziehungsklasse in UML

Es gibt Personen ohne Job, eine Person kann aber auch mehrere Jobs haben. Eine Firma hat (zumindest in unserem Modell) immer mindestens einen Beschäftigten, sei es der Unternehmer selbst. Die Multiplizität der Rolle Arbeitgeber ist also 0..*, die der Rolle Arbeitnehmer 1..*.

Obwohl die Reihenfolge der Mitarbeiter keine Rolle spielt und wir deswegen die Beziehung in Richtung Firma-Person als eine Menge (Set) modelliert haben, ist es doch wichtig zu wissen, welche Funktion ein Mitarbeiter in einer Firma hat. Und wichtig ist auch, zumindest für die meisten von uns, die in einer solchen Beziehung stehen, wie hoch das Gehalt [Wir meinen hier sowohl die Löhne als auch die Gehälter. ] eines Menschen in einer Firma ist.

Welcher Klasse können wir diese Informationen zuordnen? Offensichtlich können wir die Attribute Funktion und Gehalt nicht der Klasse Firma zuordnen, denn dann müssten alle Mitarbeiter die gleiche Funktion haben und dasselbe Gehalt verdienen.

Würden wir diese Attribute der Klasse Person zuordnen, könnte zwar jeder Mitarbeiter eine eigene Funktion und sein eigenes Gehalt haben, allerdings müssten die Funktion und sein Gehalt bei jeder Firma gleich sein. Außerdem hätten diese Attribute bei einem Menschen ohne Job keine Bedeutung. [Würden wir ein Personalverwaltungssystem für einen Arbeitgeber entwickeln, könnten wir durchaus die Attribute Funktion und Gehalt der Klasse Mitarbeiter zuordnen. Ein Mensch kann zwar mehrere Jobs haben, für unser System wäre dies aber nicht relevant. Die Jobs, die ein Mitarbeiter bei anderen Firmen hat, würden wir nicht verwalten. ]

Assoziationsklasse

Die Lösung unserer Aufgabe ist, die Attribute weder der Klasse Firma noch der Klasse Person zuzuordnen, sondern der Beziehung Job selbst. In diesem Falle spricht man von einer Assoziationsklasse oder auch einer Beziehungsklasse.


Assoziationsklassen in UML

In UML wird eine Assoziationsklasse als eine Klasse dargestellt, die mit einer gestrichelten Linie mit der Linie der Beziehung verbunden wird.

Eine Assoziationsklasse können wir immer auch als eine normale Klasse modellieren. Es ist eine Frage der Verständlichkeit der Modelle, für welche Alternative man sich entscheidet. Eine mögliche Alternative ist in Abbildung 4.28 dargestellt.


Abbildung 4.28    Alternative Darstellung einer Beziehungsklasse


Rheinwerk Computing - Zum Seitenanfang

4.3.6 Implementierung von Beziehungen  Zur nächsten ÜberschriftZur vorigen Überschrift

Beziehungen unterscheiden sich unter anderem durch ihre Multiplizität, ihre Navigierbarkeit; die mehrwertigen können geordnet oder ungeordnet sein; ein Objekt kann einmal oder mehrfach auftreten. Es gibt also sehr viele Varianten von Beziehungen. Aus diesem Grunde findet man in den gängigen Programmiersprachen keine speziellen Konstrukte für die Umsetzung der Beziehungen.

Umsetzung von Beziehungen

Stattdessen verwendet man bei einwertigen Beziehungen in dem Objekt, von dem die Beziehung navigierbar ist, meistens Zeiger oder Referenzen, die zu dem anderen Objekt zeigen.

Eine beidseitig navigierbare Beziehung wird am häufigsten implementiert durch zwei Zeiger oder Referenzen, die programmtechnisch synchron gehalten werden müssen.

Die mehrwertigen Beziehungen werden auf verschiedene Arten umgesetzt. Verwendet werden Arrays, Listen, Mengen oder andere Containerkonstrukte, die in der jeweiligen Programmiersprache vorhanden sind oder die man selbst implementiert.

Beziehungsklassen werden als gewöhnliche Klassen implementiert.

Listing 4.12 stellt die Umsetzung von verschiedenen Beziehungen in Java dar. Wir zeigen dabei eine mögliche Umsetzung einer beidseitig navigierbaren Mengenbeziehung Person–Adresse. Eine Person kann mehrere Adressen haben, und unter einer Adresse kann man mehrere Personen finden.

class Person { 
  private Set<Address> addresses = new HashSet<Address>(); 
  // Hier verwalten wir eine Richtung der Beziehung 
  // Person-Address: 
  public void addAddress(Address address) { 
    if (addresses.contains(address)) return; 
    adresses.add(address); 
    address.addPerson(this); // die andere Richtung pflegen 
  } 
  ... 
} 
 
class Address { 
private Set<Person> people = new HashSet<Person>(); 
  // Hier verwalten wir eine Richtung der Beziehung 
  // Person-Address: 
  public void addPerson(Person person) { 
    if (people.contains(person)) return; 
    people.add(person); 
    person.addAddress(this); // die andere Richtung pflegen 
  } 
  ... 
}

Listing 4.12    Abbildung von Beziehungen auf Klassen


Rheinwerk Computing - Zum Seitenanfang

4.3.7 Komposition und Aggregation  Zur nächsten ÜberschriftZur vorigen Überschrift

Bisher haben wir uns die Beziehungen zwischen verschiedenen Objekten angeschaut. Doch ein Objekt selbst kann eine komplexe Struktur besitzen, und wir können die Beziehungen zwischen dem Objekt und seinen Teilen modellieren. Dabei unterscheiden wir zwischen Komposition und Aggregation.

Sowohl die Komposition als auch die Aggregation sind Teil-von- bzw. Besteht-aus-Beziehungen. Wir können zum Beispiel modellieren, dass eine Bestellung aus den Bestellungsposten oder dass eine Fußballmannschaft aus ihren Spielern besteht.

Unterschied Aggregation –Komposition

Eine Aggregation unterscheidet sich von einer Komposition

  • in der Anzahl der zusammengesetzten Objekte, deren Teil ein Objekt sein kann, und
  • in der Lebensdauer der zusammengesetzten Objekte und deren Teile.

Icon Hinweis Aggregation

Von einer Aggregation sprechen wir, wenn ein Objekt ein Teil von mehreren zusammengesetzten Objekten sein kann. Die zusammengesetzten Objekte nennen wir in diesem Fall Aggregate. Die Lebensdauer der Teile kann dabei länger sein als die Lebensdauer der Aggregate.


Ein Beispiel für eine Aggregation ist die Beziehung zwischen einer Mannschaft und ihren Spielern. Ein Mensch kann in mehreren Mannschaften spielen, und wird eine Mannschaft aufgelöst, bedeutet es in den allermeisten Fällen nicht das Ende für ihre Ex-Spieler.


Icon Hinweis Komposition

Bei einer Komposition kann ein Teil immer nur in genau einem zusammengesetzten Objekt enthalten sein, und die Lebensdauer des zusammengesetzten Objekts entspricht immer der Lebensdauer seiner Komponenten. Das zusammengesetzte Objekt wird hier als Kompositum bezeichnet.


Ein Beispiel für eine Komposition ist die Beziehung zwischen einer Bestellung und den einzelnen Posten der Bestellung. Ein Bestellungsposten gehört in genau eine Bestellung, und wird die Bestellung gelöscht, löscht man automatisch auch alle ihre Posten.


Komposition und Aggregation in UML

Bei der Modellierung kommt es häufig vor, dass eine Klasse die Rolle Teil in mehreren Kompositionsbeziehungen spielt. Jedes Exemplar dieser Klasse kann aber immer nur in einer solchen Beziehung stehen. In den Modellen kann man diese Beziehungen mit der Bedingung {xor} auszeichnen.

Sind die Beziehungen nur in der Richtung Kompositum-Komponente navigierbar, ist die explizite Angabe der Bedingung {xor} meistens nicht notwendig.

In den Klassendiagrammen in UML wird die Aggregation durch eine leere Raute am Ende des Aggregats dargestellt. Die Komposition wird durch eine ausgefüllte Raute am Ende des Kompositums dargestellt.


Abbildung 4.29    Aggregation und Komposition in UML

Alternativ kann man die Komposition auch darstellen wie in Abbildung 4.30 gezeigt.

Abbildung 4.30    Verschiedene alternative Darstellungen der Komposition

Einsatz von Komposition und Aggregation

Die Entscheidung, ob wir eine Beziehung als eine Aggregation, eine Komposition oder als einfache Assoziation modellieren sollten, ist oft schwierig, weil es keine festen Regeln gibt, nach denen wir unterscheiden können, welche der Möglichkeiten die geeignete ist. Die semantische Bedeutung ist in UML nur vage definiert, man spricht von einem Modellierungsplacebo. Wie wir aber wissen, Placebos wirken. Versuchen wir also ein paar Richtlinien aufzustellen, die uns bei der Entscheidung helfen, welche Variante wir einsetzen sollen.

Hierarchie

Durch die Verwendung der Komposition lässt sich sehr gut ausdrücken, dass eine Beziehung zwischen den Objekten derselben Klasse hierarchisch ist. Gute Beispiele hierfür sind Organigramme oder Dateisysteme.

Lebensdauer und Persistenz

Eine andere Information, die sich durch die Modellierung einer Komposition ausdrücken lässt, ist das Verhalten der Objekte beim Löschen oder beim Speichern des Kompositums. Da das Kompositum aus Teilen besteht, die nur als Teile des Kompositums existieren, werden sie mit dem Kompositum gelöscht beziehungsweise gespeichert. Diese Semantik betrifft jedoch die dynamischen Aspekte der Modelle, und die Klassendiagramme sind für die Darstellung der statischen Sachverhalte vorgesehen.

Datenstruktur

Eine sinnvolle Verwendung einer Komposition ist die Modellierung der Klassen in C++. Dort wird die Struktur des Speichers, in dem die Daten eines Objekts gehalten werden, explizit ausprogrammiert. Ob ein Objekt seine Teile direkt enthält oder ob es Zeiger auf andere Speicherbereiche enthält, ist eine Tatsache, die man hervorragend mit der Verwendung der Komposition ausdrücken kann. Dies ist jedoch keine allgemeine Vorgabe von UML, es ist nur ein Vorschlag, dem man bei der grafischen Darstellung der C++-Klassen in einem UML-Klassendiagramm folgen kann.

Diskussion: Komposition und Aggregation

Bernhard: Wie entscheide ich denn nun konkret, ob ich eine Beziehung als Komposition, Aggregation oder einfach als Assoziation modelliere?

Gregor: Einige Hinweise haben wir ja schon gegeben. Vor allem das technische Kriterium, ob die referenzierten Bestandteile mit einem anderen Objekt zusammen gelöscht werden sollen, deutet stark auf eine Komposition hin.

Bernhard: Und wenn sich das zur Zeit der Modellierung gar nicht so genau entscheiden lässt?

Gregor: Bedacht angewandt können die Komposition und die Aggregation zum besseren Verständnis des Modells beitragen. Manchmal ist es einfach natürlich zu sagen, dass ein Objekt aus anderen Objekten besteht. Wir sollten aber nicht zu viele Gedanken und zu viel Zeit an die Modellierungsentscheidung verschwenden. Jede Komposition und jede Aggregation lässt sich nämlich auch einfach durch eine Assoziation mit entsprechenden Einschränkungen und der Angabe der Navigierbarkeit und der Multiplizität abbilden.
Rheinwerk Computing - Zum Seitenanfang

4.3.8 Attribute  Zur nächsten ÜberschriftZur vorigen Überschrift

Neben seiner Funktionalität und den Beziehungen zu anderen Objekten hat ein Objekt Attribute – Eigenschaften, die das Objekt beschreiben, und Daten, die das Objekt verwaltet. In Abschnitt 4.1.1 haben wir bereits vorgestellt, wie Eigenschaften von Objekten beschrieben werden.

Genau genommen entsprechen Attribute eines Objekts den Komponenten dieses Objekts in verschiedenen Kompositionsbeziehungen. Das Attribut-Sein und das Komponente-Sein sind zwei austauschbare Beschreibungsmöglichkeiten desselben Konzeptes. Daher entspricht die Notation für die Darstellung der Attribute in UML der kompakten Notation für die Darstellung der Komposition.

Für Attribute gilt also das Gleiche wie für die Komposition: Sie können ein- oder mehrwertig sein. Wenn sie mehrwertig sind, kann die Reihenfolge der Werte relevant oder irrelevant sein. Ein Wert kann mehrfach vorkommen, oder jeder Wert muss eindeutig sein.

Die Multiplizität des Ganzen ist bei Attributen genau wie bei der Komposition genau 1. Die Navigierbarkeit hat bei den Attributen fast immer die Richtung Zusammengesetztes Objekt-Attribut. Sollte irgendwann eine andere Art der Navigierbarkeit benötigt werden, empfehlen wir, diese Beziehung nicht als Attribut, sondern als Komposition zu modellieren.


Rheinwerk Computing - Zum Seitenanfang

4.3.9 Beziehungen zwischen Objekten in der Übersicht  topZur vorigen Überschrift

In Abbildung 4.31 sehen Sie noch einmal die UML-Darstellungsmöglichkeiten für Beziehungen zwischen Objekten in der Übersicht.

Abbildung 4.31    Darstellung von Beziehungen zwischen Objekten in UML



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

 <<   zurück
  Zum Rheinwerk-Shop
Neuauflage: Objektorientierte Programmierung






Neuauflage:
Objektorientierte Programmierung

Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Rheinwerk-Shop: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Rheinwerk-Shop: C++ Handbuch






 C++ Handbuch


Zum Rheinwerk-Shop: Einstieg in Python






 Einstieg in Python


Zum Rheinwerk-Shop: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2009
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern