<< zurück

MBSE Home

weiter >>

5.1 Eigenschaften von Statecharts

Wie bereits erwähnt, gibt es eine große Anzahl von Dialekten und Einsatzgebieten für Statecharts. Um nicht nur die Notation, sondern auch die Bedeutung und den methodischen Einsatz der Statecharts in der objektorientierten Softwareentwicklung hinreichend präzise festzulegen, um damit einen Gewinn im Hinblick auf Softwarequalität, -entwicklungszeit und -aufwand zu erzielen, ist es wichtig, einige grundlegende Annahmen über den Einsatz von Statecharts zu treffen. Die Abbildung 5.1 beinhaltet eine Liste von Aufgaben, die ein Statechart übernehmen kann.

Eine der grundlegenden Annahmen für den Einsatz eines Statecharts ist, dass ein Statechart nur das Verhalten eines Objekts beschreibt. Für die Beschreibung von Interaktionsmustern sind Sequenzdiagramme besser geeignet.

Ein Statechart beschreibt das Antwortverhalten eines Objekts, das entsteht, wenn ein Stimulus auf dieses Objekt trifft. Ob ein Stimulus dabei einen Methodenaufruf, eine asynchrone Nachricht, einen Timeout oder noch etwas anderes darstellt, ist dabei zunächst unwichtig. Wesentlich ist jedoch, dass die Bearbeitung des Stimulus in atomarer, also nicht unterbrechbarer und nicht hierarchisch geschachtelter Form stattfindet.

Eine Transition wird also durch einen Stimulus angestoßen und dann ohne Unterbrechung ausgeführt. Dabei wird davon ausgegangen, dass das in der Transition festgelegte Verhalten nicht zur Stimulation weiterer Transitionen desselben Objekts führt. Sind die Stimuli eines Statecharts beispielsweise Methodenaufrufe, so darf die Ausführung einer Transition nicht dazu führen, dass dabei rekursiv ein weiterer durch das Statechart beschriebener Methodenaufruf auf demselben Objekt stattfindet.

Die geforderte Ununterbrechbarkeit wird bei Statecharts auch als „run-to-completion“ bezeichnet [CCD01] und ist bei manchen Statechart-Varianten, die zum Beispiel zusammengesetzte oder priorisierte Transitionen erlauben [SGW94], aufgeweicht worden.

Die Stimuli werden durch das Statechart in sequentialisierter Form abgearbeitet. Das bedeutet, dass eine Parallelverarbeitung von Stimuli nicht stattfindet und eine Synchronisation zwischen Transitionen ebenfalls nicht notwendig ist. Dieses Konzept entspricht der in Java üblichen Synchronisation von Methoden auf Objektebene durch das Schlüsselwort synchronized.

Wie jede andere UML-Diagrammart stellt ein Statechart eine bestimmte Sicht auf einen Ausschnitt des zu implementierenden Systems dar. Während ein Objekt normalerweise einen unendlichen Zustandsraum hat, besteht ein Statechart nicht nur aus einer endlichen, sondern typischerweise sogar aus einer sehr kleinen Menge von Diagrammzuständen. Die meist fünf bis zehn Diagrammzustände stellen daher notwendigerweise eine Abstraktion des Objektzustandsraums dar. Je nach Einsatzgebiet des Statecharts kann die Beziehung zwischen Diagramm- und Objektzuständen durch Hinzufügen von OCL-Bedingungen präzise definiert werden. Ähnliches gilt für die Vorbedingungen und Effekte von Transitionen. Abhängig vom Detaillierungsgrad und der Darstellungsform dieser Bedingungen kann ein Statechart daher als ausführbare Implementierung oder als abstrakte Anforderungsbeschreibung angesehen werden. Statecharts können deshalb von der Anforderungsanalyse bis zur Implementierung eingesetzt werden. Statecharts können dabei Lebenszyklen von Objekten genauso wie detailliertes Objektverhalten beschreiben.

Einer der Vorzüge von Statecharts ist die intuitive Darstellungsform der operationellen Verhaltensbeschreibung. Durch die zusätzliche Verwendung von Hierarchie ist es möglich, den Zustandsraum des beschriebenen Objekts noch intuitiver zu strukturieren. Unglücklicherweise bringt die Zustandshierarchie einige subtile semantische Probleme mit sich, so dass die Zustandshierarchie sehr sorgfältig und nicht zu extensiv eingesetzt werden sollte. Durch den Verzicht auf Kommunikation zwischen Substatecharts können hierarchisch strukturierte Zustände semantisch einfacher behandelt und verständlicher erklärt werden. Die Hierarchie wird deshalb nicht mehr zur Komposition von Teilautomaten unterschiedlicher Objekte eingesetzt, wie das noch bei vielen ursprünglichen Varianten der Statecharts [vdB94, Har87] der Fall war.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>