Was ist ein Block in SysML? Warum ist das wichtig?

Es geht hier nicht um irgendeinen Block, sondern konkret um das Modellelement „Block“ der SysML. Dies ist das wichtigste strukturgebende Element der SysML.

Auf den ersten Blick wirkt ein Block banal – visuell ist es ein einfacher Kasten. Doch auch wenn wir konzeptionell am Whiteboard arbeiten, fangen wir oft mit Kästen und Strichen an. Warum also nicht gleich die korrekte Notation nutzen?

Das Diagramm ist nicht das Modell

Auch wenn wir oft mit dem Diagramm beginnen: Wir dürfen nicht vergessen, dass die visuelle Darstellung lediglich eine Sicht auf das Modell ist. Wenn ich hier von einem Block spreche, dann meine ich das, was dahinter steckt. Und nicht nur das, was wir auf dem Diagramm sehen.

Zurück zum Block. Ein Block ist eine modulare Einheit der Systembeschreibung. Der Block sammelt die Eigenschaften dieser Einheit. Dies können Eigenschaften wie Farbe oder Form sein, aber auch Verhalten.

Diese Flexibilität nutzen wir am Whiteboard, und sie bleibt auch in der SysML erhalten. Daher sind Blöcke in jeder Phase der Entwicklung nützlich.

Grenzen schaffen

Ein Block zieht eine klare Grenze zwischen „Innerhalb“ und „Außerhalb“. Das ist für viele Aktivitäten nützlich, zum Beispiel dem Verteilen von Verantwortlichkeiten („Ist die Stromversorgung Teil des Systems oder nicht?“).

Weiterhin ermöglicht es die Dekomposition des Systems und hilft, Komplexität in den Griff zu bekommen. Außerdem wird dadurch eine systematische und zuverlässige Wiederverwendung möglich.

Durch die Grenzen ergeben sich zwei Sichten. Die Sicht von außen ist die Black-Box-Ansicht. Diese Beschreibt das Verhalten des Systems, ohne dass wir das Innenleben verstehen können. Ein klassisches Beispiel ist ein Computer-Monitor. Dieser hat ein bestimmtes Verhalten (wenn ich ein Videosignal anschließe sehe ich ein Bild), aber wie dies funktioniert, interessiert uns nicht. Und die Black Box hat auch den Technologiewandel von Bildröhre zu LCD und LED überlebt.

Die Sicht von innen ist die Glass-Box-Ansicht, bei der wir sehen, wie das System funktioniert. Hier ist von Bedeutung, dass alles außerhalb des Blocks uns nicht wirklich interessiert. Um bei dem Monitor zu bleiben: Der White Box ist es egal, ob das Videosignal von einem Computer, einer Spielekonsole oder einem Blu-Ray-Player stammt.

Und nun etwas formaler

Auch wenn diese Konzepte einfach sind, so sind sie auch sehr mächtig. Allerdings skaliert ein informeller Ansatz weder am Whiteboard noch mit Powerpoint: Wenn von Hand ein paar Kästchen und Linien erstellt werden, dann gibt es keine klare Semantik. Das geht in einer kleinen Brainstorming-Session, aber spätestens eine Woche haben die Teilnehmer vergessen, ob die Linie eine Dekomposition darstellen soll oder ein gemeinsame Schnittstelle.

Die SysML löst dieses Dilemma, indem es diese Konzepte formalisiert. SysML ist eine Sprache, die es uns ermöglicht, diese Dinge sauber und ohne Widersprüche festzuhalten.

Die Kehrseite ist Kompliziertheit. Allein zwischen zwei Blöcken gibt es in der SysML 12 Beziehungen mit insgesamt 24 Variationen. Daher sollten wir uns unbedingt die eingesetzten Elemente einschränken. Welche das sind, hängt natürlich vom Anwendungsfall ab. Gute Ansätze gibt es in der Literatur. Bruce Douglas stellt zum Beispiel ein Minimales SysML-Profil in seinem Buch Agile Systems Engineering.

BDD: Arbeiten mit Black Box

Das Block Definition Diagram (BDD) zeigt die Blöcke, die es gibt. Also bspw. Computer und Monitor:

Die Linie ist eine Assoziation. Hier gibt es zahlreiche Variationen, auf die ich aber hier nicht weiter eingehen möchte. Wichtiger, dass es sich bei diesen Blöcken noch nicht um konkrete Instanzen handelt, sondern um Typen. Es gibt Computer und Monitore.

IBD: Arbeiten mit Glass Box

Wenn wir uns nun das System als Glass Box anschauen, sieht es anders aus: Denn nun geht es um konkrete Instanzen. Es gibt genau einen (unbenannten) Computer, und zwei Monitore, m1 und m2.

Weiterhin wurde hier auch schon mit einer Schnittstellenmodellierung begonnen: Wir sehen, dass für die Energiezufuhr Ports eingeführt wurden (die grünen Quadrate). Diese sind an allen Blöcken mit „e“ bezeichnet und haben den Typ „Energy“.

Dieses Beispiel ist definitiv noch nicht fertig ausgearbeitet. Zum Beispiel sollte konsequenterweise auch die Schnittstelle zwischen Computer und Monitoren mit Ports ausgearbeitet werden.

Modellexplosion

Was aus dem zweiten Bild ersichtlich wird: Wenn man „richtig formal“ modellieren möchte, dann explodiert das Modell sehr schnell: Es werden Schnittstellen eingeführt, diese werden typisiert, und plötzlich verlieren wir uns im Detail. Während das BDD noch intuitiv verständlich ist, müssen wir uns mit dem IDB schon in Ruhe auseinandersetzen, um es zu verstehen.

Das soll nicht heißen, dass so ein Modell nicht sinnvoll ist. Aber es ist wichtig, sich vorher im Klaren zu sein, ob sich der Modellierungsaufwand lohnt.

Daher möchte ich folgenden Rat geben:

• Das Ziel der Modellierung artikulieren
• Nicht mehr modellieren als für das Ziel notwendig
• Sicherstellen, dass alle Beteiligten das Modell auch lesen können, bzw. verstehen
• Wenn informell modelliert wird, trotzdem die korrekte Notation verwenden.

Gerade den letzten Punkt finde ich wichtig: Wenn wir bspw. am Whiteboard ein Modell besprechen, dann sollten wir den Doppelpunkt benutzen, wenn wir von konkreten Instanzen sprechen.

Fazit

Blöcke sind eines der wichtigsten Modellelemente der SysML. Wir sollten alle in der Lage sein, Blockdiagramme (IBDs und BDDs) zu lesen. Selbst beim informellen „modellieren“ am Whiteboard sollten wir die SysML-Notation nicht grob verletzen.

Und zuletzt: Blocke eignen sich hervorragend, um Strukturen zu beschreiben. Aber ohne eine Beschreibung des Verhaltens des Systems haben sie nur wenig Nutzen. Das wird Thema eines zukünftigen Artikels.