Métricas de código: acoplamiento de clases

El acoplamiento de clases también va por el nombre Acoplamiento entre objetos (CBO) tal y como se definió originalmente en CK94. Básicamente, el acoplamiento de clases es una medida del número de clases que son usadas por una sola clase. Un número alto es incorrecto y un número bajo suele ser bueno con esta métrica. Se ha demostrado que el acoplamiento de clases es un indicador preciso de errores de software y estudios recientes han demostrado que un valor de límite superior de 9 es el S2010 más eficaz.

Según la documentación de Microsoft, el acoplamiento de clases "mide el acoplamiento a clases únicas a través de parámetros, variables locales, tipos de valor devuelto, llamadas a métodos, instancias genéricas o de plantilla, clases base, implementaciones de interfaz, campos definidos en tipos externos y decoración de atributos. El buen diseño de software dicta que los tipos y métodos deben tener una cohesión alta y un acoplamiento bajo. El acoplamiento alto indica un diseño difícil de reutilizar y mantener debido a sus muchas interdependencias en otros tipos".

Los conceptos de acoplamiento y cohesión están claramente relacionados. Para mantener este debate sobre el tema, no profundizaremos en la cohesión, aparte de dar una breve definición de KKLS2000:

Yourdon y Constantine introdujeron la cohesión de módulos como "qué tan estrechamente enlazados o relacionados están los elementos internos de un módulo entre sí" YC79. Un módulo tiene una fuerte cohesión si representa exactamente una tarea [...], y todos sus elementos contribuyen a esta única tarea. Describen la cohesión como un atributo de diseño, en lugar de código, y un atributo que se puede usar para predecir la reutilización, el mantenimiento y la capacidad de cambio".

Ejemplo de acoplamiento de clases

Echemos un vistazo al acoplamiento de clases en acción. En primer lugar, cree una nueva aplicación de consola y cree una nueva clase denominada Person con algunas propiedades en ella y, a continuación, calcule inmediatamente las métricas de código:

Observe que el acoplamiento de clases es 0, ya que esta clase no usa ninguna otra clase. Ahora cree otra clase denominada PersonStuff con un método que cree una instancia de Person y establezca los valores de propiedad. Vuelva a calcular las métricas de código:

¿Ve cómo aumenta el valor de acoplamiento de clases? Observe también que, independientemente del número de propiedades que establezca, el valor de acoplamiento de clases simplemente sube en 1 y no en algún otro valor. El acoplamiento de clases mide cada clase solo una vez para esta métrica, sin importar cuántas veces se utilice la clase. Además, ¿puede ver que DoSomething() tiene un 1 pero el constructor, PersonStuff(), tiene un 0 para su valor? Actualmente no hay ningún código en el constructor que usa otra clase.

¿Qué ocurre si coloca código en el constructor que usó otra clase? Esto es lo que obtiene:

Ahora el constructor tiene claramente código que usa otra clase y la métrica de acoplamiento de clases muestra este hecho. De nuevo, puede ver que el acoplamiento general de clases para PersonStuff() es 1 y DoSomething() también es 1, lo que muestra que solo se utiliza una clase externa sin importar cuánto código interno la emplee.

A continuación, cree otra clase nueva. Asigne un nombre a esta clase y cree algunas propiedades dentro de ella:

Ahora utilice la clase en nuestro método DoSomething() dentro de una clase PersonStuff y vuelva a calcular las métricas de código otra vez.

Como puedes observar, el acoplamiento de clases de la clase PersonStuff llega hasta 2 y, si analizas la clase, puedes ver que el método DoSomething() tiene el mayor acoplamiento, pero el constructor aún solo utiliza una clase. Con estas métricas, puede ver el número máximo general de una clase determinada y explorar en profundidad los detalles por miembro.

El número mágico

Al igual que con la complejidad ciclomática, no hay ningún límite que se ajuste a todas las organizaciones. Sin embargo, S2010 indica que un límite de 9 es óptimo:

"Por lo tanto, consideramos los valores de umbral [...] como el más eficaz. Estos valores de umbral (para un solo miembro) son CBO = 9[...]". (énfasis agregado)

Análisis de código

El análisis de código incluye una categoría de reglas de mantenimiento. Para obtener más información, consulte Reglas de mantenimiento. Al usar el análisis de código heredado, el conjunto de reglas de directrices de diseño extendido contiene un área de mantenimiento:

Dentro del área de mantenibilidad hay una regla para el acoplamiento de clases:

Esta regla emite una advertencia cuando el acoplamiento de clases es excesivo. Para obtener más información, consulte CA1506: Evitar el acoplamiento excesivo de clases.

Citas

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Conjunto de métricas para el diseño orientado a objetos (transacciones IEEE en ingeniería de software, Vol. 20, Nº 6). Consultado el 14 de mayo de 2011, del sitio web de la Universidad de Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., y Saint-Denis, G. (2000). La cohesión de clases revisada: Un estudio empírico sobre sistemas industriales (Actas del taller sobre enfoques cuantitativos en ingeniería de software orientada a objetos). Consultado el 20 de mayo de 2011, del sitio web Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Análisis empírico de métricas CK para la complejidad de diseño orientado a objetos: implicaciones para defectos de software (IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Shatnawi, R. (2010). Una investigación cuantitativa de los niveles de riesgo aceptables de las métricas de orientación a objetos en sistemas de código abierto (IEEE Transactions on Software Engineering, Vol. 36, Nº 2).

YC79

Edward Yourdon y Larry L. Constantine. Diseño estructurado. Prentice Hall, Englewood Cliffs, N.J., 1979.