archivo

Archivo de la etiqueta: CBO

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