archivo

Archivo de la etiqueta: LCOM4

En mi organización vamos a realizar un estudio de una serie de sistemas de información (entre el 50 y el 75% aproximadamente de los mismos) con el objeto de detectar en ellos una serie de clases que pueden resultar conflictivas desde el punto de vista de la mantenibilidad.

Cualquier clase que cumpla alguna de las siguientes condiciones la consideraremos sospechosa (son solo métricas, que pueden encender determinadas alarmas, pero después resulta aconsejable revisar si existe justificación o no en que tomen esos valores) y será objeto de estudio con la finalidad de tomar una decisión sobre la necesidad de su refactorización:

1) Acoplamiento. Utilizaremos como base la métrica RFC de Chidamber y Kemerer.

RFC(clase)>=50 y RFC(clase)/Nº Métodos(clase)>=10

2) Cohesión. Utilizaremos como base la métrica LCOM4 de Chidamber y Kemerer.

LCOM4(clase)>=2

3) Complejidad Ciclomática de Thomas J. McCabe.

Complejidad Ciclomática(clase)/Nº Métodos(clase)>=10

Los valores anteriores por cada clase se obtendrán utilizando las métricas obtenidas a partir de Sonar.

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 implantamos Sonar en nuestra organización con el objetivo de ir controlando la calidad del software que se nos iba entregando, ya que estamos bastante preocupados por la mantenibilidad del software, algo que todavía se acusa más en épocas como la actual donde cada céntimo de euro importa.

Una de las principales curiosidades que tenía era observar a través de las métricas que ofrece Sonar si efectivamente, desde el punto de vista de la complejidad y de la mantenibilidad del software, la realización de sucesivos mantenimientos correctivos y evolutivos empeoraba dichos indicadores, tal y como establece la teoría, así como multitud de estudios empíricos realizados sobre la materia.

Pese a que haría falta más tiempo para poder tener una mayor cantidad de datos y no he entrado en detalle en todas las métricas, se puede empezar a concluir que efectivamente en la mayoría de proyectos donde se han realizado tareas de mantenimiento correctivo y evolutivo se han empeorado indicadores. Hay excepciones, ya que en algunos casos existen métricas que han mejorado y otros en las que prácticamente conservan sus valores.

Las principales métricas que se han visto empeoradas han sido: LCOM4, líneas duplicadas, la complejidad ciclomática y los comentarios de las APIs públicas. Resulta en cierto modo lógico que se incremente la complejidad ciclomática, ya que ésta depende directamente del tamaño del código. Si hubiéramos tenido unos valores de cobertura de código aceptables, podrían haberse extraido conclusiones también sobre esta métrica, algo que no ha sido posible, porque como comenté en otro artículo, la mayoría de las aplicaciones que tenemos no bienen acompañadas de pruebas unitarias y por tanto no es posible bajar del 0%.

Por tanto, la deuda técnica lejos de reducirse, se está incrementando, lo que provoca que el software sea cada vez menos mantenible y en consecuencia cueste más realizar modificaciones en el mismo y exista una mayor probabilidad de que el software se entregue con errores.

Nuestra intención con Sonar, no es ser espectadores de sus métricas, sino con el paso del tiempo exigir que el software que se entregue alcance unos umbrales mínimos en las principales métricas, tanto en desarrollos nuevos como en mantenimientos, ya que si no controlamos no conseguiremos mejorar y reducir nuestros costes de mantenimiento y el número de errores del software que llegan a la fase de pruebas o a producción.

Shyam R. Chidamber y Chris F. Kemerer enunciaron en el año 1994 un total de seis métricas para la medición de la calidad en el desarrollo de aplicaciones orientadas a objetos: WMC (Weighted Methods Per Class), DIT (Depth of Inheritance Tree), NOC (Number of Children), CBO (Coupling Between Object Classes), RFC (Response for Class) y LCOM1 (Lack of Cohesion of Methods).

En este blog, he analizado alguna de sus métricas (o derivadas de las mismas), como por ejemplo LCOM4 y RFC y más adelante seguiré tratando otras de las que fueron enunciadas por ellos.

Esta definición de métricas no cayó en saco roto y ha sido objeto de estudio y discusión desde su especificación, ya que lo primero que se suele plantear cuando se especifican un conjunto de métricas es si realmente sirven para algo y en este caso se trata de comprobar si realmente a partir de ellas se puede saber si un determinado software o componente del mismo puede presentar problemas que influyan en la calidad o no del software (y en su correspondiente deuda técnica).

Un ejemplo de estudio de estas métricas lo tenemos en la NASA que a finales de 2001, publicó un estudio realizado por el Centro Tecnológico de Aseguramiento de la Calidad del Centro de Vuelo Espacial Goddard (principal laboratorio de investigación de la NASA) que tenía como objetivo encontrar la manera o un método de desarrollar software más barato y con una mayor calidad (finalidad esta que es como la piedra filosofal de todos los que nos dedicamos al desarrollo de software).

Para ello en dicho estudio se pretendía seleccionar, del conjunto de métricas que utilizaban para medir la calidad del código, una serie de ellas a las que denominan conjunto ortogonal de métricas orientadas a objetos. Se les llama ortogonales porque cada una de ellas mide características diferentes del código y su diseño y el aspecto u objetivo que quiere medir una, no se ve afectado directamente por variaciones en el valor de la otra (dicho de otra manera, cada métrica tiene una única interpretación que dependerá intrínsecamente de su valor). El objetivo era obtener un conjunto de métricas lo más reducido posible a partir de la cual se pudiera medir la calidad general de un determinado software orientado a objetos. Este conjunto de métricas coincidía con las especificadas por Chidamber y Kemerer.

Calcularon el valor de estas métricas en tres sistemas diferentes desarrollados siguiendo el paradigma de la orientación a objetos, dos en lenguaje Java y el último en C++, para los cuales se disponía de un etiquetado de su calidad, mediante un análisis previo utilizando el conjunto completo de métricas que se estaban utilizando para medir la calidad del software (que es mayor, como es lógico que el conjunto reducido de métricas que se pretenden obtener). Entre las conclusiones que se obtuvieron se encuentra que este conjunto de métricas podía servir para determinar la calidad de un determinado software orientado a objetos.

Esto vino a refrendar estudios realizados anteriormente (por ejemplo, uno realizado por la Universidad de Maryland) en el que se obtuvo como conclusión que este conjunto de métricas resultaba válido.

Sin embargo, el gran problema que encontramos con estas métricas (sucede lo mismo con otras), es la dificultad de poder comparar los valores que se obtienen para cada una de ellas con otros que nos permitan indicar si el nivel de calidad de la aplicación, de una clase o de un método es el adecuado. Esto además se complica porque habría que tener en cuenta también la naturaleza de la aplicación desarrollada y también los umbrales de calidad que una organización estaría dispuesto a admitir. En cualquier caso, en ocasiones el simple valor que se obtiene para una métrica o la comparación de una misma métrica para dos sistemas distintos permite hacernos una idea de su nivel de calidad. Además existen herramientas que para algunas métricas tienen unos valores umbrales por defecto definidos (los cuales además, suelen ser parametrizables).

La métrica RFC (Response for class) forma parte, como sucede con el caso de LCOM4 del conjunto de métricas enunciadas por Chidamber y Kemerer y que tienen como objeto obtener valores de referencia sobre el diseño orientado a objetos de una determinada aplicación.

En el caso de RFC lo que se mide es el acoplamiento entre clases, ya que su valor se obtiene a partir del número total de métodos que pueden potencialmente invocados en respuesta a un mensaje enviado a un objeto de la clase, es decir, el número de métodos que pueden ser ejecutados, cuando un método de la clase es invocado.

Dicho de otra manera, vendría a ser el número de métodos de una clase más el número de métodos de otras clases que son invocados por métodos de la clase (no contando más de una vez cada método, es decir si un método de una clase Y puede ser invocado por tres métodos de una clase X sólo se suma una unidad).

¿Qué es el acoplamiento? Es el grado de dependencia entre clases, por lo que cuando nos encontramos con situaciones donde el acoplamiento es alto crecerán las posibilidades de que el mantenimiento de las clases sea más complejo, ya que un cambio en el comportamiento de un método puede afectar a todos los que lo llaman y un cambio de interfaz del método puede provocar la necesidad de modificar el código de los métodos que lo llaman. También se considera que clases con un acoplamiento alto son más complicadas de entender y dificultan las tareas de testeo.

Un ejemplo de acoplamiento, fuera del mundo de la orientación a objetos, lo tenemos por ejemplo en la dependencia entre una aplicación y una serie de objetos (por ejemplo tablas o vistas) de un esquema de base de datos de otra, en este caso, sobre todo si las aplicaciones son gestionadas por equipos distintos y todavía no están lo suficientemente maduras, se correrá el riesgo permanente de que un cambio en el modelado de datos provoque que la aplicación que hace uso de ellos deje de funcionar adecuadamente. Además se podrá ver afectada por otros factores (cambio de instancia del esquema, cambio de sistema de gestión de base de datos, etc…).

El acoplamiento entre clases es inevitable, ya que los objetos cooperan y precisamente ofrecen servicios a través de sus APIs públicas para poder ser utilizados por otros. No se trata por tanto de eliminar el acoplamiento ya que eso no será posible, sino de intentar conseguir niveles de acoplamiento entre clases bajos, ya que permitirán reducir el número de efectos colaterales en el mantenimiento del sistema, haciendo más sencillas estas tareas y reduciendo las tasas de errores en tiempo de compilación y en tiempo de ejecución (cuando se cambian comportamientos a los métodos). Además de tener en cuenta en el diseño de las clases la existencia de un bajo acoplamiento, se pueden utilizar diferentes estrategias, como por ejemplo la creación de clases donde se centralice ese acoplamiento e incluso se implementen en las mismas fachadas que orquesten llamadas a métodos, de manera que tengamos algunas clases que sí tendrán valores altos o muy altos de RFC, pero que a cambio permitirá que se reduzcan el RFC de un buen número de clases.

A través de Sonar se puede obtener la media de RFC de la aplicación, de cada paquete de la misma y del conjunto de clases que la conforman. Se trata de medias aritméticas puras, sin aplicar ningún tipo de ponderación o umbral de valor de RFC de una clase.

Ahora viene la pregunta de siempre en este tipo de métricas, ¿a partir de qué valor se puede considerar que un RFC es demasiado alto?. Como sucede en el resto de métricas (salvo algunas excepciones como LCOM4) hay interpretaciones para todos los gustos, también como sucede con las otras, queda bastante claro cuando un RFC es muy alto y un RFC es muy bajo, por lo que “desde lejos” se pueden apreciar valores que pueden recomendar el estudio del nivel de acoplamiento de determinadas clases. Se pueden considerar aceptables valores de RFC <= 50.

También es posible obtener valores relacionando el RFC de una clase y su número de métodos (NOM). En programas realizados en Java Se pueden considerar aceptables valores de RFC/NOM <= 10.

LCOM4 es otra métrica que utiliza Sonar y en la cual el concepto también es independiente de la existencia del producto.

Esta métrica mide la falta de cohesión de una determinada clase (forma parte de un conjunto de métricas que cogen su nombre de las iniciales de Lack of Cohesion of Methods). Antes de entrar a analizar cómo funciona esta métrica, es de interés mencionar aunque sea en líneas generales, qué es la cohesión y para qué sirve.

La cohesión mide la especialización (o la proximidad al principio de responsabilidad única) de una determinada clase o lo que es lo mismo cómo de relacionados están los distintos elementos (atributos y métodos) que la componen. Se entiende que clases más especializadas son más mantenibles. Esto es fácil de apreciar cuando por ejemplo miramos el código de una clase cohesionada y el código de una clase Tutti Frutti, en el primer caso veremos que la clase describe un objeto y su comportamiento, considerando dicho objeto como algo “atómico”, en el segundo caso nos podremos encontrar (exagerando mucho) clases que plancharán la ropa, jugarán al fútbol, te hacen un Cola Cao y son capaces de mantener una charla contigo sobre metafísica. Evidentemente, por muy complejo que sea el primer tipo de clases, probablemente el comportamiento, inteligibilidad, mantenibilidad, etc… de la segunda se vea afectado en sentido negativo.

Existen distintos grados de cohesión, según la forma en qué estén relacionados sus elementos. En el párrafo anterior me centré en la de carácter funcional, que es la que me parece más interesante.

¿Cómo funciona LCOM4? Cálcula un valor para una determinada clase, si ese valor es mayor que uno, la clase es sospechosa de falta de cohesión (cuento mayor sea dicho valor, menos cohesión tendrá). Lo que hace Sonar es indicarte el porcentaje de clases respecto al total que tienen un LCOM4 mayor que uno, así como calcularte el LCOM4 medio. Como en el resto de métricas de Sonar, la clave está en definir umbrales, es decir, qué porcentaje de clases con LCOM4 mayor que uno se considera aceptable y cuál es el máximo valor de LCOM4 admisible para las clases. Puede haber casos donde se pueda justificar superar dichos umbrales (suponiendo que dichos umbrales se hayan depurado con la experiencia), en ese caso, el equipo de desarrollo deberá explicar los motivos y ser coherentes si quiere que se le acepte la entrega.

Para el cálculo del LCOM4 de una clase básicamente lo que hace es medir el número de relaciones diferentes que se establecen entre métodos, teniendo en cuenta que un método se considera relacionado con otro si acceden a un atributo común de la clase o si uno llama a otro. Para el cálculo hay métodos que no se tienen en cuenta como por ejemplo los constructores. Tampoco se tienen en cuenta los accesores.

A través de este enlace podréis acceder a un ejemplo bastante bueno para comprender cómo se calcula esta métrica.

Por tanto, la cohesión es un factor a tener en cuenta junto al acoplamiento (entre otros factores) ya que condiciona la mantenibilidad y deuda técnica de los proyectos de desarrollo de software.