Dieser Artikel ist der Beginn einer Reihe in der wir uns mit der Simulation von Zustandsautomaten beschäftigen. Die Artikelserie ist gedacht für Einsteiger in die Thematik und baut sich in der Komplexität langsam auf. Beginnend mit dem grundlegensten Wissen um Zustandsautomaten zu erstellen und zu simulieren, werden wir nach und nach alle Aspekte der Modellierung von State Machines durchgehen.

Vorausgesetzt wird ein Basiswissen von SparxSystem’s Enterprise Architect  (EA)Aufbauend auf EA verwenden wir zur Simulation der erstellten Automaten das Enterprise Architect Add-In AMUSE .

Warum nun eine Simulation von Zustandsautomaten?

Software wird mit UML modelliert. State Machines sind Teil der UMLSpezifikation, die Simulation eines UML Modells, welches eine konzeptuelle Abbildung eines Softwaresystems darstellt bringt viele Möglichkeiten und Vorteile mit sich.

• Syntax und Semantik eines Modells können Validiert werden
• Die Konsistenz und Korrektheit eines Modells kann überprüft werden.
• Das Laufzeitverhalten des Systems kann getestet werden.
• Durch die Verwendung von Mocks ist ein Isoliertes Testen des Systems möglich. Externe Abhängigkeiten können “gefaked” werden.

AMUSE bringt dazu noch viele andere Vorteile für Architekten und Entwickler mit ein.

• AMUSE generiert Code –> Dieser kann in der Umsetzungsphase weiter verwendet / angepasst werden
• Der generierte Code basiert auf Templates welche ebenfalls völlig frei definierbar sind.
• AMUSE kann einfach erweitert werden. Eine Simulation von anderen Modellen ist ebenfalls machbar.
• Wie oben erwähnt, kann mit Mocks gearbeitet werden, um externe Abhängigkeiten zu simulieren. Dies ermöglich auch einen Test-getriebenen Entwicklungsansatz (zB TDD)

Anhand eines Mini-Beispiels, wollen wir uns kurz die exemplarische Vorgehensweise zur Simulation einer State Machine ansehen. In den Folgeartikeln werden wir dieses Beispiel dann auf ein “Echt-Welt” Beispiel erweitern.

Als Erstes erstellen wir uns eine neue State Machine in 3 Schritten:

Abb. 1 – Hinzufügen einer neuen Class View

  Abb. 2- Hinzufügen eines Elements vom Typ “Class”

  Abb. 3 – Hinzufügen einer neuen State Machine zur Klasse

Für unser 1. Beispiel erstellen wir lediglich eine “Initial” State, einen “Final” State und einen State dazwischen

  Abb. 4 – Die State Machine für Bsp. 1

Abb. 5 – Trigger erstellen

Der Transition “ButtonClicked” fügen wir einen einfachen Trigger hinzu, welchen wir dann in der Simulation feuern können. (Abb. 5)

Sofern AMUSE als EA Add-In installiert ist, kann im Menü unter
Add-Ins | AMUSE | Execute Workflow die Simulation aufgerufen werden (Abb. 6)

Abb. 6 – AMUSE aufrufen

Mittels Rechts-Klick auf die State Machine kann der Workflow gestartet werden und die Simulation beginnt.

Abb. 7 – AMUSE – Workflow starten

Der aktuelle Zustand in dem die Simluation sich befindet wird dabei jeweil rot umrandet. Um nun zum Ende des Workfows zu gelangen kann im Zustand “Initialized” mittels Rechts-Klick | Fire Trigger eine Liste aller Trigger aufgerufen werden. Unser Trigger sollte unter “Signals” erscheinen. Sobald der Trigger simuliert wurde geht der Automat in den Endzustand über.

Abb. 8 – Trigger feuern

Soweit eine erste kurze Einführung in die Simulation mit Enterprise Architect und AMUSE. Ich hoffe die Lust auf die Simulation wurde geweckt, in den Folgeartikeln erarbeiten wird dann interessantere Beispiele, welche zT. die Anbindung an externe System (zB Ampelanlagen,..) zeigen.

Links:

AMUSE Produktdatenblatt