Tema 8 - Diseño estructurado

Ingeniería del Software 3º de I.T.I.S.Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Tema 8: Diseño estructurado Dr. Francisco José García Peñalvo ([email protected]) 3º I.T.I.S. Fecha de última modificación: 15-12-2005 Universidad de Salamanca – Departamento de Informática y Automática Ingeniería del Software Diseño estructurado Resumen El objetivo principal de este tema es explicar la forma correcta de pasar del análisis al diseño dentro del paradigma estructurado, haciendo hincapié en el uso de los denominados diagramas de estructuras que provienen de los diagramas de flujo de datos, es decir, en el diseño arquitectónico. Aunque también se hará un ligero repaso del paso de un modelo conceptual de datos a su correspondiente modelo lógico relacional. En el primero de los cuatro apartados principales en que se organiza el tema se hace una introducción al diseño estructurado. El segundo apartado se dedica al estudio de la técnica fundamental del diseño arquitectónico dentro del paradigma estructurado, los diagramas de estructura. En el tercero se estudian las estrategias de diseño, que son aquéllas que se emplean para la transformación del modelo funcional basado en DFDs en los diagramas de estructuras que constituyen el diseño arquitectónico. Por último, en el cuarto apartado se aborda el paso del modelo conceptual al modelo lógico de datos y la teoría de la normalización Diseño estructurado; Diagrama de estructuras; Tabla de interfaz; Estrategias de diseño; Análisis de transformación; Análisis de transacción; Centro de transformación; Centro de transacción; Modelo relacional; Normalización [Piattini et al., 2004] Capítulo 8 [Pressman, 2002] Capítulo 14 Resumen Descriptores Bibliografía Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. García Peñalvo 2 Tema 8: Diseño estructurado Ingeniería del Software 3º de I.T.I.S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Esquema Introducción Diagrama de estructuras Diseño arquitectónico Diseño de datos Aportaciones principales del tema Ejercicios Lecturas complementarias Referencias Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. García Peñalvo 3 Ingeniería del Software Diseño estructurado 1. Introducción Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. García Peñalvo 4 Tema 8: Diseño estructurado Ingeniería del Software 3º de I.T.I.S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Introducción (i) Objetivos principales Desarrollo de una estructura modular de programa Representación de las relaciones entre módulos Combinación de la estructura de programa y de la estructura de datos Posibilita el establecimiento de la transición de los modelos del análisis a los modelos del diseño Fundamentalmente de los DFDs a una descripción de la estructura del programa El diseño estructurado está muy centrado en el diseño arquitectónico Diagrama de estructuras Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. García Peñalvo 5 Ingeniería del Software Diseño estructurado Introducción (ii) Diseño Procedimental e Esp de Da tos cri pc ión Diseño de Interfaz Diseño Arquitectónico o ces Pro de ió n cac cifi FD D De s DE R DD DTE s Especificación de Control Diseño de Datos Modelo de diseño diseñ © Dr. Francisco J. García Peñalvo Modelo de análisis aná Universidad de Salamanca – Departamento de Informática y Automática 6 Tema 8: Diseño estructurado I.S.. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Relación entre las actividades de diseño ERS E-R Enfoque de datos Diseño de alto nivel (arquitectónico) Diseño de bajo nivel (detallado) Análisis (Qué) Lenguaje comprensible para el usuario/cliente Enfoque funcional Decisiones generales y abstractas (organización lógica) Arquitectura de procesos Diseño (Cómo) DFD Modelo lógico de datos Modelo físico de datos Estructura detallada: programas y módulos Decisiones concretas y específicas (optimización y rendimiento) Esquema de BD y ficheros Cuadernos de carga Implementación Codificación Lenguaje comprensible por la máquina [Piattini et al. 2004] Universidad de Salamanca – Departamento de Informática y Automática © Dr.T. García Peñalvo 7 Ingeniería del Software Diseño estructurado Definición de diseño estructurado Es el arte de diseñar los componentes de un sistema y la relación entre ellos de la mejor forma posible [Yourdon y Constantine. 1979] Es el proceso de decidir la forma en la cual componentes interconectados resolverán un problema bien especificado [Yourdon y Constantine. Francisco J. 1979] Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. Francisco J. García Peñalvo 8 Tema 8: Diseño estructurado . García Peñalvo 10 Tema 8: Diseño estructurado .I. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 2. Francisco J.Ingeniería del Software 3º de I. Francisco J.S.T. 1995] Los datos se contemplan como la interfaz entre tratamientos sucesivos Ofrece una visión de arquitectura de sistemas Paso de análisis a diseño más sencillo cuanto mayor sea el nivel de detalle al que se haya llegado en los DFD Un diagrama de estructuras no es un organigrama Universidad de Salamanca – Departamento de Informática y Automática © Dr. bajo qué condiciones y cuántas veces se tienen que realizar los tratamientos identificados en los procesos de un DFD [MAP. Diagrama de estructuras Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 9 Ingeniería del Software Diseño estructurado Introducción Técnica también conocida como Structure chart Diagrama de Estructura de Cuadros de Constantine (Métrica v3) [MAP. 2001] Técnica que permite definir cuándo. S. Francisco J. mientras que los controles no Los controles van a indicar al módulo que llama la terminación. Francisco J. hacia exterior. Los controles tienen importancia en la comunicación de información en el interior. tanto por el llamado como por el que llama Algo esencial es que los datos se van a procesar.Ingeniería del Software 3º de I. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Elementos de un diagrama de estructuras Módulo Representa una rutina. García Peñalvo 12 Tema 8: Diseño estructurado . o error del módulo llamado Los controles deben ir siempre en sentido ascendente Los datos tienen gran importancia para el sistema en sí mismo.T. subprograma o programa Se representa mediante un rectángulo con el nombre del módulo Conexiones entre módulos Se representan mediante flechas Comunicación entre módulos Los módulos pueden comunicarse entre sí por medio de estructuras de datos o de control control datos Universidad de Salamanca – Departamento de Informática y Automática © Dr. son los que sincronizan la operativa de los módulos Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 11 Ingeniería del Software Diseño estructurado Comunicación entre módulos Controles o flags Paso de control entre módulos Un módulo comunica a otro módulo que ha terminado su proceso y traspasa al módulo el control del sistema Comunicación de que se ha producido un error en el proceso Comunicación de que se puede proceder a una operación concreta Diferencias entre datos y flags Los datos son la información compartida por los módulos.I. García Peñalvo 13 Ingeniería del Software Diseño estructurado Notación (ii) Decisión Módulo predefinido Nombre Almacén de datos Nombre Dispositivo físico Dispositivo Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 14 Tema 8: Diseño estructurado .Ingeniería del Software 3º de I. Francisco J.S.I.T. Francisco J. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Notación (i) Secuencia Iteración Universidad de Salamanca – Departamento de Informática y Automática © Dr. T. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejemplo Módulo Conexión intermodular Estructura repetitiva pet _aceptada pet _aceptada Gestionar pedidos Nombre del módulo Datos InformePrestamo InformePrestamo Consultar stock pet _prestamo Tratar petición pet _rechazada Informar petición Leer petición préstamo Rechazar petición Módulo Predefinido Estructura alternativa Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 16 Tema 8: Diseño estructurado . Francisco J.S. García Peñalvo 15 Ingeniería del Software Diseño estructurado Tabla de interfaz (i) Representa los parámetros que se pasan los diferentes módulos Apoyo a los diagramas de estructuras Facilitan su compresión Recoge para cada llamada El módulo llamado Cada parámetro formal Si el parámetro es de entrada (marcando la columna correspondiente) Si el parámetro es de salida (marcando la columna correspondiente) El uso de cada parámetro El significado de cada parámetro Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.I.Ingeniería del Software 3º de I. S.Ingeniería del Software 3º de I. sin modificar su valor El parámetro es usado como una VARIABLE DE CONTROL. García Peñalvo 18 Tema 8: Diseño estructurado . y) x y Sí No Salida No Sí Uso P M Significado parámetro Fecha-Nacimiento Edad Nemotécnico P M T C Significa El parámetro es PROCESADO: a = b + 2 El parámetro es MODIFICADO: a = 3 + b El parámetro es TRANSFERIDO por el módulo llamado a otro módulo que éste llama. como un valor de un flag o para la especificación de una función que es usada por el módulo llamado El parámetro es TRANSFERIDO a otro módulo y es MODIFICADO en este segundo módulo © Dr. quizás para actuar como índice conmutador. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Tabla de interfaz (ii) Módulo Parámetro Entrada formal f(x. García Peñalvo I Universidad de Salamanca – Departamento de Informática y Automática 17 Ingeniería del Software Diseño estructurado 3.T. Diseño arquitectónico Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.I. Francisco J. T.I.S.Ingeniería del Software 3º de I. 4. 5. Se Se Se Se Se establece el tipo de flujo de información indican los límites del flujo convierte el DFD en la estructura del programa define la jerarquía de control descomponiéndola mediante particiones refina la estructura resultante usando medidas y heurísticas de diseño Tipos de flujo Flujo de transformación Análisis de transformación Flujo de transacción Análisis de transacción Estrategias de diseño Universidad de Salamanca – Departamento de Informática y Automática © Dr. caminos “directos” Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 20 Tema 8: Diseño estructurado . Francisco J. García Peñalvo 19 Ingeniería del Software Diseño estructurado Flujo de transformación (i) Flujo de transformación La información entra en el sistema mediante caminos que transforman los datos externos a un formato interno y se identifica como flujo de entrada En el interior del software se produce una transformación La información entrante se pasa a través de un centro de transformación y empieza a moverse a lo largo de caminos que ahora conducen hacia el exterior del software Los datos que se mueven a lo largo de estos caminos se denominan flujos de salida El flujo general de datos ocurre de manera secuencial y sigue uno. 2. Francisco J. o unos pocos. 3. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Estrategias de diseño Contar exclusivamente con un conjunto de principios y reglas convertiría el proceso de diseño en una tarea tediosa Estrategias para convertir un DFD en una estructura de programa 1. 1 1.I. Francisco J. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Flujo de transformación (ii) Flujo de salida Representación externa Flujo de entrada Información Flujo de transformación Representación interna Tiempo [Pressman.1 Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 22 Tema 8: Diseño estructurado .S. Francisco J.Ingeniería del Software 3º de I. García Peñalvo 21 Ingeniería del Software Diseño estructurado Flujo de transformación (iii) 1.2 3 2.T.1 4.2 4. 1997] Universidad de Salamanca – Departamento de Informática y Automática © Dr.2 Flujo de entrada Flujo de transformación Flujo de salida 2. García Peñalvo 24 Tema 8: Diseño estructurado . Francisco J. basándose en ese valor.2 Camino de acción 3 4.2 Camino de acción 2 1 3. Francisco J.1 3. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Flujo de transacción (i) El flujo de información está caracterizado a menudo por un único elemento de datos denominado transacción Desencadena otros flujos de información a lo largo de los muchos caminos posibles El flujo de transacción se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la información del mundo exterior en una transacción La transacción se evalúa y.S.1 2.I.2 Universidad de Salamanca – Departamento de Informática y Automática © Dr. se inicia el flujo a lo largo de uno de muchos caminos de acción El centro del flujo de información del que parten los caminos de acción se denomina centro de la transacción Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. García Peñalvo 23 Ingeniería del Software Diseño estructurado Flujo de transacción (ii) Camino de acción 1 Centro de Transacción 2.T.1 4. García Peñalvo 25 Ingeniería del Software Diseño estructurado Análisis de transformación (ii) Datos de entrada Información de salida Sentido descendente Datos de entrada Proceso de datos ≡ Información de entrada Sentido ascendente Nuevos datos Datos de salida Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. García Peñalvo 26 Tema 8: Diseño estructurado . Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (i) Conjunto de pasos de diseño que permiten convertir un DFD obtenido en la fase de análisis.I.S.T. con características de flujo de transformación. Francisco J. Francisco J. en una estructura (o plantilla) predefinida del sistema Un DFD con características de transformación es aquél en que se pueden distinguir tres zonas Flujo de llegada Flujo de transformación o centro de transformación Flujo de salida Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 27 Ingeniería del Software Diseño estructurado Análisis de transformación (iv) Revisión del modelo fundamental del sistema DFD de nivel 0 y la información que lo soporta Evaluación de la especificación del sistema y de la especificación de requisitos del software Mínimo tres niveles de profundidad (diagrama de contexto.I. Francisco J. independientemente de la implementación particular de la entrada y de la salida Hay que especificar los límites del flujo de llegada y salida Los límites del flujo de llegada y salida están abiertos a interpretación Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. diagrama de sistema y diagramas de nivel 2) en el análisis estructurado para poder aplicar el diseño estructurado con el nivel suficiente detalle Determinar si el DFD tiene características de transformación o de transacción El flujo de información dentro del sistema puede representarse siempre como transformación Aislar el centro de transformación.S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (iii) Pasos del análisis de transformación Revisión del modelo fundamental del sistema Determinar si el DFD tiene características de transformación o de transacción Aislar el centro de transformación. especificando los límites del flujo de llegada y de salida El centro de transformación es la parte del DFD que contiene las funciones esenciales del sistema.Ingeniería del Software 3º de I.T. García Peñalvo 28 Tema 8: Diseño estructurado . especificando los límites del flujo de llegada y de salida Realizar el primer nivel de factorización del diagrama de estructuras Elaboración del segundo nivel de factorización Refinamiento de la estructura del sistema utilizando medidas y guías (heurísticas de diseño) para mejorar la calidad del software Asegurarse del trabajo realizado por el diseño obtenido Universidad de Salamanca – Departamento de Informática y Automática © Dr. de cálculo y de salida Módulos de nivel intermedio ejecutan algún control y realizan cantidades de trabajo moderadas Universidad de Salamanca – Departamento de Informática y Automática © Dr.5 d 1. Francisco J.7 Centro de la transformación j Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 29 Ingeniería del Software Diseño estructurado Análisis de transformación (vi) Realizar el primer nivel de factorización de diagrama de estructuras El propósito del análisis de transformación es convertir un DFD en un diagrama de estructuras para este tipo de operación Esta traducción es necesaria. Francisco J.S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (v) a 1. García Peñalvo 30 Tema 8: Diseño estructurado .3 1.T.I.4 g f h 1.2 e c 1.Ingeniería del Software 3º de I. pues el diagrama de estructuras describe una estructura jerárquica y el DFD no La estructura del sistema representa una distribución descendente del control Da como resultado una estructura del sistema en la que los módulos de nivel superior toman las decisiones de ejecución y los módulos de nivel inferior ejecutan la mayoría del trabajo de entrada.6 i 1.1 b 1. 2 e c 1.5 d 1.4 g f h 1.7 Salida Primer nivel de factorización Cm j Ce Ct Cs © Dr. Francisco J.I.S. dirigiéndose hacia fuera a lo largo de los caminos de llegada y salida Las transformaciones (procesos del DFD) se convierten en módulos subordinados de la estructura Será necesario la introducción de módulos predefinidos que proporcionen las diferentes entradas y/o salidas que necesita y/o genera el sistema Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. García Peñalvo 32 Tema 8: Diseño estructurado .1 b 1.3 1. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (vii) Entrada a Transformación 1. García Peñalvo Universidad de Salamanca – Departamento de Informática y Automática 31 Ingeniería del Software Diseño estructurado Análisis de transformación (viii) Elaboración del segundo nivel de factorización Conversión de las transformaciones de cada proceso de un DFD en los módulos correspondientes del diagrama de estructuras Se comienza en el límite del centro de transformación.6 i 1.T. Francisco J. S.7 j c d f 1.5 1.1 a Leer Leer 1. García Peñalvo 34 Tema 8: Diseño estructurado .2 b 1. Francisco J. García Peñalvo 33 Ingeniería del Software Diseño estructurado Análisis de transformación (x) Refinamiento de la estructura del sistema utilizando medidas y guías (heurísticas de diseño) para mejorar la calidad del software Se puede aumentar o disminuir el número de módulos Producir una factorización lógica que tenga una buena calidad y una estructura que se implemente sin dificultad.I. además de por los requisitos del software Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. se pruebe sin confusión y se mantenga sin problemas Los refinamientos están dictados por consideraciones prácticas y de sentido común.6 Escribir Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (ix) Cm e c e c i i Ce c e Ct Cs i 1.T.4 1.3 e g g h f h i 1. 2 1. Francisco J.T. García Peñalvo 35 Ingeniería del Software Diseño estructurado Análisis de transacción (i) Un solo elemento de datos determina caminos alternativos por los que puede transitar el flujo de información Dependiendo del camino tomado varía la función realizada sobre el dato tratado El elemento de datos se denomina transacción Este elemento desencadena otro flujo de datos a lo largo de uno de los muchos caminos El centro del flujo de información desde el que emanan muchos caminos de acción.1 a Leer Leer 1.3 Ct Cs i b d e c g g f f h h i 1. García Peñalvo 36 Tema 8: Diseño estructurado .4 1. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transformación (xi) Cm c e e c i i 1. exclusivos entre sí.Ingeniería del Software 3º de I.7 j 1. se llama centro de transacción El flujo de información a lo largo de un camino de acción puede ser tanto de transformación como de transacción Universidad de Salamanca – Departamento de Informática y Automática © Dr.S.I.6 Escribir Universidad de Salamanca – Departamento de Informática y Automática © Dr.5 1. Francisco J. I. el proceso del DFD que corresponde a la transacción no se refleja en dicho DFD Conocer bien el sistema para darse cuenta de que se tienen entradas al sistema que son exclusivas entre sí El camino de llegada y todos los caminos de acción debe ser aislados también Cada camino de acción debe evaluarse en función de las características individuales de flujo (tipo transformación o tipo transacción) Realizar el primer corte del diagrama de estructuras El flujo de transacciones se convierte en una estructura de programa formada por una bifurcación de entrada y una bifurcación de salida Para el caso de la entrada se hace igual que en el análisis de transformación Para el caso de la salida. se añade un módulo controlador por cada camino de flujo de acción El módulo que se corresponde con el centro de transacción refleja la exclusividad de los diferentes caminos por medio de un rombo del cual parten los diferentes módulos controladores de cada camino de acción Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 38 Tema 8: Diseño estructurado . Francisco J.S.T. García Peñalvo 37 Ingeniería del Software Diseño estructurado Análisis de transacción (iii) Identificación del centro de transacción y la características del flujo de cada camino de acción El centro de transacción está ligado al origen de varios caminos de información que fluyen radialmente de él Normalmente.Ingeniería del Software 3º de I. Francisco J. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transacción (ii) Pasos similares a los pasos para el análisis de transformación Revisión del modelo fundamental del sistema Determinar si el DFD tiene características de transformación o de transacción Aislar el centro de transacción y las características del flujo de cada camino de acción Realizar el primer nivel de factorización del diagrama de estructuras Elaboración del segundo nivel de factorización Refinamiento de la estructura del sistema utilizando medidas y guías (heurísticas de diseño) para mejorar la calidad del software Asegurarse del trabajo realizado por el diseño obtenido Universidad de Salamanca – Departamento de Informática y Automática © Dr. S. Francisco J.Ingeniería del Software 3º de I.T. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Análisis de transacción (iv) a A b Cm D P Ce Q D C1 R z Camino 3 Camino 2 Camino 1 C2 C3 Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.I. García Peñalvo 40 Tema 8: Diseño estructurado . García Peñalvo 39 Ingeniería del Software Diseño estructurado Análisis de transacción (v) Realizar el segundo nivel de factorización Se desarrolla cada camino de acción dependiendo de su tipo de flujo a A Cm b D P Ce A Q C1 Leer a D C2 Q C3 R Escribir z P R z Camino 3 Camino 2 Camino 1 Leer b Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.T. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 4. Diseño de datos Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 42 Tema 8: Diseño estructurado . Se considera una particularización de 1:N Universidad de Salamanca – Departamento de Informática y Automática © Dr.Ingeniería del Software 3º de I. García Peñalvo 41 Ingeniería del Software Diseño estructurado Paso del diagrama E/R al modelo relacional (i) Todo tipo de entidad se convierte en una relación Todo tipo de asociación (relación) N:N se transforma en una relación Todo tipo de asociación (relación) 1:N se traduce en el fenómeno de propagación de clave o se crea una nueva relación Todo tipo de asociación (relación) 1:1 se traduce en el fenómeno de propagación de clave o se crea una nueva relación.S. Francisco J.I. García Peñalvo 44 Tema 8: Diseño estructurado . Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Paso del diagrama E/R al modelo relacional (ii) Relaciones ISA Posibilidad 1 El conjunto de entidades correspondiente a la generalización se modela como una tabla en la que cada campo se corresponde con un atributo de dicho conjunto de entidades El conjunto de entidades correspondiente a las especializaciones toma sus atributos de la unión de los atributos de la generalización con sus propios atributos Posibilidad 2 Crear una única tabla que tenga por campos la unión de los campos de la generalización y de las especializaciones Posibilidad 3 Crear una tabla con todos los datos comunes de la generalización. inserción o borrado en los esquemas de datos Penaliza la recuperación de datos Consiste en ir descomponiendo los registros en otros de menor tamaño de forma que satisfagan una serie de restricciones específicas que definen lo que se conoce como forma normal Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. y otras tablas relacionadas con la primera. Francisco J.T. con los atributos especializados de cada especialización Universidad de Salamanca – Departamento de Informática y Automática © Dr.S. 1995] Difundida Aplicable en un plano conceptual y en un plano lógico Ayuda a los diseñadores a prevenir problemas de redundancias y anomalías de modificación.Ingeniería del Software 3º de I. García Peñalvo 43 Ingeniería del Software Diseño estructurado Normalización (i) El procedimiento de normalización es la reducción sucesiva de un conjunto dado de relaciones a una forma más deseable [Date.I. García Peñalvo 46 Tema 8: Diseño estructurado .S. Cod_Almacén. Dirección_Almacén) Universidad de Salamanca – Departamento de Informática y Automática © Dr. Dirección_Almacén) VENTA (Cod_Pieza. Francisco J. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Normalización (ii) Relaciones 1NF 2NF 3NF BCNF 4NF 5NF DKNF Universidad de Salamanca – Departamento de Informática y Automática © Dr.I.T. García Peñalvo 45 Ingeniería del Software Diseño estructurado Normalización (iii) Se dice que una relación está en primera forma normal (1FN) si no existen en ella grupos repetitivos. Cantidad) ALMACEN (Cod_Almacén. Francisco J. Cantidad. todos los campos que no formen parte de ninguna clave candidata suministran información acerca de la clave completa VENTA (Cod_Pieza. si cada atributo tiene un único valor 1FN obliga que todos los campos sean atómicos Se dice que una relación está en segunda forma normal (2FN) cuando. es decir. además de estar en 1FN.Ingeniería del Software 3º de I. Cod_Almacén. Cod_Dpto) DEPARTAMENTO (Cod_Dpto.I. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Normalización (iv) Se dice que una relación está en tercera forma normal (3FN) cuando. Cod_Dpto. Nombre_Dpto) EMPLEADO (Cod_Empleado. los campos que no forman parte de la clave candidata deben facilitar información sólo acerca de la(s) clave(s) candidata(s). Nombre_Dpto) Universidad de Salamanca – Departamento de Informática y Automática © Dr. es decir. tienen por lo menos un atributo en común Forma normal Boyce/Codd (FNBC) Formal normal Boyce/Codd si y sólo si todo determinante es una clave candidata Un determinante es atributo del cual depende funcionalmente por completo algún otro atributo Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 47 Ingeniería del Software Diseño estructurado Normalización (v) La 3FN falla por Hay varias claves candidatas Esas claves candidatas son compuestas Las claves compuestas se solapan. García Peñalvo 48 Tema 8: Diseño estructurado .S. y no acerca de otros campos Los campos del registro deben ser mutuamente independientes y completamente dependientes de la(s) clave(s) candidatas EMPLEADO (Cod_Empleado.T. además de estar en 2FN. Francisco J.Ingeniería del Software 3º de I. Francisco J. se aplica en aquellos sistemas donde la característica fundamental sea de flujo de trasformación. el análisis de transformación. Francisco J.Ingeniería del Software 3º de I. García Peñalvo 50 Tema 8: Diseño estructurado . la primera de ellas. Aportaciones principales del tema Universidad de Salamanca – Departamento de Informática y Automática © Dr.I.S. independientes los unos de los otros. Francisco J.T. el análisis de la transacción. de manera que las decisiones las toman los módulos de ámbito superior y las operaciones se llevan a cabo por los módulos de orden inferior El flujo de transacción establece dos módulos principales. García Peñalvo 49 Ingeniería del Software Diseño estructurado Aportaciones principales Se distinguen dos tipos de flujos de datos: el flujo de transformación y el flujo de transacción El flujo de transformación reproduce fielmente el patrón entrada/proceso/salida. de forma que la transacción servirá de elemento discriminador para determinar el camino a elegir La existencia de dos tipos de flujos de datos origina dos estrategias de diseño. mientras que la segunda. uno que analiza la transacción a ser tratada y otro que encamina hacia el módulo que la trata En estos sistemas se tienen diferentes caminos de acción. se aplica en los sistemas cuya característica principal sea de transacción Llama la atención lo artificial del proceso seguido para pasar de un DFD a diagrama de estructuras. que obliga a cambiar de modelo subyacente en la técnica de modelado: de los procesos del DFD se pasa a la jerarquía de módulos Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 4. . La función de la central de compras consiste en obtener. García Peñalvo 51 Ingeniería del Software Diseño estructurado Ejercicios resueltos (i) Se va a desarrollar una aplicación que apoye a la gestión de una central de compras que permita hacer pedidos globales por temporadas (juguetes en Navidad.S.. Francisco J. Así que se llevará a cabo un Análisis de transformación Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 5. la central de compras puede modificar al alta o a la baja la cantidad pedida por almacén en función de una serie de factores (umbrales de descuento por diversas cantidades.). notificándoselo a cada almacén (notificación de pedido) a la vez que comunica el pedido global (cantidades definitivas de los productos) de todos los almacenes a cada proveedor seleccionado El flujo principal de este sistema es de transformación.I.Ingeniería del Software 3º de I.. García Peñalvo 52 Tema 8: Diseño estructurado .).T. el pedido global teniendo en cuenta los pedidos individuales (pedido rellenado). Francisco J. material de acampada en verano. Cuestiones y ejercicios Universidad de Salamanca – Departamento de Informática y Automática © Dr.. No obstante. a partir del catálogo de los proveedores y del archivo histórico de ventas de los almacenes. Ingeniería del Software 3º de I. García Peñalvo 54 Tema 8: Diseño estructurado . Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (ii) Se tiene el siguiente diccionario de datos Documentos Almacén = Histórico de Ventas + Pedido Rellenado Pedido Global = Notificación Pedido Documentos Almacén 0 Gestionar Central de Compras Almacén Pedido Global Almacén Notificación Pedido Preveedor Catálogo Preveedor Diagrama de contexto Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 53 Ingeniería del Software Diseño estructurado Ejercicios resueltos (iii) Mejores Ofertas Documentos Almacén 1 Seleccionar Mejores Ofertas 2 Hacer Pedidos Según Ofertas Pedido Global Notificación Pedido Diagrama de sistema Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.T. Francisco J.I.S. 1 Recibir histórico ventas Histórico Ventas Recibido Histórico Histórico Ventas Recibido 2.Ingeniería del Software 3º de I. García Peñalvo 55 Ingeniería del Software Diseño estructurado Ejercicios resueltos (v) Histórico Ventas 2.1 Recibir Catálogo Catálogo Recibido Catálogos Catálogo Recibido 1.2 Recibir Pedidos Rellenados Pedido Rellenado Recibido Pedido Global Mejor Oferta Notificación Pedido Catálogo 1.2 Calcular mejores ofertas Mejor Oferta Mejores Ofertas DFD extendido Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (iv) Histórico Ventas 2. Francisco J.4 Hacer pedido global Pedido Rellenado 2.S.3 Ajustar pedidos almacén Corregido Pedidos Corregidos Corregido Pedido Rellenado Recibido Pedidos 2.4 Hacer pedido global Pedido Rellenado 2.3 Ajustar pedidos almacén Corregido Pedidos Corregidos Corregido Pedido Rellenado Recibido Pedidos 2.1 Recibir histórico ventas Histórico Ventas Recibido Histórico Histórico Ventas Recibido 2.2 Recibir Pedidos Rellenados Pedido Rellenado Recibido Pedido Global Mejor Oferta Notificación Pedido Catálogo 1. García Peñalvo 56 Tema 8: Diseño estructurado . Francisco J.T.I.2 Calcular mejores ofertas Mejor Oferta Mejores Ofertas Universidad de Salamanca – Departamento de Informática y Automática © Dr.1 Recibir Catálogo Catálogo Recibido Catálogos Catálogo Recibido 1. I. Universidad de Salamanca – Departamento de Informática y Automática © Dr. Cat. H Leer PR Escr.T. García Peñalvo 57 Ingeniería del Software Diseño estructurado Ejercicios resueltos (vii) Gestionar Central de Compras Recibir Documentación Cat Recibir Catálogo CR HVR Ajustar Pedidos Almacén Corregido PRR Calcular Mejores Ofertas Hacer Pedido Global NP MO PG Recibir Histórico Ventas HV HVR Recibir Pedidos Rellenados PR PRR Leer Cat. Francisco J. Francisco J. NP Impr. E/L MO Leer PCo. PCo. Escr.S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (vi) Gestionar Central de Compras PRR HVR CR PRR HVR Corregido CR MO MO Corregido Recibir Documentación HVR PRR Catálogo Recibir Catálogo Ajustar Pedidos Almacén Calcular Mejores Ofertas Notificación Pedido Hacer Pedido Global Pedido Global Recibir Histórico Ventas Recibir Pedidos Rellenados PR Leer Catálogo Imprimir Notificación Pedido Imprimir Pedido Global HV Leer Histórico Ventas Leer Pedidos Rellenados Universidad de Salamanca – Departamento de Informática y Automática © Dr. P Leer Cat.Ingeniería del Software 3º de I. MO CR Impr. García Peñalvo 58 Tema 8: Diseño estructurado . Leer H Leer. Cat. Escr. PG Corregido Leer HV Escr. García Peñalvo 60 Tema 8: Diseño estructurado .T.I. Dependiendo del tipo de usuario (estudiante o trabajador) se realizarán diferentes tratamientos El flujo principal de este sistema es de transacción. Francisco J.Ingeniería del Software 3º de I.S. Así que se llevará a cabo un Análisis de transacción Universidad de Salamanca – Departamento de Informática y Automática © Dr. García Peñalvo 59 Ingeniería del Software Diseño estructurado Ejercicios resueltos (ix) Carnet Usuario 0 Gestionar Piscina Entrada Usuario Diagrama de contexto 2 Tratar Estudiante Carnet Estudiante Entrada Carnet 1 Seleccionar Tipo Carnet Diagrama de sistema Carnet Trabajador 3 Tratar Trabajador Entrada Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (viii) La gestión de una determinada piscina municipal ha decidido permitir el acceso gratuito a los recintos de la piscina a los usuarios que sean estudiantes o trabajadores locales. Francisco J. García Peñalvo 62 Tema 8: Diseño estructurado .I.S.1 Comprobar Carnet Estudiante Carnet Estudiante Válido Entrada Estudiante 2.T.3 Entregar Entrada Estudiante Entrada Carnet 1 Seleccionar Tipo Carnet Carnet Trabajador 3.2 Numerar Talón Estudiante 2.Ingeniería del Software 3º de I. García Peñalvo 61 Ingeniería del Software Diseño estructurado Ejercicios resueltos (xi) Gestionar Piscina Carnet Carnet Leer Carnet Carnet estudiante Seleccionar Tipo Carnet Carnet trabajador Tratar Estudiante Tratar Estudiante Tratar Trabajador Tratar Trabajador Tratar Estudiante Carnet estudiante Carnet validado Entrada estudiante Entrada estudiante Tratar Trabajador Carnet trabajador Carnet validado Entrada trabajador Entrada trabajador Comprobar Carnet Estudiante Numerar Talón Estudiante Entregar Entrada Estudiante Entrada Comprobar Carnet Trabajador Numerar Talón Trabajador Entregar Entrada Trabajador Entrada Coger Entrada Coger Entrada Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J.1 Comprobar Carnet Trabajador Carnet Trabajador Válido 3.3 Entregar Entrada Trabajador Entrada DFD extendido Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (x) Carnet Estudiante 2.2 Numerar Talón Trabajador Entrada Trabajador 3. Francisco J. Ingeniería del Software 3º de I.S. García Peñalvo 63 Ingeniería del Software Diseño estructurado Cuestiones y ejercicios Determinar cuál es el flujo dominante en los ejercicios de modelado de flujos de datos del Tema 5 Realizar los diagramas de estructuras correspondientes a los DFDs de los ejercicios de modelado funcional del Tema 5 Universidad de Salamanca – Departamento de Informática y Automática © Dr.I. García Peñalvo 64 Tema 8: Diseño estructurado . Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado Ejercicios resueltos (xii) Gestionar Piscina Tipo Carnet Tipo Carnet Leer Carnet Seleccionar Tipo Carnet Tratar Estudiante Tratar Estudiante Tratar Trabajador Tratar Trabajador Tratar Estudiante Carnet validado Entrada estudiante Entrada estudiante Tratar Trabajador Carnet validado Entrada trabajador Entrada trabajador Comprobar Carnet Estudiante Numerar Talón Estudiante Entregar Entrada Estudiante Entrada Comprobar Carnet Trabajador Numerar Talón Trabajador Entregar Entrada Trabajador Entrada Carnet estudiante Carnet trabajador Leer Carnet Estudiante Coger Entrada Leer Carnet Trabajador Coger Entrada Universidad de Salamanca – Departamento de Informática y Automática © Dr.T. Francisco J. Francisco J. I. 1979 Libro dedicado al diseño estructurado del software Universidad de Salamanca – Departamento de Informática y Automática © Dr. M. así como la teoría de la normalización Yourdon. E.0”. “Fundamentos y Modelos de Bases de Datos”.. García Peñalvo 66 Tema 8: Diseño estructurado . Lecturas complementarias Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 6. “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design”. 2001 Es interesante destacar la parte de diseño estructurado de esta metodología Miguel.Ingeniería del Software 3º de I.T. Francisco J.S. Ministerio de Administraciones Públicas. “MÉTRICA 3. en el que se puede seguir el paso al modelo relacional de un diagrama entidad-relación. García Peñalvo 65 Ingeniería del Software Diseño estructurado Lecturas complementarias Ministerio de Administraciones Públicas. Constantine. 1997 Libro clásico de diseño de bases de datos. A. Piattini. Prentice-Hall. Ra-ma. de. L. Francisco J. Volúmenes 13. “Software Engineering: A Practitioner’s Approach”. Francisco J.1”. 68 [Yourdon y Constantine. Addison-Wesley. Ra-ma. S. 1995 [MAP. Ministerio de Administraciones Públicas. 1997] Pressman. J. “An Introduction to Database Systems”. 2001 [Piattini et al. 1979] Yourdon. Cervera. Referencias Universidad de Salamanca – Departamento de Informática y Automática © Dr. 1995] Date. McGraw Hill. 1997 Universidad de Salamanca – Departamento de Informática y Automática © Dr. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Diseño estructurado 7.Ingeniería del Software 3º de I. R. 1995 [MAP...T.S. “MÉTRICA 3. 2004] Piattini. J.I. “Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión”.0”. García Peñalvo 67 Ingeniería del Software Diseño estructurado Referencias [Date. 4th Edition. M.García Peñalvo Tema 8: Diseño estructurado ... Fernández. 2004 [Pressman. L. Volúmenes 1-3. “Metodología Métrica 2. 2001] Ministerio de Administraciones Públicas. C.. Francisco J. Volúmenes 1-3. Calvo-Manzano. 1995] Ministerio de las Administraciones Públicas. E. Editorial Tecnos. 6th Edition. A. J. S. Departamento de Informática y Automática Universidad de Salamanca Ingeniería del Software Tema 8: Diseño estructurado Dr.I.Ingeniería del Software 3º de I.T. Francisco José García Peñalvo ([email protected]) 3º I.S.I. Fecha de última modificación: 15-12-2005 Universidad de Salamanca – Departamento de Informática y Automática Tema 8: Diseño estructurado .T.