oose
Lernen am Strand? 19.08. - 30.08.24 bei oose am meer. 🏖️
Deutsch

Drei Verhaltensmodelle - Zustandsmaschine

Blog offline

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Dies ist der zweite Teil der dreiteiligen Reihe über die Verhaltensmodelle der UML/SysML. Ich betrachte jeweils ein einfaches Exemplar eines Diagramms und übersetze es in die anderen beiden Beschreibungsformen, die die UML/SysML bietet. Dadurch werden die Stärken und Schwächen der verschiedenen Formen sichtbar.

Hier sind Links zu den anderen Folgen:

Eine einfache Zustandsmaschine

Ich beginne wieder mit einem ziemlich einfachen Diagramm. Die Zustandsmaschine soll das Verhalten der Klasse Class1 beschreiben. Wie auch in der ersten Folge definiert diese Klasse drei Operationen, nur ist diesmal das Verhalten bei Aufruf der Operationen nicht fest verdrahtet, sondern je nach Zustand unterschiedlich. Im Zustand A wird bei Aufruf von op1() Act1 ausgeführt, aber im Zustand B Act2 und im Zustand C passiert einfach gar nichts - der Aufruf wird schlicht ignoriert. Die Übergänge zwischen den Zuständen werden durch op2() ausgelöst und im Zustand C kann man über op3() die Zustandsmaschine beenden.

Als Aktivität

Etwas Gleichwertiges in einem Aktivitätsdiagramm darzustellen sieht schon sehr viel komplizierter aus:

Die fünfeckigen Fähnchen sind Aufrufsempfangsaktionen (Accept Call Actions). Die Notation ist eher für Signalempfang bekannt, gilt aber auch für Aktionen die auf den Aufruf einer Operation warten. Eingebettet sind sie in einen strukturierten Aktivitätsknoten, da alle darin enthaltenen Aktionen freigeschaltet werden, sobald ein Token am eingehenden Kontrollfluss ankommt.

Eigentlich fehlen auch noch die Antwortaktionen. Nachdem nämlich der synchrone Aufruf einer Operation empfangen wurde, muss eine Antwort gesendet werden. Ich setze einfach voraus, dass die Operationen asynchron aufgerufen werden. Dann wird die Antwortnachricht eh ignoriert.

Eine besondere Herausforderung ist das für Zustandsmaschinen geltende Run-to-Completion Paradigma. Es besagt, dass alles Verhalten zu einem Abschluss gekommen sein muss, bevor die Zustandsmaschine das nächste Ereignis verarbeitet. Während op1() verarbeitet wird, kann also nicht auf op2() reagiert werden. Das wird dadurch erreicht, dass die Aktionen in unterbrechbaren Bereichen platziert sind und unterbrechende Kanten von ihnen ausgehen.

Übersichtlich ist was anderes. Es dürfte schwer werden, ein auch nur etwas komplizierteres Beispiel zu übersetzen.

Aufruf durch eine andere Aktivität

Wie sich die Zustände eines Objekts durch Aktionen eines anderen Objekts ändern, kann in einem Aktivitätsdiagramm ebenfalls dargestellt werden. Die Operationen der Klasse Class1 werden in diesem Beispiel von einer Aktivität der Klasse Class2 aufgerufen. Die Zustände, die sich in Class1 dadurch ergeben können an den Pins in eckigen Klammern notiert werden. Für diese Aktionen wird natürlich ein Objekt benötigt. Dieses wird durch die erste Aktion, eine CreateObjectAction, erstellt.

Als Interaktion

Auf den ersten Blick könnte man denken, dass hier Zustände angezeigt werden. Tatsächlich stehen diese Symbole für  Invarianten der Lebenslinie die einen Zustand nur referenzieren.

Das Sequenzdiagramm zeigt normalerweise nur einen möglichen Ablauf. Hier habe ich mal versucht, alle möglichen Abläufe zu zeigen. Für diese einfache Zustandsmaschine geht das tatsächlich. Allerdings kann man daraus nicht ableiten, dass alle anderen Abläufe ungültig wären. Schon deswegen sind Sequenzdiagramme weder geeignet noch dafür gedacht Verhalten vollständig zu spezifizieren. Abgesehen davon werden sie auch schnell unübersichtlich.

Vielleicht wundern Sie sich, dass ich bei den Loop- und Alt-Fragmenten keine Bedingungen angegeben habe. Das ist nämlich nicht vorgeschrieben und wäre hier sogar falsch. Die Bedingung müsste ja vom Sender der Nachrichten beachtet werden, der in dieser Interaktion aber außerhalb des Modellierungsfokus liegt.

Die von den Ausführungs­spezifikationen referenzierten Verhalten Act1 und Act2 habe ich in einer Art Call-Out-Notation dargestellt. Das ist zwar nicht Standard, sollte es aber sein. Im Zustand C wird op1() aufgerufen. Es folgt aber keine Ausführung, da der Aufruf ignoriert wird.

Neue Version 7.3.22: Ich habe das Sequenzdiagramm erweitert, so dass es nun alle möglichen Abläufe enthält. Ein weiteres Beispiel für Aktivitätsdiagramme zeigt die Visualisierung von Zuständen.

26.4.22: Ich habe ergänzt, dass Aufrufempfangsaktionen normalerweise eine Antwortaktion benötigen.

Mein Fazit: Konnte man das Aktivitätsdiagramm noch schemenhaft in den Übersetzungen wiedererkennen, ist das beim Zustandsdiagramm schon ziemlich verzerrt. Ich glaube, das Zustandsdiagramm ist einfach so gut in dem was es tut, dass ein anderes Diagramm einfach keine Chance hat.