Figura 1 – Script lato client

La pagina client PaginaClient1 definisce due funzioni di script con un blocco di codice nella pagina client , ad esempio all’interno di un blocco<script></script> inserito nel codice HTML, mentre la pagina client PaginaClient2 include un file esterno contenente le stesse funzioni. Nel primo caso le funzioni sono rappresentate come operazioni della classe stereotipata mentre nel secondo la libreria di funzioni è rappresentata a sua volta con una classe di stereotipo <<clientscript>> . La dipendenza tra la pagina client e la libreria di funzioni ha stereotipo <<script>>.
Anche se la modellazione degli script lato client può sembrare un’attività secondaria nella fase di progettazione di una applicazione web va tenuto presente che in alcune applicazioni questi script svolgono funzioni anche importanti che vanno documentate per una migliore comprensione dell’applicazione. Chiaramente il livello di dettaglio può variare in base alla complessità delle funzioni lato client e deve essere valutato in base all’esperienza del progettista. Tenere nella giusta considerazione anche questo aspetto nella progettazione è comunque importante; in questa fase infatti si può capire quali siano le funzioni necessarie e quali quelle riutilizzabili nelle diverse pagine della propria applicazione.
Relazioni tra pagine e frameset
Un altra delle caratteristiche fondamentali di tutte le applicazioni web sono le relazioni tra le diverse pagine e la loro stessa composizione. E’ possibile avere una pagina client che contenga non solo form per l’immissione dei dati ma anche link ipertestuali ad altre pagine client. E’ essenziale rappresentare questi legami in fase di progettazione per avere una chiaro modello della struttura dell’applicazione dal punto di vista logico. Come già accennato nel precedente articolo questo legame è espresso da una associazione con stereotipo <<link>> tra due classi stereotipate <<client page>> come in Figura 2.

Figura 2 – Link tra pagine client

Ovviamente le relazioni non esistono esclusivamente tra pagine client ma è possibile avere un link ad una pagina server ed oltre a ciò è possibile che al URL che identifica la pagina server in questione vengano accodati alcuni parametri utili all’elaborazione. Questo insieme di cose si esprime come in Figura 3.

Figura 3 – Link tra pagine client e pagine server

In figura sono evidenziati i due modi con i quali si può rappresentare un invio di parametri nella richiesta http. Nel primo caso i parametri accodati al URL sono rappresentati come constraint dell’associazione. Nel secondo caso invece sono rappresentati da una classe di associazione tra le due classi stereotipate <<client page>> e <<server page>>.
Questa rappresentazione è secondo me estremamente utile in fase di progettazione visto che il passaggio di parametri nelle richieste http fatte tramite link è uno degli aspetti generalmente trascurati in fase di progettazione. Quanto detto è valido allo stesso modo quando il link è effettuato tra due pagine JSP.
Un’altra relazione tipica a livello di pagina è quella di inclusione. E’ molto frequente nella pratica realizzare pagine statiche o dinamiche condivise tramite inclusione nelle diverse pagine dell’applicazione. L’esempio tipico è quello degli header e dei footer.
Come è intuibile questo tipo di relazione la si può esprimere con una associazione di stereotipo <<include>> come nella figura seguente.

Figura 4 – Inclusione di pagine client e server

In questo caso la pagina server esegue una include dinamica di un’altra pagina server ed una include statica di una pagina client.
Altro aspetto molto interessante è la possibilità di rappresentare un frameset tramite appositi stereotipi della WAE. Lo stereotipo <<frameset>> rappresenta , manco a dirlo, il fameset vero e proprio ovvero una pagina client contenitore di frame, mentre lo stereotipo <<target>> rappresenta un’area di una pagina client a cui è associato un nome.
Utilizzando le classi stereotipate <<frameset>> e <<target>> è possibile diagrammare la struttura di un frameset e dei suoi frame come in Figura 5.

Figura 5 – I frameset

In questo caso abbiamo il fameset Main che contiene due frame. Il frame di sinistra è fisso ed è il menù dell’applicazione rappresentato dalla pagina client Menu. Il frame di destra è rappresentato dal target Body all’interno del quale vengono caricate via via le pagine client associate ai vari link contenuti nel menù. Si noti appunto la presenza della classe stereotipata <<target>> per indicare la regione del frameset nella quale vengono caricate le pagine client.
I custom tag
Altro elemento ormai comunissimo nello sviluppo delle pagine server sono i custom tag, ovvero tag personalizzati il cui compito è svolto da opportune classi handler ad essi associate. L’utilizzo dei custom tag conferisce maggiore pulizia alle pagine web in quanto consente di eliminare da esse il codice, di standardizzare la scrittura delle pagine e garantisce un completo riutilizzo delle funzionalità più comunemente svolte all’interno di una pagina web.
Con la WAE è possibile rappresentare l’inclusione di una libreria di tag all’interno di una pagina server come in Figura 6.

Figura 6 – I custom tag

In questo caso è raffigurata una pagina JSP che include la libreria core della JSTL. Il ruolo della dipendenza tra la pagina JSP e la libreria di tag è il prefisso usato per la libreria all’interno della pagina.

Vista dinamica
Tutti i diagrammi visti fino ad ora ci hanno permesso di capire come con la WAE si possano rappresentare le strutture ed i legami tipici dei componenti di una applicazione web quali pagine client, pagine server, script e quant’altro. Tutte le rappresentazioni viste erano però di natura statica quindi nulla è stato evidenziato riguardo la vista dinamica del sistema che modella le interazioni tra i vari elementi. Per questo tipo di rappresentazione si utilizzano gli strumenti tipici di UML quali collaboration diagram e sequenze diagram dei quali se ne trova un’ottima spiegazione in [2] e sui quali non ci soffermiamo. L’unica particolarità è che in questi diagrammi saranno presenti le classi stereotipate della WAE quando si va a rappresentare una interazione tra elementi del modello web.

Vista logica e componenti
Nei paragrafi precedenti si è fatto riferimento a stereotipi rappresentanti pagine client e pagine server, mentre non si è fatto esplicito riferimento ad una tecnologia di implementazione. Questo perché la rappresentazione fornita è quella della vista logica del sistema nella quale ci si occupa di stabilire quali componenti del nostro sistema assolveranno ai compiti necessari. E’ chiaro che questi elementi logici saranno poi realizzati nel nostro sistema in componenti specifici della tecnologia in uso. In ambito J2EE si rappresenteranno quindi delle realizzazioni di pagine server tramite pagine JSP o servlet e di pagine client generalmente tramite pagine HTML.
A volte si tende a trascurare o sottintendere questa distinzione definendo un modello utilizzando lo stereotipo server page come sinonimo di pagina JSP e client page come sinonimo di pagina HTML. In realtà questo avviene perché quasi sempre quando ci si appresta a definire il modello logico a livello di progettazione si ha ben chiaro in mente quale sia la tecnologia utilizzata nel progetto ma a scopo di chiarezza è bene puntualizzare che lo stesso modello logico potrebbe essere implementato da componenti diversi.

Conclusioni
In questo articolo e nel precedente abbiamo fatto una panoramica sugli elementi della Web Application Extension di UML ideata da Jim Conallen ed abbiamo visto come sia possibile rappresentare molti degli elementi di uso ricorrente nelle applicazioni web con questa estensione. In [1] nella Appendice A è possibile trovare un riferimento completo al profilo WAE se si desidera approfondire quanto visto in questi due articoli e esaminare gli aspetti non trattati. Nel prossimo articolo vedremo come mettere insieme i concetti visti e usare la notazione vista per la progettazione in un caso reale di una semplice applicazione web.

Bibliografia
[1] Jim Conalen - "Applicazioni Web con UML", II edizione italiana – Pearson Education Italia, 2003
[2] Luca Vetti tagliati - " UML ed ingegneria del software: dalla teoria alla pratica ", Mokabyte, 2000
[3] Jim Arlow, Ila Neustadt – “UML e Unified Process” – McGraw Hill , 2002

Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo ora si occupa in particolare di aspetti architetturali per progetti rivolti al mercato finanziario ed industriale. E’ un Enterprise Architect certificato Sun Microsystems (SCEA) ed inoltre ha conseguito le certificazioni SCJP, SCWCD 1.3, SCWCD 1.4, SCBCD.