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

 << zurück
Praxisbuch Objektorientierung von Bernhard Lahres, Gregor Raýman
Professionelle Entwurfsverfahren
Buch: Praxisbuch Objektorientierung

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


Rheinwerk Computing

4.3 Beziehungen zwischen Objekten  downtop

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

gp  Beziehungen zwischen Klassen und Objekten Eine solche Beziehung, die Klassifizierung, haben wir in Abschnitt 4.2.1 kennen gelernt. 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 2.

Beziehungen zwischen Klassen

gp  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 1 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

gp  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 3 und 4.

Abbildung
Hier klicken, um das Bild zu vergrößern

Abbildung 4.21   UML-Darstellung der Beziehungen von Aristoteles

Assoziation, Aggregation und Komposition

Beziehungen zwischen verschiedenen Objekten werden ganz allgemein auch Assoziation genannt. 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.


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

4.3.1 Rollen und Richtung einer Assoziation  downtop

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-Klassendiagrammen14  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
Hier klicken, um das Bild zu vergrößern

Abbildung 4.22   Rolle und Richtung einer Assoziation
Rheinwerk Computing

4.3.2 Navigierbarkeit  downtop

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
Hier klicken, um das Bild zu vergrößern

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

4.3.3 Kardinalität  downtop

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

Abbildung

Dateien im Dateisystem

Nehmen wir 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. Die mögliche beziehungsweise nötige Anzahl der Objekte, mit denen ein Objekt in einer Beziehung stehen kann, bezeichnen wir als die Kardinalität oder auch die Multiplizität dieser Beziehung.

Ein beliebtes Beispiel für eine Beziehung zwischen Objekten ist die Beziehung Elternteil-Kind. Die Kardinalität der Rolle Kind ist beliebig viele, denn es gibt Menschen, die keine Kinder haben, und Menschen, die ein oder mehrere Kinder haben. Wie sieht es aber mit der Kardinalitä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. Dennoch könnten wir diese Beziehung in unserer Anwendung nicht so modellieren.

Mögliche Kardinalitäten

Am häufigsten treffen wir auf Beziehungen mit folgenden Kardinalitäten:

Ein Objekt steht in einer Beziehung mit

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

Es kann aber durchaus Beziehungen mit anderen Kardinalitäten geben. Zum Beispiel in der Beziehung Tennismatch-Spieler ist die Kardinalität der Spieler zwei oder vier.


Kardinalität in UML

In UML wird die Kardinalität eines Endes einer Beziehung als eine Auflistung der möglichen Anzahlen in der Nähe des Endes dargestellt. Intervalle werden als »min .. max« angegeben. Ein Stern bedeutet dabei »beliebig viele«. Das Intervall »0..*« kann also auch als »*« angegeben werden.


In Abbildung 4.24 wird das Konzept der Kardinalität in UML verdeutlicht. An Markierung 1 ist eine Assoziation zwischen Exemplaren derselben Klasse Person dargestellt. Die Assoziation wird durch eine Linie repräsentiert, die am Kästchen Person anfängt und endet, denn sowohl die Rolle Kind als auch die Rolle Elternteil wird von Personen gespielt. Ein und dieselbe Person kann in dieser Beziehung für andere Personen der Elternteil und für andere das Kind sein. Diese Person kann (nach diesem Modell) beliebig viele Kinder, aber maximal zwei Eltern haben.

Abbildung
Hier klicken, um das Bild zu vergrößern

Abbildung 4.24   Mehrwertige Beziehungen in UML

Mehrwertige Beziehungen

Wenn die maximale Kardinalitä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
Hier klicken, um das Bild zu vergrößern

Abbildung 4.25   Zusatzinformationen zu Beziehungen in UML
Rheinwerk Computing

4.3.4 Qualifikatoren  downtop

Manchmal kann man über die Kardinalitä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 Kardinalitä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
Hier klicken, um das Bild zu vergrößern

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 Kardinalität der qualifizierten Beziehung an.



Rheinwerk Computing

4.3.5 Beziehungsklassen, Attribute einer Beziehung  downtop

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

Abbildung
Hier klicken, um das Bild zu vergrößern

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 Kardinalitä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 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.

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
Hier klicken, um das Bild zu vergrößern

Abbildung 4.28   Alternative Darstellung einer Beziehungsklasse
Rheinwerk Computing

4.3.6 Implementierung von Beziehungen  downtop

Beziehungen unterscheiden sich unter anderem durch ihre Kardinalitä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

4.3.7 Komposition und Aggregation  downtop

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

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

Abbildung


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.

Abbildung


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
Hier klicken, um das Bild zu vergrößern

Abbildung 4.29   Aggregation und Komposition in UML

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

Abbildung
Hier klicken, um das Bild zu vergrößern

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 Kardinalität abbilden.


Rheinwerk Computing

4.3.8 Attribute  downtop

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 Kardinalitä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

4.3.9 Beziehungen zwischen Objekten in der Übersicht  toptop

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

Abbildung
Hier klicken, um das Bild zu vergrößern

Abbildung 4.31   Darstellung von Beziehungen zwischen Objekten in UML


1  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.

2  Wir werden uns in diesem Buch nicht allen Details der Fähigkeiten der UML widmen, eine tiefer gehende Beschreibung können Sie in [Kecher2005] finden.

3  Obwohl der Begriff Multiplizität unserer Ansicht nach besser ausdrückt, welche Eigenschaft von Beziehungen hier gemeint ist, verwenden wir in der Folge doch den Begriff Kardinalität. Zum einen ist dieser Begriff gebräuchlicher. Zum anderen haben wir uns auch nach dem Versuch, Multiplizität dreimal hintereinander schnell auszusprechen, gegen die Verwendung dieses Begriffs entschieden.

4  Warum können wir die Kardinalität der Rolle »Elternteil« nicht als 2, sondern nur als 0..2 implementieren? Diese Frage ist eine kleine Denkaufgabe für Sie, geehrter Leser!

5  Wir meinen hier sowohl die Löhne als auch die Gehälter.

6  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.

 << zurück
  
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Neuauflage: Objektorientierte Programmierung






 Neuauflage:
 Objektorientierte
 Programmierung


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Katalog: C++ Handbuch






 C++ Handbuch


Zum Katalog: Einstieg in Python






 Einstieg in Python


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Rheinwerk Verlag GmbH 2006
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