Le linee tratteggiate in figura etichettate con la parola “refine” rappresentano uno stereotipo (“versione specializzata”) della relazione di dipendenza. Molto semplicemente, indicano che un aggiornamento apportato ad un oggetto indipendente (quello a cui punta la freccia) implica una revisione e verosimilmente una modifica dell’oggetto dipendente.
 
 
 

Due parole sullo UML ed il relativo metamodello
Prima di entrare nel merito nell’esposizione dei lavori affrontati dalla seconda RTF, probabilmente è il caso di spendere qualche parola sulla nozione di metamodello UML e di meta-metamodello (consultare [1] e [3] per ulteriori dettagli).
In questo paragrafo è necessario introdurre concetti di un livello di difficoltà superiore.. Nonostante l’impegno profuso dall’autore nel cercare di renderli il più semplici possibili, non è possibile renderli banali.
Contrariamente a convinzioni comuni in molti tecnici, lo Unified Modeling Language, non è unicamente una notazione standard per la descrizione di modelli object oriented di sistemi software; si tratta bensì di un metamodello definito rigorosamente che, a sua volta, è istanza di un meta-metamodello definito altrettanto formalmente (Auch! Questo concetto fa un po’ male).
Si inizi ad esporre ed analizzare la definizione di metamodello.
Un metamodello è un modello a sua volta istanza di un meta metamodello, fruibile per esprimere una sua istanza di modello: l’UML (metamodello) permette di realizzare diversi modelli object oriented (modelli definiti dall’utente). Il metamodello dello UML definisce la struttura dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del mondo object oriented, quali ad esempio classi, interfacce, relazioni e così via, ma esso rende possibile avere diverse notazioni che si conformano al metamodello stesso.
Così come avviene nella relazione che lega le classi agli oggetti, una volta definita una classe si possono avere svariate istanze della stessa (oggetti), analogamente è possibile progettare un numero infinito di varianti dello “UML” (istanze del metamodello).
Nelle sue prime apparizioni ufficiali lo UML era composto “semplicemente” da una notazione grafica, fruibile per rappresentare modelli di sistemi object oriented.
Quando poi è giunto il momento della sottomissione allo OMG, per il conferimento del riconoscimento ufficiale di standard (Gennaio 1997), si è reso necessario conferirgli una veste più formale. Così a partire dalla versione 1.1 lo UML definisce rigorosamente un metamodello e la notazione atta alla formulazione di modelli object oriented conformi ad esso.
Un meta-metamodello è un modello che definisce un linguaggio per esprimere un metamodello. (Chiaro no!?)
La relazione tra il meta-metamodello ed il metamodello è paragonabile a quella esistente tra il metamodello ed un modello.
Lo UML è definito in termini di un meta-metamodello denominato MOF: Meta Object Facility.
Nella figura 2 viene illustrato graficamente quanto emerso fino a questo punto: relazioni esistenti tra il meta-metamodello, il metamodello ed il modello dell’utente.
Scorrendo il diagramma dall’alto verso il basso si assiste ad una graduale diminuzione del livello di astrazione; se si fosse deciso di visualizzare un ulteriore livello, si sarebbero trovate entità, istanze della classe del modello dell’utente: oggetti.
Se per esempio si realizzasse un prototipo di un sistema di commercio elettronico (i famosi siti .com), a livello del modello realizzato dall’architetto, si troverebbero classi (opportunamente relazionate tra loro) del tipo: Categoria, SottoCategoria (probabilmente l’organizzazione in Categorie si presta ad essere rappresentata per mezzo del pattern composite), Prodotto, Utente, Profilo, e così via. Se poi si volesse visualizzare l’ulteriore livello, l’istanza del user model, bisognerebbe inserire oggetti, istanze di tali classi, come per esempio il Prodotto di codice X, avente prezzo Y, della categoria Z, e così via.
Per avere un’idea più chiara (forse meno oscura), si consulti il diagramma riportato nella figura 3.
Come si può notare, nel modello di analisi compare una classe denominata Ordine appartenente al dominio del problema. La classe è un’istanza della metaclasse, presente nel package UML metamodello e contiene attributi ed operazioni che, a loro volta, sono istanze rispettivamente delle metaclassi Attributi e Operazioni. Se anche in questo caso si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate le istanze delle classe Ordine, ossia oggetti del tipo: 00000312 : Ordine. 
 
 

Qualche informazione sulla seconda RTF
Prima di entrare nel merito degli aggiornamenti apportati allo UML con la versione 1.4, probabilmente è il caso di illustrare brevemente le attività svolte dalla seconda Revision Task Force, i cui lavori sono iniziati nel dicembre 1999 a seguito dell’investitura della Platform Technology Committee (Agosto 1999).
Le richieste sono state sottoposte al gruppo sia via e-mail e mail listing (uml-rtf@omg.org, issues@omg.org rispettivamente) sia direttamente dagli stessi membri del RTF.
Il gruppo è stato suddiviso in otto team per specifiche aree di competenza (gruppo del Foundation package, dei profili, dell’OCL, state machine ecc.). Le necessarie sincronizzazione tra i gruppi sono avvenute sia attraverso cinque raduni, sia per mezzo di riunioni virtuali (via video conferenza ) con cadenza bisettimanale.
Come evidenziato nella tabella 1 e nel relativo diagramma a torta di figura 4, il numero di richieste prese in esame è stato di 155 unità. Di queste 86 sono state considerate legittime e quindi risolte, 31 al fuori dagli obiettivi del gruppo (“out of scope”), 23 sono state passate al RTF che ci occupa della versione 2.0 dello UML, 13 sono state considerate  risolte da versioni precedenti dello UML, mentre le restanti 2 sono risultate ridondanti con ad altre richieste.
Il risultato dei lavori della seconda RTF è confluito nel “MG Unified Modeling Language
Specification draft” versione 1.4 del Febraio 2001, che, attualmente, sta seguendo l’iter del processo di adozione da parte del OMG. In altre parole bisognerà attendere alcuni mesi per vederne la ratificazione.

Overview delle modifiche proposte
Gli aggiornamenti apportati, o meglio proposti, hanno investito diverse aree. Quelle oggetto di maggiori attenzione probabilmente sono state (l’approfondimento della descrizione delle modifiche proposte è riportata nel prossimo capitolo):

· Core (Foundation package), in particolare è stato ridefinito il concetto di “Component” al fine di fornire elementi che consentano di utilizzare più proficuamente lo UML nella modellazione di architetture component based. Sempre in questo contesto sono stati aggiunti ulteriori “artefacts” al fine di poter di distinguere manufatti di deployment (file come EJB JARS, DLL, ecc.) da gli elementi che li costituiscono generati durante la fase di sviluppo (EJB, COM objects, ecc.).
· Meccanismi di estensione (Foundation package), è stato ridefinito sia il concetto di stereotipo (stereotype) al fine di permettere la definizione di diversi stereotipi di uno stesso elemento del modello, sia i tag value aggiungendovi l’attributo “TagDefinition” che ne consente una forte tipizzazione dei valori;
· Model Management Package (Modeling Language), è stato aggiunto lo stereotipo “Profile” per l’elemento “Package” al fine di consentire il raggruppamento di eventuali profili definiti dall’utente (in questo caso con il termine utente si fa riferimento prevalentemente agli architetti). 
· UML Standard profiles (profili UML standard)., queste modifiche si sono rese necessarie al fine di conservare la consistenza tra i profili predefiniti e la nuova versione UML. In particolare si è reso necessario revisionare i profili per via di diverse modifiche apportate alla semantica e notazione che influenzano direttamente la definizione dei profili.
· Activity Diagram (behaviour Elements Package) sono stati aggiunte (finalmente) le notazioni per l’invocazione degli stati e tags specifici per l’utilizzo di object flow states;
· OCL, il cui obiettivo principale è stato fornire chiarimenti circa elementi sintattici e regole grammaticali, correggere imprecisioni e di fornire nuove macro per semplificarne l’utilizzo;
 
 
 

UML 2.0?
A questo punto viene da interrogarsi legittimamente su come stiano procedendo i lavori per la versione 2.0 (etichettata come “major revision”), cosa sia lecito attendersi e se questa decreterà la fine della serie 1.x dello UML.
Molto probabilmente uno degli impegni più importanti consiste nel proseguire nella direzione, già intrapresa con la versione 1.4, dello studio delle necessità dei sistemi component-based. Ciò al fine di adeguare sempre più lo UML allo stato dell’arte della tecnologia e quindi fornire soluzioni concrete alle esigenze dei tecnici coinvolti nella realizzazione di sistemi basati sui componenti.

Le frecce tratteggiate rappresentano relazioni di dipendenza come da definizione standard.
Le linee culminanti con un diamante rappresentano relazioni di composizione dette anche whole-part (tutto-parte). In particolare, nel contesto oggetto di studio, indicano che la versione UML 2.0 è costituita dalla documentazioni prodotta della RTF infrastructure, Superstructure e OCL. 

Si consideri il diagramma riportato in figura 5. Come annunciato in precedenza dallo OMG, la RTF per la versione 2.0 è stata suddivisa (questa volta ufficialmente) in tre parti:

1. 1. Infrastruttura (Infrastructure RFP, OMG document ad/00-09-01). Come ne suggerisce il nome, obiettivo di questa RTF consiste nel curare miglioramenti relativi alla struttura base del metamodello UML, ossia, riguardanti il core, i meccanismi di estensione, le facility del linguaggio ecc. In particolare i relativi obiettivi sono di allineare l’architettura dello UML agli altri standard gestisti dall’OMG (quali per esempio il MOF, Meta Object Facility, Meta-data Interchange XMI), ristrutturare il linguaggio al fine di renderlo più comprensibile ed estenderlo mantenendo però la semantica e notazione attuale.
2. Superstruttura (Superstructure RFP, OMG document ad/00-09-02). Obiettivo di questa RTF è elaborare proposte atte ad incorporare le “best-pratices” in aree particolarmente sensibili come lo sviluppo di sistemi basati sui componenti, i modelli architetturali, quelli eseguibili e dell’area business. In particolare è necessario studiare ulteriormente le soluzioni per:
1. la gestione degli eventi nei diagrammi delle attività;
2. migliorare l’illustrazione dell’incapsulamento con particolare riferimento ai digrammi di stato e di sequenza;
3. ridefinire la semantica di relazioni come la generalizzazione, associazione, ecc.
4. il supporto dello sviluppo component-based di sistemi software. 
5. il supporto per architetture a tempo di esecuzione, favorendone la descrizione del comportamento dinamico e l’eventuale rappresentazione gerarchica.
3. Object Constraint Language (OMG document ad/00-09-03). Il nome di questa RTF evidenzia chiaramente quale sia la relativa area di competenza: l’OCL. Gli obiettivi sono di presentare proposte atte ad aumentare il livello di specializzazione dell’OCL per l’utilizzo UML. Ciò dovrebbe semplificare il lavoro degli utenti, favorendo l’aumento di formalita’ dei vari modelli prodotti.

Da diverso tempo è in corso un dibattito all’interno dell’OMG stesso, teso ad investigare la necessità di introdurre un ulteriore “task force” con l’obiettivo di studiare l’area relativa allo scambio di modelli UML prodotti da tool diversi. Il nome di tale gruppo dovrebbe essere “Diagram Interchange RFP”. Sebbene in tale direzione ci sia già stato un impegno iniziale della seconda RTF, il relativo interesse è stato focalizzato principalmente sulla semantica e non sulla problematica specifica dello scambio concreto di diagrammi.
Come ben noto a tutti i tecnici informatici, l’aumento del parallelismo nello svolgimento di attività presenta evidenti vantaggi (riduzione dei tempi grazie al lavoro in parallelo, maggiore specificità delle tematiche affrontate, ecc.), a fronte dei quali però, sono presenti tutta una serie di problematiche. Nel contesto oggetto di studio queste sono relative essenzialmente all’incremento del lavoro necessario sia per l’integrazione delle proposte avanzate dai singoli gruppi, sia per il mantenimento della coerenza delle specifiche finali.
Pertanto ulteriore preoccupazione della RTF per la revisione 2.0 dello UML è controllare lo sviluppo parallelo delle varie task force al fine di far sì che le varie componenti lavorino nella stessa direzione e producano la “maggiore revisione” preservando la coerenza e le strutture delle precedenti versioni mostratesi particolarmente efficaci.
 
 
 

Conclusioni
Non ostante il recente fiorire di processi, per così dire leggeri, incentrati sulla codifica, lo UML è diventato uno standard “de facto” largamente accettato su base planetaria. I suoi pregi sono così universalmente comprovati che non richiedono ulteriori commenti.
Probabilmente non esistono più giustificazioni al rifiuto dell’utilizzo dello UML.
Attualmente, risulta veramente difficile lavorare in sistemi di medio grandi dimensioni, in cui non venga utilizzato lo UML per documentare, analizzare, …. i vari “artefact” previsti dal processo di sviluppo (dal modello dei requisiti utente al deployment del sistema).
A dire il vero, esiste tutta una schiera di tecnici che rifiutano l’utilizzo dello UML. Tra di essi vi sono i vari hacker che lo fanno per scelta religiosa e quindi non esiste modo di persuaderli, e tutta una serie intimorita dalla presunta complessità dello strumento stesso. Probabilmente questi ultimi non hanno tutti i torti… I vari libri disponibili sul mercato non sempre sono esempi di praticità. Comunque è importante sottolineare che il premio al diagramma UML più formale non dovrebbe essere stato ancora stato istituito.
Premesso ciò, il grande lavoro prodotto dalle varie RTF e l’interesse dimostrato dalla comunità informatica mondiale è un segnale evidentissimo della vitalità ed efficacia del linguaggio.
Chiaramente si tratta di un formalismo destinato a ancora a crescere, non ostante la paura nutrita da molti tecnici di vederlo aumentare eccessivamente in complessità.
Non ostante il brillante lavoro prodotto dalla seconda RTF, esistono ancora diverse aree che probabilmente necessitano di essere investigate, tra le quali quelle ritenuti più importanti sono :
· area component: verosimilmente è necessario proseguire nel lavoro di studio di soluzioni atte a facilitare la rappresentazione dei “artefact” necessari per lo studio di sistemi component-based;
· cosa dire dell’interfaccia utente? Probabilmente l’autore verrà tacciato di realizzare sistemi dell’età della pietra, eppure nel 98% dei sistemi sviluppati era presente una GUI. Tra l’altro tutti i processi di sviluppo del software prevedono come “artefact” la definizione della GUI, la relativa navigazione ecc.
· database relazionali: attualmente lo UML non prevede alcun formalismo per la definizione della struttura logica e fisica dei data base relazionali. Non ostante l’introduzione di quelli basati sul paradigma object oriented, per tutta una serie di motivi (politiche di salvaguardia degli investimenti delle aziende, relativa giovinezza della tecnologia dei OODMS, scarsa cultura in materia di taluni tecnici, ecc.) quelli relazionali risultano ancora predominare il mercato. Pertanto nel contesto dei processi di sviluppo si rende necessario disporre di formalismi atti a descrivere i manufatti necessari per la progettazione di database relazionali.
 

Bibliografia
· [1] OMG UML v. 1.4: Revisions and Recommendations – OMG UML 1.4 Revision Task Force
· [2] OMG Unified Modeling Language Specification (draft) – Version Draft 1.4 Febraio 2001
· [3] UML dalla Teoria alla Pratica di Luca Vetti Tagliati
 

Biografia dell'autore
Luca Vetti Tagliati è uno studioso e appassionato del linguaggio UML. Ha scritto diversi articoli “pubblicati” sulla rivista virtuale www.Mokabyte.it. Attualmente sta terminando di redigere il libro “UML dalla teoria alla pratica” presto disponibile sempre nel sito di Mokabyte.
Negli ultimi anni ha applicato la progettazione/programmazione component based in settori che variano dal mondo delle smart cards (www.platform7.com) a quello del trading bancario (www.hsbc.com). Lavora come consulente presso la banca londinese HSBC con funzioni di technical architect e team leader. È membro del gruppo di “processing engineering” (a cui partecipano personaggi del calibro di Frank Armour coautore del libro “Advanced Use Case Modeling” e John Daniles coautore del libro “UML components”). Si tratta di un gruppo ristretto di dieci tecnici istituito per stabilire ed attuare, una versione del RUP da utilizzarsi come standard interno della banca da applicarsi nello sviluppo di sistemi software.
E’ rintracciabile, presso l’indirizzo lvetti@mokabyte.it