Un diagramma di flusso di dati sembra corretto quando un'entità esterna è collegata a troppe frecce?

Question

Un diagramma di flusso di dati sembra corretto quando un'entità esterna è collegata a troppe frecce?

#1 da (0 voti)
#2 da (0 voti)

-1

Sto provando a modellare un diagramma di flusso di dati in conformità con un documento di requisito. Il documento richiede un sistema con molti ruoli che gli utenti possono svolgere, in cui ha bisogno di uno scambio costante di informazioni tra diversi ruoli.
Ecco un esempio delle sue funzioni, dove 'Ruolo A' è un revisore o giudice di alcuni elementi, e 'Ruolo B' è un gestore di quegli elementi:
1. Il ruolo A mostra l'elenco degli elementi (che sono memorizzati in un database) e sceglie gli oggetti a cui è interessato;
2. Il ruolo B ottiene un riepilogo delle preferenze dei diversi ruoli A e gli assegna gli elementi; 3. Il ruolo A riceve gli elementi a lui assegnati, li visualizza e lascia il suo feedback sugli elementi,
4. Il ruolo B riassume il feedback di tutti i ruoli A e decide quali elementi eliminare dal pool.
In base a ciò che ho appreso, considererei il ruolo A e il ruolo B come entità esterne diverse, quindi il DFD viene pubblicato in questo modo:
Come si può vedere, ci sono troppe frecce collegate a ciascuna entità esterna; mentre i processi non sono collegati. Questo è diverso dalla maggior parte degli esempi DFD che ho trovato.
Quindi, il mio lavoro è corretto? In caso contrario, come dovrei modificarlo?

requirements modeling requirements-management flowchart

posta Garlic Xu 26.04.2017 - 13:32

fonte

2 risposte

Leggi altre domande sui tag requirements modeling requirements-management flowchart

Progettazione OOP: definizione di set di regole aggiuntivi e scelta dinamica Sviluppo di un'app utilizzando Django. Devo progettare front-end dopo l'app? O sviluppare Django per adattarsi all'interfaccia utente? [duplicare]

score 0 · Answer 1

Quando il flusso di dati ha cicli, avrai un diagramma come questo. I diagrammi del flusso di dati in genere non mostrano l'ordinamento, quindi quello che hai è normale.

Ci sono alcune cose che potresti fare se vuoi renderlo più ordinato:

Dovresti etichettare le frecce con il contenuto di dati che scorre tra gli elementi. Spesso quando c'è un ciclo, mostrare il contenuto che viene scambiato cancella le cose. Ad esempio, quando ci sono due ruoli, cliente e rivenditore, e il cliente effettua un ordine, e il rivenditore invia una ricevuta. Questo ha un ciclo; tuttavia, si può dedurre che l'ordine è posto prima che venga inviata la ricevuta.
Puoi uscire dagli schemi tradizionali del diagramma del flusso di dati e aumentare il diagramma del flusso di dati con i numeri, se il tuo sistema di diagrammi lo consente.
Nel tuo caso, dal momento che hai svolto così tante responsabilità sia dal ruolo A che dal ruolo B, potresti dividere i ruoli in sub-ruoli che sono più funzionali, in cui ogni sub-ruolo ha solo un input accettato e un output restituito. Il risultato sarebbe che il flusso di dati ha meno o nessun ciclo. Nel tuo caso i ruoli secondari potrebbero essere Role A Chooser, Role B Assigner, Role A Feedback, Role B Finalizer. Ciò rimuoverà tutti i cicli tranne quello grande che coinvolge il database.

Se poi volessi dimostrare che questi sub-ruoli hanno tutti lo stesso ruolo, sarebbe un diverso tipo di relazione, che potresti (1) lasciare implicito nella denominazione dei sub-ruoli, (2) mostrare su un diverso tipo di diagramma o (3) aggiungi a questo diagramma usando l'illustrazione che esce dal tradizionale diagramma di flusso dei dati (come una freccia tratteggiata ben etichettata).

E infine, naturalmente, puoi combinare quanto sopra.

score 0 · Answer 2

Prima di tutto devi decidere se il flusso di dati è il giusto tipo di diagramma per il tuo scopo principale, è questo:

A: mostra come i flussi di dati
B: mostra in quale ordine vengono eseguiti i passaggi del processo
C: mostra chi sta facendo cosa

Potresti trovare un diagramma di attività UML con ruoli / attori per essere una buona alternativa, dato che sembri principalmente interessato allo scopo B & C. L'esempio collegato prende in prestito idee da BPM in cui le swimline mostrano chi è attualmente attivo nel processo:

link

Punti generali:

Definisci nomi univoci per informazioni e usa sempre lo stesso nome. Nel tuo esempio utilizzi l'elemento e l'elemento in modo intercambiabile.
Se il diagramma che disegni si adatta al tuo scopo, non mi preoccuperei troppo delle regole. Naturalmente se il tuo diagramma deve essere letto da (molte) altre persone, diventa più importante che segua per lo più uno standard che già conoscono.

Se rimani con il diagramma del flusso di dati, ti suggerirei:

Mi piacerebbe che le frecce avessero etichette - quale flusso di informazioni scorre qui? (Erik lo sottolinea pure)
Chiama i ruoli qualcosa di significativo, cioè revisore e responsabile degli elementi