Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Vorlesung Automatisierungsprojekte Seite 9/1 OO-Phasen für Embedded Systems Dynamisches Verhalten in UML."—  Präsentation transkript:

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

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

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

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

5 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

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

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

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

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

10 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

11 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

12 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

13 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

14 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

15 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

16 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 Attributliste Operationen Dynamisches Verhalten in UML

17 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

18 Vorlesung Automatisierungsprojekte Seite 9/18 UML – Objekt- und Klassenbeziehungen – Kardinalitäten am Beispiel der Beziehung Assoziation Klasse AKlasse B ◄ Assoziationsname Assoziationsname ► Rolle A Rolle B KAKA KBKB Klasse A 1 Genau eine Beziehung (Muss-Beziehung) Klasse A * Viele Beziehungen: Null, eine, mehrere (Kann-Beziehung) Klasse A 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) Dynamisches Verhalten in UML

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

20 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 11..* Dynamisches Verhalten in UML

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

22 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

23 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

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

25 Vorlesung Automatisierungsprojekte Seite 9/25 UML – Dynamisches Objektverhalten – State Charts State Chart Transitionen Quell-ObjektObj1Obj2 Quelle 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 Objekten propagiert und dort ausgewertet.

26 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

27 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

28 Vorlesung Automatisierungsprojekte Seite 9/28 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 B D C T1/f T3/h T2[x<0]/g [y>0] /m,n A B D C T1[y>0]/f,m,n T3/h,m,n T2[x 0]/g,m,n Diagramm 1 ist äquivalent zu Diagramm 2 Dynamisches Verhalten in UML

29 Vorlesung Automatisierungsprojekte Seite 9/29 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 Entry/ Betrag = 0 Wechselgeld geben Entry/ 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?

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

31 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

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

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

34 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

35 Vorlesung Automatisierungsprojekte Seite 9/35 UML – Dynamisches Objektverhalten – State Charts Synchronisation 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 gestartet [normal] [else] Farbe Betriebsart Ende Start Ablauf t0 t1 Dynamisches Verhalten in UML

36 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 E D 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) e5 e4[IS_IN(D)] e6 Dynamisches Verhalten in UML

37 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 B C A F 4 Dynamisches Verhalten in UML

38 Vorlesung Automatisierungsprojekte Seite 9/38 UML – Dynamisches Objektverhalten – State Charts Hierarchische Zustände Untermaschinen Ober Unter1 Unter2 Unter3 include/ subm1 include/ subm2 ZS1_1 ZS1_2 ZS1_3 ZS2_1 ZS2_2 … subm1 subm2 ZS1_1 ZS1_2 ZS1_3 Dynamisches Verhalten in UML

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

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

41 Vorlesung Automatisierungsprojekte Seite 9/41 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 Zeit setz Leist. setz Zuber. Auftau Timer Ab- Ein bruch 00:00 9 Dynamisches Verhalten in UML

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

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

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

45 Vorlesung Automatisierungsprojekte Seite 9/45 UML – Dynamisches Objektverhalten – State Charts Beispiel 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)] kochMeisterZustand evAbbruch / seinKochTimer->GEN(evAbbruch); seinMw_sender->GEN(evAbbruch); seinPiepser->piep( ); Dynamisches Verhalten in UML

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

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

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

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

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

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

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

53 Vorlesung Automatisierungsprojekte Seite 9/53 Zeit UML – Objekte mit kontinuierlichem Verhalten In 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 Dynamisches Verhalten in UML

54 Vorlesung Automatisierungsprojekte Seite 9/54 UML – Objekte mit kontinuierlichem Verhalten In technischen Anwendungen: StreamOps wie Filter, Regler, … streamOp 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 X T. 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 empfObjekt Dynamisches Verhalten in UML

55 Vorlesung Automatisierungsprojekte Seite 9/55 streamOp quellObjekt empfObjekt Init / j=0 FülleRingPuffer [j

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

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

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

59 Vorlesung Automatisierungsprojekte Seite 9/59 Szenarios: Zeitverhalten von Objekten: Zeitablaufdiagramme Erweiterungen zur Erfassung von RT-Anforderungen Taskzeitdiagramme Aus: Bruce Powel Douglass: Real Time UML Second Edition Dynamisches Verhalten in UML

60 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 > Dynamisches Verhalten in UML

61 Vorlesung Automatisierungsprojekte Seite 9/61 Use cases: Beziehungen UML 1.3 definiert drei verschiedene Beziehungen zwischen Use Cases: Generalisierung Bedeutet, dass ein Use Case eine spezialisiertere oder verfeinerte Version des anderen ist. Analog zu Klassenvererbung. Symbol: Pfeil mit geschlossener Spitze, Richtung vom Eltern- zum Kindprozess. > Wenn z.B. mehrere Geschäftsprozesse die gleichen Unterprozesse besitzen, werden letztere als eigenständige Use Cases modelliert, analog einem Unterprogramm. Die Unterprozesse existieren nie für sich alleine. Symbol: gestrichelter Pfeil mit offener Spitze, Richtung von Basis zum Unterprozess, Stereotypenbeschriftung >. > Von einem Use Case wird in einen anderen verzweigt, wenn gegebene Bedingungen erfüllt sind. Ist der Use Case, in den verzweigt wurde, (die Erweiterung) beendet, erfolgt eine Rückkehr in den Use Case, aus dem verzweigt wurde (die Basis). Symbol: gestrichelter Pfeil mit offener Spitze, Richtung von Erweiterung zu Basis, Stereotypenbeschriftung >. Dynamisches Verhalten in UML

62 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

63 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 mindestens 5/s, Latenzzeit , Fehlerrate < } { Genauigkeit Position besser 500 m, Genauigkeit Höhe besser 50m, Latenzzeit < 100 ms} Dynamisches Verhalten in UML

64 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

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

66 Vorlesung Automatisierungsprojekte Seite 9/66 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 :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

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

68 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

69 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

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

71 Vorlesung Automatisierungsprojekte Seite 9/71 Robert 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

72 Vorlesung Automatisierungsprojekte Seite 9/72 Robert 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

73 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

74 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  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. Robert C. Martin: „Engineering Column“ Dynamisches Verhalten in UML

75 Vorlesung Automatisierungsprojekte Seite 9/75 Szenarios: Beispiel Mobiltelefon Geä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

76 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

77 Vorlesung Automatisierungsprojekte Seite 9/77 Szenarios: Beispiel Mobiltelefon Verfeinerung 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

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

79 Vorlesung Automatisierungsprojekte Seite 9/79 Szenarios: Beispiel Mobiltelefon Anpassung 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

80 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

81 Vorlesung Automatisierungsprojekte Seite 9/81 Szenarios: Beispiel Mobiltelefon Sequenzdiagramm: 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 der Gruppe Dynamisches Verhalten in UML

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

83 Vorlesung Automatisierungsprojekte Seite 9/83 Szenarios: Beispiel Mobiltelefon Erzeugung 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

84 Vorlesung Automatisierungsprojekte Seite 9/84 Szenarios: Beispiel Mobiltelefon Asynchrone 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

85 Vorlesung Automatisierungsprojekte Seite 9/85 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) 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

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

87 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

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

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


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

Ähnliche Präsentationen


Google-Anzeigen