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 INTRODUCCIÓN

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 soft-ware 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 di-seño OO en fases tempranas, antes incluso de que dicho

diseño se haya implementado en código. Por una parte, interesa saber si un determinado diseño se ajusta a un de-terminado 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 reha-cer todo el producto desde sus fases iniciales. En el último caso, quizás el más complejo, se podría incluso llegar a de-cidir 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 necesa-rio disponer de métricas tales que permitieran, en primer lugar, establecer niveles cuantitativos de calidad en deter-minados 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-

C

2

bles para alcanzar dichos niveles. Esto implicaría, natural-mente, no solamente un conjunto de métricas sino toda una metodología de mejora de diseño OO basado en transfor-maciones, 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ús-queda de métricas OO aplicables al diseño. Para ello se reali-zará 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 entien-de 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, fi-nalmente, se cierra el estudio con unas conclusiones, en el apartado 4.

2 ANTECEDENTES 2.1 Atributos de calidad y entidades de diseño En primer lugar debemos acotar el contexto en el que nos movemos, ya que la calidad, en el software, se puede en-tender 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 clara-mente centrados en la calidad del producto software y, de-ntro 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 in-terna se mejora directamente la calidad observada en atri-butos de uso del producto software. Tanto la calidad inter-na como la externa se definen, en ISO 9126, como un con-junto 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

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 co-rrecciones, mejoras o adaptaciones a cambios en el en-torno y en los requisitos y especificaciones funciona-les.

• Portabilidad: la capacidad del software de ser trasla-dado 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 ge-neral de lo que es la calidad de producto software en gene-ral, 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 sub-productos intermedios en los que podemos hacer medicio-nes de calidad previas a las que se puedan hacer al dispo-ner 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

Fig. 1: Atributos de calidad ISO 9126

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

diseño: • Por lo que respecta a la característica de funcionali-

dad hemos de decir que su medición pretende diluci-dar 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 me-dirse 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 Ca-lidad cubre, entre otras cosas, la verificación de di-chos 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 comporta-miento del diseño original debe ser fundamentalmen-te correcto (Fowler, 2000) (en términos de funcionali-dad y de fiabilidad). Por tanto, si dos diseños respon-den 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 fia-bilidad como uno de los atributos internos que defi-nen 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 pa-ra asegurar un determinado nivel de cobertura y por ende el número de defectos latentes. Trabajos poste-riores (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 fiabili-dad 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 pro-

1 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 termina-do. No se han encontrado evidencias que permitan es-tablecer esta característica como un atributo interno de calidad del diseño. La comprensibilidad (ing. “Un-derstandability”) se menciona en la literatura (Bansiya & Davis, 2002; Deligiannis et al., 2003; Dum-ke & 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 po-dría tratarse del desarrollador que ha de implemen-tarlo, o bien podría ser el mismo diseñador (u otro) en el futuro cuando se requiera introducir una nueva ca-racterística al producto o se deba modificar el diseño por cualquier razón, este último caso ya está com-prendido 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 ca-racterística un claro objetivo de medición en las fases de pruebas, sin embargo existe una tendencia actual-mente, 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 cali-dad altos aunque probablemente no en los más bási-cos. 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

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

4

entidades permite un mejor aislamiento e identifica-ció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 di-señ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 repre-sentació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 ge-nerales para el diseño software pero no hemos particulari-zado 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) de-bemos 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 propieda-des como cohesión, acoplamiento, encapsulamiento, com-plejidad 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 gene-rales de calidad de diseño, como en el caso de (Bansiya & Davis, 2002) donde a cada atributo de diseño le correspon-de 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 aplica-das 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 es-tamos 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 tra-bajo 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 revisa-ron 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 aque-llas 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

2.2 Métricas de Orientación a Objetos Hasta ahora hemos hablado de nuestro objetivo, revi-

sar métricas OO propias del diseño, hemos situado par-te 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 & Vaishna-vi, 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 pa-ra poderse aplicar. Otra conclusión importante que se saca de este rápido análisis es que estas “suites” se cen-tran 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

Entidad Atributo

Asociación Tamaño Atributo Posición Clase Abstracción Comportamiento Comentarios

Esfuerzo

Interacción

Interfaz

Rendimiento

Posición

Reutilización

Tamaño

Estructura

Jerarquía Estructura

Enlace Cardinalidad

Método Abstracción

Esfuerzo

Interacción

Interfaz

Rendimiento

Posición

Reutilización

Tamaño

Estructura

Paquete Abstracción

Interacción

Tamaño

Estructura

Parametro Tamaño

Escenario Tamaño

Sistema 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 atribu-tos

6

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, acoplamien-to, cohesión, herencia y comunicación inter-clases. Pode-mos 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

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 en-tonces, 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 modi-ficaciones 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

Métrica Definición Propiedades

Weighted methods per class (WMC)

Considérese una clase 1C con los métodos nMMM ,...,, 21 . Sea

nccc ,...,, 21 la complejidad estática de los métodos. Entonces:

∑ ==

n

i icWMC1

La complejidad estática se puede medir de mu-

chas maneras, siendo una de ellas CC(McCabe, 1976).

Complejidad

Depth of Inheritance tree (DIT) La métrica DIT de una clase A es su profundidad en el árbol de heren-cia. Si A se encuentra en situación de herencia multiple la longitude maxima hasta la raíz sera el DIT.

Herencia

Number of children (NOC) NOC de una clase es el número de subclases inmediatamente subordi-nadas a una clase en la jerarquía.

Herencia

Coupling between object classes (CBO)

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.

Acoplamiento

Response for a class (RFC) RSRFC = donde RS es el conjunto respuesta de la clase, dado

que { } { }U iall iRMRS = donde { }=iR conjunto de los méto-

dos invocados por el método i y { }M es el conjunto de todos los 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 reci-bido por un objeto de la clase.

Comunicación

Lack of cohesion in methods (LCOM)

Considérese una clase iC con n métodos nMMM ,...,, 21 . Sea { }jI el conjunto de variables de instancia usados por el método iM . Existen n de esos conjuntos{ } { }nII ,...,1 . Sea ( ){ }Ø, == jiji IIIIP I y ( ){ }Ø, ≠= jiji IIIIQ I . Si todos los n conjuntos { } { }nII ,...,1 son Ø entonces sea

Ø=P . QPLCOM −= , si QP > ó 0 en otro caso.

Cohesión

TABLA II: Métricas de C&K

Métrica Definición Propiedades

Message passing coupling (MPC) MPC= número de métodos invocados en un clase. Acoplamiento/Comunicación

Data abstraction coupling (DAC) El número de atributos en una clase que tienen como tipo otra clase. Acoplamiento/Abstracción

SIZE1 Es una variación de la tradicional LOC (Lineas de Código) definida específicamente para el lenguaje Ada. Obviamos la definición

Tamaño del diseño

SIZE2 SIZE2 = número de atributos + número de métodos locales. Tamaño del diseño

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

clases con distintos grados de cohesión real obtengan idén-ticos valores de LCOM. Por otra parte esta nueva suite de métricas tiene un objetivo claro, que es la medición y mejo-ra 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 in-cluir 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.

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 antece-sores más uno en otro caso.

3 METODOLOGÍA Y RESULTADOS

3.1 Procedimiento de revision sistemática Para nuestro studio hemos seguido el procedimiento de revisión sistemática de la literatura especializada de Kit-chenham (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 ques-tions).

• 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 (valida-ción y criterios de calidad de los datos). Este protoco-lo 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 final-mente 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 documen-tar 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 fi-nales en forma resumida, preferentemente de la ma-nera 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 dis-tintos elementos como eran los criterios de calidad, que más adelante veremos. Los trabajos que pasaron los criterios bási-cos de selección fueron recogidos en formato electrónico (PDF). Se utilizó la herramienta Access para la base de datos

Métrica Definición Propiedades

Design size of classes (DSC) Número total de clases en el diseño Tamaño del diseño Number of Hierarchies (NOH) Número de jerarquías de clases Jerarquías Average number of ancestors (ANA)

Número medio de ancestros Abstracción

Data access Metric (DAM) Relación entre el número de atributos privados (protegidos) y el núme-ro total de atributos de la clase.

Encapsulamiento

Direct class coupling (DCC) 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.

Acoplamiento

Cohesion among methods of class (CAM)

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.

Cohesión

Measure of aggregation (MOA) Mide la extension de la relación parte/todo, mediante el uso de atribu-tos. Es el número de declaraciones de variables cuyo tipo es definido por el usuario.

Composición

Measure of functional abstraction (MFA)

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.

Herencia

Number of polymorphic methods (NPM)

Número de métodos que pueden mostrar comportamiento polimórfico (virtual en C++ y no final en Java)

Polimorfismo

Class interface size (CIS) Número de métodos públicos en una clase Comunicación

Number of methods (NOM) Número de métodos definidos en una clase Complejidad

TABLA IV: Métricas de Bansiya y Davis

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 dilu-cidar 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 cali-dad 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 fun-ció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 di-señ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 cali-dad son los más utilizados en dichas métricas.

Para acotar claramente nuestro campo de acción utiliza-remos 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 referi-remos a los objetos y las clases, su estructura y relación en-tre 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 cuanti-tativamente 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 co-mo:

Pregunta 2: ¿Se miden las propiedades OO tradicionales (an-tes mencionadas) o bien se utiliza nuevos elementos de conoci-miento tales como los clasificados en (Garzás & Piattini, 2005)?

Es importante, para posteriores trabajos, saber si elemen-tos 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 ac-tas 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 distin-

tas 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, co-mo por ejemplo “assess”, “assessing”, “evaluation” y “evalua-te”. 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 particu-laridades 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 rela-cionados 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án-donos con la más reciente.

Tras los descartes por repetición quedaron 481 trabajosso-bre 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 des-cartaron 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

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 crite-rio de exclusión y todos los trabajos que habían llegado hasta este punto fueron tenidos en cuenta.

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 in-cluyendo, por ejemplo, mediciones de productividad o de asegu-ramiento 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 atri-butos 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. Aun-que todas las fuentes primarias proponían de alguna mane-ra métodos de evaluación de calidad de diseño OO, sola-mente 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-

tudio en cuestión realmente se refiera a un método de eva-luació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, cal-cularse 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 SI-ZE1 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 di-señ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 cali-dad que aparecen en los estudios primarios, con las deno-minaciones 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 anali-zabilidad, inteligibilidad2 y comprensibilidad. Ha de tener-se en cuenta que en todo momento nos referimos a atribu-

2 Hemos traducido “comprehensibility” por inteligibilidad y “understan-dability” 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

Level Name Description

1 Ensayo aleatorio Evidencia obtenida de al menos un ensayo aleatorio controlado bien dise-ñado.

2 Ensayo pseudo-aleatoriol Evidencia obtenida de al menos un ensayo pseudos-aleatorio controlado bien diseñado.

3 Estudio concurrente de cohorte (grupo de voluntarios)

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.

4 Control histórico 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.

5 Experimento aleatorio Evidencia obtenida de un experimento aleatorio ejecutado en un entorno artificial.

6 Serie de casos Evidencia obtenida de una serie de casos, bien post-tes o pre-test.

7 Experimento pseudo-aleatorio Evidencia obtenida de un experimento pseudos-aleatorio ejecutado en un entorno artificial.

8 Opinión de experto Evidencia obtenida de la opinion experta basada en la teoría o el consenso.

TABLA V: Niveles de calidad para las fuentes primarias

Número de Estudios Aceptados

Total Aceptados Descartados Modelos completos Diseño exclusivamente Intersección

481 23 458 4 9 2

TABLA VI: Resumen de los datos recogidos

10

tos de calidad aplicados al diseño, por tanto la comprensibi-lidad 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.

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 mantenibi-lidad, 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, inteli-gibilidad y comprensibilidad son sinónimos, y lo mismo puede decirse de la cambiabilidad, flexibilidad y extensibi-lidad. 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 estudios-para evitar confusiones en la traducción.

menos importantes que la mantenibilidad. Por otra, se ha observado que muchos estudios tratan de predecir y dis-munir los defectos tan pronto como sea posible en el ciclo de vida, es decir, en la etapa de diseño. Una posible inter-pretació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 com-paració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 eva-luación de atributos de calidad de alto nivel en diseño orientado a objetos llamado Quality Model for Object-Oriented Design (QMOOD). Se descompone en cuatro nive-les: componentes de diseño OO (L4), métricas OO (L3), pro-piedades de diseño OO (L2) y finalmente atributos de cali-dad de diseño (L1). Establece también enlaces entre niveles

Indicador3 Modelo Completo

Estudios aplica-dos a diseño sólo

Fuentes primarias

Adaptability 0 0 1 Analysability 1 0 1 Change proneness 0 0 0 Changeability 1 1 2 Completeness 0 2 2 Complexity 0 0 3 Comprehensibility 1 1 1 Consistency 0 2 2 Correctness 0 2 2 Effectiveness 1 1 1 Efficiency 0 0 0 Extensibility 1 1 4

Flexibility 1 1 1

Functionality 1 1 1

Maintainability 1 4 10

Performance 1 1 2

Realizability 0 1 1

Reliability 0 0 4

Reusability 2 2 5

Security 0 0 1

Stability 1 0 1

Testability 1 3 5

Traceability 0 1 1

Unambiguity 0 1 1

Understandability 1 2 4

Usability 0 0 1

Verifiability 0 0 0

TABLA VII: Indicadores de calidad de alto nivel recogidos

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

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 expli-cada en el apartado 2.1 y utiliza parcialmente los atributos de la norma ISO 9126: reusabilidad, flexibilidad, compren-sibilidad, 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étri-cas y las propiedades OO (tamaño de diseño, jerarquías, cohesión, abstracción, encapsulamiento, acoplamiento, co-hesió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 reusabili-dad 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 in-forman 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.

3.6.2 El modelo RARE de Barer y Graser: El modelo de Barber y Graser (2000) no es un método de evaluación sino más bien una herramienta para crear mode-los de evaluación mediante la especificación de los atribu-tos 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 Environ-ment). Los autores afirman que los atributos de calidad impactan mutuamente y por tanto no es posible maximizar-los 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 aplica-ció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-

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 propie-dades intermedias no son las usuales sino que se utilizan elementos de conocimiento OO: heurísticas y estrategias (en-tendidas 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 elegi-dos 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 alcan-zado 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 sugie-ren las transformaciones viene determinado por los objeti-vos.

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 ca-da heurística ni se listan las heurísticas y estrategias utiliza-das, por lo que este estudio queda incompleto.

4 CONCLUSIONES 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 dia-gramas 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 ex-clusivamente en la mantenibilidad).

Una conclusión importante es que la mantenibilidad es el indicador de calidad más utilizado, lo cual es lógico da-do que la Orientación a Objetos se considera un paradigma que favorece la flexibilidad y la reutilización. Otros indica-dores de calidad como la eficiencia o la portabilidad no es-tán presentes en los modelos completos, lo que puede de-berse 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 entida-des de diseño.

En una futura investigación se perfilan ya dos objetivos fundamentales, por un lado el establecimiento de jerarquías

Principios Patrones Heuristicas Malos Olores

Bansiya & Davis No No No No Barber & Graser No Indirectamente Sí No

Marinescu & Ratiu (2004) No Parcialmente No Sí

Miller, Hsia & Kung Sí No No No

TABLA VIII: Uso de elementos de conocimiento OO en los cuatro modelos completos

12

entre atributos de calidad, quizás en conjuntos basados en dominios específicos de aplicación (tiempo real, interactivi-dad, 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.

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

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

Bansiya, J., & Davis, C. G. (2002). A hierarchical model for object-oriented 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 object-oriented design metrics as quality indicators. Software Engi-neering, 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 object-oriented 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 heu-ristic 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 Develop-ment Tools.

Fenton, N., Pfleeger, S. L., & Glass, R. L. (1994). Science and sub-stance: 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-

sevier. Henderson-Sellers, B., Constantine, L. L., & Graham, I. M. (1996).

Coupling and cohesion (towards a valid metrics suite for ob-ject 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 methodol-ogy 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 Sympo-sium.

Marinescu, R., & Ratiu, D. (2004). Quantifying the quality of object-oriented design: The factor-strategy model.

McCabe, T. J. (1976). A software complexity measure. Software Engi-neering, IEEE Transactions on, 2, 308-320.

Meyer, B. (1988). Object-oriented software construction (1 ed.): Pren-tice Hall.

Miller, B. K., Hsia, P., & Kung, C. (1999). Object-oriented architecture measures. Paper presented at the Hawaii International Con-ference 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 Transac-tions on, 29(4), 297.