Medir Complejidad

Medir Complejidad
• Supongamos que para solucionar todas las instancias de un problema
particular un algoritmo requiere f (n) cálculos.
• Decimos que f (n) es asintóticamente óptima si para todo
algoritmo con complejidad g que soluciona el problema, f es O(g).
• Complejidad de un Problema: es el orden del algoritmo
asintóticamente óptimo para la solución del problema.
• Un problema que tiene una solución acotada polinómicamente se
dice factible.
Administración y Gestión de Proyectos de Software, UNS
239
Medir Complejidad...
• P: la clase de todos los problemas factibles.
• NP: la clase de programas cuya factibilidad es desconocida.
Parecieran no admitir solución, pero hay métodos (algoritmos
acotados polinómicamente) para chequear una solución.
• NP-completo: subconjunto de programas mas complejos.
• La jerarquı́a de clases de complejidad está dada por P, NP y
NP-completo.
Administración y Gestión de Proyectos de Software, UNS
240
Estructura
• La estructura del producto es importante no solo para el desarrollo
sino también para el mantenimiento.
• Dividimos la estructura en:
1. Estructura del Flujo de Control: apunta a la secuencia en las
cuales se ejecutan las instrucciones.
2. Estructura del Flujo de Datos: sigue el rastro de los items de
datos como son creados o manejados por el programa.
3. Estructura de Datos: la organización de los datos en sı́ misma,
independiente del programa.
Administración y Gestión de Proyectos de Software, UNS
241
Estructura del Flujo de Control
• Las mediciones de flujo de control son usualmente modeladas a
partir de grafos dirigidos, llamados grafos de control de flujo flowgraphs.
• Nodo: Secuencia de programa.
programa.
Enumeran las sentencias del
• Arco: Flujo de control de una sentencia a otra. Muestran el patrón
de control.
• Dado un programa A, llamamos interpretación razonable F (A) al
grafo de control de flujo de A.
No siempre es posible mapear A en F (A).
Administración y Gestión de Proyectos de Software, UNS
242
Estructura del Flujo de Control: Ejemplo
Ver figura 8-1.
Administración y Gestión de Proyectos de Software, UNS
243
Estructura del Flujo de Control...
• Idea: Si m es una medida estructural definida en términos del
modelo F (A), y si el programa A es estructuralmente mas complejo
que B =⇒ m(A) >> m(B)
• Se trata de introducir un enfoque independiente de cualquier visión
de programación estructurada.
• La técnica permite mostrar que cualquier programa tiene una única
descomposición estructural definida por componentes primitivas.
• Se utilizan conceptos de grafos.
Administración y Gestión de Proyectos de Software, UNS
244
Grafo de Flujo de Control
• Grafo: conjunto de puntos (o nodos) y segmentos.
• Grafo Dirigido: cada segmento tiene asignada una dirección
indicada por una flecha, llamada arco. Conjunto de nodos y arcos.
Cada arco conecta un par de nodos.
• Arco: par ordenado < x, y > donde x e y son los nodos de los
extremos. La dirección del arco es de x a y.
• Grado-in: número de arcos que llegan a un nodo.
• Grado-out: número de arcos que dejan un nodo.
Administración y Gestión de Proyectos de Software, UNS
245
Grafo de Flujo de Control
• Camino: secuencia de arcos consecutivos. Puede haber duplicados
en la secuencia.
• Camino Simple: camino sin arcos repetidos.
• Ejemplo:
1. Nodo 50 Grado-in: 1
2. Nodo 50 Grado-out: 2
3. Camino: < 30, 40 >, < 40, 50 >, < 50, 60 >, < 60, 40 >, <
40, 50 >, < 50, 80 >
No es camino simple, ya que repite < 40, 50 >
Administración y Gestión de Proyectos de Software, UNS
246
Grafo de Flujo de Control
• Grafo de Flujo: es un grafo dirigido en los cuales dos nodos, el nodo
inicial y el nodo final tienen propiedades especiales. El nodo final
tiene grado-out = 0 y cada nodo del grafo está en alún camino
desde el nodo inicial al nodo final.
• El nodo inicial y el nodo final se distinguen con •
• El grafo de flujo es un ejemplo de máquina de estados finitos.
• Nodos de Procedimiento: nodos con grado-out = 1.
• Nodos de Predicado: nodos con grado-out > 1.
Administración y Gestión de Proyectos de Software, UNS
247
Grafo de Flujo de Control: Ejemplos
Ver figura 8.2
Administración y Gestión de Proyectos de Software, UNS
248
Grafo de Flujo de Control...
• Grafo de flujo Parametrizado: cuando se asocia con el código actual
que representa. Ejemplo: D2(A, X) significa D2 con parámetros A
y X. Notación para la estructura while A do X. Si se habla solo de
D2 significa la estructura de control genérica while-do.
• La mayorı́a de los programas imperativos utilizan construcciones de
control prediseñadas. Pero esto no siempre es la realidad.
• Ejemplo:
Administración y Gestión de Proyectos de Software, UNS
249
Secuencia y Anidamiento
• Hay dos operaciones básicas que se pueden utilizar para construir un
grafo de flujo: secuencia y anidamiento
• Sean F1 y F2 grafos de flujos. La secuencia F1 y F2 es el grafo
formado por intercalar el nodo final de F1 con el nodo inicial de F2.
El grafo resultante es F1; F2 o seq(F1, F2) o P2(F1, F2)
• Ejemplo: Figura 8.4
Administración y Gestión de Proyectos de Software, UNS
250
Secuencia y Anidamiento...
• La operación de secuencia de grafos de flujo corresponde a la
operación de secuencia (concatenación) de los LP imperativos.
• Supongamos que A y A son dos bloques de código de programa:
F (A; A) = F (A); F (A)
• El grafo del programa secuencia es igual a la secuencia de grafos.
• Sean F1 y F2 grafos de flujos. Supongamos que F1 tiene un nodo
de procedimiento X. Anidar F2 en F1 en X es el grafo formado por
F1 reemplazando el arco que sale de X con todo F2. El grafo de
flujo resultante es F 1(F 2 en X). Si no hay ambiguedad F 1(F 2)
Administración y Gestión de Proyectos de Software, UNS
251
Secuencia y Anidamiento...
• La operación de anidamiento de grafos de flujos corresponde a la
operación de sustitución de procedimientos en LP imperativos.
• Ejemplo: Figura 8.5
Administración y Gestión de Proyectos de Software, UNS
252
Secuencia y Anidamiento...
• Sea A un programa en el cual el procedimiento A es llamado por
un parámetro X.
F (A con A sustituido por X) = F (A)(F (A) en X)
• El grafo de flujo de la sustitución es igual al anidamiento de grafos
de flujos.
• En general, sean F1, F2, . . . , Fn grafos de flujos con n nodos de
procedimientos especı́ficos X1, X2, · · · , Xn. El grafo resultante es
F (F 1 en X1, F2 en X2, · · · , Fn en Xn) Si los nodos no son relevantes
F (F1, F2, · · · , Fn)
Administración y Gestión de Proyectos de Software, UNS
253
Secuencia y Anidamiento: Ejemplo 8.6
Administración y Gestión de Proyectos de Software, UNS
254
Nociones de Estructurado
• Grafo de Flujo Primo: grafos de flujos que no pueden ser
descompuestos de manera no trivial en secuencias y anidamientos
• Bohm y Jacopini: Cualquier algoritmo puede ser implementado
usando las construcciones de secuencia, selección y anidamiento.
• Objetivo: Considerando solo el grafo de flujo determinar si un
algoritmo es estructurado o no.
• Se introduce el concepto de familia S de grafos de flujo primos.
Administración y Gestión de Proyectos de Software, UNS
255
Nociones de Estructurado...
• Se dice que una familia de grafos es S − estructurada (o que los
miembros de la familia son S − graf os) si satisface las siguientes
reglas recursivas:
1. Cada miembro de S es S − estructurado
2. Si S y S son S − graf os =⇒
F ; F es S − graf o
F (F ) es S − graf o (siempre que esté definido el anidamiento de
F en F
3. Ningún otro grafo es un S − graf o a menos que se pueda mostrar
que es generado en un número finito de veces por la aplicación de
los puntos anteriores.
Administración y Gestión de Proyectos de Software, UNS
256
Nociones de Estructurado...
• Los elementos de S son S − graf os. Se llaman S − graf os básicos
• Se puede elegir que bloques constituyen los S − graf os. Ejemplo:
1. Para S = {P1}, S − graf os = {P1, P2, · · · , Pn, · · ·}
2. S d = {P1, D0, D2} son los grafos D − estructurados
3. Para S = {D1, D2}, los siguiente son S − graf os: Fig.8.7
Administración y Gestión de Proyectos de Software, UNS
257
Descomposición Prima
• Se puede asociar con cualquier grafo de flujo un árbol de
descomposición.
• El árbol es construı́do a partir de secuencias y anidamiento de grafos
primos.
• Ejemplo:
Administración y Gestión de Proyectos de Software, UNS
258
Ejemplo de Descomposición
Administración y Gestión de Proyectos de Software, UNS
259
Ejemplo de Descomposición
Administración y Gestión de Proyectos de Software, UNS
260
Descomposición Prima
• Teorema de Descomposición Prima: Todo grafo tiene una única
descomposición en una jerarquı́a de grafos primos.
• Existen herramientas que lo hacen automáticamente.
• El teorema provee una forma simple para determinar si un grafo es
S − estructurado para una familia de primos S.
• Procedimiento:
1. Se calcula el árbol.
2. Si todo nodo es un elemento de S o es un Pn =⇒ el grafo es un
S − graf o.
Administración y Gestión de Proyectos de Software, UNS
261
Medidas Jerárquicas
• La descomposición prima definida de manera única es una
descomposición definitiva de la estructura de control de un programa.
• Medir formalmente la profundidad de anidamiento de un programa:
Sea F el grafo de un programa. α la profundidad de anidamiento
de F . Podemos expresar α en términos de primos, secuencias y
anidamientos:
1. Primos: α(P1) = 0 y ∀ F primo = P1 α(F ) = 1
2. Secuencia: la profundidad de anidamiento de la secuencia
F1, F2, · · · , Fn es la máxima profundidad de anidamiento de los
Fi
α(F1; F2; · · · ; Fn) = max(α(F1), · · · , α(Fn))
Administración y Gestión de Proyectos de Software, UNS
262
Medidas Jerárquicas...
3. Anidamiento: la profundidad de anidamiento de F (F1 · · · Fn) es
la máxima profundidad de anidamiento de los Fi + 1
α(F (F1, · · · , Fn) = 1 + max(α(F1), · · · , α(Fn))
• Ejemplo:
α(F ) = α(D1((D0; P 1; D2), D0(D3)))
α(F ) = 1 + max(α(D0; P1; D2), α(D0(D3)))
α(F ) = 1 + max(max(α(D0 ), α(P1), α(D2)), 1 + α(D3))
α(F ) = 1 + max(max(1, 0, 1), 2)
α(F ) = 1 + max(1, 2)
α(F ) = 3
Administración y Gestión de Proyectos de Software, UNS
263
Medidas Jerárquicas...
• Sea S un conjunto arbitrario de primos. Decimos que m es una
medida jerárquica si puede definirse en el conjunto de S − graf os
especificando:
1. Regla M1: m(F ) ∀F ∈ S
2. Regla M2: la(s) función(es) de secuencia
3. Regla M3: las funciones de anidamiento hf ∀F ∈ S
• Se puede calcular la medida jerárquica de un programa una vez que
conocemos las reglas M1, M2, M3 y el árbol de descomposición.
Administración y Gestión de Proyectos de Software, UNS
264
Medir Longitud
• Deseamos medir formalmente la longitud v que indique el número de
sentencias en un programa, cuando este se modela como un grafo.
1. M1: v(P1) = 1 Si F = P1 → v(F ) = n + 1
donde n es el número de nodos de procedimientos en F
2. M2: v(F1; · · · ; Fn) = Σv(Fi )
3. M3: v(F (F1, · · · , Fn)) = 1 + Σv(Fi ) para cada primo F = P1
• v(D0) = 1 + 1 = 2
v(D1) = 2 + 1 = 3
v(D2) = 1 + 1 = 2
v(D3) = 1 + 1 = 2
Administración y Gestión de Proyectos de Software, UNS
265
Ejemplo de Medir Longitud
v(F ) = v(D1(D0; P1; D2), D0(D3)))
v(F ) = 1 + v(D0; P1; D2) + v(D0(D3)))
v(F ) = 1 + (v(D0) + v(P1) + v(D2)) + (1 + v(D3))
v(F ) = 1 + (2 + 1 + 2) + (1 + 2)
v(F ) = 1 + 5 + 3
v(F ) = 9
Administración y Gestión de Proyectos de Software, UNS
266
Medida de Complejidad Ciclomática de Mc Cabe
• Para un programa con grafo F , el número ciclomático es:
v(F ) = a − n + 2
donde F tiene a arcos y n nodos.
• El número ciclomático mide el número de caminos linealmente
independientes de F .
• Para cualquier grafo F , v(F ) = 1 + d, donde d es el número de
nodos predicados de F .
• La medida es objetiva y útil para medir los caminos linealmente
independientes, pero no es claro que refleje de manera completa y
exacta la complejidad de un programa.
Administración y Gestión de Proyectos de Software, UNS
267
Medida de Complejidad Ciclomática de Mc Cabe...
• v puede ser definida como una medida jerárquica:
1. M1: v(F ) = 1 + d para cada primo F
donde d:cantidad de nodos predicados de F .
2. M2: v(F1; · · · ; Fn) = Σv(Fi ) − n + 1
3. M3: v(F (F1, · · · , Fn)) = v(F ) + Σv(Fi ) − n para cada primo F
• La complejidad de los primos depende sólo del número de nodos
predicado que tengan.
• La complejidad de la secuencia es igual a la suma de las complejidades
de las componentes menos el número de componentes mas uno.
Administración y Gestión de Proyectos de Software, UNS
268
Medida de Complejidad Ciclomática de Mc Cabe...
• La complejidad de las componentes anidadas en un primo F es la
complejidad del primo F mas la suma de las complejidades de las
componentes menos el número de componentes.
• Desde la teorı́a de las mediciones, es dudoso que cualquiera de estas
afirmaciones corresponda a relaciones intuitivas sobre complejidad.
• Por eso, v no puede ser usada como una medida general de
complejidad.
• El número ciclomático es un indicador útil de la dificultad para probar
y mantener un programa o módulo. Si v > 10 = problemático.
Administración y Gestión de Proyectos de Software, UNS
269
Medida de Complejidad Esencial de Mc Cabe...
• Mc Cabe tambien propone una medida para capturar el nivel general
de estructuración de un programa.
• Para un programa con grafo F , define:
complejidad esencial: ev(F ) = v(F ) − m
donde m es el número de subgrafos de F que ∈ {D0, D1, D2, D3}
Administración y Gestión de Proyectos de Software, UNS
270
Ej.: Medida de Complejidad Esencial de Mc Cabe
Administración y Gestión de Proyectos de Software, UNS
271
Medida de Complejidad Esencial de Mc Cabe...
• Mc Cabe afirma que la complejidad esencial indica el grado hasta el
cual el grafo puede ser “reducido” descomponiéndolo en todos los
subgrafos que son D − primos.
• La complejidad esencial mide el número ciclomático de lo que queda
luego de descomponer todos los subgrafos estructurados.
• Una idea más intuitiva de la complejidad esencial puede ser el número
ciclomático del primo más grande en el árbol de descomposición.
Administración y Gestión de Proyectos de Software, UNS
272
Medidas de Cubrimiento de Tests
• La estructura de un módulo está relacionada con la dificultad para
testearlo.
• Sea P un programa, S la especificación de P , e i un input a P .
Definimos:
Caso de test: (i, S(i)). El interés es chequear que P (i) = S(i)
• Las estrategias para testear software pueden ser:
1. Pruebas de caja negra: los casos de test se derivan de la
especificación sin referencias al código.
2. Pruebas de caja blanca: los casos de test se seleccionan basados
en el conocimiento de la estructura interna del programa.
Administración y Gestión de Proyectos de Software, UNS
273
Medidas de Cubrimiento de Tests...
• En estrategias de caja blanca, los casos de test se seleccionan de tal
manera que toda sentencia de programa se ejecute al menos una vez
(cobertura de sentencias).
• En términos de grafos de programas la cobertura de sentencias se
logra encontrando un conjunto de caminos de tal forma que todo
nodo esté en al menos un camino.
Administración y Gestión de Proyectos de Software, UNS
274
Ejemplo: Medidas de Cubrimiento de Tests
Administración y Gestión de Proyectos de Software, UNS
275
Medidas de Cubrimiento de Tests...
• Una alternativa para tests de caja blanca es seleccionar casos de test
de tal manera que cada rama (arco) sea ejecutada al menos una vez
(cobertura de arcos).
• La estrategia de caja blanca mas exhaustiva es seleccionar casos
de test de tal forma que todo camino posible del programa sea
ejecutado al menos una vez (cobertura de caminos). Prácticamente
imposible.
• Existe un impedimento básico en las estrategias de caja blanca:
Camino No Factible: es un camino del programa que no puede ser
ejecutado por ningún input.
Ejemplo: ABCEFG
Administración y Gestión de Proyectos de Software, UNS
276
Medidas de Cubrimiento de Tests...
• Ninguna estrategia de caja blanca puede asegurar por sı́ misma un
adecuado testeo del software.
Ejemplo: La ejecución del camino ABDEFG para ”9” fue correcta.
Qué pasa con el input 11? Ejecuta el mismo camino y el resultado
es erróneo.
• El conocer todos los caminos que satisfacen una estrategia no
significa conocer cómo definir los casos de test.
• Asociado con toda estrategia de test, existen dos medidas:
1. El mı́nimo número de casos de test.
2. El ratio de efectividad del test.
Administración y Gestión de Proyectos de Software, UNS
277
Número Mı́nimo de Casos de Test
• Es importante no sólo diseñar la estrategia, sino también el número
mı́nimo de casos de test.
• El teorema de descomposición nos permite calcular el NMCT.
• Un caso de test corresponde a un camino a través del grafo F .
• Para calcular el NMCT, debemos calcular el número mı́nimo de
caminos m(F ) requeridos para satisfacer la estrategia.
• Podemos calcular m(F ) a partir del árbol, conociendo m(F ) para
los primos, la secuencia y el anidamiento.
Administración y Gestión de Proyectos de Software, UNS
278
Número Mı́nimo de Casos de Test: Ejemplo
Administración y Gestión de Proyectos de Software, UNS
279
Ratio de Efectividad de Test
• Para un programa y un conjunto de casos de test, deseamos conocer
en que grado los casos de prueba satisfacen una estrategia particular
de test.
• Ejemplo: Ejecutamos con 2 casos de prueba: ”6” y ”9”. Los casos
de test cubren dos caminos: ABDEG y ABDEFG y cubren 6 de las
7 sentencias, 7 de los 8 arcos y 2 de los 4 caminos.
Decimos que cubrimiento de sentencias es 86%, cubrimiento de arcos
es 87,5% y cubrimiento de caminos es 50%.
Administración y Gestión de Proyectos de Software, UNS
280
Ratio de Efectividad de Test...
• Dada una estrategia T que requiere cubrir una clase de objetos
(sentencias, caminos,...), para un programa dado y un conjunto de
casos de prueba, se define el Ratio de Efectividad del Test:
RETT =número de objetos de T usados al menos una vez / número
total de objetos de T
• Los gerentes asumen que normalmente RET es del 100%.
experiencia dice que no supera el 40%.
La
• Se testea correctamente el software?
Administración y Gestión de Proyectos de Software, UNS
281
Métricas Orientadas a Objetos
• Métricas propuestas por Shyam R.Chidamber y Chris F.Kemerer
1. Definición de Objetos y Relaciones entre Objetos
– Métodos ponderados por clase (WMC:Weighted Methods per
Class)
– Profundidad del árbol de herencia (DIN:Depth of Inheritance)
– Número de descendientes (NOC: Number Of Children)
2. Atributos y Propiedades de Objetos
– Respuesta para una clase (RFC: Response for a Class)
– Falta de cohesión en los métodos (LCO: Lack of Cohesion)
3. Comunicación entre Objetos
– RFC
– Acoplamiento entre clases (CBO: Coupling Between Objects)
Administración y Gestión de Proyectos de Software, UNS
282
Métodos Ponderados por Clase : WMC
• W M C = Σci, donde ci es una medida de complejidad del método
i.
• El número de métodos y su complejidad es un predictor de cuanto
tiempo y esfuerzo es necesario para desarrollar y mantener la clase.
• Cuanto más métodos mayor impacto en los hijos (herencia).
• Clases con más métodos son mas especı́ficas, limitando el reuso.
Administración y Gestión de Proyectos de Software, UNS
283
Profundidad del Arbol de Herencia : DIN
• La longitud máxima desde el nodo hasta la raı́z del árbol.
• Cuanto más profunda está una clase en una jerarquı́a, mayor
número de métodos hereda, haciendo más complejo predecir su
comportamiento.
• Una jerarquı́a de clases profunda lleva también a una mayor
complejidad de diseño ya que involucra más clases.
• Por otro lado, los valores grandes de esta medida implican que se
pueden reutilizar muchos métodos.
Administración y Gestión de Proyectos de Software, UNS
284
Número de Descendientes : NOC
• Definida como el número inmedidato de subclases.
• A medida que crece el número de descendientes se incrementa la
reutilización.
• Puede darse una mayor posibilidad de una incorrecta abstracción y
mayor complejidad de la clase padre.
• Un gran número de hijos puede requerir mayor testing de los métodos
de la clase.
• Un gran número de hijos también es un indicador de la influencia
potencial de una clase en el diseño.
Administración y Gestión de Proyectos de Software, UNS
285
Acoplamiento entre Clases : CBO
• La cantidad de clases con las cuales está acoplada.
• Una clase está acoplada con otra si usa métodos o variables de
instancia de la otra.
• Un valor alto decrementa el diseño modular y dificulta el reuso.
• El acoplamiento debe mantenerse mı́nimo para mejorar modularidad
y encapsulamiento.
• Una medida de acoplamiento es útil para determinar cuanto de
complejo será el diseño de testing. Cuanto más acoplamiento se
presenta mas riguroso debe ser el testing.
Administración y Gestión de Proyectos de Software, UNS
286
Respuesta para una Clase : RFC
• El número de métodos que pueden ser invocados en respuesta a un
mensaje enviado a un objeto de la clase.
• Un valor muy alto indica que la clase es compleja y probablemente
altamente acoplada.
• Aumenta el esfuerzo de testeo y mantenimiento.
• Puede surgir el interrogante de si la clase está modelada
correctamente.
Administración y Gestión de Proyectos de Software, UNS
287
Falta de Cohesión en los Métodos : LCO
• El número de pares de métodos cuya similitud es cero menos el
número de pares de métodos cuya similitud es distinta de cero. Si
el valor es negativo, se asume cero.
• Similitud: si dos pares de métodos acceden a uno o más de los
mismos atributos.
• La cohesión de los métodos dentro de una clase es deseable ya que
promueve el encapsulamiento.
• La falta de cohesión implica que una clase debiera dividirse en dos o
más clases.
Administración y Gestión de Proyectos de Software, UNS
288
Métricas propuestas por Lorenz y Kidd
• Dividen las métricas en cuatro categorı́as: tamaño (recuento de
atributos y operaciones), herencia (reutilización del código a lo
ancho y alto de la jerarquı́a de clases), valores internos (cohesión y
análisis de código) y valores externos (acoplamiento y reuso).
• Tamaño de la clase (TC):
– Número de Operaciones (heredadas + privadas)
– Número de Atributos (heredados + privados)
• Número de Operaciones Invalidadas por una Subclase (NOI)
– Invalidación: cuando una subclase substituye una operación
heredada por una versión especializada para su propio uso.
Administración y Gestión de Proyectos de Software, UNS
289
Métricas propuestas por Lorenz y Kidd...
• Número de Operaciones Agregadas por una Subclase (NOA)
– Las subclases se especializan agregando atributos y operaciones
privadas.
• Indice de Especialización (IE) = (N OI ∗ nivel)/Mtotal .
– nivel= nivel de la jerarquı́a de clases donde reside la clase.
– Mtotal=número total de métodos para la clase.
Administración y Gestión de Proyectos de Software, UNS
290
Métricas Orientadas a Operaciones
• Propuestas por Lorenz y Kidd.
• Tamaño Medio de Operación: (T OAvg ).
– LOC
– Cantidad de mensajes enviados por la operación.
• Complejidad de Operación (CO): se calcula mediante cualquier
métrica de complejidad.
• Número medio de parámetros por operación (N Pavg ).
Administración y Gestión de Proyectos de Software, UNS
291
Métricas para Pruebas OO (Binder)
1. Encapsulamiento
• Carencia de Cohesión en Métodos (LOC).
• Porcentaje Público y Protegido (PPP): Los atributos públicos
se heredan de otras clases. Los atributos protegidos son una
especialización y privados de una clase especı́fica. Esta métrica
indica el ratio entre ambos.
• Acceso Público a Datos Miembros (APD): Indica el número de
clases (o métodos) que pueden acceder a los atributos de otra
clase, violando el encapsulamiento.
Administración y Gestión de Proyectos de Software, UNS
292
Métricas para Pruebas OO (Binder)...
2. Herencia
• Número de Clases Raı́z (NCR): Cantidad de jerarquı́as de clases.
• Admisión (ADM): medida de herencia múltiple. Si ADM > 1 la
clase hereda de más de una clase raı́z.
• Número de Descendientes (NOC) y Profundidad del Arbol de
Herencia (DIN).
Administración y Gestión de Proyectos de Software, UNS
293
Métricas para Proyectos OO (Lorenz y Kidd)
• Número de Guiones de Escenario (NGE)
– Guión de Escenario: es una secuencia detallada de pasos que
describen la interacción entre el usuario y la aplicación.
• Número de Clases Claves (NCC)
– Clase Clave: Clase central al dominio del problema.
• Número de Subsitemas (NSUB)
– Proporciona una idea de la asignación de recursos, de planificación
y de esfuerzo de integración.
Administración y Gestión de Proyectos de Software, UNS
294