analisi-disegno.com

Homepage  | Notiziario | In English


Intervista a Ivar Jacobson (di Adriano Comai)

- l'intervista è stata pubblicata sul numero 213 (ottobre 1999) di ZeroUno -

ZeroUno: Dottor Jacobson, Lei è noto come ideatore del concetto di "caso d'uso". Quali sono le radici dei casi d'uso nella storia dell'ingegneria del software?

Ivar Jacobson: Non saprei, direi che non ce ne sono. Quando ero giovane lavoravo nel settore delle telecomunicazioni, dove esistevano i "casi di traffico". Erano, di fatto, le chiamate telefoniche, e ce n'erano di tipi diversi, ciascuno dei quali era un tipo particolare di "caso di traffico". In quegli anni, attorno al 1967, c'era un altro termine simile a "caso d'uso", e con lo stesso significato, cioè "funzione". Una chiamata telefonica era una funzione, ma erano "funzioni" anche cose più astratte, in quanto il termine non era definito con precisione. Il nostro era uno sviluppo "function-driven": si identificavano le funzioni e poi le si progettava, come facciamo oggi con i casi d'uso.

ZeroUno: Il concetto di caso d'uso è come un filtro che distingue tra le funzioni significative per l'utente e quelle interne al sistema …

Ivar Jacobson: Sì, elimina molte funzioni, che non possono essere considerate casi d'uso. È un concetto molto più specifico. Qualsiasi cosa può essere una funzione, questo è il problema. Mentre i casi d'uso non possono essere qualsiasi cosa.

Ho ideato il concetto di caso d'uso nel 1986, e ho capito subito che era la soluzione a molti problemi, perché lo potevo usare in tutto lo sviluppo dei sistemi, e per ogni tipo di sistema. Mi è stato molto utile per creare una metodologia sistematica.

Voglio però chiarire un aspetto. Può essere vero che la mia fama è legata soprattutto ai casi d'uso, ma noi sviluppavamo sistemi a componenti nel 1967, quando i casi d'uso non c'erano ancora, ed è sullo sviluppo a componenti che ho lavorato per tutta la vita. Un altro aspetto su cui ho sempre insistito, già da quegli anni, è la necessità di definire un'architettura prima di fare qualunque altra attività di sviluppo. Quando andavamo dai clienti presentavamo l'architettura software dei nostri sistemi, e ricordo che non avevano mai sentito parlare di una cosa del genere. Si parlava di architetture hardware, ma non di architetture software.

ZeroUno: Oggi i casi d'uso sembrano un concetto quasi ovvio, scontato …

Ivar Jacobson: E penso che sia proprio così.

ZeroUno: Ma è stato straordinario vedere con quale rapidità sono stati accettati dagli altri metodologi. Come mai così poca opposizione?

Ivar Jacobson: A un certo punto la maggioranza dei metodologi si è buttata sul mondo degli oggetti, e c'era molta competizione. Ma i casi d'uso non competevano con nulla, e risolvevano un problema che avevano tutti. Anche il concetto di scenario era relativo alle interazioni interne al sistema, e non era ben specificato. Di fatto, i libri degli altri metodologi ci hanno aiutato, perché avevano una lacuna proprio sul modo in cui partire dai requisiti per effettuare l'analisi e il disegno.

Un aspetto su cui personalmente mi sono mosso in ritardo è stato la pubblicazione di testi. Se si guarda al mio intervento all'OOPSLA nel 1987, c'erano già tutte le idee, fin da allora. Il fatto, però, era che in quel periodo potevo vendere il testo della mia metodologia, Objectory, per 25.000 dollari alla copia. Perché, pensavo allora, dovrei pubblicarlo presso un editore, per guadagnare 3 dollari a copia? Adesso capisco che avrei dovuto agire in modo diverso, ma è difficile scegliere i tempi giusti.

ZeroUno: Le specifiche dei casi d'uso sono essenzialmente sotto forma di testo (anche se possono essere corredate da diagrammi UML). Al contrario, metodi precedenti, come l'Analisi Strutturata o l'Information Engineering, proponevano l'utilizzo di diagrammi come "linguaggio comune" tra clienti (o "utenti") e sviluppatori. Cosa c'è dietro questa rinascita del testo?

Ivar Jacobson: In realtà, oggi, i clienti dei sistemi software non vogliono leggere diagrammi, e non c'è bisogno di imparare un linguaggio speciale per leggere un testo. Se invece si vuole una rappresentazione visiva, i Diagrammi dei Casi d'Uso sono così intuitivi che può leggerli chiunque.

Per descrivere i casi d'uso si possono anche usare i Diagrammi di Attività, ma hanno qualche controindicazione. Diventano rapidamente molto dettagliati, e non è detto che ciò li renda più comprensibili. Non c'è dubbio che prima o poi bisogna specificare in dettaglio, ma noi pensiamo che il modo migliore per farlo sia nel modello di analisi, dove ogni caso d'uso viene descritto come una Collaborazione tra oggetti. Le attività possono essere talmente astratte da renderne difficile la comprensione: bisogna capire bene ciò cha va fatto, per comprendere le attivitè. Quindi sono molto cauto nell'introdurre formalismi per i casi d'uso. Quando si passa all'analisi si ha a disposizione un formalismo molto migliore, un linguaggio più adeguato per esprimere i dettagli, perché si parla di oggetti, e di collaborazioni tra oggetti.

È un aspetto pragmatico, non un dogma. A volte può essere opportuno usare i Diagrammi di Attività, ma voglio segnalare una criticità, perché è meglio dettagliare quando si ha a disposizione il linguaggio giusto per farlo. Anche se gli oggetti di analisi sono concettuali, e non cose fisiche, implementative, sono comunque molto più concreti e comprensibili che non le attività.

ZeroUno: E l'ambiguità del linguaggio naturale?

Ivar Jacobson: Sì, è ambiguo, ma ci sono pro e contro… Il linguaggio naturale è comprensibile. D'altra parte, quando abbiamo a che fare con casi d'uso complessi, con molte interazioni, si può avere bisogno di specificare maggiormente. Ma è meglio considerare il modello di analisi una parte integrante dei requisiti, come ho fatto nel nuovo libro sullo Unified Process. In questo modo, uno dei risultati prodotti dall'analisi è la struttura che vorremmo vedere nel disegno e nell'implementazione, cioè i requisiti architetturali.

ZeroUno: I casi d'uso rivestono un ruolo duplice nel Suo metodo. Prima vengono utilizzati per scoprire e validare i requisiti provenienti da clienti e utilizzatori, e successivamente guidano l'intero processo di sviluppo. Esiste una graduatoria di importanza tra i due ruoli?

Ivar Jacobson: No, naturalmente no. Ma molti metodologi, e molti sviluppatori software, sono degli "introversi tecnologici". Se il concetto di caso d'uso non fosse risultato così adatto per descrivere le interazioni, e per definire le collaborazioni tra oggetti, non l'avrebbero accettato in modo così generalizzato. Quindi questo aspetto è quello essenziale nei confronti degli sviluppatori, perché impatta sul disegno, e guida l'intera attività di sviluppo. Per me, comunque, i due aspetti sono ugualmente importanti. Si tratta di un ottimo modo per scoprire i requisiti e di documentarli, e per identificare gli scenari, senza entrare nelle caratteristiche interne del sistema.

ZeroUno: Nel libro sullo Unified Process Lei parla della lista dei requisiti ("feature list of requirements") come del punto di partenza per l'identificazione dei casi d'uso.

Ivar Jacobson: La lista dei requisiti viene tradotta in termini di casi d'uso, ma la documentazione del sistema deve descrivere i casi d'uso. Quindi la lista dei requisiti tenderà a crescere con le nuove richieste, e a sgonfiarsi quando le richieste vengono tradotte in forma di casi d'uso.

ZeroUno: Alcuni anni fa Lei ha proposto l'utilizzo dei casi d'uso per le attività di Business Process Reengineering. Quali sono stati i risultati? Vengono utilizzati in modo massiccio come nell'area IT?

Ivar Jacobson: No, e per molte ragioni. Rational ha scelto di operare soprattutto nel campo del software, anche se ci è chiara l'importanza del Business Engineering. Gli strumenti necessari a chi fa Business Engineering sono in ogni caso derivabili da quelli per il Software Engineering. È possibile ad esempio estendere Rose [NdT: il prodotto di Rational per la modellazione visuale] per renderlo adatto anche ad attività di Business Engineering, mentre non è possibile fare il contrario. È quello che abbiamo fatto a livello locale, in Scandinavia, dove abbiamo un service package, chiamato Rational Business Engineering, con una specializzazione di Rose e delle specifiche di processo dettagliate.

Nei fatti, il mercato potenziale per il Software Engineering è molto più ampio. Le persone che fanno Business Modeling, tipicamente, capiscono bene il mondo del software, ed hanno la consapevolezza di avere bisogno di spingersi oltre, nella modellazione del business. È triste che i grandi nomi del Business Engineering, come Hammer, il cui lavoro è strettamente imparentato con il nostro, non abbiano dedicato un'attenzione sufficiente alla modellazione. Hammer espone i problemi, e fornisce degli abbozzi di soluzione. Ma non è in grado di rappresentare i problemi in un modello, e se non è in grado di modellarli non è neppure in grado di comprenderli fino in fondo. La conseguenza di questa scarsa attenzione alla modellazione è che l'interesse proveniente da quel settore è molto più ristretto: la maggioranza di coloro che fanno attività di Business Modeling arriva dal mondo del software. Comunque abbiamo clienti con centinaia di licenze di Rose per il Business Engineering, ad esempio in una Telecom e nell'ente che gestisce il sistema pensionistico in Svezia.

L'altra ragione della difficoltà che incontra il Business Engineering è che la gente dice di non trovare il tempo sufficiente per questa attività. E' il problema del "time to market": è più importante tirare subito fuori qualcosa di rilasciabile che non la qualità del prodotto. Il che significa che le due attività, Business Engineering e Software Engineering, devono diventare più integrate tra loro. Gli informatici sanno che modellare il business richiede tempo, e che quando iniziano a costruire il software, il business è già cambiato, e il modello che lo descriveva è diventato obsoleto. La novità del nostro approccio è che il Business Modeling è all'interno del processo, e che se per costruire il software ci vogliono sei mesi, in questi sei mesi si svolgono anche attivitè di Business Engineering.

Capisco che si abbiano resistenze al Business Modeling: se riteniamo che la qualità non sia molto importante, avremo sempre dei problemi ad adottare un qualunque approccio organizzato allo sviluppo del software. Ma uno sviluppo di tipo iterativo produce risultati in tempi utili, e credo che questo approccio renderà la gente consapevole dell'esigenza di fare Business Modeling, con continuità, nel corso di tutto lo sviluppo.

ZeroUno: UML e lo Unified Process sono state creazioni collettive. Ma il Suo contributo personale è più evidente per quanto riguarda il processo, che deriva più dal filone Objectory / OOSE che non dal metodo di Booch o da OMT di Rumbaugh. Si può parlare di una divisione del lavoro tra voi "Amigos"?

Ivar Jacobson: No, nessuna divisione del lavoro. Ci sono persone esperte di tutto, e non credo che uno di noi tre ammetterebbe l'esistenza di un'area in cui non ha alcuna esperienza. È però un fatto che siamo partiti da Objectory, per sviluppare il Rational Unified Process, e che non avremmo potuto partire dal semplice Object Modeling, perché non è semplice partire da approcci come Booch, o OMT, e arrivare al livello di Objectory. Molto meglio la strada opposta, che parte dai casi d'uso per scoprire gli oggetti, le classi ed i sottosistemi da progettare.

ZeroUno: Booch e Rumbaugh partivano dal software, Lei invece dai clienti e dagli utenti…

Ivar Jacobson: Sì, ma è non solo questo. Il fatto è che bisogna partire dai componenti. Nel 1967, quando iniziavo a introdurre questo approccio in Ericsson, l'obiezione maggiore che ricevevo dagli sviluppatori era che i componenti che progettavamo non erano riconducibili in modo diretto alle "funzioni", cioè ai casi d'uso, e che ogni caso d'uso coinvolgeva più di un componente. Il loro modo di vedere era: "ci vuole un modulo per ogni funzione", mentre io non ero d'accordo. La maggior parte di una funzione, cioè di un caso d'uso, viene implementata da un componente, ma il caso d'uso coinvolge anche altri componenti. Quindi mi sforzai di trasformare l'obiezione in termini positivi, affermando che la complessità del rapporto tra casi d'uso e componenti era necessaria. Il mondo esterno vede i casi d'uso, ma all'interno del sistema ogni caso d'uso coinvolge più componenti, pi&eugrave; sottosistemi.

Guardare solo agli oggetti e ai componenti, senza preoccuparsi di ciò che li lega, è solo una piccola parte del problema. Il difficile è progettare le realizzazioni dei casi d'uso, ed in particolare gestire le dipendenze tra i sottosistemi.

No, non c'è stata una decisione vera e propria di dividere il lavoro tra noi. Definire UML era un compito arduo, e avevamo bisogno di collaborare per portarlo a termine. Ora lavoriamo su temi diversi; non ha senso operare insieme su tutto.

ZeroUno: Si aspetta che lo Unified Process abbia un successo ed un impatto analoghi a quelli di UML?

Ivar Jacobson: Assolutamente sì, ed abbiamo buone ragioni per crederlo, molte organizzazioni lo stanno adottando. Non sarebbe stato semplice fare approvare anche lo Unified Process come standard, ci sarebbe voluto troppo lavoro e avrebbe incontrato troppa opposizione. Preferiamo che la diffusione avvenga un passo alla volta: invece di forzare le persone a conformarsi a uno standard, è meglio che si convincano da sole. Credo che chi dà un'occhiata al Rational Unified Process si convincerà subito del fatto che è la strada da seguire, perché non ci sono altri approcci comparabili. Molti affermano il contrario, ma su quali basi? Ci sono approcci che possono essere messi in confronto con il mio libro, che è solo un'introduzione, ma nessuno che sia ad un livello paragonabile al nostro processo, in termini di sostanza, di profondità e di esperienze di applicazione. Da quanto tempo esistono, gli altri approcci? Li abbiamo forse visti funzionare in progetti di grandi dimensioni?

ZeroUno: Quanto è rimasto di Objectory nello Unified Process?

Ivar Jacobson: Nel vecchio Objectory coprivamo solo la definizione dei requisiti, l'analisi e il disegno. Questa parte è rimasta, ma sono state aggiunte molte altre cose. Avevamo poco sull'implementazione, in Objectory, poco sul testing, nulla su configuration management, version control, project management. Raccomandavamo lo sviluppo iterativo, ma senza che il processo entrasse nel merito di come effettuarlo, e sulle differenze che vi sono tra le diverse iterazioni.

Il Rational Unified Process è un lavoro di gruppo, a cui hanno partecipato in molti, mentre Objectory Process era costruito essenzialmente sulle mie idee e sul mio lavoro, perché non disponevamo di molte risorse.

ZeroUno: Lei presenta ogni iterazione come un mini-waterfall (sviluppo "a cascata")…

Ivar Jacobson: Sì, ma con molte attività parallele. All'interno del waterfall, coloro che sviluppano sottosistemi operano in modo concorrente: chi lavora sui casi d'uso nei diversi gruppi si deve confrontare, per riutilizzare i medesimi componenti ed evitare di inventare ogni volta la ruota. Comunque, il processo è ancora a cascata, perché si parte dai requisiti, poi si fa analisi, quindi disegno, …

ZeroUno: Lei è svedese, ma lavora molto anche negli USA. Ha riscontrato differenze nell'approccio al software engineering tra Europa e USA?

Ivar Jacobson: No, nessuna differenza sistematica. In entrambi i contesti ho trovato persone consapevoli dell'importanza di partire dal business, prima di mettersi a sviluppare il software. In Europa si è fatta molta ricerca ad un livello più astratto, e meno a livello concreto, ma ci sono stati risultati utili, sia qui che là - e anche molto lavoro che non ha portato a nulla.

ZeroUno: Ora la maggior parte del lavoro di "unificazione" è completo. Cosa pensa di fare?

Ivar Jacobson: Una parte di me dice: voglio andare avanti, e capire cosa bisogna fare per migliorare il mondo. UML è uno standard, e ciò è positivo, ma non si tratta di idee nuove: le abbiamo solo consolidate. Negli ultimi anni non penso di aver fatto nulla di veramente innovativo, ho lavorato più sul fronte della diffusione che non su quello della creazione. Ora ho bisogno di andare avanti. Cosa c'è oltre lo Unified Process, oltre UML? Si tratta ancora di evoluzioni, e non di rivoluzioni, ma ci sono ancora dei passi importanti da fare nel software, per raggiungere il livello di qualità necessario a realizzare i sistemi che ci serviranno tra venti anni. Saranno sistemi molto più ampi e complessi di quelli attuali. E servirà un'infrastruttura migliore di quella disponibile oggi, in termini di sistemi operativi, di linguaggi di programmazione, di integrazione di UML con i linguaggi. Forse una parte di UML sarà un linguaggio di programmazione, con una semantica per la definizione delle azioni.

Comunque ci sono due aree a cui mi dedicherò nel prossimo futuro. Una è il Business Engineering, ed in particolare l'impatto che il nuovo mondo di Internet, e idee come l'"one-to-one marketing" hanno sugli scenari di business. Sto anche lavorando ad una revisione del mio libro "The Object Advantage. Business Process Reengineering with Object Technology", che uscirà alla fine di quest'anno, e dovrà essere maggiormente comprensibile per le persone del business, e non solo per gli informatici. Abbiamo bisogno di superare la barriera dell'IT, risolvendo il problema dell'accettazione delle notazioni tecniche per il Business Modeling, ed in questo compito un ruolo importante sarà giocato dai diagrammi di attività.

L'altra area è lo sviluppo di applicazioni software nel contesto web. Anche se il web cambia tutti gli scenari business, il modo in cui sviluppiamo software per il web non cambia di molto, tranne per un aspetto, sempre più importante, cioè l'interfaccia con l'utilizzatore.

Il Rational Unified Process è ben attrezzato per il Web, e viene già utilizzato da molti produttori di siti Web, con qualche adattamento per lo scopo specifico. A me interessa estenderlo, apportandovi i cambiamenti necessari per farlo diventare, senza alcun dubbio, "il" processo per la progettazione di siti Web.

--> vai a pagina principale UML


analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.