Diseo de Software

Ejemplo Diseo de Software

Ejemplo Diseo de Software

Ejemplo Diseo de Software

Ejemplo Diseo de Software

Ejemplo Diseo de Software

Diseo de Software
Requerimientos

Arquitectura/Diseo de Software

Implementaciones Puente entre mundos Fronteras difusas a diferencia de otras disciplinas

7

Frenado del Airbus A320

Sensor Ruedas
giro alt pulsos

Sensor Sensor

Sistema de Frenado Airbus A320

peso seal de habilitado y deshabilitado de aceleracin de reversa

Motor de Reversa

prendido y apagado de motor

Controlador de Aceleracin de Reversa

seales de prendido y apagado de motor

Piloto

Frenado del Airbus A320

Ruedas
giro

Sensor

pulsos

Sistema de Frenado Airbus A320

Motor de Reversa

prendido y apagado de motor

seal de habilitado y deshabilitado de aceleracin de reversa

Controlador de Aceleracin de Reversa

seales de prendido y apagado de motor

Piloto

Recordatorio: La relacin entre el problema y solucin

Independiente Menos Info Dependencia de la implementacin

Dependiente

Nivel de Completitud

Enunciado del Problema Mas Info

Enunciado de la Implementacin

10

Requerimientos y Diseo: Una Visin Top-Down

Sistema
Requerimientos

Design

Subsistema

Requerimientos Design

Componente

Requerimientos Design

Ojo: Tomar decisiones de bajo nivel es compatible con esta visin...

11

Diseo de Software
Los Sistemas de Software Intensivo son entes complejos Cmo lidiamos con la complejidad?
millones de lneas de cdigo, variables, posibles estados, etc... Estructura y Abstraccin... ...s, pero cmo? qu abstracciones? qu relaciones?...

Disear involucra estructurar la solucin utilizando abstracciones y relaciones entre las abstracciones apropiadas para poder:

Documentar y Comprender la propuesta de solucin Razonar sobre su grado de adecuacin c.r.a los requerimientos Comunicarla Implementarla Verificar/Validar el producto final Modificar/Adaptar la solucin en la medida que cambien los requerimientos

Diseo de Software
Gua en la concepcin de productos de software (requerimientos complejos, integracin de componentes existentes, tecnologa, familias de productos, etc.) Drivers: atributos de calidad/requerimientos no funcionales y restricciones de proyecto y tecnologa Usualmente en tensin

A diferencia del mundo de los requerimientos: Denota conceptos del mundo de la solucin (pero incluye fenmenos de la interfase mundo mquina) En general se describen propiedades localizadas (unidad, componente, mdulo) y son de naturaleza operacional

13

Objetivos de la Etapa de Diseo

Descomponer el sistema en entidades de diseo ms chicas Determinar la relacin entre entidades. Fijar mecanismos de interaccin
ej. identificar dependencias

ej qu paquetes, clases, mdulos, componentes...

Especificar interfaces y funcionalidad de entidades

ej. memoria compartida, RPC, llamadas a funcin

Identificar oportunidades para el reuso

tanto top-down como bottom-up

ej. operaciones y sus aridades, descripcin formal/informal de comportamiento

Documentar todo lo anterior junto con la fundamentacin de las elecciones

Metodologa de Diseo: Visin Macro

El foco en el proceso de Diseo pasa:
de los stakeholders externos (cliente, usuario, etc.) a los internos (desarrolladores, testers, etc.) de Qu y Porqu a Qu y Cmo

Pasos Macro
Diseo Arquitectnico (o Arquitectura) Diseo Detallado (o Diseo)

Proceso iterativo
Decisiones clave primero
ej. Requerimientos no-funcionales crticos Qu va a cambiar?

El Diseo Detallado y la Tecnologa de Construccin de Soluciones Decisiones, patrones, notaciones, modelos y blueprints de diseo pueden estar fuertemente impactados por el paradigma de la tecnologa que se usa en la solucin,
(especialmente si hablamos de un diseo detallado)

Dnde est el lmite entre codificar y disear? Veremos el caso cuando hablemos de POO
19

Introduccin a POO

20

Documentacin

21

 La descripcin de un sistema complejo no es unidimensional Es clave saber cules son las vistas relevantes y vincularlas Relevancia: depende del propsito (e.g., enunciar la misin de implementacin, anlisis de atributos de calidad, generacin automtica de cdigo, planificacin, etc.)
22

Vistas

Vistas y stackeholders
La metfora de D.Garlan
I do bones,

not hearts.

These views are needed by the cardiologist

but will these views work for the orthopedist?

D.Garlan

23

Vistas
Las vistas exponen atributos de calidad en diferente grado:
Vista modular: portabilidad Vista de deployment: performace, confiabilidad

Enfatizan aspectos e ignoran otros para que el problema sea abordable Ninguna vista es EL diseo
24

Vistas Clsicas
Vista Modular: Cmo agrupamos el cdigo?
mtodos, procedimientos, clases, librera, DLLs, APIs, paquetes, mdulos... usa, subclase, contiene, depende-de,... diagrama de clases y de paquetes

Vista Run-time o de Componentes y Conectores: Cmo son las entidades run-time?

procesos, threads, objetos, protocolos, ciclos de vida se-comunica-con, bloquea, contiene, crea, destruye,... maquinas de estado, diagrama de secuencia y de colaboracin, diagrama de objetos, diagrama de componentes

Vista de Deployment (de Despliegue): Dnde residen las distintas partes?

Recursos y repositorios adems de entidades dinmicas o estticas procesos ejecuta-sobre server, cdigo de mdulos almacenado en directorio, equipo de trabajo desarrolla paquete,... diagrama de despliegue, ...

25

Ejemplo: Mdulos vs. Componentes

Mdulos: entidad en tiempo de diseo. Enfatiza en encapsulamiento: information hiding e interfaces.

Componentes: tienen entidad en tiempo de ejecucin y de despliegue

26

Alternando caracteres:
Module View
Alternar maysculas con minsculas a partir de un stream de caracteres
main
sofTWareArchitecture => SoFtWaReArCiTeCtUrE

split

lower

upper

merge

Referencias

config

input/output

Modulo

Modularizacin en funcin del a relacin de uso

Usos

27

Alternando caracteres:
C&C View

lower

split

merge

upper

Referencias

Componentes y Conectores (Pipe & Filter)

Filter Pipe
Binding

28

Diagramas y vistas en UML

29

Vista Modular (Diagrama de Clases)

Este ejemplo enfatiza la agrupacin de mtodos y datos en clases adems de asociaciones (dependencias estructurales) y relaciones de herencia y contiene-a

30

Vista Modular (2)

Otros niveles de abstraccin...

31

Vista Run-Time (Estructura: componentes & conectoresObjetos y links)

32

Ejemplo de Vista Run-Time (Comportamiento)

33

Ejemplo de Vista Run-Time (Estructura)

Poner ejemplo con multiples instancias de un tipo

34

Ejemplo de Vista de Deployment (1)

35

Ejemplo de Vista de Deployment (2)

36

Mezclando Vistas

37

Mezclando Vistas

38

Mezclando Vistas

39

Generalizando los tipos de vista

Mas all de UML

40

Mdulo
Concepto proveniente de los 60s y 70s Basado en la nocin de unidad de software que provee servicios a travs de una interfaz bien definida

La manera de modularizacin suele determinar caractersticas como modificabilidad, portabilidad y reuso

41

Elementos
Un mdulo es una unidad de cdigo que implementa un conjunto de responsabilidades
Una clase, una coleccin de clases, una capa o cualquier descomposicin de la unidad de cdigo

42

Relaciones
Se distinguen tres tipos de relaciones
es parte de que define la relacin entre un submdulo A y un mdulo B depende de que define la dependencia entre dos mdulos A y B es un que define una relacin de generalizacin entre un modulo especfico y otro ms general
43

Module Viewtype: utilidad

Anlisis
A partir de estas vistas, es posible realizar distinto tipos de anlisis Por ejemplo: Trazabilidad de Requerimientos
Analiza como los requerimientos funcionales son soportados por las responsabilidades de los distintos mdulos

Anlisis de Impacto
Permite predecir el efecto de las modificacin del sistema
44

Module Viewtype: utilidad

Comunicacin
Estas vistas pueden ser utilizadas para explicar las funcionalidades del sistema a alguien no familiarizado con el mismo
Distintos niveles de granularidad, presentan una descripcin top-down de las responsabilidades del sistema

45

Module Viewtype: cuando no

Es dificultoso utilizar este tipo de vistas para realizar inferencias sobre el comportamiento del sistema durante su ejecucin Dada su naturaleza, no es de mucha utilidad para la realizacin de anlisis de performance, confiabilidad u otras caractersticas asociadas al tiempo de ejecucin
Mltiples instancias de objetos Relaciones existentes slo en tiempo de ejecucin

46

Componentes y Conectores: Ejemplos

47

Elementos
Son entidades con manifestacin runtime que consumen recursos de ejecucin y contribuyen al comportamiento en ejecucin del sistema La configuracin del sistema es un grafo conformado por la asociacin entre componentes y conectores

Las entidades runtime son instancias de tipos de conector o componente

48

Utilidad
Cuales son los componentes ejecutables y

como interactan?

Cules son los repositorios y que componentes los acceden? Qu partes del sistema son replicadas y cuantas veces? Cmo progresan los datos a los largo del sistema a medida que ste se ejecuta?
49

Utilidad
Qu protocolos de interaccin son usados por las entidades comunicantes? Qu partes del sistema se ejecutan en paralelo? Cmo la estructura del sistema puede cambiar a medida que se ejecuta?

50

Propiedades

Confiabilidad

Podemos usarlo para determinar la funcionalidad del sistema en su conjunto

Performance
Tiempo de respuesta / carga Tiempo de latencia y volumen de procesamiento

Recursos requeridos
Necesidades de almacenamiento Necesidades de procesamiento

51

Propiedades
Funcionalidad
Funciones mapeadas sobre el componente

Protocolos

Patrones de eventos o acciones que pueden tener lugar en una interacciones representada por el elemento

Seguridad
Encripta Audita Autentica

52

Para lo que NO sirve

No se debe usar para modelar elementos de diseo que no tienen comportamiento runtime Una clase no es un componente. Un componente no representa de ninguna manera una visin esttica de diseo

53

Resumen Conectores
C&C viewtype define modelo consistente de elementos que tienen presencia runtime C&C viewtype incluye informacin sobre los caminos de interaccin entre los componentes Los componentes tienen interfaces llamadas ports Los conectores tienen interfaces llamadas roles
54

Ejemplo: IP 2000
Siemens
Source: Applied Software Architecture (Nord, Hofmeister) (Escaneado)

55

Visin Conceptual

56

Caractersticas del C&C

Los componentes y conectores representan entidades de tiempo de ejecucin Los ports son las interfaces de comunicacin de los componentes agrupando seales de entrada y salida que siguen algn tipo de secuenciamiento (protocolo) Los conectores tienen como funcin mediar en la interaccin entre componentes Los conectores pueden representar formas complejas de interaccin ms all del simple call return sincrnico El conector debera especificar el protocolo bajo el cual los componentes interactan para cada uno de sus roles

57

Vista de Mdulos

58

Vista de Mdulos
Descomposicin

59

Vista de Mdulos
Descomposicin

60

Visin Conceptual
C&C

61

C&C y Comportamiento

Sebastian Uchitel

62

C&C - Descomposicin

Visin Conceptual

63

Visin Conceptual
Comportamiento

64

Visin Conceptual
C&C

65

Conector PacketPipe

Visin Conceptual

66

Visin de Ejecucin

67

Principios de Diseo

68

Herramientas Conceptuales: Principios

Decomposicin
Divide & Conquer (piezas conocidas y tratables) Separacin por niveles de abstraccin y/o mquinas virtuales Separacin por aspectos, etc.

Modularidad
Coleccin bien definida de partes e interacciones bien delimitadas

Ocultamiento de la informacin
Confinar el impacto del cambio (de un mdulo) El ciente de un mdulo no debe conocer los detalles de diseo difciles o que pueden cambiar

Encapsulamiento
Clara separacin de interface e implementacin Mecanismos para no conocer ni usar ms de lo que la interface promete

Abstraccin
Foco en lo esencial
69

Principios (Cont.)
Explotar el Polimorfismo
tratamiento uniforme de una entidad que puede tener mltiples formas Sustitucin Liskov/Wing

Inversin de dependencia/control
Depender en abstracciones e interfaces en lugar de clases concretas Ser invocado en lugar de invocar para reuso de abstracciones de control

Segregacin de interfaces Una sola responsabilidad (cohesion) Open-Close Deteccin de puntos de variabilidad

Advertencia: Estos principios han nacido con la extensibilidad y la modificabilidad como atributos de calidad preponderantes

70

Estrategias de Descomposicin
Problemas que sabemos resolver
Ej. M. Jacksons Problem Frames: Control, Visualizacion, Correspondencia, etc

Pasos de ejecucin
Ej. Filtros de procesamiento de imagenes

Tempo de ejecucin
Ej. Acumulacin vs Utilizacin de Informacin

Funcional
Ej. Facturacin, Compras y Sueldos

Modos de Operacin
Normal vs Excepcional

Datos
Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...
71

Advertencia
Divide and Conquer est muy bien... ...pero despues de descomponer hay que integrar Divide to Conquer and reunite to rule M. Jackson Hay que poder razonar sobre la composicin...

73

Descomposicin de software
Mdulos
Agrupa estructuras de datos y cdigo (y posiblemente otros mdulos) Entidad esttica A veces, separa Interfaz de Implementacin
A veces, es compilable de manera independiente
Es una unidad de trabajo para desarrollo Interfaz bien definida

Componentes

Entidades run-time Descomposicin para cumplir con ciertos requerimientos no funcionales distintos a los mdulos (performance, distribucin, tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).
74

Abstraccin
Suprimir detalles de implementacin permite
Posponer ciertas decisiones de detalle que ocurren a distintos niveles de anlisis Simplificar el anlisis, comprensin y justificacin de la decisin de diseo

Tipos de Abstraccin
Procedural ej. Funciones, mtodos, procedimientos Datos ej. TADs, modelos de componentes Control ej. loops, iteradores, frameworks y multitasking
75

Distintos tipos de abstracciones

76

Acoplamiento
Grado de dependencia del mdulo sobre otros mdulos y en particular las decisiones de diseo que estos hacen Generalmente correlaciona inversamente con cohesin Alto acoplamiento generalmente conlleva
Bajo/Dbil acoplamiento y Alta Cohesin Propagacin de cambios cuando se altera un mdulo Mdulos son difciles de entender aisladamente Reuso y testeo de mdulos es difcil ya que se requieren otros mdulos Un mdulo usa un tipo de otro mdulo Si un mdulo usa un servicio de otro mdulo Si un mdulo es un submdulo de otro Tradeoff...

Acoplamiento se incrementa si

Bajo acoplamiento puede significar peor performance

80

Tipos de Acoplamiento
Ordenado de mayor a menor (segun E. Yourdon y L. Constantine...) Contenido Comn
Cuando un mdulo modifica o confa en el lo interno de otro ej. acceso a datos locales o privados Cuando comparten datos comunes ej. una variable global Cuando comparten aspectos impuestos externamente al diseo. ej. formato de datos, protocolo de comunicacin, interfaz de dispositivo. Cuando un mdulo controla la lgica del otro ej. pasndole un flag de comportamiento). Cuando comparten una estructura de datos pero cada uno usa slo una porcin Paso de todo un registro cuando el mdulo slo necesita una parte. Mdulos se comunican a travs de datos en parmetros ej. llamado de funciones de otro mdulo Mdulos se comunican a travs de mensajes. Posiblemente no se conocen explcitamente
81

Externo Control

Estampillado (Stamp) Datos

Mensajes

Information Hiding / Encapsulamiento

Esconder las decisiones de diseo que pueden llegar a cambiar Minimizar el impacto de cambios futuros Minimizar la informacin en la interfaz Informacin a abstraer/esconder

Representacin de datos Algoritmos Formatos de entrada y salida Interfaces de bajo nivel Separacin de polticas y mecanismos Decisiones estructurales de ms bajo nivel Aspectos funcionales

82

Programacin basada en interfases

Como usuario de una abstraccin, es fundamental no depender de los detalles de la implementacin
Ejemplos
Estndares de jure vs. Implementaciones Estndares de facto vs. variaciones Especificacin vs. Implementacin Interfases (OO) vs. Clases concretas

83

Dependency Inversion Principle

Depend upon Abstractions. Do not depend upon concretions. Objetivo: Hacer un diseo ms flexible, enfocando el diseo a interfaces o clases abstractas, en lugar de a clases concretas.

84

Interface Segregation Principle

Many client specific interfaces are better than one general purpose interface. Objetivo: Separar interfaces para minimizar dependencias.

85

Liskov Substitution Principle

Un principio pensado para lenguajes de programacin con herencia... Subclasses should be substitutable for their base classes Una subclase puede ser usada donde su clase base es usada.

86

Cohesin
Del diccionario
cohesin. (Del lat. cohaesum, supino de cohaerre, estar unido). cohesion. the action or fact of forming a united whole
1. f. Accin y efecto de reunirse o adherirse las cosas entre s o la materia de que estn formadas.

Grado de [foco | cun bien trabajan juntos | coherencia | unin] que tienen los distintos elementos de un mdulo Alta cohesin tiende a proveer:
Robustez Confiabilidad Reusabilidad Comprensibilidad Testeabilidad Mantenibilidad

87

Tipos de Cohesin
Ordenado de peor a mejor (segn E. Yourdon y L. Constantine en los 70s) Coincidental
ej. mis funciones de uso frecuente, utils.lib

Lgico

Temporal

Existe una categora lgica que agrupa elementos aunque hagan cosas muy distintas ej. todas las rutinas de I/O Agrupadas por el momento en que se ejecutaran ej. Funciones que atajan un error de output, crean un error en un log y notifican al usuario Agrupadas por pertenecer a una misma sequencia de ejecucin o poltica. ej. funciones que chequean permisos y abren archivos Agrupadas por operar sobre los mismo datos. ej. objetos, operaciones sobre clientes. Agrupadas porque el output de uno es el input de otro Agrupadas porque contribuyen a una tarea bien definida del mdulo Ed dice que estos son aceptables

Procedural

Comunicacional

Secuencial
Funcional

88

Single Responsibility Principle

A class should have only one reason to change.
Objetivo: Obtener un alto grado de cohesin. Una clase debe tener una y solo una responsabilidad.

89

Extensibilidad y Open/Closed Principle

Los requerimientos cambian. El diseo debe poder acomodar estos cambios. Un diseo extensible debe poder ser extendido con facilidad para incorporar nueva funcionalidad The open/closed principle
Software entities should be open for extension but closed for modification La idea es que la funcionalidad existente no debe tocarse para no romper cdigo existente, slo agregar. ej. Capacidad de lidiar con nuevos tipos de eventos
90

The Open Closed Principle usando Polimorfismo

91

Preguntas para la Buena Modularizacin

Hay una jerarqua de mdulos donde mdulos grandes estn descompuestos en ms pequeos? Cada mdulo es comprensible de manera independiente Qu cambios de requerimientos podran implicar un cambio en el mdulo? Qu impacto tiene un pequeo cambio en un mdulo a otros? Qu impacto tiene el mal funcionamiento de un mdulo sobre otros? Es excesivo el nmero de mdulos con que un mdulo se comunica (fan-out)? Es excesivo el nmero de mdulos que utilizan al mdulo (fan-out)? La interfaz de un mdulo revela demasiado? Podra abstraerse? Es evidente del cdigo cuando dos mdulos se comunican? ...
Interface Segregation Principle: Many specific interfaces are better than a general one.
The Single Responsability Principle: A module should have only one reason to change

92

Design Patterns
Gamma, Helm, Johnson & Vlissides, 1995 (Aka The gang of four) Soluciones esquemticas (buen diseo) a problemas recurrentes en el desarrollo de software OO Catlogo de 23 patrones:
fenmeno de definicin terminolgica

Los Design Patterns se suponen que incorporan los principios de diseo que vimos
93

Design Patterns
La descripcin de un patrn de diseo debe incluir:
Nombre: Debe ser significativo Problema: una descripicin del problema atacado por el patrn Contexto: precondiciones bajo las que puede ocurrir Fuerzas: restrciciones y cuestiones que la solucin debe tratar Solucin: relacin estticas y dinmicas entre los componentes del patrn. La solucin resuelve las fuerzas en el contexto dado Ms
Ejemplos de uso Patrones relacionados Otros nombres usados del patrn Ejemplo en cdigo

94

Design Patterns
Tipos de Patterns:
De Creacin: soluciones flexibles para la creacin de instancias (e.g., abstract factory, singleton, etc.) Estructurales: soluciones de organizacin (herencia, composicin, agregacin, asociacin) de clases e interfaces para la extensibilidad y cambio (ej., composite, bridge, facade, adapter, etc.) De comportamiento: soluciones para la asignacin de responsabilidades y diseo de algoritmos. Muestran relacin esttica y comunicacin (ej., command, interpreter, mediator, observer, memento, etc. )

95

Design Pattern: Singleton

Nombre: Singleton Problema: Cmo definir una clase que debe tener una sola instancia accesible desde toda la aplicacin. Contexto: En algunas aplicaciones es importante que la clase tenga exactamente una instancia. Una aplicacin de procesamiento de ventas podra tratar con ventas de una sola compaa y necesitar datos de la misma almacenado en un objeto que sera el nico de la clase. Fuerzas: Usar una variable global no es un buen diseo. Otra opcin es no crear instancias sino usar mtodos y atributos estticos pero no es es una buena solucin para explotar el polimorfismo sobre sublases singleton y require un conocimiento global del tratamiento de la instancia como singleton.
96

Design Pattern: Singleton

Solucin:Crear un mtodo esttico GetInstance(). Cuando accede por primera vez crea la instancia y devuelve una referencia. Las otra veces que es accedido retorna esa referencia. El patrn ofrece las siguientes ventajas y desventajas.

97

Design Pattern: Singleton

Solucin de Will Pugh (Thread Safe y Laizy load)

public class Singleton { // Protected constructor is sufficient to suppress unauthorized calls to the constructor protected Singleton() {}
/** * SingletonHolder is loaded on the first execution of Singleton.getInstance() or the first access to SingletonHolder.instance , not before. */ private static class SingletonHolder { private final static Singleton instance = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.instance; } }
98

Design Patterns

99

Design Patterns

100

Design Patterns

101

Design Patterns

102

Design Patterns

103

Design Patterns

104

Design Patterns

105

Design Patterns

106

Design Patterns

107

Design Patterns

108

Design Patterns

109

Design Patterns
Strategy

Relacin con el Open-Close principle

110

Design Patterns

111

Design Patterns

112

Design Patterns

113

Cundo usar los Design Patterns

Hay un pattern para el problema Propone una solucin mejor No hay una solucin ms simple El contexto del problema es consistente con el del pattern Las consecuencias de usarlo son aceptables

114

Evaluacin de Diseos
3 grandes tipos de evaluacin
Requerimientos Requerimientos Requerimientos

Diseo

Diseo

Diseo

Cdigo

Cdigo

Cdigo

115

Algunos Errores Comunes (1/2)

Diseo Depth First
Slo satisface algunos requerimientos

Refinamiento directo de la especificacin de requerimientos

Puede llevar a un diseo ineficiente

Olvidarse de cambios a futuro

Disear para extensin (y contraccin!)

Disear demasiado en detalle

Introduce demasiadas restricciones a implementacin es muy caro, no vale la pena

Disear exclusivamente top-down

Primero los requerimientos crticos! No todo lo vamos a construir. Seleccin de COTS influye en la descomposicin

116

Algunos Errores Comunes (2/2)

Diseo documentado ambiguamente
Interpretado incorrectamente en tiempo de implementacin

Decisiones de diseo indocumentadas

Diseadores son necesarios durante la implementacin

Decisiones de diseo sin justificacin documentada

Cambios mas adelante, aparentemente inofensivos, rompen el diseo

Diseo inconsistente
Mdulos funcionan, pero no encajan Divide to conquer, reunite to rule

117

Ejes para crticas de diseo

Coorreccin: fallas sintcticas y semnticas Completud: tareas relevantes de diseo incompletas Consistencia: contradicciones internas del diseo Optimizacin: mejores opciones para los parmetros de diseo Pertinencia: decisiones soportadas por requerimientos Alternativas: otras elecciones para una decisin de diseo Evolucin: asuntos que comprometen futuros cambios Presentacin: uso torpe de la notacin Herramientas: otras herramientas que podran ser usadas en una decisin de diseo Experiencia: recordar experiencias pasadas relevantes Organizacional: interses de otros stakeholders

121

Mtricas de Software
1970s: Intentos para definir criterios cuantitativos simples de complejidad del sofwtare y otras calidades Halstead Complexity Measures Program Length = total operators + total operands Program Vocabulary = total distinct operators + total distinct operands Volume = Program Length * (log2Program Vocabulary) Difficulty = (total distinct operators/2) * (total operands/total distinct operands) Effort = Difficulty * Volume McCabe Complexity Measure Cyclomatic Complexity = edges in call graph nodes in call graph + connected components COCOMO modelo de costo para la estimacin de costo, esfuerzo y calendario

122

Crtica a las mtricas: Weyuker et.al.

Weyuker y otros observaron que la mayora de las mtricas fallaban en cumplir algunas propiedades obvias y deseables Weyuker defini 9 propiedades deseables Propiedad 3: Detalles de Deseo son importantes Dos clases con la misma funcionalidad no deberan necesariamente tener el mismo valor para la mtrica Propiedad 4: Monotona La mtrica para una combinacin de clases no puede dar menos que ninguna de las mtricas de las componentes Propiedad 6: La interaccin de clases incrementa la complejidad El valor de la mtrica de un par de clases que interactuan es mayor a la suma de los valores individuales
Shyam R. Chidamber, Chris F. Kemerer, A Metrics Suite for Object Oriented Design, IEEE

Transactions on Software Engineering, vol. 20, no. 6, pp. 476-493, Jun. 1994

123