Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

MethodenMuster

SysML: Spaghettimodelle mit der richtigen Package-Struktur vermeiden

Es ist schon erstaunlich, wie schnell die Anzahl der Elemente in einem Systemmodell wächst. Daher ist es essentiell, diese von Anfang an richtig zu strukturieren. Sonst bekommen wir ganz schnell „Spaghettimodelle“. Damit sind Modelle gemeint, die wie ein Knäuel Spaghetti aussehen und dementsprechend schwer zu verstehen sind. Aber fast alle Modellierungssprachen, einschließlich SysML, geben uns die Möglichkeit die Modelle zu strukturieren. In SysML machen wir das mit der richtigen Package-Struktur.

Der Modellbaum

Vor zwei Wochen stellte ich ein einfaches SysML-Modell vor, dass das Zusammenspiel von Steckdose, Ladegerät, Kabel und Smartphone zeigte. Auf den ersten Blick ein kleines Modell, das aus nur ein paar Dutzend Modellelemente zu bestehen scheint. Doch der aufgeklappte Modellbaum ist erschreckend groß. Das liegt daran, dass auch die Teile, die das Modell zusammenhalten (Relationen, etc.) im Modellbaum erscheinen. Hier der Modellbaum, der hoffentlich korrekt eingebettet mit Scrollbar zu sehen ist:

Dieses Modell hatte ich mit Cameo/MagicDraw erstellt. Doch bei anderen Werkzeugen (Rhapsody, Enterprise Architect) sieht es ähnlich aus.

Warum wir Struktur brauchen

Wenn selbst ein so kleines Modell schon aus so vielen Elementen besteht, dann ist hoffentlich klar, warum wir eine gute Modellstruktur brauchen. Die richtige Struktur ermöglicht und verbessert Lesbarkeit, Verständnis, Pflege, Teamwork und vieles mehr.

In der SysML gibt es das Package-Element, mit dem wir strukturieren können. Ein Package ist im Prinzip nichts weiter als ein Ordner, der weitere Elemente enthalten kann. Packages können beliebig tief verschachtelt werden. Das Ganze hat viel Ähnlichkeit mit einem Ordner auf einem Dateisystem.

Doch die Package-Struktur ermöglicht nicht nur das Organisieren, sondern wirkt aktiv am Modellierungsprozess bei. Zum Beispiel nutzen wir oft Packages, um einen Scope vorzugeben. Wir könnten etwa eine Tabelle erstellen, die die Eigenschaften von Ports auflistet, die ein oder mehrere Ebenen tief im Package enthalten sind.

Vorsicht: Neben dem Package können auch andere Elemente rekursiv Kinder haben, zum Beispiel Blöcke. Allerdings ist der Freiheitsgrad von dem, was enthalten werden kann, beim Package am größten.

Auch andere Elementtypen erlauben das Anlegen von Kindern des selben Typs und damit beliebig tiefe Verschachtelungen. Außerdem gibt es viele Varianten.

Spaghetticode und Spaghettimodelle

Der Begriff Spaghetticode stammt aus der Programmierung und bezeichnet abwertend schlecht strukturierten Softwarecode. Spaghetticode funktioniert zwar in der Regel, kann aber überdurchschnittlich viele Bugs enthalten und ist schwer zu warten.

Dasselbe trifft auf Spaghettimodelle zu: Diese sind schlecht strukturiert, können überdurchschnittlich viele Fehler enthalten und sind schwer zu warten. Spaghetticode ist zumindest ein „Endprodukt“ und macht (hoffentlich) etwas Nützliches. Doch schlimmer ist es bei Spaghettimodellen, da diese ja ein Artefakt sind, das beim Erstellen des endgültigen Produkts helfen soll. Doch wenn es diese Tätigkeit nicht zuverlässig unterstützt, dann wird es ignoriert. Oder schlimmer, die darin enthaltenen Fehler können zu teurer Nacharbeit führen.

Mit einer bewährten Package-Struktur arbeiten

Zum Glück haben sich viele Experten schon Gedanken über dieses Problem gemacht und Vorschläge für die Package-Struktur gemacht. die unter SYSMOD veröffentlichte Struktur stammt von Tim Weilkiens. Eine kurze, wenn auch veraltete Einführung hat er in seinem Blog veröffentlicht. Wer SYSMOD nutzen möchte, sollte aber auf jeden Fall auf die aktuelle und wesentlich ausführlicher Dokumentierte Package-Struktur aus dem SYSMOD-Buch zurückgreifen.

Eine andere gute Package-Struktur ist im MagicGrid-Buch zu finden. Das oben verlinkte Beispiel des Ladegeräts nutzt die MagicGrid-Struktur.

Alle empfehlenswerte Strukturen haben gemeinsam, dass sie sich rekursiv verschachteln lassen, um konsistent die Ebenen der Entwicklung abzubilden.

Einschließung und Referenzen

Eine weitere Komplikation entsteht durch die Tatsache, dass es für Referenzen keine Vorgabe gibt, wo diese herkommen müssen. Das ist anders als bei der Einschließung (Containment), bei der Elemente fest zu einem übergeordneten gehören.

Dazu ein Beispiel. Im Folgenden ibd sehen wir rechts einen Teil des Modellbaums. Dort ist zu sehen, dass der Ladekontext vier Teile (Parts, P) enthält. Diese Parts haben keinen Namen (kein Text vor dem Doppelpunkt), sind jedoch typisiert. Die Typen sind Smartphon, Steckdose, Ladegerät und Nutzer.

Die Teile (Parts p) sind vom Ladekontext eingeschlossen, die Typen der Teile jedoch nicht.

Natürlich können wir in allen Werkzeugen relativ leicht nach den referenzierten Elementen suchen, um diese im Modellbaum zu finden. Doch eine gute Package-Struktur macht hier sinnvolle Vorgaben.

Fazit

In der Modellierung lauern viele Gefahren. Eine andere hatte ich schon vor einer Weile beschrieben, die Elfenbeinturm-Modellierung. Eine andere Gefahr sind die heute beschriebenen Spaghettimodelle. Diese Probleme können nur mit einer vernünftigen Methodik verhindert werden. Und eine gute Package-Struktur ist ein wichtiger Teil davon.

Photo by Julia Kadel on Unsplash

Michael Jastram

Creator and Author of SE-Trends