Sesion 5 2 del análisis al diseño

638 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
638
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
44
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sesion 5 2 del análisis al diseño

  1. 1. Diseño:Del Análisis Al DiseñoLic. César Alcántara Loayza
  2. 2. Del Análisis Al Diseño  Para manejar el proceso de desarrollo se debe comprender como se relacionan las fases de desarrollo una con otra y con el proceso general.  Comprender las relaciones entre los productos de trabajo facilita el mejoramiento y refinamiento de los modelos. Así como en el análisis, los modelos se deben reconciliar para probar su integridad y exactitud. Los procesos de prueba del proceso continuarán a través del diseño.CAL/Fundamentos 2
  3. 3. Del Análisis Al Diseño  Comprender como estos mismos productos del trabajo evolucionan desde una fase hacia la siguiente facilitan el manejo del proceso general. Cada fase entrega los productos de trabajo a un nivel que les permita usarse como recursos en la siguiente fase.CAL/Fundamentos 3
  4. 4. Revisión Del Ciclo De Vida  En las lecciones anteriores aprendimos acerca de las dos primeras fases, Inicio del proyecto y análisis del problema. Al final de estas dos fases, ha creado y probado un modelo completo del dominio del problema. Se ha definido todos los objetivos y recursos que el sistema final deberá soportar. Estos productos del trabajo representan su objetivoCAL/Fundamentos 4
  5. 5. Revisión Del Ciclo De Vida  El diseño es cuando Ud. toma el objetivo como el blanco. Es importante que no dispare hasta que que tenga el blanco. En otras palabras, diseñar trata acerca del planear como conseguir los objetivos definidos en los productos de trabajo del análisis. El proceso de planeamiento identifica la solución deseada, no la solución completa.CAL/Fundamentos 5
  6. 6. Revisión Del Ciclo De Vida  El diseño trata la funcionalidad asi como el rendimiento, la flexibilidad y la capacidad de mantenimiento.CAL/Fundamentos 6
  7. 7. Diseño vs. Implementación  Probablemente preguntará, ¿pero el lenguaje y el ambiente de implementación no dictan el diseño?, En parte es así. Habrá un esfuerzo convenido durante la implementación para reconciliar el diseño deseado y lo que la tecnología soportará. El valor de separar estos dos pasos viene del hecho de que el diseño retiene la imagen del resultado deseado, mientras que la implementación se debe conformar con las limitaciones de la tecnología y entornos actuales.CAL/Fundamentos 7
  8. 8. Diseño vs. Implementación  Las tecnologías y los entornos cambian rápidamente, presentando nuevas oportunidades para mejorar la implementación. El diseño proporciona un marco a através del cual medir estas nuevas oportunidades y planear su introducción en la implementación.CAL/Fundamentos 8
  9. 9. El Proceso De Desarrollo  Inicio del Proyecto  Documenta las espectativas del usuario.CAL/Fundamentos 9
  10. 10. Análisis del problema  Define los recursos del dominio del problema.CAL/Fundamentos 10
  11. 11. Análisis arquitectural  Selecciona la aproximación arquitectónica para la solución.CAL/Fundamentos 11
  12. 12. Diseño de Objetos  Selecciona y define la implementación para la solución de software.CAL/Fundamentos 12
  13. 13. Construcción  Construye, compra, integra el código para satisfacer el diseño.CAL/Fundamentos 13
  14. 14. Instalación  Coloca la aplicación en producciónCAL/Fundamentos 14
  15. 15. Mantenimiento  Revisa / mejora la aplicación en producción.CAL/Fundamentos 15
  16. 16. Transición Análisis - Diseño  La transición desde el análisis hacia el diseño requiere que se comprenda la diferencia entre lo que se modeló en el análisis y lo que se modelará en el diseño. Durante el inicio del proyecto y del análisis del problema se procedió bajo el supuesto de que el “sistema” que estaba modelando no tenía nada que hacer en absoluto con el software y hardware.CAL/Fundamentos 16
  17. 17. Transición Análisis - Diseño  La funcionalidad (modelo de casos de uso), los recursos (modelo de objetos) y la interacción de los recursos para soportar la funcionalidad (Diagramas de secuencia y colaboración) podrían existir se proporcione o no automatización. p.e en el sistema de venta de boletos, se identificó la necesidad de fijar asiento, fijar presentaciones, los precios por asiento en las presentaciones y la venta de boletos. No hay nada tecnológico en estas funciones. De hecho ellas han sido realizadas manualmente durante centurias.CAL/Fundamentos 17
  18. 18. Transición Análisis - Diseño  Todo lo que definió en el análisis debe permanecer intacto a medida que se mueve hacia el diseño. De hecho, el modelo de objetos a nivel de análisis será la base para su diseño de base de datos. Pocos objetos nuevos, si hay alguno, que se adicionan en el diseño formarán parte de la base de datos. Aquellos que se agregan durante el diseño de objetos serán para mejorar el rendimiento no la funcionalidad.CAL/Fundamentos 18
  19. 19. Transición Análisis - Diseño  Diseño: el diseño añade una “capa” de funcionalidad mas arriba del modelo de análisis. Esta capa es el software que facilita el uso de los recursos del dominio del problema usando interfaces, bases de datos, control de transacciones y comunicación que conforma al modelo de casos de uso.CAL/Fundamentos 19
  20. 20. Transición Análisis - Diseño  Esta capa de tecnología probablemente cambie a menudo, pero el dominio del problema subyacente permanecerá relativamente estable.CAL/Fundamentos 20
  21. 21. Transición Análisis - Diseño Capa de diseño Capa de análisisCAL/Fundamentos 21
  22. 22. Revisión Productos del Análisis  Diccionario de datos:  Define el vocabulario del dominio del problema. Este vocabulario forma la base para todos los modelos.  Modelo de casos de uso:  Incluye los diagramas de casos de uso, como también la descripción narrativa y los escenarios de cada caso de uso.CAL/Fundamentos 22
  23. 23. Revisión Productos del Análisis  Modelo de casos de uso  El propósito del modelo de casos de uso es establecer lo que el usuario espera ver cuando interactúe con el sistema. La vista es de alguien de fuera del sistema. Los escenario proporcionan los casos de prueba para cada caso de uso y así son recursos críticos para el resto del proyecto. Estos casos de prueba pueden y deben ser aplicados en cada iteración del proceso de análisis y diseño.CAL/Fundamentos 23
  24. 24. Revisión Productos del Análisis  Modelo de objetos:  Proporciona dos recursos: el diagrama de clases y el diagrama de objetos. Los dos diagramas representan los recursos del dominio del problema que los usuarios podrían requerir aún si el sistema no fuera automatizado. El diagrama de clases (frecuentemente llamado modelo de objetos) es el modelo principal.CAL/Fundamentos 24
  25. 25. Revisión Productos del Análisis  Modelo de objetos:  El diagrama de clases genera el código y proporciona la mejor definición para los objetos persistentes del sistema –los objetos que deberán manejarse en la base de datos. El diagrama de objetos es una herramienta para prueba y compresión de los objetos que son representados por clases en el diagrama de clases.CAL/Fundamentos 25
  26. 26. Revisión Productos del Análisis  Diagramas de interacción:  Los diagramas de secuencia y colaboración representan las interacciones entre objetos. Como tal son herramientas valiosas para identificar interfaces de objetos. Las interfaces a su vez ayudan a identificar los atributos que debe soportar el diagrama de clases. Los atributos contienen valores de datos.CAL/Fundamentos 26
  27. 27. Revisión Productos del Análisis  ... Los valores de datos son pasados como argumentos y valores de retorno en las interfaces. Un valor no se puede pasar como argumento si no está contenido en un atributo en algún objeto o creado por alguna operación que pertenece a un objeto (atributo derivado).CAL/Fundamentos 27
  28. 28. Revisión Productos del Análisis Modelo de Casos de Uso Mas útil para describir el negocio Diagrama de Secuencia ó Diagramas de Modelo de Actividad Objetos Diagrama de EstadosCAL/Fundamentos 28
  29. 29. Diseño En Dos Pasos  El diseño está dividido en dos pasos:  Análisis arquitectural y  Diseño de objetos.  Por ejemplo la diferencia entre aplicaciones locales y distribuidas son significativas. Los retos de latencia, acceso a memoria, fallas parciales y concurrencia, requieren diseños significativamente diferentes para soluciones locales que para distribuidas.CAL/Fundamentos 29
  30. 30. Diseño En Dos Pasos  Arquitecturas diferentes dictan diferentes diseños de bajo nivel. Consecuentemente, las decisiones arquitecturales proporcionan el contexto para el diseño de bajo nivel.CAL/Fundamentos 30
  31. 31. Análisis Arquitectural  El análisis arquitectural evalúa los requerimientos del sistema contra las tecnologías que ofrecen los mas promisorios marcos para una solución. El problema se particiona para soportar tanto los requerimientos tecnológicos como los funcionales.CAL/Fundamentos 31
  32. 32. Análisis Arquitectural  Los casos de uso con utilizado como fuente para la división funcional. Los diagramas de clases proporcionan los recursos de cada área funcional. Los diagramas de interacción proporcionan la visión de las dependencias entre las particiones funcionales. Las particiones resultantes se modelan en un diagrama de paquetes.CAL/Fundamentos 32
  33. 33. Análisis Arquitectural  Cada paquete (partición funcional) está dividido para representar las capas de tecnología que se usarán para implementar la solución.CAL/Fundamentos 33
  34. 34. Análisis ArquitecturalModelo de Casos de Uso modelo de objetos Diagramas de Interacción (Funcionalidad) (Recursos) (Comunicación) Diagrama de Paquetes Representación de las particiones del Sistema A B C DCAL/Fundamentos 34
  35. 35. Diseño De Objetos  Durante el diseño de objetos cada partición representa un tipo diferente de reto de diseño. Por ejemplo, la partición de interface del usuario trata un conjunto muy diferente de problemas que la partición de acceso a datos. Una partición de Servidor de Transacciones es muy diferente de una partición de Aplicación del Cliente.CAL/Fundamentos 35
  36. 36. Diseño De Objetos  El diseño de objetos utilizará el diagrama de estados adicionalmente a otras herramientas de análisis. Juntas estas herramientas proporcionan modelos activos de todos los aspectos del diseño de software.CAL/Fundamentos 36
  37. 37. Resúmen  Las fases del proceso de desarrollo se asignan para soportan la evolución de los modelos desde la definición del problema hasta la definición de la solución. Las mismas herramientas se usan a través del proceso. Sin embargo el nivel de detalle y la clase de objetos agregados a cada fase sucesiva son diferentes. La clave para manejar y aplicar el proceso con éxito está en comprender las relaciones entre las fases y los productos de trabajo que ellos afectan.CAL/Fundamentos 37

×