<< zurück

MBSE Home

weiter >>

5.5 Aktionen

Erst durch Verwendung von Aktionen wird die Verhaltensbeschreibung eines Statecharts vollständig. Aktionen beschreiben die Reaktion auf den Empfang eines Stimulus in einem bestimmten Zustand, indem sie dem Zustand als entry- beziehungsweise exit-Aktion oder der Transition als Reaktion hinzugefügt werden. Gemäß der UML/P zugrunde liegenden Philosophie werden zwei Arten von Aktionen erlaubt. Eine prozedurale Form erlaubt die direkte Nutzung von Zuweisungen und Kontrollstrukturen und eine beschreibende Aktionsform ermöglicht es, den Effekt einer Aktion zu charakterisieren, ohne festzulegen, mit welchen Mitteln diese Aktion tatsächlich realisiert wird.

Beide Arten von Aktionsbeschreibungen ergänzen einander und erlauben jeweils die Nutzung der Technik, die sich am besten eignet. Manchmal ist es einfacher, eine Aktion durch prozedurale Anweisungen zu beschreiben und damit ihre Implementierung anzugeben. Leider führen Anweisungen oft zu unnötiger Überspezifikation, weil sie Implementierungsdetails vorweg nehmen. Deshalb ist es von Interesse, je nach Bedarf die beschreibende Form oder eine Kombination beider Formen einzusetzen.

5.5.1 Prozedurale und beschreibende Aktionen

Die Verwendung eines prozeduralen Stücks Code hat gegenüber einer beschreibenden Bedingung den Vorteil, dass sie direkt zur Codegenerierung verwendet werden kann. Demgegenüber können beschreibende Bedingungen oft abstrakter formuliert werden und der Implementierung einen Freiraum zur Verfügung stellen. Besonders interessant wird die Kombination aus beiden Aktionsformen, indem die Aktion sowohl durch prozeduralen Code modelliert als auch durch eine Bedingung beschrieben wird.

Ein Methoden-Statechart besitzt typischerweise nur Aktionen die durch Java-Code modelliert sind. Ein solches Statechart eignet sich zur direkten Umsetzung in eine vollständige Implementierung. Da UML/P als Zielsprache Java vorsieht, ist die Verwendung einer eigenständigen „Action Language“, wie sie in [OMG01a] diskutiert wird, nicht notwendig. Stattdessen können direkt in Java formulierte Codestücke eingesetzt werden. Die Idee einer für diese Aufgabe angepassten „Action Language“ hat nur beschränkten Wert, da es sich ebenfalls um eine vollständige Programmiersprache handeln muss und sich daher notwendigerweise gegenüber einer vorhandenen Programmiersprache wie Java nur ein geringfügiger Vorteil durch eine an die Aufgabenstellung angepasste syntaktische Form ergibt. Im Gegenteil benötigt die „Action Language“ eigene Übersetzer und Funktions-Bibliotheken. Es setzt sich daher auch in diesem Kontext der Ansatz durch, die UML als Familie von Sprachen zu sehen [CKM⁺99] und dadurch Elemente der Zielsprache direkt in die jeweils genutzte UML-Version zu übernehmen.

Als Aktion ist daher ein beliebiges Java-Codestück erlaubt, das Bezug auf die Attribute des modellierten Objekts und die Argumente des bearbeiteten Stimulus nehmen darf. Die Veränderung des Objektzustands und des Zustands weiterer Objekte der Umgebung sind explizit erlaubt. Ist der bearbeitete Stimulus ein Methodenaufruf mit Ergebnis, so ist die Aktion mit einer Return-Anweisung abzuschließen. Um zu vermeiden, dass ein Statechart überladen wirkt, können die Aktionen zum Beispiel in tabellarischer Form dem Statechart angefügt werden, wie das für Vorbedingungen bereits in ähnlicher Form in Tabelle 5.13 erfolgt ist.

Eine durch Code beschriebene Aktion bietet keinen Spielraum für die Auslassung von Implementierungsdetails, die der Modellierer noch nicht angeben möchte. Deshalb bieten Statecharts als zweite Aktionsform die Möglichkeit, Nachbedingungen in Form von OCL-Statements anzugeben, die es erlauben, eine gewisse Bandbreite von Verhalten zu charakterisieren, ohne vorwegzunehmen, wie diese tatsächlich zu implementieren sind. Eine in OCL formulierte Nachbedingung wird auch Aktionsbedingung genannt. Sie besitzt einen ähnlichen Charakter, wie die Nachbedingung der in Abschnitt 3.4.3 diskutierten Methodenspezifikation. Tatsächlich lassen sich Transitionen, die als Stimulus einen Methodenaufruf verarbeiten, wie in Abschnitt 5.6.3 beschrieben, in eine Spezifikation in den Vor-/Nachbedingungs-Stil umsetzen. Wie dort besprochen, eignen sich mit Aktionsbedingungen versehene Statecharts nicht direkt zur Codegenerierung. Sie sind stattdessen ein Hilfsmittel zur abstrakten Modellierung von Verhalten während des Entwurfsprozesses und zur Modellierung von Tests. Während die Etablierung einer Aktionsbedingung im Allgemeinen nicht automatisiert möglich ist, können Aktionsbedingungen sehr wohl automatisiert überprüft und Fehlerfälle erkannt werden.

Die Aktionsbedingungen einer Transition dürfen auf die Argumente des verarbeiteten Stimulus, die Attribute des modellierten Objekts und gegebenenfalls lokale Variablen, die im Anweisungsteil der Aktion definiert wurden, zugreifen. Insbesondere Attribute können dabei im Zustand vor und nach Durchführung der Transition verwendet werden. So kann zum Beispiel mit a==a@pre modelliert werden, dass ein Attribut unverändert geblieben ist.

Abbildung 5.36 beinhaltet einen Ausschnitt aus einem Statechart für die Klasse Auction, in der eine Transition mit prozeduraler Aktionsbeschreibung und einer Nachbedingung zu sehen ist. Ist die Klasse TimingPolicy korrekt implementiert, so ergibt sich die Nachbedingung bereits aus den Aktionsanweisungen. Die Nachbedingung hat hier also illustrativen Charakter und kann vor allem für Tests eingesetzt werden.

Nachbedingungen können aber nicht nur als redundantes Addendum zu Aktionsanweisungen formuliert werden, sondern können diese auch ergänzen. Auf diese Weise kann ein Teil des Verhaltens bereits prozedural modelliert und ein anderer Teil noch durch eine OCL-Bedingung beschreibend charakterisiert sein. Bei der nachfolgend diskutierten Behandlung von Aktionen in hierarchischen Zuständen wird diese Interaktion zwischen charakterisierender Bedingung und prozeduraler Implementierung noch genauer beleuchtet.

Eine beschreibende Charakterisierung der Aktion mithilfe einer Nachbedingung hat den bereits in Abschnitt 3.4.3 diskutierten Nachteil, dass weitere Änderungen an Variablen, die in der Bedingung nicht explizit erwähnt werden, auch nicht ausgeschlossen sind. Auch hier soll der pragmatische Ansatz verfolgt werden, dass bei einer Implementierung oder einer Ergänzung des Statecharts in Richtung Codegenerierung dem Implementierer die Möglichkeit gegeben wird, selbständig zu entscheiden, welche Änderungen zusätzlich vorzunehmen sind. Statecharts, deren Nachbedingungen nur einen Teil von der Implementierung vorgenommenen Veränderungen beschreiben, sind dennoch für Tests hervorragend geeignet. Sie können eingesetzt werden, um das Verhalten der Implementierung bezüglich eines bestimmten Aspekts zu beschreiben und zu testen.

5.5.2 Aktionen in Zuständen

Wie bereits Abbildung 5.11 zeigt, gibt es jedoch auch die Möglichkeit, einem Zustand eine entry- und exit-Aktion sowie eine do-Aktivität hinzuzufügen. Auch diese Aktionen können prozedural oder durch eine OCL-Bedingung beschrieben werden. Die entry-Aktion eines Zielzustands wird in Kombination mit der Transitionsaktion ausgeführt und dient häufig dazu, Verbindungen zu öffnen, Zustandswechsel zu signalisieren, Protokollausgaben durchzuführen oder Manipulationen an der graphischen Oberfläche vorzunehmen.

In ganz ähnlicher Form werden exit-Aktionen benutzt, um Tätigkeiten durchzuführen, die beim Verlassen des Zustands notwendig sind. Das kann etwa das Schließen einer Verbindung oder einer Datei sowie weitere Protokollausgaben sein. Da sowohl entry- als auch exit-Aktionen jeweils im Kontext der Durchführung einer Transition ausgeführt werden, sind diese Aktionen primär eine Schreibabkürzung, denn wie Abbildung 5.37 zeigt, können entry-Aktionen alternativ auch auf ankommende Transitionen und exit-Aktionen auf ausgehende Transitionen verschoben werden. Abbildung 5.37 stellt dabei den Fall prozeduraler Aktionen dar, in der die Aktionen durch sequentielle Aneinanderreihung komponiert werden können.

Sequentielle Komposition für Code

Die in Abbildung 5.37 gezeigte Regel erlaubt es, entry- und exit-Aktionen auf die Transitionen zu verschieben und aus den Zuständen zu entfernen. Dies gilt aber natürlich nur, wenn alle betroffenen Transitionen gleichermaßen behandelt werden.

Dieses Verfahren kann auch für entry- und exit-Aktionen in hierarchischen Zuständen verwendet werden. Abbildung 5.38 zeigt den Transfer prozeduraler Aktionen auf die Transitionen. Diese Regel demonstriert auch, in welcher Reihenfolge entry- beziehungsweise exit-Aktionen in hierarchischen Zuständen ausgeführt werden. Die Reihenfolge der Ausführung dieser Aktionen entspricht dabei der Reihenfolge des Verlassens beziehungsweise des Betretens von Zuständen durch die ausgeführte Transition.

Konjunktion für Aktionsbedingungen

Sind die Aktionen eines Statecharts durch OCL-Aktionsbedingungen spezifiziert, so wird statt der sequentiellen Komposition die logische Konjunktion verwendet. Abbildung 5.39 zeigt, wie auch in diesem Fall Bedingungen von den Zuständen in die Transitionen verschoben werden können. Bei dieser Transformation ist natürlich, wie bei allen anderen Transformationen, auch auf die Erhaltung der syntaktischen Korrektheit zu achten. Insbesondere sind gegebenenfalls zufällig gleich definierte lokale Variablen geeignet umzubenennen.

Die Schaltbereitschaft einer Transition hängt nach der Definition in Abschnitt 5.4.4 ausschließlich vom Quellzustand, dem Stimulus und der Vorbedingung ab. Es gibt jedoch schaltbereite Transitionen, die zu einem Zielzustand führen, dessen Zustandsinvariante nicht erfüllt ist, die eine nicht erfüllbare Nachbedingung haben oder in der sich Zielzustandsinvariante und Nachbedingung widersprechen. Dieses Problem tritt bei einer prädikativen Beschreibung von Aktionen auf und ist nicht automatisiert erkennbar. Zum einen lässt sich dies vermeiden, indem die Nachbedingung und die Zustandsinvariante des Zielzustands einfache Formen annehmen, die idealerweise über orthogonale Teile des Zustandsraums Aussagen treffen. Zum anderen kann durch Wahl einer geeigneten Vorbedingung sichergestellt werden, dass die Transition nur schaltbereit ist, wenn die Nachbedingung erfüllbar ist. Entsprechend kann die Schaltbereitschaft einer Transition zusätzlich dadurch festgelegt werden, dass die Transition ausführbar ist, also Nachbedingung und Zielzustandsinvariante erfüllt werden können. Generell ist eine unerfüllbare Nachbedingung jedoch zu vermeiden, denn einem solchen Statechart kann keine sinnvolle Bedeutung zugewiesen werden [Rum96]. Wird sie jedoch in einem Softwareentwicklungsprozess eingebracht und nicht sofort als solche erkannt, so ist spätestens nach deren Erkennung, zum Beispiel bei entsprechenden Tests, eine Behebung angebracht.

Abschnittsweise Aktionsbedingungen

Die in Abbildung 5.39 illustrierte Interpretation von Zustandsaktionen ist für rein prädikativ beschriebene Statecharts adäquat. Besitzt ein Statechart jedoch eine Mischform aus prozeduralen und prädikativen Aktionsbeschreibungen, so ist eine alternative Interpretation angebracht, die dem Charakter einer sequentiellen Abarbeitung der Aktionen gerecht wird. Abbildung 5.40 illustriert diese Interpretation. Mithilfe der in Anhang B eingeführten ocl-Anweisung für OCL-Zusicherungen wird dabei eine abschnittsweise Erfüllung der für eine Transition relevanten Bedingungen gefordert.

In Abbildung 5.40 wird durch Verwendung des Stereotyps ≪actionconditions:sequential≫ im Wesentlichen verhindert, dass die in der exit-Aktion verwendete Bedingung bedA auch am Ende der Transition noch gelten muss. Stattdessen kann diese Bedingung zum Beispiel durch die Transitionsaktion wieder invalidiert werden.

Der Stereotyp ≪actionconditions:sequential≫ wird in Tabelle 5.41 definiert.

Bei der Betrachtung der entry- und exit-Aktionen wurden die bereits in früheren Abschnitten diskutierten Zustandsinvarianten vernachlässigt. Eine Zustandsinvariante gilt immer dann, wenn der Zustand, dem sie zugeordnet ist, eingenommen wurde. Insbesondere gilt eine Zustandsinvariante auch nachdem die entry-Aktion eines Zustands ausgeführt wurde und bevor die exit-Aktion eines Zustands ausgeführt wird. Zustandsinvarianten können also an entsprechender Stelle bei den in den Abbildungen 5.39 und 5.40 gezeigten Äquivalenzen eingefügt werden.

5.5.3 Zustandsinterne Transitionen

Während die entry- und exit-Aktionen als Teile der ankommenden und ausgehenden Transitionen zu sehen sind, bilden zustandsinterne Transitionen vollständige und eigenständige Transitionen, bei denen die entry- oder exit-Aktionen des Zustands nicht durchgeführt werden. Abbildung 5.42 zeigt, wie eine zustandsinterne Transition verstanden werden kann. Zustandsinterne Transitionen verlassen nämlich den Zustand nicht und führen deshalb keine entry- und exit-Aktionen durch. Würde ZustandA keine entry- und exit-Aktion besitzen, so könnte statt der Einführung eines Subzustands die Transition vereinfachend direkt an ZustandA angebracht werden.

5.5.4 do-Aktivität

Wenn ein Zustand eine Situation des Objekts repräsentiert, in der eine Aktivität herrscht, zum Beispiel ein Telefon klingelt oder eine Warnmeldung blinkt, kann die do-Aktivität zu ihrer Modellierung verwendet werden. In einem nicht durch spezielle Hardware unterstützten Java-Programmiermodell gibt es dafür zwei wesentliche Interpretationsmöglichkeiten. Eine Möglichkeit ist es, eine do-Aktivität durch einen parallelen Thread, der nur in diesem Zustand aktiv ist, umzusetzen. Eine alternative und hier bevorzugte Methode ist jedoch in Abbildung 5.43 dargestellt.

In der Transformation der Abbildung 5.43 wurde angenommen, dass ein Zeitgeber timer zur Verfügung steht, der nach Ablauf der festgelegten Zeit die Methode timeout() aufruft. Diese ist als interne Transition dargestellt, die den Zustand nicht verlässt, zunächst die Aktion ausführt und dann den Zeitgeber neu setzt.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>