Objektorientierte Analyse und Design - beim Fachbereich Informatik ...

Hochschule Darmstadt 

Fachbereich Informatik 

Objektorientierte Analyse und Design 

4.3 Aktivitätsdiagramme 

OOAD, Dr. Eicke Godehardt WS2012/13, h_da, Fachbereich Informatik


Ausgangssituation 

n� Situation: 

ð� Use Cases- und Use Case Diagramme bieten adäquate Mittel 

zur Darstellung der funktionalen Anforderungen! 

- Aber die Abläufe sind in den Use Case -Templates nicht wirklich übersichtlich 

dargestellt 

- Parallele Vorgänge sind sprachlich schwer auszudrücken 

ð� Wie kann man Abläufe anschaulich beschreiben? 

- übersichtlich und leicht verständlich 

- inklusive Kontrollstrukturen (Schleifen und Bedingungen) 

- inklusive paralleler Ausführung von Teilabläufen (Concurrency) 

ð� Aktivitätsdiagramme 

OOAD, Dr. Eicke Godehardt WS2012/13, h_da, Fachbereich Informatik 102


Notation am Beispiel: 'Essen zahlen' 

Startknoten 

Aktion 

Kontrollfluss(kante) 

Essen zahlen 

Verantwortungsbereich 

(swim lane) 

Synchronisations 

knoten 

Entscheidungs- 

knoten 

Endknoten 



Notation am Beispiel: 'Betragsfunktion' 

Zahl 

Aktivität 

Betrag berechnen 

Parameter 

[Zahl < 0] 

[Zahl >= 0] 

Ergebnis 

[= -1*Zahl] 

Ergebnis 

[=Zahl] 

Objektknoten 

Ergebnis 

Zusammenführungsknoten 



Tokenprinzip 

n� Aktivitätsdiagramme erlauben Verzweigungen des Kontrollflusses und 

gleichzeitig ablaufende, parallele Pfade 

ð� Belege die aktiven Zweige mit je einer imaginären Marke ("Token") um zu 

verstehen, wie der Ablauf funktioniert ! 

- Nachdem der Ablauf gestartet wurde, wird das erste Token erzeugt. Danach wird die Aktion a1 ausgeführt und 

das Token auf den Ausgang von a1 gelegt. Durch die Verzweigung in die beiden Threads p1 und p2 wird am 

Anfang beider Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgeführt; die Tokens werden 

auf die Ausgänge von p1 und p2 gelegt. Erst wenn auch das Token über p3 gewandert ist und beide Tokens 

da sind, wird das Eingangstoken für a2 gestartet. 

Dann wird a2 ausgeführt, das Token auf den Ausgang von a2 gelegt, die Aktivität beendet und das Token 

vernichtet. 

1 2 

a1 

3 

3 

p1 

p2 

4 

p3 

5 

4 

6 7 

a2 



Tokenprinzip am Beispiel: 'Essen zahlen' (erfolgreich) 

1 

2 

3 

7 

4 

6 

5 

8 

3 

9 

10 



Elemente in Aktivitätsdiagrammen (I) 

Aktion ZZZ 

Aktivität XXX 

Ergebnis 

[=Basis] 

n� Aktion 

ð� Ist das Basiselement zur Spezifikation von Verhalten. Es beschreibt 

einen Einzelschritt wie z. B. "Summe berechnen" 

ð� Eine Aktion kann als nicht weiter zerlegbare Funktion angesehen 

werden. Sie transformiert eine Eingabe zu einer Ausgabe. 

n� Aktivität 

ð� Eine Aktivität setzt sich aus Aktionen und anderen Aktivitäten 

zusammen, die im Aktivitätsdiagramm enthalten sind. 

ð� Symbole in einer Aktivität stellen Aktionen dar aus denen die 

Aktivität aufgebaut ist und Pfeile den Kontrollfluss. 

n� Objektknoten 

ð� können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren 

ð� Sie können als unabhängige Knoten in einem Diagramm benutzt 

werden, bzw. als Parameter für Aktionen (Input, Output Pin) 



Elemente in Aktivitätsdiagrammen (II) 

[else] 

[x = 1] 

n� Entscheidungsknoten 

ð� Es wird eine der herausführenden Kontrollflusskanten 

weiterverfolgt (abhängig davon, welche Bedingung wahr ist). 

Zu jedem Zeitpunkt darf nur genau eine Bedingung wahr sein. 

n� Verbindungsknoten 

ð� Schaltet eine von mehreren hineinführenden 

Kontrollflusskanten, wird die herausführende 

Kontrollflusskante weiterverfolgt 

n� Synchronisationsknoten 

ð� Der aus dem Balken herausführende Ablauf kann nur dann 

weitergeführt werden, wenn alle einmündenden Abläufe 

beendet sind 

n� Splittingknoten 

ð� Aus dem Balken herausführende Abläufe können gleichzeitig, 

also parallel ausgeführt werden 

(Aufspaltung des Kontrollflusses in mehrere parallele Teile) 



Anwendung 

n� Aktivitätsdiagramme 

ð� werden zur Modellierung von Abläufen und deren Steuerung benutzt 

ð� stellen die einzelnen Verfahrensschritte von Aktivitäten, zusammen mit der 

Reihenfolge in der sie ausgeführt werden, dar 

ð� können (durch Verantwortungsbereiche) die modellierten Aktionen bestimmten 

Modellelementen zuordnen 

ð� können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von 

Kontrollflüssen benutzt werden 

Aktivitätsdiagramme können in einem Projekt überall verwendet 

werden, wo Verhalten beschrieben werden muss, 

bzw. wo Datenflüsse oder Kontrollflüsse modelliert werden sollen 



Weiteres Beispiel: Geschäftsprozess 'Getränk bereiten' 

Kaffee- 

Maschine 

Kaffee 

brühen 

Suche 

Getränk 

Kaffee in 

Filter geben 

Maschine 

anschalten 

Kaffee 

eingießen 

Barkeeper Cola-Automat 

[kein Kaffeepulver 

vorhanden] 

Hole Dose 

Cola 

[Kaffeepulver vorhanden] 

Wasser 

eingießen 

Gast 

vertrösten 

Getränk 

aushändigen 

[Keine Cola 

vorhanden] 

Cola 

entnehmen 

[Cola 

vorhanden] 



Notation in UML 2.x (I) 

The image cannot be displayed. Your computer may not have enough memory to open the image, or the 

image may have been corrupted. Restart your computer, and then open the file again. If the red x still 

appears, you may have to delete the image and then insert it again. 

The image cannot be displayed. 

Your computer may not have 

enough memory to open the 

image, or the image may have 

been corrupted. Restart your 

computer, and then open the file 

again. If the red x still appears, 

you may have to delete the 

Aktivität (Activity) 

Eine Aktivität besteht aus Knoten (Aktivitäten, Aktionen, 

Kontroll- und Objektknoten) und Kanten (Pfeilen), die den 

Kontrollfluss durch die Aktivität darstellen. Die Aktivität wird als 

abgerundetes Rechteck dargestellt. In der linken, oberen Ecke 

steht der Name der Aktivität, gefolgt vom Eingangsparameter 

und Typ. Die Rechtecke an beiden Seiten geben die Eingangs- 

bzw. Ausgangsparameter an. Die Symbole in der Aktivität 

stellen die Aktionen dar und die Pfeile den Kontrollfluss. 

Aktion (Action) 

Eine Aktion ist in UML das Basiselement zur Spezifikation von 

Verhalten. Eine Aktion kann als nicht weiter zerlegbare 

Funktion angesehen werden. Sie transformiert eine Eingabe 

zu einer Ausgabe. 



Notation in UML 2.x (II) 

The image cannot be displayed. Your computer may not have enough 

memory to open the image, or the image may have been corrupted. 

Restart your computer, and then open the file again. If the red x still 


The image cannot be displayed. 

Your computer may not have 

enough memory to open the 

image, or the image may have 

been corrupted. Restart your 

computer, and then open the file 

again. If the red x still appears, 

you may have to delete the image 

and then insert it again. 





Start-, Endknoten, Ablaufende 

Ein Startknoten (Initial Node) stellt den Beginn eines Ablaufes dar. Ein 

Endknoten (Activity Final Node) beendet eine Aktivität vollständig. Ein 

Ablaufende (Flow Final Node) terminiert einen Zweig einer Aktivität, die 

Aktivität selbst läuft weiter. 

Pfeil/Kante 

Ein Pfeil beschreibt den Fluss zwischen den verbundenen Elementen. 

In einer eckigen Klammer kann eine Bedingung angegeben werden, die 

erfüllt sein muss, damit die Kante überquert wird. 

Entscheidung und Zusammenführung 

Bei der Entscheidung wird nach Eintreffen des Tokens a entweder nach 

b oder nach c verzweigt. Die Bedingung, die erfüllt sein muss, kann als 

Ausdruck in eckigen Klammern an den Pfeilen angegeben werden. 

Bei der Zusammenführung wird nach Eintreffen der Token a oder b 

nach c verzweigt. 



Notation in UML 2.x (III) 

The image cannot be displayed. Your computer may not have 

enough memory to open the image, or the image may have been 

corrupted. Restart your computer, and then open the file again. If 

the red x still appears, you may have to delete the image and 

then insert it again. 

The image cannot be displayed. Your 

computer may not have enough memory 

to open the image, or the image may 

have been corrupted. Restart your 

computer, and then open the file again. If 

the red x still appears, you may have to 

delete the image and then insert it again. 

Aufteilung (Splitting), Synchronisation 

Bei einem Splitting-Knoten wird in mehrere parallele Threads verzweigt 

(wenn a da ist, feuern b und c). Ein Synchronisationsknoten 

synchronisiert mehrere Threads (wenn a und b da sind, feuert c) 

Signal (Send signal action, Accept event action) 

Mit diesen Symbolen kann das Senden und Empfangen von Signalen 

dargestellt werden (z. B. „Polizei ruft an“ wäre ein empfangenes Signal 

bei Aktivität „Party feiern“). 

Zeitereignis (Accept time event action) 

Über diese Symbol wird ausgedrückt, dass eine Aktion zeitgesteuert 

angestoßen wird. 

Verantwortungsbereiche (Partitions, swim lanes) 

Zur Zuordnung der Aktionen einer Aktivität zu den verantwortlichen 

Elementen können Aktivitätsdiagramme in Partitionen (Activity Partition) 

unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine 

in Bahnen eingeteiltes Schwimmbecken aussieht, werden die Activity 

Partitions oft auch swim lanes genannt. 



Notation in UML 2.x (IV) 

The image cannot be displayed. Your computer may not 

have enough memory to open the image, or the image may 

have been corrupted. Restart your computer, and then open 

the file again. If the red x still appears, you may have to 

delete the image and then insert it again. 


enough memory to open the image, or the image may have been 

corrupted. Restart your computer, and then open the file again. 

If the red x still appears, you may have to delete the image and 

then insert it again. 

Objektknoten 

können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren. Sie 

können als unabhängige Knoten in einem Diagramm benutzt werden, 

bzw. als Parameter für Aktionen (Input, Output Pin). Beide Darstellungen 

sind äquivalent. Im Bild oben ist a als Objekt eingezeichnet; im unteren 

Bild ist a Ausgangsparameter der linken Aktion und Eingangsparameter 

der rechten. 

Kanten 

verbinden die Aktionen in einem Diagramm und stellen den Fluss dar. 

Kanten, die Kontrollfluss modellieren, verbinden Aktionen direkt; 

Objektflusskanten verbinden die Pins der beteiligten Aktionen. 

Verfeinern von Aktivitäten 

Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden. 

Das zu verfeinernde Element wird mit einem Gabelsymbol 

gekennzeichnet und kann in einem Unterdiagramm verfeinert werden. 

Alle Aktivitäten sind auf der untersten Hierarchieebene auf Aktionen 

abzubilden. 





4.4 Alternative Beschreibung von Use Cases 


4.4 Alternative Beschreibungen von Use Cases 

Möglichkeiten zur Beschreibung der Basic und Alternative Courses 

n� Zielsetzung Use Cases: 

ð� Beschreibung der Interaktion zwischen Benutzer(n) und einem System 

n� Bisherige Ausdrucksmittel: 

ð� normaler Text 

ð� strukturierter Text (pro Satz eine Aktion), in Tabellen 

n� Anforderungen 

ð� Möglichkeit zum Ausdruck von sequentiellen Abläufen zwischen System und der 

Außenwelt 

ð� If-Konstrukt für alternative Abläufe 

ð� Schleifen 

ð� Auslagern von Teilabläufen 

Das können Aktivitätsdiagramme auch! 



Aktivitätsdiagramme zur Beschreibung des Basic und Alternative Course 

Aktoren mit 

Kommunikation als 

Erweiterung zur 

UML-Norm für 

Aktivitätsdiagramme 

Alternative Course 

Ein-/Ausgabe 

Darstellung ist 

besonders geeignet 

bei parallelen Abläufen 

Darstellung von Angaben, 

die nichts mit der 

Schnittstelle zum Benutzer 

zu tun haben, aber deren 

Kenntnis wichtig für den 

Benutzer ist. 


Kunde 


Lösung: Aktivitätsdiagramme für Basic und Alternative Course 

Geld abheben 

PIN-Eingabe 

Betrag eingeben 

[PIN 1. oder 2. 

mal falsch] 

[PIN 3. mal falsch] 

[PIN gültig] 

Karte 

einschieben 

[Karte gültig] [Karte ungültig] 

Betrag 

abbuchen 

Fehlversuch 

protokollieren 

Fehlversuch 


Karte 

ausgeben 


benachrichtigen 

Karte 

einziehen 

Geld 

ausgeben 

Kommunikation 

teilweise nur 

angedeutet 

Fehlversuch 




Karte 

ausgeben 



Farben dienen nur der 

Veranschaulichung! 



Fazit 

n� Die Beschreibung der Abläufe von Use Cases und die Modellierung der 

Use Cases eines Systems können auch in UML erfolgen 

n� aber 

ð� kein neues Sprach-Konstrukt zu erlernen 

ð� standardisierte Beschreibungsmittel 

ð� bessere Integration in Tools 

ð� die Verständlichkeit nimmt ab 

(versteht der Kunde/Auftraggeber überhaupt Aktivitätsdiagramme?) 

ð� eine derartige Verwendung der UML ist nicht allgemein bekannt 

ð� es fehlen Ausdrucksmöglichkeiten für Stakeholder, Trigger, Guarantees,... 

Die meisten UML-Diagramme können zu 

unterschiedlichen Zwecken eingesetzt werden! 

Der Vorteil der „internationalen Sprache“ UML geht dann 

aber schnell verloren! 





4.5 Analysemodell 



Analysemodell 

n� Bei der Beschreibung der Anwendungsfälle stößt man auf materielle und 

immaterielle Dinge (Objekte!) mit zu verwaltenden Informationen 

Modelliere diese Objekte der Domäne als Klassen 

mit Eigenschaften und Beziehungen 

ð� Analysemodell/Domänenmodell 

ð� Identifizieren von Objekten, Klassen, Attributen, Beziehungen 

ð� nur Klassen und Attribute, d. h. keine Operationen 

ð� keine Richtungen bei Beziehungen 

ð� evtl. Gemeinsamkeiten als Generalisierungsbeziehungen 

ð� evtl. weitere Eigenschaften der Klassen, die nicht in Diagrammform ausdrückbar 

sind, in Textform 

ð� die Klassen des Analysemodells/Domainmodells nennt man Analyse-/Domain- 

Klassen 



Analyseklassendiagramm 

verallgemeinerte 

Datentypen 

keine Methoden 

Klassendiagramme werden im Design-Kapitel 

ausführlich behandelt! 



Ergebnis des Analysemodells 

n� Statische Systemsicht 

ð� Klassendiagramme mit rudimentären Klassen (Domain-/Analyseklassen) 

ð� die zu Objekten gehören, die ein Anwender wahrnimmt 

ð� Erstellungsregeln: 

- jede Domainklasse muss in mindestens einem Anwendungsfall vorkommen 

- jede Domainklasse sollte mindestens ein Attribut haben 

- Domainklassen enthalten keine Realisierungsdetails einer potentiellen Lösung 

n� Dynamische Systemsicht 

ð� Aktivitätsdiagramme zur Verdeutlichung der Abläufe 

n� Das Analysemodell stellt einen ganz groben Entwurf für das Design dar 

ð� es dient der Verständigung zwischen Auftraggeber und -nehmer 

ð� die tatsächliche Umsetzung kann sich später deutlich unterscheiden 

ð� In der Designphase kommen weitere Diagramme hinzu (z. B. Zustands- & 

Komponentendiagramme) 


4. Objektorientierte Analyse 

Kontrollfragen 

ð� Welche Zielsetzung hat die Anforderungsanalyse? 

ð� Warum beschreibt man Anforderungen nicht in einer natürlichen Sprache? 

ð� Ist ein Dieb ein Stakeholder für einen Geldautomaten? Ein Aktor? 

ð� Was ist der Unterschied zwischen Include und Extend? 

ð� Wie stellt man Use Cases in UML dar? 

ð� Wie beschreibt man ein gesamtes System mit Use Cases? 

ð� Welche Beziehungen gibt es in der UML zwischen Use Cases? 

ð� Kann man Use Cases komplett in der UML beschreiben? 

ð� Was ist das Tokenprinzip? 

ð� Was sind „Swim Lanes“? 

ð� Was unterscheidet Zusammenführungsknoten von Synchronisationsknoten? 

ð� Was ist das Analysemodell? 

Sie wissen jetzt wie man die Ergebnisse einer 

objektorientierten Analyse dokumentiert ! 





5. Objektorientiertes Design 


Die Idee ist das Absolute, und alles 

Wirkliche ist nur Realisierung der Idee. 

Georg W. F. Hegel 



Zur Erinnerung: Abstraktionsebenen 

gedankliche 

Ebene 

logische Ebene 

(Modell) 

physische Ebene 

(Implementierungsebene) 

Reale Welt 

OOA-Ebene 

OOD-Ebene 

Programm 

Abstraktion 

Implementierungskonzepte 

Codierung 

Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell) 

Arzt.cpp 



Zur Erinnerung: Phasenmodell der objektorientierten Systementwicklung 

Informationsgehalt 

reale Welt 

Abstraktion 

OOA 

(Analyse) 

Analyse-Modell 

Konkretisierung 

Abbildung 

OOD 

(Design) 

Design- 

Modell 

Isomorphismus 

OOP 

(Programmierung) 

Code 

Konsistenz 

Coderahmen 

Entwicklungs 

-phase 



Zwischenstand 

n� Sie ahnen jetzt 

ð� wie man die Welt der Anwendung analysiert und 

ð� daraus Objekte und Klassen extrahiert 

n� Sie wissen jetzt 

ð� wie man die Ergebnisse dokumentiert 

- als textuelle Use Cases, als Use Case Diagramme (UML) 

- als Aktivitätsdiagramme (UML) 

- als Analysemodell 

n� Das ist alles recht abstrakt und hat wenig mit der Umsetzung zu tun !? 

ð� ergänze nun Umsetzungsdetails (Programmiersprache, Betriebssystem,...) 

ð� modifiziere die Analyseklassen 

- um weitere Klassen für die Realisierung 

- um Methoden, weitere Attribute 

ð� Objektorientiertes Design 





5.1 Darstellung der Statik eines Systems 

5.1.1 Klassen und die UML 


5.1.1 Darstellung der Statik eines Systems: Klassen und die UML 

Lernziele 

n� Sie sollen in diesem Kapitel verstehen, 

ð� wie man Klassen darstellt 

ð� wie man Klassen und deren Assoziationen findet 

ð� welche Arten von Beziehungen es zwischen Klassen gibt 

ð� Was Generalisierung und Spezialisierung ist 

ð� wie man Klassen und die Beziehungen zwischen Klassen in UML darstellt 

ð� wie man Klassen und Beziehungen in C++ umsetzt 

Hinterher können Sie Klassen und deren Beziehungen in 

einem Klassendiagramm darstellen! 



Darstellung von Klassen, Attributen und Methoden 

geschütztes Attribut 

privates Attribut 

öffentliches Attribut 

Klassenattribut 

Öffentliche Operation 

Klassenmethode 

Window 

# groesseX : Integer 

# groesseY : Integer 

- sichtbar : Boolean = TRUE 

+ position : (x : Integer, y : Integer) 

- standardGroesse: Flaeche 

+ darstellen_Icons () 

+ maximieren () 

+ minimieren () 

# create () 

+ veraendern_Groesse (offsetX, offsetY) 

+ ausgeben_Flaeche () : Flaeche 

Spezifikation 

Beschreibung... 

OOAD, Dr. Eicke Godehardt WS2012/13, h_da, Fachbereich Informatik 133 

Typ 

Parameter 

Initialisierung 

Rückgabewert-Typ


Darstellung von Klassen, Attributen und Methoden (II) 

n� Klassenmethode: 

ð� Bezieht sich nicht auf Instanz (Instanzmethode) sondern auf die Klasse als die 

Menge aller ihrer Objekte z. B. Konstruktor, Berechnung Durchschnittsgehalt etc. 

n� Klassenattribute: 

ð� Attributwert ist nicht einer Instanz (Instanzattribut) sondern der Klasse 

zugeordnet und existiert nur 1x für die Klasse, z. B. maxGeschwindigkeit eines 

Fahrzeugtyps. 

n� Spezifikation: 

ð� Text, der die Verantwortlichkeit/den Zweck einer Klasse, eines Attributs oder 

einer Methode beschreibt 

n� Methoden für das Schreiben und Lesen von Attributen: 

ð� setXXX, getXXX sind trivial ⇒ werden nicht in die Klassendefinition auf Analyse- 

Ebene aufgenommen 

n� Bei Verwendung eines CASE-Tools: 

ð� Einzelangaben können, um die Übersicht des Gesamtdiagramms zu erhöhen, 

ausgeblendet werden 



Wie findet man Kandidaten für Klassen (und Attribute)? 

n� Aus den Beschreibungen der Anwendungsfälle (Use Cases)! 

ð� Suche nach Substantiven (Kandidaten für Klassen, evtl. Attribute), z. B. 

- Personen, Orte, konkrete Dinge 

(Artikel, Rechnungen, Abteilung, Messwerte etc.) 

- Schnittstellen eines Systems 

(Masken, Anbindungen an Datenbanken etc.) 

- Abstrakte Dinge (ein Algorithmus, eine Information etc.) 

ð� Ordne nach Klassenkandidaten/Attributen zu Klassenkandidaten 

ð� Sondere überflüssige Klassenkandidaten aus! 

Ist Kunde eine eigene Klasse oder nur eine Rolle in einer gemeinsamen Klasse? 

(z. B. Klasse Person mit Rollen: Kunde, Vorgesetzter etc.) 

ð� Ergänze später im Lauf der Modellierung 

fehlende Klassen fallen auf, wenn man mit dem Modell arbeitet 



Wie findet man weitere Attribute und Methoden ? 

n� Attribute und Methoden ergeben sich aus 

ð� Beobachtungen des Anwendungsgebiets (der „Domäne“) 

- Attribute: Eigenschaften der Objekte 

- Methoden: Operationen auf den Objekten 

ð� oder aus der Analyse von Vorgängersystemen 

- Attribute: Einträge in Formularen, Bildschirmmasken, Datenmodell etc. 

- Methoden: Aktionen und Buttons in Formularen, Bildschirmmasken etc. 

ð� oder aus Anwendungsfällen (Use Cases) 

- Attribute: z. B. ...für jeden Kunden wird das Alter erfasst... 

- Methoden: Suche Verben, die Aktionen auf den Objekten ausführen 

ð� und auch bei der Weiterarbeit mit dem Modell 

- fehlende Attribute und Methoden fallen auf, wenn man mit dem Modell arbeitet 



Wie findet man Klassen, Operationen und Attribute? Beispiel 

n� Aus der Beschreibung eines Anwendungsfalls: 

Ein Dauerauftrag überweist einen bestimmten Betrag in regelmäßigen 

Zeitabständen von einem Girokonto auf ein Anderes. 

Der Dauerauftrag gehört immer zu einem bestimmten Girokonto. Daueraufträge 

können angelegt und wieder gelöscht werden. 

ð� Dauerauftrag 

ð� Betrag 

ð� Zeitabstand 

ð� Girokonto 

ð� Anderes (Girokonto) 

ð� Überweisen 

ð� Anlegen 

ð� Löschen 

Klasse 

Attribut in Klasse Dauerauftrag 

Attribut in Klasse Dauerauftrag 

Klasse!? Assoziation von Dauerauftrag? Oder Attribut? 

Assoziation von Dauerauftrag? Oder Attribut? 

Operation in Klasse Dauerauftrag? Oder Girokonto? 

Operation in Klasse Dauerauftrag? Oder Konstruktor? 

Operation in Klasse Dauerauftrag? Oder Destruktor? 





5.1.2 Darstellung der Statik eines Systems: 

Generalisierung, Spezialisierung und Vererbung 


5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung 

Grundidee Generalisierung 

n� Aus der Menge der Klassen sucht man 

nach Klassenpaaren wobei: 

ð� Die eine Klasse („Superklasse“) ist 

ein allgemeiner Typ und die 

andere Klasse („Subklasse“) ist ein 

spezieller Typ, der die 

Superklasse erweitert 

ð� Es besteht eine Ist-Ein-Beziehung! 

ð� Ein Objekt der Superklasse ist 

durch ein Objekt der Subklasse 

ersetzbar! 

ð� Unter der Subklasse ist eine 

Teilmenge der Menge der 

Instanzen der Superklasse 

angesiedelt 

Konto 

Kontonummer 

KontoStand 

GeldAbheben 

GeldEinzahlen 

Girokonto 

Kontonummer 

KontoStand 

ÜberziehungsLimit 

Sparkonto 

Kontonummer 

KontoStand 

Sperrfrist 

GeldAbheben 

GeldEinzahlen 

SetzeSperrfrist 

LeseSperrfrist 

GeldAbheben 

GeldEinzahlen 

PrüfeÜberziehungsLimit 

SetzeÜberziehungsLimit 

LeseÜberziehungsLimit 



Begriffe 

n� Generalisierung: 

ð� „Ist-ein-Beziehung“ von der Subklasse aus gesehen. 

ð� Ein Konto ist ein (verallgemeinertes) Girokonto 

n� Spezialisierung: 

ð� „Ist-ein-Beziehung“ von der Superklasse aus gesehen 

ð� Ein Girokonto ist ein (spezialisiertes) Konto 

ð� Die spezielle Klasse besitzt alle 

Merkmale der Superklasse 

n� Vererbung: 

ð� ist ein Konzept der Programmierung. 

Die Subklasse übernimmt („erbt“) 

alle Merkmale von der Superklasse 

Girokonto 

ÜberziehungsLimit 

Konto 

Kontonummer 

KontoStand 

GeldAbheben 

GeldEinzahlen 

PrüfeÜberziehungsLimit 

SetzeÜberziehungsLimit 

LeseÜberziehungsLimit 

ð� Die Subklasse besitzt alle Merkmale (Attribute, Operationen, Assoziationen, 

Aggregationen) der Superklasse und noch zusätzliche Merkmale 

Sparkonto 

Sperrfrist 

SetzeSperrfrist 

LeseSperrfrist 

GeldAbheben 



Beispiel: Vererbungshierarchie 

Pumpe 

Ansaugdruck 

Auslassdruck 

Durchflussmenge 

Zentrifugalpumpe 

Schaufeldurchmesser 

Zahl der Schaufeln 

Rotationsachse 

Gerät 

Name 

Hersteller 

Gewicht 

Preis 

Wärmetauscher 

Oberfläche 

Behälterdurchmesser 

Behälterlänge 

Behälterdruck 

Manteldruck 

Membranpumpe 

Membranmaterial 

... 

Welche Attribute 

besitzt eine 

Membranpumpe ? 

Kolbenpumpe 

Kolbenlänge 

Kolbendurchmesser 

Zahl der Zylinder 

Pumpe, Tank, etc. als 

spezielle Geräte mit 

Zusatzeigenschaften 

Tank 

Volumen 

Druck 

Durchmesser 

Höhe 

... 



Lösung: Welche Attribute besitzen die Objekte der Klassen? 

Instanzen: 

:Membranpumpe 

Name = P101 

Hersteller = Simplex 

Gewicht = 100 kg 

Preis = 8.000 € 

Ansaugdruck = 1,1 atm 

Auslassdruck = 3,3 atm 

Durchflussrate = 300 l/h 

Membranmat. = Teflon 

:Wärmetauscher 

Name = E302 

Hersteller = Braun 

Gewicht = 5000 kg 

Preis = 30.000 € 

Oberfläche = 300 m 

Behälterdurchm. = 2 cm 

Behälterlänge = 6 m 

Behälterdruck = 15 atm 

Manteldruck = 1,7 atm 

:Tank 

Name = T111 

Hersteller = Simplex 

Gewicht = 10.000 kg 

Preis = 80.000 € 

Volumen = 400.000 l 

Druck = 1,1 atm 

Durchmesser = 8 m 

Höhe = 9 m 



Sichtbarkeit 

n� Man unterscheidet 4 verschiedene Sichtbarkeitsstufen: 

ð� Public: für alle anderen Klassen sichtbar, d. h. öffentlich 

(in der UML: + ) 

ð� Private: außerhalb der Klasse nicht sichtbar, auch nicht für Unterklassen 

(in der UML: – ) 

ð� Protected: nur für alle Unterklassen sichtbar 

(in der UML: # ) 

ð� Package: nur für Klassen im gleichen Paket („Ordner“) sichtbar 

(in der UML: ~ ) 

n� innerhalb einer Generalisierung-/Spezialisierungshierarchie 

ð� können verschiedene Stufen der Sichtbarkeit eingesetzt werden 

Wegen der Kapselung 

sind Attribute in der 

Regel Private oder 

Protected! 

ð� „kennt“ jede Klasse nur ihre eigenen Attribute, Operationen und Beziehungen 

und die ihrer Oberklassen – sofern diese für sie sichtbar sind 



Regeln 

n� In Subklassen dürfen nicht nur zusätzliche Merkmale 

definiert werden, sondern auch geerbte Merkmale 

überschrieben werden: 

n� Aber: 

- Operationen (Reimplementierung/Polymorphie) 

- Einschränkungen von Attribut-Typen auf Untertypen (int statt float) 

- Einschränkungen der Typen oder Wertebereiche von Argumenten und 

Rückgabewerten von Operationen 

ð� In der Subklasse können Berechnungen spezialisiert werden: 

z. B. kann die Operation GeldAbheben der Klasse Girokonto zusätzlich das 

Überziehungslimit prüfen 

Durch Überschreiben darf nie die Semantik des Attributs bzw. 

der Operation geändert werden! 

(Die Ist-ein-Beziehung darf nie verletzt werden!) 

Wie kann man das in einer 

Programmiersprache 

umsetzen? 



Einschränkungen bezüglich des Überschreibens der Merkmale (I) 

n� Integritätsbedingungen einer Klasse dürfen nicht verletzt werden: 

ð� Wenn eine Klasse eine bestimmt Bedingung vorschreibt, muss diese Bedingung 

in der abgeleiteten Klasse auch gelten 

ð� Beispiel: Ellipse-Kreis – Wer erbt von wem? 

- Eine Ellipse ist keine Spezialisierung eines Kreises, da die Kreiseigenschaft zweier 

gleichlanger Achsen durch die Ellipse verletzt würde. Ein Kreis ist jedoch eine 

spezielle Ellipse, bei der die Achsen gleich lang sind. 

n� Überschreiben von Methoden 

ð� Andere Implementierungen (z. B. Performance-Verbesserung) mit gleicher 

Funktionalität sind erlaubt. 

ð� Die Schnittstelle (Name, Anzahl von Argumenten) der Operation der Superklasse 

muss jedoch eingehalten werden. 

ð� Typen von Argumenten und Rückgabewerten dürfen nur eingeschränkt werden 



Einschränkungen bezüglich des Überschreibens der Merkmale (II) 

n� Der Typ eines Attributs der Subklasse muss vom Typ der Superklasse 

isomorph umschlossen sein 

ð� z. B.: Superklasse Attribut von Typ REAL 

in Subklasse Attribut von Typ INTEGER 

ð� z. B.: Superklasse Attribut von Typ der Klasse KONTO 

in Subklasse Attribut von Typ einer Subklasse 

von KONTO (z. B. GIROKONTO) 

n� Der Wertebereich von Attributen darf eingeschränkt, 

jedoch nicht erweitert werden 

ð� z. B.: Superklasse Mitarbeiter: Gehalt 1... 150.000,- € 

Subklasse Arbeiter: Gehalt 1... 80.000,- € 



Gleiche Eigenschaften – aber keine Generalisierung 

n� 2 Klassen haben gleiche Attribute, Operationen... 

ð� Dann kann man die gemeinsamen Merkmale in eine Superklasse extrahieren!? 

n� Achtung! Es muss eine „ist-ein-Beziehung“ bestehen! 

ð� Die Generalisierung darf nicht zur reinen Vereinfachung der Implementierung 

missbraucht werden! 

n� 1. Beispiel: Klasse Rollstuhl und Klasse Kraftfahrzeug: 

ð� Gleiche Attribute: Gewicht, Anzahl Räder, Farbe; Operation: fortbewegen 

ð� Kraftfahrzeug besitzt zusätzliches Attribut kW 

ð� Aber: trotzdem ist ein Kraftfahrzeug keine Spezialisierung eines Rollstuhls. 

n� 2. Beispiel: Klasse See und Klasse Papierformat: 

ð� Gleiche Attribute: Breite und Länge 

ð� Dieselben Attribute, aber: 

es liegt keine „ist-ein-Beziehung“ vor; aus semantischer Sicht 

haben die Klassen keine (sinnvolle) gemeinsame Superklasse 



Darstellung von Randbedingungen für Vererbung/Mehrfachvererbung 

Constraints 

{overlapping, complete} 

Fahrzeug 

Luftfahrzeug Landfahrzeug Wasserfahrzeug 

{disjoint, incomplete} {disjoint, incomplete} 

Lastwagen 

Amphibienfahrzeug 

Segelboot 

Default: {overlapping, incomplete} – wird meist weggelassen 

Constraints 






Spezielle Klassen 


5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen 

Abstrakte Klassen (I) 

n� Eine abstrakte Klasse ist eine spezielle Art von Klasse, von der niemals 

Instanzen erzeugt werden; sie ist bewusst unvollständig und bildet die Basis für 

weitere Unterklassen, die Exemplare haben können 

n� Eine abstrakte Klasse 

ð� beinhaltet mindestens eine abstrakte Operation 

ð� wird in C++ durch eine Klasse umgesetzt, die mindestens eine pure virtual 

Methode enthält 

ð� kann Default-Implementierungen enthalten 

n� Wozu ? 

ð� um davon andere Klassen abzuleiten! 

Abstrakte Klassen werden durch das 

Schlüsselwort abstract markiert – oder 

auch durch Kursivschreiben des Namens! 

ð� Klassenhierarchien sind „Begriffshierarchien“ – abstrakte Klassen definieren 

Oberbegriffe für Klassenhierarchien und setzen somit Begriffe und Standards fest 

ð� Abstrakte Klassen definieren den Kern einer Klassenhierarchie, d. h. die 

zentralen Gemeinsamkeiten! 



Abstrakte Klassen (II) 

n� Klassen, die nicht abstrakt sind und Instanzen bilden können, werden 

konkrete Klassen genannt. 

n� Konkrete Klassen, die von abstrakten Klassen erben, definieren alle abstrakten 

Operationen ihrer Superklassen, d. h. sie implementieren Methoden dafür. 

ð� Polymorphie 

gleiche Methoden anwendbar auf unterschiedliche Objekte 

(innerhalb einer Vererbungshierarchie) 

ð� dynamisches/spätes Binden 

Die Verknüpfung zwischen Methodenaufruf und Methodenimplementierung findet 

erst zur Laufzeit statt 

(Wird nicht von allen Sprachen unterstützt!) 



Abstrakte Klassen (Beispiel) 

{overlapping, complete} 


{disjoint, incomplete} {disjoint, incomplete} 

Lastwagen 

fortbewegen() 

Fahrzeug 

{abstract} 

fortbewegen() {abstract} 

Amphibienfahrzeug 

fortbewegen() 

Segelboot 

fortbewegen() 



Schnittstelle: Definition 

n� Eine Schnittstelle (Interface) ist ein Modellierungselement, das mit Signaturen 

einen ausgewählten Teil eines extern sichtbaren Verhaltens beschreibt. 

Es gibt bereitgestellte und benötigte Schnittstellen. 

n� Ein Schnittstelle 

ð� legt durch Signaturen eine Schnittstelle für mehrere Klassen fest 

ð� kann nicht instanziiert werden 

ð� beinhaltet keine Implementierung 

ð� ist mit dem Stereotyp «interface» im Kopf gekennzeichnet 

ð� enthält in der Regel keine Attribute (darf es aber prinzipiell) 

ð� wird in C++ durch eine Klasse umgesetzt, die nur pure virtual Methoden enthält 

ð� wird realisiert, indem Klassen von der Schnittstellen ableiten und dann die 

Methoden implementieren 



Schnittstelle: Notation 

n� Bereitstellung und Verwendung einer Schnittstelle 

n� oder alternativ 

Anbieter 

bereitgestellte 

Schnittstelle 

«interface» 

Anbieter Nutzer 

Schnittstelle_A 

« implements » 

Schnittstelle_A 

hängt ab von 

Nutzer 

benötigte 

Schnittstelle 

« depends » 



Schnittstelle: Zweck 

n� Wozu ? 

ð� Schnittstellen definieren einen Teil der Außenschnittstelle, 

d. h. eine Zugriffsmöglichkeit, die mehrere Klassen gemeinsam nutzen 

ð� Es werden Operationen (und nicht die Methoden!) definiert, wobei die Aufrufer 

der Operationen zum Zeitpunkt der Definition der Schnittstelle evtl. noch nicht 

bekannt sind 

n� Beispiel 

ð� Wenn Sie unter Windows ein Programm schreiben, das sich an die normalen 

Mechanismen zur Umschaltung von Fenstern halten soll, müssen Sie bestimmte 

Methoden implementieren, damit das Verschieben und Überlappen der Fenster 

funktioniert (z. B. redraw) 

Diese Methoden sind in einem Interface innerhalb Windows definiert – aber die 

Implementierung müssen Sie machen! 

Windows 

Iwindow 

MyApp 



Schnittstelle: Beispiel 

Mensch 

fortbewegen() 

«interface» 

Bewegung 

fortbewegen() 

Vogel 

fortbewegen() 

Segelboot 

fortbewegen() 

Erkennen Sie den Unterschied zwischen 

Schnittstellen und abstrakten Klassen? 

Fahrzeug 

{abstract} 

fortbewegen() {abstract} 

abstrakte Klasse 




Schnittstelle oder abstrakte Klasse? 

n� Eine abstrakte Klasse, die ausschließlich abstrakte Methoden enthält, 

ist identisch zu einer Schnittstelle 

ð� auch wenn die Konzepte sehr ähnlich sind, gibt es grundlegende Unterschiede 

Kern oder Rand 

Implementierung 

von Methoden 

Erweiterung der 

Funktionalität um 

eine neue Methode 

Schnittstelle Abstrakte Klasse 

Schnittstellen definieren die 

Außenschnittstelle einer Klasse, 

d. h. lediglich eine 

Zugriffsmöglichkeit, die mehrere 

Klassen nutzen können 

kein Code erlaubt; lediglich 

Festlegung von Signaturen 

Alle Implementierungen der 

Schnittstelle müssen aufgefunden 

und um die neue Methode erweitert 

werden 

Abstrakte Klassen beschreiben den 

Kern einer Vererbungshierarchie, 

den alle Spezialisierungen 

gemeinsam haben 

Code ist erlaubt; kann von erbenden 

Klassen überschrieben werden 

Durch Vererbung einer Default- 

Implementierung können alle 

erbenden Klassen leicht mit einer 

Implementierung versorgt werden 

Auszug aus: Rahman Mahmoodi "Abstract Class versus Interface" 



Parametrisierte Klassen (Templates) (I) 

n� Eine parametrisierbare Klasse ist eine mit 

generischen formalen Parametern versehene 

Schablone, mit der gewöhnliche (d. h. nicht- 

generische) Klassen erzeugt werden können. 

Die generischen Parameter dienen als Stell- 

vertreter für die echten Parameter, die 

Klassen oder einfache Datentypen 

repräsentieren. 

Fixed_List 

wurzel: T* 

cursor: T* 

eintrag T [0 .. max] 

n� Beispiel: 

Die parametrisierte Klasse Fixed_List hat die generischen Parameter T und max 

(eine Integerzahl). Eine Konkretisierung dieser Klasse muss max und T mit 

entsprechenden Daten belegen. Zum Beispiel max als 5 und T als int 

n� Anwendung: 

Standardalgorithmen und Datenstrukturen mit variablen Datentypen, 

z. B. Graphen, Bäume, Listen, Sortierungen, Suche 


... 

T, 

max: int


Parametrisierte Klassen (Templates) (II) 

n� Eine parametrisierte Klasse kann nicht direkt von anderen Klassen benutzt 

werden. Ihre generischen Parameter müssen erst an einen konkreten Typ 

„gebunden“ werden. Diese gebundenen Klassen können dann von anderen 

Klassen assoziiert werden. 

n� Bei der Definition einer Instanz einer parametrisierten Klasse müssen die 

Parameter konkretisiert werden. Zur Compilierzeit sind die möglichen Typen 

bekannt. 

FesteZahlen 

Liste 

«bind» 

< T -> int, max->20 > 

Fixed_List 

wurzel: T* 

cursor: T* 

eintrag T [0.. max] 

... 

FestePersonen 

Liste 

«bind» 

< T -> Person, max->100 > 

T, max: int 






Durchgängiges Beispiel 


5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel 


n� In diesem Abschnitt werden die theoretisch eingeführten Konzepte mit Hilfe 

eines Beispiels detailliert erläutert. Das Beispiel ist so gewählt, dass es durch 

das gesamte Kapitel weiterentwickelt und zu einem konsistenten 

objektorientierten Modell integriert wird. 

n� Die aufeinander aufbauenden Teile des Beispiels in den einzelnen Abschnitten 

sind so formuliert, dass die Ziele, die zu erreichen sind, in Form einer 

Aufgabenstellung beschrieben werden. Danach folgt die fachliche Beschreibung 

der zu modellierenden Inhalte. 

n� Sie sollten die Lösung selbst erarbeiten. 

Die Lösung wird aber direkt im Anschluss präsentiert. 



Aufgabe 

n� Analysieren Sie die nachfolgenden verbal formulierten Anforderungen an das 

System „Hochschulverwaltung“: 

ð� Identifizieren Sie die Klassen des Problembereichs (Domäne) und ihre Attribute 

durch Textanalyse. 

ð� Identifizieren Sie die Generalisierungs-/Spezialisierungs-Beziehungen zwischen 

den Klassen. 

ð� Integrieren Sie die Klassen zu einer Vererbungshierarchie (Klassendiagramm). 

n� Anforderungen: 

ð� In einer Hochschulverwaltung sind mehrere Personengruppen tätig. Die 

Hochschule hat Angestellte, die Professoren, Labor-Ingenieure, Lehrbeauftragte, 

Sekretärinnen oder Tutoren sein können. An einer Hochschule studieren 

Studenten, die auch als Tutoren in einzelnen Lehrveranstaltungen eingesetzt 

werden können. Jede Person hat einen Namen, Geburtsdatum und Geburtsort. 

Alle Angestellten verfügen über ein Gehaltskonto. Dozenten haben einen 

akademischen Titel und leisten pro Semester eine bestimmte Anzahl 

Semesterwochenstunden (SWS). 

Jeder Student hat eine identifizierende Matrikelnummer. 



Lösungsweg zu den Klassen und Attributen 

n� Zur Identifizierung der Klassenkandidaten wird zunächst eine Liste aller 

Substantive der Problembeschreibung erstellt: 

ð� ð� ð� Hochschulverwaltung, Personengruppen, Hochschule, Angestellte, Professoren, 

Labor-Ingenieure, Lehrbeauftragte, Sekretärinnen, Tutoren, Studenten, Person, 

Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Dozenten, Titel, Semester, Semester, Anzahl, 

Semesterwochenstunden, Anzahl, Semesterwochenstunden, Matrikelnummer. 

Matrikelnummer 

n� Dann werden überflüssige Begriffe (redundant oder irrelevant) eliminiert: 

ð� Hochschulverwaltung, Personengruppen, Hochschule, Semester, Anzahl 

n� Folgende Begriffe werden als Klassenkandidaten eliminiert, weil sie 

Eigenschaften (Attribute) anderer Substantive (Klassenkandidaten) bezeichnen: 

ð� Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Titel, 

Semesterwochenstunden, Matrikelnummer. 



Lösung: Klassen und Attribute 

n� Daraus ergibt sich dann folgende grobe Klassenstruktur mit Attributen 

Klasse Attribute 

Person Name, Geburtsdatum, Geburtsort 

Student Matrikelnummer 

Angestellter Gehaltskonto 

Tutor 

Dozent Titel, Semesterwochenstunden 

Sekretärin 

Labor-Ingenieur 

Professor 

Lehrbeauftragter 

Studentischer Tutor 

ð� Selbstverständlich haben noch andere Klassen Attribute. Diese sind aber den 

Dokumenten (Anforderungen), die in dieser Projektphase (Analyse) vorliegen, noch 

nicht zu entnehmen. Deswegen werden sie zunächst offen gelassen und in 

späteren Projektphasen ergänzt (iterativer Entwicklungsprozess). 



Zwischenschritt: Darstellung der Klassen 

Student 

# Matrikelnr : Integer 

studentischer 

Tutor 

Person 

# Name : String 

# GebDatum : Datum 

# Geburtsort : String 

Tutor 

{abstract} 

Dozent 

{abstract} 

# akademTitel : String 

# SWS : Integer 

+ Vergütung () {abstract} 

Angestellter 

{abstract} 

# Gehaltskonto 


Professor Lehrbeauftragter 

Sekretärin 

Gibt es 

Generalisierungsbeziehungen? 

Lab-Ing 



Lösung als Klassendiagramm 

Student 


studentischer 

Tutor 

Person Person {abstract} 




Tutor 

{disjoint, complete} 

Dozent 

{abstract} 




Angestellter 

{abstract} 

# Gehaltskonto 


Professor Lehrbeauftragter 

{overlapping} 

Sekretärin 

Lab-Ing 



Offene Punkte 

n� Was passiert, wenn ein Student eine Tutorenstelle annimmt? 

ð� Das Objekt „Student“ müsste zerstört und ein neues Objekt der Klasse 

„StudentischerTutor“ erzeugt und mit denselben Daten belegt werden. 

n� Was passiert, wenn ein Labor-Ingenieur einen Lehrauftrag erhält? 

ð� dann stimmt das „disjoint“ nicht mehr 

ð� es gibt keine Klasse für diese Konstruktion 

Wie können diese Sachverhalte geschickter modelliert werden? 



Zwischenstand Klassen(diagramme) 

n� Klassendiagramme – behandelte Themen 

ð� Finden von Klassen 

ð� Bestandteile einer Klasse (Attributen und Operationen) 

ð� Sichtbarkeit 

ð� Vererbung/Generalisierung/Spezialisierung 

ð� Abstrakte Klasse 

ð� Schnittstelle 

ð� Parametrisierte Klasse 

ð� Offen: welche Beziehungen gibt es außer der Vererbung zwischen Klassen? 






Assoziationen 


5.1.5 Darstellung der Statik eines Systems: Assoziationen 

Grundidee 

n� Beobachtung: 

ð� Zwischen Objekten gibt es häufig Beziehungen – die Objekte „kennen sich“ 

ð� Viele der Beziehungen gelten für alle Objekte einer Klasse 

n� Idee: Abstrahiere gleichartige Beziehungen zwischen Objekten 

zu Beziehungen zwischen Klassen! 

(analog zur Abstraktion von gleichartigen Objekten zu Klassen) 

n� „Assoziationen“ 

ð� stellen logische Beziehungen zwischen Klassen dar; 

die Klassen „kennen sich“ 

ð� sind Verknüpfungsmöglichkeiten zwischen Objekten dieser Klassen 

ð� definieren ebenso mögliche Kommunikationswege zwischen Objekten der 

Klassen. 



Notation am Beispiel 

Leserichtung 

Navigationsrichtung 

Name der Assoziation 

Multiplizität 

* arbeitet für 

1..* 

Firma Person 

Arbeitgeber 

Rolle 

Arbeitnehmer 

ð� 1 Person (als Arbeitnehmer) arbeitet für 0..n Firmen (als Arbeitgeber) 

ð� 1 Firma (als Arbeitgeber) beschäftigt 1..n Personen (als Arbeitnehmer) 

ð� 1 Person (als Vorgesetzter) ist vorgesetzt für 0..n Personen (als Untergebene) 

ð� 1 Person (als Untergebener) hat 0..1 Personen als Vorgesetzten 

Vorgesetzter 


0..1 

* 

Untergebener 

ist 

vorgesetzt

Interpretation des Beispiels mit Objekten 

n� Betrachten Sie die folgenden Objekte 

Employer Inc.: Firma 

MoD : Firma 

W. Orker ist Vorgesetzter 

von I. N. Dianer, aber I. N. 

Dianer arbeitet gar nicht für 

die gleiche Firma. 

Vom Modell her ok, wenn 

auch fachlich eher falsch. 

(Lösung später durch 

„Constraints“) 

h_da: Firma 

arbeitet für 

B. Igboss: Person 

W. Orker : Person 

I. N. Dianer: Person 

T. Unix: Person 

P. Rof: Person 

A.R. Beitslos: Person 

ist 

vorgesetzt 

ist 

vorgesetzt 

Person ohne Vorgesetzten 

2 Personen bei der gleichen 

Firma ohne Assoziation 

untereinander 

Person ohne Vorgesetzten 

und ohne Firma 



Navigationsrichtungen bei Assoziationen 

n� Bei der Modellierung des dynamischen Verhaltens (Entwurf der Kommunikation 

zwischen Klassen) wird festgestellt, in welche Richtung eine 

Assoziationsbeziehung durchlaufen wird. 

ð� Diese Navigationsrichtung kann angegeben werden (offene Pfeilspitze) 

ð� Die Navigationsrichtung gibt beim späteren Programmentwurf Auskunft darüber, 

in welchen Klassen Verweise auf Objekte anderer Klassen angelegt werden 

müssen. 

n� Beispiel: 

unspezifiziert navigierbar 

* 1..* 

Auftrag Artikel 

Nicht mit der 

Leserichtung 

verwechseln! 

ð� Ein Auftrag muss seine assoziierten Artikel kennen 

(z. B. Gesamtsumme berechnen, Nachschauen was disponiert werden muss). 

ð� Es ist noch nicht festgelegt, ob ein Artikel wissen muss in welchen Aufträgen er 

bestellt wurde. 



Notation für Navigationsrichtungen 

n� In UML 1.x steht die Assoziation in Linienform (ohne Pfeilspitzen) 

für eine bidirektionale Beziehung 

ð� es gab keine Möglichkeit auszudrücken, dass man sich über die Richtung 

„noch keine Gedanken gemacht“ hat 

n� In UML 2.x: 

ð� getrennte Notation für „navigierbar“ und „unspezifiziert“ (default) 

Unspezifiziert: 

UML 2! 

geändert ggü. UML 1.x 

1 

Klasse1 

* 

Klasse2 

1 * 

Unidirektional: Klasse1 Klasse2 

1 

Bidirektional: Klasse1 

* 

Klasse2 

Unidirektional 

(einseitig): 

1 * 

Klasse1 Klasse2 

nicht 

navigierbar 

navigierbar 

unspezifiziert 



Multiplizität 

n� Eine Assoziation sagt aus, dass sich Objekte der beteiligten Klassen kennen 

n� Die Multiplizität spezifiziert, wie viele Objekte ein bestimmtes Objekt kennen 

kann 

X 

n 

1 

0..2 

* 

3..* 

genau 1 

0 bis 2 

0 bis viele 

3 bis viele 

m Y Ein Objekt x der Klasse X kennt m Objekte der Klasse Y; 

Ein Objekt y der Klasse Y kennt n Objekte der Klasse X 

Beim Lesen einer Assoziation wird immer die Multiplizität am 

Ausgangspunkt der Beziehung als „1“ gelesen! 



Wie findet man Assoziationen? 

n� a) Dokumentenanalyse 

ð� Verben in Dokumenten (Use Cases, Dokumentationen, Spezifikationen 

Interview-Protokoll etc.) 

ð� Aber: Nicht alle Assoziationen sind für den zu modellierenden Problembereich 

wichtig! 

n� b) Weitere Hinweise auf Assoziationen: 

ð� Verwaltung von Dingen (Firma hat Kunden, Abteilung gliedert sich in Gruppen) 

ð� Besitz (Motor besitzt Benzinpumpe, Auftrag besteht aus Positionen) 

ð� Kommunikation zwischen Objekten 

n� c) In späteren Schritten: 

ð� Bei dynamischer Modellierung wird die Kommunikation zwischen Klassen 

dargestellt: 

- Kommunikation läuft über vorhandene Assoziation – oder auch nicht 

Falls nicht ð� oft zusätzliche Assoziation! 



Modellierung 

n� Regeln: 

ð� Verbindungen zwischen Objekten stets als Assoziation modellieren 

(und nicht als Zeiger-Attribut)! 

- übersichtliche Darstellung 

- das Modell bleibt unabhängig von den Fähigkeiten der Programmiersprache 

ð� Voneinander unabhängige Beziehungen können (und sollten) durch mehrere 

Assoziationen (mit gleicher Quelle und gleichem Ziel) ausgedrückt werden 

- durch Rollen ausdrücken, warum es mehrere Beziehungen gibt 

ð� Multiplizität sollte angegeben werden 

- muss (spätestens) im Design angegeben werden, damit die Coderahmen mit 

entsprechenden Attributen generiert werden können 

ð� Implementierung erfolgt erst später (auf niedrigerer Abstraktionsebene) 

ð� Leserichtung immer angeben, wenn sie von links → rechts bzw. oben → unten 

abweicht 



Übung „Linien und Schnittpunkte“ 

n� Entwickeln Sie ein Klassendiagramm zur Darstellung von Linien, die sich in 

Schnittpunkten schneiden können. 

L5 

L3 

L1 

L2 

P1 

P3 

P2 


L4


„Linien und Schnittpunkte“: Analyse des Problems 

n� 1) Klassen und Attribute durch „Suchen der Substantive“ 

Schnittpunkt Linie 

Name Name 

n� 2) Erweiterung um Assoziationen 

Schnittpunkt schneidet 

Linie 

Name Name 



Assoziationen (Vorarbeit durch Betrachtung der Objekte) � Objektdiagramm 

L1 : Linie 

L2 : Linie 

L3 : Linie 

L4 : Linie 

L5 : Linie 

P1: 

Schnittpunkt 

P2: 

Schnittpunkt 

P3: 

Schnittpunkt 



„Linien und Schnittpunkte“: Lösung als Klassendiagramm 

n� 3) Multiplizitäten aus dem Beispiel extrahieren: 

ð� Die Linien und Schnittpunkte sind Exemplare der Klassen „Linie“ und 

„Schnittpunkt“. Die Linien L1, L3 und L4 besitzen jeweils zwei Schnittpunkte mit 

anderen Linien (P1,P3 bzw. P1,P2 bzw. P3,P2), L2 hat einen Schnittpunkt, L5 

hat keinen Schnittpunkt. P2 und P3 haben 2 Linien, Schnittpunkt P1 hat 3 Linien. 

Schnittpunkt 0..2 ? schneidet 2..3 

? Linie 

Name Name 

n� 4) Abstraktion: 

ð� 2 Linien können aufeinander liegen (haben unendlich viele Schnittpunkte) 

ð� beliebig viele Linien können durch einen Schnittpunkt gehen 

Schnittpunkt ? * schneidet 2..* ? Linie 

Name Name 


Ein Problem 

n� Die bisherige Modellierung von Person und Firma soll so erweitert werden, dass 

ein Gehalt verwaltet und Urlaub beantragt werden kann 

ð� Betrachten Sie das Attribut Gehalt und die Methode Urlaub_beantragen() 

ð� Wie und wo sollten diese Elemente modelliert werden? 

ð� Denken Sie daran, dass eine Person in mehreren Firmen arbeiten kann! 

Employer Inc.: Firma 

MoD : Firma 

arbeitet für 

Gehalt 

Urlaub_beantragen() 

B. Igboss: Person 

W. Orker : Person 

I. N. Dianer: Person 

ð� Diese Attribute und Methoden gehören jeweils zu der 

Assoziation zwischen einer Firma und einer Person! 

ist 

vorgesetzt 

ist 

vorgesetzt 



Assoziationsklassen 

n� Es gibt Attribute und Operationen, die vom Vorhandensein einer Assoziation 

abhängig sind. In anderem Kontext sind sie nicht nötig. 

- Person bekommt das Gehalt nur/kann nur dann Urlaub beantragen, wenn sie 

angestellt ist und zwar von der Firma, bei der sie angestellt ist. 

- Gehalt, Urlaub_beantragen sind Merkmale der Assoziation. 

ð� auch Assoziationen können Merkmale, d. h. Attribute und Operationen besitzen. 

ð� „Assoziationsobjekt“ 

n� Die Merkmale existieren für jede einzelne aufgebaute Verbindung zwischen zwei 

Objekten dieser Klassen genau einmal 

n� Abstraktion zur „Assoziationsklasse“ im Klassendiagramm 



Darstellung einer Assoziationsklasse 

* arbeitet _für 1..* 

Firma Person 

Arbeitgeber 

Anstellung 

Gehalt 

Urlaub_beantragen() 

Arbeitnehmer 

Vorgesetzter 

n� Bemerkung: 

ð� Auch wenn jede Person in genau einer Firma arbeiten würde, gehören Gehalt 

und Urlaub_beantragen semantisch zur Assoziation 


0..1 

* 

Untergebener 

ist_ 

vorgesetzt 

Assoziationsklasse


Durchgängiges Beispiel – Fortsetzung 

n� Die bisher modellierte Vererbungshierarchie ist korrekt, jedoch bezüglich 

Flexibilität und Wiederverwendung ungünstig modelliert: 

ð� Wird ein Objekt der Klasse Student erzeugt, so müsste dieses Objekt seine 

Klasse wechseln, sobald der Student Tutor wird. Nach der bisher modellierten 

Hierarchie müsste das Objekt zerstört und ein neues Objekt der Klasse 

StudentischerTutor erzeugt und mit denselben Daten belegt werden. 

ð� Der Unterschied zwischen den Personengruppen (im Hinblick auf ein 

Hochschulverwaltungssystem) besteht in der Art der Vergütung. 

Die Vergütung taucht aber nur „versteckt“ als Methode auf. 

ð� Nachdem wir Assoziationen und Assoziationsklassen kennengelernt haben, 

können wir durch ein geschicktes Design der bisherigen Klassenhierarchie 

dieses Problem beseitigen. 



Durchgängiges Beispiel (Lösung mit Assoziationen) 

Student 


Person 




FH_Person 

+ Vergütung () 

Dozent 



Die Klassen (Sekretärin etc.) sind in diesem 

Diagramm nicht dargestellt, weil es hier um die 

Aufteilung zwischen Person und Gehalt geht! 

* 

Gehaltskonto 

0..1 

Professor 

Vergütung 


Vergütung 

{abstract} 


Lehrbeauftragten 

Vergütung 


Es gibt Personen, 

Vergütungen – und 

Beziehungen dazwischen 

BAT 


Tutor 

Vergütung 




Randbedingungen für Assoziationen (Constraints) 

n� Zu Assoziationen können Randbedingungen hinzudefiniert werden. 

ð� Eine Randbedingung ist eine zusätzliche Information zum vorhandenen 

Modellelement, um es konsistent zu machen. 

ð� Constraints geben Bedingungen für die Implementierungsphase. 

n� Beispiel 1: 

Bei einem Polygon kommt es auf die Reihenfolge der Punkte an 

0..1 

wird_definiert 

Polygon Punkt 

{ordered} 


3..*


Randbedingungen für Assoziationen (Beispiel) 

n� Randbedingungen mit langem Text können als Kommentar angegeben werden 

ð� z. B.: Der Vorgesetzte und dessen untergebener Arbeitnehmer müssen bei 

demselben Arbeitgeber beschäftigt sein. 

Arbeitgeber 

Firma Person 

Randbedingung formuliert in OCL 

(Object Constraint Language) 

Anstellung 

Arbeitnehmer 

* arbeitet _für 1..* 

Gehalt 

Urlaub_beantragen 

{ Person.Arbeitgeber = 

Person.Vorgesetzter.Arbeitgeber 

Vorgesetzter 


} 

1 

* 

Untergebener 

ist_ 

vorgesetzt


Durchgängiges Beispiel (mit Constraints) 

n� Unsere bereits veränderte Vererbungshierarchie des ersten 

Klassenhierarchieentwurfs kann nun durch die Verwendung von selbstdefinierten 

Constraints vollständig und widerspruchsfrei modelliert werden. 

n� Es ist klar, dass nicht jedes Objekt willkürlich mit jedem Gehalt kombiniert 

werden kann. Durch ein entsprechendes Constraint sind nun (gemäß der 

Aufgabe eines Modells) alle Regeln des Anwendungsbereichs widergespiegelt 

und hinreichende Vorgaben für die Implementierung gegeben. 



Durchgängiges Beispiel (Lösung mit Constraints) 

Student 


Person 




FH_Person 

Dozent 



Gehaltskonto 

typeOf (Student.Vergütungsberechnung) = Tutorvergütung 

typeOf (FH_Person.Vergütungsberechnung) = BAT 

typeOf (Dozent.Vergütungsberechnung) ∈ (ProfessorVergütung, 

LehrbeauftragtenVergütung) 

* 

Professor 

Vergütung 


Vergütungs 

berechnung 

{abstract} 


Lehrbeauftragten 

Vergütung 


Tutor 

Vergütung 


0..1 

BAT 


+ Vergütung ()


Ternäre und höherwertige Assoziationen: Beispiel 

n� An einer Assoziation können auch mehr als zwei Klassen beteiligt sein. 

Torwart Verein Saison S N U GT 

Peter Gleichauf FC Sandberg 1964 10 13 02 12 

Peter Gleichauf FC Sandberg 1966 15 10 00 21 

Fred Hill ASC Altheim 1966 08 06 11 13 

Fred Hill ASC Altheim 1972 21 02 02 01 

Fred Hill SV Rohrstock 1972 14 07 04 16 

Fred Hill FC Sandberg 1970 12 06 07 07 

Verein 

n� Zu einem assoziierten Tripel von 

ð� Spieler, Verein und Saison gibt es eine Statistik 

* 

Statistik 

Siege 

Niederlagen 

Unentschieden 

Gegentore 

Saison 

Torwart 

Spieler 


* 

* 

Ternäre 

Assoziation mit 

Assoziationsklasse


Ternäre und höherwertige Assoziationen 

n� Oft sind vermeintliche 3-er Beziehungen in Wahrheit drei 2-er Beziehungen! 

ð� 3-er und höherwertige Assoziationen sollten, falls möglich, vermieden werden! 

n� Oft gibt es Alternativen zur 3-er bzw. höherwertigen Assoziation 

ð� durch die Einführung einer Klasse statt 3er-Beziehung 




n� Aufgabe: 

ð� Erweitern Sie das bisherige Klassendiagramm des Hochschulverwaltungssystems 

so, dass es die folgenden Klassen und Assoziationen integriert. 

ð� Analysieren Sie zur Identifikation der Klassen und Assoziationen den Text. 

Bestimmen Sie die Multiplizitäten der Assoziationen und benennen Sie die 

Assoziationen und/oder die Rollen, die die beteiligten Klassen in einer Assoziation 

spielen, wenn dadurch die Verständlichkeit des Modells verbessert wird. 


ð� Die Dozenten und die Studenten gehören einem Fachbereich an. 

ð� Studenten nehmen an Lehrveranstaltungen teil, welche die Dozenten halten 

ð� Lehrveranstaltungen werden mit einem benoteten Leistungsnachweis 

abgeschlossen. Besteht ein Student nicht, kann er die Klausur wiederholen 

ð� Studenten werden während der Masterarbeit von einem Professor betreut. 

Thema und Abgabetermin der Masterarbeit sind zu erfassen. Studenten können 

natürlich eine Masterarbeit auch unvollendet abbrechen. 

ð� Lehrveranstaltungen im Semester können von Tutoren mitbetreut werden. 



Durchgängiges Beispiel (überarbeitet) 

Fachbereich 

1 

gehört_FB_an 

Masterarbeitsbetreuung 

Student 

* 

0..1 

Masterstudent Betreuer 

Teilnehmer * 

* 

besucht_ 

Veranstaltung 

Leistung 

Note 

wiederholen 

gehört_FB_an 

Masterarbeit 

Thema 

Abgabe 

abbrechen 

Lehrkörper 

1 * 

Professor 

hält_ 

Veranstaltung 

* 

Lab-Ing 

Sekretärin 

Dozent 

Referent 


1 

Lehrveranstaltung 

Semester 

Raumnummer 

Kurs 

* 

* 

Tutor 

Angestellter 

{abstract } 

* Betreuer 

betreut_ 

Veranstaltung


Durchgängiges Beispiel: Zusatzfragen 

n� Sie sitzen gerade in einer Vorlesung. Wo ist die Beziehung zu Ihrem Professor? 

n� Was verändert sich, wenn 2 Professoren eine Masterarbeit betreuen? 

n� Was verändert sich, wenn wir darstellen wollen, dass Lehrbeauftragte zu 

mehreren Fachbereichen gehören können, Professoren aber nur zu einem? 

n� In Lehrveranstaltungen werden Werte von Attributen redundant gespeichert (In 

der OOAD-LV von Herrn Weber, als auch in der OOAD-LV von Herrn Hahn 

stehen Titel und ECTS). Wie könnte man das vermeiden? 



Spezielle Assoziationen: Aggregation und Komposition 

n� Aggregation/Komposition bedeutet „Teil-von-Beziehung“ (oder „besteht-aus- 

Beziehung“), d. h. ein Objekt ist Bestandteil eines anderen 

Computersystem 

n� Aggregation und Komposition sind 

1 0..1 

1 1..* 1..* 

Motherboard Festplatte 

Netzwerkkarte 

ð� transitiv: A ist Teil von B, B ist Teil von C. Somit ist A Teil von C 

ð� asymmetrisch: A ist Teil von B, aber B ist nicht Teil von A 

Monitor 



Spezielle Assoziationen: Aggregation (Shared Aggregation) 

n� Aggregation: 

ð� Symbol: leere Raute 

ð� spezifiziert Referenz auf das aggregierte Objekt 

ð� Aggregiertes Objekt ist zwar Bestandteil, existiert aber unabhängig vom 

aggregierenden Objekt 

ð� „shared“ Aggregation (kann zu mehreren Objekten gleichzeitig gehören, d. h. die 

Multiplizität darf > 1 sein) 

Monitor 

0..1 

1 

Computersystem 

Mensch 

Verein 

1..* 

1..* 

shared Aggregation 



Spezielle Assoziationen: Komposition (Composite Aggregation) 

n� Komposition 

ð� Symbol: ausgefüllte Raute 

ð� Teilobjekte einer Komposition 

- werden beim Zerstören des „Ganzes-Objektes“ automatisch (kaskadierend) mit 

zerstört 

- dürfen nicht Teil anderer Kompositionen sein 

- dürfen nur von Operationen der „Ganzes-Klasse“ entfernt oder ersetzt werden 

ð� Komposition (= „unshared“ Aggregation) 

Motherboard 

1 

1 

(kann weggelassen werden, da bei 

Composite Aggregation immer 1) 

Computersystem Composite 

Finger 

Mensch 


10 

1


Beispiel: Constraints für Aggregationen 

Auto 

1 

1 

Motor 

Getriebe 

Kupplung 

n� Ohne ein Constraint könnte laut Modell der Motor sowie das Getriebe ein 

anderes Kupplungsexemplar assoziieren als das übergeordnete Auto selbst 

ð� Inkonsistenz im Modell! 

n� Das hinzu definierte Constraint schließt diese Lücke 

1 

1 

1 

Ein Motor und das Getriebe 

müssen, um zu funktionieren, mit 

derselben Kupplung verbunden 

sein. 

Auto.Kupplung = 

Auto.Motor.Kupplung AND 

Auto.Kupplung = 

Auto.Getriebe.Kupplung 



Durchgängiges Beispiel mit Aggregationen 

n� Aufgabe: 

Erweitern Sie das Klassendiagramm der Hochschulverwaltung um die 

nachfolgenden Inhalte 


ð� Ein Fachbereich kann eine Bibliothek und mehrere Labore besitzen, in denen 

Laboringenieure arbeiten 

ð� Jeder Fachbereich beschäftigt in der Verwaltung Sekretärinnen 

ð� Die Laborräume sind zur Vermeidung von Diebstählen mit Sicherheitstüren 

ausgestattet 

ð� Labor-Ingenieure arbeiten in einem bestimmten Labor 



Durchgängiges Beispiel mit Aggregationen (Lösung) 

Bibliothek Labor 

1 

Fachbereich 

1 

Sicherheitstür 

1 

* 

* 

gehört_FB_an 

Masterarbeit 

* 

Student 

* 

1 

* Diplomand Betreuer 

Teilnehmer 

besucht_ 

Veranstaltung 

1 

1 * 

Leistung 

Note 

wiederholen 

Arbeitsplatz 

gehört_FB_an 

Masterarbeit 

Thema 

Abgabe 

abbrechen 

arbeitet_in_Labor 

arbeitet_für_FB * 

Lehrkörper 

Professor 

hält_ 

Veranstaltung 

* 

Dozent 

1 

Lehrveranst. 

Semester 

Raumnummer 

Kursname 

* 

1 

* 

Ansprechpartner 

Sekretärin 

Referent 

Lehrveranstaltungs- 

beschreibung 

Belegnummer 

Titel 

Beschreibung 

* 

Lab-Ing 


* 

beschreibt 

Tutor 

* Betreuer 

betreut_ 

Veranstaltung 

Angestellter 

{abstract }


Durchgängiges Beispiel (Erklärung) 

n� Labors und eine Bibliothek sind Teile eines Fachbereichs, die aber jederzeit 

einem anderen Fachbereich zugewiesen werden können. Daher ist die Teil-von- 

Beziehung eine Aggregation (shared Aggregation) 

n� Eine Sicherheitstür ist fester Bestandteil des Labors und ist deswegen eine 

Komposition (unshared Aggregation) 






Zusammenfassung 


5.1.6 Darstellung der Statik eines Systems: Zusammenfassung 

Schritte zum Entwickeln von Klassendiagrammen 

1. Klassen(kandidaten) finden 

ð� Substantive bestimmen 

ð� überflüssige Begriffe rausfiltern 

ð� Attribute identifizieren 

ð� Methoden über Verben suchen 

2. Vererbungsbeziehungen suchen 

ð� Ähnliche Klassen identifizieren (Aber: „Ist-ein-Regel“ beachten!) 

ð� Evtl. Schnittstellen durch abstrakte Klasse + Vererbung definieren 

3. Assoziationen zwischen Klassen bestimmen 

ð� „Kennt“-Beziehungen: normale Assoziation 

ð� „Besteht aus“-Beziehung: Aggregation bzw. Komposition 

ð� evtl. Leserichtung und Rollen angeben 

ð� Objekte, deren Existenz an einer Assoziation hängt: Assoziationsklasse 

4. Multiplizitäten und Navigationsrichtungen eintragen 



Wert von Klassendiagrammen 

n� Klassendiagramme sind eines der wichtigsten Beschreibungsmittel in der 

Modellierung 

ð� Zur Beschreibung eines (komplexen) Systems werden viele Klassendiagramme 

erstellt 

ð� Tipps: 

- niemals versuchen gleich alles perfekt zu machen; 

auch Klassendiagramme werden iterativ entwickelt 

- Details wie Navigationsrichtungen und Multiplizität erst dann eintragen, 

wenn die Modellierung hinreichend stabil scheint 

- Bei der Modellierung an die Systemgrenze denken! 

Nur das System modellieren – nicht die komplette Außenwelt! 

- immer nur einen Aspekt auf einem Diagramm darstellen; 

wenn das Diagramm nicht mehr auf eine Seite passt – aufteilen! 

- die Begriffe für alle Elemente mit großer Sorgfalt wählen 

- Assoziationen so konkret wie möglich spezifizieren 

- keine unverständlichen Pseudoprogramme in Constraints schreiben 

- es geht (auch) um Verständlichkeit 

- ein Pointer als Attribut einer Klasse ist meist eine falsch modellierte Assoziation 



Notation in UML 2.x (I) 





The image cannot be displayed. Your computer may not 

have enough memory to open the image, or the image may 

have been corrupted. Restart your computer, and then 

open the file again. If the red x still appears, you may have 

to delete the image and then insert it again. 

Klasse 

Ein Klasse kann als Rechteck dargestellt werden, das den 

Klassennamen enthält. Üblicherweise bestehen Klassen aus 

drei Bereichen; der obere Bereich enthält den Namen und 

kann den Stereotyp (z. B. ) und das Paket, zu dem 

die Klasse gehört, enthalten. Im mittleren Bereich werden die 

Attribute angegeben und im unteren Bereich stehen die 

Operationen der Klasse. Laut UML-Spezifikation kann die 

Darstellung einer Klasse zusätzliche Bereiche enthalten. 

Abstrakte Klasse 

Der Name einer abstrakten Klasse wird kursiv geschrieben. 

Alternativ kann die Eigenschaft {abstract} angegeben werden. 

Schnittstelle (Interface) 

Schnittstellen sind Spezifikationen des externen Verhaltens 

von Klassen und beinhalten Signaturen für Operationen und 

Attribute. 



Notation in UML 2.x (II) 


enough memory to open the image, or the image may have 

been corrupted. Restart your computer, and then open the file 

again. If the red x still appears, you may have to delete the 

image and then insert it again. 

Parametrisierte Klasse 

auch Template oder Schablone genannt. Die parametrisierte 

Klasse hat in der rechten, oberen Ecke ein das Klassensymbol 

überlappendes Rechteck, das die Schablonen-Parameter der 

Klasse enthält. Die Funktion, die den Parameter verwendet, wird 

angegeben. Die Klasse, die den Parameter bindet, wird über 

eine gestrichelte Linie mit Pfeil an dem Template verbunden. 

Diese trägt die Bezeichnung . 

Assoziation 

Eine Linie zwischen den Klassen stellt eine Assoziation dar. Eine 

Assoziation ist eine Beziehung zwischen Klassen. Die Objekte 

der Klassen kommunizieren über Assoziationen miteinander. Die 

Assoziation kann einen Namen haben. Ein Pfeil an dem Assoziationsnamen 

gibt die Leserichtung des Namens an. An den 

Assoziationsenden können die Rollen der beteiligten Klassen 

und die Multiplizität angegeben werden. 



Notation in UML 2.x (III) 

The image cannot be displayed. Your computer may not have enough memory to open 

the image, or the image may have been corrupted. Restart your computer, and then open 

the file again. If the red x still appears, you may have to delete the image and then insert 

it again. 

The image cannot be displayed. Your computer may not have enough memory 

to open the image, or the image may have been corrupted. Restart your 

computer, and then open the file again. If the red x still appears, you may have 

to delete the image and then insert it again. 

Gerichtete Assoziation 

Mit einem Pfeil an der Assoziation kann die Navigationsrichtung 

angegeben werden. Der Pfeil drückt die 

Zugriffsrichtung der Objekte aus. Hier: Objekt A greift 

auf B zu, der Zugriff von B auf A ist noch un-spezifiziert. 

Generalisierung/Spezialisierung 

Generalisierungs-/Spezialisierungs-Beziehungen 

werden mit einem Pfeil dargestellt. Die Pfeilspitze zeigt 

auf die Oberklasse. Die Oberklasse gibt ihre Eigenschaften 

an die Unterklassen weiter. 



Notation in UML 2.x (IV) 










Aggregation 

Eine Aggregation drückt eine Teile-Ganzes-Beziehung 

aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die 

Raute befindet sich an dem Ende des Ganzen. Die 

Aggregation ist eine spezielle Art der Assoziation. Da 

das Ganze die Teile enthält, sollten am Assoziationsende 

der Teile ein Navigationspfeil stehen. 

Komposition 

Die Komposition ist auch eine Beziehung, die Teile zu 

einem Ganzen in Beziehung setzt. Die Teile und das 

Ganze sind bei dieser Beziehung existenzabhängig; die 

Teile können nicht ohne das Ganze existieren. Wird das 

Ganze gelöscht, so beenden auch die Teile ihre Existenz. 



Notation in UML 2.x (V) 

The image cannot be displayed. Your computer may not have enough memory to 

open the image, or the image may have been corrupted. Restart your computer, and 

then open the file again. If the red x still appears, you may have to delete the image 

and then insert it again. 






Assoziationsklasse 

Ist eine Klasse von dem Vorhandensein einer Assoziation 

zwischen zwei Klassen abhängig, so kann dies durch eine 

Assoziationsklasse ausgedrückt werden. Die Assoziationsklasse 

beschreibt Eigenschaften, die keiner der an der 

Assoziation beteiligten Klassen sinnvoll zuordenbar sind. 

Die Assoziationsklasse wird über eine gestrichelte Linie mit 

der Assoziation, von der sie abhängt, verbunden. Hat die 

Assoziation einen Namen, dann muss die Assoziationsklasse 

den selben Namen erhalten. Die Assoziationsklasse 

ist ein Analysekonzept. 

Mehrgliedrige Assoziation 

Eine mehrgliedrige Assoziation drückt eine Beziehung 

zwischen mehr als 2 gleichwertigen Klassen aus. Die 

Beziehung wird mit einer Raute markiert. 



Zusammenfassung Klassendiagramme 

n� Klassendiagramme enthalten 

ð� Klassen mit Attributen und Methoden 

ð� Generalisierung/Spezialisierung 

ð� Abstrakte Klasse/Schnittstelle 

ð� Parametrisierte Klasse 

ð� Constraints 

ð� Assoziationen 

- (normale) Assoziationen: einfache, mehrfache 

- Aggregation 

- Komposition 

ð� Navigationsrichtung 

ð� Assoziationsklassen 

ð� Das sind die Elemente im „Modellierungs-Baukasten“ 

– aber wie werden die in Code umgesetzt?

Objektorientierte Analyse und Design - beim Fachbereich Informatik ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?