Diagramas de Flujos de Datos

Como sabemos, la información se transforma a medida que fluye por un sistema basado en
computadora. Un sistema acepta entradas en una gran variedad de formas, aplica elementos de
hardware, de software y humanos para transformar la entrada en salida, produciendo salidas en una
gran variedad de formas. Podemos, de forma efectiva, construir un modelo del flujo de la
información para cualquier sistema de computadora, independientemente del tamaño y la
complejidad del mismo. Para ello contamos con una herramienta gráfica muy simple: el Diagrama
de Flujos de Datos (DFD).
Los DFDs son una notación operacional semi-formal que ha sido ampliamente adoptada para
la especificación de sistemas de información. Son una de las herramientas gráficas más importantes
del Análisis Estructurado [3].
Un Diagrama de Flujos de Datos permite visualizar un sistema como una red de procesos
funcionales. En la literatura computacional, es común referirse a éstos también como Diagrama de
burbujas, Modelo de procesos o Modelo de función. Un tratamiento en profundidad del tema puede
encontrarse en el capítulo 9 en [3]. En el capítulo 12 en [4], en el capítulo 5 de [5] y en capítulo 6 de
[6], entre otros, puede también encontrarse información relacionada.
Los DFDs no sólo se usan para modelar sistemas de información, sino también para modelar
organizaciones enteras, es decir, como una herramienta para el planeamiento estratégico y de
negocios.
Los DFDs sirven para mostrar sólo una visión o punto de vista de un sistema: el orientado a la
funcionalidad. Sin embargo, si lo que estamos desarrollando es un sistema donde las relaciones
entre los datos son más importantes que las operaciones que se llevan a cabo sobre éstos,
probablemente al DFD se le dé menos importancia que al DER. Por otro lado, si lo que domina es el
comportamiento dependiente del tiempo, tal vez nos concentremos más en los diagramas de
transición de estado (DTE). Sin embargo, es importante destacar que las distintas visiones del
sistema, que podamos obtener a partir de distintos modelos del mismo, no se contraponen entre sí
sino que más bien se complementan.
El DFD es una técnica que representa el flujo de la información y las transformaciones que se
aplican a los datos al moverse desde la entrada hasta la salida. Usaremos una notación bastante
común que es la misma que utilizan Yourdon [3], DeMarco [7] y otros.
1. Componentes de un DFD
Los DFDs se construyen a partir de la combinación de componentes de cuatro tipos:
procesos, flujos, almacenes y terminadores o entidades externas.
1.1. El proceso
Un proceso también suele ser llamado burbuja, función, transformación. Se representa
gráficamente como un círculo, como se ve, por ejemplo, en la figura 1.

VALIDAR
USUARIO

Figura 1

Especificaciones de Software -–DFD, DD, DTE 1 Ingeniería de Software I

 Nótese que un proceso se nombra con una sola palabra, frase u oración sencilla. Esta
describirá qué es lo que el proceso hace. En general, consiste en una frase del tipo verbo-objeto tal
como VALIDAR ENTRADA o CALCULAR IMPUESTO. En algunos casos, el proceso podrá
contener el nombre de una persona o grupo (por ejemplo, departamento o división de una
organización), o de una computadora, o de un aparato mecánico. Es decir, en ocasiones, el proceso
describe quién o qué lo está efectuando, en lugar de describir el proceso mismo; pero este último es
un caso muy particular que se aplica para la construcción de los modelos de procesadores. Por
ahora, a cada proceso lo nombraremos usando la convención verbo-objeto.
Un proceso transforma entradas en salidas. Las entradas y salidas a un proceso de un DFD son
representadas por los flujos de datos.
1.2. El flujo de datos
Un flujo se usa para describir el movimiento de paquetes de datos de una parte del sistema a
otra. Por esto, los paquetes representan datos en movimiento, mientras que los almacenes (que
veremos en el próximo punto) representan datos en reposo.
Un flujo de datos se representa gráficamente como una flecha que entra o sale de un proceso,
almacén o terminador. Un ejemplo de un flujo de entrada y uno de salida hacia y desde un proceso
se muestra en la figura 2.

usario + respuesta de
contraseña VALIDAR validación
USUARIO

Figura 2
Nótese que los flujos están etiquetados. Esta etiqueta representa el significado de lo que viaja
por el flujo. Ya veremos cómo por medio del diccionario de datos se especifica sin ambigüedad
cuáles son los datos que viajan por ese flujo.
Los flujos tienen una dirección dada por una cabeza de flecha en cualquier extremo (o
posiblemente en ambos). Los flujos de dos cabezas muestran un diálogo, es decir, un pedido y una
respuesta en el mismo flujo. En este último caso, los paquetes de cada extremo de la flecha deben
etiquetarse, como se muestra en la figura 3.
Una alternativa al diálogo es el uso de dos flujos diferentes, uno que muestre las entradas
(pregunta) y otro que muestre las salidas (respuesta).

pregunta sobre DETERMI-

estado de pedido NAR
ESTADO
respuesta sobre DEL
PEDIDO
estado de pedido

Figura 3
En la mayoría de los sistemas que modelemos, los flujos representarán datos, es decir, bits,
caracteres, números en punto flotante, etc. Pero los DFDs también pueden usarse para modelizar
otro tipo de sistemas aparte de los basados en computadoras; podrían, por ejemplo, utilizarse para
modelar una línea de ensamblado en la que por los flujos viajen materiales físicos. La figura 4
muestra un ejemplo de un DFD con flujo de materiales, que modeliza el proceso de preparación de
una torta.

Especificaciones de Software -–DFD, DD, DTE 2 Ingeniería de Software I

 azúcar
leche

harina MEZCLAR
INGRE- masa HORNEAR torta
DIENTES
huevos

manteca

Figura 4

Los flujos de datos en un DFD pueden ser divergentes o convergentes, es decir, un flujo se
divide en varios flujos o varios flujos se unen para formar uno solo.
Cuando el flujo es divergente, puede significar dos cosas: (a) se están creando copias del
paquete de datos que son enviadas a diferentes partes del sistema; (b) es un paquete complejo que se
está dividiendo en paquetes más pequeños, cada uno de los cuales se está enviando a distintas partes
del sistema.
Cuando el flujo es convergente, varios paquetes se están uniendo para formar un paquete
complejo. En las figuras 5 y 6 se ven ejemplos de las dos posibles situaciones para los flujos
divergentes. La figura 7 muestra un ejemplo de flujo convergente.
ACTUALI
ZAR
INVENTA
RIO
detalle de
pedido SELECCIO pedidos
NAR
PEDIDOS
VALIDOS

GENERAR
PEDIDO
Figura 5

VALIDAR
CODIGO
POSTAL

código postal VALIDAR

NUMERO
TELEFO-
domicilio numero NO
teléfono

VALIDAR
CALLE
calle

Figura 6

Especificaciones de Software -–DFD, DD, DTE 3 Ingeniería de Software I

 OBTENER
CODIGO
POSTAL

código postal OBTENER

NUMERO
TELEFO-
NO
domicilio numero
VALIDAR
DOMICILIO teléfono

calle OBTENER
CALLE

Figura 7

1.3. El almacén de datos

Un almacén muestra una colección de datos en reposo. Se lo representa por medio de dos
líneas paralelas con un nombre entre medio. En general, dicho nombre está en plural. En la figura 8
se muestra un ejemplo.

CLIENTES
Figura 8
Un almacén puede corresponder a una tabla en una base de datos, a un archivo en disco, pero
también a datos almacenados en otros medios como por ejemplo microfichas, microfilms, o
inclusive a datos almacenados en papel en un cajón.
Los almacenes se conectan a los procesos por medio de los flujos de datos. Los flujos pueden
salir o entrar a los almacenes. En la mayoría de los casos, los flujos se etiquetan de la forma que
vimos anteriormente. Sin embargo, algunos analistas optan como convención no etiquetarlos
cuando éstos transportan una instancia completa desde o hacia un almacenamiento.
Un flujo que sale de un almacén se interpreta como una lectura a información del almacén: ya
sea que se recupere un paquete completo, varios paquetes (que podrían cumplir con una cierta
condición) o una parte de un paquete o una porción de varios paquetes. Para saber cuál de ellas
representa usamos el diccionario de datos.
Estas lecturas son no destructivas, es decir, el almacén no cambia cuando un paquete se
mueve desde el almacén a lo largo del flujo de salida. En los modelos que no son de procesos de
información, esto podría no darse; por ejemplo, un almacén podría contener cosas físicas y el flujo
representar un mecanismo para transportar materiales hacia un proceso. En estos casos, el DFD
debe incluir algún tipo de anotación extra para que el lector no se confunda.
Un flujo de entrada a un almacén se interpreta como una escritura en el almacén. Esto podría
significar que se agregan o borran paquetes, se modifican paquetes o porciones de los mismos. En
todos los casos es evidente que el almacén cambiará. El proceso en el otro extremo del flujo es el
encargado de producir el cambio en el almacén. Desde luego que los flujos de entrada a un
almacenamiento sólo pueden transportar paquetes que el almacén sea capaz de guardar.
Una cosa a tener en cuenta es que los almacenes son pasivos, es decir, los datos no viajarán
hacia un flujo o desde un flujo a menos que un proceso lo solicite.

Especificaciones de Software -–DFD, DD, DTE 4 Ingeniería de Software I

 1.4. El terminador o entidad externa

Los terminadores o entidades externas representan objetos con los cuales el sistema se
comunica (no confundir con las entidades de un DER). Estos producen información para ser
transformada por el software o reciben información producida por el software.
Un terminador puede ser una persona, una compañía, un departamento que se encuentran
fuera del sistema que se está modelando. También puede ser otro sistema de software o de hardware
con el cual el sistema se comunica.
Se representan como un rectángulo con un nombre adentro, como se muestra en la figura 9.

CONTADURIA

Figura 9
Los podemos identificar a partir de las entrevistas con el usuario. Son aquellas entidades que
se encuentran por afuera del sistema que proveen con datos al sistema y/o esperan algún tipo de
salida del mismo. Por ejemplo, si el usuario dice:
• “Cuando recibamos los formularios XYZ de Contaduría debemos producir los reportes
financieros al Comité de finanzas”; de acá podemos concluir que tanto Contaduría como el
Comité de finanzas son dos entidades externas.
• “Pretendo suministrar al sistema los datos X, Y y Z y espero que me devuelva los datos A y B”;
el usuario es un terminador.
Con respecto a los terminadores debemos recordar que:
• Son externos al sistema que se está modelando.
• Las relaciones existentes entre los terminadores no se muestran en el DFD. Si existiera la
necesidad de modelar dichas relaciones, entonces, los terminadores en realidad son parte del
sistema y deberían modelarse como procesos.

2. DFD por niveles

¿Qué hacemos cuando el DFD es muy complejo y tiene docenas de funciones a modelar? La
respuesta es organizar el DFD global en una serie de niveles de modo que cada DFD de nivel
inferior proporcione más detalles sobre un proceso del DFD de nivel superior.
Cuando construimos un DFD por niveles, el primer DFD consta de una sola burbuja, que
representa el sistema completo y los flujos de datos muestran la comunicación entre el sistema y las
entidades externas (y almacenes externos, si los hubiera). Este DFD especial se lo conoce como
Diagrama de Contexto.
El DFD de siguiente nivel se lo conoce como la figura 0. Muestra los procesos de más alto
nivel del sistema y sus principales interfaces. Estas burbujas deberán numerarse de manera
adecuada.
Cada burbuja i de un nivel particular se asocia con una figura i del nivel siguiente (si es que
existe). Por ejemplo, la burbuja 2 del DFD de la figura 0 se asocia con la figura 2 del nivel
siguiente.
Las burbujas en la figura j se numerarán j.1, j.2, j.3, etc. Por ejemplo, las burbujas de la figura
3 (obtenida por la explosión de la burbuja 3 de la figura 0) se numerarán 3.1, 3.2, etc.; las burbujas

Especificaciones de Software -–DFD, DD, DTE 5 Ingeniería de Software I

de la figura 3.1 (obtenida por la explosión de la burbuja 3.1 de la figura 3) se numerarán 3.1.1,
3.1.2, 3.1.3, etc. En la figura 10 se ve un ejemplo de explosiones.

E1 E2

a b
EL
SISTEMA c w
1 2
E3 PA PB b
c
x y v
Diagrama de
Contexto

3 z 4
PC PD

Figura 0: EL SISTEMA
x
3.1
PE o
3.2 y
PF

z t

3.3
PG

Figura 3: PC

Figura 10

El nombre de la figura es heredado de la burbuja correspondiente a su explosión. Por ejemplo,

si la burbuja 2 de la figura 0 se llama VALIDAR DATOS, entonces la figura 2 se deberá etiquetar
“Figura 2: VALIDAR DATOS” y así sucesivamente para todos los niveles.
¿Cuántos niveles debe tener un DFD? Dependerá del sistema. Podríamos aplicar la misma
regla que antes para dar un indicativo: cada DFD no debería contener más de media docena de
procesos y almacenes relacionados (entrar en una hoja).
¿Deben desarrollarse todas las partes del sistema con el mismo número de niveles? No.
Pueden existir partes más complejas que otras que necesiten un mayor número de niveles de
partición. Pero por otro lado, si por ejemplo, al explotar el diagrama de contexto obtenemos 2
burbujas, donde la burbuja 1 es primitiva (no necesita ser explotada) y la burbuja 2 debe ser
explotada en 7 niveles, significa que el modelo está desequilibrado y probablemente algunas de las
porciones de la funcionalidad asignada a la burbuja 2 deban ser asignadas a otra nueva burbuja o a
la burbuja 1.
¿Cómo asegurar que los niveles de un DFD sean consistentes entre sí? Se sigue una regla
simple: “los flujos de entrada y salida de una burbuja en un nivel dado deben corresponder con los

Especificaciones de Software -–DFD, DD, DTE 6 Ingeniería de Software I

que entran y salen de toda la figura asociada a dicha burbuja en el nivel inmediato inferior”. Los
DFDs de la figura 10 son consistentes entre sí.
¿Cómo se muestran los almacenes en los diversos niveles? La regla es la siguiente: mostrar
un almacén en el nivel más alto donde por primera vez sirve de interfaz entre dos o más procesos,
luego mostrarlo en cada nivel inferior que describa más a fondo cada una de dichas burbujas. Un
ejemplo se ve en la figura 11.

A B
ALMX

A1 A2 B1 B2

ALMX ALMX

Figura 11

Cuando un almacén es local a los procesos de un figura de un nivel inferior, es decir, sólo es
utilizado por los procesos de esa figura, no se lo mostrará en los niveles superiores, ya que quedará
implícito en ellos.
¿Cómo se realiza la partición de los DFDs por niveles? Existen dos enfoques diferentes:
(a) el enfoque clásico descendente que consiste en partir del diagrama de contexto, para luego
desarrollar la figura 0 y así sucesivamente;
(b) el enfoque por partición de acontecimientos que consiste en identificar primero los
acontecimientos externos a los cuales debe responder el sistema y utilizarlos para realizar
un primer borrador de DFD del sistema. Esto puede llevar a aplicar después un enfoque
ascendente y, eventualmente, aplicar un enfoque descendente.
Es importante destacar acá que la organización y presentación de DFDs por niveles no
necesariamente corresponde a la estrategia para desarrollar estos niveles.

3. Guía práctica para la construcción de un DFD

• Escoger nombres significativos para todos los componentes del DFD.

• Numerar los procesos, ya que además de permitir un modo abreviado de referirse a un proceso,
sirve como base a una numeración jerárquica cuando se construyan DFDs por niveles. Esta
numeración puede ser hecha en cualquier orden, de derecha a izquierda, de arriba abajo, de
cualquier manera siempre que exista una forma consistente de aplicar los números. Lo que

Especificaciones de Software -–DFD, DD, DTE 7 Ingeniería de Software I

 importa es no pensar que porque exista una numeración esto implicará algún tipo de secuencia
entre los procesos.

• Redibujar los DFDs tantas veces como sea necesario.

• Evitar los DFD excesivamente complejos. En lo posible deberá entrar en una sola página. En la
mayoría de los casos, esto significa que no deberían haber mas de media docena de procesos,
almacenes, flujos de datos y terminadores relacionados en un solo diagrama. Esta regla proviene
de “El número mágico siete, mas o menos dos” de George Miller, Psychology Review, 1956.
Existe una excepción para esto: un caso especial de DFD, conocido como diagrama de contexto,
que trataremos más adelante. Generalmente, estos últimos diagramas no pueden simplificarse.

• Asegurarse que el DFD sea lógicamente consistente. Las principales reglas de consistencia son:

• Evitar sumideros infinitos, es decir DFDs donde solo existen flujos de entrada y
ninguno de salida.

• Evitar burbujas de generación espontánea, es decir aquellas burbujas que tienen

salidas y no tienen entradas, ya que son sumamente sospechosas. Sin embargo,
podrían existir. Un ejemplo de esto es un proceso de generación de números random.

• Evitar los flujos y procesos no etiquetados. Esto no solo indica falta de esmero sino
que podría estar ocultando un error o falta de comprensión del problema.

• Tener cuidado con los almacenes de solo lectura o solo escritura. Son sospechosos.
Acá pasa lo mismo que con los procesos de sólo entrada y de sólo salida. Sin
embargo, dado que los DFDs cuando son muy grandes se particionan, podríamos
encontrarnos que una parte del sistema está modelada por un DFD en el cual un
almacén es accedido como solo lectura, pero luego en otra parte del sistema, exista un
DFD que se lo accede para escritura. Otra excepción a esta regla son los almacenes
externos al sistema que sirven de interfaz entre el sistema y algún otro sistema.
Además de estas reglas propias de los DFDs, existen otras reglas que ayudan a asegurar la
consistencia del DFD con respecto a otros modelos del sistema (DER, Diccionario de Datos y
DTE). Esas reglas las veremos en la sección “Balanceo de Modelos”.

4. Observaciones sobre los DFDs

Es importante notar que, aunque los DFDs son una herramienta gráfica atractiva para capturar
de manera bastante intuitiva los flujos de datos y las operaciones involucradas en un sistema de
información, carecen de un significado preciso, ya que:
• La semántica de los componentes usados solamente se encuentra especificada por los nombres
elegidos por el analista.
• Carecen de aspectos de control. Por ejemplo, no está claro cuantos paquetes requiere un proceso
de un flujo de entrada para producir una salida, o en qué orden los requiere si existen varios
flujos de entrada.
El primer problema lo vamos a solucionar, en parte, acompañando al DFD con un diccionario
de datos. Sin embargo, para la semántica de un proceso y los detalles de control será necesario usar
otro tipo de herramienta que permita construir especificaciones de procesos no ambiguas.
Por otro lado, imaginemos que queremos construir una máquina para simular el sistema
modelado, a fin de controlar si las especificaciones reflejan las expectativas del usuario. Tal

Especificaciones de Software -–DFD, DD, DTE 8 Ingeniería de Software I

máquina no puede ser derivada directamente a partir del DFD ya que ninguna ejecución sobre la
máquina es posible sin una semántica precisa para las notaciones. Un lector humano puede llenar el
hueco semántico gracias al significado intuitivo de los identificadores usados en el DFD. Pero una
máquina carece de intuición y no podrá interpretar una notación de este tipo.
Por estas razones, decimos que los DFDs tradicionales son una notación semi-formal. Su
sintaxis, es decir, la forma en que se componen los DFDs muchas veces se encuentra definida en
forma precisa, pero su semántica no.

Especificaciones de Software -–DFD, DD, DTE 9 Ingeniería de Software I

 Diccionario de Datos
El Diccionario de Datos (DD), aunque no es una herramienta gráfica, es de vital importancia
para el desarrollo de un sistema. Sin él, por ejemplo, un modelo de los requerimientos del usuario
construido haciendo uso de DFDs está incompleto.
El DD es un listado organizado de todos los datos del sistema, con definiciones precisas. En
las entradas de un DD tendremos:
• Nombre, significado y composición de los flujos y almacenes que se muestran en un DFD.
Cuando el paquete de datos que viaja por un flujo es compuesto, se describirá cada una de
sus partes, los cuales a su vez si son complejos deberán aparecer como una nueva entrada
del diccionario, y así sucesivamente. Lo mismo vale para los paquetes de datos de los
almacenes.
• Nombre, significado y composición de las entidades dependientes e independientes que se
muestran en el DER.

Notación
Existen varias notaciones alternativas, nosotros adoptaremos la siguiente:
= está compuesto de
+ y
() opcional (lo que está entre los dos paréntesis puede estar presente o ausente)
{} iteración. Cero o más ocurrencias de lo que se encuentra entre las dos llaves.
[] seleccionar una de varias alternativas dadas entre los dos corchetes.
* principio y fin de comentario. El comentario se coloca entre los dos asteriscos.
@ identificador para un almacén (clave primaria). Se coloca precediendo la clave.
| separa opciones alternativas de construcción
Ejemplo:
nombre = *nombre de una persona*
primer nombre + (segundo nombre) + apellido
primer nombre = {caracter válido}
segundo nombre = {caracter válido}
apellido = {caracter válido}
caracter válido = [A-Z|a-z|’|-| |]
Es importante que el diccionario esté completo y sea consistente. Para controlar la
completitud deberemos verificar que se hayan definido todos los datos presentes en los diagramas;
para la consistencia deberemos controlar que no exista más de una definición para un mismo dato y
que no hayan entradas fantasmas, es decir, que no correspondan a ningún dato en los diagramas ni
tampoco sean parte componente de otro dato definido en el diccionario.

Especificaciones de Software -–DFD, DD, DTE 10 Ingeniería de Software I

 Diagramas de Transición de Estados
El Diagrama de Transición de Estados (DTE) es una notación operacional semi-formal que
permite construir modelos de comportamiento dependientes del tiempo.

1. Componentes de un DTE
Los principales componentes de un DTE son los estados y las transiciones (flechas que
representan cambios de estado). Además, tenemos las condiciones y las acciones asociadas a las
transiciones.

1.1. Estados
Usaremos un rectángulo para representar cada uno de los estados en los cuales se puede
encontrar un sistema.
Un estado observable del sistema corresponde a períodos en los cuales
(a) el sistema está esperando que algo ocurra en el ambiente externo
ó
(b) está esperando que alguna actividad que se está realizando en ese momento cambie a otra.
Entonces, decimos que un estado representa algún comportamiento del sistema que es
observable y que perdura durante algún período de tiempo.
Ejemplos de estados pueden ser:
Œ Esperando que el usuario ingrese una contraseña.
ΠAcelerando el motor.
ΠMezclando los ingredientes.
1.2. Transiciones
Para representar los cambios del sistema de un estado a otro usamos una flecha conectando los
dos estados involucrados. Por ejemplo, en la figura 12 se ve un DTE con tres estados y tres
transiciones.
ESTADO 1

ESTADO 2

ESTADO 3

Figura 12
El sistema modelado por el DTE de la figura 12 puede alternar entre el estado ESTADO 1 y el
estado ESTADO 2, pero una vez que pasó del estado ESTADO 2 al estado ESTADO 3 no puede
volver más a ninguno de los otros dos estados.
Dos de los estados tienen características particulares. El estado ESTADO 1 es el estado inicial
del sistema. Se lo reconoce por la flecha de entrada que no viene de ningún estado anterior. Un DTE
sólo puede tener un estado inicial. El estado ESTADO 3 es un estado final. Son estados finales
aquellos estados que no tienen ninguna flecha de salida (o tienen una flecha de salida que no lleva a

Especificaciones de Software -–DFD, DD, DTE 11 Ingeniería de Software I

ningún otro estado), es decir, aquellos estados en los que una vez que se entró no se puede salir más.
Pueden existir múltiples estados finales. Estos son mutuamente excluyentes.

1.3. Condiciones y acciones

Asociados a una transición, existen dos elementos más: las condiciones que se deben
satisfacer para que se produzca el cambio de estado y las acciones que el sistema lleva a cabo
cuando se realiza el cambio de estado. Se representan como se muestra en la figura 13.

ESTADO 1
Condición

Acción
ESTADO 2
Figura 13

2. Particionado de un DTE
Al igual que sucede con los DFDs, un DTE puede ser tan complejo que no sea posible
visualizarlo cómodamente en una página. En este caso podemos descomponerlo por niveles:
cualquier estado complejo puede dar origen a un nuevo nivel el cual muestre un nuevo DTE con un
estado inicial y estados finales.
El estado inicial corresponde al estado de nivel superior, es decir se entra en el estado inicial
del DTE de nivel inferior cuando se entra al correspondiente estado compuesto del nivel superior.
Los estados finales de los DTE de nivel inferior corresponden a las condiciones de salida del nivel
superior.

ESPERANDO TARJETA

Se pulsó Cancelar Se ingresó tarjeta

Devolver Tarjeta
Mostrar “Ingrese contraseña”
ESPERANDO CONTRASEÑA Se pulsó Cancelar
Devolver Trajeta
Se ingresó contraseña
Mostrar menú de opciones Se pulsó “Finalizar”
Devolver Tarjeta
ESPERANDO OPCION

Se pulsó “Extraer efectivo” Se pulsó “Transferir Fondos” Se pulsó “Realizar Consulta”

Mostrar opciones de consulta

EXTRACCION TRANSFERENCIA CONSULTAS

Mostrar menú de opciones

DTE para un cajero automático

Especificaciones de Software -–DFD, DD, DTE 12 Ingeniería de Software I

 ESPERANDO ELECCION

Se pulsó “Consulta de
Se pulsó “Consulta de Saldo” Ultimos Movimientos”

IMPRIMIENDO SALDO IMPRIMIENDO MOVIMIENTOS

DTE correspondiente al estado “CONSULTAS”

Figura 14
En la figura 14 se ve un ejemplo de un DTE por niveles que modela el comportamiento de un
cajero automático. Si bien el DTE no está completo, muestra cómo el estado “CONSULTAS” es
una estado compuesto que puede ser modelado a su vez por un nuevo DTE.

Especificaciones de Software -–DFD, DD, DTE 13 Ingeniería de Software I

 Balanceo de Modelos
El Análisis Estructurado hace uso de tres herramientas gráficas a la hora de construir una
especificación de los requerimientos del usuario: los Diagramas de Entidad-Relación, los
Diagramas de Flujo de Datos y el Diagrama de Transición de Estados. Cada uno de ellos nos brinda
una visión diferente del sistema. El primero pone el énfasis en los datos y sus relaciones, el segundo
centra la atención en la funcionalidad del sistema y el tercero en el comportamiento dependiente del
tiempo. También, vimos que un complemento a estas herramientas es el Diccionario de Datos el
cual nos permite definir con un mayor grado de detalle los datos presentes en los diagramas.
Cuando reunimos todos lo modelos del sistema, corremos el riesgo de que aparezcan
inconsistencias entre ellos. Esto suele suceder cuando se trata de proyectos particularmente grandes
donde distintos grupos de personas han trabajado sobre diferentes modelos. Una especificación
estructurada, en la cual se ha verificado que todos los modelos sean consistentes entre sí se dice que
está balanceada.
Hay dos tipos de errores comunes que se suelen detectar en la actividad de balanceo. Uno es una
definición faltante de algún elemento; por ejemplo un almacén de datos definido en un DFD que no
se encuentra en el DD. El otro tipo son las inconsistencias entre modelos: la misma realidad se
describe de maneras contradictorias en modelos diferentes.

4.1. Balanceo del DFD con el DD

• Cada flujo de datos y cada almacén de datos deben estar definidos en el DD. Caso contrario se
dice que el dato está indefinido.
• Cada dato y almacén que se define en el DD debe encontrase en alguna parte del DFD. Si no
aparece se dice que es un dato fantasma.

4.2. Balanceo del DFD con el DER

• Cada almacén del DFD debe corresponderse con una entidad dependiente o independiente del
DER.
• Los nombres de objetos en el DER deben coincidir con los nombres de los almacenes de datos
del DFD. La convención a seguir es usar el plural para los nombres de los almacenes en el
DFD y el singular para las entidades en el DER. Por ejemplo, si en el DFD tenemos un
almacén CLIENTES, en el DER deberá existir una entidad CLIENTE; esto lleva a una
definición en el dicccionario de datos como sigue:
CLIENTES = {CLIENTE}
CLIENTE = nombre + domicilio + teléfono + ...
nombre = ...

Referencias
[3] Edward Yordon. Análisis Estructurado Moderno. Prentice Hall. 1989
[4] Roger Pressman. Ingeniería del Software, un enfoque práctico. Quinta edición. Mc Graw
Hill. 2002
[5] Carlo Ghezzi y Dino Mandrioli. Fundamentals od Software Enginering. Prentice Hall. 1991
[6] Ian Sommerville. Software Enginering. Quinta Edición. Addison Wesley. 1996
[7] Tom De Marco. Structured Analysis and System Specification. Prentice Hall. 1979

Especificaciones de Software -–DFD, DD, DTE 14 Ingeniería de Software I