Dise ño de Software

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. Diseño de Software • Puente entre mundos • Fronteras difusas a diferencia de otras disciplinas… Requerimientos Arquitectura/Diseño de Software Implementaciones

8. Frenado del Airbus A320 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

9. Frenado del Airbus A320 Sistema de Frenado Airbus A320 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 Piloto

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 delProblema Enunciado de laImplementación Mas Info

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

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

17. Introducción a POO

18. Documentación

19. 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.)

20. Vistas y stackeholders La metáfora 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

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

22. 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, ...

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

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

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

26. Diagramas y vistas en UML

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

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

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

30. Ejemplo de Vista Run-Time (Comportamiento)

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

32. Ejemplo de Vista de Deployment (1)

33. Ejemplo de Vista de Deployment (2)

34. Mezclando Vistas

35. Mezclando Vistas

36. Mezclando Vistas

37. Generalizando los tipos de vista Mas allá de UML

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

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

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

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

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

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

44. Componentes y Conectores: Ejemplos

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

46. Utilidad ¿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?

47. 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?

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

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

50. Para lo que NO sirve Nose 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