Diagramma di flusso e chiamate di metodo


11

Sto realizzando alcuni diagrammi di flusso e mi chiedo se mi sto avvicinando a questo in modo corretto. In sostanza, ho diverse chiamate di metodo e sto condividendo il flusso separatamente. Tuttavia, molti di questi metodi effettuano una chiamata di metodo per alcune informazioni e poi continuano. Vedi questo esempio:

inserisci qui la descrizione dell'immagine

Ho altri 3 metodi che chiamano anche GetQueue () e mi chiedo se lo rappresento correttamente. Il flusso AddQueue () sembra visivamente interrotto.

NOTA: modifiche apportate nel mio diagramma di flusso:

inserisci qui la descrizione dell'immagine


Questo livello di dettaglio pittorico è davvero necessario? So che, un tempo, i diagrammi di flusso come questo erano popolari, ma al giorno d'oggi sembrano essere sfuggiti al favore per molte ragioni ... Essenzialmente sono una forma ridondante di documentazione; è necessario tenerli aggiornati e il codice dovrebbe già rappresentare adeguatamente ciò che viene mostrato nel diagramma di flusso (il che significa che il tempo viene speso meglio producendo più codice).
Robert Harvey,

Mi è stato richiesto prima di passare a un altro cliente.
Keith Barrows

@Robert Harvey: i diagrammi di flusso erano utili ai vecchi tempi, quando le persone scrivevano direttamente il codice macchina o assemblatore. Potrebbero essere stati utili ai primi programmatori FORTRAN e BASIC, che non avevano una buona gamma di strutture di controllo. Al giorno d'oggi, l'unica ragione per cui li farei è se un cliente li volesse come prodotto da consegnare e fosse disposto a pagarmi adeguatamente.
David Thornley,

Quando ho sviluppato questi da zero ho trovato molto utile usare sticky gialli, girando i 90 gradi per le decisioni. Ciò consente di spostarli e inserire processi tra di loro. Quando siete tutti don, quindi inseriscili nel tuo software.
Michael Riley - AKA Gunny,

Uso ancora i diagrammi di flusso occasionalmente, anche se trovo che i test unitari siano spesso migliori per lo stesso scopo. Non sono risultati finali, tuttavia; Li uso per ottenere un flusso di controllo nella mia testa.
Michael K,

Risposte:



2

Recentemente ho fatto alcuni diagrammi di flusso e ho lottato con lo stesso problema, come presentare chiamate di subroutine, o forse chiamate di metodo e funzione come potresti chiamarle in questi giorni.

Ho optato per una convenzione che separa le CHIAMATE della subroutine dalle RIFERIMENTI della subroutine. Per il primo utilizzo un normale rettangolo che mostra la chiamata con gli argomenti in corso, usando qualunque variabile sia attiva a quel punto nell'esecuzione del programma.

Uso il rettangolo di "processo predefinito" a doppia faccia semplicemente come riferimento ad un altro diagramma di flusso che contiene la definizione di quella funzione o sub-routine. Il rettangolo della sub-routine non ha bisogno di mostrare gli argomenti della sub-routine poiché fa parte del diagramma di flusso di definizione della sub-routine in questione, ma può essere utile aggiungerli già nel riferimento in modo che chiunque lo legga possa vedere il significato degli argomenti reali utilizzati in una chiamata.

Ciò aumenta il numero di rettangoli ma rende più chiaro che esistono quegli altri diagrammi di flusso per cercare la definizione di alcune delle funzioni chiamate da. Spesso se una funzione è semplice non creerò un diagramma separato per essa, ma la documenterò solo verbalmente.

Uso anche il simbolo "documento" per dire che i dettagli dovrebbero essere cercati dalla lista dei codici.

Il punto di un diagramma di flusso per me non è creare un programma, ma rendere più facile per gli altri capire un programma. Penso che l'aiuto come una visione a volo d'uccello e quello scopo di loro dovrebbero essere tenuti a mente. Non servono per descrivere visivamente OGNI dettaglio del programma, i dettagli sono visibili dal codice quando necessario. Il diagramma di flusso è solo una foto del tuo programma dal punto di vista di alto livello.

Mantenere i diagrammi di flusso di alto livello significa anche che è meno necessario tenerli aggiornati quando il codice viene modificato.

Sono immagini. Come ogni buona storia, la documentazione del software dovrebbe contenere anche immagini che forniscano un punto di vista alternativo al codice.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.