MAS4SysML: Uma Estrutura Multi-Agente para Geração de Modelos SysML v2 a partir de Linguagem Natural

Summary

Este protocolo apresenta o MAS4SysML, uma abordagem multi-agente que gera automaticamente código SysML v2 por meio de divisão coordenada de tarefas, exigindo poucas iterações de reparo e reduzindo significativamente o tempo de modelagem manual, além de melhorar a eficiência da modelagem do sistema.

Abstract

Gerar automaticamente modelos SysML precisos a partir de requisitos de linguagem natural pode acelerar substancialmente a adoção da Engenharia de Sistemas Baseada em Modelos (MBSE) no desenvolvimento de sistemas complexos. No entanto, usar grandes modelos de linguagem (LLMs) para gerar código de modelo frequentemente não atende às restrições sintáticas rigorosas das linguagens formais de modelagem, e garantir consistentemente o alinhamento semântico entre modelos gerados e requisitos continua sendo um desafio. Para enfrentar esses desafios, este artigo apresenta o MAS4SysML, uma estrutura colaborativa multiagente para geração de código SysML v2 que melhora a correção sintática e a consistência semântica sob um orçamento de reparo restrito. A estrutura decompõe uma tarefa de modelagem em subtarefas hierárquicas, formaliza-as como cartões de tarefas estruturadas e gera código modelo de forma de baixo para cima. Durante a geração, um ambiente oficial de validação é usado para diagnósticos de sintaxe; Após a conclusão, o framework verifica a consistência semântica entre o código e os cartões de tarefa. Se a validação sintática ou semântica falhar, o framework repara e revalida iterativamente o código dentro de um orçamento de reparo pré-definido, guiado por feedback diagnóstico, até que os critérios de validação sejam atendidos ou o orçamento seja esgotado. Para avaliar o método proposto, construímos um conjunto de dados SysML v2 abrangendo cinco tipos principais de tarefas — requisitos, casos de uso, estrutura, paramétricas e máquinas de estados — e realizamos experimentos comparativos. Os resultados mostram que o MAS4SysML reduz a taxa média de erro sintático para 2,63, aumenta a similaridade semântica para 0,91 e supera os métodos de geração de código existentes no geral.

Introduction

O MBSE tornou-se uma metodologia chave para análise de requisitos, design de arquitetura de sistemas e planejamento de verificação no desenvolvimento de equipamentos complexos em domínios como aviação e^{aeroespacial 1}. Utilizando linguagens de modelagem unificadas como SysML como espinha dorsal de modelagem, informações — incluindo requisitos, estrutura, comportamento e restrições — podem ser organizadas em uma estrutura de modelo coerente, melhorando a estrutura do processo e a eficiência da colaboração interdisciplinar². No entanto, à medida que a escala do sistema continua crescendo, o número de modelos que precisam ser desenvolvidos aumenta de acordo, levando a um aumento sustentado na carga de trabalho da modelagem manual em SysML. Além disso, os modeladores devem trabalhar sob restrições sintáticas e metodológicas rigorosas, que exigem expertise substancial e fortes capacidades de abstração. Esses fatores se tornaram um grande gargalo na adoção do MBSE³ em engenharia.

Nos últimos anos, os LLMs demonstraram fortes capacidades em compreensão de linguagem natural, representação estruturada de informações e geração de código, possibilitando novas oportunidades para automatizar a modelagem MBSE da linguagem natural para o código^{modelo 4}. Estudos anteriores exploraram a geração direta de código modelo SysML usando^{LLMs 5}. No entanto, desafios significativos permanecem. Sintaticamente, o sistema de tipos, os mecanismos de escopo e a semântica de referência do SysML são regidos por restrições formais estritas e frequentemente são mais complexos do que os das linguagens de programação de uso^{geral 6}. Semanticamente, LLMs podem falhar em capturar totalmente a lógica comportamental, relacionamentos estruturais e restrições entre camadas, resultando em relações ausentes, inconsistências lógicas ou modelos^{incompletos 7}. Essas limitações dificultam a confiabilidade, controlabilidade e interpretabilidade das abordagens de geração direta.

Para enfrentar esses desafios, este artigo apresenta o MAS4SysML, um framework de geração de código SysML v2 composto por quatro papéis de agente. Em vez de direcionar diretamente a geração one-shot de um modelo completo de sistema cross-view, este estudo foca em gerar e reparar iterativamente múltiplas tarefas representativas de modelagem SysML v2. Impulsionado pela decomposição de tarefas e cartões de tarefas estruturados, integrando geração de código, diagnóstico de sintaxe em nível de ferramenta e verificação de consistência semântica, o MAS4SysML estabelece um fluxo de trabalho em ciclo fechado de geração, validação e reparo. Esse design melhora a correção sintática, consistência semântica e completude estrutural do código gerado sob um orçamento de reparo restrito.

As principais contribuições são resumidas da seguinte forma: (1) framework MAS4SysML. Propomos o MAS4SysML, uma estrutura multiagente orientada por LLM que permite a geração de ponta a ponta, desde requisitos em linguagem natural até código executável de modelos SysML v2, oferecendo um caminho prático para reduzir custos de modelagem e melhorar a eficiência da modelagem. (2) Análise sintática de tarefas e validação dupla. Introduzimos um mecanismo de análise sintática de estrutura de tarefas-árvore e um esquema dual de validação (sintaxe e semântica). Na análise sintática de tarefas, os objetivos de modelagem são decompostos hierarquicamente e formalizados em cartões de tarefa estruturados. Para validação, diagnósticos sintáticos utilizam um ambiente oficial^{de validação 8} para verificar o código gerado e retornar diagnósticos orientados a reparo, enquanto a validação semântica utiliza campos-chave nos cartões de tarefas como referências para avaliar a consistência geral entre o modelo gerado e os objetivos de modelagem. (3) Avaliação experimental. Realizamos experimentos comparativos usando a taxa de erro sintático e a pontuação de consistência semântica como métricas principais. Os resultados mostram que o MAS4SysML reduz a taxa média de erro sintático para 2,63 e aumenta a similaridade semântica para 0,91, superando os métodos de linha básica em precisão de geração e automação.

Protocol

O processo de geração de código do framework MAS4SysML é resumido no Arquivo Suplementar 1. Deve-se notar que este estudo não visa alcançar a geração única de um modelo completo de sistema a partir de linguagem natural com consistência estrita em visão cruzada, incluindo requisitos, estrutura, parâmetros e comportamento. Em vez disso, o protocolo foca em gerar vários tipos representativos de código de visualização SysML v2.

Fase I: Análise de tarefas
O fluxo de trabalho começa com a análise das tarefas. O sistema fornece a intenção de modelagem em linguagem natural para o Agente de Geração de Estrutura de Tarefas, que gera um conjunto de fichas de tarefa. Para garantir que as gerações subsequentes sejam executáveis e reprodutíveis, cada cartão de tarefa deve incluir, no mínimo, (i) um identificador de tarefa, (ii) relações de dependência e (iii) informações de modelagem chave para validação, como o objetivo de modelagem, restrições/condições de contorno, slots de parâmetros e valores de instanciação, e as saídas esperadas. Essa etapa produz task_card_set, que serve como base unificada para a geração subsequente de código do modelo.

Fase II: Geração iterativa de código
Na geração iterativa, o sistema inicializa o contexto de código prev_code a um estado vazio e gera código para cada cartão de tarefa sequencialmente, de acordo com uma ordem determinada pelos campos de dependência. Para cada cartão de tarefa, o Agente de Geração de Código recebe o cartão de tarefa atual e o código contextual como entrada para produzir candidate_code e então imediatamente invoca o Módulo de Validação de Sintaxe para verificação. O módulo valida o código usando o ambiente oficial de validação SysML v2 e retorna os resultados do diagnóstico. Se a validação for bem-sucedida, o candidate_code é usado para atualizar prev_code e suporta gerações subsequentes. Se a validação falhar, o Agente de Reparo de Código é acionado e realiza edições mínimas e direcionadas guiadas pelos diagnósticos retornados, após o que o código reparado é reenviado para revalidação. Esse ciclo de revalidação de reparo é limitado pelo orçamento máximo de reparo K_máx. Se a validação for bem-sucedida dentro do orçamento, a versão aprovada é atualizada prev_code; caso contrário, após tentativas de K_max , o sistema registra a falha e continua com a geração subsequente do cartão de tarefa usando a última versão reparada como prev_code para evitar bloquear o fluxo de trabalho mantendo a continuidade contextual.

Fase III: Validação semântica
Após o código ser gerado para todos os cartões de tarefa, o fluxo de trabalho segue para a validação semântica. O Agente de Validação Semântica avalia a consistência entre o código final e a intenção de modelagem usando campos-chave em task_card_set como referências e gera os resultados da validação semântica. Se a validação for bem-sucedida, prev_code é aceito como o código final do modelo SysML v2. Caso contrário, o sistema gera um Relatório de Desvio Semântico que identifica campos de cartão-tarefa não cumpridos e o escopo de revisão necessário. O Agente de Reparação de Código então revisa o código conforme e gera o código do modelo revisado como resultado final.

Arquitetura e metodologia do modelo
Arquitetura do modelo
O framework MAS4SysML, ilustrado na Figura 1, compreende quatro agentes colaborativos: o agente de geração de estrutura de tarefas, o agente de geração de código, o agente de reparação de código e o agente de validação semântica. Os modelos correspondentes de prompts são apresentados na Figura 2.

O agente de geração de estrutura de tarefa realiza análise semântica da intenção de modelagem de entrada e gera cartões de tarefas estruturados e executáveis. Primeiro, ele aplica um mecanismo hierárquico de decomposição de tarefas (veja mecanismo hierárquico de decomposição de tarefas) para decompor o objetivo geral da modelagem em nós de tarefa com limites semânticos bem definidos e, em seguida, constrói um cartão de tarefa estruturado para cada nó. Subsequentemente, os cartões de tarefa são ordenados de acordo com seus campos de dependência de modelagem para garantir que a sequência de execução esteja alinhada com a estrutura de código eventual, estabelecendo assim a base para a geração de código de baixo para cima guiada pelo objetivo global de modelagem.

O agente de geração de código gera progressivamente código de modelo compatível com SysML v2 de acordo com as dependências de modelagem. A partir dos artefatos de código produzidos pelas tarefas pais, o agente executa as operações correspondentes de geração de código com base nos requisitos especificados em cada cartão de tarefa, permitindo assim um processo de construção por etapas — dos componentes locais até o modelo completo.

O agente de reparo de código corrige erros no código gerado com base nos resultados do módulo de validação sintática (veja módulo de validação sintática) e nos resultados de validação semântica. Para reparação sintática, ele utiliza o tipo de erro, a posição e as informações contextuais retornadas pelo validador sintático para sintetizar estratégias de reparo direcionadas e gerar código corrigido. Para reparação semântica, ajusta as relações estruturais e lógicas de acordo com os resultados da validação semântica, garantindo consistência semântica e completude estrutural no modelo final.

O agente de validação semântica avalia a consistência semântica entre o código totalmente gerado e os cartões de tarefa usando um mecanismo dedicado de validação semântica (veja mecanismo de validação semântica). Por meio da avaliação quantitativa, garante que o código gerado reflita com precisão a intenção original de modelagem, alcançando assim um alinhamento exato entre o código do modelo e os requisitos de modelagem especificados.

Mecanismo hierárquico de decomposição de tarefas
Como uma linguagem formal de modelagem para sistemas complexos, o SysML v2 apresenta sintaxe fortemente acoplada, estruturas hierárquicas profundamente aninhadas e restrições semânticas entre níveis. Por exemplo, um bloco estrutural de sistema pode conter múltiplas subpartes, atributos e portas enquanto simultaneamente expressa requisitos de desempenho ou comportamentais por meio de restrições entre camadas. Essas estruturas e restrições criam dependências estruturais de cima para baixo e relações semânticas de feedback de baixo para cima. Com uma abordagem plana e de geração de um único uso, mapear com precisão tais dependências hierárquicas torna-se desafiador, frequentemente resultando em relações ausentes, inconsistências semânticas ou perda de informações de restrições.

Para enfrentar esse desafio, desenvolvemos um método de análise de intenção de modelagem baseado em árvores de tarefas, que decompõe hierarquicamente os requisitos de modelagem em linguagem natural. Como ilustrado na Figura 3, objetivos complexos de modelagem são decompostos em nós de tarefa estruturados e rastreáveis, permitindo que o sistema interprete a semântica de modelagem de forma top-down e identifique relações de dependência. Especificamente, quando o agente de geração de estrutura de tarefas recebe a entrada do usuário, ele primeiro utiliza as capacidades de análise semântica dos LLMs para identificar objetivos centrais de modelagem, entidades-chave e suas dependências. Em seguida, decompõe recursivamente o objetivo principal em subtarefas semanticamente independentes e as refina ainda mais em tarefas atômicas que podem ser mapeadas diretamente para operações de modelagem SysML v2, formando, em última análise, uma árvore completa de estrutura de tarefas. Após a construção da árvore de tarefas, o agente gera um cartão de tarefa estruturado para cada nó de tarefa baseado em um modelo pré-definido. O formato do cartão de tarefa é definido da seguinte forma:

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

Onde id é o identificador único do nó da tarefa, O é o objetivo da tarefa, N é a descrição em linguagem natural da tarefa, K denota os elementos semânticos centrais do SysML v2 que podem estar envolvidos na tarefa, incluindo principalmente definição de requisito/requisito, def/parte de parte, def de porta/porta, def de item, def de atributo e estado/transição. As relações entre esses elementos são expressas principalmente por meio de conexão (conexões estruturais), itens de entrada/saída nas portas (fluxos de informação/material) e condições de gatilho/guarda de transições da máquina de estados (por exemplo, comandos, status de saúde e restrições de limiar), C como as regras semânticas ou condições de contorno, P como os espaços parametrizáveis dentro da tarefa, como nomes de atributos, tipos de dados ou tipos compostos, V como os valores instanciados para cada slot e D como as dependências de modelagem entre tarefas, onde depend_on especifica as saídas necessárias de outras tarefas antes de gerar o código atual da tarefa, fornece denota as saídas produzidas após a conclusão da tarefa e consome representa entradas externas exigidas pela tarefa.

Módulo de validação de sintaxe
Um módulo de validação de sintaxe é construído com base na Implementação Piloto do SysML v2. Ao invocar suas interfaces de parser e validador, o módulo analisa e verifica a correção sintática do código do modelo SysML v2 gerado. Os critérios de validação do módulo são derivados principalmente da especificação da linguagem SysML v2, bem como das regras gramaticais, regras de resolução de escopo e mecanismos relacionados de verificação de restrições implementados na ferramenta Pilot. Especificamente, a validação examina se declarações de elementos são bem formadas, se as estruturas de blocos estão completas, se as anotações de tipo são válidas, se nomes e referências podem ser resolvidos com sucesso e se construtos de modelagem como portas, conexões, estados e transições cumprem os requisitos da linguagem.

Após o agente de geração de código produzir o fragmento de código para a tarefa atual, a saída é encaminhada para o módulo de validação sintaxe, onde o script de validação analisa o código e retorna os resultados na forma de informações diagnósticas estruturadas. Os resultados da validação são reportados da seguinte forma:

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

Onde e_i denota a lista de problemas detectados para a tarefa de modelagem atual, cada entrada contendo o tipo de erro _{tipo i}, localização do erro _{pos i} e mensagem de diagnóstico _i .

Por exemplo, se o código gerado contém um erro de sintaxe como "um atributo não é tipado por uma definição de atributo", o módulo de validação retorna a seguinte mensagem de diagnóstico:

'tipo' : 'erro'
'mensagem': 'ERRO: Um atributo deve ser tipado pela definição de atributo.' (3)
'posição' : 'linha 7 coluna: 3'

Quando o resultado de validação e_i ≠ 0, as informações de erro coletadas e_i são encaminhadas ao agente de reparação de código para correção adicional. Portanto, o processo de reparo de código não é um procedimento de modificação sem restrições, mas uma revisão direcionada guiada pelas informações diagnósticas explícitas retornadas pelo parser e validador.

Mecanismo de validação semântica
O mecanismo de validação semântica usa campos de cartão-chave que têm correspondências explícitas e rastreáveis ao código do modelo como âncoras semânticas. Ele avalia a consistência semântica no nível do modelo, fornecendo assim critérios explícitos e acionáveis para o reparo subsequente do modelo. Especificamente, para cada cartão de tarefa TC_i, os seguintes campos são usados como referências semânticas chave: (i) o objetivo de modelagem O_i, (ii) restrições semânticas e condições de contorno C_i, (iii) valores instanciados de slot de parâmetro V_i, e (iv) saídas esperadas após a conclusão da tarefa_{D i}['providenciar']. Esses campos impõem restrições semânticas complementares ao modelo gerado sob múltiplas perspectivas: realização da intenção de modelagem, satisfação de restrições, consistência da instanciação de parâmetros e completude dos resultados do modelo — permitindo uma decisão baseada em princípios sobre se o código do modelo satisfaz os requisitos de modelagem sem exigir suposições extras.

Com base nesses campos-chave, definimos uma função de decisão de consistência semântica multi-campo:

(4)

onde I(·) denota uma função indicadora que é igual a 1 se todas as funções de subdecisão dentro dos parênteses forem válidas, e 0 caso contrário. Essa decisão binária distingue explicitamente entre os estados de satisfação dos requisitos de modelagem e a necessidade de reparo adicional, fornecendo uma condição determinística de gatilho para o processo semântico subsequente de reparação. A decisão geral é determinada conjuntamente pelas seguintes quatro funções subdecisoras:

(1) Modelagem da consistência dos objetivos:

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

onde Consist(c_{f,0 i}) indica se o código de modelo c_f é semanticamente consistente com o objetivo de modelagem_{0 i} especificado no cartão de tarefa.

(2) Satisfação de restrições semânticas:

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

onde Satisfy(_{c f,C i}) indica se o código de modelo c_f satisfaz as restrições semânticas e condições de contorno C_i especificadas na ficha de tarefa.

(3) Consistência de parâmetros:

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

onde Instant(_{c f,V i}) indica se os valores instanciados do parâmetro V_i no cartão de tarefas são refletidos consistentemente no código do modelo.

(4) Consistência da saída:

(8)

onde Artefatos(c_j) indica se as saídas esperadas pela ficha de tarefa estão presentes no código final do modelo, servindo como medida da completude do resultado gerado.

Esses julgamentos de consistência são implementados pelo Agente de Validação Semântica aproveitando a capacidade de compreensão semântica do LLM; O processo interno de raciocínio do agente não altera a definição formal ou o uso da função de consistência.

Por meio dessa verificação de consistência semântica multi-campo, o modelo gerado pode ser validado campo por campo para garantir que cada objetivo de modelagem, condição de restrição, configuração de parâmetros e resultado esperado seja adequadamente satisfecida. Esse processo não apenas fornece um gatilho explícito para reparos semânticos subsequentes, mas também fornece evidências semânticas rastreáveis ao longo de toda a pipeline de geração, melhorando assim a confiabilidade e consistência do modelo gerado.

Dados experimentais e avaliação
Dados experimentais
O código do modelo SysML v2 não é código de software comum; seus artefatos gerados exibem características distintas da modelagem formal. Diferentes visões normalmente envolvem categorias distintas de elementos centrais de modelagem, como requisitos, partes, portas, atributos, estados e transições, que diferem substancialmente em seus estilos de declaração, formas organizacionais e estruturas composicionais. Além disso, o código do modelo deve satisfazer múltiplas restrições, incluindo referência de tipos, aninhamento hierárquico, restrições de conexão e reutilização semântica entre os elementos.

Para avaliar de forma abrangente o desempenho do método proposto sob diferentes complexidades de modelagem, é construído um conjunto de dados de código cobrindo cinco tipos representativos de visualização de modelo — requisitos, casos de uso, estrutura, paramétricas e máquinas de estados. Essas visões de modelo correspondem à especificação de requisitos, interação funcional, composição estrutural, representação de restrições paramétricas e descrição de lógica comportamental em modelagem de sistemas, respectivamente. Avaliar o framework separadamente em diferentes tipos de visualização de modelo permite uma análise mais detalhada de sua aplicabilidade sob diversas características estruturais de código e condições de restrições de modelagem.

Cada tipo de visualização de modelo contém 15 instâncias de modelo criadas manualmente, resultando em um conjunto de dados de N = 75 modelos SysML v2. O conjunto de dados abrange múltiplos domínios de engenharia, incluindo aeroespacial, automotivo, médico e sistemas domésticos inteligentes, e todos os modelos passaram com sucesso no ambiente oficial de validação SysML v2, garantindo rigorosa conformidade sintática.

Posteriormente, geramos uma descrição correspondente da intenção de modelagem em linguagem natural para cada modelo. Para melhorar a eficiência da construção, usamos o modelo de prompt mostrado no Arquivo Suplementar 2 e empregamos GPT-4o para produzir as descrições iniciais. O GPT-4o foi selecionado por sua forte compreensão semântica e capacidades de extração de informações, permitindo capturar com precisão elementos centrais do modelo sem alucinações e gerar descrições de intenção de modelagem semelhantes às^{humanas 9}. Para garantir precisão e eliminar ambiguidades, todas as descrições geradas foram revisadas e refinadas manualmente por pesquisadores com formação em engenharia de sistemas. Exemplos representativos para diferentes tipos de modelos são mostrados na Tabela 1.

Métricas de avaliação
Empregamos as seguintes três métricas-chave para avaliar a qualidade do código do modelo SysML v2 gerado:

Taxa média de erro sintático (SER)
Essa métrica quantifica a proporção de erros sintáticos detectados quando o código do modelo gerado é validado contra as regras oficiais da sintaxe SysML v2. Ele é calculado como:

(9)

onde E_i denota o número de erros sintáticos identificados no i-ésimo modelo gerado. Essa métrica reflete até que ponto o código do modelo gerado adere à especificação formal da sintaxe SysML v2.

Pontuação de consistência semântica (SCS)
Essa métrica avalia quão precisa e abrangente o código do modelo gerado captura a intenção semântica expressa nas especificações de modelagem em linguagem natural. Especificamente, extraímos unidades semânticas da intenção de modelagem — como entidades do sistema, componentes participantes, funções centrais ou cenários comportamentais, e condições ou restrições chave — e as comparamos com as unidades semânticas presentes no código do modelo gerado. A consistência semântica é calculada como:

(10)

onde U representa o conjunto de unidades semânticas extraídas da intenção de modelagem, e representa o conjunto de unidades semânticas identificadas no código gerado. indica o número de unidades corretamente capturadas pelo código do modelo gerado. Um valor SCS mais alto indica uma cobertura semântica e alinhamento mais fortes.

Avaliação da qualidade humana
Métricas automatizadas tradicionais, como BLEU e CodeBLEU, avaliam principalmente similaridade superficial ou executabilidade de código, mas não capturam se o modelo realmente entende ou expressa corretamente a semântica pretendida de modelagem. Essas métricas são limitadas na avaliação da consistência semântica, completude dos elementos-chave e alinhamento com a intenção de^{modelagem 10}. Em contraste, a avaliação humana pode identificar com mais precisão questões como elementos semânticos ausentes, inconsistências lógicas, redundância estrutural ou alucinações não fundamentadas, fornecendo assim uma avaliação mais^{confiável 11}. Motivados por essas limitações, projetamos uma estrutura de avaliação humana para modelos SysML v2 gerados, consistindo em três critérios: (1) Correção: o modelo gerado deve refletir com precisão a intenção da modelagem, manter consistência estrutural e lógica com os objetivos da tarefa, e não conter ambiguidade semântica, elementos ausentes ou extensões errôneas. (2) Legibilidade: o código do modelo deve ser claro e fácil de entender, com nomeação consistente, estrutura coerente e uma hierarquia bem organizada que suporte inspeção e manutenção subsequente. (3) Integridade: o modelo deve apresentar lógica estrutural completa, referências consistentes entre elementos e sem tipos indefinidos ou cadeias de dependências quebradas, garantindo sua usabilidade para análise e integração posteriores. Convidamos pesquisadores com experiência em modelagem SysML para pontuar cada modelo gerado em uma escala de três pontos, onde 1 indica a menor qualidade e 3 a mais alta. Durante a avaliação, os avaliadores puderam comparar o código do modelo gerado com o modelo de verdade para garantir uma avaliação mais precisa e abrangente.

Linha base
Selecionamos múltiplas linhas de avaliação para testes comparativos com o método proposto, incluindo:
CodeCoT¹²: Combina raciocínio em cadeia de pensamento com um mecanismo de auto-verificação, permitindo que o modelo raciocine explicitamente durante a geração e auto-corriga erros sintáticos, melhorando assim a qualidade do código e a consistência semântica.

^{Auto-planejamento 13}: Introduz um pipeline de geração de código em duas etapas, no qual o modelo primeiro planeja as etapas da solução e depois gera código de acordo com o plano, aumentando efetivamente a coerência lógica e a interpretabilidade para tarefas complexas.

Autoedição¹⁴: Adota um paradigma iterativo de gerar e editar que executa o código gerado e corrige automaticamente os erros com base no feedback em tempo de execução, refinando continuamente a saída.
^{CodeChain 15}: Utiliza geração modular e revisão iterativa ao decompondo tarefas complexas em módulos funcionais independentes e melhorando a solidez estrutural e a qualidade geral por meio de múltiplas rodadas de otimização.

Autodepuração¹⁶: Dota o modelo de capacidades autônomas de depuração e explicação. Por meio de um processo em loop fechado de geração, execução e depuração, ele melhora substancialmente a correção em tarefas complexas de programação sem intervenção humana.

MapCoder¹⁷: Constrói uma estrutura colaborativa em múltiplas etapas composta por quatro agentes — recuperação, planejamento, codificação e depuração — simulando de perto o fluxo de trabalho de programação humana e possibilitando a geração em ciclo fechado desde a compreensão da tarefa até a verificação de resultados.

Auto-Colaboração¹⁸: Organiza o sistema como uma equipe de programação virtual com funções como analista, programador e testador, melhorando o desempenho geral na geração de código complexo por meio de colaboração baseada em papéis e feedback iterativo.

Configuração experimental
Para garantir justiça e comparabilidade entre experimentos, primeiro avaliamos vários LLMs tradicionais usando uma abordagem de geração direta de código para estabelecer o desempenho base. Com base nesses resultados iniciais, o LLM de melhor desempenho foi selecionado como modelo unificado de espinha dorsal para todos os experimentos subsequentes. Posteriormente, comparamos o framework proposto MAS4SysML com múltiplos métodos representativos de geração de código. Todas as interações com LLM foram realizadas usando uma temperatura fixa (T = 0,2) para minimizar a aleatoriedade durante a geração. Para cada tarefa de modelagem, o número máximo de iterações de reparo no MAS4SysML foi definido como K_máximo = 3. Todos os métodos de linha base foram executados sob a mesma configuração experimental do MAS4SysML para garantir consistência dos resultados e justiça experimental. O script em Python do método MAS4SysML é fornecido como Arquivo Suplementar 3.

Results

Avaliação do modelo de referência
Primeiro selecionamos vários LLMs convencionais e realizamos testes preliminares de desempenho usando geração direta de modelo para código, incluindo CodeX(175B)¹⁹, CodeGen-Mono(16.1B)²⁰, PaLM Coder(62B)²¹, Alphacode(1.1B)²², Incoder(6.7B)²³ e code-davinci-002(175B)²⁴. Como mostrado na...

Discussion

Propomos o MAS4SysML, uma estrutura colaborativa multiagente para geração semi-automatizada de código de modelos SysML v2. A estrutura consiste em quatro agentes funcionalmente complementares. Durante a geração, ela (i) decompõe hierarquicamente os requisitos de modelagem em linguagem natural usando uma estrutura baseada em árvores de tarefas e os formaliza em cartões de tarefas estruturados, e (ii) gera código de modelo SysML v2 de forma ascendente, guiado pelas restrições e relações de...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
LangChain	LangChain (projeto de código aberto)	v1.0.8; https://github.com/langchain-ai/langchain	Estrutura para interação com LLM e orquestração de agentes
LangGraph	LangChain (projeto de código aberto)	v1.0.3; https://github.com/langchain-ai/langgraph	Framework de execução de workflow multi-agente
Python	Fundação de Software Python	3.10.x; https://www.python.org/downloads/release/python-3100/	Principal linguagem de programação para implementação do MAS4SysML
Implementação Piloto do SysML v2	Grupo de Gerenciamento de Objetos (OMG)	(fornecer versão de liberação/tag); https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	Usado para validação de sintaxe e análise de modelos