Unidad I de Diseño de Sistemas. Significado dentro del Ciclo de Vida de Desarrollo de Sistemas. Modelos de Desarrollo de Software. Modelos de Desarrollo Estructurado (3K1) UTN-FRT. 2011

1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

6. II – El Análisis: Imponer Orden al Caos: La Descomposición: Técnica de dominar la complejidad: “divide et impera” (Dijkstra) B) El Análisis: Proceso que define los requerimientos para solucionar un problema Examina las necesidades del usuario Define las propiedades que debería poseer el sistema para cubrir esas necesidades Identifica las limitaciones del sistema y los requisitos de performance Define precisamente las funciones a llevarse a cabo y no cómo trabajan Del análisis surgen las ESPECIFICACIONES FUNCIONALES DEL SISTEMA. Deseo de saltear el Análisis: común, ya que carece de herramientas técnicas y metodología como en el diseño Se orienta más a las personas que a los equipos. Enfoca la interfaces usuario/computadora Los desarrolladores siempre prefieren ignorar esta interfaces a favor de los asuntos técnicos más fácilmente definibles Análisis: Define los requerimientos del problema y propone una solución Primero se determinan las partes del problema y sus interrelaciones Es esencial entender completamente el problema antes de definir una solución

7. El Análisis Si la estructura de la solución no refleja la estructura del problema, el sistema resultante será difícil de cambiar y mantener El no anticipar la natural tendencia de los sistemas al cambio fue la causa de la construcción de software inflexible, caro e inmantenible Sólo luego de entender bien a un problema, puede proponerse una buena solución Los problemas no son estáticos: pueden cambiar en el futuro, en función de un usuario determinado, del tiempo y nuevas tecnologías El ANALISIS influye enormemente en el resto del ciclo de vida del sistema

8. Especificaciones Funcionales del Sistema Resulta de la fase de ANALISIS Describe cómo el sistema deberá satisfacer los requerimientos del problema Define: reportes, estructuras de datos, bases de datos, archivos externos, tablas internas, componentes funcionales e interfaces con otros sistemas. O sea: componentes del sistema e interfaces que los conectan Ofrece al usuario y desarrollador una descripción concreta de los componentes para evitar confusiones del usuario y errores del desarrollador Debe ser precisa, comprobable y formal. Entendible por analistas, diseñadores y usuarios. Es el medio de comunicación principal entre ellos Unas especificaciones completas y correctas afectan el éxito de todo el esfuerzo de desarrollo Influye en proyectar tiempos, asignar personal, documentación, plan de pruebas Mala especificación: demoras, malas pruebas, documentación incorrecta. Resultado: soft no confiable ni útil Errores de especificación: muy caros (100 veces más) si no se detectan y corrigen tempranamente

9. III – El Diseño: A) Conceptos Generales: Etapa que sigue al Análisis antes de la Implementación Proceso de planificar cómo se construirá el sistema Determina los procesos y datos que se necesitan Ensambla dichos componentes para proporcionar la solución informática Desarrollo de algoritmos que describen lo que hace cada componente Input del Diseño: Especificaciones Funcionales, Requerimientos y Limitaciones del Problema proporcionados por el ANALISIS. Detectar 1 error de diseño durante la codificación requiere el doble corregirlo. Detectarlo durante la fase de prueba, 10 veces más Mayor cuidado al diseño = > Sistemas más baratos y confiables

10. El Diseño: Conceptos Generales Base de la implementación del sistema, ayuda la lectura y confiabilidad del soft, reduce su complejidad y costo Subestimada en el desarrollo tradicional de sistemas. Se saltea en muchos desarrollos. Esto ocasiona problemas y consecuencias a largo plazo Su falta complica el desarrollo, que carece de plan de acción. Dificulta asignar personal a las tareas. No hay mecanismos de medición de la calidad de los trabajos de los desarrolladores. Carece de documentación y prueba Oportunidad dada a los desarrolladores para planear lo que van a hacer y evaluar las bondades de su plan antes de codificarlo y probarlo Propósito: Especifica cómo debe ser construido el software para cumplir con las Especificaciones Funcionales

12. 1º) Diseño Arquitectónico o del Sistema Diseño de Alto Nivel Define los procedimientos básicos y sus interrelaciones Define a grandes rasgos la representación de los datos Sigue la estructura del problema a resolver

13. 2º) Diseño Detallado Crea algoritmos específicos Estructuras de Datos detalladas. Define niveles del sistema Requiere niveles sucesivos de detalle y refinamiento Termina con algoritmos precisos y estructuras de datos que cubren todos los requerimientos

14. C) Métodos del Diseño Conceptos Generales. Importancia: Camino para llegar a un fin Proceso disciplinado para generar un conjunto de modelos que describe a un sistema de software en desarrollo, utilizando alguna notación bien definida Brindan disciplina para desarrollar sistemas de software complejos Facilitan comunicación y estándares en equipos de desarrollo Definen metas y objetivos para medir el progreso y gestionar el riesgo Surgieron de la complejidad creciente de los sistemas de software: 60’s y 70’s

16. 1º) Metodologías de Diseño Estructurado o Diseño Compuesto Fueron los métodos más utilizados hasta los ‘90 Influencia de lenguajes: FORTRAN y COBOL Unidad fundamental de Descomposición: Subprogramas Programa resultante: árbol donde subprogramas se ejecutan llamando a otros subprogramas Aplica la descomposición algorítmica para fragmentar un problema grande en pasos más chicos Fundamentos Teóricos: Yourdon, Wirth, Dijkstra, Mills

17. Metodologías de Diseño Estructurado o Diseño Compuesto Usa el concepto de modularización, restringe las interfases entre módulos, estandariza la estructura de los módulos de programación Avance en Hard: equipos de mayor capacidad. Pero la programación estructurada puede derrumbarse cuando hay más de 100.000 líneas de código (Stein) Inapropiado para su uso en lenguajes de programación basados en objetos y orientados a objetos Inapropiado para sistemas muy complejos

18. Metodologías de Diseño Estructurado o Diseño Compuesto Herramientas utilizadas para describir lógicamente un sistema: Diagramas de Flujo: modelan las transformaciones de los datos en su flujo por el sistema. Núcleo del enfoque estructurado. Los procesos complejos se van dividiendo recursivamente en subdiagramas, que quedan cada vez más sencillos y fáciles de implementar. Cuando los procesos resultantes son lo suficientemente simples, se detiene la descomposición. Especificación de Procesos : descripción de cada proceso de más bajo nivel. Se especifican con tablas de decisión, seudocódigos, etc. Diccionarios de Datos : Contienen detalles que escapan a los diagramas de flujos. Definen los flujos y almacenamientos de datos y el significado de los nombres. Diagramas de Transición de Estados: Describen los procesos controladores o el tiempo de ejecución de funciones y de acceso de datos activados por eventos Diagramas de Entidad/Relación : enfoca relaciones entre bases de datos

19. 2º) Metodologías de Diseño Dirigido a los Datos Por Jackson y Orr. Popular en Europa La estructura de un sistema de software se deduce de la correspondencia entre entradas y salidas del sistema Exitoso para sistemas de gestión de información Sistemas que impliquen relaciones directas entre entradas y salidas del sistema No atiende eventos internos No distingue entre Análisis y Diseño: Une a ambas en ESPECIFICACION Divide el Desarrollo en dos etapas: ESPECIFICACION (qué) e IMPLEMENTACION (cómo)

20. Metodologías de Diseño Dirigido a los Datos Orientada a los datos y no a los procesos Comienza con el diseño de las estructuras de datos La estructura del programa deriva de las estructuras de datos Asume que el problema ha sido completamente especificado antes del diseño Enfoca en las salidas (outputs) del sistema Filosofía: Los outputs del sistema en forma absoluta y completa determinan la estructura de datos, y la estructura de datos, a su vez, determina la estructura del programa Comienza con una descripción jerárquica de las salidas del sistema La estructura de los inputs y de los programas del sistema derivan necesariamente de la estructura de los outputs

22. Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Cada módulo del sistema es un paso importante de algún proceso global alternativa para el mismo problema. Es una descomposición basada en OBJETOS y NO en ALGORITMOS Diagramas de Flujo. Organiza el sistema en base a procedimientos Se organiza el sistema como un conjunto de objetos reales o conceptuales que existen en la visión que el usuario tiene del mundo Descompone el problema en pasos Cada objeto contiene su propio comportamiento único y modela a un objeto del mundo real

23. Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Enfatiza el Orden de los Eventos Los objetos hacen cosas, y a los objetos se les pide que las hagan enviándoles mensajes Descomposición funcional. El sistema proporciona funciones al usuario final Resalta los agentes que causan acciones o son objetos de acciones Visión Activa de la Realidad Visión Pasiva Cambios en requerimientos: desastroso porque hay que replantear todo Cambios en los requerimientos: cambios en las funciones y no en los objetos. Fácil: se agregan o quitan funciones a cada objeto. Se deja sin cambios la estructura del objeto.

24. Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Útil en los casos en que las funciones sean más importantes y complejas que los datos Existe una analogía directa entre objetos de la vida real y los objetos del problema. Son sistemas más fáciles de comprender para el usuario. Diseño más intuitivo. Simplifica el seguimiento entre requerimientos y codificación Tiene los límites claramente definidos del sistema. Su estructura deriva de los límites del sistema. Es difícil extenderlos Es Fácil ampliar un sistema. Son más resistentes al cambio. Evolucionan mejor. Reduce el riesgo de construir sistemas complejos La descomposición de un proceso en subprocesos es arbitraria y cambia de persona a persona La descomposición se basa en objetos del dominio del problema. Desarrolladores de diferentes programas en el mismo dominio tienden a descubrir los mismos objetos

25. Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Los programadores piensan en términos de funciones. Son más fáciles de aprender Facilita la reusabilidad de componentes de un proyecto a otro. Es difícil integrar código de programas basado en funciones y bases de datos organizadas como datos Integra mejor bases de datos con codificación. Primera metodología formal bien pensada, disciplinada y organizada destinada al desarrollo de software Produce sistemas más pequeños: reuso de mecanismos comunes

32. Componentes de una herramienta CASE para el soporte de métodos estructurados

39. Clasificación de herramientas CASE según su función

41. Clasificación de herramientas CASE según la perspectiva del proceso

45. Clasificación de herramientas CASE según la perspectiva de Integración