11. Evaluación y métricas de acoplamiento y cohesión en proyectos reales

Medir la calidad estructural transforma el debate sobre acoplamiento y cohesión en decisiones objetivas. Las métricas permiten detectar desviaciones, priorizar refactorizaciones y verificar que las mejoras se mantengan en el tiempo. En este tema se combinan fundamentos, herramientas y ejemplos aplicados a proyectos de Java.

11.1 Por qué cuantificar el diseño

Los indicadores de acoplamiento y cohesión complementan la revisión manual del código. Sin datos, un equipo puede pasar semanas discutiendo gustos personales. Con métricas confiables, es posible negociar objetivos de calidad y demostrar que una refactorización tiene impacto real en la mantenibilidad.

11.2 Métricas clásicas de cohesión

Existen varias propuestas académicas y adoptadas por la industria para evaluar la cohesión:

• Lack of Cohesion of Methods (LCOM): mide cuántos métodos operan sobre atributos compartidos. Un valor alto indica que la clase contiene responsabilidades mezcladas.
• LCOM*: versión normalizada que entrega valores entre 0 y 1, lo que facilita comparaciones entre clases de tamaños distintos.
• Co-Occurring Methods (TCC/LSC): relacionan cuántos pares de métodos utilizan el mismo subconjunto de datos. Un nivel alto sugiere cohesión funcional.

11.3 Indicadores de acoplamiento

Los indicadores que evalúan la relación entre módulos permiten visualizar cómo se propagan los cambios:

• Afferent Coupling (Ca): cantidad de clases externas que dependen de un módulo. Un Ca alto implica que la unidad ofrece servicios esenciales y cambiarla tiene costo.
• Efferent Coupling (Ce): dependencias salientes de un módulo. Un valor reducido suele indicar diseño estable o necesidad de ampliar colaboraciones.
• Instability (I): relación entre Ce y Ca. Valores cercanos a 1 indican que el módulo depende mucho de otros; cercanos a 0 señalan que sirve como fundamento.
• Dependency Cycles: la presencia de ciclos entre paquetes dificulta desplegar cambios y se debe eliminar a la brevedad.

11.4 Herramientas que automatizan el análisis

La medición continua requiere integrar herramientas al flujo de desarrollo:

• SonarQube: calcula métricas de diseño, registra tendencias y permite configurar umbrales de calidad.
• IntelliJ IDEA: incluye inspecciones que detectan dependencias cíclicas, complejidad excesiva y clases con baja cohesión.
• JDepend: librería que reporta Ca, Ce e inestabilidad a partir de paquetes compilados.

11.5 Integrar métricas en un pipeline de construcción

En proyectos con maven se puede automatizar la ejecución del plugin jdepend durante la fase de verificación:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>jdepend-maven-plugin</artifactId>
  <version>2.0</version>
  <executions>
    <execution>
      <goals>
        <goal>jdepend</goal>
      </goals>
      <phase>verify</phase>
    </execution>
  </executions>
</plugin>

El reporte resultante expone los módulos con mayor inestabilidad. Si alguna cifra supera el límite acordado, el pipeline puede fallar y alertar al equipo.

11.6 Ejemplo práctico: interpretando resultados

Supongamos que el análisis detecta los siguientes valores:

• AplicacionPedidos: Ca = 7, Ce = 2, I = 0.22, LCOM = 0.15.
• InfraestructuraEmail: Ca = 1, Ce = 8, I = 0.89, LCOM = 0.75.

La primera clase actúa como base del dominio y mantiene cohesión alta; conviene refactorizarla con cuidado para no afectar a los consumidores. La segunda expone bajo acoplamiento entrante pero depende demasiado de otros módulos y su cohesión mediocre sugiere responsabilidades mezcladas. Una acción inmediata podría ser separar la configuración de la lógica de envío y aislar adaptadores externos.

11.7 Umbrales y tendencias

No existe una cifra universal para LCOM o inestabilidad. Lo valioso es observar cómo evolucionan. Si una refactorización disminuye Ce y LCOM, es evidencia de mejora. Si los valores vuelven a crecer, hay que revisar los cambios recientes y conversar con el equipo para mantener las buenas prácticas descritas en el tema 10.

11.8 Checklist para adoptar métricas en el equipo

• ¿Las herramientas de análisis se ejecutan automáticamente en el servidor de integración continua?
• ¿Existe un tablero visible con las métricas clave de cada módulo?
• ¿Los umbrales acordados se revisan trimestralmente para adaptarse al contexto del proyecto?
• ¿Se documentan las acciones correctivas cuando una métrica se degrada?

Medir con disciplina permite detectar desviaciones antes de que el diseño se vuelva frágil. Al combinar métricas, herramientas y revisiones regulares, los equipos sostienen la modularidad y mantienen el equilibrio entre acoplamiento y cohesión.