← Últimos artigos
💻 computer science

NOMAD: A Multi-Agent LLM System for UML Class Diagram Generation from Natural Language Requirements

O artigo apresenta o NOMAD, um framework modular multiagente que supera as bases existentes na geração de diagramas de classe UML a partir de linguagem natural ao decompor a tarefa em subtarefas especializadas, ao mesmo tempo em que estabelece a primeira taxonomia sistemática de erros nesse domínio e avalia estratégias de verificação.

Autores originais: Polydoros Giannouris, Sophia Ananiadou

Publicado 2026-05-04
📖 5 min de leitura🧠 Leitura aprofundada

Autores originais: Polydoros Giannouris, Sophia Ananiadou

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando construir um castelo complexo de Lego baseado apenas em uma descrição escrita de um amigo. Se você pedir a um único robô muito inteligente para ler a descrição e construir todo o castelo de uma vez, ele pode ficar sobrecarregado. Ele pode esquecer um tijolo específico, confundir duas torres semelhantes ou construir uma ponte onde deveria haver uma parede.

Este é o problema que os pesquisadores da Universidade de Manchester enfrentaram ao tentar usar Inteligência Artificial (IA) para transformar requisitos de software escritos em Diagramas de Classes UML. Esses diagramas são como plantas baixas para software, mostrando como diferentes partes (classes) se conectam entre si.

Veja como eles resolveram isso com seu novo sistema, NOMAD, usando analogias simples:

1. O Problema: O "General Sobrecarregado"

Anteriormente, os pesquisadores pediam a uma única IA (um "General") para fazer tudo: ler o texto, encontrar os substantivos, descobrir as relações e desenhar o diagrama final.

  • O Problema: Assim como um general cansado tentando gerenciar todo um exército sozinho, a IA cometia erros. Frequentemente, ela acertava a visão geral (os principais edifícios), mas errava nos detalhes (as janelas e portas) ou nas conexões entre eles.

2. A Solução: A "Equipe de Construção Especializada" (NOMAD)

Em vez de um robô fazer tudo, o NOMAD atua como uma equipe de construção onde cada trabalhador tem uma função específica. Eles passam o trabalho ao longo de uma linha, como uma linha de montagem em uma fábrica.

  • Trabalhador 1: O Extrator de Conceitos (O Batedor)
    • Função: Lê o texto e apenas lista as principais "coisas" (como "Cliente", "Pedido", "Produto").
    • Analogia: Como um batedor caminhando por uma floresta e dizendo: "Vejo uma árvore, uma pedra e um rio". Eles não se preocupam com como se conectam ainda; apenas identificam o que existe.
  • Trabalhador 2: O Compreendedor de Relações (O Conector)
    • Função: Pega a lista de "coisas" e descobre como elas conversam entre si.
    • Analogia: Como um planejador social que diz: "O Cliente compra o Pedido" ou "O Pedido contém Produtos". Eles desenham as linhas entre os itens.
  • Trabalhador 3: O Integrador de Modelos (O Arquiteto)
    • Função: Pega a lista e as conexões e as organiza em um formato estrito e limpo (como uma planta baixa digital).
    • Analogia: Como um arquiteto que pega as ideias rústicas e as transforma em um plano preciso e padronizado que ninguém pode mal entender.
  • Trabalhador 4: O Articulador de Código (O Tradutor)
    • Função: Transforma esse plano limpo no código real (PlantUML) que os computadores podem ler para desenhar o diagrama.
    • Analogia: Como um tradutor que pega o plano do arquiteto e o escreve na linguagem específica que a equipe de construção fala.
  • Trabalhador 5: O Validador (O Inspetor)
    • Função: Olha para o diagrama final e o verifica contra o texto original para ver se há algo errado.
    • Analogia: Como um inspetor de edificações que percorre a casa terminada para garantir que as portas abrem e o telhado não está vazando. Se encontrarem um erro, sugerem um reparo.

3. O Que Eles Encontraram (Os Resultados)

Os pesquisadores testaram essa "Equipe" (NOMAD) contra o "General Sobrecarregado" (uma única IA) usando dois tipos de testes:

  1. O Teste Northwind: Um cenário de banco de dados massivo e complexo (como um plano de cidade enorme e detalhado).
  2. O Teste de Exercício: Oito cenários menores, escritos por humanos (como pequenos planos de casa).

A Boa Notícia:

  • Conexões Melhores: A Equipe foi muito melhor em descobrir como as coisas se conectam. A IA única frequentemente perdia conexões ou desenhava as erradas. A Equipe acertou isso quase todas as vezes.
  • Menos Erros: A Equipe cometeu muito menos erros "estruturais" (como construir uma parede onde deveria haver uma porta).

A Má Notícia (A "Letra Miúda"):

  • A Luta com "Atributos": A Equipe ainda teve dificuldades com os detalhes minúsculos, especificamente atributos (os pequenos campos de dados dentro de uma classe, como "Data de Nascimento" ou "Preço").
    • Por quê? As descrições de texto eram frequentemente vagas. Às vezes, o texto dizia "mantenha o registro do cliente", mas não listava explicitamente "e-mail" ou "número de telefone". A IA tinha que adivinhar, e frequentemente adivinhava errado ou os perdia.
    • Analogia: A equipe era ótima em construir a estrutura da casa, mas às vezes esquecia de instalar os interruptores de luz específicos porque as instruções não diziam exatamente quais usar.

4. A "Taxonomia de Erros" (O Dicionário de Erros)

Os pesquisadores perceberam que, quando a IA comete erros, eles não são todos iguais. Eles criaram o primeiro "Dicionário de Erros" para esses diagramas. Eles categorizaram os erros em três categorias:

  • Estrutural: Faltando um edifício inteiro ou adicionando um falso.
  • Relação: Conectando dois edifícios com uma ponte quando deveriam ser conectados por uma estrada.
  • Semântico/Lógico: Colocar uma "Cozinha" dentro de uma "Garagem" (faz sentido gramaticalmente, mas é logicamente errado).

5. O Veredito

O artigo conclui que o NOMAD é uma maneira melhor de construir essas plantas baixas de software porque divide o trabalho difícil em pedaços menores e gerenciáveis.

  • Funciona melhor quando as instruções são claras e o projeto é grande.
  • Ainda precisa de ajuda com os detalhes minúsculos (atributos) porque a linguagem humana é naturalmente nebulosa.
  • Adicionar um "Inspetor" (o Validador) ajuda a limpar o produto final, tornando-o ainda mais preciso.

Em resumo: Não peça a um único robô superinteligente para fazer tudo. Em vez disso, dê a uma equipe de robôs especializados uma linha de montagem clara, e você obterá uma planta baixa muito melhor.

Afogado em artigos na sua área?

Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.

Experimentar Digest →