Resumen Técnico: Hacia la Identificación Automatizada de Síntomas de Violación de la Erosión de la Arquitectura

1. Planteamiento del Problema

La erosión de la arquitectura de software ocurre cuando el sistema implementado diverge de su arquitectura prevista, lo que conduce a una degradación de la mantenibilidad, el rendimiento y la sostenibilidad. Si bien existen diversos síntomas de erosión (estructurales, de calidad y de evolución), los síntomas de violación —instancias donde el código viola principios, patrones o decisiones de diseño— son los indicadores más inmediatos que requieren atención.

Tradicionalmente, la identificación de estas violaciones depende del análisis estático de código o de la revisión manual de artefactos textuales. Sin embargo, las herramientas de análisis estático suelen sufrir de una detección limitada de tipos de violación, un soporte de lenguaje estrecho y una incapacidad para capturar matices semánticos. La identificación manual mediante revisiones de código es precisa pero tediosa, consume mucho tiempo y es propensa al error humano. A pesar de la riqueza de información en los comentarios de las revisiones de código con respecto a las decisiones arquitectónicas, ningún estudio previo había investigado la identificación automatizada de síntomas de violación específicamente dentro de los artefactos textuales, como los comentarios de las revisiones de código.

2. Metodología

El estudio emplea un enfoque empírico de múltiples fases para evaluar la viabilidad de automatizar la detección de síntomas de violación a partir de comentarios de revisión de código.

2.1 Construcción del Conjunto de Datos

• Fuente: Comentarios de revisión de código de cuatro proyectos de código abierto: OpenStack (Nova, Neutron) y Qt (Base, Creator), recolectados a través de la API REST de Gerrit entre 2014 y 2020.
• Etiquetado: Se minó un conjunto de datos de 21,583 comentarios. Cuatro investigadores etiquetaron manualmente 606 comentarios como "síntomas de violación" (clase positiva) y 606 como "no violaciones" (clase negativa) para crear un conjunto de entrenamiento balanceado. El acuerdo entre evaluadores (Kappa de Cohen) fue de 0.857.
• Conjunto de Prueba Desbalanceado: Se construyó un conjunto de prueba independiente de 150 comentarios (7 violaciones, 143 no violaciones) para simular condiciones de baja prevalencia del mundo real (~4.7% de tasa positiva).

2.2 Fase 1: Clasificación ML/DL

Los autores entrenaron y evaluaron clasificadores utilizando tres técnicas de incrustación de palabras (word embedding) preentrenadas: word2vec, fastText y GloVe.

• Aprendizaje Automático (ML): Se probaron cinco algoritmos: Máquina de Vectores de Soporte (SVM), Regresión Logística (LR), Árbol de Decisión (DT), Naive Bayes de Bernoulli (NB) y k-Vecinos más Cercanos (kNN).
• Aprendizaje Profundo (DL): Se entrenó un modelo TextCNN.
• Aprendizaje de Conjunto (Ensemble Learning): Se aplicó una estrategia de votación por mayoría (Votación Dura/Hard Voting) para combinar las predicciones de los clasificadores individuales.
• Ajuste de Hiperparámetros: Se utilizó búsqueda de cuadrícula (Grid search) para los modelos de ML. Para DL, la configuración específica incluyó embeddings de 200 dimensiones, una tasa de aprendizaje de 0.001 y un dropout de 0.25.
• Manejo de Desbalanceo: Se aplicaron técnicas de aprendizaje sensible al costo (por ejemplo, ponderación de clases, remuestreo SMOTE, matrices de costo) a los datos de entrenamiento para abordar el desbalanceo natural en el conjunto de prueba.

2.3 Fase 2: Validación

• Cualitativa: Se realizó una encuesta en línea (24 respuestas) y entrevistas semiestructuradas (6 participantes) con profesionales involucrados en las revisiones de código originales para evaluar la utilidad percibida del enfoque automatizado.
• Cuantitativa: Se realizó un experimento controlado con 35 desarrolladores (grupos de Control vs. Experimental). El grupo Experimental recibió pistas generadas por los clasificadores que resaltaban posibles síntomas de violación. La métrica fue la proporción de violaciones correctamente identificadas y corregidas.

2.4 Fase 3: Comparación con LLM

Se evaluaron tres Modelos de Lenguaje de Gran Escala (LLM) de última generación utilizando ingeniería de prompts (aprendizaje Zero-shot y Few-shot con 2, 4, 6 y 10 ejemplos):

• GPT-4o (Propietario)
• Qwen-3 (Pesos abiertos)
• DeepSeek-R1 (MoE de código abierto)
  Se utilizaron estrategias de prompting conscientes del costo para mitigar el sesgo hacia la clase mayoritaria en el entorno desbalanceado.

3. Resultados Clave

3.1 Rendimiento de ML/DL (RQ1 y RQ2)

• Mejor Clasificador: Entre los enfoques de ML/DL, el clasificador SVM con embeddings de word2vec logró el mayor rendimiento en el conjunto de datos balanceado (F1-score: 0.808, Precisión: 0.789, Recall: 0.828).
• Impacto de los Embeddings: Los embeddings de palabras de 200 dimensiones generalmente superaron a los modelos de 100 y 300 dimensiones. Los embeddings de fastText arrojaron resultados relativamente buenos para los modelos de DL (TextCNN).
• Ensemble: Los clasificadores de conjunto utilizando votación por mayoría generalmente mejoraron el rendimiento sobre los clasificadores de ML individuales (por ejemplo, mejoras en el F1-score de hasta 13.10%). Sin embargo, el ensamblado no mejoró consistentemente los clasificadores de DL (TextCNN).
• Robustez ante el Desbalanceo: Bajo condiciones naturales de baja prevalencia, los modelos SVM sensibles al costo mantuvieron altos puntajes de Macro-F1 (0.816), demostrando efectividad en escenarios realistas. El análisis de significancia estadística (prueba de Friedman) confirmó que las diferencias de rendimiento no se debieron a variaciones aleatorias.

3.2 Rendimiento de LLM (RQ4)

• Superioridad: Los mejores clasificadores basados en LLM superaron a los enfoques tradicionales de ML/DL.
• Mejor Desempeño: GPT-4o con una configuración de 2-shot alcanzó el F1-score más alto (0.851) y la Exactitud (0.848) entre todos los modelos evaluados.
• Limitaciones del Ensemble: A diferencia de ML/DL, el ensamblado de LLMs (a través de modelos o configuraciones de shots) no mejoró consistentmente el rendimiento y, en ocasiones, lo degradó, probablemente debido al alto rendimiento base de los LLM individuales y la potencial amplificación de las alucinaciones.

3.3 Validación Práctica (RQ3)

• Retroalimentación de Profesionales: El 66.7% de los encuestados coincidió en que los síntomas identificados representaban posibles violaciones arquitectónicas. La mayoría estuvo de acuerdo en que el enfoque podría ayudar a localizar y priorizar problemas más rápido que la revisión manual.
• Experimento Controlado: Proporcionar pistas de síntomas de violación mejoró significativamente las tasas de detección de los desarrolladores. La tasa de identificación y corrección correcta de violaciones (Categoría 1) aumentó del 13.0% (Control) al 29.4% (Experimental). La tasa de detección general (Categoría 1 + 2) subió del 25.9% al 64.7%, una mejora relativa del 150%.

4. Contribuciones Clave

1. Demostración de Viabilidad: El primer estudio que demuestra la viabilidad de identificar automáticamente los síntomas de violación de la arquitectura a partir de comentarios de revisión de código utilizando ML, DL y LLMs.
2. Comparación Exhaustiva: Una comparación riguroosa de 15 clasificadores de ML, 4 de DL y 3 LLMs a través de diferentes dimensiones de embedding y configuraciones de shots.
3. Información Validada por Profesionales: Evidencia empírica de encuestas, entrevistas y un experimento controlado que confirma que las pistas automatizadas mejoran significamente el desempeño de los desarrolladores en la detección de problemas arquitectónicos.
4. Dataset y Herramientas: La publicación de un conjunto de datos etiquetado de violaciones de arquitectura de revisiones de código y el paquete de replicación para apoyar futuras investigaciones.

5. Significado y Reivindicaciones

El artículo sostiene que la identificación automatizada de síntomas de violación sirve como una capa complementaria a la revisión de código moderna, ofreciendo advertencias tempranas para prevenir la integración de código que se desvía de la arquitectura prevista.

• Para Profesionales: El enfoque ofrece una herramienta práctica para reducir la carga cognitiva de identificar problemas arquitectónicos, ayudando a los equipos a priorizar la refactorización y mantener la integridad arquitectónica.
• Para la Investigación: El estudio destaca que, si bien los LLM (específicamente GPT-4o) ofrecen actualmente un rendimiento superior, los enfoques tradicionales de ML (SVM con word2vec) siguen siendo altamente efectivos y más rentables para tareas específicas de clasificación de texto, especialmente cuando los recursos computacionales son limitados.
• Metodológica: El trabajo cierra la brecha entre la verificación teórica de la conformidad de la arquitectura y los flujos de trabajo prácticos de los desarrolladores, aprovechando el rico contexto semántico encontrado en las discusiones de revisión de código.

Los autores concluyen que, si bien persisten desafíos respecto a los falsos positivos y los costos de integración, la evidencia cuantitativa y cualitativa respalda fuertemente la integración de tales técnicas automatizadas en los ciclos de vida de desarrollo de software para mejorar la sostenibilidad del sistema.