Dr. Carlo Pescio
Intervista a Grady Booch

Pubblicato su Computer Programming No. 59


Grady Booch, Chief Scientist di Rational Corporation, ideatore della omonima metodologia di analisi e design object oriented, ed attualmente impegnato nello sviluppo del linguaggio di modellazione unificato, risponde ad alcune domande su UML, i CASE tool, ed altro ancora.

Grady Booch è famoso per la metodologia di analisi e design object oriented che porta il suo nome. Da anni impegnato nel settore della tecnologia ad oggetti, autore di una delle prime foundation libraries per Ada ed il C++, ha scritto diversi libri, parecchi articoli, ed ha partecipato a numerosi grandi progetti. In tempi più recenti, altri due famosi metodologi si sono uniti alla scuderia Rational, al fine di unificare le diverse tecniche: James Rumbaugh, ideatore di OMT, ed Ivar Jacobson, autore di Objectory. Il progetto, inizialmente chiamato Unified Method, ha subito diversi cambi di rotta quando i metodologi hanno riscontrato non poche difficoltà a conciliare alcune delle loro posizioni. Dopo una breve parentesi in cui si è parlato di una sola notazione comune, la posizione definitiva si è concretizzata in UML (Unified Modeling Language), un linguaggio per la modellazione ad oggetti che, oltre ad una notazione comune, definisce anche la semantica formale dei diversi costrutti. UML rimpiazzerà quindi il metodo di Booch, OMT, ed Objectory a livello di notazione e di significato dei diversi diagrammi; passerà ancora tempo, tuttavia, prima che si possa raggiungere una vera e propria metodologia unificata. Oltre che su UML, Booch è da sempre impegnato con Rational nello sviluppo di CASE tool per l'analisi ed il design ad oggetti. Su questi argomenti ho concentrato le domande che seguono, cercando di toccare in modo anche provocatorio temi come la reale utilità degli strumenti CASE, la percorribilità del round-trip engineering, la difficoltà di UML e così via.


D
Questa è probabilmente una delle domande più frequenti, ma vorrei che ci parlassi un po' di UML. Ad esempio, perché avete deciso di spostare l'enfasi da "una notazione più una metodologia", come era nelle intenzioni iniziali, verso un vero e proprio linguaggio di modellazione ad oggetti?

R
In effetti la domanda è molto frequente, tanto che ho scritto alcune pagine di FAQ che sono disponibili all'URL http://www.rational.com nella sezione "oo technology".
In breve, ci sono state due ragioni che hanno portato al cambiamento. Primo, era evidente che molti utenti volevano la possibilità di usare UML all'interno dei loro attuali processi di sviluppo; infatti, domini differenti richiedono approcci metodologici diversi. Secondo, volevamo proporre UML come standard all'Object Management Group, e la richiesta di OMG per OOA/OOD riguardava i linguaggi di modellazione, non i processi o le metodologie.

D
Ho sentito più di una persona dire che "UML è troppo difficile" oppure "troppo potente". E probabile che ciò sia in parte dovuto alla vostra documentazione preliminare, che è molto diversa dai libri di OOA/OOD cui il grande pubblico è abituato. Ma d'altra parte, se vi spostate da una metodologia ad un linguaggio, un maggiore livello di formalismo è inevitabile. Non pensi che dover imparare la semantica formale del linguaggio spaventerà qualche analista? Sto pensando in particolare agli esperti del dominio applicativo, che sono abituati a scrivere i documenti di analisi ma hanno limitate competenze informatiche.

R
È vero che UML è molto potente; abbiamo cercato di affrontare sia i tradizionali problemi di modellazione (modello delle classi, macchine a stati, ecc), sia i più recenti, ed abbiamo anche cercato di coprire le problematiche di business modeling (poiché spesso finiscono per essere rappresentate nei modelli ad oggetti). Abbiamo anche cercato di mantenere la semantica di UML eseguibile, ai fini di simulazione. Inoltre, abbiamo anche cercato di guardare avanti, focalizzandoci su alcuni trend dello sviluppo del software, in particolare il componentware, la programmazione distribuita, e le applicazioni basate su rete. Questi elementi sono tutti coperti da UML.
È comunque vero che l'attuale documentazione di UML non è facilmente avvicinabile per i meno esperti: del resto, lo abbiamo scritto nella stessa introduzione alla documentazione. In effetti, questi documenti sono nati per specificare il linguaggio, non per spiegarlo; non sono molto diversi dall'Annotated Reference Manual del C++, tanto per fare un esempio: e quello non è un libro che si deve usare per imparare a programmare in C++.
Gli amigos1 stanno scrivendo tre libri per mitigare il problema. Una guida per gli utenti, un manuale di riferimento, ed un libro sul processo di sviluppo. Inoltre, conosco ormai parecchi altri libri in lavorazione che useranno UML. Di fatto, "Core Java" contiene già alcuni diagrammi UML, basati sulla versione 0.8 del linguaggio.

D
La tua società produce strumenti CASE. Ma tu ritieni veramente che gli strumenti CASE attuali siano indicati per il lavoro di ogni giorno? Io conosco molte realtà in cui gli strumenti CASE sono usati soprattutto come sofisticati strumenti di disegno per i diagrammi, perché nessuno si fida a sufficienza dei tool nella fase di reverse engineering. Quindi si trovano tutti ad affrontare il problema di mantenere "vivi" i diagrammi di design a mano a mano che il codice evolve. In alcuni casi le aziende smettono semplicemente di usare gli strumenti CASE dopo alcuni tentativi. Ritieni che la vostra attuale tecnologia per il round-trip engineering sia abbastanza buona da poter essere usata in progetti reali, magari basati su librerie come MFC (con la loro "sindrome delle macro") o come STL (quindi template ovunque)?

R
Questa domanda riguarda più i tool che UML, e se vuoi possiamo approfondire in privato. La risposta breve è si, Rational Rose è appropriato per il lavoro di ogni giorno e vi sono persone che lo usano in una varietà di progetti reali, in molti dei quali stanno scommettendo il futuro della loro compagnia sulla bontà dello strumento. Con questo non voglio dire che i produttori di CASE si devono ritenere soddisfatti dai loro attuali strumenti: stiamo migliorando di continuo l'usabilità e la funzionalità dei nostri prodotti.

D
In effetti preferirei approfondire il discorso in questa sede. Non credi che la distanza tra un linguaggio come il C++ ed uno come UML sia troppo grande per poter essere colmata da un tool? Ad esempio, un puntatore in C++ può rappresentare molte cose, tra cui:


Come fai a ricostruire un diagramma significativo in UML che preservi la reale semantica del codice C++?

R
Insisto che Rose lo fa già per il C++ e per altri linguaggi...

D
Può darsi che la mia domanda non fosse abbastanza precisa. Ovviamente Rational Rose fa un reverse engineering del codice C++, ma io mi riferisco alla qualità dell'output. Usando lo stesso esempio di cui sopra (i puntatori), considera questo semplice codice:

class A
  {
  int x ;
  } ;

class B
  {
  A* a ;
  } ;
Rational Rose 3.0.2 decide che vi è una relazione generica tra B ed A (il che è corretto, anche se probabilmente sotto-specificato), che la decorazione è per reference (corretto), che la cardinalità sul lato A è 1 (arbitrario) e che sul lato B è (0,1) (di nuovo, totalmente arbitrario).
A mio avviso non si tratta di un problema di qualità del tool (che di fatto è molto buono), ma di un diverso livello di astrazione tra i linguaggi, con la conseguente impossibilità di risolvere delle ambiguità a livello semantico, se non con delle scelte arbitrarie, quando ti sposti da un livello ad un altro. Naturalmente, spostarsi da UML, che è più ricco dal punto di vista semantico, verso il C++ (che è più povero), è molto più semplice.

R
È vero, non riusciamo a farlo perfettamente. Se generi il codice C++ a partire da UML, e poi fai il passo alla rovescia verso UML, noi utilizziamo dei commenti sparsi nel codice per avere degli indizi sul significato del modello originale. Se parti con un codice non generato dal tool, cerchiamo di indovinare meglio che possiamo (di solito, specificando una associazione generica).

D
E come dicevo, usare una libreria macro-intensive come MFC significa quasi programmare in un altro linguaggio. Per derivare una classe da una delle classi base MFC come Cview, non puoi semplicemente derivare una classe C++, devi anche definire la tua mappa dei messaggi e così via, come fa il ClassWizard del Visual C++. Ma senza una conoscenza della speciali necessità di MFC, come può un CASE tool fare la stessa cosa? Ovviamente, MFC è solo un esempio, probabilmente una delle più diffuse librerie macro-intensive.

R
Questo è un problema di muoversi a partire da un framework esistente... ed è qualcosa su cui stiamo provando ad applicare le stesse idee dei wizard per ottenere risultati migliori.

D
Ti è probabilmente noto il fatto che in Europa, gran parte dei team di sviluppo sono piccoli (ad es. 3- 5 persone) e vi è poca o nessuna gerarchia. Ognuno fa un po' di analisi, un po' di design, codifica, debugging, documentazione. O perlomeno, dovrebbero farlo. C'é sempre una forte pressione a saltare tutte le fasi tranne la codifica. Questo è ancora più comune quando il tuo vicino di scrivania sta usando il Visual Basic per mettere insieme qualcosa alla velocità della luce. Ho visto personalmente degli sviluppatori scrivere pessimo codice il più in fretta possibile, e chiamare questo metodo "rapid prototyping" o "sviluppo incrementale" tanto per salvare la faccia. Si tratta in gran parte di ottenere la giusta comprensione ed il giusto supporto dal management: in alcuni casi, un progammino scritto in fretta è "abbastanza buono", ma non in tutti i casi. Ma è anche un percorso molto difficile: come si riesce ad ottenere la giusta comprensione dal management?

R
In effetti quanto sopra non si applica solo ai progetti europei. Nel nostro lavoro vediamo progetti che vanno dai piccoli team alle grandi organizzazioni, con tutti i passi intermedi. Del resto, questo è il tema per un intero libro (ehi, è il momento di un po' di pubblicità: andate a leggere "Object Solutions"). Per quanto riguarda strumenti come il Visual Basic: ci sono dei limiti pratici alla complessità dei sistemi che uno può costruire con simili tool. Infatti, noi abbiamo creato una connessione tra Rational Rose ed il Visual Basic per sfruttare le possibilità di sviluppo rapido del Visual Basic mantenendo però il controllo dell'architettura attraverso Rose.

D
A dire il vero ho letto il libro che citi, ed in effetti vi si possono trovare molti buoni consigli per i manager che abbiano già deciso di utilizzare la tecnologia ad oggetti. Tuttavia, la questione di fondo mi sembra diversa. Esiste un folklore secondo il quale tool come il Visual Basic hanno, come dici tu, dei "limiti pratici" quando vengono usati per affrontare problemi complessi. Tuttavia, abbiamo pochi dati concreti da esibire al momento opportuno. Io certamente non sono un VB-fan, ma ho potuto vedere che in molti casi il Visual Basic vince semplicemente perché è il miglior "affare del momento", quindi se la preoccupazione è che l'applicazione doveva essere pronta ieri, si può essere tentati di tralasciare i benefici a lungo termine per un incremento a breve termine in produttività. In alcuni casi, questo va benissimo perché l'applicazione non deve sopravvivere a lungo, oppure perché il dominio è sottoposto a continui cambiamenti, eccetera. Ma come possono gli sviluppatori aiutare un manager, che non abbia già preso la decisione di adottare la tecnologia object oriented, ad evitare l'uso di tool come il Visual Basic in grandi progetti, semplicemente perché hanno funzionato bene in applicazioni più semplici? Come fai a tirare una riga e dire "questo è troppo complesso per il Visual Basic"?

R
In realtà è ancora peggio. Vi sono dei limiti ad oggetti come il Visual Basic, ma raramente riesci ad accorgerti che il tuo progetto supererà tali limiti sino a quando non sarà troppo tardi.
La cosa fondamentale che insegno agli utenti del Visual Basic è di avere una chiara separazione dei compiti tra l'interfaccia utente ed i dati2. Ed anche di creare perlomeno una architettura a tre livelli (three-tier), in modo da isolare le business rules.

D
Cercherò di resistere alla tentazione di chiederti qualcosa sui metodi traslazionali "alla Shlaer-Mellor"3. Invece, vorrei chiederti qualcosa a proposito della metodologia BON (Business Object Notation), che mi sembra utilizzi un approccio alla modellazione molto diverso da UML, proprio per massimizzare la reversibilità di cui parlavamo prima. Ad esempio, su IEEE Computer del Settembre 1996, Kim Walden4 è stato molto critico nei confronti dei metodi elaborazionali come UML, dove i concetti di alto livello non rispecchiano quelli di basso livello (codifica). Qual è la tua posizione?

R
Ho dibattuto la mia posizione con Steve Mellor al recente OOPSLA. Non conosco il lavoro di Kim Walden a sufficienza per rispondere.

D
Va bene, ti pongo un'altra sfida. Peter Coad, nel suo libro "Object Models", critica brevemente le altre notazioni dicendo: "Classi, stati e diagrammi funzionali? Potremmo dire entità-relazione, diagrammi degli stati e flusso dei dati? [...] Suggerire una simile triade multimodello significa mancare completamente il bersaglio del cambio di paradigma". Ora, sono sicuro che avrai qualcosa da dire al proposito, e mi farebbe piacere conoscere la tua opinione.

R
Preferirei non rispondere...

D
Come vuoi. In conclusione, qual è stato il segreto del tuo successo? Seriamente, ben pochi consulenti hanno avuto il tuo impatto sul processo, la pratica, ed il linguaggio stesso dello sviluppo del software. È accaduto per caso, serendipità, impegno continuo, o che altro?

R
Probabilmente, una combinazione di quanto hai detto. Dio mi ha graziato con la capacità di sintetizzare le idee e comunicarle, ed io ho preso questo dono molto seriamente. Ho anche avuto la fortuna di trovarmi nel posto giusto, al momento giusto, in più di una occasione.

Reader's Map
Molti visitatori che hanno letto
questo articolo hanno letto anche:

Biografia
Carlo Pescio (pescio@acm.org) svolge attività di consulenza in ambito internazionale nel campo delle tecnologie Object Oriented. Ha svolto la funzione di Software Architect in grandi progetti per importanti aziende europee e statunitensi. È incaricato della valutazione dei progetti dal Direttorato Generale della Comunità Europea come Esperto nei settori di Telematica e Biomedicina. È laureato in Scienze dell'Informazione ed è membro dell'ACM, dell'IEEE e della New York Academy of Sciences.

[1]
Booch ha da tempo preso l’abitudine (apparentemente contagiosa) di riferisi a se stesso, Rumbaugh e Jacobson come "i tre amigos". Ho preferito mantenere la citazione dall’originale.

[2]
Per un approfondimento di questo punto, potete consultare il mio articolo
"Design: Interfaccia Utente", apparso su Computer Programming No. 45.

[3]
Da tempo vi e’ un dibattito in corso tra Booch e Steve Mellor sulla percorribilita’ dell’approccio traslazionale, incarnato dalla metodologia Shlaer-Mellor. Booch sostiene che si tratti "di un mito", non di una soluzione realmente utilizzabile.

[4]
Uno dei creatori di BON.