Post on 12-Jun-2015
description
Ingeniería en Sistemas de Información
Diseño de Sistemas(3K1)
Contenidos de la Unidad 1Introducción al Diseño
a. Significado Dentro del Ciclo de Vida de Desarrollo de Sistemas.
b. Modelos de Desarrollo de software
i. Modelos de Desarrollo Estructurado
Sommerville. Sección 8.5 y 4.5.1Pressman. Sección 2.10
1.Modelo en Cascada. Sommervillle. Sección 4.1.1.Pressman. Sección 2.4.
2. Modelos evolutivos: incremental y espiral.
Sommervillle. Sección 4.1.2.Pressman. Sección 2.7
3. RUP Sommervillle. Sección 4.4.Jacobson, Booch y Rounbahg. Secciones 1.1 a a 1.5. Larman últ. Ed. Sección 37.1., 37.4 y 37.9
Diseño Estructurado: Primera aproximación científica para «atacar la Complejidad»
I – La Complejidad:
A) Sistemas de Software Simples Vs. Complejos (de dimensión industrial).
B) Complejidad inherente al software.
Unidad I: Significado dentro del Ciclo de Vida de Desarrollo de
Sistemas
Caracteres del Software de dimensión industrial:Difícil entender todos los aspectos de su diseño.Su complejidad excede la capacidad intelectual humana.Grandes sistemas: la complejidad es su propiedad esencial.Esencial: La complejidad puede dominarse. Nunca eliminarse.
A) Software Simple Vs. Software Complejo
Deriva de 4 elementos: a) Dominar el Problema. b) Desarrollar el Soft: Escribir y Reutilizar. Equipo
de desarrolladores: Comunicación y Coordinación. Dispersión geográfica. Proyectos grandes.
c) Flexibilidad propia del Soft: el desarrollador tiende a autoabastecerse de todo.
d) Comportamiento de los Sistemas Discretos: Sistemas continuos: leyes físicas y determinísticos. Grandes sistemas discretos: explosión combinatoria de posibilidades. Eventos externos pueden corromper el estado del sistema.
B) Complejidad inherente al software
B) El Análisis:Proceso que define los requerimientos para solucionar un problemaExamina las necesidades del usuarioDefine las propiedades que debería poseer el sistema para cubrir esas necesidadesIdentifica las limitaciones del sistema y los requisitos de performanceDefine precisamente las funciones a llevarse a cabo y no cómo trabajanDel 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ñoSe orienta más a las personas que a los equipos. Enfoca la interfaces usuario/computadoraLos desarrolladores siempre prefieren ignorar esta interfaces a favor de los asuntos técnicos más fácilmente definiblesAnálisis: Define los requerimientos del problema y propone una soluciónPrimero se determinan las partes del problema y sus interrelacionesEs esencial entender completamente el problema antes de definir una solución
II – El Análisis:Imponer Orden al Caos: La Descomposición:
Técnica de dominar la complejidad: “divide et impera” (Dijkstra)
Si la estructura de la solución no refleja la estructura del problema, el sistema resultante será difícil de cambiar y mantenerEl no anticipar la natural tendencia de los sistemas al cambio fue la causa de la construcción de software inflexible, caro e inmantenibleSó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íasEl ANALISIS influye enormemente en el resto del ciclo de vida del sistema
El Análisis
Resulta de la fase de ANALISISDescribe cómo el sistema deberá satisfacer los requerimientos del problemaDefine: 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 conectanOfrece al usuario y desarrollador una descripción concreta de los componentes para evitar confusiones del usuario y errores del desarrolladorDebe ser precisa, comprobable y formal. Entendible por analistas, diseñadores y usuarios. Es el medio de comunicación principal entre ellosUnas especificaciones completas y correctas afectan el éxito de todo el esfuerzo de desarrolloInfluye en proyectar tiempos, asignar personal, documentación, plan de pruebasMala especificación: demoras, malas pruebas, documentación incorrecta. Resultado: soft no confiable ni útilErrores de especificación: muy caros (100 veces más) si no se detectan y corrigen tempranamente
Especificaciones Funcionales del Sistema
A) Conceptos Generales:Etapa que sigue al Análisis antes de la ImplementaciónProceso de planificar cómo se construirá el sistemaDetermina los procesos y datos que se necesitanEnsambla dichos componentes para proporcionar la solución informáticaDesarrollo de algoritmos que describen lo que hace cada componenteInput 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ásMayor cuidado al diseño = > Sistemas más baratos y confiables
III – El Diseño:
Base de la implementación del sistema, ayuda la lectura y confiabilidad del soft, reduce su complejidad y costoSubestimada en el desarrollo tradicional de sistemas. Se saltea en muchos desarrollos. Esto ocasiona problemas y consecuencias a largo plazoSu 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 pruebaOportunidad dada a los desarrolladores para planear lo que van a hacer y evaluar las bondades de su plan antes de codificarlo y probarloPropósito: Especifica cómo debe ser construido el software para cumplir con las Especificaciones Funcionales
El Diseño:Conceptos Generales
1º) Diseño Arquitectónico o del Sistema:
2º) Diseño Detallado:
B) Etapas del Diseño:
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
1º) Diseño Arquitectónico o del
Sistema
Crea algoritmos específicos
Estructuras de Datos detalladas. Define niveles del sistemaRequiere niveles sucesivos de detalle y refinamientoTermina con algoritmos precisos y estructuras de datos que cubren todos los requerimientos
2º) Diseño Detallado
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 definidaBrindan disciplina para desarrollar sistemas de software
complejosFacilitan comunicación y estándares en equipos de
desarrolloDefinen metas y objetivos para medir el progreso y
gestionar el riesgoSurgieron de la complejidad creciente de los sistemas de
software: 60’s y 70’s
C) Métodos del Diseño
1º) Metodologías de Diseño Estructurado o Diseño Compuesto.
2º) Metodologías de Diseño Dirigido a los Datos.
3º) Diseño Orientado a Objetos.
Clasificación de las Metodologías de Diseño de
Sistemas:
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
1º) 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
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 eventosDiagramas de Entidad/Relación: enfoca relaciones entre bases de datos
Metodologías de Diseño Estructurado o Diseño
Compuesto
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)
2º) Metodologías de Diseño Dirigido a los Datos
Orientada a los datos y no a los procesosComienza con el diseño de las estructuras de datosLa estructura del programa deriva de las estructuras de datosAsume que el problema ha sido completamente especificado antes del diseñoEnfoca en las salidas (outputs) del sistemaFilosofí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 programaComienza con una descripción jerárquica de las salidas del sistemaLa estructura de los inputs y de los programas del sistema derivan necesariamente de la estructura de los outputs
Metodologías de Diseño Dirigido a los Datos
Sistema de Software => Conjunto de Objetos que cooperan, y se tratan como instancias de una clase que está dentro de una jerarquía de clases.
Surgidos a partir de los ‘90.
Reflejado en lenguajes de alto nivel: Smalltalk, Object Pascal, C++, Ada, Java, etc.
3º) 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
ALGORITMOSDiagramas 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
pasosCada objeto contiene su propio
comportamiento único y modela a un objeto del mundo real
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 mensajesDescomposición funcional. El
sistema proporciona funciones al usuario final
Resalta los agentes que causan acciones o son objetos de
accionesVisión Activa de la Realidad Visión PasivaCambios 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.
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ónTiene 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
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
Diseño Estructurado Vs. Diseño Orientado a
Objetos
Conclusiones:
Ambas visiones son contrapuestas. No puede diseñarse un sistema complejo
con las dos visiones a la vez. Hay que descomponer un sistema por
algoritmos u objetos y utilizar la estructura resultante como marco de referencia.
Diseño Estructurado Vs. Diseño Orientado a
Objetos
«Ingeniería del Software», de Ian Sommerville, 8.5
Métodos Estructurados Forma sistemática de elaborar modelos de un
sistema existente o de un sistema que tiene que ser construido.
Desarrollados por primera vez en la década de los ‘70 para soportar el Análisis y el Diseño del Software. (Constantine y Yourdon, 1979; Gane y Sarson, 1979; Jackson, 1983)
Modelos de Desarrollo Estructurado
Los métodos estructurados proporcionan un marco para el modelado detallado de sistemas.
Pueden suponer reducciones significativas de costos porque utilizan notaciones estándar producen una documentación de diseño estándar.
Métodos Estructurados
No dan soporte efectivo para comprender o modelar requerimientos del sistema no funcionales.
Casi no incluyen guías que ayuden a los usuarios a decidir si un método es adecuado para un problema concreto.
Tampoco incluyen consejos sobre cómo adaptar su uso en un entorno particular.
Métodos EstructuradosInconvenientes
Generan demasiada documentación. La esencia de los Requerimientos del Sistema
puede quedar oculta por el volumen de detalle que se incluye.
Los modelos producidos son muy detallados. Pueden ser difíciles de entender para los
usuarios, que no pueden comprobar el realismo de estos modelos, por ser tan específicos.
Métodos EstructuradosInconvenientes
Las herramientas CASE de Análisis y Diseño soportan la creación, edición y análisis de las notaciones gráficas utilizadas en los métodos estructurados.
La Figura siguiente nos muestra los componentes de una herramienta CASE de esa naturaleza.
Métodos EstructuradosHerramientas Case
Componentes de una herramienta CASE para el soporte de métodos
estructurados
Editores de diagramas: crean modelos de objetos, modelos de datos, modelos de comportamiento, etcétera. No son sólo herramientas de dibujo; pues, identifican los tipos de entidades en el diagrama. Captan la información sobre estas entidades y la guardan en el repositorio central.
Herramientas de análisis y comprobación de diseños: procesan el Diseño e informan sobre errores y anomalías. Permite detectar los errores del usuario en etapas tempranas del proceso de desarrollo.
Lenguajes de consulta del repositorio: permite encontrar diseños e información asociada a los diseños en el almacén.
Componentes de una herramienta CASE para el soporte de métodos
estructurados
Un diccionario de datos: mantiene información sobre las entidades utilizadas en el diseño de un sistema.
Herramientas de generación y definición de informes: obtienen información del almacén central y generan automáticamente la documentación del sistema.
Herramientas de definición de formularios: permiten especificar los formatos de pantallas y de documentos.
Componentes de una herramienta CASE para el soporte de métodos
estructurados
Facilidades para importar/exportar: Permiten el intercambio de información desde el Repositorio Central con otras herramientas de desarrollo.
Generadores de Código: generan código o esqueletos de código automáticamente, a partir del Diseño capturado en el Almacén Central.
Componentes de una herramienta CASE para el soporte de métodos
estructurados
Permiten al usuario generar programas a partir de información proporcionada en el modelo del sistema.
Soportan diferentes lenguajes, para que el usuario pueda generar programas, a partir del mismo modelo de Diseño.
Como los modelos excluyen detalles de bajo nivel, el generador de código no puede normalmente generar el sistema completo.
Por eso es necesaria alguna codificación manual para añadir detalles al código generado.
Herramientas CASE
«Ingeniería del Software», de Ian Sommerville, 4.5,1
Las herramientas Case se pueden clasificar desde 3 puntos de vista distintos:
1) Una perspectiva funcional: de acuerdo con su función específica.
2) Una perspectiva de proceso: de acuerdo con las actividades del proceso que ayudan.
3) Una perspectiva de integración: de acuerdo con cómo están organizadas en unidades integradas que proporcionan ayuda a una o más actividades del proceso.
Clasificación de Herramientas Case
La Figura siguiente muestra una clasificación de las herramientas CASE acorde con su función.
Enumera diferentes tipos y da ejemplos específicos de cada una.
No es una lista completa de herramientas CASE.
Las herramientas especializadas, como las de ayuda a la reutilización, no se incluyen.
Clasificación de herramientas CASE según
su función
Clasificación de herramientas CASE según
su función
La Figura siguiente muestra las fases del proceso que reciben ayuda por varios tipos de herramientas CASE.
Clasificación de herramientas CASE según la perspectiva del
proceso
Clasificación de herramientas CASE según la perspectiva del
proceso
Las Herramientas para:1.La planificación y estimación, 2.Edición de Texto, 3.Preparación de Documentos 4.Gestión de la Configuración
Se pueden utilizar durante todo el Proceso del Software.
Clasificación de herramientas CASE según la perspectiva del
proceso
En función de la amplia ayuda que ofrece la tecnología CASE para el proceso del software, los sistemas CASE se pueden clasificar en tres categorías:
1. Herramientas: ayudan a las tareas individuales del proceso (compilación de un programa y la comparación de los resultados de las pruebas). Las herramientas pueden ser de propósito general, independientes (procesador de texto) o agrupadas en bancos de trabajo.
2. Bancos de trabajo: ayudan a las fases o actividades del proceso (especificación/análisis, diseño, etc.). Son un conjunto de herramientas con algún grado de integración.
Clasificación de herramientas CASE según la perspectiva de
Integración
3. Entornos: ayudan a todos los procesos del software, o una parte sustancial de éstos. Normalmente incluyen varios bancos de trabajo integrados.
La Figura siguiente ilustra esta clasificación y muestra algunos ejemplos de estas clases de ayuda CASE.
Clasificación de herramientas CASE según la perspectiva de
Integración
Clasificación de herramientas CASE según la perspectiva de
Integración
Herramientas de propósito general: se usan a discreción del ingeniero de software, quien decide cuándo aplicarlas para ayudar al proceso.
Bancos de Trabajo: ayudan a algún método que incluye un modelo del proceso y un conjunto de reglas/pautas que se aplican al software en desarrollo.
Entornos: se clasifican en integrados y centrados en el proceso.
Clasificación de herramientas CASE según la perspectiva de
Integración
Entornos Integrados: brindan ayuda a los datos, al control y a la integración de la presentación.
Entornos Centrados en Procesos: son más generales. Incluyen el conocimiento del proceso del software y un motor de procesos para aconsejar a los ingenieros qué herramientas o bancos de trabajo aplicar y cuándo deben utilizarse.
Clasificación de herramientas CASE según la perspectiva de
Integración
Advertencias: En la práctica, los límites entre estas diferentes clases
son borrosos. Las herramientas se pueden vender como productos individuales, y ayudar a diferentes actividades.
Ejemplo: Muchos procesadores de texto incluyen un editor de diagramas integrado. Los bancos de trabajo CASE para el diseño normalmente ayudan a la programación y a las pruebas (se relacionan más con el entorno que con los bancos de trabajo especializados).
Clasificación de herramientas CASE
Conclusiones:
No siempre es fácil ubicar un producto utilizando una clasificación.
Sin embargo, la clasificación brinda un primer paso útil para ayudara entender la amplitud de los servicios que los sistemas CASE pueden proporcionar al Proceso de Desarrollo de Software.
Clasificación de herramientas CASE