Den Überblick behalten: Die Vererbungshierarchie der SysML v2

Die SysML v2-Spec mit 691 Seiten ist nichts für schwache Nerven. Dennoch ist sie ein hervorragendes Nachschlagewerk. Doch als solches erkennt man bestimmte Zusammenhänge erst beim gründlicheren Durcharbeiten. Ein Aspekt hat mir enorm geholfen: Die Vererbungshierarchie der Typen. Zum Beispiel wissen viele, die mit SysML v2 arbeiten, dass ein Part ein spezialisierter Item ist. Doch war mir nicht klar dass ein Use Case indirekt auch eine Action ist. Und das zu verstehen ist nützlich.

Im folgenden erkläre ich, was wir sonst noch so aus der Vererbungshierarchie der SysML v2 lernen können. Und zwar in klarer Sprache.

Teaser: Ich arbeite mit SodiusWillert an einem 4-seitigen Cheat Sheet zu SysML v2, das noch dieses Jahr veröffentlicht wird. Darin wird es auch ein Diagramm geben, das die hier beschriebenen Konzepte visualisiert.

Erinnerung: Wofür soll SE-Trends in Deinem Namen spenden? Noch eine Woche bei LinkedIn abstimmen >>

KerML als Startpunkt: Behavior, Structure und Data Type

Viele Texte zu SysML v2 weisen auf die Bedeutung von Occurrence hin: Alles in SysML v2, womit wir täglich arbeiten, ist in der Tat eine Occurrence.

Was jedoch nicht offensichtlich ist: Manche Elemente der SysML v2 haben weitere Elternelement aus der KerML, der Kernel Modeling Language, auf der die SysML v2 basiert. Und diese Mehrfachvererbung ist aufschlussreich, denn sie macht die Intention der Elemente transparenter.

Konkret ist sind Part, Item und Port auch Spezialisierungen von Structure, was meiner Meinung nach besser ausdrückt, was wir damit machen, nämlich die Struktur unseres Systems zu beschreiben.

Das Gegenstück zu Structure in KerML ist dementsprechend Behavior, welches die Wurzel der Elemente ist, die Verhalten modellieren, wie Action, Calculation und Flow.

Zuletzt möchte ich noch Attributes erwähnen, die ebenfalls nicht von Occurrence abgeleitet sind, sondern Spezialisierungen vom KerML Data Type. Ebenso gibt es Spezialisierungen von AnnotatingElement, wie Metadata, Comment oder Documentation.

Die Grenze zwischen KerML und SysML v2

Das klärt hoffentlich, warum die Occurrence so eine wichtige Rolle in der SysML v2 spielt: Sie ist als Wurzelelement der Ankerpunkt der Sprache. Doch zum Verständnis hilft es, KerML mit einzubeziehen, auch wenn dies nicht unbedingt zu sehen ist.

Hier noch mal der Zusammenhang zwischen SysML v2 und KerML:

SysML v2 baut auf KerML auf. KerML liefert die grundlegenden Bausteine, mit denen man technische Systeme formal beschreiben kann. SysML v2 nutzt diese Elemente und setzt eine Schicht darüber, um damit die SysML v2-Modellierungssprache zu definieren. KerML ist also das Fundament, SysML v2 das darauf aufbauende Modelliersystem, das für die tägliche Arbeit gedacht ist.

Daher würden wir in der Praxis auch keine Behavior Usage in der SysML v2 in unser Modell mit aufnehmen. Es hilft aber trotzdem enorm, den Stammbaum der Elemente zu kennen.

Die Vererbungshierarchie der SysML v2 unter der Lupe

Nachdem wir nun geklärt haben, wie die Vererbung von KerML-Elementen sich auf die SysML v2 auswirkt, hier eine Liste von Bezhiehungen, die auf den ersten Blick überraschen und dann hoffentlich beim Modellieren helfen:

Ein Viewpoint ist ein Requirement, ist ein Constraint

Anforderungen spielen im Systems Engineering eine wichtige Rolle und sind dementsprechend mächtig in der SysML v2. Das bedeutet insbesondere, dass wir sie formalisiert können, um sie dann später besser in unser System einzubinden, als es mit textuellen Anforderungen möglich wäre.

Doch bemerkenswert finde ich, dass sie zu diesem Zweck eine Spezialisierung von Constraint sind. Ein Constraint ist eine Bedingung, die festlegt, was erlaubt ist und was nicht. Es definiert eine Regel oder Einschränkung, die immer gelten muss, damit etwas als korrekt zählt. In SysML v2 ist ein Constraint genau so eine Regel, nur formal beschrieben und direkt im Modell verankert. Es legt fest, welche Werte, Beziehungen oder Zustände zulässig sind, sodass das Modell konsistent bleibt und spätere Fehler vermieden werden.

Ebenso bemerkenswert ist es, dass ein Viewpoint auch eine Anforderung ist. Ein Viewpoint beschreibt, welche Elemente gezeigt werden sollen, wie sie gefiltert oder strukturiert werden und wozu die Sicht dient, damit unterschiedliche Stakeholder das System gezielt und konsistent beurteilen können.

Doch genau das ist ja die Natur einer Anforderung Wenn ein Viewpoint als spezialisiertes Requirement definiert ist, kann man ihn versionieren, prüfen, nachverfolgen und validieren wie jede andere Anforderung auch. Dadurch wird die geforderte Sicht nicht nur eine informelle Idee, sondern ein überprüfbarer Teil des Modells.

Ein Use Case ist eine Calculation

Ein Use Case in SysML v2 ist zunächst einmal ein Case, wobei es auch die Spezialisierungen Verification Case und Analysis Case gibt. Schon in der SysML v1 haben wir Use Cases ähnlich wie Activities behandelt, also Use Cases heruntergebrochen, indem wir sie als Activities modelliert haben. In SysML v2 gibt es nur noch Actions und es ist zunächst nicht überraschend, dass ein Use Case eine Action ist. Überraschend finde ich jedoch, dass diese Beziehung indirekt ist:

Denn ein Case ist eine Spezialisierung von Calculation, die wiederum eine Spezialisierung von Action ist. Und wie wir oben gesehen haben, ist eine Calculation (und Case) damit eine Spezialisierung vom KerML-Element Behavior, Action jedoch ist keine Spezialisierung von Calculation.

Die Spezialisierung von Case als Calculation ist sinnvoll, da das zentrale Merkmal einer Calculation die verpflichtende Bereitstellung eines Ergebnisses ist. Das triff auch auf Case zu. Diese Ergebnisorientierung ist notwendig, nicht nur beim Use Case: Ein Analysis Case muss ein Ergebnis über das Subjekt zurückgeben, ein Verification Case muss ein Urteil fällen.

Metadata ist ein Item

SysML v2 stellt verschiedene Methoden bereit, Elemente mit zusätzlicher Metadata zu versehen. Dies ist eine Spezialisierung von AnnotatingElement, aber gleichzeitig auch ein Item. Das bedeutet, dass ein Metadata-Element ist nicht nur eine lose Anmerkung, sondern ein vollwertiges Modellobjekt mit Identität, Typ, Beziehungen und Lebenszyklus ist. Wenn wir uns dessen bewusst sind, können wir viele nützliche Einsatzmöglichkeiten für Metadaten finden.

Verwirrend kann sein, dass Comment und Documentation ebenfalls Spezialisierungen von AnnotatingElement sind, aber nicht gleichzeitig Item spezialisieren. Daher ist Metadata wesentlich mächtiger als Comment, obwohl es sich als AnnotatingElement ähnlich verhält.

Eine Allocation ist ein Part

Eine Allocation wirkt auf den ersten Blick wie eine einfach Relation, wenn auch eine wichtige. Aber in SysML v2 ist sie jedoch ein echtes strukturelles Element, über Connection von Part vererbt. Das bedeutet, eine Allocation lässt sich nicht nur deklarieren, sondern auch aktiv ins Modell einbinden.

Dieser architektonische Ansatz erlaubt es Modellierern, die Allokation nicht nur als abstrakte Zuordnung zu deklarieren, sondern aktiv ins Modell einzubinden, zu verfeinern und eigene Features hinzufügen um genau zu beschreiben, wie die Zuordnung realisiert wird.

Fazit

Die Vererbungshierarchie von SysML v2 ist ein Fluch und ein Segen. Die Strukturen sind gut durchdacht, aber nicht immer leicht zu durchdringen. Hinzu kommt die Beziehung zu KerML. Ich hoffe, dieser Artikeln hat Euch geholfen, sich nicht im Detail zu verlieren, sondern das Große Ganze im Auge zu behalten.