SysML v2: Ein Überblick auf vier Seiten für Praktiker

Die SysML v2 kann einschüchtern: Sie ist in mehreren Dokumenten spezifiziert, jedes davon weit über 500 Seiten lang. Zum Glück gibt es inzwischen eine Menge Hilfestellung. Diese möchte ich in diesem Artikel geben, indem ich auf die vier Aspekte der SysML eingehe, die für die praktische Arbeit notwendig sind. diese sind: (1) Das Metamodell; (2) Grundlagen der Modellierung; (3) Strukturen richtig erfassen; (4) Verhalten richtig erfassen.

Diese Inhalte gibt es übrigens auch in kompakter Form als 4-seitiges PDF, dass Du hier ohne Registrierung herunterladen kannst. Unter demselben Link kannst Du übrigens auch ein kostenloses Multifunktionstuch mit SysML v2-Aufdruck bestellen (Weihnachtsaktion).

Grafische Modellierung

Im folgenden fokussiere ich mich auf die grafische Modellierung, da es zu der textuellen Notation ja schon sehr viel gutes Material gibt. Außerdem benutze ich Screenshot vom 4-seitigen Cheat Sheet, das hier als PDF heruntergeladen werden kann.

Metamodell

SysML v2 basiert auf KerML, der Kernel Modeling Language. Eigentlich sollte es für Praktiker nicht notwendig sein, KerML zu verstehen, oder überhaupt zu kennen. Doch in der Praxis hilft es ein paar Dinge zu wissen:

KerML definiert die präzise Bedeutung der Sprache, was die SysML v2 zu einer sauber definierten, formalen Sprache mit einer klaren Semantik macht. In KerML (und damit auch in SysML v2) ist alles ein typisiertes Element, es keine „Sonderfälle“ wie in SysML v1. Elemente haben Typen, Eigenschaften und Beziehungen, die einheitlich funktionieren. SysML v2 nutzt viele KerML-Konzepte direkt, insbesondere Beziehungen wie specializes, subsets oder redefines.

Ein zweiter zentraler Aspekt ist die klare Trennung zwischen Definition und Usage. KerML erzwingt dieses Muster nicht explizit, aber es macht es erst sauber möglich. Definitionen beschreiben wiederverwendbare Typen, Usages deren konkrete Anwendung im Modellkontext. Dieses Prinzip zieht sich durch Struktur, Verhalten und Anforderungen und ist einer der Hauptgründe, warum SysML v2 deutlich robuster für Wiederverwendung, Variantenbildung und Skalierung ist als SysML v1.

Definition und Usage

Als erstes sollte jeder Modellierer verstehen, was Definition und Usage sind und wie diese eingesetzt werden. Eine Definition beschreibt einen wiederverwendbaren Typ, also das allgemeine Konzept eines Elements. Eine Usage ist die konkrete Verwendung dieses Typs im Modellkontext. Typen werden definiert, Instanzen oder kontextspezifische Ausprägungen werden genutzt. Das gilt für Strukturen, Verhalten, Anforderungen und sogar für Beziehungen selbst. In SysML v2 ist dieses Muster allgegenwärtig und bewusst explizit gemacht. Definitionen sind zwar optional, sie auszulassen ist aber nicht empfehlenswert.

Das gezeigte Bild fasst die wichtigsten Beziehungen: specialize beschreibt eine Vererbungsbeziehung zwischen Definitionen: Eine SubDef ist eine Spezialisierung einer allgemeineren Definition und erbt deren Eigenschaften. usage verbindet eine Usage mit ihrer Definition und beantwortet die Frage: „Von welchem Typ ist dieses konkrete Element?“ Auf Usage-Ebene kommen zwei weitere Beziehungen hinzu: subset bedeutet, dass eine Usage eine eingeschränkte Teilmenge einer anderen Usage darstellt, etwa bei Ports, Attributen oder Rollen. redefine geht einen Schritt weiter und ersetzt eine geerbte Eigenschaft bewusst durch eine neue, präzisere Bedeutung.

Zusammengenommen erklären diese vier Beziehungen, wie SysML v2 Konsistenz, Wiederverwendung und kontrollierte Spezialisierung sauber und nachvollziehbar modelliert.

Grundlagen der Modellierung

Es gibt zahllose Methodiken: SYSMOD, Harmony, MagicGrid, Arcadia und viele andere. Alle haben ihre Existenzberechtigung, manche setzen auch andere Modellierungssprachen ein, doch sie haben auch viel gemeinsam. Um diese Gemeinsamkeiten geht es bei dieser kurzen Einführung.

Unabhängig von der konkreten Methodik lassen sich MBSE-Ansätze auf wenige gemeinsame Grundlagen zurückführen. Im Kern arbeiten alle mit denselben fachlichen Quadranten: Anforderungen, Verhalten und Struktur. In SysML v2 werden diese klar durch Sprachelemente abgedeckt (siehe unten).

Zusätzlich trennen alle MBSE-Methodiken zwischen Problem- und Lösungsschicht. SysML v2 unterstützt diese Trennung explizit, ohne sie zu erzwingen. In der Problemschicht werden Bedürfnisse, Ziele und gewünschtes Verhalten beschrieben, typischerweise mit abstrakten Requirements, Use Cases und Black-Box-Verhalten. In der Lösungsschicht werden diese Elemente verfeinert und realisiert, etwa durch konkrete Parts, interne Strukturen, detaillierte Aktionen und Allokationen.

Die Verbindung zwischen den Schichten entsteht über Beziehungen wie refine, satisfy und allocate. Damit liefert SysML v2 kein Methodenvorschrift, aber ein konsistentes sprachliches Fundament, auf dem sich praktisch alle etablierten MBSE-Methodiken abbilden lassen.

Struktur

Eine skalierbare Struktur beginnt mit einer sauberen Projektorganisation. In SysML v2 werden Modelle über Namespaces und Packages gegliedert, die Besitzverhältnisse eindeutig festlegen. Der Modellbaum beschreibt dabei auch Ownership.

Bibliotheken ermöglichen dabei Wiederverwendung. Es gibt sowohl Standardbibliotheken und die Möglichkeit, eigene anzulegen. Auch eine einheitliche Namenskonventionen ist wichtig. Üblich ist CamelCase, mit Großschreibung für Definitionen und Kleinschreibung für Usages.

Zentrale Bausteine der Strukturmodellierung sind Occurrences und Parts. Eine Occurrence beschreibt ein konkretes Vorkommen eines Elements in Raum und Zeit und bildet damit die Grundlage vieler SysML-v2-Konzepte. Parts sind spezialisierte Items, die zusätzlich Verhalten ausführen können. Sie repräsentieren die strukturellen Bestandteile eines Systems, die wir hierarchisch verschachteln können.

Ports und Interfaces definieren schließlich die Systemgrenzen und Kopplungen. Ports beschreiben explizite Interaktionspunkte eines Parts und legen fest, welche Arten von Flüssen oder Nachrichten erlaubt sind. Interfaces spezialisieren Verbindungen zwischen Ports und stellen sicher, dass Interaktionen kompatibel sind. Damit unterstützen sie sauberes Black-Box- und Glass-Box-Modellieren.

Verhalten

Verhalten baut direkt auf der zuvor beschriebenen Struktur auf. Occurrences liefern den zeitlichen Kontext, in dem Verhalten stattfindet, Parts sind die Träger dieses Verhaltens. Eine Action ist immer an eine Occurrence gebunden und wird von einem Part ausgeführt, entweder direkt oder über die perform-Beziehung. Die explizite Kopplung verhindert abstrakte „Funktionswolken“ ohne Bezug zur Systemarchitektur.

Actions sind das wichtigste Sprachelement zur Beschreibung von Verhalten und erlauben das Modellieren von komplexen Abläufen. Kommunikation wird über Messages realisiert, die über Interfaces und Ports zwischen Parts ausgetauscht werden. Der Verhaltensmodellierung ist enorm mächtig, es ist aber leider auch oft eine Herausforderung, die Strukturen richtig hinzubekommen. Hier wünsche ich mir noch wesentlich mehr Unterstützung durch die Werkzeuge.

Cases beschreiben Verhalten aus einer übergeordneten, szenariobasierten Perspektive. Ein Case hat mindestens ein Subjekt, optional Akteure, Eingangsparameter und ein Ergebnis. Der bekannteste Spezialfall ist der Use Case, der typische Nutzungsszenarien in Verbindung mit Anforderungen beschreibt. Darüber hinaus gibt es Analysis Case und Validation Case, die gezielt technische Fragestellungen adressieren. Definition und Usage erlauben es, wiederverwendbare Cases zu definieren und sie in konkreten Systemkontexten zu instanziieren. Damit schlagen Cases die Brücke zwischen Anforderungen, Verhalten und Nachweisführung.

Anforderungen

In SysML v2 sind Requirements ebenfalls Occurrences, was sie zu vollwertigen Modellelementen macht. Eine Anforderung ist damit kein statischer Textblock mehr, sondern kann Attribute, Parameter und Beziehungen besitzen, die im Modell verarbeitet werden. Genau hier entsteht die Brücke zur Parametrisierung: Anforderungen können Werte enthalten, Constraints referenzieren oder selbst Berechnungen und Grenzwerte vorgeben, die später mit Entwurfsparametern abgeglichen werden. Dadurch lassen sich Anforderungen nicht nur formulieren, sondern auch quantitativ überprüfen, vergleichen und automatisiert auswerten.

Fazit

SysML v2 hat enormes Potential, hat aber auch eine steile Lernkurve. Es reicht nicht, die Modellelemente zu kennen. Wir müssen die Sprache auch methodisch korrekt einsetzen.

Wenn dieser Artikel für Dich nützlich ist, dann empfehle ich Dir, auch das 4-seitige Cheat Sheet herunterzuladen und ausgedruckt auf dem Schreibtisch bereitzuhalten. Und wenn Du einen anderen Fokus haben solltest, schau‘ dir die anderen SysML v2-Ressourcen an.