El diagrama de flujo de datos y sus reglas

Un diagrama de flujo de datos usa cinco piezas. La entidad externa es quien usa el sistema o lo que está fuera de él y no controlas: una persona, otro sistema, un proveedor. El proceso es código tuyo que transforma o decide algo. El almacén es donde los datos descansan: una base, un archivo, un depósito. El flujo es la flecha: un dato que va de un elemento a otro. Y la frontera de confianza es la línea que separa zonas con distinto nivel de control; se verá en la sala siguiente.

Con esas cinco piezas se dibuja casi cualquier sistema, y lo importante es que cada una sepa qué es: un servicio que lee una base es un proceso, no un almacén.

Las reglas básicas de construcción evitan los dibujos que engañan. La primera: un almacén solo habla con procesos. Nadie de fuera escribe directamente en una base o en un depósito; siempre hay un proceso en medio, y ese proceso es justo donde se decide si se deja pasar o no. Un flujo que une una entidad externa con un almacén esconde esa decisión: o falta el proceso en el dibujo, o falta el control en el sistema, y en ambos casos hay un hueco.

Abre el borrador y mira el tipo de cada extremo de cada flecha con la consulta que cruza flujos con elementos.

La segunda regla: un proceso que recibe datos tiene que producir algo, aunque sea una respuesta, un registro o un flujo hacia un almacén. Un proceso con entradas y sin ninguna salida es lo que se llama un agujero negro: o el dibujo está incompleto, o ese proceso hace algo con los datos que nadie anotó, y esa parte oculta es exactamente donde se esconden las amenazas.

La consulta de los procesos sin salida del borrador te deja ver cuál es.

La tercera regla: todo elemento del diagrama tiene al menos un flujo. Uno sin ninguna flecha es una de dos cosas: algo que sobra y se quedó dibujado, o algo que existe y se movió sin que el diagrama lo reflejara. Lo segundo es peor, porque un sistema que habla con algo que el modelo no conoce es un sistema con amenazas sin revisar.

Compara los elementos con los flujos y busca el que no aparece en ninguna flecha.

Encontrar el fallo es la mitad; la otra es decidir qué hacer con él. Ante un proceso que recibe datos y no emite nada, lo primero es preguntar al dueño del sistema qué hace en realidad con esos datos. Con la respuesta se corrige el dibujo: se añade el flujo que falta hacia donde de verdad van, sea un archivo, una dirección de correo o un panel. Quitar el proceso del diagrama sin preguntar no lo quita del sistema, solo del modelo.

El diagrama se corrige para que diga lo que el sistema hace, no para quedar limpio.