1

Revisión Sistemática de Métricas de Diseño Orientado a Objetos
Trabajo tutelado de Investigación Autor: Juan José Olmedilla Arregui Tutor: Tomás San Feliu Gilabert
Universidad Politécnica de Madrid, Facultad.de Informática Septiembre 2005

Abstract— Since (Chidamber & Kemerer, 1991) multiple Object-Oriented (OO) metrics suites have been proposed, claiming, in many cases, to be focused in design measurement and not so much in measurement of code or other products of the software lifecycle. We are talking, of course, about those metrics not focused on productivity but rather in quality, therefore these metrics try to evaluate, in a quantitative way, if certain properties such as encapsulation, cohesion, abstraction and coupling, supposingly desirable for OO design, are being met. By the other hand, since the forthcoming of concepts such as design patterns (Gamma et al., 1995) and refactorings (Fowler, 2000) new elements have been added to the OO literature to aid with the evaluation of designs. This study performs a systematic review of the literature in order to find out the current state of the art of OO design metrics. The main objective is to know which current OO metrics can be applied exclusively to the design. By the other hand we want to know whether the OO properties mentioned above are still direct measurable attributes, or they are measured indirectly through new directly measurable elements, or on the contrary the OO design quality metrics have completely changed. Resumen—.Desde (Chidamber & Kemerer, 1991) se han propuesto múltiples conjuntos de métricas orientadas a objetos (OO), pretendiendo, en muchos casos, estar centradas en la medición de los diseños y no tanto del código u otros productos del ciclo de vida. Estamos hablando, por supuesto, de aquellas métricas enfocadas no a la productividad sino a la calidad, por tanto, estas métricas tratan de evaluar, de manera cuantitativa, si ciertas propiedades supuestamente deseables del diseño OO se cumplen, tales como encapsulamiento, cohesión, abstracción y acoplamiento. Por otro lado, desde la aparición de conceptos como los patrones de diseño (Gamma et al., 1995) y las refactorizaciones (Fowler, 2000) nuevos elementos para juzgar lo que es un buen o un mal diseño han entrado a formar parte de la literaratura especializada en orientación a objetos. El presente trabajo realiza una revisión de la literatura para evaluar el estado actual de la cuestión entorno a las métricas OO de diseño. El objetivo fundamental es discernir cuáles son las métricas OO que se pueden aplicar exclusivamente al diseño. Por otro lado, se pretende saber si las propiedades OO antes mencionadas siguen siendo el objeto principal y directo de medición, o bien si se miden de manera indirecta a través de nuevos elementos, como los patrones, o si por el contrario ha cambiado radicalmente la forma de medir la calidad de un diseño OO. Palabras clave— Diseño orientado a objetos, métricas de software.

——————————

——————————

1

C

INTRODUCCIÓN
diseño se haya implementado en código. Por una parte, interesa saber si un determinado diseño se ajusta a un determinado nivel de calidad fijado de antemano y por otra parte, interesa poder juzgar si el diseño de un producto software ya existente tiene un nivel de calidad suficiente para ser susceptible de mejoras o bien merece la pena rehacer todo el producto desde sus fases iniciales. En el último caso, quizás el más complejo, se podría incluso llegar a decidir si el coste económico de desarrollar el producto desde cero, partiendo de unos requisitos previos y alguna técnica de estimación de esfuerzo, es superior o inferior al coste de mejorar un diseño existente, siempre suponiendo que el código existente sigue dicho diseño. Para ello sería necesario disponer de métricas tales que permitieran, en primer lugar, establecer niveles cuantitativos de calidad en determinados aspectos o atributos, y en segundo lugar medir la calidad real del diseño así como el coste esperado de las transformaciones del diseño (e implementación) aconseja-

ASI desde los albores de la Informática se han tratado de medir de una manera u otra distintos atributos del software. Estos atributos pueden ser, el tamaño, la complejidad, la frecuencia esperada de aparición de errores, cobertura de pruebas, o incluso atributos del proceso software como pueden ser la productividad. Dichos atributos se pueden medir directa o indirectamente, esto es, a través de la medición previa de otros atributos con los que se sabe que aquellos tienen una relación matemática (N. Fenton et al., 1994). Los objetivos perseguidos por dichas mediciones pueden ser la búsqueda de un método de estimación de esfuerzo de desarrollo, el cálculo de la cobertura de pruebas en el aseguramiento de la calidad o como en el caso que nos ocupa, la calidad en el diseño software Orientado a Objetos (OO). Estamos interesados en el uso de métricas que ayuden a la detección de errores y a la mejora de la calidad en el diseño OO en fases tempranas, antes incluso de que dicho

2

bles para alcanzar dichos niveles. Esto implicaría, naturalmente, no solamente un conjunto de métricas sino toda una metodología de mejora de diseño OO basado en transformaciones, ya sean éstas, refactorizaciones, aplicación de reglas, heurísticas, patrones, etc. El presente trabajo es un primer paso en la dirección antes mencionada ya que nos quedaremos simplemente en la búsqueda de métricas OO aplicables al diseño. Para ello se realizará una revision sistemática de la literature en cuanto a métricas OO buscando aquellas que se refieran al diseño. En primer lugar, en el apartado 2 se describen los antecedentes en el cual se incluye una somera descripción de lo que se entiende por atributos de calidad software y qué se entiende por elementos de diseño, que son al fin y al cabo lo que pretendemos medir, así como la evolución de las métricas OO en general. En el siguiente apartado, el 3, se describe la metodología utilizada y los resultados de la revisión y, finalmente, se cierra el estudio con unas conclusiones, en el apartado 4.

2
2.1

ANTECEDENTES
Atributos de calidad y entidades de diseño Fig. 1: Atributos de calidad ISO 9126
nivel específico de rendimiento bajo determinadas condiciones de uso. • Usabilidad: la capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando se usa bajo ciertas condiciones. • Eficiencia: la capacidad del software de ofrecer el rendimiento apropiado con respecto a la cantidad de recursos utilizados, bajo condiciones prefijadas. • Mantenibilidad: la capacidad del producto de ser modificado. Dichas modificaciones pueden incluir correcciones, mejoras o adaptaciones a cambios en el entorno y en los requisitos y especificaciones funcionales. • Portabilidad: la capacidad del software de ser trasladado de un entorno (informático) a otro. Estas características son generales para cualquier tipo de programa informático o software independientemente de si el paradigma empleado para construirlo es el Orientado a Objetos, el estructurado u otro cualquiera, sin embargo si que afectará a la manera de medirlas. Dichas características se dividen a su vez en subcaracterísticas tal como se puede ver en la Fig. 1. La norma ISO 9126 trata de establecer una definición general de lo que es la calidad de producto software en general, tanto desde el punto de vista del usuario final como del que lo construye, de ahí que exista la visión externa como la interna. Sin embargo se puede decir que existen subproductos intermedios en los que podemos hacer mediciones de calidad previas a las que se puedan hacer al disponer el producto acabado y que, sin embargo nos pueden dar una previsión de la calidad de este último. Es lógico pensar que no todas las características antes mencionadas son mensurables o tiene sentido en determinados productos intermedios, como el diseño micro-arquitectónico, como es el caso que nos ocupa. De este modo debremos distinguir qué características son planteables y cuáles no en la fase de

En primer lugar debemos acotar el contexto en el que nos movemos, ya que la calidad, en el software, se puede entender como calidad de proceso o de producto. La calidad de proceso ha sido objeto de mucho interés en las últimas décadas (Humphrey, 1989) y su desarrollo ha concienciado a los profesionales de la necesidad de aplicar la calidad a otros aspectos del software. En nuestro caso estamos claramente centrados en la calidad del producto software y, dentro de ella, en el producto derivado de la fase de diseño (Software design, part 2, 2004). Fenton y Pfleeger (1998) explican que es un paso previo al establecimiento de las métricas el definir qué atributos o propiedades de qué elementos son los que queremos medir. Posteriormente podremos establecer si para medir dichos atributos es necesario medir otros y derivar los que nos interesan de ellos o bien se puede hacer directamente. En nuestro caso la única norma que hemos encontrado en la literatura que da una definición de calidad de producto software en base a atributos es ISO 9126 (ISO/IEC, 2001). Dicha norma establece que la medición de la calidad de un producto software debe hacerse en base a sus atributos, siendo éstos internos, propiedades características de cómo se estructura el software, o externos, cualidades observables aún sin conocer cómo está construido. De hecho no se habla de calidad, en general, sino de calidad interna y calidad externa, afirmándose que la calidad interna de un producto software influye directamente en su calidad externa. De algún modo se está diciendo que mejorando la calidad interna se mejora directamente la calidad observada en atributos de uso del producto software. Tanto la calidad interna como la externa se definen, en ISO 9126, como un conjunto de 6 características: • Funcionalidad: la capacidad del software de proveer las funciones que cumplen con las necesidades implícitas y explícitas cuando el mismo es utilizado bajo ciertas condiciones. • Fiabilidad: la capacidad del software de mantener un

JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS

3

Fig. 2: Calidad de producto en el ciclo de vida software

diseño: • Por lo que respecta a la característica de funcionalidad hemos de decir que su medición pretende dilucidar si se ha hecho una cobertura correcta y completa de los requisitos de usuario, por tanto, se trata de algo que debiera hacerse durante la fase de análisis y medirse durante etapas posteriores al diseño, cuando ya se tiene el código mediante pruebas de cobertura. Lo que se ha venido llamando Aseguramiento de la Calidad cubre, entre otras cosas, la verificación de dichos requisitos de usuario. Por tanto la calidad de un diseño no debería medirse por la funcionalidad, tal como se define en ISO 9126. Las técnicas de mejora de diseño indican que, para ser aplicadas, el comportamiento del diseño original debe ser fundamentalmente correcto (Fowler, 2000) (en términos de funcionalidad y de fiabilidad). Por tanto, si dos diseños responden a los mismos requisitos y uno de ellos no se ajusta totalmente a ellos o de manera correcta, no es que sea “peor” que el otro, es que simplemente es incorrecto o incompleto. • De la misma manera no deberíamos considerar la fiabilidad como uno de los atributos internos que definen la calidad del diseño, basándonos en el hecho de que esta característica se mide durante la etapa de pruebas. Sin embargo McCabe (1976) introdujo la métrica de Complejidad Ciclomática (CC) para predecir el número mínimo de pruebas que son necesarias para asegurar un determinado nivel de cobertura y por ende el número de defectos latentes. Trabajos posteriores (Chidamber & Kemerer, 1994) establecieron métricas equivalentes para el software OO y existen estudios (Basili et al., 1996; Briand et al., 2000; Brito e Abreu & Melo, 1996) que tratan de predecir la fiabilidad durante la etapa de diseño. Éstos y otros trabajos 1 establecen una relación entre la complejidad, como una propiedad OO, y la densidad de defectos o pro1 En (Subramanyam & Krishnan, 2003) se puede ver una lista de estos trabajos.

pensión a fallos, que interpretamos como antónimos de fiabilidad. • La usabilidad está directamente relacionada con la forma en que el usuario percibe el producto terminado. No se han encontrado evidencias que permitan establecer esta característica como un atributo interno de calidad del diseño. La comprensibilidad (ing. “Understandability”) se menciona en la literatura (Bansiya & Davis, 2002; Deligiannis et al., 2003; Dumke & Kuhrau, 1994) como una propiedad deseable en el diseño, sin embargo es más que discutible que su interpretación como la sub-característica usabilidad de ISO 9126, más bien deberíamos tomarla como “analizabilidad” (ing “analasybility”). Sin embargo, Fowler (2000) argumenta que el usuario del diseño no es mismo que el usuario del producto final, que podría tratarse del desarrollador que ha de implementarlo, o bien podría ser el mismo diseñador (u otro) en el futuro cuando se requiera introducir una nueva característica al producto o se deba modificar el diseño por cualquier razón, este último caso ya está comprendido bajo el atributo “mantenibilidad”, pero el anterior no y queda en terreno ambiguo. • La eficiencia, según la ISO 9126, se divide en e las sub-características “comportamiento temporal” y “utilización de recursos”, lo cual ha hecho de esta característica un claro objetivo de medición en las fases de pruebas, sin embargo existe una tendencia actualmente, sobre todo en el sector de las aplicaciones de tiempo real, a medir en fases tempranas de diseño la eficiencia en términos de rendimiento. Este atributo sería un buen objetivo a satisfacer en niveles de calidad altos aunque probablemente no en los más básicos. Mejorar la comprensibilidad de un diseño OO mediante la aplicación, por ejemplo, de patrones de diseño, introduce indirecciones que suelen penalizar el rendimiento, así que ambos atributos de calidad parecen ser incompatibles, sin embargo si un diseño es más comprensible gracias a su descomposición en

4

entidades permite un mejor aislamiento e identificación de aquellos “puntos calientes” donde tienden a acumularse los problemas de rendimiento (Fowler, 2000). • La mantenibilidad es objetivo indiscutible de la mayoría del conocimiento OO sobre mejora del diseño, esto se deduce del hecho, entre otros, de que la mayor parte del esfuerzo de diseño en el paradigma OO se centra alrededor de conceptos como ocultación, encapsulación y abstracción de datos lo cual mejora la comprensibilidad (analizabilidad) mediante la representación de conceptos del dominio, separación de componentes en unidades verificables (“testeables”), etc. • La portabilidad parece a todas luces completamente fuera del alcance de la etapa de diseño, como atributo mensurable de calidad, dado que el diseño debe mantenerse conceptualmente separado del entorno de implementación final; aún no siendo ésto más que una generalización muy discutible tampoco hemos encontrado suficiente evidencia como para apoyar que este atributo o característica es importante, desde el punto de vista de la calidad, durante etapas tempranas de diseño. Aún en el caso de que se considere que un diseño ha de tener en cuenta el entorno final de ejecución todo lo más se puede considerar como un requisito más y por tanto se cumplirá o no, pero no se cumple “mejor o peor”. Bansiya y Davis (2002) utilizan un conjunto de seis características o atributos mensurables de calidad de diseño, cuatro de ellos tomados directamente de ISO 9126, otros dos adaptados con otro nombre y otros dos no se encuentran en dicha norma y los toman de conceptos generales de diseño software presentes en la literatura. Hasta ahora hemos hablado de atributos de calidad generales para el diseño software pero no hemos particularizado para el diseño OO ni tampoco hemos hablado de cómo observar o medir los niveles en que se satisfacen dichos atributos, éstos son conceptos abstractos no observables directamente en el diseño, al menos no de una manera cuantificable. Como observan Fenton y Pfleeger (1994) debemos encontrar propiedades del objeto de estudio, el diseño en este caso, directamente observables y mensurables y que tengan una relación conocida con los atributos que pre-

tendemos convertir en nuestras métricas. En muchos de los conjuntos de métricas OO publicados se utilizan propiedades como cohesión, acoplamiento, encapsulamiento, complejidad y herencia que, sin ser todas específicas del diseño OO, son lo suficientemente concretas y además se pueden relacionar matemáticamente con los atributos generales de diseño. Se han propuesto distintas medidas para dichas propiedades e incluso las relaciones con los atributos generales de calidad de diseño, como en el caso de (Bansiya & Davis, 2002) donde a cada atributo de diseño le corresponde una de estas métricas. En (Miller et al., 1999) se eligieron 11 propiedades, de hecho se trata de principios de diseño OO en el sentido de elemento de conocimiento OO de (Garzás & Piattini, 2005); y se utilizaron 5 medidas aplicadas a clases para medir el grado de satisfacción de dichas propiedades. En (Bansiya & Davis, 2002), sin embargo, las medidas se hacen tanto sobre atributos de clase, como métodos y paquetes. Para que se entienda de qué tipo de propiedades OO estamos hablando exponemos una lista no exhaustiva pero lo suficientemente ilustrativa: 1) Tamaño del diseño 2) Jerarquías (de clases) 3) Abstracción 4) Encapsulamiento 5) Acoplamiento 6) Cohesión 7) Composición 8) Herencia 9) Polimorfismo 10) Comunicación inter clases (ing. “Messaging”) 11) Complejidad Como ya se ha sugerido, estas propiedades se miden en components o entidades del diseño (veáse Fig. 1) que habrá que definir. Purao y Vaishnavi (2003) revisan las métricas de producto de sistemas OO y proponen un modelo de trabajo y un formalismo , de acuerdo al cual, el producto pasa por distintos “estados” durante el proceso de desarrollo y en cada uno de ellos se producen o modifican distintos componentes que llaman “entidades”. Estos autores revisaron las familias de métricas presentes en la literatura con el fin de recopilar el conjunto de entidades mensurables en cada uno de esos estados; ofrecemos en la TABLA I aquellas entidades recopiladas para el “estado” de diseño.

JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS

5

Entidad Asociación Atributo Clase

Atributo Tamaño Posición Abstracción Comportamiento Comentarios Esfuerzo Interacción Interfaz Rendimiento Posición Reutilización Tamaño Estructura

2.2

Métricas de Orientación a Objetos

Jerarquía Enlace Método

Estructura Cardinalidad Abstracción Esfuerzo Interacción Interfaz Rendimiento Posición Reutilización Tamaño Estructura

Hasta ahora hemos hablado de nuestro objetivo, revisar métricas OO propias del diseño, hemos situado parte del dominio del problema explicando qué se entiende en este contexto por calidad y dónde se debería medir. Antes de entrar en el método de trabajo y los hallazgos debemos ofrecer una visión retrospectiva e histórica de lo que son las métricas OO en general. Para obtener una lista más exhaustivas de métricas se pueden consultar (Briand et al., 2000; Purao & Vaishnavi, 2003). Podemos adelantar que en su mayoría las métricas OO de diseño no son tales, aunque digan serlo, ya que necesitan el código fuente resultante del diseño para poderse aplicar. Otra conclusión importante que se saca de este rápido análisis es que estas “suites” se centran en conjuntos bastante restringidos de propiedades OO, fundamentalmente, acoplamiento, cohesión, y herencia. Las primeras métricas OO, como se puede ver, tampoco estaban orientadas a objetivos específicos de calidad.

2.2.1

La familia de métricas de Chidamber y Kemerer

Paquete

Abstracción Interacción Tamaño Estructura

Parametro Escenario Sistema

Tamaño Tamaño Comportamiento Cambio Comentarios Dinámica Esfuerzo Interfaz Rendimiento Requisitos Reutilización Tamaño Estructura

Caso de uso

Interfaz Tamaño Estructura

TABLA I: Entidades de diseño mensurables y sus atributos

6

Métrica Weighted methods per class (WMC)

Definición Considérese una clase

Propiedades

C1 con los métodos M 1 , M 2 ,..., M n . Sea

Complejidad

c1 , c 2 ,..., c n la complejidad estática de los métodos. Entonces:
WMC = ∑i =1 ci
n

La complejidad estática se puede medir de muHerencia

Depth of Inheritance tree (DIT) Number of children (NOC) Coupling between object classes (CBO) Response for a class (RFC)

chas maneras, siendo una de ellas CC(McCabe, 1976). La métrica DIT de una clase A es su profundidad en el árbol de herencia. Si A se encuentra en situación de herencia multiple la longitude maxima hasta la raíz sera el DIT. NOC de una clase es el número de subclases inmediatamente subordinadas a una clase en la jerarquía. CBO de una clase es el número de clases con las que está acoplada. Una clase está acoplada a otra si utiliza sus métoods o variables de instancia, excluyendo acoplamiento por herencia.

Herencia Acoplamiento

RFC = RS
que

donde RS es el conjunto respuesta de la clase, dado

Comunicación

RS = {M } Uall i {Ri } donde {Ri } = conjunto de los méto-

dos invocados por el método

i y {M } es el conjunto de todos los

Lack of cohesion in methods (LCOM)

métodos de la clase. El conjunto respuesta de una clase es el conjunto de métodos que se pueden ejecutar como respuesta a un mensaje recibido por un objeto de la clase. Considérese una clase C i con n métodos M 1 , M 2 ,..., M n . Sea I j el conjunto de variables de instancia usados por el método M i . n de esos conjuntos I 1 ,..., I n . Existen Sea P = I i , I j I i I I j = Ø y Q = I i , I j I i I I j ≠ Ø . Si todos los n conjuntos I 1 ,..., I n son Ø entonces sea P = Ø . LCOM = P − Q , si P > Q ó 0 en otro caso.

{ }

Cohesión

{(

)

{ } { }

}

{(

)

{ } { }

}

S.R. Chidamber y C.F. Kemerer (C&K) fueron los primeros (1991) en establecer un conjunto de 6 métricas de productos específica para código OO; todas menos uno se aplicaban a las clases y trataban de medir la complejidad, acoplamiento, cohesión, herencia y comunicación inter-clases. Podemos ver en la TABLA II la definición de dichas métricas y la propiedad OO con la que se relacionan. Obviamente hay una relación directa entre cada una de las métricas y la propiedad OO correspondiente, aunque en el caso de la herencia existan dos métricas asociadas a ella. Por otro lado no se establece ningún método de evaluación de calidad de producto ni se relacionan explícitamente los atributos de calidad con las propiedades OO, de manera intuitivas, eso sí, se sabe que el control de dichas propiedades ayuda, de manera general, a mejorar el diseño o el producto final o que un buen sistema OO debe maximizar el uso de las
Métrica Message passing coupling (MPC) Data abstraction coupling (DAC) SIZE1 SIZE2 Definición

TABLA II: Métricas de C&K

mismas. Se trata por un lado de un intento de adaptar las métricas ya en uso en el mundo estructurado (Halstead, 1977; McCabe, 1976), cuyo uso está más bien orientado a la productividad y el cálculo de coberturas de pruebas que a la calidad, y por otro lado de incorporar los, por aquel entonces, incipientes principios básicos del diseño orientado a objetos (Meyer, 1988).

2.2.2

Métricas de Li y Henry

A partir de las métricas de C&K se van proponiendo modificaciones y ampliaciones sobre ellas, éste es el caso de Li y Henry (1993) que proponen varias modificaciones y añaden cuatro nuevas métricas. La modificación más resaltable es la que se hace sobre la LCOM, que otros autores volverán a discutir (Henderson-Sellers et al., 1996), ya que se considera que la definición original es ambigua y permite que dos
Propiedades Acoplamiento/Comuni cación Acoplamiento/Abstracc ión Tamaño del diseño Tamaño del diseño

MPC= número de métodos invocados en un clase. El número de atributos en una clase que tienen como tipo otra clase. Es una variación de la tradicional LOC (Lineas de Código) definida específicamente para el lenguaje Ada. Obviamos la definición SIZE2 = número de atributos + número de métodos locales.

TABLA III: Métricas de Li y Henry

JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS

7

Métrica Design size of classes (DSC) Number of Hierarchies (NOH) Average number of ancestors (ANA) Data access Metric (DAM) Direct class coupling (DCC)

Definición Número total de clases en el diseño Número de jerarquías de clases Número medio de ancestros Relación entre el número de atributos privados (protegidos) y el número total de atributos de la clase. Número de clases diferents con las que una clase está relacionada. Esta métrica incluye clases que están relacionadas directamente mediante la declaración de atributos y el paso de parámetros de los métodos. Esta métrica calcula la relación entre métodos de una clase basándose en la lista de parámetros de los métodos. Se calcula utilizando la suma de la intersección de parámetros de un método con el conjunto máximo independiente de todos los tipos de parámetros de la clase. Mide la extension de la relación parte/todo, mediante el uso de atributos. Es el número de declaraciones de variables cuyo tipo es definido por el usuario. Relación del número de métodos heredados por una clase y el número total de métodos accesibles por un método miembro. Número de métodos que pueden mostrar comportamiento polimórfico (virtual en C++ y no final en Java) Número de métodos públicos en una clase Número de métodos definidos en una clase

Propiedades Tamaño del diseño Jerarquías Abstracción Encapsulamiento Acoplamiento

Cohesion among methods of class (CAM)

Cohesión

Measure of aggregation (MOA)

Composición

Measure of functional abstraction (MFA) Number of polymorphic methods (NPM) Class interface size (CIS) Number of methods (NOM)

Herencia Polimorfismo Comunicación Complejidad

clases con distintos grados de cohesión real obtengan idénticos valores de LCOM. Por otra parte esta nueva suite de métricas tiene un objetivo claro, que es la medición y mejora de la mantenibilidad del software OO, y para ello se añaden la abstracción y el tamaño de diseño (aunque una de las dos métricas propuestas para él se basa en las líneas de código). Se da pues un cierto avance conceptual al incluir de manera explícita un atributo de calidad de software como objetivo de las métricas. En la TABLA III se pueden ver la modificación de LCOM y las cuatro nuevas métricas propuestas por Li y Henry.

TABLA IV: Métricas de Bansiya y Davis

2.2.3

Métricas de Henderson-Sellers

Henderson-Sellers, Constantine y Graham (1996) ofrecieron su propia familia de métricas donde la mayoría estaban relacionadas con el acoplamiento y la cohesión, solamente la “profundidad media de herencia de una clase” o AID (ing. Average Inheritance Depth) se relacionaba con la herencia. Esta medida tomaba el valor 0 si la clase no tenía antecesores y la media de los valores de AID de sus antecesores más uno en otro caso.

3
3.1

METODOLOGÍA Y RESULTADOS
Procedimiento de revision sistemática

Para nuestro studio hemos seguido el procedimiento de revisión sistemática de la literatura especializada de Kitchenham (2004). En dicho procedimiento se establecen una serie de pasos a seguir que son: • Establecimiento del objetivo de revisión mediante “preguntas de la investigación” (ing. research questions). • Establecimiento de un protocolo de revisión donde se establezcan las fuentes a utilizar, los patrones de bús-

queda, criterios de inclusión y exclusión, la forma de recogida de dato y los criterios de extracción (validación y criterios de calidad de los datos). Este protocolo se debe refinar tras las primeras búsquedas ya que normalmente los propios datos obtenidos van dando indicaciones sobre ajustes que deben realizarse, sobre todo en la forma de recogida de datos o los criterios de exclusión. • Se ejecutan propiamente las búsquedas y se recogen los datos. • En la etapa de extracción de datos se validan los datos y se clasifican según su “calidad” con lo que finalmente se obtienen resultados y conclusiones. • Finalmente se recogen los resultados en formatos de tablas u otros y se elabora un informe documental que es el objetivo final de la revisión. Kitchenham propone un formato de documento de revisión que, fundamentalmente, es el que se ha seguido en este trabajo. En dicho documento es importante documentar los antecedentes y objetivos, el protocolo seguido a alto nivel, incluyendo las cuestiones de investigación y los criterios de exclusión, así como los resultados finales en forma resumida, preferentemente de la manera más visual posible, tablas o gráficos. En las siguientes secciones recogemos el protocolo seguido, aunque no con todo el detalle de todas las consultas realizadas en las distintas fuentes, pues sería tedioso. Se eligió recoger los datos de las búsquedas en una base de datos diseñada “ad hoc” con campo específicos donde tras la lectura inicial de los resumenes (ing abstracts) o de los trabajos completos (si nos e descataban directamente por los resumenes) se recogían distintos elementos como eran los criterios de calidad, que más adelante veremos. Los trabajos que pasaron los criterios básicos de selección fueron recogidos en formato electrónico (PDF). Se utilizó la herramienta Access para la base de datos

8

“ad hoc” y BibTeX y EndNote para la gestión bibliográfica.

3.2

Preguntas de la revision sistemática

El objetivo primordial de esta revisión sistemática es dilucidar qué métricas OO existen actualemente para medir la calidad de un diseño previamente a su implementación, o más bien, sin que se tengan que aplicar a él. Nos interesan aquellas métricas que nos puedan servir para medir la calidad de los diseños independientemente de que hayan sido implementados o no, pero siempre con la idea de hacer una valoración exclusivamente en base al diseño. Nos interesa que la medición nos arroje resultados significativos en función de determinados atributos de calidad, en concreto, los que establece la norma ISO 9126 o similares (extrapolables a dicha norma). El objetivo futuro, a desarrollar en posteriores trabajos, es el desarrollo de algún tipo de metodología o incluso herramienta que permita mejorar sistemáticamente los diseños hasta alcanzar un nivel preestablecido en función de valores asignados a los atributos de calidad. Por tanto nos interesa saber también qué atributos o indicadores de calidad son los más utilizados en dichas métricas. Para acotar claramente nuestro campo de acción utilizaremos el término “diseño de micro-arquitectura” tal como se entiende en el SWEBOK (Abran et al., 2004), que no lo define explícitamente, pero sí diferencia entre patrones de diseño micro y macro arquitectónicos. Por tanto nos referiremos a los objetos y las clases, su estructura y relación entre ellos pero no aspectos internos de sus métodos, más relacionados con la implementación. Formulamos, pues, la cuestión inicial de investigación de la siguiente manera: Pregunta 1: ¿Existen métricas Orientadas a Objetos, basadas únicamente en entidades de diseño, para la evaluación de calidad mediante atributos internos de producto (tipo ISO 9126)? Por supuesto dichas métricas deben relacionarse cuantitativamente con los atributos de calidad, bien directamente o bien mediante elementos intermedios como, por ejemplo, las propiedades OO. La otra cuestión que nos importa puede formularse como: Pregunta 2: ¿Se miden las propiedades OO tradicionales (antes mencionadas) o bien se utiliza nuevos elementos de conocimiento tales como los clasificados en (Garzás & Piattini, 2005)? Es importante, para posteriores trabajos, saber si elementos tales como los patrones han sido aplicados a un diseño y cómo ésto ha impactado en el nivel medido de calidad. Si las métricas fueran capaces de medir sobre la presencia de dichos elementos podríamos, en un futuro, llegar a crear una especie de “guía de aplicación de transformaciones de diseño” para la mejora del mismo.

3.3

Método

Todas las fuentes elegidas fueron digitales y se pretendía

cubrir el máximo posible de publicaciones periódicas y actas de congresos relacionados con métricas, calidad de software, conocimiento OO y mantenimiento de software. Por tanto se eligieron dos portales agregadores de literatura especializada y tres revistas específicas no incluidas en ellas: • IEEE Digital Library • ACM Digital Library • Journal of Systems and Software, ed. Elsevier. • Journal of Software Maintenance and Evolution, ed. Wiley. • Software Practice and Experience, ed. Wiley. Nuestra estrategia de búsqueda consistió en elaborar distintas consultas mediante expresiones booleanas formadas por los siguientes términos (en inglés): • Object Oriented design • Metrics • Quality • High level indicators • Assessment • Method • Patterns • Heuristics • Bad smells • Principles • Rules • Refactorings • Lessons learned • Best practices Algunos de los términos fueron desglosados en expresiones booleanas de tipo “o” formadas por todos sus sinónimos, como por ejemplo “assess”, “assessing”, “evaluation” y “evaluate”. Mediante la correcta manipulación de las leyes del algebra de Boole se consiguió una única expresión booleana con todos los términos y sus sinónimos, sin embargo, debido a la particularidades sintácticas de cada buscador se tuvieron que hacer versiones para cada uno de ellos y, en algún caso, se tuvieron, incluso, que eliminar términos para ampliar la búsqueda y después eliminar manualmente estudios que no estaban relacionados con nuestro objetivo; esto fue así ya que en esos casos específicos la búsqueda inicial daba resultados muy escasos. Siguiendo el procedimiento especificado por Kitchenham se eliminaron repeticiones de estudios tanto de publicaciones en distintas búsquedas como de publicaciones distintas pero que se referían al mismo trabajo de campo, siempre quedándonos con la más reciente. Tras los descartes por repetición quedaron 481 trabajossobre los cuales se realizó una primera revisión rápida sobre los resumenes y se descartaron todos aquellos que no se referían a métricas OO (en general). En una segunda revisión se descartaron los trabajos de acuerdo a los criterios de exclusión. Tanto en la primera como la segunda revisión se registraron en la base de datos las razones del descarte.

JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS

9

Level 1 2 3

Name Ensayo aleatorio Ensayo pseudo-aleatoriol Estudio concurrente de cohorte (grupo de voluntarios) Control histórico

Description Evidencia obtenida de al menos un ensayo aleatorio controlado bien diseñado. Evidencia obtenida de al menos un ensayo pseudos-aleatorio controlado bien diseñado. Evidencia obtenida de estudios comparativos con control concurrente y asignación no aleatoria, estudios de cohorte, estudio controlado de un caso o series interrumpidas en el tiempo con un grupo de control. Evidencia obtenida de estudios comparativos con control histórico, dos o más estudios de una sola rama, o series interrumpidas en el tiempo sin un grupo de control paralelo. Evidencia obtenida de un experimento aleatorio ejecutado en un entorno artificial. Evidencia obtenida de una serie de casos, bien post-tes o pre-test. Evidencia obtenida de un experimento pseudos-aleatorio ejecutado en un entorno artificial. Evidencia obtenida de la opinion experta basada en la teoría o el consenso.

4

5 6 7 8

Experimento aleatorio Serie de casos Experimento pseudo-aleatorio Opinión de experto

TABLA V: Niveles de calidad para las fuentes primarias
Número de Estudios Total 481 Aceptados 23 Descartados 458 Modelos completos 4 Aceptados Diseño exclusivamente 9 Intersección 2

TABLA VI: Resumen de los datos recogidos
Los trabajos no descartados, o “fuentes primarias”, fueron registradas en la base de datos con un pequeño resumen y su nivel de calidad de acuerdo a los niveles que establecimos (véase TABLA V) según el grado de experimentalidad. Dado que todos los trabajos estaban por debajo del nivel 3, decidimos no utilizar la calidad experimental como otro criterio de exclusión y todos los trabajos que habían llegado hasta este punto fueron tenidos en cuenta. tudio en cuestión realmente se refiera a un método de evaluación o unas métricas aplicables a las entidades de diseño. Esto significa que el estudio habla de aplicar el método a documentos de diseño o diagramas UML (cualquiera de ellos) o bien se está aplicando al código pero se podría hacer una extrapolación al diseño; esto último quiere decir que las métricas aplicadas podrían, de alguna manera, calcularse sólo con entidades de diseño, como por ejemplo las distintas métricas de jerarquías o profundidad de herencia. En algún caso se ha marcado este valor com falso porque, si bien casi todas las métricas podrían hacerse sobre diseño, el estudio lo hacía sobre código y además se incluía una métrica imposible de aplicar a entidades de diseño como SIZE1 o LCOM. En la TABLA VI se puede observar el resumen del número de fuentes primarias, modelos completos, fuentes primarias cuyo método o métricas pueden aplicarse al diseño exclusivamente y el número de fuentes primarias que son completas y de diseño exclusivamente. En la TABLA VI podemos observar los atributos de calidad que aparecen en los estudios primarios, con las denominaciones con que aparecen originalmente, en algún caso hemos simplificado y lo hemos asimilado al nombre que aparece en otros estudios y cuya semántica es la mimsa, sin embargo hemos mantenido todos los nombres originales aunque ello implica la aparición de sinónimos como analizabilidad, inteligibilidad2 y comprensibilidad. Ha de tenerse en cuenta que en todo momento nos referimos a atribu2 Hemos traducido “comprehensibility” por inteligibilidad y “understandability” por comprensibilidad cuando debiera ser al revés, sin embargo ha sido necesario para mantener la coherencia con la traducción más extendida de “understandiblity” en la literatura de Ingeniería del Software española

3.4

Criterios de exclusión

El criterios de exclusión elegidos fueron: Criterio de Exclusión 1: El estudio no está centrado en métricas para la mejora del diseño, por ser demasiado generales incluyendo, por ejemplo, mediciones de productividad o de aseguramiento de calidad. Criterio de Exclusión 2: El estudio no propone un modelo de evaluación con atributos de calidad como objetivo de las métricas.

3.5

Recogida y extracción de datos

Un objetivo indirecto del estudio es la recogida de los atributos de calidad usados como indicadores de calidad de diseño, así que se recogieron dichos atributos para todos los estudios que pasaron los criterios de exclusión. Por cada uno de los estudios se estableció un indicador booleano (Si/No) para registrar si el trabajo en cuestión proponía un modelo de evaluación completo y cuantificado desde las métricas propuestas hasta los atributos de calidad, pasando (en su caso) a través de las propiedades OO elegidas. Aunque todas las fuentes primarias proponían de alguna manera métodos de evaluación de calidad de diseño OO, solamente 4 de ellos realmente proponían un modelo completo cuantificado, los hemos denominado “modelos completos”. Por otra parte también registramos el hecho de que el es-

10

Indicador3 Adaptability Analysability Change proneness Changeability Completeness Complexity Comprehensibility Consistency Correctness Effectiveness Efficiency Extensibility Flexibility Functionality Maintainability Performance Realizability Reliability Reusability Security Stability Testability Traceability Unambiguity Understandability Usability Verifiability

Modelo Completo 0 1 0 1 0 0 1 0 0 1 0 1 1 1 1 1 0 0 2 0 1 1 0 0 1 0 0

Estudios aplicados a diseño sólo 0 0 0 1 2 0 1 2 2 1 0 1 1 1 4 1 1 0 2 0 0 3 1 1 2 0 0

Fuentes primarias 1 1 0 2 2 3 1 2 2 1 0 4 1 1 10 2 1 4 5 1 1 5 1 1 4 1 0

tos de calidad aplicados al diseño, por tanto la comprensibilidad debe ser entendida como la capacidad que tiene un diseño de ser entendido por un desarrollador distinto a su autor y no como la sub-caracerística de usabilidad de la ISO 9126.

TABLA VII: Indicadores de calidad de alto nivel recogidos

3.6

Resultados

A la vista de los resultados podemos afirmar que menos de la mitad de los estudios que tratan de establecer alguna manera de evaluar la calidad de un diseño OO se basan en analizar únicamente entidades de diseño. De las 23 fuentes primarias 14 se basan en el análisis del código fuente. Por otra parte, podemos observar que, viendo la TABLA VII, para los llamados “modelos completos”, la mantenibilidad, contando sus sub-características es el indicador más recurrente con un total de 8 apariciones. La mantenibilidad se compone de analizabilidad, cambiabilidad, estabilidad y testabilidad, y como ya hemos dicho, analizabilidad, inteligibilidad y comprensibilidad son sinónimos, y lo mismo puede decirse de la cambiabilidad, flexibilidad y extensibilidad. Otro fasctor importante observado es la reusabilidad. Aparentemente cuando se trata de establecer un método de evaluación de la calidad, la fiabilidad, la tendencia a los defectos y la validez funcional y consistencia son bastante
3 Incluimos aquí los nombres en inglés tal como aparecen en los estudiospara evitar confusiones en la traducción.

menos importantes que la mantenibilidad. Por otra, se ha observado que muchos estudios tratan de predecir y dismunir los defectos tan pronto como sea posible en el ciclo de vida, es decir, en la etapa de diseño. Una posible interpretación es que los métodos de evaluación de la calidad no se interpretan como sustitución del Aseguramiento de la Calidad y tratan de establecer un medio de medida y comparación de diseños distintos semánticament equivalentes, o sea, construidos en base a los mismos requisitos y válidos funcionalmente. Dado el escaso número de estudios relevantes no se ha considerado necesario realizar un análisis estadístico de los datos obtenidos. Solamente 2 estudios presentan todas las características buscadas, estar basados en las entidades de diseño y constituir un método de evaluación completo.A continuación realizaremos una crítica de los dos estudios de nuestro interés. La TABLA VIII muestra el uso que hacen dichos modelos de algunos elementos de conocimiento OO.

3.6.1

El modelo QMOOD de Bansiya y Davis

Bansiya y Davis (2002) presentan un modelo para la evaluación de atributos de calidad de alto nivel en diseño orientado a objetos llamado Quality Model for ObjectOriented Design (QMOOD). Se descompone en cuatro niveles: componentes de diseño OO (L4), métricas OO (L3), propiedades de diseño OO (L2) y finalmente atributos de calidad de diseño (L1). Establece también enlaces entre niveles

JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS

11

Principios Bansiya & Davis Barber & Graser Marinescu & Ratiu (2004) Miller, Hsia & Kung No No No Sí

Patrones No Indirectamente Parcialmente No

Heuristicas No Sí No No

Malos Olores No No Sí No

TABLA VIII: Uso de elementos de conocimiento OO en los cuatro modelos completos
adyacentes, L31 (del 1 al 3), L23 (del 3 al 2) y L12 (del 2 al 1). Este modelo sigue una filosofía muy parecida a la explicada en el apartado 2.1 y utiliza parcialmente los atributos de la norma ISO 9126: reusabilidad, flexibilidad, comprensibilidad, funcionalidad, extensibilidad y efectividad. En cada uno de los enlaces Bansiya y Davis identifican relaciones explícitas entre componentes de ambos niveles, para el L23 la correspondencia es uno a uno entre las métricas y las propiedades OO (tamaño de diseño, jerarquías, cohesión, abstracción, encapsulamiento, acoplamiento, cohesión, composición, herencia, polimorfismo, comunicación inter clases y complejidad), y en L12 la correspondencia es incluso más explícita porque cada atributo de calidad es el resultado de la suma de cada una de las métricas obtenidas multiplicada por su peso, como, por ejemplo, la reusabilidad que es igual a -0.25*Acoplamiento +0.25*Cohesión +0.5*comunicación +0.5Tamaño del diseño. Los pesos pueden ser negativos o positivos y se han sido calculados de manera intuitiva, de hecho, los autores informan de que los pesos se pueden variar para ajustarse a los objetivos perseguidos por la organización que haga uso del modelo. Por otro lado, la importancia relativa de cada atributo de calidad queda a merced del diseñador con lo que éste podrá establecer qué tipo de calidad busca. No se utiliza ningún tipo de elemento de conocimiento orientado a objetos con lo que, a nuestro entender, se pierde la oportunidad de utilizar información calidad de diseño recopilada colectivamente en los últimos 20 años. ductos. Como en el caso anterior existen correspondencias que guían los cálculos desde las métricas propiamente dichas hasta los atributos de calidad, pero en este caso las propiedades intermedias no son las usuales sino que se utilizan elementos de conocimiento OO: heurísticas y estrategias (entendidas como refactorizaciones y transformaciones del diseño que guían la aplicación de las herísticas). De esta manera Barber y Graser incorporan el conocimiento OO no como un objetivo a alcanzar, como ocurre en (Miller et al., 1999), sino como una herramienta para incrementar el valor de los atributos de calidad. Los atributos de calidad elegidos por el diseñador y sus pesos asociados son objetivos de calidad; las métricas calculan el grado de cumplimiento de las heurísticas que se utilizan para calcular si se han alcanzado los objetivos. La herramienta utiliza estrategias para ayudar al diseñador a cambiar los diseños (sugiriendo una determinada transformación) para incrementar el grado de cumplimiento de las heurísticas. El orden en que se sugieren las transformaciones viene determinado por los objetivos. Por desgracia el artículo habla de una herramienta en construcción y en nuestras búsquedas no hemos vuelto a encontrar ninguna mención al respecto. En el artículo no se ofrecen medidas cuantitativas acerca de los cálculos de cada heurística ni se listan las heurísticas y estrategias utilizadas, por lo que este estudio queda incompleto.

3.6.2

El modelo RARE de Barer y Graser:

4

CONCLUSIONES

El modelo de Barber y Graser (2000) no es un método de evaluación sino más bien una herramienta para crear modelos de evaluación mediante la especificación de los atributos de calidad que son objetivo del usuario, automatiza lo que Bansiya y Davis dejaban a merced del diseñador, o sea, la importancia relativa de los atributos y los pesos de otros elementos o propiedades. La herramienta se denomina RARE (Referente Architecture Representation Environment). Los autores afirman que los atributos de calidad impactan mutuamente y por tanto no es posible maximizarlos todos al mismo tiempo, por lo que el diseñador debe resolver los conflictos que surjan. Es decir, no es lo mismo la calidad que se busca para el diseño de un sistema en tiempo real que para uno orientado a la interactividad humana pero del que preveemos una alto nivel de cambios, los atributos a optimizar serán distintos, en uno se primará el rendimiento y en el otro la flexibilidad, que, en principio, suelen tener una relación inversa. Cada dominio de aplicación buscará un nivel de calidad distinto, algo así como lo que ocurre en el proceso software de una organización donde buscaremos el nivel CMM 2 si la orientación es a proyectos o el nivel 3 ó 4 si el objetivo es desarrollar pro-

Podemos concluir que ya existen trabajos en la literatura que han establecido métricas específicas basadas en el diseño, como por ejemplo (Genero et al., 2001; Kiewkanya et al., 2004) que establecen un conjunto de métricas sobre diagramas UML (de clases y secuencias). Sin embargo pocos establecen un método completo de evaluación de calidad del diseño (los dos anteriores, por ejemplo, se centran exclusivamente en la mantenibilidad). Una conclusión importante es que la mantenibilidad es el indicador de calidad más utilizado, lo cual es lógico dado que la Orientación a Objetos se considera un paradigma que favorece la flexibilidad y la reutilización. Otros indicadores de calidad como la eficiencia o la portabilidad no están presentes en los modelos completos, lo que puede deberse a que los estudios están sesgados por no considerarse diferentes dominios de aplicación. Sólo cuatro estudios establecen un modelo completo de evaluación de calidad del diseño de manera cuantitativa y de ello sólo dos se pueden aplicar exclusivamente a entidades de diseño. En una futura investigación se perfilan ya dos objetivos fundamentales, por un lado el establecimiento de jerarquías

12

entre atributos de calidad, quizás en conjuntos basados en dominios específicos de aplicación (tiempo real, interactividad, procesamiento masivo de datos, proceso científico, etc.), y por otro lado una mejor apliación de los elementos de conocimiento de micro arquitecturas OO mediante el uso de ontologías.

sevier. Henderson-Sellers, B., Constantine, L. L., & Graham, I. M. (1996). Coupling and cohesion (towards a valid metrics suite for object oriented analysis and design). Object Oriented Systems, 3, 142-158. Humphrey, W. S. (1989). Managing the software process. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. ISO/IEC. (2001). Software engineering -- product quality -- part 1: Quality model. Geneva, Switzerland: ISO/IEC. Kiewkanya, M., Jindasawat, N., & Muenchaisri, P. (2004). A methodology for constructing maintainability model of object-oriented design. Kitchenham, B. (2004). Procedures for performing systematic reviews (Joint Technical Report No. NICTA Technical Report 0400011T.1): Software Engineering Group, Department of Computer Science, Keele University and Empirical Software Engineering National ICT Australia Ltd. Li, W., & Henry, S. (1993). Maintenance metrics for the object oriented paradigm. Paper presented at the Software Metrics Symposium. Marinescu, R., & Ratiu, D. (2004). Quantifying the quality of objectoriented design: The factor-strategy model. McCabe, T. J. (1976). A software complexity measure. Software Engineering, IEEE Transactions on, 2, 308-320. Meyer, B. (1988). Object-oriented software construction (1 ed.): Prentice Hall. Miller, B. K., Hsia, P., & Kung, C. (1999). Object-oriented architecture measures. Paper presented at the Hawaii International Conference on System Sciences. Purao, S., & Vaishnavi, V. (2003). Product metrics for object-oriented systems. ACM Comput. Surv., 35(2), 191--221. Software design, part 2. (2004).). Subramanyam, R., & Krishnan, M. S. (2003). Empirical analysis of ck metrics for object-oriented design complexity: Implications for software defects. Software Engineering, IEEE Transactions on, 29(4), 297.

5

BIBLIOGRAFÍA
the software engineering body of knowledge. 2004 version. Swebok: IEEE Press.

Abran, A., James, W. M., Bourque, P., & Dupuis, R. (2004). Guide to

Bansiya, J., & Davis, C. G. (2002). A hierarchical model for objectoriented design quality assessment. Software Engineering, IEEE Transactions on, 28(1), 4. Barber, K. S., & Graser, T. J. (2000). Tool support for systematic class identification in object-oriented software architectures. Basili, V. R., Briand, L. C., & Melo, W. L. (1996). A validation of objectoriented design metrics as quality indicators. Software Engineering, IEEE Transactions on, 22(10), 751. Briand, L. C., Wust, J., Daly, J. W., & Victor Porter, D. (2000). Exploring the relationships between design measures and software quality in object-oriented systems. Journal of Systems and Software, 51(3), 245. Brito e Abreu, F., & Melo, W. (1996). Evaluating the impact of objectoriented design on software quality. Paper presented at the Software Metrics Symposium. Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for object oriented design. Paper presented at the OOPSLA '91: Conference proceedings on Object-oriented programming systems, languages, and applications, New York, NY, USA. Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object oriented design. Software Engineering, IEEE Transactions on, 20(6), 476. Deligiannis, I., Shepperd, M., Roumeliotis, M., & Stamelos, I. (2003). An empirical investigation of an object-oriented design heuristic for maintainability. Journal of Systems and Software, 65(2), 127. Dumke, R. R., & Kuhrau, I. (1994). Tool-based quality management in object-oriented software development. Paper presented at the Symposium Assessment of Quality Software Development Tools. Fenton, N., Pfleeger, S. L., & Glass, R. L. (1994). Science and substance: A challenge to software engineers. IEEE Software, 11(4), 86--95. Fenton, N. E., & Pfleeger, S. L. (1998). Software metrics: A rigorous and practical approach: PWS Publishing Co. Fowler, M. (2000). Refactoring: Improving the design of existing code: Addison-Wesley. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. Garzás, J., & Piattini, M. (2005). An ontology for microarchitectural design knowledge. Software, IEEE, 22(2), 28. Genero, M., Piattini, M., & Jimenez, L. (2001). Empirical validation of class diagram complexity metrics. Halstead, M. H. (1977). Elements of software science. New York: El-