Diseño de Software

Ejemplo Diseño de Software

2

Ejemplo Diseño de Software

3

Ejemplo Diseño de Software

4

Ejemplo Diseño de Software

5

Ejemplo Diseño de Software

6

Diseño de Software

RequerimientosRequerimientos

Arquitectura/Diseño de SoftwareArquitectura/Diseño de Software

• Puente entre mundos

Implementaciones

7

Puente entre mundos• Fronteras difusas a diferencia de otras disciplinas…

Recordatorio: La relación entre el problema y soluciónproblema y solución

Dependencia de la DependienteIndependiente Dependencia de la implementación

DependienteIndependiente

Menos Info

Nivel de CompletitudCompletitud

Mas Info

Enunciado de laImplementación

Enunciado delProblema

8

Mas Info

Requerimientos y Diseño: Una Visión Top-Down

RequerimientosSistemaSistema

Top-Down

Requerimientos

Design

SubsistemaSubsistema Requerimientos

Design

SubsistemaSubsistema

CC Requerimientos

Design

ComponenteComponente

Ojo: Tomar decisiones de bajo nivel es 9

• Ojo: Tomar decisiones de bajo nivel es compatible con esta visión...

Frenado del Airbus A320

Sistema de F d Ai b R d S

giro pulsos

Sensor alt

Frenado Airbus A320

Ruedas Sensorpulsos

Sensorpeso

M d prendido y

señal de habilitado y deshabilitado de aceleración de reversa

Controlador de Aceleración de

Reversa

Motor de Reversa

ñ l d

apagado de motor

Pil t

señales de prendido y apagado de motor

10

Piloto

Frenado del Airbus A320

Sistema de F d Ai b R d S

giro pulsos Frenado Airbus A320

Ruedas Sensorpulsos

M d prendido y

señal de habilitado y deshabilitado de aceleración de reversa

Controlador de Aceleración de

Reversa

Motor de Reversa

ñ l d

apagado de motor

Pil t

señales de prendido y apagado de motor

11

Piloto

Diseño de Software• Los Sistemas de Software Intensivo son entes

complejos– millones de líneas de código, variables, posibles estados, etc...

• ¿Cómo lidiamos con la complejidad?– Estructura y Abstracción...– ...sí, pero cómo? qué abstracciones? qué relaciones?...

• Diseñar involucra estructurar la solución utilizando abstracciones y relaciones entre las abstracciones

i d s d :apropiadas para poder:• Documentar y Comprender la propuesta de solución• Razonar sobre su grado de adecuación c.r.a los requerimientos• ComunicarlaComunicarla• Implementarla• Verificar/Validar el producto final• Modificar/Adaptar la solución en la medida que cambien los

requerimientosrequerimientos

Diseño de Software

• Guía en la concepción de productos de software (requerimientos complejos, integración de componentes existentes, tecnología, familias de productos etc )familias de productos, etc.)

• Drivers: atributos de calidad/requerimientos no funcionales y restricciones de proyecto y tecnología– Usualmente en tensión

• A diferencia del mundo de los requerimientos:D t t d l d d l l ió ( i l – Denota conceptos del mundo de la solución (pero incluye fenómenos de la interfase mundo máquina)

– En general se describen propiedades localizadas (unidad, componente, módulo) y son de naturaleza operacionalp , ) y p

13

Objetivos de la Etapa de Diseño

• Descomponer el sistema en entidades de diseño “más chicas”a– ej qué paquetes, clases, módulos, componentes...

• Determinar la relación entre entidades.ej identificar dependencias – ej. identificar dependencias

• Fijar mecanismos de interacción– ej. memoria compartida, RPC, llamadas a función

• Especificar interfaces y funcionalidad de entidades– ej. operaciones y sus aridades, descripción formal/informal de

comportamientop• Identificar oportunidades para el reuso

– tanto top-down como bottom-up• Documentar todo lo anterior junto con la • Documentar todo lo anterior junto con la

fundamentación de las elecciones

Metodología de Diseño: Visión “Macro”

• El foco en el proceso de Diseño pasa:d l t k h ld t ( li t i t ) – de los stakeholders externos (cliente, usuario, etc.) a los internos (desarrolladores, testers, etc.)

– de Qué y Porqué a Qué y Cómode Qué y Porqué a Qué y Cómo• Pasos Macro

– Diseño Arquitectónico (o Arquitectura)q ( q )– Diseño Detallado (o Diseño)

• Proceso iterativo – Decisiones clave primero

• ej. Requerimientos no-funcionales críticos¿Q é bi ?• ¿Qué va a cambiar?

El Diseño Detallado y la Tecnología de Construcción de Soluciones

• Decisiones, patrones, notaciones, modelos y “blueprints” de diseño pueden estar blueprints de diseño pueden estar fuertemente impactados por el paradigma de la tecnología que se usa en la solución, tecnología que se usa en la solución, (especialmente si hablamos de un diseño detallado)

• Dónde está el límite entre codificar y diseñar?…

• Veremos el caso cuando hablemos de POO

19

Introducción a POOIntroducción a POO

20

DocumentaciónDocumentación

21

VistasVistas• La descripción de un sistema complejo

no es unidimensional no es unidimensional

E l b ál l i t • Es clave saber cuáles son las vistas relevantes y vincularlas

• Relevancia: depende del propósito (e.g., i l i ió d i l t ió enunciar la misión de implementación,

análisis de atributos de calidad, generación automática de código

22

generación automática de código, planificación, etc.)

Vistas y stackeholdersVistas y stackeholders• La metáfora de D.Garlan

I do bones,I do bones, not hearts.

These views are needed by the cardiologist…

…but will these views work for the orthopedist?the orthopedist?

D.Garlan

23

VistasVistas• Las vistas exponen atributos de calidad

dif t den diferente grado:– Vista modular: portabilidad…– Vista de deployment: performace,

confiabilidad…

• Enfatizan aspectos e ignoran otros para que el problema sea abordable

24

• Ninguna vista es “EL” diseño

Vistas Clásicas• Vista Modular: ¿Cómo agrupamos el código?

– métodos, procedimientos, clases, librería, DLLs, APIs, paquetes, módulos...

– usa, subclase, contiene, depende-de,...– diagrama de clases y de paquetes

• Vista “Run-time” o de Componentes y Conectores: ¿Cóm s n l s ntid d s run tim ?¿Cómo 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 colaboración maquinas de estado, diagrama de secuencia y de colaboración,

diagrama de objetos, diagrama de componentes• Vista de Deployment (de Despliegue): ¿Dónde residen

las distintas partes?– Recursos y repositorios además de entidades dinámicas o estáticas– procesos ejecuta-sobre server, código de módulos almacenado en

directorio, equipo de trabajo desarrolla paquete,...– diagrama de despliegue, ...

25

g p g ,

Ejemplo: Módulos vs ComponentesEjemplo: Módulos vs. Componentes• Módulos: entidad en tiempo de diseño.

E f ti l i t Enfatiza en encapsulamiento: “information hiding” e interfaces.

• Componentes: tienen entidad en tiempo p pde ejecución y de despliegue

26

Alternando caracteres: Module View

Alternar mayúsculas con minúsculas a partir de un stream de caracteres

main“sofTWareArchitecture” =>“SoFtWaReArCiTeCtUrE”

split lower upper mergep pp g

Referencias

config input/outputinput/output

Modularización en función del

Referencias

ModuloUsos

27

Modularización en función del a relación de uso

Alternando caracteres: C&C View

lower

split merge

upperReferencias

Componentes y Conectores(Pipe & Filter)

FilterPipeBinding

28

(Pipe & Filter) g

Diagramas y vistas en UMLDiagramas y vistas en UML

29

Vista Modular (Diagrama de Clases)

Este ejemplo enfatiza la agrupaciEste ejemplo enfatiza la agrupación de métodos y datos en ón de métodos y datos en clases además de asociaciones (dependencias estructurales) y clases además de asociaciones (dependencias estructurales) y relaciones de herencia y contienerelaciones de herencia y contiene--aa

30

Vista Modular (2)Otros niveles de abstracciOtros niveles de abstracción...ón...

31

Vista Run-Time (Estructura: componentes & conectores…Objetos y links)j y )

32

Ejemplo de Vista Run-Time (Comportamiento)( p )

33

Ejemplo de Vista Run-Time (Estructura)

Poner ejemplo con multiples instancias de un tipoPoner ejemplo con multiples instancias de un tipo

34

Ejemplo de Vista de Deployment (1)

35

Ejemplo de Vista de Deployment (2)

36

Generalizando los tipos de vistaGeneralizando los tipos de vista

Mas allá de UML

37

Módulo

• Concepto proveniente de los 60’s y 70’sConcepto proven ente de los 60 s y 70 s

• Basado en la noción de unidad de • Basado en la noción de unidad de software que provee servicios a través de una interfaz bien definidade una interfaz bien definida

• La manera de modularización suele determinar características como

38

modificabilidad, portabilidad y reuso

Elementos

• Un módulo es una unidad de código que Un módulo es una un dad de cód go que implementa un conjunto de responsabilidadesresponsab l dades

– Una clase una colección de clases una capa – Una clase, una colección de clases, una capa o cualquier descomposición de la unidad de códigocód go

39

RelacionesRelaciones

• Se distinguen tres tipos de relacionesg p

– es parte de que define la relación entre un p qu f n n n unsubmódulo A y un módulo B

– depende de que define la dependencia entre dos módulos A y B

– es un que define una relación de generalización entre un modulo específico y

40

generalización entre un modulo específico y otro más general

Module Viewtype: utilidad• Análisis

– A partir de estas vistas, es posible realizar par r a a , p r a zar distinto tipos de análisis Por ejemplo:

• Trazabilidad de Requerimientos– Analiza como los requerimientos funcionales q

son soportados por las responsabilidades de los distintos módulos

• Análisis de ImpactoP it d i l f t d l s

41

– Permite predecir el efecto de las modificación del sistema

Module Viewtype: utilidad

• ComunicaciónComunicación– Estas vistas pueden ser utilizadas para

explicar las funcionalidades del sistema a palguien no familiarizado con el mismo

– Distintos niveles de granularidad, presentan una descripción top-down de las responsabilidades del sistema

42

Module Viewtype: cuando no

• Es dificultoso utilizar este tipo de vistas para realizar inferencias sobre el comportamiento realizar inferencias sobre el comportamiento del sistema durante su ejecución

• Dada su naturaleza, no es de mucha utilidad para la realización de análisis de performance para la realización de análisis de performance, confiabilidad u otras características asociadas al tiempo de ejecuciónp j– Múltiples instancias de objetos– Relaciones existentes sólo en tiempo de ejecución

43

Componentes y Conectores: EjemplosComponentes y Conectores: Ejemplosp y j pp y j p

44

ElementosElementos

• Son entidades con manifestación runtime que consumen recursos de ejecución y contribuyen consumen recursos de ejecución y contribuyen al comportamiento en ejecución del sistema

• La configuración del sistema es un grafo conformado por la asociación entre conformado por la asociación entre componentes y conectores

• Las entidades runtime son instancias de tiposde conector o componente

45

de conector o componente

UtilidadUtilidad• ¿Cuales son los componentes ejecutables y

como interactúan?como interactúan?

• ¿Cuáles son los repositorios y que • ¿Cuáles son los repositorios y que componentes los acceden?

• ¿Qué partes del sistema son replicadas y cuantas veces?cuantas veces?

• ¿Cómo progresan los datos a los largo del

46

¿Cómo progresan los datos a los largo del sistema a medida que éste se ejecuta?

UtilidadUtilidad

• ¿Qué protocolos de interacción son usados ¿Qué protocolos de interacción son usados por las entidades comunicantes?

• ¿Qué partes del sistema se ejecutan en paralelo?p

• ¿Cómo la estructura del sistema puede ¿ m a tructura t ma pu cambiar a medida que se ejecuta?

47

PropiedadesPropiedadesppConfiabilidad

P d l d t i l f i lid d d l Podemos usarlo para determinar la funcionalidad del sistema en su conjunto

PerformanceTiempo de respuesta / cargaTiempo de latencia y volumen de procesamientoTiempo de latencia y volumen de procesamiento

Recursos requeridosNecesidades de almacenamientoNecesidades de procesamiento

48

PropiedadesPropiedadespp• Funcionalidad

– Funciones mapeadas sobre el componenteFunciones mapeadas sobre el componente

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

• SeguridadEncriptaEncriptaAuditaAutentica

49

Para lo que NO sirvePara lo que NO sirveqq

• No se debe usar para modelar elementos de • No se debe usar para modelar elementos de diseño que no tienen comportamiento runtime

• Una clase no es un componente. Un componente no representa de ninguna manera componente no representa de ninguna manera una visión estática de diseño

50

ResumenResumenConectoresConectoresConectoresConectores

• C&C viewtype define modelo consistente de elementos que tienen presencia runtimeelementos que tienen presencia runtime

C&C i t i l i f ió s b l s • C&C viewtype incluye información sobre los caminos de interacción entre los componentes

• Los componentes tienen interfaces llamadas portsports

• Los conectores tienen interfaces ll m d s r l s

51

• Los conectores tienen interfaces llamadas roles

Ejemplo: IP 2000 SiSiemens

Source: Applied Software Architecture (Nord, Hofmeister)pp f ( , f )(Escaneado)

52

Visión ConceptualVisión Conceptual

53

Características del C&C• Los componentes y conectores representan entidades

de tiempo de ejecuciónde tiempo de ejecución• Los ports son las interfaces de comunicación de los

componentes agrupando señales de entrada y salida p g p yque siguen algún tipo de secuenciamiento (protocolo)

• Los conectores tienen como función mediar en la i ió interacción entre componentes

• Los conectores pueden representar formas complejas de interacción más allá del simple call return de interacción más allá del simple call return sincrónico

• El conector debería especificar el protocolo bajo el

54

El conector debería especificar el protocolo bajo el cual los componentes interactúan para cada uno de sus roles

Vista de Módulos

55

Vista de MódulosDescomposición

56

Vista de MódulosD óDescomposición

57

Visión ConceptualC&C

58

C&C y Comportamiento

59Sebastian Uchitel

Visión ConceptualC&C - Descomposición

60

Visión ConceptualComportamiento

61

Visión Conceptual&C&C

62

Visión Conceptual P k PConector PacketPipe

63

Visión de EjecuciónVisión de Ejecución

64

Principios de DiseñoPrincipios de Diseño

65

Herramientas Conceptuales: Principios

• Decomposición– Divide & Conquer (piezas conocidas y tratables)q (p y )– Separación por niveles de abstracción y/o máquinas virtuales– Separación por aspectos, etc.

• ModularidadModularidad– Colección bien definida de partes e interacciones bien delimitadas

• Ocultamiento de la informaciónConfinar el impacto del cambio (de un módulo)– Confinar el impacto del cambio (de un módulo)

– El ciente de un módulo no debe conocer los detalles de diseño difíciles o que pueden cambiar

• EncapsulamientoEncapsulamiento– Clara separación de interface e implementación– Mecanismos para no conocer ni usar más de lo que la interface promete

• Abstracción

66

• Abstracción– Foco en lo esencial

Principios (Cont.)• Explotar el Polimorfismo

– tratamiento uniforme de una entidad que puede tener múltiples q p pformas

– Sustitución Liskov/Wing• Inversión de dependencia/controlp

– Depender en abstracciones e interfaces en lugar de clases concretas– Ser invocado en lugar de invocar para reuso de abstracciones de

control• Segregación de interfaces• Una sola responsabilidad (cohesion)• Open-CloseOpen Close• Detección de puntos de variabilidadAdvertencia: Estos principios han nacido con la extensibilidad y la

modificabilidad como atributos de calidad preponderantes

67

modificabilidad como atributos de calidad preponderantes

Estrategias de Descomposición• Problemas que sabemos resolver

– Ej. M. Jackson’s Problem Frames: Control, Visualizacion, Correspondencia etcCorrespondencia, etc

• Pasos de ejecución– Ej. Filtros de procesamiento de imagenesj p g

• Tempo de ejecución– Ej. Acumulación vs Utilización de Información

F i l• Funcional– Ej. Facturación, Compras y Sueldos

• Modos de OperaciónModos de Operación– Normal vs Excepcional

• Datos

68

– Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...

Advertencia

• Divide and Conquer está muy bien...• pero despues de descomponer hay que • ...pero despues de descomponer hay que

integrar

• “Divide to Conquer and reunite to rule” M. JacksonJackson

• Hay que poder razonar sobre la composición• Hay que poder razonar sobre la composición...

70

Descomposición de software

• Módulos– Agrupa estructuras de datos y código (y posiblemente otros

módulos) – Entidad estática– A veces, separa Interfaz de Implementación

• Interfaz bien definida– A veces, es compilable de manera independientep p

• Es una unidad de trabajo para desarrollo

• ComponentesComponentes– Entidades run-time– Descomposición para cumplir con ciertos requerimientos no

funcionales distintos a los módulos (performance distribución

71

funcionales distintos a los módulos (performance, distribución, tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).

Abstracción

• Suprimir detalles de implementación permite– Posponer ciertas decisiones de detalle que ocurren a distintos

niveles de análisis– Simplificar el análisis, comprensión y justificación de la

decisión de diseño• Tipos de Abstracción

– ProceduralProcedural• ej. Funciones, métodos, procedimientos

– Datosj TAD d l d t• ej. TADs, modelos de componentes

– Control• ej. loops, iteradores, frameworks

72

y multitasking

Distintos tipos de abstracciones

73

Information Hiding / Encapsulamiento

• Esconder las decisiones de diseño que pueden llegar a cambiarllegar a cambiar

• Minimizar el impacto de cambios futuros

• Minimizar la información en la interfaz• Información a abstraer/esconderf m

– Representación de datos– Algoritmos

F d d lid– Formatos de entrada y salida– Interfaces de bajo nivel– Separación de políticas y mecanismos

74

Separación de políticas y mecanismos– Decisiones estructurales de más bajo nivel– Aspectos funcionales

Cohesiónl d• Del diccionario

– cohesión. (Del lat. cohaesum, supino de cohaerēre, estar unido).

ó í1. f. Acción y efecto de reunirse o adherirse las cosas entre sí o la materia de que están formadas.

– cohesion. the action or fact of forming a united whole

• Grado de [foco | cuán bien trabajan juntos | coherencia | unión] que tienen los distintos elementos d ód lde un módulo

• Alta cohesión tiende a proveer:– Robustez– Confiabilidad– Reusabilidad – Comprensibilidad

78

p– Testeabilidad– Mantenibilidad

Tipos de CohesiónOrdenado de peor a mejor (según E. Yourdon y L. Constantine en los 70’s)• Coincidental

– ej mis funciones de uso frecuente utils lib– ej. mis funciones de uso frecuente, utils.lib• Lógico

– Existe una categoría lógica que agrupa elementos aunque hagan cosas muy distintas– ej. todas las rutinas de I/O

• Temporal• Temporal– 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

• ProceduralAgrupadas por pertenecer a una misma sequencia de ejecución o política– Agrupadas por pertenecer a una misma sequencia de ejecución o política.

– ej. funciones que chequean permisos y abren archivos• Comunicacional

– Agrupadas por operar sobre los mismo datos.ej objetos operaciones sobre clientes– ej. objetos, operaciones sobre clientes.

• Secuencial– Agrupadas porque el output de uno es el input de otro

• FuncionalA d t ib t bi d fi id d l ód l

Ed diceque estos

son aceptables

79

– Agrupadas porque contribuyen a una tarea bien definida del módulo

Single Responsibility Principle

• “A class should have only one reason to change.”

• Objetivo: Obtener un alto grado de cohesión. Una clase debe tener una y solo una responsabilidad debe tener una y solo una responsabilidad.

80

Acoplamiento

• Grado de dependencia del módulo sobre otros módulos y en particular las decisiones de diseño que estos hacen

• Generalmente correlaciona inversamente con cohesión– Bajo/Débil acoplamiento y Alta Cohesión

• Alto acoplamiento generalmente conllevaP d b d l d l– Propagación de cambios cuando se altera un módulo

– Módulos son difíciles de entender aisladamente– Reuso y testeo de módulos es difícil ya que se requieren otros

módulosmódulos• Acoplamiento se incrementa si

– Un módulo usa un tipo de otro módulo– Si un módulo usa un servicio de otro móduloSi un módulo usa un servicio de otro módulo– Si un módulo es un submódulo de otro

• Bajo acoplamiento puede significar peor performance– Tradeoff...

81

Tipos de AcoplamientoOrdenado de mayor a menor (segun E. Yourdon y L. Constantine...)• Contenido

– Cuando un módulo modifica o confía en el lo interno de otro– ej. acceso a datos locales o privados

• Común– Cuando comparten datos comunes– ej. una variable global

• Externo– Cuando comparten aspectos impuestos externamente al diseño.– ej. formato de datos, protocolo de comunicación, interfaz de dispositivo.

• Control– Cuando un módulo controla la lógica del otro– ej. pasándole un flag de comportamiento).

• Estampillado (Stamp)– Cuando comparten una estructura de datos pero cada uno usa sólo una porciónp p p– Paso de todo un registro cuando el módulo sólo necesita una parte.

• Datos– Módulos se comunican a través de datos en parámetros– ej. llamado de funciones de otro módulo

82

j• Mensajes

– Módulos se comunican a través de mensajes. Posiblemente no se conocen explícitamente

Programación basada en interfases

• Como usuario de una abstracción es abstracción, es fundamental no depender de los detalles de la impl m nt ciónimplementación

• Ejemplos– Estándares de jure vs.

I l iImplementaciones– Estándares de facto vs.

variacionesEsp ifi ión s – Especificación vs. Implementación

– Interfases (OO) vs. Clases concretas

83

concretas

Dependency Inversion Principle

• “Depend upon Abstractions. Do not depend upon concretions.”• Objetivo: Hacer un diseño más flexible, enfocando el diseño a j m f , f

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”general purpose interface .

• Objetivo: Separar interfaces para minimizar dependencias.

85

Liskov Substitution Principle• Un principio pensado para lenguajes de programación con

herencia...“S b l h ld b b tit t bl f th i b l ”• “Subclasses should be substitutable for their base classes”

• Una subclase puede ser usada donde su clase base es usada.

86

Extensibilidad y Open/Closed Principle

• Los requerimientos cambian. El diseño debe poder acomodar estos cambiospoder acomodar estos cambios.

• Un diseño extensible debe poder ser extendido con facilidad para incorporar nueva con facilidad para incorporar nueva funcionalidad

• The open/closed principleThe 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 código existente, sólo agregar

87

agregar.– ej. Capacidad de lidiar con nuevos tipos de eventos

The Open Closed Principle usando PolimorfismoPolimorfismo

88

Preguntas para la Buena ModularizaciónModularización

• Hay una jerarquía de módulos donde módulos grandes están descompuestos en más pequeños?

• Cada módulo es comprensible de manera independiente• Qué cambios de requerimientos podrían implicar un cambio en el

módulo?Th Si l R bilit P i i l A d l h ld h l – The Single Responsability Principle: A module should have only one reason to change

• Qué impacto tiene un pequeño cambio en un módulo a otros?• Qué impacto tiene el mal funcionamiento de un módulo sobre otros?• Qué impacto tiene el mal funcionamiento de un módulo sobre otros?• Es excesivo el número de módulos con que un módulo se comunica

(fan-out)?• Es excesivo el número de módulos que utilizan al módulo (fan-out)? Es excesivo el número de módulos que utilizan al módulo (fan out)?

– Interface Segregation Principle: Many specific interfaces are better than a general one.

• La interfaz de un módulo revela demasiado? Podría abstraerse?

89

• Es evidente del código cuando dos módulos se comunican?• ...

Design Patterns

• Gamma, Helm, Johnson & Vli id 1995 & Vlissides, 1995 (Aka The gang of four)

• Soluciones esquemáticas (buen diseño) a problemas recurrentes en el desarrollo de software OO

• Catálogo de 23 patrones: – fenómeno de definición terminológica

• Los Design Patterns se suponen que incorporan los principios de diseño que

90

p p p qvimos

Design Patterns

• La descripción de un patrón de diseño debe incluir:incluir:– Nombre: Debe ser significativo– Problema: una descripición del problema atacado por el patrón– Contexto: precondiciones bajo las que puede ocurrir– Fuerzas: restrciciones y cuestiones que la solución debe tratar– Solución: relación estáticas y dinámicas entre los componentes Solución: relación estáticas y dinámicas entre los componentes

del patrón. La solución resuelve las fuerzas en el contexto dado

– MásMás• Ejemplos de uso• Patrones relacionados• Otros nombres usados del patrón

91

p• Ejemplo en código

Design Patterns• Tipos de Patterns:

– De Creación: soluciones flexibles para la creación De Creación soluciones flexibles para la creación de instancias (e.g., abstract factory, singleton, etc.)

– Estructurales: soluciones de organización (herencia, ó ó ó ) d l i t f composición, agregación, asociación) de clases e interfaces

para la extensibilidad y cambio (ej., composite, bridge, facade, adapter, etc.)g p )

– De comportamiento: soluciones para la asignación de responsabilidades y diseño de algoritmos. Muestran relación estática y comunicación (ej Muestran relación estática y comunicación (ej., command, interpreter, mediator, observer, memento, etc. )

92

Design Pattern: Singleton• Nombre: Singleton• Problema: Cómo definir una clase que debe tener una

sola instancia accesible desde toda la aplicaciónsola instancia accesible desde toda la aplicación.• Contexto: En algunas aplicaciones es importante que la

clase tenga exactamente una instancia. Una aplicación g pde procesamiento de ventas podría tratar con ventas de una sola compañía y necesitar datos de la misma almacenado en un objeto que sería el único de la clasealmacenado en un objeto que sería el único de la clase.

• Fuerzas: Usar una variable global no es un buen diseño. Otra opción es no crear instancias sino usar métodos y

b á b l ó atributos estáticos pero no es es una buena solución para explotar el polimorfismo sobre sublases singleton y require un conocimiento global del tratamiento de la

93

y q m g minstancia como singleton.

Design Pattern: Singleton

• Solución:Crear un método estático GetInstance(). Cuando accede por primera vez crea la instancia y Cuando accede por primera vez crea la instancia y devuelve una referencia. Las otra veces que es accedido retorna esa referencia. El patrón ofrece las si ui nt s v nt j s d sv nt j s siguientes ventajas y desventajas….

94

Design Pattern: Singleton

Solución de Will Pugh (Thread Safe y Laizy load)

public class Singleton { // Protected constructor is sufficient to suppress unauthorized

calls to the constructor calls to the constructor protected Singleton() {}

/** * Si l t H ld i l d d th fi t ti f /** * SingletonHolder is loaded on the first execution of Singleton.getInstance() or the first access to SingletonHolder.instance , not before. */

i t t ti l Si l t H ld { private static class SingletonHolder { private final static Singleton instance = new Singleton(); }

public static Singleton getInstance() { return

95

SingletonHolder.instance; } }

Design Patterns

96

Design Patterns

97

Design Patterns

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

• Strategy

107

• Relación con el “Open-Close principle”

Design Patterns

108

Design Patterns

109

Design Patterns

110

Cuándo usar los Design Patterns

• Hay un pattern para el problema• Propone una solución mejor • No hay una solución más simpley p• El contexto del problema es consistente

con el del patterncon el del pattern• Las consecuencias de usarlo son

aceptablesaceptables

111

Evaluación de DiseñosEvaluación de Diseños• 3 grandes tipos de evaluación

RequerimientosRequerimientos Requerimientos

DiseñoDiseño Diseño

CódigoCódigo Código

112

Algunos Errores Comunes (1/2)

• Diseño Depth First– Sólo satisface algunos requerimientosSólo satisface algunos requerimientos

• Refinamiento directo de la especificación de requerimientos– Puede llevar a un diseño ineficiente

• Olvidarse de cambios a futuro– Diseñar para extensión (y contracción!)– Diseñar para extensión (y contracción!)

• Diseñar demasiado en detalle– Introduce demasiadas restricciones a implementación– es muy caro, no vale la pena

• Diseñar exclusivamente top-down– Primero los requerimientos críticos!

113

– Primero los requerimientos críticos!– No todo lo vamos a construir. Selección de COTS influye en la

descomposición

Algunos Errores Comunes (2/2)

• Diseño documentado ambiguamenteInterpretado incorrectamente en tiempo de implementación– Interpretado incorrectamente en tiempo de implementación

• Decisiones de diseño indocumentadas– Diseñadores son necesarios durante la implementaciónDiseñadores son necesarios durante la implementación

• Decisiones de diseño sin justificación documentada– Cambios mas adelante, aparentemente inofensivos, rompen el

diseño

• Diseño inconsistente• Diseño inconsistente– Módulos funcionan, pero no encajan– Divide to conquer, reunite to rule

114

Ejes para críticas de diseño

• Coorrección: fallas sintácticas y semánticas• Completud: tareas relevantes de diseño incompletasCompletud: tareas relevantes de diseño incompletas• Consistencia: contradicciones internas del diseño• Optimización: mejores opciones para los parámetros de

d ñdiseño• Pertinencia: decisiones soportadas por requerimientos• Alternativas: otras elecciones para una decisión de Alternativas: otras elecciones para una decisión de

diseño• Evolución: asuntos que comprometen futuros cambios

P ió d l ió• Presentación: uso torpe de la notación• Herramientas: otras herramientas que podrían ser

usadas en una decisión de diseño

118

• Experiencia: recordar experiencias pasadas relevantes• Organizacional: interses de otros stakeholders

Métricas 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 +

119

connected componentsCOCOMO modelo de costo para la estimación de costo, esfuerzo y

calendario

Crítica a las métricas: Weyuker et.al.

Weyuker y otros observaron que la mayoría de las métricas fallaban en cumplir algunas propiedades obvias y deseablesp g p p y

Weyuker definió 9 propiedades deseables

Propiedad 3: Detalles de Deseño son importantesp p» Dos clases con la misma funcionalidad no deberían necesariamente tener el

mismo valor para la métricaPropiedad 4: Monotonía» La métrica para una combinación de clases no puede dar menos que ninguna

de las métricas de las componentesPropiedad 6: La interacción de clases incrementa la complejidad» El valor de la métrica 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

120

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