C.5 Statecharts

Statecharts stellen eine weitere Diagrammart der UML/P dar. Ein Statechart ist grundsätzlich einer Klasse oder einer Methode zugeordnet. Deshalb trägt es den Namen des beschriebenen Elements. Ein Statechart benötigt deshalb nur dann einen eigenen Namen, wenn für dieselbe Klasse oder Methode mehrere Beschreibungen existieren. Dies kann zum Beispiel bei Testmodellen der Fall sein. In diesem Abschnitt wird zunächst die abstrakte Syntax von Statecharts in gewohnter Weise durch die in Anhang A eingeführten Syntaxklassendiagramme und EBNF formuliert. Dabei werden auch die in diesem Kapitel eingeführten Stereotypen in einer Liste zusammengefasst und ihre Bedeutung sowie syntaktische Einschränkungen in kompakter Form wiederholt. Schließlich werden die Unterschiede zwischen den UML/P-Statecharts und dem UML-Standard diskutiert.

C.5.1 Abstrakte Syntax

Der graphische Anteil der Statecharts ist im Syntaxdiagramm in Abbildung C.16 festgelegt.

Abbildung C.16: Syntax der Statecharts

Jedes Statechart besitzt ein Attribut der Sorte ⟨KlassennameC.3⟩, das kennzeichnet welcher Klasse beziehungsweise welchem Interface das Statechart zugeordnet ist. Handelt es sich um ein Methoden-Statechart, so ist zusätzlich eine Methode angegeben. Der graphische Anteil von Statecharts ist relativ einfach strukturiert. Ein Statechart besteht aus einer Sammlung von Zuständen und Transitionen, die jeweils in einem Zustand beginnen und enden. Die Zustände sind hierarchisch angeordnet.

Sowohl Zustände als auch Transitionen besitzen eine Reihe von textuellen Anteilen, die unter anderem Bedingungen und Aktionen beschreiben. Diese Anteile sind in Abbildung C.17 beschrieben.

Statecharts kennen drei Arten von Bedingungen, die Zustandsinvariante, die Vor- und die Nachbedingung, die jeweils durch eine OCL-Bedingung der Sorte ⟨OCLExprC.8⟩ umgesetzt werden. Nur in Nachbedingungen ist der Zugriff auf Attributwerte im Ursprungszustand mit @pre erlaubt. Beginnt eine Vorbedingung mit einem let-Konstrukt, so ist die Gültigkeit der dadurch lokal definierten Variablen auf die Transitionsaktion inklusive der Nachbedingung erweitert. Dadurch können ähnlich wie bei OCL-Methodenspezifikationen lokale Variablen effektiver eingesetzt werden.

Für die Beschreibung prozeduraler Aktionen werden direkt Java-Anweisungen verwendet, die auf die Attribute des Objekts und die als lokale Variablen beziehungsweise Parameter zu verstehenden Argumente des Stimulus zugreifen können. Ein Stimulus stößt eine Transition an. Dies kann entweder spontan sein (markiert durch ε), durch ein return einer vorher abgesandten Anfrage oder durch einen Methodenaufruf. Ob letzterer als normaler Methodenaufruf oder als asynchron versandte Nachricht ankommt, wird im Stimulus nicht unterschieden.

Wie bereits für die anderen Diagrammarten wird auf die explizite Einbeziehung von Stereotypen und Merkmalen verzichtet. Dennoch wurden in diesem Kapitel eine Reihe von Stereotypen eingeführt, die zur Festlegung von Semantik und damit auch zur Steuerung von Codegenerierung und des methodischen Einsatzes dienen. Nachfolgend werden diese Stereotypen in Kurzform wiederholt. Generell gilt bei Statecharts wie auch bei den anderen Diagrammarten, dass Stereotypen und Merkmale grundsätzlich für jedes Nichtterminal der Syntax definiert werden können.

Kommentare werden wie in den anderen graphischen Teilnotationen der UML/P üblich und in Abbildung 2.3 demonstriert an die kommentierten Diagrammelemente angefügt.

In Tabelle 5.13 wurden die Zustandsinvarianten aus dem Diagramm in eine eigene Tabelle ausgelagert. In ähnlicher Form kann dies auch für Transitionen und Aktionen erfolgen, um eine Überladung des Diagramms zu vermeiden. Dafür können zusätzliche Namen als Hilfsreferenzen eingeführt werden, die den Bezug eines Tabelleneintrags zu dem beschriebenen Diagrammelement herstellen. Statt also beispielsweise Invarianten oder Vorbedingungen direkt ins Diagramm zu schreiben, steht dort nur ein Name, der auf den entsprechenden Tabelleneintrag verweist. Diese Namen besitzen ansonsten keine weitere Bedeutung, so dass eine explizite Darstellung von Ausgliederungen in Tabellen in der oben dargestellten abstrakten Syntax nicht vorgenommen wird.

C.5.2 Vergleich mit dem UML-Standard

Bei der Definition der UML/P-Statecharts wurden im Vergleich zum UML-Standard [OMG10a] Konzepte weggelassen, deren Notwendigkeit aufgrund der Einbettung der Statecharts in die UML nicht evident ist. Dazu gehören zum Beispiel nebenläufige Zustandsregionen („Und-Zustände“), die eine Spezifikation kompakter, aber nicht lesbarer machen. So ist das Identifizieren von möglichen Abläufen beim „Lesen“ (Review) von Statecharts wesentlich erschwert, da der Leser diese nebenläufigen Zustandsräume gedanklich nachvollziehen muss. Das gilt übrigens auch dann, wenn die Nebenläufigkeit wie in [HG97] vorgeschlagen nur konzeptueller Natur ist und in der Implementierung zum Beispiel durch Bildung von Produktautomaten aufgelöst wird. Aus ähnlichen Gründen wurde auf die Verwendung des History-Mechanismus verzichtet.

Umgekehrt jedoch wurden die UML/P-Statecharts um Nachbedingungen in den Aktionen erweitert, so dass ein Statechart nicht nur eine ausführbare Verhaltensbeschreibung sein muss, sondern auch zur abstrakten Spezifikation von Verhalten auf Basis eines abstrakten Zustandsmodells verwendet werden kann. Die Form der eingeführten Nachbedingungen bietet einen guten Übergang zu OCL-Methodenspezifikationen für die im Statechart verwendeten Stimuli.

Nachfolgend sind die Unterschiede zwischen den UML/P-Statecharts und dem UML-Standard zusammengefasst:

1. Auf parallele Subzustände wurde verzichtet.
2. Ein History-Mechanismus existiert in UML/P nicht.
3. Das Konzept der Stimuli und der Schaltbereitschaft ist gegenüber dem sehr abstrakt gehaltenen Event-Konzept des Standards wesentlich präzisiert worden.
4. Vorbedingungen von Transitionen stehen jetzt links vom Stimulus, um sie noch besser von Nachbedingungen zu unterscheiden.
5. Der UML-Standard kennt keine deskriptiv formulierten Nachbedingungen. Deshalb sind die UML-Statecharts weniger für Spezifikationen, sondern vor allem für Implementierungsbeschreibungen geeignet.
6. Das Aussehen von Invarianten, Vorbedingungen und Aktionen wurde wesentlich konkretisiert, indem OCL-Ausdrücke beziehungsweise Java-Anweisungen dafür vorgegeben wurden.
7. Die Darstellung von Stimuli-Parametern wurde von name:Typ zu Ausdrücken verallgemeinert. Darin enthalten sind konkrete Werte genauso wie Variablen, die dadurch belegt werden und in den Vorbedingungen, Aktionen und Nachbedingungen benutzbar sind. Auf eine Typangabe wurde verzichtet, denn diese ergibt sich bereits aus der Signatur der Klasse, der ein Statechart zugeordnet ist. Gegebenenfalls kann mit Typkonversion der Parameter eine Methode aus mehreren überladenen Methoden eindeutig bestimmt werden.
8. Nebenläufige Transitionen, die mehrere Start- oder Zielzustände besitzen und damit Nebenläufigkeit innerhalb des Statecharts simulieren, sowie Synchronisationszustände wurden weggelassen, da generell das Konzept der Nebenläufigkeit innerhalb eines Objekts beziehungsweise Statecharts fehlt.
9. „Stubbed transitions“, also Transitionen, die in das Innere eines hierarchischen Zustands hineinführen, ohne zum genauen Subzustand zu führen, wurden in UML/P nicht aufgenommen, da die damit ausgedrückte Information nicht präziser ist, als wenn diese Transition direkt zum Superzustand führen würde. Wenn gewünscht, kann eine solche Transition durch einen geeigneten Stereotyp markiert werden.
10. „Junction“ und „choice points“ repräsentieren Kontrollzustände in der Abarbeitung von Transitionen und können durch mit ≪controlstate≫ markierte Zustände nachgebildet werden.

Generell sind die UML/P-Statecharts syntaktisch und semantisch besser mit den anderen UML/P-Notationen integriert, als dies im UML-Standard der Fall ist. Das „Event“-Konzept wurde dort sehr allgemein gehalten, um die verschiedensten, aus den Echtzeitsystem wie auch den Geschäftssystemen stammenden Arten von Stimuli, subsumieren zu können. Eine Integration mit OCL-Bedingungen oder einer konkreten Sprache zur Darstellung von Aktionen erfolgt im Standard nicht. Dort werden zum einen die OCL und zum anderen die Action-Language [OMG01a] als mögliche Sprachen erwähnt, jedoch keine konkrete Integration vorgenommen.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012