OO-Phasen für Embedded Systems

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

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

3. 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 Use cases werden durch kooperierende Objekterealisiert. Pilot Objekt Nachricht Kursänderung Setze Drehzahl Flugrechner Triebwerk Pilot Auf Ab Auf Ab Assoziation Links Rechts Aileron Seitenruder Höhenruder Steuerfläche Flügel Steuerfläche Heck Druck+ Druck+ Druck- Druck+ Druck- Druck- Hydrauliksystem Vorlesung Automatisierungsprojekte Seite 9/3

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

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

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

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

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

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

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

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

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

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

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

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

16. 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 Vorlesung Automatisierungsprojekte Seite 9/16

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

18. Klasse A Klasse A Klasse A Klasse A Klasse A Klasse A 1..4,6,8..* 1,4,7 1 3 * 0...4 Null bis fünf Beziehungen (Kann-Beziehung) Eine bis 4, 6, 8 oder mehr Beziehungen (Muss-Beziehung) Eine, vier oder sieben Beziehungen (Muss-Beziehung) Genau eine Beziehung (Muss-Beziehung) Genau drei Beziehungen (Muss-Beziehung) Viele Beziehungen: Null, eine, mehrere (Kann-Beziehung) Dynamisches Verhalten in UML UML – Objekt- und Klassenbeziehungen – Kardinalitäten am Beispiel der Beziehung Assoziation Klasse A KA ◄ Assoziationsname KB Klasse B Assoziationsname ► Rolle B Rolle A Vorlesung Automatisierungsprojekte Seite 9/18

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

20. 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 1 1..* Autopilot Aerofoil-Surface- Controller Vorlesung Automatisierungsprojekte Seite 9/20

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

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

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

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

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

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

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

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

29. 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 Wechselgeld geben Münze_ein(Münzwert)/Betrag=+Münzwert Entry/ Wechselbetrag= Betrag-Soll; Wechselgeld zu- rückgeben Entry/ Betrag = 0 [Betrag > Soll] [else] [Betrag == Soll] Rückgabe_erfolgt Auswahl bearbeiten erledigt Was stimmt hier noch nicht? Vorlesung Automatisierungsprojekte Seite 9/29

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

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

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

33. 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. Betriebsart Farbe 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) Fehlerfall Ok BehebungsCmd/genSignal(init) Entry/handle(err) Vorlesung Automatisierungsprojekte Seite 9/33

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

35. 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 Betriebsart Farbe 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

36. 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)] C e2/genSignal(e3(x,y,z)) e5 G e6 e3(a:int, b:float, c:char) e3(a:int, b:float, c:char) D H E e1 Unter2 Vorlesung Automatisierungsprojekte Seite 9/36

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

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

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

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

41. 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 zurInitialisierung der Eingabe und Um-schalten des Einstellmodus für dieeinzelnen Stellen von Minuten undSekunden; Zifferntasten zur Eingabe. • Ähnlich kann die Leistungsstufe eingegeben werden: „0“ für Stufe 1 bis „9“ für Stufe 10. • Wird die Tür geöffnet, wir der laufende Modus unterbrochen und nach Schließen wieder aufgenommen. • Objekte (physisch motiviert): Tasten, Display, Licht, Piepser, Türsensor, Ventilator, Drehteller, Mikrowellensender, Timer. Koordinationskomponente: kochMeister Vorlesung Automatisierungsprojekte Seite 9/41

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

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

44. Dynamisches Verhalten in UML • UML – Dynamisches Objektverhalten – State Charts • Beispiel Mikrowellenherd • Reaktive Klassen: • kochMeisterSteuert 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

45. 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 TimerAblauf evEin [(seinTürSensor->IS_IN(zu)] 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

46. 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); Abstrahlen bereit 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

47. 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/berechneZeit(gesetzteZeit); evAbbruch evZeitsetz /z1=0; z2=0;z3=0; z4=0; ZeitSetzen SekZweiteStelle Vorlesung Automatisierungsprojekte Seite 9/47

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

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

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