Editor de Diagrama de Fluxo de Dados Extendido

Vista previa del material en texto

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. 
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. 
CONTENIDO 
Capítulo 1 
1.1 
1.2 
1.3 
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 
Introducción 
Antecedentes .......................................................................................... 1 
Herramientas CASE ................................................................................ 5 
El problema ............................................................................................ 6 
El Objetivo .............................................................................................. 6 
La Estructura de la Te sis ........................................................................ 7 
Fundamentos Básicos del DFD y DFDX 
Introducción ........................................................................................... 9 
Los Diagramas de Flujo de Datos ........................................................... 1 O 
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 
3.2 Acerca de las Interfases de Usuario ....................................................... 29 
3.3 La Especificación de Requerimientos del DFDX ................................... 29 
3.4 Diseño ..................................................................................................... 30 
3.4.1 Arquitectura ............................................................................................ 31 
3.4.1.1 Los Conjuntos de Información ............................................................... 31 
3.4.1.1.1 Datos de Entrada ..................................................................................... 31 
3 .4.1.1.2 Datos de Salida ....................................................................................... 31 
3.4.1.1.3 Bases de Datos ........................................................................................ 31 
3.4.1.1.3.1 Diseño Conceptual de La Base De Datos ............................................... 32 
3.4.1.1.3.2 Diseño Lógico De La Base De Datos .................................................... 32 
3.4.2 La Identificación de Programas .............................................................. 34 
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 ......................................................................... 3 7 
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 
Anexo B Las Operaciones de Reestructuración 
Conjunto de Operaciones de Reestructuración ....................................... 89 
2 Especificación de Operadores de Reestructuración ................................ 90 
2.1 El Operador de Agrupación .................................................................... 91 
2.2 El operador de Expansión ....................................................................... 92 
2.3 El Operador de División ......................................................................... 93 
2.4 El operador de Fusión .............................................................................95 
2.5 El Operador de Transferencia ................................................................. 96 
LISTA DE FIGURAS 
1.1 El Ciclo de Vida del Software ................................................................ 2 
1.2 Usuarios de Especificaciones ................................................................. 4 
2.1 Los componentes Gráficos del DFD ....................................................... 9 
2.2 Una Entidad Externa o Terminador ........................................................ 11 
2.3 Un proceso .............................................................................................. 11 
2.4 Los Flujos de Datos ................................................................................ 11 
2.5 Un almacén de datos ............................................................................... 12 
2.6 Interrelación de los elementos del DFD ................................................. 12 
2.7 Ejemplo del Uso Del DFD ...................................................................... 13 
2.8 Un DFD nivelado .................................................................................... 17 
2.9 Elementos de eXtensión del DFD ........................................................... 20 
3 .1 Simple interacción del usuario con el sistema ....................................... 3 O 
3.2 Operaciones básicas de edición ............................................................. 33 
3.3 Base de Datos ......................................................................................... 34 
3.4 Diagrama de Contexto (nivel O) ............................................................. 35 
3.5 Este es el diagrama 1 (5 procesos de transformación.) ........................... 35 
3 .6 Prototipo de Interfase principal, para la herramienta de construcción 
de especificaciones a través del DFD Extendido .................................... 3 7 
3.7 Elementos del sistema o Diagrama de Estructura .................................. 38 
3.8 Archivos necesarios para el sistema ....................................................... 39 
3.9 Flujos permitidos .................................................................................... 41 
4.1 Una Máquina de Estado Finito, El Interruptor de una Lámpara ............. 46 
4.2 Diagrama de transición para un Autómata Finito ................................... 47 
4.3 Especificación para un Analizador Léxico en Pascal ............................. 49 
4.4 Un ejemplo de una RP ............................................................................ 54 
4.5 Modelando un programa con una RP ..................................................... 55 
4.6 RP antes y después de disparo ................................................................ 56 
4.7 RP, ¿posible evolución? ........................................................................ 56 
4.8 RP para modelar actividades independientes ......................................... 57 
5.1 Interfase Inicial Del Sistema ................................................................... 64 
5 .2 Interfase Inicial, algunas opciones .......................................................... 64 
iii 
5.3 Un Editor Amigable ................................................................................ 66 
5.4 Asignando Datos a Elementos u Objetos ................................................ 68 
5.5 Guardando Especificación ...................................................................... 69 
5.6 Asignando Nombre a Especificación ...................................................... 70 
5.7 Una especificación Recuperada .............................................................. 70 
5.8 Selección de proceso para bajar un nivel de abstracción ........................ 72 
5.9 Edición en varios niveles de varios diagramas, flujos heredados ........... 73 
5.1 O El Proceso de Verificación, disponible en cualquier diagrama .............. 74 
5 .11 El Proceso de Verificación, después de una modificación errónea ........ 7 5 
A-O Diagrama de Contexto de la Especificación( Nivel O) ........................... 80 
A-1 HERRAMIENTA DE EDICION(Nivel 1) ............................................. 81 
A-2 TRABAJO DE MENU(Nivel 1-1) ......................................................... 82 
A-3 PALETA DE HERRAMIENTAS(Nivel 1-2) ......................................... 83 
A-4 El proceso PIZARRON DE EDICION(Nivel 1-3) ................................. 84 
A-5 El trabajo de archivos en MENU_ARCHIVO(Nivel 1-1-1) ................... 85 
A-6 El proceso de Crear un nuevo Archivo de la sección Arhivo, 
del área de menú. ARCH_ NUEVO Nivel ( 1-1-1-1) ........................... 85 
A-7 El proceso de crear un nuevo elemento (Proceso) de la especificación 
MBH _PROCESO (nivel 1-2-3 ) ............................................................. 86 
A-8 Proceso del evento mouse_down del ratón. MOUSE_DOWN, 
ejecutado sobre el PIZARRON DE EDICION (Nivel 1-3-1) ................. 87 
B-1 La operación de Agrupar ........................................................................ 91 
B-2 La operación de Expansión ..................................................................... 92 
B-3 La operación de División ........................................................................ 94 
B-4 La operación de Fusión ........................................................................... 95 
B-5 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 
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 
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 
incluyela 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. 
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 
Confiable-. 
Eficiente.-
puedan ser hechas sin grandes costos. 
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. 
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. 
1 
1 
' 
¡ 
r-Í)c11;;·¡-ció-n cl~---._..l __ 
I Requerimientos I 
l --·-·····--·--·- ········--··-·-·····---.J .1 ,, 
Disefio del S0llware 
y del Sistema 1---~ 
' l ,. 
lrnpleme11tación y 
Pn11::bas de Unidad 1----, 
'l 
'r 
Pruebas dd Si, t<:ma 
y de I ntcgra~ión -~ 
,, 
Operación y 
Ma11tc11imiento 
r! 
11 
i 
¡.__ ____________________ __. 
FIGURA 1.1 El Ciclo de Vida del Software[Sommerville 94]. 
2 
. 
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 
Capítulo J 
)~~--·~J:~--· 
Cliente Especi ii cador 
Introducción 
¿, Qué hace este 
programa? 
Ch ente 
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 
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 losdesarrolladores en tales métodos. 
5 
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 
PaintBrush1-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. 
1
-
1 Es un programa de edición gráfica que corre bajo Windows de Microsoft. 
6 
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és1-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. 
1
-
2 Se tomará como correcta a una especificación cuando ésta esté apegada a las reglas de construcción del 
DFDX 
7 
Capítulo 1 Introducción 
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 
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 
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 
Capítulo 2 
Etiqueta 
Fundamentos Básicos del DFD y DFDX 
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 EntidadExterna 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 
1 
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 
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 
! 
: .......... ~""111111m1 ...................................... 1111111!1 ...... 1111111!1, .. 111!!~~~., .. -!I 
--,·-·-·------
Figura 2.4 Los Flujos de Datos. 
11 
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]. 
Etiqueta Un Almacén de Datos es un depósito de datos o de 
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. 
datos datos datos datos 
1 
entidad 1 IB2 5 ,_____. roceso 1 ----. proceso ~ _____. proceso 3 ~ entidad2 j 
• 
datos 3 datos 4 
• 
Almacén 
de datos 
Figura 2.6 Interrelación de los elementos del DFD [Molina 94]. 
12 
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é? 
DATOS 
MENSAJE.ERROR 
TIPO __ TRi\MITE 
EDAD 
CREDENClAL 
PAIJRON 
TOMA .DE __ 
FOTOGRAFI . .\ 
flGURA 2.7. Ejemplo del Uso Del DFD. 
13 
DATOS 
ACTUALIZADOS 
ORDEN 
o~ ~o ro 
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 
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 
Capílulo 2 
FAND o(_) 
FoR; (_) 
FoR O (_) 
AAND¡ (_) 
AAND o(_) 
A OR¡ (_) 
AoR 0 (_) 
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 
Fundamentos Básicos del DFD y DFDX 
Es una función AND de Almacén de entrada 
Es una función AND de Almacén de salida 
Es unafunción OR de Almacén de entrada 
Es una función OR de Almacén de salida 
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 E x.P u x.T} 
FoRº(e) = { f E x.F¡ < e, f> E x.C, donde :le E x.P u x.T} 
AAND¡ (e) = { an E x,FI < ao,e > E x.C, donde :le E x.P u x.T A a0 < a11+1 } 
AA·mº (e)= { a11 E x.FI < e, a0 > E x.C, donde :le E x.P u x.T A a .. < a11+1 } 
AoR¡ (e) = { a E x.F¡ < a,e > E x.C, donde :le E x.P u x.T} 
AoRº (e)= { a E x.F¡ < e,a > E x.C, donde :le E 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) 
A O (E) = U e EE A O (e) 
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 bajonivel de los diagramas se encuentran los 
16 
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 
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 1 O) en un mismo diagrama y evitar cruces en los flujos de datos. 
18 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
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 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
Los 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 
1 
' 
l 
l 
. 
o 
o 
D 
Es util12a<lú sobre los flujos de entrada ,·.'o saltda , 
Jndica qu,, los datos so11 necesarios o r,-qu,-ri<los 
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 . 
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 
-·,- .... ---- ~= 
I• 
\ .................................................................................... ... 
:::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 
l. Para los flujos de datos de salida o entrada de un proceso. 
p_) 
1.1 Si el flujo de datos tiene un círculo, es deseable que se tenga esta 
salida o entrada de datos. 
20 
IIILIOffQ 
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 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
3. 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 conectorde 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 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
3 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 E dc.P) [(FANO¡ (p) u FoR¡(p)-:t- 0) A ( FANoº(p) u FoRº (p)-:t- 0)] 
5 Cada terminador debe tener conectado al menos un flujo 
(Vt E dc.T) [(FANO¡ (t) u FoR¡(t)) u ( FANoº(t) u FoRº (t)) -:f. 0] 
6 Un flujo no debe ser emisor y receptor del mismo proceso 
(Vp E dc.P) [(FANO¡ (p) u FoR\p)) n ( FANoº(p) u FoRº (p)-:t- 0)] 
7 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 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
2 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.FAND1 u x. F ANoº 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) A 
(FANo0 (p) uFoR0(p))u (AANo0 (p) uAoRº(p))-:t0)] 
5 En cada proceso, al menos una de las entradas y salidas debe ser un flujo. 
(Vp E x.P) [(FANO¡ (p) u FoR¡(p)) u (FANoº (p) u FoRº(p)) * 0)] 
6 Un flujo no debe ser emisor y receptor del mismo proceso. 
(Vp E x.P) [(FANO¡ (p) u FoR\p)) n (F ANoº (p) u FoRº(p)) = 0)] 
7 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 
Capítulo 2 Fundamentos Básicos del DFD y DFDX 
8 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 
((FANo0(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 
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 
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 operacionesde reestructuración debe conocer las necesidades de 
reestructuración desde el principio. 
27 
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 
Capítulo 3 Diseño del DFDX 
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 
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 
Reglas Formales 
de Construcción 
Programas de 
Cóm puto(editor) 
t Ju. j_ J ~1mp1e mreracc1on ae1 usuario con et sís\emii. · 
30 
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 
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 DFDs3-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_ BORRAR, ELEMENTOS_ MOVER, 
ELEMENTOS MODIFICAR. Puede alguno de esos 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 relacionadosentre 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. 
3•1 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 
Capítulo 3 Diseño del DFDX 
ELEMENTOS VJSIBLES EN Dl/\GRAMA 
ELEMENTOS .. BORRAR El .EMENTOS)v!OYER 
~-------···----
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 
Capítulo 3 
• 
Elementos 
num_ diagrama 
c:oord xl 
coord_ .. YI 
coord x2 
coord _y2 
contwl 
tipo_ elemento 
nombre exter 
nombre ínter 
tipo de Esl'ructura : Elementos, 
Diagramas y· 
Flujos_hcredados 
Flujos Heredados 
num_díagrama 
num ___ flow _original 
nomb__proc 
Jfo1v_orígínal 
Diseño del DFDX 
Diagramas 
nivel 
m1m __ diagrama 
nomb int .. __ proceso 
nomb_ e:..:l_proceso 
n u rn _ d iag_ 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 
Capítulo 3 Diseño del DFDX 
En la figura 3 .4 se muestra el nivel O y diagrama O ( de contexto) de la 
especificación de la herramienta, construida "manualmente" con sus propios elementos. 
USUARIO 1----~ 
HERRAMIENTA 
DE EDICION 
Valores 
Global<' , 
DATOS 
GRALES 
~i' 'i<'N 
Fig 3.4.- Diagrama de Contexto (nivel O). 
M .;;Jc \1ENU .\.; ... MENU 
~o-~~ \..-~ 
:\1sJl_ A1.. .. 
HF.P..R . .;\1lFNT,\~ t LKRAM! E NTAS 
PALET :\ DE --o------ HERRAMID/Ti\S 
Ac1..· Plí.'.!\RRON 
Fig 3.5.- Este es el diagrama 1 (5 procesos de transfonnación.) 
l lSUi \RIO 
\\E~SAJFn 
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 
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 
Capítulo 3 Diseño del DFDX 
de la pantalla y es donde se capturan los eventos del ratón que, combinados con opciones 
de las otras dos áreas de recepción de eventos, determinan el comportamiento gráfico de 
los elementos en esta área. El sistema trabaja de manera muy similar a los editores gráficos 
usados en ambiente Windows de Microsoft, de tal manera que al usuario le resulte familiar 
su uso. Siendo transparentes al usuario la aplicación de las reglas de construcción del 
DFDX. 
Archivo ~d itor Yer tferramien tas Nivel V erifica r A~uda 
Figura 3 .6.- Pantalla Inicial de la Interfase de la herramienta de construcción 
de especificaciones a través del DFDX. 
3.4.3 DIAGRAMA DE ESTRUCTURA.- La estructura del sistema, en su división de 
módulos principales se constituye de formularios3-2 un módulo principal 
MODDFDX.BAS y un módulo de variables globales VARTOTAL.GBL (Fig 3.7). Es 
importante señalar que este diagrama toma en cuenta la filosofía de alcance de variables de 
Visual Basic (VB), así como el agrupamiento de rutinas relacionadas a determinadas 
secciones de la interfase. 
3-2 El concepto de "formulario", es propio de Visual Basic y se refiere a un tipo de control que simula un 
lienzo o pizarrón en el que se puede prediseñar de una manera sencilla una interfase gráfica agregando 
botones, menus pull-down, imagenes y otro tipo de controles, más información en [Visual Basic 93]. 
37 
Capítulo 3 
1 
1 
1 
'vlodulo de variables y estructuras globaks 
MODDFDX.BAS 
Módulo de ,manque y rutinas compartidas 
por formularios. Su existencia se determina 
debido a la necesidad de los fonnularios de 
compartir información y rutinas comunes. 
PIZARRA.FRM 
Que contiene lainterfase 
principal.así como todas 
las rutinas que sus 
element(IS necesitan. 
U:CTURA.FRM 
Que contiene la interfase 
de captura de datos 
de elementos de la 
cs1x:cificación previa 
selección. 
Diseño del DFDX 
MSG_ERROR.FRM 
Que contiene la interfase 
que despliega los resu ltados 
del proceso de verificación 
de: la información 
1 
¡, 
Figura 3.7.- Elementos del sistema o Diagrama de Estructura. 
El sistema arranca conociendo todas las variables del tipo global y estructuras de datos. 
Define en el modo de diseño del entorno de VB a la función mainO, como su función de 
arranque3-3 . Después es llamado el módulo de la interfase principal pizarra (ver fig. 3.7). 
El módulo de msg_ error es llamado después de que se activa el proceso de verificación 
dentro de el módulo pizarra. El módulo lectura es llamado cuando se asigna un nombre y/o 
una función o número de prioridad de entrada o salida a un elemento de la especificación . 
Este módulo también es llamado desde el módulo pizarra. El total de los módulos se 
encuentra diluido entre los archivos de extensión frm,bas y gbl. En la figura 3.8 se 
muestran los archivos necesarios para la generación del archivo ejecutable que deberá 
trabajar sobre un entorno Windows de Microsoft. 
3
-
3 Sería lógico pensar que la función de arranque siempre será la función main(), sin embargo VB permite 
predefinir la rutina con la que se inicia. Ver opción project del entrono de diseño de VB [Visual Basic 93]. 
38 
Capítulo 3 
PROYD FD\'..\l .\h. 
\·111UDI DX IJ..\S 
PI/ i\Rf{AI RM 
IFCI 111{1\ 1 l{M 
\l's(, 1 RfU 1(\1 
V \ R ll i 1 :\ L 1 , l l l 
C.\11)1:\1 Oli VB\ 
Diseño del DFDX 
- IHD\'..E\E 
Figura 3.8.- Archivos necesarios para el sistema. 
3.4.4 DETALLE DE MODULOS.- A continuación se describen los módulos antes 
mencionados. Se detallan algunas características como nombre del archivo, módulo, 
argumentos, objetivo y en caso necesario submódulos de interés y su algoritmo general. 
ARCHIVO: 
MODULO: 
ARGUMENTOS: 
OBJETIVO: 
SUBMODULOS 
IMPORTANTES: 
ALGORITMO: 
MODDFDX.bas 
MODDFDX 
s/a 
Es el módulo general, donde se encuentra la rutina de arranque 
sub mainO, también se inicializa el sistema y todas las variables 
globales. Contiene rutinas compartidas por los formularios y 
algunas que sincronizan a tales formularios . 
sub default(), que inicializa los valores de las variables globales del 
sistema. 
1.-Define un arreglo dinámico de formularios del tipo de la interfase 
principal. 
39 
Capítulo 3 
ARCHIVO: 
MODULO: 
ARGUMENTOS: 
OBJETIVO: 
SUBMODULOS 
IMPORTANTES: 
Diseño del DFDX 
2.-Busca y ubica a los objetos de la interfase principal 
3 .-Inicializa todos los identificadores de uso global 
4.-Carga el formulario principal pizarra, listo para su interacción con 
el usuario. 
PIZARRA.frm 
PIZARRA 
n, que se refiere al número de elemento del arreglo de interfases de 
tipo formulario. Esto es el número de diagrama, que es distinto al 
nivel de abstracción, soportado en una estructura tipo árbol. De tal 
forma que el usuario pueda trabajar en diferentes diagramas de igual 
o diferente nivel. 
Permitir al usuario la construcción de especificaciones formales 
usando el DFDX. Es importante señalar que contiene el trabajo de 
edición, es decir, el control de tales rutinas. Está compuesto por las 
rutinas de las tres áreas de la interfase principal definida en la fig. 3.5 
De los relacionados a la sección de herramientas, que son: un arreglo 
de objetos-imagen, las rutinas que capturan los eventos del ratón: 
click y doble click:paletatool_clicky paletatool double_click, donde 
la primera activa el objeto-imagen apropiado a la selección del 
usuario y la segunda crea el objeto seleccionado en el área de 
dibujo, asignando a tal objeto un nombre por omisión. De los 
relacionados a la sección de menús pull-down, la rutina 
mnu archivo puede cargar en memoria una especificación 
previamente creada, guardar en disco la actual, crear una nueva, 
renombrar la actual o imprimir una especificación. La rutina 
mnu _ Verfificar determina las relaciones de los elementos que 
conforman la especificación y en base a las reglas de construcción 
40 
Capítulo 3 Diseño del DFDX 
de los DFDXs emite mensaJes de error o de aceptación de la 
especificación. Además de las reglas de construcción se toma en 
cuenta a una tabla de validez de los flujos de información obtenida 
también de las reglas de construcción y que describe las 
siguientes relaciones : Retomando la nomeclatura de las secciones 
2.2.3 y 2.2.4; m.C= m.dc.C um.X.C donde las relaciones (m.T x 
m.A) u ( m.A x m. T) f! m. C . De las relacionadas a las sección 
de edición gráfica. Las rutinas que capturan los eventos básicos del 
ratón: pizarra_ MouseDown, pizarra MouseMove y pizarra - -
MouseUp. Donde la primera está enfocada a las acciones que ocurren 
cuando el usuario oprime el botón o los botones del ratón en 
un estado determinado del sistema. Sus acciones son totalmente 
gráficas. 
~ D D 
--
D ]) --' 
D Si Si Si [ ¡¡~fo [ fa.fo [ fa,fü 
D Si Si 1 S1 Si t: fa.fo [ fa.fo e fü,fo e tafo t: fü,fo 
-- Si Si s 1 
-- t: fa.fo [ fa,fo f. fü,fo 
D Si Si Si Si Si f. fü,fo 1: fü,fo f. fü,fo f. fü,fo 1: fafo 
]) Si Si Si Si Si 1: 1a10 L fr~fo i; fa.fo i: fa.fo 1: fr~fo 
Figura 3.9.- Flujos permitidos. 
41 
Capítulo 3 
ALGORITMO: 
ARCHIVO: 
MODULO: 
ARGUMENTOS: 
OBJETIVO: 
SUBMODULOS 
IMPORTANTES: 
ALGORITMO: 
Diseño del DFDX 
La segunda se refiere a las acciones que se toman cuando al usuario 
está moviendo el ratón sobre el área del PIZARRON DE EDICION, 
sin importar que esté o no presionado el botón del ratón. La tercera es 
el último evento de los 3 ( que se accionan de manera consecutiva) y 
actúa de acuerdo a la posición en la pantalla donde se deja de 
presionar el botón del ratón y en función de la actividad de edición 
que se esté realizando. 
1.- Repite 
1.1.- Captura de Eventos 
2.- Hasta que hay Evento 
3.- Mientras Evento es diferente de selección de 
menu _ Archivo(Salir) hacer 
3 .1. -Tomar acciones correspondientes 
4.- Fín Mientras 
5.- Fín Modulo. 
LECTURA.frm 
LECTURA 
s/a 
Permitir al usuario la captura de información (nombre y función) de 
un objeto previamente seleccionado y actualizar tales cambios. 
1.-loop que espera por un evento 
2.-Si el evento es aceptar cambios entonces 
2.1.- asignar nuevos datos a los elementos 
2.2.- regresar a diagrama anterior 
3.-Fin Si 
42 
Capítulo 3 
ARCHIVO: 
MODULO: 
ARGUMENTOS: 
OBJETIVO: 
SUBMODULOS 
IMPORTANTES: 
ALGORITMO: 
4.-Si el evento es cancelar entonces 
4.1.- regresar a diagrama anterior 
5.- Fin si 
6.- Si el evento es Sobre otro diagrama entonces 
6.1.-Ubicar diagrama y regresar a el. 
7.-Fin si 
8.- Fin 
msge _ err.frm 
msge_err 
s/a 
Diseño del DFDX 
Desplegar errores de construcción de especificaciones hechas con el 
sistema en la sección de edición. Tales errores son identificados en el 
proceso de verificación y guardados , en caso de existir, en un arreglo 
de tamaño variable de mensajes de error. 
1.- Si NUMERRORES=O entonces 
1.1.- Arreglo de errores con un elemento que contiene 
la cadena de datos: "VERIFICACION EXITOSA" 
Si NO 
1.2.-
2.- Fín Si 
Llenar el objeto editor-de-texto que se encuentra en el 
formulario "lectura" con el Arreglo ARR_ERRORES 
(NUMERRORES) , llenado previamente en el proceso 
de verificación. 
43 
Capítulo 4 El DFDX dentro de los Métodos Formales Gráficos 
CAPITULO 4 
EL DFDX DENTRO DE LOS METODOS FORMALES 
GRAFICOS 
4.1 INTRODUCCJON 
En este capítulo se pretende ubicar al DFDX dentro del contexto de los Métodos 
Gráficos de Especificación Formal (MGEF). Se presentan dos de los más conocidos dentro 
de la especificación de software de diferentes aplicaciones. 
La primera Técnica o Método Gráfico de Especificación Formal (MGEF) que se 
muestra son las Máquinas de Estado Finito (MEF) o Autómatas de Estado Finito (AEF)