Ufficio Centrale per lo sviluppo e la gestione del Sistema Informativo
 |
MetoDoc v1.0 |
|
MetoDoc v1.0 |
L'attività di progettazione è la fase della produzione del software gestionale volta a definire come realizzare le responsabilità che sono state individuate, in modo completo, nella fase di analisi concettuale.
Come accade per ogni altro tipo di prodotto, il software viene sviluppato da un processo produttivo, la cui struttura può avere una forte influenza sulle qualità del prodotto finale, oltre che sul costo del processo che porta a quel prodotto. Per capire il ruolo della progettazione in tutto ciò conviene distinguere i fattori di qualità interni da quelli esterni. Le qualità esterne sono quelle percepibili dall'utente che esamina il processo o il prodotto come se fosse una scatola nera. Le qualità interne sono invece quelle che rappresentano il modo in cui quelle esterne possono essere raggiunte: in altre parole implementano (sono un modo per realizzare) le qualità esterne.
Nella progettazione gli aspetti statici del sistema (progettazione logica dei dati) e gli aspetti dinamici (progettazione logica delle responsabilità) andranno descritti in modo separato, mediante gli specifici modelli di rappresentazione che devono essere sviluppati parallelamente perché fortemente interdipendenti ed interagenti.
Figura 6.3.1 – Il prodotto della fase di Progettazione.
La metodologia prevede la stesura di un Documento di Progetto o Documento delle Specifiche di Progetto, che discende in modo diretto dalla sintesi di queste attività, unitamente ad un efficace utilizzo del linguaggio naturale. E' essenziale sottolineare che il documento prodotto è sostanzialmente diverso da quelli che escono dalle fasi precedenti, in quanto è l'unico documento nella produzione del software che illustra in modo inequivocabile e completo come verranno realizzate e soddisfatte le richieste dell'applicativo.
L'implementatore, con i prodotti che il progettista gli fornisce, deve essere in grado di realizzare un applicativo funzionante e definitivo.
6.3.1 Attività di progettazione
Il progettista riceve dal team di lavoro che ha analizzato le funzionalità da soddisfare, una serie di prodotti indispensabili che sono il punto di partenza per la sua attività: il documento di analisi, lo schema Entità -Relazione e il Data Flow Diagram delle funzioni.
Nella Progettazione è evidente, più che in ogni altra fase della produzione che lo studio della base dati e delle responsabilità deve procedere in modo separato (ma è indubbio che le due cose restano ancora imprescindibili l'una dall'altra).
Dallo schema concettuale (E-R) il progettista elabora la struttura della base dati, con il supporto del modello relazionale, strumento ormai consolidato e universalmente accettato in ambito accademico e industriale (questo dimostra quanto sia divenuto uno strumento irrinunciabile). In questo momento deve essere in grado di valutare e prevedere il carico applicativo e tenere conto dell'ambiente di sviluppo scelto in fase di analisi e definizione dei requisiti. Egli realizza un diagramma logico dei dati che è radicalmente diverso dallo schema E-R di partenza, infatti vengono fatte considerazioni sulle dimensioni dei campi, sul numero occorrenze e sulle distribuzioni delle tabelle nei diversi Database.
Figura 6.3.2 – Le attività della Progettazione.
Un discorso analogo non si può fare per la progettazione delle responsabilità in quanto il modello utilizzato è lo stesso della fase di analisi: il Data Flow Diagram. Il DFD di progetto permette di giungere alla esplosione più spinta delle singole responsabilità sviscerando la parte dinamica dell'applicativo. La bravura del progettista risiede proprio nel giungere ad un punto in cui il diagramma gli permette di prendere in considerazione la successione temporale e la sincronizzazione degli eventi attraverso lo schema di struttura Stati/Eventi.
Negli ultimi anni, nello scenario in cui un progetto software nasce e si sviluppa , è entrato in gioco un nuovo attore, il prototipo, uno strumento potentissimo che abbiamo già incontrato nelle altre fasi, ma che qui ha un utilizzo completamente diverso. La tecnica del Prototyping, che solo ora sta assumendo la dignità di modello grazie a tentativi di formalizzazione (es. "The Prototyping Methodology" di Kenneth E. Lantz) e alla disponibilità di ambienti di sviluppo visuali versatili e relativamente semplici, pervade le due attività, nel senso che permette di unire in modo intuitivo la funzionalità da implementare con la base dati tramite una vista logica.
La figura 6.3.3 presenta questi concetti.
Figura 6.3.3 – Le attività della Progettazione.
6.3.2.1 Il Modello Relazionale
Nella progettazione della parte statica del sistema l'obiettivo è quello di costruire uno schema logico in grado di descrivere, in maniera corretta ed efficiente tutte le informazioni contenute nello diagramma E-R prodotto nella fase concettuale.
Lo strumento che si utilizza in questa fase è il modello relazionale.
Bisogna sottolineare che non si tratta di una semplice traduzione da un modello a un altro perché, prima di passare allo schema logico, lo schema E-R va ristrutturato per soddisfare due esigenze: quella di tradurre e di ottimizzare le prestazioni del progetto.
La progettazione logica dei dati deve tenere conto, per quanto possibile, delle prestazioni dell’applicazione adattandosi al sistema di basi di dati (DBMS) scelto.
Nella figura seguente si illustrano le varie fasi della progettazione per la traduzione dallo schema concettuale a quello logico e si evidenziano gli strumenti e le informazioni di input di cui si tiene conto
I dati in ingresso della prima fase sono lo schema E-R prodotto nella fase concettuale e il carico applicativo previsto, in termini di volume dei dati e frequenza delle operazioni.
Il risultato che si ottiene è uno schema E-R ristrutturato, che non è più uno schema concettuale tout court, in quanto costituisce una rappresentazione dei dati che tiene conto degli aspetti realizzativi.
Lo schema logico finale, i vincoli di integrità definiti su di esso e la relativa documentazione costituiscono i prodotti finali della progettazione logica.
La figura 6.3.4 è ripresa integralmente dal testo di Atzeni (cap. 7, pag. 224).
Figura 6.3.4 – La progettazione logica dei dati (Atzeni).
Il cuore della progettazione della parte dinamica del sistema parte dalla trasformazione delle informazioni delle responsabilità acquisite dall’analisi.
Da un lato il progetto risultante deve essere sufficientemente astratto per essere agevolmente confrontato con le specifiche da cui viene derivato, dall'altro lo stesso progetto deve essere sufficientemente dettagliato in modo tale che la codifica possa avvenire senza ulteriori necessità di chiarire le operazioni che devono essere realizzate.
Si propone un procedimento analogo a quello indicato da Atzeni per la progettazione logica dei dati e si schematizza tale procedimento nella figura 6.3.5, che deriva dalla Figura 6.3.4.
Per muoversi dall'organizzazione a grafo dell'analisi (DFD) ad un'organizzazione tecnica per il progetto si possono utilizzare nuovamente come strumento i DFD scendendo ad un livello di dettaglio in cui viene descritto ciascun processo semplice che appartiene ad una responsabilità.
Mentre i DFD dell'Analisi sono una rappresentazione reticolare di bolle e memorie di massa, i diagrammi strutturati per la progettazione sono una rappresentazione gerarchica di moduli in cui si sono aggiunte considerazioni basate su vincoli realizzativi. E’ sottinteso che in ogni passo di raffinamento deve essere assolutamente rispettato il vincolo di continuità del flusso informativo, poiché per progetti particolarmente complessi il diagramma rischierebbe di diventare poco controllabile.
Figura 6.3.5 – La progettazione logica delle responsabilità.
I Data Flow Diagram forniscono solamente informazioni sulle dipendenze funzionali tra i dati, ma sono quantomeno imprecisi per quanto riguarda gli aspetti di sincronizzazione e controllo.
Ciascuna responsabilità, descritta nei DFD, di progetto è costituita da più processi elementari dei quali si rappresenta lo stato per mezzo di diagrammi Stati/Eventi: questo strumento, per ciascuna responsabilità, introduce la coordinata temporale nella descrizione dei vari processi, che risulteranno così sincronizzati.
All’interno dello sviluppo di software gestionale, usualmente si riscontrano tre stati individuabili dei processi e, peraltro, stravolgeremmo lo spirito e lo scopo di questo lavoro se pretendessimo di esaurire tutte le ulteriori possibilità di stato che possono presentarsi: lo stato INIT indica lo stato in cui ogni processo singolo si trova prima che venga attivato da un evento; lo stato NEW indica che l’esecuzione del processo ha condotto ad una modifica delle proprietà dello stato iniziale (si pensi alla modalità di inserimento dei dati in un archivio elettronico); lo stato EDIT indica tipicamente la condizione in cui si permette la modifica di dati del Database (stiamo operando in ambito Gestionale!).
Allo scopo di fornire uno strumento al progettista che si basa su una descrizione formale meno astratta e più efficientemente eseguibile dei requisiti dettati dall’analisi si introduce la tecnica della prototipizzazione (prototyping).
Il prototipo che si utilizza in questa fase di progettazione determina la reale fattibilità delle responsabilità ed è espressamente rivolto all’implementatore.
In questa ottica definisce un modello di prototipo il cui solo obiettivo è quello di contribuire a chiarire all’implementatore come devono essere sviluppatate le specifiche definite nei documenti di Analisi.
Nel prototipo di progetto sarà trascurato l’effettivo svolgimento delle operazioni che sono comandate attraverso le maschere, ma per ciascun pulsante o casella o strumento tipico degli ambienti visuali sarà specificato mediante linguaggio naturale l’aspetto tecnico vero e proprio che supporta il processo.
L’implementatore che si trova a dover considerare una per una le responsabilità per svilupparle, trae tutte le informazioni dal documento di progetto ed in particolare dagli schemi DFD e Stati/Eventi, inoltre avendo a disposizione il prototipo di progetto ha una visione rapida e completa di come dovrà apparire il prodotto finale.
Come già detto nel capitolo sulle metodologie di riferimento, il modello relazionale è quello definito da Atzeni, mentre DFD e Stati/Eventi sono quelli descritti da Batini. Spunti si possono trovare in Ghezzi.
Il percorso metodologico (Figura 6.3.6) suggerito per l'attività di Progettazione richiede che il prodotto in ingresso a livello di organizzazione di impresa sia il documento di analisi che fornisce le informazioni e le richieste relative ai singoli sottosistemi.
I diagrammi E-R e DFD forniscono rispettivamente la descrizione per i dati e le funzioni.
Il progettista, dalla ristrutturazione e traduzione dei digrammi E-R, deriva gli Schemi Logici dei singoli sottosistemi i-esimi la cui integrazione descriverà il sistema globale.
La progettazione delle funzioni a partire dal DFD del livello di sottosistema 1 viene esplosa dettagliatamente per ogni responsabilità. Inoltre per ciascuna responsabilità viene sviluppato il diagramma stati/eventi e, se necessario, è possibile rappresentare alcune funzioni utilizzando i diagrammi di flusso o la pseudocodifica.
Il raffinamento del documento di analisi e la sua rielaborazione a livello di singola responsabilità, descritta mediante i DFD e diagrammi Stati/Eventi producono il Documento delle Specifiche di Progetto integrato sino al sottosistema di primo livello.
Figura 6.3.6 – Il percorso metodologico della fase di Progettazione.
La fase di elaborazione degli stati/eventi può dar luogo ad un feedback rispetto al corrispondente prospetto delle responsabilità nei DFD (ad esempio ci si può accorgere che la successione temporale degli eventi necessari a soddisfare una funzionalità non è quella ottimale e porta ad una rielaborazione della struttura della funzionalità)
L’integrazione del Documento di Progettazione a livello di Sottosistema i-esimo può innescare aggiornamenti e riflessioni al livello delle singole Responsabilità.
6.3.4 Contenuto del documento di progetto
Gli strumenti introdotti conducono alla stesura, a mezzo del linguaggio naturale, del documento forse più importante di tutta l'attività: il documento di progettazione. Nel pieno rispetto degli standard definiti nell’ambito dell’intera metodologia, si propone, nel seguito la struttura del documento: per ogni sezione si suggerisce il contenuto che si ritiene più opportuno affinché il prodotto sia sufficiente per la corretta realizzazione dei progetti di interesse per il MURST. In esso devono essere dichiarate in modo esplicito le scelte progettuali effettuate dal professionista, che discendono spesso dalla sua bravura ed esperienza.
Progettazione della Base Dati: In questa sezione il progettista inserisce il diagramma logico necessario alla realizzazione della base dati con commento in Linguaggio Naturale.
Egli illustra le scelti progettuali che lo hanno portato ad organizzare una base dati singola o distribuita.
Progettazione Funzionale: In questo paragrafo si inseriscono gli schemi DFD per ogni singola Responsabilità al livello di astrazione più basso. Suggeriamo un sottoparagrafo per ciascuna esplosione del DFD, così da poter essere individuato direttamente anche dall’indice. Ove necessario (flussi funzionali particolarmente complessi o temporalmente collegati) è auspicabile che venga riportato lo schema Stati/Eventi.
Realizzazione delle Responsabilità: Gli ambienti di sviluppo visuale consento una rapida visualizzazione delle funzionalità a mezzo del prototipo. Questa sezione del documento è dedicata ai commenti in linguaggio naturale concernenti la realizzazione delle funzionalità. Eventualmente a mezzo delle maschere prototipali per la chiarezza e la completezza dell’esposizione, il progettista potrebbe anche inserire una fotografia (snapshot) della maschera.
Dizionario dei Dati: fornisce una descrizione squisitamente sintattica (nome, tipo, lunghezza, descrizione) dei campi, dal momento che specifica esclusivamente la struttura, tralasciando il significato (peculiare dell’analisi).