miércoles, 10 de junio de 2009

Sonar Metrics Analytics Plugin

Sonar[1] es un sistema para la gestión de la calida del código de los proyectos de desarrollo que, como le gusta decir a uno de los fundadores de SonarSource[2], trata de dar caza a los siete pecados capitales aplicados al código fuente. Pero, hasta ahora, siempre se escapaban un par de ellos, el mal diseño y arquitectura. Hasta ahora porque gracias a Sonar Metrics Analytics Plugin[3], a JDepend[4] y Ckjm[5] están cerca de caer.

El plugin trata de acercar el funcionamiento de XRadar[6] al mundo de Sonar, sin llegar a entrar tan en detalle como sí lo hace él. Esto es así porque el objetivo es otro, dotar de métricas de diseño y arquitectura y buscar un valor (relativamente objetivo) de la calidad del proyecto.

Sonar Metrics Analytics añade nuevos dominios y nuevas métricas a Sonar, y un punto de extensión en el dashboard.


Los dominios "Design" y "Architecture", y las métricas a nivel de clase por ckjm y a nivel de paquete por jdepend. Así, obtenidas a nivel de paquete por jdepend,
  • tc, Number of Classes and Interfaces. Número total de clases concretas y abstractas (e interfaces) en un paquete, como un indicador de la extensibilidad del paquete. Introducido en el dominio "Size".
  • cc, Concrete Class Count. Número de clases concretas (instanciables) en un paquete, introducido en el dominio "Size" de sonar.
  • ac, Abstract Class (and Interface) Count. Número de clases abstractas (e interfaces) en un paquete, introducido en el dominio "Size".
  • ca, Afferent Couplings. El número de otros paquetes que dependen de las clases del paquete, como indicador de su responsabilidad. Introducido en "Architecture".
  • ce, Efferent Couplings. Número de otros paquetes de los que dependen las clases del paquete, como indicador de su independencia. Introducido en "Architecture".
  • a, Abstractness. El porcentaje del número de clases no instanciables frente al total de clases del paquete, donde 0% indica que el paquete es totalmente concreto y el 100% que es completamente abstracto. Introducido en "Architecture".
  • i, Instability. El ratio del acoplamiento eferente frente al acoplamiento total tal que i = ce / (ce + ca). Es un indicador de la resistencia al cambio del paquete donde un 0% indica que es completamente estable y el 100% indica una inestabilidad total. Introducido en el dominio "Architecture".
  • d, Distance from the Main Sequence. Es la distancia de un paquete frente a la línea ideal a + i = 100%, indicando el balance del paquete entre abstracción y estabilidad. Los paquetes "perfectos" son los que son completamente abstractos y estables, y los que son totalmente concretos e inestables. Esta métrica está medida porcentualmente donde 0% indica que el paquete coincide con la línea ideal y el 100% que se encuentra muy retirado. Se incorpora como los anteriores en el dominio de "Architecture".
  • dc, Package Dependency Cycles. Es un valor que indica el número de ciclos en los que se ve implicado el paquete. En cero es el mejor valor posible para esta métrica incluida en "Architecture".

Obtenidas a nivel de clase por ckjm tenemos,
  • dit, Depth of Inheritance Tree. Proporciona una medida de los niveles de herencia (profundidad) desde la raíz de la jerarquía empezando en 1, quedando incluida en el dominio "Design". Cuanto mayor sea el valor peor será el diseño.
  • cbo, Coupling between object classes. Número de clases acopladas a una dada (acoplamiento eferente), y puede darse desde llamadas a métodos, accesos a atributos, herencia, tipos de respuesta, argumentos y excepciones. Incluida en "Design". Cuanto mayor sea el valor peor será el diseño.
  • rfc, Response for a Class. Indica el número de métodos diferentes que pueden ser ejecutados cuando un método del objeto de la clase es invocado. Se incluye en "Design" y cuanto mayor sea su valor peor será el diseño.
  • lcom, Lack of cohesion in methods. Cuenta los conjuntos de métodos que no usan ninguno de sus atributos, debiendo tender a cero para buscar un mejor diseño. Se incluye en el dominio "Design".

Posteriormente, se agregan y combinan dando lugar a, desde el punto de vista de la arquitectura,
  • COH, Cohesion. Número de paquetes con ciclos dividido entre el total. Incluido en "Architecture" a nivel de proyecto. A nivel de paquete también se agrega la métrica pero con dos únicos valores posibles, 0 o 100, donde 0 quiere decir que el paquete tiene ciclos y el 100 que está limpio de ellos.
  • ADI, Distance. Número de paquetes con distancia superior a 20% (este dato es configurable) dividido entre el total de paquetes, a nivel de proyecto. A nivel de paquete se incluye también pero, como en el caso anterior sólo tiene dos valores posibles, 0 que indica que la distancia del paquete es superior a 20 y 100 que indica que es inferior.
  • ARCH, Architecture. El valor medio de las dos métricas de arquitectura (COH y ADI), añadidas a nivel de proyecto y paquetes en el dominio "Architecture".

desde el punto de vista del diseño,
  • NOM, Number of Methods. Controla la complejidad de los métodos y se calcula sumando el número de clases con complejidad por método menor que 20 (este valor es configurable) dividido entre el total de clases de un paquete. A nivel de proyecto se calcula haciendo la media de los NOM de los paquetes, y se añade en "Design".
  • RFC, Response for Class. Número de clases de un paquete con rfc menor que 50 (este valor es configurable) dividido entre el total de clases del paquete. A nivel de proyecto se calcula haciendo la media de los paquetes. Incluido en "Design".
  • CBO, Coupling Between Objects. Número de clases con cbo menor que 5 (valor configurable) dividido entre el total de clases (todas del paquete). Como en los anteriores a nivel de proyecto se calcula con la media, y se incluye en "Design".
  • DIT, Depth of Inheritance Tree. Se calcula contando las clases con dit inferior a 5 (valor configurable) dividido entre el total de clases del paquete. Para los proyectos el cálculo se realiza haciendo la media de los DITs de sus paquetes. Se incluye en "Design".
  • DESIGN, Design. Se obtiene sumando el 20% de NOM, más el 30% de RFC, más el 30% de CBO, más el 20% de DIT, tanto en paquetes como en proyectos, y se incluye en "Design".

desde el punto de vista de las pruebas,
  • COVERAGE, Code coverage by unit tests. Tomado directamente de las métricas del core de Sonar.

desde el punto de vista del código,


  • DOC, Documentation. Se obtiene multiplicado por 10/4 el valor de la métrica de Sonar Documentation (%). Incluida en "Documentation" tanto a nivel de paquete como a nivel de proyecto.
  • DRY, Dryness. Es el inverso del % de líneas duplicadas, a nivel de paquete y proyecto, e incluyendolo en el dominio "Size".
  • RULES, Rules compliance. Tomado directamente de las métricas del core de Sonar.
  • CODE, Code Quality. Se obtiene sumando el 15% de DOC, más el 40% de DRY, y el 45% de RULES, tanto en paquetes como en proyectos, y se incluye en "Rules"

por último, la calidad total,
  • TQ, Total Quality. Se obtiene haciendo la media de los valores obtenidos en arquitectura, diseño, pruebas, y código, tanto en proyectos como en paquetes. Incluido en el dominio "General".


Permite configurar desde la administración, como se ha comentado, los siguientes valores,
  • cota para el cálculo de ADI.
  • cota para el cálculo de NOM.
  • cota para el cálculo de RFC.
  • cota para el cálculo de CBO.
  • cota para el cálculo de DIT.

Y por cierto andaluces, ya está en Madeja[7].

Uso e Instalación [8]
- Descargar el jar [9]
- Copiarlo en el directorio /extensions/plugins/ y reiniciar el servidor. Si has construido el war tendrás que volver a hacerlo cada vez que instales un nuevo plguin.
- Lanzar un nuevo análisis y las métricas empezará a entrar.

Temas pendientes y para futuras versiones,
- Una página de resumen más completa usando un punto de extensión de página.
- Gráfico de distribución de las distancias de los paquetes.
- Ampliación de las métricas de Arquitectura.
- Ampliación de las métricas de Pruebas Unitarias y de Integración.

El equipo que ha dedicado Isotrol, SA[10] para el desarrollo del plugin,
- Nicolas Bertet, responsable funcional.
- Emilio Escobar Reyero, responsable técnico.

Enlaces
[1] http://sonar.codehaus.org
[2] http://www.sonarsource.com
[3] http://redmine.isotrol.org/projects/show/org00003-mtrcsnlytcs
[4] http://clarkware.com/software/JDepend.html
[5] http://www.spinellis.gr/sw/ckjm/
[6] http://xradar.sourceforge.net/
[7] http://www.juntadeandalucia.es/xwiki/bin/view/MADEJADGIAP/VerRecursoSonar
[8] http://docs.codehaus.org/display/SONAR/Install+a+new+plugin
[9] http://redmine.isotrol.org/wiki/org00003-mtrcsnlytcs/Downloads
[10] http://www.isotrol.com
[11] http://www.isotrol.org

5 comentarios:

Jesta dijo...

Muy buen proyecto, y las metricas que añaden son muy utiles para intentar "mejorar" la calidad del software.

Probado, pero los resultados no son tan bonicos como los del ejemplo ;-).

Enhorabuena y seguir asi.

Jose

DanTitan dijo...

Está muy bien el plugin. Sin mebargo me falta algo: una serie de umbrales que categoricen los valores obtenidos en los distintos aspectos de arquitectura, diseño, código y pruebas y para cada una de las métricas de más bajo nivel. Por ejemplo, un 80% en diseño es bueno o es regular, obtener un 80% en dryness puede parecer bueno a primera vista, pero cuando se tiene más de un 20% de código duplicado ya suele ser demasiado.
¿Tenéis pensado establecer estos umbrales? ¿Existe alguna documentación que pueda servir para fijarlos?

Emilio Escobar Reyero dijo...

Hola a los dos :-) y siento la tardanza en responder.

Veamos, el plugin como tal está deprecado. Como puede verse en
http://forge.isotrol.org/wiki/org00003-mtrcsnlytcs
se quedó en la versión 1.11 de sonar.

Los umbrales de los que comentas los puedes fijar desde la administración de Sonar. Además, el plugin te permite configurar también los pesos de cada métrica concreta (incluso cambiar la fórmula como tal) desde la administración también.

Por último, hay otro plugin nuevo, compatible con la versión 2.x de sonar en el que también participo,

http://docs.codehaus.org/display/SONAR/Total+Quality+Plugin

El concepto es similar al Metrics Analytics.

madness dijo...

donde puedo conseguir los plugins? la pagina de isotrol ya no existe!! necesito su ayuda

Emilio Escobar Reyero dijo...

Hola madness, Metrics Analytics se encuentra deprecado. En su lugar mejor utilizar Total Quality