Spaghetti-Modellierung mit MBSE

Es gibt viele Wege, Model Based Systems Engineering (MBSE) falsch zu machen. Eines der Probleme, das ich oft in diesem Bereich sehe, ist das, was ich Spaghetti-Modellierung nenne.

Was ist MBSE?

Ich mag die folgende Definition für Model Based Systems Engineering (MBSE) von INCOSE:

MBSE: A formalisiert Anwendung von Modellierung auf Unterstützung Systemanforderungen, Design, Analyse, Verifizierung und Validierung Anfang in der konzeptionellen Entwurfsphase und fortwährend während der Entwicklung und spätere Lebenszyklusphasen.

INCOSE

Anstatt Dokumente und Zeichnungen zu verwenden, nutzen wir eine formalere Modellierungssprache.

Modellierungssprachen gibt es für spezifische Domänen schon lange. Zum Beispiel ein Schaltplan ist ein Modell für elektronische Schaltungen. Es ist jedoch nur für einen bestimmten Bereich, die Elektronik, gedacht. Systemmodellierungssprachen sollten theoretisch alle Bereiche und alle Lebenszyklusphasen abdecken. Die derzeit beliebteste Systemmodellierungssprache ist SysML.

Elfenbeinturm-Modellierung mit MBSE

Warum MBSE?

Der Treiber für Model-Based Systems Engineering ist die Systemkomplexität. Durch den verstärkten Einsatz von Software, Vernetzung und strengere Regularien ist die Systemkomplexität explodiert. MBSE ist ein Ansatz, um diese Komplexität zu beherrschen, beispielsweise durch eine systematische Zerlegung mittels des Black-Box-Ansatz / Glasbox-Ansatz.

Wenn es richtig gemacht wird, hat MBSE das Potenzial, die Produktentwicklung drastisch zu verbessern. MBSE ist ein Wegbereiter für Change Management, Automatisierung, Produktlinien und vieles mehr. Aber es hat seinen Preis und die Einführung von MBSE ist riskant, da sie eine hohe Anfangsinvestition erfordert. Und oft geht es schief…

Spaghetti-Code

Spaghetti-Code ist ein Begriff aus der Softwareentwicklung, der in den 1970er Jahren aufkam. Er bezeichnete unstrukturierten und schwer zu wartenden Code. Bedauerlicherweise finden wir auch heute noch überall viel Spaghetticode. Jeder, der jemals an einem Legacy-Softwareprojekt arbeiten musste, kennt das.

Spaghetti-Code wird durch viele Dinge verursacht, darunter sich ändernde Projektanforderungen, fehlende Programmierstilregeln und Software-Ingenieure mit unzureichenden Fähigkeiten oder Erfahrungen.

Unbeständige Anforderungen, fehlende Stilregeln, mangelnde Erfahrung… kommt Ihnen das bekannt vor?

Spaghetti Modellierung

Die Gründe, die zu Spaghetti-Code führen, ähneln denen, die zu Spaghetti-Modellen führen. Obwohl SysML seit über 20 Jahren existiert, ist es nicht sehr weit verbreitet. Organisationen, die die Bedeutung von Struktur nicht verstehen, lassen Teams die Dinge selbst herausfinden, anstatt ihren Mitarbeitern eine entsprechende Schulung anzubieten, was zu mangelnder Methodik und unerfahrenen Praktikern führt.

Und Modellierung ist mindestens genauso komplex/kompliziert wie Programmierung. Denken Sie an die Verwendung von SysML mit Cameo:

• SysML umfasst 9 Diagrammtypen, die auf viele verschiedene Arten verwendet (und missbraucht) werden können
• Cameo Systems Modeler hat ungefähr 200 Menüeinträge, einschließlich verschiedener Optionen zur Anpassung und Funktionalitäten für Simulationen und Analysen.
• Das SysML-Metamodell definiert über 50 verschiedene Elementtypen, darunter Blöcke, Werteigenschaften, Constraints, Aktivitäten, Akteure und mehr.
• Kombinieren Sie dies mit rund 20 vordefinierten Stereotypen, wie z. B. «block», «constraint», «requirement», «testCase», «problem» usw. Plus jenen, die Sie selbst definieren.
• Obwohl MBSE immer angepasst und konfiguriert werden sollte, enthält ein typisches SysML-Diagramm in der Regel bis zu 30 verschiedene diagrammatische Elemente, wie z. B. Aktionen, Aktivitäten, Zustände, Blöcke, Ports, Lifelines, Fragmente und andere.
• Zurück zu den Werkzeugen: Cameo bietet über 100 anpassbare Parameter und Einstellungen für Diagramme, Modellelemente und Projektkonfigurationen.

Was können wir aus der Softwareentwicklung lernen?

Obwohl wir immer noch Spaghetti-Code antreffen, hat er sich stark, stark verbessert. Warum?

• Umfangreiche Nutzung von Bibliotheken: Niemand, der bei klarem Verstand ist, würde eine verkettete Liste von Grund auf neu programmieren, da wir stattdessen eine Bibliothek verwenden können. Und Programmbibliotheken sind heutzutage von extrem hoher Qualität.
• Unter Verwendung etablierter Architektur: Es gibt eine begrenzte Anzahl von Software-“Typen”: Webanwendung, eingebetteter Controller, mobile App, Ego-Shooter usw. Jede dieser Anwendungsarten hat heutzutage eine kleine Anzahl empfohlener Architekturen. Die Werkzeuge und Bibliotheken erleichtern die Verwendung der Architektur.
• Entwurfsmuster: Auf Architekturbasis, eine Ebene tiefer, bieten etablierte Entwurfsmuster eine strukturierte Möglichkeit, gängige Programmierprobleme zu lösen.
• Neue Programmierparadigmen Paradigmen wie objektorientierte Programmierung, Aspekte und dergleichen erlauben es nicht, etwas Neues zu programmieren. Vielmehr unterstützen sie den Programmierer dabei, wartbaren Code zu schreiben.

Das Verlassen der “GOTO”-Anweisung trug dazu bei, Spaghetti-Code drastisch zu reduzieren. Neue Paradigmen (Prozeduren, Bedingungen und Wiederholungsklauseln) boten Alternativen.

Eine Argumentation gegen die GO TO-Anweisung, Edsger W. Dijkstra

• Werkzeugunterstützung: Moderne Programmierwerkzeuge geben bereits während des Programmierens Feedback zur Code-Qualität. Das geht über Spaghetti-Code hinaus: Linting weist auf alle möglichen Probleme im Zusammenhang mit "Code Smells" hin.
• Automatisierte Tests: Das Schreiben von automatisierten Tests, einschließlich Unit-, Integrations- 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-Praktiken stellen sicher, dass mehrere Augen den Code überprüfen, potenzielle Probleme frühzeitig erkennen und sicherstellen, dass der Code Best Practices entspricht und leicht verständlich ist.

Wie man Spaghetti-Modellierung verhindert

Einige der Ideen aus der Softwareentwicklung werden bereits auf Systemmodellierung angewendet. Die Aspekte von Architektur und Entwurfsmuster manifestieren sich zu einem gewissen Grad in Methodologien.

Methoden liefern Anleitungen zu Modellarchitektur, Design und Best Practices beim Modellieren im Allgemeinen. Beispiele hierfür sind MagicGrid von Dassault oder SYSMOD von Tim Weilkiens. Leider sind diese nicht sehr zugänglich. Sie sind als Bücher mit sehr begrenzter Werkzeugunterstützung erhältlich. Das reine Lesen des Buches reicht nicht aus, man muss das Wissen auch anwenden, um sich damit vertraut zu machen, idealerweise in einem Realprojekt. Ohne einen erfahrenen Modellierer im Projekt besteht weiterhin die Gefahr des Spaghetti-Modellings.

Andere Paradigmen, wie Reviews und Pair Modeling, könnten ebenfalls sofort angewendet werden. Dies erfordert jedoch ein Budget. Es hat lange gedauert in der Programmierung, Entscheidungsträger davon zu überzeugen, dass diese Praktiken eine gute langfristige Investition sind. Mit MBSE haben wir immer noch Probleme, sie von vielen anderen, viel alltäglicheren Ausgaben (wie Werkzeugen und Schulungen) zu überzeugen.

Größtes Problem: Zielgerichtetes Modellieren

Das größte Problem, das ich in der Praxis sehe, ist das Fehlen eines spezifischen Zwecks. Der unspezifische Zweck ist normalerweise, 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 erreichen? spezifischIm Softwareentwicklungsbereich ist dies recht einfach, da das wichtigste Ergebnis lauffähige Software ist. Aber was ist die Ergebnislieferung von MBSE?

MBSE ist mehrere Schritte vom tatsächlichen Produkt entfernt, was es wesentlich schwieriger macht, den Nutzen zu demonstrieren und es zielgerichtet einzusetzen. 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 gibt es hier eine Liste von 18 Ideen die als Ausgangspunkt für die Identifizierung dieser Anwendungsfälle dienen können.

18 Dinge, die Sie mit Ihren Systemmodellen tun können

Zum Beispiel, betrachten Sie die Dokumentengenerierung. Sie können lesen dieser Artikel über Dokumentengenerierung aus UML-Modellen das dem Team einen erheblichen Mehrwert brachte, indem es die Kommunikation mit den Stakeholdern verbesserte. Ein klar definiertes Ziel des Modellings erleichterte die Anpassung der Werkzeuge zur Unterstützung der betreffenden Aktivitäten erheblich.

Wie fange ich an?

Hier ist eine Checkliste, die Ihnen hilft, Spaghettimodellierung zu vermeiden. Ihre Erfahrungen können variieren, je nachdem, wie weit Sie mit Ihrer MBSE-Implementierung fortgeschritten sind:

• Verstehen Sie den Zweck von MBSE in Ihrer spezifischen Situation. Sie sollten einige übergeordnete Ziele haben, z. B. “Compliance-Bereitschaft”. Identifizieren Sie dann spezifische Anwendungsfälle, die dieses übergeordnete Ziel unterstützen. Idealerweise sind diese quantifizierbar, damit Sie den Erfolg messen können.
• Machen Sie sich mit den Methoden vertraut und wählen Sie eine, die für Ihre Situation geeignet ist. Wählen Sie die Elemente der Methodik aus, die für Ihre Situation relevant sind.
• Werkzeug auswählen, wenn noch keiner festgelegt wurde. Es gibt zwar die “üblichen Verdächtigen” (IBM Rhapsody, Dassault Cameo und Sparx Enterprise Architect), aber es gibt noch viele andere. Oftmals sind die Alternativen einfacher zu bedienen und günstiger, aber auch wesentlich weniger mächtig. Wählen Sie weise und behalten Sie Ihre langfristigen Ziele im Auge, da ein Werkzeugwechsel schwierig ist.
• Holen Sie sich externe Hilfe wenn möglich. Auch wenn Sie ein sehr kluges Team haben, ist es ratsam, jemanden von außen hinzuzuziehen, der Probleme erkennen kann, für die Ihre Organisation “farbenblind” ist.
• Alle relevanten Interessengruppen einbeziehen von Anfang an. Sie brauchen den Entscheidungsträger an Bord (MBSE ist teuer), Ihr Team (es muss es nutzen), die IT-Abteilung des Unternehmens (sie muss das Modellierungswerkzeug unterstützen) und so weiter.

Schlussfolgerung

Model-Based Systems Engineering ist eine risikoreiche, aber lohnende Technologie. Aufgrund der erforderlichen hohen Anfangsinvestitionen scheuen sich viele Entscheidungsträger davor. Risiken wie Spaghetti-Modellierung oder Elfenbeinturm-Modellierung sind real. Aber das Verständnis der Risiken ist der erste Schritt zur Minderung. Verwenden Sie die Checkliste aus diesem Artikel, um so gut wie möglich vorbereitet zu sein.