search
menu Navigation
Drei Verhaltensmodelle – Aktivität

Systems Engineering

Drei Verhaltensmodelle – Aktivität

18. Februar 2022

In den UML- und SysML-Modellen meiner Kunden sehe ich oft merkwürdige Konstrukte in den Verhaltens­diagrammen. Nicht selten kommt das von exzentrischen Tool­eigenheiten. So gibt es in Rhapsody „zustandsbasierte Aktivitäts­diagramme“ und in der Enterprise Architect Hilfe wird die Verbindung von Sendeaktionen mit Signal­empfangs­aktionen empfohlen. Vielfach fehlt aber auch ein Überblick über die Unterschiede und Gemeinsamkeiten der drei in der UML/SysML1 definierten Verhaltens­elemente Aktivität, Zustandsmaschine und Interaktion 2. Diesen Überblick will ich mit diesem Post schaffen.

Verhaltensmodellierung

Die drei Elemente beschreiben Verhalten auf sehr unterschiedliche Weise. Jede Beschreibung hat ein komplett anderes Metamodell. Das ist zu bedauern, bedeutet es doch, dass man nicht so einfach erkennen kann, wenn zwei Diagramme im Grunde das gleiche Verhalten beschreiben. Die zukünftige SysML 2 wird das besser machen und führt alle drei Darstellungen auf ein und das selbe Metamodell zurück. Bis dahin dauert es aber noch und ganz ohne Gemeinsamkeiten sind ja auch die Modelle in der UML 2/SysML 1 nicht. Alle können zum Beispiel die gleichen Signale und Operationen referenzieren. Auch können Zustände in Aktivitäts­diagrammen und Aktivitäten in Zustands­diagrammen vorkommen und beide Elemente in Interaktions­diagrammen. Wenn man aber eine Beschreibungs­form in eine andere übersetzt, ändert sich nicht nur die Darstellung, sondern auch das Modell.

Mit diesem Blogpost starte ich eine Serie von drei Beiträgen, in denen ich jeweils ein einfaches Beispiel eines Verhaltens in die zwei anderen Formen übersetze. Den Anfang mache ich mit dem Aktivitäts­diagramm.

Ein einfaches Aktivitätsdiagramm

Nehmen wir ein denkbar einfaches Aktivitäts­diagramm mit drei Aktionen, von denen nacheinander die drei Aktivitäten A, B und C aufgerufen werden:

Die Zustandsmaschine verhält sich genau gleich. Die drei Aktivitäten sind das Entry-Verhalten dreier Zustände, die durch Transitionen verbunden sind, die durch den Abschluss des jeweiligen Zustands­verhaltens ausgelöst werden.
Etwas überraschender dürfte die Darstellung als Sequenz­diagramm sein: Die kleinen grünen Kästchen sind Verhaltens­ausführungs­spezifikationen, hier mit den drei ausgeführten Aktivitäten beschriftet. Diese Notation wird meines Wissens von keinem Tool unterstützt, obwohl das die von der UML vorgesehene Darstellung ist. Immerhin konnte ich die Aktivitäten im Modell referenzieren. Bei anderen Tools ist das nicht unbedingt möglich. Gut, man braucht es auch selten, weil man in einem Interaktions­diagramm normalerweise eben Interaktionen darstellen möchte und nicht die Abfolge von internen Schritten.

Mit Aufruf von Operationen

Das gezeigte Beispiel ist etwas simpel gestrickt, denn meist werden Aktivitäten nicht direkt aufgerufen. Stattdessen werden normalerweise Operationen aufgerufen, die ihrerseits eine Aktivität als Methode haben. Das sieht dann im Klassen­diagramm so wie rechts dargestellt aus.

Und die Verhaltensdiagramme sehen so aus:

Im Aktivitätsdiagramm sind jetzt Operations­aufruf­aktionen modelliert. Da sie keine eigene Notation haben, kann man sie nur daran erkennen, dass sie mit dem Namen einer Operation beschriftet sind.

Das Verhalten in der Zustandsmaschine hatte ich oben mit Aktivitäten beschrieben. Hier wähle ich opakes Verhalten. Dessen Definition liegt außerhalb der UML, daher „opak“, und dafür kann eine beliebige textuelle Notation verwendet werden. Im Beispiel ist es Alf3. Der Alf-Text kann dann an Stelle des Namens des Verhaltens angezeigt werden.

Das Sequenzdiagramm zeigt endlich Nachrichten­austausch, wenn auch nur mit self. Wie oben habe ich auch die Aktivitäten notiert. Das scheint redundant zum Klassen­diagramm zu sein, wo ja schon Operationen und Aktivitäten verknüpft sind. Ein Sequenz­diagramm definiert aber keine Kausalität. Wenn dort also steht, auf den Aufruf von opA() folge die Ausführung von A, dann kann das auch reiner Zufall sein.

Mit Kontrollknoten

Zu guter Letzt noch ein etwas komplizierteres Diagramm.

Man sieht gut, dass für diesen Sachverhalt das Aktivitäts­diagramm die kompakteste Darstellung anbietet. Vor allem wird das Zustands­diagramm schnell an Grenzen stoßen, wenn die Kontrollknoten nicht so schön symmetrisch eingesetzt werden wie hier. Damit würde auch das Sequenz­diagramm seine Schwierigkeiten haben, aber eigentlich ist es jetzt schon bei diesem kurzen Ablauf unübersichtlich.

Im nächsten Beitrag wird es um Zustandsdiagramme gehen.

 

 


1) UML: Unified Modeling Language (www.omg.org/spec/UML), SysML: Systems Modeling Language (www.omg.org/spec/SysML)
2) Es gibt noch drei weitere Verhaltenselemente: Protokollzustandsmaschine, opakes Verhalten und Funktionsverhalten. Die letzteren sind aber nur Platzhalter für außerhalb der UML definiertes Verhalten und die Protokollzustandsmaschine definiert eigentlich kein Verhalten, sondern Regeln für die Benutzung eines Objekts.

3) Alf: Action Language for Foundational UML (www.omg.org/spec/ALF)


  • Drei Verhaltensmodelle – Aktivität
  • Drei Verhaltensmodelle – Zustandsmaschine
  • Drei Verhaltensmodelle – Interaktion (demnächst)

[shariff services="xing|linkedin|whatsapp|info"]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Ich erkläre mich mit den Datenschutzhinweisen und der Datenschutzinformation.