Análisis y Diseño Estructurado

Análisis y Diseño Estructurado
Diagrama de Flujo de Datos Docente : Yessica Gómez Gutiérrez

Integra las actividades de análisis estructurado y OO.
Introducción ANÁLISIS DEL SISTEMAS DE INFORMACIÓN (ASI) Objetivo: Obtener una especificación detallada del SI, y de sus interfaces con otros sistemas, que satisfaga las necesidades de información de los usuarios y sirva de base para el diseño. Integra las actividades de análisis estructurado y OO. Se refinan los productos obtenidos en el proceso EVS.

Productos que se generan: Catálogo de requisitos Glosario En AE,
Actividades Iniciales y Análisis de Requisitos. Donde nos encontramos… Análisis del Sistema de Información (Proceso ASI) Definición del Sistema. Introducción Productos que se generan: Catálogo de requisitos Glosario En AE, Contexto del sistema Modelo conceptual de datos En AOO, Modelo del negocio / Modelo del dominio Catálogo de estándares y de normas Catálogo de usuarios (participantes y finales) Entorno tecnológico del sistema Plan de trabajo

Objetivo: Definición, análisis y validación de los requisitos.
Actividades Iniciales y Análisis de Requisitos. Donde nos encontramos… Análisis del Sistema de Información (Proceso ASI) Establecimiento de los Requisitos. Introducción Objetivo: Definición, análisis y validación de los requisitos. Se completa el catálogo de requisitos. Modelos gráficos de requisitos: casos de uso (obligatorios en AOO, opcionales en AE) Las tareas se realizan de forma iterativa y con continuas realimentaciones y solapamientos.

Actividades Iniciales y Análisis de Requisitos. Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI) - Obtención de Requisitos. Introducción Sesiones de trabajo con los usuarios para extraer los requisitos (con prioridades): Técnica de recogida de información. Catálogo de requisitos. Modelo de casos de uso. Requisitos funcionales Con casos de uso (obligatoriamente) en AOO: Actores. Casos de uso. Breve descripción de cada caso de uso. Requisitos no funcionales: Restricciones del entorno Niveles de servicio del sistema: Rendimiento, seguridad, implantación, disponibilidad...

Actividades Iniciales y Análisis de Requisitos. Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI) Análisis de los Requisitos. Introducción Objetivos: Detectar inconsistencias, ambigüedades, duplicidad o escasez de información. Se revisan las prioridades. Se relacionan requisitos. Identificar relaciones entre casos de uso. Análisis del Sistema de Información (Proceso ASI) Validación de los Requisitos. Objetivo: Mediante esta tarea, los usuarios confirman que los requisitos especificados en el catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos.

Decisión de emprender el proyecto Informe de Necesidades
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Actividades Iniciales y análisis de necesidades. Decisión de emprender el proyecto Recoger información sobre el proyecto (Directivos nivel alto/medio) -Técnicas recogida información Informe de Necesidades Estudio de la viabilidad del proyecto Introducción

Evaluación de las alternativas:
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Estudio de Viabilidad. EVS. Introducción Alternativas. Evaluación de las alternativas: Económico. Técnico. Legal (p.e. LOPD “Ley Orgánica de Protección de Datos”) Operativo. Especificación detallada de la alternativa seleccionada. Definición del plan inicial del proyecto.

Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
Estudio de Viabilidad. Introducción EVS 4. ¿Qué alternativas tengo? Comprar un producto software comercial, ya construido, que cumpla los requisitos marcados. (COTS, Commercial Off-The-Shelf) Desarrollarlo de forma externa mediante un contrato (outsourcing). Automatizar sólo parcialmente el sistema, para no tener que afrontar demasiados gastos. Desarrollar el producto internamente. Esta es la decisión en el caso de la práctica del curso.

Estudio de Viabilidad. Introducción EVS 5. ¿Cómo valoro las diferentes alternativas? Económico: Determinar si el beneficio compensa los costes. Operativa: Determinar si se puede implantar de manera efectiva en la empresa. Legal: Determinar si los requisitos violan o atenta contra alguna ley o reglamento. Técnico: Estudiar si la funcionalidad, el rendimiento.. Son realizables.

Identificar las fuentes de información.
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Técnicas de recogida de Información. Introducción En general, el proceso de análisis debería seguir los siguientes cinco pasos: Identificar las fuentes de información. Realizar las preguntas apropiadas. Analizar la información. Confirmar con los usuarios lo que parece haberse comprendido de los requisitos. Sintetizar los requisitos en un documento. Para la práctica y tras determinar la viabilidad del proyecto, como resultado de la aplicación de una o varias de las técnicas de recogida de información ,se entregará a los grupos un documento que resume/sintetiza los datos obtenidos, que será el punto de partida en la etapa análisis del sistema de información.

Técnicas de recogida de Información. Introducción Entrevistas vs JAD (Joint Application Design): Basada en la creación de equipos de usuarios y analistas que se reúnen para trabajar conjuntamente en el establecimiento de las necesidades del sw a desarrollar. Prototipado: Construcción de una maqueta o modelo de sistema para evaluar los requisitos. Observación: Análisis in situ del entorno a informatizar. Estudio de documentación / Cuestionarios / Tormenta de ideas (brainstorming) ..... Posible proceso de Reingeniería. Análisis de los sistemas de información existentes.

Actividades generales de la etapa de análisis. ASI. Introducción “El proceso de estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hw. o de sw.” “El proceso de estudio y refinamiento de dichos requisitos” [IEEE Std. 610, Glosario estándar de términos en ingeniería del software] Análisis de Requisitos: Condiciones que debe cumplir un sistema para satisfacer un contrato, una norma o una especificación. Condición o capacidad que necesita el usuario para poder resolver un problema o conseguir un beneficio determinado. REQUISITO:

Actividades generales de la etapa de análisis. ASI. Introducción Requisitos Funcionales: describen la funcionalidad o los servicios que se espera que el sistema proveerá: sus entradas y salidas, excepciones, .. etc en resumen su lógica. Nuestra asignatura se centrará en este tipo de requisitos, mientras en la asignatura de Diseño de BBDD se centrará en su dominio, aunque el CGR en el mismo. Requisitos no Funcionales: se refieren a las propiedades emergentes del sistema como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, la capacidad de los dispositivos de entrada/salida, y la representación de datos que se utiliza en las interfaces del sistema. Extracción: El proceso mediante el cual los clientes o futuros usuarios del software descubren, revelen, articulan y comprenden los requisitos que desean. Técnicas de recogida de información. Análisis: el proceso de razonamiento sobre los requisitos obtenidos, detectando y resolución de posibles inconsistencias o conflictos. Especificación de requisitos: el proceso de redacción o registro de los requisitos. Para este proceso puede recurrirse al lenguaje natural, lenguajes formales. Catálogo de requisitos. Validación de los requisitos: el proceso de confirmación, por parte de los usuarios o clientes, de que los requisitos especificados son válidos, consistentes, completos.

Fácil de utilizar durante la fase de explotación y mantenimiento.
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos. Actividades generales de la etapa de análisis. ASI. Introducción Las características deseables para un buen análisis de los requisitos son las siguientes [IEEE 1984b]: No ambigua. Completa. Fácil de verificar. Consistente. Fácil de modificar. Fácil para identificar el origen u las consecuencias de cada requisito. Fácil de utilizar durante la fase de explotación y mantenimiento.

Análisis y Diseño Estructurado
Visión panorámica del Análisis y Diseño Estructurado. Análisis : Diagramas de Flujo de Datos. Diseño: Diagrama de Estructuras

Visión panorámica del AyDE
Análisis Estructurado Método clave en el “desarrollo estructurado” o “convencional” Aparece a finales de los 70 Facilita la comunicación en el proceso de desarrollo de un sistema de información análisis y diseño usuarios y analistas Sencillo, fácil de entender y fácil de aprender El análisis estructurado es un método de especificación de sistemas de información (existen extensiones para sistemas en tiempo real); a través de tal especificación, se facilita la comunicación entre las fases de análisis y diseño del sistema, entre los usuarios y analistas, e incluso dentro del equipo de desarrollo: analistas y diseñadores. Por otro lado, el AE se puede aplicar (dentro del ámbito de la ingeniería de requisitos) a dos niveles: análisis del sistema actual o de los requisitos del nuevo sistema, y síntesis (diseño) de una solución para el nuevo sistema.

Visión panorámica del AyDE. Características
Amplia difusión Descomposición funcional (Originariamente) Orientada a procesos (Originariamente) Top/down Presente en numerosas metodologías p.ej. Métrica, SSADM, information engineering, Merise Herramientas CASE disponibles

Bibliografía Texto principal
Mario Piattini,Jose Calvo-Manzano,Joaquín Cervera,Luis Fernandez, Análisis y diseño detallado de Aplicaciones Informáticas de gestión. Edit. Ra-ma Yourdon, E., Análisis estructurado moderno. 1993: Prentice-Hall Hispanoamericana

Bibliografía (II) Entre la bibliografía básica...
MAP, MÉTRICA versión 2.1. Guía de Técnicas. 1995, Madrid: Ministerio de Administraciones Públicas. Secretaría de Estado para la Administración Pública. Consejo Superior de Informática. Referencias clásicas... DeMarco, T., Structured analysis and system specification. 1979, Englewood Cliffs, New Jersey: Yourdon Press. Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo (traducción de Gane, C. and T. Sarson, Structured systems analysis, tools and techniques. Software series. 1979, New Jersey: Prentice-Hall.)

Visión panorámica del AyDE. Componentes
DFD (Diagrama de Flujo de Dato Dataflow diagram) Diagrama E-R (Entidad-Relación), o alternativamente, DED (Diagrama de Estructura de Datos) Diagramas HVE (Historia de Vida de las Entidades) Diagramas de Transición de Estados (STD, State Transition Diagram) En AE... ... El modelado funcional se realiza a través de los DFDs ... El modelado de datos se realiza mediante diagramas E/R o DED ... El modelado de comportamiento se realiza mediante diagramas HVE o STD, aunque muchas veces no se considera conveniente.

Visión panorámica del AE. componentes
Lógica de procesos Lenguaje estructurado Pre y post-condiciones Tablas de decisión Árboles de decisión Diccionario de Datos (DD)

Visión panorámica del AE. DFD
Visión general de las funciones y transformaciones de datos en una organización Modelo lógico y gráfico del sistema también como modelo físico Identifica entradas, salidas, procesos y relaciones con el exterior ...a nivel general ...por refinamiento, a nivel detallado

Visión panorámica del AE. DFD
Tipos de símbolos en los DFDs (notación de Yourdon/De Marco)

Visión panorámica del AE. DFD: Ejemplo Práctico
Sistema de distribución sin inventario “Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.” Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.

Análisis de los procesos del sistema  Aplicamos la visión sistémica Diagrama de contexto CLIENTE pedidos órdenes de compra libros entregados 0. Sistema de Pedidos en principio, no son materiales, son datos EDITOR libros pedidos

0. Sistema de pedidos pedidos D LIBROS órdenes de compra D ÓRDENES DE COMPRA 2. Armar pedidos a editores 1. Verificar validez de pedido pedidos válidos D PEDIDOS PENDIENTES D CLIENTES estado del crédito pedidos por título pedidos en lote dirección 4. Asignar libros a pedidos 3. Verificar envío de editores libros entregados 5. Armar entrega a clientes libros por clientes libros recibidos libros pedidos libros entregados = albarán + lista-novedades libros recibidos = {título + cantidad}  DD

Visión panorámica del AE. Diccionario de Datos
“Es un conjunto de metadatos, es decir, de información (datos) sobre datos” Contiene las definiciones de todos los elementos de los diagramas Implementación Manual Procesador de textos Base de datos Automático e integrado

Visión panorámica del AyDE. Diccionario de Datos
Flujo de datos: entrega Descripción: Conjunto de libros enviados por un proveedor a la biblioteca, basado en la relación que previamente había recibido. Sinónimos: *** none *** Componente de: *** none *** Composición: Libros + { Albarán } Información de entrada y salida Origen Destino *** Off the diagram *** Compra libros PROVEEDORES Biblioteca

Visión panorámica AyDE Diccionario de Datos (III)
Almacen: Facturas Descripción: Información, por número de factura, sobre facturas en el sistema actual. Sinónimos: *** none *** Composición: @Número-factura + Fecha-factura + Dirección-cliente + { Número-producto + Cantidad-producto + Costo-unidad-producto } + Costo-envío + Tasa-de-descuento + Neto-factura + Estado-factura Procesos asociados: Según DFD general Proc_cancelación Proc_pago Proc_consultas Adjuntar_albarán

Visión panorámica del AyDE. Pseudocódigo.
Proceso: Verificar estado del socio Número: 1.1.1 Descripción: Se examina si el socio no está sancionado Miniespecificación: Recibir “Socio ID” del socio Leer “SOCIOS” para Leer “Flag-de-precaución” Si OK, enviar “Socio ID válido” Complejidad: Prioridad: Ratio de transacciones: Memoria requerida (Kb): Tiempo de proceso:

Visión panorámica del AyDE. Modelado de Datos
Diagramas E-R y DED (Diagrama de Estructura de Datos) DED es, básicamente, un E-R limitado: no relaciones ternarias sólo cardinalidades 1:N no atributos multivaluados ni compuestos

Visión panorámica del AE. Ejemplo de E/R .
Diagrama E-R Proyecto Empleado Departamento asignado pertenece (1,n) (1,1) (0,n) (1,m) [EN2002] (Chen) Asignación Departamento Empleado Proyecto requiere tiene pertenece DED

Visión panorámica del AyDE. Lógica de Proceso.
Técnicas para describir la lógica de los procesos primitivos Lenguaje estructurado Pre y post-condiciones Tablas de decisión Árboles de decisión

Lenguaje estructurado SI la factura excede de 300€ SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días, dejar la confirmación pendiente de este pago. SI NO (la cuenta está en buen estado) hacer confirmación y factura SI NO (la factura es de 300€ o menos) SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días hacer la confirmación, la factura y escribir un mensaje sobre informe de crédito SI NO (la cuenta está en buen estado) hacer confirmación y factura FIN-SI.

Visión panorámica del AE. Lógica de Proceso.
Pre y post-condiciones Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días) Pos1 (confirmación pendiente de este pago) Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días) Pos2 (confirmación y factura realizadas) Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días) Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de crédito) Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días) Pos4 (confirmación y factura realizadas)

Tablas de decisión

Árboles de decisión 1. Dejar confirmación pendiente de los pagos debidos. Cuentas impagadas más de 60 días Factura excede de 300€ Cuentas en buen estado 2. Hacer confirmación y factura Política contable 3. Hacer confirmación y factura y escribir mensaje sobre informe de crédito Cuentas impagadas más de 60 días Cuentas en buen estado Factura menos de 300€ 4. Hacer confirmación y factura

¿Y después del AE? DISEÑO ESTRUCTURADO (DE)
El diseño lógico de los requisitos del nuevo sistema de información se convierte en un modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA. En el paso AE  DE, Análisis de transacciones Análisis de transformaciones

Diseño Estructurado: DIAGRAMA DE ESTRUCTURA
Diseño Estructurado: DIAGRAMA DE ESTRUCTURA. Ejemplo de diagrama de estructuras Informar petición Elaborar informe Rechazar Leer peticiones Consultar stock Recibir Evaluar informe préstamo pet rechazada ok pet préstamo pet aceptada

Visión panorámica AE Esquema resumen
Diagrama de flujo de datos PROC B Z Y X W V A FUENTE DESTINO D ALMACÉN DE DATOS Diagrama de estructuras Paso al diseño Definición del FD Descrip. E. E. Descripción del proceso Diagrama E-R (o DED) En esta visión general se presentan los dos modelos más importantes del AE: el modelo funcional y el modelo de datos. Se obvia el modelo de comportamiento, que se realiza a través de diagramas menos extendidos, como los HVE (Historia de Vida de las Entidades) o los STD (Diagramas de Transición de Estados). El hecho de que en la transparencia el tamaño del DFD sea mayor que el del E-R no quiere decir que el primero tenga mayor importancia: los dos diagramas presentan visiones paralelas, de las funciones y de los datos. Diccionario de Datos Definiciones de la BD Definiciones de los módulos

Diagramas de Flujo de Datos (DFDs)

Símbolos del DFD (notación Yourdon/De Marco)
2.- Diagramas de Flujo de Datos Símbolos del DFD (notación Yourdon/De Marco) P Proceso Transformaciones o procesos (funciones, cálculo, selección) Terminadores (Fuentes o Destinos) (personas, entidades) Entidad Externa Flujos de información (inputs-outputs) Flujo de datos Flujos de control (Ward & Mellor 85) Flujo de eventos Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.) D ALMACÉN DE DATOS

Símbolos del DFD (notación Métrica/SSADM)
2.- Diagramas de Flujo de Datos Símbolos del DFD (notación Métrica/SSADM) Localización Proceso ID Transformaciones o procesos Entidad Externa Terminadores (Fuentes o Destinos) Flujos de información Flujo de datos Ficheros o depósitos temporales de información D ALMACÉN DE DATOS

2.- Diagramas de Flujo de Datos
Procesos 2.- Diagramas de Flujo de Datos TRANSFORMACIÓN (cálculo, operación) FILTRO (verificación fecha, validación transacción) DISTRIBUCIÓN (menú, selección transacción) E2 E3 E1 P Transformación S2 S1

Procesos (II) Nombres únicos, significativos y concisos Preferiblemente expresados en función de las entradas y salidas Recomendación: verbo (no ambiguo) + objeto Evitar verbos ambiguos procesar, gestionar, manejar... “objeto” está definido en el DD Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos

Diagrama de contexto Es el DFD más general de todos Está formado por un solo macroproceso (el sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso Delimita el sistema y su entorno

Entidades externas Señalan los límites del sistema y establecen sus relaciones con el entorno FUENTE DESTINO P FUENTE DESTINO Sistema FUENTE DESTINO Los identificadores (nombres) de las entidades externas serán únicos, significativos y concisos

Flujos de datos Los nombres de los FD deben ser únicos, significativos y concisos Son datos, así que nómbralos como datos. Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades (Barranco 95) Los nombres no sirven sólo para identificar los datos, sino también la información que se tiene sobre ellos P.ej. Información (fecha-válida) > Información (fecha)

Flujos de datos (II) Flujos de datos interactivos (dialog flows) Cuando dos FD establecen un diálogo o comparten una acción de estímulo-respuesta, pueden dibujarse como un único FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan. P Determinar estado pedido respuesta estado pedido petición estado pedido denegación crédito P Analizar Petición Aceptar pago solicitud crédito autorización crédito recibo pago

Flujos de datos (III) Las flechas dobles con sentidos opuestos que transportan los mismos datos pueden sustituirse por flechas doblemente encabezadas ¡Pero sólo si transportan los mismos datos! P X P P P A B A B X X

Flujos de datos (IV) Se puede representar, si se desea, el FLUJO DE MATERIAL, usando flechas de trazo grueso EDITORIALES INTERVENTOR P4 Enviar al dpto. comprador P1 Selecc. y pedir nuevos libros P3 Registrar libros nuevos P5 Poner libros nuevos en estantes P2 Examinar nuevos libros D2 ESTANTES D3 INVENTARIO D4 SIGNATURAS D9 CARRITO LIBROS NUEVOS D1 LISTA MAESTRA DE ISBN nuevas ofertas pedidos de libros nuevos ajuste de inventario ajuste de signaturas libros nuevos Notación Gane & Sarson En principio, no recomiendamos usar flujos de material. En la práctica, los flujos de datos se usa a veces para representar materiales.

Flujos de datos (V) Se pueden considerar flechas convergentes o divergentes, con un mismo nombre P Validar cod postal P cod postal A dirección cli telef número de cuenta calle P Validar Telef. P P Validar calle B Observaciones: Sólo los procesos pueden separar FD (Piattini et al. 96) No poner FD como señales de activación (Yourdon 89)

Flujos de datos (VI) Notación System Architect. Ejemplos
2.- Diagramas de Flujo de Datos Flujos de datos (VI) Notación System Architect. Ejemplos FD divergentes (conectores XOR y AND) P Imprimir factura cliente Imprimir lista empaquetado Determinar prods.para enviar XOR cuando los datos son divididos en subconjuntos datos de facturación datos de empaquetado datos de envío P Determinar prescripción Rellenar prescripción Actualizar registro paciente AND cuando todos los datos siguen por ambos caminos prescripción

Flujos de datos (VII) Notación System Architect. Ejemplos
2.- Diagramas de Flujo de Datos Flujos de datos (VII) Notación System Architect. Ejemplos FD convergentes (conectores XOR y AND) P Aceptar pago en metálico Transferir pago Aceptar pago a crédito XOR cuando los mismos datos provienen de cualquier dirección datos de pago P Confirmar historial de crédito Conceder tarjeta de crédito Confirmar empleo AND cuando los subconjuntos son combinados en uno historial de empleo historial de crédito historia combinada

Flujos de datos (VIII) P Evaluar pedido ¿El proceso “pide” el FD “pedido”? ¿El proceso “necesita” ambos FD? pedido criterios valoración No lo sabemos, no importa: Los aspectos procedurales no se manifiestan en los DFDs Si tales aspectos son relevantes, se deben incluir en las miniespecificaciones

Flujos de control En los DFDs no se muestra el control ni el orden de ejecución No se puede mostrar: Procesos que se realizan antes que otros Sincronización Periodificación Extensiones al AE para sistemas en tiempo real: (Ward & Mellor 85) (Hatley & Pirbhai 87)

Almacenes de datos Nombre único, significativo y conciso Convenciones de nombres en los FD a/desde un almacén: No lleva etiqueta El FD se refiere a un paquete (instancia) completo de la información contenida en el almacén La etiqueta es la misma que la del almacén El FD se refiere a uno o más paquetes completos (instancias) de la información contenida en el almacén La etiqueta es distinta de la del almacén El FD se refiere a uno o más componentes (atributos) de una o más instancias del almacén

Consistencia DFD / E-R (MAP 95)
2.- Diagramas de Flujo de Datos Consistencia DFD / E-R (MAP 95) Para facilitar validaciones cruzadas entre DFDs y E-R (o DED)... Correspondencia entre los almacenes de datos “principales” (permanentes) del DFD y las entidades del E-R Cada almacén de un DFD representa una o varias entidades del E-R Cada entidad del E-R pertenece a un único almacén principal de un DFD

Consistencia DFD / E-R (II)
2.- Diagramas de Flujo de Datos Consistencia DFD / E-R (II) ETIQUETA DE LOS ALMACENES Según explosione a Entidad de datos  Plural nombre entidad Diagrama E-R (o DED)  Nombre diagrama DEFINICIÓN DE LOS ALMACENES Pocos almacenes Para cada uno, diagrama E-R (o DED) Tantos almacenes como entidades se hayan identificado Preferible (si no hay muchas entidades)

Descomposición funcional
2.- Diagramas de Flujo de Datos Descomposición funcional Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerárquicamente Los niveles de la jerarquía están determinados por la descomposición funcional de los procesos La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos

Descomposición funcional (II)
2.- Diagramas de Flujo de Datos Descomposición funcional (II) P Sist B A FUENTE DESTINO P f5 f4 f3 f2 f1 B Z Y X W V A P f45 f44 f43 f42 f41 Z y2 x2 y1 x1 Y X

Consistencia en el DFD Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo” Balanceo de DFDs Las E/S de un proceso “padre” deben corresponderse con las E/S del DFD “hijo” que lo explica

Descomposición paralela
2.- Diagramas de Flujo de Datos Descomposición paralela Descomposiciones de funciones Proceso en subprocesos (DFD) Descomposición de flujos de datos La regla de balanceo se aplica teniendo en cuenta la descomposición paralela

Descomposición paralela (II)
2.- Diagramas de Flujo de Datos Descomposición paralela (II) Ejemplo: pedido = autorización + cupón de pedido + pago P6 P5 P4 P3 P2 P1 envío pedido P6.3 P6.2 P6.1 pago envío cupón de pedido autorización

Jerarquía de DFDs En un DFD completo cada proceso tiene un número único que lo identifica en función de su situación en la jerarquía Cada DFD tiene también un número único que coincide con el proceso que describe Las hojas o nodos terminales corresponden a “procesos primitivos” o indescomponibles Para cada proceso primitivo existirá una miniespecificación. Localización Proceso Proceso primitivo en Métrica

Jerarquía de DFDs (II) P 1.2 Proceso A B A P 1.2.3 f3 P 1.2.1 f1 Y W V A X P 1.2.2 f2 DFD 1.2

Jerarquía de DFDs DFD 0 El primer diagrama general que sigue al de contexto es el número 0 por convenio En el DFD 0 se hace una descomposición en subsistemas, es decir, se indican los procesos más importantes en el sistema  Han de ser SUBSISTEMAS

Descomposición funcional y almacenes de datos
2.- Diagramas de Flujo de Datos Descomposición funcional y almacenes de datos Los almacenes aparecen lo más tarde posible En un nivel superior únicamente cuando son interfaz entre procesos Una vez que aparezca en un DFD, el almacén aparecerá otra vez en cada DFD de nivel más bajo relacionado

Descomposición funcional y almacenes de datos (II)
2.- Diagramas de Flujo de Datos Descomposición funcional y almacenes de datos (II) P A.2 A.1 D FICH B.2 B.1 P P A B D FICH

Tamaño de la jerarquía de DFDs
2.- Diagramas de Flujo de Datos Tamaño de la jerarquía de DFDs Cada DFD debería tener alrededor de 7 procesos o menos (Miller 57) En general, habrá varios niveles intermedios, dependiendo del tamaño y complejidad del sistema que se está modelando ¿Cuántos niveles son convenientes? Yourdon: depende del problema (Miller 57) Miller, G.A. The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psycological Review, vol. 63, pp Diagrama de contexto / sistema Diagrama de subsistemas Diagrama de funciones Diagrama de subfunciones Diagrama de procesos (opcional) Métrica

Reglas sintácticas en DFDs
2.- Diagramas de Flujo de Datos Reglas sintácticas en DFDs El origen y/o el destino de un FD es siempre un proceso Excepción: almacenes en el diagrama de contexto (Yourdon 89) CLIENTE datos del mercado CLIENTES CORPORATIVOS informes anuales D DATOS DEL MERCADO CENTROS DE INVESTIGACIÓN datos de investigación P SIST. DE INVESTIG. DE MERCADOS datos del mercado

Reglas sintácticas en DFDs (II)
2.- Diagramas de Flujo de Datos Reglas sintácticas en DFDs (II) Todo almacén y todo proceso tienen uno o más FD de E y uno o más FD de S EXCEPCIÓN: un almacén puede no tener FD de salida, por simplificación (p.ej. BD Histórica) RECOMENDACIÓN: si aparece un proceso fuente o sumidero, replantearse los límites del sistema P Sumidero P Fuente

Ideas útiles para construir el DFD
2.- Diagramas de Flujo de Datos Ideas útiles para construir el DFD Identificar todos los elementos exógenos Identificar sus relaciones con el sistema Trabajar según alguna de las siguientes filosofías: De inputs a outputs De outputs a inputs Desde una posición intermedia hacia delante o hacia atrás

Ideas útiles para construir el DFD (II)
2.- Diagramas de Flujo de Datos Ideas útiles para construir el DFD (II) Nombrar adecuadamente todos los objetos del DFD Numerar adecuadamente procesos y diagramas Realizar una correcta división en subsistemas (DFD 0) Utilizar la descomposición funcional jerárquica hasta alcanzar las funciones primitivas

DFDs - Conclusiones Valiosa herramienta de comunicación Usuario, analista, diseñador, programador Se puede combinar con el uso de prototipos Fácil de entender y de aprender Facilita las relaciones con el usuario Amplia difusión

DFDs – Conclusiones (II)
2.- Diagramas de Flujo de Datos DFDs – Conclusiones (II) Superado por las metodologías OO, pero todavía vigente: se enseña en 12 de 15 ppales. universidades españolas,casi todas en Chile industria, administración (Métrica 2.1 y 3), cuerpo de conocimiento de ingeniería del software (SWEBOK, SEEK, etc.) El control no aparece hasta el final de la especificación estructurada No es inmediato el paso a la codificación y prueba  Diseño estructurado

DFDs – Conclusiones (III)
2.- Diagramas de Flujo de Datos DFDs – Conclusiones (III) Útil para el análisis y para el diseño del nuevo sistema Más adecuado para el nivel lógico, aunque también puede ser adecuado para el nivel físico (indicando personas concretas, lugares geográficos, formatos de datos, etc.)

3.- Diseño: Diagrama de Estructuras
Diseño Estructurado Introducción Concepto y Principios del Diseño Inicios del Diseño Efectividad del Diseño Módulo(laridad) Abstracción Refinamiento Factores de calidad Acoplamiento Cohesión Tipos de Acoplamiento Tipos de Cohesión Consideraciones para un Diseño de Calidad Resultados del Diseño

3.- Diseño: Diagrama de Estructuras
Diseño Arquitectónico ( Diseño Preliminar) Elementos Diagrama de Estructura Partición Estructural de un Diagrama de Estructura Estrategias de Diseño Construcción del Diagrama de Estructura

Concepto y Principios del Diseño
“ El diseño es un proceso a través del cual los requerimientos establecidos en la fase de análisis deben traducirse en una representación ‑que se sugiere modular‑ del producto de software que se precisa construir y que se acompaña de los procedimientos en virtud de los cuales cada módulo debe llevar a cabo su tarea, y de las estructuras de datos que debe procesar” Larry Constantine ‘78

Concepto y Principios del Diseño
El diseño estructurado es un método de configuración de la organización modular del software que se desarrolla a partir de los flujos de datos que contiene la especificación de requerimientos obtenida en la fase de análisis bajo enfoque estructurado. En este sentido, puede decirse que este enfoque consiste en el diseño de programas como estructuras de funciones únicas y de relativa independencia.

Efectividad del Diseño
Para poder evaluar la efectividad de una representación de diseño, es preciso establecer lo que se denomina en Ingeniería de software, "criterios para un buen diseño", entre los cuales es posible destacar los siguientes: El diseño debe exhibir una organización jerárquica con mecanismos de control que no atenten contra la independencia relativa de cada componente de la jerarquía.

‑ El diseño debe ser modular, esto es, el software debe estar particionado lógicamente en elementos que ejecuten funciones y subfunciones específicas. - El diseño debe generar módulos que exhiban niveles adecuados de independencia funcional. ‑ El diseño debe obtenerse a partir de la especificación de requerimientos generada durante la fase de análisis. ‑ Módulo(laridad) ‑ Abstracción ‑ Refinamiento

‑ Módulo(laridad) “Módulo es una unidad claramente definida y manejable que forman parte de los elementos constituyentes del software” “La modularidad consiste básicamente en el particionamiento del software en elementos con nombres y direcciones separadas que se denominan módulos, los cuales en su composición generan la totalidad que debe ser capaz de resolver el problema global que da origen a la necesidad de construir un producto de software. “ Tiene que ver con la separabilidad de las funciones que en conjunto cumplen un objetivo mayor, esto es, responden a la idea de totalidades emergentes propia de la noción de sistemas.

‑ Beneficios de la Modularidad ‑ Programas más simples, ya que puede ser comprendido, verificado, programado, depurado, mejorado y alterado por partes. ‑ Módulos que pueden ser desarrollados con relativa independencia. ‑ Disminución de la posibilidad de errores al reducir la complejidad. ‑ Programas que pueden evaluarse por partes, por lo cual todo test se hace más fácil. ‑ Programas más fáciles de alterar ya que son menores las líneas de código a considerar para incorporar los cambios. ‑ Módulos de función única que pueden ser reutilizados.

‑ Beneficios de la Modularidad ‑ La posibilidad de cometer errores por parte de los programadores disminuye porque son menos las líneas de código que deben enfrentarse al mismo tiempo. ‑ La rotación de personal se hace menos crítica, ya que los programadores están involucrados en unidades de código más pequeñas por lo cual la sustitución resulta menos dificultosa. ‑ Responder al requerimiento de la división del código en segmentos de una página, como lo sugiere la programación estructurada, es casi total.

‑ Módulo El Fan‑out es una medida del número de módulos controlados directamente por otro módulo (número de subordinados inmediatos que posee). El Fan‑in indica cuántos módulos controlan directamente un determinado módulo (número de superiores inmediatos que posee) Un módulo que controla a otro se dice que es "superordinado" a éste y, recíprocamente, un módulo controlado por otro se dice que es "subordinado".

‑ Módulo Módulo Superordinado Módulo Subordinado Fan‑out : 2 Fan‑in : 1

‑ Módulos & Integración Costos o Esfuerzo Costo Total SW Costo por Integración Costo por Módulo N° Módulos Costos Mínimos

‑ Abstracción “Cuando se considera una solución modular para enfrentar un problema, se puede plantear en distintos niveles de abstracción. Un nivel superior de Abstracción supone una solución en términos amplios, usando un lenguaje del entorno del problema. A un niveles más bajos, se toma una orientación más procedimental, se combina una terminologia orientada al problema con una orientada a la implementación. El nivel más bajo de abstracción permite que la solución pueda implementarse directamente”

‑ Refinamiento El refinamiento gradual es una estrategia de diseño top_down cuyo origen es la propuesta de Niklaus Wirth (WIRTH‑71) quien postula que "La arquitectura de un programa se desarrolla refinando sucesivamente los niveles de detalle de los procedimientos. De este modo se desarrolla una jerarquía de procedimientos al descomponer sucesivamente una sentencia global hasta alcanzar sentencias específicas a nivel de un lenguaje de programación". R. Pressman (PRESSMAN‑88) al respecto cita a Wirth señalando que: "En cada etapa (del refinamiento), se descomponen una o varias de las instrucciones del programa dado en instrucciones cada vez más detalladas. Esta descomposición o refinamiento sucesivo termina cuando todas las intrucciones están expresadas en términos de cualquier lenguaje básico de computador o de programación.

‑ Refinamiento En el dominio de la Ingeniería de Software, la modularización se apoya en lo que se conoce como refinamiento sucesivo o gradual, para la configuración de la estructura del software que se precisa diseñar y luego construír. Abstracción Refinamiento Gradual Módulo A Modularidad Factorización A1 A2

Factores de Calidad ‑ Acoplamiento
Corresponde al grado de independencia entre dos módulos. Entendido así, minimizar el acoplamiento aparece entonces como una determinante prioritaria al configurar las conformaciones estructurales. La obtención de módulos tan independientes como sea posible,se puede ser lograda principalmente de tres maneras: ‑ Eliminando relaciones innecesarias. ‑ Reduciendo el número de relaciones necesarias. ‑ Debilitando la dependencia de las relaciones necesarias.

Factores de Calidad ‑ Cohesión
Corresponde a la medida de relación funcional de los elementos de un módulo, Los elementos de un módulo corresponden a instrucciones, definiciones de datos, o llamadas o otros módulos. La idea es organizar estos elementos de tal manera que tengan una mayor relación entre ellos a la hora de realizar la tarea específica del módulo

Factores de Calidad Acoplamiento Principios de un Buen Diseño Cohesión

Tipos de Acoplamiento Acoplamiento Normal Acoplamiento por Datos
Acoplamiento por Estampado o Imagen Acoplamiento de Control Acoplamiento Común Acoplamiento por Contenido

Tipos de Acoplamiento Mejor Acoplamiento NORMAL DATOS ESTAMPADO
CONTROL EXTERNO (caso especial de COMÚN) COMÚN CONTENIDO Grado de Acoplamiento

Tipos de Acoplamiento Acoplamiento Normal
Dos Módulo A y B están Normalmente Acoplados si: Un Módulo A llama a otro B B retorna el control a A No se produce traspaso de parámetros entre ellos, sólo existe la llamada de uno a otro. A B

Tipos de Acoplamiento 2. Acoplamiento por Datos Obtener
Dos módulos están acoplados por datos si ellos se comunican por parámetros, siendo cada parámetro una unidad elemental de datos El acoplamiento por datos corresponde a la comunicación de datos necesaria entre módulos. Toda vez que los módulos tienen que comunicarse entre sí, la ligazón por datos es inevitable y serán adecuadas si se mantienen a niveles mínimos. Obtener Datos Cliente Rut_cliente Leer Rut

Tipos de Acoplamiento 3. Acoplamiento por Estampado o Imagen Calcular
Dos módulos aparecen acoplados por estampado o ligados por imagen si ellos se refieren a la misma estructura datos local. Cabe destacar que por estructura de datos se debe entender un grupo compuesto de datos, tal como un registro, el cual, por su parte, se constituye de varios campos. Calcular Deuda Cliente Cliente Leer Cliente Cliente= rut+nombres+apellido_paterno+ Apellido_materno+dirección+fono+e_mail

Tipos de Acoplamiento 4. Acoplamiento de Control Obtener Datos
Dos módulos están acoplados por control cuando uno de ellos pasa al otro módulo elementos de control (flags, switchs) como argumentos. Provoca dependencia de ejecución entre un módulo y otro. No es muy recomendable. Obtener Datos Cliente Tipo_dato Cliente Leer Cliente

Tipos de Acoplamiento Actualizar Stock Video Obtener Nombre Video
5. Acoplamiento Común Los módulos presentan acoplamiento común, si ellos se refieren a la misma área estructura de datos (global). Cuando sólo se acomplan por una variable (global), se trata de un Acoplamiento Externo video Leer Registro Video Programas con muchos datos globales son extremadamente difíciles de entender por los programadores de mantención, porque no es fácil saber cuáles son los datos usados por un cierto módulo.

Tipos de Acoplamiento 6. Acoplamiento por Contenido
Este es un tipo de Acoplamiento Inaceptable. Dos módulos presentan acoplamiento de contenido (o patológico) si uno hace referencia al interior del otro. Esto ocurre si por ejemplo, en un módulo se desvía la secuencia de instrucciones al interior de otro o si un módulo altera un comando de otro. A B ……….. Srch: Move.. ………. ……… ……….. ……… Jump to Srch ………. Tal acoplamiento torna el concepto de módulos configurados bajo el criterio de la caja negra sin sentido, ya que fuerza a un módulo a conocer explícitamente los contenidos y la implementación de otro.

Enfoques: ¿Cómo Analizar el Tipo de Acoplamiento?
Tipos de Acoplamiento Dos módulos pueden estar relacionados por más de un tipo de acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si dos módulos están ligados por acoplamiento de imagen y acoplamiento común a la vez, se dirá que los módulos están ligados por acoplamiento común. Enfoques: ¿Cómo Analizar el Tipo de Acoplamiento? Imaginar el Módulo como una Biblioteca Cada Módulo es codificado por un programador diferente

Tipos de Cohesión STEVEN, MYERS, CONSTANTINE y YOURDON (1974)
Mayor Cohesión Módulo como Caja Negra FUNCIONAL SECUENCIAL COMUNICACIONAL PROCEDURAL Módulo Transparente TEMPORAL LÓGICA COINCIDENTAL Grado de Cohesión STEVEN, MYERS, CONSTANTINE y YOURDON (1974) establecieron "una escala de cohesión"

Tipos de Cohesión 1. Cohesión Funcional
Se puede decir que un módulo con cohesión funcional es aquel que contiene elementos que contribuyen a la ejecución de una y sólo una tarea relacionada al problema objeto de diseño,. Ejemplos Calcular el coseno de un ángulo Calcular el I.V.A. De una factura Verificar el dígito de un RUT

Tipos de Cohesión 2. Cohesión Secuencial
Un módulo secuencialmente cohesionado es aquel cuyos elementos están envueltos en actividades tales que los datos de salida de una actividad sirven como datos de entrada para la próxima actividad. Ejemplo: Calcular Salario 1. Obtener sueldo base 2. Verificar número de cargas 3. Revisar días con permiso 4. Revisar días con licencia 5. Calcular horas de trabajo 6. Descontar horas de atraso 7. Agregar horas extras ....

Tipos de Cohesión 3. Cohesión Comunicacional
Un módulo presenta cohesión comunicacional cuando sus elementos contribuyen a actividades que usan la misma entrada o la misma salida. No importa el orden secuencial Ejemplo: Obtener datos Video 1. Obtener nombre video 2. Obtener stock video 3. Obtener ubicación 4. Obtener precio ....

Tipos de Cohesión 4. Cohesión Procedimental
un módulo cohesionado por procedimientos es aquel cuyos elementos están envueltos en actividades diferentes y posiblemente no relacionadas, en donde el control fluye de una actividad a otra. Ejemplos: Actividades en una oficina 1. Hablar por teléfono 2. Tomar un café 3. Leer correo electrónico 4. Solicitar cotización ....

Tipos de Cohesión 5. Cohesión Temporal Un módulo con cohesión temporal es aquel cuyos elementos están envueltos en actividades que están relacionadas en función del momento en que se realizan. Ejemplo: Actividades al iniciar el día 1. Apagar despertador 2. Tomar una ducha 3. Vestirse 4. Hacer la cama 5. Tomar desayuno ....

Tipos de Cohesión 6. Cohesión Lógica
Un módulo tiene cohesión lógica, cuando existe alguna relación entre los elementos del módulo, contribuyendo al desarrollo de actividades de una misma categoría general, donde la actividad o las actividades a ser ejecutadas se seleccionan desde fuera del módulo. Ejemplo: Registrar Pago 1. Registrar pago con tarjeta de crédito 2. Registrar pago con cheque 3. Registrar pago con efectivo ....

Tipos de Cohesión 7. Cohesión Coincidental Ejemplo:
Un módulo coincidentemente cohesionado es aquel cuyos elementos desarrollan actividades sin relación significativa entre sí. Ejemplo: 1. Comprar un libro 2. Comer un trozo de torta 3. Ir al teatro 4. Lavar la ropa 5. Dormir ....

Árbol de Cohesión

Consideraciones Importantes para un Diseño de Calidad
La factorización consiste en separar la funcionalidad de un módulo, en subfunciones claramente identificables, en términos tales que sea posible considerarla como constitutiva de un módulo independiente. 1. La necesidad de reducir el tamaño de un módulo. 2. Obtener las ventajas de la modularización mediante un diseño "top_down". => Sistema más comprensible el sistema y facilitamiento de cambios 3. Evitar que una misma función aparezca en diferentes partes del sistema, es decir, en más de un módulo. 4. Proveer módulos de uso general. 5. Simplificar la implementación.

Reducir el Tamaño de un Módulo
1. De Marco señala, un tamaño razonable para un módulo corresponde a un conjunto de líneas de código de alrededor de media página de listado (30 líneas más o menos), 2. Page‑Jones, señala que toda la codificación de un módulo debería, idealmente, ser visible en una página de listado (una exigencia que impone un límite no superior a 60 líneas) 3. Geral Weinberg (WEI‑72) muestran que la habilidad del hombre para entender un módulo y encontrar errores depende de la capacidad de aprehender el módulo como un todo de una sola vez.

Resultados del Diseño El proceso de diseño debe lograr la determinación de las directrizes en virtud de las cuales el producto de software ha de construirse, tomando como base la especificación de requerimientos generada en la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe dar como resultado: el Diseño de la Arquitectura del producto de software a construir. la Especificación de los Procedimientos del software a construir. el Diseño de los Datos involucrados el Diseño de la Interfaz de usuario

Diseño Arquitectónico

Diccionario de Datos Clave_votante_válida: Flag que indica que la combinación ingresada por el cliente es válida, y puede llevar a emitir su voto.

Especificación de procesos
Nombre : REGISTRAR DATOS ACTUALIZACIÓN Entradas : Datos_actualización Salidas :Datos_actualización, datos_actualización_registrados. Procedimiento: Recibir Datos_actualización. Abrir archivo INFORMACIÓN MUNICIPAL. Escribir en archivo los Datos_actualización. Cerrar archivo INFORMACIÓN MUNICIPAL. Mandar mensaje indicando Datos_actualización_registrados. Interfaz Pseudocódigo

Diseño de Datos

Diseño de Interfaz

Elementos del Diagrama de Estructura
Obtener Nombre Video Módulo Leer Registro Video Módulo Predeterminado X MÓDULO JEFE (INVOCADOR) Y MÓDULO SUBORDINADO (INVOCADO)

Obtener Datos Cliente Flujo de Control Flujo de Dato Tipo_dato Cliente Leer Cliente Un dispositivo físico es cualquier dispositivo mediante el cual se puede recibir o enviar datos necesarios para el sistema Un almacén de datos corresponde a la instancia real en la cual van a estar los datos que precisa el sistema

Conectores

Secuencia Iteración

Selección

Profundidad y Ancho de un Diagrama de Estructura
Profundidad y ancho proporcionan una idea del número de niveles de control y el ámbito global de control respectivamente. El grado de salida es una medida del número de módulos que son controlados directamente por otro módulo. El grado de entrada indica cuántos módulos controlan directamente un módulo dado.

Estrategia de Diseño para Construir Diagrama de Estructura
Diseño Centrado en Transformaciones Diseño Centrado en Transacciones Diagrama de Estructura DFD Análisis Diseño

Estrategia de Diseño Diseño Centrado en Transformaciones
Diseño Centrado en Transformaciones Los datos entran al sistema mediante caminos que se llaman flujos de entrada En el núcleo ocurre la transformación de los datos, que entraron anteriormente Finalmente los datos se mueven por caminos llamados flujos de salida 1.1 1.2 3 4.1 2.1 2.2 4.2 Flujo de Llegada Flujo de Salida Centro de Transformación

Estrategia de Diseño Diseño Centrado en Transacciones
Se presenta un centro de transacción, como centro de flujo de información Desde el centro de flujo de Información, surgen muchos caminos de acción alternativos Los caminos de acción alternativos, son de forma excluyentes Camino de Acción 1 2.1 2.2 1 3.1 3.2 Camino de Acción 2 Centro de Transacción 4.1 4.2 Camino de Acción 3

Estrategia de Diseño: Transformación
1. Revisión del Modelo Fundamental del sistema DFD, mínimo tres niveles 2. Determinar si el DFD tiene características de Transformación o Transacción Analizar el centro de transformación propiamente tal 3. Aislar el centro de Transformación, especificando los límites del flujo de llegada y de salida Delimitar el centro de transformación (depende del diseñador) 4. Realizar el primer corte del diagrama de estructura Primer nivel de factorización, se incorporan módulos coordinadores

Módulos a incorporar Módulo principal Cp, que controla el resto de los módulos Módulo coordinador de la Información de Entrada, Ce Módulo controlador del centro de transformación, que supervisa las operaciones de los datos, Ct Módulo controlador, del procesamiento de la información de salida, Cs 1.1 4.2 4.1 3 1.2 2.1 2.2 Flujo de Llegada Centro de Transformación Flujo de Salida Diagrama de Contexto Cp Ce Ct Cs Nombres representativos

5. Ejecución del “segundo nivel de factorización” 5. Ejecución del “segundo nivel de factorización” a 1.1 4.2 4.1 3 1.2 2.1 2.2 Flujo de Llegada Centro de Transformación Flujo de Salida Cp b z Ce Ct Cs 1.2 2.2 3 4.1 1.1 2.1 4.2 Leer a Leer b Escribir z

6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad Aumentar o Disminuir el N° de módulos (ejemplo Ct) Incorporar flujos de datos (DFD) y de control 7. Asegurarse del trabajo realizado, representado en el diseño construido Verificar funcioanalidad, orden de módulos, etc.

Estrategia de Diseño: Transacción
1. Revisión del Modelo Fundamental del sistema DFD, mínimo tres niveles 2. Determinar si el DFD tiene características de Transformación o Transacción Analizar el centro de transacción propiamente tal 3. Aislar el centro de Transacción, especificando los límites del flujo de llegada y de salida El centro de transacción se encuentra ligado al origen de varios caminos de información que fluyen radialmente de él 4. Realizar el primer corte del diagrama de estructura Primer nivel de factorización, se incorporan módulos coordinadores

R A Q D P a z b Módulos a incorporar Módulo principal Cp, que controla el resto de los módulos Módulo coordinador de la Información de Entrada, Ce Módulo gestor del centro de transacción, D Módulo controlador, los distintos caminos que generan información de salida, Ci i =1—n (n: n° caminos) Cp Ce D C1 C2 C3

5. Ejecución del “segundo nivel de factorización” 5. Ejecución del “segundo nivel de factorización” Camino 1 Cp a A D Camino 2 Ce D P Q z R a b Camino 3 C1 C2 C3 Leer a P Q R Escribir z Leer b

6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad Aumentar o Disminuir el N° de módulos Incorporar flujos de datos (DFD) y de control 7. Asegurarse del trabajo realizado, representado en el diseño construido Verificar funcionalidad, orden de módulos, etc.

Diseño Procedimental (Diseño Detallado
Especificación Interfaz-Función Especificación Mediante las Miniespecificaciones del Análisis Especificación por Pseudocódigo

Diseño Detallado 1. Especificación por interfaz-función
Permite definir un módulo sin entrar en excesivos detalles. La interfaz del módulo contiene los parámetros de entrada y de salida, mientras la función del módulo describe las tareas que este lleva a cabo. Se permite el uso de tablas, fórmulas, lenguaje natural, etc. Permite variar el grado de formalismo en la definición del módulo, generalmente, dando bastante libertad a los programadores. Su inclusión como comentario en el código final facilita el mantenimiento.

Ejemplo: Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE Función: Seleccionar un asiento para un pasajero considerando que sus preferencias de ubicación sean lo más cercanas (ponderadamente) al asiento elegido.

Diseño Detallado 2. Especificación Mediante las Miniespecificaciones del Análisis Este método considera que las miniespecificaciones generadas durante la fase de análisis sirven también como especificación de módulos. Se considera, en general, que la especificación de cada burbuja del diagrama de flujo de datos es suficiente para especificar lo que en la fase siguiente al diseño se debe construir. La gran limitación de este método es que no siempre existe una correspondencia uno a uno entre las burbujas, explicitadas como necesarias de automatizar en la fase de análisis, y los módulos del diagrama de estructura.

Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE Función: Seleccionar un asiento para un pasajero considerando que sus preferencias deubicación sean lo más cercanas (ponderadamente) al asiento elegido. Detalles de Funcionalidad · Buscar asiento disponible comenzando con la clase solicitada y continuando con clases inferiores. · Anotar para cada asiento la diferencia respecto a la preferencia del cliente. · Seleccionar el asiento con menor diferencia: este será el Asiento-Seleccionado. (Diferencia=Dif-Fumador*PESO_FUMADOR+ ...) · Si el cliente necesita un asiento no fumador (y Peso-Fumador > 1) y ha sido seleccionado un asiento fumador, intentar mover en una fila atrás la sección de no fumadores en la clase del cliente (si es posible). · Si la diferencia entre el asiento preferido y el asiento seleccionado es 0, realizar la asignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario asígnele “N”.

Diseño Detallado 2. Especificación por pseudocódigo
Pseudocódigo es un lenguaje informal similar al lenguaje estructurado, el cual es más preciso y detallado que la especificación por interfaz-función. Tiene sintaxis fija para constructores, declaración de datos y módulos, y sintaxis libre para describir características de procesamiento

Análisis y Diseño Estructurado

Presentaciones similares

Presentación del tema: "Análisis y Diseño Estructurado"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Análisis y Diseño Estructurado

Presentaciones similares

Presentación del tema: "Análisis y Diseño Estructurado"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback