Vorlesung Software Engineering I 10 Unified Modeling Language: Zustandsdiagramme Prof. Dr. Dirk Müller
Einführung Übersicht Software-Entwicklungsprozesse Anforderungsanalyse Prozessanalyse und -modellierung Objekt-orientierte Analyse UML Ziele, Grenzen, Geschichte, Metamodellierung, Bewertung Anwendungsfalldiagramme Klassendiagramme Aktivitätsdiagramme Zustandsdiagramme 2/29
Diagrammarten in der UML 2.4.1 Quelle: http://upload.wikimedia.org/wikipedia/de/5/53/uml-diagrammhierarchie.png Download am 27.05.2014 3/29
Motivation Anwendungsfall- und Klassendiagramme sind noch zu weit von der Implementierung entfernt Verfeinerungen nötig wichtigste Möglichkeiten: natürliche Sprache, Aktivitätsdiagramme, Zustandsdiagramme Zustandsautomaten (state machines) in Zustandsdiagrammen (state machine diagrams) darstellen Zustände bilden das bisher Geschehene ab (Gedächtnis) Übergänge (Transitionen) zwischen Zuständen durch interne oder externe Ereignisse initiiert Wie verhält sich das System in einem bestimmten Zustand bei gewissen Ereignissen? 4/29
Geschichte und Prinzipielles Zusammenführung und Erweiterung der endlichen Automaten (Moore- und Mealy-Automaten) durch David Harel [1] wesentliche Erweiterungen hierarchisch (Modularisierung => bessere Lesbarkeit, Testbarkeit und Wiederwendung) Dekomposition in orthogonale zusammengesetzte Zustände mit mehreren Regionen (Parallelisierung) aka active state configuration vereinfachende Annahmen System zu 1 bestimmten Zeitpunkt jeweils in genau 1 Zustand Übergang (Transition) von einem in einen anderen Zustand ohne zeitliche Verzögerung als typische Annahme, aber The duration of a Transition traversal is undefined, allowing for different semantic interpretations, including both 'zero' and non-'zero' time. [3], S. 312 5/29
Ereignis Bedingung Beispiel: Fahrkartenautomat Verhalten kann jeweils nach einem Schrägstrich zur weiteren Verfeinerung angegeben werden z. B. 1 Anwendungsfalldiagramm mit 1 Zustandsdiagramm pro Anwendungsfall dort jeweils 1 Aktivitätsdiagramm für jedes Verhalten Verhalten Quelle: [2], S. 331 6/29
Verfeinerung eines Anwendungsfalls use case implizite Zusammenführung explizite Verzweigung konkrete Syntax überlappend mit der von Aktivitätsdiagrammen feine Unterschiede, die zu beachten, also im Weiteren zu betrachten sind Quelle: [2], S. 334 7/29
Verfeinerung einer Klasse auch als Protokollzustandsautomat möglich bei Ergänzung von Nachbedingungen Quelle: [Bal09], S. 290 Protokoll: Spezifikation erlaubter Abfolgen von Aufrufen der Operationen typischerweise einer Klasse 8/29
Verhaltenszustandsautomat ereignisgesteuerter Ablauf von einem Zustand ausgehende Transitionen werden von relevanten Ereignissen, die dort spezifiziert sind, ausgelöst alle anderen werden ignoriert verschiedene Transitionen vom selben Zustand sollen nicht vom selben Ereignis ausgelöst werden können (sonst nicht eindeutig) Vereinigung der relevanten Ereignisse aller Zustände in einem Ereignispool zusammengefasst gegebene Sequenz von Ereignissen impliziert Sequenz von Zuständen, wobei unterwegs beliebiges Verhalten ausgeführt werden kann bei Ausführung jeweils entweder in einem Zustand oder in einer Transition, alternierend 9/29
Grundelement Zustand Modellierung einer Situation während der Ausführung, wobei eine (meist implizite) Invarianzbedingung erfüllt ist Beispiel Telefon: frei und aktiv als zwei (grobgranulare) Zustände Rechteck mit abgerundeten Ecken, optional mit einer waagerechten Linie unterteilt oben: Name (aussagekräftig) optionale Linie Mitte: internes Verhalten (entry, do, exit) unten: interne Transitionen 3 Arten einfacher Zustand zusammengesetzter Zustand Unterzustandsautomatenzustand Schlafen entry/ einschlafen do/ Schlafphasen durchlaufen exit/ aufwachen 10/29
Grundelement Transition Übergang von einem Ausgangs- zu einem Zielzustand Selbsttransition: Übereinstimmung der beiden Zustände Pfeil mit Beschriftung Ereignisse CallEvent, Operation, operation() SignalEvent, Signal ereignis[bedingung] / verhalten ChangeEvent, Änderung der Bedingung von false zu true, when TimeEvent, Zeitpunkt/-dauer at, after AnyReceiveEvent, alle anderen, all Bedingung: Boolesche, jederzeit auswertbar sollte nur in Protokollzustandsautomaten verwendet werden [2], S. 343 when [Tee kalt genug] at(17:00) after(10 s) 11/29
Protokollzustandsautomat muss einem Classifier (typisch: Klasse), Interface oder Port zugeordnet sein: Operationen bilden den Ereignispool Schlüsselwort {protocol} im Titel fungiert als Black Box, dient also nur der Beschreibung nach außen (externe Sicht) interne Zustände gleichen nicht zwingend den hier angegebenen Beschreibung erlaubter Abfolgen von Aufrufen von Operationen z. B. einer Klasse, also ihres Verhaltens Verhaltenskontext (Ausgangszustand und Vorbedingungen) gültige Reihenfolgen von Operationen erwartete Ergebnisse der Aufrufe (Nachbedingungen) [vorbedingung] operation() / [nachbedingung] kein Verhalten bei Transitionen und auch kein internes Verhalten (entry, do, exit) in den Zuständen Zustandsinvarianten explizit angebbar 12/29
Protokollzustandsautomat einer Tür Door {protocol} Quelle: [3], S. 342 Quelle: [3], S. 342 13/29
Pseudozustände und Endzustand Pseudozustand: Abstraktion, die verschiedene flüchtige Zustände zusammenfasst Zustandsautomat bleibt niemals in einem Pseudozustand stehen Ein- und Austritt finden in einem Verarbeitungsschritt statt; Transitionen dürfen über 1 oder mehrere Pseudozustände gehen Startzustand tiefe History Eintrittspunkt flache History Synchronisation Parallelisierung Austrittspunkt Terminator Kreuzung Verzweigung Endzustand ist kein Pseudozustand: dort echtes Verweilen 14/29
Startzustand ausgefüllter Kreis jede Region (später genauer) mit maximal 1 Startzustand inv: self.subvertex->select (ocliskindof(pseudostate))-> collect (oclastype(pseudostate))->select(kind=pseudostatekind::initial)-> size() <= 1 keine eingehende Transition höchstens eine ausgehende Transition inv: (kind = PseudostateKind::initial) implies (outgoing->size() <= 1) muss ohne Ereignis und ohne Bedingung sein inv: (kind = PseudostateKind::initial) implies (outgoing.guard = null and outgoing.trigger->isempty()) somit nur noch Verhalten als Beschriftung erlaubt in einem Protokollzustandsautomat völlig ohne Beschriftung / schreien() Baby Beispiel zur Klasse Person 15/29
Endzustand vs. Terminator Endzustand kleiner ausgefüllter Kreis umgeben von einem unausgefüllten keine ausgehenden Transitionen inv: outgoing->size() = 0 sofortiges Ende, kein weiteres Verhalten ausgeführt Semantik: Zustandsautomat bzw. Region (später genauer) wurde erfolgreich durchlaufen Terminator Kreuz sofortiges Ende, kein weiteres Verhalten ausgeführt entspricht bei Verfeinerung einer Klasse dem Ende der Lebensdauer eines Objekts der Klasse Semantik: Abbruch, z. B. Fehlerfall oder Notschalter Quelle: [2], S. 348 16/29
Endzustand vs. Terminator: Beispiel Betriebssystem Quelle: [2], S. 356 17/29
ausgefüllter Kreis Kreuzung statische Verzweigung, Bedingungsraum braucht nicht vollständig abgedeckt sein Berücksichtigung der Ereignisse und Bedingungen am Wege vor und nach der Kreuzung, erst danach Ausführung von möglichem Verhalten an Transitionen min. 1 eingehende und min. 1 ausgehende Transition inv: (kind = PseudostateKind::junction) implies (incoming->size() >= 1 and outgoing->size() >= 1) abkürzende Schreibweise mit m+n statt mn Transitionen verschiedene Ereignisse, dass Zustandsänderung per Bedingungen bestimmt, welcher der Zielzustand ist hier: m=n=2 Quelle: [2], S. 352 m=2 n=2 18/29
Beispiel für Kreuzungen: Labyrinth 1. Kreuzung: kein echter Gewinn, sogar schlechter da m=1 und n=4 mit nun 5 > 4 Transitionen [else] 2. Kreuzung: echter Gewinn, da m=4 und n=2 mit 6 < 8 Transitionen Quelle: [2], S. 353 19/29
Verzweigung analog zum Aktivitätsdiagramm: ungefüllte Raute Zusammenführung implizit bei >1 Transitionen zum selben Zustand dynamische Auswertung der Bedingungen an den ausgehenden Transitionen nachdem mögliches Verhalten an der eingehenden Transition ausgeführt wurde Bedingungen müssen Partitionierung bilden Unterschied zur Kreuzung am Beispiel verdeutlicht mit Kreuzung landet man im Zustand C mit Verzweigung landet man im Zustand B Quelle: [2], S. 354 20/29
Zusammengesetzte Zustände und Unterzustände Zustände in einem zusammengesetzten Zustand heißen Unterzustände direkte (Distanz 1 im Baum) und indirekte (sonst) Unterzustände Zustandsbaum (Hierarchie) wird aufgebaut Zustandsautomat A ohne Transitionen Quelle: [2] S. 358 21/29
Zusammengesetzte Zustände und Regionen zusammengesetzter Zustand enthält 1 oder mehrere Regionen, die jeweils Unterzustände enthalten orthogonale Regionen können parallel ausgeführt werden Start der Ausführung des Verhaltens in einer Region Standardaktivierung des Startzustands durch Aktivierung des umschließenden Zustands bzw. des Zustandsautomats (auf der höchsten Ebene) explizite Aktivierung durch Transition zu einem Zustand oder Pseudozustand in der Region bei expliziter Aktivierung einer Region Standardaktivierung aller zu dieser Quelle: [2] orthogonalen Regionen S. 360 auch möglich: explizite Aktivierung mehrerer Regionen durch Parallelisierung 22/29
Verlassen eines zusammengesetzten Zustandes ohne Ereignis aus dem Endzustand aus einem beliebigen Unterzustand aus einem Unterzustand (hier aus C) Quelle: [2], S. 361 23/29
Parallelisierung und Synchronisation Parallelisierung und Synchronisation Parallelisierung in zueinander orthogonale Regionen Synchronisation aus zueinander orthogonalen Regionen jeweils keine Ereignisse und keine Bedingungen an den parallelen Transitionen Notation wie bei Aktivitätsdiagrammen: schwarzer Balken Parallelisierung Synchronisation Parallelität: Unterteilung in 2 zueinander orthogonale Regionen Quelle: [3], S. 328 24/29
Ein- und Austrittspunkte Zweck: kontrollierter Ein- und Austritt in einem zusammengesetzten Zustand, um Lesbarkeit zu verbessern und abstrakte Zustände zu ermöglichen Eintrittspunkt Austrittspunkt Quelle: [2], S. 371 25/29
Flache und tiefe History Merken des letzten Zustands auf der Ebene der direkten Unterzustände zur späteren Wiederherstellung: flache Merken der ges. aktiven Zustandskonfiguration: tiefe flache Historie: Radio, Kassette oder CD wird sich gemerkt tiefe Historie: alles wird sich gemerkt, bis hin zu Titel, Zeit, etc. Quelle: [2], S. 377 26/29
Verhaltenszustandsautomat Telefon Quelle: [3], S. 334 27/29
Zusammenfassung ausdrucksstarke Notation zur Beschreibung von Verhalten basiert auf endlichen Automaten wesentliche Neuerungen in Statecharts nach David Harel zusammengesetzte Zustände zur Hierarchisierung und zur Beschreibung von Parallelität in Regionen flache und tiefe History zur dynamischen Wiederherstellung von Zuständen Kreuzung als statische Verzweigung mit m+n statt mn Transitionen Bedingungen brauchen keine Partitionierung zu bilden falls das auslösende Ereignis Bedingungsvariablen ändert, anderer Folgezustand als bei (dynamischer) Verzweigung möglich Terminator zur Beendigung der Lebenszeit eines Objekts 28/29
Literatur [1] David Harel: Statecharts: A visual formalism for complex systems in: Science of Computer Programming, 8(3):231 274, June 1987 [2] Chris Rupp, Stefan Queins: UML 2 glasklar, Hanser Verlag, 2012, 4. Auflage [3] OOSE, UML-2.5-Notationsübersicht, 2013, Download am 20.11.2016, http://www.oose.de/wp-content/uploads/2012/05/uml-notationsübersicht-2.5.pdf 29/29