archivo

Archivo de la etiqueta: Kemerer

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.

NOC es otra de las métricas de Chidamber y Kemerer. Como no podía ser de otra forma, mide la complejidad de una clase desde un punto de vista diferente al del resto de métricas propuestas por estos autores. En este caso su cálculo se basa en contar el número de subclases que directamente heredan de la clase para la cual se calcula esta métrica.

Las subclases están acopladas con la clase de la que heredan, esto quiere decir que cuanto más clases hijas tenga una clase más prudencia hay que tener con cambios relacionados con el comportamiento y especificación de los métodos, ya que podría tener trascendencia sobre sus subclases. Por ese motivo, es necesario ser más exhaustivo en las pruebas de clases con un NOC alto, ya que cualquier problema en las mismas tiene un impacto importante en el programa. Por tanto, se puede deducir de esto que clases con un número de hijos elevado son más complicadas de mantener que otras con un número más bajo.

En el árbol de jerarquía de clases de un determinado programa resulta razonable que las clases situadas en los niveles más alto de la jerarquía tengan un valor de NOC superior a las clases que se encuentren en niveles inferiores, por ese motivo, la existencia de clases con un NOC alto en comparación con otras que se encuentran en niveles superior de la jerarquía, puede ser un indicador de un mal diseño de la clase o una utilización no adecuada de la herencia.

Por otro lado, clases con un NOC alto favorecen su comprensibilidad y la capacidad de implementación de nuevas reutilizaciones, ya que existe un número de clases de ejemplo donde se puede estudiar cómo han aplicado la herencia y como se ha reutilizado la clase.

CBO es otra métrica de las propuestas por Chidamber y Kemerer y se utiliza para medir el acoplamiento entre clases.

Originalmente, el cálculo del CBO para una clase, según las especificaciones de sus autores, se realizaba teniendo en cuenta las dependencias hacia dentro de la clase y las dependencias de la clase respecto a otras. Esto era por la propia definición que se realizó para acoplamiento entre dos clases, ya que se decía que dos clases estaban acopladas cuando una utiliza/accede a métodos y atributos de otra (por tanto se establecía una relación bidireccional). En este cálculo sólo se contaba cada ocurrencia una sóla vez, es decir, si una clase utilizaba dos métodos de otra, sólo contaba una vez. Además tampoco se tenían en cuenta las relaciones de herencia entre clases.

Posteriormente diversos autores reinterpretaron el concepto, lo que ha dado lugar a que en la actualidad en el cálculo del CBO en la mayoría de los casos solo se tengan en cuenta las dependencias hacia fuera de una clase (Fan Out). También existen interpretaciones de esta métrica donde se tienen en cuenta las relaciones de herencia.

La existencia de diferentes interpretaciones de la métrica provoca que en ocasiones la lectura de bibliografía sobre la misma no especifique con claridad si se cuenta solo las dependencias salientes o si hay que contar (como originalmente) las dependencias entrantes y salientes. Por ese motivo, si tomais la decisión de buscar más información sobre la materia tened en cuenta que podéis encontraros con definiciones y métodos de cálculo diferentes en función de la fuente que consultéis.

En cualquier caso e independientemente de la interpretación de la forma de cálculo, tal y como comenté anteriormente y tal y como el mismo nombre de la métrica indica, lo que pretende medir es el acoplamiento o lo que es lo mismo el grado de impredecibilidad del comportamiento y funcionamiento de una clase por la dependencia que tiene de otras y si se toma la definición original de Chidamber y Kemerer además el grado de responsabilidad o influencia de esta clase respecto de otras, es decir, el grado en el que modificaciones de la clase puede afectar al funcionamiento o compartamiento de otras.

Como sucede en el caso de otras métricas que miden acoplamiento, como por ejemplo RFC o DIT, es una medida de la complejidad de una determinada clase y por tanto, valores de CBO altos sugieren que puede ser una clase candidata a ser tratada mediante pruebas unitarias (aunque como bien sabemos las pruebas unitarias no entran en aspectos funcionales) y a estar en cuarentena en las tareas de mantenimiento por posibles efectos colaterales provocados por la modificación de clases con las que tiene dependencia hacia afuera.

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).