Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

102 dicembre
, anno 2005

Skill differenti per applicazioni J2EE di successo

La sfida del teamworking

Avatar

Doriano Gallozzi

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.

MokaByte

Skill differenti per applicazioni J2EE di successo

La sfida del teamworking

Doriano Gallozzi

Doriano Gallozzi

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”.

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!

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], [4], [5]. 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).

Per illustrare meglio quanto stiamo discutendo, possiamo servirci di un esempio utilizzando lo strumento Compuware OptimalJ ([6]), 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).

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).

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).

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.

1″Sviluppare Applicazioni J2EE di grandi dimensioni: un approccio concreto e affidabile”https://www.mokabyte.it/2005/03/huge_progect.htm2Jan JÈurjens”Formal Semantics for Interacting UML subsystems”http://www4.in.tum.de/~juerjens/papers/fmoods02Talk.pdf3H. Tai, K. Mitsui, T. Nerome, M. Abe, K. Ono, M. Hori”Model-driven development of large-scale Web applications”http://www.research.ibm.com/journal/rd/485/tai.html4″Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE” parte 1https://www.mokabyte.it/2004/07/mda-1.htm5″Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE” parte 2https://www.mokabyte.it/2004/09/mda-2.htm6Compuware Lab”OptimalJ Community”

Facebook
Twitter
LinkedIn
Avatar

Doriano Gallozzi

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.

Doriano Gallozzi

Doriano Gallozzi

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.
Tutti gli articoli
Nello stesso numero
Loading...

Applicazioni Desktop

Persistenza delle preferenze

La Reflection in Java

Parte II

Integration Patterns

Parte III: la pratica

Service Oriented Architecture

Parte III: Maturity Model

Introduzione al workflow

Sistemi di gestione del flusso di lavoro

Firma digitale con dispositivo crittografico sicuro

I parte: le smart card

J2ME vs Symbian

Evoluzione e confronto

Architetture e tecniche di progettazione EJB

III parte: trasmissione dati tra strati con DTO

Java Business Integration

Parte III: Service Unit & Service Assembly

Nella stessa serie
Loading...

Digital revolution: trasformare le aziende in ecosistemi digitali

III parte: Dagli obiettivi strategici alle iniziative operative

Digital revolution: La teoria

Tema 2: Il framework OKR

Digital revolution: trasformare le aziende in ecosistemi digitali

II parte: Un workshop per definire la vision

Bitcoin, blockchain e criptovaluta

V parte: Come funziona Bitcoin. Transazioni e UTXO

Digital revolution: La teoria

Tema 1: Approccio Scrum-like alle trasformazioni organizzative

Digital revolution: trasformare le aziende in ecosistemi digitali

I parte: Primo incontro.

Bitcoin, blockchain e criptovaluta

IV parte: Come funziona Bitcoin. Chiavi, indirizzi e wallet

Che cosa significa fare una trasformazione agile?

II parte: Le buone pratiche

Bitcoin, blockchain e criptovaluta

III parte: Come funziona Bitcoin. Rete e crittografia

Che cosa significa fare una trasformazione agile?

I parte: Le indispensabili premesse

Oltre Google Maps?

Una nuova alleanza per le mappe digitali

“Babbo… Ma te che lavoro fai?”

Come spiegare a un bambino (e alla sua maestra) il mestiere dell'agile coach

Bitcoin, blockchain e criptovaluta

II parte: Perché è nato Bitcoin

Microservizi: non solo tecnologia

Quanto influiscono sul business?

LEGO® Serious Play®

Che cosa è il metodo LSP?

State of Agile 2022

Qualche considerazione sul 16° rapporto

Bitcoin, blockchain e criptovaluta

I parte: Breve storia del denaro

Stili di leadership per l’agilità

Oltre il comando e controllo

Effetto Forrester e dinamiche dei sistemi di produzione

La storiella di una birra per comprendere il Lean

Fare “il tagliando” a Scrum

A due anni dalla pubblicazione della nuova guida

Veicoli elettrici ed esperienza utente

II parte: Riflessioni su app e UX

OKR, cadenze in Kanban e Flight Levels

Uscire dalla trappola dell’agilità locale

Continuous Delivery per il proprio team di sviluppo

Principi e pratiche

Il contratto è agile!

Gli elementi del contratto e l'Agilità

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte