Las métricas y su cálculo (K2 - entender, explicar , razonar)

Objetivos:

1. Conocer los tipos de métricas utilizados y sus complejidades

Términos usados en este artículo: MÉTRICA, LOC (LÍNEAS DE CÓDIGO), NÚMERO CICLOMÁTICO, HALSTEAD-METRIC.

Alcance.

• Ciertos aspectos de la calidad de un programa pueden ser medidos utilizando métricas.
•     La métrica sólo tiene relevancia para el aspecto medido (considerado).
• La complejidad estática de un programa puede ser medida.
•     Actualmente hay aproximadamente 100 métricas diferentes disponibles.
• Métricas diferentes tratan aspectos diferentes de la complejidad de porgrama.

1.     Tamaño del programa (por ejemplo líneas de código "lines od code - LOC"). 
2.     Estructura de control del programa (por ejemplo número ciclomático).
3.     Estructura de control de datos (por ejemplo métrica de Halstead "Halstead Metric").

• Es difícil comparar dos métricas diferentes,incluso cuando ambas abordan el mismo atributo del programa.

Métricas del tamaño del programa.

Parece claro que los programas muy grandes son complejos, aunque sólo sea por la gran cantidad de información que hay que considerar para poderlos entender. Según esta apreciación, una primera medida de la complejidad del programa vendrá dada por su tamaño. 

El problema está en definir qué es el tamaño de un programa. O dicho de otra forma, qué es lo que hace que un programa sea considerado como grande o pequeño. Según sea esta definición, tenemos las siguientes métricas:

a. Número de líneas.

b. Métricas de Halstead.

Ambas son fáciles de calcular y ampliamente utilizadas. La primera destaca por su sencillez. El segundo apartado incluye en realidad varias métricas, cada una de ellas centrada en diferentes aspectos de la complejidad software.

Numero de líneas.

Podemos suponer que, en igualdad de otros factores, es más complejo el programa más grande. La suposición implícita que sustenta esta afirmación es que un objeto es más complejo cuando manejamos más información para describirlo. Y el tamaño del programa está en relación directa con la cantidad de información que lo describe (el código de un programa es precisamente información detallada de cómo se ejecuta). 


Contar la cantidad de líneas de código de un programa es una forma sencilla de medir su tamaño. El problema principal de esta sencilla métrica estriba en decidir qué consideramos como línea. Según sea la decisión, estaremos midiendo cosas diferentes:


A). En primer lugar, el mismo programa dará diferente medida según el lenguaje en que sea 
codificado (aunque esto tal vez esté en relación con una mayor o menor complejidad intrínseca" del lenguaje). Así, al comparar tamaños de programas escritos en diferentes lenguajes, no sólo estamos comparando la complejidad de los programas, sino también la de los lenguajes utilizados. Por eso, para quedarnos con la componente debida al propio programa, se hace necesario realizar comparaciones para el mismo lenguaje.

B). En segundo, tenemos las líneas de comentario. Aunque puedan añadir más complejidad al aumentar la cantidad de información que hay que asimilar, también simplifican la comprensión del código. Por tanto, si las contamos, nos estaremos centrando más en la cantidad de información total. Si no las contamos, nos centraremos sin embargo en la aportada sólo por el código.

C). Por último, están las líneas de declaración de datos. Quizás no deberían considerarse de la misma manera que las líneas de código, ya que la diferencia conceptual entre ambas es muy clara.

Según el criterio que sigamos, tendremos una métrica distinta. Posiblemente, la más usada sea la cuenta pura y simple de todas las líneas del programa, por ser la más sencilla.

Métricas de Halstead.

Una forma más precisa de medir el tamaño de un programa fue propuesta por Halstead, como parte de su ciencia del software [Halstead, 1977]. Para ello, considera que el código está formado por unas unidades que llama operadores y operandos, parecidos a los tokens que un compilador puede distinguir en ese código [Henry y Selig, 1990]. Y estos operadores y operandos no contribuyen siempre de igual forma a la complejidad. Es necesario considerar, además del número total de elementos (operadores y operandos), el número de éstos que son diferentes (esto es, el vocabulario del programa). Investigando las relaciones entre estas cuentas, obtendremos unos cuantos parámetros que intentarán medir diferentes aspectos de la complejidad del programa.

A continuación pasamos a estudiar con algo de detalle esta métrica. Para ello utilizaremos la 
siguiente notación:

n1: número de operadores diferentes.
n2: número de operandos diferentes.
N1: número total de operadores.
N2: número total de operandos.
n: vocabulario de un programa (n=n1+n2).
N: longitud total del programa (N=N1+N2).

Según Halstead, se puede calcular de forma bastante aproximada el valor de N (longitud total)

mediante la fórmula

N proporciona una medida similar a la del apartado anterior (líneas de código), y que está, como ella, en relación directa con la cantidad de información total del programa. Como puede observarse, la estimación de N puede hacerse a partir únicamente del vocabulario empleado. Por lo tanto la complejidad debida al tamaño del programa, depende en última instancia sólo de ese vocabulario. 

Además, se define el volumen de un programa como

V=Nlog2n

Y el volumen potencial como

V*=N*log2n*

donde n* es el tamaño del vocabulario potencial. El vocabulario potencial es algo así como el vocabulario mínimo que podría usar una codificación que hiciera lo mismo que la estudiada. 

Se corresponde normalmente con el de la llamada a una función que haga la tarea deseada. Se usa como referencia para obtener parámetros normalizados y por tanto más comparables

Número ciclomático.

McCabe [McCabe, 1976] propone una medida de la complejidad de un programa, basada en su grafo de control, que ha sido ampliamente aceptada. Su éxito probablemente se deba, entre otras causas, a la gran facilidad con que se calcula, a que su significado es intuitivamente sencillo de asimilar, y a que estudios sobre programas reales avalan su relación con el tiempo de desarrollo, la dificultad de mantenimiento, etc. 

Esta medida no es otra que el número ciclomático, que se define para un grafo dado. Para 
calcularlo, supongamos que tenemos un grafo correspondiente al flujo de control de un programa, con a arcos, n nodos y c componentes conectados (normalmente, c valdrá 1). La complejidad ciclomática de ese programa vendrá dada por la siguiente fórmula:

V(G)=a-n+2 c

El número ciclomático puede entenderse como el número mínimo de caminos necesario para,
mediante combinaciones, construir cualquier otro camino presente en el grafo. Utilizamos el término camino en el sentido usual, como una sucesión de nodos que puede recorrerse siguiendo arcos presentes en el grafo.

Por ejemplo, si tenemos un grafo , donde a=12 y n=10, tiene una complejidad ciclomática que puede calcularse como:

V(G)=12-10+2.1=4