Mauro Pullin - I DFD di Yourdon e De Marco - elvira.univr.it · FLOW DIAGRAMS DI YOURDON E DE MARCO...

Mauro Pullin - Progetto e realizzazione di soluzioni applicative _______________________________________________________________________________

_______________________________________________________________________________

Fondamenti di analisi strutturata: i Data Flow Diagrams

1

Mauro Pullin

PROGETTARE CON LA METODOLOGIA DEI DATA FLOW DIAGRAMS DI YOURDON E DE MARCO


_______________________________________________________________________________


2

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


_______________________________________________________________________________


3

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.


_______________________________________________________________________________


4

Figura 1


_______________________________________________________________________________


5

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.


_______________________________________________________________________________


6

3. ELEMENTI COSTITUTIVI DEI DFD Gli elementi basilari che compongono i DFD sono cinque: 1. Flussi (Data Flow), rappresentati per mezzo di linee orientate; 2. Processi (Process), rappresentati per mezzo di cerchi (detti anche “bolle”); 3. Data store (archivi), rappresentati per mezzo di rettangoli aperti; 4. Origini (Source) di dati, rappresentati per mezzo di rettangoli; 5. 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.


_______________________________________________________________________________


7

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.


_______________________________________________________________________________


8

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.


_______________________________________________________________________________


9

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.


_______________________________________________________________________________


10

• 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.


_______________________________________________________________________________


11

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’”.


_______________________________________________________________________________


12

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”).


_______________________________________________________________________________


13

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.


_______________________________________________________________________________


14

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.


_______________________________________________________________________________


15

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.


_______________________________________________________________________________


16

Figura 8


_______________________________________________________________________________


17

Figura 9


_______________________________________________________________________________


18

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.


_______________________________________________________________________________


19

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.


_______________________________________________________________________________


20

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.


_______________________________________________________________________________


21

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.


_______________________________________________________________________________


22

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.


_______________________________________________________________________________


23

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 top-down, 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


_______________________________________________________________________________


24

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.


_______________________________________________________________________________


25

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


_______________________________________________________________________________


26

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.


_______________________________________________________________________________


27

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?


_______________________________________________________________________________


28

Figura 12


_______________________________________________________________________________


29

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.


_______________________________________________________________________________


30

Figura 13


_______________________________________________________________________________


31

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.


_______________________________________________________________________________


32

Figura 14


_______________________________________________________________________________


33

Figura 15


_______________________________________________________________________________


34

Figura 16


_______________________________________________________________________________


35

Figura 17


_______________________________________________________________________________


36

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.


_______________________________________________________________________________


37

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.


_______________________________________________________________________________


38

6. BIBLIOGRAFIA [ 1 ] E. Yourdon

«Managing The System Life Cicle: a Software Development 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

Date post:	15-Feb-2019
Category:	Documents
Upload:	vanthuan
View:	222 times
Download:	1 times

Mauro Pullin - I DFD di Yourdon e De Marco - elvira.univr.it · FLOW DIAGRAMS DI YOURDON E DE MARCO...

Documents