Allocation: Verhalten und Struktur in SysML verknüpfen
Zwei wesentliche Aspekte im MBSE sind das Modellieren von Verhalten und Struktur. Mit SysML wird die Struktur mit Blöcken modelliert und das Verhalten mit Aktivitäten. Allocation ist der Prozess, Verhalten und Struktur zu verknüpfen. Dazu ein kleines Beispiel.
Das Verhalten der Welt verändern
In der Regel sind bei der Entwicklung von Systemen daran interessiert, das Verhalten der Welt zu verändern. Es geht also um Funktionalität. Ein Ladegerät sorgt dafür, dass sich der Ladezustand des Smartphones erhöht. Das wäre ein einfacher Use Case: „Smartphone laden“.
Doch dieser Use Case findet nicht im luftleeren Raum statt. Daher brauchen wir zunächst einen Kontext, den wir mit SysML-Blöcken modellieren. Für dieses einfache Beispiel besteht unser Kontext aus Smartphone, Ladegerät und Steckdose (die Kabel lassen wir der Einfachheit weg).
Allocation: Anwendungsfall im Kontext betrachten
Auf der Ebene des Anwendungsfall läuft dieser im Kontext ab. Daher ist das unsere erste Allocation. Die anderen Blöcke unterstützen den Anwendungsfall, was wir über eine Assoziation ausdrücken können. Visuell können wir das in einem Use Case Diagram darstellen:
Bevor wir den Anwendungsfall „Smartphone laden“ weiter verfeinern, sollten wir allerdings den Ladekontext genauer definieren. Insbesondere haben die Blöcke standardisierte Schnittstellen (außer „User“), nämlich Schuko (Steckdose) und USB-C (Smartphone). Der Charger hat das Gegenstück zu beidem. Das können wir folgendermaßen im Kontextdigramm (idb) visualisieren:
Der Nutzer (User) ist zwar Teil des Kontext „Phone is Charging“, hat jedoch keine Schnittstellen, die wir explizit modellieren müssen.
Mit diesem Verständnis können wir nun den Use Case weiter in Aktivitäten herunterbrechen, die sich im Aktivitätsdiagramm als Aktionen manifestieren. Die Aktionen müssen jedoch mit einem strukturellen Element verknüpft werden. Das geschieht visuell über das Zuordnen zu einer „Swimlane“, wie es im folgenden Diagramm zu sehen ist:
Black-Box-Denken durch Allocation realisieren
Sinn und Zweck des bisherigen ist es, unser System in Bestandteile aufzubrechen, die wir unabhängig zueinander betrachten können. Mit anderen Worten, wir wollen, dass jeder Bestandteil als Black Box betrachtet werden kann. Eine Black Box hat zwei wichtige Eigenschaften: (1) Sie kann verbaut werden, ohne dass der Konsument etwas über die Implementierung wissen muss; und (2) Die Implementierung einer Black Box muss nichts über die Verwendung dieser im System wissen. Beides setzt voraus, dass sowohl des verbauende System und die Implementierung sich an die Schnittstellenspezifikation halten.
Durch die Allocation auf Swimlanes erkennen wir sowohl Schnittstellen bezüglich des Ablaufs (Control Flow) als auch von Strömen (Stream), die Material (einschließlich Energie) oder Information darstellen können. Jede Überschreitung einer Swimlane durch einen Pfeil repräsentiert so eine Schnittstelle.
Im konkreten Beispiel haben wir nun zum Beispiel die Aktivität „Laden durchführen“, die dem „Ladegerät“ zugeordnet ist. Wir können nun diese Aktivität weiter herunterbrechen, ohne etwas über den weiteren Kontext wissen zu müssen.
Das leuchtet ein: Unser Ladegerät kann nun alles Mögliche über jede beliebige Steckdose laden — solange die in Abb. 2 gezeigten Schnittstellen korrekt verbunden werden (Schuko und USB-C).
In Wirklichkeit ist es natürlich noch einen Tick komplizierter. Konkret müssen nicht nur die Schnittstellen passen, sondern auch nichtfunktionale Anforderungen erfüllt werden, wie bspw. das zur Verfügung stellen und Einhalten der maximale Leistung. Weiterhin können die Schnittstellen ebenfalls weiter verschachtelt werden, um mehr Detail festzuhalten. Abb. 4 zeigt beispielhaft, wie wir den Schuko-Port modellieren könnten:
Beliebig tief Allocation weiter betreiben
Wir haben eben gesehen, wie wir Verhalten und Struktur (Use Case und Kontext) über Allocation auf die nächsttiefere Ebene abgebildet haben. Dies können wir beliebig tief weiterbetreiben. Nützlich finde ich diesbezüglich Abb 5 aus dem MagicGrid Book of Knowledge:
Wie man sich denken kann, kann hier schnell die Anzahl der Modellelemente explodieren. Daher ist es wichtig, im Werkzeug skalierbare Strukturen für den Modellbaum anzulegen. Neben der Konvention im MagicGrid-Buch spricht auch das SYSMOD-Buch gute Empfehlungen aus.
Nur mit vernünftiger Methodik arbeiten!
Richtige Allocation ist kein Selbstzweck. In der Praxis hilft sie uns:
- Subsysteme voneinander zu entkoppeln
- Vollständigkeit der Subsystemspezifikationen sicherstellen
- Varianten- und Produktlinen ermöglichen
- … und vieles mehr
Das hier gezeigte ist nur ein einziger Aspekt der SysML-Modellierung. Um Allocation effektiv im MBSE zu nutzen, brauchen wir den entsprechenden Arbeitskontext (Werkzeug und Methodik).
Fazit
Allocation ist ein wichtiges Konzept im MBSE, um Strukturen und Verhalten zu verknüpfen. SysML stellt uns die Mittel für Allocation bereit. Jeder an MBSE interessierte sollte verstehen, wie Allocation funktioniert und warum diese wichtig ist.
