Métricas de software, bienvenidos a los grises!!

Para este artículo me propuse analizar un segmento muy pequeño de las métricas que podemos obtener en el escenario de la ingeniería de software. Para este objetivo tenemos que tener claro que la medición es un elemento clave en cualquier proceso de ingeniería, las medidas se emplean para comprender mejor los atributos de los modelos que se elaboran y con esto se puede evaluar la calidad de los productos.

Hay una discusión de varios autores sobre las medidas directas de varias ramas de la ingeniería en contraste con las medidas indirectas de la ingeniería de Software, para este punto voy a citar a Fenton:

"La medición es el proceso mediante el cual se asignan números o símbolos a los atributos de entidades reales para definirlas de acuerdo con reglas claramente establecidas… En las ciencias físicas, la medicina y, más recientemente, las ciencias sociales, ahora podemos medir atributos que se consideraban imposibles de medir…Por supuesto, estas mediciones no tienen el mismo refinamiento que casi todas las de las ciencias físicas…Pero existen (y muchas decisiones importantes se toman con base en ellas). Sentimos que la obligación de tratar de "Medir lo inmedible" para mejorar nuestra comprensión de entidades particulares es tan importante en la ingeniería del software como en cualquier otra disciplina."

Podría enunciar y trabajar con diversas métricas en escenarios de "análisis" o "diseño", particularmente en este artículo voy a desarrollar un escenario sobre el diseño. Ahora los invito a reflexión:

"Sería inconcebible que el diseño de un nuevo avión, un nuevo chip de computadora o un edificio de oficinas se realizara sin definir las medidas del diseño, sin determinar las métricas de diversos aspectos de la calidad del diseño y sin usarlas para guiar la manera en que evoluciona el diseño. Sin embargo, a menudo el diseño de sistemas de software complejos suele avanzar casi sin medición. La ironía es que se dispone de métricas de diseño para el software, pero la gran mayoría de los desarrolladores siguen ignorando su existencia" – Pressman

Para continuar el análisis vamos a trabajar con la OO, y para ello me pareció interesante traer algunas opciones en este escenario.

Sabemos que la clase es la unidad fundamental de un sistema orientado a objetos. Por lo tanto las medidas y métricas de una clase individual, la jerarquía de clase y las colaboraciones de clase serán invaluables para un ingeniero de software que debe valorar la calidad del diseño.

En este caso les voy a presentar las métricas CK:

• Métodos ponderados por clase (MPC)
  
• Árbol de profundidad de herencia (APH)
  
• Número de descendientes (NDD)
  
• Acoplamiento entre clases de objetos (AECO)
  
• Respuesta para una clase (RPC)

http://www.aivosto.com/project/help/pm-oo-ck.html

Particularmente voy a realizar un detalle de MPC:

"Supongamos que n métodos de complejidad c1,c2,c3 están definidos por la clase C. La métrica de complejidad específica que se elija, debe normalizarse con el fin que la complejidad nominal de un método tome un valor de 1.0"

MPC = ∑ ci

Para i = 1 a n.

Bueno, el ambiente es formal es reconfortante para los ingenieros, pero vamos a detallar esto un poco. En primer lugar, es mi deber decir que, conforme crece el número de métodos de una clase determinada, es probable que se vuelva más y más específica de la aplicación, lo que limita las posibilidades de reutilización.

Ahora, veamos el desarrollo de los métodos ponderados, en la definición queda claro la operación de cálculo pero en el detalle se nombra la métrica de complejidad y de hecho es el eje de cálculo, para este punto el ejemplo que les traigo es basado en la utilización de la "complejidad ciclomática" algo que seguramente han sentido nombrar enunciado por McCabe.

http://javier.callon.org/complejidad-ciclomatica

http://en.wikipedia.org/wiki/Cyclomatic_complexity

(Más fórmulas y cálculos para lograr el objetivo)

En síntesis, tenemos un esquema de cálculo para trabajar sobre una clase y la definición de la complejidad a utilizar. En este punto se deben estar preguntando, que utilizar para que este cálculo sea lo más automatizado posible, y de hecho existen varias iniciativas sobre diversos lenguajes, como en mi caso particular trabajo con Visual Studio y C# el IDE tiene una prestación que justamente analiza entre otras cosas la complejidad ciclomática de las clases:

¿La aplicamos?

Como vemos en la figura anterior, tengo definida una clase de nombre "EmpleadoPorComisión" y al ejecutar el análisis de métricas de código VS me muestra el cálculo de complejidad ciclomática, para este ejemplo sobre el método en cuestión he realizado algunas barbaridades para incrementar el valor de la métrica, con varias estructuras de decisión.

Si tengo este cálculo resuelto por la herramienta de programación el resto es muy simple de analizar y evaluar ya que se resume a una sumatoria.

Veamos un poco más de detalle, les muestro un método constructor en este ejemplo:

public EmpleadoPorComision(string nombre, string apellido,string nss, decimal ventas, decimal tarifas)

{

primerNombre = nombre;

apellidoPaterno = apellido;

numeroSeguroSocial = nss;

ventasBrutas = ventas;

tarifaComision = tarifas;

}

Les muestro el análisis de código:

Como pueden ver, el valor es muy pequeño "1", ahora vamos a generar problemas al método constructor, sin sentido, solo a modo de demostración:

public EmpleadoPorComision(string nombre, string apellido,string nss, decimal ventas, decimal tarifas)

{

primerNombre = nombre;

apellidoPaterno = apellido;

numeroSeguroSocial = nss;

ventasBrutas = ventas;

tarifaComision = tarifas;

string demo1 = nombre;

string demo2 = nombre;

string demo3 = nombre;

string demo4 = nombre;

string demo5 = nombre;

string demo6 = nombre;

string demo7 = nombre;

if (demo1 == "Hola")

{

demo2 = demo3;

}

else
if (demo5 == "Hola")

{

demo2 = demo3;

}

else
if (demo5 == "Hola")

{

demo5 = string.Empty;

}

else

{

demo5 = string.Empty;

}

}

Y su análisis:

El valor aumentó a "4".

Espero que les sea de utilidad, hasta la próxima….