Métricas de calidad para componentes de software (packages)
Hace unas semanas, revisando métricas de un análisis de código estático me di cuenta que había muchos de ellas que no conocía, entendía ni sabía interpretar, así que me puse manos a la obra para conseguir descifrar aquellos números. Partiendo de esta entrada de hoy, y en las próximas, intentaré averiguar a que características del código se refieren cada una de las métricas para así poder tenerlas en cuenta a la hora de programar. He comenzado por métricas de calidad para componentes de software (packages o paquetes).
Una métrica en el desarrollo de software es una medida, o conjunto de ellas, que nos da una información objetiva sobre el código de una aplicación ayudándonos a conocer alguna característica suya.
Robert C. Martin, en su libro Agile Principles, Patterns, and Practices in C#, hace mención a una serie de métricas relacionadas con el acoplamiento de código para evaluar componentes de software o packages (en realidad el título del post iba a ser ‘Métricas de calidad para paquetes’, pero se me hacía un poco raro el nombre 😝 )
Las métricas de las que habla ‘Uncle Bob’, son las siguientes:
- acoplamiento aferente (Ca)
- acoplamiento eferente (Ce)
- inestabilidad (I)
- abstracción (A)
Estabilidad — Software estable
¿Qué significa estabilidad en el desarrollo de software? ¿qué significa que un componente de software es estable? Atento a la jugada que puede ser un tanto liosa y es necesario entenderla para que, a su vez, podamos entender la parte de las métricas que parten de este concepto.
Según ‘Uncle Bob’, se define la estabilidad de un componente en base a la cantidad de trabajo que hace falta realizar para llevar a cabo un cambio en el código de dicho componente. Es decir, es estable si no es fácil de ‘cambiar’.
Yo siempre pensé que el concepto de estabilidad referido a métricas de calidad estaba más relacionado con el concepto de la frecuencia de cambio, pero no, tiene más que ver con cuánto de complicado es cambiar un artefacto de software. Así que, por dejarlo claro, mientras más complicado sea cambiar el código de un componente de software, más estable es.
Componentes estables e inestables
Ahora, la pregunta es, ¿cómo o cuánto de estable es un componente de software? ¿cómo medimos este concepto? Según Robert C. Martin, existen muchos factores que hacen de un componente de software difícil de cambiar: tamaño, complejidad…etc. Una forma segura de hacer un artefacto de software complicado de cambiar (estable) es hacer que muchos otros componentes dependan de él de manera que si tiene muchas dependencias, es decir, lo usan mucho, requeriría un gran esfuerzo hacer cambios en él y que siguiera siendo compatible con todos los otros componentes externos que lo usan.
- Componentes estables
En este caso, y según lo dicho anteriormente, ‘X’ es un componente estable. Es responsable de tres componentes y cualquier cambio en él requiere hacerlo de tal forma que no se vean afectados los otros tres. Además, ‘X’ no depende de nada ni de nadie por lo que cambios externos no le afectan, así que tenemos que también es un componente independiente.
- Componentes inestables
En este caso nos encontramos que ‘Y’ es un componente inestable porque es fácil de cambiar o al menos requiere poco esfuerzo, ¿y por qué?, pues porque nadie depende de él, por lo que cambios en su código no afectan a nadie. Y, como no tiene componentes externos que dependan de él, también lo definiremos como irresponsable. Sin embargo, él si depende de otros componentes, por lo que decimos que es dependiente.
Métricas para medir la estabilidad
Ahora bien, ¿cómo podemos medir la estabilidad de un componente? La forma de hacerlo es contar el número de dependencias de entrada y salida que tiene ese componente. Este conteo nos dará una medida sobre cuanto de estable es o no es. Dado un componente de software, podemos obtener tres valores: Acoplamiento aferente, acoplamiento eferente e inestabilidad.
Acoplamiento aferente (Ca)
Hace referencia a -¿quién depende de ti?- es decir, al número de dependencias entrantes de un artefacto de software específico. Mide cuantos artefactos externos dependen de él, es decir, cuanto lo usan desde otros sitios y por lo tanto, la responsabilidad que tiene.
Ejemplo: dado un artefacto A (paquete o una clase), el acoplamiento aferente indica el número de usos que otro artefacto B distinto (clase o paquete y externo a A), hace de sus atributos y/o métodos de clase o heredan de él.
Acoplamiento eferente (Ce)
Hace referencia a -¿de quién dependemos?-, nos da el número de dependencias salientes de un componente de software, es decir, es una medida que nos dice el número de usos que hacemos de clases que están fuera de nuestro componente. De igual manera que antes, lo sabemos porque hacemos uso de atributos y/o métodos de clases de artefactos externos.
Un valor alto indica que nuestra clase tiene muchas dependencias lo que significa que cambios en aquellos artefactos de los que dependemos pueden llevarnos a cambiar el nuestro.
Inestabilidad (I)
La inestabilidad es la métrica que ‘enfrenta’ al acoplamiento aferente y eferente ofreciéndonos un indicador de la resiliencia del artefacto de software medido. La relación se da a través de la siguiente fórmula:
Inestabilidad = Acoplamiento eferente / (Acoplamiento eferente + Acoplamiento aferente)
Por lo tanto, los valores van a estar entre 0 y 1. Por ejmplo:
Para interpretar el valor del resultado, nos fijaremos en los dos extremos: valores de cero o valores de uno:
- Valores de 0: tienen muchas dependencias entrantes y no salientes. Estos artefactos son más difíciles de modificar debido a la alta responsabilidad que tienen con el resto de artefactos que dependen de él. Por lo tanto, son más estables (mayor esfuerzo de cambio), y, lógicamente, responsables (dependen de él) e independiente (no dependen de nadie)
- Valores de 1: tienen muchas dependencias salientes y no entrantes por lo que son inestables (menor esfuerzo de cambio), nadie los usa (irresponsables) y son dependientes (usan otros componentes externos) así que se pueden ver afectados por cambios en los artefactos de los que depende.
Abstracción (A)
El principio de abstracciones estables (Stable-Abstractions Principle — SAP) relaciona la estabilidad y abstracción. Por un lado, nos dice que un componente estable debe ser también abstracto para que su estabilidad no impida que se extienda. Y, por otro lado, nos dice también que un componente inestable debe ser concreto ya que su inestabilidad permite cambiar fácilmente el código.
Que un componente de software estable sea, además, extensible, nos dota de una mayor flexibilidad a la hora de programar haciendo que no se limite el diseño del software.
El valor de la métrica de la abstracción (A) es una simple relación de clases abstractas de un componente y la cantidad total de clases que hay en él.
donde Nc es el número de clases en el componente y Na es la cantidad de clases abstractas en el componente.
Los valores de la métrica pueden ir de 0 a 1.
- Valores de 0: implica que el componente no tiene clases abstractas en absoluto.
- Valores de 1: implica que el componente no contiene más que clases abstractas.
Relacionando estabilidad (I) y abstracción (A). Encontrando buenos componentes.
Una vez conocido como podemos calcular la estabilidad (I) y la abstracción (A), estamos en posición de definir la relación existente entre ambas con el objetivo de encontrar buenos componentes de software.
Podemos crear un gráfico con la abstracción (A) en el eje vertical y la I en el eje horizontal. Si trazamos los dos tipos de componentes “buenos” en este gráfico, encontraremos los componentes que son estables y abstractos en la parte superior izquierda en (0,1) y los componentes que son inestables y concretos se encuentran en la parte inferior derecha en (1,0).
Esto es todo por el momento en cuanto a métricas de calidad para componentes de software, en la próxima entrada estudiaré otras métricas de calidad, a ver si logro enterarme de que va la película 😆
Como siempre, cualquier comentario, mejora, sugerencia o corrección son bienvenidos. Gracias por adelantado.
¡chimpún!
Bibliografía
- https://en.wikipedia.org/wiki/Software_package_metrics
- https://www.future-processing.pl/blog/object-oriented-metrics-by-robert-martin/
- Martin, Robert C. (2002). Agile Software Development: Principles, Patterns, and Practices. Upper Saddle River, NJ: Pearson Education. ISBN 9780135974445. Las figuras 28–5 y 28–6 han sido extraídas de este libro.
