<< zurück

MBSE Home

weiter >>

5.3 Zustände

Die Statechart-Notation wird verwendet, um auf Basis von Zustandsräumen das Verhalten von Objekten zu beschreiben. Die wesentlichen Elemente eines Statecharts sind daher Zustände, Transitionen und die ihnen zugeordneten Aktionen. Die in den Abbildungen 5.8, 5.9 und 5.10 gegebene kompakte Begriffseinordnung wird nun in den folgenden Abschnitten detaillierter diskutiert.

Ein Zustand ist laut dem UML-Standard [OMG10a] eine Situation für ein Objekt, in der das Objekt eine bestimmte Bedingung erfüllt und dabei auf ein Ereignis wartet oder eine interne Aktivität durchführt. Typischerweise bleibt ein Objekt eine bestimmte Zeit in einem solchen Objektzustand. Abbildung 5.11 zeigt einen einzelnen Zustand, der von der Klasse Auction eingenommen werden kann²

Zustandsnamen sind innerhalb des Diagramms eindeutig.

5.3.1 Zustandsinvarianten

Da ein Diagrammzustand einer Menge von Objektzuständen entspricht, ist es meistens notwendig, diese Menge genauer zu beschreiben. Dazu kann die Zustandsinvariante verwendet werden, die in Form einer OCL-Bedingung notiert wird. Die OCL-Bedingung wird im Kontext des beschriebenen Objekts, in Abbildung 5.11 also ein Objekt der Klasse Auction, formuliert. Dabei ist es möglich, auf Attribute des eigenen Objekts, aber auch davon abhängiger Objekte (also der Objektumgebung) zuzugreifen. Die Zustandsinvariante hätte also auch in einer normalen OCL-Bedingung verwendet werden können.

Es ist empfehlenswert, die Zustandsinvariante unter Benutzung der lokalen Attribute und gegebenenfalls von Attributen durch Komposition abhängiger Objekte zu beschränken, da sich sonst ein Diagrammzustand ändern kann, ohne dass ein expliziter Stimulus beim modellierten Objekt bearbeitet worden wäre. Solche Statecharts besitzen normalerweise nur deskriptiven Charakter und eignen sich zur Modellierung von Tests, nicht aber zur Codegenerierung.

Eine Zustandsinvariante kann verschiedene Aufgaben erfüllen:

1. Ähnlich zu einem Kontrakt [Mey97] kann eine von dem Zustand ausgehende Transition sich darauf verlassen, dass der Objektzustand die angegebene Bedingung erfüllt.
2. Umgekehrt bedeutet dies für eine in dem Zustand endende Transition, dass sie verpflichtet ist, die Zustandsinvariante zu etablieren.
3. Wenn außerdem für das Objekt eine nicht sichtbare, externe Aktivität auf der Objektumgebung stattfinden kann, während das Objekt in dem Zustand ist, dann muss diese Aktivität ebenfalls sicherstellen, dass die Zustandsinvariante nicht verletzt wird. Eine solche Sicherstellung ist zum Beispiel notwendig, wenn das Objekt öffentliche Attribute besitzt oder die Zustandsinvariante auf den Objektzustand fremder Objekte zugreift.

Wenn bei einem Statechart die Gefahr besteht, das Diagramm mit Informationen zu überladen, wird als Alternative eine Auslagerung von Zustandselementen in eine Tabelle empfohlen. Tabelle 5.13 zeigt dies für Zustandsinvarianten. Wo es sinnvoll ist, können verschiedene Formen tabellarischer Darstellung gemäß [Bro98] oder [Par93] auch für Transitionen und Aktionen zum Einsatz kommen.

Für das Verständnis des Zustandskonzepts in der objektorientierten Modellierung ist es hilfreich, dessen Bestandteile zu betrachten. Der Datenzustand wird durch die Attribute des eigenen und gegebenenfalls abhängiger Objekte bestimmt. Dazu zählen auch die Links zu anderen Objekten. Ein zweiter Anteil, der den Objektzustand ausmacht, ist jedoch der Kontrollzustand, der sich im laufenden System durch den Programmzähler und den Aufrufkeller manifestiert. Eine Zustandsinvariante kann nur über den Datenzustand sprechen, während ihr der Kontrollzustand verborgen bleibt. Abbildung 5.12 zeigt beispielsweise vier Datenzustände der Klasse Auktion, die jeweils disjunkte Zustandsinvarianten besitzen.

Mit einem Statechart kann der Kontrollzustand nicht in seiner vollen Detaillierung modelliert werden. Jedoch stellen Zustände in einem Statechart, das den Ablauf einer einzelnen Methode beschreibt, eine Abstraktion des Kontrollzustandsraums dar.

Die Zustandsinvarianten von Datenzuständen müssen ebenfalls nicht notwendigerweise disjunkt sein. So kann zum Beispiel auf die Verwendung von Zustandsinvarianten komplett verzichtet werden, wenn dies zur Darstellung der gewünschten Information nicht beiträgt. Beispielsweise besitzt das Statechart in Tabelle 5.13 auch ohne die Beschreibung der Zustandsinvarianten eine gewisse Aussagekraft bei der Kommunikation und Dokumentation.

Um Kontrollzustände von Datenzuständen unterscheiden zu können, bietet sich die Verwendung von Stereotypen an. In Tabelle 5.14 werden für diesen Zweck die Stereotypen ≪datastate≫ und ≪controlstate≫ eingeführt.

Normalerweise charakterisiert die Zustandsinvariante eine Eigenschaft des Zustands beziehungsweise des Objekts, das sich in diesem Zustand befindet. Ein Objekt kann jedoch die Zustandsinvariante auch dann erfüllen, wenn es sich gerade in einem anderen Zustand befindet. Abbildung 5.15 demonstriert dies anhand der Vertrauenswürdigkeit von Personen. Ein Rating, das unter anderem das Wohlverhalten in früheren Auktionen erfasst, wird dazu genutzt, drei Personengruppen zu unterscheiden. Der Stereotyp ≪statedefining≫ im Zustand BadPerson führt dazu, dass jede Person mit einem Rating kleiner als Null sich definitiv in diesem Zustand befindet. Deshalb ist diese Bedingung definierend für den Zustand BadPerson. Demgegenüber wirkt die Bedingung im Zustand VIP-Person lediglich charakterisierend. Es kann also nach dem Statechart in Abbildung 5.15 Personen im Zustand NormalPerson geben, die ebenfalls ein Rating größer 4500 erreichen. Hintergrund dieser Modellierung ist, dass eine Person erst dann VIP wird, wenn dies explizit freigegeben wird, während bei negativem Rating der Zustand BadPerson sofort eingenommen wird.

Der Stereotyp ≪statedefining≫ wird in der nachfolgenden Tabelle 5.16 definiert.

Abhängig davon, ob es sich bei im Statechart modellierten Zuständen um Kontroll- oder Datenzustände handelt und ob diese durch definierende Zustandsinvarianten beschrieben sind, sind unterschiedliche Strategien für die Implementierung des Statecharts möglich. Beispielsweise können definierende Invarianten durch boolesche Prädikate realisiert und dazu genutzt werden, den Zustand direkt aus den Attributen abzuleiten. Fehlen definierende Zustandsinvarianten, so muss fast immer ein zusätzliches Attribut verwendet werden, das den Diagrammzustand explizit im Objektzustandsraum speichert.

5.3.2 Hierarchische Zustände

Hierarchie kann eingesetzt werden, um eine Zustandsexplosion zu verhindern, indem mit ihr komplexe Zustandsräume strukturiert werden. Zusätzlich ist die Hierarchie von methodischem Interesse, weil sie erlaubt, Zustände der oberen Ebene zuerst zu definieren und diese später in Subzustände zu verfeinern. Hierarchiebildung erlaubt deshalb eine abstrakte Sicht des Zustandsraums eines Objekts zu definieren. Ein hierarchisch unterteilter Zustand hat wie jeder andere Zustand einen Namen und kann eine Zustandsinvariante sowie eine entry- und exit-Aktion als auch eine do-Aktivität enthalten. Zusätzlich enthält er einen oder mehrere Subzustände. Abbildung 5.17 zeigt eine alternative Darstellung des Statecharts aus Abbildung 5.12, in dem zwei Zustände hierarchisch zusammengefasst wurden.

Der Zustand AuctionOpen ist dabei durch die beiden enthaltenen Subzustände AuctionRegularOpen und AuctionExtended unterteilt. Diese Subzustände sind in einem eigenen Feld von den anderen Komponenten des partitionierten Zustands abgegrenzt.

Mit der Vollständigkeitsmarkierung © wird festgelegt, dass der Zustand AuctionOpen durch die beiden Subzustände partitioniert wird. Das heißt, befindet sich das Objekt im Zustand AuctionOpen, so auch genau in einem der beiden Subzustände und umgekehrt. Wäre die Vollständigkeitsmarkierung weggelassen worden oder explizit die Markierung für Unvollständigkeit „… “ angegeben worden, so wäre es möglich, dass Objekte der modellierten Klasse den Superzustand AuctionOpen einnehmen, ohne sich in einem der beiden Subzustände zu befinden. Das ist zum Beispiel dadurch möglich, dass ein weiterer, im Diagramm nicht explizit angegebener Subzustand, existiert.

Einer der Vorteile der hierarchischen Dekomposition von Zuständen ist die Möglichkeit, gemeinsame Anteile von Zustandsinvarianten in den Superzuständen zu notieren. Damit entsteht eine kompaktere Fassung der Zustandsinvarianten für beide Subzustände. Die tatsächliche Zustandsinvariante eines Subzustands ist also die Konjunktion aller Zustandsinvarianten seiner Superzustände. Dementsprechend sind die beiden in Abbildung 5.18 gezeigten Darstellungen für Zustände äquivalent und es darf generell die kompaktere Darstellungsform verwendet werden.³

Es ist möglich, dass eine Zustandsinvariante nicht erfüllbar ist. Das heißt, es gibt keinen Objektzustand, bei dem die Zustandsinvariante zu true evaluiert. Eine solche Situation ist, wie in Abschnitt 5.5.2 beschrieben, zu vermeiden, da Transitionen, die zu diesem Zustand führen, ein Verhalten suggerieren, das die Implementierung gar nicht besitzt. In hierarchisch strukturierten Zuständen ist dabei nicht jede Zustandsinvariante einzeln, sondern die Konjunktion aller Zustandsinvarianten des Subzustands und seiner Superzustände zu betrachten.

Ein Nebeneffekt der Möglichkeit, Zustandsinvarianten vom Superzustand explizit in den Subzustand zu übernehmen und der später noch diskutierten Möglichkeiten, Transitionen vom oder zum Superzustand direkt in die Subzustände zu führen, erlaubt es, je nach Erfordernis eine Hierarchie im Zustandsraum einzuführen oder zu entfernen. Die Äquivalenz von flacher und hierarchischer Darstellung ist im Statechart in Abbildung 5.19 illustriert. Hierarchie ist aufgrund dieser Äquivalenz nichts anderes, als eine Schreiberleichterung zur Verhinderung der Explosion von Zuständen und Transitionen.

Im Vergleich zu den Original-Statecharts [Har87] und zum UML-Standard [OMG10a] wird genau wie in ROOM [SGW94] nur die so genannte Oder-Dekomposition von Zuständen verwendet. Diese Form der Dekomposition erlaubt den Zustandsraum hierarchisch zu zerlegen, ist aber nicht geeignet, Parallelität oder Nebenläufigkeit innerhalb eines Objekts zu beschreiben. Da Parallelität heute in vielen Systemen vor allem auf grob granularer Ebene stattfindet und spätestens innerhalb eines Objekts Sequentialisierung vorherrscht, ist die Und-Dekomposition von Zuständen in der UML zur Modellierung nebenläufiger Verhaltenskomponenten nicht notwendig.⁴

5.3.3 Start- und Endzustand

Da Statecharts meist den Lebenszyklus eines Objekts oder den Ablauf einer Methode modellieren, benötigen sie eine Beschreibung, die Diagrammzustände als Start- beziehungsweise Endzustände qualifizieren. Abbildung 5.20 zeigt, wie Start- und Endzustände markiert werden.

Ein Statechart darf mehrere Start- und Endzustände besitzen. Es dürfen sogar Zustände gleichzeitig Start- und Endzustand sein. Abbildung 5.20 zeigt, dass es zwei Arten gibt, eine Auktion ins Leben zu rufen. Normale Kunden können eine Auktion anlegen. Diese muss jedoch noch zusätzlich frei gegeben werden. Nur eine bevollmächtigte Gruppe guter Kunden darf Auktionen in einem sofort freigegebenen Zustand anlegen. Wird eine Auktion zum Beispiel wegen fehlender Bonität des Anlegers nicht freigegeben oder ist die Auktion beendet, so ist auch der Lebenszyklus des Auktionsobjekts beendet. Die schwarzen Kreise und die Pfeile von beziehungsweise zu diesen Kreisen stellen also selbst keine Zustände oder Transitionen dar, obwohl ihre Darstellung diesen Eindruck erweckt.

Der durch die Markierung mehrerer Startzustände entstehende Nichtdeterminismus im Statechart wird, wie in Abschnitt 5.2.2 beschrieben, als Wahlfreiheit interpretiert. Entweder kann der Entwickler diese Wahlfreiheit im weiteren Verlauf des Projekts einschränken oder bei der Implementierung durch verschiedene Konstruktoren dem System alle Möglichkeiten überlassen.

Innerhalb eines hierarchisch zergliederten Zustands können ebenfalls Start- und Endzustände markiert werden. Sie haben dann allerdings eine andere Bedeutung, die in Abschnitt 5.4.2 diskutiert wird.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>