Un Diagrama Flujo de Datos es una representación estructurada y gráfica que describe cómo circula la información a través de un sistema y los diferentes procesos de transformación a los que se ve sometida. Permite visualizar un sistema como una red de procesos funcionales, conectados entre mediante flujos de datos. Es una de las herramientas más usadas en sistemas computacionales en los que las funciones del sistema son de gran importancia y son más complejas que los datos que éste maneja.

Es un modelo lógico (no físico) que representa qué hace el sistema y no cómo. Es comprensible por el usuario. Muestra cualquier nivel de detalle y, el flujo de la información asociada. Sirve para identificar y dar nombre a las fuentes de datos, destinos de los datos, flujos de datos, almacenes de datos y, procesos.

El DFD se desarrolla con un enfoque descendente y está sujeto a una notación y a unas reglas predefinidas que buscan producir un documento conciso y autoorganizado. El DFD se compone de Entidades Externas, flujos de datos, funciones o procesos y almacenes de datos.

En un DFD se utilizan símbolos gráficos para representar procesos, entidades externas, flujos de datos y almacenes de datos. Veamos cada uno de estos componentes:

Muestra una parte del sistema que transforma entradas en salidas, es decir, muestra cómo es que una o más entradas se transforman en salidas. Actividad definida y predecible que transforma flujos de datos con el fin de conseguir un cierto objetivo. Se representa gráficamente por un círculo. El proceso se nombre o describe con una sola palabra, frase u oración sencilla, que describirá lo que hace el proceso.

Información que circula de un objeto del diagrama a otro. Puede representar un dato elemental o una estructura de datos. Se representa gráficamente por una flecha que entra o sale de un proceso. Se usa para describir el movimiento de bloques de información de una parte a otra del sistema, por lo que representan datos en movimiento. El nombre del flujo de datos describe el tipo de información que se transporta.

Conjunto de datos siempre disponible donde los datos quedan retenidos. Se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas. El nombre que se utiliza para denotar al almacén es el plural del que se utiliza para los datos que almacena. La información almacenada está en reposo. Es independiente de la implementación física.

Los flujos que van hacia el almacén se interpretan como una escritura, una actualización o una eliminación de información del almacén. Los flujos que salen del almacén se interpretan como una lectura o un acceso a la información del almacén.

Se representa gráficamente por un rectángulo y representa las entidades externas con las que el sistema se comunica. Existen tres cosas importantes acerca de los agentes externos:

• Son externos al sistema que se está modelando; los flujos que los conectan a los distintos procesos representan la interfaz entre él y el mundo exterior.
• No es posible cambiar el contenido del agente externo, ya que está fuera del dominio del cambio.
• Las relaciones existentes entre los agentes externos, no se muestran en el DFD.
• No es relevante ni como obtiene la información ni qué hace con ella.

La técnica del DFD se basa en el principio de descomposición de la funcionalidad de un sistema en sucesivos niveles de refinamiento (enfoque top-down) cuyo objetivo es permitir una lectura de la especificación del sistema desde lo abstracto al detalle, permitiendo ver el sistema de forma global (niveles superiores), o de forma detallada (niveles inferiores). Se organiza así el DFD global en una serie de niveles de modo que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior. Así se parte de un diagrama general o Diagrama de Contexto en el que se representa una sola función con el nombre del sistema, las entidades externas que se relacionan con el sistema y, los flujos de entrada y salida al sistema. El siguiente nivel conocido como DFD/0 representa la vista de más alto nivel de las principales funciones del sistema, al igual que sus principales interfaces. Y así sucesivamente. La descomposición de cada subsistema no se detiene en un nivel determinado, sino que dependen del grado de complejidad del sistema. Normalmente se suele recomendar no utilizar más de 4 niveles y que en cada nivel no aparezcan más de 9 funciones.

Veamos algunos aspectos de cada nivel:

• Diagrama de Contexto (Nivel inicial). El objetivo de este diagrama es la delimitación del dominio del sistema que se está estudiando. Formado por una única función, que representa al sistema completo y, el contexto del mismo.
• Diagrama nivel 0 (DFD/0). En este diagrama se especifican las funciones más importantes del sistema, cada una de las cuales será llevada por una parte del sistema. Podemos encontrarnos dos posibilidades: que sea igual al DC o, que esté formado por las funciones o áreas más importantes del sistema.
• Diagrama nivel 1 (DFD/1). Es un modelo de trabajo con toda la funcionalidad del sistema. No muestra errores ni excepciones. Está formado por tantos procesos como eventos o acontecimientos se hallan detectado en la lista de eventos.
• Diagramas de niveles intermedios. Corresponden a los DFD en los que se explotan o descomponen cada uno de los subsistemas.
• Diagramas de último nivel. Son aquellos en los que las funciones que aparecen no se van a descomponer en subfunciones. Tales funciones no se pueden descomponer en otro DFD pero si en un documento denominado "Especificación de Función Elemental" en el que se describe textualmente lo que debe hacer la función, pero no cómo debe hacerlo (que corresponde a la fase de diseño).

Debemos saber algunos cosas sobre la descomposición en niveles:

1. ¿Cómo saber cuántos niveles debe haber en un DFD? Cada DFD no debería tener más de 6 burbujas y almacenes relacionados. Si no es posible escribir una especificación de una función en una página, entonces es probable que sea demasiado complejo y debe descomponerse en un DFD de nivel inferior.
1. ¿Existen reglas acerca del número de niveles que debe obtenerse? No, dependerá de la complejidad del sistema.
1. ¿Deben partirse todas las partes del sistema con el mismo nivel de detalle? No, algunas partes del sistema pueden ser más complejas que otras y pueden requerir uno o más niveles de descomposición.
1. ¿Cómo asegurar que los niveles del DFD son consistentes entre sí? Para asegurarse que un DFD es consistente con su DFD de nivel superior, los flujos de datos que entran y salen de una burbuja en un nivel dado, deben corresponder con los que entran y salen del nivel inmediato inferior que lo describe.
1. ¿Cómo se muestran los almacenes en los distintos niveles? Se debe mostrar un almacén en el nivel más alto donde primeramente sirva de interfaz entre dos o más procesos; luego, mostrarlo de nuevo en cada diagrama de nivel inferior que describa más a fondo dichos procesos.

Veamos algunas recomendaciones para la construcción de un DFD:

1. Identificar las entidades externas al sistema y, sus flujos de entrada y salida. Es decir, establecer el contexto del sistema.
1. Elegir nombres adecuados para todos los objetos del diagrama, evitando términos demasiado generales o ambiguos.
1. Ignorar la inicialización y terminación del sistema. Un DFD no representa el flujo de ejecución de un sistema, sino los datos que maneja, por lo que se puede suponer que el sistema ya está en funcionamiento y que nunca termina.
1. Ignorar el flujo de control. Los flujos de datos válidos son aquellos que son recibidos por una función que los modifica y los vuelve a generar como flujo de salida o como parte de un flujo de salida.
1. Evitar los DFD demasiado complejos, con demasiados flujos, procesos, almacenes y agentes externos.
1. Omitir tratamiento de errores.
1. Refinar los DFD constantemente. El diseño de un DFD es un proceso iterativo, por lo que habrá que hacer revisiones y modificaciones periódicas hasta obtener la versión definitiva. Es importante dedicar tiempo a esta labor ya que los posibles errores introducidos en un DFD será errores de análisis que se arrastrarán a lo largo de las siguientes fases del ciclo de vida del sistema.
1. Asegurase de que el DFD sea lógicamente consistente, evitando sumideros infinitos (procesos que solo tienen entradas pero no salidas), burbujas de generación espontánea (tienen salida sin tener entradas), flujos no etiquetados, almacenes de solo lectura o solo escritura.

El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el analista como el usuario tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos intermedios. Sirve como descripción lógica del sistema y documenta: todos los flujos incluidos en el DFD, todos los almacenes de datos, la actividad de los procesos, las entidades externas. El diccionario de datos define los datos haciendo:

• Describe un significado de los flujos y almacenes que se muestran en los DFD.
• Describe la composición de agregados de paquetes de datos que se mueven a lo largo de los flujos.
• Describen la composición de los paquetes de datos en los almacenes.
• Especifica los valores y unidades relevantes de piezas elementales de información en los flujos de datos y en los almacenes de datos.
• Describe los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación.

Para comprobar que un DD es correcto se deberá comprobar si todos los flujos del DFD se han definido en el diccionario, si se han definido todos los componentes de los datos, si se ha definido un dato más de una vez y, si se ha utilizado la notación correcta.

La definición de un dato se introduce con el símbolo "=", que se lee: "se define como", "se compone de", "significa". Para definir por completo un dato, nuestra definición debe incluir: la composición del dato, si se compone de partes elementales con significado; los valores que puede tomar el dato, si es un dato elemental que no puede descomponerse más.

Las partes elementales de los datos son aquellas para las cuales ya no existe una descomposición con significado dentro del contexto del ambiente de usuario. Cuando se han identificado todos los datos elementales, deben introducirse en el DD con una breve narrativa describiendo su significado en el contexto del usuario.

Un dato opcional es que que puede estar o no presente en un dato compuesto. Van encerrados entre paréntesis y deben verificarse con el usuario.

La notación de iteración se utiliza para indicar la ocurrencia repetida de un componente de un dato. Se lee como "cero o más ocurrencias de".

La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Las opciones se encierran entre corchetes y, se separan con una barra vertical. Es importante revisar las opciones de selección con el usuario para cubrir todas las posibilidades.

Un alias es una alternativa de nombre para un dato. Se incluye en el DD y se relaciona con el nombre primario u oficial del dato. Por ejemplo:

comprador = *alias de cliente*

Comprador no muestra su composición ya que estos detalles aparecen en el nombre primario y así se evita la redundancia en el modelo. Debe evitarse el uso de alias en la medida de lo posible.

Cuando un proceso puede describirse en un espacio razonable, ya no es necesario descomponerlo en otros subprocesos. Se dice entonces que se trata de un proceso primitivo o elemental, al que se debe asociar una especificación de proceso. La Especificación del Proceso es la descripción de qué es lo que sucede en cada burbuja primitiva de nivel más bajo en un DFD. Debe expresarse de una manera que pueda verificar tanto el usuario como el analista y de forma que pueda ser comunicada efectivamente al público amplio que esté involucrado. Una buena herramienta de especificación de proceso no debe imponer o aplicar decisiones de diseño e implementación arbitrarias.

Existen varias formas de describir la lógica de un proceso:

• Mediante un Texto Narrativo. Se debe evitar esta opción porque puede producir frases oscuras(no obstante, sin embargo, etc.), rangos indefinidos ("hasta un 20 con descuento, más de 20 al 50%" ¿y con 20?), frases con y/o ("los clientes que nos compran más de 1 millón al año y tienen una buena historia de pagos o que han tenido tratos con nosotros por más de 20 años..."), adjetivos indefinidos ("buena historia de pagos").
• Mediante Lenguaje Natural Estructurado. Se trata de limitar el lenguaje natural obligando a la utilización de un vocabulario limitado: verbos infinitivos precisos (sumar, calcular,...), términos definidos en el DD, palabras reservadas para la formulación lógica (Repetir, Si...) y una sintaxis limitada a base de constructores predefinidos (Hacer Mientras, Repetir Hasta,...). esta técnica también se conoce como seudocódigo.
• Mediante Árboles de Decisión. Pueden resultar no válidos en situaciones complejas con gran número de condiciones e implicaciones, ya que no aseguran que se hayan considerado todas las opciones.

• Mediante Tablas de Decisión. Son más precisas dado que permiten reflejar todas las situaciones posibles, pero son más difíciles de entender por el usuario. Se crea listando todas las variables (lógicas) relevantes y todas las acciones relevantes a su lado izquierdo. A continuación, se lista en columnas separadas cada combinación posible de valores de las variables; cada columna se conoce como regla y describe una acción que debe llevarse a cabo para una combinación específica de valores de las variables.

• Mediante Diagramas de Flujo. Muestra una lógica secuencial y de tipo procedimiento. Muy pocos analistas utilizan este método.

Los DFD se pueden verificar utilizando tres tipos de pruebas: de exactitud, de comprensión y de cohesión.

Se trata de comprobar que el DFD refleja lo que realmente hace o debe hacer el sistema modelado. Este tipo de pruebas implica varios aspectos:

• Mantenimiento: se trata de comprobar que no haya flujos de datos sin nombre o con nombre ambiguo, que cada flujo está definido en el DD, de detectar y eliminar todos los flujos falsos y, por último, de comprobar que los nombres de las funciones son correctos.
• Errores de consistencia: se trata de comprobar que el DFD no sea autocontradictorio ni tenga funciones redundantes.
• Conservación de datos: hay que comprobar que todas las funciones cumplen la regla de conservación de datos: "una función debe ser capaz de construir sus salidas usando solamente la información suministrada por los flujos de entrada más los datos constantes (internos en la función)".
• Problemas de almacenes: comprobación de que no existan almacenes de datos de solo lectura o solo escritura.
• Errores conceptuales: conviene revisar el DFD con el usuario para comprobar si se ha entendido correctamente sus especificaciones.

Puede que un DFD sea muy difícil de leer y comprender. Para obtener un DFD legible se recomienda someterlo a varias pruebas:

• Complejidad de la interfaz: comprobar que no es excesivo el número de flujos que entran y salen de un proceso y que se entienden sus nombres.
• Nombres de los procesos: hay que evitar nombres ambiguos. Se deben usar nombres con verbos de acción fuerte y acoplarlo con un objeto explícito simple.
• Descomposición desigual: se trata de descomponer los procesos de la forma más igualada posible. Será desigual si en un mismo nivel existen procesos primitivos junto a otros que necesitan ser descompuestos en varios niveles más.

Se trata de obtener una versión mejorada del DFD. Comprobar que no existen redundancias, que no falten procesos y que sean totalmente coherentes.