Wann ist SysML korrekt, und wann nicht?

Holt Euch Popcorn, lehnt Euch zurück und genießt die Schlacht der Werkzeughersteller! Aber im Ernst, ich war doch überrascht bei LinkedIn eine „Friendly Competition“ zwischen Dassault (Cameo) und Sensmetry (Syside) mitzuerleben. Bei dem Schlagaustausch ging es um die Korrektheit der „Cheat Sheets“ zu SysML v2 der beiden Hersteller.

Die ernstere und wichtigere Frage ist: Was ist korrektes SysML v2. Und wann ist welche Art von Korrektheit wichtig?

Worum geht es?

Da SysML v2 im Moment ein heißes Thema ist, gibt es auch viel Bedarf an Hilfen für die Nutzung. Ein beliebtes Werkzeug sind Cheat Sheets, Also Spickzettel aus wenigen Seiten, die wichtige Aspekte prägnant und nutzerfreundlich zusammenfassen. Kürzlich veröffentlichte ich eine Liste aller mir bekannten SysML v2 Cheat Sheets.

Auf der Liste fehlte das Cheat Sheet von Dassault, das zu dem Zeitpunkt noch nicht fertig war. Das holte Dassault am 18. Oktober 2025 nach. In den Kommentaren meldete sich Juozas Vaicenavičius, CEO von Sensmetry zu Wort, um auf sein eigenes Cheat Sheet hinzuweisen, was ja völlig legitim ist. Die Antwort von Andrius Armonas war, ehrlich gesagt, „Rage Bait“: Unterstellung von Fehlern ohne konkrete Begründung:

Juozas Vaicenavicius I’m not sure who created it, but it contains a number of errors and, from a methodological standpoint, could mislead users. I wish the creator had some knowledge of SysML v2.

Andrius Armonas, CATIA Systems R&D Application Director, Product Manager at Dassault Systèmes

Dass Juozas das so nicht durchgehen lassen wollte, ist nachvollziehbar. Nach dem Motto: „Angriff ist die beste Verteidigung“, startete Juozas wiederum eine Bug-Hunting Challenge mit Belohnung:

Let’s help Dassault Systemes fix SysMLv2 textual notation mistakes in their recently released official cheat sheet!

Juozas Vaicenavicius, CEO & Co-Founder @ Sensmetry, PhD

An dieser Stelle möchte ich gar nicht kommentieren, welches Cheat Sheet richtig oder falsch ist, oder welches die meisten Fehler enthält. Wir dürfen nicht vergessen, dass LinkedIn Social Media ist: Dementsprechend sollten wir den Schlagabtausch auch nicht zu ernst sehen. Was mich freut: „There is no bad publicity“, und dieser Austausch hilft, die Sichtbarkeit von SysML v2 zu erhöhen.

Diesen Gedanken hat Udo Nink schön zusammengefasst:

Have fun in the tool battle and may it help to make all tools and examples better.

Udo Nink, Unlocking AI Use Cases in Product Development, informed by deep Architecture & Engineering experience.

Was ist richtig, was ist falsch?

Wie gesagt, an dieser Stelle möchte ich die Cheat Sheets gar nicht im Detail auseinandernehmen. Stattdessen möchte ich kurz reflektieren, was in diesem Kontext überhaupt relevant ist. Da sehe ich nämlich verschiedene Ebenen:

Syntaktische Korrektheit

Die Syntax beschreibt, wie ein Modell formal aufgebaut ist, also ob Klammern, Doppelpunkte, Bindungen und Schlüsselwörter korrekt verwendet werden. Oder ob im Diagramm Ecken rund sind, oder Linien durchgezogen oder gestrichelt. Hier gibt es keinen Interpretationsspielraum. Die SysML-v2-Spezifikation definiert die Syntax vollständig, sodass Werkzeuge diese regelbasiert prüfen können.

Grammatische Korrektheit

Die Grammatik betrifft, wie Modellelemente in Beziehung stehen dürfen. Sie ist enger mit der Metamodellstruktur verknüpft. Zum Beispiel darf ein „part usage“ nur innerhalb einer Blockdefinition auftreten. Auch das ist formal definiert und kann automatisiert geprüft werden, etwa beim Laden eines Modells.

Semantische Korrektheit

Semantik bedeutet, dass das Modell das ausdrückt, was beabsichtigt war. Ein Modell kann syntaktisch korrekt, aber semantisch unsinnig sein. Beispiel: Ein „value type“ mit Einheit „ampere“ für eine „length“. Hier ist kein Syntaxfehler, aber eine Verletzung der Bedeutung. Diese Ebene ist schwer automatisch zu prüfen, weil sie Fachwissen und Kontext erfordert. Wobei gerade hier KI punkten kann.

Methodische Korrektheit

Diese Ebene betrifft Vorgehensweisen, also wie SysML im Rahmen eines Entwicklungsprozesses angewendet wird. Hier geht es um „Best Practices“, Architekturprinzipien und Modellstrukturierung. Ein Modell kann formal korrekt sein, aber methodisch fragwürdig, etwa durch fehlende Traceability oder Vermischung von Anforderungen und Design. Das fällt eher in den Bereich Modellierungsrichtlinien oder interne Modellstandards.

Stilistische Korrektheit

Analog zu Lintern in der Softwareentwicklung lassen sich Werkzeuge einsetzen, die Modelle gegen definierte Stilregeln prüfen. Das kann von Textformatierung über einfache Namenskonventionen bis zu komplexen Heuristiken reichen (z. B. Warnung bei unbenannten Ports, ungenutzten Signalen oder zu tief verschachtelten Blöcken). Diese Prüfungen sind nicht Teil der Spezifikation, erhöhen aber Qualität und Konsistenz.

Cheat-Sheet-Vereinfachungen

Spickzettel müssen abstrahieren. Um Übersichtlichkeit zu wahren, werden Details weggelassen oder vereinfacht dargestellt. Das ist legitim, solange klar ist, dass Vereinfachungen existieren. Typische Vereinfachungen sind das Weglassen von Importen oder vereinfachte Beispiele ohne vollständige Bindungen. Entscheidend ist, dass sie beim Lernen helfen, nicht dass sie jedes syntaktische Detail abbilden.

Fazit

Wer über Korrektheit spricht, sollte also präzisieren, auf welcher Ebene. Denn was für den einen ein Fehler ist, ist für den anderen eine didaktisch sinnvolle Vereinfachung. Und ganz wichtig: Wer ohne Begründung dem anderen Fehler vorwirft, diskreditiert nicht den anderen, sondern sich selbst. Konstruktive Kritik erfordert Begründung, Kontext und den Willen zur Verbesserung. Alles andere ist bloß Click Bait bei Social Media.