Abordando la erosión de la arquitectura en sistemas de software

La arquitectura de software es clave para crear sistemas grandes y complejos. Representa cómo está estructurado un sistema y cómo se comporta. Una buena arquitectura se alinea con los objetivos del negocio y el software real que se construye. Sin embargo, a veces la arquitectura puede desviarse con el tiempo, lo que se conoce como erosión de la arquitectura. Esta desviación puede hacer que el mantenimiento y las actualizaciones sean difíciles, llevando a posibles problemas con la calidad del software.

La erosión de la arquitectura ocurre cuando la forma en que se construye un sistema empieza a diferir de cómo se planeó originalmente. Esto puede suceder a través de varios síntomas a los que los desarrolladores deberían prestar atención. Reconocer estos síntomas temprano es clave para prevenir problemas futuros.

En esta discusión, nos enfocamos en identificar problemas en la arquitectura de software a partir de discusiones en las revisiones de código, un proceso donde los desarrolladores revisan los cambios de código de los demás para encontrar errores y mejorar la calidad.

#¿Qué es la erosión de la arquitectura?

La erosión de la arquitectura es un gran desafío en el desarrollo de software. Ocurre cuando hay brechas crecientes entre lo que se pretendía en la arquitectura y lo que realmente se construye. Esto puede llevar a problemas con el tiempo. Muchos términos describen este problema, como degradación arquitectónica, deterioro y decadencia.

A medida que el software evoluciona, pueden aparecer ciertos signos o síntomas que indican erosión. Estos pueden incluir:

• Síntomas estructurales: Problemas como dependencias circulares dentro del código.
• Síntomas de violación: Problemas que surgen cuando no se siguen principios o reglas de diseño, como violaciones de capas.
• Síntomas de calidad: Señales de que la calidad del software está disminuyendo, como altas tasas de defectos.
• Síntomas de evolución: Impactos de cambios que afectan muchas partes del sistema, como efectos de onda.

En nuestro análisis, nos concentramos principalmente en los síntomas de violación, ya que representan señales de alerta inmediatas para arquitectos y desarrolladores. Estas violaciones suelen surgir de no seguir principios, patrones o requisitos de diseño establecidos.

#La necesidad de identificar síntomas de violación

Identificar síntomas de violación es esencial para mantener la calidad del software. Si se ignoran, estos síntomas pueden acumularse y llevar a problemas significativos en el futuro. Monitorear estos síntomas de violación ayuda a los desarrolladores a mantenerse alineados con la arquitectura pretendida, facilitando abordar cualquier erosión antes de que escale.

Hay dos maneras principales de identificar síntomas de violación: a través del análisis del código fuente o examinando artefactos textuales como comentarios y revisiones de código.

Si bien el análisis del código fuente es útil, tiene limitaciones. Algunas herramientas solo pueden encontrar ciertos tipos de violaciones, y no todos los lenguajes de programación pueden ser compatibles. Además, estas herramientas a menudo no entienden el contexto detrás del código. Por otro lado, revisar manualmente comentarios del código y discusiones puede llevar tiempo y puede dar lugar a errores humanos.

#Usando técnicas automatizadas para identificar síntomas de violación

La automatización ofrece una solución práctica para mejorar la identificación de síntomas de violación en la arquitectura de software. Al usar técnicas de Aprendizaje automático (ML) y aprendizaje profundo (DL), podemos analizar revisiones de código y comentarios para detectar estas violaciones de manera más eficiente.

En este estudio, desarrollamos varios Clasificadores de ML y DL diseñados específicamente para identificar síntomas de violación a partir de comentarios hechos durante las revisiones de código. Nos enfocamos en discusiones de cuatro grandes proyectos de código abierto en dos comunidades: OpenStack y Qt.

#Cómo llevamos a cabo el estudio

#Creación del conjunto de datos

Comenzamos construyendo un conjunto de datos que incluía comentarios de revisiones de código. Nuestro objetivo era recopilar la mayor cantidad de comentarios relevantes posible. Esto implicó varios pasos:

1. Búsqueda de palabras clave: Creamos una lista de palabras clave relacionadas con violaciones de arquitectura para ayudar a encontrar comentarios que discutieran estos problemas.
2. Revisión manual: Después de filtrar comentarios potenciales usando nuestras palabras clave, los revisamos manualmente para asegurarnos de que eran relevantes.
3. Etiquetado: Etiquetamos los comentarios como si contenían una violación de arquitectura o no.

Al final de nuestra recopilación de datos, etiquetamos más de 600 comentarios de varias revisiones de código relacionadas con violaciones de arquitectura.

#Entrenamiento de clasificadores

Luego, desarrollamos clasificadores utilizando técnicas de aprendizaje automático y aprendizaje profundo. Usamos varios algoritmos para entrenar estos clasificadores, incluyendo máquinas de vectores de soporte (SVM), regresión logística y redes neuronales convolucionales (CNN).

También utilizamos diferentes modelos de incrustación de palabras para representar el texto de una manera que los clasificadores pudieran entender. Las incrustaciones de palabras ayudan a capturar el significado de las palabras convirtiéndolas en representaciones numéricas basadas en su contexto.

Probamos 15 clasificadores de aprendizaje automático y 4 clasificadores de aprendizaje profundo con diferentes niveles de éxito. Nuestro objetivo era averiguar cuál clasificador funcionaba mejor al identificar síntomas de violación.

#Evaluación del rendimiento

Para evaluar nuestros clasificadores, medimos su rendimiento utilizando métricas como precisión, recuperación y exactitud. La precisión indica cuántas de las violaciones predichas eran correctas, la recuperación mide cuántas violaciones reales fueron identificadas, y la exactitud nos dice la tasa general de predicciones correctas.

A través de nuestros experimentos, descubrimos que diferentes clasificadores tenían rendimientos variados. El clasificador SVM usando un modelo de incrustación específico llamado word2vec superó a los demás, logrando los mejores resultados en general.

#Hallazgos y resultados

#Mejores clasificadores

De nuestros experimentos, encontramos que el clasificador SVM usando el modelo word2vec tuvo el mejor rendimiento en la identificación de síntomas de violación. Las métricas de rendimiento mostraron que tenía una alta tasa de recuperación, lo que indica que fue efectivo para atrapar muchas violaciones reales.

Además, los clasificadores que usaban el modelo de incrustación fastText también tuvieron un buen desempeño, especialmente con representaciones de 200 dimensiones, que parecieron proporcionar un mejor equilibrio de información.

#Aprendizaje en conjunto

También exploramos la idea de usar aprendizaje en conjunto, que implica combinar las predicciones de múltiples clasificadores para mejorar la precisión. Al implementar una estrategia de votación donde se elegía la predicción más común entre los clasificadores, pudimos mejorar el rendimiento general.

Este enfoque en conjunto mostró resultados prometedores, ya que a menudo superó a los clasificadores individuales. Sin embargo, la mejora no fue tan significativa al usar modelos de aprendizaje profundo en comparación con los modelos de aprendizaje automático tradicionales.

#Retroalimentación de profesionales

Para validar la utilidad de nuestros clasificadores, realizamos una encuesta y entrevistas con desarrolladores. Buscamos retroalimentación sobre si encontraban útil la identificación de síntomas de violación en la práctica.

La mayoría de los profesionales que participaron en la encuesta coincidieron en que la identificación automatizada de síntomas de violación podría ayudar en el proceso de Revisión de Código al permitir una identificación más rápida de problemas potenciales. Muchos expresaron que esto podría ayudar a priorizar problemas arquitectónicos de manera más efectiva y reducir el tiempo dedicado a revisiones manuales.

Sin embargo, algunos participantes expresaron preocupaciones sobre la fiabilidad de los clasificadores. Les preocupaba la posibilidad de falsos positivos y negativos, lo que podría llevar a pasar por alto problemas importantes o tener que lidiar con advertencias innecesarias.

#Conclusión

En resumen, la erosión de la arquitectura presenta un desafío significativo en el desarrollo de software, y la identificación oportuna de síntomas de violación es crucial para mantener la calidad del software. Nuestra investigación se centró en usar técnicas automatizadas para identificar estos síntomas a partir de discusiones en revisiones de código.

Creamos con éxito clasificadores entrenados con datos del mundo real de proyectos de código abierto, logrando resultados prometedores. Los clasificadores SVM que usaron incrustaciones de palabras específicas demostraron ser efectivos, y el enfoque de aprendizaje en conjunto ofreció mejoras adicionales en el rendimiento.

La retroalimentación de los profesionales confirmó que las técnicas automatizadas podrían ser beneficiosas en entornos prácticos, aunque persistían preocupaciones sobre la precisión. De cara al futuro, buscamos refinar aún más nuestros clasificadores y explorar aplicaciones adicionales de este enfoque en contextos de revisión de código.

Este trabajo abre puertas para futuras investigaciones y desarrollos, con el potencial de mejorar la calidad del software a través de la detección automatizada de violaciones arquitectónicas.