Un diagramma di flusso del processo di sviluppo software converte una sequenza di passaggi, decisioni e risultati in un diagramma che chiunque può leggere in pochi secondi. Mentre un paragrafo di testo richiede un'attenta lettura per comprendere l'ordine delle operazioni e le condizioni che ne modificano il percorso, un diagramma di flusso lo mostra spazialmente: inizia qui, fai questo, verifica quella condizione, diramati a sinistra o a destra, continua fino alla fine. Questa rappresentazione spaziale è il motivo per cui i diagrammi di flusso rimangono uno degli strumenti di diagrammazione più utilizzati nell'ingegneria del software, a più di settant'anni dalla loro introduzione.
Questa guida illustra tutto ciò che è necessario per leggere, creare e applicare i diagrammi di flusso in un contesto di sviluppo software: i simboli standard e il loro significato, i diversi tipi di diagrammi di flusso e quando utilizzare ciascuno di essi, esempi pratici in un formato che è possibile copiare e visualizzare immediatamente, e come i diagrammi di flusso si collegano al codice effettivo che rappresentano, incluso come tale collegamento può essere generato automaticamente anziché disegnato a mano.
Diagrammi di flusso che si aggiornano automaticamente
SMART TS XL Genera diagrammi di flusso accurati direttamente dal codice sorgente, senza bisogno di disegni manuali.
Saperne di piùChe cos'è un diagramma di flusso nello sviluppo software?
Un diagramma di flusso è un diagramma che rappresenta un processo, un algoritmo o un flusso di lavoro utilizzando simboli standardizzati collegati da frecce che indicano la direzione del flusso. Nello sviluppo software, i diagrammi di flusso mappano la logica di un programma o di un processo: la sequenza delle operazioni, i punti in cui il programma prende decisioni e i diversi percorsi che l'esecuzione può intraprendere a seconda di tali decisioni.
I diagrammi di flusso risalgono agli anni '1920 nell'ingegneria industriale, dove venivano utilizzati per documentare i processi produttivi. La tecnica è stata formalizzata per l'informatica negli anni '1940 e '1950 e, quando la programmazione strutturata è diventata una pratica standard negli anni '1970, i diagrammi di flusso erano già diventati una parte fondamentale della documentazione di progettazione del software. Oggi, i diagrammi di flusso sono ancora ampiamente utilizzati per la progettazione di algoritmi, la documentazione di onboarding, la mappatura dei processi aziendali e la comunicazione della logica a interlocutori non tecnici, anche se tipologie di diagrammi più specializzate (UML, diagrammi di sequenza, diagrammi di stato) hanno assunto alcuni dei ruoli originariamente svolti dai diagrammi di flusso.
Qual è la differenza tra un diagramma di flusso e un diagramma di flusso di processo?
Questi termini vengono spesso usati in modo intercambiabile e, nella maggior parte dei contesti, ciò non crea problemi. Tuttavia, a volte si fa una distinzione: un diagramma di flusso rappresenta tipicamente la logica di un singolo algoritmo o programma, le decisioni, i cicli e le ramificazioni all'interno del codice. Un diagramma di flusso di processo (o flowchart) rappresenta più spesso un processo aziendale, la sequenza di attività che coinvolgono persone, reparti o sistemi, spesso senza la logica decisionale dettagliata di un flowchart a livello di codice. In pratica, i simboli e le convenzioni sono condivisi tra entrambi e il termine che si utilizza è in gran parte determinato dal pubblico e dalle convenzioni del settore piuttosto che da un confine tecnico rigido.
Simboli dei diagrammi di flusso: la guida completa
I simboli dei diagrammi di flusso sono standardizzati in modo che qualsiasi lettore, indipendentemente dalla lingua o dal background, possa interpretarli correttamente. La tabella seguente elenca tutti i simboli utilizzati nei diagrammi di flusso standard per lo sviluppo software:
| Simbolo | Forma | Nome | Significato |
|---|---|---|---|
| ⬭ | Ovale / Rettangolo arrotondato | Terminator (Inizio/Fine) | Segna l'inizio o la fine del processo |
| ▭ | Rettangolo | Processo | Rappresenta un singolo passo, azione o operazione |
| ◇ | Diamante | Decisione | Un punto di biforcazione con due o più possibili esiti (Sì/No, Vero/Falso) |
| ▱ | Parallelogrammo | Ingresso/Uscita | Rappresenta i dati in entrata o in uscita dal processo |
| ⬡ | Esagono | Preparazione | Rappresenta una fase di configurazione, come l'inizializzazione di un contatore di ciclo. |
| ▭ (con doppio bordo) | Processo predefinito | Una chiamata a un processo o subroutine separato e già definito | |
| ⬠ | funzionalità di | Rappresenta un documento stampato o generato | |
| ○ | Piccolo cerchio | Connettore | Collega due punti nel diagramma di flusso, spesso utilizzato per evitare linee che si incrociano |
| ▽ | Triangolo (punta verso il basso) | Unire | Unisce più percorsi in uno solo |
| △ | Triangolo (punta verso l'alto) | Estratto | Divide un percorso in più |
| → | Arrow | Linea di flusso | Indica la direzione del flusso del processo |
| ⬢ | Connettore fuori pagina | Indica che il flusso continua su un'altra pagina |
I due simboli che ogni lettore deve riconoscere immediatamente sono il rettangolo (una fase del processo) e il rombo (un punto decisionale con uscite multiple). Questi due simboli da soli coprono la maggior parte del contenuto di qualsiasi diagramma di flusso. Il terminatore ovale/arrotondato che indica l'inizio e la fine completa il vocabolario minimo necessario per leggere correttamente la maggior parte dei diagrammi di flusso.
Tipologie di diagrammi di flusso utilizzati nello sviluppo software
I diversi tipi di diagrammi di flusso servono a scopi diversi. Scegliere il tipo sbagliato per la situazione produce un diagramma tecnicamente corretto ma più difficile da leggere del necessario.
| Tipo di diagramma di flusso | Cosa mostra | Ideale per |
|---|---|---|
| Diagramma di flusso del processo | Passaggi sequenziali in un unico processo | Documentare un algoritmo, la logica di una funzione o una procedura aziendale. |
| Diagramma di flusso del sistema | Come i dati si spostano attraverso i componenti hardware e software | Documentazione dell'architettura di alto livello, mappatura dei sistemi legacy |
| Diagramma di flusso Swimlane (interfunzionale) | Passaggi raggruppati in base alla persona, al team o al sistema responsabile | Processi che coinvolgono più ruoli o dipartimenti |
| Diagramma di flusso dei dati (DFD) | Come i dati si spostano tra processi, archivi ed entità esterne | Documentare le trasformazioni dei dati anziché la logica di controllo. |
| Diagramma del flusso di lavoro | Passaggio di consegne e catene di approvazione in un processo aziendale | Gestione dei progetti, flussi di lavoro di approvazione, instradamento dei ticket |
| Diagramma di attività UML | Attività simultanee e sequenziali con notazione UML formale | Documentazione di progettazione del software orientato agli oggetti |
Diagramma di flusso dati vs. diagramma di flusso: qual è la differenza?
Questo è uno dei punti di confusione più comuni e merita una risposta diretta. Un diagramma di flusso mostra il flusso di controllo : l'ordine in cui vengono eseguite le fasi e le condizioni che determinano quale percorso viene intrapreso. Un diagramma di flusso dei dati (DFD) mostra il flusso dei dati : da dove provengono i dati, quali processi li trasformano, dove vengono memorizzati e dove vanno infine, senza necessariamente mostrare l'ordine sequenziale delle operazioni o la logica decisionale.
Un diagramma di flusso risponde alle domande "cosa succede, in quale ordine e in quali condizioni?". Un diagramma di flusso dei dati risponde alle domande "da dove provengono questi dati, cosa li modifica e dove finiscono?". Molti sistemi reali traggono vantaggio da entrambi: un diagramma di flusso per documentare la logica di elaborazione e un DFD per documentare come le informazioni si muovono attraverso tale logica.
Esempi di diagrammi di flusso nello sviluppo software
La sintassi Mermaid riportata di seguito viene visualizzata direttamente in GitHub, GitLab, Notion e nella maggior parte delle moderne piattaforme di documentazione, diventando così il metodo standard per mantenere i diagrammi di flusso versionati insieme al codice, anziché gestirli come immagini statiche separate.
Diagramma di flusso del processo di base
Questo diagramma di flusso mostra lo schema canonico che ogni sviluppatore riconosce: un terminatore per iniziare, una fase del processo, un rombo decisionale con due possibili esiti e la convergenza verso un unico punto finale. Ogni diagramma di flusso, per quanto complesso, è costruito a partire da istanze ripetute di questo stesso schema.
Diagramma di flusso con un ciclo
I cicli nei diagrammi di flusso sono rappresentati da una freccia che ritorna a un punto decisionale precedente invece di continuare in avanti. Questo è l'equivalente nel diagramma di flusso di un for or while Il ciclo è un elemento fondamentale del codice ed è uno dei modelli più frequentemente testati nei corsi introduttivi di programmazione; esercizi come "disegnare un diagramma di flusso per trovare il più grande di tre numeri" e simili richiedono quasi sempre un ciclo o una struttura decisionale annidata.
Esempio di diagramma di flusso a corsie
I diagrammi a corsie (chiamati anche diagrammi di flusso interfunzionali) raggruppano le fasi di un processo in base a chi le esegue, rendendo immediatamente visibili i passaggi di consegne tra team o sistemi. Questo formato è lo standard per la documentazione dei processi aziendali che coinvolgono più reparti o parti esterne.
Come creare un diagramma di flusso del processo di sviluppo software
Passaggio 1: Definire i punti di inizio e fine. Ogni diagramma di flusso necessita di un punto di inizio chiaro e di uno o più punti di fine altrettanto chiari. Se il processo che si sta documentando non ha un inizio e una fine evidenti, l'ambito non è ancora sufficientemente definito per poterlo rappresentare efficacemente con un diagramma di flusso.
Passaggio 2: Elenca ogni passaggio in sequenza. Descrivi i passaggi in linguaggio semplice prima di assegnare i simboli. Questo separa la definizione logica dal lavoro di diagrammazione e rende più facile individuare gli errori; è molto più veloce correggere un passaggio mancante in un elenco di testo che in un diagramma disegnato solo a metà.
Passaggio 3: Identificare ogni punto decisionale. Esaminare l'elenco dei passaggi e contrassegnare ogni punto in cui l'azione successiva dipende da una condizione. Ogni punto decisionale diventa un rombo con almeno due percorsi uscenti, e ogni percorso deve essere etichettato (Sì/No, Vero/Falso o la condizione specifica).
Passaggio 4: Assegnare i simboli corretti. Associare ogni passaggio al suo simbolo: rettangoli per le azioni, rombi per le decisioni, parallelogrammi per input/output e ovali per inizio e fine. L'uso coerente dei simboli è ciò che rende un diagramma di flusso leggibile anche da chi non ha familiarità con il processo specifico.
Passaggio 5: Collegare con frecce direzionali. Ogni simbolo deve avere una chiara connessione in entrata e in uscita (tranne l'inizio, che non ha connessioni in entrata, e la fine, che non ha connessioni in uscita). Le frecce devono seguire una direzione generale coerente, in genere dall'alto verso il basso o da sinistra a destra, per evitare confusione visiva.
Passaggio 6: Convalida tracciando ogni percorso. Percorri manualmente il diagramma di flusso, seguendo ogni possibile percorso dall'inizio alla fine. Verifica che ogni ramo decisionale conduca da qualche parte, che nessun percorso termini senza raggiungere un terminatore finale e che i cicli abbiano una condizione di uscita definita.
Strumenti per la creazione di diagrammi di flusso nello sviluppo software
Per la creazione manuale di diagrammi di flusso, diversi strumenti sono standard nei flussi di lavoro di sviluppo software:
Mermaid e PlantUML sono strumenti di diagrammazione come codice: il diagramma di flusso è definito come testo e viene renderizzato automaticamente, il che ne garantisce il controllo di versione insieme al codice sorgente che documenta. Questo è l'approccio consigliato per qualsiasi diagramma di flusso che documenti la logica del codice, perché può essere aggiornato nello stesso commit della modifica al codice che descrive.
Lucidchart , Microsoft Visio e draw.io sono strumenti di diagrammazione generici con interfacce drag-and-drop, adatti alla documentazione dei processi aziendali, alle presentazioni e ai diagrammi gestiti al di fuori di un sistema di controllo di versione.
Gli strumenti di lavagna virtuale (lavagne fisiche, Miro, FigJam) sono adatti per le sessioni di progettazione collaborativa in cui il diagramma di flusso è un artefatto di lavoro durante una discussione piuttosto che un documento permanente.
Il compromesso tra queste categorie risiede nella sincronizzazione: i diagrammi gestiti manualmente in Lucidchart o Visio diventano obsoleti man mano che il processo o il codice sottostante cambiano, perché l'aggiornamento del diagramma richiede un passaggio manuale separato che è facile dimenticare. I diagrammi come codice e la generazione automatica risolvono entrambi questo problema, vincolando l'accuratezza del diagramma a un processo automatizzato anziché alla memoria umana.
Generazione automatica di diagrammi di flusso a partire da codice esistente
Disegnare manualmente un diagramma di flusso per un nuovo progetto funziona bene. Disegnare manualmente un diagramma di flusso per documentare un sistema esistente, complesso e non documentato non è scalabile e produce un diagramma che risulta già obsoleto al momento del completamento, qualora il codice sottostante subisca modifiche durante il processo di documentazione.
Per le codebase esistenti, in particolare i sistemi di grandi dimensioni o legacy, la generazione automatizzata di diagrammi di flusso analizza il codice sorgente effettivo e produce il diagramma di flusso direttamente dal suo flusso di controllo, ogni ifOgni ciclo, ogni chiamata di funzione viene rappresentata come il corrispondente simbolo del diagramma di flusso, senza che sia necessario che un essere umano tracci manualmente la logica in anticipo.
Questa distinzione è fondamentale soprattutto per i sistemi legacy. Un programma COBOL modificato da una dozzina di sviluppatori nel corso di vent'anni ha accumulato una logica condizionale che nessuno comprende appieno. Un diagramma di flusso disegnato manualmente di quel programma richiederebbe che qualcuno leggesse e interpretasse correttamente ogni riga, proprio il problema che il diagramma di flusso dovrebbe risolvere. La generazione automatica a partire dal codice sorgente effettivo produce un diagramma di flusso accurato, indipendentemente dal livello di comprensione del programma da parte di chiunque, perché deriva da ciò che il codice effettivamente fa, piuttosto che da ciò che qualcuno crede che faccia.
Come SMART TS XL Genera diagrammi di flusso dal tuo codice sorgente
SMART TS XL Genera diagrammi di flusso, grafici delle chiamate e diagrammi di dipendenza direttamente dall'analisi del codice sorgente, COBOL, JCL, Java, Python, RPG e altri linguaggi, senza richiedere agli sviluppatori di disegnarli manualmente. Questo approccio è fondamentalmente diverso da quello degli strumenti di diagrammazione generici come Lucidchart o Visio, che forniscono aree di disegno ma non sono in grado di comprendere cosa faccia effettivamente il codice.
La funzionalità di visualizzazione del codice analizza il flusso di controllo di un programma e genera automaticamente un diagramma di flusso accurato della sua logica decisionale, dei rami e dei cicli. Per un programma COBOL legacy con decenni di logica condizionale accumulata, ciò significa che è possibile generare un diagramma di flusso completo e preciso in pochi istanti, anziché richiedere giorni di lettura manuale del codice e di disegno del diagramma.
Poiché il diagramma di flusso viene generato direttamente dallo stato attuale del codice sorgente, non può perdere la sincronizzazione come accade con un diagramma gestito manualmente. Ogni volta che il programma sottostante cambia, la rigenerazione del diagramma di flusso produce un diagramma aggiornato che riflette la logica corrente effettiva, risolvendo il problema di sincronizzazione che affligge ogni team che si affida a documentazione di processo disegnata manualmente.
Per i team che documentano sistemi complessi, la funzionalità di mappatura delle dipendenze delle applicazioni estende questa capacità oltre i diagrammi di flusso di singoli programmi, mostrando come più programmi, flussi di lavoro e fonti di dati si connettono all'interno di un intero portfolio di applicazioni, rispondendo non solo alla domanda "cosa fa questo programma?" ma anche a "a cosa si connette questo programma e a cosa si connette?". Come descritto nel contesto delle tecniche di visualizzazione del codice , i diagrammi generati automaticamente risolvono il problema dell'obsolescenza che rende inaffidabile la documentazione gestita manualmente in qualsiasi sistema in fase di sviluppo attivo.
I diagrammi di flusso sono uno strumento di comunicazione, non solo un documento.
Il valore di un diagramma di flusso non risiede nel diagramma in sé, ma nella comprensione condivisa che esso genera tra chiunque lo osservi. Un diagramma di flusso che rappresenta accuratamente un processo, ma a cui nessuno fa riferimento durante lo sviluppo, la revisione del codice o l'inserimento di un nuovo membro del team, ha prodotto documentazione senza generare valore. Un diagramma di flusso che il team utilizza effettivamente per discutere casi limite, per introdurre un nuovo sviluppatore a un modulo sconosciuto o per identificare un ramo mancante per la gestione degli errori, ha invece raggiunto il suo scopo.
Il valore pratico di un diagramma di flusso dipende dalla sua costante attualità. Un diagramma disegnato una sola volta durante la fase di progettazione iniziale e mai aggiornato diventa fuorviante non appena il codice se ne discosta, peggio ancora che non averne affatto, perché infonde una falsa sicurezza. Sia attraverso pratiche di "diagrammi come codice", che mantengono il diagramma di flusso nello stesso repository del codice, sia attraverso la generazione automatica che deriva il diagramma di flusso dallo stato attuale del codice, la disciplina di mantenere il diagramma accurato è ciò che distingue i diagrammi di flusso che aiutano realmente un team da quelli che diventano artefatti obsoleti di cui nessuno si fida.
