Dise ño de Software - PowerPoint PPT Presentation

dise o de software n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dise ño de Software PowerPoint Presentation
Download Presentation
Dise ño de Software

play fullscreen
1 / 113
Dise ño de Software
163 Views
Download Presentation
yagil
Download Presentation

Dise ño de Software

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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