MokaByte 102 - Dicembre 2005
 
MokaByte 102 - Dicembre 2005 Prima pagina Cerca Home Page

 

 

 

Skill differenti per applicazioni J2EE di successo
La sfida del teamworking

Esperti di User Interface ed esperti di Business Logic in un progetto J2EE. Come promuovere la massima cooperazione? La risposta ci viene dagli UML Subsystems

Introduzione
Se vogliamo essere sicuri di costruire una casa a regola d'arte, dobbiamo partire da un ottimo progetto, ma anche avere la garanzia che le maestranze al lavoro (muratori, falegnami, idraulici, elettricisti, piastrellisti, parquettisti) siano al tempo stesso esperti dell'arte che esercitano e che sappiano mettere in opera manufatti in grado di costituire un insieme integrato. Nessuna cucina potrà mai essere montata come si deve se mancano i collegamenti dell'acqua e del gas o se gli attacchi per l'elettricità non sono stati predisposti correttamente. Non basta quindi un team formato da specialisti esperti in una determinata disciplina, occorre anche che ciascuno sia in condizioni di utilizzare quegli elementi del lavoro degli altri necessari e rilevanti allo svolgimento del proprio compito. In questo modo avremo la garanzia di un progetto complessivo eseguito da specialisti e in cui le singole parti cooperano alla perfezione. Tutto questo discorso può essere fatto anche per applicazioni J2EE?

 

Segmentare un progetto
Una applicazione J2EE può essere vista come un edificio di una certa complessità, in cui i singoli "layer" (Web tier, Business tier, Integration tier, EIS tier), progettati e sviluppati secondo regole e tecnologie differenti (JSP, Servlet, EJB), debbono comunque essere inseriti in un contesto integrato. In termini di team di lavoro, questo implica la necessità sia di poter disporre nel proprio gruppo di specialisti dotati di skill differenti (UML Designer, EJB Developer, Web Designer etc), sia di poter segmentare il progetto complessivo in sotto-progetti "aggredibili" in modo indipendente da ciascun team, salvo permettere a ciascuno di essi di "vedere" (e quindi utilizzare) quanto occorre dei sotto-progetti per così dire "limitrofi".

 


Figura 1
– Skill differenti su un progetto J2EE


Nella pratica corrente dello sviluppo di applicazioni J2EE, è abbastanza frequente assistere a una suddivisione del carico di lavoro in due gruppi principali, di cui uno dedicato al backend, tipicamente coinvolto in attività relative alla costruzione di componenti di business, implementazione di metodi, gestione delle problematiche di persistenza, e l'altro responsabile della GUI, concentrato cioè sul disegno e la prototipizzazione dell'interfaccia utente.

 

Suddivisione Orizzontale e Verticale
A tale scopo, occorrerebbe una metodologia di sviluppo che ci permettesse una suddivisione del nostro progetto in due distinte parti "User Interface" e "Backend". Tale tipo di approccio "orizzontale" si contrappone alla suddivisione "verticale" di un progetto complesso, vale a dire per aree funzionali (ad esempio Gestione Ordini, Magazzino, Fatturazione). Proprio su queste pagine ([1]) è stato a suo tempo presentato un tipo di approccio metodologico che permetteva di affrontare lo sviluppo di grandi applicazioni J2EE suddividendole in sottoprogetti ben delineati funzionalmente e accoppiati tra di loro in modo alquanto lasco: questo discorso aveva portato a presentare, a discutere e a mostrare l'impiego pratico di quella parte della notazione UML detta "Subsystems" ([2]). Si trattava, in quel caso, di una segmentazione orientata alle macrofunzionalità, cioè di tipo "verticale"….e allora il nostro interrogativo potrebbe essere: è possibile utilizzare gli UML Subsystems per suddividere un progetto anche in modo "orizzontale"?
La risposta potrebbe essere semplicemente "sì", ma allora l'articolo finirebbe qui…..perciò, come si dice in questi casi, parliamone!

 


Figura 2
– User Interface e Backend

 

Modellare l'Applicazione
Parlare di notazione UML significa sottintendere un approccio allo sviluppo della nostra applicazione J2EE basato sulla modellazione. Inoltre, data la complessità della realtà che dobbiamo affrontare, giova servirsi di UML nell'ambito della metodologia Model Driven Architecture (MDA nel seguito), così come indicato in [3] e [4]. Secondo l'approccio MDA, si costruisce un modello di business (Platform Independent Model o PIM), si deriva da esso un insieme di modelli applicativi (Platform Specific Model o PSM) e da essi il codice che costituisce l'applicazione globale (Code Model).


F
igura 3 – Model Driven Architecture

Per illustrare meglio quanto stiamo discutendo, possiamo servirci di un esempio utilizzando lo strumento Compuware OptimalJ ([5]), tool di sviluppo J2EE completamente aderente alla metodologia MDA.
Cominciamo quindi col creare un progetto ex-novo, che chiameremo "Backend", e che rappresenterà la parte "business" della nostra applicazione. Esso, in accordo alla metodologia MDA, conterrà un PIM, una serie di PSM e il puntamento a un insieme di directory destinate a ospitare il codice che verrà prodotto. In particolare, è la parte PSM che dovrà essere strutturata ad hoc, e cioè basata su un package "application", destinato a contenere i soli elementi di business logic. Un eventuale package "maintenance" potrà essere eventualmente predisposto al fine di ospitare del codice web di interfaccia per testare rapidamente la parte business, che resta comunque il focus principale di "Backend" (figura 4).

 


Figura 4 – Backend Project

La parte PIM di questa architettura ci permette ora di modellare con UML la nostra applicazione, definendo classi, attributi, associazioni ed eventuali vincoli.
Sempre secondo MDA, una volta che il nostro PIM sarà considerato sufficientemente "stabile", si deriveranno da esso i diversi PSM, che nel nostro caso sono principalmente costituiti dal package "application" (vedere sempre figura 4).

 

Utilizzo dei Subsystem
E' proprio a questo punto che il concetto di Subsystem inizia a fornire il suo grande contributo. Predisponiamo, allo stesso modo di quanto descritto in [1], la "pubblicazione" del nostro "Backend", che viene visto come Subsystem della applicazione J2EE complessiva
I successivi passi di generazione del codice, compilazione e deployment del progetto "Backend", avranno come risultato la creazione di un archivio EAR autonomo e "visibile" da altri Subsystem, ad esempio visibile da altri destinati, per fare un esempio "a caso", alla sola User Interface........

 

User Interface
In modo del tutto analogo a quanto fatto più sopra, creiamo adesso un nuovo progetto, che chiameremo "UserInterface", con una struttura iniziale PSM stavolta predisposta per la sola parte "presentation", destinata a contenere il lavoro del nostro team di grafici ed esperti di tecnologie Web (JSP, Servlet etc).

 


F
igura 5 – UserInterface Project

Se il progetto corrente "UserInterface" effettua ora il "mount" del Subsystem "Backend" appena creato (archivio EAR), il risultato è che "UserInterface" ha la possibilità di "vedere" gli oggetti definiti in "Backend"
Tutte le operazioni che potremo a questo punto definire e sviluppare all'interno del nostro progetto "UserInterface", potranno avvalersi di quanto i colleghi esperti di EJB e Business Logic hanno modellato e costruito nel Subsystem "Backend". Al team di "UserInterface", il team di "Backend" ha appena messo a disposizione - via Subsystem - ciò che occorre per poter collegare quanto viene definito e costruito nella parte presentation con la logica di business già implementata in "Backend". Il tutto, come risultato finale, in modo da offrire una piena collaborazione tra i diversi Subsystem (figura 6).


Figura 6 – Deployment


Conclusioni
Come far lavorare insieme specialisti delle varie tecnologie presenti all'interno del mondo J2EE nel modo più efficace ed efficiente possibile? Impiegando in modo pragmatico i Subsystem. Completando quanto presentato e discusso in [1], in cui si era parlato di suddivisione per aree funzionali (cosiddetta "verticale"), nel presente articolo si è invece descritto l'impiego cosiddetto "orizzontale" dei Subsystem, che permette a gruppi di lavoro contenenti al loro interno skill molto specifici di cooperare efficacemente, così che ciascun team riesce a mettere a frutto le proprie competenze e al tempo stesso a collaborare al massimo livello di integrazione con gli altri team, contribuendo nel modo migliore al successo del progetto.

 

Bibliografia
[1] Mokabyte - " Sviluppare Applicazioni J2EE di grandi dimensioni: un approccio concreto e affidabile”, http://www.mokabyte.it/2005/03/huge_progect.htm
[2] Jan JÄurjens "Formal Semantics for Interacting UML subsystems" online copy su http://www4.in.tum.de/~juerjens/papers/fmoods02Talk.pdf
[3] H. Tai, K. Mitsui, T. Nerome, M. Abe, K. Ono, and M. Hori, "Model-driven development of large-scale Web applications", on line copy su http://www.research.ibm.com/journal/rd/485/tai.html
[4] 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)
[5] Compuware Lab “OptimalJ Community” - http://javacentral.compuware.com


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 le soluzioni di Project Management per IT-Governance, i Portali Web, gli strumenti di Business Process Automation, l’Enterprise Application Integration.