Los diagramas de flujo de datos

El diagrama de flujo de datos, abreviado DFD, es la técnica gráfica con la que el análisis estructurado representa un sistema de información. Muestra por dónde circula la información dentro de los procesos de negocio: de dónde llega cada dato, qué funciones lo transforman, dónde se guarda y hacia dónde sale.

Es análisis funcional, y esa es su diferencia esencial con el modelo entidad-relación. El modelo entidad-relación describe qué datos existen y cómo se relacionan entre sí; el DFD describe qué hace el sistema con esos datos. Son las dos caras del mismo análisis y se construyen en paralelo, pero responden a preguntas distintas.

El equivalente del DFD en el enfoque orientado a objetos, es decir en UML, es el diagrama de actividad. Es la equivalencia que se pregunta cuando el enunciado contrapone análisis estructurado y orientado a objetos.

Lo que el DFD deliberadamente no dice es cuándo ocurre cada cosa, con qué tecnología se implementa ni en qué orden se ejecutan los procesos. Es un modelo de qué hace el sistema, no de cómo ni cuándo lo hace, y por eso sirve para hablar con el usuario antes de haber decidido nada técnico.

Un sistema entero no cabe en un solo diagrama legible, así que el DFD se construye por descomposición funcional descendente (top-down): se empieza por una visión de conjunto y cada proceso se va abriendo en un diagrama propio más detallado. Cada apertura es un nivel.

En el nivel 0 solo importan las relaciones con el exterior: hay una única burbuja y ningún almacén. Los almacenes no aparecen hasta el nivel 1, y ese es el detalle que más se pregunta de toda la descomposición.

El diagrama de contexto sirve para fijar la frontera del sistema, que es la primera decisión del análisis: qué queda dentro y qué queda fuera. Todo lo que quede fuera será una entidad externa, y a partir de ahí el sistema solo se relaciona con ello mediante flujos.

Los flujos no son todos iguales, y distinguirlos es lo que más se pregunta de esta técnica. La primera clasificación atiende a qué hace el proceso con el almacén al que se conecta.

La segunda clasificación atiende al momento en que ocurren las dos puntas del flujo. Un flujo es síncrono cuando conecta directamente dos procesos: el dato pasa de uno al otro en el mismo instante, así que ambos tienen que estar activos a la vez. Un flujo es asíncrono cuando por medio hay un almacén: un proceso deja el dato y otro lo recoge más tarde, sin que ninguno tenga que esperar al otro.

Lo que hace asíncrono a un flujo es la presencia de un almacén. El almacén desacopla en el tiempo a los dos procesos: quien escribe y quien lee no necesitan coincidir.

Hay además un flujo especial, el flujo de control o de evento, que no transporta datos sino una señal. Enlaza dos procesos de forma que, al ejecutarse el primero, se desencadena el segundo. Es un disparador, y actúa de forma asíncrona: quien lanza el evento no se queda esperando el resultado.

Un DFD no admite cualquier combinación de elementos. Los flujos son direccionales, es decir, la flecha indica siempre hacia dónde va el dato, y solo se permiten tres conexiones.

En las dos conexiones prohibidas la solución es siempre la misma: intercalar un proceso. Si dos almacenes o dos entidades externas necesitan intercambiar algo, tiene que haber una función del sistema que lo haga.

Detrás de esa restricción hay un principio: el almacén es pasivo. No transforma nada por su cuenta ni toma iniciativa; su contenido solo cambia si un proceso lo cambia. Un diagrama donde un almacén parece actuar por sí mismo está mal construido.

• No solo los procesos se descomponen: un flujo puede abrirse en los flujos concretos que lo componen, y un almacén en los almacenes de detalle que contiene.
• Todos los niveles deben estar balanceados: lo que entra y sale de un proceso tiene que coincidir exactamente con lo que entra y sale del diagrama que lo desarrolla.
• Cada nivel es coherente con el superior: no se pueden inventar en un nivel flujos de entidades externas que no estuvieran ya en el nivel anterior.

El balanceo es el criterio de corrección que se comprueba en examen. Si al abrir un proceso aparece un flujo nuevo que venía de una entidad externa no declarada arriba, el diagrama es incoherente: o falta ese flujo en el nivel superior o sobra en el inferior.

CASE son las siglas de ingeniería de software asistida por computador. Una herramienta CASE es un programa que ayuda a construir software apoyando las tareas del ciclo de vida, sobre todo las de análisis y diseño: dibujar y validar modelos como los diagramas de flujo de datos, mantener un diccionario de datos, generar código a partir de los diagramas y documentar.

Su valor no está en dibujar, que se podría hacer a mano, sino en comprobar: una herramienta CASE detecta que un DFD no está balanceado, que un flujo conecta dos almacenes o que un dato se usa en un nivel sin estar declarado. Ese control automático de coherencia es lo que hace viable mantener un modelo de varios niveles.

Se llama entorno I-CASE (CASE integrado) al que cubre el ciclo de vida completo combinando varias herramientas que comparten un mismo repositorio. Suelen distinguirse las de las fases iniciales (Upper CASE: planificación, análisis y diseño) de las de las fases finales (Lower CASE: generación de código, pruebas y mantenimiento).

XMI es el formato con el que las herramientas CASE se intercambian modelos entre sí. Es un lenguaje basado en XML, y es lo que permite exportar un modelo UML de una herramienta e importarlo en otra.