MAS4SysML : Un cadre multi-agents pour la génération de modèles SysML v2 à partir du langage naturel

Summary

Ce protocole présente MAS4SysML, une approche multi-agents qui génère automatiquement du code SysML v2 via une division coordonnée des tâches, nécessitant peu d’itérations de réparation et réduisant significativement le temps de modélisation manuelle tout en améliorant l’efficacité de la modélisation système.

Abstract

Générer automatiquement des modèles SysML précis à partir des exigences en langage naturel peut considérablement accélérer l’adoption de l’ingénierie des systèmes basée sur les modèles (MBSE) dans le développement de systèmes complexes. Cependant, l’utilisation de grands modèles de langage (LLM) pour générer du code de modèle ne respecte souvent pas les contraintes syntaxiques strictes des langages de modélisation formelle, et assurer de manière cohérente l’alignement sémantique entre les modèles générés et les exigences reste un défi. Pour relever ces défis, cet article présente MAS4SysML, un cadre collaboratif multi-agents pour la génération de code SysML v2 qui améliore la correction syntaxique et la cohérence sémantique sous un budget de réparation limité. Le cadre décompose une tâche de modélisation en sous-tâches hiérarchiques, les formalise en cartes de tâches structurées, et génère du code modèle de manière ascendante. Lors de la génération, un environnement de validation officiel est utilisé pour le diagnostic de syntaxe ; Après l’achèvement, le framework vérifie la cohérence sémantique entre le code et les cartes de tâches. Si la validation syntaxique ou sémantique échoue, le cadre répare et révalide de manière itérative le code dans un budget de réparation prédéfini, guidé par un retour d’information diagnostique, jusqu’à ce que les critères de validation soient satisfaits ou que le budget soit épuisé. Pour évaluer la méthode proposée, nous construisons un ensemble de données SysML v2 couvrant cinq types de tâches principales — exigences, cas d’usage, structure, paramétriques et machines à états — et réalisons des expériences comparatives. Les résultats montrent que MAS4SysML réduit le taux moyen d’erreur syntaxique à 2,63, augmente la similarité sémantique à 0,91, et surpasse globalement les méthodes de génération de code existantes.

Introduction

Le MBSE est devenu une méthodologie clé pour l’analyse des exigences, la conception de l’architecture système et la planification de la vérification dans le développement d’équipements complexes dans des domaines tels que l’aviation et^{l’aérospatiale 1}. En utilisant des langages de modélisation unifiés tels que SysML comme infrastructure de modélisation, les informations — y compris les exigences, la structure, le comportement et les contraintes — peuvent être organisées dans un cadre de modèle cohérent, améliorant la structure des processus et l’efficacité de la collaboration interdisciplinaire². Cependant, à mesure que l’échelle du système continue de croître, le nombre de modèles à développer augmente en conséquence, entraînant une augmentation soutenue de la charge de travail de la modélisation manuelle SysML. De plus, les modélisateurs doivent travailler sous des contraintes syntaxiques et méthodologiques strictes, qui nécessitent une expertise substantielle et de fortes capacités d’abstraction. Ces facteurs sont devenus un goulot d’étranglement majeur dans l’adoption en ingénierie du^{MBSE 3}.

Ces dernières années, les LLM ont démontré de solides capacités en compréhension du langage naturel, représentation structurée de l’information et génération de code, offrant de nouvelles opportunités pour automatiser la modélisation MBSE du langage naturel au code^{modèle 4}. Des études antérieures ont exploré la génération directe de code modèle SysML à l’aide des^{LLMs 5}. Néanmoins, d’importants défis subsistent. Syntaxiquement, le système de types, les mécanismes de cadrage et la sémantique de référence de SysML sont régis par des contraintes formelles strictes et sont souvent plus complexes que ceux des langages de programmation^{polyvalents 6}. Sémantiquement, les LLM peuvent ne pas capturer pleinement la logique comportementale, les relations structurelles et les contraintes inter-couches, entraînant des relations manquantes, des incohérences logiques ou des modèles^{incomplets 7}. Ces limitations nuisent à la fiabilité, à la contrôlabilité et à l’interprétabilité des approches de génération directe.

Pour relever ces défis, cet article présente MAS4SysML, un cadre de génération de code SysML v2 composé de quatre rôles d’agent. Plutôt que de cibler directement la génération one-shot d’un modèle système complet à vue croisée, cette étude se concentre sur la génération et la réparation itérative de multiples tâches de modélisation SysML v2 représentatives. Guidé par la décomposition des tâches et des cartes de tâches structurées, et intégrant la génération de code, le diagnostic de syntaxe au niveau de l’outil et la vérification de la cohérence sémantique, MAS4SysML établit un flux de travail en boucle fermée de génération, validation et réparation. Cette conception améliore la correction syntaxique, la cohérence sémantique et la complétude structurelle du code généré dans un budget de réparation contraint.

Les principales contributions sont résumées comme suit : (1) cadre MAS4SysML. Nous proposons MAS4SysML, un cadre multi-agents piloté par LLM qui permet une génération de bout en bout, des exigences en langage naturel jusqu’au code exécutable SysML v2, offrant une voie pratique pour réduire le coût de modélisation et améliorer l’efficacité de la modélisation. (2) Analyse syntaxique des tâches et validation duale. Nous introduisons un mécanisme d’analyse des arbres de structure des tâches et un schéma de validation dual (syntaxe et sémantique). En analyse des tâches, les objectifs de modélisation sont décomposés hiérarchiquement et formalisés en fiches de tâches structurées. Pour la validation, le diagnostic syntaxique utilise un environnement de validation^{officiel 8} pour vérifier le code généré et retourner des diagnostics orientés réparation, tandis que la validation sémantique utilise des champs clés dans les cartes de tâches comme références pour évaluer la cohérence globale entre le modèle généré et les objectifs de modélisation. (3) Évaluation expérimentale. Nous menons des expériences comparatives en utilisant le taux d’erreur syntaxique et le score de cohérence sémantique comme indicateurs principaux. Les résultats montrent que MAS4SysML réduit le taux moyen d’erreur syntaxique à 2,63 et augmente la similarité sémantique à 0,91, surpassant les méthodes de base en termes de précision de génération et d’automatisation.

Protocol

Le processus de génération de code du cadre MAS4SysML est résumé dans le Fichier Supplémentaire 1. Il convient de noter que cette étude ne vise pas à obtenir la génération unique d’un modèle système complet à partir d’un langage naturel avec une stricte cohérence croisée, incluant les exigences, la structure, les paramétriques et le comportement. Au lieu de cela, le protocole se concentre sur la génération de plusieurs types représentatifs de code de vue SysML v2.

Phase I : Analyse de la tâche
Le flux de travail commence par l’analyse des tâches. Le système fournit l’intention de modélisation en langage naturel à l’Agent de génération de structure de tâche, qui produit un ensemble de fiches de tâches. Pour garantir que les générations suivantes soient exécutables et reproductibles, chaque carte de tâche doit inclure, au minimum, (i) un identifiant de tâche, (ii) des relations de dépendance, et (iii) des informations de modélisation clés pour la validation, telles que l’objectif de modélisation, les contraintes/conditions aux limites, les emplacements de paramètres, les valeurs d’instanciation et les sorties attendues. Cette étape produit task_card_set, qui sert de base unifiée pour la génération ultérieure du code modèle.

Phase II : Génération itérative de code
En génération itérative, le système initialise le contexte de code prev_code à un état vide et génère du code pour chaque carte de tâche séquentiellement selon un ordre déterminé par les champs de dépendance. Pour chaque carte de tâche, l’Agent de Génération de Code prend la carte de tâche courante et le code contextuel en entrée pour produire candidate_code, puis invoque immédiatement le module de validation de syntaxe pour vérification. Le module valide le code en utilisant l’environnement officiel de validation SysML v2 et renvoie les résultats de diagnostic. Si la validation réussit, le candidate_code sert à mettre à jour prev_code et prend en charge la génération ultérieure. Si la validation échoue, l’Agent de Réparation de Code est déclenché et effectue des modifications minimales ciblées guidées par les diagnostics retournés, après quoi le code corrigé est soumis à nouveau pour revalidation. Cette boucle de revalidation de réparation est limitée par le budget de réparation _maximal K max. Si la validation réussit dans le budget, la version en validation se met à jour prev_code ; sinon, après K_{au max}, le système enregistre la défaillance et poursuit la génération ultérieure de la carte de tâches en utilisant la dernière version réparée comme prev_code afin d’éviter de bloquer le flux de travail tout en maintenant la continuité contextuelle.

Phase III : Validation sémantique
Après la génération du code pour toutes les fiches de tâches, le flux de travail passe à la validation sémantique. L’agent de validation sémantique évalue la cohérence entre le code final et l’intention de modélisation en utilisant des champs clés dans task_card_set comme références et produit les résultats de validation sémantique. Si la validation réussit, prev_code est accepté comme code final du modèle SysML v2. Sinon, le système génère un rapport de déviation sémantique qui identifie les champs de la carte de tâche non remplis et le périmètre de révision requis. L’agent de réparation de code révise ensuite le code en conséquence et produit le code modèle révisé comme résultat final.

Architecture et méthodologie du modèle
Architecture du modèle
Le cadre MAS4SysML, illustré à la Figure 1, comprend quatre agents collaboratifs : l’agent de génération de structure de tâches, l’agent de génération de code, l’agent de réparation de code et l’agent de validation sémantique. Les modèles d’invite correspondants sont présentés à la Figure 2.

L’agent de génération de structure de tâches effectue une analyse sémantique de l’intention de modélisation d’entrée et génère des cartes de tâches structurées et exécutables. Il applique d’abord un mécanisme de décomposition hiérarchique des tâches (voir mécanisme de décomposition hiérarchique des tâches) pour décomposer l’objectif global de modélisation en nœuds de tâche avec des frontières sémantiques bien définies, puis construit une carte de tâche structurée pour chaque nœud. Par la suite, les cartes de tâches sont ordonnées selon leurs champs de dépendance de modélisation afin de garantir que la séquence d’exécution s’aligne avec la structure de code finale, posant ainsi les bases de la génération de code ascendante basée sur l’objectif global de modélisation.

L’agent de génération de code génère progressivement du code modèle conforme à SysML v2 selon les dépendances de modélisation. S’appuyant sur les artefacts de code produits par les tâches parentes, l’agent effectue les opérations de génération de code correspondantes en fonction des exigences spécifiées dans chaque fiche de tâche, permettant ainsi un processus de construction par étapes — des composants locaux jusqu’au modèle complet.

L’agent de réparation de code corrige les erreurs dans le code généré en fonction des résultats du module de validation syntaxique (voir module de validation syntaxique) et des résultats de validation sémantique. Pour la réparation syntaxique, il exploite le type d’erreur, la position et les informations contextuelles retournées par le validateur de syntaxe pour synthétiser des stratégies de réparation ciblées et générer du code corrigé. Pour la réparation sémantique, il ajuste les relations structurelles et logiques selon les résultats de validation sémantique, assurant la cohérence sémantique et la complétude structurelle dans le modèle final.

L’agent de validation sémantique évalue la cohérence sémantique entre le code entièrement généré et les cartes de tâches à l’aide d’un mécanisme dédié de validation sémantique (voir mécanisme de validation sémantique). Par l’évaluation quantitative, il garantit que le code généré reflète fidèlement l’intention de modélisation initiale, assurant ainsi un alignement précis entre le code du modèle et les exigences de modélisation spécifiées.

Mécanisme de décomposition hiérarchique des tâches
En tant que langage de modélisation formel pour les systèmes complexes, SysML v2 présente une syntaxe fortement couplée, des structures hiérarchiques profondément imbriquées et des contraintes sémantiques inter-niveaux. Par exemple, un bloc de structure système peut contenir plusieurs sous-parties, attributs et ports tout en exprimant simultanément des exigences de performance ou de comportement via des contraintes inter-couches. Ces structures et contraintes créent des dépendances structurelles descendantes et des relations de rétroaction sémantiques ascendantes. Avec une approche de génération plate et en un seul coup, la cartographie précise de telles dépendances hiérarchiques devient difficile, entraînant souvent des relations manquantes, des incohérences sémantiques ou la perte d’informations sur les contraintes.

Pour relever ce défi, nous développons une méthode d’analyse d’intention de modélisation basée sur un arbre de tâches, qui décompose hiérarchiquement les exigences de modélisation en langage naturel. Comme illustré à la Figure 3, les objectifs de modélisation complexes sont décomposés en nœuds de tâche structurés et traçables, permettant au système d’interpréter la sémantique de modélisation de manière descendante et d’identifier les relations de dépendance. Plus précisément, lorsque l’agent de génération de structure de tâche reçoit l’entrée utilisateur, il exploite d’abord les capacités d’analyse sémantique des LLM pour identifier les objectifs de modélisation essentiels, les entités clés et leurs dépendances. Il décompose ensuite récursivement l’objectif principal en sous-tâches sémantiquement indépendantes et les affine en tâches atomiques pouvant être directement mappées aux opérations de modélisation SysML v2, formant finalement un arbre complet de structure de tâches. Après la construction de l’arbre des tâches, l’agent génère une fiche de tâche structurée pour chaque nœud de tâche basée sur un modèle prédéfini. Le format de la carte de tâches est défini comme suit :

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

Où id est l’identifiant unique du nœud de tâche, O l’objectif de la tâche, N la description en langage naturel de la tâche, K désigne les éléments sémantiques de base de SysML v2 pouvant être impliqués dans la tâche, incluant principalement la définition de la demande/exigence, la définition de la partie/la partie, la défense du port/port du port, la définition de l’élément, la définition de l’attribut/attribut et l’état/transition. Les relations entre ces éléments s’expriment principalement via connect (connexions structurelles), les éléments d’entrée/sortie sur les ports (flux d’information/matériaux), et les conditions de déclenchement/garde des transitions de la machine à états (par exemple, commandes, état de santé et contraintes de seuil), C comme règles sémantiques ou conditions aux limites, P comme emplacements paramétrables dans la tâche tels que les noms d’attributs, types de données ou types composites, V comme valeurs instanciées pour chaque emplacement et D comme dépendances de modélisation entre les tâches où depend_on spécifie les sorties requises d’autres tâches avant de générer le code de tâche courant, fournit désigne les sorties produites après l’achèvement de la tâche et consomme les entrées externes requises par la tâche.

Module de validation de syntaxe
Un module de validation de syntaxe est construit à partir de l’implémentation pilote SysML v2. En invoquant ses interfaces d’analyseur et de validateur, le module analyse et vérifie la correction syntaxique du code du modèle SysML v2 généré. Les critères de validation du module sont principalement dérivés de la spécification du langage SysML v2, ainsi que des règles grammaticales, des règles de résolution de portée et des mécanismes de vérification des contraintes associés implémentés dans l’outil pilote. Plus précisément, la validation examine si les déclarations d’éléments sont bien formées, si les structures de blocs sont complètes, si les annotations de type sont valides, si les noms et références peuvent être résolus avec succès, et si des constructions de modélisation telles que les ports, connexions, états et transitions respectent les exigences du langage.

Après que l’agent de génération de code a produit le fragment de code pour la tâche en cours, la sortie est transmise au module de validation de syntaxe, où le script de validation analyse le code et retourne les résultats sous forme d’informations diagnostiques structurées. Les résultats de validation sont rapportés comme suit :

e₁ = (type_i, pos_i, msg_i) (2)

Où e_i désigne la liste des problèmes détectés pour la tâche de modélisation en cours, chaque entrée contenant le type d’erreur _{type i}, la position pos _i, et le message de diagnostic_i .

Par exemple, si le code généré contient une erreur de syntaxe telle que « un attribut n’est pas typé par une définition d’attribut », le module de validation renvoie le message de diagnostic suivant :

'type' : 'error'
'message' : 'ERREUR : Un attribut doit être typé selon la définition de l’attribut.' (3)
'Position' : 'Ligne 7 Colonne : 3'

Lorsque le résultat de validation e_i ≠ 0, l’information d’erreur collectée e_i est transmise à l’agent de réparation de code pour correction supplémentaire. Par conséquent, le processus de réparation de code n’est pas une modification non contrainte, mais une révision ciblée guidée par les informations diagnostiques explicites retournées par l’analyseur et le validateur.

Mécanisme de validation sémantique
Le mécanisme de validation sémantique utilise des champs clés de cartes de tâche qui ont des correspondances explicites et traçables avec le code du modèle comme ancres sémantiques. Il évalue la cohérence sémantique au niveau du modèle, fournissant ainsi des critères explicites et exploitables pour la réparation ultérieure du modèle. Plus précisément, pour chaque carte de tâche TC_i, les champs suivants sont utilisés comme références sémantiques clés : (i) l’objectif de modélisation O_i, (ii) contraintes sémantiques et conditions aux limites C_i, (iii) valeurs instanciées des emplacements de paramètre V_i, et (iv) sorties attendues après l’achèvement de la tâche_{D i}['fournir']. Ces champs imposent des contraintes sémantiques complémentaires au modèle généré sous plusieurs angles : réalisation de l’intention de modélisation, satisfaction des contraintes, cohérence de l’instanciation des paramètres et complétude des sorties du modèle — permettant une décision fondée sur la satisfaction du code modèle sans nécessiter d’hypothèses supplémentaires.

Sur la base de ces champs clés, nous définissons une fonction de décision de cohérence sémantique multi-champs :

(4)

où I(·) désigne une fonction indicatrice égal à 1 si toutes les fonctions de sous-décision entre parenthèses sont valables, et 0 sinon. Cette décision binaire distingue explicitement entre les états satisfaisant les exigences de modélisation et nécessitant une réparation supplémentaire, fournissant une condition déclencheuse déterministe pour le processus de réparation sémantique ultérieur. La décision globale est déterminée conjointement par les quatre sous-fonctions de décision suivantes :

(1) Modéliser la cohérence des objectifs :

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

où Consist(c_{f,0 i}) indique si le code modèle c_f est sémantiquement cohérent avec l’objectif de modélisation_{0 i} spécifié dans la fiche de tâche.

(2) Satisfaction des contraintes sémantiques :

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

où Satisfy(_{c f,C i}) indique si le code de modèle c_f satisfait les contraintes sémantiques et les conditions aux limites C_i spécifiées dans la carte de tâche.

(3) Cohérence des paramètres :

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

où Instant(_{c f,V i}) indique si les valeurs instanciées des paramètres V_i dans la carte des tâches sont reflétées de manière cohérente dans le code du modèle.

(4) Régularité des sorties :

(8)

où Artifacts(c_j) indique si les sorties attendues par la carte de tâche sont présentes dans le code final du modèle, servant de mesure de la complétude du résultat généré.

Ces jugements de cohérence sont mis en œuvre par l’agent de validation sémantique en tirant parti de la capacité de compréhension sémantique du LLM ; Le processus de raisonnement interne de l’agent ne modifie pas la définition formelle ni l’utilisation de la fonction de cohérence.

Grâce à cette vérification de cohérence sémantique multi-champs, le modèle généré peut être validé champ par champ afin de garantir que chaque objectif de modélisation, condition de contrainte, configuration de paramètres et résultat attendu est suffisamment satisfait. Ce processus fournit non seulement un déclencheur explicite pour une réparation sémantique ultérieure, mais fournit également des preuves sémantiques traçables tout au long de la chaîne de génération, améliorant ainsi la fiabilité et la cohérence du modèle généré.

Données expérimentales et évaluation
Données expérimentales
Le code modèle SysML v2 n’est pas un code logiciel ordinaire ; ses artefacts générés présentent des caractéristiques distinctives de modélisation formelle. Différentes vues impliquent généralement des catégories distinctes d’éléments de modélisation centrale, telles que les exigences, les pièces, les ports, les attributs, les états et les transitions, qui diffèrent substantiellement par leurs styles de déclaration, leurs formes organisationnelles et leurs structures compositionnelles. De plus, le code modèle doit satisfaire à plusieurs contraintes, notamment le référencement de types, le nesting hiérarchique, les contraintes de connexion et la réutilisation sémantique entre les éléments.

Pour évaluer de manière exhaustive les performances de la méthode proposée sous différentes complexités de modélisation, un jeu de données de code couvrant cinq types de vues de modèle représentatives — exigences, cas d’usage, structure, paramétriques et machines à états — est construit. Ces vues de modèle correspondent respectivement à la spécification des exigences, à l’interaction fonctionnelle, à la composition structurelle, à la représentation paramétrique des contraintes et à la description de la logique comportementale en modélisation des systèmes. Évaluer le cadre séparément sur différents types de vues de modèle permet une analyse plus fine de son applicabilité sous diverses caractéristiques de structure de code et conditions de contraintes de modélisation.

Chaque type de vue de modèle contient 15 instances de modèle créées manuellement, aboutissant à un ensemble de données de N = 75 modèles SysML v2. L’ensemble de données couvre plusieurs domaines d’ingénierie, notamment l’aérospatiale, l’automobile, la médecine et les systèmes domestiques intelligents, et tous les modèles ont réussi l’environnement officiel de validation SysML v2, garantissant une stricte conformité syntaxique.

Par la suite, nous avons généré une description correspondante de l’intention de modélisation en langage naturel pour chaque modèle. Pour améliorer l’efficacité de la construction, nous avons utilisé le modèle de prompt présenté dans le Fichier Supplémentaire 2 et utilisé GPT-4o pour produire les descriptions initiales. GPT-4o a été sélectionné pour sa forte compréhension sémantique et ses capacités d’extraction d’informations, lui permettant de capturer avec précision les éléments centraux du modèle sans hallucination et de générer des descriptions d’intention de modélisation similaires à^{celles de l’humain 9}. Pour garantir l’exactitude et éliminer toute ambiguïté, toutes les descriptions générées ont été révisées manuellement et affinées par des chercheurs issus de l’ingénierie système. Des exemples représentatifs pour différents types de modèles sont présentés dans le tableau 1.

Indicateurs d’évaluation
Nous utilisons les trois indicateurs clés suivants pour évaluer la qualité du code du modèle SysML v2 généré :

Taux moyen d’erreur syntaxique (SER)
Cette métrique quantifie la proportion d’erreurs syntaxiques détectées lorsque le code du modèle généré est validé selon les règles syntaxiques officielles de SysML v2. Elle se calcule ainsi :

(9)

où E_i désigne le nombre d’erreurs syntaxiques identifiées dans le i-ème modèle généré. Cette métrique reflète dans quelle mesure le code du modèle généré adhère à la spécification syntaxique formelle SysML v2.

Score de cohérence sémantique (SCS)
Cette métrique évalue la précision et la compréhension du code du modèle généré qui capture l’intention sémantique exprimée dans les spécifications de modélisation en langage naturel. Plus précisément, nous extravons des unités sémantiques de l’intention de modélisation — telles que les entités système, les composants participants, les fonctions principales ou les scénarios comportementaux, ainsi que les conditions ou contraintes clés — et les comparons aux unités sémantiques présentes dans le code du modèle généré. La cohérence sémantique se calcule comme suit :

(10)

où U représente l’ensemble des unités sémantiques extraites de l’intention de modélisation, et représente l’ensemble des unités sémantiques identifiées dans le code généré. indique le nombre d’unités correctement capturées par le code du modèle généré. Une valeur SCS plus élevée indique une couverture sémantique et un alignement plus forts.

Évaluation de la qualité humaine
Les métriques automatisées traditionnelles telles que BLEU et CodeBLEU évaluent principalement la similarité de surface ou l’exécutabilité du code, mais elles ne capturent pas si le modèle comprend réellement ou exprime correctement la sémantique de modélisation prévue. Ces métriques sont limitées dans l’évaluation de la cohérence sémantique, de la complétude des éléments clés et de l’alignement avec l’intention de^{modélisation 10}. En revanche, l’évaluation humaine peut identifier plus précisément des problèmes tels que l’absence d’éléments sémantiques, des incohérences logiques, la redondance structurelle ou les hallucinations non étayées, fournissant ainsi une évaluation plus fiable¹¹. Motivés par ces limitations, nous concevons un cadre d’évaluation humaine pour les modèles SysML v2 générés comprenant trois critères : (1) Correcteur : le modèle généré doit refléter fidèlement l’intention de modélisation, maintenir une cohérence structurelle et logique avec les objectifs de la tâche, et ne contenir aucune ambiguïté sémantique, aucun élément manquant ou extension erronée. (2) Lisibilité : le code du modèle doit être clair et facile à comprendre, avec une nomenclature cohérente, une structure cohérente et une hiérarchie bien organisée qui supporte l’inspection et la maintenance ultérieure. (3) Intégrité : le modèle doit présenter une logique structurelle complète, des références croisées cohérentes, et aucun type indéfini ni chaînes de dépendances brisées, garantissant ainsi son utilité pour l’analyse et l’intégration en aval. Nous avons invité des chercheurs ayant de l’expérience en modélisation SysML à noter chaque modèle généré sur une échelle de trois points, où 1 indique la qualité la plus basse et 3 la plus élevée. Lors de l’évaluation, les évaluateurs ont pu comparer le code du modèle généré avec le modèle de justesse du terrain afin d’assurer une évaluation plus précise et complète.

Ligne de base
Nous avons sélectionné plusieurs références d’évaluation pour les tests comparatifs avec la méthode proposée, notamment :
CodeCoT¹² : Combine le raisonnement en chaîne de pensée avec un mécanisme d’auto-vérification, permettant au modèle de raisonner explicitement pendant la génération et d’auto-corriger les erreurs syntaxiques, améliorant ainsi la qualité du code et la cohérence sémantique.

Auto-planification¹³ : Introduit un pipeline de génération de code en deux étapes dans lequel le modèle planifie d’abord les étapes de la solution puis génère du code selon le plan, améliorant efficacement la cohérence logique et l’interprétabilité pour des tâches complexes.

Auto-édition¹⁴ : Adopte un paradigme itératif de générer et d’éditer qui exécute le code généré et corrige automatiquement les erreurs en fonction du retour d’exécution à l’exécution, affinant continuellement la sortie.
^{CodeChain 15} : Utilise la génération modulaire et la révision itérative en décomposant des tâches complexes en modules fonctionnels indépendants et en améliorant la solidité structurelle ainsi que la qualité globale grâce à plusieurs cycles d’optimisation.

Auto-débogage¹⁶ : Dote le modèle de capacités autonomes de débogage et d’explication. Grâce à un processus en boucle fermée de génération, d’exécution et de débogage, il améliore considérablement la correction des tâches de programmation complexes sans intervention humaine.

MapCoder¹⁷ : Construit un cadre collaboratif à plusieurs étapes composé de quatre agents — récupération, planification, codage et débogage — simulant étroitement le flux de travail de programmation humaine et permettant la génération en boucle fermée de la compréhension des tâches à la vérification des résultats.

Auto-collaboration¹⁸ : Organise le système en une équipe de programmation virtuelle avec des rôles tels qu’analyste, programmeur et tester, améliorant la performance globale sur la génération de code complexe grâce à la collaboration basée sur les rôles et au retour d’information itératif.

Installation expérimentale
Pour garantir l’équité et la comparabilité entre les expériences, nous avons d’abord évalué plusieurs LLM grand public en utilisant une approche de génération directe de code afin d’établir la performance de base. Sur la base de ces premiers résultats, le LLM le plus performant a été sélectionné comme modèle unifié de base pour toutes les expériences ultérieures. Nous avons ensuite comparé le cadre MAS4SysML proposé avec plusieurs méthodes de génération de code représentative. Toutes les interactions LLM ont été réalisées en utilisant un réglage de température fixe (T = 0,2) afin de minimiser l’aléatoire lors de la génération. Pour chaque tâche de modélisation, le nombre maximal d’itérations de réparation dans MAS4SysML était fixé à K_max = 3. Toutes les méthodes de référence ont été exécutées sous la même configuration expérimentale que MAS4SysML afin d’assurer la cohérence des résultats et l’équité expérimentale. Le script Python de la méthode MAS4SysML est fourni en Fichier Supplémentaire 3.

Results

Évaluation du modèle de référence
Nous avons d’abord sélectionné plusieurs LLM grand public et mené des tests préliminaires de performance en générant directement modèle à code, notamment CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)^22, Incoder(6.7B)²³ et code-davinci-002(175B)²⁴. Comme montré dans

Discussion

Nous proposons MAS4SysML, un cadre collaboratif multi-agents pour la génération de code de modèles SysML v2 semi-automatisée. Le cadre se compose de quatre agents fonctionnellement complémentaires. Lors de la génération, elle (i) décompose hiérarchiquement les exigences de modélisation en langage naturel à l’aide d’une structure basée sur un arbre de tâches et les formalise en cartes de tâches structurées, et (ii) génère du code de modèle SysML v2 de manière ascendante, guidée par les co...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (projet open source)	v1.0.8 ; https://github.com/langchain-ai/langchain	Cadre pour l’interaction avec les LLM et l’orchestration d’agents
LangGraph	LangChain (projet open source)	v1.0.3 ; https://github.com/langchain-ai/langgraph	Cadre d’exécution de flux de travail multi-agents
Python	Fondation Python Software	3.10.x ; https://www.python.org/downloads/release/python-3100/	Principal langage de programmation pour la mise en œuvre de MAS4SysML
Implémentation pilote de SysML v2	Groupe de gestion d’objets (OMG)	(fournir la version release/tag) ; https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Utilisé pour la validation de syntaxe et l’analyse des modèles