Diagrama de flujo de datos extendido : un editor y su inmersión en los métodos formales gráficos

Texto completo

(1)INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. CAMPUS MORELOS. TESIS. MAESTRIA EN CIENCIAS COMPUTACIONALES ·, • '. . '"¡ f{ ' . '. .. ~. ., ~- ,.,. -~·. INGENIERIA DE SOFTWARE. DIAGRAMA DE FLUJO DE DATOS EXTENDIDO: UN EDITOR Y SU INMERSION EN LOS METODOS FORMALES GRAFICOS. POR. ALFREDO FERNANDEZ DELGADO. Abril de 1997..

(2) DIAGRAMA DE FLUJO DE DATOS EXTENDIDO: UN EDITOR Y SU INMERSION EN LOS METODOS FORMALES GRAFICOS.. POR. ALFREDOFERNANDEZDELGADO. TESIS. Presentada a la División de Graduados e Investigación Este Trabajo es Requisito Parcial para Obtener el Grado de Maestro en Ciencias Computacionales. INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. Abril de 1997..

(3) CONTENIDO Capítulo 1. Introducción. 1.1 1.2 1.3. Antecedentes .......................................................................................... 1 Herramientas CASE ................................................................................ 5 El problema ............................................................................................ 6 El Objetivo .............................................................................................. 6 La Estructura de la Te sis ........................................................................ 7. 1.4. 1.5 Capítulo 2. 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3 2.3.1 2.4 2.4.1 2.4.2 2.5 2.5.1 Capítulo 3. 3.1 3.2 3.3 3.4 3.4.1 3.4.1.1 3.4.1.1.1 3.4.1.1.2 3.4.1.1.3 3.4.1.1.3.1 3.4.1.1.3.2 3.4.2. Fundamentos Básicos del DFD y DFDX. Introducción ........................................................................................... 9 Los Diagramas de Flujo de Datos ........................................................... 1O Notación de los DFDs ............................................................................. 10 Un Ejemplo del uso del DFD(Trámites Electorales) .............................. 13 Definición Formal del DFD .................................................................... 15 Modelado de Sistemas ............................................................................ 16 Reglas de Construcción de los DFDs ..................................................... 18 El Diagrama de Flujo de Datos eXtendido DFDX ................................. 19 Reglas de Construcción de los DFDX .................................................... 20 Acerca de la Consistencia e Integridad ................................................... 21 Reglas de Formación de la Estructura del Diagrama de Contexto ............................................................................ 22 Reglas de Formación de la Estructura de los Diagramas de Transformación ................................................................ 23 Las Operaciones de Reestructuración Para los Diagramas de Flujo de Datos ................................................... 25 Requerimientos para las Operaciones de Reestructuración ................... 26 Diseño del Editor DFDX. Introducción ........................................................................................... 28 Acerca de las Interfases de Usuario ....................................................... 29 La Especificación de Requerimientos del DFDX ................................... 29 Diseño ..................................................................................................... 30 Arquitectura ............................................................................................ 31 Los Conjuntos de Información ............................................................... 31 Datos de Entrada ..................................................................................... 31 Datos de Salida ....................................................................................... 31 Bases de Datos ........................................................................................ 31 Diseño Conceptual de La Base De Datos ............................................... 32 Diseño Lógico De La Base De Datos .................................................... 32 La Identificación de Programas .............................................................. 34.

(4) 3.4.2.1 3.4.3 3.4.4. Capítulo 4. 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 Capítulo 5. 5.0 5.1 5.2 5.3 5.4 5.5 Capítulo 6. 6.1 6.2 Anexo A. 2. El Comportamiento Dinámico Del Sistema ........................................... 36 Diagrama de Estructura ......................................................................... 37 El Detalle de Módulos ............................................................................ 39. El DFDX Dentro de dos Métodos Formales Gráficos. Introducción ............................................................................................ 44 Las Máquinas de Estados y Autómatas Finitos ...................................... 45 Elementos de las MEF y Autómatas Finitos .......................................... 46 Autómatas Finitos Deterministas y NO-Deterministas .......................... 48 Las aplicaciones de las MEFs ................................................................. 48 Un ejemplo del Uso de una Especificación ............................................ 50 Ventajas de Uso ...................................................................................... 51 Redes de Petri ......................................................................................... 52 Componentes de una RP ......................................................................... 53 Representación Gráfica de una RP ......................................................... 54 Ventajas ................................................................................................. 59 Desventajas ............................................................................................. 59 Campos de Aplicación de las RP ............................................................ 59 Comparando los tres MFEGs .................................................................. 60 Pruebas del Sistema. Introducción ............................................................................................ 62 Caso Número 1:Despliegue correcto de los elementos que conforman la interfase .......................................... 63 Caso Número 2: Proceso de edición amigable y familiar al usuario .............................................................. 65 Caso Número 3: La creación, impresión, asignación de nombres, renombrado y carga de Especificaciones ........... .. ....... ..... 68 Caso Número 4: La Edición a diferentes niveles donde hay diagramas padres e hijos ..................................................... 71 Caso Número 5: El proceso de Verificación .......................................... 74 Conclusiones y Trabajos Futuros. Conclusiones ........................................................................................... 77 Trabajos Futuros ..................................................................................... 79 Uso del DFDX (Editor). Introducción ............................................................................................ 80 Especificación de la herramienta del DFDX, usando DFDX ................. 80. 11.

(5) Anexo B. 2 2.1 2.2 2.3 2.4 2.5. Las Operaciones de Reestructuración. Conjunto de Operaciones de Reestructuración ....................................... 89 Especificación de Operadores de Reestructuración ................................ 90 El Operador de Agrupación .................................................................... 91 El operador de Expansión ....................................................................... 92 El Operador de División ......................................................................... 93 El operador de Fusión ............................................................................. 95 El Operador de Transferencia ................................................................. 96. LISTA DE FIGURAS 1.1 1.2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5.1 5.2. El Ciclo de Vida del Software ................................................................ 2 Usuarios de Especificaciones ................................................................. 4 Los componentes Gráficos del DFD ....................................................... 9 Una Entidad Externa o Terminador ........................................................ 11 Un proceso .............................................................................................. 11 Los Flujos de Datos ................................................................................ 11 Un almacén de datos ............................................................................... 12 Interrelación de los elementos del DFD ................................................. 12 Ejemplo del Uso Del DFD ...................................................................... 13 Un DFD nivelado .................................................................................... 17 Elementos de eXtensión del DFD ........................................................... 20 Simple interacción del usuario con el sistema ....................................... 3O Operaciones básicas de edición ............................................................. 33 Base de Datos ......................................................................................... 34 Diagrama de Contexto (nivel O) ............................................................. 35 Este es el diagrama 1 (5 procesos de transformación.) ........................... 35 Prototipo de Interfase principal, para la herramienta de construcción de especificaciones a través del DFD Extendido .................................... 37 Elementos del sistema o Diagrama de Estructura .................................. 38 Archivos necesarios para el sistema ....................................................... 39 Flujos permitidos .................................................................................... 41 Una Máquina de Estado Finito, El Interruptor de una Lámpara ............. 46 Diagrama de transición para un Autómata Finito ................................... 47 Especificación para un Analizador Léxico en Pascal ............................. 49 Un ejemplo de una RP ............................................................................ 54 Modelando un programa con una RP ..................................................... 55 RP antes y después de disparo ................................................................ 56 RP, ¿posible evolución? ........................................................................ 56 RP para modelar actividades independientes ......................................... 57 Interfase Inicial Del Sistema ................................................................... 64 Interfase Inicial, algunas opciones .......................................................... 64. iii.

(6) 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.1 O 5.11 A-O A-1 A-2 A-3 A-4 A-5 A-6 A-7 A-8 B-1 B-2 B-3 B-4 B-5. Un Editor Amigable ................................................................................ 66 Asignando Datos a Elementos u Objetos ................................................ 68 Guardando Especificación ...................................................................... 69 Asignando Nombre a Especificación ...................................................... 70 Una especificación Recuperada .............................................................. 70 Selección de proceso para bajar un nivel de abstracción ........................ 72 Edición en varios niveles de varios diagramas, flujos heredados ........... 73 El Proceso de Verificación, disponible en cualquier diagrama .............. 74 El Proceso de Verificación, después de una modificación errónea ........ 75 Diagrama de Contexto de la Especificación( Nivel O) ........................... 80 HERRAMIENTA DE EDICION(Nivel 1) ............................................. 81 TRABAJO DE MENU(Nivel 1-1) ......................................................... 82 PALETA DE HERRAMIENTAS(Nivel 1-2) ......................................... 83 El proceso PIZARRON DE EDICION(Nivel 1-3) ................................. 84 El trabajo de archivos en MENU_ARCHIVO(Nivel 1-1-1) ................... 85 El proceso de Crear un nuevo Archivo de la sección Arhivo, del área de menú. ARCH_ NUEVO Nivel ( 1-1-1-1) ........................... 85 El proceso de crear un nuevo elemento (Proceso) de la especificación MBH _PROCESO (nivel 1-2-3 ) ............................................................. 86 Proceso del evento mouse_down del ratón. MOUSE_DOWN, ejecutado sobre el PIZARRON DE EDICION (Nivel 1-3-1) ................. 87 La operación de Agrupar ........................................................................ 91 La operación de Expansión ..................................................................... 92 La operación de División ........................................................................ 94 La operación de Fusión ........................................................................... 95 La Operación de Transferencia, que usa las Operaciones Subir y Bajar 97. TABLA 4t-1. Tabla Comparativa de los tres Métodos Formales Presentados ............. 61. iv.

(7) RESUMEN. El desarrollo de sistemas de software está soportado por el modelo del Ciclo de Vida del Software. Una de las etapas de mayor importancia dentro de tal modelo es la Especificación de Requerimientos. La comunicación entre el desarrollador o el equipo de desarrollo de sistemas y el cliente e incluso entre los miembros del equipo de desarrollo, es de importancia tal, que obliga a la utilización de un lenguaje de especificación que permita esa buena comunicación y que sea fácil de entender. Es por esto que la intuitividad y sencillez del Diagrama de Flujo de Datos (DFD), le han hecho tan popular. Sin embargo la especificación de sistemas a través de DFDs produce especificaciones ambiguas e inconsistentes que dan como resultado altos costos de mantenimiento de sistemas. La extensión del DFD resolvió tal problemática, desarrollando un método capaz de aprovechar las características intuitivas del DFD y eliminando sus ambigüedades e inconsistencias a partir de la inclusión de nuevos elementos gráficos soportados por reglas formales de construcción. El DFD eXtendido (DFDX), se presenta como una herramienta competitiva y eficaz. El uso manual del DFDX representa una de sus principales desventajas con respecto a otros Métodos Gráficos de Especificación Formal (MGEF). El presente trabajo de tesis pretende contribuir al fortalecimiento del DFDX mediante el desarrollo de una herramienta computacional que automatice la construcción de especificaciones con DFDXs y verifique la correctés de tales especificaciones. Se fortalece además mediante su inmersión en los MGEFs a través de un estudio comparativo con otros dos MGEFs de amplio uso como son las Redes de Petri y las Máquinas de Estado Finito, además se propone la formalización de nuevas operaciones de reestructuración de los DFDXs, que son viables de ser automatizadas y agregadas a la herramienta desarrollada.. Palabras Clave y Frases Clave:. Modelo del Ciclo de Vida del Software, Métodos de Especificación Formal, Diagrama de Flujo de Datos, DFDX reglas formales de construcción, operaciones de reestructuración, Redes de Petri, Máquinas de Estado Finito.. V.

(8) Capítulo 1. Introducción. CAPITULO 1 INTRODUCCION. 1.1. ANTECEDENTES. El Software no es tan solo un conjunto de programas de computadora asociados con alguna aplicación o inmersos en algún producto. Además de los programas, el software incluye la documentación necesaria para instalar, usar , desarrollar y mantener esos programas. El término Ingeniería de Software (ISW) fue empleado por primera vez a finales de los años 60s en una conferencia internacional de impacto mundial llamada "La Crisis del Software", resultante de la carencia de buenos métodos de desarrollo de software, poca experiencia en el desarrollo de grandes sistemas , de la velocidad desigual de desarrollo de hardware y software. En esa conferencia se planteaba la necesidad de dedicar un área al estudio específico del desarrollo de software. A pesar que han existido avances considerables en la calidad del software que se produce, a más de treinta años del nacimiento de la ISW, el problema de la Crisis del Software aún no ha sido resuelto (Sommerville 94]. A pesar de los problemas de desarrollo de software, la computación se ha vuelto de uso casi popular y crece de manera impresionante la cantidad de personas y empresas que se involucran en el área de la computación. Ese auge computacional estimula el nacimiento de empresas dedicadas al desarrollo de software para las más variadas aplicaciones y esto, a su vez, el desarrollo de cada vez mejores productos de software con el fin de ganar un mercado. Sin embargo las mejoras en la productividad del software no están a la altura de las demandas. Es por ello que la ISW está en una búsqueda permanente, a través de sus diferentes disciplinas, de soluciones para elevar la calidad de los sistemas de software..

(9) Capítulo l. Introducción. Algunos de los atributos comunes de un software de calidad son :. Mantenible.-. Debe estar escrito y documentado de tal forma que las modificaciones puedan ser hechas sin grandes costos.. Confiable-.. Que ejecute sus tareas de acuerdo a lo que el usuario espera y no tener fallas mas allá de las que el usuario tolere en su especificación.. Eficiente.-. Entendiendo por eficiencia el uso óptimo de los recursos del sistema.. Interfase Apropiada al Usuario. - Muchas veces el software no es utilizado en su total potencial, por tanto es importante que la interfase de usuario sea hecha a la medida de las capacidades y conocimientos del usuario. Además del uso de entornos que le sean familiares como los sistemas de menú. Es deseable que los mensajes de error no sugieran que el usuario tiene la culpa, por el. i.. r-Í)c11;;·¡-ció-n cl~---._. l__ Requerimientos I. I. l --·-·····--·--·-. ········--··-·-·····---.J. .1. ,,. r!. Disefio del S0llware y del Sistema 'l. 1. 11. i. 1---~. ,. lrnpleme11tación y Pn11::bas de Unidad. 1----,. .. 1. 'l. '. 'r Pruebas dd Si, t<:ma y de Intcgra~ión. -~. ,,. Operación y Ma11tc11imiento. ¡. ¡.________________________. FIGURA 1.1 El Ciclo de Vida del Software[Sommerville 94].. 2.

(10) Capítulo I. Introducción. contrario, estos deben ofrecer soluciones acerca de como recuperarse de los errores [Sommerville 94].. Es precisamente en la búsqueda de calidad que a principios de los 70s se proponen modelos de desarrollo de software, como el modelo en cascada que está basado en técnicas de aplicación ingenieril y que en un principio tuvo bastante aceptación. Sin embargo después de un tiempo de aplicación, se notó que era apropiado sólo para determinado tipo de sistemas, además de que en realidad no se termina una etapa y se continúa con la siguiente sin regresar otra vez a la etapa anterior. Se propone después el Modelo del Ciclo de Vida del Software (MCVS), ver figura 1.1 . No es casualidad que la primera etapa del ciclo de vida del software en la figura 1.1 se encuentre resaltada. Este trabajo pretende aportar. una herramienta que ayude a elevar la calidad de la etapa de Definición de. Requerimientos. El análisis de requerimientos de software se describe en un Documento de Especificación de Requerimientos (DER). En [Zave 90] se define a una Espec(ficación de. Requerimientos como una representación de un sistema de computadora propuesto o existente. El DER puede servir como base para un contrato entre un desarrollador y su cliente para el desarrollo del sistema propuesto. Pero además del cliente y el desarrollador hay mas usuarios ¿ Quiénes son ?. En la figura 1.2 cada miembro de ese equipo de desarrollo representa un rol diferente en el proceso de desarrollo de sistemas . Una persona que juege cualquiera de esos roles es un usuario potencial de las especificaciones. En la práctica, una persona puede jugar diferentes roles, pero hay roles que no pueden ser jugados por cualquier persona. En esta etapa de Especificación de Requerimientos, la persona que juega el rol de "cliente", puede adecuar sus expectativas en relación a sus necesidades y recursos disponibles para llevar a cabo el desarrollo de su sistema.. 3.

(11) Capítulo J. Introducción. ¿, Qué hace este programa?. Chente. )~~--·~J:~--· Cliente. Especi ii cador. Proµrru11ador. Verificador. (.Salisface esle programa la Espceificac,on?. Figura 1.2.- Usuarios de Especificaciones[Wing 91 ].. Existen dos tipos bien definidos de métodos de especificación, los formales y los informales. Los informales suelen ser más amigables, de tal forma que casi cualquier tipo de usuario los pueda leer y entender. Esto no significa que necesariamente deba ser así, usualmente los métodos informales se conforman de elementos gráficos y sintácticos que permiten especificar una secuencia de procesos y acciones de manera intuitiva, usando elementos fáciles de identificar y relacionar, como son los elementos gráficos. Algunas veces utilizan lenguaje natural y/ó pseudocódigo. Por el contrario los métodos formales usados en el desarrollo de sistemas de cómputo se basan en algunas herramientas matemáticas que permiten describir las propiedades de un sistema. En la mayoría de estos métodos se requiere que el usuario conozca de conceptos simples de álgebra, teoría de conjuntos y lógica formal. Para la aplicación de algún método formal específico, los usuarios necesitarían saber algunas teorías matemáticas adicionales como lógica digital si se especifica hardware o. 4.

(12) Capítulo J. Introducción. probabilidad y estadística si se especifican sistemas de confiabilidad. Debido a que la notación utilizada en estas áreas es léxica y pudiera parecer difícil de comprender, se dice que los métodos formales son una herramienta léxica poco intuitiva. Por tanto algunos desarrolladores de las especificaciones formales tienen que hacer también una especificación con un método informal para así poder interactuar con el cliente, además de interactuar con otros usuarios de la especificación (miembros del equipo de desarrollo sin conocimiento sobre métodos formales). Esto suele suceder, pues muchas veces los programadores por ejemplo, no dominan algunas áreas de conocimiento necesarias para trabajar con métodos de especificación formal y por tanto prefieren el uso de métodos informales como es el caso del DFD que propone [Demarco 78]. Se puede decir además que aún no existe una cultura general de software que permita la difusión y aplicación de los métodos formales de especificación.. 1.2. HERRAMIENTASCASE Las Herramientas CASE, por sus siglas en inglés (Ingeniería de Software Asistida. por Computadora), son los programas de cómputo que auxilian a los integrantes del equipo de desarrollo de software durante las diferentes etapas del ciclo de vida del software. [Guezzi 91] señala que un entorno es una colección de herramientas relacionadas. Las herramientas y entornos ayudan en la automatización de algunas de las actividades que están incluidas en la ISW.. Sin embargo, es importante aclarar que aunque muchas gentes involucradas en el desarrollo de sistemas asumen que las herramientas CASE representan una solución a todos sus problemas de desarrollo de sistemas, eso no es del todo cierto. La administración debe seleccionar y aplicar métodos que soporten la herramienta CASE y entrenar a los desarrolladores en tales métodos.. 5.

(13) Capítulo 1. Introducción. El uso apropiado de una herramienta CASE puede mejorar de manera significativa la productividad de los desarrolladores y elevar la calidad de los sistemas. Además de una herramienta CASE, se incluye una aplicación apropiada de administración, métodos, disciplina y entrenamiento en un trabajo conjunto [Chmura 95].. 1.3. EL PROBLEMA Es importante señalar que los métodos de especificación formal pueden ser. complementarios a los informales buscando aprovechar los beneficios y eliminar desventajas de ambos. Esto es, conjugando las características intuitivas de los métodos informales con las ventajas matemáticas de los métodos formales. Esto ha sido posible en la definición de un método de especificación denominado Diagrama de Flujo de Datos Extendido (DFDX ó DFD Extendido) [Molina 94][Frausto et al 97]. El DFD Extendido es todavía una herramienta manual, entendiendo por manual la especificación manuscrita y/o usando herramientas computacionales auxiliares como. PaintBrush 1- 1 u otra. Por lo tanto su utilización resulta cansada, pues en un momento determinado, al hacer un pequeño cambio se puede derivar en modificaciones en varias partes y a diferentes niveles de la especificación. Por tanto es muy importante el contar con una herramienta CASE propia del DFDX que permita la construcción de especificaciones formales a través de una interfase amigable con elementos gráficos familiares al usuario y algunos elementos nuevos de igual intuitividad y sencilla comprensión.. 1.4. EL OBJETIVO Se pretende introducir al usuano al conocimiento de los métodos formales, el. porqué son necesarios, donde se aplican, de qué manera ayudan a elevar la calidad en el proceso de desarrollo de software, qué se necesita para conocerlos, y contribuír de esta forma a la promoción de un área que puede ayudar a reducir sensiblemente los costos en la etapas posteriores a la definición de requerimientos de usuario.. 11 -. Es un programa de edición gráfica que corre bajo Windows de Microsoft.. 6.

(14) Capítulo 1. Introducción. Se pretende el desarrollo de un sistema de cómputo cuyo beneficio redunde en una edición gráfica que lleve de la mano al usuario durante el proceso de edición de alguna especificación y que además sea capaz de determinar la correctés 1-2 de las especificaciones construídas en base a los principios y reglas de construcción del DFDX.. Sin embargo es válido aclarar que no se pretende profundizar en los detalles de edición gráfica, ya que el desarrollo de un editor gráfico representa de entrada un fuerte trabajo de programación, que no es lo que se pretende a priori.. Se pretende también ubicar al DFDX, en el contexto de los métodos formales gráficos a través de una comparación con algunos de los métodos más conocidos como Redes de Petri y Máquinas de Estado Finito.. 1.5. LA ESTRUCTURA DE LA TESIS En este Capítulo se describen los antecedentes, se introducen los métodos formales,. en donde los ubicamos dentro del ciclo de vida del software, su problemática y beneficios. El problema que se va a resolver,. las herramientas CASE y las expectativas de la. herramienta que se propone desarrollar. El objetivo de la presente tesis y la estructura del trabajo.. En el Capítulo 2 se plantean los fundamentos básicos del DFD y del DFDX, así como la definición formal de sus elementos. Con esto se pretende que el lector se familiarice con los nuevos elementos propuestos en el DFDX y conozca el aspecto que da formalidad al método.. 12 -. Se tomará como correcta a una especificación cuando ésta esté apegada a las reglas de construcción del. DFDX. 7.

(15) Introducción. Capítulo 1. En el Capítulo 3 se presenta el diseño y aspectos de importancia retomados de la implementación del sistema propuesto. Los. conjuntos de información que el sistema. necesita, de entrada, de salida, de bases de datos, el diseño modular y el detalle a un nivel todavía abstracto de algunos módulos de importancia para la implementación del sistema.. E11 el Capítulo 4 se presenta un estudio comparativo que ubica al DFDX dentro de los principales métodos gráficos de especificación. Se introducen también fundamentos de dos MGEF de uso muy común en las ciencias de la computación como lo son las Máquinas de Estado Finito y las Redes de Petri.. En el Capítulo 5 se ejemplifica el uso del sistema para modelar algunos sistemas con el sistema propuesto. Se desarrollan casos de prueba que ayudan a mostrar algunos ejemplos del uso del sistema de edición a desarrollar. Se ilustra así el beneficio y la contribución a la herramienta de especificación formal (DFDX) al automatizar su aplicación.. El Capítulo 6 presenta las conclusiones y propone trabajos futuros en la línea de la investigación. Se proponen ideas para una implementación más elegante y aspectos de optimización. de nivelación de estructura de los DFDXs denominados operadores de. reestructuración.. El Anexo A presenta una especificación, mediante el uso del DFDX, de la herramienta desarrollada.. El Anexo B presenta las operac10nes de reestructuración, su descripción y especificación hasta un nivel de requerimientos.. 8.

(16) Capítulo 2. Fundamentos Básicos del DFD y DFDX. CAPITULO 2. FUNDAMENTOS BASICOS DEL DFD Y DFDX. 2.1 INTRODUCCJON En el desarrollo de sistemas de software, una fase importante es el establecimiento de la Especificación de Requerimientos de Software. El documento que se produce es considerado como un contrato entre el desarrollador y el usuario final del sistema; por esta razón, es fundamental realizar esta fase de una manera tal que sea clara para ambos. Como lo hemos señalado, los DFD pueden contribuir a una mejor definición de requerimientos de software. Sin embargo esto no significa que no sean útiles en el desarrollo de las fases posteriores del proceso de desarrollo de sistemas.. Principales Componentes del DFD. Entidad Externa. [. Proceso. Almacén. ..... Fluju de Datos. Figura 2. l Los componentes gráficos del DFD.. 9.

(17) Capítulo 2. Fundamentos Básicos del DFD y DFDX. En este capítulo se presentarán los Conceptos Básicos de los DFD y DFD eXtendido . En la figura 2-1 se presentan elementos que se usan en el DFD, así como su significado [Demarco 78].. 2.2. LOS DIAGRAMAS DE FLUJO DE DATOS. Un Diagrama de Flujo de Datos es una representación en red de un sistema de software. El sistema puede ser automático (donde éste funciona de manera transparente al usuario), manual o una mezcla de ambos. El DFD interpreta el sistema en ténnino de sus piezas componentes con todas las interfases entre los componentes indicados [Demarco 78]. Es cierto que la popularidad de los DFDs proviene de la notación gráfico-intuitiva que permite una fácil identificación de sus elementos así como el significado de éstos. Es cierto también que la flexibilidad tiene sus costos, pues la falta de una base formal para los conceptos y la notación del DFD prohibe su uso como una herramienta de especificación formal [Molina 94].. 2.2.1 NOTACION DE LOS DFDs. Los DFDs muestran regularmente cómo la entrada de datos es transformada en resultados de salida a través de transformaciones secuenciales. Los DFDs son una parte integral de un determinado número de métodos de diseño y las herramientas CASE usualmente soportan la creación de diagramas de flujo. Las notaciones usadas en diferentes métodos son similares [ Sommerville 94]. Los datos pueden ser transformados y almacenados, y también pueden desplazarse entre los elementos del diagrama y desde entidades externas. Los elementos ó símbolos utilizados en el DFD que presentamos aquí son los siguientes:. 10.

(18) Capítulo 2. Fundamentos Básicos del DFD y DFDX. Etiqueta. Una Entidad Externa o Terminador es una fücnte de entradas o salidas, al o desde, el sistema. Figura 2.2 Una Entidad Externa o Terminador.. En la Figura 2.2 se representa una Entidad Externa o Terminador. El terminador es una persona o un elemento al exterior del sistema, es decir , que no forma parte del sistema sino que es quien recibe o envía datos-información al sistema. Este elemento, por su propia definición, sólo funciona como enlace entre el sistema y el mundo exterior. Por convención son representados como rectángulos etiquetados.. Etiqueta. Un Proceso es una transformación. donde un flujo de datos que entra es transformado , mod ificado o procesado, generando así datos de salida. La transformación es etiquetada con un nombre descriptivo. 1. Figura 2.3.- Un proceso.. En la Figura 2.3 se representa un proceso o procedimiento. Es un tratamiento, proceso, transición o procedimiento al que son sometidos los datos de entrada. Es representado como un rectángulo circular con una notación descriptiva.. i. l ____ ____...,.. ;. í. ~. .... Etiqueta. Los Flujo de daros representan la circulación o tránsito de datos o información. donde la flecha indíca su dirección. !. -!I. :. . . . . . . . . .~""111111m1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1111111!1. . . . . .1111111!1,. .111!! ~~~.,. .. Figura 2.4. Los Flujos de Datos.. 11. --,·-·-·------.

(19) Capítulo 2. Fundamentos Básicos del DFD y DFDX. Un flujo de datos es la liga entre los diferentes elementos del DFD (con excepción de si mismo). Suelen también ser etiquetados con un nombre mnemónico, de preferencia, que representa a un paquete de información coherente, es decir , con un sentido. Cuando de un proceso salen dos flujos de infonnación (A y B) significa que la infonnación del flujo A no necesita de la del B y viceversa. Un flujo de datos NO es un activador de procesos, no se debe usar con ese fin [Demarco 78].. Un Almacén de Datos es un depósito de datos o de. Etiqueta. información.. Figura 2.5.- Un Almacén de datos.. Un Almacén de datos es el lugar. en donde son almacenados los datos, éste puede ser. físicamente un dispositivo de almacenamiento como disco o cinta magnética. La notación es sencilla; dos líneas horizontales paralelas con la etiqueta, normalmente entre ellas (ver fig. 2.5). La etiqueta debe decir mucho pues contribuirá a una mejor lectura, es por ello que se recomienda no codificar los nombres de los archivos.. IB2. datos. datos. datos. datos. 5 entidad 1 ,_____. roceso 1 ----. proceso ~ _____. proceso 3~ entidad2 1. • datos 3. datos 4. • Almacén de datos Figura 2.6 Interrelación de los elementos del DFD [Molina 94].. 12. j.

(20) Capítulo 2. Fundamentos Básicos del DFD y DFDX. En la figura 2.6 podemos observar la utilización de los elementos del DFD [Molina 94], donde entidad] y entidad2 son entidades externas (fuente y salida respectivamente), proceso], proceso2 y proceso3 son los procesos donde se transforma la información de. entrada, la entidad almacén de datos intercambia datos con proceso2 y por último, las entidades datosl .. datos6 muestran la existencia y dirección de flujos de datos.. 2.2.2. UN EJEMPLO DEL USO DEL DFD (Trámites Electorales). A continuación se presenta un ejemplo que ilustra una especificación usando DFD como método informal, un ejemplo sencillo y común: Trámites Electorales. Después, con el fin de observar un método formal en una notación léxica y contrastar sus características antes de plantear la formalidad del DFD. Como se puede observar en la figura 2.7, no se necesita más que un poco de atención para comprender lo que la especificación propone. Sin embargo. es una. especificación ambigua, ¿porqué?. PAIJRON. DATOS ACTUALIZADOS. TIPO __ TRi\MITE. DATOS. MENSAJE.ERROR. EDAD. ORDEN. o~ ~o ro. CREDENClAL TOMA .DE __ FOTOGRAFI ..\. flGURA 2.7. Ejemplo del Uso Del DFD.. 13.

(21) Capítulo 2. Fundamentos Básicos del DFD y DFDX. A).- Es importante notar que después del proceso UBICAR al ciudadano, no se conoce el orden de secuencia de los datos requeridos para evaluar su trámite, ni tampoco si son todos indispensables. No se conoce si el dato de MENSAJE ERROR es necesario o inevitable que aparezca al ciudadano. 8).- Después del proceso de EVALUAR TRAMITE, no se sabe si hay un orden en la salida de datos. C).- No se sabe si ambos datos saldrán a la vez del proceso EVALUAR_TRAMITE o si saldrá uno u otro. Aunque la especificación parece ser clara e intuitiva, al momento de ser implementada pueden sus usuarios (en este caso el programador), tener su propia interpretación . Con ayuda de la Lógica de Primer Orden (LPO) usando precondiciones y postcondiciones de procesos la especificación luciría así:. {DATOS_ CIUDADANO} UBICAR {MENSAJE_ERROR V (TIPO_TRAMITE A NOMBRE A FECHA_NAC A LUGAR_NAC A EDAD)}. { TIPO TRAMITE A NOMBRE A FECHA_NAC A LUGAR_NAC A PADRON} EVALUAR TRAMITE {(ORDEN_DE_FOTO A DATOS_ACTUALIZADOS) V FECHA_SIGUIENTE_TRAM}. {ORDEN_DE_FOTO} TOMA DE FOTOGRAFIA {CREDENCIAL}. Como se puede ver, estas especificaciones lógicas muestran los datos de entrada y salida, pero no muestran como se llevan a cabo los procesos. Para ello se traducen a. 14.

(22) Capítulo 2. Fundamentos Básicos del DFD y DFDX. símbolos de predicados que al ejecutarse permiten verificar la consistencia de la especificación [Lian, Chan 87]. Después de que se ha visto lo contrastantes que pueden ser los métodos formales-informales, se presenta la formalización del DFD.. 2.2.3 DEFINICION FORMAL DEL DFD. Los DFD son una de las herramientas de mayor uso en la ISW, lo que ha motivado el tratar de hacer uso de ellas como una herramienta formal, con este fin se han llevado a cabo investigaciones que se pueden complementar, por ejemplo:. Poh-Tin and K.P. formalizan a los DFDs mediante el uso de Redes de Petri en [Pho Tin 92].. Ming-Jie define a los DFDs como una quinteta (P,T,F,A,C), donde P={procesos},. T={Terminadores}, F={flujos}, A={Almacenes} y Ces la relación de conexión Ce f(PuT) x (FuA)J u f(F uA) x (PuT)J.. De tal suerte que un diagrama inicial es siempre. (@, @, @, @, @),. asumiendo así que. cada elemento será referido por su etiqueta.. Para una estructura de un DFD x se usa la notación x.P,x.T,x.F,x.A y x.C Para abreviar se define a X. Y como U,EX x.Y Donde X es el conjunto de DFDs y Y puede ser P,T,F,A ó C.. Se definen también 4 funciones para obtener los flujos de entrada, flujos de salida, almacén de entrada y almacén de salida de procesos y terminadores.. Molina retoma las definiciones de flujos y almacenes de entrada y salida propuestas por Ming-Jie y las aplica a los nuevos elementos propuestos en [Molina 94]:. FAND¡ (_). Es una función AND de flujo de entrada. 15.

(23) Capílulo 2. FAND. o(_). FoR; (_) FoR. O (_). Fundamentos Básicos del DFD y DFDX. Es una función AND de flujo de salida Es unafunción OR de flujo de entrada Es unafunción OR de flujo de salida. AAND¡ (_). Es una función AND de Almacén de entrada. AAND o(_). Es una función AND de Almacén de salida. A OR¡. (_). Es unafunción OR de Almacén de entrada. (_). Es una función OR de Almacén de salida. AoR. 0. Es un elemento ordenado del conjunto. FANO. Es un elemento ordenado del conjunto. AAND. Sea un proceso o terminador e en su DFD residente x, y para un conjunto de procesos y terminadores E;. FAND¡ (e) = { f0. E. x,FI < fo ,e>. E. x.C, donde :le. E. x.P u x.T A f0 < f0 +1}. FANoº(e) = { fo. E. x.FI < e, fo>. E. x.C, donde :le. E. x.P u x.T A fo< fo+I }. FoR¡ (e) = { f. E. x.F¡ < f,e > E x.C, donde :le. FoRº(e) = { f. E. x.F¡ < e, f>. E. x.P u x.T}. E. x.C, donde :le. x.P u x.T}. E. AAND¡ (e) = { an. E. x,FI < ao,e > E x.C, donde :le. E. x.P u x.T A a 0 < a 11 +1 }. AA·mº (e)= { a 11. E. x.FI < e, a 0 > E x.C, donde :le. E. x.P u x.T A a .. < a11+1 }. AoR¡ (e) = { a. x.F¡ < a,e >. AoRº (e)= { a. E E. E. x.C, donde :le. E. x.F¡ < e,a > E x.C, donde :le. E. x.P u x.T} x.P u x.T}. Fi (E) = U e E E Fi (e). Fº (E) = U e EE Fº (e) A¡ (E)= U e EE A¡ (e) O. A (E) = U e EE A (e) O. 2.2.4 MODELADO DE SISTEMAS Se modela un sistema como una estructura nivelada de DFD donde en el tope se encuentra el diagrama de contexto y en el más bajo nivel de los diagramas se encuentran los. 16.

(24) Capítulo 2. Fundamentos Básicos del DFD y DFDX. diagramas de transformación (Ver Figura 2.8). Ahí se puede definir un sistema como un diagrama de contexto, un conjunto de diagramas de transformación y un mapeo entre esos diagramas de transformación y sus procesos padres.. En la figura 2.8 se muestra un DFD nivelado, donde un diagrama de contexto AA aparece en primer plano y los diagramas de transformación en segundo {AA.I ,AA.2,AA.3}.. L. !!. 7 /,,___. ~ _ ____.., ~ --/. v. ~. U,. 7. Figura 2.8. Un DFD nivelado.. Un modelo de sistema es una tripleta (de, X,D), donde de es un diagrama de contexto, X es un conjunto de diagramas de transformación y D s;;; (P x X) es una relación de descomposición con P = ( de.P u X.P). Un modelo de sistema inicialmente creado será ((lJ, lJ, lJ, lJ, lJ), lJ, lJ). Para un modelo de sistema m, usamos las notaciones m.P, m. T,m.F,m.A y m. C para referirse al conjunto de todos los procesos, terminadores, flujos, almacenes y sus conexiones, como. 17.

(25) Capítulo 2. Fundamentos Básicos del DFD y DFDX. m.P=m.dc.P u m.X.P , m.T=m.dc.T u m.X.T, m.F=m.dc.F u m.X.F, m.A= m.dc.A u m.X.A y m.C=m.dc.C u m.X. C.. Entonces para describir un proceso < p,x > que está en m.D, se utiliza la función x.pa para referirse al proceso p padre del diagrama x. y la función p.hijo se refiere al diagrama hijo x del proceso p. Si p no existe en m.P tal que < p,x > esté en m.D, la función x.pa está indefinida. Si x no existe en m.X tal que <p,x > esté en m.D, la función p.hijo está indefinida. [Ming- Jie 91]. plantea la automatización de los DFD,. así. como algunas. operaciones de reestructuración. [Molina 94] plantea una extensión al DFD a través de nuevos elementos que eliminan gran parte de las inconsistencias originales.. 2.2.5 REGLAS DE CONSTRUCCION DE LOS DFDs. Los DFDs a varios niveles tienen un conjunto de reglas sintácticas y semánticas (como lo son de conectividad, conservación de datos y precedencia.). Algunas de las que se presentan a continuación son recomendaciones para hacer especificaciones coherentes, entendibles y gratas a la vista [Molina 94] [Martínez 93].. l.. Escoger nombres mnemónicos para los elementos de construcción del DFD. Es recomendable también que estos nombres no sean muy grandes, por motivos de estética y por la fluidez al leer éstos.. 2.. Enumerar los procesos como una forma de identificarles.. 3.. Redibujar el DFD tantas veces como sea necesario estéticamente. Esto con el fin de que su presentación sea clara.. 4.. Evitar los DFD Excesivamente complejos. Esto es un número pequeño de elementos (aproximadamente 1O) en un mismo diagrama y evitar cruces en los flujos de datos.. 18.

(26) Fundamentos Básicos del DFD y DFDX. Capítulo 2. 5.. Asegurarse de la consistencia interna de los DFDs. En este punto, [Pho Tin 92] sugiere algunas reglas que dan integridad a cualquier DFD.. • Cada Entidad Externa-Fuente tiene un flujo de dato de salida. • Cada Entidad Externa-Destino tiene un flujo de dato de entrada • Cada Entidad de Almacén tiene un flujo de datos de entrada y un flujo de datos de salida. • Cada Entidad de Proceso tiene un flujo de datos de entrada y un flujo de datos de salida. • Cada Flujo de Datos tiene una Entidad Fuente y una Entidad Destino válidos.. 6.. Poh sugiere también algunas restricciones de balance:. • Cada flujo de entrada de un proceso padre debe ir hacia un proceso hijo en el diagrama hijo. • Cada flujo de salida de un proceso padre debe provenir desde un proceso hijo en el diagrama hijo. • La suma de todos los flujos de entrada a un proceso padre debe equilibrar la suma de todos los flujos de entrada de su diagrama hijo. • La suma de todos los flujos de salida de un proceso padre debe equilibrar la suma de todos los flujos de salida de su diagrama hijo.. 2.3. EL DIAGRAMA DE FLUJO DE DATOS EXTENDIDO (DFDX).. El problema de la ambigüedad de los DFDs, es la más importante de sus desventajas. Sin embargo, su amplia aplicación, popularidad e intuitividad, obligan a buscar alternativas de su aplicación. Aportaciones como las señaladas arriba, referentes a las reglas de construcción y como las de Molina, quien plantea el uso de nuevos elementos en los DFDs, eliminan en conjunto el problema de la ambigüedad y presentan al DFD eXtendido como una alternativa para ayudar a la construcción de una buena especificación.. 19.

(27) Capítulo 2. Los. Fundamentos Básicos del DFD y DFDX. nuevos elementos propuestos por Molina, presentados en la figura 2.9,. clarifican el orden y necesidad de datos modificando su secuencia y nivel de requisito, es decir, trabajan exclusivamente sobre el elemento de flujo de datos . -·,-. l. o. 1. 'l. ~=. Es util12a<lú sobre los flujos de entrada ,·.'o saltda , Jndica qu,, los datos so11 necesarios o r,-qu,-ri<los. o. l. ....----. Es util izado sobre los fl ujo , de entrada y.:o salida. Indica que los datos son deseables, esto es , que seria ópt imo contar con ellos para utiliza rles .. D. I•. Signifi ca AN D y es ut ilizado Cúmo agru pador de Flujos de Datos .. Signiric:, cm v se utili za , al igual que AND . ~01110 u11 :1¡:ruµ ado, de tlujo de datos. . \. ....................................................................................... :::J Figura 2.9. Elementos de eXtensión del DFD.. 2.3.1 REGLAS DE CONSTRUCCION DE LOS DFDX.. Las reglas de construcción de esta extensión del DFD, son básicamente las mismas del DFD original, sin embargo se agregan algunas nuevas para una correcta interpretación. Se toman en cuenta 2 enfoques; uno se refiere a los flujos de datos de SALIDA de un. ~z. proceso, y el otro se refiere a los flujos de datos de ENTRADA a un proceso. rÍ. ,,)(JL. p_) l. Para los flujos de datos de salida o entrada de un proceso.. 1.1. Si el flujo de datos tiene un círculo, es deseable que se tenga esta salida o entrada de datos.. 20. IIILIOffQ.

(28) Capítulo 2. Fundamentos Básicos del DFD y DFDX. 1.2. El círculo a su vez, puede tener una condición que determina la. salida o. entrada de datos. 1.3. Si un flujo de datos tiene un rombo, es necesario que se tenga esa salida o entrada de datos.. 1.4. El rombo puede estar vacío, contener un número o contener una función. 1.4.a Si el rombo está vacío significa que no importa el orden. de salida o entrada del flujo de datos. 1.4.b Si el rombo contiene un número, éste indica el orden de. salida o entrada del flujo de datos, en relación con las otras salidas o entradas indicadas en los otros flujos de datos en el DFDX. 1.4.c. Si el rombo contiene una función, entonces el valor de la función indica el orden de salida o entrada del flujo de datos.. 1.5. El conector OR significa que sólo uno de los flujos de datos se genera como salida o entrada.. 1.6. Los conectores AND y OR se utilizan para agrupar las salidas o entradas de los flujos de datos, en los casos que se requieran.. 2.4.. ACERCA DE LA CONSISTENCIA E INTEGRIDAD.. La estructura de un modelo de sistema , diagrama de contexto y diagrama de transformación debe ser consistente, íntegra y debe estar regulada por un conjunto de convenciones llamadas reglas de formación . Tales reglas incluyen formas de modelar un sistema DFD y los conceptos que lo constituyen. También se incluyen reglas de balance y originalidad de los elementos. Una regla de formación se define como una fórmula bien formada , la cual se define recursivamente en lógica proposicional como:. 1.. Un átomo es una fórmula.. 2.. Si Ges una fórmula, entonces ( - G) es una fórmula.. 21.

(29) Capítulo 2. 3.. Fundamentos Básicos del DFD y DFDX. Si G y H son fónnulas, entonces ( G /\ H), ( G v H), ( G => H) y ( G <=> H) son fónnulas.. 4.. Todas las fónnulas son generadas mediante la aplicación de las reglas anteriores.. Puede ser eliminado el uso de paréntesis mediante las jerarquias de uso. de los. conectores proposicionales (en orden decrementa}):<=>,=>, A, v, -. Donde el conector de mayor jerarquía tiene más alcance, por ejemplo: P => Q /\ R será (P => (Q /\ R)) y P => Q /\ -R v S será (P => (Q A(( -R) v S))) [Liang, Chan 87].. Cuando un. modelo de sistema se confonna estructuralmente. de reglas de. fonnación , es estructuralmente consistente e íntegro [Ming -Jie 1991].. 2.4.1. REGLAS DE FORMACION DE LA ESTRUCTURA DEL DIAGRAMA DE CONTEXTO.. En la figura 2.8, el proceso AA , representa el diagrama de contexto del sistema que ahí se ejemplifica. Contiene sólo un proceso representante en todas las funciones del sistema.. El diagrama de contexto de un sistema contiene sólo un proceso que representa las funciones de todo el sistema (3p) dc.P={p}. 2. El Diagrama de contexto tiene todos los terminadores con los que el sistema interactúa y los flujos necesarios entre procesos y tenninadores pero, no se penniten los almacenes en el diagrama de contexto. dc.A=0. 22.

(30) Capítulo 2. 3. Fundamentos Básicos del DFD y DFDX. Sólo se permiten conexiones entre flujos y procesos y entre flujos y terminadores de.e~ [dc.F x (dc.P u dc.T)] u[ (dc.P u dc.T) x dc.F]. 4. El proceso debe tener ambos flujos, entrada y salida (Vp. 5. E. dc.T) [(FANO¡ (t) u FoR¡(t)) u ( FANoº(t) u FoRº (t)). -:f.. 0]. Un flujo no debe ser emisor y receptor del mismo proceso (Vp. 7. dc.P) [(FANO¡ (p) u FoR¡(p)-:t- 0) A ( FANoº(p) u FoRº (p)-:t- 0)]. Cada terminador debe tener conectado al menos un flujo (Vt. 6. E. E. dc.P) [(FANO¡ (p) u FoR\p)) n ( FANoº(p) u FoRº (p)-:t- 0)]. Un flujo no debe tener terminadores, sean el mismo o no, como su emisor y receptor. [(FANO¡ (dc.T) u FoR\dc.T)) n ( FANoº (dc.T) u FoRº (dc.T)) = 0)]. 8. Cada flujo debe tener un emisor y receptor [dc.F~ FANO¡ (dc.P u dc.T) FoR\dc.P u dc.T)] A [dc.F~ FANoº(dc.P u dc.T) FoRº(dc.P u dc.T)]. 9. Cada flujo debe tener a lo más un emisor y un receptor Vq,r e dc.P u dc.T [ (q-:t-r) => ((FANO¡ (q) u FoR¡(q)) n (FANO¡ (r) u FoR¡(r)) = 0) A ((FANoº (q) u FoRº(q)) n (FANoº (r) u FoRº(r)) =0]. 2.4.2. REGLAS DE FORMACION DE LA ESTRUCTURA DE LOS DIAGRAMAS DE TRANSFORMACION. Al menos un proceso es requerido x.P-:t-0. 23.

(31) Capítulo 2. 2. Fundamentos Básicos del DFD y DFDX. No son permitidos los terminadores x.T=0. 3. Son permitidas sólo las conexiones entre flujos y procesos y entre almacenes y procesos. x.F= x.FAND 1 u x. FANoº u x.FoR¡ u x. FoRº x.A= x.AAND¡ u x. AANoº u x.AoR¡ u x. AoRº x.C~ [(x.F u x.A) x x.P] u [x.P x (x.F u x.A)]. 4. Cada proceso debe tener entradas y salidas de flujos o almacenes (Vp. E. x.P) [(FANO¡ (p) u FoR¡(p)) u (AAND¡ (p) u AoR¡(p)) 0. * 0). A. 0. (FANo (p) uFoR (p))u (AANo0 (p) uAoRº(p))-:t0)]. 5. En cada proceso, al menos una de las entradas y salidas debe ser un flujo.. (Vp. 6. x.P) [(FANO¡ (p) u FoR¡(p)) u (FANoº (p) u FoRº(p)). * 0)]. Un flujo no debe ser emisor y receptor del mismo proceso.. (Vp. 7. E. E. x.P) [(FANO¡ (p) u FoR\p)) n (F ANoº (p) u FoRº(p)) = 0)]. Un flujo no debe necesariamente tener su emisor y receptor en el mismo diagrama de transformación, su salida abierta se unirá con el proceso padre del diagrama. Sin embargo, un flujo no debe pasar a través de un diagrama de transformación sin conectarse con un proceso. x.F ~ [(FANO¡ (x.P) u FoR\x.P)) u (FANoº (x.P) u FoRº(x.P))]. 24.

(32) Capítulo 2. 8. Fundamentos Básicos del DFD y DFDX. Un flujo no debe pasar a través de un diagrama de transformación teniendo más de un emisor y receptor. (Vp, q. E. x.P) [(p:tq) => ((FANO¡ (p) u FOR\p)) n (FANO¡ (q) u FoR¡(q)) = 0). A. 0. ((FANo (p) u FoR0 (p)) n (FANo0 (q) u FoRº(q)) = 0)] 9. Los almacenamientos no necesitan tener a sus lectores y escritores en el mismo diagrama de transformación, pero un almacén no debe aparecer en un diagrama de transformación sin ser accesado,. x.A ~ [ AANO¡ (x.P) u AoR¡ (x.P)) u (AANoº (x.P) u AoR¡ (x.P)]. 2.5.. OPERACIONES DE REESTRUCTURACION PARA DFD 'S. Se ha planteado con anterioridad, la necesidad de automatizar el proceso de edición de los DFDX, debido a lo tedioso que suele resultar su trazo, y aún mas sus correcciones, así como dar una mayor consistencia y validación a los diagramas a construir.. En cuanto un sistema crece, se dificulta su control y entendimiento, por otra parte sería imposible manejar DFDs tan grandes como un campo de futbol, estos sistemas, además de ser laboriosos son propensos al error. Es por ello que se hace necesario un proceso de reestructuración que permita dividir el sistema en niveles sin perder consistencia y/o elementos.. Es necesario tener un editor de DFDXs que se encargue de las operaciones de edición específicas para una reestructuración. Sin embargo la implementación total de tales operaciones no se contempla en el presente trabajo, así que se plantearán las operaciones necesarias en el Anexo B.. La división de un sistema muy grande en DFDXs de múltiples niveles, debe darse en un enfoque estrictamente jerárquico, donde los procesos compuestos (llamaremos a estos así, cuando un proceso esté compuesto de subprocesos a su vez) estén definidos en niveles. 25.

(33) Capítulo 2. Fundamentos Básicos del DFD y DFDX. altos y sus procesos componentes en niveles bajos. En el tope de tal jerarquía se encuentra el diagrama de contexto , éste contiene un solo proceso. El sistema que es dividido en base a éste enfoque está dividido en diagramas de. más bajo nivel , los cuales en adelante. llamaremos diagramas de transformación.. Este enfoque de estructura nivelada. hace a un sistema más fácil de leer y. comprender. Desde luego que para llegar a éste punto es necesaria una reestructuración, que cubra las siguientes necesidades.. • Reestructuración para una división apropiada de los niveles de DFDs. Esto es una distribución apropiada del trabajo de un proceso compuesto en todos sus procesos. componentes o hijos.. • Reestructuración para reducir complejidad. Cuando modelamos un sistema en una estructura nivelada lo hacemos en aras de una mayor legibilidad. Sin embargo cuando varios procesos se "apiñan" en un DFD,. tal legibilidad se ve obstaculizada. Cuando. queremos dividir el diagrama, otro importante problema suele ser la complejidad de su interfase, es requisito por lo tanto que cada DFD tenga bien claro su patrón de flujo, pues cuando es muy grande el número de flujos hacia un proceso se tienen que agrupar algunos de los procesos en el diagrama para reacomodar sus flujos.. • Reestructuración para presentar aspectos de un sistema en particular. Es útil presentar el modelo del sistema en varios aspectos, esto con el fin de que la reestructuración a los niveles más altos del modelo del sistema vaya de acuerdo al interés del usuario. Es de utilidad agrupar procesos cuyas entradas y salidas están conectadas a los mismos terminadores.. 2.5.1 REQUERIMIENTOS DE OPERACIONES DE REESTRUCTURACION Podemos usar operaciones de edición básicas tales como insertado/borrado, conectar/desconectar. elementos y crear/remover diagramas para completar una buena. 26.

(34) Capüulo 2. Fundamentos Básicos del DFD y DFDX. reestructuración. Por supuesto que el llevar a cabo este proceso de reestructuración de una forma manual puede ser. tediosa y propensa al error puesto que pueden presentarse. problemas de inconsistencia y falta de integridad.. No es fácil, definitivamente, mantener en balance DFDs nivelados después de la reestructuración, pero es más difícil garantizar que un sistema es equivalente antes y después de ser sometido a un proceso de reestructuración.. Los problemas presentados arriba se acrecentan en una proporción mayor cuando se tratan DFDs muy grandes. Un conjunto de operaciones de reestructuración deseable, debe tener en cuenta los siguientes 3 requerimientos.. • Los modelos de. DFDs nivelados de un sistema, antes y después de cada. operación de reestructuración , deben ser equivalentes.. • Cada operación de reestructuración en el conjunto debe mantener las propiedades de consistencia e integridad del modelo del sistema.. • El conjunto de operaciones de reestructuración debe conocer las necesidades de reestructuración desde el principio.. 27.

(35) Capítulo 3. Diseño del DFDX. CAPITULO 3. DISEÑO DEL DFDX. 3.1. INTRODUCC/ON. Este capítulo permitirá adentrarse a la necesidad, concepción, diseño e implementación de un editor gráfico que permita al ingeniero. de requerimientos de. software, crear DFDXs. En el capítulo anterior se ha descrito el DFDX, tanto sus elementos, reglas de construcción y reglas de formación que lo hacen una herramienta de especificación formal. Sin embargo,. en un estudio comparativo de algunos métodos. formales gráficos que se muestra más adelante (Capítulo 4), se encontró que una desventaja importante del DFDX con respecto a los demás es que no estaba automatizado.. Después de poner en práctica su uso, se ha encontrado que cada modificación puede llevar horas si se toma en cuenta que un cambio en algún elemento puede desencadenar cambios en varios niveles de la especificación.. Una de las aspiraciones de la Ingeniería de Software es determinar la factibilidad y costo del sistema que está siendo construido. Los prototipos y simulaciones ayudan a los desarrolladores a entender mejor los requerimientos de usuario tanto como al diseño del producto inicial, en particular cuando el usuario tiene conocimientos computacionales limitados, pero es conocedor de su área de especialidad [Ramamoorthy 96].. 28.

(36) Diseño del DFDX. Capítulo 3. 3.2. ACERCA DE LAS INTERFASES DE USUARIO. No existe una "mejor" manera de diseñar una interfase de usuario, desde luego que los diseñadores de la interfase deben estar conscientes de que una interfase de usuario puede estar basada en alguno de los modelos existentes, una tarea de los diseñadores es elegir cual es el modelo más apropiado al proyecto que se pretende realizar [Getner 96].. Se pretende mostrar el diseño de la interfase gráfica, así como la implementación de las operaciones de edición tomando en cuenta las reglas propuestas por [Molina 94] y utilizando la herramienta de desarrollo propuesta (Visual Basic). Es importante señalar que el desarrollo de la interfase se sometió a las necesidades del presente trabajo de tesis y se delimitó en término de nuestros objetivos principales; esto es, no es el objetivo de este trabajo la programación de un editor gráfico que tome en cuenta pequeños detalles estéticos, sino la creación de un editor que permita la construcción de especificaciones a través del DFDX y la determinación automática de la correctés de tal especificación. Se puede entonces clasificar al DFDX como una herramienta CASE .. 3.3.. LA ESPECIFICACION DE REQUERIMIENTOS DEL DFDX. Es necesario que previo a las etapas de diseño e implementación de un sistema de software, se cuente con un Documento de Especificación de Requerimientos.. Hasta ahora, se conoce el problema y se han visto en capítulos anteriores las necesidades de automatizar el uso del DFDX, la especificación de requerimientos de software está dada por las reglas de construcción planteadas por Molina, aunque de manera parcial, pues en tal trabajo no se especifica el diseño de la interfase, ni se aislan los detalles de construcción de sistemas de información .. 29.

(37) Capítulo 3. Diseño del DFDX. Debido a que uno de los objetivos de esta tesis es la implementación de la automatización del uso de los DFDXs y en razón de que son éstos una herramienta excelente para la especificación de software, se presentan algunos módulos principales de la especificación de la implementación de la interfase desarrollada (véase Anexo A) . Además de que la formalización de la especificación de requerimientos puede ser -y en éste caso lo es- parte de la fase de diseño [Sommerville 94].. 3.4. DISEÑO A esta fase del Modelo del Ciclo de Vida del Software, concierne el cómo. implementar los requerimientos de software de la manera más efectiva o eficiente. Esta fase puede estar dividida en tres partes , la primera es el diseño del software a un nivel tope (algunas veces llamado diseño de Arquitectura) y la segunda es el diseño modular o Diagrama de Estructura y la tercera es el diseño detallado (algunas veces llamado Detalle de Módulos o diseño a bajo nivel). Se desglosan a continuación: 1.- Arquitectura 2. - Diagramas de Estructura. 3.- Detalle de Módulos Programas de Cóm puto(editor). Reglas Formales de Construcción. t Ju.. j_. J. ~1mp1e mreracc1on ae1 usuario con et sís\emii. ·. 30.

(38) Capítulo 3. Diseño del DFDX. 3.4.1 ARQUITECTURA En primera instancia se ha dividido el sistema en tres subsistemas, donde es importante. identificar. sus. partes. funcionales. y asociarles. sus. correspondientes. requerimientos , así como asociar éstos a programas computacionales [Nieva, Campesino 88]. Se definen aquí : los conjuntos de iformación, los procesos o programas a desarrollar (identificación de programas) y el comportamiento dinámico del sistema.. 3.4.1.1 LOS CONJUNTOS DE INFORMACION Existen básicamente en el sistema tres tipos de conjuntos de información; Entrada,. Salida y Base de Datos.. 3.4.1.1.1 DATOS DE ENTRADA .- Previa instalación y ejecución del sistema en un entorno Windows de Microsoft; las entradas de información al sistema son proporcionadas por el usuario mediante el uso de dispositivos de entrada como ratón o teclado. La interfase en su conjunto permite hacer una especificación usando Diagramas de Flujo de Datos Extendido. En lo particular, la información de entrada depende del estado en el que se encuentre el sistema en un momento dado durante la construcción de los DFDXs.. 3.4.1.1.2 DATOS DE SALIDA.- La información de salida ofrecida por el sistema se constituye de la información que se despliega sobre el área de graficación de la interfaz al momento en que se está construyendo, esto es, la información gráfica que se está editando. Se constituye también de mensajes de error o advertencias o simples avisos desplegados a través de cajas de mensajes. Otro elemento es la información desplegada al momento de hacer la verificación de una especificación, esto se muestra en una ventana pop_ up, que señala los errores que pudieran existir en la construcción de la especificación o en su caso, el mensaje" verificación exitosa". El último elemento es la impresión de la especificación.. 3.4.1.1.3 BASES DE DATOS- La base de datos es creada para cada especificación, una vez que el usuario ha grabado su especificación en disco. Cuando el usuario abre su especificación, la BD es cargada a memoria principal y modificada durante una sesión de. 31.

(39) Capítulo 3. Diseño del DFDX. trabajo, de acuerdo a los usos del sistema, mismos que son por supuesto transparentes al usuario del sistema.. 3.4.1.1.3.1. DISEÑO CONCEPTUAL DE LA BASE DE DATOS.- La base de datos fue. concebida a partir de la arquitectura naturalmente jerárquica de los DFDs 3- 1 , donde cada proceso, a excepción del proceso que pertenece al diagrama de contexto, tiene un padre y O, 1 ó más hijos. Cada proceso puede convertirse en un diagrama y en cada diagrama se pueden aplicar operaciones de edición sobre sus elementos. En la Figura 3.2 todos los ELEMENTOS VISIBLES EN EL DIAGRAMA pueden ser afectados por las operaciones de. ELEMENTOS_INSERCION,. ELEMENTOS MODIFICAR.. ELEMENTOS_BORRAR,. Puede. alguno. de. esos. ELEMENTOS_MOVER, elementos. ser. un. ELEMENTO _PROCESO_HIJO de tal diagrama y éste a su vez, convertirse en diagrama y tener sus propios ELEMENTOS VISIBLES EN EL DIAGRAMA y éstos a su vez, pueden ser afectados por las operaciones señaladas anteriormente y así sucesivamente. Se genera también una tabla virtual creada por el proceso de Verificación de la especificación, que permitirá, previo algoritmo y en base a las reglas de construcción del DFDX, determinar la correctés de la especificación.. 3.4.1.1.3.2. DISEÑO LOGICO DE LA BASE DE DATOS.- Se ha concebido la base. de datos como un caso especial de archivos cuyos componentes están relacionados entre si por algo más que una simple concatenación [Demarco 78]. Se crea un archivo principal que contiene los datos de los elementos de la especificación, cuya estructura se puede ver en la figura 3.3. y se llama también elementos. Los archivos de este tipo tienen una extensión dfx.. Se cuenta con un archivo auxiliar que contiene información referente a los procesos compuestos creados, que en realidad se convierten también en diagramas, cuya estructura también se puede ver en la figura 3.3. y se llama Diagramas donde los archivos generados tienen una extensión dig.. 31 •. Sin que se pretenda por ello hacer necesario el uso de un enfoque jerárquico como el que señala [Date 86) en el sistema de bases de datos.. 32.

(40) Capítulo 3. Diseño del DFDX. ELEMENTOS VJSIBLES EN Dl/\GRAMA. ELEMENTOS.. BORRAR. El .EMENTOS)v!OY ER. ~ - - - --- -···----. Figura 3.2. Operaciones básicas de edición.. El otro archivo auxiliar contiene los datos de los flujos heredados de un proceso padre sea p , a su proceso hijo p.hijo, en realidad este tipo de procesos son llamados. procesos compuestos que se convierten también en diagramas cuando se baja en un nivel sobre la construcción de una especificación. Estos archivos contienen infonnación acerca de qué procesos heredan sus entradas y salidas y conservan la referencia acerca de quién son los procesos hijos y a quiénes se heredan tales flujos de datos de entrada-salida. Su estructura y tipo de archivo se denominan.flujos heredados.. En la Figura 3.3 se muestra la base de datos y sus relaciones, donde se dice que un. diagrama tiene o está constituido por 1 ó más elementos y puede tener O, 1 ó más flujos heredados . La Base de Datos es generada a partir de la construcción de una especificación con DFDX. La extensión y tipo de cada archivo corresponde a la estructura definida en el programa de aplicación.. 33.

(41) Capítulo 3. Diseño del DFDX. •. Diagramas. Elementos. nivel. m1m __diagrama nomb int..__proceso nomb_e:..:l_proceso. num_diagrama c:oord xl coord_. YI coord x2 coord_y2 contwl tipo_elemento nombre exter nombre ínter. Flujos Heredados num_díagrama num ___ flow _original. tipo de Esl'ructura : Elementos,. nomb__proc. Diagramas y· Flujos_hcredados. Jfo1v _orígínal nurn _diag_de_pro e_co pía Oow _copia direccíon_de_ flujo. Fig. 3.3 BASE DE DATOS.. 3.4.2 LA IDENTIFICACION DE PROGRAMAS.- La identificación de programas necesita de la especificación de requerimientos del sistema. Por tanto, para ilustrar mejor al lector acerca de los programas que se tuvieron que implementar, se muestran en las figuras 3.4 y 3.5, para fines ilustrativos, los primeros dos diagramas de especificación del sistema que se ha desarrollado. Estos sugieren programas en los procesos compuestos. En la Fig. 3.4 se encuentra el proceso HERRAMIENTA DE EDICION, que sugiere ser el sistema a desarrollar en su nivel más alto de abstracción, esto es, el diagrama de contexto, debiendo recibir un mensaje de entrada(MENSAJEi) del USUARIO para, después del proceso, ofrecerle una respuesta (MENSAJEo ).. 34.

(42) Capítulo 3. Diseño del DFDX. el nivel O y diagrama O (de contexto) de la. En la figura 3.4 se muestra. especificación de la herramienta, construida "manualmente" con sus propios elementos.. HERRAMIENTA USUAR IO. 1----~. l lSUi \RIO. DE EDICION. ~i'. 'i<'N. Fig 3.4.- Diagrama de Contexto (nivel O).. M .;;Jc \1ENU. .\.; ... MENU. ..-~ ~\ o-~~ :\1sJl_ HF.P..R ..;\1lFNT,\~. --o------. A1.. .. t LKRAM! E NTAS. \\E~SAJFn. PALET :\ DE H E RRAMID/Ti\S. Ac1..· Plí.'.!\RRON. Valores Global<' ,. DATOS GRALES. Fig 3.5.- Este es el diagrama 1 (5 procesos de transfonnación.). En la Fig. 3.5, se sugiere que cualquiera que sea el mensaje del usuario MENSAJEi, se necesita un programa SELECCION DE OPCION, que analice la petición y envíe un. 35.

(43) Capítulo 3. Diseño del DFDX. mensaje apropiado (Msje_MENU, Msje_HERRAMIENTAS o Msje_PIZAZRRON) a uno de los tres procesos-programas sugeridos (TRABAJO DE MENU, PALETA DE HERRAMIENTAS o PIZARRON DE EDICION) respectivamente. El proceso ejecutado deberá corresponder con un mensaje apropiado (Acc_MENU, Acc_HERRAMIENTAS o Acc_PIZARRON) que debe ser sometido a un proceso de EVALUACION DE MENSAJE, que determinará y ejecutará la acción correspondiente y determinará también el mensaje de salida MENSAJEo que será enviado al usuario en señal de respuesta. De esta forma el usuario siempre observa una reacción a cada una de las acciones que realiza durante la construcción de la especificación. El proceso EVALUACION DE MENSAJE detecta el caso en que se trate del arranque. del. sistema,. entonces. envía. un. mensaje. de. 1mc10. al. proceso. VALORES_DE_INICIO, que inicializa valores por omisión y los almacena en memoria. Es importante señalar que esta identificación de programas es a un nivel de abstracción todavía muy alto para su codificación. Sin embargo se nota ya como el DFDX invita al usuario a bajar, de manera metódica y paso a paso su nivel de abstracción. Así se ha tratado de hacer ver un proceso como un programa y a los flujos de entrada/salida de información como sus parámetros. Para más información véase Anexo A.. 3.4.2.1 EL COMPORTAMIENTO DINAMICO DEL SISTEMA.- Debido a que el objetivo de este trabajo no es detallar las respuestas funcionales del sistema, se describen las partes de la interfase. En la figura 3.6 se aprecia la pantalla inicial de la interfase, la cual se divide en 3 áreas de recepción de eventos, tal como se ha descrito a nivel general en la figura 3.5. El área de recepción TRABAJO DE MENU se encuentra en la parte superior de la pantalla inicial de la interfase y cuyas opciones son Archivo, Editar, Herramientas, Nivel, Verificar y Ayuda. El área de recepción PALETA DE HERRAMIENTAS, está en la parte. izquierda de la pantalla inicial y sus opciones son botones gráficos representados con el elemento gráfico que producirán en caso de ser seleccionados, éstos se encuentran colocados en orden vertical descendente; Control, Flujo, Entidad Externa, Proceso, Almacén, Flujo Necesario, Flujo Deseable, Agrupador AND, Agrupador OR, Etiquetas y Dirección de Flujos. Por último, el área de recepción PIZARRON DE EDICION es el resto. 36.