OO-Phasen fÃ¼r Embedded Systems Dynamisches Verhalten in UML ...

Dynamisches Verhalten in UML 

OO-Phasen für Embedded Systems 

Vorlesung Automatisierungsprojekte Seite 9/1 


OO-Phasenübersicht 

Vorlesung Automatisierungsprojekte Seite 9/2


System-Fähigkeit 

Objekte arbeiten zusammen, um die System-Funktionalität herzustellen. 

Pilot 

Pilot 

Assoziation 

Steuerfläche 

Flügel 

Externes 

Interaktionsobjekt 

(Akteur, actor) 

Kursänderung 

Auf 

Ab 

Flugzeug-Autopilot 

Use cases 

kooperierende 

realisiert. 

Flugrechner 

Links 

Rechts 

Systemfähigkeit 

(Use Case) 

Setze Drehzahl 

Auf 

Aileron Seitenruder Höhenruder 

Druck+ 

Druck+ 

werden durch 

Objekte 

Druck- 

Druck- 

Ab 

Druck+ 

Objekt 

Nachricht 

Triebwerk 

Steuerfläche 

Heck 

Hydrauliksystem 

Druck- 



Übungsbeispiel UML: Telefonanlagenverwaltung 

In einem ersten Schritt: Spezifikation einer Klasse Telefon und einer Klasse Telefonanlage. 

Jedes Telefon ist an eine Telefonanlage angeschlossen. 

Telefonanlage: Stellt die Verbindung zum Telefonnetz der Telekom her und kann maximal 901 

Nebenstellen verwalten (3-stellige Durchwahl, 0 für die Zentrale). 

Jedes Telefon: Es müssen die Nebenstellennummer des Apparats, die Berechtigungsstufe 

(international, national, intern) sowie der Aufstellort und die Anzahl der verbrauchten Einheiten 

gespeichert werden. Es soll möglich sein, ein Telefon zu sperren, wenn eine maximal erlaubte 

Anzahl von Einheiten verbraucht ist. Dazu gibt es eine Operation Sperren, die die verbrauchten 

Einheiten mit einer für alle Apparate gleichen maximal erlaubten Telefoneinheitenanzahl vergleicht. 

Für die Telefonanlage wird die Anzahl der zur Verfügung stehenden Amtsleitungen, die 

Amtsnummer und eine Anlagenkennung gespeichert. 

• Erstellen Sie ein Klassen-Diagramm für die beiden Klassen des beschriebenen Szenario in 

UML-Notation. 

• Erstellen Sie ein Objekt-Diagramm für eine Telefonanlage mit drei Nebenstellenapparaten in 

UML-Notation. 

• Erweitern Sie das Klassendiagramm der Klasse Telefon um eine Operation »Gesamt- 

Sperren«, die an alle Telefone die Botschaft Sperren schickt. 







Erweitern Sie das Klassen-Diagramm des beschriebenen Szenarios um 

Assoziationen und Kardinalitäten 




Es ist erforderlich geworden, das Software-System um verschiedene Telefonarten zu 

erweitern (Fax und ISDN-Gerät). Bei Fax-Geräten muss zusätzlich zu den Telefondaten die 

Stationskennung (Text) und bei ISDN-Geräten die Art des Anschlusses (Modem, PC-Karte, 

Telefon) gespeichert werden. 

• Ändern Sie das Klassendiagramm so ab, dass der neuen Situation Rechnung 

getragen wird. Die bereits definierten Klassen sollen möglichst unverändert 

übernommen werden. 

• Erstellen Sie für diese erweiterte Telefonanlage ein Objekt-Diagramm mit drei 

unterschiedlichen Arten von Nebenstellenapparaten in UML-Notation. 






UML – Unified Modeling Language 

• Sprache zur Beschreibung von Komponenten und 

Beziehungen komplexer Systeme 

• Bei der OMG (Object Management Group) eingereicht von 

– Grady Booch, Jim Rumbaugh & Ivar Jacobson 

• Unterstützt von 

– Digital, HP, Microsoft, MCI, Oracle, TI, Unisys, etc. 

– Von der OMG im November 1997 akzeptiert 



UML – Primäreigenschaften 

• UML ist derzeit eine der umfassendsten Methoden zur 

Modellierung komplexer Systeme, 

inkl. eingebetteter Echtzeit-Systeme 

– Use Cases und Szenarien 

– Objektmodell 

– Verhaltensmodellierung mit Zustandsdiagrammen 

– Paketierung von verschiedenen Arten von Entitäten 

– Repräsentation von Aufgaben und Aufgabensynchronisation 

– Modelle physikalischer Topologie 

– Modelle zur Quellkodeorganisation 

– Unterstützung von objektorientierten Mustern 



UML-Diagrammtypen 

• Use-Case-Diagramm (auch: Anwendungsfalldiagramm) 

• Kollaborationsdiagramm (engl. Collaboration Diagram) 

• Sequenzdiagramm (engl. Sequence Diagram) 

• Klassendiagramm (engl. Class Diagram) 

• Zustandsdiagramm (engl. Statechart Diagram) 

• Aktivitätsdiagramm (engl. Activity Diagram) 

• Komponentendiagramm (engl. Component Diagram) 

• Verteilungsdiagramm (engl. Deployment Diagram) 

• Objektdiagramm (engl. Object Diagram) 



Objektorientierte Analyse 

Anforderungsanalyse: Akteure und Geschäftsprozesse des Systems 

• Use-Case-Diagramm (auch: Anwendungsfalldiagramm) 

Systemanalyse anhand Szenarios: Zusammenarbeit von Objekten, um 

mögliche Abläufe der Geschäftsprozesse zu realisieren: Beteiligte Objekte, 

ausgetauschte Nachrichten, benötigte Operationen. 

• Kollaborationsdiagramm (engl. Collaboration Diagram) 

• Sequenzdiagramm (engl. Sequence Diagram) 

Nicht konstruktivistisch: es kann kein vollständiger Code abgeleitet 

werden. Weitere Abstraktion und Zusammenfassung nötig. 

• Objektanalyse: Abstraktion der Objekte 

• Klassendiagramm (engl. Class Diagram) 

• Dynamikanalyse: Abstraktion des Verhaltens 

• Zustandsdiagramm (engl. Statechart Diagram) 



UML – Objekte 

• Repräsentation von Dingen, die sowohl Daten als auch Verhalten 

aufweisen: realweltliche Dinge (z.B. Sensoren, Maschinen) oder 

begriffliche Dinge (z.B. Gefahr, Aufmerksamkeit) 

– Attribute (Daten) 

– Verhalten (Operationen oder Methoden) 

– Zustand (gespeicherte Werte) 

– Identität 

– Verantwortlichkeiten bzw. Zuständigkeiten 

Beispiel: Winkelsensor 



UML – Verhaltensmodelle für Objekte 

• Einfach 

– Das Objekt führt Dienstleistungen durch und speichert keinerlei 

Daten vorhergehender Dienstleistungen. 

– Jede Handlung ist (von außen betrachtet) atomar und 

vollständig. 

z.B.: Verwaltung von primitiven Datentypen und Operationen, cos(x) 

• Automat: in UML besonders stark berücksichtigt! 

– Objekt wird als eine spezielle Maschine behandelt: EA 

– Endliche Menge von Bedingungen, Zuständen und Übergängen 

– Muss in genau einem Zustand zu einem Zeitpunkt sein. 

– Zustand: wechselseitig ausschließliche Existenzbedingung, definiert durch 

verarbeitete Ereignisse und durchgeführte Aktionen. 

– EA reagiert auf Ereignisse: „reaktives Objekt“. 

• Kontinuierlich 

– Unbegrenzte Anzahl von Existenzbedingungen 

Beispiel: Algorithmisches Objekt, welches einen Algorithmus auf einem ggf. 

unendlichen Eingabestrom ausführt, z.B. FIR-Filter. 

– Aktuelles Verhalten hängt vom vergangenen Verhalten ab. 



UML – Klassen 

• Eine Klasse ist eine Abstraktion gemeinsamer Merkmale einer 

Menge von ähnlichen Objekten; eine Art „Objekttyp“ 

• Eine Klassendeklaration erfolgt meist durch Beobachtung einer 

Reihe von Objekten und der anschließenden Abstraktion 

gemeinsamer Merkmale 

• UML-Notation 

Klassenname 

Klassenname 

Attributliste 

Operationen 



UML – Objekt- und Klassenbeziehungen 

• Es gibt 5 elementare Typen von Objektbeziehungen 

– Assoziation: Beziehung manifestiert sich typisch zur 

Laufzeit und erlaubt Botschaftsaustausch 

– Aggregation: falls ein Objekt logisch oder physikalisch ein 

anderes enthält oder beinhaltet („□ consists of") 

– Komposition: Ähnlich wie Aggregation, Besitzer ist für die 

Instantiierung und Freigabe des Teilobjekts verantwortlich; 

es kann nur einen Besitzer geben (nicht teilbar) 

– Generalisierung (Vererbung): „□ is-a-kind-of"-Beziehung 

– Abhängigkeit: „□ depends-on"-Beziehung 




– Kardinalitäten am Beispiel der Beziehung Assoziation 

Klasse A 

K A 

Rolle A 

◄ Assoziationsname 

Assoziationsname ► 

K B 

Rolle B 

Klasse B 

Klasse A 

1 

Genau eine Beziehung (Muss-Beziehung) 

Klasse A 

* 

Viele Beziehungen: Null, eine, mehrere (Kann-Beziehung) 

Klasse A 

0...4 

Null bis fünf Beziehungen (Kann-Beziehung) 

Klasse A 

3 

Genau drei Beziehungen (Muss-Beziehung) 

Klasse A 

1,4,7 

Eine, vier oder sieben Beziehungen (Muss-Beziehung) 

Klasse A 

1..4,6,8..* Eine bis 4, 6, 8 oder mehr Beziehungen (Muss-Beziehung) 




– Assoziation: Interpretation 

Klasse A 

K A 

Rolle A 

◄ Assoziationsname 

Assoziationsname ► 

K B 

Rolle B 

Klasse B 

1 1..* 

Supervisor überwacht ► 

Kfz-Steuergerät 

Airbag- 

Steuergerät 

Ein Airbag-Steuergerät in seiner Rolle als Supervisor überwacht ein oder 

mehrere Airbag-Steuergeräte. 

Rollennamen oder Assoziationsnamen müssen angegeben werden, wenn 

zwischen zwei Klassen mehr als eine Assoziation besteht. 

1 * 

Mitarbeiter 

0..1 0..1 

Fahrer 

Unternehmen 

Arbeitgeber 

Arbeitnehmer 

Dienstwagen 

PKW 

Ein Unternehmen hat in seiner Rolle als Arbeitgeber null, einen oder mehrere Mitarbeiter. 

Ein Mitarbeiter ist in seiner Rolle als Arbeitnehmer Mitglied genau einer Firma. 

Ein Mitarbeiter fährt in seiner Rolle als Fahrer einen PKW. 

Ein PKW wird in seiner Rolle als Dienstwagen von einem Mitarbeiter gefahren. 




Komposition und Aggregation 

– Aggregation: falls ein Objekt logisch oder physikalisch ein 

anderes enthält oder beinhaltet ("consists of"). 

Eine Instanz einer Klasse kann Bestandteil mehrerer Instanzen einer 

Aggregatklasse sein. 

Web-Auftritt 

* 1..* 

Web-Seite 

– Komposition: Ähnlich wie Aggregation, Besitzer ist für die 

Instantiierung und Freigabe des Teilobjekts verantwortlich; 

es kann nur einen Besitzer geben (nicht teilbar). 

Eine Instanz einer Klasse kann nur Bestandteil genau einer Instanz einer 

Aggregatklasse sein. Wird eine Instanz der Aggregatklasse gelöscht, so 

werden auch alle durch Komposition referenzierten Instanzen gelöscht. 

Autopilot 

1 1..* 

Aerofoil-Surface- 

Controller 



UML – Beispiel: Sensorklassenbeziehung 

{abstract} 

Wärmebildkamera 

Videokamera 

Laserscanner 

1...N 

Optischer 

Sensor 

Sensor 

„ist eine Art von ...“ 

Optische 

Messvorrichtung 

1 

Multiplex- 

Sensor 

* 

Uniplex- 

Sensor 

1 

A/D- 

Konverter 

1 1 

A/D- 

Konverter 

„besteht aus ...“ 



UML – Botschaften und Schnittstellen 

• Objekte tauschen Botschaften über Schnittstellen aus 

• Eine Botschaft ist eine Datenabstraktion oder 

Kontrollinformation, Implementierungsmöglichkeiten: 

– Funktionsaufrufe 

– Ereignis (Event) via RTOS 

– Interrupt 

– Semaphore-geschützte gemeinsam genutzte Ressource 

– RPC (Remote Procedure Call) im verteilten System 

• Bei der Analyse werden Schlüsselbotschaften identifiziert; beim 

Design Synchronisation und Zeitanforderungen 

• Intern geschieht im Objekt folgendes 

– Übersetzung in Operationen, Zustandsübergänge, Befehle 

oder Daten 



UML – Dynamisches Objektverhalten – State Charts 

Nur Classifier wie Use Cases und Klassen können Zustandsmodelle definieren 

und nur Objekte können Zustandsmaschinen ausführen. 

Harel-Zustandsdiagramme (siehe Auto2_4) sind die Grundlage der UML State 

Charts. 

Wesentliche Charakteristika: 

• Modellierung mit endlichen Automaten erweitert durch 

• Hierarchische Struktur 

• Nebenläufigkeit 

• Bedingte Übergänge 

• Pseudozustände 




State Chart Transitionen 

Erweiterung gegenüber Harel-Notation um Parameterliste: 

A 

Ereignis (Parameterliste) [Guard] / Aktionsliste 

B 

Parameterliste: Kommagetrennte Liste mit Namen der Datenparameter, die bei 

Ereigniseintritt weitergegeben werden. Deklaration der Parameter an der 

Transition, welche die Parameter entgegennehmen (und verarbeiten). 

X 

T1(a:int, b:float) / c=b^a 

Y 

Aktionsliste: Kommagetrennte Liste der Operationen, die beim 

Zustandsübergang ausgeführt werden (Ereigniserzeugung, 

Operationsaufrufe). 

Guard: Boolescher Ausdruck, der den Wert „wahr“ ergeben muss, damit der 

Übergang stattfinden kann 

tm(Zeitdauer) 

X 

Y 

Timer-Ereignisse: Timer wird bei Einnahme des Zustandes gestartet, 

Ereignis bei Ablauf der Zeitdauer ausgelöst. 




State Chart Transitionen 

Quell-Objekt 

Zust1 

S(a,b,x, y) / a=12, b=3.14, 

x=23, y=2.73, T 

Zust1 

Quelle 1 

1 

Quelle 

Ziel1 

1 

1 

Ziel2 

Obj1 

Obj2 

ZustA 

T(a:int, b:float) / c=b^a 

ZustB 

ZustX 

T(x:int, y:float) / z=x/y 

ZustY 




Pseudozustände von UML 1.3 

Initial oder Default: Gibt in einem Superzustand an, welcher seiner 

Subzustände bei Einnehmen des Superzustandes zuerst 

eingenommen wird. 

Terminaler, finaler oder End-Zustand: Beendigung des 

T 

eingeschlossenen zusammengesetzten Zustandes. 

Junction (Kreuzung): Zusammenführung mehrfacher Übergänge 

oder Aufspaltung einer Transition in mehrere Folgetransitionen. 

Auswahlpunkt, choice point: Eine Junction, die ihre Aktionsliste 

ausführt, bevor zum nächsten Transitionssegment 

übergegangen wird. Erlaubt die Ausführung von Aktionen, die 

an das erste Übergangssegment gebunden sind, vor der 

Auswertung nachfolgender Guards. 

Join: Verbindet mehrfache eingehende Transitionen von 

nebenläufigen Zuständen in eine einzige Transition. 

Fork: Verzweigt eine Eingangstransition in mehrere Transitionen 

nebenläufiger Zustände. 





History (flach): Gibt in einem Superzustand an, dass derjenige 

seiner Subzustände bei Einnehmen des Superzustandes 

eingenommen wird, der zuletzt verlassen wurde. 

Verfeinerungszustände der Subzustände nehmen dann ihren 

Initialzustand ein. 

History (tief): Gibt in einem Superzustand an, dass derjenige seiner 

Subzustände bei Einnehmen des Superzustandes 

eingenommen wird, der zuletzt verlassen wurde. Dies gilt auch 

für alle Verfeinerungszustände der Subzustände. 

H 

H* 





Junction (Kreuzung): Zusammenführung mehrfacher Übergänge 

oder Aufspaltung einer Transition in mehrere Folgetransitionen. 

A 

T1/f 

T3/h 

C 

Diagramm 1 

[y>0] 

B 

T2[x0]/f,m,n 

T3/h,m,n 

C 

Diagramm 2 

D 

B 

T2[x0]/g,m,n 





Auswahlpunkt, choice point: Eine Junction, die ihre Aktionsliste ausführt, bevor zum 

nächsten Transitionssegment übergegangen wird. Erlaubt die Ausführung von 

Aktionen, die an das erste Übergangssegment gebunden sind, vor der 

Auswertung nachfolgender Guards. 

Warten auf Münzen 

Entry/ Betrag = 0 

Münze_ein(Münzwert)/ 

Betrag=+Münzwert 

[Betrag > Soll] 

Wechselgeld geben 

Entry/ Wechselbetrag= 

Betrag-Soll; 

Wechselgeld zurückgeben 

[else] 

[Betrag == Soll] 

Rückgabe_erfolgt 

erledigt 

Auswahl bearbeiten 




Aktionen 

• Aktionsliste von Übergängen 

• Entry actions 

• Exit actions 

Werden durchgeführt, wenn Zustandsübergang eintritt, Zustand eingenommen 

bzw. verlassen wird. Laufen vollständig durch und sind nicht unterbrechbar 

durch Ereignisse, die dem Objekt gesandt werden. 

Sie können sein: 

• Methodenaufrufe innerhalb des Objekts, zu dem der Zustandsautomat 

gehört. 

• Methodenaufrufe anderer Objekte (mit denen das aktuelle Objekt 

Assoziationen hat. 

• Erzeugung oder Löschung anderer Objekte 

• Zuweisungen, wie z.B. „z += 18“ 

• Löschung des Objekts, zu dem der Zustandsautomat gehört. 

• Erzeugung und Versendung von Signalen zu anderen nebenläufigen 

Automaten oder Objekten (sog. SendAction): Synchronisation. 




Aktivitäten 

• Werden durchgeführt, solange ihr Zustand eingenommen wird. Sie sind 

unterbrech- und beendbar durch eintreffende Ereignisse. 

• Aktivitäten sind gewöhnlich längere, unterbrechbare Verhalten, währen 

Aktionen kurze, ununterbrechbare Verhalten sind. 

• Beendet eine Aktivität vor einem unterbrechenden Ereignis, sendet sie einen 

completion event an ihr Objekt, was alle Übergänge ohne Ereignis-Trigger 

auslöst. 




Aktionen in verfeinerten Zuständen: Stubbed transitions 

• Entry Aktionen werden in der gleichen Reihenfolge durchgeführt wie die 

durchlaufenen Verfeinerungsstufen. 

Z1 

Entry/ en_1 

Exit/ ex_1 

E1 / a,b 

Z2 

Entry/ en_2 

Exit/ ex_2 

Z3 

Entry/ en_3 

Exit/ ex_3 

E2 / c,d 

E1: a, b, en_1, en_2, en_3 

E3: e, ex_3, ex_2, en_4 

E3 / e 

Z4 

Entry/ en_4 

Exit/ ex_4 




Nebenläufige Zustände 

Sind immer Unterzustände eines Oberzustandes. Ist dieser auf der äußersten 

Ebene eines Statecharts, wird er als einzelner Zustand gezeichnet. 

Farbe 

Z_rot 

Betriebsart 

Initial 

Z_grün 

init 

gestartet 


Z_blau 

grün 

[IS_IN(Fehlerstatus::Ok) 

[normal] 

Z_normal 

[else] 

Demo 

Fehlerzustand 

Ok 

Fehler(err)/log(err) 

Fehlerfall 

BehebungsCmd/genSignal(init) Entry/handle(err) 




Nebenläufige Zustände 

• Jede der orthogonalen Komponenten arbeitet unabhängig. 

• Ein Objekt muss in genau einem Unterzustand jedes der nebenläufigen 

Zustände sein, solange der zugehörige Oberzustand aktiv ist. 

• Der Gesamtzustand des Objekts ist das Kreuzprodukt der Unterzustände in 

den aktiven nebenläufigen Zuständen. 

• Empfängt ein Objekt ein Ereignis, wird es von allen aktiven Unterzuständen 

empfangen. 

• Synchronisation mit 

‣ Join Pseudozustand 

‣ Fork Pseudozustand (wenn nicht die Initialzustände eingenommen 

werden sollen) 

‣ Broadcast Ereignisse 

‣ Propagierte Ereignisse 

‣ IS_IN() Operator 

‣ Synch Pseudozustand 




Synchronisation mit 

‣ Join Pseudozustand 

‣ Fork Pseudozustand (wenn nicht die Initialzustände eingenommen 

werden sollen) 

Farbe 

Z_rot 

Ablauf 

t0 

Start 

Betriebsart 

Initial 

Z_grün 


gestartet 


Z_blau 

grün 

[IS_IN(Fehlerstatus::Ok) 

t1 

[normal] 

Z_normal 

t1 

[else] 

Demo 

Ende 





‣ Broadcast Ereignisse: Werden von allen nebenläufigen Zuständen des 

Objekts empfangen. 

‣ Propagierte Ereignisse: Werden als Ergebnis einer Transition gesendet 

durch eine Aktion SendAction (z.B. GenSignal()). 

‣ IS_IN() Operator: TRUE, wenn bezeichneter Zustand eingenommen. 

Bedingung in Guard. 

Ober 

Unter1 

Unter3 

B 

e1 

F 

A 

e2/ 

genSignal(e3(x,y,z)) 

C 

e3(a:int, b:float, c:char) 

D 

E 

Unter2 e1 

e4[IS_IN(D)] 

e5 

G 

e3(a:int, e6 

b:float, c:char) 

H 





‣ Synch Pseudozustand: Analog zu Stellen in Stellen/Transitionsnetzen. 

In Verbindung mit Fork- und Join-Pseudozuständen: 

‣ Synch ist Ausgabe eines Fork-Pseudozustandes und wird mit jeder 

Aktivierung dessen inkrementiert. Wird dabei die Kapazität des 

Synch überschritten, kann die Transition nicht stattfinden. 

‣ Synch ist auch Eingabe eines Join-Pseudozustandes und wird mit 

jeder Aktivierung dessen dekrementiert. Wird dabei der Wert des 

Synch negativ, kann die Transition nicht stattfinden. 

A 

D 

B 

C 

4 

E 

F 




Hierarchische Zustände 

Untermaschinen 

Ober 

Unter1 

Unter2 

include/ subm1 include/ subm2 

ZS1_1 

ZS2_1 

ZS1_2 

ZS2_2 

ZS1_3 

Unter3 

subm1 

subm2 

ZS1_1 

… 

ZS1_2 

ZS1_3 




Hierarchische Zustände 

Vererbung 

Modifikationen im vererbten Modell: 

• Hinzufügen neuer Zustände und Übergänge erlaubt 

• Löschen von Zuständen und Übergängen der Eltern nicht erlaubt 

• Modifikation von Aktions- und Aktivitätenlisten erlaubt 

• Spezialisierung von Aktionen und Aktivitäten 

• Unterzustände dürfen ihre Oberzustände nicht verändern. 

• Transitionen können auf andere Zustände umgebogen werden. 

• Orthogonale Komponenten dürfen zugefügt werden. 




Beispiel Mikrowellenherd 

Spezifikation: 

• Im Zubereitungsmodus muss der Benutzer die Kochzeitdauer und kann Leistungsstufe 

eingeben. Nach Drücken des Aktivierungsknopfes wird das Licht im Ofen, das 

Gebläse, der Drehteller und die Mikrowelle für die eingestellte Zeit eingeschaltet. 

• Die Leistungsstufe wird realisiert, indem das Magnetron ein- und ausgeschaltet wird. 

Stufe 10 bedeutet, dass es in einem Zyklus die ganze Zeit an ist, während Stufe 1 

bedeutet, dass es in 10% einer Zykluszeit an ist. Im Zubereitungsmodus ist die 

Default-Stufe (falls nicht anders gesetzt) 10. 

• Der Herd schaltet das Magnetron nur ein, wenn die Tür geschlossen ist und schaltet 

es aus, sobald die Tür geöffnet wird. 

• Das Licht geht an, wenn die Tür geöffnet oder der Kochvorgang gestartet wird. 

• Der Herd besitzt einen Auftau-Modus, für den die Default-Leistungsstufe 10 ist, und 

ferner einen Timer-Modus, worin er nur als Countdown-Timer ohne Licht, Ventilator, 

Drehteller oder Magnetron arbeitet. 

• Der Herd zeigt die eingestellte Koch- bzw. Timer-Dauer, die Restlaufzeit, die 

Leistungsstufe und den Modus an. 

• Der Ablauf der Koch- bzw. Timer-Dauer wird durch ein akustisches Signal angezeigt. 





Spezifikation: 

• Der Eingabe dienen ein Ziffernblock und Knöpfe für Timer- und Leistungsstufe-Setzen, 

Auftaumodus aktivieren, Zubereitungsmodus aktivieren und Timermodus aktivieren 

und Abbruch. 

• Zur Bestimmung der Zeitdauer 

werden die Zifferntasten und die 

Zeitsetz-Taste benutzt. 

Möglicher Ablauf: Zeitsetz-Taste zur 

Initialisierung der Eingabe und Umschalten 

des Einstellmodus für die 

einzelnen Stellen von Minuten und 

Sekunden; Zifferntasten zur Eingabe. 

• Ähnlich kann die Leistungsstufe eingegeben werden: „0“ für Stufe 1 bis „9“ für Stufe 

10. 

• Wird die Tür geöffnet, wir der laufende Modus unterbrochen und nach Schließen 

wieder aufgenommen. 

Zeit 

setz 

Leist. 

setz 

Objekte (physisch motiviert): Tasten, Display, Licht, Piepser, Türsensor, Ventilator, 

Drehteller, Mikrowellensender, Timer. Koordinationskomponente: kochMeister 

7 

4 

1 

0 

8 

5 

2 

9 

6 

3 

Zuber. 

Auftau 

Timer 

Abbruch 

00:00 

9 




Beispiel Mikrowellenherd - Klassendiagramm 

display 

1 

stufeView:stringView 

1 

1 1 

timerView:stringView modusView:bitMap 

1 

1 

1 

1 

kochMeister 

1 

licht 

1 

Tastenfeld 

10 

ziffernKnopf:Button 

1 

zuberAktKnopf:Button 

1 

auftauAktKnopf:Button 

1 

timerAktKnopf:Button 

1abbruchKnopf:Button 

1 

zeitsetzKnopf:Button 

1 

leistsetzKnopf:Button 

1 

1 1 

kochTimer 

1 

1 

türSensor 

1 

piepser 

1 

1 

1 

mw_sender 

1 1 

drehtellerMotor ventilator 





Zusammengesetzte Klassen (Komposition): Tastenfeld, Display. 

Aggregation: kochMeister mit kochTimer, türSensor, piepser und mw_Sender. 

Sonst Assoziationen 

Konvention zur Benennung der Zeiger, welche die Assoziation implementieren: 

Anfügen von „sein“ vor den Namen der Klasse am anderen Ende der 

Assoziation. Z.B. seinVentilator->einschalten( ); ruft Operation einschalten 

der Klasse Ventilator. 

Mit GEN(Ereignisname) wird eine Operation zur Erzeugung eines Ereignisses 

bezeichnet, dem der Zielobjektname vorangestellt wird. 

Z.B. als Aktion: evTürOffen/ seinTimer->GEN(evPause); 

Reaktive Klassen: 

• kochMeister, 

• kochTimer, -> Statecharts für das Verhalten dieser Klassen 

• türSensor 

• mw_Sender 





Reaktive Klassen: 

• kochMeister 

Steuert die aggregierten Objekte entsprechend Modi, kochTimer- 

Zustand und Fertig-Ereignis von kochTimer. 

Suspendiert den laufenden Modus, solange Tür geöffnet ist. 




Beispiel Mikrowellenherd, Statechart für kochMeister: 

evAbbruch / seinTimer->GEN(evAbbruch); seinMw_sender->GEN(evAbbruch); seinPiepser->piep( ); 

kochMeisterZustand 

Ablauf 

H 

Timing 

TimerAblauf 

bereit 

evTimingSel 

[seinKochTimer-> 

IS_IN(ZeitGesetzt)] 

evMicroAn 

[(seinTürSensor->IS_IN(zu)] 

evFertig / seinMw_sender->GEN(evFertig); seinPiepser->piep( ); 

evAuftauenSel 



Auftauen 

evZubereitenSel 



Zubereiten 

evMicroAn[(seinTürSensor->IS_IN(zu)] / 

seinMw_sender->GEN(evMicroAn); 


seinMw_sender->GEN(evLeistungAn) 

KochenAblauf 

AuftauAblauf 

evTürÖffnet / 

seinMw_sender->GEN(evPausieren); 

seinKochTimer->GEN(evPausieren); 

Pause 


seinMw_sender->GEN(evLeistungAn); 

seinKochTimer->GEN(evLeistungAn); 




Beispiel Mikrowellenherd, Statechart für mw_sender: 

Steuert die Leistung des Magnetrons durch Pulsweitenmodulation. 

Steuert die mit seinem Betrieb verbundenen Objekte Licht, Ventilator und Drehteller. 

Schaltet Leistung ab, wenn Pause-Modus vom Objekt kochMeister angefordert wird. 

Schaltet Leistung ab, wenn Abbruch vom Objekt kochMeister gefordert oder Zeitablauf vom Objekt 

kochTimer signalisiert wird. 

bereit 

evLeistungAn / berechne(leistungStufe, sTime, wTime); 

evAbbruch 

evAbbruch 

evFertig 

Betrieb 

Abstrahlen 

tm(sTime) / 

magnetronAus( ); 

Abwarten 

tm(wTime) / 

magnetronAn( ); 

Pause 

evLeistungAn 

evPausieren 

entry/ seinLicht->einschalten( ); 

seinVentilator->einschalten( ); 

seinDrehteller->einschalten( ); 

exit/ leistungAus( ); 

if (seinTürSensor->IS_IN(Closed)) 

seinLicht->ausschalten( ); 

seinVentilator->ausschalten( ); 

seinDrehteller->ausschalten( ); 




Beispiel Mikrowellenherd, Statechart für mw_kochTimer: 

Ermittelt die Zeitdauer aufgrund von Tastendrücken. 

Verweilt in Zustand Countdown, bis eingestellte Zeit abgelaufen; signalisert Objekt kochMeister, 

wenn Zeit abgelaufen. 

Hält den Timer an, im Falle, dass Objekt kochMeister Pausieren fordert. 

evZiffer/ 

seinZifferknopf->zahl(z1); 

Bereit 

evZeitsetz 

MinErsteStelle 

do/ seinTimerView 

->blink(1,z1); 

evFertig 

evAbbruch 

evZeitsetz/ 

berechneZeit(gesetzteZeit); 

ZeitGesetzt 

SekZweiteStelle 

do/ seinTimerView 

->blink(4,z4); 

evZiffer/ 


evZeitsetz [z1blink(2,z2); 

evZeitsetz 

evZeitsetz[z3blink(3,z3); 

evZiffer/ 


evZiffer/ 





Beispiel Mikrowellenherd, Statechart für mw_kochTimer: 

ZeitGesetzt 

bereit 

evMicroAn / kochZeit=gesetzteZeit; 

tm(kochZeit)/seinKochMeister->GEN(evFertig); 

Countdown 

evAbbruch 

evAbbruch 

Pause 

evMicroAn 

evPause / kochZeit=getRestZeit( ); 




Beispiel Mikrowellenherd, Statechart für türSensor: 

Ermittelt Status der Tür (wird vom Objekt mw_sender zur Aktivierung der Strahlung benutzt) und 

erzeugt das Ereignis TürSchließt (versetzt das Objekt kochMeister in den Pause-Modus). 

else 

Offen 

Entry/ seinLicht->einschalten( ) 

Status 

do/ s=getTürStatus( ) 

evTürSchließt / 

seinKochMeister-> 

GEN(evTürSchließt) 

evTürÖffnet / 

seinKochMeister-> 

GEN(evTürÖffnet) 

[s==zu] 

Zu 

Entry/ seinLicht->ausschalten( ) 



UML – State Charts und Klassendiagramme 

Beispiel Herzschrittmacher: Klassendiagramm 

Zustandsdiagramm zu 

AtrialModel auf der 

folgenden Folie 


Aus: Bruce Powel Douglass: Real Time UML Second Edition 


UML – State Charts und Klassendiagramme 

Beispiel Herzschrittmacher: State Chart für Objekte der Klasse 

AtrialModel 


Aus: Bruce Powel Douglass: Real Time UML Second Edition


UML – Objekte mit kontinuierlichem Verhalten 

In technischen Anwendungen: Filter, Regler, …: streamOps 

Eingangs-Datenstrom x(t) 

quellObjekt 

Eingangsdatenstrom: Strom von 

Datenvektoren, z.B. zeitl. äquidistant 

v v v 

v N 

x( 

t), 

x( 

t − ∆), 

x( 

t − 2∆), 

L x ∈ R 

Zeit 

streamOp 

Ausgangsdatenstrom: 

Strom von Datenvektoren 

v v 

y( 

t −τ 

L 

), y( 

t − ∆ −τ 

L), 

v 

y( 

t − 2∆ −τ 

L), 

L 

v K 

y ∈ R , τ : Latenzzeit 

L 

empfObjekt 

Zeit 

Ausgangs-Datenstrom y(t) 




In technischen Anwendungen: StreamOps wie Filter, Regler, … 

Objekt streamOp arbeitet auf Strom von Eingangs-Datenstrukturen x und 

liefert daraus einen Strom von Ausgangs-Datenstrukturen y. 

quellObjekt 

streamOp 

empfObjekt 

Dazu benutzt streamOp einen jeweils aktuellen Ausschnitt der unmittelbaren 

Vergangenheit des Eingangs-Datenstrukturstromes 

x t), 

x( 

t − ∆ ), x( 

t − ∆ ), L, 

x( 

t − ∆ ) 

( 

1 2 

N −1 

Diese werden in einem Ringpuffer gespeichert und bilden die N Komponenten 

des Zeilenvektors X T . v 

T 

X x t), 

x( 

t − ∆ ), L, 

x( 

t − ∆ ) 

[ ] 

= ( 

1 N −1 

v 

Die Filterfunktion ist definiert durch y( 

t) 

= f ( X 

Ausgangs-Datenvektor. 

T 

) und liefert den aktuellen 

Zum Anstoßen der Verarbeitung erzeugt das quellObjekt in streamOp das 

Ereignis evNewX. 

Wurde von streamOp ein neuer Ausgangs-Datenvektor erzeugt, wird in 

empfObjekt das Ereignis evNewY erzeugt. 




StreamOps: Filter, Regler, … 

quellObjekt 

streamOp 

empfObjekt 

erzeugen 

vernichten 

T 

/ j=0 

Init 

v 

do/ = 0 

x j 

entry/ read( xneu 

); 

exit/ x = x ; 

N −1− 

j neu 

evNewX[j X T ist ein Zeilenvektor. K ist der Faltungskern. 

FaltungOp1d 

Kernelgröße: int 

Kernel: float vector 

(Kernelgöße) 

quellObjekt 

FaltungOp1d 

empfObjekt 

/ j=0; 


v 

do/ = 0 

x j 

[j=N-1] 

AufDatenWarten 

evNewX[j


Szenarios: Zeitverhalten von Objekten: Zeitablaufdiagramme 

Erweiterungen zur Erfassung von RT-Anforderungen 

Zustandszeitdiagramme: 

Darstellung des Verweilens in und des Wechsels von Zuständen 

Z3 

Zustand 

Z2 

Z1 

Zeit 

10ms 20ms 30ms 40ms 50ms 150ms 160ms 170ms 180ms 

Das Zeitablaufdiagramm zeigt einen speziellen Pfad durch das 

Zustandsdiagramm einer Zustandsmaschine. 





Zustandszeitdiagramme für nebenläufige Zustände 






Taskzeitdiagramme 


Aus: Bruce Powel Douglass: Real Time UML Second Edition 


Use cases 

• Zeigt das System in Beziehung zu seiner Umgebung (zu externen Objekten) 

und seine grundlegenden Fähigkeiten der Wechselwirkung 

• Darstellung: Use case Diagramm 

 

Lokalisiere Trajektorien 

Identifiziere Flugzeug 

 

 

Zeige Luftraumsituation 

 

Zeige Flugpfad 

Verarbeite Nutzerbefehl 

 

Setze Zoomlevel Verschiebe Ausschnitt 

Detektiere Abstandsunterschreitung 

Primärradar 

Sekundärradar 

Flugzeug- 

Transponder 

Fluglotse 



Use cases: Beziehungen 

UML 1.3 definiert drei verschiedene Beziehungen zwischen Use Cases: 

Generalisierung 

Bedeutet, dass ein Use Case eine spezialisiertere oder verfeinerte Version des anderen 

ist. Analog zu Klassenvererbung. Symbol: Pfeil mit geschlossener Spitze, Richtung 

vom Eltern- zum Kindprozess. 

 

Wenn z.B. mehrere Geschäftsprozesse die gleichen Unterprozesse besitzen, werden 

letztere als eigenständige Use Cases modelliert, analog einem Unterprogramm. Die 

Unterprozesse existieren nie für sich alleine. Symbol: gestrichelter Pfeil mit offener 

Spitze, Richtung von Basis zum Unterprozess, Stereotypenbeschriftung 

. 

 

Von einem Use Case wird in einen anderen verzweigt, wenn gegebene Bedingungen 

erfüllt sind. Ist der Use Case, in den verzweigt wurde, (die Erweiterung) beendet, 

erfolgt eine Rückkehr in den Use Case, aus dem verzweigt wurde (die Basis). 

Symbol: gestrichelter Pfeil mit offener Spitze, Richtung von Erweiterung zu Basis, 

Stereotypenbeschriftung . 



Use cases: requirements 

1. Funktionale Anforderung wird durch Use Case selbst repräsentiert. 

2. Quality of Service (QoS): Wie gut muss der Use Case ausgeführt werden? 

• Geschwindigkeit 

• Rechtzeitigkeit 

• Durchsatz 

• Kapazität 

• Voraussagbarkeit 

• Zuverlässigkeit 

• Betriebssicherheit 

• Manipulationssicherheit 

QoS requirements werden als Randbedingungen (constraints) formuliert. 

Constraint: Eine Regel, die auf eine Menge von Modellelementen angewandt 

wird und die außerhalb der Standard-Regeln von UML liegt. 



Use cases: requirements 

3. Darstellung der QoS 

Sekundärradar 

Flugzeug- 

Transponder 

Detektiere Abstandsunterschreitung 

Primärradar 

Lokalisiere Trajektorien 

Idenzifiziere Flugzeug 

Verarbeite Nutzerbefehl 

{ Identifikationsrate mindestens 

5/s, Latenzzeit < 100 ms, 

Verfügbarkeit > 1-10 -9 , 

Fehlerrate < 10 -12 } 

{ Genauigkeit Position 

besser 500 m, 

Genauigkeit Höhe besser 50m, 

Latenzzeit < 100 ms} 

Fluglotse 

Setze Zoomlevel 



Dynamisches Verhalten: Szenarios 

Ein Use Case kann durch eine Kollektion von Szenarios dokumentiert werden. 

Jedes Szenario wird durch eine oder mehrere Bedingungen definiert, die 

zu einem speziellen Ablauf des jeweiligen Use Cases führen. 

Darstellung dynamischer Abläufe in UML mittels 

• Objektdiagramm: 

Schnappschuss eines Systems auf Objektebene zu einem bestimmten 

Zeitpunkt 

• Kollaborationsdiagramm: Darstellung des Botschaftenflusses 

• Sequenzdiagramm: Präzise Beschreibung des Ablaufs der 

Operationsaufrufe. 



Szenarios: Objektdiagramm 

• Objektdiagramm: 

Schnappschuss eines Systems auf Objektebene zu einem bestimmten 

Zeitpunkt 



Szenarios: Kollaborationsdiagramm 

Kollaborationsdiagramm: Darstellung des Botschaftenflusses 

• Erweiterung des Objektdiagramms um Botschaften 

• Zeigt die Objekte, die für die Ausführung einer bestimmten Operation relevant sind. 

• Objekte, die während der Ausführung erzeugt bzw. gelöscht oder erzeugt und 

gelöscht werden, werden mit {new} bzw. {destroyed} oder {transient} gekennzeichnet. 

• Als Auslöser einer Operation kann ein Akteur eingetragen werden. 

• An jede Verbindung („link“: nur wenn Assoziation im Klassendiagramm) kann eine 

Botschaft eingetragen werden: laufende Nummer, Operationsname, Pfeil. 

Reihenfolge und Verschachtelung gekennzeichnet durch hierarchische 

Nummerierung. 

Verschachtelung: Welche Nachrichten sind aus welchen heraus gesendet 

1: Operation1() 

:Klasse3 

{new} 

:Klasse1 

{transient} 

2: Operation2() 3: Operation4() 

:Klasse2 

{new} 

2.1: Operation3() 

:Klasse4 

Im Kollaborationsdiagramm ist jedes 

dargestellte Objekt Platzhalter für ein 

beliebiges Objekt der Klasse. 

Unterschied Klassendiagramm! 



Szenarios: Sequenzdiagramm 

Sequenzdiagramm: Abfolge von Nachrichten 

• Genauere zeitliche Darstellung als Kollaborationsdiagramm 

• Verzicht auf Attributangaben und Verbindungen 

• Objekte, die Botschaften austauschen: gestrichelte, senkrechte Linien // Zeitachse. 

Beginnt nach Erzeugen und endet mit Löschen des Objekts (Symbol: X). 

• Botschaft: horizontaler Pfeil vom Sender zum Empfänger mit Name der Botschaft 

• Aktive Operation: Schmales vertikales Rechteck auf Objektlinie 

• Wird eine Objekt erzeugt, zeigt eine Botschaft auf das Objektsymbol 

Existierende Objekte 

erstesObjekt 

:Klasse1 

Operation1() 

Botschaft 

Klasse3() 

:Klasse2 

Länge: relative 

Dauer der Methode 

neuesObjekt 

:Klasse3 

Neu erzeugtes Objekt 

Operation5() 

Operation3() 

Kontrollfluss nach 

Operationsende 

Operation2() 

X 

Objekt wird 

gelöscht 

Objekt sendet 

Botschaft an sich selbst 



Szenarios: Beispiel Mobiltelefon 

Betrachten wir eine Software, die ein sehr, sehr einfaches 

Mobiltelefon steuert. Dieses hat 

• Tasten zum eingeben der Ziffern 

• eine „Send“-Taste 

• Eine „Dialer“-Hardware und Software zum Aufsammeln der 

Zahlen und Wiedergabe der zugehörigen Wähltöne 

• Ein Mobilfunkgerät zur Verbindung mit dem Funkzellen- 

Netzwerk um ein Gespräch herzustellen 

• Mikrophon 

• Lautsprecher 

• Display 

Wir stellen aus dieser einfachen Spec ein statisches Modell auf. 

Robert C. Martin: „Engineering Column“ 




Dagegen ist kaum etwas einzuwenden. Die Kompositionsbeziehungen 

reflektieren die Spec. Woher wissen wir, ob dies das korrekte Modell ist? 

Kriterium 1: Vergleich mit der realen Welt: bestanden. 

Aber: Kriterium 1 notwendig, aber nicht hinreichend, da es mehrere 

statische Modelle gibt, welche mit der realen Welt eines Mobiltelefons 

übereinstimmen. 

Auswahl durch weiteren, anwendungssensibleren Test. 





Spezifikation des dynamischen Verhaltens 

Wie arbeitet das Mobiltelefon? 

Aufstellung des Use Case Diagramms und Analyse der Use Cases. 

Netzwerk 

Anruf empfangen 

Anruf tätigen 

{ ...} 

{ ...} 

Datenendgerät 

Telefonbenutzer 

SMS empfangen 

SMS versenden 

... 

Fax/Datenbetrieb 

Telefon 

konfigurieren 





Analyse des Use Cases „Anruf tätigen“. Anruf tätigen 

Use case: „Anruf tätigen“ 

1. Benutzer drückt die Ziffern-Tasten, um die Telefonnummer einzugeben. 

2. Bei jedem Ziffern-Tastendruck wird die Zahl im Display um die Ziffer 

ergänzt. 

3. Für jede Ziffer erzeugt der „Dialler“ den entsprechenden Ton und gibt ihn 

über den Lautsprecher aus. 

4. Der Benutzer drückt die „Send“-Taste. 

5. Ein “in use” Anzeigesymbol erscheint im Display. 

6. Das Mobilfunkgerät stellt eine Verbindung mit dem Netzwerk her. 

7. Die akkumulierten Ziffern werden an das Netzwerk gesendet. 

8. Die Verbindung zum angerufenen Apparat wird hergestellt. 

Stark vereinfachte Darstellung des Use Cases. Der Use Case verdeutlicht, 

dass beim „Anruf tätigen“ eine Ablaufprozedur stattfindet. 

Wie arbeiten also die Objekte des statischen Modells zusammen 

(kollaborieren), um diese Ablaufprozedur auszuführen? 





Analyse des Use Cases „Anruf tätigen“. 

Verfolgung des Prozesses Schritt für Schritt 

• Prozess wird dadurch initiiert, dass der Benutzer eine Zifferntaste drückt, 

um die Eingabe einer Telefonnummer zu beginnen. Woher weiß die 

Software im Telefon, dass eine Taste gedrückt wurde? 

• Alle möglichen Arten können dahingehend vereinfacht werden, dass ein 

„Button“ Objekt eine „digit“ Nachricht sendet. 

• Welches Objekt soll die Nachricht empfangen? Antwort: Die 

Wählvorrichtung (der „Dialer“). 

• Der Dialer muss dann dem Display sagen, dass es die neue Ziffer 

anzeigen soll und dem Lautsprecher („Speaker“), dass er den 

zugehörigen Ton emittieren soll. 

• Der Dialer muss auch die Ziffer in einer Liste abspeichern, welche die 

Telefonnummer akkumuliert. 

• Jeder Zifferntastendruck folgt derselben Prozedur, bis der „Send“-Button 

gedrückt wird. 

Fortsetzung nächste Seite 





• Wenn der „Send“-Button gedrückt wird, schickt das entsprechende 

Button Objekt die Send Nachricht an den Dialer. 

•Der Dialer sendet dann eine Connect Nachricht an das Mobilfunkgerät 

(Cellular Radio) und gibt ihm die akkumulierte Telefonnummer weiter. 

•Das Cellular Radio weist das Display an, das In Use Symbol anzuzeigen. 

Kollaborationsdiagramm des Use Case „Anruf tätigen“ 





Überarbeitung des statischen Modells mit dem dynamischen Modell 

Kollaborationsdiagramm unähnlich dem Klassendiagramm. 

Problem: Die Links sind Instanzen von Assoziationen Widerspruch 

Möglichkeiten: 1) Anpassung des dynamischen an das statische Modell, 2) 

Entwurf eines statischen Modells für das Kollaborationsdiagramm 

Konsequenzen von 1): Ein Telefon Objekt in der Mitte würde Nachrichten von 

allen anderen Objekten erhalten und auf jede eingehende Nachricht mit 

eigenen ausgehenden Nachrichten antworten. Stark gekoppeltes 

Design: Telefon Objekt als Master Controller, das alle anderen Objekte 

kennt und von allen anderen gekannt wird. Enthält alle Systemintelligenz. 

Fehlergefahr bei Änderungen. 

Konsequenzen von 2): Aufgaben sind vernünftig verteilt, jedes Objekt hat ein 

wenig eigene Intelligenz und kein spezielles Objekt ist für alles zuständig. 

Änderungen an einem Teil des Modells breiten sich nicht unbedingt zu 

anderen Teilen aus. 

Schlussfolgerung: Unser statisches Modell ist unangemessen und sollte 

abgeändert werden. 





Geändertes Klassendiagramm 

• Keine Kompositionen 

mehr, nur noch 

Assoziationen: Keine 

der verknüpften 

Klassen hat eine 

Gesamtheit/Teil- 

Beziehung. 

• Assoziationsrichtungen 

wegen Klarheit der 

Kommunikationsrichtung 

im dynamischen 

Modell. 

• Angabe der 

Operationen in 

den Klassensymbolen 

wegen Offensichtlichkeit 

im dynamischen 

Modell 





Geändertes statisches Modell 

• Reflektiert nicht mehr die reale Welt wie das ursprüngliche Modell 

• Verlust der Abbildung des Telefons aus Tasten und Display, usw. 

• Abbildung basierte auf den physikalischen Komponenten, nicht auf 

Dynamik 

Neues Modell 

• basiert auf dem Realwelt-Verhalten 

• Verlust der Klassen Telefon und Mikrofon (kein Beitrag zum dyn. Modell), 

werden möglicherweise in einem anderen Use Case benötigt und müssen 

dann wieder hinzugefügt werden. 

Zu einem statischen, physischen Modell gehören häufig viele 

dynamische Modelle, von denen jedes eine andere Variation eines 

Use Cases (Szenario oder Anforderung) reflektiert. 





Verfeinerung des statischen Modells 

Entkopplung von Button und Dialer zur Wiederverwendbarkeit der Button 

Klasse in Programmen, die keine Dialer haben. 

• Jede Klasse, die einen 

Tastendruck erkennen 

muss, wird von 

ButtonServer abgeleitet 

und implementiert die 

Funktion ButtonPressed. 

• Wenn eine Klasse (wie 

Dialer) verschiedene 

Button Objekte detektieren 

muss, können Adapter 

benutzt werden, um die 

ButtonPressed Nachrichten 

abzufangen und zu 

übersetzen. 





Verfeinerung des statischen Modells 

Hohe Kopplung der Display Klasse. Änderung einer Methode von Display wegen 

eines in Dialer entstandenen Bedarfs Auswirkung auf CellularRadio 

Maßnahme zur Entkopplung: Segregation der Schnittstellen: 





Anpassung des dynamischen Modells an die Änderungen 

Adapter übersetzen die ButtonPressed Nachrichten in Nachrichten, die Dialer 

verstehen kann. 

Segregation der Schnittstellen: Objekt mit Namen display taucht zweimal mit 

verschiedenem Klassennamen auf. 





Schlussfolgerungen bisher: 

• Statische Modelle sind notwendig, aber nicht hinreichend für vollständige 

objektorientierte Analysen. 

• Ein statisches Modell ohne die Erkenntnisse einer dynamischen Analyse 

ist zum Scheitern verurteilt. 

• Die angemessenen statischen Beziehungen sind Ergebnisse der 

dynamischen Anforderungen der Applikation. 

• UML Kollaborationsdiagramme sind geeignet, die dynamischen Modelle 

herzuleiten und sie den statischen Modellen gegenüberzustellen, von 

denen sie getragen werden. 

• In den Kollaborationsdiagrammen wird die Beziehung zwischen den 

Objekten unter dem Aspekt der Sequenz der Nachrichten dargestellt. 





Sequenzdiagramm: Gleiche Information wie Kollaborationsdiagramm, 

Darstellung betont Sequenz der Nachrichten statt Beziehung der Objekte. 

1. Ereignisablauf, wenn eine Zifferntaste gedrückt wird 

Iteration der 

Gruppe 

2. Ereignisablauf, wenn der „Send“ Button gedrückt wird 





Sequenzdiagramme versus Kollaborationsdiagramme 

Kollaborationsdiagramm 

Zeigt die gesamte Objektzusammenarbeit in einem dichten Diagramm. 

Sequenzdiagramm 

Zeigt den Fluss des Algorithmus. 





Erzeugung und Vernichtung von Objekten im Sequenzdiagramm 

Sequenzdiagramm für 

„Verbindung herstellen“ und 

„Verbindung beenden“ 

Erzeugung: 

Nachrichtenpfeil auf das 

Objektsymbol des erzeugten 

Objekts 

Zerstörung: 

Nachrichtenpfeil auf ein „X“ 

Symbol am Ende der 

Lebenslinie des Objekts 





Asynchrone Nachrichten und Nebenläufigkeit 

Sequenzdiagramm für 

„Verbindung herstellen“ und 

„Verbindung beenden“ 

„Halbpfeile“ symbolisieren 

asynchrone Nachrichten: kehren 

unmittelbar zurück, nachdem 

ein Thread im empfangenden 

Objekt ausgelöst wurde. 

Die Methode (z.B. Connect) 

kann weiter existieren. 

Methoden, deren Balken zur 

gleichen Zeit existieren, 

repräsentieren nebenläufige 

Prozesse. 





Konfliktbedingungen: wenn ein Objekt Nachrichten von zwei oder mehr 

konkurrierenden Quellen erhält. Immer möglich bei Nebenläufigkeit. 

Ausschnitt aus Sequenzdiagramm „Anruf empfangen“ / „Anruf tätigen“, 

normaler Ablauf (Aktivierungsbalken zur Übersichtlichkeit weggelassen) 

Das Mobilfunkgerät (CellularRadio) detektiert einen eingehenden Anruf und aktiviert 

den Anruftöner (Ringer). Es teilt ebenso dem Dialer den Eingang eines Anrufs mit. Dies 

versetzt den Dialer in einen speziellen Zustand, in welchem der Dialer bei Empfang 

einer Send Nachricht an das Mobilfunkgerät eine Answer Nachricht schickt. 

Zwei verschiedene Umstände, unter denen der Dialer eine Send Nachricht empfängt: 

1) Zum Anrufen Connect(pno) Nachricht, 2) zum Antworten Answer Nachricht 





Konfliktbedingungen 

Ausschnitt aus Sequenzdiagramm „Anruf empfangen“ / „Anruf tätigen“, 

Konfliktbedingungs-Ablauf 

Benutzer wählt gerade eine Nummer und drückt den Send-Button, als gerade 

ein Anruf eingeht. Die Wege der IncomingCall Nachricht und der Connect 

Nachricht kreuzen sich: Konfliktsituation 

Wenn das Zustandsdiagramm von CellularRadio nicht berücksichtigt, dass 

Connect unmittelbar nach Versenden von IncomingCall eintreffen kann, ist 

CellularRadio in undefiniertem Zustand. 

Abwärts gerichtete Nachrichten-Pfeile symbolisieren, dass zwischen Absenden und 

Empfang der Nachricht Zeit vergehen kann. 



RT-Erweiterung UML 

Sequenzdiagramme 


• Zustands-Marken: Auf der Lebenslinie eines Objekts werden die 

eingenommenen Zustände des Objekts in ihrem zeitlichen Ablauf 

dargestellt. 

• Zeitablauf-Marken (timing marks): Standard-Darstellung der Zeitdifferenz 

zwischen zwei Nachrichten 

• Nachrichten haben zusätzliche semantische Elemente. Eine Nachricht hat 

folgende Operationen: 

msg.sendTime: Zeit, zu der die Nachricht von der Quelle versandt wird. 

msg.receiveTime: Zeit, zu der die Nachricht vom Empfänger erhalten wird. 

• Weitere semantische Elemente können hinzugefügt werden 

• msg.executionTime 

• msg.arrivalPattern: periodisch/aperiodisch 

• msg.period 

• msg.jitter 

• msg.minimumArrivalTime 

• msg.deadline 

• ... 

Erlauben Zeitablaufanalysen. 





Beispiel Sequenzdiagramm „Herzschrittmacher“ 






Fortgeschrittene Sequenzdiagramme

OO-Phasen fÃ¼r Embedded Systems Dynamisches Verhalten in UML ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?