Diagrama de Contexto y DFD Nivel 0

Ver el sistema desde afuera, antes de abrirlo

Hasta ahora modelaste sistemas con cajas de Entrada-Proceso-Salida, jerarquías y bucles de retroalimentación. Para el sistema real de tu proyecto final —una organización, un proceso de negocio, un servicio, con o sin software de por medio— hace falta un lenguaje más preciso para decir exactamente qué entra, qué sale y quién está afuera. Ese lenguaje es el Diagrama de Flujo de Datos (DFD), y empieza con una sola caja.

Armemos el diagrama en vivo, capa por capa, con el proceso de ventas de un almacén de barrio →

La frontera del sistema

Todo sistema tiene un límite que separa lo que está adentro (lo que vas a modelar) de lo que está afuera (el entorno). En un DFD, esa frontera se dibuja explícitamente alrededor de una única caja que representa, por ahora, todo el sistema como una sola unidad — sin abrir todavía cómo funciona por dentro.

Primer actor: el Cliente

Un actor externo (o entidad externa) es cualquier persona, sistema u organización que está fuera de la frontera pero intercambia información con el sistema. El Cliente manda datos de pedido hacia adentro — sin ser parte del sistema que estás modelando.

Segundo actor: el Administrador

El Administrador (el dueño o encargado del almacén) también está afuera de la frontera, aunque trabaje todos los días con el sistema: actualiza precios y consulta reportes de ventas. Estar "afuera" no significa estar lejos — significa que no es una parte interna del sistema, sino alguien que lo usa desde su entorno.

Tercer actor: otra organización

No todos los actores externos son personas. El Proveedor es otra organización, con su propia frontera, que intercambia información con la tuya: le mandás una solicitud de reposición de mercadería y te devuelve la confirmación de la entrega — todo esto puede pasar por teléfono o papel, sin una sola línea de código de por medio, y sigue siendo perfectamente modelable en un DFD. Con estos tres actores y sus flujos, ya tenés un Diagrama de Contexto completo.

Lo mismo que ya conocías, con otro nombre

Si ya viste diagramas UML, esto te va a sonar conocido: un actor externo del DFD es prácticamente lo mismo que un actor en un diagrama de casos de uso, y la frontera del sistema es el mismo rectángulo que UML dibuja alrededor de los casos de uso. La TGS y UML llegan al mismo concepto —qué es el sistema y qué es su entorno— desde dos vocabularios distintos.

Abrimos la caja: DFD Nivel 0

El Diagrama de Contexto trata al sistema como una sola caja opaca — una caja negra. El siguiente paso es abrirla y mostrar sus procesos principales por dentro: 1 Registrar Pedido, 2 Reponer Stock y 3 Generar Reporte. Cada uno es un proceso más chico, numerado, que transforma parte de los datos que entran — y no tiene por qué estar automatizado: "Reponer Stock" puede ser, en la práctica, el encargado llamando por teléfono al Proveedor.

Los procesos no viven aislados

Adentro de la frontera, los procesos se conectan entre sí y con un almacén de datos —acá, D1: Pedidos— donde queda guardado lo que Registrar Pedido creó, para que Reponer Stock y Generar Reporte lo lean después. Ese almacén tampoco tiene que ser una base de datos: puede ser un cuaderno de pedidos o una planilla de cálculo — lo que importa es el rol que cumple, no la tecnología. Los actores externos siguen mandando y recibiendo los mismos flujos que en el Diagrama de Contexto; lo único que cambió es que ahora ves el mecanismo interno.