Avanços na Reparo Automático de Programas Usando Modelos de Linguagem

A Reparação Automatizada de Programas (APR) é um processo que ajuda a corrigir bugs de software sem precisar de ajuda humana. Esse método tá ficando cada vez mais importante à medida que os sistemas de software crescem e os bugs aumentam. Encontrar e consertar bugs manualmente consome muito tempo e é caro pros desenvolvedores. As ferramentas de APR podem ajudar gerando automaticamente patches pra corrigir esses bugs. Uma abordagem específica de APR é a APR baseada em templates, que usa padrões ou templates pré-definidos que descrevem como corrigir erros comuns de código.

Embora a APR baseada em templates tenha mostrado bons resultados, ela enfrenta desafios, especialmente na hora de escolher o código doador certo pra usar nas correções. O código doador refere-se às partes de código que ajudam a criar o patch. Se escolher o código doador errado, até os melhores templates podem falhar em produzir uma correção correta. Essa limitação é um grande problema pra eficácia das ferramentas de APR baseadas em templates.

Neste trabalho, a gente dá uma nova olhada na APR baseada em templates e propõe um método que usa grandes modelos de linguagem pré-treinados pra gerar o código doador necessário diretamente. A ideia é prever os tokens de código corretos em vez de procurá-los nos arquivos bugados locais. Usando uma abordagem de preencher as lacunas, podemos criar patches que têm mais chances de serem corretos.

#Contexto e Motivação

Com a complexidade crescente do software, o número de bugs aumentou drasticamente. Esses bugs podem frustrar os usuários e resultar em perdas financeiras pros desenvolvedores. Como resultado, encontrar e corrigir bugs se tornou uma prioridade pra equipes de desenvolvimento de software. A APR busca agilizar esse processo gerando automaticamente patches.

Existem várias técnicas de APR, incluindo métodos baseados em heurísticas, em restrições e baseados em templates. A APR baseada em templates ganhou atenção por sua capacidade de dividir o processo de correção de bugs em duas partes principais: identificar o padrão da correção e escolher o código doador certo. Padrões de correção representam ações comuns de codificação, enquanto o código doador é composto por fragmentos de código que se alinham a essas ações.

Apesar da promessa da APR baseada em templates, ela geralmente depende de localizar o código doador dentro do arquivo de código local. É aí que os problemas costumam surgir. Muitos bugs ficam sem correção porque o código doador relevante não está disponível no mesmo arquivo. Quando o código doador certo não pode ser encontrado, a ferramenta de APR pode gerar patches que parecem bons, mas não são corretos. Isso leva a um desempenho abaixo do esperado e à incapacidade de reparar vários bugs.

Pra resolver essa limitação, propomos uma nova ferramenta que aproveita os avanços recentes em modelos de linguagem. Ao usar esses modelos poderosos, conseguimos prever o código doador correto necessário pra corrigir bugs, melhorando assim o desempenho geral da APR baseada em templates.

#Visão Geral do Método

Nossa ferramenta de APR proposta funciona em várias etapas. Primeiro, coletamos um conjunto de padrões de correção de pesquisas anteriores e os transformamos em padrões que podem ser preenchidos, ou seja, substituímos algumas partes do código por tokens mascarados. Em seguida, usamos um Modelo de Linguagem pré-treinado pra prever o código necessário pra essas seções mascaradas como se fosse uma tarefa de preencher as lacunas. Essa abordagem nos permite gerar patches sem precisar de exemplos anteriores de bugs corrigidos pra treinamento.

Escolhemos implementar nosso método usando o modelo UniXcoder. Esse modelo tem mostrado um bom desempenho na previsão de tokens de código com base no contexto. Nossa ferramenta conseguiu consertar 82 bugs no conjunto de dados Defects4J-v1.2, mostrando um desempenho melhor comparado aos métodos de APR baseados em templates anteriores.

#Padrões de Correção e Código Doador

Os padrões de correção são componentes essenciais da nossa abordagem. Um padrão de correção é uma regra que descreve como mudar o código pra corrigir um bug. Como muitos bugs são semelhantes, os padrões de correção podem ser reutilizados em diferentes cenários. Nós categorizamos vários padrões comuns e os definimos de forma que nos permita mascarar partes do código que precisam ser mudadas.

O segundo componente chave é o código doador. Isso se refere aos trechos de código reais que substituirão os tokens mascarados em nossos padrões. Pra encontrar um código doador adequado, utilizamos um modelo de linguagem pré-treinado, que já aprendeu com uma vasta quantidade de dados de programação. Em vez de tentar encontrar trechos de código localmente, podemos prever diretamente o código necessário com base no contexto.

#Processo da Ferramenta de APR

1. Localização de Falhas: O primeiro passo envolve identificar onde está o bug no código. Isso geralmente é feito usando ferramentas existentes que podem destacar áreas suspeitas no código.

2. Seleção de Padrões: Com base nas áreas identificadas, escolhemos padrões de correção apropriados. Analisamos a estrutura do código pra combinar os padrões aos tipos específicos de problemas encontrados.

3. Previsão de Máscaras: Em seguida, criamos templates com tokens mascarados a partir dos padrões selecionados. Depois, usamos o modelo de linguagem pra preencher essas máscaras com o código correto.

4. Validação de Patches: Após gerar os patches, testamos eles contra suítes de testes existentes pra garantir que não introduzam novos erros e corrijam efetivamente os problemas originais.

5. Inspeção Manual: Por fim, os patches plausíveis são revisados manualmente pra confirmar que atendem às expectativas dos desenvolvedores quanto à correção.

#Configuração Experimental

Pra avaliar o desempenho da nossa ferramenta, usamos o benchmark Defects4J-v1.2, que contém vários bugs do mundo real e é amplamente utilizado na pesquisa de APR. Esse conjunto de dados inclui bugs conhecidos com casos de teste correspondentes, permitindo que a gente avalie o quão bem a ferramenta pode corrigi-los.

Comparamos nossa ferramenta com diversas ferramentas tradicionais e baseadas em aprendizado de máquina, incluindo métodos baseados em templates e métodos de aprendizado recentes. O objetivo era verificar não apenas o número de bugs corrigidos, mas também a qualidade dessas correções.

#Métricas de Avaliação

Utilizamos duas métricas principais pra avaliar o desempenho:

• Patch Plausível: Essa métrica indica se o patch corrige o bug sem prejudicar outras funcionalidades.
• Patch Correto: Essa mede se o patch gerado é semanticamente equivalente a uma correção que um desenvolvedor teria feito.

#Resultados e Discussão

Após realizar experimentos extensivos, nossa ferramenta demonstrou melhorias significativas em relação às abordagens existentes. Conseguimos corrigir 82 bugs no conjunto Defects4J-v1.2. Esse número é consideravelmente maior do que os resultados reportados por outras ferramentas, indicando um avanço substancial no desempenho de reparo.

#Comparação com Técnicas Existentes

Quando comparamos nossa ferramenta com métodos tradicionais como TBar e técnicas baseadas em aprendizado como Recoder, descobrimos que nossa abordagem não só corrigiu mais bugs, mas também alcançou uma taxa melhor de patches corretos. Isso mostra o potencial do nosso método pra resolver as limitações que as técnicas atuais de APR enfrentam.

#Generalização

Nós também avaliamos nossa ferramenta em conjuntos de dados adicionais, incluindo Defects4J-v2.0 e QuixBugs. Isso foi importante pra testar quão bem nossa abordagem pode se adaptar a diferentes tipos de bugs. Os resultados mostraram que nossa ferramenta ainda conseguia gerar um alto número de patches corretos, confirmando ainda mais sua eficácia em cenários do mundo real.

#Escalabilidade

Além disso, exploramos a escalabilidade do nosso método aplicando diferentes modelos pré-treinados, como CodeBERT e ChatGPT, à nossa tarefa. Os resultados indicaram que, embora todos os modelos tenham se saído bem, nossa implementação inicial usando UniXcoder superou consistentemente os outros. Isso destaca a importância da seleção do modelo pra alcançar os melhores resultados na reparação de programas.

#Desafios e Limitações

Apesar do sucesso da nossa ferramenta, alguns desafios ainda permanecem. A dependência de modelos pré-treinados significa que, se o modelo subjacente não entender bem uma estrutura de código específica, a previsão pode falhar. Além disso, a qualidade e diversidade dos padrões de correção desempenham um papel crítico em determinar quantos bugs podem ser reparados com sucesso.

É importante notar que, embora nosso método mostre promessa, ele pode ainda ignorar certos bugs que exigem uma abordagem mais especializada ou diferentes padrões de correção não cobertos nos templates existentes.

#Trabalho Futuro

No futuro, pretendemos expandir nossa biblioteca de padrões de correção pra cobrir uma variedade maior de bugs. Pesquisar novos padrões ajudará a aumentar a capacidade da nossa ferramenta de lidar com problemas mais complexos que surgem no desenvolvimento de software. Explorar modelos pré-treinados mais avançados e ajustá-los para tipos específicos de bugs também poderia trazer melhores resultados.

A gente também planeja investigar como implementar técnicas automatizadas de localização de falhas dentro do nosso fluxo de trabalho. Isso vai aumentar a usabilidade da ferramenta em cenários do mundo real, onde os desenvolvedores podem não ter informações perfeitas sobre a localização do bug.

#Conclusão

A reparação automatizada de programas representa uma oportunidade empolgante de melhorar as práticas de desenvolvimento de software ao minimizar o tempo e o esforço necessários pra corrigir bugs. Nossa ferramenta proposta está na vanguarda desse campo ao integrar poderosos modelos de linguagem com abordagens baseadas em templates, melhorando assim a capacidade de gerar patches corretos. Com essa ferramenta, podemos nos aproximar de um futuro onde os bugs de software podem ser tratados de forma mais eficiente, deixando os desenvolvedores livres pra focar na criação de novas funcionalidades e na melhoria das experiências dos usuários.