Resumo Técnico: Rumo à Identificação Automatizada de Sintomas de Violação de Erosão de Arquitetura

1. Definição do Problema

A erosão da arquitetura de software ocorre quando o sistema implementado diverge de sua arquitetura pretendida, levando à degradação da manutenibilidade, desempenho e sustentabilidade. Embora existam vários sintomas de erosão (estruturais, de qualidade e de evolução), os sintomas de violação — instâncias onde o código viola princípios, padrões ou decisões de design — são os indicadores mais imediatos que requerem atenção.

Tradicionalmente, a identificação dessas violações depende de análise estática de código ou revisão manual de artefatos textuais. No entanto, ferramentas de análise estática frequentemente sofrem com detecção limitada de tipos de violação, suporte restrito a linguagens e incapacidade de capturar nuances semânticas. A identificação manual por meio de revisões de código é precisa, mas tediosa, demorada e propensa ao erro humano. Apesar da riqueza de informações nos comentários de revisão de código sobre decisões arquiteturais, nenhum estudo anterior havia investigado a identificação automatizada de sintomas de violação especificamente dentro de artefatos textuais, como comentários de revisão de código.

2. Metodologia

O estudo emprega uma abordagem empírica de múltiplas fases para avaliar a viabilidade de automatizar a detecção de sintomas de violação a partir de comentários de revisão de código.

2.1 Construção do Conjunto de Dados

• Fonte: Comentários de revisão de código de quatro projetos de código aberto: OpenStack (Nova, Neutron) e Qt (Base, Creator), coletados via API REST do Gerrit entre 2014 e 2020.
• Rotulagem: Um conjunto de dados de 21.583 comentários foi minerado. Quatro pesquisadores rotularam manualmente 606 comentários como "sintomas de violação" (classe positiva) e 606 como "não-violações" (classe negativa) para criar um conjunto de treinamento equilibrado. O acordo inter-avaliador (Kappa de Cohen) foi de 0,857.
• Conjunto de Teste Desbalanceado: Um conjunto de teste separado de 150 comentários (7 violações, 143 não-violações) foi construído para simular condições reais de baixa prevalência (~4,7% de taxa positiva).

2.2 Fase 1: Classificação ML/DL

Os autores treinaram e avaliaram classificadores usando três técnicas de incorporação de palavras (word embedding) pré-treinadas: word2vec, fastText e GloVe.

• Aprendizado de Máquina (ML): Cinco algoritmos foram testados: Support Vector Machine (SVM), Regressão Logística (LR), Árvore de Decisão (DT), Naive Bayes de Bernoulli (NB) e k-Vizinhos Próximos (kNN).
• Aprendizado Profundo (DL): Um modelo TextCNN foi treinado.
• Aprendizado de Conjunto (Ensemble): Uma estratégia de votação majoritária (Votação Dura/Hard Voting) foi aplicada para combinar as previsões dos classificadores individuais.
• Ajuste de Hiperparâmetros: A busca em grade (grid search) foi usada para modelos de ML. Para DL, as configurações específicas incluíram embeddings de 200 dimensões, uma taxa de aprendizado de 0,001 e dropout de 0,25.
• Tratamento de Desbalanceamento: Técnicas de aprendizado sensíveis ao custo (ex: ponderação de classe, reamostragem SMOTE, matrizes de custo) foram aplicadas aos dados de treinamento para abordar o desbalanceamento natural no conjunto de teste.

2.3 Fase 2: Validação

• Qualitativa: Uma pesquisa online (24 respostas) e entrevistas semiestruturadas (6 participantes) foram conduzidas com profissionais envolvidos nas revisões de código originais para avaliar a utilidade percebida da abordagem automatizada.
• Quantitativa: Um experimento controlado foi realizado com 35 desenvolvedores (grupos Controle vs. Experimental). O grupo Experimental recebeu dicas geradas pelos classificadores destacando potenciais sintomas de violação. A métrica foi a proporção de violações corretamente identificadas e corrigidas.

2.4 Fase 3: Comparação com LLM

Três modelos de linguagem de grande escala (LLMs) de última geração foram avaliados usando engenharia de prompt (Zero-shot e Few-shot learning com 2, 4, 6 e 10 exemplos):

• GPT-4o (Proprietário)
• Qwen-3 (Peso aberto/Open-weight)
• DeepSeek-R1 (MoE de código aberto)
  Estratégias de prompt conscientes de custo foram usadas para mitigar o viés em direção à classe majoritária no cenário desbalanceado.

3. Resultados Principais

3.1 Desempenho ML/DL (RQ1 & RQ2)

• Melhor Classificador: Entre as abordagens ML/DL, o classificador SVM com embeddings word2vec alcançou o maior desempenho no conjunto de dados equilibrado (F1-score: 0,808, Precisão: 0,789, Recall: 0,828).
• Impacto do Embedding: Embeddings de palavras de 200 dimensões geralmente superaram os modelos de 100 e 300 dimensões. Os embeddings fastText renderam resultados relativamente bons para modelos DL (TextCNN).
• Ensemble: Classificadores de conjunto usando votação majoritária geralmente melhoraram o desempenho sobre os classificadores ML individuais (ex: melhorias no F1-score de até 13,10%). No entanto, o ensemble não melhorou consistentemente os classificadores DL (TextCNN).
• Robustez ao Desbalanceamento: Sob condições naturais de baixa prevalência, os modelos SVM sensíveis ao custo mantiveram altos escores de Macro-F1 (0,816), demonstrando eficácia em cenários realistas. A análise de significância estatística (teste de Friedman) confirmou que as diferenças de desempenho não se devem à variação aleatória.

3.2 Desempenho LLM (RQ4)

• Superioridade: Os melhores classificadores baseados em LLM superaram as abordagens tradicionais de ML/DL.
• Melhor Desempenho: O GPT-4o com configuração de 2-shot alcançou o maior F1-score (0,851) e Acurácia (0,848) entre todos os modelos avaliados.
• Limitações de Ensemble: Ao contrário de ML/DL, o uso de ensemble de LLMs (entre modelos ou configurações de shot) não melhorou o desempenho de forma consistente e, às vezes, o degradou, provavelmente devido ao alto desempenho base dos LLMs individuais e ao potencial de amplificação de alucinações.

3.3 Validação Prática (RQ3)

• Feedback dos Profissionais: 66,7% dos respondentes da pesquisa concordaram que os sintomas identificados representavam potenciais violações arquiteturais. A maioria concordou que a abordagem poderia ajudar a localizar e priorizar problemas mais rapidamente do que a revisão manual.
• Experimento Controlado: Fornecer dicas de sintomas de violação melhorou significativamente as taxas de detecção dos desenvolvedores. A taxa de identificação e correção correta de violações (Categoria 1) aumentou de 13,0% (Controle) para 29,4% (Experimental). A taxa de detecção total (Categoria 1 + 2) subiu de 25,9% para 64,7%, um aumento relativo de 150%.

4. Principais Contribuições

1. Demonstração de Viabilidade: O primeiro estudo a demonstrar a viabilidade de identificar automaticamente sintomas de violação de arquitetura a partir de comentários de revisão de código usando ML, DL e LLMs.
2. Comparação Abrangente: Uma comparação rigorosa de 15 classificadores ML, 4 classificadores DL e 3 LLMs através de diferentes dimensões de embedding e configurações de shot.
3. Insights Validados por Profissionais: Evidência empírica de pesquisas, entrevistas e um experimento controlado confirmando que dicas automatizadas melhoram significamente o desempenho do desenvolvedor na detecção de problemas arquiteturais.
4. Dataset e Ferramentas: O lançamento de um conjunto de dados rotulado de violações de arquitetura provenientes de revisões de código e o pacote de replicação para apoiar pesquisas futuras.

5. Significância e Alegações

O artigo afirma que a identificação automatizada de sintomas de violação serve como uma camada complementar à revisão de código moderna, oferecendo alertas precoces para evitar a integração de código que se desvia da arquitetura pretendida.

• Para Profissionais: A abordagem oferece uma ferramenta prática para reduzir a carga cognitiva de identificar questões arquiteturais, ajudando equipes a priorizar refatoração e manter a integridade arquitetural.
• Para Pesquisa: O estudo destaca que, embora os LLMs (especificamente o GPT-4o) ofereçam atualmente um desempenho superior, as abordagens tradicionais de ML (SVM com word2vec) continuam sendo altamente eficazes e mais eficientes em termos de custo para tarefas específicas de classificação de texto, especialmente quando os recursos computacionais são limitados.
• Metodológica: O trabalho preenche a lacuna entre a verificação teórica de conformidade arquitetural e os fluxos de trabalho práticos de desenvolvedores, aproveitando o rico contexto semântico encontrado nas discussões de revisão de código.

Os autores concluem que, embora desafios relativos a falsos positivos e custos de integração permaneçam, as evidências quantitativas e qualitativas apoiam fortemente a integração de tais técnicas automatizadas nos ciclos de vida de desenvolvimento de software para aumentar a sustentabilidade do sistema.