Il Processo di Modellazione Unificato
Il grande successo che ha avuto UML (rif.[1]) risiede nella sua elevata potenza espressiva, perchè si tratta di un linguaggio semantico che può essere applicato a qualsiasi processo di sviluppo software. Tuttavia UML è soltanto un formalismo per modellare, non un modo di progettare un sistema. Per utilizzare efficacemente UML è necessario avvalersi di un metodo di progettazione. Ne esistono diversi (ad esempio OOSP - rif.[2] - oppure ICONIX - rif.[3]- o ancora OPEN - rif.[4]), ma il più comune è probabilmente il primo che è stato utilizzato insieme con UML, quello noto come Rational Unified Process (RUP nel seguito) anche se poi è stato rinominato semplicemente Unified Process, ovvero Processo Unificato (rif.[5]). Come spiegato dettagliatamente in rif.[6], RUP non è fisso e inalterabile, ed è perfettamente possibile fare in modo che si adatti alle proprie competenze e alle proprie necessità, al fine di utilizzarlo con efficacia nel proprio processo produttivo.

Sviluppare il software
Un processo di sviluppo software è costituito da un insieme di fasi da seguire per portare un sistema dall'ideazione all'implementazione effettiva. Tali fasi comportano la messa in campo di numerose discipline, che tipicamente sono:

- Modellazione del Business
- Raccolta dei requisiti
- Analisi e Progettazione
- Implementazione
- Test
- Deployment
- Gestione della Configurazione e dei Cambiamenti
- Project Management
- Gestione dell'ambiente

Ciascuna delle suddette discipline necessita della possibilità di essere raffinata ed iterata, sia perchè è impossibile pensare che l'attività ad essa relativa sia a un dato momento completamente "stabile e definitiva", sia perchè occorre sempre poter gestire al meglio eventuali modifiche da apportare "in corsa" in virtù di cambiamenti che il sistema finale deve osservare. Anche per questo si tende a raccomandare l'impiego di strumenti di sviluppo visuali che permettono di raggiungere quella astrazione fondamentale per catturare al meglio gli aspetti più rilevanti del business, ma si sottolinea altresì la necessità di prevedere intense fasi di verifica tramite test del software che viene via via prodotto, proprio al fine di garantirne in modo sempre maggiore il livello qualitativo.

RUP: le fasi componenti
Nel caso specifico del Processo Unificato (RUP), è possibile individuare quattro fasi componenti, e precisamente:

- Inception, ovvero Inizio, fase in cui il sistema da sviluppare viene identificato, assieme ai suoi contenuti e casi d'uso
- Elaboration, ovvero Elaborazione, fase in cui viene eseguita una progettazione dettagliata che porta ad identificare le basi del sistema
- Construction, ovvero Costruzione, fase in cui si procede alla scrittura del software
- Transition, ovvero Transizione, fase in cui il sistema viene fornito agli utenti

Nella sottostante figura 1, il collocamento delle varie discipline discusse nel paragrafo precedente "incrociate" in modo matriciale con le quattro fasi del RUP.

Figura 1 - Il Processo Unificato

E' molto importante ricordare che il RUP possiede due dimensioni, una di tipo "statico", che raggruppa le diverse discipline rilevanti al ciclo di vita del progetto, l'altra di tipo "dinamico", che crea e mantiene un appropriato "contesto" per l'implementazione delle diverse attività corrispondenti alle medesime discipline coinvolte. Ecco il motivo per cui all'interno di ciascuna fase devono essere individuate, pianificate ed eseguite tutte le diverse iterazioni necessarie a portare avanti il progetto con il massimo controllo possibile.

Applicare RUP in pratica
Quando si decide di utilizzare RUP per i propri obiettivi di business, diviene vitale la scelta di uno strumento di sviluppo appropriato, in grado di coprire le diverse fasi del Processo Unificato e, all'interno di ciascuna di esse, garantire la possibilità di effettuare le varie iterazioni come previste dall'impiego delle diverse discipline coinvolte, il tutto con l'obiettivo di assicurare al sistema da sviluppare la massima qualità nei tempi più brevi.
Altro aspetto non meno importante è identificare con chiarezza i diversi attori e ruoli coinvolti in ciascuna fase, allo scopo di garantire al team di lavoro una accorta e precisa suddivisione dei compiti e assegnazione di ciascun attore al ruolo più appropriato secondo i suoi specifici skill.
Per illustrare meglio tutto ciò, può essere a questo punto utile seguire lo sviluppo di una applicazione J2EE-tipo mediante RUP evidenziando, per ciascuna delle quattro fasi, le diverse azioni e/o iterazioni da svolgere, i flussi di lavoro previsti, gli attori coinvolti con i rispettivi ruoli. Questo è proprio ciò che verrà illustrato nei prossimi paragrafi.

Inception
La fase di Inception (Inizio) è caratterizzata dalla raccolta e relativa comprensione dei requisiti di business di base, a partire dai quali è possibile tracciare i casi d'uso e i diversi attori coinvolti nel sistema assieme alle relazioni e interazioni con i casi d'uso medesimi. Questa fase coinvolge tipicamente figure professionali quali architect, project manager e business analyst.
Essi individuano dapprima gli aspetti salienti del core business del sistema da sviluppare e successivamente procedono alla formalizzazione dei relativi modelli, servendosi di strumenti di lavoro opportuni. Un esempio di tali strumenti può essere offerto dalla soluzione Steeltrace Catalyze (rif.[7]), un tool dedicato proprio alla cattura requisiti e produzione documentazione, con l'obiettivo di permettere ai diversi attori coinvolti di condividere le varie informazioni così formalizzate.
Nella figura 2 un esempio di modellazione dei requisiti, in un ipotetico sistema di gestione degli ordini denominato OptiShop.

Figura 2 - Raccolta requisiti con Steeltrace Catalyze
(clicca sull'immagine per ingrandire)

L'insieme dei requisiti raccolti e documentati in tal modo può essere a questo punto esportato in diversi formati (fig. 3), al fine di permetterne l'utilizzo da parte di altri strumenti.

Figura 3 - Export dei requisiti

Nella figura 3 si può notare come uno dei tool verso cui è possibile effettuare l'export sia Compuware OptimalJ (rif.[8]), tool di sviluppo J2EE completamente visuale e conforme ai principi della Model Driven Architecture (rif.[9]). OptimalJ permette di approcciare in una varietà di modi le problematiche inerenti la modellazione di un sistema durante la fase di Inception, e ciò in quanto offre sia un completo supporto UML (figura 4), sia la possibilità di interagire e cooperare con altri strumenti di modellazione (Catalyze, ad esempio). Questo lascia la massima libertà di scelta in termini di tool da impiegare per catturare i requisiti.

Figura 4 - Supporto UML in OptimalJ

E' quindi possibile acquisire quanto è stato prodotto da Catalyze in termini di requisiti (figura 5) e visualizzarlo sotto forma di diagrammi Use Case (figura 6).

Figura 5 - Import UML da Catalyze

Figura 6 - Use Case Diagram Sistema Optishop

Viceversa, nel caso in cui si sia invece utilizzato Rose per la modellazione, sarà possibile effettuare un import in OptimalJ del file UML/XMI prodotto, deducendo da esso il Class Diagram necessario a iniziare l'attività di sviluppo. Nelle seguenti figure 7 e 8 un import del file UML/XMI corrispondente al medesimo sistema Optishop proveniente da una modellazione effettuata con Rose.

Figura 7 - Import UML da Rose

Figura 8 - Class Diagram Sistema Optishop

Elaboration
La fase di Elaboration (Elaborazione) è caratterizzata dalla progettazione di una architettura di base destinata a contenere tutti i requisiti raccolti durante la fase precedente, tanto quelli funzionali quanto quelli non funzionali. Anche questa fase coinvolge tipicamente figure professionali quali architect, project manager e business analyst.
Durante questa fase è di primaria importanza poter considerare stabili i requisiti "immersi" nel modello architetturale in corso di sviluppo, proprio perchè da essi occorre partire per lo step successivo (Construction, vedi paragrafo successivo). Questa è appunto una criticità, proprio perchè tale esigenza di "stabilità" non è riscontrabile nella pratica, pur essendo fondamentale per poter procedere con i lavori. Ecco perchè diviene determinante avere a disposizione un tool che permetta di ricavare in modo veloce e quanto più possibile affidabile il modello architetturale di base (il Class Diagram), permettendo altresì di apportarvi, se e quando necessario, le varie modifiche via via richieste, salvo aggiornare e allineare tutti i modelli derivati da esso. In pratica, occorre uno strumento che permetta di "iterare" in modo facile, veloce, affidabile. Questo è completamente garantito dall'impiego della metodologia MDA (rif.[9]) che permette di lavorare per astrazioni e modelli. Proprio su di essi è possibile effettuare le modifiche che dovessero rendersi necessarie per esigenze di business. Vale la pena qui ricordare che i modelli previsti da MDA sono quelli indipendenti dalla tecnologia (i cosiddetti Platform Independent Model, o PIM), e quelli specifici della tecnologia scelta, J2EE nel nostro caso (Platform Specific Model o PSM). Uno strumento che implementa completamente MDA permette di lavorare sui modelli PIM e PSM garantendo la sincronizzazione tra di essi e offrendo la possibilità di intervenire per attività di "fine-tuning". Qualsiasi modifica apportata su uno qualsiasi dei modelli sarà in modo immediato riportata su tutti gli altri, proprio grazie ai principi di MDA.
Alcuni esempi? Nella figura 9 l'inserimento di un vincolo ("constraint") nella classe UML Customer, utile ad esempio per modellare regole di validazione su attributi.

Figura 9 - Modellare vincoli sul Class Diagram di Optishop

Nella figura 10, un esempio di Component Model Diagram utile per modellare e personalizzare le invocazioni tra le diverse parti del sistema.

Figura 10 - Application Component Diagram di Optishop

Nella figura 11 infine, un esempio di Activity Diagram utilizzato per modellare sul PSM Web model un flusso applicativo personalizzato.

Figura 11 - Web Flow Diagram di Optishop

Construction
La fase di Construction (Costruzione) prevede la progettazione dettagliata di quanto ricavabile dal modello architetturale messo a punto durante la fase precedente e la susseguente scrittura materiale del codice, inteso come sviluppo di tutte le componenti software che realizzano e implementano le funzionalità del sistema. Questa fase, ragionevolmente piuttosto costosa in termini di effort temporale, coinvolge tipicamente figure professionali quali team leader e sviluppatori, impegnati a identificare e implementare le cosiddette "Business Rules", processo oltremodo delicato e complesso (rif.[10]).
Se utilizziamo uno strumento che supporta MDA, ricaviamo il codice Java dai modelli PSM costruiti durante la fase precedente, eventualmente personalizzandolo e modificandolo secondo le nostre esigenze. E' importante essere certi che il codice generato in modo automatico sia efficiente e di qualità, e questo non dipende solo dalla bontà dei modelli costruiti precedentemente, ma anche dalle regole di derivazione del codice dai modelli stessi. Proprio a questo proposito, uno strumento che, oltre a supportare MDA, produce il codice implementando i Core J2EE Pattern rappresenta una notevole garanzia in termini di qualità e affidabilità (rif.[11]).
Per quanto concerne invece le attività di personalizzazione del codice, è importante notare che esse tipicamente riguarderanno:

• interventi sulla interfaccia grafica, in cui è necessario applicare alla GUI tutti i requirements "cosmetici" richiesti dall'utente finale (in figura 12 un esempio di JSP authoring su una form)

Figura 12 - JSP Authoring

• interventi sulla logica di business, che possono essere effettuati tanto sui modelli (PIM o PSM, in figura 13 il wizard di definizione di metodi di business sul layer EJB)

Figura 13 - Wizard di definizione dei metodi di bsuiness

quanto sul codice (in figura 14 un esempio di visualizzazione del codice di un Entity Bean, in cui sono evidenziate le zone bianche in cui è possibile inserire il proprio codice, i cosiddetti free blocks)

Figura 14 - Codice generato di un Entity Bean

- interventi di "internazionalizzazione" al fine di adattare la user interface alle diverse realtà internazionali (in figura 15 un esempio di impostazione internazionalizzazione).

Figura 15 - Internazionalizzazione

Transition
La fase di Transition (Transizione) corrisponde alla preparazione del sistema per la consegna fino alla fase di delivery vera e propria effettiva del sistema agli utenti finali. Durante tale fase è fondamentale poter disporre di facility che permettano in modo rapido e affidabile di effettuare le diverse attività di debugging, unit test, logging, collaudo integrato, deployment. Mentre funzionalità come quella di debugging o di logging sono ampiamente fornite e supportate (chi non conosce JPDA o log4j, tanto per fare due esempi?), meno diffusa forse è la possibilità di modellare anche i propri unit test o la capacità di effettuare un collaudo direttamente sulla piattaforma target prima del deployment vero e proprio, per non parlare della possibilità di effettuare, sempre durante il collaudo, attività di "troubleshooting", individuando ad esempio i classici "colli di bottiglia" o i cosiddetti "memory leak".
Per nostra fortuna, esistono soluzioni a tutto, vediamole brevemente e nell'ordine.
A proposito dello unit test, a partire da marzo 2004 è diventato standard in ambito OMG il cosiddetto U2TP (UML 2.0 Testing Profile), ossia la possibilità di modellare con UML e i modelli MDA proprio i test funzionali, abbattendo in tal modo i tempi della verifica del codice e parallelizzando al massimo la comunicazione tra team di sviluppo e team di test, proprio in virtù dell'utilizzo del medesimo formalismo (rif.[12]). In figura 16 un esempio di definizione del test funzionale secondo U2TP.

Figura 16 - Model Driven Testing secondo U2TP

Come spiegato dettagliatamente in rif.[13], è altresì di vitale importanza poter verificare, prima ancora di affrontare il deployment vero e proprio della applicazione, che essa sia compatibile con l'ambiente in cui dovrà operare, l'ambiente cioè di esercizio. E' per questo che sempre in rif.[13] si parla di Management Specification e Application Deployment, una serie di "regole" e "guidelines" che si propongono l'obiettivo di rendere le procedure di deployment quanto più semplici possibile. E' ovvio che disporre di tool che permettono questo tipo di approccio facilita enormemente il processo di deployment. In figura 17 un esempio di wizard di definizione del server di deployment prima di lanciare, direttamente su di esso e prima del deployment vero e proprio, l'applicazione oggetto delle sviluppo.

Figura 17 - Collaudo integrato nel contesto del tool di sviluppo

Se si desidera poi controllare in modo approfondito se l'applicazione sviluppata determina problemi in termini di performance ovvero in termini di allocazione e consumo della memoria è particolarmente utile servirsi delle funzionalià di troubleshooting disponibili, che servono appunto a "mettere a punto" l'applicazione in questione, cercando di individuare per tempo e con la massima accuratezza l'origine di problemi prima che possano causare un degrado significativo del software che deve essere consegnato. Nella figura 18 un esempio delle funzionalità di troubleshooting offerte dallo strumento Compuware OptimalJ.

Figura 18 - Funzionalità di troubleshooting

A questo punto sembra proprio che siamo pronti ad affrontare la fase di consegna agli utenti finali, ed è indispensabile essere pronti a pensare che sarà necessario un buon numero di attività di regressione dovute proprio alla richiesta, da parte degli utenti, di apportare modifiche e/o aggiunte, senza contare ulteriori errori e/o malfunzionamenti che dovessero essere rilevati durante questa fase. E' durante questa delicata fase che è di primaria importanza avere effettuato correttamente e in modo completamente integrato tutte le precedenti fasi di sviluppo, al fine di poter in qualsiasi momento tornare indietro ad una delle fasi precedenti per apportare le modifiche che dovessero essere necessarie. Nel caso del nostro esempio, in cui si è applicato RUP mediante uno strumento MDA-compliant, appare chiaro come il fatto di poter disporre dei modelli PIM (di business) e PSM (applicativi) permetta in modo veloce, efficiente e affidabile di far fronte a qualsiasi tipo di cambiamento venga richiesto.

Un Case Study reale
Abbiamo sin qui esaminato i concetti di base e le problematiche che nel corso delle quattro fasi principali di RUP devono essere prese in considerazione. Per motivi di spazio non è qui possibile analizzare in dettaglio un esempio più significativo. Tuttavia, per chi desiderasse ulteriori approfondimenti, un Case Study completamente svolto e tratto da una situazione reale è reperibile in rif.[14].

Conclusioni
Nonostante il grande successo e la grande popolarità che UML ha acquistato non bisogna dimenticare che si tratta solo di un formalismo, utile per poter esprimere concetti e per poter modellare oggetti di business. Al fine di riuscire a progettare con successo un sistema occorre servirsi di una metodologia, e il Processo Unificato (RUP) nasce proprio con tale scopo. In questo articolo si è cercato di andare oltre, offrendo spunti per la applicazione pratica di RUP nell'ambito di situazioni reali e ponendo il focus sulla necessità di disporre di adeguate soluzioni software che permettano di applicarlo nel modo più efficiente possibile, fornendo il più elevato valore aggiunto.

Bibliografia
[1] UML Resource Page, http://www.uml.org/
[2] Scott Ambler, "Process Patterns, Building Large-Scale Systems using Object Technology",
Cambridge University press
[3] "Il processo ICONIX", Unified Object Modeling www.iconixsw.com/Spec_Sheets/UnifiedOM.html
[4] "Il processo OPEN", www.open.org.au
[5] Jacobson, Booch, Rumbaugh, "The Unified Software Development Process", Addison Wesley
[6] Jason T. Roff "Fondamenti di UML", McGraw Hill
[7] Steeltrace Home Page, http://www.steeltrace.com/
[8] Compuware Lab "OptimalJ Community" - http://javacentral.compuware.com
[9] Mokabyte - "Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE", parte 1 http://www.mokabyte.it/2004/07/mda-1.htm e parte 2 http://www.mokabyte.it/2004/09/mda-2.htm)
[10] Mokabyte -"Le Business Rules nelle Applicazioni J2EE", http://www.mokabyte.it/2004/12/busrules.htm
[11] Compuware Lab "Implementing Sun Microsystems' Core J2EE Patterns" http://javacentral.compuware.com/members/downloads/pdf/OJSunpatterns.pdf
[12] Mokabyte -"Model Driven testing nelle Applicazioni J2EE", http://www.mokabyte.it/2005/01/mdatesting.htm
[13] E. Armstrong et al. "The J2EE 1.4 Tutorial", http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
[14] Compuware Lab "Using OptimalJ in a Unified Software Development Process" http://javacentral.compuware.com/members/optimalj/documentation/v3.3/pe/2310-6-20-17-22.html

Doriano Gallozzi è nato a Roma nel 1964 e si è laureato in Ingegneria Elettronica (indirizzo Informatica) nel 1989. Da sempre interessato a problematiche di analisi, progettazione e sviluppo di Sistemi Informativi, ha lavorato per diversi anni in aziende del settore informatico italiano (gruppo ENI, gruppo Telecom Italia), dove ha acquisito diverse esperienze tanto nel campo della progettazione e sviluppo del software (in ambiente M/F come in ambiente distribuito) quanto nel campo dei RDBMS (DBA su diversi progetti per clienti finali quali Telecom Italia). Da gennaio 2000 lavora nella Divisione Prevendita di Compuware Italia. La sua attività verte principalmente sulla piattaforma J2EE e tecnologie correlate, ma anche su ambiti tecnologici quali l'Enterprise Application Integration, i Portali Web, gli strumenti di Business Process Modeling.