Cmo interpretar mtricas de

calidad software: entendiendo el

cuadro de mandode Sonar (1/3)
Sonar es quizs la plataforma ms popular para medir la calidad del cdigo (evaluacin esttica y de caja
blanca, principalmente). Sonar obtiene mtricas del cdigo, trabaja con muchos lenguajes,y para ello
utiliza plugins y otras herramientas (PMD, Checkstyle, etc.) y muestra los resultados en un cuadro de
mando.
La herramienta es libre, potente y muy popular. Pero la documentacin sobre la misma es escasa, muy
escasa, y, si bien he encontrado decenas de implantaciones en empresas apenas he encontrado
equipos (muy pocos) que sepan de verdad qu significa cada mtrica del cuadro de mando de Sonar, y
ese el motivo de este post: aclarar el significado del cuadro de mando de Sonar.
Vamos all.

El cuadro de mando de Sonar

A travs de la interfaz de Sonar podemos ver de forma detallada los puntos dbiles de nuestro proyecto
como errores potenciales en el cdigo, escasez de comentarios, clases demasiado complejas, escasez de
cobertura de las pruebas unitarias, y ms.
Realmente el cuadro de mando que aparece en Sonar, es el resultado de analizar nuestro cdigo con los
plugins o herramientas que hemos instalado en el programa. Sonar trae instalados por defecto
herramientas de anlisis dinmico y esttico de cdigo (caja blanca) como Checkstyle, PMD, Findbugs,
etc., adems de implementaciones propias del equipo de Sonar, para obtener distintas mtricas del
software.
A continuacin puedes ver la imagen tpica del cuadro de mando de mtricas de Sonar.

Figura 1.Vista del cuadro de mando principal de un proyecto en Sonar

Podemos configurar las mtricas que queremos que se muestren en el cuadro de mando o aadir nuevas
mtricas de plugins que instalemos.

Las mtricas que muestra el cuadro de mando de Sonar por defecto para cada proyecto son las que
veremos a continuacin.
1. Complejidad
Cuando en Sonar se habla de complejidad se refiere a complejidad ciclomtica (te recomiendo aqu este
post complejidad ciclomtica, o la mtrica esencial para evaluar el diseo software). La parte del cuadro
de mando que trata sobre ello es la que se muestra en la siguiente figura.

Figura 2. Complejidad ciclomtica

1.1. Cmo calcula Sonar la complejidad ciclomtica?
Sonar, al analizar nuestro cdigo para calcular la complejidad ciclomtica, mantiene un contador. Cuando
el flujo de una funcin se altera, es decir, se produce un salto, este contador de la complejidad aumenta
en 1. Cada funcin tiene como mnimo una complejidad de 1, aunque no hayamos programado nada en
ella (se suma 1 por la llamada al mtodo).
En el caso de Java este valor se obtendra de la siguiente forma:

Cuando Sonar encuentra las palabras clave if,for,while,case,catch, throw,return (sin

ser la ltima sentencia de un mtodo), &&, ||, ?, else, se aumenta el contador global de
complejidad ciclomtica en 1. Tambin se aumenta en 1 el contador por la cabecera del mtodo.

Los mtodos get() y set() (accesores) no entran en esta cuenta, es decir, Sonar no aumenta en 1 la
complejidad ciclomtica total al encontrar la cabecera de un mtodo de este tipo.

Un ejemplo del clculo de la complejidad ciclomtica en Sonar para Java sera el de la Figura 3.

Figura 3. Ejemplo del clculo de la complejidad ciclomtica en Java

Para ver como calcula Sonar la complejidad ciclomtica en otros lenguajes se puede ver la tabla de
la esta pgina.

En lo que refiere a complejidad el cuadro de mando muestra tres tipos: la de mtodo, la de clase, la de
fichero y la total.

Complejidad/mtodo:Es la media de la complejidad por mtodo, es decir, la suma de la

complejidad/mtodo de cada clase dividido entre el nmero de mtodos totales de nuestro software.

El valor que aparece en la Figura 2 es una media global de nuestro programa analizado. Si queremos ver
este valor desglosado, accediendo a alguna clase del sistema nos encontraremos una seccin parecida a
la siguiente:

Figura 4. Lista de mtricas de una clase

El valor de complejidad/mtodo que aparece en cada clase, es el valor total de complejidad ciclomtica de
esa clase dividido entre el nmero de mtodos. En el ejemplo de la Figura 2 sera:

Complejidad/clase: Es la media de la complejidad de todas las clases, es decir, la suma de la

complejidad ciclomtica total de cada clase (obtenida como la suma de la complejidad de cada uno de sus
mtodos), dividida entre el nmero de clases.

Complejidad/fichero: Es la media de la complejidad por fichero.

Complejidad total (Total): Es la complejidad ciclomtica total del sistema (es decir, el sumatorio de la
complejidad ciclomtica de todos los mtodos de nuestro software).

De todos estos valores que nos muestra el cuadro de mando principal de Sonar (ver Figura 2), los valores
de los que se puede deducir ms informacin acerca de la calidad nuestro sistema son de la
complejidad/mtodo y por clase.

1.2. Valores recomendados de complejidad ciclomtica

Saber que un programa tiene un valor muy alto de complejidad ciclomtica (lo que hemos llamado
complejidad ciclomtica total, vase en la Figura 2 con un valor 68313) no nos aporta demasiado a la hora
de decidir qu acciones llevar a cabo para mejorar nuestro software.
Esto ocurre porque no existe un valor umbral aproximado de la complejidad ciclomtica total que un
software debera tener (no todo el software tiene el mismo tamao, ergo, no podemos realizar una
estimacin de un valor de complejidad ciclomtica que no deberan sobrepasar todos los programas).
Sin embargo si podramos decir que la complejidad ciclomtica de cada mtodo, y en consecuencia
tambin la media de la complejidad ciclomtica/mtodo no debera sobrepasar el valor de 30. No obstante
el valor adecuado de complejidad ciclomtica depender de lo que establezca la organizacin, no siempre
deber tomarse como referencia ese valor de 30. Pero podemos decir que 30 en un mtodo ya es
bastante.

Por ello, le parmetro del cuadro de mando de ms utilidad es la complejidad/mtodo, que, igualmente, no
debera ser ms de 30.
Por ltimo, un valor muy alto de complejidad ciclomtica por clase, debido a su propia definicin, nos
indica sntomas de un mal diseo, hace que el cdigo sea ms difcil de entender y dificulta la cobertura
de pruebas unitarias, puesto que habra que realizar ms test para probar cada uno de los caminos
independientes extra de nuestro cdigo. En este post complejidad ciclomtica, o la mtrica esencial para
evaluar el diseo software, viene todo explicado.
Una buena ayuda para ver esto es emplear las nubes de palabras (Figura 5) que ofrece Sonar, a las que
accedemos desde el men de Herramientas -> Nubes. En este apartado si seleccionamos Complejidad
ciclomtica, podremos saber a partir de un vistazo rpido, qu clases tienen mayor complejidad
ciclomtica del sistema.

Figura 5. Nube de palabras Sonar

Puedes ver la continuacin de est post aqu: Cmo interpretar mtricas de calidad software: entendiendo
el cuadro de mando de Sonar (2/3)
2. Cdigo duplicado
El cdigo repetido es una mtrica bsica de calidad, y junto con la complejidad ciclomtica, es el mayor
enemigo de la mantenibilidad (aqu hay un post sobre el tema y aqu otro post sobre estas dos mtricas)

Figura 6. Cdigo repetido

Lneas duplicadas: Nmero de lneas involucradas en una duplicacin

Bloques duplicados: Nmero de bloques de lneas duplicadas

Archivos duplicados:Nmero de archivos involucrados en una duplicacin.

Lneas duplicadas (%): (Nmero de lneas duplicadas/Nmero total de lneas) *100

Por defecto se considera una duplicacin si 10 lneas sucesivas de cdigo Java estn repetidas, pero se
puede modificar este lmite a travs de la propiedad sonar.cpd.java.minimumLines
Por ejemplo, si vamos a analizar un proyecto con Maven, y queremos cambiar a 30 el lmite al que se
considera cdigo duplicado, deberemos escribir en la terminal lo siguiente:
mvn sonar:sonar -D sonar.cpd.java.minimumLines=30
An as, despus de consultar detenidamente la documentacin y los foros de Sonar, no nos queda muy
claro el criterio que utiliza la herramienta para considerar el cdigo duplicado, y no tenemos informacin
acerca de a partir de cunto se considera duplicacin en otros lenguajes de programacin.

3. Documentacin y comentarios

Figura 7. Documentacin y comentarios

Documentacin

API pblica:Nmero de clases pblicas, mtodos pblicos (sin contar mtodos de acceso como get y set)
y propiedades pblicas (sin contar aquellas que son de la forma public static)

API pblica sin documentar: Nmerode APIs pblicas sin una cabecera de comentarios, sin un
Javadoc.

API pblica documentada (%):

Comentarios

Lneas comentadas: Nmero de lneas que contienen un comentario.

Comentarios (%):

De esta frmula se deduce lo siguiente:

Si el valor es un 50%, el nmero de lneas de cdigo es igual al nmero de lneas comentadas.

Si el valor es un 100%, significa que el archivo solo contiene comentarios.

4.Tamao

Figura 8. Mtricas relacionadas con el tamao del sistema

Lneas de cdigo: Nmero de lneas de cdigo, sin contar los comentarios (en la Figura 8 seran 365375)

Lneas: Nmero de lneas totales (lneas de cdigo + lneas de comentarios).

Accesores: Nmero de mtodos get () y set () totales.

El resto de mtricas que aparecen siguen la misma forma que las anteriores, es decir, se muestra el
nmero de paquetes, clases, mtodos o ficheros totales.

5. Violaciones

Figura 9. Violaciones de cdigo

Issues: Nmero de malas prcticas (violaciones) en el cdigo. Por ejemplo, los nmeros mgicos,
llamar a un mtodo que no es un constructor con el mismo nombre que una clase etc.

Cumplimiento de reglas (%)=

Si el valor es negativo, se redondea a 0%

Las violaciones ponderadas son la suma de todas las violaciones multiplicadas por los coeficientes
asociados a su severidad. Para asociar un peso a las severidades, hay que loguearse como administrador
en Sonar, e ir a Ajustes > Ajustes Generales y establecer la propiedad pesos de las reglas (Rules weight).
Los valores por defecto son 10 para las violaciones bloqueantes, 5 para las violaciones crticas, 3 para las
violaciones mayores y 1 para las menores. Logueados como administradores en la herramienta,
podremos definir nuevas violaciones en el cdigo.
Post anterior: Cmo interpretar mtricas de calidad software: entendiendo el cuadro de mando de Sonar
(1/3)
Puedes ver la continuacin de est post aqu: Cmo interpretar mtricas de calidad software: entendiendo
el cuadro de mando de Sonar (3/3)
6. Diseo

Figura 10. Mtricas de diseo

Esta mtrica nos sirve para controlar nuestro diseo. Aunque un diseo sea bastante bueno desde el
principio, puede ir sufriendo una cierta erosin a lo largo del tiempo. Esta mtrica calcula los ciclos que
hay entre paquetes en nuestro sistema, por lo que ir revisndola cada cierto tiempo es bueno para saber
cmo evoluciona el diseo de nuestro software y poner remedio si empeora.

Cuando dos, tres o cuatro paquetes estn involucrados en un ciclo, quiere decir que esos paquetes
dependen unos de otros y no se pueden dividir, reduciendo la modularidad del sistema, y haciendo que el
sistema sea ms difcil de probar y menos mantenible.
A la izquierda de este cuadro de mando de diseo, aparece el nmero total de ciclos presentes en todo el
sistema, y el ndice de interdependencia entre paquetes, que nos da una idea del grado de acoplamiento
general del sistema (un valor 0% significa que no hay ningn ciclo en el sistema, y un valor de 100% que
los paquetes estn muy acoplados).

La frmula del ndice de interdependencia entre paquetes es la siguiente:

Donde:
Dependencias entre archivos que hay que reducir indica el nmero de dependencias entre archivos que
hay que reducir para eliminar todos los ciclos entre directorios.
Una vez que hemos observado la zona izquierda de este cuadro de mando, tendremos una idea general
acerca del estado del diseo de nuestro software. En la parte derecha de esta seccin, Sonar nos indicar
cuntas dependencias concretas entre paquetes y archivos hay que eliminarpara mejorar el diseo.
Si por ejemplo pinchamos sobre el nmero de dependencias a cortar entre paquetes (en el caso de la
Figura 10, hacemos click en la lnea que dice 230 entre paquetes), accederemos a una pantalla en la
que podremos ver cules son esas dependencias entre paquetes que tenemos que eliminar y los
paquetes que estn involucrados en los ciclos.
Uno de los elementos presentes en esta vista ser la Matriz de dependencias de Sonar (Figura 11):

Figura 11. Matriz de dependencias. Ciclos sospechosos a eliminar

En gris aparecen las dependencias entre los distintos paquetes, y en rojo los ciclos sospechosos y que
involucran a los paquetes.
Por ejemplo, si nos fijamos en el paquete .list, y hacemos click en el nmero 2 con el cuadrado rojo, la
vista cambiar a la Figura 12. El paquete .iterators queda seleccionado, con lo que quiere Sonar nos
quiere decir que el paquete .list tiene 2 dependencias con el paquete .iterators que deben ser eliminadas.

Figura 12. Matriz de dependencias

Profundizando un poco ms en esta seccin y haciendo ms clicks, podremos saber en qu archivos
estn las dependencias y en qu parte del cdigo.

7. Test

Figura 13. Test

Por ltimo, hay una seccin en el cuadro de mando principal de Sonar, donde se muestra informacin
acerca de las pruebas: el % de cobertura de pruebas, y en el caso de que las haya, cuntos test ha
pasado o no nuestro software.
Para obtener resultados en esta seccin, es necesario utilizar un lanzador que analice los proyectos de
Sonar compilando el cdigo, por ejemplo Maven.