Sunteți pe pagina 1din 14

Medir Complejidad Estructura

• Supongamos que para solucionar todas las instancias de un problema • La estructura del producto es importante no solo para el desarrollo
particular un algoritmo requiere f (n) cálculos. sino también para el mantenimiento.

• Decimos que f (n) es asintóticamente óptima si para todo • Dividimos la estructura en:
algoritmo con complejidad g que soluciona el problema, f es O(g).
1. Estructura del Flujo de Control: apunta a la secuencia en las
cuales se ejecutan las instrucciones.
• Complejidad de un Problema: es el orden del algoritmo
2. Estructura del Flujo de Datos: sigue el rastro de los items de
asintóticamente óptimo para la solución del problema.
datos como son creados o manejados por el programa.
3. Estructura de Datos: la organización de los datos en sı́ misma,
• Un problema que tiene una solución acotada polinómicamente se independiente del programa.
dice factible.

Administración y Gestión de Proyectos de Software, UNS 239 Administración y Gestión de Proyectos de Software, UNS 241

Medir Complejidad... Estructura del Flujo de Control

• Las mediciones de flujo de control son usualmente modeladas a


• P: la clase de todos los problemas factibles. partir de grafos dirigidos, llamados grafos de control de flujo -
flowgraphs.
• NP: la clase de programas cuya factibilidad es desconocida.
Parecieran no admitir solución, pero hay métodos (algoritmos • Nodo: Secuencia de programa. Enumeran las sentencias del
acotados polinómicamente) para chequear una solución. programa.

• NP-completo: subconjunto de programas mas complejos. • Arco: Flujo de control de una sentencia a otra. Muestran el patrón
de control.
• La jerarquı́a de clases de complejidad está dada por P, NP y
NP-completo. • 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 240 Administración y Gestión de Proyectos de Software, UNS 242
Estructura del Flujo de Control: Ejemplo Grafo de Flujo de Control

Ver figura 8-1. • 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 243 Administración y Gestión de Proyectos de Software, UNS 245

Estructura del Flujo de Control... Grafo de Flujo de Control

• Idea: Si m es una medida estructural definida en términos del • Camino: secuencia de arcos consecutivos. Puede haber duplicados
modelo F (A), y si el programa A es estructuralmente mas complejo en la secuencia.
que B =⇒ m(A) >> m(B)
• Camino Simple: camino sin arcos repetidos.
• Se trata de introducir un enfoque independiente de cualquier visión
de programación estructurada. • Ejemplo:
1. Nodo 50 Grado-in: 1
• La técnica permite mostrar que cualquier programa tiene una única 2. Nodo 50 Grado-out: 2
descomposición estructural definida por componentes primitivas. 3. Camino: < 30, 40 >, < 40, 50 >, < 50, 60 >, < 60, 40 >, <
40, 50 >, < 50, 80 >
• Se utilizan conceptos de grafos. No es camino simple, ya que repite < 40, 50 >

Administración y Gestión de Proyectos de Software, UNS 244 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 • Grafo de flujo Parametrizado: cuando se asocia con el código actual
tiene grado-out = 0 y cada nodo del grafo está en alún camino que representa. Ejemplo: D2(A, X) significa D2 con parámetros A
desde el nodo inicial al nodo final. 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 nodo inicial y el nodo final se distinguen con •
• La mayorı́a de los programas imperativos utilizan construcciones de
• El grafo de flujo es un ejemplo de máquina de estados finitos. 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 Administración y Gestión de Proyectos de Software, UNS 249

Grafo de Flujo de Control: Ejemplos 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. • Sea A un programa en el cual el procedimiento A es llamado por
un parámetro X.
• Supongamos que A y A son dos bloques de código de programa: F (A con A sustituido por X) = F (A)(F (A) en X)
F (A; A) = F (A); F (A)
• El grafo de flujo de la sustitución es igual al anidamiento de grafos
• El grafo del programa secuencia es igual a la secuencia de grafos. de flujos.

• Sean F1 y F2 grafos de flujos. Supongamos que F1 tiene un nodo • En general, sean F1, F2, . . . , Fn grafos de flujos con n nodos de
de procedimiento X. Anidar F2 en F1 en X es el grafo formado por procedimientos especı́ficos X1, X2, · · · , Xn. El grafo resultante es
F1 reemplazando el arco que sale de X con todo F2. El grafo de F (F 1 en X1, F2 en X2, · · · , Fn en Xn) Si los nodos no son relevantes
flujo resultante es F 1(F 2 en X). Si no hay ambiguedad F 1(F 2) F (F1, F2, · · · , Fn)

Administración y Gestión de Proyectos de Software, UNS 251 Administración y Gestión de Proyectos de Software, UNS 253

Secuencia y Anidamiento... 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 • Los elementos de S son S − graf os. Se llaman S − graf os básicos
descompuestos de manera no trivial en secuencias y anidamientos
• Se puede elegir que bloques constituyen los S − graf os. Ejemplo:
• Bohm y Jacopini: Cualquier algoritmo puede ser implementado
1. Para S = {P1}, S − graf os = {P1, P2, · · · , Pn, · · ·}
usando las construcciones de secuencia, selección y anidamiento.
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
• 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 Administración y Gestión de Proyectos de Software, UNS 257

Nociones de Estructurado... Descomposición Prima

• Se dice que una familia de grafos es S − estructurada (o que los • Se puede asociar con cualquier grafo de flujo un árbol de
miembros de la familia son S − graf os) si satisface las siguientes descomposición.
reglas recursivas:
1. Cada miembro de S es S − estructurado • El árbol es construı́do a partir de secuencias y anidamiento de grafos
2. Si S y S  son S − graf os =⇒ primos.
F ; F  es S − graf o
F (F ) es S − graf o (siempre que esté definido el anidamiento de • Ejemplo:
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 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 Administración y Gestión de Proyectos de Software, UNS 261

Ejemplo de Descomposición 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


• Deseamos medir formalmente la longitud v que indique el número de
la máxima profundidad de anidamiento de los Fi + 1
sentencias en un programa, cuando este se modela como un grafo.
α(F (F1, · · · , Fn) = 1 + max(α(F1), · · · , α(Fn))
1. M1: v(P1) = 1 Si F = P1 → v(F ) = n + 1
• Ejemplo: donde n es el número de nodos de procedimientos en F
α(F ) = α(D1((D0; P 1; D2), D0(D3))) 2. M2: v(F1; · · · ; Fn) = Σv(Fi )
α(F ) = 1 + max(α(D0; P1; D2), α(D0(D3))) 3. M3: v(F (F1, · · · , Fn)) = 1 + Σv(Fi ) para cada primo F = P1
α(F ) = 1 + max(max(α(D0 ), α(P1), α(D2)), 1 + α(D3))
α(F ) = 1 + max(max(1, 0, 1), 2) • v(D0) = 1 + 1 = 2
α(F ) = 1 + max(1, 2) v(D1) = 2 + 1 = 3
α(F ) = 3 v(D2) = 1 + 1 = 2
v(D3) = 1 + 1 = 2

Administración y Gestión de Proyectos de Software, UNS 263 Administración y Gestión de Proyectos de Software, UNS 265

Medidas Jerárquicas... Ejemplo de Medir Longitud

v(F ) = v(D1(D0; P1; D2), D0(D3)))


• Sea S un conjunto arbitrario de primos. Decimos que m es una v(F ) = 1 + v(D0; P1; D2) + v(D0(D3)))
medida jerárquica si puede definirse en el conjunto de S − graf os v(F ) = 1 + (v(D0) + v(P1) + v(D2)) + (1 + v(D3))
especificando: v(F ) = 1 + (2 + 1 + 2) + (1 + 2)
1. Regla M1: m(F ) ∀F ∈ S v(F ) = 1 + 5 + 3
2. Regla M2: la(s) función(es) de secuencia v(F ) = 9
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 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: • La complejidad de las componentes anidadas en un primo F es la
v(F ) = a − n + 2 complejidad del primo F mas la suma de las complejidades de las
donde F tiene a arcos y n nodos. componentes menos el número de componentes.

• El número ciclomático mide el número de caminos linealmente • Desde la teorı́a de las mediciones, es dudoso que cualquiera de estas
independientes de F . afirmaciones corresponda a relaciones intuitivas sobre complejidad.

• Para cualquier grafo F , v(F ) = 1 + d, donde d es el número de • Por eso, v no puede ser usada como una medida general de
nodos predicados de F . complejidad.

• La medida es objetiva y útil para medir los caminos linealmente • El número ciclomático es un indicador útil de la dificultad para probar
independientes, pero no es claro que refleje de manera completa y y mantener un programa o módulo. Si v > 10 = problemático.
exacta la complejidad de un programa.

Administración y Gestión de Proyectos de Software, UNS 267 Administración y Gestión de Proyectos de Software, UNS 269

Medida de Complejidad Ciclomática de Mc Cabe... Medida de Complejidad Esencial de Mc Cabe...

• v puede ser definida como una medida jerárquica: • Mc Cabe tambien propone una medida para capturar el nivel general
1. M1: v(F ) = 1 + d para cada primo F de estructuración de un programa.
donde d:cantidad de nodos predicados de F .
2. M2: v(F1; · · · ; Fn) = Σv(Fi ) − n + 1 • Para un programa con grafo F , define:
3. M3: v(F (F1, · · · , Fn)) = v(F ) + Σv(Fi ) − n para cada primo F 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 Administración y Gestión de Proyectos de Software, UNS 273

Medida de Complejidad Esencial de Mc Cabe... Medidas de Cubrimiento de Tests...

• Mc Cabe afirma que la complejidad esencial indica el grado hasta el • En estrategias de caja blanca, los casos de test se seleccionan de tal
cual el grafo puede ser “reducido” descomponiéndolo en todos los manera que toda sentencia de programa se ejecute al menos una vez
subgrafos que son D − primos. (cobertura de sentencias).

• La complejidad esencial mide el número ciclomático de lo que queda • En términos de grafos de programas la cobertura de sentencias se
luego de descomponer todos los subgrafos estructurados. 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 Administración y Gestión de Proyectos de Software, UNS 277

Medidas de Cubrimiento de Tests... Número Mı́nimo de Casos de Test

• Una alternativa para tests de caja blanca es seleccionar casos de test • Es importante no sólo diseñar la estrategia, sino también el número
de tal manera que cada rama (arco) sea ejecutada al menos una vez mı́nimo de casos de test.
(cobertura de arcos).
• El teorema de descomposición nos permite calcular el NMCT.
• La estrategia de caja blanca mas exhaustiva es seleccionar casos
de test de tal forma que todo camino posible del programa sea • Un caso de test corresponde a un camino a través del grafo F .
ejecutado al menos una vez (cobertura de caminos). Prácticamente
imposible. • Para calcular el NMCT, debemos calcular el número mı́nimo de
caminos m(F ) requeridos para satisfacer la estrategia.
• Existe un impedimento básico en las estrategias de caja blanca:
Camino No Factible: es un camino del programa que no puede ser • Podemos calcular m(F ) a partir del árbol, conociendo m(F ) para
ejecutado por ningún input. los primos, la secuencia y el anidamiento.
Ejemplo: ABCEFG

Administración y Gestión de Proyectos de Software, UNS 276 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%. La


experiencia dice que no supera el 40%.

• Se testea correctamente el software?

Administración y Gestión de Proyectos de Software, UNS 279 Administración y Gestión de Proyectos de Software, UNS 281

Ratio de Efectividad de Test Métricas Orientadas a Objetos

• Métricas propuestas por Shyam R.Chidamber y Chris F.Kemerer


• Para un programa y un conjunto de casos de test, deseamos conocer 1. Definición de Objetos y Relaciones entre Objetos
en que grado los casos de prueba satisfacen una estrategia particular – Métodos ponderados por clase (WMC:Weighted Methods per
de test.
Class)
– Profundidad del árbol de herencia (DIN:Depth of Inheritance)
• Ejemplo: Ejecutamos con 2 casos de prueba: ”6” y ”9”. Los casos – Número de descendientes (NOC: Number Of Children)
de test cubren dos caminos: ABDEG y ABDEFG y cubren 6 de las 2. Atributos y Propiedades de Objetos
7 sentencias, 7 de los 8 arcos y 2 de los 4 caminos. – Respuesta para una clase (RFC: Response for a Class)
Decimos que cubrimiento de sentencias es 86%, cubrimiento de arcos – Falta de cohesión en los métodos (LCO: Lack of Cohesion)
es 87,5% y cubrimiento de caminos es 50%. 3. Comunicación entre Objetos
– RFC
– Acoplamiento entre clases (CBO: Coupling Between Objects)

Administración y Gestión de Proyectos de Software, UNS 280 Administración y Gestión de Proyectos de Software, UNS 282
Métodos Ponderados por Clase : WMC Número de Descendientes : NOC

• Definida como el número inmedidato de subclases.


• W M C = Σci, donde ci es una medida de complejidad del método
i. • A medida que crece el número de descendientes se incrementa la
reutilización.
• El número de métodos y su complejidad es un predictor de cuanto
• Puede darse una mayor posibilidad de una incorrecta abstracción y
tiempo y esfuerzo es necesario para desarrollar y mantener la clase.
mayor complejidad de la clase padre.
• Cuanto más métodos mayor impacto en los hijos (herencia). • 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 Administración y Gestión de Proyectos de Software, UNS 285

Profundidad del Arbol de Herencia : DIN 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.
• Una clase está acoplada con otra si usa métodos o variables de
• Cuanto más profunda está una clase en una jerarquı́a, mayor instancia de la otra.
número de métodos hereda, haciendo más complejo predecir su
comportamiento. • Un valor alto decrementa el diseño modular y dificulta el reuso.

• El acoplamiento debe mantenerse mı́nimo para mejorar modularidad


• Una jerarquı́a de clases profunda lleva también a una mayor y encapsulamiento.
complejidad de diseño ya que involucra más clases.
• Una medida de acoplamiento es útil para determinar cuanto de
• Por otro lado, los valores grandes de esta medida implican que se complejo será el diseño de testing. Cuanto más acoplamiento se
pueden reutilizar muchos métodos. presenta mas riguroso debe ser el testing.

Administración y Gestión de Proyectos de Software, UNS 284 Administración y Gestión de Proyectos de Software, UNS 286
Respuesta para una Clase : RFC Métricas propuestas por Lorenz y Kidd

• Dividen las métricas en cuatro categorı́as: tamaño (recuento de


• El número de métodos que pueden ser invocados en respuesta a un atributos y operaciones), herencia (reutilización del código a lo
mensaje enviado a un objeto de la clase. 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).
• 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)
• Aumenta el esfuerzo de testeo y mantenimiento. – Número de Atributos (heredados + privados)

• Puede surgir el interrogante de si la clase está modelada • Número de Operaciones Invalidadas por una Subclase (NOI)
correctamente.
– 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 287 Administración y Gestión de Proyectos de Software, UNS 289

Falta de Cohesión en los Métodos : LCO Métricas propuestas por Lorenz y Kidd...

• El número de pares de métodos cuya similitud es cero menos el • Número de Operaciones Agregadas por una Subclase (NOA)
número de pares de métodos cuya similitud es distinta de cero. Si
el valor es negativo, se asume cero. – Las subclases se especializan agregando atributos y operaciones
privadas.
• Similitud: si dos pares de métodos acceden a uno o más de los
mismos atributos. • Indice de Especialización (IE) = (N OI ∗ nivel)/Mtotal .
– nivel= nivel de la jerarquı́a de clases donde reside la clase.
• La cohesión de los métodos dentro de una clase es deseable ya que
– Mtotal=número total de métodos para la clase.
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 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.
• Tamaño Medio de Operación: (T OAvg ). • Admisión (ADM): medida de herencia múltiple. Si ADM > 1 la
– LOC clase hereda de más de una clase raı́z.
– Cantidad de mensajes enviados por la operación. • Número de Descendientes (NOC) y Profundidad del Arbol de
Herencia (DIN).
• 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 Administración y Gestión de Proyectos de Software, UNS 293

Métricas para Pruebas OO (Binder) Métricas para Proyectos OO (Lorenz y Kidd)

1. Encapsulamiento • Número de Guiones de Escenario (NGE)

• Carencia de Cohesión en Métodos (LOC). – Guión de Escenario: es una secuencia detallada de pasos que
• Porcentaje Público y Protegido (PPP): Los atributos públicos describen la interacción entre el usuario y la aplicación.
se heredan de otras clases. Los atributos protegidos son una
especialización y privados de una clase especı́fica. Esta métrica • Número de Clases Claves (NCC)
indica el ratio entre ambos. – Clase Clave: Clase central al dominio del problema.
• Acceso Público a Datos Miembros (APD): Indica el número de
clases (o métodos) que pueden acceder a los atributos de otra • Número de Subsitemas (NSUB)
clase, violando el encapsulamiento.
– 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 292 Administración y Gestión de Proyectos de Software, UNS 294

S-ar putea să vă placă și