archivo

Archivo de la etiqueta: RFC

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.

Que una aplicación tenga una cobertura de pruebas unitarias alta (y se haya verificado el resultado de las mismas) supone una garantía para la reducción del número de errores de la aplicación tanto en la fase de pruebas funcionales como una vez que la misma se encuentre en producción.

La implementación de pruebas unitarias tiene su coste en tiempo, por lo que salvo que la organización para la que se desarrolla tenga unos umbrales de cobertura de código que haya que cumplir de manera obligatoria, es recomendable determinar en qué clases centramos nuestras pruebas unitarias, para que con el menor esfuerzo posible consigamos cubrir aquellas que pueden resultar más conflictivas y de esta forma, tal y como se comentó en el párrafo anterior reducir el número de errores que se propagan a etapas posteriores del desarrollo.

Estrategias para colocar las pruebas unitarias puede hacer muchas. Una de ellas es la que voy a comentar en este artículo y consiste en seleccionar aquellas clases que presentan de manera combinada una mayor complejidad ciclomática (posibles caminos lógicos) y mayor RFC (acoplamiento con métodos de otras clases).

Lo de seleccionar aquellas con mayor complejidad ciclomática puede parecer lógico, pero, ¿por qué combinarlas con las que tienen un mayor RFC? Pues porque el RFC es otra medida de complejidad y mide otro tipo de aspecto complejo, ya que se centra en la relación de la clase con otras y por tanto se puede ver afectada por cambios en cualquiera de los métodos de las clases con las que se relaciona.

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.