Quando ho iniziato a programmare, mi sono affidato molto ai diagrammi di flusso (e ai grafici di spaziatura della stampante). Mentre ero in classe COBOL, non potevo iniziare a scrivere alcun codice fino a quando il mio diagramma di flusso non fu firmato dall'istruttore. Allora, dovevo creare un diagramma di flusso per tutto.

Oggi, venticinque anni dopo, mi ritrovo a disegnare solo due tipi di cose. Algoritmi molto specifici in cui la logica è complicata o concetti molto generali per garantire che ottenga tutti i grandi passi definiti e nel giusto ordine.

Ci sono altri casi d'uso per i diagrammi di flusso che ho semplicemente trascurato?

Assolutamente.

Ogni volta che sto implementando qualcosa che non ho mai fatto prima (e l'algoritmo richiede più di alcuni passaggi), lo tracciamo. Trovo che mi costringe davvero ad analizzare l'intera soluzione a un livello più atomico e più approfondito che se non fosse tracciata. Trovo che ci siano tre vantaggi principali in questa pratica:

• Meno "oh craps" perché ho pensato a tutto l'algoritmo
• Elimina tutti i potenziali colpi che possono verificarsi in tutto il resto del sistema
• Mi permette di guidare facilmente qualcun altro attraverso l'algoritmo

Le due diverse occasioni in cui le utilizzo effettivamente sono:

• Algoritmi di livello basso (ish). Intendo una soluzione molto specifica per un problema molto specifico. Generalmente li passerò dai colleghi prima dell'implementazione.
• Flusso utente. Non solo posso usarlo per passare da un peer, ma lo userò anche per spiegare (in modo molto non tecnico) il flusso a un esperto di usabilità.

Detto questo, non produco diagrammi di flusso ogni giorno (e anche quando hanno finito, è generalmente una sessione di lavagna a meno che non stia scrivendo un documento di progettazione tecnica).

Mai

I diagrammi di flusso - specialmente come praticati più di 25 anni fa - sono stati sostituiti da tecniche di diagrammi molto più espressive (cfr. Diagrammi di azione, Diagrammi di sequenza, Diagrammi di stato, ecc.)

Gli stessi studi di IBM hanno dimostrato che l'uso dei diagrammi di flusso non ha avuto alcun effetto sulla qualità della progettazione o dell'implementazione di un sistema (sebbene fossero marginalmente utili per comunicare con utenti e altri sviluppatori) [riferimento preciso non facilmente disponibile, ma è stato citato nelle Tecniche di diagramma di James Martin per analisti e programmatori ].

Non ho tracciato un diagramma di flusso classico dalla mia prima lezione di programmazione nel 1976 e non ho visto nessun altro crearne uno dai primi anni '80. I diagrammi di flusso erano utili per comunicare la logica del programma quando il codice era in linguaggio assembly. Alla fine degli anni '60, i programmatori di linguaggio assembly usavano lo pseudo-codice. Quando si programma in moderni linguaggi OO, né i diagrammi di flusso né gli pseudo-codici hanno alcun valore. Puoi anche scrivere codice di alto livello nella lingua di implementazione.

Di tanto in tanto disegno diagrammi UML, principalmente su carta, per esprimere idee progettuali, ma quei diagrammi vivono solo fino alla fine della discussione. Traccio anche diagrammi di transizione di stato di volta in volta, quindi li converto in una tabella di stato nel linguaggio di implementazione.

Uso sempre i diagrammi di flusso per una serie di motivi:

1. Secondo me sono migliori dei diagrammi dei casi d'uso di UML. Possono riflettere un numero di casi d'uso diversi e il modo in cui interagiscono e nel complesso svolgono un lavoro migliore riunendo l'esperienza e le decisioni dell'utente.

2. Sono più facili da capire e più intuitivi. La tua mente segue naturalmente le frecce come un labirinto dall'inizio alla fine. È possibile utilizzare i diagrammi di flusso per terminare e fare riferimento a un altro diagramma di flusso per una diversa user story. In genere posso stamparli in un libro numerato di pagine e capovolgere rapidamente le pagine per passare al diagramma di flusso successivo.

3. Sono universali. Poche persone al di fuori dell'ingegneria del software conoscono e comprendono i diagrammi UML, dove i diagrammi di diagramma di flusso sono molto più riconoscibili dagli utenti e dagli analisti aziendali. Cerco di comunicare casi d'uso complessi a un cliente e a volte fanno fatica a capire, disegno un diagramma di flusso e capiscono perché finalmente capiscono tutte le sfumature che lo rendono MOLTO PIÙ complesso di quanto pensassero.

I diagrammi di flusso sono utili quando è necessario eseguire le operazioni in un ordine specifico. Dove davvero brillano nella mia mente è mostrare dove vengono prese le decisioni e assicurarsi che ogni possibile decisione abbia un percorso. Questo impedisce la creazione di programmi in cui è richiesta un'approvazione mamager ma non ha modo di gestirla se il manager (che approva il 98% delle volte) dice di no. Ci ricordano che il percorso più comune non è l'unico percorso. Li trovo utili nel parlare agli utenti dei requisiti perché spesso ti diranno solo il percorso più comune.

I diagrammi di flusso possono essere utili per il reverse engineering di codici strutturati in modo non corretto. Soprattutto se ha goto. Per fortuna non ho visto molto codice goto-riddden di recente.

Come altri hanno notato per comunicare con gli utenti finali. Ordino l'avvio di un trasmettitore TV documentato dal diagramma di flusso. Le persone hardware e software avevano una specifica comune su cui lavorare.

Il diagramma di attività e il diagramma di flusso UML sono utili per mostrare la complessità medio-bassa di un processo o algoritmo.

Sono molto bravi quando comunicano con gli utenti aziendali le regole aziendali.

Esiste una variante sotto forma di BPMN 2.0 che è molto utile nella modellazione dei processi aziendali.

Alcuni strumenti BPMN possono generare applicazioni Web in esecuzione dai grafici.

Quindi sì, i diagrammi di flusso hanno ancora un posto ma devono essere usati con saggezza.

Non sono un programmatore. Sono una tecnologia di ingegneria hardware.

Per me ha senso almeno iniziare con commenti che spiegano i blocchi logici che verranno utilizzati. Successivamente, riempie lo scheletro del programma con il codice reale. È simile all'avvio di una sceneggiatura del film con uno storyboard e quindi dopo la compilazione dei dettagli dell'azione e della finestra di dialogo.

Qualunque sforzo utile non dovrebbe essere pianificato con cura? Nel regno dell'hardware, iniziamo con un documento sui requisiti del cliente, quindi scriviamo un documento con le specifiche dell'hardware, quindi perfezioniamo lo schema, quindi disegniamo un layout della scheda, quindi creiamo la documentazione di assemblaggio. Non iniziamo solo ad afferrare parti e saldarle insieme mentre ci vengono in mente idee per realizzare il prodotto finale.

Non vedo come un codice efficiente possa essere scritto in un programma da 15 KB o 15 MB senza un sacco di lavoro di preparazione prima di iniziare la codifica effettiva.