I DFD di Yourdon

1
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Mauro Pullin
PROGETTARE CON LA METODOLOGIA DEI DATA
FLOW DIAGRAMS DI YOURDON E DE MARCO
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
2
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
0. SOMMARIO
1.
PREMESSA
2.
PRINCIPALI CARATTERISTICHE DEI DFD
3.
ELEMENTI COSTITUTIVI DEI DFD
3.1. Flusso dei Dati
3.2. Processo
3.3. Data store
3.4. Origine e Destinatario dei Dati
3.5. La Legge di Weinberg
4.
REGOLE DI DISEGNO DEI DFD
4.1. Identificazione degli input primari e degli output finali
4.2. Riempimento dell’interno del DFD
4.3. Attribuzione di un nome a flussi, data store, origini e destinatari
4.4. Attribuzione di un nome ai processi
4.5. Rappresentazione dei flussi di dati e non di quelli di controllo
4.6. Prepararsi a ricominciare
5.
SCOMPOSIZIONE A LIVELLI
5.1. Approccio top-down: il concetto di scomposizione a livelli
5.2. Componenti di DFD a livelli
5.3. Convenzioni
5.4. Determinazione del livello finale
6.
BIBLIOGRAFIA
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
3
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
1. PREMESSA
Nella realtà odierna, in qualsiasi organizzazione il Sistema Informativo
rappresenta il tessuto connettivo fra tutti i soggetti, gli organi e le funzioni
all’interno dell’organizzazione stessa.
Attraverso i suoi canali fluiscono tutte le informazioni necessarie all’attuazione
dei processi decisori, esecutivi e di controllo.
Esso consiste in una serie di canali, procedure e strumenti aventi per oggetto la
raccolta, l’elaborazione, la conservazione e la trasmissione di dati, informazioni e
notizie.
L’analisi strutturata ha fra i suoi obiettivi quello di dotarsi di un semplice
strumento grafico di scomposizione dell’area oggetto delle specifiche.
Il principale strumento di scomposizione in nostro possesso è il Diagramma di
Flusso dei Dati (DFD).
Un Diagramma di Flusso dei Dati è una rappresentazione reticolare di un
Sistema, che può essere automatico, manuale o misto.
Esso ci rappresenta il sistema mettendo in evidenza tutti gli elementi che lo
compongono, con le interfacce esistenti tra i componenti stessi [1].
In figura 1 è rappresentato un primo esempio di Data Flow Diagram (d’ora in poi
si utilizzerà l’acronimo “DFD”).
Molti autori, per enfatizzarne la leggibilità, sono soliti dire frasi del tipo “un DFD
vale mille parole” (o anche più).
Esistono comunemente altre espressioni con cui in letteratura ci si riferisce ai
DFD: Diagrammi di Flusso di Dati, Data Flow Graphs, Grafici di Flusso dei Dati,
Bubble Charts.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
4
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 1
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
5
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
2. PRINCIPALI CARATTERISTICHE DEI DFD
Di seguito vengono elencate le principali caratteristiche dei DFD.
I diagrammi di flusso dei dati:
•
sono espressi in forma grafica;
•
sono scomponibili;
•
sono multidimensionali;
•
enfatizzano il flusso dei dati (a differenza di quanto accade negli approcci di
tipo procedurale);
•
trascurano il flusso di controllo.
L’uso dei DFD in fase di analisi consente di rappresentare la realtà dal punto di
vista dei dati e non da quello di qualsiasi persona, ente o organizzazione che
interagisca con essi.
Questo costituisce una significativa inversione del modo di procedere nell’analisi.
Nel modo di procedere tradizionale si studiano le operazioni dal punto di vista
dell’utente e conseguentemente si imposta l’attività di indagine per apprendere
come egli opera.
Quando, invece, si effettua lo studio secondo i modelli proposti dall’Analisi
Strutturata si cerca di “fotografare” l’attività di un sistema come “visto dai dati” e
non dal punto di vista di chi tratta i dati.
Il vantaggio di questo approccio è che i dati “vedono” la globalità del sistema,
mentre le persone e le organizzazioni che con esso interagiscono vedono solo una
porzione del tutto.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
6
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3. ELEMENTI COSTITUTIVI DEI DFD
Gli elementi basilari che compongono i DFD sono cinque:
1.
2.
3.
4.
5.
Flussi (Data Flow), rappresentati per mezzo di linee orientate;
Processi (Process), rappresentati per mezzo di cerchi (detti anche “bolle”);
Data store (archivi), rappresentati per mezzo di rettangoli aperti;
Origini (Source) di dati, rappresentati per mezzo di rettangoli;
Destinatari (Sink) di dati, rappresentati per mezzo di rettangoli.
Oltre ai cinque elementi sopra citati, a volte se ne considera anche un sesto:
6. Dizionario dei Dati (Repository), che contiene l’elenco di tutti gli oggetti, con
descrizione ed eventuale scomposizione in oggetti elementari.
Figura 2
In figura 2 è rappresentata una porzione di DFD che comprende tutti e cinque gli
elementi.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
7
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Coerentemente con la modalità operativa che prevede di concentrarsi
principalmente sui flussi di dati, la figura 2 si legge nel modo seguente: X arriva
dall’origine S e viene trasformato in Y dal processo P1 (che richiede l’accesso
all’archivio F). Successivamente Y viene trasformato in Z dal processo P2.
I processi P1 e P2 debbono ricevere i loro nomi dai flussi di dati che entrano ed
escono da loro. Ad esempio, P2 potrebbe essere chiamato “trasformazione di Y in
Z”.
Nell’analisi classica, invece, i flussi avrebbero dovuto chiamarsi in funzione del
processo con cui interagiscono direttamente e quindi Y si sarebbe chiamato
“entità generata da P1 per essere usata da P2”, con evidenti lacune di chiarezza.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
8
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3.1. Flusso dei Dati
Si definisce Flusso dei Dati una connessione tra elementi del DFD attraverso
cui scorrono pacchetti di informazioni congruenti.
I flussi dei dati rappresentano l’interfaccia tra due componenti di un DFD. Essi
attraversano processi, entrano o escono da data store, provengono da origini e
vanno verso destinatari di dati.
Essi sono raffigurati tramite una linea orientata e chiamati in modo preciso.
Si osservi ora la figura 3.
Figura 3
Si supponga di sapere dal Dizionario dei Dati che il flusso chiamato “Pagamento”
consiste in una copia della fattura per il cliente e di uno scontrino.
Perché in questo caso si è scelto di evidenziare il Pagamento come un singolo
flusso di dati piuttosto che due? Che cosa è dunque un flusso di dati?
Per rispondere a questi quesiti, è necessario distinguere tra le interfacce e le
informazioni che passano attraverso le interfacce.
Siccome, dalla definizione, un flusso di dati è una connessione tra elementi del
DFD attraverso cui scorrono pacchetti di informazioni congruenti, nell’esempio
riportato il pacchetto di informazioni è costituito dalla copia della fattura e dallo
scontrino; tale flusso viaggia dal cliente al processo di fatturazione attraverso una
connessione chiamata Pagamento.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
9
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Nella figura 4 è rappresentata una porzione di DFD che ha due flussi di dati che
collegano due processi.
Figura 4
La ragione per cui essi sono stati distinti è perché non costituiscono un pacchetto
di informazioni congruenti, infatti essi non si presentano mai
contemporaneamente (ad esempio, il “Riepilogo livelli di giacenza” potrà essere
generato settimanalmente, mentre il “Foglio di riordino urgente” verrà prodotto
tutte le volte in cui ci si troverà di fronte ad una situazione critica).
Il “Riepilogo livelli di giacenza” ed il “Foglio di riordino urgente” sono due flussi
di dati che hanno scopi diversi, probabilmente sono prodotti da differenti porzioni
del processo di origine e generalmente non hanno molte informazioni in comune.
E` per questi motivi che è stato previsto di connettere i due processi con due
interfacce separate: qualora, infatti, le si forzasse in una connessione comune si
riuscirebbe solo a rendere più oscura l’interfaccia. Tra l’altro, sarebbe molto
difficile trovare un nome soddisfacente per questo ipotetico unico flusso di dati.
Il riuscire o meno a dare un nome ad un flusso può essere utilizzato come
meccanismo di feedback per valutare il modo in cui il sistema è stato scomposto
nelle sue parti componenti.
Vengono ora fornite, di seguito, alcune convenzioni usate per rappresentare i
flussi di dati.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
10
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
•
Non devono esistere due flussi con lo stesso nome.
•
I nomi vanno scelti per rappresentare non solo i dati che fluiscono nella
connessione, ma anche ciò che si conosce su quei dati.
Ad esempio, in figura 5 sono presenti i flussi “Codice di addebito” e “Codice
validato”, che sono strutturalmente equivalenti. Il nome diverso sta tuttavia a
significare che si conosce qualcosa di più relativamente al secondo flusso,
ovvero che il dato è stato validato.
•
Non si deve attribuire il nome ai flussi che vanno e/o vengono da data store, in
quanto è il nome del data store che li individua.
Tutti gli altri flussi di dati debbono invece ricevere un nome.
Figura 5
Per concludere, si forniscono alcune precisazioni su quello che non è un flusso di
dati.
•
Il flusso di dati non rappresenta un flusso di controllo.
•
Il flusso di dati non attiva o disattiva processi.
Come dunque si possono rappresentare i flussi di controllo o di attivazione in un
DFD? E` semplice, non si rappresentano!
Infatti, trattandosi di informazioni di natura procedurale, forniscono un contributo
esiguo rispetto agli obiettivi propri dei DFD.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
11
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3.2. Processo
Si definisce Processo la trasformazione dei flussi di ingresso nei flussi di
uscita.
I Processi illustrano il lavoro eseguito sui dati.
Il processo di figura 6, ad esempio, mostra l’attività di dividere il flusso entrante
(testo) nelle due connessioni “parole corrette” e “parole errate”.
Figura 6
Tale processo è stato chiamato “Verifica dell’ortografia”, ma se gli si volesse
attribuire un nome esclusivamente in termini dei suoi input e output, esso sarebbe:
“separare il ‘testo’ in ‘parole corrette’ e ‘parole errate’ facendo riferimento ad un
‘dizionario delle parole’”.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
12
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
I processi individuati correttamente hanno tutti la caratteristica di essere chiamati
in termini dei propri input e output, è proprio per questo che la definizione li
individua come enti che eseguono la trasformazione dei flussi di input nei flussi di
output.
I processi sono rappresentati simbolicamente con cerchi (talvolta detti anche
“bolle”).
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
13
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3.3. Data store
Si definisce Data Store qualsiasi “deposito” temporaneo di dati.
Il concetto di Archivio (Data Store) è abbastanza consolidato per chi opera
nell’informatica.
Nel contesto dei DFD, però, il deposito di dati che costituisce un data store può
essere costituito da varie cose: un nastro magnetico, un’area di disco o una
“porzione” di floppy disk, uno schedario, una rubrica, il cestino dei rifiuti, un
registro contenuto in un apposito cassetto, ecc..
Il verso della freccia, orientato da o verso il data store, è significativo.
In figura 6 i dati fluiscono solamente dal data store e non verso esso.
Il DFD in essa rappresentato, pertanto, vuole esprimere il fatto che il processo
“Verifica dell’ortografia” non accetta alcuna parola nuova e quindi non aggiorna
il dizionario.
Se così non fosse, la freccia sarebbe presente in entrambi i versi.
In figura 7 si assiste invece al caso opposto, nel quale i dati fluiscono nel Catalogo
Articoli e non viceversa.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
14
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 7
Naturalmente non si può aggiornare un archivio senza prima leggerlo (come ben
sa chi si occupa dello sviluppo di software applicativo), ma nonostante ciò la
figura 7 è corretta nel modo in cui è stata disegnata.
Si può porre la regola seguente: nei flussi di dati che si interfacciano con i data
store vanno indicati solo i versi significativi, si omettono quindi gli aspetti
trascurabili di accesso fisico agli archivi.
Nel caso esaminato, se alcune delle informazioni del Catalogo Articoli, non
presenti nel flusso Nuovo Articolo, finissero nella Lista Arrivi, allora sarebbe
corretto evidenziare un flusso orientato secondo tutti e due i versi rispetto al data
store.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
15
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3.4. Origine e Destinatario dei Dati
Si definisce Origine dei Dati una persona, un ente o un’organizzazione
esterna al contesto del sistema che è l’organizzatore “primo” dei dati.
Si definisce Destinatario dei Dati una persona, un ente o un’organizzazione
esterna al contesto del sistema che è l’utilizzatore “ultimo” dei dati.
Qualsiasi sistema può essere espresso nei DFD tramite flussi, processi, data store.
Per aumentare in modo significativo la “leggibilità” del diagramma è necessario
evidenziare da dove arrivano gli input al sistema e dove vanno a finire gli output.
Le definizioni sopra esposte chiariscono questi concetti.
La parte qualificante della definizione è costituita dall’espressione “esterna al
contesto del sistema”: infatti le persone, gli enti e le organizzazioni interne al
sistema sono rappresentate per mezzo dei processi da essi eseguiti.
La linea tratteggiata di figura 8 identifica il contesto del sistema e quindi la
corretta individuazione di origini e destinatari permette di descrivere in modo più
completo come il sistema si connette con il mondo esterno.
Di seguito viene esposta la definizione di sistema.
Si definisce Sistema un insieme di procedure, automatiche o manuali, usate
per ottenere uno scopo desiderato.
Tenendo presente la definizione sopra esposta, si osservi la figura 9, nella quale il
contesto comprende sia processi manuali, sia processi automatici.
Si tenga presente che il contesto comprende qualsiasi cosa interessi la nostra
analisi, non solo quello che interessa alle origini ed ai destinatari.
La definizione di contesto è la seguente:
Si definisce Contesto dell’Analisi il sistema da automatizzare a cui va
aggiunto tutto ciò che potrebbe essere influenzato dal cambiamento dovuto
all’automazione.
Origine e destinatario si collocano fuori del contesto.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
16
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 8
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
17
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 9
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
18
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
3.5. La Legge di Weinberg
Il lettore avrà sicuramente osservato che finora si è applicata una tecnica
nell’approccio dell’Analisi Strutturata tale da trascurare in prima battuta tutta una
serie di considerazioni, che consideriamo “non di importanza immediata”, tra le
quali vanno annoverate specialmente quelle di tipo “fisico”.
La corretta metodologia dell’Analisi Strutturata insegna che qualsiasi approccio
pulito e sistematico ad un problema richiede che si posticipino tutti gli aspetti che
riguardano dettagli di una certa consistenza.
Questi concetti sono stati espressi da Jerry Weinberg come regola [2]:
Se si vuole imparare qualcosa, non bisogna cercare di imparare tutto.
In altre parole, si deve rimandare tutto quello che non è subito necessario.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
19
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4. REGOLE DI DISEGNO DEI DFD
Viene fornito, di seguito, il prospetto delle regole che debbono essere seguite per
disegnare correttamente i DFD.
1. Bisogna identificare gli input primari e gli output finali e poi li si deve porre
lungo il contorno del foglio.
2. Si deve disegnare il DFD come è più comodo o congeniale: dall’input
all’output, dall’output all’input, dal centro agli estremi.
3. E` importante dare un nome significativo a flussi, data store, origini,
destinatari.
4. Si deve dare un nome ai processi in termini di trasformazione dall’input
all’output.
5. E` necessario tralasciare le inizializzazioni.
6. In prima battuta, vanno omessi i dettagli ed i flussi di errore.
7. Non debbono essere indicati i flussi di controllo.
8. E` importante prepararsi a ricominciare.
Esaminiamo ora in dettaglio i punti sopra esposti.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
20
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.1. Identificazione degli input primari
e degli output finali
Determinare quali sono gli input primari e gli output finali è un’attività vincolata
alla decisione di quale sarà il contesto dello studio.
Questa decisione viene presa, in genere, all’inizio della fase di analisi e spesso
senza un grosso sforzo di ragionamento, in quanto è più una questione di giudizio
e sensibilità.
Ci si è già soffermati sul problema di individuare correttamente il contesto del
sistema e quindi di evitare impostazioni troppo restrittive o comprensive di
elementi estranei al problema.
Stabilito quindi il confine del nostro lavoro, gli input primari e gli output finali
sono costituiti dai flussi che attraversano il confine del contesto.
In questa fase non ci si deve preoccupare troppo se questo semplice criterio non
fornisce risultati completi, perché i DFD hanno meccanismi insiti di autocontrollo
che permettono di rintracciare i flussi eventualmente dimenticati.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
21
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.2. Riempimento dell’interno del DFD
In quasi tutti i progetti il primo utilizzo dei DFD è per documentare l’area utente
alla data di inizio.
Si è quindi chiamati a descrivere non tanto come dovranno essere le cose, quanto
come sono effettivamente. Di conseguenza, si può modellare il DFD sulla base di
quanto si conosce e di quanto l’utente racconta.
I flussi sono insiemi di dati che l’utente conosce, usa comunemente e quindi
chiama in qualche modo; i processi sono segmenti del lavoro che si svolge in
quest’area.
Si deve procedere ponendo l’attenzione, in primo luogo, ai flussi di dati.
Si supponga di avere identificato un insieme significativo di informazioni che
l’utente tratta in modo unitario (perché arrivano insieme, vengono elaborate
insieme, ecc.), certamente esso diverrà un flusso di dati nel DFD.
Lo si inserisce quindi nel diagramma e si cerca di collegarlo con i flussi esterni, si
aggiungono processi ovunque un qualche lavoro è richiesto per trasformare un
flusso o un insieme di flussi in un altro.
Non ci si deve comunque preoccupare di trovare per loro un nome.
Si indaga ora sui processi così introdotti, per verificare se nascondono un qualche
flusso di dati, si esegue la verifica con l’utente e, in caso affermativo, si
sostituisce il singolo processo con due, tre o quattro altri processi, introducendo il
flusso o i flussi identificato/i in tal modo.
Di ogni nuovo flusso si deve arrivare a sapere come è composto e, per ciascuno
dei componenti, deve essere individuata la provenienza; si deve poi verificare se
qualcuno dei flussi già noti può essere trasformato in uno di questi o viceversa e,
in caso affermativo, quali processi debbono intervenire per effettuare la
trasformazione.
A questo punto si inseriscono i data store (archivi) segnalati dall’utente, dei quali
si deve conoscere esattamente il contenuto, in modo da poter raffigurare cosa
fluisce da o verso ciascuno di essi.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
22
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.3. Attribuzione di un nome a flussi,
data store, origini e destinatari
La scelta del nome da assegnare ad un flusso ha notevoli effetti per la leggibilità
complessiva del DFD.
Vengono esposte, di seguito, alcune regole empiriche per evitare errori.
•
E` necessario riuscire a dare un nome ad ogni singolo flusso. Se per qualche
flusso questa operazione non riesce, bisogna scomporlo.
•
Si deve cercare di attribuire un nome appropriato, che sia rappresentativo
dell’intero flusso e non solo dei suoi principali componenti.
•
E` importante evitare termini generici, quali, ad esempio, “dati” e
“informazioni”.
•
Si deve porre attenzione a non raggruppare assieme in un unico flusso
componenti che non devono essere trattati in modo analogo.
A volte il nome più appropriato per un flusso è del tipo “cosa necessaria” oppure
“misto vario”.
Quando ciò avviene non ci si deve sforzare di trovare un nome diverso al flusso,
bensì lo si deve spezzare in due o più flussi a cui sia possibile attribuire nomi
meno generici.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
23
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.4. Attribuzione di un nome ai processi
E` opinione diffusa tra gli studiosi della materia che procedere prima
concentrandosi sui flussi e poi sui processi sia intrinsecamente un approccio topdown, mentre procedere concentrandosi prima sui processi sia intrinsecamente un
approccio bottom-up.
Quando a tutti i flussi è stato attribuito un nome, è un problema banale attribuire
un nome ai processi.
Si osservi ora la figura 10.
Figura 10
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
24
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Come si può facilmente notare, è facile attribuire al processo P il nome “Validare
la Transazione”, mentre è impossibile assegnare un nome adeguato ai flussi A, B,
C basandosi solo sul nome del processo “Controllo Giacenza”.
Nell’attribuire un nome ai processi si consiglia di seguire le regole di seguito
esposte.
•
E` necessario assicurarsi di dare un nome appropriato e rappresentativo
dell’attività svolta.
•
Bisogna esprimere il nome con una frase imperativa composta di un solo
predicato verbale e di un solo complemento oggetto; se i predicati verbali sono
due, probabilmente il processo deve essere spezzato.
•
Si debbono evitare termini troppo generici come, ad esempio, “trattare”,
“manipolare”, “gestire”.
•
Qualora l’unico nome appropriato da attribuire ad un processo contenga uno
dei termini generici precedentemente indicati, il processo dovrà essere
scomposto in uno o più processi ai quali sia possibile dare nomi significativi.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
25
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.5. Rappresentazione dei flussi di dati
e non di quelli di controllo
L’abitudine a ragionare in termini procedurali può indurre a considerare come
flusso di dati quello che in realtà è un flusso di controllo.
I flussi di controllo vanno eliminati dal DFD.
Un flusso è di controllo quando la sua presenza serve solo per attivare un
processo o per guidare il modo in cui un processo lavora.
In figura 11 solo due sono i flussi di dati legittimi: “somma fattura” e “imposta
globale”.
Figura 11
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
26
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
4.6. Prepararsi a ricominciare
La mente umana lavora in modo iterativo, non fa mai niente di completamente
esatto al primo tentativo.
E` pertanto naturale prendere una realizzazione imperfetta di un determinato
lavoro ed apportarvi aggiunte significative.
In quest’ottica, se consideriamo i DFD e teniamo conto che i meccanismi di
disegno sono banali, ripartire cancellando qualcosa è un prezzo non elevato per
ottenere un risultato migliore.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
27
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
5. SCOMPOSIZIONE A LIVELLI
In figura 12 è illustrato il DFD di un semplice programma di aggiornamento di un
archivio di documenti.
Esso ci fornisce una sufficiente visione d’insieme, pur avendo eseguito una
adeguata scomposizione di processi.
Nell’uso dei DFD nasce però un problema: se il quadro di un’applicazione
relativamente banale è già sufficientemente grande, cosa si deve disegnare sul
singolo foglio di carta?
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
28
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 12
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
29
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
5.1. Approccio top-down: il concetto
di scomposizione a livelli
Quando un sistema è troppo grande perché il suo DFD possa essere disegnato in
una sola pagina, bisogna scomporlo in sottosistemi.
Se anche i sottosistemi sono troppo grandi, vanno scomposti e così via.
Se si descrive ognuna di queste successive scomposizioni con un DFD si ottiene
un insieme di DFD scomposti a livelli (si veda la figura 13), il quale mantiene lo
stesso contenuto di informazioni riguardanti il sistema ma risulta essere
decisamente più leggibile.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
30
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 13
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
31
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
5.2. Componenti di DFD a livelli
Un insieme di DFD scomposti a livelli è caratterizzato dal tipo dei livelli:
superiore, inferiore, intermedio.
Il livello superiore è un unico diagramma definito “di contesto”.
Il livello inferiore è composto da un insieme di processi non più divisibili; per
questo motivo è chiamato anche “diagramma delle trasformazioni elementari”.
I livelli intermedi comprendono infinite varietà tra questi due estremi, a seconda
della complessità del sistema analizzato.
Il diagramma di contesto identifica il dominio dello studio.
In figura 14 sono rappresentati il diagramma di contesto ed il diagramma a livello
0 relativi ad un sistema di cui viene effettuato lo studio.
Si può notare come il diagramma di contesto sia sufficiente a far capire di cosa si
sta trattando.
Nelle figure 15, 16 e 17 sono illustrate le scomposizioni di primo livello dei tre
processi individuati a livello 0.
Il/i diagramma/i delle trasformazioni elementari comprende/comprendono i
processi non più divisibili perché presentano quel tipo di livello atomico che
impedisce ulteriori scomposizioni, oppure perché per scelta d’analisi si decide
di aver raggiunto un livello di conoscenza adeguato al problema.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
32
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 14
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
33
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 15
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
34
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 16
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
35
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
Figura 17
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
36
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
5.3. Convenzioni
Quando si effettua l’esplosione di un diagramma di partenza in uno o più di
arrivo, il diagramma di partenza si chiama genitore e quelli di arrivo si chiamano
diagrammi figlio.
Un diagramma figlio fornisce una visione più dettagliata della trasformazione
indicata nel diagramma padre.
E` importante verificare che gli input primari e gli output finali del diagramma
figlio coincidano con input e output del corrispondente processo nel diagramma
padre.
L’equivalenza tra input e output nei diagrammi padre e figlio è espressa con il
termine di “bilanciamento”, che sta a significare: tutti i flussi che entrano in un
diagramma figlio sono rappresentati nel diagramma padre dagli stessi flussi
entranti nel processo associato; gli output del diagramma figlio sono gli stessi
output del processo associato nel diagramma padre, con l’eccezione degli scarti
banali.
Per quanto riguarda i data store, vale la regola seguente: un data store va
rappresentato nei DFD al primo livello in cui viene usato come interfaccia tra due
processi.
Ne consegue che al primo livello in cui compare un data store sono evidenziati
tutti i riferimenti ad esso relativi.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
37
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
5.4. Determinazione del livello finale
Il processo di scomposizione non può ovviamente proseguire all’infinito: esso si
dovrà arrestare ad un livello di dettaglio ritenuto accettabile.
In base a precise scelte di progetto, si potrà adottare il criterio che si ritiene più
opportuno, per quanto arbitrario esso sia, per stabilire se si è giunti al livello finale
di scomposizione, in funzione del risultato che si vuole ottenere (analisi
preliminare, analisi funzionale, analisi tecnica, ecc.).
Vengono comunque forniti, di seguito, i criteri più diffusi.
•
Il processo di scomposizione si arresta quando si riesce a descrivere
completamente un processo all’ultimo livello con una serie di specifiche
sintetiche che riescono a stare in una pagina.
Esse saranno “specifiche strutturate”, talvolta espresse sotto forma di
pseudocodice [3].
•
Il processo di scomposizione deve procedere fino a che ogni processo presenta
un solo flusso di ingresso ed uno solo di uscita (ovviamente in questo computo
vanno trascurati i flussi banali o di errore), accettando comunque un numero
limitato di processi di “merge”, caratterizzati dall’avere più flussi in input ed
uno in output.
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams
38
Mauro Pullin - Progetto e realizzazione di soluzioni applicative
_______________________________________________________________________________
6. BIBLIOGRAFIA
[ 1]
E. Yourdon
«Managing The System Life Cicle:
Methodology Overview»
Yourdon Press, New York, 1982
[ 2]
J. Weinberg
«Introduction to General Systems Thinking »
[ 3]
G. Casadei, A. Teolis
« Introduzione all’Informatica: la Programmazione »
Zanichelli, Bologna, 1979
a Software Development
_______________________________________________________________________________
Fondamenti di analisi strutturata: i Data Flow Diagrams