COMPUTERWORLD 7/4/91
L'ANALISI OBJECT ORIENTED
La rapidità di obsolescenza dei prodotti nel mondo
informatico è, si sa, molto accentuata.
In questi anni migliaia di aziende in tutto il mondo
investono in architettura CASE (in prodotti, in
revisioni organizzative, in formazione).
Convinte della possibilità di coniugare qualità e
produttività, confrontano, scelgono, personalizzano
metodologie di sviluppo; consapevoli dell'importanza
centrale dell'analisi per lo sviluppo e la
manutenzione dei sistemi, si predispongono ad
utilizzare le tecniche più avanzate disponibili sul
mercato del knowhow.
Per l'analisi dati, le tecniche derivate dal modello
Entity-Relationship e della teoria relazionale (la
"normalizzazione"), opportunamente combinate,
costituiscono da tempo uno standard nel mondo EDP.
Per l'analisi delle funzioni, la diffusione dei
prodotti CASE sta imponendo in modo generalizzato
l'utilizzo dei Data Flow (DFD), una tecnica nata
negli Stati Uniti nel corso degli anni settanta ma
ancora poco diffusa nella nostra realtà. Lo
scorrevole testo di Ed Yourdon "Modern Structured
Analysis", apparso nel 1989 e tradotto in italiano
l'anno successivo, è attualmente materia di studio
per molti analisti che affrontano per la prima volta
i DFD.
In questo scenario di evoluzione e di investimenti,
già zeppo di punti esclamativi (dei commerciali) e
di punti interrogativi (dei clienti), spunta una
nuova ricetta: l'object oriented.
L'object oriented è un approccio che investe più
aree:
- analisi (object oriented Analysis-OOA)
- disegno ( " " Design-OOD)
- linguaggi ( " " Programming Language-OOPL)
- DBMS (OODBMS)
I primi OOPL (Simula, Smalltalk) risalgono all'inizio
degli anni settanta. A questi negli ultimi anni se ne
sono aggiunti altri (C++, Objective-C, Ada...). Le
estensioni all'analisi, al disegno ed ai DBMS sono
invece molto più recenti, ed allo stato dell'arte
tutt'altro che consolidate.
Ciò nonostante l'object oriented viene presentato
come un approccio "più avanzato", al punto di
rendere obsolete le tecniche di analisi dei dati e di
analisi delle funzioni correntemente utilizzate (cfr.
"Abbandonare i DFD?" di Michele Sacerdoti, su CWI del
14-2-91). Anche il modello relazionale viene messo in
discussione ("gli anni ottanta hanno visto
l'affermazione dei DBMS relazionali, gli anni novanta
vedranno quella dei DBMS Object Oriented" ...)
Avviene così che lo stesso Ed Yourdon, un anno dopo
"Modern Structured Analysis", firmi insieme a Peter
Coad "Object Oriented Analysis", dove dà per ormai
superato l'approccio dell'analisi strutturata.
L'obsolescenza, come si può vedere, è rapida ...
Coad e Yourdon sostengono la superiorità
dell'analisi object oriented sulla base di due
motivi:
1) la tradizionale distinzione tra analisi dei dati
ed analisi delle funzioni porta, in alcuni casi,
ad incongruenze tra schema dei dati e schema delle
funzioni (DFD)
2) l' approccio "orientato agli oggetti" è più
"naturale", ossia più vicino al modo in cui gli
esseri umani organizzano la propria conoscenza del
mondo reale.
La prima motivazione ha sicuramente un fondo di
verità: analisi dati ed analisi delle funzioni, se
condotte da gruppi di lavoro diversi e non
comunicanti, possono portare a risultati non
omogenei.
La seconda motivazione è solo una petizione di
principio, in quanto non ne esistono dimostrazioni;
inutile, quindi, discuterne.
Scendendo nel dettaglio, la tecnica di analisi object
oriented proposta da Coad e Yourdon presenta più di
un'analogia con un entity relationship tradizionale
arricchito della parte funzionale.
I passi consigliati sono i seguenti:
- definizione degli oggetti (entità)
- definizione delle strutture (si tratta delle
gerarchie IS-A, definite come "strutture di
classificazione", e delle associazioni del tipo
insieme/componenti - ad esempio i due oggetti
"ordine" e "riga ordine" - definite come "strutture
di assemblaggio")
- definizione dei soggetti (si tratta di viste
logiche, analoghe alle "subject area"
dell'information engineering)
- definizione degli attributi e delle "instance
connections" (tutte le associazioni che non
rientrano nelle tipologie precedenti)
- definizione dei "servizi" (processi)
Il tutto, secondo un approccio esclusivamente top
down (secondo Coad e Yourdon, la normalizzazione
degli oggetti, cioè la parte "bottom up"
dell'analisi dati, è un problema di disegno, non di
analisi...) e data driven.
Quest'ultima caratteristica riveste una particolare
importanza. Come tutti gli approcci rigidamente data
driven, anche questo comporta la difficoltà di
individuare quali oggetti facciano parte del sistema
in esame, e quali invece non rientrino nel campo
dell'analisi.
La determinazione del contesto del sistema da
analizzare è centrale per l'analisi strutturata
basata sui DFD. Ma nell'analisi object oriented viene
completamente abbandonata: il "problem space" è
considerato solo in termini impliciti ed intuitivi,
con tutti i problemi di ambiguità che ne possono
derivare.
L'analisi della parte funzionale (i "servizi") appare
poi estremamente sacrificata e semplicistica. Per
ogni oggetto individuato vengono definiti
"automaticamente" servizi di lettura, inserimento,
aggiornamento e cancellazione. Altri servizi vengono
individuati sulla base del "ciclo di vita" e degli
"stati" assumibili dagli oggetti. Le funzionalità
che possono coinvolgere più di un oggetto vengono
realizzate tramite "messaggi" che gli oggetti si
scambiano per attivare servizi definiti al loro
interno. Solo nel caso tali funzionalità risultino
molto complesse viene consigliato di specificarle
utilizzando i DFD.
L'impostazione tradizionale dell'analisi, che vedeva
la definizione dei dati subordinata a quella delle
funzioni, viene completamente ribaltata. Le funzioni,
ormai, sono interamente "incapsulate" all'interno
degli oggetti. Ma il metodo di analisi proposto non
ci sembra molto convincente.
"Abbandonare i DFD", o utilizzarli solo in casi
eccezionali, come gli autori propongono, significa
perdere tutti i punti di forza di tale tecnica, in
particolare la definizione del contesto e la
possibilità di descrivere il comportamento
"sistemico" dell'applicazione in esame.
In altri termini, l'analisi object oriented esclude a
priori ogni visione di sintesi della logica
funzionale del sistema, e delle interazioni tra il
sistema e l'ambiente esterno. In mancanza di uno
schema globale di riferimento, la definizione dei
processi elementari da "incapsulare" negli oggetti
risulta quindi problematica, legata com'è in buona
parte all'estro del singolo analista.
Coad e Yourdon non sono comunque soli nello sforzo di
superare i confini tradizionali tra analisi dei dati
ed analisi delle funzioni.
L'Information Model del Repository IBM, per esempio,
prevede esplicitamente una definizione del patrimonio
informativo in termini object oriented.
Anche la nuova versione del prodotto di Bachman,
"Bachman Analyst", prevede la definizione di
specifiche funzionali "incapsulate" nelle entità del
modello Entity Relationship.
Lo stesso ideatore del modello relazionale, Codd,
nella recente "versione 2" del modello estende la
tipologia e la copertura delle regole di integrità,
aprendo così la strada per un incorporamento della
logica funzionale nel modello dati. Ed il suo socio
Chris Date spinge nel dettaglio l'analisi sui
problemi dell'integrità, giungendo a definire una
nuova tassonomia delle regole sicuramente
promettente, se non ancora definitiva.
Tra tutte queste proposte esiste una linea di
tendenza comune: una maggiore integrazione della
componente dati e della componente funzioni, che dia
luogo ad una definizione centralizzata ed unitaria a
livello di catalogo (o repository).
I benefici di una simile impostazione sono evidenti.
Centralizzare in un unico livello di definizione i
dati ed i processi che li trattano accresce la
possibilità di mantenere integro il proprio
patrimonio informativo, minimizzando i rischi di
errori ed incongruenze.
La strada appare dunque tracciata. Ed è molto
probabile che nei prossimi anni i confini tra analisi
dei dati ed analisi delle funzioni saranno
decisamente più sfumati di quelli odierni. Ma, per
favore, senza eccessive semplificazioni...