Un'implementazione di RUP con EJB...in attesa di UML 2.0

Abstract
Sovente la definizione del processo è influenzata dalla tecnologia sottostante, tanti i costruttiUML/RUP proposti, tante le esperienze altrui (Pattern) quali scegliere? Ecco un approccio efficace....

Lo UML è il potente linguaggio standardizzato dall'OMG (Object Management Group ) per specificare, visualizzare, costruire e documentare sistemi Software. L'OMG ha dichiarato che la nuova versione di UML, la 2.0, dovrebbe essere disponibile entro il prossimo Dicembre.
L'architettura EJB è una tecnologia server-side basata su componenti per lo sviluppo e l'installazione di applicazioni che impiegano componenti distribuiti. Tale tecnologia permette di realizzare sistemi scalabili, transazionali, sicuri con una progettazione e realizzazione dell'infrastruttura demandata all'Application Server. RUP (Rational Unified Process) è un Framework di processo da adattare alle diverse tipologie di progetto. Risponde agli obiettivi primari di Time-to-market, controllo dei rischi e visibilità dello stato di avanzamento dei lavori.
Questo articolo si rivolge principalmente ad analisti e progettisti, propone solo una configurazione del RUP che evidenzia le attività e gli elaborati da produrre proprio in fase di analisi e progettazione.
Nel contempo si vuole fornire al Designer una overview dell'estensione del metamodello (EJB Profile) proposto dall'OMG per modellare i componenti della tecnologia EJB. Quando si usa l'UML, per la modellazione, molto spesso ci si chiede quali diagrammi usare per rappresentare il sistema. La scelta di una corretta metodologia è cruciale per il buon esito del progetto.
Col nascere della tecnologia EJB i progettisti hanno usato notevolmente le estensioni dell'UML: constraints (vincoli), tagged values (valori etichettati), stereotypes (stereotipi).
Ma l'uso pesante di tali estensioni ha portato alla nascita di una serie di dialetti UML che, oltre a mettere a rischio la comunicabilità tra i Designer ha portato a delle difficoltà nel forward/reverse engineering dei Tool a disposizione, addirittura invalidando a volte il lavoro di modellazione.
Per sopperire a ciò l'OMG ha deciso di lavorare alla standardizzazione di una serie di profili, i più importanti dei quali sono quello di CORBA e quello degli EJB. Per quest'ultimo ovviamente è stata stretta la collaborazione con SUN Microsystems.
Una versione draft di `UML for EJB' è stata pubblicata nel Dicembre del 2001 (http://cgi.omg.org/docs/ptc/01-12-04.pdf). Un Profilo rappresenta un Framework costituito da una serie di concetti, utilizzati per estendere efficacemente il linguaggio adattandolo alla tecnologia che il profilo vuole rappresentare. Nella realizzazione di ogni profilo si fa uso dei meccanismi di estensione, e ancora una volta si dimostra l'efficacia di quest'ultimi.
Vediamo quindi come procedere nelle varie fasi.

Requisiti e Analisi

Vengono modellate le caratteristiche del sistema:

• Il primo passo consiste nella definizione di cosa il sistema deve fare. Questo viene rappresentato mediante il diagramma degli Use Cases, un eventuale documento descrittivo associato ad essi e con delle pagine HTML che oltre a rappresentare un prototipo dell'interfaccia modellano, mediante dei Link tra esse, la dinamicità del sistema.
• Altri due documenti possono essere associati in questa prima fase: il Glossario che definisce i termini importanti del sistema, e il Supplementary Specification Requirements contenente i requisiti cosidetti non funzionali: Usability, Rialibility, Performance e Supportability (URPS).
• Diagramma delle classi: vengono individuate le classi di dominio; le classi vengono etichettate con gli stereotipi Entity (rappresentano le classi di persistenza del sistema), Control (coordinano il Business dello Use Case che rappresentano) e Boundary (la classe con la quale gli attori del sistema interagiscono). L'analista generalmente associa ad ogni Use Case una classe Control, individua delle classi generiche Boundary e modella con più dettaglio le classi Entity.
• Diagramma di Sequenza : per gli Use Cases ritenuti critici e rilevanti viene mostrato almeno lo scenario la cui sequenza delle interazioni va a buon fine ( Happy End).

Progettazione

Viene modellato come il sistema deve essere realizzato. In questa fase è necessario tener conto della tecnologia che si sta adottando (EJB).

• Grafica: nella rappresentazione grafica il Designer tiene conto degli stereotipi, Tagged Values e Constraints del modello di disegno dell'EJB, Profile dell'UML. Il Profilo EJB è costituito da due componenti: il modello di disegno e il modello di implementazione. Il modello di disegno mostra gli stereotipi relativi alle interfacce degli EJB (EJBRemoteInterface, EJBSessionHomeInterface, EJBEntityHomeInterface) e gli stereotipi relativi ai metodi (EJBCreateMethod, EJBFinderMethod, EJBRemoteMethod). Sono previsti molti Tagged Values. Per esempio, EJBTransAttribute definisce la politica per la gestione delle transazioni (Supports, Required, Never...). Il modello comprende anche i Constraints. Il modello di implementazione (poco usato!) contiene i diagrammi dei componenti.
• Uso del Pattern MVC (Model View Controller): vengono individuati gli oggetti View (modellati generalmente mediante pagine JSP che rappresentano le classi Boundary), hanno a che fare con la presentazione, gli oggetti Controller (modellati come descritto nei due punti seguenti con Session Bean) che coordinano, validano le richieste utenti provenienti mediante la view, e gli oggetti Model (modellati con Entity) che rappresentano i dati dell'applicazione e le regole che governano la modifica e la selezione di tali dati.
• Session Bean: il progettista individua le classi Control, nel mondo degli EJB; le classi Control associate agli Use Cases sono implementate come Session Bean. Il Session Bean può essere Stateless o Stateful. Viene considerato il sistema nel suo complesso e generalmente il numero di classi Control individuate in analisi e quindi di Session Bean da modellare viene ridotto di numero; non si ha più quindi il mapping uno-a-uno tra Use Case e Session Bean.
• Uso del Pattern Session Facade : al fine di ridurre l'accoppiamento tra Client e Business Objects e quindi diminuire le interazioni remote tra Client, e Business Objects migliorando così la Performance di rete, un EJB di tipo Session (Session Facade) si espone al Client con un'interfaccia unificata, fungendo da coordinatore/delegatore per una serie di componenti di Business. Più Use Cases correlati hanno associato uno stesso Session Facade.
• Operazioni: ogni Session Bean implementa le operazioni di Business già rappresentate in analisi; la responsabilità assegnata al Controller in analisi si modella con una o più operazioni in Design.
• Entity Bean: vengono individuate in maniera esaustiva le classi di persistenza.

L'aumento della complessità dei sistemi da modellare, il cambiamento dei requisiti nel tempo, l'affermarsi di nuove tecnologie, l'integrazione tra componenti di tecnologie differenti ha fatto sentire sempre più l'esigenza di definire un processo di costruzione del Software e l'adozione di uno standard per la comunicabilità tra team e Tool differenti. Imparare dal successo degli altri! L'uso di Pattern, valutare i pro e i contro, consente di creare modelli adattabili alle modifiche e all'introduzione di requisiti. Alcuni Pattern possono persino diventare parte integrante del processo. L'UML 2.0 si prepara, tra le diverse novità, anche a definire lo standard per la modellazione secondo il profilo.

Informazioni sull'autore

Santina Antinoro, si è laureata in Scienze dell'Informazione, ha conseguito il Master in Telecomunicazione al Politecnico di Torino. Attualmente ha il ruolo di Senior Consultant presso ObjectWay, svolge attività di consulenza presso clienti e fa parte del team di formazione nei diversi ambiti dell'Analisi e Progettazione: UML, J2EE, .NET. C++, XML, Database.

È possibile consultare l'elenco degli articoli scritti da Santina Antinoro.

Altri articoli sul tema Design / UML.