Diseño de Software.

Presentación del tema: "Diseño de Software."— Transcripción de la presentación:

1 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 Ejemplo Diseño de Software

7 Arquitectura/Diseño de Software
Puente entre mundos Fronteras difusas a diferencia de otras disciplinas… Requerimientos Arquitectura/Diseño de Software Implementaciones build systems compositionally from parts assure that the system conforms to the architecture and has the desired properties use standard integration architectures reuse codified architectural design expertise reduce costs through product-lines

8 Frenado del Airbus A320 Sensor Sistema de Frenado Airbus A320 Ruedas
alt Sensor Sistema de Frenado Airbus A320 giro pulsos Ruedas Sensor Sensor peso señal de habilitado y deshabilitado de aceleración de reversa prendido y apagado de motor Motor de Reversa Controlador de Aceleración de Reversa señales de prendido y apagado de motor Piloto 8

9 Frenado del Airbus A320 Sistema de Frenado Airbus A320 Ruedas Sensor
giro pulsos Ruedas Sensor señal de habilitado y deshabilitado de aceleración de reversa prendido y apagado de motor Motor de Reversa Controlador de Aceleración de Reversa señales de prendido y apagado de motor Si tuvieramos cambiaramos la interfaz, tendriamos mas garanteias Piloto 9

10 Recordatorio: La relación entre el problema y solución
Independiente Dependencia de la implementación Dependiente Menos Info Camino de Exploración Nivel de Completitud Enunciado del Problema Enunciado de la Implementación Mas Info

11 Requerimientos y Diseño: Una Visión Top-Down
Sistema Design Requerimientos Subsistema Design Requerimientos Componente Design Ojo: Tomar decisiones de bajo nivel es compatible con esta visión...

12 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 apropiadas para poder: Documentar y Comprender la propuesta de solución Razonar sobre su grado de adecuación c.r.a los requerimientos Comunicarla Implementarla Verificar/Validar el producto final Modificar/Adaptar la solución en la medida que cambien los requerimientos

13 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.) 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: 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 operacional

14 Objetivos de la Etapa de Diseño
Descomponer el sistema en entidades de diseño “más chicas” ej qué paquetes, clases, módulos, componentes... Determinar la relación entre entidades. 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 comportamiento Identificar oportunidades para el reuso tanto top-down como bottom-up Documentar todo lo anterior junto con la fundamentación de las elecciones

15 Metodología de Diseño: Visión “Macro”
El foco en el proceso de Diseño pasa: de los stakeholders externos (cliente, usuario, etc.) a los internos (desarrolladores, testers, etc.) de Qué y Porqué a Qué y Cómo Pasos Macro Diseño Arquitectónico (o Arquitectura) Diseño Detallado (o Diseño) Proceso iterativo Decisiones clave primero ej. Requerimientos no-funcionales críticos ¿Qué va a cambiar?

16 Historia Simula 67 Programming Language (1967) First appearance of object-oriented concepts On the Criteria to Be Used in Decomposing Systems into Modules (Parnas, 1972)  Information hiding The Mythical Man-Month (Brooks, 1975)  Importance of maintaining conceptual integrity of the design  And concerns about the advisability of information hiding!

17 Historia Programming-in-the-Large versus Programming-in-the- Small (DeRemer & Kron, 1976)  “Structuring a large collection of modules to form a system is an essentially distinct and different intellectual activity from that of constructing the individual modules. … Correspondingly, we believe that essentially distinct and different languages should be used for the two activities.” Designing Software for Ease of Extension and Contraction (Parnas, 1979)  Program families  Uses relation

18 Historia No Silver Bullet: Essence and Accidents of Software Engineering (Brooks, 1985) “There is no single development, in technology or management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.” Must instead “grow great designers” And a concession to Parnas about information hiding! Foundations for the Study of Software Architecture (Perry & Wolf, 1992) Components, connectors, configurations Architectural styles Design Patterns (Gamma, Helm, Johnson, Vlissides, 1995)

19 El Diseño Detallado y la Tecnología de Construcción de Soluciones
Decisiones, patrones, notaciones, modelos y “blueprints” de diseño pueden estar fuertemente impactados por el paradigma de la 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

20 Introducción a POO

21 Documentación

22 Vistas La descripción de un sistema complejo no es unidimensional
Es clave saber cuáles son las vistas relevantes y vincularlas Relevancia: depende del propósito (e.g., enunciar la misión de implementación, análisis de atributos de calidad, generación automática de código, planificación, etc.) Poner gráfico de sistema oseo y sistema circulatorio

23 Vistas y stackeholders
La metáfora de D.Garlan …but will these views work for the orthopedist? I do bones, not hearts. These views are needed by the cardiologist… D.Garlan

24 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” diseño Mención a las palabras de Gamma : la diferencia entre la estructura del programa en tiempo de ejecución y la estructura del código (congelada en tiempo de compilación como jerarquía de clases vs objetos comunicándose)

25 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ó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, 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, ...

26 Ejemplo: Módulos vs. Componentes
Módulos: entidad en tiempo de diseño. Enfatiza en encapsulamiento: “information hiding” e interfaces. Componentes: tienen entidad en tiempo de ejecución y de despliegue Un módulo puede no ser deployable. Un compoenente se replica un módulo no Un módulo pude vivir en muchos componentes.

27 Alternando caracteres: Module View
Alternar mayúsculas con minúsculas a partir de un stream de caracteres “sofTWareArchitecture” => “SoFtWaReArCiTeCtUrE” main split lower upper merge config input/output Referencias Modulo Usos Modularización en función del a relación de uso

28 Alternando caracteres: C&C View
split lower upper merge Referencias Filter Pipe Binding Componentes y Conectores (Pipe & Filter)

29 Diagramas y vistas en UML

30 Vista Modular (Diagrama de Clases)
Este ejemplo enfatiza la agrupación de métodos y datos en clases además de asociaciones (dependencias estructurales) y relaciones de herencia y contiene-a

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

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

33 Ejemplo de Vista Run-Time (Comportamiento)

34 Ejemplo de Vista Run-Time (Estructura)
Poner ejemplo con multiples instancias de un tipo

35 Ejemplo de Vista de Deployment (1)

36 Ejemplo de Vista de Deployment (2)

37 Mezclando Vistas

38 Mezclando Vistas

39 Mezclando Vistas

40 Generalizando los tipos de vista
Mas allá de UML

41 Módulo Concepto proveniente de los 60’s y 70’s
Basado en la noción de unidad de software que provee servicios a través de una interfaz bien definida La manera de modularización suele determinar características como modificabilidad, portabilidad y reuso

42 Elementos Un módulo es una unidad de código que implementa un conjunto de responsabilidades Una clase, una colección de clases, una capa o cualquier descomposición de la unidad de código Un módulo se caracteriza enumerando sus responsabilidades

43 Relaciones Se distinguen tres tipos de relaciones
es parte de que define la relación entre un submó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 otro más general El estilo del módulo determinará el tipo de dependencia

44 Module Viewtype: utilidad
Análisis A partir de estas vistas, es posible realizar distinto tipos de análisis Por ejemplo: Trazabilidad de Requerimientos Analiza como los requerimientos funcionales son soportados por las responsabilidades de los distintos módulos Análisis de Impacto Permite predecir el efecto de las modificación del sistema

45 Module Viewtype: utilidad
Comunicación Estas vistas pueden ser utilizadas para explicar las funcionalidades del sistema a alguien no familiarizado con el mismo Distintos niveles de granularidad, presentan una descripción top-down de las responsabilidades del sistema Cuándo no usarlo?

46 Module Viewtype: cuando no
Es dificultoso utilizar este tipo de vistas para 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, confiabilidad u otras características asociadas al tiempo de ejecución Múltiples instancias de objetos Relaciones existentes sólo en tiempo de ejecución Qué tipo de notaciones conocen?

47 Componentes y Conectores: Ejemplos
3.1 Introducción The system contains a shared repository of customer accounts (Account DB) accessed by two servers and an administrative component. A set of client tellers can interact with the account repository servers, embodying a client-sever style. The purpose of the two servers (we learn from the supporting documentation) is to enhance reliability: if the main server goes down, the backup can take over. There is a component that allows an administrator to access, and presumably maintain, the shared data store. There are three types of connectors shown in this cartoon, each representing a different form of interaction among the connected parts.: The client-server connector allows a set of concurrent clients to retrieve data synchronously via service requests and supports transparent failover to a backup server. The database access connector supports authenticated administrative access for monitoring and maintaining. The publish-subscribe connector supports asynchronous announcement and notification of events. 47

48 Elementos Son entidades con manifestación runtime que 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 componentes y conectores Las entidades runtime son instancias de tipos de conector o componente 3.2 Elements, Relations, and Properties of the C&C Viewtype Each of the elements in a C&C view of a system has a run-time manifestation as an entity that consumes execution resources, and contributes to the execution behavior of that system. The relations of a C&C view associate components with connectors to form a graph that represents a run-time system configuration. These run-time entities are instances of component and connector types. The available types are either defined by choosing a specific architectural style that prescribes a set of C&C building blocks (see Chapter 4) or they may be custom defined. In either case, the types are chosen because there is significant commonality among several components or connectors in the architecture. Defining or using a set of component and connector types provides a means for capturing this commonality, provides a specialized design vocabulary targeted to specific domains, and introduces constraints on how that vocabulary is used. 48

49 Utilidad ¿Cuáles son los repositorios y que componentes los acceden?
¿Cuales son los componentes ejecutables y como interactúan? ¿Cuáles son los repositorios y que componentes los acceden? ¿Qué partes del sistema son replicadas y cuantas veces? ¿Cómo progresan los datos a los largo del sistema a medida que éste se ejecuta? 3.3 What the C&C Viewtype Is For, and What It’s Not For The C&C viewtype is used to reason about run-time system quality attributes, such as performance, reliability, availability. In particular, a well documented view will allow architects to predict overall system properties, given estimates or measurements of properties of the individual elements and interactions. For example, to determine whether the overall system can meet its real-time scheduling requirements you must usually know the cycle time of each process in a process-oriented view. Similarly, knowing the reliability of individual elements and communication channels supports an architect when estimating or calculating overall system reliability. In some cases this kind of reasoning is supported by formal, analytical models and tools. In others, it is achieved by judicious use of rules of thumb and past experience. C&C views allow one to answer questions such as: • What are the system’s principal executing components and how do they interact? • What are the major shared data stores? • Which parts of the system are replicated, and how many times? • How does data progress through a system as it executes? • What protocols of interaction are used by communicating entities? • What parts of the system run in parallel? • How can the system’s structure change as it executes? 49

50 Utilidad ¿Qué protocolos de interacción son usados por las entidades comunicantes? ¿Qué partes del sistema se ejecutan en paralelo? ¿Cómo la estructura del sistema puede cambiar a medida que se ejecuta? 3.3 What the C&C Viewtype Is For, and What It’s Not For C&C views allow one to answer questions such as: • What are the system’s principal executing components and how do they interact? • What are the major shared data stores? • Which parts of the system are replicated, and how many times? • How does data progress through a system as it executes? • What protocols of interaction are used by communicating entities? • What parts of the system run in parallel? • How can the system’s structure change as it executes? 50

51 Propiedades Confiabilidad Performance Recursos requeridos
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 3.2 Elements, Relations, and Properties of the C&C Viewtype A particular element may have a number of different kinds of associated properties including the name, type, and ports or roles of the element. Other properties are possible and they should be chosen to support the usage intended for the particular component-and-connector view. For example, different properties might be chosen depending on whether the view is to be used as a basis for construction, analysis, or communication, as outlined below. Here are some examples of typical properties and their uses: • Reliability: What is the likelihood of failure for a given component or connector? This might be used to help determine overall system reliability. • Performance: What kinds of response time will the component provide and under what loads? What kinds of latencies and throughputs can be expected for a given connector? This can be used (with other properties) to determine system properties such as latencies, throughput, and buffering needs. • Resource requirements: What are the processing and storage needs of a component or connector? This can be used to determine if a proposed hardware configuration will be adequate. 51

52 Propiedades Funcionalidad Protocolos Seguridad
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 3.2 Elements, Relations, and Properties of the C&C Viewtype • Functionality: What functions does an element perform? This can be used to reason about overall computation performed by a system. • Protocols: What patterns of events or actions can take place for an interaction represented component or connector? Protocols can be used to determine whether a particular interaction deadlock, whether specific components can legally participate in a given interaction, what are ordering constraints on an interaction, and how errors are handled. • Security: Does a component or connector enforce or provide security features, such as encryption, audit trails, or authentication? This can be used to determine system security vulnerabilities. 52

53 Para lo que NO sirve 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 una visión estática de diseño 3.3 What the C&C Viewtype Is For, and What It’s Not For C&C views are not appropriate for representing design elements that do not have a run-time presence. For example, a class is not a component. A good rule of thumb is that if it doesn’t make sense to characterize the interface(s) of an element, it probably isn’t a component (although the inverse is clearly not necessarily true – there are many things with interfaces that are not components). 53

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

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

56 Visión Conceptual

57 Características del C&C
Los componentes y conectores representan entidades de tiempo de ejecución Los ports son las interfaces de comunicación de los componentes agrupando señales de entrada y salida que siguen algún tipo de secuenciamiento (protocolo) Los conectores tienen como función mediar en la interacción entre componentes Los conectores pueden representar formas complejas de interacción más allá del simple call return sincrónico El conector debería especificar el protocolo bajo el cual los componentes interactúan para cada uno de sus roles

58 Vista de Módulos

59 Vista de Módulos Descomposición

60 Vista de Módulos Descomposición

61 Visión Conceptual C&C

62 C&C y Comportamiento Sebastian Uchitel

63 Visión Conceptual C&C - Descomposición

64 Visión Conceptual Comportamiento

65 Visión Conceptual C&C

66 Visión Conceptual Conector PacketPipe

67 Visión de Ejecución

68 Principios de Diseño

69 Herramientas Conceptuales: Principios
Decomposición Divide & Conquer (piezas conocidas y tratables) Separación por niveles de abstracción y/o máquinas virtuales Separación por aspectos, etc. Modularidad Colección bien definida de partes e interacciones bien delimitadas Ocultamiento de la información 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 Encapsulamiento Clara separación de interface e implementación Mecanismos para no conocer ni usar más de lo que la interface promete Abstracción Foco en lo esencial

70 Principios (Cont.) Explotar el Polimorfismo
tratamiento uniforme de una entidad que puede tener múltiples formas Sustitución Liskov/Wing Inversión 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 Segregación de interfaces Una sola responsabilidad (cohesion) Open-Close Detección de puntos de variabilidad Advertencia: Estos principios han nacido con la extensibilidad y la modificabilidad como atributos de calidad preponderantes

71 Estrategias de Descomposición
Problemas que sabemos resolver Ej. M. Jackson’s Problem Frames: Control, Visualizacion, Correspondencia, etc Pasos de ejecución Ej. Filtros de procesamiento de imagenes Tempo de ejecución Ej. Acumulación vs Utilización de Información Funcional Ej. Facturación, Compras y Sueldos Modos de Operación Normal vs Excepcional Datos Ej. Guiado por el modelo conceptual. Clientes, Ambulancias...

72 Ejemplo de Descomposición

73 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 composición...

74 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 independiente Es una unidad de trabajo para desarrollo Componentes Entidades run-time Descomposición para cumplir con ciertos requerimientos no funcionales distintos a los módulos (performance, distribución, tolerancia a fallas, seguridad, adaptabilidad en run-time, etc.).

75 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 Procedural ej. Funciones, métodos, procedimientos Datos ej. TADs, modelos de componentes Control ej. loops, iteradores, frameworks y multitasking

76 Distintos tipos de abstracciones

77 Information Hiding: Ejemplo
Diseño de Message_Queue es una lista doblemente encadenada de Message_Blocks Manejo eficiente de listas no acotadas Encapsulamiento y parametrización de otros aspectos en cabecera sincronización, asignación de memoria y contador de referencias pueden ser agregados/intercambinads luego.

78 Frameworks Un diseño reutilizable / una implementación parcial
Colección de módulos o clases con mecanismos de interacción y colaboración prefijadas con implementaciones parciales Tarea del usuario: Implementar los huecos de manera específica a la aplicación siendo construida Típicamente implementado en lenguajes OO Completamos la implementación con subclases Diferencias con librerías Inversion of Control or Hollywood Principle: “Don’t call us, we’ll call you” Las subclasses son invocadas desde el framework Desventajas Código en exceso Dificultad de comprensión y selección de framework adecuado

79 Interfases Elementos Provistos Elementos Requeridos Control de acceso
Ej. métodos, procedimientos, eventos Elementos Requeridos Ej. métodos, procedimientos, eventos, objetos Control de acceso Ej. servicios ofrecidos para algunos clientes. Uid, groups, pivate/protected/public

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 conlleva 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ó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ódulo Si un módulo es un submódulo de otro Bajo acoplamiento puede significar peor performance Tradeoff...

81 Tipos de Acoplamiento Ordenado 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ón 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 Mensajes Módulos se comunican a través de mensajes. Posiblemente no se conocen explícitamente

82 Information Hiding / Encapsulamiento
Esconder las decisiones de diseño que pueden llegar a cambiar Minimizar el impacto de cambios futuros Minimizar la información en la interfaz Información a abstraer/esconder Representación de datos Algoritmos Formatos de entrada y salida Interfaces de bajo nivel Separación de políticas y mecanismos Decisiones estructurales de más bajo nivel Aspectos funcionales

83 Programación basada en interfases
Como usuario de una abstracción, es fundamental no depender de los detalles de la implementación Ejemplos Estándares de jure vs. Implementaciones Estándares de facto vs. variaciones Especificación vs. Implementación Interfases (OO) vs. Clases concretas C Java HTML Servicios Web Corba SQL

84 Dependency Inversion Principle
“Depend upon Abstractions. Do not depend upon concretions.” Objetivo: Hacer un diseño más flexible, enfocando el diseño a interfaces o clases abstractas, en lugar de a clases concretas.

85 Interface Segregation Principle
“Many client specific interfaces are better than one general purpose interface”. Objetivo: Separar interfaces para minimizar dependencias.

86 Liskov Substitution Principle
Un principio pensado para lenguajes de programación con herencia... “Subclasses should be substitutable for their base classes” Una subclase puede ser usada donde su clase base es usada.

87 Cohesión 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 de un módulo Alta cohesión tiende a proveer: Robustez Confiabilidad Reusabilidad Comprensibilidad Testeabilidad Mantenibilidad

88 Tipos de Cohesión Ordenado de peor a mejor (según E. Yourdon y L. Constantine en los 70’s) Coincidental 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 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 Procedural 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. Secuencial Agrupadas porque el output de uno es el input de otro Funcional Agrupadas porque contribuyen a una tarea bien definida del módulo Ed dice que estos son aceptables

89 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.

90 Extensibilidad y Open/Closed Principle
Los requerimientos cambian. El diseño debe poder acomodar estos cambios. Un diseño 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 código existente, sólo agregar. ej. Capacidad de lidiar con nuevos tipos de eventos

91 The Open Closed Principle usando Polimorfismo

92 Preguntas para la Buena Modularizació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? 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? 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)? Interface Segregation Principle: Many specific interfaces are better than a general one. La interfaz de un módulo revela demasiado? Podría abstraerse? Es evidente del código cuando dos módulos se comunican? ...

93 Design Patterns Gamma, Helm, Johnson & 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 vimos

94 Design Patterns La descripción de un patrón de diseño debe 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 del patrón. La solución resuelve las fuerzas en el contexto dado Más Ejemplos de uso Patrones relacionados Otros nombres usados del patrón Ejemplo en código

95 Design Patterns Tipos de Patterns:
De Creación: soluciones flexibles para la creación de instancias (e.g., abstract factory, singleton, etc.) Estructurales: soluciones de organización (herencia, composición, agregación, asociación) de clases e interfaces para la extensibilidad y cambio (ej., composite, bridge, facade, adapter, etc.) De comportamiento: soluciones para la asignación de responsabilidades y diseño de algoritmos. Muestran relación estática y comunicación (ej., command, interpreter, mediator, observer, memento, etc. )

96 Design Pattern: Singleton
Nombre: Singleton Problema: Cómo definir una clase que debe tener una sola instancia accesible desde toda la aplicación. Contexto: En algunas aplicaciones es importante que la clase tenga exactamente una instancia. Una aplicación de 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 clase. Fuerzas: Usar una variable global no es un buen diseño. Otra opción es no crear instancias sino usar métodos y 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 instancia como singleton.

97 Design Pattern: Singleton
Solución:Crear un método estático GetInstance(). 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 siguientes ventajas y desventajas….

98 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 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; } }

99 Design Patterns Represent an operation to be performed on the
elements of an object structure. Define a new operation without changing the classes of the elements on which it operates.

100 Design Patterns Aside from potentially improving separation of concerns, the visitor pattern has an additional advantage over simply calling a polymorphic method: a visitor object can have state. This is extremely useful in many cases where the action performed on the object depends on previous such actions.

101 Design Patterns

102 Design Patterns

103 Design Patterns

104 Design Patterns Compose objects into tree structures to
represent part/whole hierarchies. The Composite lets clients treat individual objects and compositions of objects uniformly.

105 Design Patterns

106 Design Patterns

107 Design Patterns

108 Design Patterns Muy usado en frameworks, hollywood inversion principle
The participants of the pattern are detailed below. Member functions are listed with bullets. [edit] Subject This abstract class provides an interface for attaching and detaching observers. Subject class also holds a private list of observers. Contains these functions (methods): Attach - Adds a new observer to the list of observers observing the subject. Detach - Removes an existing observer from the list of observers observing the subject Notify - Notifies each observer by calling the notify() function in the observer, when a change occurs. [edit] ConcreteSubject This class provides the state of interest to observers. It also sends a notification to all observers, by calling the Notify function in its superclass (i.e, in the Subject class). Contains this function: GetState - Returns the state of the subject. [edit] Observer This class defines an updating interface for all observers, to receive update notification from the subject. The Observer class is used as an abstract class to implement concrete observers. Contains this function: Notify - An abstract function, to be overridden by concrete observers. [edit] ConcreteObserver This class maintains a reference with the ConcreteSubject, to receive the state of the subject when a notification is received. Contains this function: Notify - This is the overridden function in the concrete class. When this function is called by the subject, the ConcreteObserver calls the GetState function of the subject to update the information it has about the subject's state. When the event is raised each observer receives a callback. This may be either a virtual function of the observer class (called 'notify()' on the diagram) or a function pointer (more generally a function object or "functor") passed as an argument to the listener registration method. The notify function may also be passed some parameters (generally information about the event that is occurring) which can be used by the observer. Each concrete observer implements the notify function and as a consequence defines its own behavior when the notification occurs.

109 Design Patterns

110 Design Patterns Strategy Relación con el “Open-Close principle”
The Strategy Design Pattern basically consists of decoupling an algorithm from its host, and encapsulating the algorithm into a separate class. More simply put, an object and its behaviour are separated and put into two different classes. This allows you to switch the algorithm that you are using at any time. There are several advantages to doing this. First, if you have several different behaviours that you want an object to perform, it is much simpler to keep track of them if each behaviour is a separate class, and not buried in the body of some method. Should you ever want to add, remove, or change any of the behaviours, it is a much simpler task, since each one is its own class. Each such behaviour or algorithm encapsulated into its own class is called a Strategy. When you have several objects that are basically the same, and differ only in their behaviour, it is a good idea to make use of the Strategy Pattern.. Using Strategies, you can reduce these several objects to one class that uses several Strategies. The use of strategies also provides a nice alternative to subclassing an object to achieve different behaviours. When you subclass an object to change its behaviour, that behaviour that it executes is static. If you wanted to change what it does, you'd have to create a new instance of a different subclass and replace that object with it. With Strategies, however, all you need to do is switch the object's strategy, and it will immediately change how it behaves. Using Strategies also eliminates the need for many conditional statements. When you have several behaviours together in one class, it is difficult to choose among them without resorting to conditional statements. If you use Strategies you won't need to check for anything, since whatever the current strategy is just executes without asking questions.

111 Design Patterns According to Strategy pattern, the behaviors of a class should not be inherited, instead they should be encapsulated using interfaces. As an example, consider a car class. Two possible behaviors of car are brake and accelerate. Since accelerate and brake behaviors change frequently between models, a common approach is to implement these behaviors in subclasses. This approach has significant drawbacks: accelerate and brake behaviors must be declared in each new Car model. This may not be a concern when there are only a small number of models, but the work of managing these behaviors increases greatly as the number of models increases, and requires code to be duplicated across models. Additionally, it is not easy to determine the exact nature of the behavior for each model without investigating the code in each. The strategy pattern uses composition instead of inheritance. In the strategy pattern behaviors are defined as separate interfaces and specific classes that implement these interfaces. Specific classes encapsulate these interfaces. This allows better decoupling between the behavior and the class that uses the behavior. The behavior can be changed without breaking the classes that use it, and the classes can switch between behaviors by changing the specific implementation used without requiring any significant code changes. Behaviors can also be changed at run-time as well as at design-time. For instance, a car object’s brake behavior can be changed from BrakeWithABS() to Brake() by changing the brakeBehavior member to: brakeBehavior = new Brake();

112 Design Patterns

113 Design Patterns

114 Cuándo usar los Design Patterns
Hay un pattern para el problema Propone una solución mejor No hay una solución más simple El contexto del problema es consistente con el del pattern Las consecuencias de usarlo son aceptables

115 Evaluación de Diseños 3 grandes tipos de evaluación Código Diseño
Requerimientos Código Diseño Requerimientos Código Diseño Requerimientos 1. Architectural Design Reviews bring stakeholders together to determine feasibility of an architectural design to solve a particular problem 2. Product-line Engineering/Commonality Analysis identify common requirements of a group of products 3. Rules-of-thumb and Automated Design Guidance codify criteria and guidance for choosing appropriate architectural designs 4. Architecture-based Analysis use analytic techniques to decide whether an architectural design will lead to a system that meets its requirements Design Reviews: Define a process of formal review of architecture that leads to list of issues that must be resolved Prescribe guidelines for architectural description and rationale May be done using corporate “design review boards” or by a product group itself Used to produce corporate architectural assets Checklists of issues to consider Standard solutions to domain-specific problems Case studies and examples Measurement of costs/benefits Architectural Missmatch

116 Algunos Errores Comunes (1/2)
Diseño Depth First Só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 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! No todo lo vamos a construir. Selección de COTS influye en la descomposición

117 Algunos Errores Comunes (2/2)
Diseño documentado ambiguamente Interpretado incorrectamente en tiempo de implementación Decisiones de diseño indocumentadas Diseñ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 Módulos funcionan, pero no encajan Divide to conquer, reunite to rule

118 Algunas reglas para cuando diseñamos (1)
Asegurarse que el problema está claro En la medida de lo razonable, requerimientos claros, consistentes y completos Qué antes que cómo En la medida de lo posible, pensar en interfases primero Separar aspectos ortogonales No conectar lo que es independiente... Mantener las cosas lo más simple posible, pero no más. Diseños “chetos” tienden a tener mas errores, ser más difíciles de testear y ser mas ineficientes Trabajar a múltiples niveles de abstracción ...pero entender la relación entre estos niveles

119 Algunas reglas para cuando diseñamos (2)
Pensar en la posiblidad de prototipar Vertical vs. Horizontal, para evolucionar vs. para tirar Mantener las representaciones consistentes Utilizar, en la medida de lo posible, patrones y esquemas conocidos No reinventar la rueda Ser auto-crítico Usar principios de diseño para evaluar el diseño No asumir que las reglas aquí expuestas son Absolutas Completas

120 AntiPatterns

121 Ejes para críticas de diseño
Coorrección: fallas sintácticas y semánticas Completud: tareas relevantes de diseño incompletas Consistencia: contradicciones internas del diseño Optimización: mejores opciones para los parámetros de diseño Pertinencia: decisiones soportadas por requerimientos Alternativas: otras elecciones para una decisión de diseño Evolución: asuntos que comprometen futuros cambios Presentación: uso torpe de la notación Herramientas: otras herramientas que podrían ser usadas en una decisión de diseño Experiencia: recordar experiencias pasadas relevantes Organizacional: interses de otros stakeholders

122 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 + connected components COCOMO modelo de costo para la estimación de costo, esfuerzo y calendario

123 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 deseables Weyuker definió 9 propiedades deseables Propiedad 3: Detalles de Deseño son importantes » Dos clases con la misma funcionalidad no deberían necesariamente tener el mismo valor para la métrica Propiedad 4: Monotonía » La métrica para una combinación de clases no puede dar menos que ninguna de las métricas de las componentes Propiedad 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 Transactions on Software Engineering, vol. 20, no. 6, pp , Jun. 1994