6. Diseño
Figura 10. Métricas de diseño
Esta métrica nos sirve para controlar nuestro diseño. Aunque un diseño sea bastante bueno desde el principio, puede ir sufriendo una cierta erosión a lo largo del tiempo. Esta métrica calcula los ciclos que hay entre paquetes en nuestro sistema, por lo que ir revisándola cada cierto tiempo es bueno para saber cómo evoluciona el diseño de nuestro software y poner remedio si empeora.
Cuando dos, tres o cuatro paquetes están 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 más difícil de probar y menos mantenible.
A la izquierda de este cuadro de mando de diseño, aparece el número 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 ningún ciclo en el sistema, y un valor de 100% que los paquetes están muy acoplados).
La fórmula del índice de interdependencia entre paquetes es la siguiente:
Donde:
Dependencias entre archivos que hay que reducir indica el número 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 diseño de nuestro software. En la parte derecha de esta sección, Sonar nos indicará cuántas dependencias concretas entre paquetes y archivos hay que eliminarpara mejorar el diseño.
Si por ejemplo pinchamos sobre el número de dependencias a cortar entre paquetes (en el caso de la Figura 10, hacemos click en la línea que dice “230 entre paquetes”), accederemos a una pantalla en la que podremos ver cuáles son esas dependencias entre paquetes que tenemos que eliminar y los paquetes que están 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 número 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 más en esta sección y haciendo más clicks, podremos saber en qué archivos están las dependencias y en qué parte del código.
7. Test
Figura 13. Test
Por último, hay una sección en el cuadro de mando principal de Sonar, donde se muestra información acerca de las pruebas: el % de cobertura de pruebas, y en el caso de que las haya, cuántos test ha pasado o no nuestro software.
Para obtener resultados en esta sección, es necesario utilizar un lanzador que analice los proyectos de Sonar compilando el código, por ejemplo Maven.
Posts anteriores:
Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (1/3)
Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (2/3)
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024