Diagrammi di Flusso dei Dati (DFD): Livelli, Simboli ed Esempi Pratici
Impara a creare diagrammi di flusso dei dati con la notazione corretta. Copre i livelli DFD 0-2, i simboli Yourdon-DeMarco vs Gane-Sarson ed esempi reali.
Quando un sistema si blocca o un processo produce output errati, la prima domanda è di solito: "dove sono andati storto i dati?" I diagrammi di flusso dei dati (DFD) rispondono a questa domanda rendendo esplicito il movimento dei dati — mostrando esattamente da dove provengono i dati, dove vanno, come vengono trasformati e dove vengono memorizzati.
A differenza dei diagrammi di flusso che modellano il flusso di controllo (cosa succede dopo), i DFD modellano il flusso di dati (quali dati si spostano dove). Questa distinzione li rende lo strumento giusto per l'analisi dei sistemi, la progettazione del software e la documentazione di integrazioni di dati complesse.
Cos'è un diagramma di flusso dei dati?
Un diagramma di flusso dei dati è una rappresentazione visiva di come i dati si muovono all'interno di un sistema. Mostra:
- Entità esterne — fonti e destinazioni dei dati al di fuori del sistema
- Processi — trasformazioni che convertono i dati di input in dati di output
- Archivi di dati — luoghi dove i dati vengono conservati a riposo
- Flussi di dati — il movimento dei dati tra gli elementi sopra descritti
I DFD non mostrano la tempistica, la logica decisionale o chi esegue i task. Mostrano esclusivamente il movimento dei dati. Questo ambito focalizzato li rende utili per comprendere e progettare sistemi senza perdersi nei dettagli implementativi.
Simboli DFD
Due notazioni dominano: Yourdon-DeMarco e Gane-Sarson. Rappresentano gli stessi concetti con forme diverse.
Notazione Yourdon-DeMarco
La notazione originale di analisi strutturata, ampiamente utilizzata nell'ingegneria del software:
| Elemento | Simbolo | Descrizione |
|---|---|---|
| Processo | Cerchio (bolla) | Trasforma i dati; etichettato con una frase verbale |
| Archivio dati | Rettangolo aperto | Memorizza i dati; etichettato con un sostantivo |
| Entità esterna | Rettangolo | Fonte o destinazione esterna al sistema |
| Flusso di dati | Freccia con etichetta | Dati denominati che si spostano tra gli elementi |
┌──────────┐ ╭──────────╮ ┌═══════════════╗
│ Cliente │───────→ │ Valida │───────→ ║ D1: Ordini ║
└──────────┘ Ordine │ Ordine │ Ordine ╠═══════════════╣
╰──────────╯ Valido ║ ║
Notazione Gane-Sarson
Comune nei sistemi informativi aziendali e nell'analisi aziendale:
| Elemento | Simbolo | Descrizione |
|---|---|---|
| Processo | Rettangolo con angoli arrotondati (intestazione divisa) | Etichettato con ID e nome del processo |
| Archivio dati | Rettangolo aperto sul lato sinistro | Etichettato con numero D e nome |
| Entità esterna | Rettangolo | Fonte o destinazione esterna al sistema |
| Flusso di dati | Freccia con etichetta | Dati denominati che si spostano tra gli elementi |
┌──────────┐ ┌────────────────┐ ┌═══╦════════════╗
│ Cliente │───────→ │ 1.0 │───────→ ║D1 ║ Ordini ║
└──────────┘ Ordine │ Valida Ordine │ Ordine ╚═══╩════════════╝
└────────────────┘ Valido
Quale notazione utilizzare?
Entrambe trasmettono le stesse informazioni. La scelta dipende dal contesto:
- Yourdon-DeMarco: preferita nell'ingegneria del software, nell'accademia e quando si utilizzano metodi di analisi strutturata
- Gane-Sarson: comune nei sistemi informativi aziendali e nei contesti enterprise
Scegliere una e mantenerla coerente in tutti i diagrammi di un progetto.
Livelli DFD
I DFD sono organizzati gerarchicamente. I diagrammi di livello superiore forniscono una panoramica; i diagrammi di livello inferiore forniscono dettagli. Ogni livello decompone un singolo processo del livello superiore nei suoi sotto-processi interni.
Livello 0: Diagramma di contesto
Il diagramma di contesto mostra l'intero sistema come un singolo processo, circondato da entità esterne. Definisce il confine del sistema e mostra quali dati attraversano quel confine.
Ordine Cliente
┌──────────┐ ─────────────────→ ╭──────────────────────╮
│ Cliente │ │ │
└──────────┘ ←───────────────── │ Sistema Gestione │
Conferma Ordine │ Ordini │
│ │
┌──────────┐ ─────────────────→ ╰──────────────────────╯
│ Fornitore│ Aggiornamento │
└──────────┘ Inventario ↓
┌──────────────┐
│ Elab. Pagam. │
└──────────────┘
Un diagramma di contesto deve stare su una sola pagina e mostrare solo i flussi di dati che attraversano il confine — nessun dettaglio interno. Se ci si trova ad aggiungere processi interni, si è al livello sbagliato.
Livello 1: Diagramma di panoramica
Il diagramma di livello 1 decompone il singolo processo di contesto nei suoi principali sotto-processi. Questi sono le principali aree funzionali del sistema.
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Cliente │───────→ │ 1.0 │───────→ │ 2.0 │───┐
└──────────┘ Ordine │ Ricevi │Ordine │ Elabora │ │
│ Ordine │Validato │ Pagamento│ │
╰──────────╯ ╰──────────╯ │
│ ↓
↓ ╭──────────╮
┌════════════════╗ │ 3.0 │
║ D1: Ordini ║────────────→ │ Evadi │
╚════════════════╝ Dati Ordine │ Ordine │
╰──────────╯
│
↓
┌──────────┐
│ Partner │
│Spedizione│
└──────────┘
I diagrammi di livello 1 hanno tipicamente da 3 a 7 processi. Se ce ne sono di più, considerare di raggruppare in un numero inferiore di processi di livello superiore.
Livello 2: Diagramma dettagliato
Il livello 2 decompone ogni processo di livello 1 nei suoi sotto-passaggi. Ogni bolla del livello 1 ottiene il proprio diagramma di livello 2.
Per esempio, espandendo il processo 1.0 "Ricevi Ordine" dal precedente:
┌──────────┐ ╭──────────╮ ╭──────────╮
│ Cliente │──────────→ │ 1.1 │──────────→ │ 1.2 │
└──────────┘ Ordine │ Valida │ Dati │ Controlla│
Grezzo │ Formato │ Validi │ Stock │
╰──────────╯ ╰──────────╯
│ │ │
Ordine │ Disponibile
Non Valido Esaurito │
↓ Stock ↓
┌──────────┐ ╭──────────╮
│ Cliente │ │ 1.3 │
└──────────┘ │ Riserva │
│ Articoli │
╰──────────╯
│
↓
┌════════════╗
║ D1: Ordini ║
╚════════════╝
Quanto in profondità bisogna andare?
Smettere di scomporre quando un processo è:
- Abbastanza semplice da descrivere in poche frasi
- Implementato da una singola persona o funzione di sistema atomica
- Già al livello di dettaglio necessario per l'implementazione
La maggior parte dei sistemi non necessita di più del livello 2. Il livello 3 è raro e spesso indica che il sistema è troppo complesso o che la scomposizione non è ben strutturata.
DFD vs diagramma di flusso
Questi vengono spesso confusi perché entrambi usano caselle e frecce. Rispondono a domande diverse.
| Aspetto | Diagramma di Flusso dei Dati | Diagramma di Flusso |
|---|---|---|
| Mostra | Come i dati si muovono in un sistema | Come il controllo fluisce in un processo |
| Domanda primaria | Dove vanno i dati? | Cosa succede dopo? |
| Tempo/sequenza | Non modellato (solo trasformazioni) | Centrale — la sequenza è la struttura principale |
| Logica decisionale | Non rappresentata | Esplicita (nodi decisionali a rombo) |
| Chi esegue | Non mostrato | Può mostrare con il formato a corsie |
| Archiviazione dati | Simbolo esplicito di archivio dati | Non rappresentata |
| Ideale per | Analisi dei sistemi, architettura dati | Documentazione di processo, guide procedurali |
Un diagramma di flusso mostra i passaggi in un processo di approvazione del credito. Un DFD mostra quali dati riceve il sistema di domande di credito, dove vengono memorizzati e quali output produce.
Usare un DFD quando si sta analizzando o progettando un sistema. Usare un diagramma di flusso quando si sta documentando una procedura.
Passo dopo passo: creare un DFD
Passo 1: Definire il confine del sistema
Identificare cosa è interno al sistema e cosa è esterno:
- Interno: processi, archivi di dati e flussi di dati che si controllano
- Esterno: entità esterne — clienti, partner, sistemi esterni
Tutto ciò che è al di fuori del confine è un'entità esterna. I dati che attraversano il confine appaiono come flussi nel diagramma di contesto.
Passo 2: Disegnare il diagramma di contesto (Livello 0)
- Posizionare l'intero sistema come un singolo cerchio etichettato al centro
- Identificare tutte le entità esterne e posizionarle all'esterno
- Disegnare flussi di dati che attraversano il confine con etichette descrittive
- Verificare la completezza: ci sono dati che entrano o escono dal sistema senza etichetta?
Passo 3: Identificare i processi principali (Livello 1)
Scomporre il sistema in 3-7 processi principali:
- Denominare ogni processo con una frase verbale ("Valida Ordine," "Elabora Pagamento")
- Numerarli (1.0, 2.0, 3.0)
- Identificare quali flussi di dati li collegano
Passo 4: Aggiungere gli archivi di dati
Identificare dove i dati vengono conservati tra i processi:
- Database: record clienti, storico ordini, inventario
- File: file di log, configurazione
- Dati esterni: dati passati a/da sistemi esterni (spesso rappresentati come flussi di confine, non archivi interni)
Denominare ogni archivio di dati con un sostantivo e assegnare un numero D (D1, D2).
Passo 5: Collegare con i flussi di dati
Disegnare frecce etichettate tra gli elementi:
- I flussi devono avere nomi descrittivi ("ordine cliente," "record validato," "fattura")
- I flussi collegano processi a processi, processi ad archivi di dati ed entità esterne a processi
- Gli archivi di dati non si collegano direttamente alle entità esterne (i dati devono passare attraverso un processo)
Passo 6: Scomporre al Livello 2
Per ogni processo principale nel Livello 1, disegnare un diagramma di Livello 2 separato che mostri i suoi sotto-processi interni. I flussi di dati che entrano ed escono dal processo di Livello 1 diventano i flussi di confine del diagramma di Livello 2.
Passo 7: Verificare la coerenza
Controllare che:
- Ogni flusso di dati che entra in un processo venga utilizzato da quel processo
- Ogni flusso di dati che esce da un processo origini da quel processo
- Gli archivi di dati siano accessibili solo attraverso i processi (non direttamente dalle entità esterne)
- I flussi di confine di Livello 1 corrispondano ai flussi del diagramma di contesto
Esempio reale: sistema di ordini e-commerce
Livello 0: Diagramma di contesto
┌──────────┐ Richiesta Ordine ╭──────────────────────╮
│ Cliente │ ────────────────→ │ │
└──────────┘ │ Sistema Ordini │
↑ Stato Ordine │ E-Commerce │
└───────────────────────── │ │
╰──────────────────────╯
┌──────────┐ Risultato Pagam. │ ↑
│Passarella│ ────────────────→ │ │
│Pagamento │ ←──────────────── │ Dati
└──────────┘ Richiesta Addebito ↓ Spedizione
┌──────────────┐
│ Partner │
│ Spedizione │
└──────────────┘
Livello 1: Processi principali
Cliente ─── Richiesta Ordine ──→ ╭──────────╮
│ 1.0 │ ──→ D1: Ordini
│ Valida │
│ Ordine │
╰──────────╯
│
Ordine Validato
↓
Pass. Pagam. ←── Addebito ── ╭──────────╮ ── Registr. ──→ D2: Pagamenti
Richiesta │ 2.0 │ Pagamento
Pass. Pagam. ── Risultato ──→ │ Elabora │
│ Pagamento│
╰──────────╯
│
Ordine Confermato
↓
╭──────────╮
D1: Ordini ── Dati Ordine ──────→ │ 3.0 │ ── Richiesta Spediz. ──→ Partner
D3: Prodotti ─ Dati Stock ───────→ │ Evadi │ Spediz.
│ Ordine │
╰──────────╯
│
Dati Spedizione
↓
╭──────────╮
│ 4.0 │ ── Aggiornamento ──→ Cliente
│ Traccia │ Stato
│ e Notifica│
╰──────────╯
Errori comuni nei DFD
Collegare le entità esterne direttamente agli archivi di dati. Gli archivi di dati sono interni; le entità esterne non possono accedervi direttamente. Tutti i dati che attraversano il confine del sistema devono passare attraverso un processo.
Flussi di dati senza etichetta. Ogni freccia deve avere un nome descrittivo. "Dati" o "Info" non sono descrittivi. Un flusso dovrebbe essere denominato per ciò che i dati rappresentano: "ordine cliente," "conferma pagamento," "livello di stock."
Processi senza input o output. Un processo deve avere almeno un flusso di input e uno di output. Un cerchio senza dati in ingresso "crea" dati dal nulla — non è un processo, è un'entità esterna. Un cerchio senza dati in uscita scarta tutto — modellarlo come scrittura su archivio o rimuovere il processo.
Mischiare il flusso di controllo con il flusso di dati. Le decisioni, la sequenza e la logica di controllo non appartengono ai DFD. Se ci si trova a disegnare rombi decisionali, si sta creando un diagramma di flusso, non un DFD. I DFD mostrano solo il movimento dei dati.
Troppi dettagli al livello 1. Il livello 1 dovrebbe avere da 3 a 7 processi principali. Se se ne mostrano 15 al livello 1, si è saltata la scomposizione gerarchica. Raggruppare i processi correlati in bolle di livello superiore e usare il livello 2 per mostrare i dettagli.
Livelli incoerenti. I flussi di dati che entrano nel processo 2.0 nel diagramma di livello 1 devono corrispondere ai flussi di confine nel diagramma di livello 2 per il processo 2.0. L'incoerenza significa che i diagrammi non rappresentano lo stesso sistema.
Archivi di dati condivisi tra sottosistemi senza spiegazione. Se più processi accedono allo stesso archivio di dati, assicurarsi che sia intenzionale e che l'accesso abbia senso. L'uso eccessivo di un unico archivio "database principale" nasconde importanti decisioni sull'architettura dei dati.
Creare diagrammi di flusso dei dati con Flowova
Mappare manualmente i flussi di dati è tedioso — identificare tutti i flussi di confine, numerare i processi in modo coerente e mantenere i livelli sincronizzati richiede uno sforzo significativo.
Il creatore di diagrammi di flusso dei dati di Flowova genera strutture DFD da descrizioni di sistema in linguaggio naturale. Descrivere gli input, gli output e i processi principali del sistema, e ottenere un diagramma abbozzato da perfezionare. Questo è particolarmente utile per creare rapidamente diagrammi di contesto e panoramiche di livello 1, per poi approfondire i dettagli di livello 2 per i processi che ne hanno bisogno.
Conclusione
I DFD sono lo strumento giusto quando è necessario comprendere o comunicare come i dati si muovono attraverso un sistema — non cosa succede passo dopo passo, ma da dove originano i dati, cosa li trasforma, dove vengono memorizzati e dove vanno alla fine.
Iniziare con un diagramma di contesto per stabilire il confine del sistema. Scomporre al livello 1 per identificare i processi principali. Andare al livello 2 solo per i processi che necessitano di ulteriori chiarimenti. Mantenere i flussi di dati denominati in modo specifico, evitare di mischiare la logica di controllo nel diagramma e verificare la coerenza tra i livelli.
Risorse correlate
- Simboli e Significati del Diagramma di Flusso — Riferimento per la notazione standard
- Guida ai Diagrammi BPMN — Standard di modellazione dei processi aziendali
- Creatore di Diagrammi di Flusso dei Dati — Crea DFD con l'AI
- Template di Architettura di Sistema — Template di diagrammi di architettura pronti all'uso
