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