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
b1:Benutzer

t1:Termin

b2:Benutzer
t2:Termin

Links (Verweise) und

b3:Benutzer
Assoziation

Termin

Benutzer

entsprechende Assoziation

Klassen

28.10.2007

C++ - Beziehungen zwischen Objekten

Assoziationen und ihre Dekorationen


Assoziationen beschreiben allgemeine, lose
Beziehungen zwischen Objekten (meist)
unterschiedlicher Klassen. Auf Objektebene
bedeutet dies, dass ein Objekt ein anderes
"kennt" und mit ihm kommunizieren kann.
werden in UML-Objekt- und Klassendiagrammen
durch Linien dargestellt.
sind ggf. durch zustzliche Angaben (Dekoration)
genauer beschrieben, wie z.B. durch
einen Namen , Leserichtung (`)
ggf. eine (Navigations)Richtung (): kennen
sich die beteiligten Objekte gegenseitig
(Normalfall) oder kennt lediglich ein Objekt
das andere? Eine Kommunikation kann immer
nur von einem Objekt ausgehen, das ein
anderes kennt; die Kommunikation kann
dennoch bidirektional sein
Kardinalitten (multipicity): Sie spezifiziert,
wieviele andere Objekte ein bestimmtes
Objekt ber diese Assoziation kennen kann
oder kennen mu. Kardinalitten definieren
also auch KANN oder MUSS Beziehungen.

28.10.2007

FB Informatik
Prof. Dr. R.Nitsch

Assoziationen in Klassendiagrammen
Name

Navigationsrichtung

ist verheiratet mit

Ehemann
1

1
unterrichtet

Lehrer
*

Schueler

KANN Bez.

hat

Kunde

1,2 MUSS Bez.

Konto
1..*

hat

Haus

1 KANN Bez.

Kamin
0,1

enthaelt

Eierkarton

C++ - Beziehungen zwischen Objekten

Ehefrau

Eier
6,10
Kardinalitt

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.
Mann
class Mann {
Frau *pEP
public:
Mann() { pEP=0;
~Mann() { }
void setEP(Frau
void removeEP()
Frau* getEP() {

0,1

ist verheiratet mit 0,1

Keine Abhngigkeit:
Ehepartner lebt weiter!
}
*pEF) { pEP=pEF; }
{ pEP=0; }
return pEP; }

void heiraten(Frau *pF) {


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

};
28.10.2007

Frau

class Frau {
Mann *pEP
public:
Frau() { pEP=0;
~Frau() { }
void setEP(Mann
void removeEP()
Mann* getEP() {

}
*pEM) { pEP=pEM; }
{ pEP=0; }
return pEP; }

void heiraten(Mann *pM) {


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

C++ - Beziehungen zwischen Objekten

Anwendung einer bidirektionalen Assoziation

Manager-Klassen oder -Funktionen


erzeugen und verwalten urschlich
Objekte anderer Klassen in OOProgrammen und stellen notwendige
Verknpfungen her.
treten zumeist auch in Interaktion
mit dem Benutzer, um seine
Wnsche auf Software-Ebene (z.B.
Modus "testen" oder "spielen") im
Einklang und per Teamarbeit mit den
brigen Klassen umzusetzen.
Jedes C++-Programm wird durch ein
Hauptprogramm bzw. eine main()Funktion gestartet. In dieser
Funktion wird mindestens
ein Objekt dieser ManagerKlasse erzeugt und
eine Start-Methode
28.10.2007

FB Informatik
Prof. Dr. R.Nitsch

class Schoepfungsgeschichte {
Mann* pAdam; Frau* pEva
public:
Schoepfungsgeschichte() {
pAdam = new Mann();
pEva = new Frau();
}
void letzterAkt() {
pEva->heiraten(pAdam);
ApfelEssen();
Managerklasse verwaltet
pAdam->scheiden();
Mann- und Frau-Objekte

auch nach der Scheidung


}
(keine verwaisten Objekte)
void ApfelEssen() {
cout << "Eva klaut einen Apfel "
<< "vom Baum des Hotelchefs."
cout << "Mmmh schmeckt lecker!";
cout << "Stimme vom CHEF: "
<< "Raus aus dem Hotel!!";
}
~Schoefungsgeschichte {
delete pAdam; delete pEva; }
};

void main () {
aufgerufen.
Schoepfungsgeschichte SG;
SG.letzterAkt();
C++ - Beziehungen zwischen
Objekten
}

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
To-do-Eintrgen zusammen

UML-Notation

ToDoEintrag

Jeder Eintrag kann in mehreren To-do-Listen vorkommen


oder unabhngig von einer To-do-Liste existieren.
hat
gehrt zu

ToDoListe

UML-Symbol fr Aggregation
28.10.2007

C++ - Beziehungen zwischen Objekten

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)

UML-Notation
Lies:
wie bei Treppe, aber
Zimmer ohne Gebude
gibt es nicht
Zimmer knnen auch
nachtrglich eingebaut
werden

Gebude
Komposition
(Composition)

0..1

Aggregation

Exklusivitt
*

*
Unabhngigkeit
Zimmer

Noch ein Beispiel: Window, Men, Button, Scrollbar bilden eine


28.10.2007

Lies:
Jeder Kamin gehrt zu
hchstens einem Gebude.
Ein Gebude hat keinen,
einen oder mehrere Kamine.
Kamine knnen auch ohne
Gebude existieren
(Unabhngigkeit)

C++ - Beziehungen zwischen Objekten

Kamin

Komposition
7

Beispiel: Konto

FB Informatik
Prof. Dr. R.Nitsch

Beispiel: UML Klassendiagramm Konto


hat
Konto
1
1
Betrag

0..* gehrt zu

1..*

Kunde
1

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

Realisierung in C++
class Kunde
{
string adresse;
string name;
vector<Konto*> kto;
public:
Kunde(const string& n = "", const string& a ="");
~Kunde();
void neuesKonto(const Konto &nK);
void loescheKonto(const Konto &k);
void displayKonten() const;
hebt Zugriffschutz fr Konto auf
friend class Konto;
};

Informatik
Regel fr Objekt-Konstruktor: FB
Prof. Dr. R.Nitsch
Zuerst werden (implizit) die Standardkonstruktoren der Teilobjekte aufgerufen:
1. string::string() fr Adresse-Objekt
2. string::string() fr Name-Objekt
3. vector<Konto*>::vector() fr Kto-Objekt
4. Kunde::Kunde()
Aufbau von innen nach aussen

// Kunde.cpp: Implementierung der Klasse Kunde.


#include "Kunde.h"
#include <iostream>
using std::cout; using std::endl;

Kunde
string

adresse
string

name
vector<Konto*>

kto

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
Komp. od. Aggr?
Komposition
{
int euro, cent;
void set( int e, int c = 0) Private!
public:
Betrag( int e, int c);
void display() const;
friend class Konto; fr Zugriff auf private
}
Elemente

// Betrag.cpp:
// Implementierung der Klasse Betrag.
#include "Betrag.h"
#include <iostream>
Betrag::Betrag( int e, int c) Konstruktor
{ euro=e; cent=c; }
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++
Komposition mit Kardinalitt 1
Attribut Betrag und Konto haben die gleiche Lebensdauer

class Konto
{
Betrag stand; long nummer; Kunde *pKunde;
public:
Assoziation
Konto( long nr, Kunde *pK);
void druckeAuszug() const;
void einzahlen( int e, int c = 0);
long getNummer() const { return nummer; }
// SS fr Aggregationsmanagement
};

FB Informatik
Prof. Dr. R.Nitsch

mit Kardinalitt 1

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);
Konto
Fehler: Standardkonstruktor fehlt!
}
Implementieren oder
Betrag
Konto::~Konto() {}
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
C++ - Beziehungen zwischen Objekten
} 28.10.2007

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);
Kto1.einzahlen(100,99);
Kto1.druckeAuszug();
Kto2.einzahlen(1000);
Kto2.druckeAuszug();
pK1->displayKonten();
}

Kann auch von einer Manager-Klasse (z.B.


Kontenverwaltung) bernommen werden

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