Mostrando entradas con la etiqueta calidad. Mostrar todas las entradas
Mostrando entradas con la etiqueta calidad. Mostrar todas las entradas

martes, 18 de enero de 2011

Sonar 2.5 al fin en la calle

Después de un par (o de tres) de release candidates ya disponemos de la versión 2.5 del mejor sistema de control de la calidad de los desarrollos existente, Sonar.

Con algo de retraso, la versión 2.5 trae las muy esperadas funcionalidades:

  • herencia de perfiles, compartiendo reglas de configuración en un perfil común.

  • seguimiento de las violaciones a lo largo del tiempo, detectando nuevos incumplimientos

    • entre análisis previos

    • un número de días

    • desde una versión

    • desde una fecha


  • cambios de medidas a lo largo del tiempo, con igual comportamiento que el anterior

  • nuevas reglas para Java:

    • la instrucción break no debe usarse fuera de un switch

    • la instrucción continue no debe usarse

    • la complejidad total de una clase no debe ser superior a un límite

    • el DIT no debe ser superior a un límite


  • nuevas tareas de mantenimiento y limpieza de base de datos

  • mejoras en los servicios web para obtener un histórico de las medidas

  • soporte para la anotación @SuppressWarnings para mejorar el comentario //NOSONAR



La dirección de la descarga, como siempre, en SonarSource.

Y tal y como podeis leer en la guía de actualización, la versión 2.5 tiene una serie de detalles a tener en cuenta,

  • limpieza de histórico configurable, aunque por defecto se eliminará la información con más de cinco años, etc.

  • la propiedad "sonar.reuseExistingRulesConfiguration" se eliminará

  • se añadirá una nueva regla de Findbugs al perfil "Sonar way with Findbugs"



Por último, recordaros que Total Quality Plugin sigue siendo compatible con esta nueva versión, y que podéis instalarlo sin problemas desde el Update Center.

miércoles, 17 de noviembre de 2010

Sonar 2.4

Tal y como anunció Simon Brandhof en la lista de correo desde hoy miércoles tenemos disponible la versión 2.4 de Sonar.

Las cuatro mejoras fundamentales que incluye son,
  • Posibilidad de personalizar el dashboar (más información)

  • Instalar y actualizar plugins desde el navegador gracias la Update Center (más información)

  • Definir reglas de arquitectura para, por ejemplo, prohibir el acceso a clases *.web.* from *.dao.* (más información)

  • Soporte de Maven 3


También mejora el rendimiento de Findbugs en, al menos, un 30%, que no está nada mal.

Retomando el trabajo activo en Sonar

Después de un tiempo algo alejado he vuelto a participar de forma activa en la forja de plugins de Sonar liberando una nueva versión de Total Quality Plugin compatible con el futuro Update Center.

En breve publicaré algunos posts comentando las novedades de Sonar y qué hace el plugin que ya lidero.

viernes, 3 de julio de 2009

Cambios en el API de Sonar 1.10

Parece que en la versión 1.10 de sonar hay cambios muy importantes en su api de plugins.

Los principales, ya no más collectors, ahora tenemos sensors, y no más jobs, ahora contamos con decorators. ¿Qué supone esto? Fundamentalmente, los decorators (antes jobs) se ejecutan en la máquina que construye y no en el servidor de sonar.

Hay muchos más pero esos son los que más me afectan a mi :-)

Dentro de poco, una nueva versión de MetricsAnalytics, la 0.6.0

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