7. Konkretisierungen im Feindesign 7.1 Zustandsdiagramme 7.2 Object Constraint Language 173
Verfeinerte Modellierung Durch die verschiedenen Sichten der Systemarchitektur wird der Weg vom Anforderungsmodell zur Implementierung beschrieben Es bleiben offene Themen: Wie bekomme ich ein gutes Klassendesign (nächstes Kapitel)? Wie kann man das komplexe Verhalten von Objekten noch beschreiben (Klassendiagramme sind statisch, Sequenzdiagramme exemplarisch)? Antwort: Zustandsdiagramme Wie kann man bei der Klassenmodellierung Randbedingungen formulieren, was in Klassendiagrammen (Bedingungen in geschweiften Klammern) nur bedingt möglich ist? Antwort: Object Constraint Language 174
Zustandsdiagramme 7.1 generell wird der Zustand eines Objekts durch die Werte seiner Exemplar- und Klassenvariablen beschrieben Häufig wird der Begriff Zustand auch für eine spezielle Exemplarvariable genutzt, die z. B. über eine Enumeration realisierbar ist z. B. : Ampel: rot, rotgelb, gelb, grün z. B. : Projekt: vorbereitet, grob geplant, Mitarbeiter zugeordnet, verschoben, in Bearbeitung, in Endabnahme, in Gewährleistung, beendet Die Übergänge zwischen den Zuständen werden durch Ereignisse, zumeist Methodenaufrufe, veranlasst Die Übergänge lassen sich durch ein Zustandsdiagramm (ursprünglich Statechart nach D. Harel) spezifizieren Zustandsautomaten spielen auch in der theoretischen und technischen Informatik eine zentrale Rolle 175
Struktur von Zustandsdiagrammen Zustandsdiagramm gehört zu einem Objekt einer Klasse alle Angaben für Zustände und Transitionen sind Optional Transition wird ausgeführt, wenn Ereignis eintritt und Bedingung erfüllt ist ohne Ereignis und Bedingung wird Transition dann ausgeführt, wenn Entry, Do, und Exit durchlaufen Einfacher Automat muss deterministisch sein 176
Beispiel: Zustandsdiagramm eines Projekts man erkennt: nach Planung keine Planungsänderung 177
Hierarchische Zustände 178
Parallele Unterzustände unabhängige Teilzustände können in parallelen Zuständen bearbeitet werden ohne Parallelität müsste Kreuzprodukt der Zustände der parallelen Automaten betrachtet werden 179
Beispiel: Uhr 180
Zustandsmodellierung und Realzeitsysteme in klassischen OO- Programmen gibt es meist wenige zentrale Klassen, für die sich eine Zustandsmodellierung anbietet In Systemen mit Zeit kann Zustandsmodellierung Zeitbedingungen beinhalten auch warte(5 sek) 181
Event [Condition] / Action Transitionsbeschriftung Ereignis[Bedingung]/Aktion Was ist Ereignis? Hängt von Applikation ab Methodenaufruf Ereignis im Programm (Variable wechselt Wert) technische Systeme: Signale typisches Beispiel: Steuersysteme erhalten Signale (->Ereignisse) von Sensoren wenn etwas passiert (z. B. ein-/ausgeschaltet) lesen Werte anderer Sensoren, Teilsysteme (-> Bedingung), die Entscheidungen beeinflussen senden Signale (-> Aktion) an andere Systeme 182
Beispiel: Start-Stopp-Automatik (1/2) zentrale Aufgabe: Start-Stopp-Automatik stellt den Motor immer dann selbstständig aus, wenn dieser nicht mehr benötigt wird (z. B. Halt an Ampel) Randbedingung: keine Abschaltung bis maximal 3 Grad und ab minimal 30 Grad Ablauf: Zündschlüssel einstecken, Motorstartknopf drücken, dann startet Automatik Motorein- und Abschaltung wird anhand der Kupplung erkannt einmal Motorabschaltknopf zum Verlassen der Automatik, zweimal zum Stoppen des Autos [Frage: was fehlt alles zur Realität] 183
Beispiel: Start-Stopp-Automatik (2/2) Klärung, welche Sensoren senden Signale: Zündschloss: ein Motorein-/ und Abschaltung: ein und aus Kupplung: leerlauf und treten Klärung, welchen Sensoren können abgefragt werden: Temperaturwert temp 184
Umsetzung von Zustandsdiagrammem Abhängig davon, wie formal die Zustände und Transitionen spezifiziert sind, kann aus Zustandsdiagrammen Programmcode erzeugt werden Typisch: Iteratives Vorgehen: informelle Beschreibungen werden schrittweise durch formalere ersetzt Ereignisse können für folgendes stehen Methodenaufrufe externe Ereignisse des GUI (-> Methodenaufruf) Teilsituation, die bei der Abarbeitung einer Methode auftreten kann Automat wird zunächst zu komplexer Methode, die z. B. anhand der Zustände in Teilmethoden refaktoriert werden kann 185