Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

Modellierung & MBSEMuster

Spaghetti-Modellierung mit MBSE: So bitte nicht!

Es gibt viele Möglichkeiten, Fehler beim Einsatz von Model Based Systems Engineering (MBSE) zu machen. Eines der Probleme, die ich in der Praxis häufig sehe, bezeichne ich als Spaghetti-Modellierung.

Was ist MBSE?

Ich habe schon oft über MBSE geschrieben. Hier eine gute Definition von INCOSE:

Modellierungssprachen gibt es für bestimmte Domänen schon seit langem. Ein Schaltplan zum Beispiel ist ein Modell für elektronische Schaltungen. Es ist jedoch nur für eine bestimmte Domäne, nämlich die Elektronik, geeignet. Systemmodellierungssprachen sollten theoretisch alle Bereiche und alle Lebenszyklusphasen abdecken. Die derzeit beliebteste Systemmodellierungssprache ist SysML.

Warum MBSE?

Der Treiber für modellbasierte Systemtechnik ist die Komplexität der Systeme. Aufgrund der zunehmenden Verwendung von Software, der Vernetzung und Compliance ist die Komplexität der Systeme explodiert. MBSE ist ein Ansatz zur Beherrschung dieser Komplexität, z. B. durch eine systematische Zerlegung nach dem Black-Box/Glas-Box-Ansatz.

Wenn es richtig gemacht wird, hat MBSE das Potenzial, die Produktentwicklung drastisch zu verbessern. MBSE ist ein Wegbereiter für Änderungsmanagement, Automatisierung, Produktlinien und vieles mehr. Aber es hat seinen Preis, und der Einsatz von MBSE ist riskant, da er hohe Vorabinvestitionen erfordert. Und es geht oft schief…

Spaghetticode

Spaghetticode ist ein Begriff aus der Softwareentwicklung, der in den 1970er Jahren aufkam. Er bezog sich auf unstrukturierten und schwer zu wartenden Softwarecode. Leider finden wir auch heute noch überall jede Menge Spaghetticode. Jeder, der schon einmal an einem Legacy-Software-Projekt arbeiten musste, weiß das.

Spaghetticode hat viele Ursachen, darunter unbeständige Projektanforderungen, fehlende Regeln für den Programmierstil und Softwareingenieure mit unzureichenden Fähigkeiten oder Erfahrungen.

Spaghetti-Modellierung

Die Gründe, die zu Spaghetticode geführt haben, sind ähnlich wie die, die zu Spaghetti-Modellen führen. Obwohl es SysML schon seit über 20 Jahren gibt, ist diese Modellierungssprache noch nicht sehr weit verbreitet (zumindest verglichen mit Programmiersprachen). Unternehmen, die die Relevanz von Struktur nicht verstehen, lassen ihre Teams die Dinge selbst herausfinden, anstatt ihre Mitarbeiter angemessen zu schulen, was zu einem Mangel an Methodik und Einsatz von unerfahrenen Mitarbeitern führt.

Und Systemmodellierung ist mindestens genauso komplex/kompliziert wie Programmierung. Schauen wir uns doch mal den Einsatz von SysML mit Cameo genauer an:

  • SysML umfasst 9 Diagrammtypen, die auf viele verschiedene Arten verwendet (und missbraucht) werden können.
  • Der Cameo Systems Modeler verfügt über ca. 200 Menüeinträge, darunter viele Optionen zur Anpassung und Funktionalitäten für Simulationen und Analysen.
  • Das SysML-Metamodell definiert über 50 verschiedene Arten von Elementen, darunter Blöcke, Properties, Constraints, Activities und mehr.
  • Hinzu kommen etwa 20 vordefinierte Stereotypen wie „Block“, „Constraint“, „Requirement“, „Test Case“, „Problem“ usw. Hinzu kommen die Stereotypen, die wir selbst definieren.
  • Auch wenn MBSE immer maßgeschneidert und angepasst werden sollte, enthält ein typisches SysML-Diagramm bis zu 30 verschiedene Diagrammelemente.
  • Zurück zu den Werkzeugen: Cameo bietet über 100 anpassbare Parameter und Einstellungen für Diagramme, Modellelemente und Projektkonfigurationen.

Was können wir von der Softwareentwicklung lernen?

Auch wenn wir immer noch in der Software Spaghetticode finden, ist es wesentlich besser geworden. Warum?

  • Breite Verwendung von Bibliotheken: Niemand, der bei Verstand ist, würde eine verlinkte Liste von Grund auf neu programmieren, weil wir stattdessen eine Bibliothek verwenden können. Und der Code der Bibliotheken ist heutzutage von extrem hoher Qualität.
  • Verwendung einer etablierten Architektur: Es gibt eine begrenzte Anzahl von Software-„Typen“: Webanwendung, Steuergerät, mobile Anwendung, Ego-Shooter usw. Für jeden Anwendungstyp gibt es heutzutage eine kleine Anzahl von empfohlenen Architekturen. Die Werkzeuge und Bibliotheken erleichtern die Verwendung der Architektur.
  • Entwurfsmuster: Ähnlich wie bei der Architektur, nur eine Ebene tiefer, bieten etablierte Entwurfsmuster (Design Patterns) einen strukturierten Weg zur Lösung gängiger Programmierprobleme.
  • Neue Programmierparadigmen: Paradigmen wie objektorientierte Programmierung, Aspekte und dergleichen ermöglichen keine neue Funktionen; vielmehr unterstützen sie den Programmierer dabei, wartbaren Code zu schreiben.
  • Werkzeugunterstützung: Moderne Programmierwerkzeuge geben während der Programmierung Rückmeldung über die Codequalität. Das geht über Spaghetti-Code hinaus: Linting weist auf alle Arten von Problemen im Zusammenhang mit „Code Smell“ hin.
  • Automatisierte Tests: Das Schreiben automatisierter Tests, einschließlich Unit-Tests, Integrationstests und End-to-End-Tests, stellt sicher, dass Codeänderungen keine neuen Fehler einführen.
  • Code-Reviews und Pair Programming: Regelmäßige Code-Reviews und Pair Programming stellen sicher, dass der Code von mehreren Personen überprüft wird, um potenzielle Probleme frühzeitig zu erkennen und sicherzustellen, dass der Code den Best Practices entspricht und leicht verständlich ist.

Wie wir Spaghetti-Modellierung vermeiden können

Einige der Iden aus der Softwareentwicklung werden bereits auf die Systemmodellierung angewendet. Die Aspekte der Architektur und der Entwurfsmuster manifestieren sich bis zu einem gewissen Grad in den Methodiken.

Methodiken stellen Leitlinien für die Modellarchitektur, das Design und die besten Praktiken bei der Modellierung bereit. Beispiele hierfür sind MagicGrid von Dassault oder SYSMOD von Tim Weilkiens. Leider sind diese nicht sonderlich zugänglich. Sie sind als Bücher mit sehr begrenzter Toolunterstützung erhältlich. Es reicht nicht aus, nur das Buch zu lesen, man muss das Wissen auch anwenden, um sich damit vertraut zu machen, am besten in einem realen Projekt. Ohne einen erfahrenen Modellierer im Projekt besteht immer noch das Risiko einer Spaghetti-Modellierung.

Andere Paradigmen, wie Reviews und Pair Modeling, könnten ebenfalls sofort angewendet werden. Dies erfordert jedoch ein Budget. In der Programmierung hat es lange gedauert, die Entscheider davon zu überzeugen, dass diese Praktiken eine gute langfristige Investition sind. Bei MBSE haben wir immer noch Probleme, sie von vielen anderen, viel banaleren Ausgaben (wie Werkzeuge und Schulungen) zu überzeugen.

Größtes Problem: Zielgerichtete Modellierung

Das größte Problem, das ich in der Praxis sehe, ist das Fehlen eines klaren Ziels. Das unspezifische Ziel besteht in der Regel darin, Zeit zu sparen, die Qualität zu erhöhen und die Kosten für Änderungen und Wiederverwendung zu senken. Aber wie können wir das konkret erreichen? Bei der Softwareentwicklung ist dies recht einfach, da das wichtigste Ergebnis die funktionierende Software ist. Aber was ist das Ergebnis von MBSE?

MBSE ist mehrere Schritte vom eigentlichen Endprodukt entfernt, was es sehr viel schwieriger macht, die Nützlichkeit zu demonstrieren und zielführend zu gestalten. Der beste Ansatz besteht darin, spezifische, wertschöpfende Anwendungsfälle zu identifizieren. Dann müssen wir sicherstellen, dass das Modell diese Anwendungsfälle effektiv unterstützt. Praktischerweise hatte ich bereits vor langer Zeit eine Liste von 18 Ideen erstellt, die als Ausgangspunkt für die Identifizierung dieser Anwendungsfälle dienen können.

Nehmen wir zum Beispiel die Generierung von Dokumenten. Dieser Artikel befasst sich mit der Generierung von Dokumenten aus UML-Modellen, die durch die Verbesserung der Kommunikation mit den Stakeholdern einen erheblichen Mehrwert für das Team darstellten. Da der Zweck der Modellierung klar war, war es viel einfacher, die Werkzeuge auf die Unterstützung der betreffenden Aktivitäten zuzuschneiden.

Wie fange ich an?

Hier ist eine Checkliste, die Dir hilft, Spaghetti-Modellierung zu vermeiden. Der Wert hängt natürlich davon ab, wie weit Dein Team bereits mit der MBSE-Implementierung ist:

  • Verstehe den Zweck von MBSE in Deiner spezifischen Situation. Dein Team sollte einige übergeordnete Ziele haben, z. B. „für den Nachweis der Compliance bereit sein“. Dann identifizierst Du spezifische Anwendungsfälle, die dieses übergeordnete Ziel unterstützen. Idealerweise sind diese quantifizierbar, so dass Du den Erfolg messen kannst.
  • Mache Dich mit den Methodiken vertraut und wählen eine für Ihre Situation geeignete Methodik aus. Wähle die Elemente der Methodik, die für Deine Situation relevant sind.
  • Entscheide Dich für ein Werkzeug, wenn noch keines gesetzt ist. Es gibt zwar die „üblichen Verdächtigen“ (IBM Rhapsody, Dassault Cameo und Sparx Enterprise Architect), aber es gibt auch viele andere. Oft sind die Alternativen einfacher zu bedienen und günstiger, aber auch viel weniger leistungsfähig. Wähle mit Bedacht und behalte die langfristigen Ziele im Auge, denn ein Werkzeugwechsel ist aufwändig.
  • Hole Dir Hilfe von außen, wenn möglich. Auch in einem kompetenten Team ist es ratsam, jemanden von außen hinzuzuziehen, der Probleme erkennen kann, für die die Organisation „farbenblind“ ist.
  • Beziehe alle relevanten Stakeholder von Anfang an mit ein. Wir brauchen den Entscheider an Bord (MBSE ist teuer), das Team (es muss es benutzen), die IT-Abteilung des Unternehmens (sie muss das Modellierungstool unterstützen), und so weiter.

Ich helfe auch!

Und an dieser Stelle das obligatorisch „in eigener Sache“: Einführung von MBSE ist eine der Aktivitäten, die ich mit meinem Unternehmen Formal Mind GmbH die letzten Jahre immer häufiger umsetze. Interesse? Dann vereinbare ein unverbindliches Gespräch zum Kennenlernen.

Fazit

Model Based Systems Engineering ist eine Technologie mit hohem Risiko und hohem Nutzen. Aufgrund der erforderlichen hohen Anfangsinvestitionen schrecken viele Entscheidungsträger davor zurück. Risiken wie Spaghetti-Modellierung oder Elfenbeinturm-Modellierung sind real. Aber die Risiken zu verstehen ist der erste Schritt, um sie zu mindern. Verwende die Checkliste aus diesem Artikel, um so gut wie möglich vorbereitet zu sein.

Michael Jastram

Creator and Author of SE-Trends