archivo

Archivo de la etiqueta: orientación a objetos

El puglin de Sonar Quality Index proporciona otra métrica agregada (resultado de otras métricas) para obtener un valor que indique la calidad del software. En este caso lo que se pretende es obtener un valor entre 0 y 10.

Particularmente me gusta más SIG MM ya que se centra en la mantenibilidad que es lo que realmente me preocupa sobre el software que nos entregan, pero todo es cuestión de gustos y de lo que cada uno valore lo que te calcula la métrica y lo claro que te exprese los resultados. Desde mi punto de vista este indicador da demasiado peso a la verificación de reglas PMD y pone casi al mismo nivel la verificación de estilos que la complejidad ciclomática y no otorga ningún valor al acoplamiento o a la cohesión (algo de lo que también adolece SIG MM).

Para su cálculo se basa en la obtención previamente de cuatro métricas:

– Violaciones de código: basada en los resultados obtenidos mediante la aplicación de las reglas PMD y se calcula a partir de la siguiente fórmula:

Coding Violations = (Blocker * 10 + Critical * 5 + Major * 3 + Minor + Info) / validLines

donde validLines es el número total de líneas de código de la aplicación menos el código duplicado. Como puede darse el caso de que la métrica código duplicado supere al número de líneas de código cuando ocurre esto el valor de validLines es 1. Como casi todas las métricas de Quality Index se hacen en relación al número de líneas válidas la influencia de la duplicidad de código en los resultados finales es importante (como también lo es en el cálculo de otras métricas como Technical Debt o SIG MM, algo que me parece totalmente razonable. Esto va a provocar en consecuencia que soluciones basadas en generadores de código, salvo que éstos estén muy depurados van a verse muy perjudicadas por esta métrica.

– Complejidad: basada en los resultados obtenidos mediante la obtención de la complejidad ciclomática de los diferentes métodos y se calcula a partir de la siguiente fórmula:

Complexity = (Complexity>30 *10 + Complexity>20 * 5 + Complexity>10 * 3 + Complexity>1) / validLines

Como se puede apreciar se le da un peso importante a métodos con una complejidad ciclomática alta que son aquellos que al presentar un mayor número posible de caminos lógicos hace que sean más complicados de mantener

– Cobertura: Se obtiene directamente a partir de la cobertura de código por pruebas unitarias (mirando un comentario del código del plugin (clase CoverageDecorator.java) no tiene en cuenta para el cálculo de esta métrica las líneas duplicadas.

– Violaciones de estilo: basada en los resultados obtenidos mediante la aplicación de las reglas PMD y se calcula a partir de la siguiente fórmula:

Style = (Errors*10 + Warnings) / ValidLines * 10

Una vez calculadas las métricas ya se puede tener el valor de Quality Index:

QI = 10 – (4.5 * Coding – 2 * Complexity – 2 * Coverage -1.5 * Style)

El plugin además de calcularte el valor global, te indica el valor de las 4 métricas (ejes) llevados a la escala correspondiente en función de su peso en la fórmula del cálculo de la métrica, representando en rojo la proporción que incumple y en verde la proporción que cumple.

Se codifica, se construye la aplicación, pero en demasiadas ocasiones se tiene en cuenta como fin único la entrega del proyecto, dejando al margen o dedicándole menos importancia a una programación pensando en futuros mantenimientos.

La dificultad de los mantenimientos depende de muchos factores y algunos de ellos están por encima en importancia de una codificación clara y de calidad, como por ejemplo la búsqueda de una alta cohesión y un bajo acoplamiento, lo cual no debería ser una excusa para olvidarnos de este asunto ya que no se trata solo de que se pueda comprender lo que se ha programado (que no es poco) sino que un código poco cuidado probablemente influirá en una mayor complejidad ciclomática de la aplicación (además de a la mayoría de las variables que determinan la deuda técnica de la aplicación) dificultando, en consecuencia, a la mantenibilidad.

Generalmente nos solemos acordar de todo esto cuando toca realizar el mantenimiento del sistema de información y nos encontramos con que la forma en que se ha codificado hace que se requiera un mayor esfuerzo y en consecuencia coste. Por este motivo importa y mucho como se codifica.

El problema de todo esto es que resulta complicado detectar este tipo de problemas en tiempo de desarrollo ya que obliga a estar encima y revisar el código, lo que puede hacer que casi cueste más el collar que el perro. Por tanto, tenemos que utilizar otras estrategias que faciliten la localización de estos problemas, como es por ejemplo estudiar variables que se pueden incrementar indirectamente por una mala programación (se puede realizar una revisión periódica de las métricas que devuelve Sonar) y complementarlo, si es posible, con la revisión, también periódica, de una muestra de clases de la aplicación.

Siendo realista, veo complicado que una empresa de desarrollo, salvo que las deficiencias encontradas en el proceso de verificación interno sean serias, se pongan a rehacer a módulos ya codificados, pero por lo menos si se aplican estas políticas se puede reconducir la tendencia en el desarrollo y que el proyecto se encuentre dentro de unos umbrales de calidad aceptables (los cuales en algunos casos podrán ser exigidos y verificados por el cliente y provocar un rechazo en la entrega y la consiguiente necesidad de refactorizar partes de la aplicación lo cual se volverá en contra del proveedor ya que tendrá que sufrir en sus carnes las consecuencias de unas malas prácticas.

Martin Fowler es un importante y reconocido autor especialista en ingeniería del software y en el proceso de desarrollo (particularmente en el campo de la refactorización) el cual ya he tenido la oportunidad de citar en un artículo sobre una regla de CheckStyle que no comprendía su significado.

Steve C. McConnell es otro reputadísimo autor y especialista en ingeniería del software, tanto es así, que durante años fue considerado junto a Linus Torvalds y Bill Gates unas de las personas más influyentes en el negocio del desarrollo de software. En la actualidad posee una empresa llamada Construx Software que se dedica a consultoría y formación sobre buenas prácticas en desarrollo de software.

Ambos autores son responsables de las siguientes citas relacionadas con la comprensión del código:

Martin Fowler (traducción libre): “Cualquiera puede escribir código que un ordenador pueda entender. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Steve McConnell (traducción libre): “El buen código es su mejor documentación. Cuando vayas a escribir un comentario, pregúntate, ¿cómo puedo mejorar el código para que este comentario no sea necesario?”.

Sobre este tema ya publiqué una cita que se atribuye a Martin Golding en unos casos y a John F. Woods en otros que complementa perfectamente a éstas.

Como he comentado en otras ocasiones, hacer las cosas bien, tarde o temprano, marca la diferencia.

Cuando se habla de programación orientada a objetos se dice que un buen diseño es aquel que consigue una alta cohesión y un bajo acoplamiento. Como es lógico, estoy de acuerdo, no obstante de los dos conceptos la cohesión, tal vez por entenderse menos su utilidad, es el hermano pobre, es decir, si se tiene en cuenta alguno de los dos (algo que desgraciadamente no ocurre demasiado, ya que no se suele prestar suficiente atención a la calidad del diseño y de la codificación) se suele echar más en cuenta al acoplamiento, además de ser más inteligible por ser más evidentes los problemas existentes cuando el acoplamiento es alto.

La cohesión mide la relación entre los distintos elementos que componen una clase: atributos y métodos. Una baja cohesión da lugar a las denominadas clases tutti frutti, clases que pretenden hacer muchas cosas y diferentes.

Cuando se tienen clases con baja cohesión implica principalmente:

– Falta de comprensibilidad: La clase no sirve a un aspecto concreto, sino a muchos. Cuando pensamos en un objeto lo hacemos entendiendo que sus partes son necesarias para que exista su todo (es decir, las partes por sí solas tienen poca utilidad y es mediante su relación cuando dan entidad al objeto y hacen que en su conjunto (el todo) valga más que la suma de las partes por separado). Cuando tenemos clases cuyos elementos forman un todo, pero ese todo no es identificable con nada, nos encontraremos probablemente con clases que tienen una baja cohesión, con métodos que no guardarán relación con otros muchos de la misma y que servirán a propósitos distintos. Habrá que tener bien documentada la clase para mantenerla posteriormente, porque si la coge un equipo de desarrollo distinto o ha pasado mucho tiempo desde que se implementó resultará complicado entender para qué sirve y qué utilidad tienen muchos métodos y atributos de la misma.

– Dificulta la mantenibilidad: Además de por la disminución de la comprensibilidad de la clase, al tener más código del que debería tener, se incrementará en consecuencia la complejidad ciclomática de la misma y por tanto será más costoso realizar cambios.

– Dificulta la reutilización: Cuando tenemos una baja cohesión quiere decir que hemos modelado una realidad rara, un híbrido de muchas cosas. Se ha implementado una clase para algo muy específico y lo concreto pocas veces es reutilizable.

– Suelen tener un acoplamiento alto (en comparación a una cohesión baja): Tiene su lógica ya que la clase tendrá más métodos que si los diferentes objetos reales que están dentro de la misma se hubieran encapsulado en sus correspondientes clases. Más métodos implican por regla general llamadas a más métodos de clases y paquetes externos y en consecuencia un mayor acoplamiento.

– Tendentes a sufrir modificaciones: Como estas clases son híbridos de varias la probabilidad de tener que sufrir operaciones de mantenimiento crece (tanto como clases distintas pudieran contener en su interior), lo cual tiene su importancia sobre todo si tenemos en cuenta que este tipo de clases son más complicadas de mantener.

Una forma de medir la cohesión la tenemos con la métrica LCOM4, propuesta a partir de la métrica inicial LCOM1 de Chidamber y Kemerer. Esta métrica forma parte del conjunto de las mismas que calcula Sonar haciendo análisis estático de código.

Hace poco me comentaba un proveedor que los resultados obtenidos con Sonar tras realizar el análisis estático del código de las aplicaciones que desarrollaban en su empresa estaban muy condicionados al framework de desarrollo y a las soluciones de generación de código que se utilizaban.

Yo le comenté que no dudaba un ápice, al contrario, del framework de desarrollo utilizado, ya que no solo respetaba las reglas de diseño y codifición establecidas en nuestro libro blanco, sino que además, facilitaba el desacoplamiento de la aplicación a nivel vertical por la existencia de diferentes capas con responsabilidades concretas y además permitía disminuir tiempos de desarrollo. Como todo en la vida es mejorable, pero el nivel que tenía era bastante alto.

Tampoco dudaba lo más mínimo de las soluciones de generación de código, es más me parece muy apropiado que se utilicen este tipo de estrategias ya que además de dar uniformidad a los desarrollos (cogidos de la mano del framework) permiten ahorrar costes de desarrollo.

Calidad y reducción de costes de desarrollo, van unidos de la mano de los frameworks y de los generadores de código. Evidentemente no aseguran nada, ni calidad ni reducción de costes, pero son la base para sustentar desarrollos de calidad a menor coste.

Lo que venía a decirle al proveedor que independientemente de que el framework y la generación de código condicionen una determinada solución, siempre existe el factor humano, ya que hay clases que se tendrán que codificar a mano (incluso subsistemas de negocio completos) y por supuesto la posibilidad de refactorizar determinadas clases determinadas por el framework, sobre todo cuando tengan un alto nivel de acoplamiento.

Es decir siempre es posible mejorar la calidad del código para mejorar la mantenibilidad del sistema. ¿Qué supone un esfuerzo? Por supuesto que sí, pero la clave, como he comentado en tantas ocasiones no consiste en intentar llegar a la perfección, ya que además de no conseguirse, aproximarse a la idea que tengamos de perfección requerirá un esfuerzo (y unos costes) que no merecen, en absoluto, la pena. En estos casos, hay que centrarse en quick wins, centrarse en clases en las que se puede mejorar la codificación y/o bien es necesario realizar una refactorización y en donde estas modificaciones permitan mejorar la calidad global de la aplicación desde el punto del vista del mantenimiento.

Sonar es una herramienta muy útil para detectar este tipo de clases, aunque también sería posible detectar clases candidatas a un alto acoplamiento, antes de desarrollar, mediante la realización de diagramas de clases en los que se refleje las dependencias entre las mismas. Cada una de esas alternativas tiene sus ventajas e inconvenientes. La gran ventaja de Sonar es que te permite medir la calidad desde múltiples puntos de vista e indicarte de manera sencilla qué clases fallan en según qué métricas, su inconveniente es que ya has codificado y todos sabemos que cuánto más tarde se detecten los problemas en la construcción, más costoso resulta corregirlos.

El acoplamiento es un concepto teórico que tiene consecuencias fatales en el mundo real. Un programa con alto nivel de acoplamiento es un programa muy difícil (y en consecuencia) costoso de mantener, en consecuencia, un software con un acoplamiento elevado tiene una deuda técnica también bastante importante.

No tener en cuenta el acoplamiento cuando se desarrolla es caer en el reverso tenebroso de la fuerza, lo mismo resulta más sencillo no tener que pensar en eso cuando se codifica, además no requiere de personal más cualificado (hacer las cosas bien para luego hacer que las cosas sean más sencillas necesita de un esfuerzo y por tanto no es nada trivial). Como ya comenté en un artículo anterior, programar pensando en que no se va a tener que volver a tocar el código es vivir ajeno a la realidad de lo que es el desarrollo de software y el ciclo de vida de los sistemas de información. ¿Puede pasar que no se tenga que tocar? Sí, pero, ¿realmente lo puedes asegurar?, ¿qué te dice tu experiencia?. Cierto es que puedes pensar: “bueno, al final le tocará el marrón a otro”, pero ¿y si al final te termina tocando a ti o a algún compañero?.

Un software fuertemente acoplado es una caja de sorpresas cuando te pones a realizar tareas de mantenimiento, lo más probable es que cuando tapes un agujero se abran dos. Al final se conseguirá sacar el mantenimiento adelante, pero con un esfuerzo, desgaste y coste bastante importante.

El uso de frameworks de desarrollo supone un primer paso para reducir el acoplamiento, pero el uso de este tipo de estrategias por sí mismas no aseguran nada, ya que aunque se “deleguen” determinadas tareas en ellos, al final las “tareas de bajo nivel” residen en el software que se implementa y que el software esté más o menos acoplado depende de las buenas prácticas, conocimientos y experiencias del programador.

A los modelos de clases no se les suele prestar demasiada atención ya que una vez obtenidos los requisitos, construido el modelo de datos y consensuada la interfaz parace que lo demás no tiene demasiada importancia, sin embargo, los modelos de clases sí que permiten ver (por lo menos a alto nivel) situaciones de acoplamiento y tomar decisiones antes de codificar que pueden reducir esta métrica. Evidentemente requiere un esfuerzo y hay que sopesar también en función de las características del sistema si se realiza ese estudio o no, habrá situaciones en las que puede merecer (y merecerá) la pena y otras en las que no (aplicaciones relativamente simples).

Sonar permite calcular muchas métricas de carácter individual, como por ejemplo Cobertura, Duplicated Lines, Complejidad Ciclomática, RFC, LCOM4, etc…, pero también dispone de métricas que ofrecen resultados en función de poner en relación una serie de métricas diferentes.

Un ejemplo de ello lo tenemos en Technical Debt (base como he comentado en otros artículos de lo que es la filosofía y fin último de Sonar, tal y como dice su lema “Put your technical debt under control) y otro lo tenemos por ejemplo en las métricas proporcionada por el plugin de Sonar denominado SIG Maintainability Model.

Como indica la página que el plugin tiene en Sonar, se trata de una implementación del Modelo de Mantenimiento del Software Improvement Group (SIG).

¿Qué es el Software Improvement Group? Es una firma de consultoría holandesa con sedes en otros países europeos, que según especifica en su página web se basa en dar una serie de resultados, basados en hechos (métricas objetivas) y no en opiniones, proporcionando evaluciones de riesgos imparciales, objetivas,verificables y cuantitativas relacionados con los sistemas de información corporativos que se quieran estudiar.

Uno de los servicios que proporciona la empresa SIG es la certificación de la mantenibilidad de los productos software según el estándar internacional ISO/IEC 9126. Dicho estándar clasifica la calidad del software en una serie de aspectos, uno de los cuales es la mantenibilidad basándose el mismo en la obtención de las siguientes métricas: Estabilidad, Facilidad de análisis, Facilidad de cambios y Facilidad de Pruebas.

Por tanto el plugin de Sonar SIG Maintainability Model, permite calcular dichas métricas, las cuales resultan significativas ya que determinan el grado de mantenibilidad de un software basado en un estándar internacional.

Una vez que hemos podido apreciar lo relevante que resulta este plugin, toca analizar como calcular cada una de sus métricas.

El cálculo se basa en la obtención en primer lugar de una serie de métricas más simples (ya que las métricas finales indicadas anteriormente son el resultado de la combinación de las mismas) y clasificando los resultados de dichas métricas en cinco posibles escalas (las cuales voy a ordenar de menor a mejores resultados desde el punto de vista de la mantenibilidad):

Volumen: Se obtiene a partir del número de líneas de código de la aplicación.

Escalas:

–: > 1310000 líneas de código.
-: > 655000 líneas de código.
0: > 246000 líneas de código.
+: > 66000 líneas de código.
++: > 0 líneas de código.

Duplicidades: Se obtiene a partir del porcentaje de líneas duplicadas en la aplicación:

Escalas:

–: > 20% líneas duplicadas
-: > 10% líneas duplicadas
0: > 5% líneas duplicadas
+: > 3% líneas duplicadas
++: > 0% líneas duplicadas

Pruebas unitarias: Se obtiene a partir del grado de cobertura del código a través de pruebas unitarias.

Escalas:

–: > 95% cobertura
-: > 80% cobertura
0: > 60% cobertura
+: > 20% cobertura
++: > 0% cobertura

Complejidad: Se obtiene a partir de la complejidad ciclomática de los métodos.

La forma de cálculo es un poco más compleja ya que se realiza en dos pasos:

1) Clasificar cada método en uno de los siguientes rangos en función de su complejidad ciclomática:

Muy alta: > 50
Alta: > 20
Media: > 10
Baja: > 0

2) A continuación la escala se obtiene a partir del porcentaje de métodos que se encuentran en los rangos definidos en el paso 1):

Escalas:

–: Resto de casos
-: C.C. Media <50%; C.C. Alta <15%; C.C. Muy Alta <5%
0: C.C. Media <40%; C.C. Alta <10%; C.C. Muy Alta <0%
+: C.C. Media <30%; C.C. Alta <5%; C.C. Muy Alta <0%
++: C.C. Media <25%; C.C. Alta <0%; C.C. Muy Alta <0%

Tamaño unitario: Se obtiene a partir del número de líneas de código de los métodos.

La forma de cálculo es un poco más compleja ya que se realiza en dos pasos:

1) Clasificar cada método en uno de los siguientes rangos en función de su número de líneas de código (LOC):

Muy alta: > 100
Alta: > 50
Media: > 10
Baja: > 0

2) A continuación la escala se obtiene a partir del porcentaje de métodos que se encuentran en los rangos definidos en el paso 1):

Escalas:

–: Resto de casos
-: LOC Media <50%; LOC Alta <15%; LOC Muy Alta <5%
0: LOC Media <40%; LOC Alta <10%; LOC Muy Alta <0%
+: LOC Media <30%; LOC Alta <5%; LOC Muy Alta <0%
++: LOC Media <25%; LOC Alta <0%; LOC Muy Alta <0%

Una vez calculadas las métricas simples, se calculan las métricas complejas que son las que definen la métrica de mantenibilidad de la ISO/IEC 9126, realizando una simple media de las escalas obtenidas en las métricas que definen cada métrica compleja:

Analizabilidad (Analysability) (A): [VOLUMEN], [DUPLICIDADES], [PRUEBAS UNITARIAS], [TAMAÑO UNITARIO].
Modificabilidad (Changeability) (C): [DUPLICIDADES], [COMPLEJIDAD]
Estabilidad (Stability) (S): [PRUEBAS UNITARIAS]
Testeabilidad (Testability) (T): [PRUEBAS UNITARIAS], [COMPLEJIDAD], [TAMAÑO UNITARIO].

De esta manera los valores de A, C, S y T oscilará cada uno entre — (valor más malo) y ++ (valor más bueno).

Estos cuatro valores se representarán en un gráfico donde cada eje representa el valor de estas métricas, teniendo cada eje tres escalas que estarán más separadas de la posición (0,0) que se corresponde con el valor (–) conforme más buena sea la métrica. En sentido horario, los ejes representan respectivamente a T, A, C y S.

Además de esa representación, el color del gráfico también es identificativo de la mantenibilidad de la aplicación, ya que tendrá un color entre el rojo (todas las métricas –) y verde (todas las métrica ++).

ACD es otra métrica que mide el acoplamiento utilizando en este caso un elemento más genérico como es el componente que se puede definir como una unidad de división de una determinada aplicación. En base a esta definición tan generalista se podría considerar componente un paquete, las unidades de compilación (.java) o directamente considerar exclusivamente las clases.

Por regla general la asociación entre componente y unidad de compilación es la más común.

El cálculo de la métrica es sencillo ya que basta con calcular para cada componente el número de componentes de los que depende directa o indirectamente (a través de otros componentes), sumar cada uno de esos cálculos individuales y dividirlos entre el número total de componentes que se han analizado.

De esta manera se calcula la dependencia media de cada componente del programa, de manera que si por ejemplo tenemos un programa con 500 componentes y se obtiene un valor de ACD de 10, estaríamos indicando que cada componente depende de otros 50 componentes, por lo que un cambio en cualquiera de ellos podría provocar un comportamiento anómalo en él. Esto también puede ser visto de manera simétrica (ya que lo que se hace es calcular un valor absoluto de dependencia) de manera que un cambio en el componente podría afectar a otros 50 componentes.

Con el ejemplo expuesto en el anterior párrafo se puede comprender cómo de necesario resulta reducir el número de dependencias para conseguir un software lo más mantenible posible. De hecho esta métrica es considerada por muchos como una métrica indicativa del grado de testeabilidad que debe tener una determinada aplicación, ya que como es lógico a mayor dependencia, más probabilidad de efectos colaterales, mayor necesidad de pruebas.