Significado dentro del ciclo de vida de desarrollo de sistemas

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




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.


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


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


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.


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.


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.


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.


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


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.


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.


Integración


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.


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.


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

Significado dentro del ciclo de vida de desarrollo de sistemas

Education

Transcript of Significado dentro del ciclo de vida de desarrollo de sistemas