Object Oriented Analysis

Le metodologie ad oggetti sono state introdotte da poco tempo, prima come strumento di programmazione (OOP - Object oriented programming), quindi anche come strumento di analisi e progettazione.

Se nel campo dei linguaggi di programmazione esiste ormai una storia consolidata, dai primordi del Simula ‘67 allo Smalltalk e alle estensioni di linguaggi più tradizionali come il C verso il C++, per quanto riguarda le fasi di analisi e disegno i metodi proposti non hanno ancora raggiunto una forte diffusione e stabilità.

Una analisi orientata agli oggetti si realizza nel seguente modo:

si riconoscono le varie entità in cui è possibile suddividere il problema

si dividono in classi, raggruppando le entità che hanno delle caratteristiche comuni

per ogni classe si riconoscono gli attributi (dati) ed i metodi (procedure)

si raffinano i singoli oggetti creando sottoclassi e applicando l’ereditarietà

si stabiliscono le comunicazioni tra gli oggetti

Questo modo di procedere presenta dei grandi vantaggi rispetto ai metodi tradizionali.

Il primo vantaggio è proprio lo scopo per cui è stata creato il metodo: una visione unitaria di dati e funzioni. A differenza dei metodi strutturati non si parla più di solo ER o solo DFD, solo dati o solo funzioni, ma si vedono tutte le entità che costituiscono il problema come oggetti, composti dai due aspetti.

Quando un oggetto ci interessa come "dato", basterà mandargli il messaggio opportuno per ottenere le informazioni richieste. Quando ci interessa come funzione basterà ancora mandarli il messaggio opportuno per ottenere il servizio desiderato.

Un secondo vantaggio viene dal modo con cui è guidata la strutturazione top-down del problema.

Le metodologie strutturate si ponevano come obiettivo di partizionare il problema in elementi via via più semplici, in modo da raggiungere delle entità così elementari da non porre alcun problema nell’essere realizzate.

Il singolo processo era però sempre visto come una bolla, senza alcuna specifica ulteriore se non "aprendolo" e controllando le sue "mini spec.".

Il singolo archivio apparteneva alla classe generica dei "file", senza alcuna specifica del significato dei dati memorizzati.

Un oggetto, dal momento che appartiene ad una ben determinata classe, invece è tipizzato, sia come dati che come procedure.

Prendiamo per esempio un archivio clienti ed un archivio fatture con il relativo programma di inserimento, ricerca e variazione dei dati in essi contenuti.

Con metodologie strutturate entrambe appaiono come dei data store, sormontati da una bolla che è il programma di gestione. La bolla può essere poi partizionata in tre sottobolle, una per il caricamento, una per la ricerca e quindi l’ultima per la variazione. I due archivi non hanno nessuna apparente differenza, se non il diverso tracciato record.

In una analisi OO i due archivi appartengono a due classi diverse.

Il primo è una anagrafica, cioè un archivio che viene gestito un record alla volta, il secondo è una movimentazione, in cui hanno significato i blocchi di record identificati dalla stessa chiave primaria.

Entrambe sono classi derivate da una stessa superclasse: la gestione archivi.

Il vantaggio di questo approccio è evidente: non si è persa l’informazione che differenzia i due oggetti! Non è necessario controllare le "mini spec." delle varie bolle per accorgersi che la gestione dei due archivi è completamente differente.

A questo punto siamo pronti per scoprire il vero plus di questo modo di affrontare un problema: se ho già sviluppato un programma di gestione archivi anagrafici, potrò sicuramente adattarlo alla gestione clienti, mentre sarà assai difficile riusarlo per la gestione fatture.

L’analisi Object Oriented guida la riusabilità del software.

L’analista non affronta più i problemi con il solo bagaglio della propria esperienza, ma aiutato anche da tutte le classi che ha sviluppato per i programmi procedenti.

Ogni nuova applicazione diventa un riconoscere quali sono le parti che ricadono in problematiche già risolte, quali sono riconducibili a classi già sviluppate e solo da specializzare con una sottoclasse, quali invece sono completamente nuove e devono essere sviluppate da zero, creando una nuova classe.

Per le parti che ricadono in una classe già risolta, l’analista dispone già del codice completo, senza dover scrivere una sola riga di programma.

Per le classi già note, l’analista riesce a "saltare" le fasi di progettazione e codifica, perchè riusa quelle svolte in precedenza.

Un programma non passa più per tutte le fasi del ciclo di vita:

vedere l’analisi è vedere la gerarchia delle classi scelte per i vari oggetti, vedere la progettazione è evidenziare i messaggi che le varie istanze di queste classi (gli oggetti) si scambiano tra loro, ispezionare il codice dei vari metodi e le variabili di ogni attributo, cioè aprire un oggetto per leggere le parti nascoste alla vista esterna è occuparsi di codifica.

L’analisi OO unisce le fasi di analisi, progettazione e codifica.

Questo facilita l’implementazione di più tipi di cicli di vita.

Il ciclo classico si implementa senza nessun problema; il prototipo rapido: gli oggetti di classi già sviluppate sono già pronti appena riconosciuti, gli altri si approssimano con la classe più vicina, si raffinano in un secondo momento; il ciclo "ciclico" discende dalla vicinanza tra le varie fasi.

Anche l’analisi object oriented ha i suoi strumenti di diagrammazione: il formalismo della figura precedente è quello proposto da Codd e Yourdon per evidenziare le dipendenze tra le varie classi.