Diagrama de flujo de datos extendido

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

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.

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 los

desarrolladores en tales métodos.

5


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


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


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


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


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

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


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


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


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


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


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 bajo nivel de los diagramas se encuentran los

16


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


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


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


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


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


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 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


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


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


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


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 operaciones de 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


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


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


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


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 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.

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


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


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


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


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 la interfase 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


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) ya

sea Deterministas o No-Deterministas, cuyas aplicaciones, como los compiladores, son

ampliamente conocidas dentro del área de sistemas.

La segunda técnica son las Redes De Petri (RP), que son identificadas como

operacionales y formales, mientras en sus inicios fueron usadas para modelar sistemas de

hardware, en los años recientes han sido aplicadas incrementalmente en el modelado de

software.

Sobre ambos MGEFs se describen cuales son sus elementos, ventajas y desventajas,

cómo se utilizan, donde se aplican y quiénes son sus usuarios.

Por último se presenta una tabla comparativa basada en algunos conceptos

propuestos por [Davis 88]. Con el conocimiento de dos de los principales MGEF se

pretende compararles con el DFDX, debido a que una comparación del DFDX con los

Métodos Sintácticos de Especificación Formal tradicionales (Lógica de Primer

Orden(LPO), Especificaciones Algebráicas), resultaría ventajosa para el DFDX, esto

principalmente en lo que se refiere a lo popular de su uso ya que se ha mostrado en el

capítulo dos, que sus elementos gráficos de construcción están soportados formalmente por

lógica y teoría de conjuntos.

44


4.2 LAS MAQUINAS DE ESTADOS y AUTOMATAS FINITOS

Una Máquina de Estado Finito es un modelo abstracto de una máquina con una

memoria interna primitiva [Johnsonbaugh 93].

Al igual que algunos de los MGEF (como Redes de Petri, DFDX), las Máquinas de Estado

Finito reciben datos de entrada en algún estado de procesamiento de la información y

producen información de salida.

Cuando se describen sistemas de información, se pone especial énfasis en la

organización de los datos y sus operaciones relacionadas, sin embargo, se debe poner

también atención en el aspecto de control de tales operaciones. Esto es, ¿se deben

especificar las condiciones en orden para la ejecución de un proceso P ?, dadas sus entradas

{i1 ,iz , ... in} , ¿es necesario que todos los datos de entrada estén disponibles para activar el

proceso?, ¿bastan sólo alguno(s) datos de entrada para activar tal proceso?. Estas preguntas

no se pueden contestar mediante el uso en las especificaciones del DFD clásico propuesto

por [Demarco 78], sin embargo, es posible contestarlas mediante el uso del DFDX, así

como también es posible contestarlas a través del uso de las MEF y las Redes de Petri (RP).

Es precisamente la certidumbre de saber que se contestan las preguntas arriba planteadas,

una de las principales bondades de los métodos formales. Por ejemplo, uno podría ligar a

los estados para su ejecución, requerimientos como:

• Ningún proceso debe escribir en un buffer lleno o leer de un buffer vacío.

• Ningún proceso debe accesar un buffer mientras otro proceso está escribiendo en

él.

• El lector de un buffer debe tener en cuenta una prioridad más alta del que escribe

en él.

• El símbolo que se espera leer a continuación es cualquiera menos "="

Las MEF son simples, ampliamente conocidas y son un modelo muy importante para la

descripción de aspectos de control[Guezzi 91].

45


4.2.1 ELEMENTOS DE LAS MEF y AUTOMATAS FINITOS.- Un Autómata Finito

(AF), es un tipo especial de MEF, puede ser determinista (AFD) o No-determinista

(AFND), donde No-determinista significa que en un estado se puede dar el caso de tener

más de una transición para el mismo símbolo de entrada [ Aho, Sethi 90].

Se define formalmente un AF como el quinteto (Q, I, 8, qo, F), donde :

Q Es el conjunto finito de estados , donde cada estado se representa por

medio de un círculo, cuya etiqueta le identifica de los demás estados.

Es un conjunto finito de símbolos de entradas/salidas de los estados

(alfabeto).

Es la función de transición que proyecta los pares estado-símbolo

hacia el conjunto de estados. Esto es:

8(q,a) es un estado por cada estado_q-símbolo_de_entrada_a

Donde estos tres elementos son suficientes para modelar algún tipo de sistemas

como el siguiente:

Sea una lámpara donde:

Q={ encendido, apagado}

¿={presionar}

Q x ¿ ~ Q={ 8(encendido, presionar), 8(apagado, presionar)}

pres ~

presionar

Figura 4.1 Una Máquina de Estados Finitos, El Interruptor de una Lámpara.

46


En la figura 4.1 , un ejemplo propuesto por [Guezzi 91], donde se describe el

funcionamiento de una lámpara, puede tener dos estados ( encendido o apagado ) y una sola

transición (presionar el interruptor), que hace ír de un estado a otro.

Los elementos restantes de un AF, suelen aplicarse en sistemas de aceptación ( de

cadenas de caracteres por ejemplo) . En tales casos, obliga un estado inicial y uno ó más

estados de aceptación.

Es el estado inicial de Q.

Es el conjunto de los estados Finales.

Ejemplo.- Sea un autómata finito que acepte cadenas pares a's y cadenas pares b's donde :

Q = { qo,q1, q2,q3}

¿ = {a,b}

qo = {qo}

F = { qo}

b

Inicial

a

"

Figura 4.2 Diagrama de transición para un Autómata Finito.

47


En la figura 4.2 se puede ver un ejemplo de uso de los estados de inicio y aceptación a

través de un sistema de aceptación de cadenas de caracteres, típico de aplicaciones de

analizadores léxicos.

4.2.2 AUTOMATAS FINITOS DETERMINISTAS Y NO-DETERMINISTAS.- Un

AFD es un caso especial de AFND.

En unAFD:

1.- No hay estados con transiciones E

2.- Para cada estado q , hay una arista o flecha saliendo con c/u de los símbolos

definidos en el alfabeto y también una arista entrando con c/u de tales

símbolos.

Pueden un AFD y un AFND aceptar un mismo Lenguaje Regular, la diferencia puede ser

una cuestión de espacio, pues un AFND puede ser representado por menos estados. Existe

también un algoritmo de conversión de AFND a AFD [Aho, Sethi 90].

4.2.3 LAS APLICACIONES DE LAS MEFs.- Sus aplicaciones invaden el

campo de la Electrónica, especialmente el diseño de circuitos. Un uso muy frecuente de los

AFs es el desarrollo de editores de texto y analizadores léxicos de lenguajes de

programación, la mayoría de los compiladores, al menos en la parte de análisis léxico,

basan su especificación usando modelos de AFs [Hopcroft 93].

En el ejemplo de la figura 4.3 se presenta parte de un analizador léxico en Pascal,

como se sabe, en esta parte de un compilador se captura un orden de secuencia de la

información editada. Esto es, el analizador captura un caracter y lo inserta en la MEF, se

compara el caracter con el caracter de salida/entrada esperado del estado O, si es igual, se

mantiene el sistema en el estado O, sino es igual se compara el caracter con el siguiente

caracter de salida, sino, con el siguiente. Siempre debe haber una salida a la que sea igual.

De tal forma que puede ser que nos haya enviado a un nuevo estado. Se repite la operación

hasta encontrar un estado de aceptación (representado por 2 círculos concéntricos) es

importante señalar que deberían tener un número de estado, sin embargo para los fines del

48


" " ' dígito

1-le-tr_ª __ ~ < > { letra, dígito, "_"] O Identificado

Cualq Cosa

,-<2-)--~o ''-" oPR

:=

< > {"="}

"<" "-"

._____G)l-01----- <=

'' { ''

dígito

">"

<>

< > {"=", ">"}

< > { eol," ' ''}

< > { eol,"} "}

<> dígito

Constante

t• String 1---------~o Error

" } '' -----o Comentario

eof ~-----~o Error

------Oonstante Entera

_"_;_"----0 Punto y Coma

1--"---"----0 Signo /~~al d1g1to

figura 4.3 Especificación para.

Analizador léxico

En Pascal

I-",, --B .::,; . o I <>{" .",dígitos

.. (Rango)

. (Punto)

49


presente ejemplo, tales números carecerían de sentido.

4.2.4 UN EJEMPLO DEL USO DE UNA ESPECIFICACIÓN.- Supóngase que se ha

editado un programa en Pascal y se ha decidido cotejarle léxicamente contra la

especificación planteada en la figura 4.3 .

program uno;

var x:integer;

y:integer

begin

x:=l;

y:=2;

x:=x+y;

end.

Se toma la primera línea del programa, ésta se compone de dos cadenas de

caracteres("program", "uno; "), un caracter de espacio en blanco (~) entre ellas y un

caracter de fin de línea ( eol ).

Tomando en cuenta la primera línea de caracteres "program uno;" y que el control

está en el estado O ( de inicio):

1.- En el estado O, se toma el primer caracter p y se compara con las salidas del estado.

2.- El caracter p E letra donde letra={a,b,c,d, .. . z,A,B,C .. .Z} por tanto se avanza al

estado uno ( 1) y se da avance al siguiente caracter de la línea del programa.

3.- En el estado 1, el siguiente caracter r se compara con las salidas del estado 1

4.- El caracter r E letra y letra~ {letra,digito,"_"}, por tanto se permanece en el

estado 1 y se da avance al siguiente caracter de la línea del programa.

5.- Se repite el paso 4 permaneciendo en el estado 1 hasta que se llega al caracter de

espacio en blanco ~

50


6.- En el estado 1, tomando p y dado que p !l { letra,digito," _"}, se llega al estado

terminador donde se concluye que se ha encontrado un Identificador o una

Palabra Reservada, se vuelve a posicionar en el estado O, pues se ha encontrado un

estado terminador.

7.- En el estado O, con el caracter p se debe permanecer en tal estado pero se continúa

avanzando sobre la línea de caracteres del programa.

8.- Se repiten los pasos del 1 al 4 con los caracteres u,n y o hasta llegar a;

9.- Se repite el paso 6 con(;) en lugar de p , por tanto se posiciona otra vez en el estado

cero (O).

10.- Del estado cero (O) y con ; se avanza hacia un estado terminador; Punto y coma

(;) por tanto, se vuelve a posicionar en el estado O y se da avance al siguiente

caracter de la línea del programa.

11.- Del estado cero (O) y con el caracter de fin-de-línea o eol no hay movimiento en los

estados (se permanece en O).

12.- Se lee el siguiente caracter, que es parte de la siguiente línea de programa, la

siguiente línea var x:integer; . Se repite el mismo procedimiento hasta leer todas

las líneas del archivo. Naturalmente que los estados terminales van a ser variados,

pero la especificación lleva de la mano al programador de un sistema.

Al final del seguimiento del comportamiento del programa, se puede obtener una

secuencia de lo que se ha editado, se pueden también encontrar errores de léxico y el

programador está en posibilidad de señalarlo de acuerdo al compilador desarrollado.

El siguiente paso en el desarrollo de un compilador sería el analizador sintáctico,

donde interviene más bien el uso de una herramienta de especificación formal sintáctica

como lo son las gramáticas regulares.

4.2.5 VENTAJAS DE USO

• Una Especificación con una MEF, no permite ambigüedades, es decir, cada

especificación tiene un solo significado

51


• Es un Modelo Fonnal, debido a sus bases matemáticas.

• Son viables de automatizarse y existen de hecho, editores.

• Tienen un alto grado de intuitividad

4.3 REDES DE PETRI

Las redes de Petri fueron diseñadas principalmente para modelar muchos tipos de

sistemas, especialmente, aquellos que tienen componentes independientes pueden ser

modelados por una red de Petri RP. Estos sistemas pueden ser de muy diferentes tipos,

problemas de hardware, software, sistemas físicos, ... [Chaparro 93].

Las RP fueron desarrolladas por Alan Carl Petri en 1962, quien estableció los

fundamentos para el desarrollo teórico de los conceptos básicos de las RP.

Al igual que los DFDX, las RP tienen transiciones que en DFDX podrían ser el

equivalente de procedimientos o procesos. Tienen condiciones de disparo, que en un

DFDX son el equivalente de los datos y condiciones necesarios para la ejecución de un

proceso determinado.

Su concepción a diferencia de otros Métodos Gráficos de Especificación Fonnal

como los que aquí se estudian, las RP penniten modelar procesos que se comportan de

manera sincronizada y/o están distribuidos.

Al igual que el DFDX, una RP pennite modelar los sistemas de una manera

descendente, es decir , desde un nivel de abstracción alto hasta un nivel de función. Un

Sistema se constituye de un módulo principal y ese módulo a su vez está compuesto de

submódulos que interactúan entre si y que a su vez pueden ser módulos compuestos por

submódulos que interactúan entre si. "Divide y Vencerás", dice el adagio, pero es bien

52


importante guardar las relaciones que tienen los módulos y submódulos entre sí. El DFDX

por ejemplo, mantiene bien definidas tales relaciones:

Del Sistema: m.dc.C u m.x.C

Del D. de Contexto de.e~ [dc.F x (dc.P u dc.T)] u [(dc.P u dc.T) x dc.F]

Del Diagrama x. x.F= x.FANO¡ u x. FANoº u x.FoR¡ u x. FoRº x.A= x.AANO¡ u x. AANo0 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)]

En cambio en las MEF, las relaciones son guardadas en las transformaciones:

8: Q x I~ Q .8 Se desplaza del estado q 1 al estado q2 si y sólo si 8( q l ,i) = q2.

Si deseamos conocer las condiciones y relaciones que guarda un sistema en un

momento dado del tiempo, podríamos llevamos la sorpresa de que en algunos sistemas las

condiciones, acciones y relaciones de un módulo en un sistema pueden ocurrir y/o coincidir

con las de otros módulos, dado que ellos podrían interactuar entre sí, es necesario

sincronizar sus eventos. Las condiciones de un módulo en el tiempo podrían necesitar

como entrada las salidas de otro, el cual podría necesitar, a su vez, más tiempo para generar

sus salidas. Es cuando se piensa en concurrencia y paralelismo.

4.3.1 COMPONENTES DE UNA RP

Una RP básicamente se compone de tres partes:

1.- Un conjunto finito de plazas o lugares.

2.- Un conjunto finito de transiciones

3.- Un conjunto finito de conexiones ya sea de plazas a

transiciones o de transiciones a plazas.

53


Si se trata de plantearla de una manera similar al DFDX, que ya ha sido planteado

en sus elementos iniciales (DFD) de una manera formal con RP por [PhoTin 92], se podría

representar como:

P={pl,p2, ... ,pn}

T={tl,t2, ... ,tm}

e~ {P x T} u {T x P}

donde P es el conjunto de plazas y n> =O

donde Tes el conjunto de transiciones y m> =O

Es el conjunto de relaciones o arcos entre plazas y

transiciones o transiciones y plazas

4.3.2 REPRESENTAC/ON GRAFICA DE UNA RP

Gráficamente las plazas o nodos son representados por círculosÜ y las transiciones

por barras 1 . Una transición puede tener una o más plazas de entrada y salida, esto es, si

una flecha va de una transición a una plaza se dice que la plaza es una plaza de salida de la

transición, si una flecha va de una plaza a una transición se dice que la plaza es una plaza

de entrada de la transición.

Los tokens son representados por pequeños puntos t, que se ubican en el interior de

las plazas. Estos nos permiten marcar una RP, El marcado de una RP consiste en asignar un

entero no-negativo a cada plaza, se representa gráficamente insertando el número no

negativo de tokens en las plazas de una RP.

pl

t3

p4 t2

Figura 4.4 Un ejemplo de una RP.

54


Si cada plaza de entrada para una transición tiene al menos un token , se dice que está

habilitada. Un düparo de una transición habilitada remueve un token de c/u de sus plazas

de entrada y agrega un token a c/u de sus plazas de salida.

En la Figura 4.4, las plazas pl y p2 son plazas de entrada para la transición tl. Las

transiciones tl y t2 están habilitadas, pero t3 no lo está. Si se dispara t1, se obtiene la

figura 4.6(a).

Modelando las RP, se puede notar que las plazas representan condiciones, las

transiciones representan eventos, y la presencia de al menos un token en una plaza

( condición) índica que la condición es satisfecha.

Sea el programa que se encuentra en la parte izquierda de la figura 4.5:

¡\c.j

B=S ~-C=8

C=8

B=A+C 0----4~1

Figura 4.5 Modelando un programa con una RP.

En la figura 4.5 las transiciones representan a las instrucciones y las plazas son las

condiciones bajo las cuales una instrucción puede ser ejecutada. La secuencia de las

instrucciones de la izquierda indica que se deben disparar las transiciones A,B,C. Después

se ejecuta A=A+ 1, donde necesita sólo conocer el valor de A. Después se debe ejecutar

C=B+C, para lo cual debe conocer el valor de B y C, al ser disparada, C obtiene un nuevo

valor. Por último la instrucción B=A+C sólo necesita conocer A y C (no pueden ser los

iniciales puesto que se han ejecutado previamente A=A+ 1 y C=B+C). Es ejecutada; B=l 5.

55


t3 t3

p2 t2

p4 p2

t2 p4

(a) (b)

Figura 4.6 RP antes y después de disparo.

En el caso de la figura 4.6 (b), ninguna transición está habilitada y por tanto no

puede ser disparada, entonces se dice que el modelo es no-determinista en el sentido de que

dado un marcado inicial, no son posibles diferentes evoluciones de la RP.

p I

Figura 4.7 RP, ¿posible evolución?

56


Como se puede apreciar en la figura 4.7, las transacciones t3 y t4 están habilitadas y

pueden disparar en una forma no-determinista, en el sentido que puede ser disparada

cualquiera de las dos transiciones.

La secuencia de disparo de una RP dada con un marcado inicial dado, es una

secuencia u orden de disparos de las transacciones denotada por la cadena <tl,t2, .. tn>

donde tl está habilitada en el marcado inicial de la red, t2 está habilitada en el marcado

obtenido por el disparo de t 1 y así sucesivamente[ Guezzi 91].

En la figura 4.8 la RP se podría interpretar en dos direcciones, consistentes en las

transiciones tl,t3,t5 y t2.t4,t6 respectivamente como dos actividades independientes

corriendo a través de los eventos modelados por sus transiciones. Se podrían interpretar

tales actividades independientes como que las dos actividades comparten un recurso común

en éste caso modelado por la plaza p3. Podrían ser dos programas compartiendo el mismo

CPU o dos estudiantes compartiendo el mismo libro.

pi p2

Figura 4.8 RP para modelar actividades independientes

57


Inicialmente las dos actividades pueden proceder en una forma independiente y

asíncrona y como tl y t2 están habilitadas el disparo de una no previene el disparo de la

otra, entonces decimos que son dos transiciones concurrentes.

Después de que ambas transacciones de la figura 4.8 (tl y t2) han sido disparadas,

ambas actividades o transacciones están habilitadas para ser disparadas pero en exclusión

mutua.

En la figura 4.7 se puede observar que el recurso modelado por p3 está disponible

pero sólo para una de las dos transacciones o actividades tl o t2 , la elección es no

determinista. En éste caso decimos que las dos transiciones están en conflicto.

Suponga que en la figura 4.7 se da la actividad de las transiciones sólo del lado

izquierdo del modelo, es decir, sobre las transiciones tl ,t3,t5 . Si después del estado del

tiempo que se muestra en la figura 4.7., es disparada la transición t3 y el recurso p3 es

liberado de la situación de conflicto, podría ser disparada la transición t4, pero también

podría ser disparada la transición t5, otra vez t4 estaría en posición de disparo, pero podría

ser disparado t 1 otra vez y se entraría en situación de conflicto, donde nada le asegura a la

transición t4 que tendrá alguna vez la ocasión de ser disparada o ejecutada. De tal manera

que esa situación puede repetirse por siempre.

El modelo (RP) no impone alguna política para resolver situaciones de conflicto. En

la terminología de sistemas concurrentes, un proceso que nunca tiene acceso a un recurso

que necesita se dice que sufre de inanición. De tal forma que una secuencia de disparo

<tl,t3,t5> en la figura 4.7 podría dejar en estado de inanición al lado derecho de la figura.

La situación de bloqueo ( dedlock) se dice existe cuando dada una secuencia de

disparos, la RP llega a un estado donde ninguna transición queda habilitada para continuar

58


evolucionando. Por el contrario dado un marcado inicial una RP puede nunca llegar a

bloquearse entonces se dice que es una RP viva.

4.3.3 VENTAJAS

1.- El sistema completo es fácil de entender debido a lo intuitivo del método gráfico,

siempre y cuando se conozcan sus reglas de funcionalidad

2.- El comportamiento del sistema puede ser analizado

3.- Son óptimas para la modelación de sistemas concurrentes y distribuidos.

4.3.4 DESVENTAJAS

1.- Es difícil modelar sistemas donde los mensajes tienen un fuerte sentido semántico.

2.- Su fuerte notación gráfica requiere de que un usuario de este modelador tenga

ciertas cualidades de abstracción que le permitan desarrollar buenos modelos.

4.3.5 CAMPOS DE APL/CACION DE LAS RP

En general las RP pueden verse como un reto intelectual, puede vérseles como un

autómata capaz de aceptar o generar lenguajes formales o, como se ha visto en este

capítulo, como un esquema de representación para describir analizar y sintetizar diferentes

tipos de sistemas.

Aunque no necesariamente deben estar ligadas al campo de la computación, los usos

más importantes de las RP abarcan:

Aplicaciones en tiempo real

59


Sistemas operativos y Compiladores

Bases de Datos Distribuidas y Protocolos de Comunicación

Hardware de Computadoras

Sistemas Electrónicos

Debido a que éstas pueden expresarse también de manera algebraica, han sido

utilizadas también en la especificación formal del DFD propuesto por [Demarco 78], esto

ha sido posible en [Pho Tin 92] donde se toman las transiciones y plazas como procesos y

flujos en DFDs respectivamente.

4.4 COMPARANDO LOS TRES MGEF

Como una forma de conclusión de éste capítulo, que ha pretendido insertar al

DFDX dentro de los MGEF, se usan como referencia algunos conceptos utilizados por

[Davis 88] en su Estudio de Comparación de Técnicas de Especificación, en tal estudio se

calificaba a los métodos de una manera numérica. Aquí se complementa tal comparación

con los métodos formales que se han presentado y un calificativo de bueno, medio y pobre

complementándolo con algunos criterios que ayudan a saber el porque del calificativo

asignado.

60


TABLA COMPARATIVA DE LOS 3 METO DOS FORMALES PRESENTADOS

Criterio Entendible para

cualquier persona

Verificación Automática

Generación de Prototipos

MEF Se requiere de algunas horas para facilitar el entendimiento. Sin

embargo no se requiere estar muy ligado a

aspectos computacionales para su

uso. Bueno

Pueden ser detectados errores de conducta y de su estructura estática, que se refiere a señales transmitidas a través de puertos inapropiados o a señales recibidas pero no

enviadas, pueden ser detectados.

Pobre Si, existen herramientas de edición (TDE Editor de Diagramas de Transiciones[Davis 88])

Buena

Redes de Petri El entender algunos

conceptos muy propios de computación es un

requisito para su uso. Se requiere por tanto un alto nivel de abstracción de

algunas situaciones.

Pobre No existe (al menos no

encontramos) un procesador automático

para realizarlo.

Pobre Si Existen Herramientas de Edición.[Chaparro 93] propone un Editor Gráfico capaz de controlar un modelo de un sistema que funcione bajo Redes de Petri.

Buena

DFDX Requiere muy poco

tiempo de aprendizaje y contienen un alto nivel de intuitividad, a pesar

de algunos elementos de cierta semántica

booleana.

Bueno Es uno de los objetivos

alcanzados por el presente trabajo. El sistema nos permite

verificar la especificación en

cualquier momento de la construcción de la

especificación.

Buena Si, el presente trabajo ha desarrollado una herramienta de edición. Capaz de editar una especificación a varios niveles de abstracción.

Buena Generación de Prueba Ninguna Encontrada Automática de SW

Ninguna Encontrada Ninguna

Pobre Pobre Pobre Aplicaciones Apropiadas Aplicaciones que Aquella parte de Todo tipo de

podrían ser en tiempo cualquier aplicación en aplicaciones que real, sobre todo la cual la sincronía sea manejen procesos y pequeñas, Analizadores crítica para la prioridades. Su uso aún, léxicos en Compiladores especificación de su por obvias razones, no es

conducta externa. muy amplio pero su Sistemas Concurrentes y potencial es bastante Distribuidos. prometedor.

61

Capítulo 5 Pruebas del Sistema

CAPITULO 5

PRUEBAS DEL SISTEMA

5.0 INTRODUCCION

En la figura 1.1 aparece la Etapa de Pruebas del Sistema, que dentro del desarrollo

de sistemas de SW, es una de la etapas más importantes. En general, el objetivo de éstas es

valorar y mejorar la calidad de los productos del trabajo generados durante el desarrollo.

Según [Sommerville 94] , las pruebas pueden sólo demostrar la presencia de

defectos en un programa, es decir, no pueden demostrar que el programa está libre de

errores. Los errores no detectados pueden existir aún después de las más exhaustivas

pruebas. Siguiendo a [Myers 79], se define una prueba exitosa como aquella que revela la

presencia de errores en el software que se está probando. Esto difiere de la noción de prueba

exitosa usada frecuentemente, la cual, no despliega errores, apelando algunas veces a frases

como "el sistema ha superado todas las pruebas" . Si la serie de pruebas para un programa

no detecta errores, esto significa simplemente que las pruebas elegidas no han ejercitado al

sistema de tal forma que los errores sean revelados y en el mejor de los casos puede

significar que se ha implementado un programa excepcional[Sommerville 94].

En este capítulo se muestran y describen pruebas después de haber sido aplicadas un

número variado de veces, en diferentes etapas del proceso de desarrollo del software,

dependiendo de la prueba. Estas pruebas han arrojado errores significativos que han sido

corregidos tantas veces como ha sido necesario. De tal forma que los resultados aquí

presentados son satisfactorios.

Es importante señalar que, por objetivos de la presente tesis y de espacio, no se ha

incluido documentación de algunas fases del sistema desarrollado. Sin embargo se pueden

tomar las reglas de construcción del DFDX como parte de la etapa de especificación de

62


requerimientos de software. El diseño se presenta a un nivel muy básico, sin embargo se

definen los conceptos suficientes para dar al lector una idea general de los alcances del

sistema desarrollado.

Se han utilizado tres tipos de pruebas: Funcionales, de Integración y de Implementación.

Las pruebas Funcionales tienen como fin detectar errores en el análisis y en la

especificación. También se puede probar si el diseño es correcto con respecto a sus dos

niveles; preliminar y detallado, que a su vez están basados en el análisis y definición de

requerimientos del sistema. Estas pruebas están guiadas por los objetivos principales de este

trabajo así como en la estructura de construcción del DFDX, buscan la posibilidad de error

de conceptualización y de especificación, se organizan tomando como guía las diferentes

opciones del sistema final.

Se presentarán y describirán las pruebas funcionales. Las pruebas de Integración son

aquellas que se realizan al interconectar los diferentes subsistemas que constituyen al

sistema en general, como se explicó en el capítulo 3, el sistema consta de 3 módulos

principales, que pueden identificarse claramente como 3 diferentes subsistemas. Las

pruebas de Integración se realizaron de manera paralela a las pruebas Funcionales, pues los

resultados satisfactorios de las pruebas Funcionales nos indican que la interconexión de los

subsistemas también lo ha sido. Las pruebas de Implementación se llevaron a cabo durante

el desarrollo de la codificación de los diferentes módulos.

5.1 CASONUMERO 1

Nombre: Despliegue correcto de los elementos que conforman la interfase.

Objetivo: Verificar que al ser llamado el sistema, se desplieguen correctamente los

elementos que constituyen la interfase, así como que las opciones de menú y de la paleta de

herramientas sean las adecuadas. Que el nombre de la especificación sea el correcto (por

omisión) debido a que se trata del llamado inicial al sistema.

63


• > ...

Ayuda

Figura 5. l Interfase (inicial) del Sistema.

Figura 5. 2 Interfase Inicial, algunas opciones.

64


Descripción de la Prueba: Una vez llamando el sistema, debe ser presentada su interfase

inicial a el usuario. Deben estar disponibles las opciones válidas de acuerdo un estado en el

tiempo de la interacción usuario-interfase.

Criterios de Aceptación: La interfase deberá aparecer con todos sus elementos. Sus

opciones de edición serán inhabilitadas así como algunas herramientas que, debido a las

reglas de construcción del DFDX, deberán estar también inhabilitadas (al menos en el

estado inicial de la sesión) y deberá la interfase aparecer con un nombre por omisión, para

la especificación.

Procedimiento de la Prueba: Para realizar esta prueba, se instaló el sistema en

varias (tres) computadoras personales y se llamó al programa, cotejando las opciones

realmente disponibles al usuario en un estado inicial del sistema.

Resultado de la Prueba: Los resultados fueron satisfactorios. En todos los casos el

sistema se presentó de acuerdo a las expectativas. Es de notarse que no hubo problema

alguno con la nueva versión de Windows (Windows 95 de Microsoft).

Desempeño de la Prueba: La prueba mostró que los requerimientos de una interfase

apropiada al usuario, descritos en el capítulo 1, página 2, fueron cubiertos de manera

satisfactoria.

5.2 CASO NUMERO 2

Nombre: Proceso de edición amigable y familiar al usuario

Objetivo: Corroborar que el proceso de edición por parte del usuario sea mucho más

fácil y confiable que un proceso en un "editor gráfico x", entendiendo por esto a un editor

gráfico de uso general como Paint Brush o Power Point, ambos de Microsoft.

65


Descripción de la Prueba: Estando dentro del sistema, se deben activar diferentes

botones de la paleta de herramientas, desplegar figuras insinuadas por tales botones y

manipularles, tanto su tamaño, posición, nombres, funciones. Así como las opciones de un

portapapeles simulado.

Criterios de Aceptación: Esta prueba deberá mostrar que el sistema permite la edición y

manipulación correcta de objetos gráficos desplegados en la pantalla. Tales objetos y sus

reglas de construcción deberán corresponder a los que se definen en la sección 2.2.2 de éste

trabajo. Deberá también, permitir la asignación de identificadores a los objetos y colocar

identificadores por omisión. El sistema debe guiar al usuario, inducirle a no cometer errores

de edición con respecto a las reglas de construcción del DFDX. Un error, por ejemplo, es

traslapar objetos, es decir, colocar objetos sobre otros objetos o por ejemplo, permitir que

los flujos de datos rebasen los contornos de los procesos o almacenes.

aneo

Figura 5. 3 Un Editor Amigable.

66

-2

... .


Procedimiento de la Prueba: Para realizar esta prueba se han activado los diferentes

botones de la paleta de herramientas, de la opción de menú edición, donde se han borrado,

copiado y pegado objetos, se han probado las alternativas de la opción de menú

Herramientas, se han activado y desactivado las opciones de la opción de menú Ver. Todo

esto en diferentes especificaciones y en tres diferentes computadoras (PC).

Resultado de la Prueba: Los resultados fueron satisfactorios. En todos los casos el

sistema ha permitido la edición de especificaciones. Los objetos correspondieron en todos

los casos a la opción solicitada, se hicieron borrado, copiado y pegado de diferentes objetos

resultando siempre satisfactorios los resultados. Se asignaron identificadores a los objetos

desplegados, se cambiaron tales identificadores y se manipularon tamaños y posiciones. En

todos los casos el editor guió de una manera sutil al usuario en la edición de los

elementos( objetos) que conforman la especificación.

Desempeño de la Prueba: La prueba mostró los beneficios del desarrollo de un editor

para especificaciones a través de DFDX. Mostró también que los conceptos de edición de

editores de uso común fueron reutilizados para la implementación del editor de

especificaciones de DFDX, con la ventaja de que aquellos elementos que resulta un tanto

tedioso dibujar, se encuentran predefinidos en el sistema desarrollado.

67


EDITOR DFDE DIAGRAt.11.DFE Archivo _Editor ~er t!erramientas Nivel Verificar A:tuda

LIENTE

NoCte

i CLIENTE!

aneo

ENTIDAD EXTERNA 4

Nombre Exterior

Nombre Interno

Funcion

-2

Figura 5. 4 Asignando Datos a Elementos u Objetos.

5.3 CASO NUMERO 3

Nombre: La creación, impresión, asignación de nombres, renombrado y carga de

Especificaciones.

68


Objetivo: Corroborar que el sistema es capaz de cargar una especificación recuperando

toda su información, lista para reuso del usuario. Comprobar que se puede renombrar una

especificación previamente creada. Verificar que se puedan construir nuevas

especificaciones. Corroborar que es posible imprimir procesos. Esto es, que es posible

imprimir una especificación.

Descripción de la Prueba: Estando inmerso en el sistema, el usuario debe seleccionar la

opción Archivo de las opciones de menú. Después debe elegir la opción de impresión, con

lo cual se espera que el sistema imprima la especificación de la ventana seleccionada.

Debe probar las otras opciones de Archivo.

i mprimir regi stros lmQrime Nivel NoCte

Salir

Figura 5.5 Guardando Especificación.

Criterios de Aceptación: Esta prueba deberá mostrar correctamente los elementos de la

especificación seleccionada, deberá imprimir correctamente los elementos de la ventana de

la especificación seleccionada. Esto es, si la especificación está a varios niveles usuano

deberá accesar al nivel y diagrama deseado e imprimir.

69


Procedimiento de la Prueba: La prueba ha sido realizada en tres diferentes PCs , y

vanas veces a través de diferentes especificaciones. Han sido creados archivos de

información de especificaciones a diferentes niveles, creado nuevos, y recuperados

verificando que la información sea la misma con relación a la que ha sido almacenada

previamente.

diagrama.

Se han realizado impresiones de diferentes especificaciones en cada

I = EDITOR DFDE DIAGRAMl .DFE I Archivo t;ditor Yer tterramientas l!,!ivel Verificar A:,:uda

Nombre de ,grchivo: j protesis. dfe

1· ""L 1H,· fín •j ,.'h, ti, I•

6 uarda r archivo como tipo:

1¡ !Archivos OFOE(".dle)

.Editor ~er

.D_irectorios: )F':ilt"Acot>Í8",:,,,,;7 1 d: \ ___ \maestria\tes is \proy ·

Jo d : \ ¡m IJ Cance!g• ":·j 12::, a lfre do 12:), maestrin lc} tesis ~ proy

Unidades:

1 :ti 112') d : sislema_2

O .S..ólo lectura

Figura 5.6 Asignando Nombre a Especificación .

Figura 5.7 Una especificación Recuperada.

70


Resultado de la Prueba: Los resultados han sido satisfactorios en todos los casos. En

todos los casos el sistema almacenó, rescató e imprimió la información correspondiente. Es

importante señalar que el papel impreso no muestra el nombre del diagrama impreso.

Desempeño de la Prueba: La prueba demostró que la información puede ser manipulada

de una manera sencilla y confiable. Demostró que las necesidades de asignar nombres a las

especificaciones, guardarlas, rescatarlas otra vez e imprimirlas han sido cubiertas de

manera satisfactoria.

5.4 CASO NUMERO 4

Nombre: De la Edición a diferentes niveles donde hay diagramas padres e hijos

Objetivo: Verificar que el sistema sea consistente con respecto a las entradas y salidas

que heredan los diagramas padres a sus diagramas hijos. Así como permitir la edición

alterna en pantallas repetidoras de varios diagramas de la especificación. Que el sistema

permita a los diagramas hijos generar sus propios diagramas hijos y ser consistente con los

flujos de entrada y salida

Descripción de la Prueba: Estando inmerso en el sistema, se selecciona un elemento

proceso previamente creado , variablemente se ha tomado con entradas y salidas, así como

sin ellas, se elige la opción de menú Nivel donde se decide bajar al nivel hijo o subir al

nivel padre del proceso . Se edita en la ventana o proceso que sea de interés para el

usuano.

71


,érchivo _Editor Y.er _tlerrami e ntas

o o

-<:r s:uauo

suario PLB

-<:>-D

D A ·~

Figura 5.8 Selección de proceso para bajar un nivel de abstracción.

Criterios de Aceptación: Esta prueba deberá mostrar que la información gráfica que el

usuario edite se refleje en el diagrama correspondiente. Deberá también permitir las mismas

facilidades y característica en todas las ventanas repetidoras o interfases de edición. Deberá

también habilitar o deshabilitar opciones de manejo de archivos, ya que estando en niveles

inferiores no se deben permitir operaciones de archivo. Deberán también habilitarse y

deshabilitarse opciones de manipulación de niveles de edición.

Procedimiento de la Prueba: Para realizar esta prueba se instaló el sistema en tres

diferentes PCs. Se realizaron 3 especificaciones distintas probando las principales

posibilidades de inconsistencia y en base a las especificaciones o reglas de construcción del

DFDX.

72

Capítulo 5

DIAGRAMA FDE :SPLB.DFE ];ditor '{er !:!erramientas Nivel Verificar A)l'.uda

suario PLB

. ; Archivo ];ditor '{er !:!erramientas Nivel

~ ~ lst_lbs

Pruebas del Sistema

suario

~ lb_psta,;)'

-=@-ms gl

Figura 5.9 Edición en varios niveles de varios diagramas, flujos heredados.

Resultado de la Prueba: Fue sin duda ésta la prueba más exitosa (según el criterio

descrito en [Myers 79]), pues ha sido la que más correcciones a necesitado para llegar a ser

satisfactoria. Se comprobó en base al procedimiento de la prueba, que la edición de

especificaciones a diferentes niveles podía también ser posible. Es importante señalar que

las operaciones de inserción y borrado de objetos puede afectar en gran medida la

especificación, por lo tanto antes de realizar alguna operación se suele pedir una

confirmación al usuario.

Desempeño de la Prueba: La prueba mostró que la edición a varios niveles de manera

alterna puede afectar a toda la especificación y las modificaciones se deben reflejar donde

sea necesario al momento.

73


5.5 CASO NUMERO 5

Nombre: El proceso de Verificación

Objetivo: Corroborar que el sistema sea capaz de hacer un diagnóstico del proceso de

edición de una especificación, de acuerdo a las reglas de construcción del DFDX, señaladas

en el capítulo 2 de este trabajo.

Descripción de la Prueba: Estando inmerso en el sistema, se elige la opción de menú

Verificar . Sin importar que exista o no una especificación, sin importar el sentido o

coherencia de la especificación.

J;_ditor Y.er tlerramientas Nivel

suario

sua,io PLB

SPLB Archivo !;ditor Y.er tlerramientas Nivel Verificar A~uda

elecYEntreg

Figura 5.10 .- El proceso de Verificación, disponible en cualquier diagrama.

Criterios de Aceptación: Esta prueba deberá mostrar los errores del tipo lexicográfico

que se hayan cometido durante la construcción de alguna especificación usando el sistema.

Deberá ser capaz de ubicar el error y a los objetos que lo constituyen. Este proceso habrá de

74


tener la capacidad de estar habilitado en cualquier momento de la interacción, a excepción

de que no exista ningún elemento u objeto interrelacionado.

' ERROR NUMERO [10)) : El proceso [[SPLB II Necesita EntradasERROR NUMERO (11)): El Elemento [[Autor )]No esta

· RelacionadoERROR NUMERO (12)) : Generacion , Espontanea,direccion imprecisa o <flujo-flujo> '. imposible [[Autor 111

Editor DFDE :SPLB.DFE Yer tlerramientas Nivel Verificar A)luda

su ario PLB

SPLB as Nivel Verifica r A)luda

usca_libro elecYEntreg

Figura 5.1 l.- El Proceso de verificación, después de una modificación erronea.

Procedimiento de la Prueba: Para realizar esta prueba se han utilizado tres

diferentes computadoras (PCs ). Se han construido varias especificaciones que han sido

sometidas al proceso de verificación. En diferentes momentos del proceso de edición se ha

llamado al proceso de verificación , En cuanto se han encontrado errores se ha procedido a

corregirlos en base a los resultados arrojados por el proceso de verificación y se ha

sometido después de correcciones a tal proceso otra vez.

Resultado de la Prueba: La prueba ha sido satisfactoria, en todos los casos el sistema

ha arrojado los resultados esperados, se han cometido errores de edición en forma

75


estratégica y aquellos errores del tipo lexicográfico has sido en todos casos localizados y

plenamente identificados los elementos involucrados.

Desempeño de la Prueba: La prueba mostró que las necesidades de contar con un editor

capaz de diagnosticarse a sí mismo en base a las reglas de construcción del Método de

Especificación fueron satisfechas.

76

Capítulo 6 Conclusiones y Trabajos Futuros

CAPITULO 6

CONCLUSIONES Y TRABAJOS FUTUROS

6.1 CONCLUSIONES

• El sistema desarrollado fortalece al DFDX como un MGEF eficaz.

• Este trabajo de tesis se ha concentrado en el estudio de algunos métodos formales, sobre

todo gráficos, el estudio de operaciones gráficas de edición, de la herramienta de

desarrollo y algunas otras áreas que fueron necesariamente abordadas de una manera

parcial.

• Se requiere alcanzar cierta cultura en el desarrollo de software para alcanzar buenos

resultados a través del uso de las técnicas o métodos de especificación formal.

• Se ha centrado la presente tesis en un método que ofrezca las bondades de la popularidad

y la certeza y confiabilidad de los formalismos. Esto es cubierto por el DFDX.

• Desde el punto de vista de hardware, el sistema está fundamentado en elementos que en

estos momentos podrían ser considerados mínimos. El uso de una computadora personal

con un procesador 386 ó mayor, corriendo a 100 Mhz y 4Mb en memoria RAM no son

elementos de dificil adquisición.

• Podemos decir que la presente investigación contribuye a promover tal viabilidad. Se ha

desarrollado una herramienta CASE que vuelve atractivo un MGEF.

77


• En el presente trabajo de tesis se ha desarrollado la automatización e inmersión del

DFDX dentro de los métodos formales gráficos.

• La automatización ayuda a colocar al DFDX en posición de competir con los principales

Métodos Formales Gráficos como lo son Redes de Petri y Máquinas de Estados Finitos,

de tal forma que se ha mostrado una tabla comparativa en el capítulo 4 , que, basada en

algunos conceptos propuestos por [Davis 88], permite ubicar los alcances del DFDX con

respecto a las dos populares técnicas con las que se le compara.

• La construcción de un editor es un trabajo bastante arduo, en relación a la impresionante

cantidad de detalles que se deben tomar en consideración y que van desde el manejo

apropiado de los archivos, a las opciones habilitadas de un menú, la consistencia que se

debe mantener en los detalles de edición, borrado, cortado y pegado de elementos de la

especificación, hasta rotaciones gráficas y la forma de la flecha de un flujo de datos.

• Con el desarrollo del trabajo de tesis presentado, se cuenta con una herramienta que

puede ayudar a un Ing. de Software a desarrollar mejores especificaciones.

• La herramienta desarrollada no incluye la generación de archivos gráficos que puedan ser

transportados con facilidad a otros paquetes de manipulación gráfica.

• Se han cubierto los principales objetivos del trabajo de tesis, es decir, el desarrollo de

una herramienta CASE del DFDX, logrando además hacer algunas observaciones sobre

el potencial del DFDX y su inmersión dentro de los MGEF. Adicionalmente, se

proponen en la siguiente sección algunas líneas de investigación que ayudarán a mejorar

aún más esta importante herramienta de especificación.

78


6.2 TRABAJOS FUTUROS

Durante el presente trabajo de tesis se encontraron detalles que podrán fortalecer al

DFDX como herramienta de especificación. Uno de ellos es la implementación formal del

sistema a través del uso intensivo de bases de datos y Querys hechos por ejemplo con SQL

(Lenguaje de Consulta Estructurado) por sus siglas en inglés. Tales bases de datos serían

muy parecidas a la utilizada y descrita en ésta investigación (Capítulo 3). El uso de Algebra

relacional como medio para obtener los conjuntos de información descritos en las reglas de

construcción del DFDX y programando tales reglas en determinados estados del sistema a

fin de que sean aplicadas tanto en el proceso de Edición, como en el proceso de

Verificación. Con relación al sistema desarrollado, básicamente usa la misma filosofía, sin

embargo, la obtención de los conjuntos de información se logró en base a algoritmos de

búsqueda y programación procedural. Los querys obtendrían tal información mediante la

generación de tablas virtuales que almacenen los conjuntos de información y permitan la

manipulación de esa información a través de programas .

Otra de las investigaciones propuestas es la formalización para el DFDX de algunos

operadores de reestructuración, de los cuales se ofrece un ligero bosquejo en el capítulo 2.

Dicha formalización deberá ser parecida a la que desarrolla [Malina 94]. Se sugiere también

la implementación de tales operadores dentro del editor gráfico de especificación. Los

trabajos a futuro son viables en realidad. Se explican las operaciones de reestructuración en

detalle, en el Anexo B.

79

1

1 , '

1

"

1 1

Anexo A Uso del DFDX(Editor)

ANEXO A

USO DEL DFDX (EDITOR)

1 INTRODUCC/ON

En este anexo se pretende mostrar parte de la especificación de la herramienta

desarrollada. Es importante señalar que no se profundiza en los diagramas de

transformación hasta nivel de instrucción, puesto que se pretende ejemplificar el uso del

DFDX y describir a grandes rasgos la especificación de la implementación desarrollada.

2. ESPECIFICACION DE LA HERRAMIENTA DEL DFDX, USANDO DFDX

--t 1-ERRAMEND\ -o ~E] LSU\RIO [EB]Q(N

fvE\&\Jfu

Figura A-0. Diagrama de Contexto de la Especificación (Nivel O).

En la figura A-0, se presenta la interacción usuario-interfase-usuario, donde el

USUARIO envía un mensaje de entrada-al-sistema MENSAJEi hacia HERRAMIENTA_

DE_EDICION, que, a su vez, envía un mensaje de salida-del-sistema MENSAJEo al

USUARIO.

Entrando al proceso HERRAMIENTA_DE_EDICION o bajando un nivel en la

especificación, se tiene en la figura A-1, el mensaje proporcionado por el usuario

80


MENSAJEi se mantiene como entrada inicial . Como salida final se tiene la respuesta del

sistema al usuario: MENSAJEo.

Ms.ic inicio

VALORES DE INiCIO

Va!ores l U!obaks V

~ DATOS GR A LES

Ms;e_MENL, Acc_MENU

o-.. ~:~·::\~:7, 1---<

o---_.. M:s_ie .. PIZAR.RO N --- Ac,: _PIZARRON

Figura A-1 .- HERRAMIENTA DE EDICION (Nivel 1).

El mensaje de entrada MENSAJEi puede ser el inicio del sistema, de ser así, se

llama a un proceso de VALORES_ DE_ INICIO, que asigna valores a las variables globales

y carga en memoria la información de la especificación que se encuentra en disco. A todos

esos datos se les llama Valores Globales y son colocados en un almacén

DATOS ORALES.

Puede ser que la SELECCION _DE_ OPCION sea trabajar en la sección de menú, en

la sección de la paleta de herramientas o en el área del pizarrón de edición. Entonces es

necesario que en el primer caso, el proceso de TRABAJO_DE_MENU reciba como entrada

un mensaje Msje_MENU, responderá con una acción visible al usuario en el área de menú

Acc_MENU. El segundo caso la SELECCION_DE_OPCION es el trabajo a través de la

paleta de herramientas, se envía un mensaje Msje_HERRAMIENTAS al proceso

PALETA_DE_HERRAMIENTAS, que ejecutará una acción y avisará al usuario a través

81


de un mensaje Acc _HERRAMIENTAS que el proceso ha sido ejecutado. El tercer caso es

similar a los dos anteriores donde Msje_PIZARRON es enviado al PIZARRON_DE_

EDICION y éste responde con una acción Acc_PIZARRON. Sólo una de las tres opciones

puede ser tomada a la vez, se especifica ésto a través del uso del agrupador OR, la que

resulte, es tomada como el mensaje de salida de la HERRAMIENTA_DE_EDICION.

En la Figura A-2 se describe el proceso de TRABAJO_DE_MENU, donde, a través

del mensaje de selección del usuario se hace una SELECCION _DE_ OPCION, canalizado

por Msje _ Menu mediante un evento de click del ratón Evto _ Click se define la opción

seleccionada, que puede ser uno de los procesos MNU_ARCHIVO, MNU_EDITOR,

MNU _ VER, MNU _ HERRAMIENTA, MNU _ NIVEL o MNU _ VERIFICA, que

responderán mediante acciones en sus propios submenús. De igual manera que en la figura

A-1, se ejecuta sólo un proceso a la vez, especificando ésto a través del uso del agrupador

OR.

Evhi_dick

o---

0·---i·~

MsJ e_Menu ~~~~ /\.. ~ SELEC'C'ION l-----

--V-- DE OPC ION

\·INU ARC'HVO

MNLI. FDITOR

Acc_ Archvo

A ce

~ Evto .. _c l,ck '\_ ~Q _.... MNU

NJVEL

Acr ... Ni,el

o ,\ce

~M-NU-, -~ V0ntic,

... VERIF ICA

Figura A-2 .-TRABAJO DE MENU (Nivel 1-1).

82


En la Figura A-3 se describe el proceso PALETA DE HERRAMIENTAS, se

describe de igual forma que el proceso TRABAJO DE MENU en la figura A-2. Estando en

la paleta de herramientas, se hace la SELECCION DE OPCION mediante un evento

double click representado por Evto _ Dclick, que entra al proceso de la opción

seleccionada; Estos pueden ser MBH_FLUJO, MBH_EXTERNO, MBH_PROCESO,

MBH_ALMACEN, MBH_FLUJO_NEC, MBH_FLUJO_DES, MBH_AND, MBH_OR o

MBH _ DIRECC. Estos procesos se ejecutan y realizan una acción visible en la paleta de

herramientas para indicar al usuario que han sido ejecutados.

MSJ\'HERRAMIENTAS

Evw_Dclick J\cc _. Flujo

Acc

~----' Acc

MBH Al macen

---1 ... -.. ALlvÚ;_CEN \ .. . . Acc \\1~

0

RRAMIENTA

Evm))chck [ . l Fluio o' e ____ MBH · - /\ ....._

... FLUJÓ_NEC ... ~

Evto_Dclick MBH ¡~~,j~_Des~ o ... FLUJÓ_DESI---V /¡ Evrn Dclick Acc ....

··· ... ~~·--

~ '\,'(' Evw_Ddick e·-

1 e' ) ·.

MBI! 1

i---1 .. -.. OR ... ---,

Evto_Dcl1<;k ~--MBH_

... FTIQIJETl\

:\ce Etiq ueta

~--~ Acc Evto .. J)d1ck Dir;~c ;---1 ... ~ MBH_

DJRECC

Figura A-3.- PALETA DE HERRAMIENTAS (Nivel 1-2).

En la figura A-4, se describe el proceso del PIZARRON DE EDICION, que a través

de un sensor de eventos del ratón SENSOR DE EVNTOS_MOUSE, que determina el

evento capturado y a través de un mensaje Msje _E_ Mouse puede ejecutar los procesos

MOUSE_DOWN, MOUSE_MOVE o MOUSE_UP. Esto permite especificar los eventos

del ratón: mouse _ down, mouse move y mouse _ up , que son sensados en el área del

pizarrón de edición.

83

Anexo A

Msj.: _ E_tvlousl"

o .,.

Msjt'_

MOUSE .. DOWN

Acc !v1ousc

Uso del DFDX(Editor)

PIZ!\RRON Acc... ~ Acc --··.. Msje.E ~.Mouse ,--- ··1 Mou,t PIZARRON

/\ ....._ SENSOR DL --Q MOUSE_ ' ' <)>------"'-~ EVNTOS_MOl'SE . MOVE • V--<>-----

Msje . .E_Mouse

o .,. MOUSE __ UP

Acc_ Mouse

Figura A-4.- El proceso PIZARRON DE EDICION (1-3).

En la Figura A-5 se presenta el DFDX del proceso MNU _ ARCHIVO, que

especifica el trabajo en la opción de menú Archivo, que tiene la misma forma que su

predecesor TRABAJO MENU y que a través de eventos click del ratón permite ejecutar los

procesos ARCH_NUEVO, ARCH_ABRIR, ARCH_GUARDAR, ARCH_ GUARDA_

COMO, ARCH _IMPRIME, ARCH _ SALIR. De éstos procesos, el usuario puede

seleccionar uno a la vez. El diagrama tiene como salida el mensaje Acc _ archivo.

En la Figura A-6 se describe el proceso de creación de un nuevo archivo

ARCH_NUEVO, donde el control del programa se mueve en base a ciertas condiciones. La

opción Archivo Nuevo de la opción de menú Archivo, requiere para su solicitada requiere de

un evento click del ratón Evto _ Click. Se tienen en la especificación condiciones dadas por

cl,c2,c3,c4,c5, y c6. Donde el=' Ha habido cambios en la especificación', c2=' No hay

cambios en la especificación', c3='El nombre de la especificación es el de omisión', c4='El

nombre de la especificación NO es el de omisión', c5='El nombre ha sido introducido' y

c6='La operación fué cancelada'.

84

Anexo A

l::vto click

Ev1c.\ .. t·\1ck .. Evto_cltck

Evto c ii l'k

ARCH_ NUEVO

ARCl-1_ ABRIR

ARC H GUARDAR

,----'-----'-~ E ... ln click. AR(H

'-----0 lllli GIJARDACOMO

:\C.T

Archivo

At·..::

E\·ro .. si11..:k ,-----~ Acc .... Q .,. ,IRC:H Archrl'O

!Mf'Rl ~·I E

Evto ... clH:k

o ...

Uso del DFDX(Editor)

Figura A-5.- El trabajo de Archivos en MNU_ARCHIVO (Nivel 1-1-1).

c2

ACTUALIZA ESPECIFICACION

Varinbles .... receptoras

Acc_

Figura A-6 El proceso de Crear un nuevo Archivo de la sección Archivo, del área de menú. ARCH _

NUEVO Nivel ( l-l-1-1).

85


Se entra al proceso de CHECA_ CAMBIOS, si c 1 se cumple entonces se verifica el nombre

de la especificación CHECA _NMB _ ARCH donde si c3 se cumple entonces aparece un

dialogo para solicitar el nombre de la nueva especificación en PIDE_ NMBARCH donde si

c5 se cumple entonces se ejecuta ACTUALIZA_ESPECIFICACION, que refresca la

especificación ( en pantalla). Si c2 se cumple, entonces significa que no se guarda la

especificación actual y por tanto se va a PIDE_ NMBARCH para el nombre de la nueva

especificación. Si en CHECA _NMB _ ARCH se cumple c4 entonces GRABA

_ARCHIVOS de la especificación actual y pasa a PIDE NMBARCH de la nueva

especificación, donde si c6 se cumple entonces la operación es cancelada .

Evto Dclick

Figura A-7.-

DATOS .. GRALES

Coonknmlas ... del Cenrro

PINTA PROCESO

DATOS GRAL ES

Coordenadas obi._nmerior obj _acrual

El proceso de crear un nuevo elemento (Proceso) en la especificación. MBH_PROCESO

(nivel 1-2-3).

En la figura A-7, se describe el proceso de crear un nuevo elemento (Proceso). En el

DFDX se tienen las condiciones cl='Es el diagrama de Contexto' y c2=' NO es el diagrama

de contexto'. El usuario selecciona el ícono apropiado de la paleta de herramientas, entra a

un proceso donde se checa el nivel en el que se encuentra el diagrama actual

86


CHECA _NUMDIAG. Si c 1 se cumple, entonces envía un mensaje de error, si en cambio,

se cumple c2 entonces dibuja un nuevo proceso en PINTA_ PROCESO, que necesita las

coordenadas del centro de la pantalla para ejecutarse usando Datos_ obj_ actual, ejecuta una

ALTA_ ENE_ REGISTROS y almacena los datos de los objetos actual y anterior, después

coloca los "puntos de foco" 1 , mediante el proceso PINTA_PUNTOS, que requiere los

datos del objeto actual Datos_obj_actual y los datos de todos los demás objetos del

diagrama Arreglo_ Objetos. REFRESCA_ DIAGRAMA, es decir, actualiza la pantalla con

nuevos datos.

BORRA_PUNT OBJ _ACTUAi..

ll-\TOS_ GIULES

Datos. Objacmal Obj_ ant~rior

,---~~--. Act'

DATOS GRAL ES

Datos Diagnuna

All,L_Y_ESPERA V ,....- --<)---.. Pl~TA. OBJ E_N ~D ;~~;\RRON

l'O"-E_F1XO 1-------<0 1Jo [J\_CERO~

DATOS_ GR•\I..ES

Ac~ ... PIZARRON

,, ·~ Figura A-8.- Proceso del evento mouse _ down del ratón,. MOUSE _ DOWN ejecutado ( el evento) sobre el

área de PIZARRÓN DE EDICION (Nivel 1-3-1).

En la Figura A-8 se describe el proceso MOUSE_DOWN. De entrada, es checada la

posición del apuntador del ratón y si ésta coincide con alguno de los "puntos de escalación

del objeto actual".

I Estos puntos son colocados sobre el objeto que tiene el control y sirven tambien para manipular la escala del objeto en cuestión. En esta descripción los utilizaremos también como "puntos de escalación".

87

r


Si c 1 se cumple, entonces son borrados los puntos del objeto actual

BORRA_PUNT_OBJ_ACTUAL y se PINTA_OBJ_EN_AZUL_Y_ESPERA, el siguiente

evento del ratón ( que siempre será uno de los dos eventos restantes (mouse _ move o

mouse_up).

Si en cambio, se cumple c2 , entonces se determina cual es el objeto sobre el que

está el apuntador del ratón mediante ESTE_ SOBRE_ UN_ OBJETO, es borrado el objeto

actual y son actualizados los datos del objeto actual y el anterior, se refresca el diagrama

con los datos actualizados de los objetos que lo conforman mediante el proceso

REFRESCA_DIAGRAMA, al igual que en la condición el, se

PINTA_ OBJ _EN_ AZUL_ Y_ ESPERA, el siguiente evento del ratón.

Si en cambio se cumple c3, entonces no se ha presionado algún objeto o sección en

especial del PIZARRON DE EDICION, por lo tanto el control le es quitado al objeto que lo

posea y son borrados los "puntos de escalación ", si es que los hay. Son actualizados los

datos del objeto actual y el anterior.

88

Anexo B las Operaciones de Reestructuración

ANEXOB

LAS OPERACIONES DE REESTRUCTURACIÓN

1 CONJUNTO DE OPERACIONES DE REESTRUCTURACION [Ming Jie 91}

Padre

Hijo

[ o0o o

7de .--·-·- -·-------

- .... / (') i":~ '1

l'- c .. n ,

[ e) ~ i--. o o'((i,1 j

Padre

hijo hijo hijo

Agrupación: Agrupa un conjunto de procesos residentes en el

mismo DFD, en un proceso compuesto y coloca un conjunto

de procesos, flujos de datos, almacenes ligados a esos

procesos, en un diagrama hijo. Esta operación incrementa en

uno el nivel de DFD nivelado.

Expansión: Reemplaza un proceso compuesto por sus

diagramas residentes, con todas sus cadenas en sus diagramas

hijo. Esta operación decrementa en uno el nivel del DFD

nivelado.

División: Divide un proceso compuesto y su

diagrama hijo en dos diagramas y dos procesos

compuestos, con cada nuevo proceso compuesto

siendo alguno de los dos nuevos diagramas.

Fusión: Fusiona dos procesos compuestos en el

mismo diagrama, en un proceso compuesto, fusiona

sus diagrama hijo en un diagrama y hace que el nuevo

diagrama venga a ser el diagrama hijo del nuevo

proceso compuesto.

89


Transferencia: transfiere un proceso de su diagrama

residente actual a otro. Desde luego, no se puede

transferir el único proceso en el diagrama de contexto

a otro diagrama; y no se permite a otro proceso ser

transferido al diagrama de contexto. Además, no

podemos transferir algún proceso a algún diagrama

descompuesto directa o indirectamente del proceso; de

otra manera la descomposición cíclica de secuencias

será introducida al modelo del sistema.

2 ESPECIFICACION DE OPERADORES DE REESTRUCTURACION

Para un diagrama de estructura x, se usan las notaciones tal como en la sección 2.2.1

del capítulo 2 del presente trabajo, x.P,x.T,x.F,x.A, y x.C para referirse a sus 5

componentes, Proceso, Terminador, Flujo, Almacén y las Conexiones (relaciones de

conexión) de cada proceso(P) respectivamente ..

Un terminador y todos los demás tipos de procesos que no están descompuestos

directa o indirectamente en el diagrama , son llamados externos del proceso .

Los flujos y almacenes que conectan el proceso y los externos del proceso son

llamados las interfases de flujos y almacenes de el proceso.

Las conexiones entre las interfases de flujos y almacenes y el proceso son llamadas

conexiones de interfases con el proceso.

90

bl


2.1 EL OPERADOR DE AGRUPACION

Agrupador (m,x,P,p)

x.pa x.pa o o

X X

[ o o@J ~[ o J l o o o

y

P : Proceso Compuesto @

o

x: Diagrama de transformación Hijo

R : Agrupa un conjunto de procesos

y: Diagrama creado como el diagrama hijo del proecso P

Figura 8-1 La operación de Agrupar.

Agrupa un conjunto de procesos(R) que está en un diagrama de

transformación (x), que está en un modelo de sistema (m) , en un proceso compuesto(p) .

Los flujos y almacenes que sólo están conectados internamente con los procesos en el

conjunto son eliminados del diagrama x. En relidad todas las conexiones con los procesos

son eliminadas también, pero las conexiones de interfases originales con el conjunto de

procesos R, serán las conexiones de interfase con el proceso compuesto p. El operador

también crea un diagrama(y) y lo identifica como el diagrama hijo del proceso compuesto

(p), para así poder acomodar el proceso compuesto(R) y sus flujos originales, almacenes y

conexiones conectados. ver Figura B-1.

agrupar(m,x,, R,p)

requiere (x E m.X) A(Rcx.P) A(R;é())A (R7X.P) A(p !i!m.P)

91


Esto es, para agrupar, es necesario que el diagrama x pertenezca al conjunto de

diagramas de transformación X del sistema m que se está especificando. Es necesario

también que el conjunto de procesos R esté incluido en el diagrama x, también es necesario

que exista al menos un proceso en el conjunto de procesos R, también el conjunto de

procesos R no debe incluír a todos los procesos del diagrama x. Además el proceso

compuesto p no debe existir previamente en el sistema m.

2.2 EL OPERADOR DE EXPANSJON

Reemplaza un proceso compuesto(p), que está en su diagrama residente(x), que está

a su vez, en un sistema modelado (m), con el contenido de su diagrama hijo(p.hUo). las

conexiones de interfases con el proceso son removidas desde su diagrama residente. El

diagrama hijo del proceso y las relaciones de descomposición entre el proceso y su

diagrama hijo son eliminadas del sistema modelado.

expandir( m,x,p)==

requiere (x E m.X) A (pEx.P) A (3z E m.X)(<p, z> E m.D)

Es necesario que el diagrama de transformación x, pertenezca al conjunto de diagramas de

transformación X, del sistema m y que el proceso compuesto pertenezca al diagrama de

Expansión (m,x,,p)

x.pa x.pa o o

X X

o o @.hijo.P j ... o

o o o o o o

p.hijo P : Proceso Compuesto

00 x : Diagrama de transformación

00 R : Agrupa un conjunto de procesos p.hijo.P

.... ·.··

Figura 8-2 La operación de Expansión.

92

Anexo B Las Operaciones de Reestructuración

transformación x, que a su vez deberá pertenecer al conjunto de procesos del sistema,

Además deberá existir un diagrama de transformación z que pertenezca al conjunto de

diagramas de transformación del sistema m, donde las relaciones del proceso compuesto p

con el diagrama de transformación z, que en este caso sería el diagrama de transformación

hijo de p, se encuentren dentro de las relaciones de descomposición que existen entre el

diagrama de contexto, el conjunto de diagramas de transformación y el conjunto de

procesos que hay en el conjunto de diagramas de transformación .

Es decir que m.D ~ ((cd.P u XP) x X)

2.3 EL OPERADOR DE DIVISION

Divide un proceso compuesto(p), que está en un diagrama de transformación(x) que

está en un sistema modelado(m), en dos procesos compuestos (p y q) mediante la

separación del diagrama de transformación p. hijo , el cual se divide en un conjunto de

procesos (R) y el resto del conjunto de procesos que conforman el diagrama de

transformación p.hijo. De tal forma que después de aplicar la operación de división, el

diagrama de transformación x contiene dos procesos compuestos (p y q). El proceso

compuesto p será padre de un diagrama de transformación llamado p.hijo, que contendrá los

elementos de p. hijo antes de aplicar la operación de división, menos R. El proceso

compuesto q será padre de un diagrama de reciente creación (y), que contendrá

precisamente el conjunto de procesos R. Los flujos y almacenes que están conectados con el

conjunto de procesos y con los otros procesos en el diagrama hijo(p.hijo), pero no con el

proceso compuesto(p ), son agregados al diagrama de transformación. Las conexiones de

interfases con el conjunto de procesos llegan a ser las conexiones de interfase con el

proceso compuesto recién creado.

Las conexiones de interfases con el otro proceso en el diagrama hijo son agregadas a

las conexiones de interfases con el proceso compuesto original si ellas no estaban

originalmente con éste.

93


Desde luego. las conexiones de interfase que están con el proceso compuesto

original pero no con los otros procesos en el diagrama hijo, diferentes al conjunto de

procesos, son eliminadas del diagrama de transformación.

El diagrama recién creado llega a ser el diagrama hijo del proceso compuesto(q).

recién creado. El operador agrega todos los flujos conectados, almacenes conectados y

conexiones con el conjunto de procesos, al diagrama recién creado.

División (m ,x,p,R,q)

X X

[ o .p J ·[ o p q J • o o o o o

p.hijo p.h ijo y

o @ D @ o o o

o o

x : Diagrama de transformación

R: Agrupa un conjunto de procesos

y: Diagrama creado como el diagrama hijo del proecso q

Figura B-3 La Operación de División.

di visión( m,x,p,R,q)==

requiere (x E m.X) A(p Ex.P)A(3 z E m.X)(<p, z> E m.D)A (Rcp.kid.P) A

(R ,i= 0) A (R ,i= p.hijo.P) A (qfí! m.P)

La división necesita los mismos requerimientos que la operación de expandir, pero además

requiere que el conjunto de procesos R esté incluido en el proceso hijo del proceso

94


compuesto p, que a su vez, debe pertenecer al conjunto de procesos del sistema. Debe

también el conjunto R, tener al menos un proceso componente, debe además ser igual al

diagrama de transformación p.hijo. El diagrama de transformación compuesto q debe ser

diferente a todos los procesos ya existentes en el sistema m.

2.4 EL OPERADOR de FUSION.

Fusiona 2 procesos compuestos (p y q) y el mismo diagrama (x) de un sistema

modelado (m), en a un proceso compuesto(p).

-l

Fu sion (m ,x,p,q) 1

x.pa x.pa .

o o ,, 11

X X

[ o

J o 11

p q . p 1 • o • 11

o o o o o

j 11

p.hijo p.hijo q.hijo 11

o ~ ijo.P ' o 00 o

00 o o o o q.hijo.P o o o 11

x: Diagrama de transformación

R : Agrupa un co njunto de procesos lj

p,q : Proceso Compuesto

%< ., ,. '" w ·" "

Figura B-4 La operación de Fusión.

Los Flujos y almacenes que están sólo conectados internamente con los 2 procesos

y las conexiones entre el proceso residente (p) y sus flujos y almacenes, son todos

eliminados del diagrama. Todas las conexiones con los procesos eliminados (q), son

95


también eliminadas, pero aquellas conexiones que están entre los procesos eliminados y los

externos de los 2 procesos compuestos, son agregadas a las conexiones de interfases con el

proceso residente, si ellas no estaban originalmente con éste.

El operador también fusiona los diagramas hijo de los 2 procesos compuestos(p. hijo

y q.hijo) en un diagrama (p.hijo). El otro diagrama (q.hijo) y sus relaciónes de

descomposición con el proceso eliminado son eliminadas ambas del sistema modelado.

fusionar(m,x,p,q)

requiere (x E m.X) A(p,q Ex.P)A(p;tq)(3y,z E m.X)(<p,y>, <q, z> E m.D)

Se indica que x debe pertenecer al conjunto de diagramas de tranasformación X, del sistema

m. y los procesos compuestos p y q deben pertenecer al conjunto de procesos del diagrama

de transformación x. Además los procesos compuestos p y q deben ser diferentes. También

deben existir los diagramas de transformación y y z que se refieren a los diagramas hijos de

p y q, donde sus relaciones de descomposición deben pertenecer al conjunto de relaciones

de descomposición del sistema m. (m.D).

2.5 EL OPERADOR de TRANSFERENCIA

Transfiere un proceso(p)que está en su diagrama residente(x), que está en un sistema

modelado (m), en otro diagrama(y). Para especificar el operador claramente, usamos 2

operadores más primitivos:

El operador SUBIR, el cual mueve un proceso(p) de su diagrama residente(x) un

nivel arriba hasta el diagrama(y), en el cual reside su proceso padre(x.pa) .

EL operador BAJAR, el cual representa la operación inversa del anterior, mueve un

proceso(p) de su diagrama residente (x) un nivel más abajo, hasta el diagrama hijo(y) de uno

de sus procesos componentes (y.pa). Ver figura B-5.

96

Anexo B

Subir (m ,x,p,y)

ººil ~ ººº ~

Tra nsfcrcn cía( m ,x,p,y)

~ Xk = X

~

Las Operaciones de Reestructuración

Bajar (m,x,p,y)

x.pa o

x.pa o

X X

~----...~ ~~

c:n ~

[ºo,'.~ 0 ]1----•·~

8 ~ y = V X,= X " ,

o o ~ o o

x : Diagrama de transformación

x.pa : Diagrama de Proceso padre

p,q : Proceso Compuesto

8 Y,,= y

~ Figura B-5 La Operación de Transferencia, que usa las Operaciones Subir y Bajar.

subir(m,x,p,y)

requiere (x,y E m.X) A(x.pa Ey.P)A(p E x.P) A ( {p} :;,= x.P)

bajar(m,x,p,y)

requiere (x,y E m.X) A(y.pa Ex.P)A(p E x.P) A ( {p} :;,= y.pa)

transferir(m,x,p,y)

requiere (x,y E m.X) A(x :;,= y)A (p Ex. P) A ( {p} :;,= x. P)

97

[ Aho Sethi 90]

[Chaparro 93]

[Chmura 95]

[Date 86]

[Davis 88]

[Demarco 78]

REFERENCIAS

"Compiladores: Principios Técnicas y Herramientas", Aho A.,

Sethi J., Ullman. Adsison-Wesley Ibero Americana , 1990.

"Redes de Petri (Un Editor)", Chaparro A., Tesis Maestria

ITESM Campus Morelos, 1993.

"What's the Proper Role for CASE Tools?", Chmura,

Crockett H.D, IEEE Software, march 1995.

"Introducción a los sistemas de Bases de Datos",Date,

Addison Wesley Iberoamericana, 1986,pp 71-78

"A comparison of techniques for the Specifications for Extemal

System Behavior",Davis A. Communications ofthe ACM. Sept

1988.

"Structured Analysis and System Specification",Tom

Demarco 1978, Yourdon Press C:S, New York N.Y.

A

[Martínez 93]

[Ming- Jie 91]

[Malina 94]

[Myers 79]

"Análisis del Estado del Arte Sobre Técnicas de Especificación", Martínez David, Tesis Maestría ITESM Campus Morelos, 1993.

"Reestructuring operations for data-flow diagrams", Ming-

Jie, et al, July 1991, Software Engineering Journal ,pp 181-

195.

"Diagrama de flujo de Datos Extendido, Una Transformación a

la Lógica de Primer Orden", Malina R, Sep 1994, Tesis

Maestría ITESM Campus Morelos.

"The Art of Software Testing ", Myers G.J, Jhon Wiley & Sons,

New York, 1979.

[Nieva, Campesino 88] "Guia de Dirección de Proyectos en el Instituto de

Investigaciones Eléctricas", Instituto de Investigaciones

Eléctricas, 1988.

[Sommerville 94] "Software Engineering", Sommerville l. ,1994, Fourth

edition, Addison Wesley.

e

[Pho Tin 92]

[Ramamoorthy 96]

[Visual Basic 93]

[Wing 90]

[Zave 90]

"Modeling of Visualised data-flow diagrams using Petri

Net Model", Pho Tin, et al, January 1992, Software

Engineering Journal, pps- 4-12.

"Advances in Software Engineering", Computer, October

Ramamoorthy C.V., Wei-tek Tsai ,1996.

"Microsoft Visual Basic, Programer' s Guide Version 3 .O",

Microsoft Corporation, 1993.

"A Specifier' s Introduction to formal Methods" Wing Jeannette

M.,Sep 1990, Computer, pps 8-21

"A Comparison of the Major Approaches to Software

Specifications and Design." ,P.Zave, System And Software

Requirements Engineering, 1990, IEEE Computer Society,

Washington 1 990.

D

[Frausto et al 97]

[Ghezzi 91]

[ Gentner 96 ]

[Hopcroft 93]

[Johnsonbaugh 93]

[Khoshafian 90]

[Liang Chang 87]

"Estudio Comparativo de Tres Métodos Formales Gráficos",

Frausto J., Del Valle M. et al. ITESM. l er Congreso Internacional

de Electrónica, UDLA. 1997

"Fundamentals of Software Engineering",Carlo Ghezzi,

Jazayeri M. et al., Prentince Hall 1991.

"Design Models for Computer-Human Interfaces", Gentner D.,

Grudin J., Computer, June 1996

"Introducción a la Teoria de Automatas, Lenguajes y

Computación", Hopfcroft, Ullman. CECSA 1993.

"Discrete Mathematics, Third Edition",Johnsonbaugh Richard,

1993, Me Millan ..

"OBJECT ORIENT ATION Concepts, Languages, Databases,

U ser Interfaces", Khoshafian, Abnous, 1990, Wiley & Sons,

NY.

"Symbolic Logic And Mechanical Theorem Proving", ChinLiang Chang & Richard Chan-Tung Lee, 1987 Academic Press me.

B

Documents

Diagrama de flujo de datos extendido