Sie sind auf Seite 1von 12

FB Informatik

Prof. Dr. R.Nitsch

Programmieren - Beziehungen zwischen Objekten

Assoziation
Aggregation
Komposition

Reiner Nitsch
r.nitsch@fbi.h-da.de
berblick FB Informatik
Prof. Dr. R.Nitsch

Assoziation, Aggregation und Komposition beschreiben die gemeinsame Struktur von


i.d.R. langfristigen (berdauern einzelne Operationen) Beziehungen zwischen
Objekten
Sie dienen der objektorientierten und semantischen Datenmodellierung.
Beispiel: Zuordnung von Teilnehmern zu Terminen im mehrbenutzerfhigen
Terminkalender Objekte

t1:Termin b1:Benutzer
Links (Verweise) und
b2:Benutzer

t2:Termin b3:Benutzer
Assoziation
Termin Benutzer entsprechende Assoziation

Klassen

28.10.2007 C++ - Beziehungen zwischen Objekten 2


Assoziationen und ihre Dekorationen FB Informatik
Prof. Dr. R.Nitsch

Assoziationen beschreiben allgemeine, lose Assoziationen in Klassendiagrammen


Beziehungen zwischen Objekten (meist)
unterschiedlicher Klassen. Auf Objektebene Name Navigationsrichtung
bedeutet dies, dass ein Objekt ein anderes
"kennt" und mit ihm kommunizieren kann. ist verheiratet mit
werden in UML-Objekt- und Klassendiagrammen Ehemann Ehefrau
durch Linien dargestellt. 1 1
sind ggf. durch zustzliche Angaben (Dekoration) Lehrer
unterrichtet
Schueler
genauer beschrieben, wie z.B. durch * KANN Bez. *
einen Namen , Leserichtung (`) hat
ggf. eine (Navigations)Richtung (): kennen Kunde Konto
sich die beteiligten Objekte gegenseitig 1,2 MUSS Bez. 1..*
(Normalfall) oder kennt lediglich ein Objekt
hat
das andere? Eine Kommunikation kann immer Haus Kamin
nur von einem Objekt ausgehen, das ein 1 KANN Bez. 0,1
anderes kennt; die Kommunikation kann
dennoch bidirektional sein enthaelt
Kardinalitten (multipicity): Sie spezifiziert, Eierkarton Eier
wieviele andere Objekte ein bestimmtes 1 6,10
Objekt ber diese Assoziation kennen kann
oder kennen mu. Kardinalitten definieren Kardinalitt
also auch KANN oder MUSS Beziehungen.

28.10.2007 C++ - Beziehungen zwischen Objekten 3


Implementierung einer bidirektionalen Assoziation FB Informatik
Prof. Dr. R.Nitsch

Objekte der Klassen Frau und Mann knnen miteinander verheiratet sein. Dabei
sollen Mann und Frau sich gegenseitig kennen und jedes ggf. die Initiative zur
Kommunikation mit dem anderen Objekt ergreifen knnen.
Zum Verwalten der Assoziation wird i.d.R. noch eine Management-SS bentigt.

0,1 ist verheiratet mit 0,1


Mann Frau

class Mann { class Frau {


Keine Abhngigkeit:
Frau *pEP Mann *pEP
Ehepartner lebt weiter!
public: public:
Mann() { pEP=0; } Frau() { pEP=0; }
~Mann() { } ~Frau() { }
void setEP(Frau *pEF) { pEP=pEF; } void setEP(Mann *pEM) { pEP=pEM; }
void removeEP() { pEP=0; } void removeEP() { pEP=0; }
Frau* getEP() { return pEP; } Mann* getEP() { return pEP; }

void heiraten(Frau *pF) { void heiraten(Mann *pM) {


if(!pEP){pEP=pF; pF->setEP(this);} pEP=pM; pM->setEP(this); }
void scheiden() { void scheiden() {
if(pEP){ pEP->removeEP(); if(pEP){ pEP->removeEP;
removeEP();} removeEP(); }
};
};

28.10.2007 C++ - Beziehungen zwischen Objekten 4


Anwendung einer bidirektionalen Assoziation FB Informatik
Prof. Dr. R.Nitsch

class Schoepfungsgeschichte {
Mann* pAdam; Frau* pEva
Manager-Klassen oder -Funktionen public:
Schoepfungsgeschichte() {
erzeugen und verwalten urschlich pAdam = new Mann();
Objekte anderer Klassen in OO- pEva = new Frau();
Programmen und stellen notwendige }
Verknpfungen her. void letzterAkt() {
treten zumeist auch in Interaktion
pEva->heiraten(pAdam);
ApfelEssen();
mit dem Benutzer, um seine pAdam->scheiden();
Managerklasse verwaltet
Wnsche auf Software-Ebene (z.B.
Mann- und Frau-Objekte
Modus "testen" oder "spielen") im
auch nach der Scheidung
}
(keine verwaisten Objekte)
Einklang und per Teamarbeit mit den void ApfelEssen() {
brigen Klassen umzusetzen. cout << "Eva klaut einen Apfel "
<< "vom Baum des Hotelchefs."
Jedes C++-Programm wird durch ein cout << "Mmmh schmeckt lecker!";
Hauptprogramm bzw. eine main()- cout << "Stimme vom CHEF: "
Funktion gestartet. In dieser << "Raus aus dem Hotel!!";
Funktion wird mindestens }
~Schoefungsgeschichte {
ein Objekt dieser Manager- delete pAdam; delete pEva; }
Klasse erzeugt und };

void main () {
eine Start-Methode aufgerufen. Schoepfungsgeschichte SG;
SG.letzterAkt();
28.10.2007 C++ - Beziehungen zwischen
} Objekten 5
Aggregation FB Informatik
Prof. Dr. R.Nitsch

ist ein Spezialfall einer Assoziation


beschreibt eine part-of-Beziehung: diese liegt vor, wenn Objekte einer Klasse Objekte
anderer Klassen nicht nur kennen, sondern aus ihnen bestehen, d.h. es existiert eine logische
Einheit: Ganzes-Teil-Beziehung (whole-part relationship, "master-slave" relationship)
Objekt A "enthlt" oder "ist zusammengesetzt aus" Objekt B berordnungsbeziehung
Objekt B "ist Teil von" oder "gehrt zu" Objekt A (Komponentenobjekt) Unterordnungsbezhg
Erfolgt eine Operation auf einem Komponentenobjekt, so wird sie auch auf den Teilobjekten
ausgefhrt (Operationen mit kaskadierender Semantik). Bsp: Lesen von Platte, verschieben auf
Bildschirm.
impliziert die Unabhngigkeit der Teile vom Ganzen, d.h. die Teile knnen auch unabhngig vom
Ganzen existieren.
Beispiel: Tisch (=Ganzes) und Tischbeine (=Teile). Geht Tisch kaputt, knnen Tischbeine ggf
auch abgeschraubt, zwischengelagert und wiederverwendet werden.
ist i.d.R. einseitig navigierbar (vom Ganzen zum Teil)

To-do-Liste setzt sich aus mehreren Jeder Eintrag kann in mehreren To-do-Listen vorkommen
To-do-Eintrgen zusammen oder unabhngig von einer To-do-Liste existieren.

hat
UML-Notation ToDoEintrag
* *
ToDoListe
gehrt zu

UML-Symbol fr Aggregation
28.10.2007 C++ - Beziehungen zwischen Objekten 6
Komposition FB Informatik
Prof. Dr. R.Nitsch

ist eine (strenge) Form der Aggregation mit folgenden Einschrnkungen


Ein Teil kann eine part-of-Beziehung zu genau einem Ganzen haben (implizite Exklusivitt),
d.h. zulssig ist nur die Kardinalitt >>1<< auf der Seite des Ganzen (Aggregats)
Teilobjekte sind existenzabhngig vom Ganzen, d.h. Ganzes und Teil werden gemeinsam
gelscht
Das Ganze ist fr die Verwaltung seiner Teile verantwortlich
beim Kopieren des Ganzen entstehen auch Kopien der Teilobjekte
beim Verschieben einer Eingabemaske werden auch alle Eingabefelder verschoben.
Beispiel: Buchhaltungssystem: Ein Auftrag ist existenzabhngig von einem Kunden (kein
Auftrag ohne Kunde)

Lies:
Jeder Kamin gehrt zu
UML-Notation Gebude
hchstens einem Gebude.
Lies: Komposition 1 0..1 Aggregation Ein Gebude hat keinen,
wie bei Treppe, aber (Composition) einen oder mehrere Kamine.
Zimmer ohne Gebude Kamine knnen auch ohne
gibt es nicht Gebude existieren
Zimmer knnen auch Exklusivitt (Unabhngigkeit)
nachtrglich eingebaut * *
werden Unabhngigkeit
Zimmer Kamin

Noch ein Beispiel: Window, Men, Button, Scrollbar bilden eine Komposition
28.10.2007 C++ - Beziehungen zwischen Objekten 7
Beispiel: Konto FB Informatik
Prof. Dr. R.Nitsch

Beispiel: UML Klassendiagramm Konto

hat 1..*
Konto Kunde
0..* gehrt zu
1 1 1

1 1 1
Betrag Name Adresse

Die Beziehung zwischen den Klassen Kunde und Konto ist eine Assoziation, weil ein
Kunde keine bis mehrere Konten haben kann, und weil ein Konto mehrere Kontoinhaber
haben kann (keine Exklusivitt). Kundendaten drfen mit dem Lschen eines Kontos
und Konten drfen mit dem Lschen eines Kunden nicht automatisch gelscht werden
(keine Abhngigkeit). Eine Aggregation liegt nicht vor: ein Konto ist kein Teil eines
Kunden sondern diesem lediglich zugeordnet.
Die Beziehung zwischen einem Konto-Objekt und dem Kontostands-Objekt (hier:
Betrag) ist eine Komposition, weil ein Kontostand ohne zugehriges Konto keinen Sinn
ergibt. Hinweis: Ein Konto sollte natrlich nicht gelscht werden knnen, solange der
Kontostand nicht 0.00 ist.
Aus den selben Grnden stellt auch die Beziehung zwischen dem Kunden und seinen
Adreinformationen eine Komposition dar.

28.10.2007 C++ - Beziehungen zwischen Objekten 8


Realisierung in C++ Regel fr Objekt-Konstruktor: FB Informatik
Prof. Dr. R.Nitsch
class Kunde Zuerst werden (implizit) die Standard-
{ konstruktoren der Teilobjekte aufgerufen:
string adresse; 1. string::string() fr Adresse-Objekt
string name; 2. string::string() fr Name-Objekt
vector<Konto*> kto; 3. vector<Konto*>::vector() fr Kto-Objekt
public: 4. Kunde::Kunde()
Kunde(const string& n = "", const string& a =""); Aufbau von innen nach aussen
~Kunde(); Kunde
void neuesKonto(const Konto &nK); string
void loescheKonto(const Konto &k);
void displayKonten() const; adresse
friend class Konto; hebt Zugriffschutz fr Konto auf string
}; name
vector<Konto*>
// Kunde.cpp: Implementierung der Klasse Kunde.
#include "Kunde.h" kto
#include <iostream>
using std::cout; using std::endl;
Konstruktor
Kunde::Kunde (const string& n, const string& a) { name=n , adresse=a; }
Kunde::~Kunde () { } Destruktor
void Kunde::neuesKonto(const Konto& nK) { kto.push_back(&nK); }
void Kunde::loescheKonto(const Konto& k) { /*in kto &k suchen und lschen*/ }
void Kunde::displayKonten() const {
displayKunde(); cout << " hat folgende Konten: " << endl;
for ( int i=0; i < kto.size(); cout << kto[i]->getNummer() << ' ', i++ );
cout << endl;
}
28.10.2007 C++ - Beziehungen zwischen Objekten 10
Realisierung in C++ FB Informatik
Prof. Dr. R.Nitsch

class Betrag // Betrag.cpp:


{ Komp. od. Aggr?
Komposition
// Implementierung der Klasse Betrag.
int euro, cent; #include "Betrag.h"
void set( int e, int c = 0) Private! #include <iostream>
public:
Betrag( int e, int c); Betrag::Betrag( int e, int c) Konstruktor
void display() const; { euro=e; cent=c; }
friend class Konto; fr Zugriff auf private
} Elemente Betrag::~Betrag () {} Destruktor
Ausgabe: 3.50
void Betrag::display() const
{ cout << euro << '.' << cent << endl; }

void Betrag::set( int e, int c)


{ euro=e; cent=c; }

28.10.2007 C++ - Beziehungen zwischen Objekten 11


Realisierung in C++ FB Informatik
Prof. Dr. R.Nitsch
Komposition mit Kardinalitt 1
class Konto Attribut Betrag und Konto haben die gleiche Lebensdauer
{
Betrag stand; long nummer; Kunde *pKunde;
public:
Assoziation mit Kardinalitt 1
Konto( long nr, Kunde *pK);
void druckeAuszug() const;
void einzahlen( int e, int c = 0);
long getNummer() const { return nummer; }
// SS fr Aggregationsmanagement
};
Regel fr Objekt-Konstruktor:
// Konto.cpp: Implementierung der Klasse Konto. Zuerst werden (implizit) die Standard-
#include "Konto.h" Konstruktoren der Teilobjekte aufgerufen
Konto::Konto ( long nr; Kunde *pK) {: Stand(0,0) { Aufbau von innen nach aussen
nummer = nr; if(pK) pKunde=pK else exit(1);
stand.set(0,0); Fehler: Standardkonstruktor fehlt! Konto
} Implementieren oder
Konto::~Konto() {} Betrag
besser: expliziter
void Konto::druckeAuszug() const { Euro
Konstruktoraufruf in
pKunde->display(); Cent
Vorinitialisierungsliste
stand.display();
Nummer
}
pKunde
void Konto::einzahlen( int e, int c ) {
if (e>=0 && c>=0) {
c += stand.getCent();
stand.set(stand.getEuro()+e+c/100 , c%100); set ist private! Deshalb: friend class Konto
} in Klasse Betrag 12
} 28.10.2007 C++ - Beziehungen zwischen Objekten
Realisierung in C++ FB Informatik
Prof. Dr. R.Nitsch

// Anwendungsumgebung
void main()
{
//Objekt vom Typ Kunde dynamisch erzeugen
Kunde* pK1 = new Kunde("Meier","Darmstadt");
Konto Kto1(123, pK1), Kto2(456, pK1);
Kto1.einzahlen(100,99); Kann auch von einer Manager-Klasse (z.B.
Kto1.einzahlen(100,99); Kontenverwaltung) bernommen werden
Kto1.druckeAuszug();
Kto2.einzahlen(1000);
Kto2.druckeAuszug();
pK1->displayKonten();
}

Ausgabe:
KontoNr 123 Kontostand: 201.98
KontoNr 456 Kontostand: 1000.0
Meier aus Darmstadt
hat folgende Konten:
123 456
Press any key to continue

28.10.2007 C++ - Beziehungen zwischen Objekten 13