Métricas de Diseño Orientado a Objetos

Pablo Damián Maiuto

Ingeniería de software III. Universidad Nacional de La Plata, Facultad de Informática

La Plata Provincia de Bs As, Argentina
pmaiuto@gmail.com

Resumen. En este trabajo se presenta un conjunto de

métricas orientadas a objetos, las cuales están centradas en la
medición de los diseños y no tanto en la medición del código u
otros productos del ciclo de vida. Estas métricas no están
enfocadas a la productividad sino a la calidad, tratan de
evaluar si ciertas propiedades deseables en el diseño
Orientado a Objetos se cumplen, propiedades tales como;
encapsulamiento, abstracción, cohesión, ocultamiento de la
información, herencia, polimorfismo. El trabajo realiza una
revisión de la literatura en torno al estado actual de las
métricas de diseño Orientadas a Objetos. Por último se
presenta conclusiones acerca de la utilidad de las métricas
presentadas y los aportes de las mismas al diseño orientado a
objetos.
INDICE

1. MARCO TEORICO

1.1 Conceptos sobre medición y métricas de software 1

1.2 Características de las métricas orientadas a objetos 2
1.3 Métricas orientadas a objetos 5

2. BIBLIOGRAFIA 6

2.1 Métricas MOOSE O CK 6

a) WMC (Weighted Methods per Class) 6

b) DIT (Depth of Inheritance Tree) 6
c) NOC (Number of Children) 6
d) CBO (Coupling Between Objects) 8
e) LCOM (Lack of Cohesion in Methods) 9
f) RFC (Response For a Class) 9

2.2 Métricas MOOD 11

2.2.1 Definición de métricas MOOD 11

a) MHF (Meted Hiding Factor) 11

b) AHF (Attribute Hiding Factor) 11
c) MIF (Method Inheritance Factor) 12
d) AIF (Attribute Inheritance Factor) 12
e) PF (Polymorphism Factor) 12

2.2.2 Calculo de métricas MOOD 12

2.3 Métricas de Lorenz y Kidd 16

2.3.1 Definición métricas de Lorenz y Kidd 16

A) Métricas de tamaño 16
1) PIM 16
2) NIM 16
3) NIV 16
4) NCM 16
5) NVV 16

B) Métricas de herencia 16
 1) NMO 16
2) NMI 17
3) NMA 17
4) SIX 17

C) Métricas de características internas de las clases 17

1) APPM 17
2) LOC 18
3) NOM 18

2.3.2 Calculo de las métricas de Lorenz y Kidd 18

2.4 Métricas de Genero et al. (2000) 19

2.4.1 Definición de las métricas de Genero et al (2000) 19

a) NAssoc 19
b) NAgg 19
c) NDep 19
d) NGen 19
e) NGenH 20
f) NAggH 20
g) MaxDIT 20
h) MaxHAgg 20

2.4.2 Cálculo de las métricas de Genero et al (200) 21

3. CONCLUCIONES 23

3.1 Conclusiones métricas MOOSE 23

3.2 Conclusiones métricas MOOD 24
3.4 Conclusiones métricas de Lorenz y Kidd 25
3.5 Conclusiones métricas de Genero et al. (2000) 26

4. REFERENCIAS 26
1. MARCO TEORICO

1.1 Conceptos sobre medición y métricas del software

Medir software no es una actividad sencilla. Se puede decir que toda magnitud
física se puede medir, pero el software es, sobre todo, el resultado de una actividad
básicamente intelectual, tanto en el origen como en el resultado final.

Aunque medida, medición y métrica son términos que suelen usarse de manera
intercambiable, es primordial observar claramente sus diferencias:

Medida: Se puede definir como el valor asignado a un atributo de una entidad

mediante una medición. Ejemplo podría ser 40.000 líneas de código.

Medición: La podemos definir como el acto de determinar una medida.

Métrica: Podemos definir a una métrica como una medida cuantitativa del grado
en que un sistema, componente o proceso posee un atributo dado. Incluye el método
de medición. Ejemplo, la productividad de un proyecto determinado fue de 800 líneas
(LDC/ persona-mes).

Las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para
desarrollar un producto, como el propio producto. El proceso para intentar mejorarlo
y el producto para intentar aumentar su calidad.

1
1.2 Características de las métricas orientadas a objetos

El software orientado a objetos tiene características fundamentalmente

distinguibles del software desarrollado con métodos convencionales. Por tal motivo,
las métricas para sistemas orientados a objetos deben ser afinadas a las características
que distinguen al software orientado a objetos del software convencional.

Se deben encontrar propiedades del objeto de estudio, el diseño orientado a objetos

en este caso, directamente observable y mensurable y que tengan una relación
conocida con los atributos que pretendemos convertir en nuestras métricas. En
muchos de los conjuntos de métricas orientadas a objetos publicados se utilizan
propiedades como cohesión, acoplamiento, encapsulamiento, complejidad y herencia
que, sin ser todas especificas del diseño orientado a objetos, son lo suficientemente
concretas y además se pueden relacionar matemáticamente con los atributos generales
de diseño.

A continuación se expone una lista no exhaustiva pero suficientemente ilustrativa

de las propiedades aplicables al diseño orientado a objetos:

Abstracción

La abstracción es un mecanismo que permite al diseñador concentrarse en los

detalles esenciales de un componente de programa. A medida que se mueve a niveles
más altos de abstracción, se ignoran más y mas detalles, es decir, se tiene una visión
más general de un concepto o elemento. A medida que se mueve a niveles de
abstracción más bajos, se introducen más detalles, es decir, se tiene una visión más
específica de un concepto o elemento.
Como una clase es una abstracción, que puede visualizarse a diferentes niveles de
detalle de diferentes maneras (por ejemplo, como una lista de operaciones, como una
secuencia de estados, como una serie de colaboraciones), las métricas Orientadas a
Objetos representan abstracciones en términos de mediciones de una clase, por
ejemplo, numero de instancias por clase por aplicación, numero o clases
parametrizables por aplicación.

Encapsulamiento

Para los sistemas orientados a objetos, el encapsulamiento engloba las

responsabilidades de una clase, incluyendo sus atributos (y otras clases para objetos
agregados) y operaciones, y los estados de la clase, definidos por valores de atributos
específicos.

2
 La encapsulación influye en las métricas, cambiando el enfoque de las mediciones
de un método simple, a un paquete de datos (atributos) y módulos de proceso
(operaciones).
Resumiendo, la encapsulación eleva la medición a un nivel de abstracción más
alto. Ejemplo métricas asociadas con el número de operaciones por clase. Contrasta
este nivel de abstracción con las métricas que se centran en contar condiciones
booleanas (complejidad ciclomàtica) o en contar líneas de código.

Ocultamiento de la información

Un sistema orientado a objetos bien diseñado debe implementar ocultamiento de la

información. Por esta razón, las métricas que proporcionan una indicación del grado
de ocultamiento de la información suministran un índice de calidad del diseño
orientado a objetos.

Herencia

La herencia es un mecanismo que habilita las responsabilidades de un objeto, para

propagarse a otros objetos. La herencia ocurre a través de todos los niveles de una
jerarquía de clases. En general el software convencional no cumple esta característica.
Ya que la herencia es una característica muy importante en muchos sistemas
orientados a objetos, muchos métodos orientados a objetos se centran en ella.
La herencia favorece la reutilización, por lo tanto las métricas deben indicar si el
sistema tiene un grado adecuado de jerarquías y niveles de herencia.

Cohesión

Como su correspondiente en el software convencional, un componente orientado a

objetos debe diseñarse de manera que posea todas las operaciones trabajando
conjuntamente para alcanzar un propósito único y bien definido. La cohesión de una
clase se determina examinando el grado en que “el conjunto de propiedades que posee
sea parte de un diseño o dominio del problema”.

Acoplamiento

Las conexiones físicas entre los elementos del diseño orientado a objetos, por
ejemplo el número de colaboraciones entre clases o el número de mensajes
intercambiados entre objetos, representan el acoplamiento dentro de un sistema
orientado a objetos.

3
Complejidad

Así como el tamaño, existen deferentes enfoques de la complejidad del software,

una posible definición es la siguiente, podemos definir a la complejidad en términos
de características estructurales, examinando como se interrelacionan las clases de un
diseño orientado a objetos con otras.

Tamaño del diseño

El tamaño se define en términos de cuatro enfoques: población, volumen, longitud

y funcionalidad. La población se mide haciendo un recuento de las entidades
orientadas a objetos, como las clases u operaciones. Las mediciones de volumen son
idénticas a las de población, pero se realizan dinámicamente, en un instante de tiempo
dado. La longitud es la medida de una cadena de elementos de diseño interconectados
(por ejemplo, la profundidad de un árbol de herencia es una medida de longitud). Las
métricas de funcionalidad proporcionan una indicación indirecta del valor entregado
al cliente por una aplicación orientada a objetos.

Polimorfismo
El polimorfismo se refiere a la posibilidad de enviar un mensaje a un grupo de
objetos cuya naturaleza puede ser heterogénea. El único requisito que deben cumplir
los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se
les envía.

Composición

La composición se refiere a la combinación de clase.

Comunicación

Conjunto de mensajes a los que el objeto debe responder.

4
1.3 Métricas Orientadas a Objetos
Aunque las métricas clásicas usadas para medir software tradicional pueden ser
usadas para medir sistemas orientados a objetos (por ejemplo, el número de líneas de
un programa escrito en Java), como el software desarrollado siguiendo el paradigma
orientado a objetos difiere del desarrollado siguiendo enfoques tradicionales se
necesita utilizar métricas adaptadas a las características particulares de este paradigma
de las cuales se presentan a continuación las propuestas más significativas.

Métricas de MOOSE (también conocidas como métricas CK (Chidamber y

Kemerer))
Fueron propuestas por Chidamber y Kemerer y son las más difundidas en
orientación a objetos.

Métricas MOOD
Este conjunto de métricas fue propuesto por Brito e Abreu y Carapuca (1994) y su
objetivo es medir los principales mecanismos del paradigma orientado a objetos.

Métricas de Lorenz y Kidd

Lorenz y Kidd (1994) propusieron un conjunto de métricas, que se refieren a un
conjunto de características estáticas del diseño de un producto de software.

Estas meticas consideran distintos niveles de granularidad, algunas consideran al

sistema en su totalidad, otras se enfocan en las clases y otras en los métodos.

Dado que el diagrama de clases es el más utilizado, las propuestas de métricas que
se podrían adaptar son alguna de las mencionadas con anterioridad, (Chidamber y
Kemerer), (métricas de Brito e Abreu y Carapuca (1994)), (Lorenz y Kidd (1994)).
Una propuesta de métrica definida específicamente para diagramas de clase UML y
que ha sido validada empíricamente es la siguiente:

Métricas de Genero
Genero et al. (2000) propusieron un conjunto de métricas para medir la
complejidad estructural de los modelos de clases.

5
2. Bibliografía
2.1 Métricas MOOSE O CK

Propuestas por Chidamber y Kemerer (1994). Son las más difundidas a nivel de
orientación a objetos. De hecho existen numerosos trabajos empíricos sobre la
relación de estas métricas y por ejemplo, la propensión a errores, o la mantenibilidad
de las clases, está compuesto por las siguientes seis métricas:

a) WMC (Métodos ponderados por clase) (Weighted Methods per Class)

Mide la complejidad de una clase. Si todos los métodos son igualmente complejos,
entonces WMC es igual al número de métodos definidos en una clase. Sea la clase Ci
que tiene los métodos M1,….,Mn siendo su complejidad respectiva c1,…..,cn es posible
definir la formula:

WMC =

b) DIT (Profundidad del Árbol de Herencia de una Clase) (Depth of Inheritance

Tree)

La métrica DIT mide el máximo nivel en la jerarquía de herencia. Se trata de la

cuenta directa de los niveles de la jerarquía de herencia, considerando que en el nivel
cero de la jerarquía se encuentra la clase raíz. DIT se considera como una métrica del
número de clases antecesoras que una clase podría potencialmente afectar, debido a
que cuanto mayor sea el nivel de profundidad de herencia de una clase mayor es el
número de métodos y atributos que hereda de otras clases.

c) NOC (Número de Hijos) (Number of Children)

NOC, es el número de subclases subordinadas a una clase en la jerarquía, es decir,

la cantidad de subclases que pertenecen a una clase. Según Chidamber y Kemerer
(1994), NOC es un indicador del nivel de reutilización, de la posibilidad de haber
creado abstracciones erróneas, y del nivel de pruebas requerido.

6
 Persona

nombre: String
dni: String
dirección: String
teléfono: String

getNombre(): String
getDni(): String
getDireccion(): String
getTelefono(): String
setNombre(nombre: String)
setDni(dni: String)
setDereccion(direccion: String)
setTelefono(telefono: String)

Cliente Empleado
codigoCliente: String numeroEmpleado: String
numeroSegSocial: Sting
getCodigoCliente(): String sueldo: String
setCodigoCliente(código: String)
altaCliente(dni: String) getNumeroSS(): String
bajaCliente(dni: String) setNumeroSS(numeroSS: String)
getFechaCom(): Date
setFechaCom(fecha: Date)
altaEmpleado(dni: String)
bajaEmpleado(dni: String)
setSueldo(base: double)

EmpleadoFijo EmpleadoTemporal

sueldoEmpFijo sueldoEmpTemp

setSueldo(base: double) setSueldo(base: double)

Figura 1. Diagrama de clases

7
 Considerando el diagrama de la Figura 1, considerando que todos los métodos
tienen complejidad 1, entonces podemos calcular:
WMC(Persona)= 8,
WMC(Cliente)= 4, no considerando los métodos heredados.
WMC(Empleado)= 10, no considerando los métodos heredados.

Como ejemplo de cálculo de las métricas DIT Y NOC, también considerando el

diagrama de la Figura 1, podemos decir acerca de la métrica DIT:
DIT(Persona)= 0, (clase Persona es la clase raíz o nivel 0).
DIT(Cliente)=1
DIT(Empleado)=1
DIT(EmpleadoFijo)=2
DIT(EmpleadoTemporal)=2

Para el caso de la métrica NOC:

NOC(Persona)= 2
NOC(Cliente)=0
NOC(Empleado)=2

d) CBO (Acoplamiento entre Objetos) (Coupling Between Objects)

La métrica CBO, indica para una clase el número de otras clases con las que está
acoplada. Se considera que un objeto esta acoplado a otro cuando actúa sobre este
otro objeto, por ejemplo cuando un método de un objeto utiliza un método de otro
objeto. Esta métrica se considera útil para predecir el esfuerzo necesario para el
mantenimiento y las pruebas. Para mostrar el cálculo de la métrica considérese este
ejemplo:

CuentaSueldo tiene Empleado

numeroCuenta: Sting codigoEmpleado: string
saldo: number
* 1

asociada

TarjetaCredito

numeroTarjeta: string

El acoplamiento entre objetos para cada clase seria:

CBO(CuentaSueldo)= 0
CBO(TarjetaCredito)= 1 (Usa métodos de la clase CuentaSueldo)
CBO(Empleado)= 1 (Usa métodos de la clase CuentaSueldo).

8
e) RFC (Respuesta de una Clase) (Response For a Class)

RFC indica el número de métodos que pueden ser ejecutados potencialmente como
respuesta a un mensaje recibido por un objeto de esa clase. RFC por lo tanto se
calcula contando las ocurrencias de llamadas a otras clases de una clase en particular.
La fórmula para calcular esta métrica es la siguiente:
RFC =|RS|, donde RS es el conjunto respuesta para la clase. El conjunto respuesta
para la clase se puede expresar de la siguiente manera:
RS= {M} Ui {Ri}, donde {Ri}es el conjunto de métodos llamados por el método i y
{M} es el conjunto de todos los métodos de la clase.

Para una mejor comprensión del modo de cálculo de RFC considérese un sistema
formado por tres clases A, B y C. La clase A tiene 4 métodos f1,f2,f3,f4, la clase B
tiene 4 métodos f1,f2,f3,f4y la clase C tiene 5 métodos f1,f2,f3,f4,f5.
Las invocaciones de los métodos de A son las que figuran en el siguiente esquema:

Clase A con 4 métodos:

A:: f1() invoca B:: f1(), B:: f2() y C:: f3()
A:: f2() invoca B:: f1()
A:: f3() invoca A:: f4(), B:: f3(), C:: f1() y C:: f2()
A:: f4() no llama a otros métodos

Entonces
RS = { A:: f1, A:: f2, A:: f3, A:: f4}U { B:: f1, B:: f2, C:: f3}U{ B:: f1}
U{ A:: f4, B:: f3, C:: f1, C:: f2}
----------------------------------------------------------------------------------------
= { A:: f1, A:: f2, A:: f3, A:: f4, B:: f1, B:: f2, B:: f3, C:: f1, C:: f2, C:: f3}

Resultando RFC(A)= 10

Se calculo la métrica RFC para la clase A, la cual tiene 4 métodos locales y llama
desde esos métodos a 6 métodos remotos (B:: f1, B:: f2, B:: f3, C:: f1, C:: f2, C:: f3).
La métrica RFC (Respuesta para una clase) se considera por tanto como la suma de
los métodos locales a una clase, mas los métodos remotos (métodos invocados de
otras clases desde los métodos locales a la clase).

f) LCOM (Falta de Cohesión en los Métodos) (Lack of Cohesion in Methods)

LCOM establece en qué medida los métodos hacen referencia a los atributos. Se
calcula como el número de pares de funciones sin variables compartidas de instancia
menos el número de pares de funciones con variables de instancia compartidas.
LCOM es una métrica de la cohesión de una clase en base al número de atributos
comunes usados por diferentes métodos. Un valor alto en LCOM implica falta de
cohesión, es decir, escasa similitud entre los métodos siendo siempre deseable un alto
grado de cohesión en los métodos de una clase.

9
 Mediante la figura 2 vamos a mostrar el cálculo de LCOM, donde los óvalos
representan los métodos de una clase y los puntos representan los atributos de la clase.
Un punto estará dentro de un ovalo perteneciente a un método, si en el mismo se hace
referencia al atributo representado por el punto.

Caso 1: LCOM = 2 – 1 = 1

Caso 2: LCOM = 4 – 2 = 2

Fig. 2. Diagrama de ejemplo para el cálculo de LCOM Y LCOM*

En la figura 3, se ve como LCOM se incrementa según se va incrementando el

número de eslabones en la cadena. Esto no es deseable ya que LCOM mide la
cohesión y no debe depender del número de métodos en la cadena, sino de en qué
medida los métodos afectan a los atributos de la clase.

10
 Figura 3. Incremento de LCOM

En el ejemplo de la figura 3 con 3 métodos en la cadena LCOM = 0. En cambio

con 5 métodos en la cadena LCOM= 2. Debido a estos problemas Henderson-Sellers
(1996) propone LCOM* como medida de cohesión, que se calcula mediante la
fórmula siguiente, siendo: M(Ai) = número de métodos que accede al atributo i; m =
numero de métodos de la clase.

LCOM*= PROMEDIO (M(Ai)) - | m | / | 1 – m |

En el caso 1 de la figura 2, el cálculo de esta métrica seria: i=6 (numero de

atributos), m=3 (numero de métodos), M(A1)= M(A2)= M(A3)= M(A4)=
M(A6)=1, M(A5)=2,entonces,
LCOM*= [1/6 * (1+1+1+1+2+1)] – 3 / (1/3), siendo LCOM*=0,916.

2.2 Métricas MOOD

2.2.1 Definición de métricas MOOD

El principal objetivo de este conjunto de métricas es medir los principales

mecanismos del paradigma orientado a objetos, tales como encapsulación, herencia,
polimorfismo y pasaje de mensajes, así como la calidad en el software y la
productividad en el desarrollo. Las métricas MOOD se pueden utilizar en las fases de
diseño y se definieron para ser aplicadas a nivel de diagrama de clases.

a) MHF (Factor de Ocultamiento de los Métodos) (Method Hiding Factor)

MHF mide la proporción entre los métodos definidos como protegidos o privados y
le número total de métodos. MHF se propone como una medida de encapsulación,
cantidad relativa de información oculta.

b) AHF (Factor de Ocultamiento de los Atributos) (Attribute Hiding Factor)

El factor de ocultamiento de los atributos se define como el cociente entre la suma

de las invisibilidades de todos los atributos definidos en todas las clases y el número
total de atributos definidos en el sistema considerado. La invisibilidad de un atributo

11
es el porcentaje del total de clases desde las cuales los atributos son invisibles.AHF se
definió como una medida de encapsulación.

c) MIF (Factor de Herencia de los Métodos) (Method Inheritance Factor)

El factor de herencia de los métodos se define como el cociente entre la suma de

los métodos heredados en todas las clases del sistema considerado y el número total
de métodos existentes, tanto los definidos localmente como los heredados, en todas
las clases. MIF se define como una medida de herencia, y por lo tanto como una
medida del nivel de reutilización.

d) AIF (Factor de Herencia de los Atributos) (Attribute Inheritance Factor)

El factor de herencia de los atributos se define como el cociente entre la suma de

los atributos heredados en todas las clases del sistema considerado y el número total
de atributos existentes, tanto los definidos localmente como los heredados, en todas
las clases. Al igual que MIF, AIF se considera como un medio para expresa la
capacidad de reutilización de un sistema.

e) PF (Factor de Polimorfismo) (Polymorphism Factor)

El factor de polimorfismo se define como el cociente entre el número actual de

posibles diferentes situaciones de polimorfismo, y el número máximo de posibles
situaciones distintas de polimorfismo para la clase Ci. PF es una medida del
polimorfismo y una medida indirecta de la asociación dinámica en un sistema.

2.2.2 Cálculo de métricas MOOD

Ilustramos el cálculo de las métricas MOOD con el siguiente código escrito en

C++:

Class FormaGeometrica{
Protected:
Double posicionX;
Double posicionY;
Void Dibujar ();
Public:
Void Cortar ();
Void Borrar ();
Void Mover (double DesplazX, double DesplazY);
Void Desagrupar ();
Virtual void Posicionar (double posX, double posY); // constr
Virtual void Escribir (int color); // llama a dibujar
Virtual double Area ();
}

12
Class cuadro: public FormaGeometrica{
Protected:
Double anchura;
Double altura;
Double DameAnchura ();
Double DameAltura ();
Public:
Void EstablecerDimensiones (double altura, double anchura);
Void Posicionar (double posX, double posY);
Void Escribir (int color);
Double Area ();
}

Class circulo: public FormaGeometrica{

Protected:
Double radio;
Public:
Void EstablecerRadio (double radio);
Void Posicionar (double posX, double posY);
Void Escribir (int color);
Double Area ();
}

Cálculo de la métrica MHF

Clase MO MV MD
FormaGeometrica 1 7 8
Cuadrado 2 4 6
Circulo 0 4 4
MO= métodos protegidos
MO: FormaGeometrica = 1(Dibujar); Cuadro= 2 (DameAnchura, DameAltura);
Circulo= 0.
MV = métodos visibles
MV: FormaGeometrica = 7 (Cortar, Borrar, Mover, Desagrupar, Posicionar,
Escribir, Area);
Cuadro = 4 (EstablecerDimensiones, Posicionar, Escribir, Area);
Circulo = 4 (EstablecerRadio, Posicionar, Escribir, Area).

MD= MO + MV = (1 + 2 )+(7 + 4 + 4) = 18

13
 MHF = 3 / 18 = 0,166666…

Cálculo de la métrica AHF

Clase MO MV MD
FormaGeometrica 2 0 2
Cuadrado 2 0 2
Circulo 1 0 1

AO = Atributos protegidos
MO: FormaGeometrica = 2 (PosicionX, PosicionY); Cuadro= 2 (Anchura,
Altura); Circulo= 1(Radio).

AV = Atributos visibles
AV: FormaGeometrica = 0 ; Cuadro = 0; Circulo = 0

AD= AO + AV = (2+ 2 + 1) + (0) = 5

MHF = 5 / 5 = 1

Cálculo de la métrica MIF

Clase MN MO MI MD MA
FormaGeometrica 8 0 0 8 8
Cuadrado 3 3 5 6 11
Circulo 1 3 5 4 9

MN = Métodos nuevos
MN: FormaGeometrica = 8 (Todos los métodos)
Cuadro = 3 (DameAnchura, DameAltura, EstablecerDimensiones)
Circulo = 1 (EstablecerRadio)

MO = Métodos redefinidos
MO: FormaGeometrica = 0
Cuadro = 3 (Posicionar, Escribir, Area)
Circulo = 3 (Posicionar, Escribir, Area)

MI = Métodos heredados
MI: FormaGeometrica = 0
Cuadro = 5 (Cortar, Borrar, Mover, Desagrupar, Dibujar)
Circulo = 5 (Cortar, Borrar, Mover, Desagrupar, Dibujar)

14
MD =MN + MO = (8 + 3 + 1) + (0 + 3 + 3) = 18

MA= MD + MI = = (18) + (10) = 28

MIF = 10 / 28 = 1
Calculo de la métrica AIF

Clase AN AO AI AD AA
FormaGeometrica 2 0 0 2 2
Cuadrado 2 0 2 2 4
Circulo 1 0 2 1 3

AN = Atributos nuevos
AN: FormaGeometrica = 2 (PosicionX, PosicionY)
Cuadro = 2 (Altura, Anchura)
Circulo = 1 (Radio)

AO = Atributos redefinidos
AO: FormaGeometrica = 0; Cuadro = 0; Circulo = 0

AI = Atributos heredados
AI: FormaGeometrica = 0
Cuadro = 2 (PosicionX, PosicionY)
Circulo = 2 (PosicionX, PosicionY)

AD =AN + AO = (2 + 2 + 1) + (0) = 5

AA= AD + AI = = (5) + (4) = 9

AIF = 4/ 9 = 0,444444….

Cálculo de la métrica PF

Clase MO MN DC
FormaGeometrica 0 8 2
Cuadrado 3 3 0
Circulo 3 1 0

DC: FormaGeometrica =2 (Cuadrado, Circulo)

Cuadro = 0
Circulo = 0

Número actual de situaciones de polimorfismo = 3 + 3 = 6

Número máximo de posibles situaciones distintas de polimorfismo = 8 * 2 =16

PF = 6/ 16 = 0,375

15
2.3 Métricas de Lorenz y Kidd

2.3.1 Definición de las métricas de Lorenz y Kidd

Lorenz y Kidd clasificaron a las métricas propuestas en: métricas de tamaño,

métricas de herencia y métricas de características internas de las clases.

A - Métricas de tamaño

a) PIM

El Número de Métodos de Instancia Públicos de una clase es el número total de

métodos públicos de instancia. Los métodos públicos son aquellos que están
disponibles como servicios para otras clases.

b) NIM

El Número de Métodos de Instancia es la suma de todos los métodos de una clase,

considerando tanto los métodos públicos como los protegidos y los privados.

c) NIV

El Número de Variables de Instancia es el número total de variables a nivel de

instancia que tiene una clase, considerando las variables privadas y protegidas
disponibles en una clase.

d) NCM

El Número de Métodos de Clase es el número total de métodos a nivel de clase,

por ejemplo, aquellos métodos que son globales a todas las instancias que tiene una
clase.

e) NVV

El Número de Variables de Clase es el número total de variables a nivel de clase

que tiene una clase.

B – Métricas de herencia

a) NMO

El Número de Métodos Sobrecargados es el número total de métodos

sobrecargados por una clase.

16
b) NMI

El Número de Métodos Heredados es el número total de métodos que una clase

hereda.

c) NMA

El Número de Métodos Añadidos es el número total de métodos que se definen en

una subclase. Esta métrica se definió para medir la calidad del uso de herencia, ya que
examina la relación de herencia entre subclase y superclase.

d) SIX

El índice de especialización para cada clase se define de esta forma:

NumeroDeMetodosSobrecargados * NivelDeAnidamientoEnLaJerarquia

NumeroTotalDeMetodos

Esta métrica mide hasta qué punto una subclase redefine el comportamiento de una
superclase.

C – Métricas de características internas de las clases

a) APPM

El Promedio de Parámetros por Método se define de esta forma:

NumeroTotalDeParametrosPorMetodo

NumeroTotalDeMetodos

17
b) LOC

Líneas de Código por Método. Es el número de líneas ejecutables en un método.

El tamaño de un método es usado para evaluar la comprensibilidad, reusabilidad y
mantenibilidad del código.

c) NOM

Número de Mensajes enviados en un Método. NOM mide el número de mensajes

enviados por un método, segregados por el tipo de mensaje. Los tipos de mensaje
incluyen:

 Unarios, mensajes sin argumento

 Binarios, mensajes con un argumento que pertenecen a tipos especiales (por
ejemplo concatenación y funciones matemáticas).
 Clave, mensajes con uno o más argumentos.

2.3.2 Cálculo de las métricas de Lorenz y Kidd

Un ejemplo de la aplicación de las métricas de Lorenz y Kidd es el siguiente:

Consideremos el diagrama de clases de la figura 1, entonces el valor de las

métricas de Lorenz y Kidd seria:

 PIM(Persona)= 8 (todos los métodos de la clase son de visibilidad publica).

 NIM(Persona)=8

 NIV(Persona)= 4 (todos los atributos de la clase son a nivel de instancia de

visibilidad privada).

 NCM(Persona) = 0 (la clase Persona no tiene ningún método estático o a

nivel de clase).

 NVV(Persona) = 0 (la clase Persona no tiene ningún atributo estático o a

nivel de clase).

 NMO(EmpleadoFijo) = 1(redefine el método setSueldo).

18
  NMO(EmpleadoTemporal) = 1(redefine el método setSueldo).

 NMI(Cliente) = 8.

 NMA(Cliente) = 4.

 SIX(EmpleadoFijo) = 1 (método sobrescrito) * 2/16 (total de métodos) .

 APPM(Persona) = 4/8 = 0.5.

2.4. Métricas de Genero et al. (2000)

2.4.1 Definicion de las métricas de Genero et al. (2000)

Propusieron un conjunto de métricas para medir la complejidad estructural de los

modelos de clases debido al uso de relaciones UML que se muestran en la definición
de las métricas presentadas a continuación.

a) NAssoc

La métrica Número de Asociaciones se define como el número total de

asociaciones dentro de un modelo de clases.

b) NAgg

La métrica Número de Agregaciones se define como el número total de relaciones

de agregación dentro de un modelo de clases (cada par todo-parte en una relación de
agregación).

c) NDep

La métrica Número de Dependencias se define como el número total de relaciones

de dependencia dentro de un modelo de clases.

d) NGen

La métrica Número de Generalizaciones se define como el número total de

relaciones de generalización dentro de un modelo de clases (cada par padre-hijo en
una relación de generalización).

19
e) NGenH

La métrica Número de Jerarquías de Generalización se define como el número total

de jerarquías de generalización dentro de un modelo de clases.

f) NAggH

La métrica Número de Jerarquías de Agregación se define como el número total de

jerarquías de agregación dentro de un modelo de clases.

g) MaxDIT

La métrica Máximo DIT se define como el máximo entre los valores DIT
obtenidos de cada clase del modelo de clases. El valor de DIT para una clase dentro
de una jerarquía de generalización es la longitud de la ruta más larga partiendo de la
clase raíz de la jerarquía.

h) MaxHAgg

La métrica Máximo HAgg se define como el máximo de los valores HAgg

obtenidos de cada clase del modelo de clases. El valor HAgg para una clase dentro de
la jerarquía de agregación es la longitud de la ruta más larga desde la clase hasta las
hojas.

20
2.4.2 Cálculo de las métricas de Genero et al (2000)

A continuación se muestra un ejemplo para el cálculo de estas métricas.

Existencia Línea de Pedido 0...* 1 Pedido

1 0...*
0...*
Especificación Existencia 0...* Catalogo

1
Cliente

0...*
Nacional Importado Servicio

Empresa Personal

0...*
Tipo I Tipo II

Empleado

Figura. 4. Diagrama de clases utilizado para calcular las métricas de Genero et al.
(2000)

Notación:
Clase

Clase Asociación Generalización Dependencia Agregación

21
NAssoc = 4

Asociaciones = (Pedido-Cliente); (Pedido-Línea de pedido); (Línea de pedido-

Producto); (Cliente de la Empresa-Empleado).

NAgg = 3

Agregaciones = 3 (Catalogo-Producto); (Catalogo-Servicio); (Producto-

Especificación).

NDep = 1

Dependencias = 1 (Existencia-Línea de Producto);

NGen = 6

Generalizaciones = (Cliene-Empresa); (Cliente-Personal); (Producot-Nacional);

(Producto-Importado); (Nacional-Tipo I); (Nacional- Tipo II).

NAggH = 1

Existe una única jerarquía de agregación que tiene como parte “todo” la clase
Catálogo.

NGneH = 2

Existen dos jerarquías de generalización, una cuya clase raíz es Cliente y la otra
Producto.

MaxHAgg = 2

HAgg(Especificacion) = 0; HAgg(Producto) = 1; HAgg(Catalogo) = 2;

HAgg(Servicio) = 0. El valor máximo de la métrica HAgg es 2.

MaxDIT = 2

DIT(Tipo II) = 2; DIT(Tipo I) = 2; DIT(Nacional) = 1; DIT(Producto) = 0;

DIT(Importado) = 1; DIT(Empresa) = 1; DIT(Personal) = 1; DIT(Cliente) = 0. El
valor máximo de la métrica DIT es 2.

22
3. Conclusiones

3.1 Conclusiones sobre las Métricas de MOOSE

a) WMC (Métodos ponderados por clase) (Weighted Methods per Class)

Clases con un gran número de métodos requieren más tiempo y esfuerzo para
desarrollarlas y mantenerlas, ya que influirán en las subclases heredando todos sus
métodos. Además, estas clases tienden a ser específicas de la aplicación, limitando su
posibilidad de reusó.
En WMC se aprecian los siguientes problemas [Harrison et al. 1996]:
 WMC mide presuntamente la complejidad, pero no da ninguna definición de
complejidad.
 WMC no puede verse como un indicador de esfuerzo necesario para
desarrollar una clase, ya que es fácil imaginar clases con pocos métodos
complicados y clases con un gran número de métodos pero muy simples.
Por lo tanto, esta métrica debería de ser considerada simplemente como una
medida del tamaño de una clase.

b) DIT (Profundidad del Árbol de Herencia de una Clase) (Depth of Inheritance

Tree)

El uso de la herencia es visto como un compromiso ya que:

Altos niveles de herencia indican objetos complejos, los cuales son difíciles de
testear y reusar.
Bajos niveles en la herencia pueden indicar que el código está escrito en un estilo
funcional sin aprovechar el mecanismo de herencia proporcionado por la orientación a
objetos.
Los problemas con esta métrica se deben a las diferentes características de la
herencia, ya que DIT no queda claramente definida y no puede verse como una
medida de reusó. Puede imaginarse clases con gran profundidad en la jerarquía
reusando menos métodos que en una clase poco profunda pero muy ancha.

c) NOC (Numero de Hijos) (Number of Children)

Aunque un mayor número de hijos representa una mayor reutilización de código,

presenta los siguientes inconvenientes:
 Mayor probabilidad de usar incorrectamente la herencia creando
abstracciones erróneas.

23
  Mayor dificultad para modificar una clase ya que afecta a todos los hijos que
tienen dependencia con la clase.
 Se requieren mayor número de recursos para testear.

Es un potencial indicador de la influencia que una clase puede tener sobre el diseño
del sistema. Si el diseño tiene una alta dependencia en la reusabilidad a través de la
herencia, puede ser mejor dividir la funcionalidad en varias clases.

d) CBO (Acoplamiento entre Objetos) (Coupling Between Objects)

Cuanto más acoplamiento se da en una clase, más difícil será reutilizarla. Además,
las clases con excesivo acoplamiento dificultan la complejidad y hacen más difícil el
mantenimiento por lo que será necesario un mayor esfuerzo y riguroso testeo.
Las clases deberían ser lo más independientes posible, y aunque siempre es
necesaria una dependencia entre clases, cuando está es grande, la reutilización puede
ser más cara que la reescritura. Al reducir el acoplamiento se reduce la complejidad,
se mejora la modularidad y se promueve la encapsulación.

e) RFC (Respuesta de una Clase) (Response For a Class)

RFC es un indicador de los recursos necesarios para testeo y depuración. Cuanto

mayor es RFC, mas complejidad tiene el sistema ya que se puede invocar un mayor
número de métodos como respuesta a un mensaje.

f) LCOM (Falta de Cohesión en los Métodos) (Lack of Cohesion in Methods)

Un valor alto de LCOM implica falta de cohesión, es decir, escasa similitud de los
métodos. Esto puede indicar que la clase está compuesta de elementos no
relacionados, incrementando la complejidad y la probabilidad de errores durante el
desarrollo. Es deseable una alta cohesión en los métodos dentro de una clase ya que
está no puede ser dividida fomentando la encapsulación.

3.2 Conclusiones métricas MOOD

 Cuando el valor de MFH aumenta, la densidad de defectos y el esfuerzo

requerido para corregirlos tendrían que disminuir.

 Cuando el valor de MIF aumenta, la densidad de defectos y el esfuerzo

requerido para corregirlos tendrían que disminuir.

24
  Idealmente, el valor de la métrica AHF seria 100%, por ejemplo todos los
atributos estarían ocultos sólo podrían ser accedidos desde los métodos de
las clases correspondientes.

 A primera vista podría resultar tentador pensar que la herencia debería ser
usada extensivamente. Sin embargo, la excesiva reusabilidad a través de
la herencia hace a los sistemas difíciles de comprender y mantener.
 En relación con la métrica PF, en algunos casos los métodos redefinidos
pueden contribuir a reducir la complejidad e incluso a hacer el sistema
más comprensible y fácil de mantener.

3.3 Conclusiones sobre las métricas propuestas por Lorenz y Kidd

 Una jerarquía poco profunda o demasiado profunda tiene repercusión directa

sobre la calidad del sistema.

 Ningún método de instancias o muchos métodos de instancias pueden indicar

una distribución de responsabilidades poco óptima (en relación con la
métrica NIM).

 Un gran número de variables de instancia puede indicar demasiado

acoplamiento con otras clases, lo que reduce la reutilización (en relación
con la métrica NIV).

 El promedio de variables de clases debería ser bajo. En general debe haber

menos variables de clase que variables de instancia.

 Demasiados métodos a nivel de clase pueden indicar el uso inapropiado de

las clases para hacer el trabajo en lugar de instancias (en relación con la
métrica NCM).

 Métodos sobrecargados, especialmente en niveles muy profundos de la

jerarquía de herencia, pueden indicar un diseño pobre de la jerarquía (en
relación con la métrica NMO).

 El índice de Especialización puede ser muy útil para identificar clases

teniendo en cuenta su ubicación dentro de la jerarquía y aquellos que
pueden traer problemas en el diseño.

25
3.4 Conclusiones sobre las métricas de Genero et al. (2000)

Estas métricas propuestas para diagramas de clases fueron validadas teóricamente

y se concluyo que las mismas miden complejidad. También se concluyó que las
métricas miden los atributos que pretendían medir.

Se realizaron varios experimentos controlados para validar empíricamente estas

métricas para diagramas de clases. Las métricas que parecen estar más relacionadas
con el tiempo que los modeladores tardan en entender y modificar los diagramas de
clases son aquellos que tienen que ver con las asociaciones y las generalizaciones.

Los autores de esta propuesta señalaron que para obtener resultados definitivos es
necesario replicar los experimentos realizados, así como constatar si las métricas son
validas utilizando diagramas de clases obtenidos en proyectos reales.

4. Referencias

Ingeniería del Software, Un Enfoque Practico, 6º edición Roger

Pressman.

Mario Piattini Velthuis, Felix Oscar Garcia Rubio, Javier Garzas

Parra, Marcela Bocco. Medición y Estimación del Software.
Técnicas y métodos para mejorar la calidad y la productividad.

Ian Sommerville. Ingeniería de Software 7º edición.

Marcela Genero, Mario Piattini, Coral Calero. Early measures for

UML class diagrams.

José Antonio Cruz-Lemus, Luis Reynoso, Mario Piattini Velthuis,

Marcela Genero. Métricas para Modelos UML. Novatica nº 170
2004.

Calero Coral, Genero Marcela, Piattini Velthuis Mario. Metrics for

Software Conceptual Models. Imperial College Press, 2005.

26