Nella programmazione visiva, ci sono molti eventi che supportano i nostri compiti applicativi. Quindi, insieme ai processi definiti dall'utente, dovrebbero anche questi essere nel diagramma di flusso o no?
E i costruttori delle classi, dovrebbero essere mostrati nel diagramma di flusso o no?
In breve, un diagramma di flusso è un tipo di diagramma che rappresenta un algoritmo o un processo, che mostra i passaggi come scatole di vari tipi e il loro ordine collegandoli con le frecce.
Si può anche pensare a un diagramma di flusso come a un flusso di processo della logica dell'applicazione mentre si collegano componenti in un certo tipo di flusso di eventi.
What about the constructors of classes, they supposed to be shown in flowchart or not ?
Il design della classe non viene eseguito mediante il diagramma di flusso. Generalmente viene creato un diagramma UML per presentare la struttura del diagramma di classe o la progettazione di applicazioni di alto livello.
L' articolo di Wikipedia copre abbastanza bene. Guarda sotto blocchi predefiniti ; se non è lì, un diagramma di flusso non lo copre.
I diagrammi di flusso sono principalmente pensati per illustrare un processo che incorpora un algoritmo (una ricetta per risolvere un problema). Il diagramma di flusso illustra i passaggi procedurali che il computer avrebbe intrapreso per risolvere il problema.
In generale, tutti gli Input (tramite I / O box), Output (tramite box I / O), Processings (tramite Proceesing box) e Decisions (tramite box Diamond) dovrebbero essere riflessi nel tuo diagramma di flusso.
Parlando di eventi, possono essere assegnati in qualche modo tramite la scatola di diamanti, se vuoi. Ad esempio:
if (utente / sistema lo fa) quindi
do this
altro
do this
Per i costruttori, devi utilizzare il diagramma degli oggetti . Come costruttori sono metodi di classe il cui unico scopo è quello di mantenere l'oggetto in uno stato valido quando istanziato.
Non essere intenzionalmente contrario, ma in risposta alla domanda:
"What types of processes have to be reflected in flowchart?"
Penso che la risposta non sia nessuno di loro.
I diagrammi di flusso sono in circolazione da molto tempo. Per gli sviluppatori, richiedono molto tempo per produrre, in particolare nella quantità necessaria per un progetto di ambito commerciale. Hanno anche lo svantaggio di diventare obsoleti abbastanza velocemente una volta che gli sviluppatori iniziano a codificarli e integrare la logica scoperta durante l'implementazione e il test.
In una conversazione casuale con Dr. Bill Curtis , che era uno degli autori di SEI CMM 1.1 e una persona con qualche background nel processo del software e nella psicologia (un dottorato di ricerca), ha detto a me e ad altri che i nostri diagrammi dipendono dalle persone che sono altamente spaziali per capirli, ma le persone che erano ad alto livello spaziale potrebbero facilmente formare un'immagine mentale dalle rappresentazioni testuali di software come pseudo codice.
La maggior parte dei metodi orientati agli oggetti sostengono di lasciare diagrammi di flusso e anche il diagramma del flusso di dati come artefatti di programmazione strutturata e persino di programmazione pre-strutturata. Più utili sono le tecniche come casi d'uso annotati con flussi alternativi. I casi d'uso tendono a iniziare con un flusso nominale che può descrivere alcune condizioni, ma non molto ramificazione del flusso di controllo. La ramificazione è coperta in casi alternativi e tipicamente fa riferimento al flusso nominale per brevità, accentuando solo le differenze. Un altro buon motivo per considerare i casi d'uso invece dei diagrammi di flusso è che possono facilmente includere tutto il testo necessario per chiarezza, sebbene tutto tranne il testo più breve possa causare problemi con il testo scorrevole nei diagrammi di flusso e combinato con il routing e altro manuale manipolazioni, può consumare un sacco di tempo, a volte con buoni benefici, a volte senza.