In ogni modo, l’organizzazione del VMM relativo al profilo EJB si presta ad essere rappresentato dalla figura seguente:

Esempio del mapping UML – Java: l’elemento Class
Tra i primissimi elementi definiti nel profilo, necessari nella vista esterna del modello di disegno, compaiono le interfacce EJB corredate dai relativi metodi. La definizione di tali elementi però non sempre può avvenire direttamente; spesso è necessario specificare formalmente gli elementi del linguaggio Java da cui derivano. Pertanto, come già riportato precedentemente, nella definizione formale del profilo EJB è indispensabile specificare tutte, e sole, le parti del linguaggio Java utilizzate dall’architettura EJB.
Per esempio è necessario definire formalmente la corrispondenza tra il concetto di classe nel linguaggio Java e quello dello UML. A tal fine la sintassi del costrutto Class di Java può essere descritta rigorosamente come segue:

Chiaramente una classe Java corrisponde all’equivalente concetto dello UML, però è necessario dar luogo a tutta una serie di mapping, quali:
· la visibilità del linguaggio Java corrisponde all’ElementOwnership presente nel Core Package dello UML. In Java quando la visibilità è omessa si intende a livello di package mentre, con la versione 1.4, in UML viene rappresentata attraverso il carattere tilde (~);

• per ciò che concerne i modificatori, si hanno le seguenti corrispondenze:
• abstarct corrisponde alla proprietà isAbstarct dello UML (GeneralizableElement);
• static viene introdotto per mezzo del tagged value booleano JavaStatic;
• final corrisponde alla proprietà isLeaf dello UML (GeneralizableElement);
• strictfp viene introdotto per mezzo del tagged value booleano JavaStrictfp;
• Identifier corrisponde ai nomi delle classi UML;
• ClassType si collega ai nomi degli elementi specializzati dall’UML;
• InterfaceType come il punto precedente;
• ClassMember corrisponde alla definizione di classe java;
• InterfaceMember è relativo alla definizione di interfaccia java (definita nel profilo);
• FieldMember corrisponde all’elemento Java Field (definito nel profilo);
• MethodMember è associato all’elemento Java Method  (definito nel profilo).

Analisi del profilo
Si cominci ad esaminare gli stereotipi definiti ritenuti più interessanti. L’ordine di presentazione prevede l’analisi degli elementi del modello di disegno, a partire dalla vista esterna per poi passare a quella interna, e quindi quelli appartenenti al modello di implementazione.

Nel package java::lang(1) è presente lo stereotipo di interfaccia java («JavaInterface»), che specializza quello denominato «type»(2): stereotipo predefinito dell’elemento classe.
Da tener presente che mentre in Java i nomi completamente specificati (fully-qualified) dei package si ottengono separando il nome dei package genitori da quello dei figli per mezzo di un carattere punto (per esempio java.lang), nello UML il separatore è dato dalla ripetizione del carattere due punti (java::ejb). 
 

1. Nella presente trattazione, l’organizzazione dei package a cui si fa riferimento, a meno di diverse indicazioni, è quella del profilo EJB e non del linguaggio di programmazione Java. Ciò dovrebbe essere evidente anche dall’utilizzo dei due punti come separatore (standard UML).
2. Si tratta di uno stereotipo che specifica un dominio di oggetti corredati dalle operazioni ad essi applicabili, senza però definire l’implementazione fisica degli stessi oggetti. In particolare può essere considerato come una particolare versione della classica interfaccia in grado di contenere attributi ed associazioni. Obiettivo di queste associazioni consiste nel poter definire il comportamento dei tipi di operazioni senza definire l’implementazione dei dati coinvolti.

 

 
 
 
 

La definizione formale dei metodi delle interfacce EJB è ottenuta attraverso i seguenti stereotipi della metaclasse Operation appartenenti al package javax::ejb: «EJBCreateMethod», «EJBFinderMethod», «EJBRemoteMethod». L’essere stereotipi della metaclasse Operation indica che tali elementi possono essere utilizzati per enfatizzare metodi con particolare significato per gli EJB, rispettivamente metodi di creazione, reperimento e remoti.
Per quanto concerne le interfacce, sono definite la «EJBRemoteInterface», «EJBHomeInterface», «EJBSessionHomeInterface» e «EJBEnityHomeInterface» (3).
 
 

3. Non è presente una definizione di home interface per i message driven bean, non solo per questioni di aggiornamento del profilo, ma anche perché tali EJB non dispongono di questa tipologia di interfaccia, così come non dispongono di remote interface. Ciò è dovuto al fatto che i message driver bean non possono essere invocati utilizzando un metodo remoto. Essi sono stati introdotti per processare messaggi asincroni e quindi la relativa invocazione deve avvenire da parte di un messaging client basato sull’architettura Java Messaging System.

Figura 2 -  Interfacce EJB definite nel package javax::ejb (external view)
La metaclasse “Class” appartiene al package “Core”, sotto package del “Foundation”, del metamodello UML. “type” è uno stereotipo standard. EJBHomeInterface è una meta classe astratta. 

Per terminare l’elenco degli stereotipi dell’extenal view, va menzionato «EJBPrimaryKey», specializzazione di Usage, stereotipo della relazione di dipendenza. Quest’ultimo viene utilizzato per indicare che un elemento necessita di un altro per la completa implementazione o operazione. Nella versione EJB, indica che il fornitore della relazione Usage (elemento da cui parte la relazione) è una classe EJB Primary Key necessaria per reperire EJB Entity Bean. 

Nella vista interna sono presenti molteplici stereotipi, il che è abbastanza naturale considerando che il relativo scopo consiste nel descrivere il dettaglio della struttura interna degli EJB. 
I primi che si incontrano sono gli stereotipi della metaclasse Attributo (Attribute), ed in particolare la versione “base” «EJBCompField» il quale evidenzia che il relativo attributo rappresenta un campo gestito dal container (container-managed field) di un EJB Entity Bean in un contesto di persistenza gestita dal container. Di questo stereotipo è prevista un’ulteriore estensione rappresentata da «EJBPrimaryKeyField» con significato piuttosto evidente: indica che il campo è una chiave primaria di un EJB Entity Bean nell’ambito di persistenza gestita dal container.
Altri due stereotipi molti interessanti sono quelli etichettati con i nomi: «EJBRealizeHome», «EJBRealizeRemote», si tratta di estensioni della specializzazione della relazione di dipendenza denominata Abstraction (Astrazione). Questa relazione è utilizzata per associare elementi rappresentanti lo stesso concetto a diversi livelli di astrazione. Nell’ambito del profilo EJB la relazione è utilizzata per indicare il legame tra interfacce (per esempio EJB Home Interface) e relative implementazioni (EJB Implementation Class). Quest’ultimo, «EJBImplementation», rappresenta a sua volta uno stereotipo, in questo caso dell’elemento Class, utilizzato per indicare che la classe realizza un’opportuna interfaccia EJB. 
Altri stereotipi molto importanti per l’internal view sono quelli relativi all’elemento Subsystem. In particolare sono presenti i seguenti stereotipi «EJBEnterpriseBean», «EJBSessionBean» e «EJBEntityBean», come mostrato nella figura seguente.
 
 

Per terminare l’esame degli stereotipi utilizzati nell’internal view, si considerino gli elementi «EJBReference», specializzazione dello stereotipo Usage e «EJBAccess», stereotipo della metaclasse associazione (Association). Per quanto riguarda il primo non c’è molto da aggiungere, mentre il secondo definisce un ruolo di sicurezza tra un attore UML e un EJB.

Terminata l’analisi degli stereotipi del modello di disegno si passa ad esaminare quelli legati al modello di implementazione.
Il primo che si incontra è «JavaClassFile» (package java::lang) che specializza lo stereotipo predefinito «file», utilizzato per indicare che un component è un Java Class File.
Un altro stereotipo, questa volta appartenente al package java::util::jar, è «JavaArchiveFile» che serve per indicare che un package rappresenta un JAR.
Ancora, nel package javax::ejb è presente lo stereotipo «EJB-JAR» che specializza «JavaArchiveFile», con significato piuttosto intuitivo. Sempre nello stesso package è presente lo stereotipo «EJBDescriptor», atto ad indicare che un determinato componente rappresenta appunto un EJB Deployment Descriptor. Infine è presente la specializzazione della relazione Usage, denominata «EJBClientJAR» utilizzato per indicare che il “cliente” della relazione rappresenta una ejb-client-jar per il “EJB-JAR” rappresentato dal fornitore della relazione.

Terminata l’analisi degli stereotipi, è necessario analizzare i vari tagged value. Una descrizione esaustiva nel contesto del presente paragrafo aggiungerebbe ulteriore tedio non sempre giustificato considerando che molti possiedono un significato piuttosto intuitivo. Pertanto nella sezione seguente l’attenzione viene focalizzata esclusivamente sui tagged value ritenuti più interessanti e/o ricorrenti.
Per esempio nel package java::lang sono definiti i valori etichettati JavaNative e JavaThrows, entrambi applicabili agli stereotipi della metaclasse Operation. Il primo è di tipo booleano e serve ad indicare se un metodo è, o meno, nativo java, mentre il secondo è un array di stringhe atto a riportare la lista dei nomi delle eccezioni, separate dal carattere virgola (comma-delimited), scatenabili da un metodo. Un altro esempio di tagged value, definito sempre nello stesso package, è JavaFinal il quale con il suo valore booleano è utilizzo per indicare se un parametro è modificabile (false) o meno.
Da tener presente che, ogniqualvolta compare un tagged value di tipo booleano, la convenzione sancisce che la relativa presenza implica un valore true (riportare JavaFinal = true o semplicemente JavaFinal è completamente equivalente), mentre l’omissione indica un valore false.
Nell’analisi della vista esterna del modello di disegno EJB sono stati introdotti alcuni tagged value, come per esempio:

• EJBSessionType di tipo enumerato, associato allo stereotipo «EJBSessionHomeInterface», il quale indica la tipologia dell relativo session bean: stateful o stateless;
• EJBNameInJar, il quale indica il nome utilizzato dell’EJB quando viene impacchettato nel file EJB-JAR. Tipicamente si utilizza il nome dell’EJB Remote Interface;
• EJBEnvEntries, associato a qualsiasi EJB, ne indica, attraverso una lista di tuple (nome, tipo, valore) separate da virgola, le environment entries;
• EJBResources, in maniera del tutto simile al tagged value precedente, indica le resource factory dell’EJB;
• EJBReferences, associato a qualsiasi EJB, ne specifica, attraverso una lista di tuple (nome, tipo, home, remote) separate da virgola, gli altri EJB referenziati;
• EJBSecurityRoles, associato a qualsiasi EJB, ne indica, attraverso una lista di tuple (nome, link) separate da virgola, il nome del ruolo di sicurezza in grado di invocare i metodi;
• EJBTransType, dichiara se la gestione delle transazioni di un Session Bean è demandata al Container oppure è eseguita direttamente dal Bean;
• EJBPersistenceType, si tratta di un tipo enumerato assolutamente analogo al precedente con la unica differenza che si applica agli Entity Bean e non ai Session;

Un altro tagged value molto interessante è quello denominato EJBTransAttribute, applicabile ai metodi. Esso sancisce la policy utilizzata per la gestione delle transazioni. In particolare i valori previsti dal tipo enumerato sono: NotSupported, Supports, Required, RequiredNew, Manadatory e Never. 
 

Esempio
A questo punto è finalmente giunta l’ora di riassumere i concetti esposti fin qui in chiave operativa attraverso il ricorso ai tanto amati esempi.
Il sistema preso in considerazione è quello di un’ipotetica banca. Più precisamente si tratta del modello IBM ITSO Bank, riportato nel profilo EJB, utilizzato spesso anche dalla stessa IBM (i famosi red book) per illustrare ambienti run-time IBM e vari tool.
Il primo modello considerato è relativo alla design view. Si inizia col focalizzare l’attenzione sulla vista esterna ed in particolare su un primo componente dedicato alla sessione utente. Come è lecito attendere si tratta di un enterprise session bean, del quale appunto ne viene fornita la vista esterna, quella a cui sono interessati gli oggetti “cliente”.
 

Come si può ben notare, l’attenzione viene focalizzata esclusivamente sulla definizione delle interfacce, a tal fine sono utilizzati gli stereotipi «EJBRemoteInterface» e «EJBSessionHomeInterface». Per ciò che concerne i metodi, gli stereotipi utilizzati sono: «EJBRemoteMethod» e «EJBCreateMethod».

Nel secondo esempio viene presentata la external view di un enterprise entity bean atto a memorizzare i dati dei clienti della banca.

A differenza del caso precedente, lo stereotipo utilizzato per la Home Interface è la specializzazione «EJBEnityHomeInterface» proprio per indicare che si tratta di un Enterprise Entity Java Bean. Sono poi presenti gli stereotipi «EJBFinderMethod» e «EJBCreateMethod» al fine di enfatizzare la natura dei relativi metodi. Infine è presente lo stereotipo «EJBPrimaryKey» della relazione di dipendenza, per mostrare che l’oggetto CustomerKey fornisce appunto la chiave primaria per il reperimento dei entity bean relativi ai clienti (Customer).

A questo punto si passa all’internal view. Da questo punto in poi viene preso in considerazione esclusivamente l’entity bean mostrato nella figura precedente.
Come già illustrato precedentemente, sebbene possa sembrare piuttosto singolare, la vista interna degli EJB viene modellata utilizzando l’elemento Subsystem(1) anziché Component. Si tratta di un elemento dello UML di utilizzo non frequente, e pertanto non molto conosciuto dai disegnatori. Verosimilmente questa scelta è dovuta alla definizione limitata di componente presente nella versione 1.3 dello UML. Già con la versione 1.4 le cose sono cambiate parecchio, quindi, alla luce delle nuove release dello UML, probabilmente il profilo EJB subirà importanti aggiornamenti.
Come si può notare dal diagramma di figura seguente, l’elemento Subsystem si presta ad essere utilizzato per descrivere i componenti EJB, in quanto dotato di una sezione relativa alle specifiche (specification elements) ed una efferente la realizzazione (realization elements). Il problema è che, al momento in cui viene scritto questo testo, non tutti i tool commerciali permettono di rappresentare sottosistemi secondo le direttive UML.
 

(1) Le metaclasse Subsystem, insieme a Model e Package (genitore dei primi due) rappresentano gli elementi di maggiore interesse del package Model Management, legato con relazione di dipendenza al Foundation, del metamodello UML. In prima analisi, tali elementi sono utilizzati per raggruppare unità, in qualche modo relazionate, necessarie ad altri ModelElements (elementi del modello). In particolare ci si avvale dell’elemento Model per rappresentare diverse viste di uno stesso sistema. L’elemento Package è utilizzato, in modo del tutto atteso, nel contesto di un modello per raggruppare elementi di modellazione. Infine Subsystem permette di rappresentare ben definite unità comportamentali di un sistema.
Come accennato poc’anzi, la metaclasse Subsystem specializza quella Package. Mentre quest’ultima rappresenta un meccanismo generico per organizzare gli elementi del modello, un subsystem tratteggia un’unità comportamentale di un sistema nel modello. L’elemento Subsystem però non eredita unicamente da Package, ma anche da Classifier. Ciò gli permette di offrire interfacce, operazioni, ecc. Il suo contenuto è partizionato in due sezioni: elementi di specificazione e di realizzazione. Nella prima trovano posto le operazioni nel sottosistema, così come use case, state machines, ecc. ossia tutti elementi che permettono di fornire elementi di specifica.
Tipicamente un sottosistema viene rappresentato utilizzando la stessa notazione dell’elemento package con in più il simbolo di fork. Chiaramente, nulla vieta di rappresentarlo come un package con lo stereotipo «subsystem».

Lo stereotipo «EJBReference», specializzazione di Usage, specializzazione della relazione di dipendenza, evidenzia la necessità di un EJB di accedere ad un altro durante la propria esecuzione. Per esempio la figura seguente mostra che l’entity EJB Customer necessita di accedere all’EJB BankAccount.
 

A questo punto è giunto il momento di rappresentare l’implementazione interna dell’entity bean. 
L’elemento introdotto nel diagramma di figura è lo stereotipo «EJBCmpField» nella sezione degli attributi della classe CustomerBean la cui descrizione è stata riportata precedentemente.
 

Per concludere l’illustrazione dell’utilizzo dei vari stereotipi presentati nella prima parte, è necessario passare al modello di implementazione. Il primo stereotipo utilizzato è «EJB-JAR», specializzazione «JavaArchiveFile», stereotipo dell’elemento Package, all’interno del quale vengono raggruppati tutti file contenenti le classi Java con in più l’aggiunta del descrittore dell’EJB (deployment descriptor). Il tutto viene esemplificato nella figura seguente.
Figura 9. Implementation view dell’entity bean Customer. (Per questioni di rendering grafico non tutti gli elementi sono stati specificati).
L’unico elemento di novità è rappresentato dal package denominato “META-INF”. Ciò è coerente con le direttive JAR File Specification contenute nella Java 2 Platform Standard Edition.
 
 
 

Conclusioni
Da questa breve trattazione, emerge che sebbene il profilo EJB sia ancora in uno stadio piuttosto evolutivo - è necessario un processo di adeguamento sia per incorporare le direttive della versione 1.4 dello UML, sia per allinearlo alla versione 2 dell’architettura EJB - si tratta complessivamente di un ottimo strumento per il supporto alla progettazione di sistemi component based utilizzanti l’architettura EJB.
Il profilo non solo risolve il problema della rappresentazione dei manufatti (artifact) previsti dall’architettura EJB, bensì fornisce anche direttive su come affrontare il processo di sviluppo di sistemi component-based. A tal fine il profilo si adegua ai processi di sviluppo dei sistemi software, organizzando i vari manufatti previsti dalle diverse fasi, in opportuni modelli; in particolare sono previsti i modelli di disegno ed implementazione.
Il profilo è focalizzato essenzialmente sulla fase di disegno e non su quelle di specifica. Il motivo è piuttosto ovvio: queste ultime devono essere generiche e non fondate su specifiche architetture come l’EJB, chiaramente devono assumere che il sistema verrà sviluppato secondo un particolare paradigma, ma non entrare assolutamente nei relativi dettagli tecnici. Lo stesso discorso non può essere applicato al modello di disegno che, per gioco-forza, deve essere realizzato in base alle direttive fornite dalla particolare architettura selezionata.
Alquanto apprezzata è anche la suddivisione del modello di disegno nelle due viste esterna ed interna. Ciò risulta molto utile nel contesto di processi di sviluppo del software iterativi ed incrementali: nelle prime iterazioni della fase di elaborazione è possibile concentrarsi sulla definizione del comportamento dei vari componenti e sulle relazioni con gli altri, rimandando a successive iterazioni i dettagli interni.
La definizione formale di tale profilo permette di mantenere standard l’utilizzo dello UML anche per specifiche tecnologie quali l’architettura EJB. Ciò è molto importante non solo in chiave comunicativa (possibilità di far circolare più agevolmente i vari modelli, semplificazione del processo di inserimento di nuove risorse, ecc.) ma anche come direttiva per le aziende fornitrici dei vari tool (interscambio di modelli tra diversi tool, garanzia che il riverse engineering sia consistente con il normale processo, forward engineering, ecc.).
Qualche perplessità permane per ciò che concerne il numero ed il dettaglio di vari manufatti. Sebbene funzioni di reverse engineering potranno fornire un notevole contributo nello snellire il lavoro a carico dei vari “modellatori”, la rappresentazione di tutti gli elementi previsti potrebbe risultare gravosa. Con ciò non si vuole assolumentamente istigare tecnici a liquidare prematuramente la fase di disegno per dedicarsi alla codifica, bensì alcuni dettagli di minore importanza possono essere non completamente definiti in fase di disegno per poi essere incorporati in u secondo momento.
Un’altra constatazione è che la stessa definizione del profilo è, se c’è ne fosse ancora bisogno, l’ennesima dimostrazione dell’efficacia, eleganza e flessibilità del metamodello UML. In effetti è stato possibile specializzarlo, dando luogo al famoso VMM, senza aver avvertito l’esigenza di modificare l’architettura di base.
Il profilo EJB rappresenta indubbiamente un primo passo nella direzione della definizione di standard di notevole importanza nella progettazione di sistemi EJB-based.
 
 
 

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.
 

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.