Vorlesung Automatisierungsprojekte Seite 9/1

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

Dynamisches Verhalten in UML OO-Phasenübersicht Vorlesung Automatisierungsprojekte Seite 9/2

Dynamisches Verhalten in UML System-Fähigkeit Objekte arbeiten zusammen, um die System-Funktionalität herzustellen. Externes Interaktionsobjekt (Akteur, actor) System- fähigkeit (Use Case) Flugzeug-Autopilot Pilot Use cases werden durch kooperierende Objekte realisiert. Objekt Nachricht Kursänderung Flugrechner Setze Drehzahl Triebwerk Pilot Auf Ab Assoziation Auf Ab Links Rechts Steuerfläche Flügel Aileron Seitenruder Höhenruder Steuerfläche Heck Druck+ Druck+ Druck- Druck+ Druck- Hydrauliksystem Druck- Vorlesung Automatisierungsprojekte Seite 9/3

Dynamisches Verhalten in UML UNAV3400 Miniature UAV autopilot Quelle: UNAV, LLC Vorlesung Automatisierungsprojekte Seite 9/4

Dynamisches Verhalten in UML Ü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. Vorlesung Automatisierungsprojekte Seite 9/5

Dynamisches Verhalten in UML Übungsbeispiel UML: Telefonanlagenverwaltung Vorlesung Automatisierungsprojekte Seite 9/6

Dynamisches Verhalten in UML Übungsbeispiel UML: Telefonanlagenverwaltung Erweitern Sie das Klassen-Diagramm des beschriebenen Szenarios um Assoziationen und Kardinalitäten Vorlesung Automatisierungsprojekte Seite 9/7

Dynamisches Verhalten in UML Übungsbeispiel UML: Telefonanlagenverwaltung 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. Vorlesung Automatisierungsprojekte Seite 9/8

Dynamisches Verhalten in UML Übungsbeispiel UML: Telefonanlagenverwaltung Vorlesung Automatisierungsprojekte Seite 9/9

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/10

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/11

Dynamisches Verhalten in UML 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) Vorlesung Automatisierungsprojekte Seite 9/12

Dynamisches Verhalten in UML 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) Vorlesung Automatisierungsprojekte Seite 9/13

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/14

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/15

Dynamisches Verhalten in UML 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 Attributliste Operationen Klassenname Vorlesung Automatisierungsprojekte Seite 9/16

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/17

Dynamisches Verhalten in UML UML – Objekt- und Klassenbeziehungen – Kardinalitäten am Beispiel der Beziehung Assoziation Klasse A KA ◄ Assoziationsname KB Klasse B Rolle A Assoziationsname ► Rolle 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) Vorlesung Automatisierungsprojekte Seite 9/18

Dynamisches Verhalten in UML UML – Objekt- und Klassenbeziehungen – Assoziation: Interpretation Klasse A KA ◄ Assoziationsname KB Klasse B Rolle A Assoziationsname ► Rolle B Kfz-Steuer- gerät 1 1..* Airbag- Steuergerät Supervisor überwacht ► 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 1 * Mitarbeiter 0..1 0..1 PKW Arbeit- geber Arbeit- nehmer Fahrer Dienst- wagen 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. Vorlesung Automatisierungsprojekte Seite 9/19

Dynamisches Verhalten in UML 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. * 1..* Web-Auftritt Web-Seite Autopilot 1 1..* Aerofoil-Surface- Controller Vorlesung Automatisierungsprojekte Seite 9/20

Dynamisches Verhalten in UML UML – Beispiel: Sensorklassenbeziehung Wärmebildkamera {abstract} Optische Messvor- richtung Videokamera Laserscanner 1 1...N Optischer Sensor Sensor „ist eine Art von ...“ „besteht aus ...“ Multiplex- Sensor Uniplex- Sensor * 1 1 1 A/D-Konverter A/D-Konverter Vorlesung Automatisierungsprojekte Seite 9/21

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/22

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/23

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts State Chart Transitionen Erweiterung 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 Vorlesung Automatisierungsprojekte Seite 9/24

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts State Chart Transitionen Quell-Objekt Annahme: System initialisert, dann Ereignis S T wird zu assozi- ierten Objekten propagiert und dort ausgewertet. Zust1 S(a,b,x, y) / a=12, b=3.14, x=23, y=2.73, T Zust2 Quelle 1 1 Quelle Ziel1 1 1 Ziel2 Obj1 Obj2 ZustB ZustX T(x:int, y:float) / z=x/y ZustA T(a:int, b:float) / c=b^a ZustY Vorlesung Automatisierungsprojekte Seite 9/25

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/26

Dynamisches Verhalten in UML 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* Vorlesung Automatisierungsprojekte Seite 9/27

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Pseudozustände von UML 1.3 Junction (Kreuzung): Zusammenführung mehrfacher Übergänge oder Aufspaltung einer Transition in mehrere Folgetransitionen. A T1/f Diagramm 1 ist äquivalent zu Diagramm 2 C T3/h [y>0] B D T2[x<0]/g /m,n C A T3/h,m,n T1[y>0]/f,m,n D B T2[x<0&&y>0]/g,m,n Vorlesung Automatisierungsprojekte Seite 9/28

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Pseudozustände von UML 1.3 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 Münze_ein(Münzwert)/ Betrag=+Münzwert Wechselgeld geben Entry/ Wechselbetrag= Betrag-Soll; Wechselgeld zu rückgeben Entry/ Betrag = 0 [Betrag > Soll] [else] [Betrag == Soll] Rückgabe_erfolgt erledigt Auswahl bearbeiten Was stimmt hier noch nicht? Vorlesung Automatisierungsprojekte Seite 9/29

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Aktionen als 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. Vorlesung Automatisierungsprojekte Seite 9/30

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/31

Dynamisches Verhalten in UML 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. E1: a, b, en_1, en_2, en_3 E3: e, ex_3, ex_2, en_4 Z1 Entry/ en_2 Exit/ ex_2 Z2 Entry/ en_1 Exit/ ex_1 Z3 E1 / a,b E2 / c,d Entry/ en_3 Exit/ ex_3 E3 / e Z4 Entry/ en_4 Exit/ ex_4 Vorlesung Automatisierungsprojekte Seite 9/32

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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 Betriebsart Initial Z_rot gestartet init init Z_grün [normal] [else] Z_normal Demo Z_blau grün [IS_IN(Fehlerstatus::Ok) Fehlerzustand Fehler(err)/log(err) Ok Fehlerfall BehebungsCmd/genSignal(init) Entry/handle(err) Vorlesung Automatisierungsprojekte Seite 9/33

Dynamisches Verhalten in UML 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 Vorlesung Automatisierungsprojekte Seite 9/34

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Synchronisation mit Join Pseudozustand Fork Pseudozustand (wenn nicht die Initialzustände eingenommen werden sollen) Start t0 Ablauf Farbe Betriebsart Initial Z_rot gestartet init init Z_grün [normal] [else] Z_normal Demo Z_blau grün [IS_IN(Fehlerstatus::Ok) t1 t1 Ende Vorlesung Automatisierungsprojekte Seite 9/35

Dynamisches Verhalten in UML 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 Unter1 Unter3 B e1 F A e4[IS_IN(D)] e2/ genSignal(e3(x,y,z)) C e5 G e3(a:int, b:float, c:char) e6 e3(a:int, b:float, c:char) D H E Unter2 e1 Vorlesung Automatisierungsprojekte Seite 9/36

Dynamisches Verhalten in UML 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. A D F 4 C E B Vorlesung Automatisierungsprojekte Seite 9/37

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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 Vorlesung Automatisierungsprojekte Seite 9/38

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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. Vorlesung Automatisierungsprojekte Seite 9/39

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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. Vorlesung Automatisierungsprojekte Seite 9/40

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel 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 zur Initialisierung der Eingabe und Um- schalten 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. Objekte (physisch motiviert): Tasten, Display, Licht, Piepser, Türsensor, Ventilator, Drehteller, Mikrowellensender, Timer. Koordinationskomponente: kochMeister 7 8 9 4 5 6 1 2 3 Zeit setz Leist. setz Zuber. Auftau Timer Ab- Ein bruch 00:00 9 Vorlesung Automatisierungsprojekte Seite 9/41

Dynamisches Verhalten in UML
UML – Dynamisches Objektverhalten – State Charts Beispiel Mikrowellenherd - Klassendiagramm display 1 stufeView:stringView 1 1 timerView:stringView 1 modusView:bitMap licht 1 1 1 1 1 1 türSensor Tastenfeld 10 1 kochTimer 1 ziffernKnopf:Button 1 piepser 1 1 zuberAktKnopf:Button 1 1 1 auftauAktKnopf:Button 1 1 kochMeister 1 mw_sender 1 timerAktKnopf:Button 1 1 1 abbruchKnopf:Button drehtellerMotor ventilator 1 einKnopf:Button 1 zeitsetzKnopf:Button Vorlesung Automatisierungsprojekte Seite 9/42 1 leistsetzKnopf:Button

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel 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 Vorlesung Automatisierungsprojekte Seite 9/43

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel 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. Vorlesung Automatisierungsprojekte Seite 9/44

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel Mikrowellenherd, Statechart für kochMeister: evAbbruch / seinKochTimer->GEN(evAbbruch); seinMw_sender->GEN(evAbbruch); seinPiepser->piep( ); kochMeisterZustand Ablauf H evTimingSel [seinKochTimer-> IS_IN(ZeitGesetzt)] Timing evEin [(seinTürSensor->IS_IN(zu)] TimerAblauf bereit evFertig / seinMw_sender->GEN(evFertig); seinPiepser->piep( ); Zubereiten KochenAblauf evEin[(seinTürSensor->IS_IN(zu)] / seinMw_sender->GEN(evLeistungAn) evAuftauenSel [seinKochTimer-> IS_IN(ZeitGesetzt)] evZubereitenSel [seinKochTimer-> IS_IN(ZeitGesetzt)] Auftauen AuftauAblauf evEin[(seinTürSensor->IS_IN(zu)] / seinMw_sender->GEN(evLeistungAn); evTürÖffnet / seinMw_sender->GEN(evPausieren); seinKochTimer->GEN(evPausieren); Pause evEin[(seinTürSensor->IS_IN(zu)] / seinMw_sender->GEN(evLeistungAn); seinKochTimer->GEN(evLeistungAn); Vorlesung Automatisierungsprojekte Seite 9/45

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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. Betrieb evLeistungAn / berechne(leistungStufe, sTime, wTime); bereit Abstrahlen evAbbruch tm(sTime) / magnetronAus( ); tm(wTime) / magnetronAn( ); evFertig Abwarten evAbbruch entry/ seinLicht->einschalten( ); seinVentilator->einschalten( ); seinDrehteller->einschalten( ); exit/ magnetronAus( ); if (seinTürSensor->IS_IN(Closed)) seinLicht->ausschalten( ); seinVentilator->ausschalten( ); seinDrehteller->ausschalten( ); evLeistungAn Pause evPausieren Vorlesung Automatisierungsprojekte Seite 9/46

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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. evFertig Bereit ZeitGesetzt evAbbruch evZeitsetz / z1=0; z2=0; z3=0; z4=0; evAbbruch evZeitsetz/ berechneZeit(gesetzteZeit); ZeitSetzen SekZweiteStelle Vorlesung Automatisierungsprojekte Seite 9/47

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel Mikrowellenherd, Statechart für mw_kochTimer: ZeitSetzen evZiffer/ seinZifferknopf->zahl(z1); evZiffer/ seinZifferknopf->zahl(z4); MinErsteStelle SekZweiteStelle do/ seinTimerView >blink(1,z1); do/ seinTimerView >blink(4,z4); evZeitsetz [z1<6] evZeitsetz[z3<6] MinZweiteStelle SekErsteStelle evZeitsetz do/ seinTimerView >blink(2,z2); do/ seinTimerView >blink(3,z3); evZiffer/ seinZifferknopf->zahl(z2); evZiffer/ seinZifferknopf->zahl(z3); Vorlesung Automatisierungsprojekte Seite 9/48

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts Beispiel Mikrowellenherd, Statechart für mw_kochTimer: ZeitGesetzt evEin / kochZeit=gesetzteZeit; bereit Countdown tm(kochZeit)/seinKochMeister->GEN(evFertig); evAbbruch evAbbruch evEin Pause evPause / kochZeit=getRestZeit( ); Vorlesung Automatisierungsprojekte Seite 9/49

Dynamisches Verhalten in UML UML – Dynamisches Objektverhalten – State Charts 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). Offen Entry/ seinLicht->einschalten( ) else evTürSchließt / seinKochMeister-> GEN(evTürSchließt) evTürÖffnet / seinKochMeister-> GEN(evTürÖffnet) Status do/ s=getTürStatus( ) [s==zu] Zu Entry/ seinLicht->ausschalten( ) Vorlesung Automatisierungsprojekte Seite 9/50

Dynamisches Verhalten in UML UML – State Charts und Klassendiagramme Beispiel Herzschrittmacher: Klassendiagramm Zustandsdiagramm zu AtrialModel auf der folgenden Folie Vorlesung Automatisierungsprojekte Seite 9/51 Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML UML – State Charts und Klassendiagramme Beispiel Herzschrittmacher: State Chart für Objekte der Klasse AtrialModel Vorlesung Automatisierungsprojekte Seite 9/52 Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML UML – Objekte mit kontinuierlichem Verhalten In technischen Anwendungen: Filter, Regler, …: streamOps Eingangs-Datenstrom x(t) Eingangsdatenstrom: Strom von Datenvektoren, z.B. zeitl. äquidistant quellObjekt Zeit streamOp Ausgangsdatenstrom: Strom von Datenvektoren Zeit empfObjekt Ausgangs-Datenstrom y(t) Vorlesung Automatisierungsprojekte Seite 9/53

Dynamisches Verhalten in UML UML – Objekte mit kontinuierlichem Verhalten 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. 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. quellObjekt streamOp empfObjekt Vorlesung Automatisierungsprojekte Seite 9/54

Dynamisches Verhalten in UML UML – Objekte mit kontinuierlichem Verhalten StreamOps: Filter, Regler, … Verhalten des Objekts streamOp / j=0 er- zeu- gen [j<N-1]/ j++ quellObjekt Init AktualisierenRingPuffer Bereit evNewX [j=N-1] streamOp AufDatenWarten evNewX [j=N] evNewX/ j=0 ver- nich- ten Operator FülleRingPuffer empfObjekt T evNewX[j<N]/ j++ Spezifikation von f(X) als Operation, Datenflussdiagramm oder Formel Vorlesung Automatisierungsprojekte Seite 9/55

Dynamisches Verhalten in UML UML – Objekte mit kontinuierlichem Verhalten StreamOps: Beispiel 1-dimensionale Faltung x ist ein Skalar. -> XT ist ein Zeilenvektor. K ist der Faltungskern. FaltungOp1d Kernelgröße: int Kernel: float vector (Kernelgöße) Verhalten des Objekts FaltungOp1d / j=0; [j<N-1]/ j++; init AktualisierenRingPuffer Bereit evNewX [j=N-1] quellObjekt AufDatenWarten evNewX [j=N] evNewX/ j=0; Operator FüllenRingPuffer FaltungOp1d evNewX[j<N]/ j++; empfObjekt T Vorlesung Automatisierungsprojekte Seite 9/56

Dynamisches Verhalten in UML Szenarios: Zeitverhalten von Objekten: Zeitablaufdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Zustandszeitdiagramme: Darstellung des Verweilens in und des Wechsels von Zuständen Zustand Z3 Z2 Z1 Zeit 10ms 20ms 30ms 40ms 50ms 150ms 160ms 170ms 180ms Das Zeitablaufdiagramm zeigt einen speziellen Pfad durch das Zustandsdiagramm einer Zustandsmaschine. Vorlesung Automatisierungsprojekte Seite 9/57

Dynamisches Verhalten in UML Szenarios: Zeitverhalten von Objekten: Zeitablaufdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Zustandszeitdiagramme für nebenläufige Zustände Vorlesung Automatisierungsprojekte Seite 9/58 Aus: Bruce Powel Douglass: Real Time UML Second Edition

Dynamisches Verhalten in UML Szenarios: Zeitverhalten von Objekten: Zeitablaufdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Taskzeitdiagramme Vorlesung Automatisierungsprojekte Seite 9/59 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 Flugzeug- Transponder Primär- radar Identifiziere Flugzeug <<includes>> <<includes>> Lokalisiere Trajektorien Zeige Luftraumsituation <<includes>> <<extends>> Fluglotse Sekundär- radar Zeige Flugpfad Detektiere Abstands- unterschreitung Verarbeite Nutzerbefehl <<extends>> <<extends>> Setze Zoomlevel Verschiebe Ausschnitt Vorlesung Automatisierungsprojekte Seite 9/60

Dynamisches Verhalten in UML 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. <<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>>. Vorlesung Automatisierungsprojekte Seite 9/61

Dynamisches Verhalten in UML Use cases: requirements 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. Vorlesung Automatisierungsprojekte Seite 9/62

Use cases: requirements 3. Darstellung der QoS Flugzeug- Transponder { Identifikationsrate mindestens 5/s, Latenzzeit < 100 ms, Verfügbarkeit > , Fehlerrate < 10-12} { Genauigkeit Position besser 500 m, Genauigkeit Höhe besser 50m, Latenzzeit < 100 ms} Primär- radar Idenzifiziere Flugzeug Lokalisiere Trajektorien Sekundär- radar Detektiere Abstands- unterschreitung Verarbeite Nutzerbefehl Fluglotse Setze Zoomlevel Vorlesung Automatisierungsprojekte Seite 9/63

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/64

Dynamisches Verhalten in UML Szenarios: Objektdiagramm Objektdiagramm: Schnappschuss eines Systems auf Objektebene zu einem bestimmten Zeitpunkt Vorlesung Automatisierungsprojekte Seite 9/65

Dynamisches Verhalten in UML 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() Im Kollaborationsdiagramm ist jedes dargestellte Objekt Platzhalter für ein beliebiges Objekt der Klasse. Unterschied Klassendiagramm! :Klasse1 {transient} 2: Operation2() 3: Operation4() :Klasse2 {new} :Klasse4 2.1: Operation3() :Klasse3 {new} Vorlesung Automatisierungsprojekte Seite 9/66

Dynamisches Verhalten in UML 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 :Klasse2 Neu erzeugtes Objekt Operation1() Klasse3() neuesObjekt :Klasse3 Botschaft Länge: relative Dauer der Methode Kontrollfluss nach Operationsende Operation5() Operation3() Objekt sendet Botschaft an sich selbst Operation2() Objekt wird gelöscht X Vorlesung Automatisierungsprojekte Seite 9/67

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/68 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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. Vorlesung Automatisierungsprojekte Seite 9/69 Robert C. Martin: „Engineering Column“

... Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon
Spezifikation des dynamischen Verhaltens Wie arbeitet das Mobiltelefon? Aufstellung des Use Case Diagramms und Analyse der Use Cases. Netzwerk { ...} Anruf empfangen Anruf tätigen Telefon- benutzer SMS empfangen ... SMS versenden Telefon konfigurieren Daten- endgerät Fax/Daten- betrieb Vorlesung Automatisierungsprojekte Seite 9/70 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon Analyse des Use Cases „Anruf tätigen“. Use case: „Anruf tätigen“ Benutzer drückt die Ziffern-Tasten, um die Telefonnummer einzugeben. Bei jedem Ziffern-Tastendruck wird die Zahl im Display um die Ziffer ergänzt. Für jede Ziffer erzeugt der „Dialler“ den entsprechenden Ton und gibt ihn über den Lautsprecher aus. Der Benutzer drückt die „Send“-Taste. Ein “in use” Anzeigesymbol erscheint im Display. Das Mobilfunkgerät stellt eine Verbindung mit dem Netzwerk her. Die akkumulierten Ziffern werden an das Netzwerk gesendet. 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? Anruf tätigen Vorlesung Automatisierungsprojekte Seite 9/71 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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 Vorlesung Automatisierungsprojekte Seite 9/72 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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“ Vorlesung Automatisierungsprojekte Seite 9/73 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon Ü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. Vorlesung Automatisierungsprojekte Seite 9/74 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon Geändertes Klassendiagramm 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 Vorlesung Automatisierungsprojekte Seite 9/75 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/76 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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. Vorlesung Automatisierungsprojekte Seite 9/77 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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: Vorlesung Automatisierungsprojekte Seite 9/78 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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. Vorlesung Automatisierungsprojekte Seite 9/79 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML 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. Vorlesung Automatisierungsprojekte Seite 9/80 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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 Vorlesung Automatisierungsprojekte Seite 9/81 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon Sequenzdiagramme versus Kollaborationsdiagramme Kollaborationsdiagramm Zeigt die gesamte Objektzusammenarbeit in einem dichten Diagramm. Sequenzdiagramm Zeigt den Fluss des Algorithmus. Vorlesung Automatisierungsprojekte Seite 9/82 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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 Vorlesung Automatisierungsprojekte Seite 9/83 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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. Vorlesung Automatisierungsprojekte Seite 9/84 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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 Vorlesung Automatisierungsprojekte Seite 9/85 Robert C. Martin: „Engineering Column“

Dynamisches Verhalten in UML Szenarios: Beispiel Mobiltelefon 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. Vorlesung Automatisierungsprojekte Seite 9/86 Robert C. Martin: „Engineering Column“

RT-Erweiterung UML 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. Vorlesung Automatisierungsprojekte Seite 9/87

RT-Erweiterung UML Sequenzdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Beispiel Sequenzdiagramm „Herzschrittmacher“ Vorlesung Automatisierungsprojekte Seite 9/88 Aus: Bruce Powel Douglass: Real Time UML Second Edition

RT-Erweiterung UML Sequenzdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Fortgeschrittene Sequenzdiagramme: Multiple Szenarios Vorlesung Automatisierungsprojekte Seite 9/89 Aus: Bruce Powel Douglass: Real Time UML Second Edition

Vorlesung Automatisierungsprojekte Seite 9/1

Ähnliche Präsentationen

Präsentation zum Thema: "Vorlesung Automatisierungsprojekte Seite 9/1"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Vorlesung Automatisierungsprojekte Seite 9/1

Ähnliche Präsentationen

Präsentation zum Thema: "Vorlesung Automatisierungsprojekte Seite 9/1"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback