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
[email protected] [email protected]
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 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.2 Características de las métricas orientadas a objetos 1.3 Métricas orientadas a objetos
2. BIBLIOGRAFIA 2.1 Métricas MOOSE O CK
a) WMC (Weighted Methods per Class) b) DIT (Depth of Inheritance Tree) c) NOC (Number of Children) d) CBO (Coupling Between Objects) e) LCOM (Lack of Cohesion in Methods) f) RFC (Response For a Class)
2.2 Métricas MOOD 2.2.1 Definición de métricas MOOD a) b) c) d) e)
MHF (Meted Hiding Factor) AHF (Attribute Hiding Factor) MIF (Method Inheritance Factor) AIF (Attribute Inheritance Factor) PF (Polymorphism Factor)
2.2.2 Calculo de métricas MOOD 2.3 Métricas de Lorenz y Kidd 2.3.1 Definición métricas de Lorenz y Kidd A) Métricas de tamaño 1) 2) 3) 4) 5)
PIM NIM NIV NCM NVV
B) Métricas de herencia
1 2 5 6 6 6 6 6 8 9 9
11 11 11 11 12 12 12 12
16 16 16 16 16 16 16 16
16
1) NMO 2) NMI 3) NMA 4) SIX
C) Métricas de características internas de las clases 1) APPM 2) LOC 3) NOM
16 17 17 17 17 17 18 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) a) b) c) d) e) f) g) h)
NAssoc NAgg NDep NGen NGenH NAggH MaxDIT MaxHAgg
19 19 19 19 19 20 20 20 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 3.2 Conclusiones métricas MOOD 3.4 Conclusiones métricas de Lorenz y Kidd 3.5 Conclusiones métricas de Genero et al. (2000)
4. REFERENCIAS REFERENCIAS
23 24 25 26 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 C i que tiene los métodos M 1,….,Mn siendo su complejidad respectiva c 1,…..,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 codigoCliente: String
Empleado numeroEmpleado: String numeroSegSocial: Sting sueldo: String
getCodigoCliente(): String setCodigoCliente(código: String) altaCliente(dni: String) bajaCliente(dni: String)
getNumeroSS(): 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 numeroCuenta: Sting saldo: number
Empleado codigoEmpleado: string
tiene 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 {R i}, donde {R i}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 f iguran 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 M ethods) 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 r epresentan 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 C i. 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 FormaGeometrica Cuadrado Circulo
MO 2 2 1
MV 0 0 0
MD 2 2 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 FormaGeometrica Cuadrado Circulo
M N 8 3 1
MO 0 3 3
MI 0 5 5
MD 8 6 4
MA 8 11 9
M N = Métodos nuevos M N: 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 =M N + 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 FormaGeometrica Cuadrado Circulo
A N 2 2 1
AO 0 0 0
AI 0 2 2
AD 2 2 1
AA 2 4 3
A N = Atributos nuevos A N: 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 =A N + 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 FormaGeometrica Cuadrado Circulo
MO 0 3 3
M N 8 3 1
DC 2 0 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 priva dos.
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.
Línea de Pedido
Existencia
1
0...*
Pedido
0...*
1 Especificación
0...*
Existencia
Catalogo
0...*
1 Cliente
0...* Nacional
Servicio
Importado
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
21
Agregación
NAssoc = 4 Asociaciones = (Pedido-Cliente); (Pedido-Línea de pedido); (Línea de pedidoProducto); (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 M ethods) 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
