analisi-disegno.com


(pubblicato su ZeroUno n.226, novembre 2000)

Strumenti UML: criteri di scelta e di utilizzo

I tool di Visual Modeling UML sono oggetto di attenzione da parte di molte organizzazioni. La scelta può essere difficile. Ed occorre molta cura per ottenere i risultati sperati dall'investimento.

UML (Unified Modeling Language), per chi non lo conosca, è il linguaggio standard per la progettazione e la rappresentazione dei sistemi software. Approvato da OMG (Object Management Group) nel novembre 1997, UML è attualmente oggetto di un processo di approvazione come standard ISO, che dovrebbe concludersi entro il 2001.

Molte aziende, in Italia e nel resto del mondo, stanno adottando UML, innanzitutto con l'obiettivo di migliorare la comunicazione relativa ai progetti software, all'interno dell'organizzazione e nei confronti di terze parti.

In quanto notazione universale, UML costituisce un linguaggio comune per l'analisi, il disegno, la documentazione dei sistemi. Può quindi agevolare il flusso comunicativo sia all'interno delle aziende che sviluppano software, che nel rapporto tra clienti e fornitori di sistemi.

Non a caso, uno dei campi nei quali l'utilizzo di UML si sta maggiormente diffondendo è quello della gestione delle subforniture nell'ambito della progettazione di sistemi complessi. Dove società diverse concorrono allo sviluppo, producendo soluzioni parziali da integrare in un'architettura complessiva, la documentazione in formato UML agevola la comunicazione tra le parti.

Il secondo motivo che favorisce l'adozione di UML è legato a un rinnovato interesse per le attività di progettazione (analisi e disegno).

I sistemi distribuiti diventano sempre più complessi, e, proprio per poterne governare la complessità, risulta necessario dedicare tempo alla definizione della loro architettura, logica e fisica, sotto forma di rappresentazioni sintetiche (modelli), prima di buttarsi a capofitto nella scrittura del codice. Inoltre, le tecnologie utilizzate per l'implementazione sono sempre più basate sull'object oriented e sull'integrazione di componenti, ed è importante che anche le attività di progettazione siano basate sugli stessi princìpi. UML, essendo un linguaggio di modellazione basato sull'approccio object oriented, risponde perfettamente ad entrambe queste esigenze.

Gli strumenti UML

La spinta all'adozione di UML può quindi provenire dall'esterno (allineamento alle richieste dei clienti, ad uno standard internazionale), o dall'interno dell'organizzazione (miglioramento della comunicazione, adozione di approcci di progettazione object-oriented).

In ogni caso, è probabile che chi intende utilizzare UML decida di avvalersi di uno strumento di visual modeling, cioè di un software commerciale per la produzione di modelli. Certo, i diagrammi UML si possono disegnare anche con carta e matita; ma è sicuramente più comodo, e forse più economico, utilizzare uno strumento software per crearli e gestirli.

Le soluzioni disponibili sono di due tipi: diagrammatori puri (come Flowcharter o Visio), oppure strumenti dedicati alla produzione di modelli UML.

I diagrammatori puri consentono di creare ogni genere di diagramma, avvalendosi di mascherine (template), legate ad ambiti notazionali specifici, e ne esistono alcuni capaci di rappresentare tutti i simboli grafici di UML. Il limite di questo tipo di strumenti è che consentono appunto di creare solo diagrammi, cioè rappresentazioni grafiche, ma non di documentare gli aspetti semantici (il significato) degli elementi rappresentati, né di controllare la correttezza sintattica delle associazioni tra elementi. Nulla vieta, ad esempio, di rappresentare graficamente una "gerarchia di aggregazione" che leghi più "attività" ad una "classe", anche se si tratta di un'associazione che UML non consente.

Gli strumenti di visual modeling veri e propri, invece, offrono una gestione completa dei modelli UML, sintattica e semantica, e non solo la produzione di diagrammi. Consentono la generazione di codice a partire dai modelli, ed il reverse engineering (riproduzione di modelli) a partire da codice esistente.

Costituiscono i discendenti diretti degli strumenti CASE (Computer Aided Software Engineering) che vissero un breve periodo di gloria tra la fine degli '80 e l'inizio dei '90, come IEW/ADW, Bachman, Excelerator, Teamwork, IEF. I primi CASE sparirono poi rapidamente dalle scene dello sviluppo, in parte perché legati al mondo mainframe (nel periodo in cui iniziavano a diffondersi le architetture distribuite), ma anche a causa di un pessimo rapporto tra i costi sostenuti per la loro adozione ed i benefici conseguiti dal loro utilizzo.

UML ha rivitalizzato questo mercato in modo decisivo. Gli strumenti di visual modeling UML (i produttori hanno preferito rinominarli in questo modo, piuttosto che utilizzare l'ormai screditato acronimo CASE) si stanno rapidamente diffondendo nelle organizzazioni. Hanno costi mediamente più ragionevoli dei loro predecessori, funzionano mediamente meglio, e sono sulla cresta dell'onda. Uno dei segni più evidenti del dinamismo del settore è rappresentato dal rapido evolversi delle acquisizioni societarie da parte dei suoi protagonisti.

Fino a pochi mesi fa, Sterling Software costituiva uno dei maggiori protagonisti di questo specifico segmento di mercato, avendo progressivamente acquisito i prodotti di KnowledgeWare (ADW), Bachman e Cadre (ObjectTeam, sotto il marchio Cayenne), Texas Instruments Software (IEF-Composer), ed avendoli integrati nella suite COOL, comprendente strumenti che andavano dalla creazione di modelli di business fino alla generazione del codice . Nel febbraio 2000, però, Sterling è stata a sua volta acquisita da Computer Associates. CA si è portata in casa l'intera suite COOL, con l'eccezione di COOL:Jex, lo strumento di visual modeling UML, ceduto alla svedese Telelogic. COOL:Jex, infatti, avrebbe costituito una sovrapposizione nell'offerta di CA, che comprende già un altro strumento UML, Paradigm Plus, frutto dell'acquisizione precedente di Platinum.

Anche Rational, la società degli autori di UML (Booch, Rumbaugh e Jacobson), è stata protagonista di una serie ripetuta di acquisizioni. Al suo prodotto principale, Rose, che costituisce il leader nel mercato dei tool UML, ha ultimamente affiancato un Rose RealTime, specializzato per la modellazione dei sistemi embedded, frutto dell'incorporazione della canadese ObjecTime, avvenuta nel dicembre 1999 .

Tra gli altri prodotti protagonisti del mercato, vanno segnalati Together, della TogetherSoft di Peter Coad, System Architect della Popkin, Select della Princeton Softech, azienda del gruppo Computer Horizons, Rhapsody della I-Logix, Software Through Pictures della Aonix, MagicDrawUML della No Magic. Esistono inoltre alcuni prodotti freeware (gratuiti), tra i quali ArgoUML .

Una scelta da valutare con attenzione

Non esiste una scelta ottimale tra gli strumenti UML, valida per tutti e in tutte le situazioni. Alcuni strumenti hanno il loro punto di forza nella generazione di codice per alcuni linguaggi, altri nella modellazione di sistemi Real-Time, altri nella completezza della loro implementazione dello standard UML, altri ancora nel supporto al lavoro di gruppo, o nella pubblicazione dei modelli in formato Html, oppure in un prezzo inferiore alla media.

La scelta va effettuata sulla base delle esigenze specifiche della singola organizzazione, e quindi ponderata sulla base di più fattori.

In ogni caso, si tratta di una scelta da effettuare con attenzione. Adottare uno strumento UML significa effettuare un investimento significativo, e non solo in termini di costo di acquisto.

L'utilizzo dello strumento può influenzare in modo rilevante le modalità di lavoro degli sviluppatori, e comporta la necessità di effettuare formazione, di acquisire il supporto di consulenti esperti per guidare i primi progetti, di definire, concordandole tra le diverse parti in causa, la documentazione da produrre e l'iter di lavoro (il "processo") da seguire. A fronte di questi costi da sostenere, scegliere uno strumento inadeguato puà essere veramente rischioso, perché può dare luogo a rifiuti, e precludere i benefici attesi dall'investimento.

La scelta deve essere quindi effettuata come un mini-progetto, e può essere basata sull'utilizzo di una griglia di valutazione, che ho realizzato per il confronto di strumenti di visual modeling UML e viene presentata nell'articolo seguente.

Innanzitutto si tratta di definire i requisiti che il prodotto (ed il fornitore) dovrà soddisfare. Dovrà essere utilizzato per sistemi informativi gestionali o per sistemi "embedded"? Quanto è importante il supporto al lavoro di gruppo? Quanto è importante l'interazione con strumenti per la gestione dei requisiti, o dei test? Si intende effettuare la generazione del codice a partire dallo strumento? E per quali linguaggi? Quali documenti e report si vuole che lo strumento produca? Quale supporto ci si attende dal fornitore in termini di formazione, di consulenza?

In questa fase occorre inoltre definire gli eventuali vincoli economici sul costo di acquisto, e temporali sulla durata del progetto di valutazione.

Il risultato di questa prima attività può essere tradotto in una personalizzazione della griglia di valutazione, ed in particolare nella determinazione dei "pesi" da associare alle singole voci della griglia, ossia dei fattori correttivi legati all'importanza relativa dei diversi aspetti da valutare.

Il secondo passo è la selezione dei prodotti da valutare. Dato il numero elevato delle possibili scelte, ed il costo di ogni singola valutazione di prodotto, è opportuno effettuare una prima cernita, restringendo il campo di indagine a tre - cinque prodotti al massimo. Questa prima selezione può avvenire raccogliendo le informazioni dai siti Web dei produttori, oppure ricorrendo a fonti indipendenti (letteratura, gruppi di discussione, consulenza).

Scelti i prodotti da valutare, si tratta di scendere in dettaglio. E' ovviamente importante contattare i produttori o distributori, per richiedere informazioni di carattere sia tecnico che commerciale. Ma è essenziale provare gli strumenti. Fortunatamente, tutti i prodotti UML sono disponibili alla prova, per un periodo di tempo limitato, ed ottenibili tramite download o facendone richiesta ai produttori. E' opportuno che i prodotti siano utilizzati, allo scopo di effettuare la valutazione, su una medesima applicazione già conosciuta in azienda, e che la prova sia effettuata da gruppi di lavoro che conoscono bene UML (almeno a livello teorico), i linguaggi da utilizzare per la generazione del codice ed il reverse engineering, e le problematiche di lavoro di gruppo. I risultati delle prove, e le indicazioni dei fornitori, consentono di attribuire un voto alle singole voci della griglia di valutazione.

L'ultima attività da effettuare consiste nel calcolo dei risultati, che avviene attraverso l'applicazione dei "pesi" ai voti riportati da ciascun prodotto nelle voci della griglia di valutazione. Il risultato è la scelta dello strumento più adatta alle specifiche esigenze dell'organizzazione.

Introduzione in azienda

Scelto lo strumento UML, è necessario porre la dovuta attenzione anche alla sua introduzione nel contesto operativo dell'azienda. In troppi casi, infatti, gli investimenti effettuati non vengono poi sfruttati nel modo ottimale, e gli strumenti acquisiti rischiano di diventare "shelfware", roba da scaffale.

Un primo aspetto da considerare è la velocità della diffusione. Si vuole procedere a spron battuto, fornendo subito il nuovo strumento a tutti i gruppi di lavoro, oppure in modo graduale, iniziando con un progetto pilota e diffondendo poi in modo incrementale il nuovo modo di lavorare?

A parte gli aspetti economici dell'investimento, la diffusione graduale è generalmente più efficace e meno rischiosa.

Il progetto pilota, che deve essere un lavoro effettivamente importante e non una simulazione (ma non dovrebbe neppure essere "mission critical" per l'organizzazione, per i rischi legati all'introduzione di un nuovo modo di lavorare), può fornire indicazioni importanti per l'adattamento dello strumento alle specificità dell'ambiente, e creare tra i partecipanti un nucleo di competenze che potrà poi essere utilizzato nei progetti successivi.

Uno dei problemi principali legato all'adozione di uno strumento di visual modeling sta infatti nella curva di apprendimento necessaria allo sviluppatore, cioè nella diminuzione temporanea di produttività legata all'acquisizione delle competenze sul prodotto. L'utilizzo degli strumenti di visual modeling UML non è infatti quasi intuitivo come quello di un word processor.

I concetti object-oriented e di sviluppo a componenti, che possono essere appresi a livello teorico in un corso di formazione, richiedono infatti una sperimentazione concreta per essere interiorizzati e applicati in modo produttivo. Il progetto pilota consente ai partecipanti di consolidare e approfondire le conoscenze, e va quindi effettuato con la guida di persone esperte, per ridurre costi e rischi e per velocizzare i tempi dell'apprendimento. I partecipanti al progetto pilota potranno poi, a loro volta, svolgere un ruolo di tutor nei successivi utilizzi nello strumento e delle tecniche in altri progetti.

Un secondo aspetto da considerare è l'adattamento dello strumento allo specifico modo di lavorare dell'organizzazione in cui viene calato. Gli strumenti di visual modeling possono essere utilizzati in modi molto diversi, anche perché UML è, in sé, decisamente complesso. Quali documenti, quali diagrammi dovranno essere prodotti? In quale sequenza? Da chi? E da chi dovranno essere validati o controllati? Si tratta di scelte non banali, che possono influire in modo decisivo sul successo o meno dell'investimento effettuato.

Andrà quindi definito un iter di lavoro per il progetto pilota, che specifichi i documenti da produrre ed il loro contenuto, la sequenza di attività da effettuare, le relative responsabilità attribuite alle figure professionali partecipanti, eventuali standard cui conformarsi.

L'iter di lavoro potrà essere più o meno "leggero", in termini di documentazione da produrre e di verifiche da effettuare, in funzione della cultura organizzativa dell'azienda, del settore di business in cui opera, del tipo di attività progettuale. Settori "life critical", come ad esempio l'industria aerospaziale, militare, medica, necessitano di un iter molto più regolamentato e controllato di altri, nei quali i rischi di una eventuale non aderenza ai requisiti di progetto hanno impatti minori. Per il progetto pilota, in ogni caso, è opportuno che l'iter di lavoro sia il più leggero possibile: una enfasi eccessiva sugli aspetti documentativi e di controllo può dare la sensazione che il nuovo modo di lavorare sia troppo burocratico, con conseguente rifiuto da parte degli sviluppatori.

L'iter di lavoro sperimentato, con gli opportuni aggiustamenti derivanti dall'esperienza concreta del progetto pilota, potrà costituire successivamente la base della procedura organizzativa (processo) per lo sviluppo, replicabile nei progetti successivi.


Elenco pubblicazioni.


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