Académique Documents
Professionnel Documents
Culture Documents
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.
—————————— ——————————
1 INTRODUCCIÓN
2 ANTECEDENTES
2.1 Atributos de calidad y entidades de diseño Fig. 1: Atributos de calidad ISO 9126
En primer lugar debemos acotar el contexto en el que nos
movemos, ya que la calidad, en el software, se puede en- nivel específico de rendimiento bajo determinadas
tender como calidad de proceso o de producto. La calidad condiciones de uso.
de proceso ha sido objeto de mucho interés en las últimas • Usabilidad: la capacidad del producto software de ser
décadas (Humphrey, 1989) y su desarrollo ha concienciado entendido, aprendido, usado y atractivo al usuario,
a los profesionales de la necesidad de aplicar la calidad a cuando se usa bajo ciertas condiciones.
otros aspectos del software. En nuestro caso estamos clara- • Eficiencia: la capacidad del software de ofrecer el
mente centrados en la calidad del producto software y, de- rendimiento apropiado con respecto a la cantidad de
ntro de ella, en el producto derivado de la fase de diseño recursos utilizados, bajo condiciones prefijadas.
(Software design, part 2, 2004). • Mantenibilidad: la capacidad del producto de ser
Fenton y Pfleeger (1998) explican que es un paso previo modificado. Dichas modificaciones pueden incluir co-
al establecimiento de las métricas el definir qué atributos o rrecciones, mejoras o adaptaciones a cambios en el en-
propiedades de qué elementos son los que queremos medir. torno y en los requisitos y especificaciones funciona-
Posteriormente podremos establecer si para medir dichos les.
atributos es necesario medir otros y derivar los que nos • Portabilidad: la capacidad del software de ser trasla-
interesan de ellos o bien se puede hacer directamente. En dado de un entorno (informático) a otro.
nuestro caso la única norma que hemos encontrado en la Estas características son generales para cualquier tipo de
literatura que da una definición de calidad de producto programa informático o software independientemente de si
software en base a atributos es ISO 9126 (ISO/IEC, 2001). el paradigma empleado para construirlo es el Orientado a
Dicha norma establece que la medición de la calidad de un Objetos, el estructurado u otro cualquiera, sin embargo si
producto software debe hacerse en base a sus atributos, que afectará a la manera de medirlas. Dichas características
siendo éstos internos, propiedades características de cómo se dividen a su vez en subcaracterísticas tal como se puede
se estructura el software, o externos, cualidades observables ver en la Fig. 1.
aún sin conocer cómo está construido. De hecho no se habla La norma ISO 9126 trata de establecer una definición ge-
de calidad, en general, sino de calidad interna y calidad neral de lo que es la calidad de producto software en gene-
externa, afirmándose que la calidad interna de un producto ral, tanto desde el punto de vista del usuario final como del
software influye directamente en su calidad externa. De que lo construye, de ahí que exista la visión externa como la
algún modo se está diciendo que mejorando la calidad in- interna. Sin embargo se puede decir que existen sub-
terna se mejora directamente la calidad observada en atri- productos intermedios en los que podemos hacer medicio-
butos de uso del producto software. Tanto la calidad inter- nes de calidad previas a las que se puedan hacer al dispo-
na como la externa se definen, en ISO 9126, como un con- ner el producto acabado y que, sin embargo nos pueden dar
junto de 6 características: una previsión de la calidad de este último. Es lógico pensar
• Funcionalidad: la capacidad del software de proveer que no todas las características antes mencionadas son
las funciones que cumplen con las necesidades implí- mensurables o tiene sentido en determinados productos
citas y explícitas cuando el mismo es utilizado bajo intermedios, como el diseño micro-arquitectónico, como es
ciertas condiciones. el caso que nos ocupa. De este modo debremos distinguir
• Fiabilidad: la capacidad del software de mantener un 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 3
entidades permite un mejor aislamiento e identifica- tendemos convertir en nuestras métricas. En muchos de los
ción de aquellos “puntos calientes” donde tienden a conjuntos de métricas OO publicados se utilizan propieda-
acumularse los problemas de rendimiento (Fowler, des como cohesión, acoplamiento, encapsulamiento, com-
2000). plejidad y herencia que, sin ser todas específicas del diseño
• La mantenibilidad es objetivo indiscutible de la OO, son lo suficientemente concretas y además se pueden
mayoría del conocimiento OO sobre mejora del di- relacionar matemáticamente con los atributos generales de
seño, esto se deduce del hecho, entre otros, de que la diseño. Se han propuesto distintas medidas para dichas
mayor parte del esfuerzo de diseño en el paradigma propiedades e incluso las relaciones con los atributos gene-
OO se centra alrededor de conceptos como ocultación, rales de calidad de diseño, como en el caso de (Bansiya &
encapsulación y abstracción de datos lo cual mejora la Davis, 2002) donde a cada atributo de diseño le correspon-
comprensibilidad (analizabilidad) mediante la repre- de una de estas métricas. En (Miller et al., 1999) se eligieron
sentación de conceptos del dominio, separación de 11 propiedades, de hecho se trata de principios de diseño
componentes en unidades verificables (“testeables”), OO en el sentido de elemento de conocimiento OO de
etc. (Garzás & Piattini, 2005); y se utilizaron 5 medidas aplica-
• La portabilidad parece a todas luces completamente das a clases para medir el grado de satisfacción de dichas
fuera del alcance de la etapa de diseño, como atributo propiedades. En (Bansiya & Davis, 2002), sin embargo, las
mensurable de calidad, dado que el diseño debe medidas se hacen tanto sobre atributos de clase, como mé-
mantenerse conceptualmente separado del entorno de todos y paquetes.
implementación final; aún no siendo ésto más que Para que se entienda de qué tipo de propiedades OO es-
una generalización muy discutible tampoco hemos tamos hablando exponemos una lista no exhaustiva pero lo
encontrado suficiente evidencia como para apoyar suficientemente ilustrativa:
que este atributo o característica es importante, desde 1) Tamaño del diseño
el punto de vista de la calidad, durante etapas 2) Jerarquías (de clases)
tempranas de diseño. Aún en el caso de que se 3) Abstracción
considere que un diseño ha de tener en cuenta el 4) Encapsulamiento
entorno final de ejecución todo lo más se puede 5) Acoplamiento
considerar como un requisito más y por tanto se 6) Cohesión
cumplirá o no, pero no se cumple “mejor o peor”. 7) Composición
Bansiya y Davis (2002) utilizan un conjunto de seis 8) Herencia
características o atributos mensurables de calidad de 9) Polimorfismo
diseño, cuatro de ellos tomados directamente de ISO 9126, 10) Comunicación inter clases (ing. “Messaging”)
otros dos adaptados con otro nombre y otros dos no se 11) Complejidad
encuentran en dicha norma y los toman de conceptos Como ya se ha sugerido, estas propiedades se miden en
generales de diseño software presentes en la literatura. components o entidades del diseño (veáse Fig. 1) que habrá
Hasta ahora hemos hablado de atributos de calidad ge- que definir. Purao y Vaishnavi (2003) revisan las métricas
nerales para el diseño software pero no hemos particulari- de producto de sistemas OO y proponen un modelo de tra-
zado para el diseño OO ni tampoco hemos hablado de có- bajo y un formalismo , de acuerdo al cual, el producto pasa
mo observar o medir los niveles en que se satisfacen dichos por distintos “estados” durante el proceso de desarrollo y
atributos, éstos son conceptos abstractos no observables en cada uno de ellos se producen o modifican distintos
directamente en el diseño, al menos no de una manera componentes que llaman “entidades”. Estos autores revisa-
cuantificable. Como observan Fenton y Pfleeger (1994) de- ron las familias de métricas presentes en la literatura con el
bemos encontrar propiedades del objeto de estudio, el dise- fin de recopilar el conjunto de entidades mensurables en
ño en este caso, directamente observables y mensurables y cada uno de esos estados; ofrecemos en la TABLA I aque-
que tengan una relación conocida con los atributos que pre- 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
Message passing coupling (MPC) MPC= número de métodos invocados en un clase. Acoplamiento/Comuni
cación
Data abstraction coupling (DAC) El número de atributos en una clase que tienen como tipo otra clase. Acoplamiento/Abstracc
ión
SIZE1 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 SIZE2 = número de atributos + número de métodos locales. Tamaño del diseño
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 Número medio de ancestros Abstracción
(ANA)
Data access Metric (DAM) Relación entre el número de atributos privados (protegidos) y el núme- Encapsulamiento
ro total de atributos de la clase.
Direct class coupling (DCC) 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.
Cohesion among methods of class Esta métrica calcula la relación entre métodos de una clase basándose Cohesión
(CAM) 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.
Measure of aggregation (MOA) 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.
Measure of functional abstraction Relación del número de métodos heredados por una clase y el número Herencia
(MFA) total de métodos accesibles por un método miembro.
Number of polymorphic methods Número de métodos que pueden mostrar comportamiento polimórfico Polimorfismo
(NPM) (virtual en C++ y no final en Java)
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
“ad hoc” y BibTeX y EndNote para la gestión bibliográfica. cubrir el máximo posible de publicaciones periódicas y ac-
tas de congresos relacionados con métricas, calidad de
3.2 Preguntas de la revision sistemática software, conocimiento OO y mantenimiento de software.
El objetivo primordial de esta revisión sistemática es dilu- Por tanto se eligieron dos portales agregadores de literatura
cidar qué métricas OO existen actualemente para medir la especializada y tres revistas específicas no incluidas en
calidad de un diseño previamente a su implementación, o ellas:
más bien, sin que se tengan que aplicar a él. Nos interesan • IEEE Digital Library
aquellas métricas que nos puedan servir para medir la cali- • ACM Digital Library
dad de los diseños independientemente de que hayan sido • Journal of Systems and Software, ed. Elsevier.
implementados o no, pero siempre con la idea de hacer una • Journal of Software Maintenance and Evolution, ed.
valoración exclusivamente en base al diseño. Nos interesa Wiley.
que la medición nos arroje resultados significativos en fun- • Software Practice and Experience, ed. Wiley.
ción de determinados atributos de calidad, en concreto, los Nuestra estrategia de búsqueda consistió en elaborar distin-
que establece la norma ISO 9126 o similares (extrapolables a tas consultas mediante expresiones booleanas formadas por
dicha norma). los siguientes términos (en inglés):
El objetivo futuro, a desarrollar en posteriores trabajos, • Object Oriented design
es el desarrollo de algún tipo de metodología o incluso • Metrics
herramienta que permita mejorar sistemáticamente los di- • Quality
seños hasta alcanzar un nivel preestablecido en función de • High level indicators
valores asignados a los atributos de calidad. Por tanto nos • Assessment
interesa saber también qué atributos o indicadores de cali- • Method
dad son los más utilizados en dichas métricas. • Patterns
Para acotar claramente nuestro campo de acción utiliza- • Heuristics
remos el término “diseño de micro-arquitectura” tal como • Bad smells
se entiende en el SWEBOK (Abran et al., 2004), que no lo • Principles
define explícitamente, pero sí diferencia entre patrones de • Rules
diseño micro y macro arquitectónicos. Por tanto nos referi- • Refactorings
remos a los objetos y las clases, su estructura y relación en- • Lessons learned
tre ellos pero no aspectos internos de sus métodos, más • Best practices
relacionados con la implementación. Algunos de los términos fueron desglosados en expresiones
Formulamos, pues, la cuestión inicial de investigación de booleanas de tipo “o” formadas por todos sus sinónimos, co-
la siguiente manera: mo por ejemplo “assess”, “assessing”, “evaluation” y “evalua-
Pregunta 1: ¿Existen métricas Orientadas a Objetos, basadas te”. Mediante la correcta manipulación de las leyes del algebra
únicamente en entidades de diseño, para la evaluación de calidad de Boole se consiguió una única expresión booleana con todos
mediante atributos internos de producto (tipo ISO 9126)? los términos y sus sinónimos, sin embargo, debido a la particu-
Por supuesto dichas métricas deben relacionarse cuanti- laridades sintácticas de cada buscador se tuvieron que hacer
tativamente con los atributos de calidad, bien directamente versiones para cada uno de ellos y, en algún caso, se tuvieron,
o bien mediante elementos intermedios como, por ejemplo, incluso, que eliminar términos para ampliar la búsqueda y
las propiedades OO. después eliminar manualmente estudios que no estaban rela-
La otra cuestión que nos importa puede formularse co- cionados con nuestro objetivo; esto fue así ya que en esos casos
mo: específicos la búsqueda inicial daba resultados muy escasos.
Pregunta 2: ¿Se miden las propiedades OO tradicionales (an- Siguiendo el procedimiento especificado por Kitchenham
tes mencionadas) o bien se utiliza nuevos elementos de conoci- se eliminaron repeticiones de estudios tanto de publicaciones
miento tales como los clasificados en (Garzás & Piattini, 2005)? en distintas búsquedas como de publicaciones distintas pero
Es importante, para posteriores trabajos, saber si elemen- que se referían al mismo trabajo de campo, siempre quedán-
tos tales como los patrones han sido aplicados a un diseño y donos con la más reciente.
cómo ésto ha impactado en el nivel medido de calidad. Si Tras los descartes por repetición quedaron 481 trabajosso-
las métricas fueran capaces de medir sobre la presencia de bre los cuales se realizó una primera revisión rápida sobre los
dichos elementos podríamos, en un futuro, llegar a crear resumenes y se descartaron todos aquellos que no se referían
una especie de “guía de aplicación de transformaciones de a métricas OO (en general). En una segunda revisión se des-
diseño” para la mejora del mismo. cartaron los trabajos de acuerdo a los criterios de exclusión.
Tanto en la primera como la segunda revisión se registraron
3.3 Método
en la base de datos las razones del descarte.
Todas las fuentes elegidas fueron digitales y se pretendía
JUAN JOSÉ OLMEDILLA ARREGUI.: REVISIÓN SISTEMÁTICA DE MÉTRICAS DE DISEÑO ORIENTADO A OBJETOS 9
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 Evidencia obtenida de estudios comparativos con control concurrente y
(grupo de voluntarios) 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.
481 23 458 4 9 2
Los trabajos no descartados, o “fuentes primarias”, fueron tudio en cuestión realmente se refiera a un método de eva-
registradas en la base de datos con un pequeño resumen y su luación o unas métricas aplicables a las entidades de dise-
nivel de calidad de acuerdo a los niveles que establecimos ño. Esto significa que el estudio habla de aplicar el método
(véase TABLA V) según el grado de experimentalidad. a documentos de diseño o diagramas UML (cualquiera de
Dado que todos los trabajos estaban por debajo del nivel 3, ellos) o bien se está aplicando al código pero se podría
decidimos no utilizar la calidad experimental como otro crite- hacer una extrapolación al diseño; esto último quiere decir
rio de exclusión y todos los trabajos que habían llegado hasta que las métricas aplicadas podrían, de alguna manera, cal-
este punto fueron tenidos en cuenta. cularse sólo con entidades de diseño, como por ejemplo las
distintas métricas de jerarquías o profundidad de herencia.
3.4 Criterios de exclusión En algún caso se ha marcado este valor com falso porque, si
El criterios de exclusión elegidos fueron: bien casi todas las métricas podrían hacerse sobre diseño, el
Criterio de Exclusión 1: El estudio no está centrado en mé- estudio lo hacía sobre código y además se incluía una mé-
tricas para la mejora del diseño, por ser demasiado generales in- trica imposible de aplicar a entidades de diseño como SI-
cluyendo, por ejemplo, mediciones de productividad o de asegu- ZE1 o LCOM.
ramiento de calidad. En la TABLA VI se puede observar el resumen del nú-
Criterio de Exclusión 2: El estudio no propone un modelo de mero de fuentes primarias, modelos completos, fuentes
evaluación con atributos de calidad como objetivo de las métricas. primarias cuyo método o métricas pueden aplicarse al di-
seño exclusivamente y el número de fuentes primarias que
3.5 Recogida y extracción de datos
son completas y de diseño exclusivamente.
Un objetivo indirecto del estudio es la recogida de los atri- En la TABLA VI podemos observar los atributos de cali-
butos de calidad usados como indicadores de calidad de dad que aparecen en los estudios primarios, con las deno-
diseño, así que se recogieron dichos atributos para todos los minaciones con que aparecen originalmente, en algún caso
estudios que pasaron los criterios de exclusión. Por cada hemos simplificado y lo hemos asimilado al nombre que
uno de los estudios se estableció un indicador booleano aparece en otros estudios y cuya semántica es la mimsa, sin
(Si/No) para registrar si el trabajo en cuestión proponía un embargo hemos mantenido todos los nombres originales
modelo de evaluación completo y cuantificado desde las aunque ello implica la aparición de sinónimos como anali-
métricas propuestas hasta los atributos de calidad, pasando zabilidad, inteligibilidad2 y comprensibilidad. Ha de tener-
(en su caso) a través de las propiedades OO elegidas. Aun- se en cuenta que en todo momento nos referimos a atribu-
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 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