Documente Academic
Documente Profesional
Documente Cultură
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
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).
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.
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
VALIDAR
CALLE
calle
Figura 6
calle OBTENER
CALLE
Figura 7
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.
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.
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
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.
• 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
• 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 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”.
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.
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
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ó “Consulta de
Se pulsó “Consulta de Saldo” Ultimos Movimientos”
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