PG_C03_Conclusiones

Conclusiones intervalos de medidas y valores anómalos del grupo 1

Analizar los valores de las medidas (umbrales y anómalos) desglosando por autor/tipo de entidad y por tipo de característica de la entidad de código (tamaño complejidad, herencia...)

Conclusiones intervalos de medidas y valores anómalos del grupo 2

Conclusiones intervalos de medidas y valores anómalos del grupo 3

Conclusiones intervalos de medidas y valores anómalos del grupo 4

ANÁLISIS TÉCNICO DE VALORES Y ANOMALÍAS Este análisis se basa en la comparación de los intervalos calculados (Q1 y Q3) frente a los umbrales de riesgo detectados por la herramienta MetricHunter de SourceMeter.

1. Análisis a Nivel de Clase (Autores: C&K y Lorenz & Kidd) A. Dimensión: Tamaño y Estructura Interna Valores Observados: En el proyecto Broadleaf, el tamaño de las clases es moderado, con un Q3 de 68 líneas lógicas (TLLOC) y 12 métodos (NM).

Anomalías vs. Umbrales: Aunque la media ponderada sitúa la normalidad en valores bajos, el archivo MetricHunter.txt identifica desviaciones críticas en clases de servicio. Por ejemplo, la métrica NOS (sentencias) alcanza valores de 940 en clases como FormBuilderServiceImpl, superando el umbral de riesgo de 900. Esto indica la presencia de "Clases Dios" que concentran excesiva responsabilidad.

B. Dimensión: Complejidad Valores Observados: La complejidad ponderada (WMC Q3 = 15,05) es superior al umbral recomendado de 10.

Análisis: Esta desviación es característica de los frameworks empresariales. La complejidad se desplaza hacia las implementaciones de lógica de negocio pesada, donde una sola clase debe gestionar múltiples flujos de datos.

C. Dimensión: Herencia Valores Observados: Se observa una convergencia total en valores mínimos (DIT Q3 = 1 y NOC Q3 = 0).

Análisis: Los tres proyectos (Broadleaf, Oxalis, Shopizer (sm-core)) muestran una jerarquía casi plana. La anomalía sería encontrar clases con un DIT > 3, lo cual es inexistente en la muestra, confirmando una clara preferencia por la composición sobre la herencia.

D. Dimensión: Acoplamiento Valores Observados: El acoplamiento global (CBO Q3 = 4,44) es notablemente sano, situándose muy por debajo del límite de alarma de 8,0.

Análisis: A pesar de la complejidad interna de las clases, la interdependencia entre ellas está bien gestionada, lo que facilita el mantenimiento evolutivo del sistema.

2. Análisis a Nivel de Método (Autor: McCabe / Tamaño) A. Dimensión: Complejidad Lógica y Granularidad Valores Observados: Los métodos presentan una Complejidad Ciclomática (McCC) extremadamente baja, con un Q3 de 1,0. El tamaño por método es de apenas 6 líneas lógicas (TLLOC).

Anomalías vs. Umbrales: El umbral de riesgo de la herramienta se sitúa en 10 para complejidad y 104 para líneas. Las únicas anomalías detectadas en MetricHunter.txt corresponden a métodos de tipo equals() o validadores extensos con múltiples ramas condicionales.

Conclusión: La granularidad de los métodos es excelente. Los desarrolladores han priorizado métodos muy cortos y simples, lo que reduce drásticamente la probabilidad de errores lógicos y facilita las pruebas unitarias.

3. Análisis a Nivel de Paquete (Autor: Robert Martin) A. Dimensión: Tamaño de Paquete y Modularity Valores Observados: La distribución de tamaño en paquetes es asimétrica. Mientras el Q1 es de 1 clase (NCL), el Q3 sube a 5. En cuanto a métodos (NM), el salto es de 2 a 36.

Análisis: No se han detectado anomalías de acoplamiento aferente (Ca) o eferente (Ce) que superen los umbrales de inestabilidad en los archivos de advertencia.

Conclusión: El sistema está organizado en una gran cantidad de paquetes pequeños y especializados. Esto favorece la estabilidad del producto, ya que los cambios en un paquete afectan a una proporción muy reducida del total de clases del sistema.

Conclusión de general convergencia

9.1. ¿Convergen los estadísticos Q1 y Q3 en los diferentes proyectos? ¿Ocurre lo mismo con la mediana? En nuestra comparativa, observamos una convergencia notable en métricas estructurales como DIT (0-1) y NOC (0-0). Esto indica que, independientemente del tamaño del proyecto, los desarrolladores Java tienden a arquitecturas planas, prefiriendo la composición sobre la herencia profunda.

Sin embargo, en métricas de complejidad como WMC, la convergencia es menor:

Mientras que en Oxalis el Q3 es 11, en Broadleaf es 15 y en ShShopizer (sm-core) opizer sube a 19.

La mediana suele mantenerse estable (cerca de valores bajos), pero la media aritmética tiende a dispararse en proyectos grandes como Broadleaf debido a la presencia de "God Classes" o servicios muy densos que actúan como valores atípicos (outliers), sesgando el promedio hacia arriba.

9.2. ¿Es posible la evaluación automatizada de un proyecto a través de valores estadísticos? Sí, es posible y recomendable, pero con matices. El uso de herramientas como SourceMeter permite establecer "Quality Gates" (puertas de calidad) automáticas en procesos de CI/CD.

Si un nuevo desarrollo supera el Q3 histórico calculado (por ejemplo, un WMC > 15), el sistema puede lanzar una alerta de refactorización automática.

No obstante, la estadística no sustituye al juicio humano: un valor alto en una métrica puede estar justificado por la naturaleza crítica de un algoritmo, por lo que la automatización debe servir para identificar "hotspots" que requieran revisión manual.

9.3. ¿Los valores de las métricas pueden depender de los tipos de software? Absolutamente. * En un framework empresarial como Broadleaf, es normal encontrar un CBO y un WMC más altos en las capas de servicio debido a la gran cantidad de dependencias inyectadas (Spring) y lógica de negocio acumulada.

Por el contrario, en una librería de utilidades o un middleware como Oxalis, esperaríamos un DIT más profundo si se basa en jerarquías de tipos, pero un CBO mucho más bajo al tener menos dependencias externas. El tipo de software dicta el "perfil estadístico" de su calidad.

9.4. ¿El proceso puede influir en la calidad del producto? ¿Métricas de proceso interesantes? El proceso de desarrollo (la metodología, las revisiones, el testing) es el determinante directo de la calidad final del código. Un proceso inmaduro genera "deuda técnica" que se refleja en métricas degradadas.

Sería muy valioso añadir métricas de proceso como:

Frecuencia de commits por módulo: Para detectar qué partes del código cambian demasiado (inestabilidad).

Code Churn (Rotación de código): Cantidad de código eliminado o modificado poco después de escribirse.

Lead Time para corrección de bugs: Cuánto tiempo pasa desde que se detecta una anomalía en MetricHunter hasta que el valor de la métrica vuelve al intervalo recomendado.

Cobertura de tests: Relación entre las líneas de código lógicas (LLOC) y las líneas ejecutadas por pruebas unitarias.

10. Conclusión y Cierre del Proyecto Grupal Como cierre de esta experiencia de medición, el grupo concluye que la aplicación sistemática de métricas orientadas a objetos es una práctica indispensable para garantizar la sostenibilidad del software a largo plazo. A través del análisis comparativo de proyectos de diferentes escalas como Broadleaf, Shopizer (sm-core) y Oxalis, hemos aprendido que la calidad no es un valor absoluto, sino que debe interpretarse dentro del contexto y dominio del sistema.

La integración de herramientas de análisis estático como SourceMeter nos ha permitido identificar patrones de diseño y anomalías que pasarían desapercibidas en una revisión de código convencional. La metodología de media ponderada por NCLOC ha resultado clave para establecer intervalos de validación realistas, demostrando que los proyectos de mayor envergadura actúan como referentes de la complejidad permitida en el grupo. En definitiva, esta práctica nos ha proporcionado una visión crítica sobre la importancia de controlar el acoplamiento y la complejidad desde las fases tempranas del desarrollo, consolidando el uso de indicadores estadísticos como una competencia fundamental para cualquier arquitecto de sistemas software.