In SysML v2 ist eine View kein Diagramm, das man von Hand zeichnet und pflegt. Sie ist eine Abfrage auf das Modell. Man schreibt einen Filter, richtet ihn auf einen Teil des Modells, und das Werkzeug rendert das Diagramm. Ändert sich das Modell, generiert man neu – und das Bild stimmt wieder. Schluss mit Diagrammen, die heimlich von der Wahrheit abweichen.
Das Problem: vererbte Bibliothekselemente
Der Haken zeigt sich beim ersten Rendern einer View. Man exponiert das System, klickt auf Generieren – und das Diagramm ist voller Kästen, die niemand modelliert hat: subparts, start, done und andere Features, die die Teile aus der SysML-Standardbibliothek erben (siehe Abb. 1). Die Lösung ist ein Filter, der das selbst Modellierte behält und das Geerbte verwirft. Dafür gibt es drei Wege, und welcher passt, hängt vom Werkzeug ab.
Abbildung 1: Automatische View-Generierung mit unerwünschten vererbten Elementen
Ansatz 1: CATIA Magic mit Bibliotheksfiltern
Cameo Systems Modeler (heute CATIA Magic) bringt fertige Filterdefinitionen mit. Man spezialisiert seine View-Definition von EssentialElementsFilter und NonStandardLibraryElementFilter – und das Bibliotheksrauschen verschwindet, ohne dass man eine einzige Filter-Expression schreibt. Das ist am saubersten zu lesen und die natürliche Wahl, wenn das Team in Cameo lebt. Der Preis ist die Portabilität: DassaultSystemesViews ist eine Hersteller-Bibliothek, dieses Modell rendert in einem anderen Werkzeug nicht gleich.
Abbildung 2: SysML-v2-Textnotation zur Erzeugung dynamischer Views in CATIA Magic
Ansatz 2: SysIDE mit dem Attribut depth
SysIDE ergänzt das Attribut depth, mit dem sich festlegen lässt, bis zu welcher Ebene Nachfahren in der View angezeigt werden. Weitere Details finden sich in der Dokumentation von SysIDE.
Abbildung 3: SysML-v2-Textnotation zur Erzeugung dynamischer Views in SysIDE
Quelle
Ansatz 3: Portabel mit not isLibraryElement
Wer ein Modell will, das sich über Werkzeuge hinweg gleich verhält, schreibt den Filter explizit mit isLibraryElement. Dieses Flag ist auf jedem Element wahr, das aus einem Standardbibliothekspaket geerbt wurde – not isLibraryElement behält also nur, was der Modellierer selbst erstellt hat. Die Form @SysML::PartUsage and not isLibraryElement ist die portable, über verschiedene Werkzeuge hinweg anwendbare Variante. Für ein Verschaltungsdiagramm statt eines Baums tauscht man Metaklasse und Render: @SysML::ConnectionUsage mit render Views::asInterconnectionDiagram.
Egal welcher Filter: Kombiniere den Metaklassen-Test immer mit not isLibraryElement. Diese eine vergessene Klausel ist die häufigste Ursache für „mein Diagramm hat Kästen, die ich nie modelliert habe“.
Wie die Generierung ausgelöst wird
Der Filter ist die halbe Miete. Den Rest erledigt die Generierung selbst: In Cameo/CATIA Magic per Rechtsklick auf die View und Generate Views. In SysIDE in VS Code aktualisiert sich das Diagramm live beim Speichern. Mit der Syside-CLI läuft es in der Pipeline für die Batch-Regenerierung – den voll qualifizierten View-Namen übergibt man mit -n. Dateiname und Format kommen aus den Attributen fileName und fileType. In CI verdrahtet liefert jeder Commit frische, korrekte Diagramme, ganz ohne manuelles Zeichnen.
Welchen Ansatz wählen?
Standardmäßig den portablen Filter not isLibraryElement: Er funktioniert in Cameo, ist nahe an dem, was SysIDE will, und hält das Modell herstellerneutral. Das Prinzip unter allen dreien ist dasselbe, das MBSE überhaupt lohnenswert macht: Das Modell ist die einzige Quelle der Wahrheit, und die Diagramme werden daraus generiert – nie umgekehrt.
Hast du ein Thema, über das wir schreiben sollen? Lass es uns wissen.
