Voglio rappresentare la logica del mio programma attraverso un diagramma, poiché il programma è piuttosto complesso; Ho bisogno di un modo per spiegare ad un'altra persona, perché e come succede qualcosa nel mio programma. Il diagramma di flusso è l'unica opzione?Rappresentazione visiva della logica di programma
Se hai bisogno di spiegare le cose a un livello passo-passo, sì, un diagramma di flusso è davvero quello che ti serve. Se puoi parlare ad un livello superiore un'altra opzione può essere il diagramma di stato.
diagrammi di flusso sono una scelta popolare, e spesso adatti per persone non tecniche.
Se sei interessato a fornire una visione più tecnica della situazione, UML può essere una scelta migliore.
A sequence diagram mostra come i componenti interagiscono tra loro.
In UML, diversi diagrammi sono destinati a cose diverse, utilizzando diverse metodologie. Considerando che tendiamo ad appoggiarci alle metodologie orientate agli oggetti, spiegherò i diversi diagrammi e come funzionano.
Use Case Diagram - Il punto di modelli dei casi d'uso è quello di individuare e definire tutti i processi di business elementari che il sistema deve supportare. Questo è da un punto di vista sia dell'utente che di un sistema. Qualsiasi singola azione all'interno del tuo sistema può essere utilizzata in un caso d'uso, il che consentirà di utilizzare altri modelli più esplicativi.
Activity Diagram - Questo è un tipo di schema di flusso di lavoro utilizzato per descrivere ciò che accade in un diagramma dei casi d'uso. È fondamentalmente un metodo visivo per descrivere il flusso di un'attività o più attività.
Sequence Diagram - Questo è un diagramma per mostrare la comunicazione tra diversi oggetti in un sistema o un processo. I diagrammi di sequenza sono importanti nell'analisi, in quanto diventano cruciali per la progettazione dettagliata del sistema e la progettazione dell'interfaccia utente. Mi piacciono molto questi perché offrono una visione fantastica di ciò che accade nel sistema.
Diagramma macchina di stato - Ciò consente di tenere traccia degli stati degli oggetti nel corso della loro durata, il che consente di ottenere informazioni dettagliate su come gli oggetti devono funzionare. Questo dà l'abilità su come mappare efficacemente eventi e simili nel sistema.
Usando i diagrammi succitato dà una grande base di analisi e progettazione, e si dovrebbe notare che una volta che si creano questi diagrammi, essi non sono necessariamente completi. Nei processi di progettazione, modificherete questi diagrammi man mano che il sistema evolve. Spero che questo ti aiuta. Di seguito sono riportati i collegamenti a wikipedia per i diversi diagrammi citati.
Dietro ogni programma è un dominio del problema, in cui presumibilmente una serie di problemi che sono ben compreso da un gruppo di dominio conoscono persone, e un dominio soluzione, in cui i metodi per risolvere tali problemi sono raccolti e utilizzati per gestire i problemi.
Per spiegare qualcosa, è necessario prima concordare il dominio del problema. Se il tuo dominio problematico è l'elaborazione del segnale, e la spiegazione è rivolta a qualcuno che non ha familiarità con il dominio, sei già brindisi.
Quindi è necessario spiegare il dominio della soluzione (o fare riferimento a un insieme ben noto di soluzioni come si potrebbe trovare in un manuale di ingegneria), in modo da giustificare una particolare scelta di soluzione che si adatta bene a questo particolare problema e altri vincoli che possono essere posti sulla risposta (corre in una piccola macchina, può essere costruita in un giorno, ecc.). Se la persona a cui stai spiegando le cose non capisce una trasformazione di Fourier veloce come una possibile soluzione a un problema nel tuo dominio prescelto di elaborazione del segnale, non sarai in grado di espellere la soluzione e tanto meno quella è la migliore delle tue scelte.
Una volta superati questi due ostacoli, quindi un diagramma di flusso potrebbe essere un elmetto. Altre stampelle, come i vari tipi di diagrammi UML, spiegano la struttura della soluzione da diverse prospettive. Quale prospettiva conta dipende da quale sia lo scopo della spiegazione.
Riguardo ai diagrammi di flusso: mentre erano popolari una volta, per descrivere gli algoritmi, il codice di psuedo è generalmente abbastanza buono. Anche le persone che non possono seguire il codice psuedo non seguiranno probabilmente un grande diagramma di flusso. E se il tuo diagramma di flusso è banale, non ne hai bisogno. Non ne ho usato uno seriamente in 20 anni. Anche la maggior parte della letteratura informatica non sembra usarla.
Detto questo, quando si vuole capire in modo estremamente dettagliato cosa stia facendo un vero pezzo di codice, soprattutto ai fini dell'analisi automatica del programma, i diagrammi di flusso (sotto il nome di follower "control flow") sono ancora piuttosto utili . Vedere a COBOL control flow graph (e vedere this for an explanation). Dovrebbe essere ovvio che non vuoi usare questo per spiegare un algoritmo ad un'altra persona.
Esistono anche diagrammi di casi d'uso. Ma sulla base della domanda, sono d'accordo: i diagrammi di flusso sarebbero la mia prima scelta. – TrueWill