First page Back Continue Last page Overview Graphics

Zustandsdiagramme


Notes:

Während Sequenz~ (und auch Kommunikationsdiagramme) zeigen, wie sich mehrere Klassen bzw. Objekte in einem Anwendungsfall verhalten (wobei nur das für den Anwendungsfall relevante Verhalten abgebildet wird), dienen Zustandsdiagramme dazu die gesamte Funktionalität eines Objektes einer Klasse darzustellen.
Ein einfaches Zustandsdiagramm wie das Obige zeigt bspw. das Verhalten einer Ampelanlage. Es bedient sich dazu sogenannter Zustände, die verbal in kürzestmöglicher Form den inneren Zustand des Objektes. Unter dem inneren Zustand versteht man in diesem Zusammenhang die Gesamtheit aller Attributwerte. Ändern sich (wesentliche) Attributwerte, findet ein sogenannter Übergang statt. Im Falle unserer Ampelanlage ist dazu nichts weiteres notwendig als das Verstreichen von Zeit. Dieses Diagramm zeigt daher nur Knoten (die Zustände) und Kanten (die Übergänge dazwischen).
Wären irgendwelche äußere Einflüsse notwendig um einen Zustandsübergang auszulösen, würden diese durch Texte bei den Kanten dargestellt werden. Auch zeigt dieses Diagramm keinen Endzustand (ein eingerahmter Punkt), in dem das System münden sollte, das ist eigentlich außer für Steuerungsanlagen untypisch und selbst diese kennen zumeist Endzustände um Fehlerfälle sauber beenden zu können.
Implementierbar sind solche endlichen Automaten (wie solche Systeme auch genannt werden) auf verschiedene Art und Weise.
Zum einen kann eine Kaskade aus If-then-else – Statements oder ähnliche Control-of-flow – Elemente benützt werden, um die Zustandsübergänge zu implementieren. Diese Methode erzeugt nicht nur viel Code, sondern dieser ist auch schlecht les~ und wartbar. Abzuraten.
Eine propagierte Methode ist die Gang of Four. Bei dieser Vorgehensweise wird für jeden Zustand im Diagramm eine eigene Unterklasse implementiert, die von einer steuernden Klasse instanziiert und vernichtet werden.
Die initial vermutlich aufwändigste, mittelfristig aber ökonomischste Methode dürfte die Entscheidungstabelle sein: Alle Zustände und die zu ihrem Wechsel nötigen Bedingungen werden in einer Matrix angeordnet. Das lässt sich in praktisch allen Programmiersrprachen recht effizient implementieren und im Servicefall kann u.U. durch simples Einfügen in eine Beschreibungsdatei (oder ~tabelle) das Gesamtverhalten des Systems wunschgemäß beeinflusst werden.