• stereotypes (stereotipi);
• tagged values (valori etichettati);
•  constraints (vincoli).

Brevemente, gli stereotipi permettono di estendere il vocabolario dello UML attraverso l’introduzione di nuovi elementi, definiti dall’utente, specifici per il problema oggetto di studio. Chiaramente la definizione degli stereotipi deve seguire regole ben precise: ciascuno di essi deve essere la specializzazione di un elemento presente nello UML (metamodello). In ultima analisi uno stereotipo è un nuova classe che viene (virtualmente) aggiunta al metamodello in fase di progettazione. 

I tagged value estendono le proprietà degli elementi dello UML aggiungendo informazioni supplementari a qualsiasi elemento. Sono a tutti gli effetti esempi di specificazioni. Si tratta di elementi costituiti dalla coppia (nome, valore), la cui interpretazione semantica esula (volutamente) dagli obiettivi dello UML. Si tratta di convenzioni interamente demandate ai tool e/o dell’utente e per questo sono definiti meta attributi virtuali.

I vincoli rappresentano restrizioni della semantica dei modelli. Una delle migliore definizioni formali sancisce che un vincolo è una restrizione di uno o più valori (o parti) di un modello object oriented o di un sistema. Tipicamente un vincolo può essere rappresentato attraverso qualsiasi formalismo: la selezione di quello ritenuto più idoneo è completamente demandata al progettista. Da notare però che, nella versione 1.3 dello UML è stato incorporato ufficialmente lo OCL (Object Constraint Language) dell’IBM: linguaggio object oriented per la formulazione di vincoli esenti da effetti collaterali. Quindi, sebbene non sia strettamente obbligatorio definire tutti i vincoli per mezzo dell’OCL, l’utilizzo, qualora possibile, ne è fortemente consigliato.
Per informazioni di dettaglio relative ai meccanismi di estensione è disponibile, nell’archivio di MokaByte, un articolo introduttivo allo UML, scritto dallo stesso autore.

A questo punto sembrerebbe che tutti i problemi siano risolti, ed invece, si scoprì che, nella flessibilità offerta dallo UML; si annidava il rischio di una nuova babele, questa volta non di lingue ma di dialetti.

Il problema emerso era che le estensioni da apportare allo UML, al fine di adattarlo a tecnologie particolarmente ricorrenti in progetti object oriented, erano completamente demandate ai progettisti. Se da un lato è vantaggioso, per i motivi più volte elencati, disporre di un linguaggio di modellazione general pouposes, dall’altro la relativa flessibilità può creare non pochi problemi soprattutto ad un pubblico non espertissimo. Ciò, oltre ad esigere lavoro supplementare ai vari tecnici (il cui buon esito tra l’altro era tutt’altro che scontato), riesumava vecchi problemi dovuti alla mancanza di standard, quali l’incomunicabilità, la difficoltà da parte dei produttori di tool di fornire funzionalità sempre più raffinate (per esempio la funzione di riverse engineering di sistemi basati su specifiche architetture non solo erano difficili da realizzare, ma si correva anche il rischio di invalidare il lavoro di modellazione) e così via.

Onde evitare tutto ciò, lo OMG (Object Managment Group) decise di lavorare alla standardizzazione di tutta una serie di profili, tra i quali molto importanti sono quello CORBA e quello EJB per il quale, ovviamente, è stato richiesta la collaborazione con la Sun Microsytem.

Si tratta di un passo indietro? La risposta all’interrogazione retorica è ovviamente no. I meccanismi di estensione rimangono comunque strumenti molto validi, la cui efficacia, tra l’altro, è stata provata durante il lavoro di definizione degli stessi profili. Si tratta di un framework di base costituito da un numero di concetti relativamente contenuto, e quindi di “più facile comprensione”, utilizzabile per estendere efficacemente il linguaggio per gli usi più svariati secondo precise direttive. 
 
 
 

Definizione formale di profilo UML
Un profilo è uno stereotipo di un package contenente un insieme di elementi del modello opportunamente adattati ad uno specifico dominio o scopo. Tipicamente lo si ottiene estendendo il metamodello utilizzando adeguatamente i meccanismi di estensioni provvisti dallo UML (stereotipi, definizioni di tagged value, vincoli e icone). In tali casi si parla di profili “leggeri” (lightweight), in quanto ottenuti per mezzo dei meccanismi di estensione propri del linguaggio, in contrasto con quelli “pesanti” (heavyweight) ottenibili per mezzo dei meccanismi di estensione definiti dalle specifiche del MOF.

La definizione formale di un profilo, per essere consistente all’approccio utilizzato nel documento delle specifiche ufficiali, deve prevedere le seguenti sezioni:

1. insieme delle estensioni standard che definiscono il profilo stesso, ottenuto attraverso l’opportuna applicazione dei meccanismi di estensione dello UML al sottoinsieme di interesse del metamodello;
2. definizione della relativa semantica descritta attraverso il linguaggio naturale (americano ovviamente);
3. insieme delle regole ben formate (well-formed rules), ossia insieme di vincoli, espressi in linguaggio naturale e, qualora possibile per mezzo dell’OCL, appartenenti agli elementi introdotti con il profilo;
4. elementi comuni del modello (common model elements), ossia istanze predefinite di elementi del metamodello UML. La definizione di tali elementi può far uso delle estensioni standard definite nel profilo stesso secondo gli eventuali vincoli in esso presenti;
5. eventuali estensioni al MOF (Meta Object Facility). Questa sezione, qualora presente, determina la transazione del profilo dalla caratterizzazione “leggero” a quella “pesante”. Si ottiene definendo nuove meta-classi da incorporare nella definizione formale del MOF. Chiaramente, si tratta di estensioni delicate a cui ricorrere solo dopo aver appurato l’inadeguatezza dei meccanismi standard ai fini richiesti.

Con la versione 1.4, i profili, sono finalmente entrati a far parte integrante del linguaggio. Attualmente sono stati formalmente incorporati due esempi: il profilo per il software development processes (processi di sviluppo del software) e quello per il business modeling (modellazione dell’area business).
 
 
 

Concetti base del profilo EJB
La formulazione del profilo EJB è frutto della collaborazione tra Sun Microsystem e l’Object Management Group (Java Specification Request JSR-26, richiesta di specificazione Java). Il risultato consiste nella versione draft (UML profile for EJB), pubblicata nel Maggio 2001, frutto del lavoro di Jack Greenfield coadiuvato da un team formato dai tecnici: James Abbott, Loïc Julien, David Frankel, Scott Rich e molti altri.

Obiettivo del profilo è definire un mapping standard tra lo UML e l’architettura Enterprise JavaBeans (EJB) (1). 

NOTA Si ritiene che benché l’illustrazione dell’architettura EJB esuli completamente dagli obiettivi del presente testo e che sebbene si tratti di una tecnologia che, più o meno approfonditamente, sia conosciuta da tutti i tecnici appartenenti alla comunità object oriented, una brevissima descrizione dei concetti citati più frequentemente sia doverosa. L’architettura EJB è una tecnologia server-side basata su componenti per lo sviluppo e l’installazione di applicazioni business organizzate in componenti distribuiti. L’utilizzo di tale tecnologia permette di realizzare sistemi scalabili, transazionali, multi-strato, sicuri, e così via, senza avere l’incombenza di dover progettare e realizzare una complicata infrastruttura. Ciò rende possibile realizzare rapidamente sistemi distribuiti ad oggetti, con rischi notevolmente ridotti e con l’enorme vantaggio che il sistema prodotto, qualora le direttive fornite della Sun Microsystem siano rispettate, sia in grado di essere eseguito virtualmente su qualsiasi piattaforma che supporti le specifiche EJB (write once run anywhere).
Un Enterprise Java Bean è un componente software, operante nel lato server, che può essere distribuito in un ambiente multi-tier. Tipicamente risulta costituito da diversi oggetti, sebbene la struttura interna è “nascosta” all’oggetto client (altro EJB, Servlet, JSP, Applet, ecc.) per mezzo di opportuna interfaccia. Gli oggetti client non possono richiedere l’esecuzione dei metodi esposti direttamente all’EJB, bensì devono necessariamente passare attraverso un apposito oggetto (detto EJB Object, oggetto EJB). Tale oggetto, pertanto, per poter svolgere il proprio ruolo di mediatore, deve clonare tutti i metodi business che il componente EJB fornisce, i quali vengono dichiarati esplicitamente dal componente in un’apposita interfaccia denominata remote interface (interfaccia remota). L’oggetto cliente, per ovvi motivi, non può neanche istanziare direttamente gli Oggetti EJB (per esempio potrebbero risiedere in un server diverso da quello in cui è in esecuzione il client), pertanto necessita di acquisirli. Ciò avviene richiedendo la loro “fornitura” ad un altro oggetto detto Home Object che funge da “factory” di EJB Object. A dir il vero è gravato da altre responsabilità oltre la creazione, come la ricerca, la rimozione ecc. degli EJB Object. A questo punto entra in gioco un’altra interfaccia detta Home interface (interfaccia casa), nella quale devono essere dichiarati i metodi per creare, reperire e distruggere gli oggetti EJB. Il tutto poi è soggetto alla gestione del famoso EJB container (contenitore EJB) il quale fornisce i servizi impliciti ai vari componenti EJB, in altre parole fornisce l’ambiente nel quale i componenti EJB vengono eseguiti. Il container a sua volta dovrebbe funzionare nell’ambiente fornito da un apposito EJB server. Tipicamente gli oggetti client dialogano sempre con il container, il quale interagisce con i vari EJB attraverso opportuni metodi dichiarati nelle interfacce di cui sopra. Si tratta di un vero e proprio mediatore “invisibile”, che assolve alle responsabilità di far comunicare i client con gli EJB, coordinare l’esecuzione delle transazioni, provvedere i servizi di persistenza, gestire il ciclo di vita degli EJB, ed altri compiti ancora.
Una volta generate le varie classi che realizzano l’Enterprise Java Bean, le home e le remote interface, il descrittore di dispiegamento e le proprietà dell’EJB stesso, è necessario impacchettare tutti questi file in un’unica entità denominata Ejb-jar file compresso secondo le direttive del formato .ZIP. 
 
 

La definizione del profilo EJB, è composto essenzialmente da due parti: il profilo UML vero e proprio e il descrittore UML. Come lecito attendersi, la prima si occupa della semantica utilizzabile dall’architettura EJB, mentre la seconda introduce un modello UML relativo ai manufatti Java ed EJB che si possono essere memorizzati in un file EJB-JAR. 
In merito alla prima parte è necessario dar luogo ad una breve considerazione. Dalla lettura dei precedenti articoli dedicati allo UML, si è appreso che uno degli obiettivi consiste nel supportare specifiche che risultino indipendenti da particolari linguaggi di programmazione o processi di sviluppo. Ciò chiaramente è molto vantaggioso in quanto rende lo UML idoneo a supportare plausibilmente tutti i linguaggi di programmazione. Però, al tempo stesso, pone qualche problema, in quanto l’architettura EJB non è stata basata su un linguaggio di programmazione generale, bensì su uno ben preciso: Java. Ciò finisce per causare un primo ostacolo tra la definizione dello UML e il relativo utilizzo nel contesto EJB. In altre parole, la definizione del profilo EJB obbliga a definire, come requisito propedeutico, il mapping tra UML ed i costrutti e package del linguaggio Java utilizzati nell’architettura EJB. 

Come mostrato nella figura seguente, il profilo EJB è costituito da due componenti, il modello di disegno e quello di implementazione. 
Per quanto riguarda il primo (modello di disegno EJB) contiene i diagrammi delle classi che descrivono le interfacce e eventualmente le classi di implementazione di un Enterprise Java Bean. Al fine sia di incoraggiare l’anticipo della suddivisione del sistema in componenti già durante le prime fasi del ciclo di vita del software, sia di assecondare la netta separazione tra la specifica di un componente EJB e la relativa implementazione, il modello di disegno è suddiviso in due viste: esterna ed interna. La prima consente di specificare un EJB dall’esterno ossia dal punto di vista del cliente. A tal fine è importante la definizione delle interfacce home e remote istanze dell’apposito stereotipo dell’elemento Class (EJB Home Interface e EJB Remote Interface). 

NOTA: In questo contesto, quando si parla di stereotipo di un elemento UML, si fa riferimento alla relativa meta-classe appartenente al sotto package Core del package Foundation del MOF.

Nella vista interna, l’attenzione viene spostata alla definizione interna dell’EJB o, se si vuole, alla prospettiva dello sviluppatore. L’EJB viene modellato per mezzo di un opportuno stereotipo dell’elemento UML Subsystem contenente sia le interfacce del punto precedente, sia ulteriori stereotipizzazioni dell’elemento Class atte a descrivere l’implementazione dell’EJB.
Il modello di implementazione EJB (EJB Implementation Model) contiene diagrammi dei componenti atti a descrivere i manufatti fisici in cui sono memorizzati gli elementi logici di un EJB. In questo ambito viene utilizzato un apposito stereotipo dell’elemento component per rappresentare classi Java, file di risorse e EJB-JAR.
 

Riassumendo brevemente, un Enterprise Java Bean viene modellato:

• logicamente o come uno stereotipo dell’elemento Class (nella vista esterna) o dell’elemento Subsystem (nella vista interna); 
• fisicamente come uno stereotipo dell’elemento Component.

Conclusioni
Nel presente capitolo si è avviata la descrizione del profilo UML dedicato all’architettura Enterprise Java Beans della Sun Micorsystem, ripresa ed approfondita nell’articolo successivo.
Si tratta di un mapping standard tra lo UML e l’architettura Enterprise JavaBeans (EJB), la cui definizione offre tutta una serie di vantaggi, come la definizione di un approccio standard da utilizzarsi per la modellazione di sistemi sfruttanti l’architettura EJB e quindi basati sul linguaggio di programmazione java, il supporto alle esigenze pratiche comunemente incontrate nel disegno di sistemi EJB-based, la semplificazione del disegno di sistemi basati sull’architettura EJB, in modo tale che gli “sviluppatori”, da un lato non siano costretti a definire per conto proprio tecniche per la modellazione di sistemi EJB e dall’altro possano confidare in tecniche di riverse engineering compatibili con quanto disegnato, e così via.
La definizione del profilo fornisce spunti interessanti anche per la risoluzione, limitatamente all’ambito dell’utilizzo dell’archiettura EJB, di problemi storici sia relativi allo stesso UML, ossia la definizione eccessivamente limitata del concetto di componente, e sia inerenti i processi di sviluppo formali, quali per esempio il RUP, legati alla tardiva introduzione del concetto di componente, tipicamente relegato ai diagrammi di dispiegamento. In particolare, grazie alla vista esterna, parte del modello di disegno, che permette di specificare un EJB dall’esterno, attraverso le relative interfacce, è possibile avviare la suddivisione del sistema in componenti, allocando le varie responsabilità, già nelle prime fasi del ciclo di vita del software. Infatti, inizialmente è sufficiente progettare il comportamento del componente, mentre per la relativa progettazione interna è possibile attendere le fasi successive.
Chiaramente ci sono anche dei contro, come si vedrà nel prossimo numero, probabilmente uno dei più seri è legato al numero di manufatti (artifact) che è necessario realizzare per descrivere ciascun componente EJB. Un altro grande svantaggio è che si limita l’esercizio di fantasia di molti tecnici prodigi nella definizione di nuovi standard del linguaggio UML.
 
 
 

Bibliografia
 “UML dalla teoria alla pratica” - di Luca Vetti Tagliati;
 “Mastering Enterprise Java Beans” – di Ed Roman, pubblicato dalla casa editrice Wiley;
 “UML profile for EJB” – di Jack Greenfield;
 “The Unified Modeling Language User Guide” – di Grady Booch, James Rumbaugh, Ivar Jacobson, pubblicato dalla casa editrice Addison Wesley;
 “The Unified Modeling Language Reference Manual” – di Grady Booch, James Rumbaugh, Ivar Jacobson, pubblicato dalla casa editrice Addison Wesley;
 

Biografia
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.datacard.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’ reperibile all’indirizzo LVetti@mokabyte.it.