Unidad_3 Diagramas Estructurados
Anuncio
Introducción al Diseño de Sistemas de Información Unidad Nº III: Diagramas Estructurados Facultad Regional Santa Fe Universidad Tecnológica Nacional Diagramas Estructurados Los Diagramas Estructurados (DE) se utilizan para la representación modular de las funciones del sistema. Representan el diseño de procesos, y se vinculan normalmente con un programa. El bloque de construcción básico de un programa es un módulo. Los programas estructurados están organizados en una “jerarquía de módulos”. El diagrama estructurado es un árbol o diagrama jerárquico que define la arquitectura de un programa mostrando los módulos de un programa y sus interrelaciones. La siguiente figura muestra el diagrama estructurado para un Sistema de Suscripción. Suscripción Subitem válido Subitem válido Obtener subitem válido Validar Item Nuevo subitem Subitem Renovar subitem OK Subitem Leer subitem Tareas de Alto Nivel Validar subitem Nueva suscripción Cancela r subitem Cancelación Nuevo subitem Renovación Registro Tareas de Bajo Nivel Registro Registro Agregar nuevo registro Crear cuenta Crear registro de auditoría El programa es representado como un conjunto de módulos ordenados jerárquicamente. Los módulos que realizan tareas de programa de alto nivel están ubicados en la parte superior de la jerarquía, mientras que los módulos que realizan tareas de bajo nivel se encuentran en los niveles inferiores de la jerarquía. Los bloques de construcción básica de los diagramas estructurados son rectángulos y flechas que los conectan. Cada rectángulo en el diagrama representa un módulo. Lógicamente, un módulo es una tarea que el programa ejecuta, tal como ‘Agregar nuevo registro’ o ‘Crear cuenta’. El nombre del módulo debe ser escrito dentro del rectángulo. El nombre debería ser descriptivo de la tarea que realiza el módulo. Los módulos están interrelacionados por una estructura de control. El diagrama estructurado muestra las interrelaciones ordenando los módulos en niveles y conectándolos por líneas. Una flecha entre dos módulos de niveles sucesivos significa que en tiempo de ejecución, el control del programa pasa de un módulo al segundo en la dirección de la flecha. Decimos que el primer módulo invoca o llama al segundo. Por ejemplo, en este caso: 2 Nueva suscripción Registro Crear cuenta El módulo ‘Nueva Suscripción’ invoca al módulo ‘Crear cuenta’. Cuando el módulo ‘Crear cuenta’ termina su ejecución el control vuelve nuevamente al módulo ‘Nueva Suscripción’. Es posible que un módulo invoque o llame a varios módulos. Los diagramas estructurados no muestran estrictamente secuencia, con lo cual no sabemos en qué orden un módulo invoca a sus hijos, pero, como normal, se estable que la secuencia de ejecución de los módulos se muestra de arriba hacia abajo y de izquierda a derecha. Un módulo que no tiene hijos se llama Hoja. Reglas de control para un diagrama estructurado Hay uno y sólo un módulo al tope de la jerarquía (nivel 1) del DE. Este módulo el llamado raíz (root). Desde la raíz el control es pasado hacia abajo nivel por nivel a los otros módulos. El control siempre es devuelto al módulo invocante. Por esto, cuando la ejecución del programa finaliza, el control regresa al root. Hay a lo sumo una relación de control entre dos módulos cualesquiera. Si el módulo A invoca a B, B no puede invocar a ‘A’. Módulos comunes A B C E D En este ejemplo, el módulo E es llamado módulo común. Este diagrama ya no es mas un árbol, esto se hace para no repetir el módulo E dos veces. Módulos librería Leer caracter En algunos casos, el programa puede usar módulos de librerías predefinidas. Esto es indicado en el diagrama por un rectángulo con dos líneas verticales. Normalmente, un módulo librería aparece como hoja en el DE. Transferencia de datos Cuando el control es transferido entre dos módulos, usualmente se transfieren también datos. Los datos pueden ser transferidos en ambas direcciones entre los módulos. La dirección de la 3 transferencia de los datos lo indican la flechas pequeñas. Los nombres de datos son escritos sobre las flechas. Tomar subitem válido subitem OK Validar subitem Dos tipos básicos de información pueden comunicarse entre dos módulos: Datos (acoplamiento de datos) Control (acoplamiento de control) Los datos son información usada en el problema, tal como una ‘suscripción de subitem’, o un ‘legajo’ de empleado, o ‘el detalle de una factura’, etc.. Este tipo de información es identificada por una flecha con un círculo vacío en su origen ( ). Control es información usada por el programa para dirigir el flujo de ejecución, tal como un indicación de que ha ocurrido un error o se ha llegado al fin de archivo. Es identificada por una flecha con un círculo pintado en uno de sus extremos ( ) Secuencia, selección e iteración Secuencia: orden en el cual los bloques son ejecutados. Selección: uso de condiciones para controlar si o no un módulo es ejecutado o cuál de varios bloques será ejecutado. Iteración: control de ciclos. La secuencia de ejecución de los módulos se muestra de arriba hacia abajo y de izquierda a derecha. Los DE no muestran ni iteración ni selección por defecto, pero pueden incorporarse simbología para estos casos. Iteración: Función Repetitiva (Iteración) Selección / Decisión: Función de Decisión Centro de Transacción Cuando son procesadas varios tipos de transacciones, un módulo de programa separado puede ser usado para procesar cada tipo de transacción. 4 Procesamiento de transacción Transacción cliente Transacción tipo A Tomar transacción Transacción tipo C Transacción tipo B Procesar transacción tipo A Procesar transacción tipo B Procesar transacción tipo C El diamante negro en el bloque superior es llamado centro de transacción. Para procesar cada tipo de transacción se usan módulos separados. El centro de transacción determina el tipo de una transacción y transfiere el control al módulo apropiado. 5 Guías de diseño Algunas guías de diseño prácticas que se pueden aplicar para transformar DFDs en DE, son las siguientes: Patrones de Diseño Validación Asociado a los procesos de validación de datos de entrada al sistema Lectura de datos desde entidades Emisión de datos a Entidades Externas Lectura desde almacenes de datos Escritura en almacenes de datos (inserción, eliminación o modificación de registros) Ejemplo de DFD a DE transformacional El siguiente DFD representa un proceso de ‘Prestamos de Libros a Socios’, siendo los datos requeridos para esto, el ‘Número de Carnet’ del Socio y el ‘Número de Libro’ requerido. Si los datos son correctos y aceptados, se actualiza los préstamos realizados, y se imprime el recibo correspondiente que se entrega al Socio. 6 Socio Socio no ex is te Validar Socio Num. Carnet Num. Carnet Actualizar Prés tamo Socio Prés tamo Imprimir Recibo Recibo Socio Nro. Libro Nro. Libro Validar Libro Libro pres tado Libro no ex is te Libros Préstamos Analizando el DFD resultante, pueden establecerse: Ramas aferentes (procesos que leen o validan los datos a la entrada del sistema): Validar Socio, Validar Libro. Ramas eferentes (procesos que dan a los datos el formato adecuado para ser emitidos al exterior – visualizados, impresos, etc): Imprimir Recibo. Centro de transformación (procesos de cálculo, procesamiento de datos, actualización de datos, etc): Actualizar Préstamo En base a esto, el Diagrama Estructurado correspondiente a este proceso, sería el siguiente: Realizar Préstamo Nro carnet Reg Préstamo Nro Libro Nro carnet Reg Préstamo Obtener carnet socio Nro carnet Obtener nro libro Num Error OK Nro carnet Existe socio Mostrar error Validar carnet Leer cadena Reg Socio EOF Leer de Socio Nro libro Actualizar Préstamo OK Nro carnet Existe libro, no prestado Validar nro libro Leer cadena Reg Libro Leer de Libros EOF EOF Nro Libro Num Error Mostrar error Reg Préstamo OK Escribir en Préstamos Imprimir Recibo Línea Recibo OK Escribir línea Reg Préstamo Leer de Prestamos 7 Ejemplo de DFD a DE transaccional En el siguiente DFD muestra un caso genérico, en el que puede determinarse los siguientes elementos: Archivo P Validar Trans. A Trans. A Trans. Bruta Determinar tipo Transacción Trans. correcta A Trans. A + P antes y despues de actualizar Actualizar archivo P Archivo Q Trans. B Trans. correcta B Validar Trans. B Actualizar archivo Q Trans. B + Q antes y despues de Imprimir actualizar diario Salida Diario Archivo R Trans. C Trans. correcta C Validar Trans. C Trans. C + R antes y despues de actualizar Actualizar archivo R Un centro de transacción Tres caminos de transacción Con estos elementos podemos derivar en el siguiente Diagrama Estructurado: Procesar Transac Tipo Trans Tipo Trans Analizador Despachador Trans C Trans A Trans B Procesar Tipo A Trans. A correcta Trans. A correcta Actualizar archivo P Validar A Trans. A correcta OK Trans. B correcta Procesar Tipo B Validar B Trans. B + Q antes y despues de actualizar Insertar Trans. A Trans. C correcta Trans. B correcta Actualizar archivo Q Validar C Trans. B correcta OK Procesar Tipo C Trans. C correcta Actualizar archivo R OK Insertar Trans. B Trans. C + R antes y despues de actualizar Trans. A + P antes y despues de actualizar Trans. C correcta Insertar Trans. C Imprimir diario Bibliografía Structured Techniques – The Basis for CASE. James Martin, Carma McClure. Información desde la Web. 8
