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).
Figura
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).
Figura
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, lEnterprise Application
Integration.
|