La fase di analisi concettuale ha il compito di approfondire la conoscenza del dominio del problema in maniera tale da poter descrivere, in modo preciso e completo, il "cosa" un progetto deve realizzare indipendentemente dagli aspetti implementativi. Inoltre, essa deve definire in modo rigoroso e formale tutte le responsabilità del sistema da automatizzare.

Gli obiettivi dell’analisi concettuale quindi sono:

• la conoscenza approfondita del dominio del problema, senza trascurare alcun dettaglio,
• il consolidamento della suddivisione del sistema nei sottosistemi individuati nella fase di analisi e definizione dei requisiti,
• l’elaborazione dello schema concettuale dei dati (diagramma E-R),
• l’elaborazione dello schema concettuale delle funzioni (Data Flow Diagram),
• la produzione del documento di analisi che, seppur derivato da quello dei requisiti, rappresenta comunque un prodotto, in quanto descrive la realtà d’interesse – sempre da un punto di vista concettuale – ma ad un livello di astrazione differente.

In questa fase qualsiasi diagramma E-R e DFD precedentemente elaborato, non viene preso in considerazione. Mentre nell’attività precedente essi rappresentano uno strumento per l’individuazione delle responsabilità, nell’analisi concettuale, in qualità di prodotti finiti, essi devono definire, in maniera esaustiva, rigorosa e formale, il dominio del problema.

Come schematizzato in Figura 6.2.1, l’input di questa fase è il documento dei requisiti; l’output è costituito dal diagramma Entity-Relationship, dal Data Flow Diagram e dal documento di analisi.

Allo scopo di aumentare la conoscenza del dominio del problema, la fase di analisi concettuale prevede due attività fondamentali:

• l’analisi concettuale dei dati,
• l’analisi concettuale delle funzioni.

I percorsi metodologici che si possono attuare nella fase di analisi sono diversi e la loro determinazione è intimamente legata al dominio del problema in esame. Così possono esistere casi in cui è richiesto lo sviluppo preferenziale dell'analisi dei dati rispetto a quello delle funzioni e casi in cui è richiesto il contrario.

In generale ogni attività di analisi può integrare e supportare l'altra attraverso successivi raffinamenti della conoscenza del dominio del problema, in questo caso parliamo di "Analisi integrata dei dati e delle funzioni", (Batini, Cap. 9). Ad ogni modo tutti i risultati dell’analisi devono essere riportati nel documento di analisi.

Uno schema delle attività è mostrato in Figura 6.2.2.

Esistono due strategie che caratterizzano il verso di percorrenza di un processo di analisi concettuale, sia per l’analisi delle funzioni che per l’analisi dei dati, la strategia top-down e quella bottom-up. La prima si avvale di primitive di trasformazione che, applicate ad un singolo concetto, ne produce una descrizione più dettagliata. La seconda, invece fa uso di primitive che introducono nuovi concetti e proprietà, non presenti nello schema iniziale.

Le primitive e le strategie rappresentano dei punti fermi per la definizione del piano metodologico. Una buona metodologia è un compromesso tra due aspetti contrastanti: rigorosità, e flessibilità. Un processo di decisione, infatti, da una parte deve corrispondere ad un algoritmo e dall’altra deve poter essere applicato a vari ambienti e situazioni.

Nella strategia top-down lo schema concettuale viene prodotto mediante una serie di raffinamenti successivi, a partire da uno schema iniziale, che descrive tutte le specifiche con pochi concetti molto astratti. Lo schema viene via via raffinato mediante opportune trasformazioni, che aumentano il dettaglio dei concetti presenti. Nella strategia bottom-up, l’analisi parte dalle componenti più piccole, che descrivono frammenti elementari della realtà d'interesse. A questo punto le varie componenti vengono rappresentate da semplici schemi concettuali, che possono consistere anche in semplici concetti. I vari schemi così ottenuti vengono poi fusi fino a giungere, attraverso una completa integrazione di tutte le componenti, allo schema concettuale finale. Esiste poi una terza strategia: inside-out, che può essere vista come un caso particolare della bottom-up. In questo caso vengono individuati inizialmente solo alcuni concetti importanti, poi si procede, a partire da questi, a "macchia d'olio".

Ognuna delle strategie citate presenta vantaggi e svantaggi. La top-down ha il vantaggio di permettere una descrizione delle specifiche essenziale, trascurandone i dettagli, ma per fare questo è necessaria sin dall'inizio una visione globale ed astratta di tutte le componenti del sistema e questa, quando il sistema è complesso, è difficile da avere. Al contrario, la strategia bottom-up si riesce ad adattare ad una decomposizione del problema in componenti più semplici, lo svantaggio risiede nel fatto che, a volte, l'integrazione delle diverse componenti risulta difficoltosa.

Esiste allora la possibilità di adottare una strategia mista, con la quale si cerca di combinare i vantaggi della strategia top down con quelli della bottom-up. L’analista parte dai frammenti elementari della realtà d’interesse, come nella strategia bottom-up, ma allo stesso tempo definisce uno schema scheletro contenente, a livello astratto, i concetti principali dell'applicazione. Questo schema scheletro fornisce una visione unitaria, sia pure astratta, dell'intero progetto e favorisce le fasi d'integrazione degli schemi sviluppati separatamente.

La strategia mista è probabilmente la più flessibile perché si adatta bene ad esigenze contrapposte: quella di suddividere un problema complesso in sottoproblemi e quella di procedere per raffinamenti successivi.

L’integrazione tra le attività dell’analisi concettuale rappresenta la parte di metodologia che unisce la determinazione degli aspetti statici di un dominio del problema con quelli dinamici.

Lo sviluppo, dello schema concettuale dei dati e delle funzioni, è orientato verso una integrazione tra le due attività. Uno scambio di informazioni tra le due attività permette di ottenere una schematizzazione più completa.

La motivazione principale legata ad un’analisi congiunta è da ricercarsi nella possibilità di supporto ed integrazione delle attività. Non di minore rilevanza è la proprietà associata all'analisi congiunta denominata "mutua completezza". Quest'ultima, sviluppandosi reciprocamente per entrambe le analisi, fa sì che uno schema sia ritenuto completo rispetto all’altro e viceversa.

Risulta d'obbligo per una analisi rigorosa e formale, che entrambi gli schemi siano mutuamente completi, verificandosi entrambe le proprietà di completezza. Ciò può avvenire solo attraverso un confronto incrociato del contenuto informativo di entrambe.

Lo schema schema metodologico dell’analisi integrata proposto da Batini prevede l’elaborazione dello schema dei dati e delle funzioni attraverso tre fasi:

Questa fase, può essere sintetizzata attraverso tre passi fondamentali:

- l’identificazione delle interfacce esterne all’applicativo che si vuole realizzare;

- la determinazione della tipologia e direzione dei flussi dei dati interscambiati;

- la realizzazione di uno schema scheletro sia dei dati che delle funzioni.

L’output che si ottiene da questa fase è rappresentato dal diagramma di contesto e dai diagrammi E-R e DFD di primo livello.

Viene ripetuto, attraverso un procedimento iterativo, un raffinamento sia dello schema dati che di quello delle funzioni, assumendo come punto di partenza gli schemi ottenuti precedentemente. L’iter di procedimento può partire sia dalla identificazione delle responsabilità, che forniranno un valido aiuto per la determinazione delle entità non ancora rilevate, o viceversa dall'analisi di entità non ancora inserite all’interno dello schema delle funzioni che permette una identificazione di responsabilità non ancora evidenziate.

L'interpretazione dei possibili raffinamenti che si possono ottenere è rappresentato in parte nella tabella, mentre per una trattazione più completa si rimanda a Batini. In Figura 6.2.3 si riporta lo schema dei raffinamenti successivi, così come proposta da Atzeni.

La verifica della mutua completezza degli schemi dei dati e delle funzioni, ha l’obiettivo di rappresentare, all’interno di essi, tutti i concetti espressi nel documento dei requisiti.

Questa attività può avvenire in due situazioni. La prima alla fine di ogni singolo raffinamento, operazione opzionale e volta al miglioramento dei due schemi.

La seconda antecedente all’elaborazione dei due documenti come prodotti finali.

Abbiamo detto che l’obiettivo della fase di analisi è la conoscenza in dettaglio del dominio del problema e che i prodotti della fase di analisi sono il diagramma E-R (Entity-Relationship), il DFD (Data Flow Diagram) e il documento di analisi.

Come già detto nel capitolo 5, il prototyping pervade tutte le attività della produzione del software gestionale, ed in fase di analisi rappresenta uno strumento essenziale di comprensione del dominio del problema. In questo contesto non si vogliono dare indicazioni su come realizzare il prototipo, ma si vuole evidenziare qual’è la sua rilevanza metodologica e quali sono gli obiettivi perseguibili attraverso il suo utilizzo. La tecnica del prototyping si è affermata grazie al fatto che permette di mostrare in modo iterativo all’utente ciò che il progetto deve realizzare.

Resti inteso che il prototipo d’analisi non deve mai evolversi in pacchetto applicativo e a tale scopo è preferibile che sia realizzato con strumenti diversi da quelli che si utilizzeranno in fase di realizzazione. La sua funzione è solo quella di mostrare ai vari utenti il comportamento del sistema, al fine di ottenere da essi il maggior numero di informazioni possibili per ampliare la conoscenza, che l’analista deve avere, del dominio del problema.

Il prototipo di analisi stabilisce un protocollo di comunicazione comune tra l’utente e l’analista. Questo permette all’utente di esprimere interamente le proprie esigenze e all’analista di approfondire la conoscenza del dominio del problema. Inoltre il prototipo rappresenta un modello empirico utilizzato per la realizzazione e la formalizzazione dei modelli concettuali, ed è lo strumento che aiuta a raffinare i diagrammi E-R e DFD.

Il prototipo viene creato nel rispetto delle funzionalità di primo livello individuate, a partire dai requisiti formalizzati. La realizzazione del prototipo avviene attraverso successivi raffinamenti, questo procedimento è detto meccanismo di prototipizzazione. Quest’attività è di fondamentale importanza nella fase di analisi concettuale. In questa fase vogliamo ottenere una visione chiara e completa del dominio del problema, cioè di tutto quello che il progetto deve realizzare.

L’obiettivo è di ottenere uno schema concettuale esauriente, sul quale elaborare le modalità di realizzazione del sistema durante la fase di progettazione. Alla fine dell’attività di analisi deve essere disponibile un prototipo di livello n, derivante da n raffinamenti, dipendentemente dalla complessità del dominio del problema, che descrive completamente l’interfaccia utente.

Per arrivare ad una visione chiara e completa, è necessario il confronto con l’utente, che spesso non ha un’idea precisa di cosa il sistema informatico debba realizzare, o più semplicemente non è in grado, dalle sole specifiche formulate in linguaggio naturale, di darne una visione chiara e completa. Un modo per facilitare la comprensione del dominio del problema è l’utilizzo di un prototipo dalle seguenti caratteristiche:

• veloce da elaborare;
• non costoso;
• chiaro, cioè di comune comprensione, sia da parte dell’analista che dell’utente;
• completo, cioè che descriva tutte le responsabilità da realizzare.

Il prototipo diventa un modo per consentire il confronto tra l’analista e l’utente, deve cioè permettere la comprensione di cosa il sistema sarà in grado di fare, prima ancora di essere implementato.

L’analista ha così la possibilità di presentare all’utente il prodotto, nelle sue prime fasi di realizzazione, e l’utente di valutare se tale prodotto corrisponde alle sue esigenze. A seguito di ogni colloquio verranno evidenziate le eventuali modifiche da apportare al prodotto, in questo modo l’analista avrà modo di raffinare i diagrammi E-R e DFD, sulla base dei nuovi dettagli acquisiti sul dominio del problema.

L’utilizzo degli strumenti descritti porta all’elaborazione in linguaggio naturale del documento di analisi. Tale documento ricalca la struttura del documento di analisi e definizione dei requisiti (vedi paragrafi 6.1.6 e 6.2.6).

Nella Figura 6.2.5 viene fornita una descrizione più dettagliata delle attività della fase di analisi; l’analisi dei dati e l’analisi delle funzioni vengono sviluppate attraverso successivi raffinamenti del prototipo, ognuno dei quali porta ad un raffinamento dei diagrammi E-R e DFD, fino al raggiungimento della conoscenza del dominio del problema al livello di dettaglio più accurato. A questo punto verrà formalizzato il documento di analisi, che fornisce una descrizione completa ed esauriente della realtà d’interesse.

Per la validazione dei documenti, viene sviluppata un’attività di review, che pervade tutta la fase di analisi concettuale, e si conclude con l’approvazione del documento finale.

Il percorso metodologico di riferimento proposto si basa sulla metodologia integrata dati-funzioni proposta da Batini. Una sua schematizzazione bidimensionale, esprimente i livelli di astrazione e raffinamento legati ai passi di derivazione e integrazione dei prodotti, è riportata in Figura 6.2.6.

Sulla coordinata dell’ascissa, attinente all’organizzazione dei concetti, compaiono i seguenti elementi: il documento dei requisiti, che rappresenta il collegamento con la fase precedente di analisi e definizione dei requisiti; il diagramma E-R; il DFD ed il documento di analisi. Questi ultimi rappresentano i prodotti della fase di analisi, proposti ad un livello di dettaglio opportuno.

In questo percorso metodologico l’input, identificato dal documento dei requisiti, viene fornito a livello di sistema.

L’analisi concettuale deve essere fatta per ogni sottosistema di livello 1. Se un progetto racchiude più modalità operative, da intendersi applicativi distinti, si procede alla costruzione dei prodotti, quali il DFD e il diagramma E-R, in modo separato per ogni sottosistema di livello 1, in modo da ridurre la complessità del sistema da realizzare. L’analisi concettuale dei sottosistemi di livello 1 può essere anche sviluppata da gruppi di lavoro differenti che procedono in parallelo.

Per ogni sottosistema di livello 1 si individuano i differenti livelli di sottosistemi di livello maggiore del primo (i-esimi).

Il processo di derivazione del documento di analisi e definizione dei requisiti permette, all’analisi dei dati e delle funzioni, di dar vita, attraverso il diagramma di contesto, a due prodotti intermedi: il DFD e il diagramma E-R, riferiti entrambi al sottosistema i-esimo.

L’intervento dell’analisi integrata dati-funzioni (riportata nel capitolo nono del testo di Batini), permette, attraverso una serie di raffinamenti prima e integrazione poi, di trasformare i diagrammi in prodotti finiti per i sottosistemi di livello 1, ovvero per ogni modalità operativa.

I diagrammi concettuali raffinati, unitamente al documento dei requisiti, generano il documento di analisi, dapprima relativo ad ogni responsabilità, poi integrato a livello di sottosistema di livello 1.

Il Documento di analisi ha la stessa organizzazione del Documento dei requisiti:

Premessa: Descrizione della realtà d’interesse; Contesto; Vincoli; Ambiente Tecnologico; Sistema Operativo; DBMS; Ambiente di Sviluppo; Interfaccia.

Obiettivi: Descrizione degli obiettivi che il software da sviluppare deve perseguire.

Il compito del documento è quello di specificare il dominio del problema al livello di dettaglio completo, senza preoccuparsi della definizione del dominio, che è già stata affrontata nella fase precedente. Per questo motivo, nel documento di analisi non esiste una sezione dedicata alle funzionalità esistenti e quelle future, ma verranno trattate solo le funzionalità da implementare. Questo aspetto distingue ulteriormente i due documenti non solo nei contenuti ma anche nella forma.

Siccome in questa fase viene approfondita la conoscenza del dominio del problema, nel documento di analisi vengono dettagliate le descrizioni delle responsabilità individuate in fase di analisi e definizione dei requisiti.

Inseriamo come esempio del meccanismo di raffinamento del documento dei requisiti nel documento d’analisi, un estratto dei due documenti elaborati per l’analisi di un applicativo per la gestione contabile:

Come si può notare, il documento dei requisiti e quello di analisi, si differenziano soltanto per il livello di astrazione con cui sono elaborati.

Infine nel documento di analisi non viene inserito il Glossario, già presente nel documento dei requisiti, ma verrà creato un Dizionario dei Dati, come documentazione dello schema concettuale dei dati. Tale dizionario è composto da due tabelle, una per la descrizione delle entità, l’altra per quella delle relazioni (per una trattazione dettagliata si rimanda al cap. 5 del testo di Atzeni).