MAS4SysML: Un marco multiagente para la generación de modelos SysML v2 a partir de lenguaje natural

Summary

Este protocolo presenta MAS4SysML, un enfoque multiagente que genera automáticamente código SysML v2 mediante división coordinada de tareas, requiriendo pocas iteraciones de reparación y reduciendo significativamente el tiempo de modelado manual mientras mejora la eficiencia del modelado del sistema.

Abstract

Generar automáticamente modelos SysML precisos a partir de requisitos de lenguaje natural puede acelerar sustancialmente la adopción de la Ingeniería de Sistemas Basada en Modelos (MBSE) en el desarrollo de sistemas complejos. Sin embargo, el uso de grandes modelos de lenguaje (LLMs) para generar código de modelo a menudo no cumple con las estrictas restricciones sintácticas de los lenguajes de modelado formal, y garantizar una alineación semántica constante entre los modelos generados y los requisitos sigue siendo un reto. Para abordar estos desafíos, este artículo presenta MAS4SysML, un marco colaborativo multiagente para la generación de código SysML v2 que mejora la corrección sintáctica y la consistencia semántica bajo un presupuesto de reparación limitado. El marco descompone una tarea de modelado en subtareas jerárquicas, las formaliza como tarjetas de tareas estructuradas y genera código modelo de forma ascendente. Durante la generación, se utiliza un entorno oficial de validación para el diagnóstico sintáctico; Tras completarlo, el framework verifica la consistencia semántica entre el código y las tarjetas de tareas. Si falla la validación sintética o semántica, el marco repara y revalida iterativamente el código dentro de un presupuesto de reparación predefinido, guiado por retroalimentación diagnóstica, hasta que se cumplen los criterios de validación o se agota el presupuesto. Para evaluar el método propuesto, construimos un conjunto de datos SysML v2 que abarca cinco tipos de tareas principales: requisitos, casos de uso, estructura, paramétricas y máquinas de estados, y realizamos experimentos comparativos. Los resultados muestran que MAS4SysML reduce la tasa media de error sintáctico a 2,63, aumenta la similitud semántica a 0,91 y supera en general los métodos existentes de generación de código.

Introduction

El MBSE se ha convertido en una metodología clave para el análisis de requisitos, el diseño de arquitectura de sistemas y la planificación de verificación en el desarrollo de equipos complejos en dominios como la aviación y^{la aeroespacial 1}. Utilizando lenguajes de modelado unificados como SysML como columna vertebral de modelado, la información—incluyendo requisitos, estructura, comportamiento y restricciones—puede organizarse en un marco de modelo coherente, mejorando la estructura de procesos y la eficiencia de la colaboración interdisciplinar². Sin embargo, a medida que la escala del sistema sigue creciendo, el número de modelos que deben desarrollarse aumenta en consecuencia, lo que lleva a un incremento sostenido en la carga de trabajo del modelado manual de SysML. Además, los modeladores deben trabajar bajo estrictas restricciones sintácticas y metodológicas, que requieren una experiencia considerable y fuertes capacidades de abstracción. Estos factores se han convertido en un cuello de botella importante en la adopción de la MBSE³ en la ingeniería.

En los últimos años, los LLMs han demostrado sólidas capacidades en la comprensión del lenguaje natural, la representación estructurada de información y la generación de código, lo que permite nuevas oportunidades para automatizar el modelado MBSE desde el lenguaje natural hasta el código^{modelo 4}. Estudios previos han explorado la generación directa de código modelo SysML utilizando^{LLMs 5}. No obstante, persisten desafíos significativos. Sintácticamente, el sistema de tipos, los mecanismos de alcance y la semántica de referencia de SysML están gobernados por estrictas restricciones formales y suelen ser más complejos que los de los lenguajes de programación de propósito^{general 6}. Semánticamente, los LLMs pueden no capturar completamente la lógica conductual, las relaciones estructurales y las restricciones entre capas, lo que resulta en relaciones ausentes, inconsistencias lógicas o modelos^{incompletos 7}. Estas limitaciones dificultan la fiabilidad, controlabilidad e interpretabilidad de los enfoques de generación directa.

Para abordar estos desafíos, este artículo presenta MAS4SysML, un marco de generación de código SysML v2 compuesto por cuatro roles de agente. En lugar de dirigirse directamente a la generación única de un modelo completo de sistema de vista cruzada, este estudio se centra en generar y reparar iterativamente múltiples tareas representativas de modelado SysML v2. Guiado por la descomposición de tareas y tarjetas estructuradas, e integrando la generación de código, el diagnóstico sintáctico a nivel de herramienta y la verificación de consistencia semántica, MAS4SysML establece un flujo de trabajo cerrado de generación, validación y reparación. Este diseño mejora la corrección sintáctica, la consistencia semántica y la completitud estructural del código generado bajo un presupuesto de reparación limitado.

Las principales contribuciones se resumen de la siguiente manera: (1) marco MAS4SysML. Proponemos MAS4SysML, un marco multiagente impulsado por LLM que permite la generación de extremo a extremo, desde los requisitos de lenguaje natural hasta el código ejecutable de modelos SysML v2, proporcionando una vía práctica para reducir el coste de modelado y mejorar la eficiencia del modelado. (2) Análisis sintáctico de tareas y validación dual. Introducimos un mecanismo de análisis árbol de tareas-estructura y un esquema dual de validación (sintaxis y semántica). En el análisis de tareas, los objetivos de modelado se descomponen jerárquicamente y formalizan en tarjetas de tareas estructuradas. Para la validación, el diagnóstico sintáctico utiliza un entorno oficial^{de validación 8} para comprobar el código generado y devolver diagnósticos orientados a la reparación, mientras que la validación semántica utiliza campos clave en las tarjetas de tareas como referencias para evaluar la consistencia general entre el modelo generado y los objetivos de modelado. (3) Evaluación experimental. Realizamos experimentos comparativos utilizando la tasa de error sintáctico y la puntuación de consistencia semántica como métricas principales. Los resultados muestran que MAS4SysML reduce la tasa media de error sintáctico a 2,63 y aumenta la similitud semántica a 0,91, superando a los métodos de referencia en precisión de generación y automatización.

Protocol

El proceso de generación de código del framework MAS4SysML se resume en el Archivo Suplementario 1. Cabe señalar que este estudio no pretende lograr la generación única de un modelo completo de sistema a partir de lenguaje natural con estricta consistencia cruzada, incluyendo requisitos, estructura, parámetros y comportamiento. En su lugar, el protocolo se centra en generar varios tipos representativos de código de vista SysML v2.

Fase I: Análisis de tareas
El flujo de trabajo comienza con el análisis de tareas. El sistema proporciona la intención de modelado en lenguaje natural al Agente de Generación de Estructuras de Tareas, que genera un conjunto de tarjetas de tareas. Para asegurar que las generaciones posteriores sean ejecutables y reproducibles, cada tarjeta de tarea debe incluir, como mínimo, (i) un identificador de tarea, (ii) relaciones de dependencia y (iii) información clave de modelado para la validación, como el objetivo de modelado, restricciones/condiciones de contorno, ranuras de parámetros y valores de instanciación, y las salidas esperadas. Esta etapa produce task_card_set, que sirve como base unificada para la generación posterior del código del modelo.

Fase II: Generación iterativa de código
En la generación iterativa, el sistema inicializa el contexto de código prev_code a un estado vacío y genera código para cada tarjeta de tarea secuencialmente según un orden determinado por los campos de dependencia. Para cada tarjeta de tarea, el Agente de Generación de Código toma la tarjeta de tarea actual y el código contextual como entrada para producir candidate_code y luego invoca inmediatamente el Módulo de Validación de Sintaxis para comprobarlo. El módulo valida el código utilizando el entorno oficial de validación SysML v2 y devuelve los resultados de diagnóstico. Si la validación tiene éxito, el candidate_code se utiliza para actualizar prev_code y soporta la generación posterior. Si la validación falla, se activa el Agente de Reparación de Código y realiza modificaciones mínimas y dirigidas guiadas por los diagnósticos devueltos, tras lo cual el código reparado se vuelve a enviar para su revalidación. Este bucle de revalidación de reparaciones está limitado por el presupuesto máximo de reparación K_máx. Si la validación tiene éxito dentro del presupuesto, la versión que pasa se actualiza prev_code; de lo contrario, tras K_{intentos máximos} , el sistema registra el fallo y continúa con la generación posterior de tarjetas de tareas usando la última versión reparada como prev_code para evitar bloquear el flujo de trabajo manteniendo la continuidad contextual.

Fase III: Validación semántica
Una vez generado el código para todas las tarjetas de tareas, el flujo de trabajo pasa a la validación semántica. El Agente de Validación Semántica evalúa la consistencia entre el código final y la intención de modelado utilizando campos clave en task_card_set como referencias y genera los resultados de la validación semántica. Si la validación tiene éxito, prev_code es aceptado como el código final del modelo SysML v2. De lo contrario, el sistema genera un Informe de Desviación Semántica que identifica los campos de la tarjeta de tarea no cumplidos y el alcance de revisión requerido. El Agente de Reparación de Código revisa entonces el código en consecuencia y genera el código del modelo revisado como resultado final.

Arquitectura y metodología del modelo
Arquitectura del modelo
El marco MAS4SysML, ilustrado en la Figura 1, comprende cuatro agentes colaborativos: el agente de generación de estructuras de tareas, el agente de generación de código, el agente de reparación de código y el agente de validación semántica. Las plantillas correspondientes de prompts se presentan en la Figura 2.

El agente generador de estructuras de tareas realiza un análisis semántico de la intención de modelado de entrada y genera tarjetas de tareas estructuradas y ejecutables. Primero aplica un mecanismo jerárquico de descomposición de tareas (véase mecanismo jerárquico de descomposición de tareas) para descomponer el objetivo global de modelado en nodos de tareas con límites semánticos bien definidos y luego construye una tarjeta de tarea estructurada para cada nodo. Posteriormente, las tarjetas de tarea se ordenan según sus campos de dependencia de modelado para asegurar que la secuencia de ejecución se alinee con la estructura de código final, sentando así las bases para la generación de código ascendente impulsada por el objetivo global de modelado.

El agente generador de código genera progresivamente código de modelo compatible con SysML v2 según las dependencias de modelado. Basándose en los artefactos de código producidos por las tareas padre, el agente realiza las operaciones correspondientes de generación de código basadas en los requisitos especificados en cada tarjeta de tarea, permitiendo así un proceso de construcción escalonado—desde los componentes locales hasta el modelo completo.

El agente de reparación de código corrige los errores en el código generado basándose en los resultados del módulo de validación sintáctica (véase módulo de validación sintáctica) y los resultados de la validación semántica. Para la reparación sintáctica, aprovecha el tipo de error, la posición y la información contextual devuelta por el validador sintáctico para sintetizar estrategias de reparación dirigidas y generar código corregido. Para la reparación semántica, ajusta las relaciones estructurales y lógicas según los resultados de la validación semántica, asegurando la consistencia semántica y la completitud estructural en el modelo final.

El agente de validación semántica evalúa la consistencia semántica entre el código completamente generado y las tarjetas de tareas utilizando un mecanismo dedicado de validación semántica (véase mecanismo de validación semántica). Mediante la evaluación cuantitativa, se asegura que el código generado refleje con precisión la intención original de modelado, logrando así una alineación precisa entre el código del modelo y los requisitos de modelado especificados.

Mecanismo jerárquico de descomposición de tareas
Como lenguaje formal de modelado para sistemas complejos, SysML v2 presenta una sintaxis estrechamente acoplada, estructuras jerárquicas profundamente anidadas y restricciones semánticas a varios niveles. Por ejemplo, un bloque de estructura del sistema puede contener múltiples subpartes, atributos y puertos mientras expresa simultáneamente requisitos de rendimiento o comportamiento mediante restricciones entre capas. Estas estructuras y restricciones crean dependencias estructurales de arriba hacia abajo y relaciones semánticas de retroalimentación de abajo hacia arriba. Con un enfoque plano y de generación única, mapear con precisión estas dependencias jerárquicas se vuelve complicado, lo que a menudo resulta en relaciones perdidas, inconsistencias semánticas o pérdida de información de restricciones.

Para abordar este desafío, desarrollamos un método de análisis de intenciones de modelado basado en árboles de tareas que descompone jerárquicamente los requisitos de modelado en lenguaje natural. Como se ilustra en la Figura 3, los objetivos complejos de modelado se descomponen en nodos de tarea estructurados y rastreables, lo que permite al sistema interpretar la semántica de modelado de forma ascendente e identificar relaciones de dependencia. Específicamente, cuando el agente de generación de estructuras de tareas recibe la entrada del usuario, primero aprovecha las capacidades de análisis semántico de los LLMs para identificar objetivos centrales de modelado, entidades clave y sus dependencias. Luego descompone recursivamente el objetivo de nivel superior en subtareas semánticamente independientes y las refina aún más en tareas atómicas que pueden mapearse directamente a operaciones de modelado SysML v2, formando finalmente un árbol completo de estructura de tareas. Una vez construido el árbol de tareas, el agente genera una tarjeta de tarea estructurada para cada nodo de tarea basada en una plantilla predefinida. El formato de la tarjeta de tarea se define de la siguiente manera:

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

Donde id es el identificador único del nodo de la tarea, O el objetivo de la tarea, N la descripción en lenguaje natural de la tarea, K denota los elementos semánticos principales de SysML v2 que pueden estar implicados en la tarea, incluyendo principalmente la definición de requisito/requisito, la definición de parte/parte, la defensa del puerto/puerto, la definición del elemento, la definición del atributo y la definición del atributo y el estado/transición. Las relaciones entre estos elementos se expresan principalmente a través de connect (conexiones estructurales), elementos de entrada/salida en puertos (flujos de información/material) y condiciones de disparo/guardia de transiciones de la máquina de estados (por ejemplo, comandos, estado de salud y restricciones de umbral), C como las reglas semánticas o condiciones de contorno, P como los espacios parametrizables dentro de la tarea, como nombres de atributos, tipos de datos o tipos compuestos, V como los valores instanciados para cada ranura y D como las dependencias de modelado entre tareas donde depend_on especifica las salidas requeridas de otras tareas antes de generar el código de tarea actual, proporciona denota las salidas producidas después de completar la tarea y consume las entradas externas requeridas por la tarea.

Módulo de validación de sintaxis
Se construye un módulo de validación sintáctica basado en la Implementación Piloto de SysML v2. Al invocar sus interfaces de analizador y validador, el módulo analiza y verifica la corrección sintáctica del código del modelo SysML v2 generado. Los criterios de validación del módulo derivan principalmente de la especificación del lenguaje SysML v2, así como de las reglas gramaticales, reglas de resolución de alcance y mecanismos relacionados de comprobación de restricciones implementados en la herramienta Pilot. Específicamente, la validación examina si las declaraciones de elementos están bien formadas, si las estructuras de bloques están completas, si las anotaciones de tipo son válidas, si los nombres y referencias pueden resolverse con éxito, y si los constructos de modelado como puertos, conexiones, estados y transiciones cumplen con los requisitos del lenguaje.

Después de que el agente generador de código produce el fragmento de código para la tarea actual, la salida se envía al módulo de validación sintáctica, donde el script de validación analiza el código y devuelve los resultados en forma de información diagnóstica estructurada. Los resultados de la validación se informan de la siguiente manera:

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

Donde e_i denota la lista de problemas detectados para la tarea de modelado actual, cada entrada contiene el tipo de error _{tipo i}, la ubicación del error _{pos i} y el mensaje de diagnóstico_{msg i} .

Por ejemplo, si el código generado contiene un error de sintaxis como "un atributo no está tipado por una definición de attributo", el módulo de validación devuelve el siguiente mensaje diagnóstico:

'tipo' : 'error'
'mensaje': 'ERROR: Un atributo debe ser tipado por definición de atributo.' (3)
'posición' : 'línea 7 columna: 3'

Cuando el resultado de validación e_i ≠ 0, la información de error recopilada e_i se envía al agente de reparación de código para su corrección adicional. Por lo tanto, el proceso de reparación del código no es un procedimiento de modificación sin restricciones, sino una revisión dirigida por la información diagnóstica explícita devuelta por el analizador y el validador.

Mecanismo de validación semántica
El mecanismo de validación semántica utiliza campos clave de tarjetas de tarea que tienen correspondencias explícitas y rastreables con el código del modelo como anclas semánticas. Evalúa la consistencia semántica a nivel de modelo, proporcionando así criterios explícitos y accionables para la reparación posterior del modelo. Específicamente, para cada tarjeta de tarea TC_i, se utilizan los siguientes campos como referencias semánticas clave: (i) el objetivo de modelado O_i, (ii) restricciones semánticas y condiciones de frontera C_i, (iii) valores instanciados de ranuras de parámetro V_i, y (iv) salidas esperadas tras completar la tarea _{D i}['proporcionar']. Estos campos imponen restricciones semánticas complementarias al modelo generado desde múltiples perspectivas: realización de la intención de modelado, satisfacción de restricciones, consistencia en la instanciación de parámetros y completitud de las salidas del modelo, permitiendo una decisión basada en principios sobre si el código del modelo cumple los requisitos de modelado sin requerir supuestos adicionales.

Basándonos en estos campos clave, definimos una función de decisión de consistencia semántica multicampo:

(4)

donde I(·) denota una función indicadora que es igual a 1 si se cumplen todas las funciones de subdecisión dentro de los paréntesis, y 0 en caso contrario. Esta decisión binaria distingue explícitamente entre los estados de satisfacción de los requisitos de modelado y los que requieren reparaciones adicionales, proporcionando una condición desencadenante determinista para el proceso semántico posterior de reparación. La decisión global está determinada conjuntamente por las siguientes cuatro funciones de subdecisión:

(1) Modelado de la consistencia objetivo:

Φ₀ (TC_{i,c f}) = I(consistir(_{c f,0 i})) (5)

donde Consist(c_{f,0 i}) indica si el código de modelo c_f es semánticamente consistente con el objetivo de modelado_{0 i} especificado en la tarjeta de tarea.

(2) Satisfacción de restricciones semánticas:

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

donde Satisfy(_{c f,C i}) indica si el código de modelo c_f satisface las restricciones semánticas y las condiciones de frontera C_i especificadas en la tarjeta de tarea.

(3) Consistencia de parámetros:

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

donde Instant(_{c f,V i}) indica si los valores instanciados del parámetro V_i en la tarjeta de tareas se reflejan de forma consistente en el código del modelo.

(4) Consistencia de la salida:

(8)

donde Artefacts(c_j) indica si las salidas esperadas por la tarjeta de tarea están presentes en el código final del modelo, sirviendo como medida de la completitud del resultado generado.

Estos juicios de consistencia son implementados por el Agente de Validación Semántica aprovechando la capacidad de comprensión semántica del LLM; El proceso de razonamiento interno del agente no altera la definición formal ni el uso de la función de consistencia.

Mediante esta comprobación de consistencia semántica multicampo, el modelo generado puede validarse campo por campo para asegurar que cada objetivo de modelado, condición de restricción, configuración de parámetros y salida esperada se cumpla adecuadamente. Este proceso no solo proporciona un disparador explícito para la reparación semántica posterior, sino que también proporciona evidencia semántica rastreable a lo largo de toda la cadena de generación, mejorando así la fiabilidad y consistencia del modelo generado.

Datos experimentales y evaluación
Datos experimentales
El código de modelo de SysML v2 no es código de software ordinario; sus artefactos generados exhiben características distintivas de modelado formal. Las diferentes vistas suelen implicar categorías distintas de elementos centrales de modelado, como requisitos, partes, puertos, atributos, estados y transiciones, que difieren sustancialmente en sus estilos de declaración, formas organizativas y estructuras composicionales. Además, el código del modelo debe cumplir múltiples restricciones, incluyendo la referencia de tipos, el anidamiento jerárquico, las restricciones de conexión y la reutilización semántica entre elementos.

Para evaluar de forma exhaustiva el rendimiento del método propuesto bajo diferentes complejos de modelado, se construye un conjunto de datos de código que cubre cinco tipos representativos de vistas de modelo: requisitos, casos de uso, estructura, paramétricas y máquinas de estados. Estas vistas del modelo corresponden a la especificación de requisitos, interacción funcional, composición estructural, representación de restricciones paramétricas y descripción lógica conductual en modelado de sistemas, respectivamente. Evaluar el marco por separado en diferentes tipos de vistas de modelo permite un análisis más detallado de su aplicabilidad bajo diversas características estructurales de código y condiciones de restricción de modelado.

Cada tipo de vista de modelo contiene 15 instancias de modelo creadas manualmente, resultando en un conjunto de datos de N = 75 modelos SysML v2. El conjunto de datos abarca múltiples dominios de ingeniería, incluyendo sistemas aeroespaciales, automotrices, médicos y de hogar inteligente, y todos los modelos superaron con éxito el entorno oficial de validación SysML v2, asegurando un estricto cumplimiento sintáctico.

Posteriormente, generamos una descripción correspondiente de la intención de modelado en lenguaje natural para cada modelo. Para mejorar la eficiencia constructiva, utilizamos la plantilla de prompt mostrada en el Archivo Suplementario 2 y empleamos GPT-4o para producir las descripciones iniciales. GPT-4o fue seleccionado por su fuerte comprensión semántica y capacidades de extracción de información, lo que le permite capturar con precisión elementos centrales del modelo sin alucinaciones y generar descripciones de intención de modelado similares a^{las humanas 9}. Para garantizar la precisión y eliminar ambigüedades, todas las descripciones generadas fueron revisadas y refinadas manualmente por investigadores con formación en ingeniería de sistemas. Ejemplos representativos para diferentes tipos de modelos se muestran en la Tabla 1.

Métricas de evaluación
Empleamos las siguientes tres métricas clave para evaluar la calidad del código del modelo SysML v2 generado:

Tasa media de error sintáctico (SER)
Esta métrica cuantifica la proporción de errores sintácticos detectados cuando el código del modelo generado se valida según las reglas sintácticas oficiales de SysML v2. Se calcula como:

(9)

donde E_i denota el número de errores sintácticos identificados en el i-ésimo modelo generado. Esta métrica refleja hasta qué punto el código del modelo generado se adhiere a la especificación sintáctica formal de SysML v2.

Puntuación de consistencia semántica (SCS)
Esta métrica evalúa cuán precisa y de forma completa captura el código del modelo generado la intención semántica expresada en las especificaciones de modelado en lenguaje natural. Específicamente, extraemos unidades semánticas de la intención de modelado —como entidades del sistema, componentes participantes, funciones centrales o escenarios de comportamiento, y condiciones o restricciones clave— y las comparamos con las unidades semánticas presentes en el código del modelo generado. La consistencia semántica se calcula como:

(10)

donde U representa el conjunto de unidades semánticas extraídas de la intención de modelado, y representa el conjunto de unidades semánticas identificadas en el código generado. indica el número de unidades capturadas correctamente por el código del modelo generado. Un valor de SCS más alto indica una mayor cobertura y alineación semántica.

Evaluación de la calidad humana
Las métricas automatizadas tradicionales como BLEU y CodeBLEU evalúan principalmente la similitud superficial o la ejecutabilidad del código, pero no capturan si el modelo realmente entiende o expresa correctamente la semántica de modelado prevista. Estas métricas están limitadas para evaluar la consistencia semántica, la completitud de los elementos clave y la alineación con la intención de^{modelado 10}. En cambio, la evaluación humana puede identificar con mayor precisión problemas como elementos semánticos ausentes, inconsistencias lógicas, redundancia estructural o alucinaciones no fundamentadas, proporcionando así una evaluación más fiable¹¹. Motivados por estas limitaciones, diseñamos un marco de evaluación humana para modelos SysML v2 generados que consta de tres criterios: (1) Corrección: el modelo generado debe reflejar con precisión la intención de modelado, mantener la coherencia estructural y lógica con los objetivos de la tarea, y no contener ambigüedades semánticas, elementos ausentes ni extensiones erróneas. (2) Legibilidad: el código del modelo debe ser claro y fácil de entender, con nombres consistentes, estructura coherente y una jerarquía bien organizada que permita la inspección y el mantenimiento posterior. (3) Integridad: el modelo debe mostrar lógica estructural completa, referencias consistentes entre elementos y sin tipos indefinidos ni cadenas de dependencias rotas, asegurando su utilidad para análisis e integración posteriores. Invitamos a investigadores con experiencia en modelado SysML a puntuar cada modelo generado en una escala de tres puntos, donde 1 indica la menor calidad y 3 la más alta. Durante la evaluación, se permitió a los evaluadores comparar el código del modelo generado con el modelo de precisión sobre el terreno para asegurar una evaluación más precisa y completa.

Línea base
Seleccionamos múltiples líneas de evaluación para pruebas comparativas con el método propuesto, incluyendo:
CodeCoT¹²: Combina razonamiento en cadena de pensamiento con un mecanismo de autoverificación, permitiendo que el modelo razone explícitamente durante la generación y autocorrija errores sintácticos, mejorando así la calidad del código y la consistencia semántica.

Autoplanificación¹³: Introduce una cadena de generación de código en dos etapas en la que el modelo primero planifica los pasos de la solución y luego genera código según el plan, mejorando eficazmente la coherencia lógica y la interpretabilidad para tareas complejas.

Autoedición¹⁴: Adopta un paradigma iterativo de generación y edición que ejecuta el código generado y corrige automáticamente los errores basándose en la retroalimentación en tiempo de ejecución, refinando continuamente la salida.
^{CodeChain 15}: Utiliza generación modular y revisión iterativa descomponiendo tareas complejas en módulos funcionales independientes y mejorando la solidez estructural y la calidad general mediante múltiples rondas de optimización.

^{Autodepuración 16}: Dota al modelo de capacidades autónomas de depuración y explicación. Mediante un proceso de ciclo cerrado de generación, ejecución y depuración, mejora sustancialmente la corrección en tareas de programación complejas sin intervención humana.

MapCoder¹⁷: Construye un marco colaborativo de varias etapas compuesto por cuatro agentes—recuperación, planificación, codificación y depuración—que simulan estrechamente el flujo de trabajo de programación humana y permiten la generación en bucle cerrado desde la comprensión de tareas hasta la verificación de resultados.

Autocolaboración¹⁸: Organiza el sistema como un equipo de programación virtual con roles como analista, programador y tester, mejorando el rendimiento general en la generación de código complejo mediante colaboración basada en roles y retroalimentación iterativa.

Montaje experimental
Para garantizar la equidad y la comparabilidad entre experimentos, primero evaluamos varios LLMs convencionales utilizando un enfoque de generación directa de código para establecer el rendimiento base. A partir de estos resultados iniciales, se seleccionó el LLM con mejor rendimiento como modelo unificado de columna vertebral para todos los experimentos posteriores. Posteriormente comparamos el marco propuesto de MAS4SysML con múltiples métodos de generación de código representativo. Todas las interacciones con LLM se realizaron usando una temperatura fija (T = 0,2) para minimizar la aleatoriedad durante la generación. Para cada tarea de modelado, el número máximo de iteraciones de reparación en MAS4SysML se estableció a K_máximo = 3. Todos los métodos de referencia se ejecutaron bajo la misma configuración experimental que MAS4SysML para garantizar la consistencia de los resultados y la equidad experimental. El script en Python del método MAS4SysML se proporciona como Archivo Suplementario 3.

Results

Evaluación del modelo de referencia
Primero seleccionamos varios LLMs convencionales y realizamos pruebas preliminares de rendimiento utilizando generación directa modelo a código, incluyendo CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)²², Incoder(6.7B)²³ y code-davinci-002(175B)²⁴. Como se muestra ...

Discussion

Proponemos MAS4SysML, un marco colaborativo multiagente para la generación de código de modelos SysML v2 semiautomatizados. El marco consta de cuatro agentes funcionalmente complementarios. Durante la generación, (i) descompone jerárquicamente los requisitos de modelado en lenguaje natural utilizando una estructura basada en árboles de tareas y los formaliza en tarjetas de tareas estructuradas, y (ii) genera código de modelo SysML v2 de forma ascendente, guiado por las restricciones y re...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (proyecto de código abierto)	v1.0.8; https://github.com/langchain-ai/langchain	Marco para la interacción con LLM y la orquestación de agentes
LangGraph	LangChain (proyecto de código abierto)	v1.0.3; https://github.com/langchain-ai/langgraph	Marco de ejecución de flujo de trabajo multiagente
Python	Fundación de Software Python	3.10.x; https://www.python.org/downloads/release/python-3100/	Lenguaje de programación principal para la implementación de MAS4SysML
Implementación piloto de SysML v2	Grupo de Gestión de Objetos (OMG)	(proporcionar versión de liberación/etiqueta); https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Utilizado para validación de sintaxis y análisis de modelos