Objektorientierte Analyse und Design - beim Fachbereich Informatik ...

Hochschule Darmstadt 

Fachbereich Informatik 

Objektorientierte Analyse und Design 

5.2 Umsetzung von UML-Klassen in C++ 

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


Das Grundproblem 

class CTaschenrechner 

{ 

private: 

CSpeicher m_cSpeicher; 

private: 

CEinAusgabe m_cEinAusgabe; 

private: 

CProzessor m_cProzessor; 

public: 

CTaschenrechner(void); 

public: 

void benutze(); 

OOD-Modell Abbildung Coderahmen in 

bestimmter 

Programmiersprache 

(hier C++) 

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

};


Umsetzung von Klassen und Assoziationen 

n� Umsetzung von Attributen, Methoden 

ð� Diese Konstrukte werden von OO-Sprachen direkt angeboten und können 1:1 

umgesetzt werden 

n� Spezialisierung/Generalisierung 

ð� Vererbung 

n� Schnittstellen 

ð� Klassen mit ausschließlich pure virtual Methoden 

n� Umsetzung einfacher Assoziationen 

ð� Realisierung über Attribute mit Referenz(en) auf ein anderes Objekt 

- Multiplizität = 0..1, 1..1 ein Zeiger 

- Multiplizität = 0..*, 1..* Verweis auf eine Menge von Objekten über Zeiger 

(Container-Klasse, z. B. Menge, Liste, Bäume, 

statische und dynamische Arrays, Hash-Tabellen) 

- Name des Attributes = Rollenname/Name der assoziierten Klasse 

Automatische Umsetzung durch Code(rahmen)generator ist möglich! 

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


Assoziationen als Klassenattribute 

n� Umsetzung Dozent und Veranstaltung aus unserem Beispiel 

generierbar 

1 

Gehaltene_Veranstaltung 

* 

Dozent Veranstaltung 

Dozent 

Liste 

gehaltene_Veranstaltung 

... 

Veranstaltung* 

getVeranstaltung() 

... 

Referent 

... 

...und wie sieht der C++ Code aus? 

Veranstaltung 

Dozent* Referent : 

Dozent* getReferent () 

... 


... 

generierbar


Assoziationen als Klassenattribute in C++ 

// Spezifikation von Veranstaltung 

class Veranstaltung { 

} 

protected: 

public: 

... 

Dozent* Referent; 

// Spezifikation von Dozent 

class Dozent { 

protected: 

public: 

... 

} 

Liste gehaltene_Veranstaltung; 



Frage: Umsetzung folgender Assoziation? 

* 

Firma Person 

Arbeitgeber 

Firma 

Liste 

Arbeitnehmer 

... 

arbeitet _für 

Person* 

getArbeitnehmer(string name) 

... 

1..* 

Arbeitnehmer 

FirmaA 

FirmaB 

Liste 

Arbeitgeber 

... 

Person 

Firma* 

getArbeitgeber(string name) 


... 

Maier 

Müller


Umsetzung von Assoziationsklassen 

* 1..* 

A B 

C 

n� a kennt 1..n Objekte der Klasse B und 

daran „hängt“ je ein Objekt der Klasse C 

n� a wählt ein Objekt der Klasse B aus und 

erhält dazu ein Objekt c 

A B 

n� a kennt 1..n Objekte der Klasse C und 

daran hängt je ein Objekt der Klasse B 

n� a durchsucht die Objekte der Klasse C 

bis das gesuchte b gefunden ist 


1 

1..* 

C 

* 

1


Beispiel: Assoziationsklassen 

2. 

* 

Firma Person 

Arbeitgeber 

arbeitet _für 

Anstellung 

Gehalt 

urlaub_von_bis 

Urlaub_beantragen 

Firma 

Liste 

Arbeitnehmer 

... 

Anstellung* 

getAnstellung(Person* p) 

... 

1..* 

Arbeitnehmer 

1. 

Anstellung 

Firma* Arbeitgeber 

Person* Arbeitnehmer 

... 

Firma* 

getArbeitgeber() 

Person* 

getArbeitnehmer() 

... 

Firma Person 

Anstellung 


1 

1..* 

Person 

Liste 

Arbeitgeber 

... 

Anstellung* 

getAnstellung(Firma* f) 

... 

* 

1


Beispiel: Assoziationsklassen (I) 

class Anstellung { 

protected: 

Firma* m_Arbeitgeber; // Referenz auf assoziiertes Objekt 

Person* m_Arbeitnehmer; // Referenz auf assoziiertes Objekt 

unsigned int Gehalt; // Attribut der Assoziation 

string urlaub_von_bis; // Attribut der Assoziation ... 

public: 

virtual Person* getArbeitnehmer (void) const{ return (m_Arbeitnehmer); } 

virtual Anstellung* setArbeitnehmer (const Person* einArbeitnehmer){ 

m_Arbeitnehmer = einArbeitnehmer; 

return (this); 

} 

virtual Firma* getArbeitgeber (void) const{ return (m_Arbeitgeber);} 

virtual Anstellung* setArbeitgeber (const Firma* einArbeitgeber){ 

m_Arbeitgeber = einArbeitgeber; 

return (this); 

} 

virtual void Urlaub_beantragen (string anfang_ende){ 

urlaub_von_bis = anfang_ende; 

}; 

... 

} // class Anstellung 



Beispiel: Assoziationsklassen (II) 

class Person { 

protected: 

Liste m_Arbeitgeber; 

public: 

Anstellung* getAnstellung (const Firma* dieFirma) const { 

// Navigieren auf dem Container gemäß gegebener Datenstruktur (Liste). 

// Liefert die Referenz auf das Objekt der Assoziationsklasse, das die 

// Referenz auf die übergebene Firma hält. So ist das Setzen und Lesen von 

// Attributen bzw. das Ausführen von Methoden der Assoziation möglich. 

} 

virtual unsigned getAnstellungsGehalt (const Firma* derArbeitgeber) const { 

// Zugriff auf ein Assoziationsklassen-Attribut: 

return (getAnstellung (derArbeitgeber)-> getGehalt()); 

} 

void do_Anstellung_Urlaub_beantragen (const Firma* derArbeitgeber, string 

anfang_ende) { 

// Ausführen einer Assoziationsklassen-Methode: 

getAnstellung(derArbeitgeber)->Urlaub_beantragen(string anfang_ende); 

} 

... 

} // class Person 



Umsetzung von ternären und höherwertigen Assoziationen 

Verein Spieler 

* 

Statistik 

Siege 

Niederlagen 

Unentschieden 

Gegentore 

* 

Saison 

Torwart 

* 

Verein 

Liste 

 

dieStatistik 

Spieler 

Liste 

 

dieStatistik 

Saison 

Liste 

 

dieStatistik 

Statistik 

Verein* v 

Spieler* p 

Saison* s 

int Siege 

int Niederlagen 

int Unentschieden 

int Gegentore 

ð� Falls keine Assoziationsklasse existiert, lege eine (leere) Assoziationsklasse an 

ð� Ergänze die Attribute der Assoziationsklasse um die Referenzen auf alle 3 bzw. n 

assoziierten Objekte 

ð� In den assoziierten Objekten ergänze die Liste der Referenzen auf die Objekte 

der Assoziationsklasse 

- Sowohl die Assoziationsklasse als auch die assoziierten Klassen bieten Operationen, 

über die zu n assoziierten Objekten navigiert werden kann. 


1 

1 

1 

* 

* 

*


Umsetzung von Aggregation und Komposition 

Computersystem 

n� Normale Aggregation (Shared Aggregation) 

ð� Attribut vom Typ Zeiger auf das aggregierte Objekt 

(d. h. genau wie eine Assoziation) 

n� Komposition (Unshared Aggregation) 

1 0..1 

1 1..* 1..* 

Motherboard Festplatte 

Netzwerkkarte 

ð� Attribut vom Typ der Klasse selbst 

(Die Klasse ist im aggregierenden Objekt integriert) 

Monitor 

Stirbt das Ganze, 

leben die Teile weiter! 

Stirbt das Ganze, 

sterben auch die Teile! 



Komposition 

n� Umsetzung der Komposition zwischen Computersystem und Motherboard aus 

unserem Beispiel 

1 

Computersystem Motherboard 

Computersystem 

Motherboard m_Motherboard 

... 

Motherboard getMotherboard() 

... 

...und wie sieht der C++Code aus? 

Motherboard 


... 

...


Beispiel: Komposition als Klassenattribute in C++ 

// Spezifikation von Computersystem 

class Computersystem { 

} 

protected: 

public: 

... 

Motherboard m_Motherboard; 

Motherboard getMotherboard(); 

// Spezifikation von Motherboard 

class Motherboard { 

} 

protected: 

... 

public: 

... 

kein Pointer, sondern echte 

Instanz der Klasse! 

Frage: Was ändert sich 

(im Diagramm und im Code), 

wenn es mehrere Motherboards 

geben darf? 



Kontrollfragen 

n� Wissen Sie jetzt, wie die UML Konstrukte auf C++ abgebildet werden? 

ð� Klassen mit Attributen und Methoden 

ð� Generalisierung/Spezialisierung 

ð� Abstrakte Klasse/Schnittstelle 

ð� Assoziationen: (normale) Assoziationen: einfache, mehrfache 

ð� Aggregation 

ð� Komposition 

ð� Navigationsrichtung 

ð� Assoziationsklassen 

Sie können jetzt ein UML-Klassendiagramm 

in C++-Code überführen!? 





5.3 Darstellung der Dynamik eines Systems 



Grenzen von Klassendiagrammen 

n� Klassendiagramme liefern einen Überblick über die Bestand- 

teile des Systems und deren Beziehungen untereinander 

ð� Klassen mit Attributen, Methoden und Spezifikation beschreiben die 

(potenziellen) Fähigkeiten und die Verantwortlichkeiten der Bestandteile 

ð� Assoziationen stellen logische Beziehungen zwischen Klassen dar und zeigen 

(potenzielle) Kommunikations- und Verknüpfungsmöglichkeiten zwischen 

Objekten der Klassen 

ð� Beschreibung der Statik des Systems: „Strukturdiagramme“ 

n� sie liefern keine Information darüber in welcher Art und Reihenfolge Objekte und 

Methoden interagieren müssen, um eine geforderte Funktionalität zu liefern! 

ð� Ergänze die Beschreibung des Systems um 

„Verhaltensdiagramme“ 



Lernziele 

n� Sie sollen in diesem Kapitel verstehen, 

ð� Was man mit Sequenzdiagrammen ausdrücken kann 

ð� Wie man mit Sequenzdiagrammen Programmabläufe ausdrückt 

ð� Worauf man bei Sequenzdiagrammen achten muss 

ð� Welche Modellierungselemente die UML dafür bietet 

ð� Was man mit Kommunikationsdiagrammen ausdrücken kann 

ð� Wie Zustandsdiagramme funktionieren 

ð� Wozu Zustandsdiagramme eingesetzt werden 

Hinterher können Sie die Dynamik eines Systems in 

Diagrammen darstellen! 



Grundidee 

n� Wie stellt man die Dynamik eines Systems dar? 

ð� „spiele“ mit Instanzen der (bereits gefundenen) Klassen 

die Methodenaufrufe durch, die erforderlich sind, 

um eine geforderte Funktionalität zu liefern 

n� Beschreibe 

ð� die Reihenfolge der Interaktionen beim Ablauf eines Anwendungsfalls 

ð� die (prinzipiellen) Aufrufe im Code 

ð� die Interaktion von Objekten 

ð� Zustände und Übergänge von Objekten 

ð� die Erzeugung und Zerstörung von Objekten 

Aus lauffähigem Code kann die Sequenz der Methodenaufrufe leicht extrahiert 

werden, indem man mit dem Debugger die Methodenaufrufe verfolgt! 

Wir machen es jetzt andersrum – und entwerfen so die Sequenz der Aufrufe! 





5.3.1 Darstellung der Dynamik eines Systems: 

Sequenzdiagramme 


5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme 

Notation am Beispiel 

n� Betrachten Sie ein Kino- 

Reservierungssystem: 

ð� Es gibt Aktoren, Objekte und 

verschiedene Aufrufe 

ð� Objekte werden in Bahnen 

nebeneinander dargestellt 

ð� Die Aktivität eines Objekts wird durch 

einen (optionalen) Balken symbolisiert 

ð� Nur ein aktiviertes Objekt kann Aufrufe 

machen! 

Aktor 

Objekt 

Steuerungsfokus 

(Aktivierungsbalken) 

Nachricht 

Aufruf 

Return 



Notationen für synchrone Aufrufe und asynchrone Nachrichten 

n� Synchron: 

ð� Der Sender wartet, bis der Empfänger die Nachricht empfangen und vollständig 

abgearbeitet hat. Erst dann arbeitet er weiter. 

n� Asynchron: 

ð� Sender setzt Nachricht ab und arbeitet sofort weiter, ohne auf den Empfänger zu 

warten. Der Empfänger arbeitet parallel zum Sender die Nachricht ab. 

synchroner Aufruf 

Rückgabewert 

asynchrone Nachricht 

Aufruf einer Operation 

Ablauf der Methode 

Return der Methode 



Durchgängiges Beispiel 

n� Aufgabe 

ð� Wir formulieren nun ein Sequenzdiagramm zu einem konkreten Anwendungsfall: 

n� Anwendungsfall „Student immatrikulieren“ 

ð� Ein Sachbearbeiter der Hochschule erfasst am Bildschirm neue Studenten. 

Wurde ein Student bisher noch nicht erfasst, so wird ein neuer Eintrag angelegt 

und der Sachbearbeiter erhält eine Rückmeldung über den Erfolg der Erfassung. 

ð� Die Kommunikation des Systems „Hochschulverwaltung“ mit der Außenwelt 

(Sachbearbeiter) soll über Bildschirmmasken erfolgen. 

n� Es wurden folgende Klassen identifiziert 

ð� Maske, Studentenverwalter, Student, Popup 



Durchgängiges Beispiel – Lösung 

n� Szenario zu Use Case „Student immatrikulieren“: 

Objekt 

erzeugen 

:Klasse 

nur die Klasse ist festgelegt – 

es ist klar welches Objekt 

gemeint ist 

Objekt:Klasse 

ein bestimmtes 

Objekt einer Klasse 

Objekt 

zerstören 

Return ist 

optional 



Durchgängiges Beispiel – Erläuterung 

n� Über eine Erfassungsmaske zur Immatrikulation werden Studentendaten erfasst. 

Ein Objekt Student wird kreiert, wenn es noch nicht vorhanden ist. 

n� Um dies herauszufinden, wird die Klasse StudentenVerwalter befragt, die alle 

Studenten kennt und verwaltet. 

n� Ist die Immatrikulation (das Kreieren des Studenten) erfolgreich, so teilt dies der 

neu angelegte Eintrag dem Sachbearbeiter selbst mit, indem er ein Popup mit 

der entsprechenden Nachricht öffnet, die bestätigt werden muss. 

In UML 1.x wurden zur Verwaltung 

der Gesamtheit aller 

Klasseninstanzen so genannte 

„Multi Object Icons“ eingesetzt. 

Diese gibt es in UML 2.x nicht mehr! 



Anmerkungen 

n� UML-CASE-Tools 

ð� bieten Ihnen beim Erstellen eines Sequenzdiagramms 

die in den Klassen vorhandenen Operationen zur Auswahl an. 

Neue Operationen können aus neu definierten 

Aufrufen erzeugt werden bzw. 

ð� erlauben oft nur Operationen, die bereits in Klassen definiert sind 

n� ein Sequenzdiagramm konkretisiert häufig einen 

Anwendungsfall 

n� ein Sequenzdiagramm kann aber auch Sachverhalte illustrieren, die den 

Anwender nicht interessieren (z. B. zur Veranschaulichung der Initialisierung) 

n� Konventionen 

ð� Sequenzdiagramme haben die Leserichtung links→rechts, oben→unten 

ð� Überkreuzungen von Aufrufen (in der Darstellung) sind möglichst zu vermeiden 

ð� Aktoren (d. h. Personen oder andere Systeme, die nicht im modellierten System 

enthalten sind) stehen üblicherweise links außen 



Zweites Beispiel 

n� Anwendungsfall „Student exmatrikulieren“ 

ð� Ein Sachbearbeiter der Hochschule erfasst an einer Bildschirmmaske Studenten, 

die exmatrikuliert werden. Die Löschung der Studentenakte darf nur erfolgen, 

wenn darin keine entliehenen Gegenstände mehr eingetragen sind. Der 

Sachbearbeiter erhält eine Rückmeldung über den Erfolg der Exmatrikulation. 

n� Es wurden bereits folgende Klassen identifiziert: 

- Maske 

- Studentenverwalter 

- Student 

- Popup 



Zweites Beispiel – Lösung 

n� Szenario zu Use Case „Student exmatrikulieren“: 



Tipps zur Erstellung von Sequenzdiagrammen 

n� Überlegen Sie zuerst, was (nicht) dargestellt werden soll 

ð� welche Aufruftiefe soll dargestellt werden? 

ð� welche konkreten Abläufe („Szenarien“) sollen dargestellt werden? 

(nur wenige Pfade bei Verzweigungen; nicht alle Alternativen gleichzeitig) 

n� Achten Sie auf eine geordnete Aufrufreihenfolge 

ð� die Aktivierung eines Objekts startet mit einem synchronen Aufruf und endet mit 

einem „Return“ (auf eine klammerartige Schachtelung achten!) 

ð� Methodenaufrufe können nur von „aktiven“ Objekten erfolgen. Wird eine 

Methode aufgerufen, geht die Aktivität an dieses Objekt über und kommt erst 

mit dessen „Return“ zurück 

ð� die Kommunikation mit Aktoren und anderen eigenständigen Systemen erfolgt 

asynchron 

ð� stellen Sie – zur Verbesserung der Lesbarkeit – auch optionale Konstrukte dar 

(Returns von Konstruktoren/Destruktoren bzw. Aktivierungsbalken) 

- Dann kann man die synchronen Aufrufe und Returns eines korrekten Diagramms von 

oben links nach unten links „durchfahren“. 



Schwierigeres Beispiel 

n� Anwendungsfall „Essen zahlen“ (in der Mensa) 

ð� Ein Mensakunde kommt mit seinem Essen zur Kasse. Die Kassenfrau gibt die 

Artikelnummern ein und die Kasse zeigt den Betrag an. Der Kunde schiebt seine 

Mensakarte in das Lesegerät und der Betrag wird abgebucht. Reicht das 

Guthaben nicht aus, wird eine Fehlermeldung angezeigt. Der Kunde entnimmt in 

beiden Fällen seine Karte. 


- Kasse 

- Display 

- LeseSchreibEinheit 

- MensaKarte 

ð� Welche Aktoren gibt es? 

ð� Wie laufen die Aufrufe? 



Schwierigeres Beispiel – Diskussion einer Lösung 

Verzweigung 

(UML 1.4) 

triviale 

Returns 

fehlen 

(optional) 

n� Anmerkungen: 

ð� In dieser Lösung 

kontrolliert die Schreib- 

Lese-Einheit den 

Gesamtvorgang. 

Die Kasse wäre 

realistischer. 

ð� Der Input ist sichtbar, 

der Output nicht. 

ð� Gehört die Karte zu 

unserem System? 

Hat sie wirklich eine 

Methode „lies“? 

ð� Was würde passieren, 

wenn die Bezahlung 

durch einen Daumen‐ 

abdruck und direkte 

Abbuchung von einem 

Bank-Konto ersetzt 

würde? 



Häufige Fehler 

1. Fehler: Methodenaufruf beim Aktor 

ð� Ein Aktor ist in der Regel menschlich. Er hat deshalb 

keine Methoden, die man aufrufen könnte. 

2. Fehler: Kontrollverlust durch synchronen Aufruf 

ð� Ein Aktor führt ein eigenständiges Leben. Er hat 

seine eigene „CPU“. Wegen des synchronen Aufrufs 

darf das aufrufende System aber erst weitermachen, 

wenn der Aktor ein Return zurückschickt – und das 

tut er vielleicht nie. Ein „Timeout-Verhalten“ kann so 

nicht mehr implementiert werden. 

ð� Richtig wäre, eine asynchrone Nachricht (als 

Ausgabe) an den Aktor zu schicken, und zu hoffen, 

dass er wie gewünscht reagiert. Falls nicht, kann 

nach einem Timeout entsprechend reagiert werden. 



Häufige Ungeschicklichkeiten 

n� Verletzung der Kapselung 

ð� Der Kartenleser sagt der Kasse was sie tun soll 

(CheckePin). Der Kartenleser kann (bzw. soll) aber 

gar nicht wissen, ob eine Pin geprüft werden muss. 

Ob die Prüfung über eine PIN erfolgt (oder über einen 

Daumenabdruck) gehört zur Verantwortung der Kasse. 

ð� Besser wäre, nur das zu sagen, was in der eigenen 

Verantwortung liegt. Dann kann die Kasse so 

reagieren wie sie es für richtig hält. 



Schwierigeres Beispiel – 2. Versuch 

n� Anwendungsfall „Essen zahlen“ (in der Mensa) 

ð� Ein Mensakunde kommt mit seinem Essen zur Kasse. Die Kassenfrau gibt die 

Artikelnummern ein und die Kasse zeigt den Betrag an. Der Kunde schiebt seine 

Mensakarte in das Lesegerät und der Betrag wird abgebucht. Reicht das 

Guthaben nicht aus, wird eine Fehlermeldung angezeigt. Der Kunde entnimmt in 

beiden Fällen seine Karte. 


- Kasse 

- Display 

- SchreibLeseEinheit 



Schwierigeres Beispiel – Alternative Lösung 

n� Anmerkungen: 

ð� In dieser Lösung kontrolliert 

die Kasse den Gesamtvor‐ 

gang. Die RW_Unit küm‐ 

mert sich bloß um die Karte. 

ð� Der Output erfolgt über die 

Klasse Display. 

ð� Die Karte wird nicht mehr 

modelliert, sondern 

übergeben. 

ð� Was würde jetzt passieren, 

wenn die Bezahlung durch 

einen Daumenabdruck und 

direkte Abbuchung von 

einem Bank-Konto ersetzt 

würde? 



Übung: Mikrowellenherd 

n� Modellieren Sie einen Mikrowellenherd. 

Die Funktionsweise wird stichwortartig zusammengefasst: 

ð� die Bedienelemente für den Benutzer sind der Einschaltknopf und die Tür 

ð� durch Drücken des Knopfes wird die Mikrowelle (die „Backröhre“) eingeschaltet 

ð� die Kochzeit wird über eine interne Zeituhr auf eine Minute festgelegt 

ð� durch weiteres n-maliges Drücken des Knopfes wird die Kochzeit um n Minuten 

verlängert 

ð� wenn die Zeit abgelaufen ist, wird die Backröhre ausgeschaltet, ein Piepton 

ertönt und als nächstes muss die Tür geöffnet werden bevor die Mikrowelle 

erneut gestartet werden kann 

ð� durch Öffnen der Tür wird die Backröhre abgeschaltet und die verbleibende 

Kochzeit gelöscht 

ð� der Mikrowellenherd startet nur bei geschlossener Tür 

ð� wenn die Tür offen ist oder wenn der Herd an ist, leuchtet das Licht 

ð� wenn der Mikrowellenherd ein- bzw. ausschaltet, muss die Backröhre ebenfalls 

ein- bzw. ausgeschaltet werden 




n� Erstellen Sie 

ð� ein Klassendiagramm 

- mit Klassen, Attribute, Methoden, Beziehungen 

ð� Sequenzdiagramme für die Szenarien 

- 2 Minuten kochen 

- Tür öffnen und schließen 

- Kochvorgang mit Abbruch durch Tür öffnen 

n� Versuchen Sie die Diagramme selbst zu entwerfen, bevor Sie sich die folgenden 

Lösungen anschauen! 

ð� Entwickeln Sie zuerst ein Klassendiagramm und vergleichen Sie Ihr Ergebnis mit 

der Lösung. 

ð� Entwickeln Sie die Sequenzdiagramme mit den Klassen und Methoden aus dem 

Lösungs-Klassendiagramm. 

ð� Beachten Sie dabei, dass es nicht nur eine einzige richtige Lösung gibt. 



Lösung Mikrowellenherd: Klassendiagramm 



Lösung Mikrowellenherd: Sequenzdiagramm „2 Minuten kochen“ 



Lösung Mikrowellenherd: Sequenzdiagramm „Tür öffnen und schließen“ 



Lösung Mikrowellenherd: Sequenzdiagramm „Kochen mit Abbruch“ 



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 image and then 

insert it again. 

Klasse, Objekt 

In dem Rechteck oberhalb der gestrichelten Linie wird der Objektname 

und der Klassenname angegeben. Der Name wird unterstrichen. 

Die senkrechte, gestrichelte Linie stellt die Lebenslinie 

(lifeline) eines Objekts dar. Im diesem zeitlichen Bereich existiert 

das Objekt. Das schmale Rechteck auf der gestrichelten Linie 

stellt eine Aktivierung dar. Eine Aktivierung ist der Bereich, in 

dem eine Methode des Objektes aktiv ist (ausgeführt wird). Auf 

einer Lebenslinie können mehrere Aktivierungen enthalten sein. 

Nachricht, Botschaft 

Objekte kommunizieren über Nachrichten. Nachrichten werden 

als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name 

der Nachricht steht an dem Pfeil. Eine Nachricht liegt immer 

zwischen einem sendenden und einem empfangenden Objekt. 



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

Synchrone Nachricht (Aufruf) 

Der Pfeil mit der ausgefüllten Spitze bezeichnet einen synchronen 

Aufruf. Der Aufruf erfolgt von der Quelle zum Ziel, d. h. die Zielklasse 

muss eine entsprechende Methode implementieren. Die Quelle wartet 

mit der weiteren Verarbeitung bis die Zielklasse ihre Verarbeitung beendet 

hat und setzt die Verarbeitung dann fort. Ein Aufruf muss einen 

Namen haben; in runden Klammern können Aufrufparameter angegeben 

werden. Der gestrichelte Pfeil ist der Return. Die Bezeichnung des Return 

mit einem Namen ist optional. 

Asynchrone Nachricht 

Mit einer offenen Pfeilspitze werden asynchrone Nachrichten gekennzeichnet. 

Der Aufruf erfolgt von der Quelle zum Ziel. Die Quelle wartet 

mit der Verarbeitung nicht auf die Zielklasse, sondern setzt ihre Arbeit 

nach dem Senden der Nachricht fort. Asynchrone Aufrufe werden verwendet, 

um parallele Threads zu modellieren. 



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. 

Objekt erzeugen, zerstören 

Das Erzeugen eines Objektes wird durch eine Nachricht, die im 

Kopf des Objekts endet, dargestellt. 

Das Zerstören (Löschen) eines Objektes wird durch ein x auf der 

Lebenslinie markiert. 

Aufruf einer Operation im gleichen Objekt (Rekursion) 

Sendet ein Objekt eine Nachricht an sich selbst, so nennt man 

dies Rekursion. Das Objekt ruft eine Operation auf, die es selbst 

anbietet. 



Erweiterte Notation in UML 2.x (I) 

Links oben stehen der 

Diagrammtyp (sd) und der 

Diagrammname (NameSQ). 

Der mit ref bezeichnete Block 

stellt einen Verweis auf ein 

Diagramm mit dem Namen „SQ- 

Diagramm 2“ dar, das eine 

Verfeinerung des Blockes 

enthält. Der mit alt markierte 

Block beschreibt eine 

Alternative (Verzweigung). Ist 

die Bedingung [b=wahr] erfüllt, 

wird der Bereich oberhalb der 

gestrichelten Linie ausgeführt, 

sonst der Bereich unterhalb der 

gestrichelten Linie. 

kombinierte Fragmente (combined fragment) 

Mit kombinierten Fragmenten können in Sequenzdiagrammen die Kontrollstrukturen höherer 

Programmiersprachen ausgedrückt werden. Ab der UML 2.0 können damit Sequenzdiagramme 

verschachtelt werden. Ein kombiniertes Fragment wird als rechteckiger Block dargestellt. In der 

linken, oberen Ecke trägt es eine Bezeichnung, die den Typ der Kontrollstruktur angibt (interaction 

operator). Die wichtigsten Interaktionsoperatoren in der UML 2.x sind ref (Verweis), alt 

(Alternative) und loop (Schleife). 



Erweiterte Notation in UML 2.x (II) 

ref 

Sequenzdiagramme können ande‐ 

re Sequenzdiagramme beinhalten 

(als eine Art Unter-Programm). 

Dabei können beim „Aufruf“ und in 

der „Definition“ des Unterpro‐ 

gramms Parameter übergeben 

bzw. spezifiziert werden. 

loop 

Eine Schleife in einem Sequenz‐ 

diagramm bewirkt, dass die enthal‐ 

tene Sequenz von Botschaften 

solange ausgeführt wird, bis die 

Abbruchbedingung erfüllt ist. 



Erweiterte Notation in UML 1.4 

n� In UML 1.4 gibt es diese erweiterte Notation nicht. 

n� Schleifen, Verzweigungen und das Beinhalten von anderen 

Sequenzdiagrammen können mit Hilfe von Zeitabschnitten und manuell 

eingeführten Kommentaren dargestellt werden: 

statt in 2.x: in 1.x: 

xxx[…] 

XXX[...] 



Anwendung 

n� Sequenzdiagramme sind z. B. in folgenden Situationen nützlich: 

ð� vor Implementierungsbeginn 

- zur Verifikation des Designs: besonders interessante (oder schwierige) 

Systemzustände anschaulich darstellen und „testen“ (z. B. Anwendungsfälle) 

- um zu verifizieren ob die Klassenaufteilung (Design) gut gewählt ist und alle 

benötigten Assoziationen vorhanden sind 

ð� im Team 

- verbesserte Kommunikation der wesentlichen Abläufe 

ð� beim Test 

- kritische Abläufe im System können für Tests spezifiziert (und evtl. generiert) werden 

Das Sequenzdiagramm ist eines der wichtigsten 

Interaktionsdiagramme in der UML! 



Tipps 

n� Sequenzdiagramme sind sehr leicht zu lesen… 

… aber gar nicht so leicht zu erstellen! 

ð� Welche Objekte sind (nicht) erforderlich? 

- Auf das Beschränken was wichtig ist bzw. dargestellt werden soll 

- aber auch nicht zu wenige Objekte 

ð� Wer ruft wen auf? 

- Überlegen, wer den Trigger erhält, der die Aktion startet 

ð� Welche bzw. wie viele Alternativen sollen dargestellt werden? 

- Nur die wichtigsten für das Szenario. Lieber mehrere Diagramme! 

- Oder kombinierte Fragmente verwenden – aber bitte nicht programmieren! 

- Nicht versuchen, alles auf einmal darzustellen! 

Sequenzdiagramme zeigen immer nur je ein Szenario! 

ð� Wie wird die Interaktion mit der Außenwelt (Aktoren) modelliert? 

- Tipp: Asynchrone Aufrufe und I/O-Objekte verwenden 

immer iterativ vorgehen! 






Kommunikationsdiagramme 


5.3.2 Darstellung der Dynamik eines Systems: Kommunikationsdiagramme 

Inhalt 

n� Ein Kommunikationsdiagramm beschreibt 

ð� die Interaktion zwischen Objekten im Überblick 

ð� die zeitliche Reihenfolge, in der die Nachrichten gesendet werden 

ð� die Beziehungen zwischen den Objekten und die Nachrichten, 

die übertragen werden 

in UML 1.x: 

„Kollaborationsdiagramme“ 

ð� Dabei steht der Überblick der Kommunikationsstruktur im Vordergrund 

n� Das kommt Ihnen bekannt vor? 

ð� Kommunikationsdiagramme werden für die selben Zwecke eingesetzt wie 

Sequenzdiagramme! 



entspricht der ersten Lösung 

Notation am Beispiel: „Essen zahlen“ 

Der „Mensa-Aufgabe“ 

als Sequenzdiagramm! 

mehrstellige 

Nummerierung 

gliedert und erlaubt 

leichtere Änderung 

Alternativen 



Kommunikationsdiagramm vs. Sequenzdiagramm 

Kommunikationsdiagramm Sequenzdiagramm 

Objekte in der Fläche verteilt Objekte in einer Linie 

Sequenz der Nachrichten durch 

Nummerierung 

Stärke: viele Objekte, die wenige 

Nachrichten austauschen 

Parallelität und Alternativen durch 

Nummerierung mit Buchstaben 

Sequenz der Nachrichten graphisch 

auf Zeitachse 

Stärke: wenige Objekte, die viele 

Nachrichten austauschen 

Parallelität durch Asynchronität 

(wird mit offenen Pfeilen angedeutet) 

Keine Verschachtelung verschachtelte Diagramme möglich 

Kommunikationsdiagramme bieten 

nur eine Untermenge der Sequenzdiagramme! 



Anwendung 

n� Kommunikationsdiagramme sind z. B. in folgenden Situationen nützlich: 

ð� wenn das Zusammenspiel zwischen vielen interagierenden Teilen möglichst 

einfach dargestellt werden soll 

ð� wenn es um das grundsätzliche Verständnis des Ablaufs und der 

Verantwortungen geht – weniger um Details im Timing 



Notation in UML 2.x 

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 


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 


Objekt 

Das Rechteck stellt ein Objekt dar. Es kann einen Objekt‐ 

namen und einen Klassennamen tragen. 

Beziehung, Nachricht 

Die Kommunikationsbeziehungen zwischen Objekten wer‐ 

den als Linie dargestellt. An die Beziehungen werden die 

Nachrichten, die darüber übertragen werden geschrieben. 

Die Nummerierung vor den Nachrichtennamen gibt die zeit‐ 

liche Reihenfolge der Nachrichten an. (2.1, 2.2, ...). 

Alternativen (Nebenläufigkeit) werden durch Angabe von 

Buchstaben dargestellt (2.3.a, 2.3.b, ...). Der Pfeil gibt die 

Richtung der Nachrichten an. 






Zustandsdiagramme 


5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme 

Beobachtung 

n� Betrachten Sie die Zustände, in der sich Ihre Digitalkamera befinden kann: 

ð� Das Verhalten der Kamera ist sehr stark davon abhängig, in welchem Zustand 

sie sich gerade befindet: Kamera reagiert beim Drücken eines Knopfes abhängig 

vom Zustand in dem sie sich gerade befindet (z. B. wird durch Drücken des 

rechten Knopfes im Zustand Display das nächste Bild angezeigt, im Zustand 

Fotografieren der Zustand des Blitzlichtes verändert). 



Beobachtung 

n� Betrachten Sie die Zustände, in denen sich ein 

typischer Laserdrucker befinden kann: 

Betriebsbereit Papierstau 

Kein Papier 

eingelegt 

Selbsttest 

Druckend 

Keine Tonerkassette 

eingelegt 

ð� Das Verhalten eines Druckers ist sehr stark davon abhängig, in welchem 

Zustand er sich gerade befindet. 

Toner 

fast leer 

ð� Der Drucker geht unter bestimmten Bedingungen von einem Zustand in den 

anderen über. 

Es handelt sich offensichtlich um die Dynamik eines Systems, 

aber wie beschreiben und implementieren wir das? 



Grundidee Zustandsautomat (State Machine) 

n� Wie stellt man die Zustände und Übergänge eines Systems dar? 

ð� Modelliere das System als eventgetriebenes System mit 

Zuständen, Übergängen und Ereignissen 

ð� „Zustandsdiagramm“ (State (Machine) Diagram) 

Schranke offen 

Öffnen 

Schließen 

Schranke geschlossen 

Es ist immer nur ein Zustand in einem Zustandsautomaten aktiv! 

Anfangszustand 

Zustand 

Ereignis 

Zustandsübergang 

Endzustand 



Interpretation des Beispiels 

n� Zustandsdiagramm zu einer Schranke 

ð� Eine Schranke wird eingebaut und erreicht nach ihrer Fertigstellung 

ihren Anfangszustand (hier: Schranke offen). Sie ist betriebsbereit. 

Während ihrer Existenz kann sie die Zustände „Schranke offen“ und 

„Schranke geschlossen“ einnehmen. 

ð� Durch die Ereignisse „Schließen“ und „Öffnen“, die von anderen Objekten 

(z. B. einem Benutzer, Kontaktschleife) verursacht werden, ändert sie ihren 

Zustand. Die Schranke reagiert aber in jedem Zustand nur auf bestimmte 

Ereignisse. Ist die Schranke im Zustand geschlossen, so reagiert sie nur auf das 

Ereignis „Öffnen“. Ist die Schranke im Zustand offen, so reagiert sie nur auf das 

Ereignis „Schließen“. 

ð� Alle Nachrichten, die in einem Zustand eines Objektes nicht sinnvoll sind (es 

existiert kein vom Zustand herausführender Pfeil mit diesem Ereignis), werden 

ignoriert und verursachen keine Reaktion des Objekts. 

Beispiel: Öffnen im Zustand „Schranke offen“ 

ð� Das Erreichen des finalen Zustandes bedeutet die Zerstörung des Objekts. 

ð� Das Modell könnte bei Bedarf um weitere Zustände ergänzt werden: 

z. B. „Schranke öffnend“, „Schranke schließend“ 

Öffnen 

Schranke offen 

Schließen 

Schranke geschlossen 



Was ist ein Zustand? 

n� Der Zustand eines Objekts ist eine Zeitspanne, in der 

ð� das Objekt eine bestimmte Aktivität ausführt und 

ð� das Objekt auf ein oder mehrere bestimmte Ereignisse wartet oder 

ð� das Objekt wartet, bis eine bestimmte Bedingung erfüllt ist 

Schranke 

offen 

n� Ein Objekt kann sich im Laufe der Zeit in verschiedenen, klar voneinander 

abgegrenzten Zuständen befinden 



Was ist kein Zustand? 

n� Verwechseln Sie die Zustände, die ein Objekt oder das System 

einnehmen kann, nicht 

ð� mit den Objekten oder Komponenten des Systems selbst 

ð� oder mit Aktivitäten 

n� Beispiel: Betrachten Sie die Steuerung einer Parkhausschranke. 

ð� Falsch: 

ð� Richtig: 

Schranke 

Schranke 

offen 

oder 

Schranke öffnen 

Schranke 

geschlossen 



Zustandsübergänge benötigen keine Zeit! 

Was ist ein Zustandsübergang? 

Die Aktionen müssen entsprechend schnell 

ablaufen! 

n� Beispiel: 

ð� Betrachten Sie einen typischen Laserdrucker. 

Der Toner ist leer und Sie legen eine neue Tonerkassette ein. 

- Erkennen Sie einen Übergang von einem Zustand zu einem anderen? 

- Welche Elemente sind an dem Übergang beteiligt? 

ð� Beschreibung: „Wenn der Drucker keinen Toner mehr hat und eine 

Tonerkassette eingelegt wird und der Deckel geschlossen wird, dann wird ein 

Reset durchgeführt und anschließend ist der Drucker im Zustand ‚Selbsttest‘.“ 

n� Ein Zustandsübergang („Transition“) liegt vor, wenn ein Objekt 

ð� in einem bestimmten Zustand ist und 

ð� ein bestimmtes Ereignis eintrifft und 

ð� bestimmte Bedingungen erfüllt sind und 

ð� dann eine bestimmte (kurze) Aktion ausgeführt wird und 

ð� das Objekt sich anschließend in einem anderen Zustand befindet. 



Notation von Zustandsübergängen 

n� Zustandsübergänge werden durch Pfeile zwischen dem aktuellen Zustand und 

einem Folgezustand dargestellt. 

n� An einem solchen Pfeil werden die Details des Zustandsübergangs notiert: 

Liste von Auslösern 

(„Trigger“) 

(durch Kommata 

getrennt) 

Tür zu 

EC-Karte ins 

Lesegerät 

gesteckt 

Eine optionale 

Bedingung („Guard“) 

(in eckigen Klammern) 

[EC-Karte ist gültig] 

/ Kartennummer 

mit Zeitstempel 

ins Logfile schreiben; 

Tür öffnen 

Für einen Trigger sollte immer nur 

ein Zustandsübergang möglich sein! 

Aktionen („Action“) die 

beim Zustandswechsel 

stattfindet 

(durch/abgetrennt) 

Tür offen 



Verhalten in Zuständen 

Vorgänge, die Zeit kosten, müssen innerhalb 

der Zustände umgesetzt werden! 

n� Beispiel: 

ð� Betrachten Sie einen Beamer, den Sie anschalten. 

- Erkennen Sie Aktivitäten, die dann ausgeführt werden? Wann werden Sie ausgeführt? 

ð� Im Zustand „Systemstart“ wird zuerst eine rote LED angeschaltet, dann wird die 

Birne vorgewärmt bis die Betriebstemperatur erreicht ist. Ist dies der Fall, wird 

der Beamer aktiviert und statt der roten eine grüne LED angeschaltet. Während 

der Aufwärmphase wird alle 5 Sekunden geprüft, ob die Temperatur erreicht ist. 

n� Verhalten in einem Zustand tritt auf, als 

ð� Eintrittsverhalten (entry behavior) 

- Verhalten eines Objekts, wenn es einen bestimmten Zustand einnimmt 

ð� Zustandsverhalten (state behavior oft auch do behavior) 

- Verhalten eines Objekts, solange es sich in dem Zustand befindet 

ð� Austrittsverhalten (exit behavior) 

- Verhalten eines Objekts, wenn es den Zustand verlässt 

ð� Interne Transition (internal transition) 

- bedingtes Verhalten bei Ereignissen, die den Zustand nicht verlassen 



Notation des Verhaltens 

n� Darstellung in einem eigenen Bereich unterhalb des Zustandsnamens 

ð� Das Verhalten wird mit Schrägstrich von den Labels entry, do und exit abgetrennt 

ð� Interne Übergänge werden analog zu Transitionen beschrieben 

ð� Mehrere Aktionen werden durch, getrennt 

Eintrittsverhalten 

Aktionen, die beim Eintritt in den 

Zustand ausgeführt werden 

Zustandsverhalten 

Aktivitäten, die ausgeführt werden, solange 

man sich in dem Zustand befindet (es findet 

jedoch keine automatische Wiederholung statt) 

Austrittsverhalten 

Aktionen, die beim Verlassen des 

Zustands ausgeführt werden 

Interne Transition 

Aktionen, die ausgeführt werden, wenn der Trigger (hier 

Time-Trigger) auftritt und der (optionale) Guard erfüllt ist 

Systemstart 

entry / roteLEDan() 

do / Birne aufheizen() 

exit / roteLEDaus() 

alle 5 Sek. [true] / checkTemp() 



Aktionen und Aktivitäten 

n� Aktionen („actions“) 

ð� sind ein nicht unterbrechbares Verhalten, das an bestimmten Stellen in einem 

Zustandsautomat ausgeführt wird 

ð� von Aktionen wird angenommen, dass Sie keine Zeit verbrauchen 

ð� eine Aktion kann wiederum aus einer Sequenz von Aktionen bestehen, die dann 

wieder nicht unterbrechbar ist 

ð� in Zustandsübergängen können Aktionen ausgeführt werden 

ð� eine Aktion kann daraus bestehen eine Nachricht an andere Objekte (oder sich 

selbst) verschicken 

n� Aktivitäten („activities“) 

ð� sind Verhalten, die endliche Zeit benötigen 

ð� Aktivitäten werden nur innerhalb des Zustandsverhaltens ausgeführt 

(do behavior) 

ð� Aktivitäten bestehen normalerweise aus mehreren Aktionen 

ð� Aktivitäten werden unterbrochen, wenn ein Ereignis einen Zustandswechsel auslöst 



Reihenfolge der Aktionsausführung nach Eingang eines Triggers 

n� Bei einem Zustandsübergang werden 

die Aktivitäten in folgender Reihenfolge ausgeführt 

ð� Do-Aktivität wird unterbrochen 

ð� Austrittsverhalten des alten Zustands 

ð� Aktionen, die zur Transition gehören 

ð� Eintrittsverhalten des neuen Zustands 

ð� Zustandsverhalten des neuen Zustands 

n� Auch bei rekursiven Transitionen (Loops) 

werden alle diese Aktionen ausgeführt 

n� Bei internen Transitionen 

ð� werden nur die Aktivitäten ausgeführt, aber 

kein Exit und kein Entry behavior 

ð� wird eine laufende do-Aktivität unterbrochen, die 

Aktionen der internen Transition ausgeführt und 

anschließend wird die do-Aktivität fortgeführt 

LOOP 

entry/ z=read() 

INT 


alle 5 Sek. / doIt() 

Exit behavior 

(actions) des 

vorhergehenden 

Zustands 

Transition 

actions 

Entry 

behavior 

(actions) 

State behavior 

(activity) 



Transitionen im Detail 

n� Transition ohne Trigger (Automatische Transition/Completion Transition) 

ð� 1. Fall: ohne Guard 

ð� feuert von selbst, sobald das Zustandsverhalten (do behavior) abgearbeitet ist 

A 

do / grinsen 

ð� 2. Fall: mit Guard 

ð� feuert von selbst, sobald das Zustandsverhalten (do behavior) abgearbeitet ist, 

aber nur wenn der Guard erfüllt ist 

ð� ist der Guard nicht erfüllt, kann der Zustand nur über eine andere Transition 

verlassen werden 

A 

do / lachen 

[Bauch tut weh] 

- Nach dem Lachen werden – falls der Bauch weh tut – die Muskeln gelockert 


B 

do / Muskeln lockern 

B 

do / Muskeln lockern


Transitionen im Detail II 

n� Änderungsauslöser (Change Trigger) 

ð� an der Transition steht eine When-Bedingung 

ð� falls die Bedingung erfüllt ist, erfolgt die Transition (auch vor oder während der 

do-Aktivität) 

ð� falls die Bedingung nicht erfüllt ist, erfolgt der Zustandsübergang dann, wenn sich 

die Bedingung von false auf true ändert 

ð� die Bedingung wird „ständig“ neu ausgewertet und bei Erfüllung wird die 

Transition ausgelöst 

- damit die Auswertung der Bedingung technisch möglich ist, wird die Überwachung in 

der Praxis auf bestimmte Zeitpunkte, bestimmt Ereignisse oder die Attribute des 

Zustands eingeschränkt 

A 

do / lachen 

when (Bauch tut weh) 

- Das Lachen wird unterbrochen, sobald der Bauch weh tut! 


B 

do / Muskeln lockern


Ereignisse im Detail 

n� Wenn ein Ereignis eintrifft, gibt es entweder 

ð� eine Transition, die feuern kann 

- das ist der Normalfall; im Beispiel für z='+' 

ð� mehrere Transitionen, die feuern können 

- Der Trigger passt zu mehreren Transitionen und der Guard 

liefert „true“; im Beispiel für z='*' 

- das Verhalten der Zustandsmaschine ist nicht vorhersagbar; 

es wird eine zufällig bestimmte Transition durchlaufen 

- Dieser Fall sollte vermieden werden! 

ð� keine Transition, die feuern kann 

- Der Trigger passt zu keiner Transitionen oder der Guard 

liefert „false“; im Beispiel für z='/' 

- dann verfällt das Ereignis und es wird keine Transition ausgeführt 

n� Bei Automatischen Transitionen (Transitionen ohne Ereignis) 

gilt das Gleiche – auch wenn es kein echtes Ereignis gibt 

Ereignis1 [z!='/'] 


SX 


Ereignis1 [z='*'] 

[z!='/'] 

SY 


[z='*']


Sonderfälle: Kreuzungen vs. Entscheidungen 

n� Eine Kreuzung erlaubt, bei Kombinationen von Zustandsübergängen das 

Diagramm zu vereinfachen. 

ð� Aber Vorsicht – es gibt einen wichtigen Unterschied zu Entscheidungen 

Kreuzung 

B 

A 

do / z = 17 

Trigger / z++ 

[z gerade] [z ungerade] 

Entscheidung 

C B 

Trigger / z++ 


A 

do / z = 17 

[z gerade] [z ungerade] 

C


Kreuzungen vs. Entscheidungen (Darstellung transformiert) 

n� Die Kreuzung kann als 2 Transitionen, die Entscheidung mit 3 Transitionen und 

Zwischenzustand dargestellt werden: 

A 

Kreuzung Entscheidung 

do / z = 17 

Trigger [z gerade] 

/ z++ 

B 

Trigger [z ungerade] 

/ z++ 

C B 

ohne Aktivitäten oder Aktionen 

Trigger / z++ 

ð� Die Auswertung der Bedingung erfolgt bei der Kreuzung VOR der Ausführung der 

Aktion; bei der Entscheidung nach der Aktion! 


A 

do / z = 17 

[z gerade] Zwischenzustand 

[z ungerade] 

C


Wie findet man Zustände, Übergänge und Ereignisse? 

n� Analysiere, in welchen unterschiedlichen Zuständen 

sich das System befinden kann 

ð� Suche nach gleichem Verhalten über einen Zeitraum 

n� Analysiere welche Ereignisse in dem System auftauchen 

ð� löst das Ereignis einen Zustandsübergang aus? 

ð� welche Aktion erfolgt als Reaktion auf das Ereignis? 

ð� welche Aktionen werden dauerhaft ausgeführt und welche Aktionen nur beim 

Eintreten oder Verlassen eines Zustands? 

n� Analysiere die Übergänge zwischen den Zuständen 

ð� sollte es einen Übergang zwischen einem Zustandspaar geben? 

ð� achte darauf, dass jedes Ereignis höchstens einen Übergang auslöst 

Analysiere auch vorliegende 

Use Cases und Sequenzdiagramme! 



Lösung der Übung: C++ Kommentarfilter 

“*” im /* Kom. gelesen 

[z='*'] 

[z!='*' && z!='/'] 


[z!='“'] 

/write(z) 

[z='*'] 

[z='/'] 

in String 


In “/*”-Kommentar 


[z!='/' && z!='“' && z!=EOF] 

/write(z) 

[z='“'] 

/write(z) [z='“'] 

/write(z) 

im Progr-Code 


[z!='*'] 

[z='/'] 

[z='*'] 

[z!='/' && z!='*'] 

/write('/'); write(z); 

[z!=EOLN 

&& z!=EOF] 

Ein “/” gelesen 


[z='/'] 

[z=EOLN] 

/write(z); 

[z=EOF] 

/write(z) In “//”-Kommentar 


[z=EOF] / write(z); 

Finden Sie noch 

einen Fehler? 



Beschreibung des Zustandsverhaltens 

n� Grundsätzlich kann das Zustandsverhalten (do / Zustandsverhalten) auch 

außerhalb des Zustandsdiagramms näher beschrieben werden: 

ð� verbal 

ð� als Aktivitätsdiagramm 

ð� als weiteres Zustandsdiagramm (ein Zustand wird in Unterzustände mit 

Zustandsübergängen zerlegt) 

ð� oder auch mit dem Konzept der zusammengesetzten Zustände 

(siehe nächste Folie) 

Systemstart 

entry / roteLEDAn() 

do / Birne aufheizen() 

exit / roteLEDAus() 

alle 5 Sek. [true] / CheckTemp() 

Birne aufheizen 

Damit die Birne... 


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. 




Zusammengesetzte Zustände (composite states) 

n� Bisher haben wir nur einfache Zustände betrachtet 

ð� Ein Zustand kann jedoch selbst wiederum als ein Automat mit Unterzuständen 

beschrieben werden 

ð� Das Vorhandensein von Unterzuständen kann durch das Composite-Icon 

(„Brille“) angedeutet werden 

Zustandsname 

entry / Eintrittsverhalten 

do / Zustandsverhalten 

exit / Austrittsverhalten 

UZ1 UZ1 

Zustandsname 

entry / Eintrittsverhalten 

do / Zustandsverhalten 

exit / Austrittsverhalten 



Eintritt in einen zusammengesetzten Zustand 

n� Ein zusammengesetzter Zustand kann wie folgt betreten werden: 

ð� Default entry 

Die Pfeilspitze des Zustandsübergangs zeigt 

auf den Rand des zusammengesetzten Zustands. 

Damit wird der Startzustand des zusammengesetzten 

Zustands implizit als Folgezustand ausgewählt. 

ð� Explicit entry 

Die Pfeilspitze zeigt direkt auf einen bestimmten 

Unterzustand eines zusammengesetzten Zustands. 


UZ 

UZ1 

UZ2


Verlassen eines zusammengesetzten Zustands 

n� Ein zusammengesetzter Zustand kann auf folgende Arten verlassen werden: 

ð� Der zusammengesetzte Zustand erreicht seinen Endzustand (weiter mit C). 

ð� Ein Unterzustand wechselt explizit in einen anderen Zustand außerhalb des 

zusammengesetzten Zustands (B nach D). 

ð� Ein Auslöser weg von dem zusammengesetzten Zustand findet statt 

(Wechsel nach E – egal aus welchem Zustand). 

C 

A B 

T1[G1]/A1 

T2[G2]/A2 

Was passiert, wenn T1 eintrifft und G1 erfüllt ist, während der Do-Teil von A ausgeführt wird? 

Was passiert, wenn T1 eintrifft und G1 erfüllt ist, während der Do-Teil von B ausgeführt wird? 

Was passiert, wenn T2 eintrifft und G2 erfüllt ist, während der Do-Teil von A ausgeführt wird? 


D 

E


Zwischenstand Zustandsdiagramme 

n� Modellierungselemente 

ð� Zustände und Verhalten in Zuständen 

ð� Transitionen und Aktionen 

ð� Ereignisse 

ð� Zusammengesetzte Zustände 

n� Bisher: 

ð� Beschreibung von zustandsbasierten Vorgängen (Laserdrucker, Tür) 

ð� Beschreibung von Algorithmen (C++-Parser) 

ð� eher als Mittel für die Analyse 

Aber wie funktioniert das im Design, 

d. h. mit Objektorientierung – mit Klassen und Objekten? 



Erste Beobachtung 

n� Betrachten Sie die Zustände, in denen 

sich ein typisches Objekt befinden 

kann: 

ð� Objekt wird angelegt (Konstruktor) 

ð� Objekt ist vorhanden 

- empfängt Nachrichten 

bzw. macht Methodenaufrufe 

- je nach Aufruf und Attributen des 

Objekts werden Attribute verändert 

oder weitere Nachrichten verschickt 

- Ereignisse (z. B. Timer) können 

Aktionen auslösen 

ð� Objekt wird zerstört (Destruktor) 

... durchläuft 

mehrere 

Zustände 

Ein Objekt 

wird erzeugt... 

Aktiv 

… und stirbt 

Der Lebenszyklus von Objekten einer Klasse kann durch Zustandsdiagramme 

beschrieben werden! 

Neu 

Sterbend 



Zweite Beobachtung 

n� Objekte in einem Sequenzdiagramm zeigen Zustände an! 

ð� eingehende Signale ändern den Zustand 

Waiting 

Checking Student 

Exmatriculating 

Zustandsdiagramm 

Exmatrikulationsmaske 

in(MatrNr) 

return (ExStudi) d. h. 

when Studi existiert 

Waiting 

Checking Student 

entry/SV.existiertStud(MatrNr) 

Exmatriculating 

entry/ExStudi.exmatrikulieren() 

return(ok), d. h. 

when Studi exmatrikuliert 



Von Sequenzdiagrammen zum Zustandsdiagramm 

n� Vorgehen zum Herausarbeiten der Zustände 

1. Wähle ein Objekt aus und analysiere ein Sequenzdiagramm in dem es vorkommt 

2. Markiere eintreffende Ereignisse für das betreffende Objekt 

3. Wähle ein Paar von „benachbarten“ Ereignissen 

4. Analysiere was das Objekt zwischen den beiden Ereignissen tut und vergebe 

einen entsprechenden Namen für diesen Zustand 

5. Führe den vorigen Schritt für alle benachbarten Paare durch 

6. Wiederhole das Vorgehen für weitere Sequenzdiagramme 

n� Zeichne ein Zustandsdiagramm 

1. Beginne das Diagramm mit einem Startzustand und den gefundenen Zuständen 

2. Zeichne Transitionen zwischen Zuständen, die im Sequenzdiagramm 

benachbart sind 

3. Ergänze das Diagramm um Ereignisse, Aktionen und bei Bedarf um einen 

Endzustand 

4. Überprüfe, ob es weitere Transitionen geben sollte, die nicht in den 

Sequenzdiagrammen vorkommen 




n� Modellieren Sie einen Mikrowellenherd. 

Die Funktionsweise wird stichwortartig zusammengefasst: 

ð� Die Bedienelemente für den Benutzer sind der Einschaltknopf und die Tür 

ð� Durch Drücken des Knopfes wird die Mikrowelle (die „Backröhre“) eingeschaltet 

ð� Die Kochzeit wird über eine interne Zeituhr auf eine Minute festgelegt 

ð� Durch weiteres n-maliges Drücken des Knopfes wird die Kochzeit um n Minuten 

verlängert 

ð� Wenn die Zeit abgelaufen ist, wird die Backröhre ausgeschaltet, ein Piepton 

ertönt und als nächstes muss die Tür geöffnet werden bevor die Mikrowelle 

erneut gestartet werden kann 

ð� Durch Öffnen der Tür wird die Backröhre abgeschaltet und die verbleibende 

Kochzeit gelöscht 

ð� Der Mikrowellenherd startet nur bei geschlossener Tür 

Die Aufgabe kennen Sie aus 

dem Kapitel Sequenzdiagramme! 

ð� Wenn die Tür offen ist oder wenn der Herd an ist, leuchtet das Licht 

ð� Wenn der Mikrowellenherd ein- bzw. ausschaltet, muss die Backröhre ebenfalls 

ein- bzw. ausgeschaltet werden 




n� Erstellen Sie 

ð� ein Klassendiagramm 

- mit Klassen, Attribute, Methoden, Assoziationen 

ð� die Zustandsdiagramme der Klassen. Suchen Sie dazu: 

- Zustände (z. B. auch in den Sequenzdiagrammen) 

- Ereignisse 

- Zustandsübergänge 

- Aktivitäten 

ð� Die Sequenzdiagramme für folgende Szenarien sollen abgedeckt werden 

- 2 Minuten kochen 

- Tür öffnen und schließen 

- Kochvorgang mit Abbruch durch Tür öffnen 

Die Aufgabe kennen Sie aus 




Lösung Mikrowellenherd: Klassendiagramm 

Die Lösung kennen Sie aus 




Lösung Mikrowellenherd: Sequenzdiagramm „2 Minuten kochen“ 

wartend 

kochend 

kochen fertig 

n� Analysiere die Objekte auf Zustände 

ð� Backröhre 

- an 

- aus 

ð� Licht 

- an 

- aus 

ð� Timer 

- aus 

- aktiv 

ð� Mikrowelle 

- wartend 

- kochend 

- kochen fertig 



Lösung Mikrowellenherd: Sequenzdiagramm „Tür öffnen und schließen“ 



- an 

- aus 

ð� Licht 

- an 

- aus 

ð� Timer 

- aus 

- aktiv 


- wartend 

- geöffnet 

schon bekannt 

neu 



Lösung Mikrowellenherd: Sequenzdiagramm „Kochen mit Abbruch“ 



- an 

- aus 

ð� Licht 

- an 

- aus 

ð� Timer 

- aus 

- aktiv 


- wartend 

- kochend 

- geöffnet 



Lösung Mikrowellenherd: Zustandsdiagramme für Licht und Backröhre 

Licht 

Licht an 

entry / lichtstatus = on; 

an aus 

Licht aus 

entry / lichtstatus = off; 

Backroehre 

Backröhre an 

entry / backstatus = on; 

an aus 

Backröhre aus 

entry / backstatus = off; 



Lösung Mikrowellenherd: Zustandsdiagramm Timer 

Timer 

Timer aus 

entry / reset() 

erhoehe / zeit++; 

start when 

zeit==0 

/myback.alert 

Timer aktiv 

do / zähle zeit runter 

erhoehe / zeit++; 

stop 



Lösung Mikrowellenherd: Zustandsdiagramm Mikrowelle 

Mikrowelle 

wartend 

entry /MyBack.aus, 

MyLicht.aus, MyTimer.reset 

Tür_zu 

Knopf 

/ MyTimer. 

erhoehe 

Tür_auf / MyLicht.an 

kochend 

entry / MyBack.an, 

MyLicht.an, MyTimer.start 

exit / MyBack.aus 

Knopf /MyTimer.erhoehe 

geöffnet 

kochen fertig 

entry / MyLicht.aus, out(Piep) 


alert 

Tür_auf / MyTimer.stop 

Tür_auf / MyLicht.an


Lösung Mikrowellenherd: Bewertung 

n� Aktionen können häufig an verschiedenen Stellen umgesetzt werden 

ð� z. B. als Austrittverhalten des alten Zustands oder als Aktion, die zur Transition 

gehört oder auch als Verhalten des neuen Zustands 

ð� achten Sie darauf, dass Aktionen nicht unnötig oder mehrfach ausgeführt wird 

ð� bedenken Sie, dass nur das Zustandsverhalten länger dauern darf 

ð� bei zyklischen Transitionen wird jeweils das Exit und Entry behavior ausgeführt 

- bei internen Transitionen nicht! 

kochend 


MyLicht.aus, MyTimer.start 


Knopf / MyTimer.erhoehe 

Knopf 

/ Timer.erhoehe 

kochend 


MyLicht.aus, MyTimer.start 


n� Die Verwendung des Exit Verhaltens im Zustand „kochend“ verhindert, dass in 

einem anderen Zustand versehentlich die Backröhre „an“ ist 



Orthogonale zusammengesetzte Zustände 

n� Der Inhalt eines Zustands ist schwer auf Korrektheit zu prüfen, wenn darin 

mehrere eigenständige Objekte behandelt werden 

ð� üblicherweise bei einer Aggregation im Klassendiagramm 

(z. B. auch Timer, Licht, Backröhre) 

n� Ein Zustand kann zur Verbesserung der Übersichtlichkeit in sogenannte 

Regionen (oder Gebiete) aufgeteilt werden 

ð� jede enthält einen parallel ausführbaren 

(„orthogonalen“) Unterzustandsautomaten 

ð� wenn der Oberzustand betreten wird, 

werden alle Unterzustandsautomaten 

parallel betreten 

ð� Auftretende Ereignisse werden 

für jede Region betrachtet 

ð� das Ein- und Austrittsverhalten wird analog 

zu den zusammengesetzten Zuständen 

dargestellt 

kochend 

Backröhre 

an 

entry / an 

exit / aus 

Licht 

an 

entry / an 

Timer 

aktiv 

entry / start 

Knopf / zeit++ 



Weitere Modellierungselemente: Gabelung und Vereinigung 

n� Um parallele Abläufe für orthogonal zusammengesetzte Zustände explizit zu 

machen, gibt es die Gabelung („Fork“) 

ð� die ausgehenden Kanten enthalten weder Trigger 

noch Bedingung 

ð� jede ausgehende Kante führt in eine (andere) Region 

ð� nun können mehrere (Unter-)Zustände aktiv sein, allerdings müssen Sie 

unabhängig voneinander sein und können deshalb auch leicht sequentialisiert 

werden 

n� Um die Synchronisation von parallelen Abläufen (innerhalb von orthogonal 

zusammengesetzten Zuständen) explizit zu machen, gibt es die 

Vereinigung („Join“) 

ð� jede der eingehenden Kanten stammt aus einer Region 

ð� die eingehenden Kanten haben weder Trigger 

noch Bedingung 

n� Die Verfolgung der aktiven Unterzustände erfolgt nach dem Tokenprinzip 

Auslöser [Bedingung] 

Verhalten Verhalten 

Verhalten Verhalten 

Auslöser [Bedingung] 



Weitere Modellierungselemente: Grundidee Historie 

n� Unterzustandsautomaten können auch komplizierter sein, als im 

vorherigen Beispiel 

ð� Stellen Sie sich z. B. ein Autoradio vor, das CD-Player, Radio usw. enthält 

ð� dann wird das Autoradio zu einem Zustandsautomaten, der viele Zustände 

enthält und wiederum selbst Unterzustandsautomaten für CD und Radio enthält 

ð� beim Wiedereintritt in einen Unterzustand wäre es oft praktisch zu wissen, in 

welchem Zustand der Unterautomat zuletzt war 

- z. B. war das Radio auf MW, oder auf UKW, bevor Sie zur CD wechselten? 

ð� Man braucht so etwas wie einen „intelligenten Eingangszustand“, der sich den 

letzten Zustand merkt 

ð� dann wird beim Wiedereintritt 

in den Unterautomaten 

der vorherige Zustand 

wiederhergestellt 

ð� „Historie“ 

CD Betrieb 

Taste RADIO 

[CD eingelegt] 

Radiobetrieb 


FM 

Taste AM 

Taste FM 

AM


Weitere Modellierungselemente: Flache Historie 

n� Eine flache Historie („Shallow History“) 

ð� merkt sich den Zustand der beim Verlassen eines Unterzustandsautomaten 

zuletzt aktiv war 

ð� kann eine Transition definieren, die ausgeführt wird, wenn die Historie noch nicht 

„gesetzt“ ist bzw. gelöscht wurde 

ð� wird gelöscht (d. h. der Inhalt), wenn ein Endzustand des 

Unterzustandsautomaten erreicht wird 

ð� merkt sich NICHT die Zustände von verschachtelten Unterzustandsautomaten 

CD Betrieb 

Taste RADIO 

when(CD eingelegt) 

definiert Zielzustand 

bei leerer Historie 

H 

FM 

Radiobetrieb 

flache Historie 

Taste AM 

Taste FM 


AM


Weitere Modellierungselemente: Tiefe Historie 

n� Eine tiefe Historie („Deep History“) 

ð� merkt sich den zuletzt aktiven Unterzustand in der aktuellen und in allen weiteren 

Unterzustandsautomaten 

ð� kann eine Transition definieren, die ausgeführt wird, wenn die Historie noch nicht 

„gesetzt“ ist bzw. gelöscht wurde 

ð� wird gelöscht (d. h. der Inhalt), wenn ein Endzustand des 

Unterzustandsautomaten erreicht wird 

ð� merkt sich die Zustände von allen verschachtelten Unterzustandsautomaten 

CD Betrieb 

Taste RADIO 

[CD eingelegt] 

H* 

FM1 

FM 

Taste FM 

Taste FM 

tiefe Historie 

Radiobetrieb 

FM2 

Taste AM 

Taste FM 


AM


Vom Zustandsautomat zum laufenden Code (Prinzip) 

n� Umsetzung eines Systems mit Zustandsautomaten 

ð� Die Implementierung der Klassen mit Methoden und Attributen ist bekannt 

ð� Die Zustände und Ereignisse kann man mit Switch/Case und Enums umsetzen 

ð� Das Eintreffen eines Ereignisses kann man durch Methodenaufrufe realisieren 

ð� Das ist für jeden Zustandsautomat das Gleiche! 

ð� Verwende eine generische Laufzeitumgebung für Zustandsdiagramme! 

n� Es gibt mächtige Tools/Frameworks für Zustandsautomaten (z. B. Rhapsody) 

ð� lesen Zustandsautomaten bzw. -diagramme ein 

ð� erzeugen lauffähigen Code 

ð� stellen die erforderliche Infrastruktur bereit (Timer, Messaging,...) 

- zum Verschicken von Nachrichten, zum Aufrufen von Methoden, zum Verfolgen des 

aktiven Zustands, usw. 

ð� unterstützen bei der Entwicklung mit „Debugger“, Analyseverfahren usw. 



Parallelität, synchron oder asynchron? Aktive Objekte 

n� In den Zustandsdiagrammen tauchen mehrere Objekte auf, die offensichtlich 

eigenständig „leben“ 

ð� z. B. muss der Timer weiterzählen, während die Mikrowelle auf einen 

Tastendruck wartet; das heißt die Mikrowelle und der Timer arbeiten parallel 

ð� und die Backröhre heizt eigentlich für eine längere Zeitdauer – wir haben das 

einfach auf das An-/Ausschalten beschränkt 

ð� in den Sequenzdiagrammen wurde das Problem schon angedeutet 

(durch asynchrone Nachrichten mit einer in()-/out()-Notation) 

– aber dort dürfen auch mehrere Objekte gleichzeitig aktiv sein! 

ð� In einem Zustandsautomaten darf immer nur ein Zustand aktiv sein! 

n� Eigentlich braucht man mehrere Zustandsautomaten, die parallel arbeiten und 

Nachrichten austauschen können! 

ð� Das Konzept der „aktiven Objekte“ erlaubt dies und die zuvor erwähnten Tools 

unterstützen auch diese Fähigkeit 

ð� Durch Multitasking, kritische Bereiche, asynchrone Kommunikation etc. wird die 

Umsetzung dann deutlich komplizierter... (und wird deshalb hier nicht behandelt) 




n� Welche Verhalten können innerhalb eines Zustands auftreten? 

n� Wie ist die Ausführungsreihenfolge bei einem Zustandsübergang? 

n� Was passiert, wenn es mehr als eine Transition gibt, deren Wächter und Trigger 

erfüllt sind? 

n� Was bedeutet eine Transition, die keinen Trigger hat, sondern nur einen 

Wächter? 

n� Was haben Zustandsdiagramme mit Objekten zu tun? 

n� Wie extrahiert man aus Sequenzdiagrammen die Zustände? 

n� Wie kann man Zustandsautomaten ausführbar machen? 






Zusammenfassung 


5.3.4 Darstellung der Dynamik eines Systems: Zusammenfassung 


n� Warum sind Verhaltensdiagramme eine wichtige Ergänzung zu 

Strukturdiagrammen? 

n� Welche Elemente enthält ein Sequenzdiagramm? 

n� Gehört ein Aktor zum System? 

n� Wann verwendet man (a)synchrone Aufrufe? 

n� Welche Bedeutung hat die Aktivierung? 

n� Was sind „Combined Fragments“? 

n� Sind Sequenzdiagramme ausführbar? 

n� Welchen Vorteil bieten Kommunikationsdiagramme? 

n� Wann verwenden Sie Zustandsdiagramme? 

n� Sind Zustandsdiagramme ausführbar? 

Können Sie jetzt die Dynamik eines Systems 

in Diagrammen darstellen?

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?