Medir Complejidad Medir Complejidad... Estructura Estructura del

Medir Complejidad
Estructura
• Supongamos que para solucionar todas las instancias de un problema
particular un algoritmo requiere f (n) cálculos.
• La estructura del producto es importante no solo para el desarrollo
sino también para el mantenimiento.
• Decimos que f (n) es asintóticamente óptima si para todo
algoritmo con complejidad g que soluciona el problema, f es O(g).
• Dividimos la estructura en:
• 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...
Administración y Gestión de Proyectos de Software, UNS
241
Estructura del Flujo de Control
• 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.
• 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.
• 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
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.
240
• 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
Grafo de Flujo de Control
• Grafo: conjunto de puntos (o nodos) y segmentos.
Ver figura 8-1.
• 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
243
Administración y Gestión de Proyectos de Software, UNS
Estructura del Flujo de Control...
Grafo de 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
245
244
• 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 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 •
• 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.
• El grafo de flujo es un ejemplo de máquina de estados finitos.
• La mayorı́a de los programas imperativos utilizan construcciones de
control prediseñadas. Pero esto no siempre es la realidad.
• Nodos de Procedimiento: nodos con grado-out = 1.
• Ejemplo:
• 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
Administración y Gestión de Proyectos de Software, UNS
249
Secuencia y Anidamiento
Ver figura 8.2
• 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
248
Administración y Gestión de Proyectos de Software, UNS
250
Secuencia y Anidamiento...
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)
• 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 del programa secuencia es igual a la secuencia de grafos.
• El grafo de flujo de la sustitución es igual al anidamiento de grafos
de flujos.
• 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)
• 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
251
Secuencia y Anidamiento...
Administración y Gestión de Proyectos de Software, UNS
253
Secuencia y Anidamiento: Ejemplo 8.6
• 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
Administración y Gestión de Proyectos de Software, UNS
254
Nociones de Estructurado
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.
• 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
• Se introduce el concepto de familia S de grafos de flujo primos.
Administración y Gestión de Proyectos de Software, UNS
255
Administración y Gestión de Proyectos de Software, UNS
Nociones de Estructurado...
257
Descomposición Prima
• 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:
• Se puede asociar con cualquier grafo de flujo un árbol de
descomposición.
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.
• El árbol es construı́do a partir de secuencias y anidamiento de grafos
primos.
Administración y Gestión de Proyectos de Software, UNS
256
• Ejemplo:
Administración y Gestión de Proyectos de Software, UNS
258
Ejemplo de Descomposición
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
259
Ejemplo de Descomposición
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
260
Administración y Gestión de Proyectos de Software, UNS
262
Medidas Jerárquicas...
Medir Longitud
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
• 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
263
Medidas Jerárquicas...
Administración y Gestión de Proyectos de Software, UNS
265
Ejemplo de Medir Longitud
• 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
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
• 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
Administración y Gestión de Proyectos de Software, UNS
266
Medida de Complejidad Ciclomática de Mc Cabe
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.
• 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.
• El número ciclomático mide el número de caminos linealmente
independientes de F .
• Desde la teorı́a de las mediciones, es dudoso que cualquiera de estas
afirmaciones corresponda a relaciones intuitivas sobre complejidad.
• Para cualquier grafo F , v(F ) = 1 + d, donde d es el número de
nodos predicados de F .
• Por eso, v no puede ser usada como una medida general de
complejidad.
• 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.
• 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
267
Medida de Complejidad Ciclomática de Mc Cabe...
Administración y Gestión de Proyectos de Software, UNS
269
Medida de Complejidad Esencial 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
• 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}
• 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
Administración y Gestión de Proyectos de Software, UNS
270
Ej.: Medida de Complejidad Esencial de Mc Cabe
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
271
Medida de Complejidad Esencial de Mc Cabe...
Administración y Gestión de Proyectos de Software, UNS
273
Medidas de Cubrimiento de Tests...
• 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.
• 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).
• La complejidad esencial mide el número ciclomático de lo que queda
luego de descomponer todos los subgrafos estructurados.
• 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.
• 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
Administración y Gestión de Proyectos de Software, UNS
274
Ejemplo: Medidas de Cubrimiento de Tests
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
275
Medidas de Cubrimiento de Tests...
277
Número Mı́nimo de Casos de Test
• 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
Administración y Gestión de Proyectos de Software, UNS
276
• 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
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
279
Ratio de Efectividad de Test
281
Métricas Orientadas a Objetos
• 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
Administración y Gestión de Proyectos de Software, UNS
280
• 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
Número de Descendientes : NOC
• 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).
• 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.
• Clases con más métodos son mas especı́ficas, limitando el reuso.
• 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
283
Profundidad del Arbol de Herencia : DIN
285
Acoplamiento entre Clases : CBO
• La cantidad de clases con las cuales está acoplada.
• 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
Administración y Gestión de Proyectos de Software, UNS
284
• 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
Métricas propuestas por Lorenz y Kidd
• 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.
• Tamaño de la clase (TC):
– Número de Operaciones (heredadas + privadas)
– Número de Atributos (heredados + privados)
• 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
• 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).
287
Falta de Cohesión en los Métodos : LCO
• 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...
• 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.
• 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.
• 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
Administración y Gestión de Proyectos de Software, UNS
290
Métricas Orientadas a Operaciones
Métricas para Pruebas OO (Binder)...
• Propuestas por Lorenz y Kidd.
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).
• 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)
293
Métricas para Proyectos OO (Lorenz y Kidd)
• Número de Guiones de Escenario (NGE)
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
Administración y Gestión de Proyectos de Software, UNS
292
– 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