89
Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Embed Size (px)

Citation preview

Page 1: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/1

OO-Phasen für Embedded Systems

Dynamisches Verhalten in UML

Page 2: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/2

OO-Phasenübersicht

Dynamisches Verhalten in UML

Page 3: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/3

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

Flugzeug-Autopilot

ExternesInteraktionsobjekt(Akteur, actor)

System-fähigkeit(Use Case)

Flugrechner Triebwerk

Aileron Seitenruder Höhenruder

Hydrauliksystem

Setze Drehzahl

Auf

Ab

Auf

Ab

Links Rechts

Druck+

Druck-

Druck+

Druck-

Druck+ Druck-

Pilot

Pilot

Kursänderung

ObjektNachricht

Assoziation

SteuerflächeFlügel

SteuerflächeHeck

Use cases werden durchkooperierende Objekterealisiert.

Dynamisches Verhalten in UML

Page 4: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/4

Dynamisches Verhalten in UML

UNAV3400      Miniature UAV autopilot

Quelle: UNAV, LLC

Page 5: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/5

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

Dynamisches Verhalten in UML

Page 6: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/6

Übungsbeispiel UML: Telefonanlagenverwaltung

Dynamisches Verhalten in UML

Page 7: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/7

Übungsbeispiel UML: TelefonanlagenverwaltungErweitern Sie das Klassen-Diagramm des beschriebenen Szenarios um Assoziationen und Kardinalitäten

Dynamisches Verhalten in UML

Page 8: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/8

Übungsbeispiel UML: TelefonanlagenverwaltungEs 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.

Dynamisches Verhalten in UML

Page 9: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/9

Übungsbeispiel UML: Telefonanlagenverwaltung

Dynamisches Verhalten in UML

Page 10: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/10

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

Dynamisches Verhalten in UML

Page 11: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/11

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

Dynamisches Verhalten in UML

Page 12: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/12

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)

Dynamisches Verhalten in UML

Page 13: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/13

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)

Dynamisches Verhalten in UML

Page 14: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/14

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

Dynamisches Verhalten in UML

Page 15: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/15

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.

Dynamisches Verhalten in UML

Page 16: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/16

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

Dynamisches Verhalten in UML

Page 17: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/17

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

Dynamisches Verhalten in UML

Page 18: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/18

UML – Objekt- und Klassenbeziehungen

– Kardinalitäten am Beispiel der Beziehung Assoziation

Klasse A Klasse B◄ Assoziationsname

Assoziationsname ►Rolle A Rolle B

KA KB

Klasse A1 Genau eine Beziehung (Muss-Beziehung)

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

Klasse A0...4 Null bis fünf Beziehungen (Kann-Beziehung)

Klasse A3 Genau drei Beziehungen (Muss-Beziehung)

Klasse A1,4,7 Eine, vier oder sieben Beziehungen (Muss-Beziehung)

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

Dynamisches Verhalten in UML

Page 19: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/19

UML – Objekt- und Klassenbeziehungen

– Assoziation: Interpretation

Klasse A Klasse B◄ Assoziationsname

Assoziationsname ►Rolle A Rolle B

KA KB

Kfz-Steuer-gerät

Airbag-Steuergerätüberwacht ►Supervisor

1 1..*

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

Unter-nehmen

MitarbeiterArbeit-geber

Arbeit-nehmer

1 *PKW

Fahrer Dienst-wagen

0..1 0..1

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.

Dynamisches Verhalten in UML

Page 20: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/20

UML – Objekt- und Klassenbeziehungen

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.

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

Web-Auftritt Web-Seite* 1..*

Autopilot Aerofoil-Surface-Controller

1 1..*

Dynamisches Verhalten in UML

Page 21: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/21

UML – Beispiel: Sensorklassenbeziehung

OptischeMessvor-richtung

OptischerSensor

Wärmebildkamera

Videokamera

Laserscanner

Multiplex-Sensor

Uniplex-Sensor

A/D-Konverter

Sensor

A/D-Konverter

1

1...N

*

1 1

1

{abstract}

„ist eine Art von ...“

„besteht aus ...“

Dynamisches Verhalten in UML

Page 22: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/22

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

Dynamisches Verhalten in UML

Page 23: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/23

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

Dynamisches Verhalten in UML

Page 24: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/24

UML – Dynamisches Objektverhalten – State Charts

State Chart TransitionenErweiterung gegenüber Harel-Notation um Parameterliste:

Ereignis (Parameterliste) [Guard] / Aktionsliste

Parameterliste: Kommagetrennte Liste mit Namen der Datenparameter, die bei Ereigniseintritt weitergegeben werden. Deklaration der Parameter an der Transition, welche die Parameter entgegennehmen (und verarbeiten).

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

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)

Timer-Ereignisse: Timer wird bei Einnahme des Zustandes gestartet, Ereignis bei Ablauf der Zeitdauer ausgelöst.

A B

X Y

X Y

Dynamisches Verhalten in UML

Page 25: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/25

UML – Dynamisches Objektverhalten – State Charts

State Chart Transitionen

Quell-Objekt

Obj1 Obj2

Quelle Quelle1

11

1

Ziel1 Ziel2

Zust1

Zust2

ZustA

ZustB ZustX

ZustY

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

x=23, y=2.73, T

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

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

Dynamisches Verhalten in UML

Annahme:System initialisert,dann Ereignis S

T wird zu assozi-ierten Objektenpropagiert und dort ausgewertet.

Page 26: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/26

UML – Dynamisches Objektverhalten – State Charts

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

T

Dynamisches Verhalten in UML

Page 27: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/27

UML – Dynamisches Objektverhalten – State Charts

Pseudozustände von UML 1.3

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*

Dynamisches Verhalten in UML

Page 28: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/28

UML – Dynamisches Objektverhalten – State Charts

Pseudozustände von UML 1.3Junction (Kreuzung): Zusammenführung mehrfacher Übergänge

oder Aufspaltung einer Transition in mehrere Folgetransitionen.

A

B D

CT1/f

T3/h

T2[x<0]/g

[y>0]

/m,n

A

B

D

CT1[y>0]/f,m,n T3/h,m,n

T2[x<0&&y>0]/g,m,n

Diagramm 1

ist äquivalent zu

Diagramm 2

Dynamisches Verhalten in UML

Page 29: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/29

UML – Dynamisches Objektverhalten – State Charts

Pseudozustände von UML 1.3Auswahlpunkt, 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

Wechselgeld gebenEntry/ Wechselbetrag= Betrag-Soll; Wechselgeld zu- rückgeben

Auswahl bearbeiten

Münze_ein(Münzwert)/Betrag=+Münzwert

[Betrag > Soll]

[Betrag == Soll]

[else]

erledigt

Rückgabe_erfolgt

Dynamisches Verhalten in UML

Was stimmt hier noch nicht?

Page 30: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/30

UML – Dynamisches Objektverhalten – State Charts

Aktionenals• Aktionsliste von Übergängen• Entry actions• Exit actionsWerden 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.

Dynamisches Verhalten in UML

Page 31: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/31

UML – Dynamisches Objektverhalten – State Charts

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.

Dynamisches Verhalten in UML

Page 32: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/32

UML – Dynamisches Objektverhalten – State Charts

Aktionen in verfeinerten Zuständen: Stubbed transitions

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

Z1Z2

Z3

Z4

Entry/ en_1Exit/ ex_1

Entry/ en_2Exit/ ex_2

Entry/ en_3Exit/ ex_3

Entry/ en_4Exit/ ex_4

E1 / a,b

E3 / e

E2 / c,d

E1: a, b, en_1, en_2, en_3E3: e, ex_3, ex_2, en_4

Dynamisches Verhalten in UML

Page 33: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/33

UML – Dynamisches Objektverhalten – State Charts

Nebenläufige ZuständeSind immer Unterzustände eines Oberzustandes. Ist dieser auf der äußersten

Ebene eines Statecharts, wird er als einzelner Zustand gezeichnet.

Fehlerfall

Entry/handle(err)

OkFehler(err)/log(err)

BehebungsCmd/genSignal(init)

Z_rot

Z_grün

Z_blau

Initial

Z_normal Demo

grün[IS_IN(Fehlerstatus::Ok)

init initgestartet

[normal] [else]

Farbe Betriebsart

Fehlerzustand

Dynamisches Verhalten in UML

Page 34: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/34

UML – Dynamisches Objektverhalten – State Charts

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

Dynamisches Verhalten in UML

Page 35: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/35

UML – Dynamisches Objektverhalten – State ChartsSynchronisation mit

Join Pseudozustand Fork Pseudozustand (wenn nicht die Initialzustände eingenommen

werden sollen)

Z_rot

Z_grün

Z_blau

Initial

Z_normal Demo

grün[IS_IN(Fehlerstatus::Ok)

init initgestartet

[normal] [else]

Farbe Betriebsart

Ende

Start

Ablauf

t0

t1 t1

Dynamisches Verhalten in UML

Page 36: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/36

UML – Dynamisches Objektverhalten – State Charts

Synchronisation mit 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

ED

C

B

A

H

G

F

Unter1 Unter3

Unter2

e1

e2/genSignal(e3(x,y,z))

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

e1

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

e5e4[IS_IN(D)]

e6

Dynamisches Verhalten in UML

Page 37: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/37

UML – Dynamisches Objektverhalten – State Charts

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

E

D

BC

A

F4

Dynamisches Verhalten in UML

Page 38: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/38

UML – Dynamisches Objektverhalten – State ChartsHierarchische ZuständeUntermaschinen

OberUnter1 Unter2

Unter3

include/ subm1 include/ subm2ZS1_1

ZS1_2ZS1_3

ZS2_1ZS2_2

subm1 subm2

ZS1_1

ZS1_2

ZS1_3

Dynamisches Verhalten in UML

Page 39: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/39

UML – Dynamisches Objektverhalten – State ChartsHierarchische ZuständeVererbung

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.

Dynamisches Verhalten in UML

Page 40: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/40

UML – Dynamisches Objektverhalten – State ChartsBeispiel 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.

Dynamisches Verhalten in UML

Page 41: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/41

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd

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

Auftaumodus wählen, Zubereitungsmodus wählen und Timermodus wählen, Ein und Abbruch.

• Zur Bestimmung der Zeitdauer werden die Zifferntasten und die Zeitsetz-Taste benutzt. Möglicher Ablauf: Zeitsetz-Taste zurInitialisierung der Eingabe und Um-schalten des Einstellmodus für dieeinzelnen Stellen von Minuten undSekunden; 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.

Objekte (physisch motiviert): Tasten, Display, Licht, Piepser, Türsensor, Ventilator, Drehteller, Mikrowellensender, Timer. Koordinationskomponente: kochMeister

7 8 9

4 5 6

1 2 3

0 Zeitsetz

Leist.setz

Zuber.

Auftau

Timer

Ab- Einbruch

00:00

9

Dynamisches Verhalten in UML

Page 42: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/42

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd - Klassendiagramm

ziffernKnopf:Button

zuberAktKnopf:Button

auftauAktKnopf:Button

timerAktKnopf:Button

abbruchKnopf:Button

Tastenfeld

10

1

1

1

1

timerView:stringView

stufeView:stringView

modusView:bitMap

display

1 1

1

11

kochMeister

kochTimer

1 1

türSensor

licht

piepser

mw_sender

drehtellerMotor ventilator

1

1

1

1

1

11

11

1

1

1

zeitsetzKnopf:Button1

leistsetzKnopf:Button1

11

Dynamisches Verhalten in UML

einKnopf:Button1

Page 43: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/43

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd

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

Dynamisches Verhalten in UML

Page 44: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/44

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd

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.

Dynamisches Verhalten in UML

Page 45: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/45

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für kochMeister:

bereit

Timing

Zubereiten

Auftauen

Pause

AuftauAblauf

KochenAblauf

TimerAblauf

evEin[(seinTürSensor->IS_IN(zu)] /seinMw_sender->GEN(evLeistungAn);seinKochTimer->GEN(evLeistungAn);

evTürÖffnet /seinMw_sender->GEN(evPausieren);seinKochTimer->GEN(evPausieren);

evEin[(seinTürSensor->IS_IN(zu)] /seinMw_sender->GEN(evLeistungAn)

evEin[(seinTürSensor->IS_IN(zu)] /seinMw_sender->GEN(evLeistungAn);

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

Ablauf H

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

evTimingSel[seinKochTimer->IS_IN(ZeitGesetzt)]

evZubereitenSel[seinKochTimer->IS_IN(ZeitGesetzt)]

evAuftauenSel[seinKochTimer->

IS_IN(ZeitGesetzt)]

kochMeisterZustandevAbbruch / seinKochTimer->GEN(evAbbruch); seinMw_sender->GEN(evAbbruch); seinPiepser->piep( );

Dynamisches Verhalten in UML

Page 46: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/46

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für mw_sender:

bereit

Pause

Abwarten

Abstrahlen

Betrieb

evAbbruch

tm(sTime) /magnetronAus( );

tm(wTime) /magnetronAn( );

entry/ seinLicht->einschalten( ); seinVentilator->einschalten( ); seinDrehteller->einschalten( );exit/ magnetronAus( ); if (seinTürSensor->IS_IN(Closed)) seinLicht->ausschalten( ); seinVentilator->ausschalten( ); seinDrehteller->ausschalten( );

evLeistungAn / berechne(leistungStufe, sTime, wTime);

evAbbruch

evFertig

evLeistungAn

evPausieren

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.

Dynamisches Verhalten in UML

Page 47: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/47

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für mw_kochTimer:

ZeitGesetzt

evZeitsetz /

z1=0; z2=0;

z3=0; z4=0;

evZeitsetz/berechneZeit(gesetzteZeit);

evFertig

evAbbruch

Bereit

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.

Dynamisches Verhalten in UML

SekZweiteStelle

ZeitSetzen

evAbbruch

Page 48: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/48

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für mw_kochTimer:

MinErsteStelle

MinZweiteStelle

SekZweiteStelle

SekErsteStelle

evZeitsetz [z1<6]

evZeitsetz

evZeitsetz[z3<6]

evZiffer/seinZifferknopf->zahl(z1);

evZiffer/seinZifferknopf->zahl(z2);

evZiffer/seinZifferknopf->zahl(z3);

evZiffer/seinZifferknopf->zahl(z4);

do/ seinTimerView ->blink(1,z1);

do/ seinTimerView ->blink(2,z2);

do/ seinTimerView ->blink(3,z3);

do/ seinTimerView ->blink(4,z4);

Dynamisches Verhalten in UML

ZeitSetzen

Page 49: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/49

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für mw_kochTimer:

bereit

Pause

evEin / kochZeit=gesetzteZeit;

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

evEin

evPause / kochZeit=getRestZeit( );

evAbbruch

evAbbruch

Countdown

ZeitGesetzt

Dynamisches Verhalten in UML

Page 50: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/50

UML – Dynamisches Objektverhalten – State ChartsBeispiel Mikrowellenherd, Statechart für türSensor:

Status

Zu

Entry/ seinLicht->ausschalten( )

Offen

Entry/ seinLicht->einschalten( )

do/ s=getTürStatus( )

[s==zu]

else

evTürSchließt /seinKochMeister->GEN(evTürSchließt)

evTürÖffnet /seinKochMeister->GEN(evTürÖffnet)

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

Dynamisches Verhalten in UML

Page 51: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/51

UML – State Charts und KlassendiagrammeBeispiel Herzschrittmacher: Klassendiagramm

Aus: Bruce Powel Douglass: Real Time UML Second Edition

Zustandsdiagramm zuAtrialModel auf derfolgenden Folie

Dynamisches Verhalten in UML

Page 52: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/52

UML – State Charts und KlassendiagrammeBeispiel Herzschrittmacher: State Chart für Objekte der KlasseAtrialModel

Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML

Page 53: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/53

Zeit

Zeit

UML – Objekte mit kontinuierlichem VerhaltenIn technischen Anwendungen: Filter, Regler, …: streamOps

streamOp

Eingangs-Datenstrom x(t)

Ausgangs-Datenstrom y(t)

quellObjekt

empfObjekt

Eingangsdatenstrom: Strom von Datenvektoren, z.B. zeitl. äquidistant

Ausgangsdatenstrom: Strom von Datenvektoren

NRxtxtxtx ),2(),(),(

LatenzzeitRy

ty

tyty

LK

L

LL

:,

),2(

),(),(

Dynamisches Verhalten in UML

Page 54: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/54

UML – Objekte mit kontinuierlichem VerhaltenIn technischen Anwendungen: StreamOps wie Filter, Regler, …

streamOp

Objekt streamOp arbeitet auf Strom von Eingangs-Datenstrukturen x undliefert daraus einen Strom von Ausgangs-Datenstrukturen y.

Dazu benutzt streamOp einen jeweils aktuellen Ausschnitt der unmittelbaren Vergangenheit des Eingangs-Datenstrukturstromes

Diese werden in einem Ringpuffer gespeichert und bilden die N Komponenten des Zeilenvektors XT.

Die Filterfunktion ist definiert durch und liefert den aktuellen Ausgangs-Datenvektor.

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.

)(,),(),(),( 121 Ntxtxtxtx

)()( TXfty

quellObjekt

empfObjekt

)(,),(),( 11 NT txtxtxX

Dynamisches Verhalten in UML

Page 55: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/55

streamOp

quellObjekt

empfObjekt

Init

/ j=0

FülleRingPuffer

[j<N-1]/ j++

evNewX/ j=0

evNewX[j<N]/ j++

0do/

jx

;exit/

);read(entry/

1 neujN

neu

xx

x

);GEN(evNewYjekt seinEmpfObexit/

);(do/

Xfy

evNewX

Operator

Verhalten des Objekts streamOp

AktualisierenRingPuffer

);,(updatedo/

);read(entry/

neu

neu

xXX

x

Bereit

T

AufDatenWarten

[j=N-1]

UML – Objekte mit kontinuierlichem VerhaltenStreamOps: Filter, Regler, …

er-zeu-gen

ver-nich-ten

Spezifikation von f(X) als Operation, Datenflussdiagramm oder Formel

evNewX[j=N]

;0

i );1mod()1(: von n xKomponenteder i Indizes

),(update

neu

neu

xx

NiiX

xX

Dynamisches Verhalten in UML

Page 56: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/56

UML – Objekte mit kontinuierlichem VerhaltenStreamOps: Beispiel 1-dimensionale Faltung

FaltungOp1d

quellObjekt

empfObjekt

init

/ j=0;

FüllenRingPuffer

[j<N-1]/ j++;

evNewX/ j=0;

evNewX[j<N]/ j++;

0do/

jx

;exit/

);read(entry/

neuj

neu

xx

x

);GEN(evNewYjekt seinEmpfObexit/

);(do/

TXfy

evNewX

Operator

Verhalten des Objekts FaltungOp1d

KXXf TT

)(

AktualisierenRingPuffer

);,(updatedo/

);read(entry/

neuTT

neu

xXX

x

Bereit

T

AufDatenWarten

[j=N-1]

x ist ein Skalar. -> XT ist ein Zeilenvektor. K ist der Faltungskern.

FaltungOp1d

Kernelgröße: intKernel: float vector(Kernelgöße)

evNewX[j=N]

Dynamisches Verhalten in UML

Page 57: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/57

Szenarios: Zeitverhalten von Objekten: ZeitablaufdiagrammeErweiterungen zur Erfassung von RT-AnforderungenZustandszeitdiagramme:Darstellung des Verweilens in und des Wechsels von Zuständen

Zeit

Zus

tan

d

Z1

Z2

Z3

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

Das Zeitablaufdiagramm zeigt einen speziellen Pfad durch das Zustandsdiagramm einer Zustandsmaschine.

Dynamisches Verhalten in UML

Page 58: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/58

Szenarios: Zeitverhalten von Objekten: ZeitablaufdiagrammeErweiterungen zur Erfassung von RT-AnforderungenZustandszeitdiagramme für nebenläufige Zustände

Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML

Page 59: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/59

Szenarios: Zeitverhalten von Objekten: ZeitablaufdiagrammeErweiterungen zur Erfassung von RT-AnforderungenTaskzeitdiagramme

Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML

Page 60: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/60

Use cases

• Zeigt das System in Beziehung zu seiner Umgebung (zu externen Objekten) und seine grundlegenden Fähigkeiten der Wechselwirkung

• Darstellung: Use case Diagramm

Identifiziere Flugzeug

Lokalisiere Trajektorien Zeige Luftraumsituation

Zeige Flugpfad

Verarbeite Nutzerbefehl

Setze Zoomlevel Verschiebe Ausschnitt

Detektiere Abstands-unterschreitung

Primär-radar

Sekundär-radar

Flugzeug-Transponder

Fluglotse

<<includes>><<includes>>

<<extends>>

<<extends>><<extends>>

<<includes>>

Dynamisches Verhalten in UML

Page 61: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/61

Use cases: Beziehungen

UML 1.3 definiert drei verschiedene Beziehungen zwischen Use Cases:

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

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

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

Dynamisches Verhalten in UML

Page 62: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/62

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.

Dynamisches Verhalten in UML

Page 63: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/63

Use cases: requirements

3. Darstellung der QoS

Idenzifiziere Flugzeug

Lokalisiere Trajektorien

Verarbeite Nutzerbefehl

Setze Zoomlevel

Detektiere Abstands-unterschreitung

Primär-radar

Sekundär-radar

Flugzeug-Transponder

Fluglotse

{ Identifikationsrate mindestens5/s, Latenzzeit < 100 ms,Verfügbarkeit > 1-10-9, Fehlerrate < 10-12}

{ Genauigkeit Positionbesser 500 m,Genauigkeit Höhe besser 50m,Latenzzeit < 100 ms}

Dynamisches Verhalten in UML

Page 64: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/64

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.

Dynamisches Verhalten in UML

Page 65: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/65

Szenarios: Objektdiagramm

• Objektdiagramm: Schnappschuss eines Systems auf Objektebene zu einem bestimmten

Zeitpunkt

Dynamisches Verhalten in UML

Page 66: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/66

Szenarios: KollaborationsdiagrammKollaborationsdiagramm: 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

:Klasse1{transient}

:Klasse4

:Klasse3{new}

1: Operation1()

2: Operation2() 3: Operation4()

2.1: Operation3()

:Klasse2{new}

Im Kollaborationsdiagramm ist jedes dargestellte Objekt Platzhalter für ein beliebiges Objekt der Klasse.Unterschied Klassendiagramm!

Dynamisches Verhalten in UML

Page 67: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/67

Szenarios: SequenzdiagrammSequenzdiagramm: 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

erstesObjekt:Klasse1

:Klasse2

neuesObjekt:Klasse3

X

Operation1() Klasse3()

Operation5()

Operation2()

Operation3()

Botschaft

Existierende Objekte

Neu erzeugtes Objekt

Objekt sendet Botschaft an sich selbst

Objekt wirdgelöscht

Kontrollfluss nachOperationsende

Länge: relativeDauer der Methode

Dynamisches Verhalten in UML

Page 68: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/68

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.

Szenarios: Beispiel Mobiltelefon

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 69: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/69

Szenarios: Beispiel Mobiltelefon

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.

Dynamisches Verhalten in UML

Page 70: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/70

Szenarios: Beispiel Mobiltelefon

Robert C. Martin: „Engineering Column“

Spezifikation des dynamischen VerhaltensWie arbeitet das Mobiltelefon? Aufstellung des Use Case Diagramms und Analyse der Use Cases.

Anruf tätigen

Anruf empfangen

SMS empfangen

SMS versenden

Fax/Daten-betriebDaten-

endgerät

Telefon-benutzer

{ ...}

{ ...}

Telefonkonfigurieren

Netzwerk

...

Dynamisches Verhalten in UML

Page 71: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/71Robert C. Martin: „Engineering Column“

Analyse des Use Cases „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?

Szenarios: Beispiel Mobiltelefon

Anruf tätigen

Dynamisches Verhalten in UML

Page 72: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/72Robert C. Martin: „Engineering Column“

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

Szenarios: Beispiel Mobiltelefon

Dynamisches Verhalten in UML

Page 73: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/73

Szenarios: Beispiel Mobiltelefon

Robert C. Martin: „Engineering Column“

• 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“

Dynamisches Verhalten in UML

Page 74: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/74

Szenarios: Beispiel MobiltelefonÜberarbeitung des statischen Modells mit dem dynamischen Modell

Kollaborationsdiagramm unähnlich dem Klassendiagramm.Problem: Die Links sind Instanzen von Assoziationen WiderspruchMöglichkeiten: 1) Anpassung des dynamischen an das statische Modell, 2)

Entwurf eines statischen Modells für das KollaborationsdiagrammKonsequenzen 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.

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 75: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/75

Szenarios: Beispiel MobiltelefonGeändertes Klassendiagramm

Robert C. Martin: „Engineering Column“

• Keine Kompositionen mehr, nur noch Assoziationen: Keine der verknüpften Klassen hat eine Gesamtheit/Teil- Beziehung.• Assoziationsrichtungen

wegen Klarheit der Kommunikationsrich- tung im dynamischen Modell. • Angabe der Operationen in den Klassensymbolen wegen Offensichtlich- keit im dynamischen Modell

Dynamisches Verhalten in UML

Page 76: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/76

Szenarios: Beispiel Mobiltelefon

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.

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 77: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/77

Szenarios: Beispiel MobiltelefonVerfeinerung des statischen Modells

Entkopplung von Button und Dialer zur Wiederverwendbarkeit der Button Klasse in Programmen, die keine Dialer haben.

Robert C. Martin: „Engineering Column“

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

Dynamisches Verhalten in UML

Page 78: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/78

Szenarios: Beispiel MobiltelefonVerfeinerung des statischen ModellsHohe Kopplung der Display Klasse. Änderung einer Methode von Display wegen

eines in Dialer entstandenen Bedarfs Auswirkung auf CellularRadioMaßnahme zur Entkopplung: Segregation der Schnittstellen:

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 79: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/79

Szenarios: Beispiel MobiltelefonAnpassung des dynamischen Modells an die Änderungen

Robert C. Martin: „Engineering Column“

Adapter übersetzen die ButtonPressed Nachrichten in Nachrichten, die Dialer verstehen kann.Segregation der Schnittstellen: Objekt mit Namen display taucht zweimal mit verschiedenem Klassennamen auf.

Dynamisches Verhalten in UML

Page 80: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/80

Szenarios: Beispiel Mobiltelefon

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.

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 81: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/81

Szenarios: Beispiel MobiltelefonSequenzdiagramm: Gleiche Information wie Kollaborationsdiagramm,

Darstellung betont Sequenz der Nachrichten statt Beziehung der Objekte.

Robert C. Martin: „Engineering Column“

1. Ereignisablauf, wenn eine Zifferntaste gedrückt wird

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

Iteration derGruppe

Dynamisches Verhalten in UML

Page 82: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/82

Szenarios: Beispiel Mobiltelefon

Sequenzdiagramme versus Kollaborationsdiagramme

KollaborationsdiagrammZeigt die gesamte Objektzusammenarbeit in einem dichten Diagramm.

SequenzdiagrammZeigt den Fluss des Algorithmus.

Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML

Page 83: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/83

Szenarios: Beispiel MobiltelefonErzeugung und Vernichtung von Objekten im Sequenzdiagramm

Robert C. Martin: „Engineering Column“

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

Dynamisches Verhalten in UML

Page 84: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/84

Szenarios: Beispiel MobiltelefonAsynchrone Nachrichten und Nebenläufigkeit

Robert C. Martin: „Engineering Column“

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.

Dynamisches Verhalten in UML

Page 85: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/85

Szenarios: Beispiel MobiltelefonKonfliktbedingungen: 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)

Robert C. Martin: „Engineering Column“

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

Dynamisches Verhalten in UML

Page 86: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/86Robert C. Martin: „Engineering Column“

Szenarios: Beispiel MobiltelefonKonfliktbedingungenAusschnitt aus Sequenzdiagramm „Anruf empfangen“ / „Anruf tätigen“,

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

Dynamisches Verhalten in UML

Page 87: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/87

Sequenzdiagramme

Erweiterungen zur Erfassung von RT-Anforderungen• 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.

RT-Erweiterung UML

Page 88: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/88

RT-Erweiterung UML

SequenzdiagrammeErweiterungen zur Erfassung von RT-AnforderungenBeispiel Sequenzdiagramm „Herzschrittmacher“

Aus: Bruce Powel Douglass: Real Time UML Second Edition

Page 89: Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML

Vorlesung Automatisierungsprojekte Seite 9/89

SequenzdiagrammeErweiterungen zur Erfassung von RT-AnforderungenFortgeschrittene Sequenzdiagramme: Multiple Szenarios

Aus: Bruce Powel Douglass: Real Time UML Second Edition

RT-Erweiterung UML