MAS4SysML: Ein Multi-Agent-Framework für die Modellgenerierung von SysML v2 aus natürlicher Sprache

Summary

Dieses Protokoll präsentiert MAS4SysML, einen Multi-Agenten-Ansatz, der automatisch SysML v2-Code durch koordinierte Aufgabenteilung generiert, nur wenige Reparaturiterationen erfordert und die manuelle Modellierungszeit deutlich reduziert, während die Systemmodellierungseffizienz verbessert wird.

Abstract

Die automatische Generierung genauer SysML-Modelle aus natürlichen Sprachanforderungen kann die Einführung von Model-Based Systems Engineering (MBSE) in der Entwicklung komplexer Systeme erheblich beschleunigen. Allerdings erfüllt die Verwendung großer Sprachmodelle (LLMs) zur Generierung von Modellcode oft nicht die strengen syntaktischen Einschränkungen formaler Modellierungssprachen, und die konsequente Sicherstellung semantischer Ausrichtung zwischen generierten Modellen und Anforderungen bleibt eine Herausforderung. Um diese Herausforderungen zu adressieren, stellt dieses Paper MAS4SysML vor, ein Multi-Agenten-Kollaborationsframework für die SysML v2-Codegenerierung, das die syntaktische Korrektheit und die semantische Konsistenz unter begrenztem Reparaturbudget verbessert. Das Framework zerlegt eine Modellierungsaufgabe in hierarchische Unteraufgaben, formalisiert sie als strukturierte Aufgabenkarten und generiert Modellcode von unten nach oben. Während der Erstellung wird eine offizielle Validierungsumgebung für Syntaxdiagnostik verwendet; Nach Abschluss überprüft das Framework die semantische Konsistenz zwischen Code und Aufgabenkarten. Wenn Syntax- oder semantische Validierung fehlschlägt, repariert und validiert das Framework den Code iterativ innerhalb eines vordefinierten Reparaturbudgets, geleitet von diagnostischem Feedback, bis die Validierungskriterien erfüllt sind oder das Budget aufgebraucht ist. Um die vorgeschlagene Methode zu bewerten, erstellen wir einen SysML v2-Datensatz mit fünf Kernaufgabentypen – Anforderungen, Anwendungsfälle, Struktur, Parametrik und Zustandsautomaten – und führen vergleichende Experimente durch. Die Ergebnisse zeigen, dass MAS4SysML die durchschnittliche Syntaxfehlerrate auf 2,63 senkt, die semantische Ähnlichkeit auf 0,91 erhöht und bestehende Codegenerierungsmethoden insgesamt übertrifft.

Introduction

MBSE ist zu einer Schlüsselmethodik für Anforderungsanalyse, Systemarchitekturdesign und Verifikationsplanung bei der Entwicklung komplexer Geräte in Bereichen wie Luftfahrt und Luft- und Raumfahrt¹ geworden. Mit einheitlichen Modellierungssprachen wie SysML als Modellierungsrückgrat können Informationen – einschließlich Anforderungen, Struktur, Verhalten und Einschränkungen – zu einem kohärenten Modellrahmen organisiert werden, was die Prozessstruktur und die Effizienz interdisziplinärer Zusammenarbeit verbessert². Mit dem weiteren Wachstum der Systemskalierung steigt jedoch die Anzahl der zu entwickelnden Modelle entsprechend an, was zu einem anhaltenden Anstieg der Arbeitsbelastung manueller SysML-Modellierung führt. Darüber hinaus müssen Modellierer unter strengen syntaktischen und methodischen Einschränkungen arbeiten, die erhebliche Fachkenntnisse und starke Abstraktionsfähigkeiten erfordern. Diese Faktoren sind zu einem großen Engpass bei der technischen Einführung von MBSE³ geworden.

In den letzten Jahren haben LLMs starke Fähigkeiten im Verständnis natürlicher Sprache, strukturierter Informationsdarstellung und Codegenerierung gezeigt, was neue Möglichkeiten zur Automatisierung der MBSE-Modellierung von der natürlichen Sprache zum Modellcode⁴ eröffnet. Frühere Studien haben die direkte Generierung von SysML-Modellcode mit LLMs⁵ untersucht. Dennoch bleiben erhebliche Herausforderungen bestehen. Syntaktisch werden das Typsystem, die Scoping-Mechanismen und die Referenzsemantik von SysML durch strenge formale Einschränkungen gesteuert und oft komplexer als die von allgemeinen Programmiersprachen⁶. Semantisch können LLMs Verhaltenslogik, strukturelle Beziehungen und Schichtübergreifende Einschränkungen nicht vollständig erfassen, was zu fehlenden Relationen, logischen Inkonsistenzen oder unvollständigen Modellen⁷ führt. Diese Einschränkungen behindern die Zuverlässigkeit, Kontrollierbarkeit und Interpretierbarkeit direkter Generierungsansätze.

Um diese Herausforderungen zu adressieren, stellt dieses Paper MAS4SysML vor, ein SysML v2-Codegenerierungs-Framework mit vier Agentenrollen. Anstatt direkt auf die One-Shot-Generierung eines vollständigen Cross-View-Systemmodells abzuzielen, konzentriert sich diese Studie darauf, mehrere repräsentative SysML-v2-Modellierungsaufgaben zu generieren und iterativ zu reparieren. Angetrieben von Aufgabendekomposition und strukturierten Aufgabenkarten sowie durch Integration von Codegenerierung, Syntaxdiagnostik auf Werkzeugebene und semantischer Konsistenzverifikation, etabliert MAS4SysML einen geschlossenen Workflow für Generierung, Validierung und Reparatur. Dieses Design verbessert die syntaktische Korrektheit, semantische Konsistenz und strukturelle Vollständigkeit des generierten Codes unter einem begrenzten Reparaturbudget.

Die Hauptbeiträge werden wie folgt zusammengefasst: (1) MAS4SysML-Framework. Wir schlagen MAS4SysML vor, ein multiagentenbasiertes, LLM-gesteuertes Framework, das eine End-to-End-Generierung von natürlichen Sprachanforderungen bis hin zu ausführbarem SysML v2-Modellcode ermöglicht und einen praktischen Weg zur Senkung der Modellierungskosten und zur Verbesserung der Modellierungseffizienz bietet. (2) Aufgabenparsing und duale Validierung. Wir führen einen Mechanismus zur Parsing von Aufgabenstrukturbäumen und ein duales Validierungsschema (Syntax und Semantik) ein. Beim Aufgabenparsen werden Modellierungsziele hierarchisch zerlegt und in strukturierte Aufgabenkarten formalisiert. Für die Validierung nutzen Syntaxdiagnostiken eine offizielle Validierungsumgebung⁸ , um generierten Code zu überprüfen und reparaturorientierte Diagnosen zurückzugeben, während die semantische Validierung Schlüsselfelder auf den Aufgabenkarten als Referenzen verwendet, um die Gesamtkonsistenz zwischen dem generierten Modell und den Modellierungszielen zu bewerten. (3) Experimentelle Bewertung. Wir führen vergleichende Experimente unter Verwendung der Syntaxfehlerrate und des semantischen Konsistenzscores als primäre Kennzahlen durch. Die Ergebnisse zeigen, dass MAS4SysML die durchschnittliche Syntaxfehlerrate auf 2,63 senkt und die semantische Ähnlichkeit auf 0,91 erhöht, wodurch sie die Basismethoden in Bezug auf Erzeugungsgenauigkeit und Automatisierung übertrifft.

Protocol

Der Code-Generierungsprozess des MAS4SysML-Frameworks ist in Supplementary File 1 zusammengefasst. Es sollte beachtet werden, dass diese Studie nicht darauf abzielt, eine einmalige Generierung eines vollständigen Systemmodells aus natürlicher Sprache mit strikter Cross-View-Konsistenz zu erreichen, einschließlich Anforderungen, Struktur, Parametrik und Verhalten. Stattdessen konzentriert sich das Protokoll darauf, mehrere repräsentative Typen von SysML v2-View-Code zu erzeugen.

Phase I: Aufgabenanalyse
Der Workflow beginnt mit der Aufgabenparsing. Das System liefert dem Task Structure Generation Agent die Intention der natürlichen Sprachmodellierung, der einen Aufgabenkartensatz ausgibt. Um sicherzustellen, dass nachfolgende Generationen ausführbar und reproduzierbar sind, muss jede Task-Karte mindestens (i) eine Aufgabenkennung, (ii) Abhängigkeitsbeziehungen und (iii) wichtige Modellierungsinformationen zur Validierung enthalten, wie das Modellierungsziel, Einschränkungen/Randbedingungen, Parameterslots und Instanziationswerte sowie die erwarteten Ausgaben. Diese Stufe liefert task_card_set aus, die als einheitliche Grundlage für die spätere Modellcode-Erstellung dient.

Phase II: Iterative Codegenerierung
Bei der iterativen Generierung initialisiert das System den Codekontext prev_code in einen leeren Zustand und erzeugt für jede Aufgabenkarte nacheinander Code gemäß einer durch die Abhängigkeitsfelder bestimmten Reihenfolge. Für jede Aufgabenkarte nimmt der Code Generation Agent die aktuelle Aufgabenkarte und den kontextuellen Code als Eingabe, um candidate_code zu erzeugen, und ruft dann sofort das Syntax-Validierungsmodul zur Überprüfung auf. Das Modul validiert den Code mit der offiziellen SysML v2-Validierungsumgebung und liefert Diagnoseergebnisse. Wenn die Validierung erfolgreich ist, wird die candidate_code verwendet, um prev_code zu aktualisieren und die nachfolgende Generation zu unterstützen. Wenn die Validierung fehlschlägt, wird der Code Repair Agent ausgelöst und führt minimale, gezielte Bearbeitungen vor, die von den zurückgegebenen Diagnosen geleitet werden, woraufhin der reparierte Code zur erneuten Validierung erneut eingereicht wird. Diese Reparatur-Revalidierungsschleife ist durch das maximale Reparaturbudget K_maximal begrenzt. Wenn die Validierung innerhalb des Budgets erfolgreich ist, aktualisiert die übergebende Version prev_code; ansonsten protokolliert das System nach K_{Max-Versuchen} den Fehler und fährt mit der anschließenden Task-Card-Generierung mit der zuletzt reparierten Version prev_code fort, um Blockade des Workflows zu vermeiden und gleichzeitig die kontextuelle Kontinuität beizubehalten.

Phase III: Semantische Validierung
Nachdem der Code für alle Aufgabenkarten generiert wurde, fährt der Workflow zur semantischen Validierung über. Der Semantic Validation Agent bewertet die Konsistenz zwischen dem finalen Code und der Modellierungsintention anhand von Schlüsselfeldern in task_card_set als Referenzen und liefert die semantischen Validierungsergebnisse aus. Wenn die Validierung erfolgreich ist, wird prev_code als endgültiger SysML v2-Modellcode akzeptiert. Andernfalls erzeugt das System einen semantischen Abweichungsbericht, der nicht erfüllte Aufgabenkartenfelder und den erforderlichen Revisionsbereich identifiziert. Der Code Repair Agent überarbeitet dann den Code entsprechend und gibt den überarbeiteten Modellcode als Endergebnis aus.

Modellarchitektur und Methodik
Modellarchitektur
Das MAS4SysML-Framework, dargestellt in Abbildung 1, besteht aus vier kollaborativen Agenten: dem Agenten zur Generierung von Aufgabenstrukturen, dem Code-Generierungsagenten, dem Code-Reparaturagenten und dem semantischen Validierungsagenten. Die entsprechenden Prompt-Vorlagen sind in Abbildung 2 dargestellt.

Der Task Structure Generation Agent führt eine semantische Analyse der Input-Modellierungsintention durch und erzeugt ausführbare, strukturierte Task-Karten. Zunächst wendet es einen hierarchischen Aufgabendekompositionsmechanismus an (siehe hierarchische Aufgabendekompositionsmechanismus), um das Gesamtmodellierungsziel in Aufgabenknoten mit wohldefinierten semantischen Grenzen zu zerlegen, und erstellt dann für jeden Knoten eine strukturierte Aufgabenkarte. Anschließend werden die Task-Karten nach ihren Modellierungsabhängigkeitsfeldern geordnet, um sicherzustellen, dass die Ausführungssequenz mit der endgültigen Codestruktur übereinstimmt, wodurch die Grundlage für die Bottom-up-Codegenerierung mit dem globalen Modellierungsziel gelegt wird.

Der Code-Generierungsagent erzeugt progressiv SysML-v2-konformen Modellcode entsprechend den Modellabhängigkeiten. Aufbauend auf den von den übergeordneten Aufgaben erzeugten Codeartefakte führt der Agent die entsprechenden Codegenerierungsoperationen basierend auf den Anforderungen jeder Aufgabenkarte durch und ermöglicht so einen schrittweisen Konstruktionsprozess – von lokalen Komponenten bis zum vollständigen Modell.

Der Code-Reparaturagent korrigiert Fehler im generierten Code basierend auf den Ergebnissen des Syntax-Validierungsmoduls (siehe Syntax-Validierungsmodul) und den semantischen Validierungsergebnissen. Für die syntaktische Reparatur nutzt sie den Fehlertyp, die Position und die vom Syntaxvalidator zurückgegebenen Fehlertyp, Position und Kontextinformationen, um gezielte Reparaturstrategien zu synthetisieren und korrigierten Code zu generieren. Für die semantische Reparatur passt es strukturelle und logische Beziehungen entsprechend den semantischen Validierungsergebnissen an und gewährleistet so semantische Konsistenz und strukturelle Vollständigkeit im endgültigen Modell.

Der semantische Validierungsagent bewertet die semantische Konsistenz zwischen dem vollständig generierten Code und den Aufgabenkarten mithilfe eines dedizierten semantischen Validierungsmechanismus (siehe semantischer Validierungsmechanismus). Durch quantitative Bewertung wird sichergestellt, dass der generierte Code die ursprüngliche Modellierungsintention genau widerspiegelt und so eine präzise Ausrichtung zwischen dem Modellcode und den spezifizierten Anforderungen erreicht.

Mechanismus der Zerlegung hierarchischer Aufgaben
Als formale Modellierungssprache für komplexe Systeme zeichnet sich SysML v2 durch eng gekoppelte Syntax, tief verschachtelte hierarchische Strukturen und semantische Einschränkungen über mehrere Ebenen aus. Beispielsweise kann ein Systemstrukturblock mehrere Unterteile, Attribute und Ports enthalten, während gleichzeitig Leistungs- oder Verhaltensanforderungen durch Ebenenübergreifende Einschränkungen ausgedrückt werden. Diese Strukturen und Einschränkungen schaffen Top-down-Strukturabhängigkeiten und semantische Rückkopplungsbeziehungen von unten nach oben. Mit einem flachen, einmaligen Generierungsansatz wird es schwierig, solche hierarchischen Abhängigkeiten genau abzubilden, was oft zu fehlenden Relationen, semantischen Inkonsistenzen oder dem Verlust von Constraint-Informationen führt.

Um diese Herausforderung zu bewältigen, entwickeln wir eine aufgabenbaumbasierte Methode zur Modellierungsabsicht, die hierarchisch Anforderungen an die natürliche Sprachmodellierung zerlegt. Wie in Abbildung 3 dargestellt, werden komplexe Modellierungsziele in strukturierte und nachverfolgbare Aufgabenknoten zerlegt, sodass das System die Modellierungssemantik von oben interpretieren und Abhängigkeitsbeziehungen identifizieren kann. Konkret nutzt der Task Structure Generation Agent, wenn er die Benutzereingaben erhält, zunächst die semantischen Parsing-Fähigkeiten von LLMs, um zentrale Modellierungsziele, Schlüsselentitäten und deren Abhängigkeiten zu identifizieren. Anschließend zerlegt es das oberste Ziel rekursiv in semantisch unabhängige Unteraufgaben und verfeinert diese weiter zu atomaren Aufgaben, die direkt auf SysML v2-Modellierungsoperationen abgebildet werden können, wodurch letztlich ein vollständiger Aufgabenstrukturbaum entsteht. Nachdem der Aufgabenbaum erstellt wurde, generiert der Agent für jeden Aufgabenknoten eine strukturierte Aufgabenkarte basierend auf einer vordefinierten Vorlage. Das Format der Aufgabenkarte ist wie folgt definiert:

TC = {id,O,N,K,P,V,C,D} (1)

Wobei id die eindeutige Identifikatorin des Aufgabenknotens ist, O das Aufgabenziel, N die natürliche Sprachbeschreibung der Aufgabe ist, bezeichnet K die zentralen semantischen Elemente von SysML v2, die an der Aufgabe beteiligt sein können, hauptsächlich einschließlich Requirement Def/Requirement, Part Def/Part, Port Def/Port, Item Def, Attribute Def/Attribut und State/Transition. Beziehungen zwischen diesen Elementen werden hauptsächlich durch Connect (strukturelle Verbindungen), Ein-/Ausgabe-Elemente an Ports (Informations-/Materialflüsse) und Trigger/Guard-Bedingungen von Zustandsmaschinenübergängen (z. B. Befehle, Gesundheitsstatus und Schwellenwertbedingungen), C als semantische Regeln oder Randbedingungen und P als parametrisierbare Slots innerhalb der Aufgabe wie Attributnamen, Datentypen oder zusammengesetzte Typen ausgedrückt, V als instanziierte Werte für jeden Slot und D als Modellierungsabhängigkeiten zwischen Aufgaben, wobei depend_on die erforderlichen Ausgaben anderer Aufgaben vor der Generierung des aktuellen Aufgabencodes angibt, liefert die nach Abschluss der Aufgabe erzeugten Ausgaben und konsum externe Eingaben für die Aufgabe darstellt.

Syntax-Validierungsmodul
Ein Syntax-Validierungsmodul wird auf Basis der Pilotimplementierung SysML v2 erstellt. Durch das Aufrufen seiner Parser- und Validator-Schnittstellen parst und überprüft das Modul die syntaktische Korrektheit des generierten SysML v2-Modellcodes. Die Validierungskriterien des Moduls leiten sich hauptsächlich aus der SysML v2-Sprachspezifikation sowie den Grammatikregeln, Scope-Resolution-Regeln und zugehörigen Constraint-Checking-Mechanismen ab, die im Pilot-Tool implementiert wurden. Konkret prüft die Validierung, ob Elementdeklarationen wohlgeformt sind, ob Blockstrukturen vollständig sind, ob Typannotationen gültig sind, ob Namen und Referenzen erfolgreich aufgelöst werden können und ob Modellierungskonstrukte wie Ports, Verbindungen, Zustände und Übergänge den Anforderungen der Sprache entsprechen.

Nachdem der Codegenerierungsagent das Codefragment für die aktuelle Aufgabe erzeugt hat, wird die Ausgabe an das Syntax-Validierungsmodul weitergeleitet, wo das Validierungsskript den Code analysiert und die Ergebnisse in Form strukturierter Diagnoseinformationen zurückgibt. Die Validierungsergebnisse werden wie folgt berichtet:

e₁ = (Typ_{i,POS i,MSG i}) (2)

wobei e_i die Liste der erkannten Probleme für die aktuelle Modellierungsaufgabe bezeichnet, wobei jeder Eintrag den Fehlertyp _{Typ i}, die Fehlerposition pos_i und die Diagnosemeldung msg_i enthält.

Wenn beispielsweise der generierte Code einen Syntaxfehler wie "ein Attribut wird nicht durch eine Attributdefinition getypt" enthält, liefert das Validierungsmodul folgende diagnostische Nachricht:

'type' : 'error'
'message' : 'FEHLER: Ein Attribut muss gemäß Attributdefinition getippt werden.' (3)
'Position': 'Zeile 7 Spalte: 3'

Wenn das Validierungsergebnis e_i ≠ 0 , werden die gesammelten Fehlerinformationen e_i zur weiteren Korrektur an den Code-Reparaturagent weitergeleitet. Daher ist der Code-Reparaturprozess kein uneingeschränktes Modifikationsverfahren, sondern eine gezielte Überarbeitung, die von den expliziten diagnostischen Informationen des Parsers und Validators geleitet wird.

Semantischer Validierungsmechanismus
Der semantische Validierungsmechanismus verwendet Schlüsselaufgabenkartenfelder, die explizite und nachverfolgbare Entsprechungen zum Modellcode aufweisen, als semantische Anker. Es bewertet die semantische Konsistenz auf Modellebene und liefert so explizite, umsetzbare Kriterien für die anschließende Modellreparatur. Konkret werden für jede Aufgabenkarte TC_i folgende Felder als wichtige semantische Referenzen verwendet: (i) das Modellierungsziel O_i, (ii) semantische Nebenbedingungen und Randbedingungen C_i, (iii) instanziierte Parameter-Slot-Werte V_i und (iv) erwartete Ausgaben nach Task-Abschluss D_i['bereitstellen']. Diese Felder legen dem generierten Modell aus mehreren Perspektiven komplementäre semantische Einschränkungen auf: Realisierung der Modellierungsintention, Erfüllung der Einschränkungen, Konsistenz der Parameterinstanziierung und Vollständigkeit der Modellausgaben – was eine prinzipielle Entscheidung darüber ermöglicht, ob der Modellcode die Modellanforderungen erfüllt, ohne zusätzliche Annahmen zu erfordern.

Basierend auf diesen Schlüsselfeldern definieren wir eine mehrfeldige semantische Konsistenz-Entscheidungsfunktion:

(4)

wobei I(·) eine Indikatorfunktion bezeichnet, die gleich 1 ist, wenn alle Teilentscheidungsfunktionen innerhalb der Klammern gelten, und sonst 0. Diese binäre Entscheidung unterscheidet explizit zwischen den Zuständen, in denen die Modellierungsanforderungen erfüllt sind, und dass weitere Reparaturen erforderlich sind, und stellt eine deterministische Auslöserbedingung für den anschließenden semantischen Reparaturprozess bereit. Die Gesamtentscheidung wird gemeinsam von den folgenden vier Unterentscheidungsfunktionen bestimmt:

(1) Modellierung objektiver Konsistenz:

Φ₀ (TC_{i,c f}) = I(consist(c_{f,0 i})) (5)

wobei Consist(c_{f,0 i}) angibt, ob der Modellcode c_f semantisch mit dem in der Aufgabe angegebenen Modellierungsziel 0_i konsistent ist.

(2) Semantische Constraint Satisfaction:

Φ_c (TC_{i,c f}) = I(Satisfy(c_{f,C i})) (6)

wobei Satisfy(c_{f,C i}) angibt, ob der Modellcode c_f die in der Aufgabenkarte festgelegten semantischen Nebenbedingungen und Randbedingungen C_i erfüllt.

(3) Parameterkonsistenz:

Φ_c (TC_{i,c f}) = I(Instant(c_{f,V i})) (7)

wobei Instant(c_{f,V i}) angibt, ob die instanziierten Parameterwerte V_i auf der Task-Karte konsistent im Modellcode wiedergegeben werden.

(4) Ausgabekonsistenz:

(8)

wobei Artefakte(c_j) angibt, ob die von der Aufgabenkarte erwarteten Ausgaben im endgültigen Modellcode vorhanden sind, und dient als Maß für die Vollständigkeit des generierten Ergebnisses.

Diese Konsistenzurteile werden vom Semantic Validation Agent umgesetzt, indem die semantische Verständnisfähigkeit des LLM genutzt wird; Der interne Schlussfolgerungsprozess des Agenten verändert nicht die formale Definition oder Verwendung der Konsistenzfunktion.

Durch diese mehrfeldige semantische Konsistenzprüfung kann das generierte Modell Feld für Feld validiert werden, um sicherzustellen, dass jedes Modellierungsziel, jede Einschränkungsbedingung, jede Parameterkonfiguration und jede erwartete Ausgabe ausreichend erfüllt ist. Dieser Prozess liefert nicht nur einen expliziten Auslöser für die anschließende semantische Reparatur, sondern liefert auch nachverfolgbare semantische Belege über die gesamte Erzeugungspipeline und verbessert so die Zuverlässigkeit und Konsistenz des generierten Modells.

Experimentelle Daten und Auswertung
Experimentelle Daten
Der Modellcode von SysML v2 ist kein gewöhnlicher Softwarecode; Ihre erzeugten Artefakte weisen charakteristische Merkmale formaler Modellierung auf. Verschiedene Ansichten umfassen typischerweise unterschiedliche Kategorien von Kernmodellierungselementen, wie Anforderungen, Teile, Ports, Attribute, Zustände und Übergänge, die sich erheblich in ihren Deklarationsstilen, Organisationsformen und kompositorischen Strukturen unterscheiden. Zusätzlich muss der Modellcode mehrere Einschränkungen erfüllen, darunter Typreferenzierung, hierarchische Verschachtelung, Verbindungsbeschränkungen und semantische Wiederverwendung zwischen Elementen.

Um die Leistung der vorgeschlagenen Methode unter unterschiedlichen Modellierungskomplexitäten umfassend zu bewerten, wird ein Code-Datensatz erstellt, der fünf repräsentative Modellansichtstypen – Anforderungen, Anwendungsfälle, Struktur, Parametrik und Zustandsautomaten – abdeckt. Diese Modellansichten entsprechen der Anforderungsspezifikation, funktionaler Interaktion, struktureller Zusammensetzung, parametrischer Constraint-Darstellung und der Beschreibung der Verhaltenslogik in der Systemmodellierung. Die separate Bewertung des Frameworks auf verschiedenen Modellansichtstypen ermöglicht eine feinere Analyse seiner Anwendbarkeit unter unterschiedlichen Codestrukturmerkmalen und Modellbedingungsbedingungen.

Jeder Modellansichtstyp enthält 15 manuell erstellte Modellinstanzen, was zu einem Datensatz von N = 75 SysML v2-Modellen führt. Der Datensatz umfasst mehrere technische Bereiche, darunter Luft- und Raumfahrt, Automobil, medizinische und Smart-Home-Systeme, und alle Modelle bestanden erfolgreich die offizielle SysML v2-Validierungsumgebung, was eine strikte syntaktische Einhaltung gewährleistet.

Anschließend erstellten wir für jedes Modell eine entsprechende Beschreibung der natürlichen Sprachmodellierungsabsicht. Um die Baueffizienz zu verbessern, verwendeten wir die in Supplementary File 2 gezeigte Prompt-Vorlage und verwendeten GPT-4o, um Anfangsbeschreibungen zu erstellen. GPT-4o wurde wegen seines starken semantischen Verständnisses und seiner Informationsextraktionsfähigkeit ausgewählt, was es ermöglicht, Kernmodellelemente ohne Halluzinationen genau zu erfassen und menschenähnliche Modellierungsabsichtsbeschreibungen^{zu erzeugen 9}. Um die Genauigkeit zu gewährleisten und Mehrdeutigkeiten zu vermeiden, wurden alle generierten Beschreibungen manuell von Forschern mit Systemingenieur-Hintergrund überprüft und verfeinert. Repräsentative Beispiele für verschiedene Modelltypen sind in Tabelle 1 dargestellt.

Bewertungsmetriken
Wir verwenden die folgenden drei Schlüsselkennzahlen, um die Qualität des generierten SysML v2-Modellcodes zu bewerten:

Durchschnittliche syntaktische Fehlerrate (SER)
Diese Metrik quantifiziert den Anteil der syntaktischen Fehler, die erkannt werden, wenn der generierte Modellcode anhand der offiziellen SysML v2-Syntaxregeln validiert wird. Er wird berechnet als:

(9)

wobei E_i die Anzahl der syntaktischen Fehler bezeichnet, die im i-ten erzeugten Modell identifiziert wurden. Diese Metrik spiegelt wider, inwieweit der generierte Modellcode der formalen SysML v2-Syntaxspezifikation entspricht.

Semantischer Konsistenzwert (SCS)
Diese Metrik bewertet, wie genau und umfassend der generierte Modellcode die semantische Absicht erfasst, die in den Spezifikationen der natürlichen Sprachmodellierung ausgedrückt wird. Konkret extrahieren wir semantische Einheiten aus der Modellabsicht – wie Systementitäten, teilnehmende Komponenten, Kernfunktionen oder Verhaltensszenarien sowie Schlüsselbedingungen oder Einschränkungen – und vergleichen sie mit den semantischen Einheiten im generierten Modellcode. Die semantische Konsistenz wird berechnet als:

(10)

wobei U die Menge der aus der Modellabsicht extrahierten semantischen Einheiten darstellt und die Menge der im generierten Code identifizierten semantischen Einheiten darstellt. Gibt die Anzahl der vom generierten Modellcode korrekt erfassten Einheiten an. Ein höherer SCS-Wert deutet auf eine stärkere semantische Abdeckung und Ausrichtung hin.

Bewertung der menschlichen Qualität
Traditionelle automatisierte Metriken wie BLEU und CodeBLEU bewerten hauptsächlich oberflächliche Ähnlichkeit oder Code-Ausführbarkeit, erfassen jedoch nicht, ob das Modell die beabsichtigte Modellierungssemantik wirklich versteht oder korrekt ausdrückt. Diese Kennzahlen sind bei der Bewertung semantischer Konsistenz, Vollständigkeit der Schlüsselelemente und der Ausrichtung mit der Modellierungsintention¹⁰ begrenzt. Im Gegensatz dazu kann menschliche Evaluation Probleme wie fehlende semantische Elemente, logische Inkonsistenzen, strukturelle Redundanz oder nicht belegten Halluzinationen genauer identifizieren und so eine zuverlässigere Bewertung^liefern. Motiviert durch diese Einschränkungen entwerfen wir einen menschlichen Bewertungsrahmen für generierte SysML v2-Modelle, der aus drei Kriterien besteht: (1) Korrektheit: Das generierte Modell muss die Modellabsicht genau widerspiegeln, strukturelle und logische Konsistenz mit den Aufgabenzielen aufrechterhalten und keine semantischen Mehrdeutigkeiten, fehlenden Elemente oder fehlerhafte Erweiterungen enthalten. (2) Lesbarkeit: Der Modellcode sollte klar und leicht verständlich sein, mit einheitlicher Benennung, kohärenter Struktur und einer gut organisierten Hierarchie, die Inspektion und anschließende Wartung unterstützt. (3) Integrität: Das Modell sollte vollständige strukturelle Logik, konsistente Querelementreferenzen und keine undefinierten Typen oder gebrochene Abhängigkeitsketten aufweisen, um seine Nutzbarkeit für nachgelagerte Analyse und Integration sicherzustellen. Wir luden Forscher mit Erfahrung in der SysML-Modellierung ein, jedes generierte Modell auf einer Dreipunktskala zu bewerten, wobei 1 die niedrigste Qualität und 3 die höchste bedeutet. Während der Bewertung durften die Gutachter den generierten Modellcode mit dem Ground-Truth-Modell vergleichen, um eine genauere und umfassendere Bewertung zu gewährleisten.

Basislinie
Wir wählten mehrere Evaluations-Baselines für vergleichende Tests mit der vorgeschlagenen Methode aus, darunter:
CodeCoT¹²: Kombiniert Gedankenketten-Schlussfolgerung mit einem Selbstkontrollmechanismus, wodurch das Modell während der Erstellung explizit argumentieren und syntaktische Fehler selbst korrigieren kann, wodurch die Codequalität und semantische Konsistenz verbessert werden.

Selbstplanung¹³: Führt eine zweistufige Code-Generierungspipeline ein, bei der das Modell zunächst die Lösungsschritte plant und anschließend Code gemäß dem Plan generiert, was die logische Kohärenz und Interpretierbarkeit für komplexe Aufgaben effektiv verbessert.

Selbstbearbeitung¹⁴: Verwendet ein iteratives Generier- und Bearbeitungsparadigma, das den generierten Code ausführt und Fehler automatisch basierend auf Laufzeitfeedback korrigiert, wobei die Ausgabe kontinuierlich verfeinert wird.
CodeChain¹⁵: Verwendet modulare Generierung und iterative Überarbeitung, indem komplexe Aufgaben in unabhängige funktionale Module zerlegt und die strukturelle Solidität sowie die Gesamtqualität durch mehrere Optimierungsrunden verbessert werden.

Selbstfehler¹⁶: Bietet dem Modell autonome Debugging- und Erklärungsfunktionen. Durch einen geschlossenen Kreislauf aus Generierung, Ausführung und Debugging verbessert es die Korrektheit komplexer Programmieraufgaben erheblich ohne menschliches Eingreifen.

MapCoder¹⁷: Erstellt ein mehrstufiges, kollaboratives Framework, bestehend aus vier Agenten – Abruf, Planung, Codierung und Debugging –, das den menschlichen Programmierworkflow eng simuliert und geschlossene Kreislauf-Generierung vom Aufgabenverständnis bis zur Ergebnisverifikation ermöglicht.

Selbstzusammenarbeit¹⁸: Organisiert das System als virtuelles Programmierteam mit Rollen wie Analyst, Programmierer und Tester, um die Gesamtleistung bei komplexer Codegenerierung durch rollenbasierte Zusammenarbeit und iteratives Feedback zu verbessern.

Experimenteller Aufbau
Um Fairness und Vergleichbarkeit über Experimente hinweg zu gewährleisten, haben wir zunächst mehrere gängige LLMs mit einem Ansatz der direkten Codegenerierung bewertet, um die Ausgangsleistung zu ermitteln. Basierend auf diesen ersten Ergebnissen wurde das leistungsstärkste LLM als einheitliches Backbone-Modell für alle folgenden Experimente ausgewählt. Anschließend verglichen wir das vorgeschlagene MAS4SysML-Framework mit mehreren repräsentativen Codegenerierungsmethoden. Alle LLM-Interaktionen wurden mit einer festen Temperatureinstellung (T = 0,2) durchgeführt, um die Zufälligkeit während der Generierung zu minimieren. Für jede Modellierungsaufgabe wurde die maximale Anzahl der Reparaturiterationen in MAS4SysML auf K_max = 3 gesetzt. Alle Baseline-Methoden wurden unter derselben experimentellen Konfiguration wie MAS4SysML ausgeführt, um Ergebniskonsistenz und experimentelle Fairness zu gewährleisten. Das Python-Skript der MAS4SysML-Methode wird als Supplementary File 3 bereitgestellt.

Results

Bewertung des Baseline-Modells
Zunächst wählten wir mehrere gängige LLMs aus und führten vorläufige Leistungstests mit direkter Model-to-Code-Generierung durch, darunter CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)²², Incoder(6.7B)²³ und code-davinci-002(175B)²⁴. Wie in Tabelle 2 da...

Discussion

Wir schlagen MAS4SysML vor, ein Multi-Agenten-Kollaborationsframework für halbautomatisierte SysML v2 Modellcode-Generierung. Das Framework besteht aus vier funktional komplementären Agenten. Während der Generierung zerlegt es (i) hierarchisch die Anforderungen der natürlichen Sprachmodellierung mittels einer aufgabenbaumbasierten Struktur und formalisiert diese in strukturierte Aufgabenkarten, und (ii) generiert SysML v2 Modellcode von unten nach oben, geleitet von den in diesen Karten ...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (Open-Source-Projekt)	v1.0.8; https://github.com/langchain-ai/langchain	Rahmenwerk für LLM-Interaktion und Agentenorchestrierung
LangGraph	LangChain (Open-Source-Projekt)	v1.0.3; https://github.com/langchain-ai/langgraph	Multi-Agenten-Workflow-Ausführungsrahmen
Python	Python Software Foundation	3.10.x; https://www.python.org/downloads/release/python-3100/	Hauptprogrammiersprache für MAS4SysML-Implementierung
SysML v2 Pilot-Implementierung	Objektverwaltungsgruppe (OMG)	(Veröffentlichung/Tag-Version bereitstellen); https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Verwendet zur Syntaxvalidierung und Modellparsing