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

C 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-
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
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 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
JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS
Fig. 2: Calidad de producto en el ciclo de vida software
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.
3
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
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

Entidad Atributo
2.2 Métricas de Orientación a Objetos
Asociación Tamaño
Hasta ahora hemos hablado de nuestro objetivo, revi-
Atributo Posición
sar métricas OO propias del diseño, hemos situado par-
Clase Abstracción
te del dominio del problema explicando qué se entiende
Comportamiento
en este contexto por calidad y dónde se debería medir.
Comentarios
Antes de entrar en el método de trabajo y los hallazgos
Esfuerzo debemos ofrecer una visión retrospectiva e histórica de
Interacción lo que son las métricas OO en general.
Interfaz Para obtener una lista más exhaustivas de métricas se
Rendimiento
pueden consultar (Briand et al., 2000; Purao & Vaishna-
vi, 2003). Podemos adelantar que en su mayoría las mé-
Posición
tricas OO de diseño no son tales, aunque digan serlo, ya
Reutilización que necesitan el código fuente resultante del diseño pa-
Tamaño ra poderse aplicar. Otra conclusión importante que se
Estructura saca de este rápido análisis es que estas “suites” se cen-
tran en conjuntos bastante restringidos de propiedades
Jerarquía Estructura
OO, fundamentalmente, acoplamiento, cohesión, y
Enlace Cardinalidad herencia. Las primeras métricas OO, como se puede ver,
Método Abstracción tampoco estaban orientadas a objetivos específicos de
Esfuerzo calidad.
Interacción
2.2.1 La familia de métricas de Chidamber y
Interfaz Kemerer
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

Métrica Definición Propiedades

Weighted methods per class Complejidad

(WMC)
Depth of Inheritance tree (DIT)
Number of children (NOC)
Coupling between object classes
(CBO)
Response for a class (RFC)
Considérese una clase C1 con los métodos M 1 , M 2 ,..., M n . Sea
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 mu-
chas maneras, siendo una de ellas CC(McCabe, 1976).
La métrica DIT de una clase A es su profundidad en el árbol de heren- Herencia
cia. 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 subordi- Herencia
nadas a una clase en la jerarquía.
CBO de una clase es el número de clases con las que está acoplada. Una Acoplamiento
clase está acoplada a otra si utiliza sus métoods o variables de instancia,
excluyendo acoplamiento por herencia.
Comunicación
RFC = RS donde RS es el conjunto respuesta de la clase, dado

que 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
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.
Considérese una clase C i con n métodos M 1 , M 2 ,..., M n . Sea
{ }
Lack of cohesion in methods Cohesión
(LCOM) I j el conjunto de variables de instancia usados por el método M i .
{ } { }
{( } {( }
n de conjuntos I 1 ,..., I n .
) )
Existen esos
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.
TABLA II: Métricas de C&K
S.R. Chidamber y C.F. Kemerer (C&K) fueron los primeros mismas. Se trata por un lado de un intento de adaptar las
(1991) en establecer un conjunto de 6 métricas de productos métricas ya en uso en el mundo estructurado (Halstead,
específica para código OO; todas menos uno se aplicaban a 1977; McCabe, 1976), cuyo uso está más bien orientado a la
las clases y trataban de medir la complejidad, acoplamien- productividad y el cálculo de coberturas de pruebas que a
to, cohesión, herencia y comunicación inter-clases. Pode- la calidad, y por otro lado de incorporar los, por aquel en-
mos ver en la TABLA II la definición de dichas métricas y la tonces, incipientes principios básicos del diseño orientado a
propiedad OO con la que se relacionan. Obviamente hay objetos (Meyer, 1988).
una relación directa entre cada una de las métricas y la
propiedad OO correspondiente, aunque en el caso de la 2.2.2 Métricas de Li y Henry
herencia existan dos métricas asociadas a ella. Por otro lado A partir de las métricas de C&K se van proponiendo modi-
no se establece ningún método de evaluación de calidad de ficaciones y ampliaciones sobre ellas, éste es el caso de Li y
producto ni se relacionan explícitamente los atributos de Henry (1993) que proponen varias modificaciones y añaden
calidad con las propiedades OO, de manera intuitivas, eso cuatro nuevas métricas. La modificación más resaltable es
sí, se sabe que el control de dichas propiedades ayuda, de la que se hace sobre la LCOM, que otros autores volverán a
manera general, a mejorar el diseño o el producto final o discutir (Henderson-Sellers et al., 1996), ya que se considera
que un buen sistema OO debe maximizar el uso de las que la definición original es ambigua y permite que dos

Métrica Definición Propiedades

Message passing coupling (MPC)
Data abstraction coupling (DAC)
SIZE1
SIZE2
MPC= número de métodos invocados en un clase. Acoplamiento/Comuni
cación
El número de atributos en una clase que tienen como tipo otra clase. Acoplamiento/Abstracc
ión
Es una variación de la tradicional LOC (Lineas de Código) definida Tamaño del diseño
específicamente para el lenguaje Ada. Obviamos la definición
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

Métrica Definición Propiedades

Design size of classes (DSC)
Number of Hierarchies (NOH)
Average number of ancestors
(ANA)
Data access Metric (DAM)
Direct class coupling (DCC)
Cohesion among methods of class
(CAM)
Measure of aggregation (MOA)
Measure of functional abstraction
(MFA)
Number of polymorphic methods
(NPM)
Class interface size (CIS)
Number of methods (NOM)
Número total de clases en el diseño Tamaño del diseño
Número de jerarquías de clases Jerarquías
Número medio de ancestros Abstracción
Relación entre el número de atributos privados (protegidos) y el núme- Encapsulamiento
ro total de atributos de la clase.
Número de clases diferents con las que una clase está relacionada. Esta Acoplamiento
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 Cohesión
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 atribu- Composición
tos. 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 Herencia
total de métodos accesibles por un método miembro.
Número de métodos que pueden mostrar comportamiento polimórfico Polimorfismo
(virtual en C++ y no final en Java)
Número de métodos públicos en una clase Comunicación
Número de métodos definidos en una clase Complejidad

TABLA IV: Métricas de Bansiya y Davis

clases con distintos grados de cohesión real obtengan idén- queda, criterios de inclusión y exclusión, la forma de
ticos valores de LCOM. Por otra parte esta nueva suite de recogida de dato y los criterios de extracción (valida-
métricas tiene un objetivo claro, que es la medición y mejo- ción y criterios de calidad de los datos). Este protoco-
ra de la mantenibilidad del software OO, y para ello se lo se debe refinar tras las primeras búsquedas ya que
añaden la abstracción y el tamaño de diseño (aunque una normalmente los propios datos obtenidos van dando
de las dos métricas propuestas para él se basa en las líneas indicaciones sobre ajustes que deben realizarse, sobre
de código). Se da pues un cierto avance conceptual al in- todo en la forma de recogida de datos o los criterios
cluir de manera explícita un atributo de calidad de software de exclusión.
como objetivo de las métricas. En la TABLA III se pueden • Se ejecutan propiamente las búsquedas y se recogen
ver la modificación de LCOM y las cuatro nuevas métricas los datos.
propuestas por Li y Henry. • En la etapa de extracción de datos se validan los datos
y se clasifican según su “calidad” con lo que final-
2.2.3 Métricas de Henderson-Sellers mente se obtienen resultados y conclusiones.
Henderson-Sellers, Constantine y Graham (1996) ofrecieron • Finalmente se recogen los resultados en formatos de
su propia familia de métricas donde la mayoría estaban tablas u otros y se elabora un informe documental
relacionadas con el acoplamiento y la cohesión, solamente que es el objetivo final de la revisión. Kitchenham
la “profundidad media de herencia de una clase” o AID propone un formato de documento de revisión que,
(ing. Average Inheritance Depth) se relacionaba con la fundamentalmente, es el que se ha seguido en este
herencia. Esta medida tomaba el valor 0 si la clase no tenía trabajo. En dicho documento es importante documen-
antecesores y la media de los valores de AID de sus antece- tar los antecedentes y objetivos, el protocolo seguido a
sores más uno en otro caso. alto nivel, incluyendo las cuestiones de investigación
y los criterios de exclusión, así como los resultados fi-
3 METODOLOGÍA Y RESULTADOS nales en forma resumida, preferentemente de la ma-
nera más visual posible, tablas o gráficos.
3.1 Procedimiento de revision sistemática En las siguientes secciones recogemos el protocolo seguido,
aunque no con todo el detalle de todas las consultas realizadas
Para nuestro studio hemos seguido el procedimiento de
en las distintas fuentes, pues sería tedioso. Se eligió recoger los
revisión sistemática de la literatura especializada de Kit-
datos de las búsquedas en una base de datos diseñada “ad
chenham (2004). En dicho procedimiento se establecen una
hoc” con campo específicos donde tras la lectura inicial de los
serie de pasos a seguir que son:
resumenes (ing abstracts) o de los trabajos completos (si nos e
• Establecimiento del objetivo de revisión mediante
descataban directamente por los resumenes) se recogían dis-
“preguntas de la investigación” (ing. research ques-
tintos elementos como eran los criterios de calidad, que más
tions).
adelante veremos. Los trabajos que pasaron los criterios bási-
• Establecimiento de un protocolo de revisión donde se
cos de selección fueron recogidos en formato electrónico
establezcan las fuentes a utilizar, los patrones de bús-
(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 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

Level Name Description

1 Ensayo aleatorio
2 Ensayo pseudo-aleatoriol
3 Estudio concurrente de cohorte
(grupo de voluntarios)
4 Control histórico
5 Experimento aleatorio
6 Serie de casos
7 Experimento pseudo-aleatorio
8 Opinión de experto
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.

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

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

cuantificado, los hemos denominado “modelos completos”. 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
Por otra parte también registramos el hecho de que el es- de “understandiblity” en la literatura de Ingeniería del Software española
10

Modelo Estudios aplica-

Indicador3 Fuentes primarias
Completo dos a diseño sólo
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
tos de calidad aplicados al diseño, por tanto la comprensibi- menos importantes que la mantenibilidad. Por otra, se ha
lidad debe ser entendida como la capacidad que tiene un observado que muchos estudios tratan de predecir y dis-
diseño de ser entendido por un desarrollador distinto a su munir los defectos tan pronto como sea posible en el ciclo
autor y no como la sub-caracerística de usabilidad de la ISO de vida, es decir, en la etapa de diseño. Una posible inter-
9126. pretación es que los métodos de evaluación de la calidad no
se interpretan como sustitución del Aseguramiento de la
3.6 Resultados Calidad y tratan de establecer un medio de medida y com-
A la vista de los resultados podemos afirmar que menos de paración de diseños distintos semánticament equivalentes,
la mitad de los estudios que tratan de establecer alguna o sea, construidos en base a los mismos requisitos y válidos
manera de evaluar la calidad de un diseño OO se basan en funcionalmente.
analizar únicamente entidades de diseño. De las 23 fuentes Dado el escaso número de estudios relevantes no se ha
primarias 14 se basan en el análisis del código fuente. considerado necesario realizar un análisis estadístico de los
Por otra parte, podemos observar que, viendo la TABLA datos obtenidos. Solamente 2 estudios presentan todas las
VII, para los llamados “modelos completos”, la mantenibi- características buscadas, estar basados en las entidades de
lidad, contando sus sub-características es el indicador más diseño y constituir un método de evaluación completo.A
recurrente con un total de 8 apariciones. La mantenibilidad continuación realizaremos una crítica de los dos estudios de
se compone de analizabilidad, cambiabilidad, estabilidad y nuestro interés. La TABLA VIII muestra el uso que hacen
testabilidad, y como ya hemos dicho, analizabilidad, inteli- dichos modelos de algunos elementos de conocimiento OO.
gibilidad y comprensibilidad son sinónimos, y lo mismo
puede decirse de la cambiabilidad, flexibilidad y extensibi- 3.6.1 El modelo QMOOD de Bansiya y Davis
lidad. Otro fasctor importante observado es la reusabilidad. Bansiya y Davis (2002) presentan un modelo para la eva-
Aparentemente cuando se trata de establecer un método luación de atributos de calidad de alto nivel en diseño
de evaluación de la calidad, la fiabilidad, la tendencia a los orientado a objetos llamado Quality Model for Object-
defectos y la validez funcional y consistencia son bastante 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-
3 Incluimos aquí los nombres en inglés tal como aparecen en los estudios-

para evitar confusiones en la traducción.

dad 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
Principios Patrones
Bansiya & Davis No
Barber & Graser No Indirectamente
Marinescu & Ratiu (2004) No Parcialmente
Miller, Hsia & Kung Sí
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 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-
11
Heuristicas Malos Olores
No No No
Sí No
No Sí
No No No
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
12

entre atributos de calidad, quizás en conjuntos basados en sevier.

dominios específicos de aplicación (tiempo real, interactivi- Henderson-Sellers, B., Constantine, L. L., & Graham, I. M. (1996).
dad, procesamiento masivo de datos, proceso científico, Coupling and cohesion (towards a valid metrics suite for ob-
etc.), y por otro lado una mejor apliación de los elementos ject oriented analysis and design). Object Oriented Systems,
de conocimiento de micro arquitecturas OO mediante el 3, 142-158.
uso de ontologías. Humphrey, W. S. (1989). Managing the software process. Boston, MA,
USA: Addison-Wesley Longman Publishing Co., Inc.
5 BIBLIOGRAFÍA ISO/IEC. (2001). Software engineering -- product quality -- part 1:
Quality model. Geneva, Switzerland: ISO/IEC.
Abran, A., James, W. M., Bourque, P., & Dupuis, R. (2004). Guide to
Kiewkanya, M., Jindasawat, N., & Muenchaisri, P. (2004). A methodol-
the software engineering body of knowledge. 2004 version.
ogy for constructing maintainability model of object-oriented
Swebok: IEEE Press.
design.
Bansiya, J., & Davis, C. G. (2002). A hierarchical model for object-
Kitchenham, B. (2004). Procedures for performing systematic reviews
oriented design quality assessment. Software Engineering,
(Joint Technical Report No. NICTA Technical Report
IEEE Transactions on, 28(1), 4.
0400011T.1): Software Engineering Group, Department of
Barber, K. S., & Graser, T. J. (2000). Tool support for systematic class
Computer Science, Keele University and Empirical Software
identification in object-oriented software architectures.
Engineering National ICT Australia Ltd.
Basili, V. R., Briand, L. C., & Melo, W. L. (1996). A validation of object-
Li, W., & Henry, S. (1993). Maintenance metrics for the object oriented
oriented design metrics as quality indicators. Software Engi-
paradigm. Paper presented at the Software Metrics Sympo-
neering, IEEE Transactions on, 22(10), 751.
sium.
Briand, L. C., Wust, J., Daly, J. W., & Victor Porter, D. (2000). Exploring
Marinescu, R., & Ratiu, D. (2004). Quantifying the quality of object-
the relationships between design measures and software
oriented design: The factor-strategy model.
quality in object-oriented systems. Journal of Systems and
McCabe, T. J. (1976). A software complexity measure. Software Engi-
Software, 51(3), 245.
neering, IEEE Transactions on, 2, 308-320.
Brito e Abreu, F., & Melo, W. (1996). Evaluating the impact of object-
Meyer, B. (1988). Object-oriented software construction (1 ed.): Pren-
oriented design on software quality. Paper presented at the
tice Hall.
Software Metrics Symposium.
Miller, B. K., Hsia, P., & Kung, C. (1999). Object-oriented architecture
Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for
measures. Paper presented at the Hawaii International Con-
object oriented design. Paper presented at the OOPSLA '91:
ference on System Sciences.
Conference proceedings on Object-oriented programming
Purao, S., & Vaishnavi, V. (2003). Product metrics for object-oriented
systems, languages, and applications, New York, NY, USA.
systems. ACM Comput. Surv., 35(2), 191--221.
Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object
Software design, part 2. (2004).).
oriented design. Software Engineering, IEEE Transactions
Subramanyam, R., & Krishnan, M. S. (2003). Empirical analysis of ck
on, 20(6), 476.
metrics for object-oriented design complexity: Implications
Deligiannis, I., Shepperd, M., Roumeliotis, M., & Stamelos, I. (2003).
for software defects. Software Engineering, IEEE Transac-
An empirical investigation of an object-oriented design heu-
tions on, 29(4), 297.
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-