Pa Tierno

Universit degli studi di Napoli Federico II
Facolt di Ingegneria

Corso di Laurea in Ingegneria Informatica

TESI DI LAUREA

Framework MVC per lo sviluppo di Web Application :
JavaServer Faces e Struts

Relatore Candidato
Ch.mo Prof. Antonio dAcierno Paolo Patierno
Matricola 041/2803

Anno Accademico 2004/2005

a tutti coloro che hanno creduto in me
alla mia pazientissima famiglia
alla mia dolcissima Sara
alle mie care nonne
R Ri in ng gr ra az zi ia am me en nt ti i

Quando nella vita si raggiungono grandi traguardi e si realizzano i propri
sogni, ci si rende conto che, senza lappoggio delle persone che ci vivono accanto,
gli sforzi e limpegno personali non avrebbero mai consentito da soli tali risultati.
Ho sempre considerato lo studio e la conoscenza tra gli elementi fondamentali
della vita di una persona e per questo, per raggiungere il mio obiettivo, non ho
mai lesinato nei miei confronti limpegno, aggiungendovi costanza, instancabilit,
caparbiet e tenacia che comunque sarebbero state vane senza le persone che qui
ho il piacere ed il dovere di ringraziare.

I miei ringraziamenti vanno innanzitutto al Prof. Ing. Antonio dAcierno,
il quale mi ha proposto questo lavoro che ho accettato con grande entusiasmo.
Grazie a lui, ho avuto la possibilit di affrontare ed approfondire nuovi temi legati
allo sviluppo del software per Internet, per me di estremo interesse.

Gli anni di studio, che mi hanno portato a questo grande traguardo, sono
stati caratterizzati da momenti di gioia cos come da periodi di sacrifici ed
amarezze, che non avrei saputo superare senza coloro che mi hanno preso per
mano lungo questo cammino.

Un immenso grazie va innanzitutto alla mia famiglia, Mamma, Pap ed
ai miei fratelli Enzo e Daniela, che mi hanno dato la possibilit di realizzare
questo sogno, senza mai ostacolarmi nelle decisioni ma dandomi sempre il
massimo appoggio. In questi anni, hanno dovuto sopportare i miei comprensibili
momenti di tensione e di nervosismo, senza mai rimproverarmi alcun
comportamento. A loro devo chiedere scusa, per non aver dedicato il giusto tempo
che merita una famiglia che ama il proprio figlio ed il proprio fratello.

Grazie a mio cugino Diego, che rappresenta per me il modello da
seguire, umanamente e professionalmente, il quale non ha mai risparmiato
consigli ed elogi nei miei confronti. Spero di poter crescere nel tempo ed acquisire
le notevoli capacit che gli riconosco.

Grazie a tutti i miei amici pi sinceri, con i quali ho trascorso delle ore
spensierate, lontano dagli affanni dello studio, e che mi hanno fatto sentire una
persona importante per loro.

Un grazie particolare va a Sara, che ho avuto limmensa fortuna di
conoscere circa un anno fa, diventando lamore della mia vita. Si ritrovata
catapultata nel mio mondo, fatto di moltissime ore si studio, di sacrifici e di
preoccupazioni, dandomi sempre la forza di rialzarmi nei momenti di rabbia e di
sconforto. Seppur soltanto in questo ultimo anno, il suo amore nei miei confronti
stato una grande fonte di energia, dalla quale spero di attingere per tutto il resto
della mia vita.

Vorrei concludere con una dedica alle mie nonne, Edy ed Anna, che ne
sono certo mi hanno guidato da lass e che in questo momento mi sono vicine, per
condividere con me lenorme gioia che ho dentro. A voi

Grazie di cuore a tutti

I In nd di ic ce e
I In nt tr ro od du uz zi io on ne e
Obiettivo della tesi 1

C Ca ap pi it to ol lo o I I I Il l p pa at tt te er rn n M MV VC C
1. Architettura software a livelli . 3
2. Limportanza dei design patterns .... 6
3. Design Pattern MVC Model View Controller ... 8
4. Evoluzione dellarchitettura delle Web Application 11
4.1 Model 1 (Page Centric Architecture) 12
4.2 Model 2 (Servlet Centric Architecture) . 13
5. Le Servlet .. 15
5.1 Struttura di base 16
5.2 Ciclo di vita ... 17
5.3 Richiesta, Risposta, Sessione e Contesto ... 19
6. Web Application Frameworks 21
7. Struttura di una Web application in Java . 22
7.1 Web Application Deployment Descriptor . 23

C Ca ap pi it to ol lo o I II I I Il l f fr ra am me ew wo or rk k J Ja av va aS Se er rv ve er r F Fa ac ce es s
1 . Introduzione .. 26
2. Teamworking . 29
3. Modelli architetturali - Framework Models . 31
3.1 Execution Model 32
I
3.1.1 FacesServlet . 32
3.1.2 Lifecycle PhaseListener 33
3.1.3 Application .. 34
3.1.4 FacesContext ExternalContext . 35
3.2 User Interface Component Model 37
3.3 Component Rendering Model . 40
3.3.1 Renderer ... 40
3.4 Conversion Model . 42
3.4.1 Converter .. 43
3.5 Event and Listener Model . 44
3.5.1 FacesEvent 45
3.5.2 FacesListener . 45
3.6 Validation Model 46
3.6.1 Validator . 47
3.7 Navigation Model 48
3.8 Backing Bean Management ... 49
4. Ciclo di vita di una pagina JavaServer Faces .. 52
4.1 Scenari di elaborazione di una richiesta 53
4.2 Ciclo di vita Standard .. 55
4.2.1 Restore View 56
4.2.2 Apply Request Values 56
4.2.3 Process Validation . 57
4.2.4 Update Model Values 57
4.2.5 Invoke Application 58
4.2.6 Render Response 58
II
5. JSF Expression Language 59
6. Espandibilit del framework . 60
6.1 Custom Converter ... 60
6.2 Event Listener ... 61
6.2.1 Implementazione di un ActionListener/ValueChangeListener ... 62
6.2.2 Backing Bean Method Listener 63
6.3 Custom Validator ... 63
6.3.1 Implementazione di un Validator . 64
6.3.1.1 Class Validator ... 65
6.3.1.2 Tag Handler ... 65
6.3.1.3 Tag Library Descriptor . 66
6.3.2 Backing Bean Method Validator .. 66
6.4 Custom UI Components ... 67
6.4.1. Class Component .. 69
6.4.2 Tag Handler . 71
6.4.3 Tag Library Descriptor 72
6.4.4 Classe Renderer .. 73
7. Sicurezza 73
8. Configurazione dellapplicazione .. 74
8.1 Configurazione dei Backing Beans ... 75
8.2 Localizzazione, Internazionalizzazione e Messaggi . 76
8.3 Registrare un Custom Validator . 77
8.4 Registrare un Custom Converter . 77
8.5 Configurare le Navigation Rules . 78
8.6 Registrare un Custom Renderer in un Renderer Kit . 79
III
8.7 Registrare un Custom Component . 80

C Ca ap pi it to ol lo o I II II I I Il l f fr ra am me ew wo or rk k S St tr ru ut ts s
1 . Introduzione .... 81
2. Controller, Model and View Components .. 83
2.1 Controller Components .. 84
2.1.1 ActionServlet . 85
2.1.2 RequestProcessor . 86
2.1.3 Action .. 88
2.1.3.1 ForwardAction . 89
2.1.3.2 DispatchAction LookupDispatchAction . 90
2.1.3.3 SwitchAction 91
2.1.4 ActionForward .. 91
2.2 Utility Classes . 92
2.3 Model Components ... 93
2.4 View Components 94
2.4.1 ActionForm .. 95
2.4.2 ActionErrors 97
2.4.2.1 ActionMessage ActionError 98
2.4.3 DynaActionForm .... 99
2.4.4 Tag Libraries .100
3. Ciclo di vita di una richiesta .. 101
4. Exception Handling .... 102
4.1 Approccio Dichiarativo 103
4.2 Approccio programmatico ......104
IV
4.3 ModuleException ....104
5. Internazionalizzazione (I18N) ..105
6. JavaServer Pages Standard Tag Library (JSTL) ...107
7. Estensioni con i PlugIn .108
8. Validator framework109
9. Tiles framework ..111
9.1 Definitions 113
9.2 Costruzione di una pagina 114
10. Sicurezza .115
11. Configurazione dellapplicazione116
11.1 DataSource .117
11.2 FormBean ...118
11.3 Global Exceptions 120
11.4 Global Forwards ..121
11.5 Action Mapping ...121
11.6 Controller ....123
11.7 Message resources ..123
11.8 Plug-In ...124

C Ca ap pi it to ol lo o I IV V I I f fr ra am me ew wo or rk k a a c co on nf fr ro on nt to o
1. Introduzione ..125
2. Ciclo di vita di una richiesta .127
3. Controller Tier ...130
4. Interfaccia Utente (UI) 133
5. Events e Listeners .......136
V
6. Mappatura delle richieste sulla Business-Logic ..140
7. Conversione ...144
8. Validazione ..145
9. Navigazione ..148
10. Expression Language ....150
11. Eccezioni 152
12. Internazionalizzazione (I18N) ...154
13. Sicurezza 155
14. Configurazione .156
15. Web Application Layout ...157
16. Migrazione da Struts a JavaServer Faces ..159
16.1 Strategie di migrazione ...159
16.1.1 Components Only 159
16.1.2 Incremental migration ...161
16.1.3 Full migration .....164

C Ca ap pi it to ol lo o V V C Ca as se e S St tu ud dy y : : A An na al li is si i e e P Pr ro og ge et tt ta az zi io on ne e
2. Requisiti ...167
3. Progettazione .168
3.1 Use Case Diagrams 168
3.1.1 Generale ..169
3.1.2 Gestione Scheda Prepagata ..170
3.1.3 Registrazione 171
3.1.4 Azioni su Brani ........171
VI
3.1.5 Gestione Playlist ....172
3.1.6 Gestione Utenti .173
3.1.7 Gestione Archivio Brani ... ...........174
3.1.8 Casi duso comuni : Login, Logout, Gestione Dati Personali ......176
3.2 Class Diagram ...177
3.3 Activity Diagrams Sequence Diagrams .....180
3.3.1 Login ..182
3.3.2 Logout 187
3.3.3 Registrazione 189
3.3.4 Richiesta Username / Password ...192
3.3.5 Acquisto, Ricarica e Visualizzazione Info Scheda Prepagata .193
3.3.6 Visualizzazione e Ricerca Brani .... ..199
3.3.7 Inserimento, Modifica ed Eliminazione Brano dallArchivio .......202
3.3.8 Ascolto di un singolo Brano .211
3.3.10 Acquisto/Download Brano ...226
3.3.11 Modifica Dati Personali ....229
3.3.12 Gestione Utenti ...234
3.4 Statechart Diagrams ....237
3.5 Conceptual Data Model ...244
3.6 Physical Data Model ...247

C Ca ap pi it to ol lo o V VI I C Ca as se e S St tu ud dy y : : I Im mp pl le em me en nt ta az zi io on ni i a a c co on nf fr ro on nt to o
2. Struttura dellapplicazione ....254
VII
3. Controller ..........263
3.1 Gestione delle sessioni ...264
3.2 Protezione pagine 266
4. View ....268
4.1 Le librerie Standard 269
4.1.1 I form : contenuto e layout ......................270
4.1.2 Costruzione condizionale dei contenuti ....272
4.1.3 DataTable JSF e Cicli JSTL ..273
4.2 Tiles .275
4.3 JavaServer Faces Custom Components .....278
4.3.1 DateSelectComponent .279
4.3.2 DDListComponent .............283
4.3.3 TimeSelectComponent ..............285
4.3.4 e Struts ? .287
4.4 I formbean di Struts 288
4.4.1 Login, Registrazione e Richiesta password ..289
4.4.2 Acquisto/Ricarica scheda prepagata ..292
4.4.3 Modifica dati utente ed amministratore .......294
4.4.5 Visualizzazione e ricerca dei brani ........294
4.4.6 Inserimento/Modifica brani .297
4.4.8 Gestione Utenti .300
4.4.9 e JavaServer Faces ? ..301
4.5 Player MP3 ...302
4.6 Internazionalizzazione (I18N) ......303
VIII
5. Validazione ..306
5.1 JavaServer Faces Custom Validators ..306
5.1.1 EmailValidator ....308
5.1.2 SeqCifreValidator .310
5.1.3 TelefonoValidator ......311
5.2 Plug-in Validator Struts ..313
6. Model ..316
6.1 Classi Exception 317
6.2 Classi di interfacciamento con il DataBase ...318
6.3 Le Action di Struts .329
6.4 Business-Logic e funzionalit del sistema .344
6.4.1 Package accesso .346
6.4.2 Package ruolo ...348
6.4.3 Package brani ...357
6.4.4 Package playlist .....364
6.4.5 Package scheda ......370
6.4.6 Package cartacredito ...374
6.4.7 Package download .376
6.4.8 Package mail 376
6.5 I Backing Beans di JavaServer Faces ..377
7. Plug-in di Struts 380
8. Navigazione ..382
9. Eccezioni ..384
10. Sicurezza 385

IX
A Ap pp pe en nd di ic ce e A A S SR RS S W We eb b A Ap pp pl li ic ca at ti io on n M MP P3 3- -W We eb b...390

R Ri if fe er ri im me en nt ti i B Bi ib bl li io og gr ra af fi ic ci i ...426
X
Introduzione Obiettivo della tesi
_________________________________________________________________
I In nt tr ro od du uz zi io on ne e

Obiettivo della tesi

Il lavoro di tesi svolto si pone come obiettivo il confronto tra due dei
principali framework MVC per lo sviluppo di Web application : JavaServer Faces e
Struts. Considerando il linguaggio comune su cui si basano, ossia il Java, tale
confronto relativo soprattutto a ci che riguarda gli strumenti, le funzionalit e le
potenzialit fornite dalluno e dallaltro.

Si parte da una descrizione del pattern MVC (Model View Controller) e
di tutti gli aspetti relativi al suo meccanismo di funzionamento, nonch da una
spiegazione delle Servlet che sono alla base dei framework suddetti.

Successivamente, viene dato ampio spazio al framework JavaServer Faces
descrivendone tutte le classi che ne costituiscono larchitettura e tutte le funzionalit
messe a disposizione per realizzare unapplicazione Web. Allo stesso modo stata
approfondita la struttura di Struts ed i relativi strumenti disponibili.

Raccolte le informazioni necessarie, stato realizzato un confronto teorico
tra i due framework evidenziando vantaggi e svantaggi delluno e dellaltro in
relazione a ciascuna funzionalit offerta.

Per poter fornire una base solida al confronto teorico, stato preso in
esame un caso di studio che ha previsto la realizzazione di una Web application
mediante i due framework. Tale applicazione mette a disposizione degli utenti la
possibilit di usufruire di contenuti audio, ossia brani MP3, registrandosi, creando
delle proprie playlist per poterle ascoltare in streaming e per poter eventualmente
acquistare i brani ed effettuarne il download. Per quanto riguarda lamministratore,
egli ha a disposizione tutte le funzionalit di gestione dellarchivio dei brani e degli
utenti registrati. E stata eseguita una preventiva fase di analisi e progettazione che ha
previsto la realizzazione del documento di specifica dei requisiti (SRS) e di tutti i
1
Introduzione Obiettivo della tesi
_________________________________________________________________
diagrammi UML (Use Case, Class, Activity, Sequence, Statechart) oltre al modello
concettuale e fisico della base di dati necessaria. A queste fasi ha fatto seguito una
doppia fase di implementazione che ha previsto la realizzazione della Web
application con entrambi i framework. Infine, sulla base di quanto sviluppato sono
state ripresi tutti gli aspetti che potessero rappresentare termini di confronto fra di
essi e sono state evidenziate le analogie e le differenze di implementazione delluno e
dellaltro.

Per quanto concerne gli strumenti adottati si fatto ampio uso del software
Sybase Power Designer per lo sviluppo dei diagrammi UML, dellambiente IDE
Eclipse 3.1 ed i plug-in Exadel ed Omondo per limplementazione ed infine del Web
Container Apache Tomcat 5.0.28 come ambiente di esecuzione delle due
implementazioni.
2
Capitolo I Il Pattern MVC
_________________________________________________________________
C Ca ap pi it to ol lo o I I I Il l P Pa at tt te er rn n M MV VC C

1. Architettura software a livelli

Nello sviluppo delle applicazioni software, possibile descrivere
larchitettura del sistema utilizzando uno fra i molteplici paradigmi a disposizione, ma
in linea generale, trova una maggiore applicazione la nota architettura a livelli
(Layered Application Architecture). Quest ultima prevede che un sistema software
sia decomposto in tre livelli nettamente distinti, che comunque abbiano la possibilit
di comunicare fra loro secondo unopportuna gerarchia. Ciascuno dei tre livelli ha un
proprio ruolo ed assolve ad uno specifico compito allinterno del sistema
complessivo, senza interferire con gli altri livelli ma scambiando con essi le
informazioni necessarie allesecuzione di elaborazioni anche molto complesse.

I tre livelli in questione sono i seguenti :

- Presentation layer : il livello di presentazione, il cui compito quello di
interagire direttamente con lutente del sistema, acquisire i dati di input
immessi da questultimo e visualizzare i risultati dellelaborazione effettuata
dal sistema stesso. Esso, in pratica, definisce la GUI (Graphic User Interface)
ossia linterfaccia grafica dellapplicazione;
- Application processing layer : il livello in corrispondenza del quale si trova la
business-logic dellapplicazione e quindi tutti i moduli software che
implementano le funzionalit che il sistema mette a disposizione. In sostanza,
il centro dellelaborazione dei dati in cui avvengono tutte le computazioni;
- Data management layer : il livello che si occupa della gestione della persistenza
e dellaccesso ai dati, per cui tipicamente caratterizzato da un DBMS
(DataBase Management System);
3
_________________________________________________________________

Figura 1 Architettura Software a livelli

Sviluppando unapplicazione secondo questa architettura, ogni livello indipendente
dagli altri, per cui la modifica di uno di essi non ha effetto sui restanti. Tuttavia
prevista la comunicazione fra loro e lo scambio di informazioni.
Un tipico scenario di funzionamento del sistema pu essere il seguente :
un utente utilizza lapplicazione, interagendo direttamente con la GUI e fornisce
quindi al Presentation layer, i dati su cui andr eseguita lelaborazione. Il Presentation
layer, acquisiti i dati di input, li trasferisce allApplication processing layer che esegue
su di essi una determinata computazione.
Durante lelaborazione, la business-logic pu prevedere la memorizzazione
persistente dei dati oppure la necessit di acquisire ulteriori dati gi memorizzati. In
questo caso, c linterazione con il Data managemente layer, il quale memorizza i
dati che gli vengono passati dal livello superiore, oppure recupera da un Data Source
(es. database) i dati richiesti e li trasmette alla business-logic. Al termine
dellelaborazione i risultati vengono passati al Presentation layer che li visualizza in
una certa forma allutente finale.
Facendo riferimento al paradigma Client-Server, notevolmente utilizzato nelle Web
application ma di gran richiamo anche per applicazioni desktop, i tre livelli del
sistema devono essere correttamente ripartiti anche da un punto di vista hardware.
Le principali architetture per la ripartizione sono :

- Two-Tier nelle due soluzioni Thin e Fat Client;
- Three-Tier;
4
_________________________________________________________________

Larchitettura Two-Tier prevede un unico Client ed un unico Server ed i tre livelli
dellapplicazione software sono distribuiti fra di essi secondo due possibili modalit :

- Thin Client : sul Client risiede il Presentation layer mentre sul Server gli altri
due livelli (Application processing layer e Data management layer). Un
vantaggio pu risiedere nel fatto che una modifica alla business-logic va
eseguita una sola volta sul Server, mentre lo svantaggio principale pu essere
caratterizzato dallenorme carico di lavoro che deve supportare il Server
stesso dato il numero elevato di Client che possono accedere ad esso;
- Fat Client : sul Client risiedono i primi due livelli (Presentation layer e
Application processing layer) mentre sul Server soltanto il Data management
layer. Il vantaggio quello di ridurre il carico di lavoro sul Server che si
occupa solo dellaccesso ai dati, delegando lelaborazione degli stessi al Client.
Lo svantaggio principale la complessit maggiore dei Client e quindi la
necessit di aggiornare ciascuno di essi nel caso in cui vengano apportate
modifiche alla business-logic;

Figura 2 Architetture Two Tier

Larchitettura Three-Tier, maggiormente utilizzata, prevede la presenza di un unico
Client ed una coppia di Server. Sul Client risiede il Presentation layer e su ciascuno
dei due Server sono distribuiti i due restanti livelli (Application processing layer e
Data management layer). Nellambito di una Web application, il Client
caratterizzato da un nodo della rete sul quale in esecuzione il browser, mentre i due
Server, da un punto di vista software, sono tipicamente inglobati in un unico nodo
5
_________________________________________________________________
della rete che funge da Server fisico. In particolare, sulla stessa macchina sono in
esecuzione il Web Server associato allApplication proccessing layer ed il Database
Server associato al Data management layer.

Figura 3 Architettura Three Tier

In conclusione, proprio su questa particolare architettura a livelli che si basa il
pattern MVC (Model View Controller) , che rappresenta il fondamento dei
framework Struts e J avaServer Faces (J SF) che saranno oggetto di studio e di un
approfondito confronto.

2. Limportanza dei design patterns

Alla met del ventesimo secolo, larchitetto Christopher Alexander osserv
come i suoi colleghi tendevano a risolvere i medesimi problemi, pi o meno allo
stesso modo. Da tale osservazione, introdusse il concetto di design pattern,
ovviamente riferito allarchitettura. Secondo Christopher Alexander, un design
pattern descrive un problema che si presenta frequentemente nel nostro ambiente, e
quindi descrive il nucleo della soluzione in modo tale che sia possibile impiegare tale
soluzione milioni di volte, senza peraltro produrre due volte la stessa realizzazione.
Ovviamente, tale definizione era riferita allambito architetturale, ma nel 1994, con il
libro Design Patterns : Elements of Reusable Object-Oriented Software, Erich
Gamma, Richard Helm, Ralph Johnson e John Vlissides, applicarono questa
intuizione allo sviluppo del software. In questo caso, il principio ugualmente valido
anche se riferito ad oggetti, classi ed interfacce piuttosto che ad elementi
architettonici come muri, archi e pilastri.

6
_________________________________________________________________
Un pattern un modello che permette di definire la soluzione di un problema
specifico che si ripresenta, di volta in volta, in un contesto diverso.
Presenta inoltre le seguenti caratteristiche :

- il nome che individua il pattern e la cui importanza non secondaria,
perch rientra a far parte del vocabolario dello sviluppo software;
- la descrizione del problema in maniera dettagliata, con la sua struttura e le
condizioni al contorno;
- la soluzione che descrive gli artefatti software per risolvere il problema
come gli elementi che rientrano nello sviluppo, quali le classi e le relazioni fra
esse, le associazioni ed i ruoli, le modalit di collaborazione tra le classi
coinvolte ed infine la distribuzione delle responsabilit nella soluzione del
particolare problema di design considerato;
- le conseguenze che descrivono i risultati che si possono ottenere
dallapplicazione del pattern per spingere uno sviluppatore a farne uso;

Ad oggi i patterns sono di grande interesse, in virt del fatto che rappresentano una
successiva evoluzione del paradigma OOP (Object Oriented Programming), poich
combinano classi ed oggetti atomici per fornire una base pi ampia per la risoluzione
di un problema, nella fattispecie per lo sviluppo di unapplicazione software.
Sotto questo punto di vista, un design pattern fornisce allo sviluppatore :

- una soluzione codificata e consolidata per un problema ricorrente;
- unastrazione di granularit e livello di astrazione pi elevati di una classe;
- un supporto alla comunicazione delle caratteristiche del progetto;
- un modo per progettare software con caratteristiche predefinite;
- un supporto alla progettazione di sistemi complessi;
- un modo per gestire la complessit del software;

Pu essere considerato un buon pattern un pattern che descrive una soluzione
assodata per un problema ricorrente in un contesto specifico.
7
_________________________________________________________________
E ovvio che esistono numerose tipologie di design patterns, ma nellambito dello
sviluppo delle Web application, in riferimento allobiettivo proposto, assume un
ruolo rilevante il pattern MVC (Model View Controller).

3. Design Pattern MVC Model View Controller

Il design pattern MVC ha le sue origini nellambiente Smalltalk, in cui
veniva utilizzato per la realizzazione della GUI (Graphic User Interface) di
applicazioni desktop e non orientate al Web. Tale pattern si basa sullidea di separare
i dati dalla rappresentazione, poich mantenere un forte accoppiamento tra essi
comporta che la modifica delluno, implica automaticamente un aggiornamento
dellaltro. Esso, quindi, prevede che un sistema software sia realizzato secondo
larchitettura a livelli, stabilendo un disaccoppiamento fra dati e rappresentazione,
mediante la definizione di tre elementi noti come : Model, View e Controller.

Figura 4 - Model, View e Controller

Il Model (Modello) responsabile della gestione dei dati e del
comportamento dellapplicazione (data & behaviour). Esso coordina la business-
logic dellapplicazione, laccesso alle basi di dati e tutte le parti critiche nascoste
del sistema. Incapsula lo stato dellapplicazione ed espone le funzionalit di
8
_________________________________________________________________
questultima. E indipendente dalle specifiche rappresentazioni dei dati sullo schermo
e dalle modalit di input dei dati stessi da parte dellutente. Ad esso fanno riferimento
lApplication processing layer ed il Data managemente layer nel design del software
a livelli.
Il Model pu essere scomposto in tre sottolivelli puramente concettuali :

- External interface : caratterizzato dal codice che definisce uninterfaccia
mediante la quale il codice esterno comunica con il Model. Generalmente il
codice esterno determinato dal framework adottato per sviluppare la Web
application, come ad esempio Struts e JavaServer Faces;
- Business logic : rappresenta il cuore del Model contenente il codice che realizza
le funzionalit dellapplicazione;
- Data access : costituito dal codice che permette di accedere ad un datasource,
come ad esempio una base di dati;

Figura 5 Architettura del Model

I tre sottolivelli descritti non rappresentano necessariamente dei set di classi separate
ma, bens, dei set di responsabilit differenti che ha il Model. Lo sviluppatore pu
decidere di realizzare i tre sottolivelli mediante una o pi classi e raggruppando due o
pi sottolivelli. Tipicamente si preferisce realizzare il sottolivello Data access con una
9
_________________________________________________________________
o pi classi che hanno come unico scopo quello di permettere laccesso ad un base di
dati. Gli altri due sottolivelli possono essere realizzati in due modi :

- separazione : ci sono una serie di classi che realizzano la Business logic ed
ulteriori classi che definiscono lExternal interface;
- fusione : sono definite una serie di classi che definiscono la Business logic e
contengono allinterno anche le funzionalit di interfacciamento dellExternal
interface;

La scelta pu dipendere dalla complessit dellapplicazione ed , eventualmente, dalla
tecnologia che viene adottata sul Model per realizzare la Web application.
La View (Vista) ha il compito di visualizzare i dati e presentarli allutente
anche in forme diverse, in relazione al dispositivo utilizzato per accedere al sistema
(es. personal computer, cellulare, ..) . Ci vuol dire che, pur partendo dagli stessi dati,
possibile effettuare rendering diversi ed ottenere viste multiple dello stesso
modello. Ad esso fa riferimento il Presentation layer.
Il Controller (Controllo) definisce il meccanismo mediante il quale il Model
e la View comunicano. Realizza la connessione logica tra linterazione dellutente con
linterfaccia applicativa e i servizi della business-logic nel back-end del sistema. E
responsabile della scelta di una tra molteplici viste dello stesso modello, in base al
tipo di dispositivo utilizzato dallutente per accedere al sistema ma anche in relazione
alla localizzazione geografica dellutente stesso. Una qualsiasi richiesta (request) fatta
al sistema viene acquisita dal Controller che individua allinterno del Model il gestore
della richiesta (request handler). Ottenuto il risultato dellelaborazione (response), il
Controller stesso determina a quale View passare i dati per la presentazione degli
stessi allutente.
Il vantaggio principale che scaturisce da questa architettura, che la business-logic
definita allinterno del Model separata dal Presentation layer che si trova allinterno
della View. Tutto ci favorisce il riuso dei componenti e la possibilit di apportare
delle modifiche ad un livello senza avere degli effetti sullaltro.

10
_________________________________________________________________
4. Evoluzione dellarchitettura delle Web Application

Considerando il Java come uno dei migliori linguaggi per lo sviluppo delle
applicazioni Web, attraverso luso delle Servlets e delle pagine JSP (Java Server
Pages), larchitettura delle Web application ha subito una notevole evoluzione nel
corso degli anni, seguendo un iter di questo tipo :

1. Assenza del pattern MVC;
2. Utilizzo del pattern MVC secondo il Model 1 (Page Centric);
3. Utilizzo del pattern MVC secondo il Model 2 (Servlet Centric);
4. Web application Frameworks (es. Struts);
5. Web application Framework basato su uno standard ( JavaServer Faces JSR
127);

Tale evoluzione ha previsto un aumento della complessit e della robustezza di
ciascuna applicazione e pu essere schematizzata nel modo seguente, sino
allintroduzione del Model 1 :

Figura 6 - Evoluzione dello sviluppo di Web Application

11
_________________________________________________________________
4.1 Model 1 (Page Centric Architecture)

Il Model 1 del pattern MVC detto anche Page Centric, poich
larchitettura della Web application basata sulle pagine JSP. Il sistema complessivo
composto da una serie di pagine JSP legate fra loro, ciascuna delle quali gestisce tutti
gli aspetti principali dellapplicazione tra cui la presentazione, il controllo ed i processi
di business. E evidente che la business-logic ed il controllo sono fortemente
accoppiati allinterno di ciascuna pagina JSP, attraverso lutilizzo di JavaBeans,
Scriptlets ed Espressioni. I tre elementi del pattern, Model, View e Controller, pur
essendo distinti, sono inglobati allinterno di una stessa struttura che in questo caso
rappresentata da una pagina JSP.

Figura 7 - MVC Model 1 (Page - Centric Architecture)

Il modello prevede uno scenario di interazione di questo tipo :
Il browser invia una richiesta (request) di una risorsa al Web Server, nella maggior
parte dei casi per la visualizzazione di una pagina JSP. Il Web Server, tipicamente,
funge da Web Container e quindi da Servlet Container in quanto va ricordato che
una pagina JSP, una volta richiesta, viene sempre trasformata in una corrispondente
Servlet. Allinterno della pagina JSP, ci sono i tag che ne definiscono la presentazione
allutente e quindi laspetto grafico (GUI) , ma anche gli elementi per lesecuzione
12
_________________________________________________________________
delle elaborazioni. Queste ultime possono essere eseguite allinterno della pagina
stessa, attraverso codice Java immerso nei tag (Scriptlets) oppure mediante dei
componenti esterni, ai quali si fa riferimento da tale pagina. I componenti in
questione sono tipicamente dei JavaBeans, i quali effettuano una qualsiasi
computazione, comunicando eventualmente con il back-end del sistema, ad esempio
per laccesso a basi di dati. Il risultato di ciascuna elaborazione sar cos integrato
allinterno della pagina HTML prodotta, che sar inviata nella risposta (response) al
browser.
Da quanto detto, si evince che Model, View e Controller sono praticamente integrati
allinterno di ciascuna pagina JSP e che non c una netta separazione fra essi.
I limiti principali di questo modello possono essere i seguenti :

- viene incoraggiata una struttura a spaghetti delle pagine JSP, poich la
business-logic si perde allinterno di ciascuna pagina e la navigazione nella
Web application complessiva viene fatta pagina per pagina;
- molto difficile eseguirne il debug, poich tutti gli errori riportati dal Web
Container, fanno riferimenti al codice compilato della pagina JSP in una
Servlet e quindi sono difficili da individuare allinterno della pagina stessa;

Tutto ci rappresenta un primo passo verso il modello definitivo del pattern MVC.

4.2 Model 2 (Servlet Centric Architecture)

Il Model 2 del pattern MVC detto anche Servlet Centric, poich
larchitettura della Web application si basa fortemente sullutilizzo di una Servlet. Il
sistema complessivo composto da una Servlet principale che svolge il ruolo di
Controller, da una serie di pagine JSP che rappresentano la View ed infine da un
insieme di JavaBeans che costituiscono il Model. I tre elementi del pattern MVC
sono quindi nettamente separati tra loro, pur mantenendo la possibilit di
comunicare per scambiarsi informazioni. In particolare, le pagine JSP si occupano
esclusivamente della presentazione dei dati allutente, senza contenere un minimo di
business-logic. La Servlet master ha il compito di acquisire tutte le richieste
provenienti dalla rete e funge da dispatcher, inoltrando ciascuna di esse verso il
13
_________________________________________________________________
corrispondente handler per permetterne la gestione. Al termine dellelaborazione,
la stessa Servlet che determina a quale pagina JSP restituire il controllo, eseguendo il
redirecting. Infine, i JavaBeans incapsulano le funzionalit dellapplicazione,
interagiscono con il back-end del sistema ed eseguono tutte le elaborazioni richieste.
Su tale modello, si basano i framework Struts e JavaServer Faces (JSF).

Figura 8 - MVC Model 2 (Servlet - Centric Architecture)

Il modello prevede uno scenario di interazione di questo tipo :
Il browser invia una richiesta (request) di una risorsa al Web Server, nella maggior
parte dei casi per la visualizzazione di una pagina JSP. Il Web Server, tipicamente
funge da Web Container e quindi da Servlet Container, in quanto in esecuzione su
di esso, la master Servlet della Web application. Questultima funge da Controller
ed acquisisce la richiesta, sulla base della quale individua lhandler che dovr gestirla.
In particolare, vengono istanziati una serie di JavaBeans, costituenti il Model, che
eseguono le elaborazioni richieste ed eventualmente interagiscono con il back-end del
sistema, accedendo ad una base di dati. Al termine della computazione, il controllo
ritorna alla Servlet che sulla base del risultato, determina la View e quindi la pagina
JSP verso la quale eseguire il redirecting, la quale estrae dai JavaBeans i risultati e li
visualizza allutente. Infine, la pagina HTML prodotta viene trasmessa al browser
come risposta (response) definitiva.
14
_________________________________________________________________
Da quanto detto si evince che Model, View e Controller sono nettamente separati fra
loro e che il Controller funge da tramite per la comunicazione tra i primi due. Da ci,
scaturisce anche che il debug pu essere eseguito in maniera piuttosto semplice su
ciascun JavaBeans, estrapolandolo dal sistema complessivo.
Per quanto riguarda la struttura del Controller, possibile pensare di utilizzare una
sola Servlet come detto sino ad ora, oppure pi Servlets. La scelta dipende dal livello
di granularit della Web application ed possibile pensare a tre diverse soluzioni :

- una sola master Servlet;
- una Servlet per ciascun caso duso dellapplicazione oppure per ogni
macrofunzionalit offerta;
- combinazione delle due precedenti soluzioni : una master Servlet per
gestire le funzioni comuni a tutti gli ambiti dellapplicazione, che delega alle
Servlets figlie la gestione di particolari macrofunzionalit del sistema;

5. Le Servlet

Lelemento tecnologico che ha determinato un notevole miglioramento
nello sviluppo delle Web application e che si pone alla base dei framework MVC, la
Servlet. Questultima, per definizione, sostanzialmente una classe Java orientata alla
comunicazione tra client e server. Essa riceve dei messaggi di richiesta da parte del
client e produce, in corrispondenza, dei messaggi di risposta. E in esecuzione
allinterno di un Web container secondo un particolare ciclo di vita per definito e pu
essere di due tipi :

- Servlet generica : non orientata alla comunicazione con uno specifico
protocollo;
- Servlet HTTP : orientata alla comunicazione Client-Server basata su protocollo
HTTP;

15
_________________________________________________________________

Figura 9 - Classi Servlet

Essendo lo studio orientato ai framework MVC, assumono un ruolo fondamentale le
Servlet HTTP, delle quali vanno evidenziate gli elementi costitutivi ed i princpi di
funzionamento.

5.1 Struttura di base

La parte fondamentale di una Servlet caratterizzata dai suoi metodi di
servizio, che vengono invocati dal Web container, in cui in esecuzione la Servlet
stessa, per gestire le richieste HTTP che le pervengono. Sono stati pensati in modo
tale che si abbia la possibilit di poter gestire in modo differenziato le richieste che
sono state inviate con metodi HTTP diversi, quali POST e GET.
Tali metodi di servizio sono sostanzialmente i seguenti :

- doGet() : contiene le operazioni da eseguire per rispondere ad una richiesta
inviata con metodo GET;
- doPost() : contiene le operazioni da eseguire per rispondere alle richieste
inviate con metodo POST;

Quando si realizza una propria Servlet, estendendo la classe HTTPServlet, necessario
eseguire loverriding di questi due metodi e , nel caso in cui una richiesta debba essere
gestita allo stesso modo indipendentemente che sia di tipo POST oppure GET,
possibile scrivere il codice in uno dei due metodi e fare in modo che laltro lo
invochi.
16
_________________________________________________________________
Essi prevedono una signature particolare, in quanto i parametri caratteristici sono :

- request : oggetto HTTPServletRequest che contiene le informazioni della
richiesta da gestire;
- response : oggetto HTTPServletResponse che conterr la risposta da inoltrare
verso il client;

5.2 Ciclo di vita

Una volta che la Servlet stata realizzata dallo sviluppatore, non
questultimo che si occupa di istanziarla al momento opportuno ma il Web
container, che ne gestir il corrispondente ciclo di vita. Il programmatore non
dispone nemmeno di un riferimento alla Servlet ed ai suoi metodi, per cui non pu
invocarli. Questi ultimi sono stati pensati per la gestione di particolari eventi che in
questo caso sono delle richieste HTTP. Ci vuol dire che allo scatenarsi dellevento
richiesta HTTP giunta al Web container ed indirizzata ad una certa Servlet, viene
avviato automaticamente uno dei due metodi doGet() e doPost() per la sua gestione.
Il ciclo di vita di un oggetto Servlet prevede le seguenti fasi :

- inizializzazione : il contenitore crea unistanza della Servlet;
- servizio : listanza viene utilizzata per gestire le richieste;
- distruzione : listanza viene deallocata e rimossa dal Web container;

Figura 10 - Ciclo di vita di una Servlet

17
_________________________________________________________________
Nella fase di inizializzazione, il Web container invoca il metodo init() della Servlet, il
quale pu essere soggetto ad overriding qualora si rendesse necessario effettuare
particolari operazioni di inizializzazione, come ad esempio lazzeramento di
contatori. A questo punto, stato creato un processo associato alla Servlet residente
in memoria e questultima pronta per ricevere e gestire le richieste. Nel momento in
cui giunge una richiesta, il Web container crea un thread associato alla Servlet e su di
esso invoca il metodo service(), il quale a sua volta non fa altro che invocare il metodo
doGet() oppure doPost() passandogli gli oggetti relativi alla request ed alla response.
La caratteristica peculiare delle Servlet che non viene allocato un nuovo processo
per ogni richiesta ma bens un thread, per cui c un notevole risparmio di risorse
rispetto alla gestione prevista dagli script CGI (Common Gateway Interface). Questi
ultimi prevedono, infatti, lallocazione di un processo CGI per ciascuna richiesta
pervenuta al CGI Server. Ovviamente, i thread condividono le risorse del processo
associato alla Servlet e quindi si pu verificare facilmente unesecuzione concorrente
dei metodi di questultima.

Figura 11 - Processi CGI

Figura 12 - Threads Servlet

18
_________________________________________________________________

Figura 13 - Esempio di threads Servlet

La fase di distruzione viene eseguita quando c lo shutdown del Web Container
oppure richiesta esplicitamente quando avviene il ricaricamento o la rimozione
dellapplicazione. Il contenitore non fa altro che invocare il metodo destroy(), il quale
pu essere soggetto ad overriding qualora si rendesse necessario liberare delle risorse
che sono state occupate attraverso il metodo init(). Lesecuzione corretta della
procedura di distruzione non sempre garantita, ad esempio nel caso in cui si
verifichi un crash dellapplicazione oppure del Web Container.
Lesecuzione delle Servlet in ambiente multithread comporta il notevole vantaggio
dellottimizzazione delle risorse, ma porta con se la necessit di fare molta attenzione
da parte dello sviluppatore, dovendo gestire la sincronizzazione e lesecuzione
concorrente dei thread.

5.3 Richiesta, Risposta, Sessione e Contesto

Nel momento in cui una Servlet viene invocata, le vengono passati gli
oggetti che contengono le informazioni relative alla richiesta pervenuta ed alla
risposta che sar generata. Tali oggetti sono accessibili allinterno dei metodi della
Servlet, cos come gli oggetti che conterranno le informazioni relative alla sessione
utente ed allapplicazione.
19
_________________________________________________________________
La classe HTTPServletRequest contiene tutte le informazioni che riguardano la request
che giunta alla Servlet. Essa ha due funzione principali :

- contiene una mappa dei parametri forniti attraverso la query string;
- contiene le informazioni tipiche di una richiesta HTTP (es. metodo
GET/POST, URI, headers,);

La classe HTTPServletResponse necessaria per generare la risposta da inviare al client,
per cui ha le seguenti funzioni principali :

- consente di specificare le intestazioni HTTP del messaggio di risposta;
- consente di produrre il corpo del messaggio di risposta stampandone il
contenuto;

Lordine delle operazioni da eseguire fondamentale, in quanto deve rispecchiare la
struttura di una risposta HTTP che prevede in primo luogo le intestazioni (headers) e
successivamente il corpo (body).
La classe HTTPSession rappresenta una sessione di lavoro tra il client ed il server che
viene gestita in maniera trasparente dal contenitore. Questultimo mantiene una
tabella contenente i dati delle sessioni instaurate con i client e consente di manipolarli
utilizzando appunto loggetto session. Tale oggetto viene restituito invocando il
metodo getSession() della classe HTTPServletRequest, in quanto le informazioni di
sessione sono strettamente legate alla richiesta. Ogni sessione prevede che il client
accetti i cookie, cos come prevede un timeout fissato dal contenitore, allo scadere del
quale la sessione viene automaticamente chiusa. Unistanza della classe HTTPSession
notevolmente utile per poter mantenere in memoria una mappa di variabili, associate
ad un unico client, per tutta la durata della sessione. Tali variabili non sono
assolutamente visibili da parte di altri client.
La classe ServletContext rappresenta il contesto dellapplicazione Web in cui la
Servlet viene eseguita. Essa risulta utile per garantire la comunicazione tra pi Servlet
facenti parte della stessa applicazione oppure per poter mantenere in memoria una
serie di variabili che saranno condivise tra pi client.
20
_________________________________________________________________
Per quanto riguarda la comunicazione tra pi Servlet, capita frequentemente che una
Servlet debba inoltrare una richiesta ad unaltra Servlet. La problematica principale
che la Servlet chiamante non dispone di un riferimento alla Servlet chiamata e quindi
non ne pu invocare i suoi metodi. Le soluzioni possibili sono le seguenti :

- redirezione della risposta;
- inoltro allinterno del contenitore;

La prima soluzione corrisponde alla produzione di una risposta di tipo 3xx per
indicare al browser che necessario richiedere un URI diverso con lo svantaggio di
innescare una nuova richiesta HTTP.
La seconda soluzione prevede che una Servlet richieda al contenitore linoltro delle
richiesta, in modo che tutto resti confinato nellambito di ununica transazione
HTTP. Per eseguire questo compito la Servlet pu fare uso di unistanza della classe
RequestDispatcher che possibile ricavare dal ServletContext.

6. Web Application Frameworks

Il Model 2 pu essere considerato la base perfetta sulla quale fondare la
realizzazione delle Web application. Infatti, nello sviluppo di applicazione software
per il Web, molti sviluppatori hanno evidenziato come alcune parti di applicazioni
diverse basate sul Model 2, siano notevolmente simili. Un caso tipico il Controller
realizzato attraverso una o pi Servlet. Tali parti possono essere realizzate in modo
tale da poter essere riutilizzate pi volte, concetto che alla base di un design
pattern. Partendo, quindi, da un insieme di elementi precostituiti si ha a disposizione
un framework.
Per definizione, un framework caratterizzato da un insieme di classi e di interfacce
che possono essere usate ed eventualmente estese dagli sviluppatori e che
rappresentano le infrastrutture sulla base della quale realizzare una Web application.

21
_________________________________________________________________
Le motivazioni principali che spingono verso lutilizzo di un framework sono le
seguenti :

- possibilie disaccoppiare il Presentation layer e la business-logic in
componenti distinti;
- si dispone di un punto centrale di controllo;
- disponibile un set molto ricco di funzionalit;
- facilitato il testing delle singole unit del sistema e la sua manutenzione;
- c il supporto da parte di numerosi ambienti di sviluppo;
- c la garanzia di una buona stabilit;
- garantita lnternazionalizzazione dei contenuti;
- semplificata la validazione dei dati di input;

7. Struttura di una Web application in Java

Per definizione, una Web application una collezione di componenti
separati ma che possono comunicare fra loro, costituendo un software che possa
essere installato ed eseguito in un Web Container anche in maniera concorrente. Ci
vuol dire che pi istanze della stessa applicazione possono essere eseguite nel Web
Container, ma ovviamente necessario poter distinguere unistanza dallaltra
mediante URL e nomi differenti.
In generale, unapplicazione di questo tipo costituita dai seguenti componenti :

- Servlets;
- Pagine JSP;
- JavaBeans;
- Pagine HTML;
- File multimediali, quali (immagini, suoni, video, );
- Applets, fogli di stile (CSS) e file JavaScript;

Tipicamente, questi elementi sono disposti allinterno dellapplicazione secondo una
struttura gerarchica suddivisa in directory.
22
_________________________________________________________________
Partendo dalla radice (root) dellapplicazione, una directory di fondamentale
importanza la directory WEB-INF, nella quale vengono memorizzate le meta-
informazioni della Web application ed, in particolare, il deployment descriptor. Le
risorse in essa contenute non sono accessibili dal client, ma solo ed esclusivamente
dalle Servlet e dalle classi Java.
Allinterno di questa directory, ci sono le seguenti due directory :

- WEB-INF/classes : contiene i package e le relative classi Java che sono
utilizzate allinterno dellapplicazione;
- WEB-INF/lib : contiene i file JAR (Java Archive), allinterno dei quali ci
sono ulteriori classi distribuite nellapplicazione;

Al di l di queste directory che costituiscono la base della Web application, lo
sviluppatore pu poi organizzare tutte le risorse di questultima in ulteriori
sottodirectory della root, sulla base delle funzionalit e del loro tipo.
Inoltre, la piattaforma Java permette di distribuire unapplicazione Web mediante la
realizzazione di un file WAR (Web Archive) , nel quale sono incluse tutte le risorse di
questultima. Tale file pu essere facilmente distribuito su un qualsiasi Web Container
che si occupa, in maniera automatica, della sua scompattazione restituendo la
struttura originaria delle directory .

7.1 Web Application Deployment Descriptor

Il Web Application Deployment Descriptor un file XML, tipicamente
chiamato web.xml, allinterno del quale ci sono tutte le informazioni di configurazione
dellapplicazione, che vengono utilizzate dal Web Container in fase di start-up della
stessa.
Nellambito dellutilizzo di un framework, le informazioni principali che
costituiscono tale file sono le seguenti :

- definizione della Servlet che funge da Controller e mapping delle richieste su
di essa;
23
_________________________________________________________________
- dichiarazione dei parametri iniziali che sono passati alla Servlet in fase di
start-up;
- configurazione delle librerie di tag (Tag Libraries) da adottare;
- elenco dei file di benvenuto dellapplicazione (Welcome File List);
- utilizzo di eventuali filtri per il filtraggio delle richieste prima che vengano
passate alla Servlet Controller;

Per la definizione della Servlet che funge da Controller dellapplicazione, viene
utilizzato il tag <servlet>, mediante il quale vengono specificate le seguenti
informazioni :

- il nome da assegnare alla Servlet, mediante il quale fare riferimento ad essa
nel resto del file (<servlet-name>);
- la classe che definisce la Servlet (<servlet-class>);

Il passo successivo quello di fare in modo che, ciascuna richiesta di un certo tipo,
ad esempio verso risorse con una particolare estensione, vengano smistate dal Web
Container verso la Servlet specificata. Tale operazione nota come mapping, in
quanto viene eseguita una vera e propria mappatura fra le tipologie di richieste e la
Servlet. Per questo scopo, viene utilizzato il tag <servlet-mapping> allinterno del quale
sono specificate le seguenti informazioni :

- il nome della Servlet a cui inoltrare le richieste (<servlet-name>);
- elenco delle estensioni che devono avere le richieste per essere inoltrate alla
Servlet suddetta (<url-pattern>);

Considerando lutilizzo di un framework come Struts e JavaServer Faces, la Servlet
che funge da Controller ha un parametro iniziale che rappresentato dal file di
configurazione XML dellapplicazione. In questo modo, nella fase di start-up di
questultima, la Servlet del framework esegue loperazione di parsing e caricamento
del contenuto del file, allinterno della memoria. Per questo scopo, viene adottato il
tag <init-param>, mediante il quale possibile specificare un qualsiasi tipo di
24
_________________________________________________________________
parametro iniziale della Servlet, oltre allapplicazione particolare suddetta. Allinterno
del tag, possono essere definite le seguenti informazioni :

- nome del parametro (<param-name>);
- valore del parametro (<param-value>);

Generalmente, una Web application prevede lutilizzo dei normali tag HTML
allinterno delle proprie pagine ma anche eventualmente ulteriori tag appartenenti a
librerie particolari, come quelle che vengono fornite con i framework Struts e
JavaServer Faces. Per poter rendere disponibili tali librerie, esse vanno specificate
allinterno del file web.xml mediante lutilizzo del tag <taglib>, specificando le seguenti
informazioni :

- la locazione fisica del file TLD (Tag Library Descriptor) che contiene la
descrizione dei tag della libreria (<taglib-location>);
- un URI associato alla libreria, per includerla allinterno delle pagine ed evitare
di fare riferimento alla locazione fisica (<taglib-uri>);

Infine, possibile specificare un elenco di risorse, tipicamente pagine, che il Web
Container invia per una certa richiesta, se questultima non completa, ossia prevede
soltanto una parte dellURL. Ciascun file viene definito con il tag <welcome-file>,
allinterno del blocco <welcome-file-list>.

25
Capitolo II Il framework JavaServer Faces
_________________________________________________________________
C Ca ap pi it to ol lo o I II I I Il l f fr ra am me ew wo or rk k J Ja av va aS Se er rv ve er r F Fa ac ce es s

1 . Introduzione

JavaServer Faces (JSF) un framework per la realizzazione di Web
application secondo il pattern MVC (Model View Controller). In particolare, esso
mette a disposizione una serie di componenti server-side per la realizzazione della UI
(User Interface) dellapplicazione stessa.
Lelemento principale, che caratterizza la tecnologia JSF, lampio insieme delle classi
e delle relative API (Application Program Interface) che permettono di :

- definire i componenti dellinterfaccia utente (UI) e gestire il mantenimento
del relativo stato;
- gestire gli eventi che si verificano sui suddetti componenti, eseguirne la
conversione dei valori e la validazione degli stessi;
- specificare la navigazione fra le pagine allinterno della Web application;
- supportare linternazionalizzazione e laccessibilit;
- realizzare dei componenti personalizzati (Custom Components) che
estendono e potenziano le funzionalit delle classi base del framework;

Inoltre, JSF mette a disposizione due librerie di tag (Tag Libraries) :

- libreria HTML : per linserimento dei componenti della UI allinterno di una
pagina JSP, secondo il linguaggio HTML;
- libreria Core : per gestire il legame tra gli elementi dellinterfaccia utente e gli
oggetti di back-end dellapplicazione;

Inoltre, larchitettura complessiva si basa sullutilizzo delle Servlet, nelle versioni 2.3 e
2.4, cos come sulle JavaServer Pages nella versione 1.2.
26
_________________________________________________________________

Figura 1 - Architettura JSF

Attraverso lutilizzo di JSF, con il minimo sforzo, possibile ottenere i seguenti
vantaggi :

- gestire gli eventi che vengono generati dal lato client (client side), con oggetti
e codice lato server (server side);
- legare i componenti della UI con dati lato server;
- costruire uninterfaccia utente con componenti riutilizzabili ed estendibili;
- salvare e recuperare lo stato di ciascun componente della UI, attraverso il
particolare ciclo di vita di una richiesta JSF (Faces request);

Figura 2 - HTTP Request/Response

Unapplicazione realizzata con JSF pu essere ricondotta ad una qualsiasi Web
application realizzata con il linguaggio Java. Essa si basa fondamentalmente sulle
pagine JSP e sulle Servlets; basta considerare che lapplicazione stessa gestita
complessivamente attraverso una Servlet che in esecuzione in un Servlet Container.
27
_________________________________________________________________
Come si pu osservare dalla figura, linterfaccia utente che viene realizzata con JSF
in esecuzione sul server e viene visualizzata nella risposta al client.

Figura 3 - Comunicazione Client/Server

Per realizzare ciascuna pagina JSP e quindi la UI, possibile sfruttare i tag che la
tecnologia JSF mette a disposizione attraverso le sue librerie. Mediante tali tag,
direttamente dallinterfaccia utente, si referenziano tutti gli oggetti che compongono
la Web application, in particolare :

- gli oggetti che rappresentano i componenti della UI mappati attraverso una
serie di tag, direttamente sulle pagine JSP;
- gli oggetti event listeners, validators e converters, rispettivamente per la
gestione degli eventi, la validazione e la conversione associati ai componenti
della UI;
- gli oggetti che incapsulano le funzionalit specifiche dellapplicazione,
tipicamente realizzati attraverso dei JavaBeans;

Inoltre, lapplicazione pu fare uso di una serie di classi di helper, realizzate dallo
sviluppatore per accedere al back-end del sistema ed eventualmente ad una base di
dati. Infine, viene definito un file di configurazione dellapplicazione nel linguaggio
XML, facilmente gestibile e modificabile, per parametrizzare tutti gli aspetti di
funzionamento principali dellapplicazione stessa e le relative risorse.
Uno dei vantaggi principali che offre la tecnologia JavaServer Faces la separazione
fra il comportamento (Application processing layer Model) e la presentazione
28
_________________________________________________________________
(Presentation layer - View) di una Web application, per favorire il team-working
(lavoro di gruppo) separando i compiti degli sviluppatori software e dei designers.
Un ulteriore vantaggio caratterizzato dal fatto che la presentazione non prevede
lutilizzo di una particolare tecnologia o di un particolare linguaggio di markup, anche
se in generale si pu preferire far uso delle pagine JSP, considerando le librerie che
JSF mette a disposizione. E ovvio che, nel caso in cui si dovesse utilizzare un
particolare dispositivo client per accedere allapplicazione stessa, ad esempio un
cellulare in luogo di un personal computer, si pu prevedere uninterfaccia utente
realizzata con una tecnologia ed un linguaggio di markup differenti (WML in luogo
dellHTML).

Figura 4 - Accesso con dispositivi Client diversi

2. Teamworking

Grazie alla divisione strutturale che comporta JSF in una Web application,
lo sviluppo e la manutenzione di questultima possono procedere rapidamente e nel
modo pi semplice possibile.
In moltissimi team di sviluppo il singolo sviluppatore, talvolta, si occupa di numerosi
e differenti compiti che in alcuni casi non sono di sua stretta competenza. Mediante
la tecnologia JavaServer Faces possibile evitare ci, assegnando ad ogni
componente del team di sviluppo una sua responsabilit ben precisa.
29
_________________________________________________________________
Tipicamente, i membri assumono i seguenti ruoli :

- Page author : colui che usa un linguaggio di markup, come lHTML, ed ha
esperienza di sviluppo grafico per la realizzazione delle pagine. Con lutilizzo
di JSF, egli usa anche i tag delle librerie standard o delle librerie custom,
realizzate dagli sviluppatori del software;
- Application developer : sviluppa gli oggetti, i gestori degli eventi (event handlers
o event listeners), i validatori (validators) ed i convertitori (converters) ed in
alcuni casi anche le helper class per laccesso alle basi di dati;
- Component writer : ha esperienza con la progettazione dellinterfaccia utente
delle applicazioni e preferisce realizzare dei Custom Components per la UI,
estendendo le funzionalit degli Standard Components messi a disposizione
da JSF;
- Application architect : colui che definisce larchitettura dellapplicazione,
assicurandone la scalabilit, definendo la navigazione fra le pagine,
configurando i JavaBeans e registrando gli oggetti;
- Tools vendors : le case produttrici che realizzano gli ambienti di sviluppo che
supportano la tecnologia JSF, per poter realizzare linterfaccia utente in
maniera semplice, attraverso il Drag & Drop dei componenti;

Figura 5 - Teamworking

30
_________________________________________________________________
Infine, sviluppare una Web application con JSF, generalmente prevede i seguenti
passi fondamentali :

- Creare le pagine JSP utilizzando i componenti della UI ed i tags delle librerie
a disposizione;
- Definire la navigazione fra le pagine dellapplicazione stessa, modificando
opportunamente il file di configurazione dellapplicazione (faces-config.xml);
- Sviluppare i backing beans che implementano le funzionalit offerte;
- Aggiungere le informazioni riguardanti i backing beans allinterno del file di
configurazione dellapplicazione;

Questi compiti possono essere eseguiti rigorosamente in ordine oppure in parallelo,
garantendo comunque la possibilit di comunicazione fra le persone del team di
sviluppo. Ad esempio, colui che sviluppa le pagine deve comunque conoscere i nomi
degli oggetti (backing beans) che realizzano le funzionalit della Web application, per
richiamarli dalle pagine stesse, comunque disinteressandosi della loro
implementazione interna.

3. Modelli architetturali - Framework Models

Il framework JSF costituito da un insieme di classi che sono raggruppate
in modelli (models), in relazione a specifici aspetti realizzativi di una Web application.
In particolare :

- Execution Model;
- User Interface Component Model;
- Component Rendering Model;
- Conversion Model;
- Event and Listener Model;
- Validation Model;
- Navigation Model;

31
_________________________________________________________________
Ad essi va aggiunto il Backing Bean Management, il quale permette la realizzazione dei
backing beans (menaged beans) che implementano la business-logic dellapplicazione.
Di seguito, verranno descritti tali modelli mettendo in risalto quelle che sono le
caratteristiche principali delle classi che entrano in gioco per ciascuno di essi ed ,
inoltre, esplicitando la loro interazione che determina il funzionamento del
framework.

3.1 Execution Model

Questo modello fa riferimento a tutto ci che riguarda lesecuzione
dellapplicazione, quindi in particolar modo definisce le classi che costituiscono il
Controller del pattern MVC.

3.1.1 FacesServlet

La classe principale su cui si basa il funzionamento del framework la
classe FacesServlet. Questultima rappresenta la vera e propria Servlet in esecuzione nel
Web Container, che riceve le richieste da parte dei client occupandosi della loro
gestione ed assumendo quindi il ruolo di Controller secondo il modello MVC.
Come tutte le Servlet, secondo limplementazione in Java, essa prevede i metodi di
inizializzazione (init()), servizio di una richiesta (service()) e di distruzione (destroy()),
mediante i quali viene avviata dal Web Container allarrivo della prima richiesta, serve
questultima e tutte le richieste successive e viene infine distrutta, tipicamente nei casi
in cui il Web Container venga interrotto o riavviato.
La FacesServlet va configurata nel Deployment Descriptor web.xml tipico di ogni Web
Application realizzata in Java :

<ser vl et >
<ser vl et - name>FacesSer vl et </ ser vl et - name>
<ser vl et - cl ass>j avax. f aces. webapp. FacesSer vl et </ ser vl et - cl ass>
<l oad- on- st ar t up>1</ l oad- on- st ar t up>
</ ser vl et >

32
_________________________________________________________________
Viene specificata la classe e quindi un nome da assegnare alla Servlet, nonch un
ordine di sequenza di start-up, nel caso in cui la Web Application preveda lutilizzo di
pi Servlet per poter gestire richieste di tipo diverso.
Ovviamente la FacesServlet ha il compito di gestire le richieste per file del tipo .jsf
oppure .faces e per questo motivo necessario specificarne il mapping su di esse :

<ser vl et - mappi ng>
<ser vl et - name>FacesSer vl et </ ser vl et - name>
<ur l - pat t er n>*. j sf </ ur l - pat t er n>
</ ser vl et - mappi ng>

Con questa configurazione, ogni qualvolta giunge una richiesta di una pagina .jsf al
Web Container, questultimo passa tale richiesta alla FacesServlet che si occuper di
gestirla.

3.1.2 Lifecycle - PhaseListener

Ogni richiesta di tipo JSF (Faces Request), che arriva alla Web application,
ha un proprio ciclo di vita (lifecycle) che prevede lesecuzione di una serie di fasi, fino
alla determinazione della risposta. Di tali operazioni, si occupa la classe Lifecycle che
riceve ciascuna richiesta dalla FacesServlet ed esegue le varie fasi, mediante il proprio
metodo execute().
Inoltre, ad essa associata linterfaccia PhaseListener, la quale permette di notificare
linizio e la fine di ciascuna fase. Tale interfaccia rappresenta un punto di estensione
del framework, in quanto possibile definire alcune elaborazioni specifiche da
eseguire prima o dopo una certa fase. Per fare ci, necessario realizzare una classe
che implementi linterfaccia PhaseListener ed esegua loverriding dei metodi
beforePhase() ed afterPhase(), allinterno dei quali sar contenuto il codice da eseguire.
Tale classe va poi associata ad una specifica fase e legata allistanza di Lifecycle, in
modo che, prima o dopo questa fase, saranno eseguite le elaborazione richieste.

33
_________________________________________________________________
3.1.3 Application

La classe Application di tipo singleton ed il suo scopo quello di
descrivere interamente la Web application ed in particolare i parametri di questultima
che sono specificati nel file di configurazione faces-config.xml.
In pratica, allavvio dellapplicazione, viene eseguita la lettura mediante un parsing
XML, del file di configurazione e tutte le informazioni in esso contenute vengono
caricate allinterno delle propriet corrispondenti della classe Application. In questo
modo, durante lesecuzione dellapplicazione possibile accedere a queste
informazioni ed eventualmente modificarle.
Le classi principali che sono legate ad essa e che vengono specificate nel file faces-
config.xml sono le seguenti :

- ActionListener : per la gestione degli action events;
- NavigationHandler : il cui scopo quello di gestire la navigazione fra le pagine
sulla base delle navigation-rules e degli outcome;
- ViewHandler : ha il compito di gestire le fasi di ricostruzione della vista di una
pagina da uno stato precedente e di visualizzare una risposta, anche sulla base
di dispositivi client di accesso differenti;
- StateManager : per il salvataggio ed il ripristino dello stato dellapplicazione fra
una richiesta ed unaltra;
- MessageBundle : che identifica il file .properties nel quale ci sono tutti i messaggi
da visualizzare nellapplicazione, sulla base di un certo Locale, permettendo
linternazionalizzazione;
- Lifecycle, PhaseListener : per la gestione del ciclo di vita di ciascuna richiesta;

Se tali classi non vengono specificate nel file faces-config.xml, verranno utilizzate quelle
di default. In caso contrario, lo sviluppatore ha la possibilit di personalizzare il
framework, estendendo queste classi e specificando le proprie classi cos ottenute nel
file di configurazione. In questo modo, ad esempio, possibile realizzare un proprio
NavigationHandler che esegua delle operazioni particolari prima di far proseguire la
navigazione. Lo stesso tipo di operazione pu essere eseguita per le altre classi.
34
_________________________________________________________________
Altre informazioni associate alla classe Application e quindi contenute nel file faces-
config.xml, specificano il Renderer Kit di default per la visualizzazione delle pagine e
linternazionalizzazione, definendo il Locale di default e tutti quelli supportati.
Infine, essa legata a tutte quelle classi che definiscono gli elementi costitutivi
dellapplicazione, in particolare :

- UIComponent : che definisce ciascun componente dellinterfaccia utente
insieme a tutte le sue classi derivate;
- Validator : che implementa un validatore per i dati di input dellutente;
- Converter : che permette di eseguire la conversione dei dati;
- MethodBinding, ValueBinding : che associano i componenti ed i loro valori, ai
metodi o alle propriet dei backing beans;

3.1.4 FacesContext - ExternalContext

La classe FacesContext definisce il contesto dellapplicazione, nel senso che
contiene tutte le informazioni che caratterizzano una richiesta e ci che riguarda la
relativa risposta da generare. Essa viene potenzialmente modificata in ciascuna fase
del ciclo di vita di una richiesta, per garantire che il contesto sia sempre aggiornato.
E ovviamente legata alla classe Application, in quanto possibile ricavare listanza di
questultima direttamente dalla classe FacesContext, facendo uso del metodo
getApplication(). Oltre alle informazioni che riguardano lapplicazione, essa legata
anche a tutte quelle classi che si occupano in particolare della fase di rendering e
quindi di produzione della risposta per una specifica richiesta.
Nella fattispecie tali classi sono :

- UIViewRoot : rappresenta il nodo radice della view che definisce lalbero dei
componenti di una certa pagina;
- RenderKit : una collezione di istanze della classe Renderer che si occupano di
visualizzare i componenti dellinterfaccia utente, secondo una certa grafica, in
relazione al dispositivo client che viene utilizzato per accedere allapplcazione,
il linguaggio di markup ed il Locale corrente;
35
_________________________________________________________________
- ResponseWriter : definisce uno stream attraverso il quale possibile produrre,
direttamente in una pagina di risposta, degli elementi ed i corrispondenti
attributi come per i linguaggi HTML ed XML;
- FacesMessage : classe che contiene un singolo messaggio associato ad un
componente specifico e che va visualizzato in una pagina. Il messaggio in
questione pu essere tipicamente un messaggio di errore, ad esempio dovuto
ad una validazione o conversione errata, ma anche di un qualsiasi altro tipo;

Infine, attraverso il metodo getExternalContext(), possibile ricavare listanza della
classe ExternalContext, la quale definisce il contesto esterno, ossia tutto ci che
riguarda lambiente in cui viene eseguita lapplicazione. Da questa classe possibile
accedere direttamente a tutte le variabili il cui ambito di visibilit (scope) sia quello di
tipo session, request ed application e quindi ai parametri ed agli attributi di una richiesta.

Figura 6 - Class Diagram Execution Model
36
_________________________________________________________________
3.2 User Interface Component Model

La tecnologia JSF mette a disposizione una serie di classi relative ai
componenti della UI e le corrispondenti interfacce che ne descrivono il
comportamento (behavioral interfaces) e le funzionalit, oltre al mantenimento dello
stato, i riferimenti agli oggetti (backing beans) e la gestione degli eventi.
Tali classi possono essere estese, permettendo allo sviluppatore di potenziare i
componenti standard, aggiungendovi nuove funzionalit.
La classe di base da cui derivano tutte le classi per i componenti standard
UIComponentBase, la quale definisce lo stato ed il comportamento di default di un
generico componente ed a sua volta estende la classe UIComponent.
Di seguito sono riportate tutte le classi che descrivono i componenti previsti in JSF :

- UIColumn : generica colonna del componente UIData;
- UICommand : controllo che pu intercettare un action event (es. click del
mouse) quando viene attivato;
- UIData : permette di gestire un binding con una collection di dati per la
loro visualizzazione. Tale collection pu essere eventualmente definita con un
DataModel;
- UIForm : permette di raggruppare pi controlli di una pagina e definire,
appunto, un form di invio delle informazioni contenute. E paragonabile al
tag form dell HTML;
- UIGraphic : immagine da visualizzare in una pagina;
- UIInput : permette di acquisire uninformazione di input dallutente;
- UIMessage : permette la visualizzazione di un messaggio anche sulla base della
localizzazione geografica dellutente (internazionalizzazione);
- UIMessages : come il precedente, ma permette di visualizzare un gruppo di pi
messaggi;
- UIOutput : visualizza uninformazione di output in una pagina;
- UIPanel : permette di raggruppare pi componenti secondo un certo layout;
- UIParameter : usato insieme ad altri componenti per specificare una serie di
parametri da passare ad essi;
37
_________________________________________________________________
- UISelectBoolean : controllo che permette allutente di selezionare un valore
booleano;
- UISelectItem : definisce una singola item di una collection di items;
- UISelectItems : definisce un insieme di items;
- UISelectMany : permette allutente di selezionare una o pi items da una
collection di items;
- UISelectOne : permette allutente di selezionare una sola item nellambito di
una collection di items a disposizione;
- UIViewRoot : rappresenta il nodo radice dellalbero dei componenti che,
secondo una gerarchia, costituiscono una pagina;

Le classi suddette, oltre ad estendere la classe base UIComponentBase, implementano
anche una serie di interfacce che ne definiscono il comportamento :

- ActionSource : indica che un componente pu intercettare un actionevent;
- ValueHolder : indica che un componente pu immagazzinare un local-value
cos come ha la possibilit di accedere al dato corrispondente allinterno del
Model;
- EditableValueHolder : estende ValueHolder aggiungendo ulteriori funzionalit ai
componenti editabili, tra cui la validazione e lintercettazione di eventi del
tipo value-change;
- NamingContainer : fa in modo che ciascun componente abbia un identificativo
univoco;
- StateHolder : segnala che un componente ha uno stato che va salvato ad ogni
richiesta;

In generale, la classe UICommand implementa ActionSource e StateHolder. La classe
UIOutput e tutte le classi che la estendono, implementano StateHolder e ValueHolder.
La classe UIInput e tutte le classi che la estendono, implementano StateHolder,
ValueHolder ed EditableValueHolder.
Per la realizzazione di un componente personalizzato (Custom Component) ,
necessario estendere la classe UIComponentBase oppure una delle sue classi derivate in
modo da sfruttare le potenzialit di queste ultime ed aggiungerne delle altre.
38
_________________________________________________________________
Infine, per poter introdurre un componente allinterno di una pagina, necessario
associare ad esso un tag realizzato mediante una classe nota come Tag Handler. Tale
classe , in generale, unestensione della classe UIComponentTag e definisce gli
attributi del tag stesso.

Figura 7 - Class Diagram UI Component Model / Rendering Model

39
_________________________________________________________________
3.3 Component Rendering Model

Larchitettura dei componenti, messi a disposizione dalla tecnologia JSF,
prevede che le funzionalit degli stessi, cos come lo stato ed il comportamento,
vengano definite con le classi e le interfacce precedentemente viste, mentre la
visualizzazione, il cosiddetto rendering, venga realizzata mediante altre classi
specifiche note come renderer.
Questa separazione comporta i seguenti vantaggi :

- coloro che scrivono i componenti (Component writers) possono definire una
sola volta il comportamento di un componente, mediate ununica classe, ma
possono permetterne diverse visualizzazioni, mediante molteplici renderers,
in relazione ai tanti dispositivi client che possono accedere alla Web
application;
- coloro che realizzano le pagine (Page authors) e coloro che sviluppano
lapplicazione (Application developers) possono scegliere la grafica di un
certo componente, utilizzando un tag che individui la giusta combinazione fra
la classe del componente stesso ed il renderer appropriato;

Un Renderer Kit definisce una mappatura fra le classi dei componenti ed i tag che
permettono di inserire questi ultimi nella UI, anche in base al dispositivo client di
accesso alla Web application. Le varie implementazioni di JSF, forniscono un
Renderer Kit standard per i client HTML, il quale permette di inserire i componenti
della UI allinterno di una pagina JSP attraverso opportuni tag.

3.3.1 Renderer

Questa classe permette di definire un renderer associato ad un
componente. Essa converte la rappresentazione interna di un oggetto UIComponent in
una rappresentazione grafica, attraverso uno stream di output sulla pagina.
Mediante la realizzazione di una o pi classi che estendono la classe Renderer, si
possono realizzare diversi renderers che cambiano la modalit di visualizzazione dello
stesso componente in base alle necessit o al dispositivo client di accesso.
40
_________________________________________________________________
Ad esempio, un componente della classe UISelectOne ha tre renderers associati : il
primo che visualizza il componete come un insieme di radio buttons, il secondo
come una combo box e lultimo come una list box. Il comportamento del
componente sempre il medesimo, ossia la definizione di una lista di items e la
possibilit allutente di selezionarne una di esse, ma le modalit di visualizzazione
sono molteplici.
In definitiva, ogni tag della libreria HTML che JSF mette a disposizione, associato
ad una classe che definisce le funzionalit del componente (UIComponent) e ad una
classe che ne permette la visualizzazione (Renderer).
Un esempio tipico la classe UICommand la cui funzionalit principale quella di
intercettare un action event (es. click del mouse) e permettere un invio di
informazioni, cos come il passaggio da una pagina allaltra. Questo scopo pu essere
raggiunto attraverso un link oppure un bottone. Questi ultimi hanno due tag
associati per la loro visualizzazione e quindi due classi Renderer diverse, che ne
permettono una grafica differente, pur basandosi sulla medesima classe componente
(appunto UICommand).

UICommand
h:commandLink
h:commandButton
Figura 8 - Rendering UICommand

Inoltre, come gi anticipato, un insieme di classi Renderer costituiscono un Renderer
Kit associato ad uno specifico dispositivo di accesso alla Web application, il quale si
basa su un determinato linguaggio di markup.
Infine, per quanto concerne la produzione degli elementi da visualizzare nella pagina,
viene utilizzata la classe ResponseWriter che rappresenta uno stream di scrittura verso
la pagina stessa.

41
_________________________________________________________________
3.4 Conversion Model

In una Web application realizzata con JSF, generalmente ogni componente
associato ad un oggetto server side, tipicamente realizzato mediante un JavaBean,
che in particolare viene definito backing bean o managed bean. Nellambito
dellapplicazione, si accede ai valori memorizzati dai componenti, utilizzando i
metodi getter e setter delle propriet corrispondenti dei backing beans associati. Ci
vuol dire che , nel momento in cui un componente legato ad un backing bean,
esistono due viste del dato relativo :

- model view (model value) : il valore rappresentato secondo un certo tipo di dato
allinterno della propriet del backing bean (es. tipo int, long, ..) ;
- presentation view (local value) : il valore rappresentato secondo una modalit per
cui pu essere letto e modificato dallutente.

Ad esempio, un componente potrebbe prevedere limmissione di una data da parte
dellutente. Il valore del componente associato alla propriet del backing bean
legato al componente stesso. La data sarebbe rappresentata come un oggetto
java.util.Date allinterno del backing bean (model view) ma attraverso una stringa del
tipo yyyy-mm-dd nel componente (presentation view).
Limplementazione JSF effettua automaticamente la conversione tra una vista e
laltra, ovviamente quando la propriet del backing bean associato al componente di
un tipo di dato tra quelli ammessi dal componente stesso.
In alcuni casi, possibile che una propriet di un backing bean, non sia di un tipo di
dato standard tra quelli previsti dal linguaggio Java, ma sia un di un tipo di dato,
magari una classe, definito dallo sviluppatore. In queste situazioni, associando il
backing bean ad un componente, si rende necessaria la realizzazione di un opportuno
convertitore, che ovviamente non fornito nellimplementazione di JSF.
Questa operazione possibile sviluppando una classe che implementi linterfaccia
Converter e specificando la modalit con cui questa debba realizzare la conversione da
una vista allaltro dei dati. In tal modo, si implementano dei convertitori
personalizzati (Custom Converters).

42
_________________________________________________________________
3.4.1 Converter

E linterfaccia che deve essere implementata da una classe per poter
eseguire una conversione Object-to-String (da model view a presentation view) e
quella inversa String-to-Object (da presentation view a model view).
Le implementazioni JSF mettono a disposizione una serie di classi standard che
implementano tale interfaccia per lesecuzione delle conversioni per i tipi di dato
semplici.
Ad essa legata anche la classe ConverterException che definisce uneccezione che pu
essere sollevata nel momento in cui, per un qualsiasi motivo, la conversione eseguita
attraverso i metodi del converter non vada a buon fine. In tal caso, verr creato
automaticamente un oggetto FacesMessage, contenente il messaggio che segnala
lerrore, che verr memorizzato nel FacesContext e visualizzato allutente.
Inoltre, essa caratterizzata fondamentalmente da due soli metodi getAsObject() e
getAsString() che eseguono le conversioni in un verso e nellaltro.
Infine, per poter associare un converter ad un componente dellinterfaccia utente,
necessario definire un tag mediante la classe ConverterTag.

Figura 9 - Class Diagram Conversion Model

43
_________________________________________________________________
3.5 Event and Listener Model

Il modello che definisce gli eventi (events) ed i relativi gestori (listeners o
handlers) di JSF molto simile al modello degli eventi dei JavaBeans, in quanto
fortemente tipizzato e basato su una serie di classi e di interfacce che permettono di
intercettare e gestire gli eventi dei componenti della UI.
Un oggetto Event identifica il componente su cui si scatenato levento e memorizza
le informazioni dellevento stesso. Per notificare il verificarsi di un evento, una Web
application deve prevedere un oggetto della classe Listener che va registrata sul
componente in questione. Nel momento in cui lutente, interagendo con la UI, fa
scatenare levento sul componente, entra in gioco il listener che si occupa di gestire
levento.
La tecnologia JSF supporta tre tipi di eventi :

- action event : si scatena quanto lutente attiva un componente che implementa
linterfaccia ActionSource, come nel caso di bottoni o collegamenti ipertestuali
(link);
- value-change event : si verifica quando lutente cambia il valore di un
componente implementato dalla classe UIInput o da una delle sue sottoclassi,
come il caso dei semplici campi di testo, checkbox, radio buttons, list box,
combo box e drop-down list;
- data-model event : si scatena quando c uno spostamento ad una nuova riga in
un componente della classe UIData;

Ci sono due modalit per poter gestire un evento :

- implementare una classe listener e registrarla sul componente di interesse
utilizzando gli attributi actionListener oppure valueChangeListener del tag del
componente stesso;
- implementare allinterno del backing bean associato al componente, un
metodo che debba gestire levento;

44
_________________________________________________________________
3.5.1 FacesEvent

E la classe base che definisce il generico evento che si pu verificare su un
componente dellinterfaccia utente e memorizza tutte le informazioni che riguardano
proprio questultimo.
Da essa derivano due sottoclassi :

- ActionEvent : che definisce un action event;
- ValueChangeEvent : che notifica il verificarsi di un value-change event;

Ovviamente, tale classe legata al generico UIComponent su cui levento stato
intercettato.

3.5.2 FacesListener

E linterfaccia mediante la quale possibile realizzare una classe che abbia
la capacit di gestire un generico FacesEvent.
Da essa derivano due interfacce :

- ActionListener : interfaccia capace di gestire un action event;
- ValueChangeListener : interfaccia per la gestione di un value-change event;

Ovviamente, esse utilizzano rispettivamente le classi ActionEvent e ValueChangeEvent,
per avere informazioni sullevento che ciascuna di esse deve gestire.
Inoltre, quando lo sviluppatore ha la necessit di realizzare dei propri listeners per
gestire dei particolari eventi, pu realizzare delle classi che implementano le
interfacce suddette.
Infine, le interfacce e le classi listeners in questione sono legate alla classe
AbortProcessingException, che rappresenta leccezione che pu essere sollevata nel
momento in cui si verifichi un errore durante la gestione di un evento.

45
_________________________________________________________________

Figura 10 - Class Diagram Event and Listener Model

3.6 Validation Model

La tecnologia JSF fornisce un particolare meccanismo per la validazione del
local value di un componente editabile (es. campo di testo). Tale validazione viene
eseguita prima che il model value corrispondente venga aggiornato ed assuma come
valore proprio il local value.
Come nel caso del Conversion Model, anche il Validation Model fornisce una serie di
classi standard per effettuare le operazioni di validazione. Inoltre, allinterno della
Core Library di JSF, ci sono dei tag che permettono di utilizzare tali validatori in una
pagina JSP, associandoli ai componenti.

46
_________________________________________________________________
E comunque possibile realizzare dei validatori personalizzati (Custom Validators),
nel seguenti modi :

- realizzare una classe che implementa linterfaccia Validator, registrarla
allinterno dellapplicazione e definire un tag che permetta di utilizzare il
validatore in una pagina JSP, associandolo ad un componente;
- implementare allinterno del backing bean associato al componente, di cui
fare la validazione del valore, un metodo che la esegua;

3.6.1 Validator

E linterfaccia che viene implementata da una qualsiasi classe che debba
eseguire delle operazioni di validazione, attraverso loverriding dellunico metodo
validate().
Le implementazioni JSF forniscono una serie di classi standard che possono eseguire
delle semplici validazioni, in particolare :

- LengthValidator : per verificare se il valore di un componente ha una
lunghezza che rientra nei limiti specificati;
- LongRangevalidator, DoubleRangeValidator : per verificare se il valore di tipo long
o double di un componente, rientra in un range prefissato;

E possibile, ovviamente, realizzare un validatore personalizzato (Custom Validator)
implementando questa interfaccia.
Inoltre, il metodo validate() che esegue la vera e propria validazione, pu sollevare
uneccezione del tipo ValidatorException nel momento in cui si verificato un
problema nel processo di validazione.
Infine, ovvio che a ciascun validator associato un tag, in modo da poterlo
utilizzare in una pagina JSP in relazione ad uno specifico componente. La classe che
permette di realizzare il Tag Handler corrispondente la classe ValidatorTag.

47
_________________________________________________________________

Figura 11 - Class Diagram Validation Model

3.7 Navigation Model

Tipicamente, una Web application costituita da un insieme di pagine. Una
delle prime operazioni da eseguire nellambito dello sviluppo, quella di definire la
navigazione fra di esse.
Nellambito della tecnologia JSF, la navigazione (navigation) tra le pagine definita
da una serie di regole (navigation-rules) che individuano la pagina successiva dopo aver
cliccato su un bottone oppure su un link. Tali regole sono definite allinterno del file
di configurazione dellapplicazione, mediante una serie di elementi XML.
Per definire la navigazione bisogna :

- specificare le regole di navigazione, ciascuna delle quali indica a partire da una
certa pagina, quale sia la pagina successiva verso la quale proseguire;
- definire in corrispondenza dei bottoni e dei link, il cosiddetto outcome ossia
una stringa che permette di selezionare una tra le regole ammesse e quindi
permettere la navigazione;

48
_________________________________________________________________
Ad esempio, quando si clicca su un bottone oppure su di un link, viene generato un
action event gestito dallistanza ActionListener di default, che invoca un action-
method, implementato allinterno di un backing bean. Tale metodo esegue
eventualmente unelaborazione e determina loutcome che viene passato al
NavigationHandler di default, il quale analizza le regole di navigazione, cerca loutcome
che gli stato fornito ed individua la pagina successiva.
Ciascuna navigation-rule specifica come eseguire la navigazione da una certa pagina
verso tutta unaltra serie di pagine, attraverso delle casistiche di navigazione
(navigation-cases). Ciascun navigation-case, allinterno di una navigation-rule, specifica una
pagina di destinazione e loutcome che permette di referenziarla per proseguire la
navigazione.

3.8 Backing Bean Management

Una funzione particolarmente critica di una Web application la gestione
delle risorse disponibili. Ci prevede una separazione degli oggetti che definiscono i
componenti della UI e gli oggetti che implementano le funzionalit disponibili.
Unapplicazione JSF prevede una serie di backing beans, che sono associati ai
componenti dellinterfaccia utente in una pagina JSP. Un backing bean associato ad
uno o pi componenti della UI, in quanto ciascuna delle sue propriet legata al
valore del componente stesso oppure ad una sua istanza. Inoltre, il bean pu avere
dei metodi che permettono di eseguire ulteriori elaborazioni sui componenti, come
la validazione, la gestione degli eventi e il processo di navigazione.
Il binding tra il valore di un componente della UI oppure di una sua istanza e le
propriet di un backing bean, viene realizzato con la sintassi dellExpression
Language (EL), cos come possibile esprimere il riferimento ad un metodo del
backing bean dal componente stesso. Nel primo caso si parla di value-binding, mentre
nel secondo di method-binding.
Se si considera un componente dellinterfaccia utente, immesso in una pagina JSP
mediante luso di un particolare tag, il suo valore sar legato ad una propriet di un
backing bean mediante lattributo value, referenziando tale propriet mediante lEL.
In questo modo, il componente avr un suo local value ed il corrispondente model
value sar memorizzato nella propriet del bean.
49
_________________________________________________________________
Nel caso in cui si voglia associare listanza del componente e non il suo valore, ad
una propriet di un backing bean, si pu utilizzare lattributo binding.
Inoltre, possibile utilizzare gli attributi validator, actionListener e valueChangeListener per
fare riferimento ad alcuni metodi dei backing bean, per poter eseguire delle
operazioni di validazione e per poter gestire gli eventi del tipo action e value-
change. Ad esempio, considerando un campo di testo il cui valore deve essere
trasferito nella propriet di un backing bean, dopo essere stato validato attraverso un
metodo di questultimo, la sintassi del tag <h:inputText> la seguente :

<h: i nput Text i d=" i dCampoTest o"
val ue=" #{backi ngBean. pr opr i et a}"
val i dat or =" #{backi ngBean. met odoVal i dazi one}"
val ueChangeLi st ener =" #{backi ngBean. met odoEvent o}" / >

Sulla base di questa definizione, se il valore del componente subisce un cambiamento
ed il form che lo contiene viene trasmesso, si scatena un value-change event che
verr gestito dal metodo del backing bean specificato.
Infine, nel momento in cui si ha a che fare con un componente che implementa
linterfaccia ActionSource (es. bottone o link), si pu utilizzare lattributo action per
specificare il metodo di un backing bean che esegue una certa elaborazione e fornisce
come risultato un outcome per proseguire la navigazione in una certa direzione.

<h: commandBut t on i d=" i dBot t one" act i on=" #{backi ngBean. met odo}" / >

Eseguire binding fra listanza di un componente e la propriet di un bean, ha i
seguenti vantaggi :

- il bean pu modificare gli attributi del componente durante lesecuzione;
- il bean pu istanziare un componente;

Invece, eseguire il binding fra il valore del componente e la propriet del bean, ha i
seguenti vantaggi :

- colui che ha realizzato la pagina ha pi controllo sugli attributi dei
componente;
50
_________________________________________________________________
- i backing beans non sono legati alle classi dei componenti e quindi si ha una
netta separazione fra Model e View;
- limplementazione JSF pu realizzare la conversione tra il valore del
componente e la relativa propriet del backing bean in maniera automatica,
senza che lo sviluppatore debba realizzare un convertitore, se non in casi
particolari;

I backing beans sono configurati nel file faces-config.xml che viene valutato allavvio
dellapplicazione, rendendo disponibili tali beans che vengono poi istanziati quando
sono referenziati allinterno dei tag.

<managed- bean>
<managed- bean- name>backi ngBean</ managed- bean- name>
<managed- bean- cl ass>
package. Cl asseBacki ngBean
</ managed- bean- cl ass>
<managed- bean- scope>r equest </ managed- bean- scope>
</ managed- bean>

Gli ambiti di visibilit (scope) in cui sono accessibili i backing beans, sono :

- request : un bean accessibile soltanto in corrispondenza di una richiesta
HTTP;
- session : un bean visibile durante unintera sessione utente;
- application : un bean condiviso ed accessibile fra tutti gli utenti che accedono
allapplicazione;

Figura 12 - Dichiarazione Backing Beans

51
_________________________________________________________________
Quando un backing bean viene referenziato allinterno di una pagina JSP, esso viene
cercato dallimplementazione JSF in tutti i possibili ambiti di visibilit.
La presenza dei backing beans introduce in JSF, luso dei pattern Inversion of Control
(IoC), noto anche come Dependency Injection. Tale pattern prevede che, nellambito
della realizzazione di un software, ci sia sempre una classe nota come container che
ha il compito di istanziare gli oggetti della business-logic e gestirne la dipendenza e lo
scambio di dati fra essi. Nel framework JSF, tutto ci accade in maniera
assolutamente automatica, in virt del fatto che i backing beans vengono istanziati
nellambito di visibilit corretto, nel momento in cui si fa riferimento ad essi
attraverso il value-binding o method-binding. Lo sviluppatore non ha pi lonere di gestire
lallocazione degli oggetti nel momento in cui ne ha bisogno, perch il tutto viene
gestito dal framework in maniera completamente trasparente.

4. Ciclo di vita di una pagina JavaServer Faces

Il ciclo di vita (life-cycle) di una pagina JSF molto simile a quello di una
normale pagina JSP. Il client invia una richiesta HTTP per ricevere una certa pagina
ed il server invia tale pagina trasformata in HTML. In realt, considerando le
potenzialit in pi offerte dalla tecnologia JSF, sono previste alcune elaborazione
aggiuntive.
Una pagina JSF rappresentata da un albero dei componenti che costituiscono
linterfaccia utente, chiamato view, caratterizzato da una gerarchia ben definito.
Ad esempio, nella figura che segue, la pagina contenente il form di Login avr :

- il nodo root dellalbero;
- il nodo relativo al form, legato al nodo root;
- allinterno del nodo del form, i nodi associati ai tre seguenti componenti : due
campi di testo ed un bottone;

Ovviamente, questa soltanto una parte della pagina, che potrebbe contenere
ulteriori componenti.
52
_________________________________________________________________
:UIViewRoot
:UIForm
:UIInput :UIInput :UICommand
loginForm
userName password loginButton

Figura 13 - Esempio struttura della view

Quando il client richiede la pagina, inizia il life-cycle e limplementazione JSF
costruisce la view, tenendo conto dello stato degli oggetti relativo ad una richiesta
precedente della pagina stessa (viene ricostruito lultimo stato della pagina). Il client
interagisce con la pagina ed invia i dati; limplementazione JSF esegue la validazione
di questi ultimi e la conversione dei valori in tipi validi dal lato del server. Infine,
vengono eseguite le funzionalit della Web application e proposti i risultati al client,
nella forma della pagina HTML risultante.

4.1 Scenari di elaborazione di una richiesta

Unapplicazione JSF supporta due tipi di richieste (request) e due tipi di (response) :

- Faces response : risposta generata durante la fase di Render Response del ciclo di
vita di una request;
53
_________________________________________________________________
- Non-Faces response : risposta che non creata durante la fase di Render Response
del ciclo di vita di una request; caso tipico quello di una pagina JSP che non
contiene componenti JSF;
- Faces request : una richiesta che viene inviata da una Faces response generata in
precedenza;
- Non-Faces request : richiesta inviata ad un elemento come una Servlet o una
pagina JSP e non direttamente ad un componente dellalbero dei componenti
JSF di una pagina;

La differenziazione delle richieste e delle risposte suddetta, da luogo a tre possibili
scenari del ciclo di vita di una richiesta :

Scenario 1 : Non-Faces request genera una Faces response

Un esempio tipico si verifica nel momento in cui si clicca su semplice link
HTML per aprire una pagina JSF. In questo caso, entra in gioco il Controller della
tecnologia JSF, ossia una Servlet della classe FacesServlet che accetta la richiesta e la
passa alla classe che implementa il ciclo di vita della stessa per elaborarla. Quando
deve essere generata la Faces response, lapplicazione acquisisce i riferimenti agli oggetti
necessari alla view, memorizza questultima nel FacesContext (contesto contenente tutte
le informazioni della richiesta) ed invoca il metodo renderResponse(), passando alla fase
Render Response.

Scenario 2 : Faces request genera una Non-Faces response

Talvolta, unapplicazione JSF pu avere la necessit di generare una
response che non contiene componenti della tecnologia JavaServer Faces. In queste
situazioni, lo sviluppatore deve saltare la fase di Render Response invocando il metodo
responseComplete() della classe FacesContext. Tale chiamata pu avvenire in una delle
seguenti fasi : Apply Request Value, Process Validations, Update Model Values.

54
_________________________________________________________________
Scenario 3 : Faces request genera una Faces response

Questo lo scenario tipico, che segue il ciclo di vita standard di una
richiesta, in cui un componente JSF invia una request ad unapplicazione JSF
utilizzando la FacesSarvlet. Tutti i listeners, validators e converters sono invocati nella
fase opportuna del ciclo di vita stesso.

4.2 Ciclo di vita Standard

Il ciclo di vita standard di una richiesta quello dello terzo scenario, che
stato introdotto in precedenza. La tecnologia JSF permette di gestire due tipologie di
richieste : richiesta iniziale (initial request) e postback. Linitial request caratterizzata dal
fatto che il client richiede per la prima volta una certa pagina, mentre un postback
scaturisce dallinvio di un form che stato generato da uninitial request precedente.
Quando deve essere gestita uninitial request, vengono eseguite solo le fasi di Restore
View e Render Response, perch non ci sono azioni da processare, mentre nel caso di
un postback vengono eseguite nellordine tutte le fasi.

Figura 14 - Ciclo di vita Standard

55
_________________________________________________________________
4.2.1 Restore View

Una richiesta per una pagina JSF viene generata nel momento in cui si
clicca su di un link oppure su di un bottone inviando le informazioni di un form; in
entrambe le situazioni viene avviata la prima fase del life-cycle, la Restore View.
Durante questa fase, viene costruita la view della pagina (albero degli oggetti associati
ai componenti della UI), vengono associati gli events handlers (listener), i validators
ed i converters ai componenti ed infine la view viene memorizzata nel FacesContext,
che avr tutte le informazioni per gestire la richiesta.
Se si tratta di una initial request viene creata una view vuota e si passa direttamente alla
fase di Render Response. Tale view vuota sar popolata quando, ad esempio, lutente
immetter dei dati in un form e verr comandato un postback.
Se si tratta di un postback, la view precedente relativa alla pagina gi esiste e viene
recuperata, utilizzando le informazioni di stato dei componenti della UI che sono
salvate sul client oppure sul server (per default).

4.2.2 Apply Request Values

Dopo aver recuperato lalbero dei componenti (view), ogni componente
estrae il suo nuovo valore dai parametri della richiesta, usando il metodo decode(). Tale
valore, noto come submittedValue, viene memorizzato localmente al componente
stesso. Se la conversione del valore fallisce, viene memorizzato nel FacesContext un
messaggio di errore che sar visualizzato nella fase di Render Response, insieme ad
eventuali altri errori di validazione successivi.
Se un metodo decode() oppure un event listener invoca il metodo renderResponse() del
FacesContext, si salta direttamente alla fase di Render Response.
Se degli eventi vengono accodati in questa fase, ne verr eseguito il broadcast
(smistamento) verso i corrispondenti listeners, ma la loro gestione avverr nelle fasi
successive.
Se, invece, alcuni componenti della pagina hanno lattributo immediate settato a true,
allora la validazione, conversione e gestione degli eventi associati vengono processati
subito e non posticipati alle fasi successive.
56
_________________________________________________________________
A questo punto, se bisogna redirezionare il flusso dellapplicazione verso una risorsa
che non ha componenti JSF, viene invocato il metodo responseComplete() del
FacesContext.
Al termine di questa fase, i componenti sono settati ai loro nuovi valori
(submittedValues) ed i messaggi eventuali di errore e gli eventi sono messi in coda,
pronti per essere processati nelle fasi successive.

4.2.3 Process Validation

Durante questa fase, vengono eseguiti tutti i validators registrati sui
componenti della view. In primo luogo, vengono valutati gli attributi fissati che
specificano le regole di validazione e viene confrontato il valore memorizzato in
ciascun componente (local-value) con le regole stesse.
Se il valore locale di un componente non valido, viene memorizzato un messaggio
di errore nel FacesContext e si passa alla fase di Render Response, per visualizzare tutti i
messaggi di questo tipo, insieme ad altri eventuali messaggi dovuti ad errori di
conversione nella fase precedente.
Se un metodo validate() oppure un event-listener invoca il metodo renderResponse() del
FacesContext, si passa direttamente alla fase di Render Response.
FacesContext.
successive.

4.2.4 Update Model Values

Una volta che i valori locali dei componenti sono considerati validi,
possibile percorrere lalbero dei componenti stessi ed assegnare alle propriet dei
backing beans, tali valori. Ci vuol dire rendere i submittedValue, valori effettivi del
modello (model-value). Ovviamente i local-values devono essere convertiti
57
_________________________________________________________________
correttamente nei tipi di dati accettati dalle propriet dei backing beans. Se si
verificano degli errori, si passa direttamente alla fase di Render Response per
visualizzarli, in maniera molto simile agli errori di validazione nelle fasi precedenti.
Se un metodo updateModels() oppure un event listener chiama il metodo
renderResponse() del FacesContext, si salta direttamente alla fase di Render Response.
FacesContext.
successive.

4.2.5 Invoke Application

In questa fase viene gestito ogni evento sia di tipo action che di tipo value-
change, come nei casi di invio di un form di click su di un link.
Se bisogna redirezionare il flusso dellapplicazione verso una risorsa che non ha
componenti JSF, viene invocato il metodo responseComplete() del FacesContext.
Se la view stata recuperata da una richiesta precedente ed su di un componente viene
sollevato un evento, questo viene smistato verso il suo listener.

4.2.6 Render Response

Durante questa fase, limplementazione JSF delega il compito della
visualizzazione (rendering) della risposta al JSP container, ovviamente nel caso in cui
si utilizzino delle pagine JSP.
Se si tratta di una initial request, i componenti della pagina vengono aggiunti alla view,
mentre nel caso di un postback gi sono presenti. In entrambi i casi, i componenti
eseguono il proprio rendering sulla base dei tag che li rappresentano nella pagina JSP.
Nel caso di un postback, se nelle fasi precedenti si verificato qualche errore, viene
visualizzata comunque la pagina e se ci sono in essa dei tag <h:message> oppure
<h:messages>, vengono visualizzati i messaggi di errore.
58
_________________________________________________________________
Una volta visualizzata la pagina, viene salvato lo stato della response, ossia lo stato
dei componenti, sul client oppure sul server, in modo che per uneventuale
successiva request potr essere eseguita la fase di Restore View.

5. JSF Expression Language

Il framework JSF dispone di una particolare versione dellExpression
Language (EL), rispetto a quello disponibile nella librerie di tag JSTL (JavaServer
Pages Standard Tag Library) ampiamente utilizzate con Struts.
Tale linguaggio permette di definire delle espressioni, mediante le quali pu essere
realizzato il value-binding ed il method-bindig tra i componenti dellinterfaccia utente
e le propriet oppure i metodi dei backing beans. Infatti, attraverso lEL che
possibile associare la propriet di un componente con la propriet di un bean, cos
come un evento oppure un azione su un componente con il metodo di un bean.
Nellespressione viene specificato il nome del bean e la propriet oppure il metodo a
cui fare riferimento, mediante la tipica dot notation.

#{backi ngBean. [ pr opr i et a | met odo] }

Inoltre, esso fornisce una serie di operatori aritmetici e logici per definire espressioni
molto pi complesse, magari utilizzando come operandi le propriet dei backing
beans a cui si fa riferimento.
Sono altres disponibili i seguenti oggetti impliciti (implicit object) ai quali si pu fare
riferimento da una qualsiasi pagina JSP :

- applicationScope : oggetto Map con varibiabili e beans che si trovano
nellambito di visibilit di tipo application;
- requestScope : oggetto Map con varibiabili e beans che si trovano nellambito di
visibilit di tipo request;
- sessionScope : oggetto Map con varibiabili e beans che si trovano nellambito di
visibilit di tipo session;
- cookie : oggetto Map contenente i cookie associati alla richiesta;
- facesContext : istanza della classe FacesContext;
59
_________________________________________________________________
- header : oggetto Map contenente gli header HTTP della richiesta corrente;
- param : oggetto Map che ha al suo interno i parametri della richiesta;
- view : oggetto che rappresenta il nodo root della view;

6. Espandibilit del framework

La tecnologia JavaServer Faces offre allo sviluppatore la possibilit di
estendere completamente le classi del framework. Nella maggior parte dei casi, per
quanto riguarda lExecution Model, vengono utilizzate sempre le classi di default a
meno di particolari esigenze. La potenzialit di personalizzare il framework viene
sfruttata soprattutto per quanto riguarda la realizzazione di :

- Custom Converter;
- Event Listeners;
- Custom Validator;
- Custom UI Components;

6.1 Custom Converter

Limplementazione JSF esegue automaticamente tutte le conversioni
necessarie dei valori dei componenti della UI nelle corrispondenti propriet dei
backing beans.
In alcuni casi particolari, pu esserci lesigenza di realizzare un convertitore
personalizzato che sia capace di eseguire una conversione che non rientri tra quelle
standard di JSF. Per fare questo, necessario realizzare una classe che implementa
linterfaccia Converter.
Tale classe dovr inoltre eseguire loverriding dei due metodi seguenti :

- getAsObject() : riceve il valore del componente e lo converte nel tipo di dato
della propriet corrispondente del backing bean associato;
- getAsString() : riceve il valore della propriet del backing bean e lo converte in
stringa per la visualizzazione nella UI;
60
_________________________________________________________________

public Obj ect get AsObj ect ( FacesCont ext cont ext ,
UI Component component ,
St r i ng val ue) {
. . .
}

public St r i ng get AsSt r i ng( FacesCont ext cont ext ,
UI Component component ,
Obj ect val ue) {
. . .
}

Durante la fase di Apply Request Values, quando lutente ha immesso dei valori nei
componenti (es. riempiendo un campo di testo), viene invocato il metodo decode() del
componente oppure del renderer corrispondente, che si occupa di acquisire tale
valore. Ovviamente, in questo metodo che viene invocato getAsObject().
Viceversa, durante la fase di Render Response, quando bisogna visualizzare
nellinterfaccia utente il valore di un componente, vengono invocati i metodi di
encoding del componente stesso oppure del renderer associato, che a loro volta
invocano getAsString().
Infine, per rendere disponibile il converter nellapplicazione, bisogna registrarlo nel
file faces-config.xml. Inoltre, affinch lo si possa associare ad un componente,
necessario usare lattributo converter del componente stesso oppure il tag <f:converter>
della Core Library di JSF.

<f : conver t er conver t er I d=" i dConver t er " / >

6.2 Event Listener

Come visto in precedenza, limplementazione JSF permette di gestire due
tipologie di eventi che si possono verificare sui componenti della UI :

- action event;
- value-change event;

61
_________________________________________________________________
Tale gestione, pu essere eseguita in due modi diversi :

- realizzare una classe listener che implementi linterfaccia ActionListener oppure
ValueChangeListener;
- realizzare, allinterno di un certo backing bean, un metodo che sia capace di
gestire levento;

6.2.1 Implementazione di un ActionListener/ValueChangeListener

Per poter gestire un action event che pu essere sollevato da un
componente, possibile sviluppare una classe che implementa linterfaccia
ActionListener. Allinterno di essa, sar eseguito loverriding del metodo processAction(),
il quale prevede come parametro di ingresso un oggetto di tipo ActionEvent che
contiene tutte le informazioni sullevento e sul componente che lha generato.
Ovviamente, allinterno di questo metodo, sar necessario scrivere il codice per la
gestione dellevento, in quanto il metodo sar immediatamente invocato, nel
momento in cui levento sar intercettato.

public void pr ocessAct i on( Act i onEvent event )
throws Abor t Pr ocessi ngExcept i on {
. . .
}

Una volta realizzata la classe, essa sar associata ad un componente utilizzando il tag
<f:actionListener>.

<f : act i onLi st ener t ype=" cl asseAct i onLi st ener " / >

Per poter gestire un value-change event per un certo componente, possibile
realizzare una classe che implementa linterfaccia ValueChangeListener. Tale classe deve
semplicemente eseguire loverriding del metodo processValueChange(), il quale ha un
parametro di ingresso di tipo ValueChangeEvent che contiene le informazioni
sullevento che si verificato. Tale metodo viene invocato nel momento in cui
levento si verifica e quindi conterr il codice per la sua gestione.

62
_________________________________________________________________
public void pr ocessVal ueChange( Val ueChangeEvent event )
throws Abor t Pr ocessi ngExcept i on {
. . .
}

Infine, per poter registrare la classe listener sul componente, si pu utilizzare il tag
<f:valueChangeListener> della Core Library di JSF.

<f : val ueChangeLi st ener t ype=" cl asseVal ueChangeLi st ener " / >

6.2.2 Backing Bean Method Listener

Una possibile strada alternativa alla realizzazione delle classi listener, lo
sviluppo di alcuni metodi allinterno dei backing beans che abbiano la capacit di
gestire gli eventi.
Nel caso in cui bisogna gestire un action event, possibile realizzare un metodo che
non ha parametri di uscite ed ha come unico parametro di ingresso, un oggetto di
tipo ActionEvent con le informazioni dellevento intercettato. Tale metodo potr
essere associato al componente, utilizzando lattributo actionListener del tag che
rappresenta il componente stesso allinterno di una pagina.

<h: commandLi nk act i onLi st ener =" #{backi ngBean. met odoLi st ener }" / >

Se invece abbiamo a che fare con un value-change event, bisogna realizzare un
metodo che ha come parametro di ingresso, un oggetto del tipo ValueChangeEvent e
che sar associato al componente, mediante lattributo valueChangeListener del
medesimo tag.

<h: i nput Text
val ueChangeLi st ener =" #{backi ngBean. met odoLi st ener }" / >

6.3 Custom Validator

Per eseguire la validazione dei dati, JSF mette a disposizione una serie di
validatori standard, ma nel caso in cui questi ultimi non siano sufficienti, possibile
realizzarne di propri.
63
_________________________________________________________________
Le modalit possibili sono le seguenti :

- realizzare una classe che implementa linterfaccia Validator;
- sviluppare un metodo allinterno di un backing bean, che si occupi della
validazione;

6.3.1 Implementazione di un Validator

Nel caso in cui la scelta sia quella di realizzare una classe che implementa
linterfaccia Validator, si deve poi poter associare tale validatore ad un qualsiasi
componente che ne possa fare uso. Le possibili soluzioni sono le seguenti :

- se il validator prevede degli attributi e si vuole dare la possibilit al Page author
di assegnare ad essi dei valori specifici, bisogna realizzare un custom tag
mediante il quale possibile immettere il validatore allinterno della pagina.
Tale tag avr quindi degli attributi accessibili al realizzatore della pagina,
secondo una modalit XML-like;
- in alcuni casi si pu preferire non realizzare un tag proprietario del validator.
In queste situazioni, per associare il validatore ad un componente, si deve
utilizzare il tag <f:validator> della Core Library , specificando la classe del
validatore, ed uno o pi tag <f:attribute> per specificarne gli attributi;
- un ultimo caso particolare quello in cui si realizza un Custom Component e
gli si vuole associare un validatore integrato. Ci vuol dire che questultimo
verr associato al componente durante lesecuzione, mediante il metodo
addValidator(), e non ci sar la possibilit per il Page author di farlo
manualmente allinterno di una pagina. Questa soluzione integrata fornisce
un componente potenziato di un validator integrato, ma non da flessibilit al
realizzatore della pagina di poter utlizzare il validatore al di fuori del
componente;

Durante la validazione, si potrebbe verificare un errore ed in questo caso, sarebbe
utile visualizzare un messaggio allutente. E possibile creare i messaggi durante
lesecuzione mediante la classe FacesMessage, memorizzandoli nel FacesContext. In
64
_________________________________________________________________
generale, si preferisce sollevare uneccezione del tipo ValidatorException, nel metodo
validate() della classe , con il messaggio di errore da visualizzare.
Nel caso pi generale possibile, i passi per poter realizzare un validatore sono i
seguenti :

- realizzare la classe che implementa linterfaccia Validator;
- realizzare un Tag Handler;
- definire un tag associato al validatore, allinterno di un file TLD (Tag Library
Descriptor);

6.3.1.1 Class Validator

La classe che implementa linterfaccia Validator deve tipicamente avere una
serie di propriet, che non sono altro che gli attributi del validatore stesso.
Ovviamente, deve essere anche dotata dei metodi di accesso a tali propriet
(Accessor Method), nella forma getNomeProprieta() setNomeProprieta(). Inoltre,
bisogna eseguire loverriding del metodo validate() che dovr contenere il codice per
eseguire la validazione.

public void val i dat e( FacesCont ext cont ext ,
UI Component t oVal i dat e,
Obj ect val ue)
throws Val i dat or Except i on {
. . .
}

6.3.1.2 Tag Handler

Per poter associare un tag al validatore, necessario realizzare un Tag
Handler, che altro non che una classe che estende la classe di base del framework
ValidatorTag. Tale classe deve avere le stesse propriet della classe validator che
saranno gli attributi del tag.

65
_________________________________________________________________
Le caratteristiche principali della classe sono le seguenti :

- i metodi di accesso alle propriet;
- esegue loverriding del metodo createValidator(), allinterno del quale viene
creata unistanza del validatore e ne vengono inizializzate le propriet sulla
base dei valori che il page author ha assegnato agli attributi del tag;

protected Val i dat or cr eat eVal i dat or ( ) throws J spExcept i on {
. . .
}

6.3.1.3 Tag Library Descriptor

Per poter associare il validatore ad un componente allinterno di una
pagina, necessario realizzare un tag che lo rappresenti. Fondamentalmente, il tag
non fa altro che rappresentare il Tag Handler, il quale avr poi il compito di utilizzare
la classe validator. Per la descrizione dei tag, vengono utilizzati i file TLD (Tag
Library Descriptor) allinterno dei quali, i tag stessi, vengono elencati con i relativi
attributi, sfruttando una sintassi XML-like.

<t ag>
<name>nomeVal i dat or </ name>
<t ag- cl ass>package. Cl asseVal i dat or Tag</ t ag- cl ass>
<bodycont ent >J SP</ bodycont ent >
<at t r i but e>
<name>at t r i but o</ name>
<r equi r ed>t r ue</ r equi r ed>
<t ype>package. Cl asseTi poAt t r i but o</ t ype>
</ at t r i but e>
. . .
</ t ag>

6.3.2 Backing Bean Method Validator

La validazione del valore di un componente pu essere eseguita anche
realizzando, allinterno di un backing bean, un metodo che riceve come parametri di
ingresso : loggetto FacesContext dellapplicazione, il componente del cui valore farne
la validazione ed infine il valore stesso. Tale metodo non ha parametri di uscita ed ha
66
_________________________________________________________________
la possibilit di generare dei messaggi di errore, nel caso in cui la validazione non
andasse a buon fine.

public void met odoVal i dat e( FacesCont ext cont ext ,
UI Component t oVal i dat e,
Obj ect val ue) {
. . .
}

Per fare in modo che il metodo venga eseguito, necessario utilizzare lattributo
validator del componente il cui valore deve essere soggetto a validazione.

<h: i nput Text i d=" i dCampoTest o" val ue=" #{backi ngBean. pr opr i et a}"
val i dat or =" #{backi ngBean. met odoVal i dat e}" / >

6.4 Custom UI Components

La tecnologia JSF mette a disposizione una serie di componenti standard
per la realizzazione dellinterfaccia utente, ma comunque possibile estendere le
funzionalit di questi ultimi o addirittura creare di nuovi, con delle funzionalit non
ancora esistenti. E inoltre possibile, creare uno o pi renderer per poter visualizzare
ciascun componente in maniera diversa su client di tipo differente. Ci vuol dire che
il comportamento del componente viene definito una sola volta, mentre la sua
visualizzazione viene delegata ai renderer che possono essere molteplici. Ci non
toglie, che un componente pu gestire la visualizzazione in maniera autonoma, non
facendo uso dei renderer.
In generale, la classe che realizza un componente, ne definisce lo stato ed il
comportamento, il quale include : convertire i valori del componente attraverso i
convertitori , accodare gli eventi, eseguire la validazione facendo uso dei validatori
ed altre funzionalit.
C bisogno di creare un Custom Component, in queste situazioni :

- aggiungere un nuovo comportamento ad un componente standard, ad
esempio un nuovo tipo di evento;
- aggregare pi componenti per costituirne uno solo con un unico
comportamento;
67
_________________________________________________________________
- se si ha bisogno di un componente supportato da un client HTML ma non
implementato da JSF;
- realizzare un componente che possa essere utilizzato da un client non
HTML, quando magari il componente stesso esiste per un client HTML;

Non c la necessit di realizzare un Custom Component in queste situazioni :

- se bisogna manipolare i dati di un componente o aggiungervi semplici
funzionalit. In questo caso, basta creare dei metodi nel backing bean,
associato ad esso;
- bisogna convertire il valore di un componente in un dato non supportato dal
suo renderer. In tale situazione, conviene adottare un convertitore standard o
realizzarne uno personalizzato;
- se bisogna eseguire la validazione sul valore del componente, conviene
utilizzare un validatore standard o realizzarne uno;
- se c la necessit di registrare degli event listeners su un componente. In tal
caso, si adottano le tecniche per la realizzazione degli event listeners;

Quando si crea un Custom Component, bisogna essere sicuri che la classe sia capace
di eseguire le seguenti operazioni :

- Deconding : prelevare, dai parametri della request, il valore del componente che
stato immesso dallutente ed associarlo al local value;
- Encoding : eseguire il rendering del componente secondo un certo linguaggio
di markup, quale pu essere HTML , XML , WML in relazione al tipo di
client;

JSF supporta due modelli di programmazione per il deconding e lencoding :

- Direct implementation : la stessa classe del componente implementa il decoding
e lencoding;
- Delegated implementation : la classe del componente delega limplementazione
del decoding e dellencoding ad un renderer;
68
_________________________________________________________________
Con il secondo modello, si ha il vantaggio di poter definire il componente una sola
volta (stato e comportamento) ma di avere pi renderer associati ad esso, che ne
permettano la visualizzazione in forme diverse a secondo del device client (browser
web , cellulare,).
Nel caso di un Custom Component, si rende necessaria la realizzazione di un tag che
permetta di introdurre il componente in una pagina, operazione opzionale, invece,
nel caso in cui si realizzi un validator e quasi mai utilizzata nel caso di un converter.
In generale, per poter realizzare un Custom Component, si seguono i seguenti passi :

- sviluppare una classe che rappresenti il componente ed estenda la classe base
del framework UIComponentBase oppure una delle sue derivate;
- realizzare un Tag Handler;
- eventualmente, sviluppare uno o pi renderer estendendo la classe Renderer;
- infine, descrivere il tag allinterno di un file TLD;

6.4.1. Class Component

Tutti i componenti standard estendono le classi UIComponentBase oppure
UIComponent. Quando si vuole creare un Custom Component, bisogna estendere una
di queste ultime se lo si vuole realizzare partendo da zero. E possibile invece, poter
sfruttare le caratteristiche di un componente standard derivando dalla sua classe. Ad
esempio se bisogna creare un men editabile, non conviene estendere la classe
UIComponentBase ma la classe UISelectOne, in modo da sfruttarne il suo
comportamento e doverne aggiungere solo le funzionalit necessarie.
Ovviamente, il componente sar utilizzato allinterno di una pagina ed in generale
sar associato ad un backing bean, che conterr in una sua propriet il valore del
componente (value-binding) e potrebbe avere dei metodi referenziati dal
componente stesso (method-binding).
Il primo passo per la realizzazione della classe del Custom Component quello di
eseguire loverriding del metodo getFamily() che restituisce la famiglia di appartenenza
del componente, registrata anche allinterno del file faces-config.xml.

69
_________________________________________________________________
public final static St r i ng COMPONENT_TYPE =" Ti poComponent e" ;
public final static St r i ng COMPONENT_FAMILY =" Fami gl i aComponent e" ;
...
...
public St r i ng get Fami l y( ) {
return COMPONENT_FAMILY;
}
. . .

<component >
<component - t ype>Ti poComponent e</ component - t ype>
<component - cl ass>package. Cl asseComponent e</ component - cl ass>
</ component >

Nel caso in cui il componente gestisca in maniera autonoma il rendering, deve
occuparsi sia della fase di decoding che di encoding. Per quanto riguarda la fase di
deconding, basta eseguire loverriding del metodo decode() che viene invocato nella
fase di Apply Values Change del ciclo di vita di una richiesta. Per quanto concerne
lencoding, bisogna eseguire loverriding dei metodi encodeBegin(), encodeChildre() ed
encodeEnd(). C da precisare che, nella maggior parte dei casi, basta realizzare soltanto
il primo metodo; i due successivi vengono usati soltanto se il componente ha dei
componenti figli al suo interno.

...
public void decode( FacesCont ext cont ext ) {
. . .
}
. . .
. . .
public void encodeBegi n( FacesCont ext cont ext ) throws I OExcept i on {
. . .
ResponseWr i t er wr i t er = cont ext . get ResponseWr i t er ( ) ;
wr i t er . st ar t El ement ( " nomeEl ement o" , this) ;
wr i t er . wr i t eAt t r i but e( " nomeAt t r i but o" , val or e, " nomeAt t r i but o" ) ;
. . .
wr i t er . wr i t e( body) ;
wr i t er . endEl ement ( " nomeEl ement o" ) ;
. . .
}

Allinterno di ciascuno di questi metodi, si fa uso di un oggetto ResponseWriter, che
permette di scrivere direttamente su una pagina, mediante uno stream di output, in
un linguaggio XML-like. Si osserva che il metodo startElement() permette di scrivere
sullo stream il tag di apertura, usando una o pi volte writeAttribute() possibile
scrivere gli attributi ed i corrispondenti valori, con il metodo write() si scrive il body
70
_________________________________________________________________
del tag ed infine, usando endElement() si scrive il tag di chiusura. In una pagina JSP, il
risultato di queste operazioni sar una cosa del tipo seguente :

<l i br er i a: nomeEl ement o nomeAt t r i but o=" [ val or e] " / >
[ body]
</ l i br er i a: nomeEl ement o>

Se il rendering viene delegato ad un renderer, i metodi di decoding e di encoding non
vengono realizzati, ma viene eseguito loverriding del metodo getRendererType() che
restituisce lidentificativo del renderer adottato.

6.4.2 Tag Handler

La classe Tag Handler associata con un componente, estende la classe base
del framework UIComponentTag e guida la fase Render Response del ciclo di vita di una
richiesta. La prima operazione eseguita quella di recuperare il tipo di componente
associato al tag mediante il metodo getComponentType().

public St r i ng get Component Type( ) {
return Cl asseComponent e. COMPONENT_TYPE;
}

Successivamente, mediante il metodo setProperties(), vengono inizializzate le propriet
del componente con i valori degli attributi del tag che sono stati specificati nella
pagina JSP in cui compare il tag stesso.

protected void set Pr oper t i es( UI Component component ) {
. . .
component e. set NomeAt t r i but o( this. nomeAt t r i but o) ;
. . .
. . .
}

Infine, tale classe, mediante il metodo getRendererType(), restituisce il tipo di renderer
adottato, se ne associato uno al componente, in modo da permettere
allimplementazione JSF di eseguire il deconding e lencoding di questultimo.

71
_________________________________________________________________
public St r i ng get Render er Type( ) {
return Cl asseRender er . RENDERER_TYPE;
}

Ovviamente, gli attributi di un tag possono avere come valore, non una stringa, ma
unespressione nel linguaggio EL, per poter eseguire le operazioni di value-binding o
method-bindig e quindi introdurre dei riferimenti alle propriet di un backing bean
oppure ai suoi metodi.
Per ogni attributo che accetta una espressione EL, allinterno del metodo
setPropterties(), per settare lattributo, necessario utilizzare le classi MethodBinding e
ValueBinding. Loggetto MethodBinding serve per valutare unespressione relativa ad un
metodo di un backing bean, mentre loggetto ValueBinding permette di valutare
unespressione relativa ad una delle sue propriet.
E raccomandabile che ogni Tag Handler abbia un metodo release() per rilasciare le
risorse allocate, una volta che siano state utilizzate.

6.4.3 Tag Library Descriptor

Per poter utilizzare un componente allinterno di una pagina, necessario
realizzare un tag che lo rappresenti. Fondamentalmente, il tag non fa altro che
rappresentare il Tag Handler, il quale avr poi il compito di utilizzare la classe del
componente. Per la descrizione dei tag, vengono utilizzati i file TLD (Tag LIbrary
Descriptor) allinterno dei quali, i tag stessi, vengono elencati con i relativi attributi,
sfruttando una sintassi XML-like.

<t ag>
<name>nomeComponent e</ name>
<t ag- cl ass>package. Cl asseComponent e</ t ag- cl ass>
<bodycont ent >J SP</ bodycont ent >
<at t r i but e>
<name>at t r i but o</ name>
<t ype>package. cl asseTi poAt t r i but o</ t ype>
</ at t r i but e>
. . .
</ t ag>

72
_________________________________________________________________
6.4.4 Classe Renderer

Nel caso in cui il componente non gestisca il decoding e lencoding in
maniera autonoma, necessario realizzare un renderer al quale delegare queste
operazioni.
La classe che implementa il renderer estende la classe base Renderer e deve eseguire
loverriding dei metodi decode(), encodeBegin(), encodeChildren() ed encodeEnd() per portare
a termine il suo compito.
.
public void decode( FacesCont ext cont ext , UI Component component ) {
. . .
}
. . .
. . .
public void encodeBegi n( FacesCont ext cont ext ,
UI Component component ) throws I OExcept i on {
. . .
}

Rispetto alla signature degli stessi metodi allinterno della classe che realizza il
componente, questi ultimi hanno come parametro di ingresso anche listanza del
componente da renderizzare.

7. Sicurezza

Per quanto riguarda la sicurezza, unapplicazione realizzata con
JavaServerFaces pu utilizzare il protocollo HTTPS per il trasferimento delle pagine
e delle informazioni, in modo da garantire la crittografia dei dati. La gestione della
sicurezza tramite lSSL (Secure Socket Layer) completamente indipendente dal
framework ed praticamente la medesima di una qualsiasi applicazione Web
realizzata in Java. In sostanza, si fa affidamento ai meccanismi del Web Container
sottostante, allinterno del quale va abilitato il supporto per le connessioni basate su
SSL. Una volta effettuata questa operazioni, nellambito dellapplicazione necessario
modificare opportunamente il Deployment Descriptor web.xml, per poter specificare
quali pagine dovranno utilizzare il protocollo HTTPS.
73
_________________________________________________________________
Per questo scopo, si utilizza il tag <security-constraint>, allinterno del quale si
specificano le risorse Web da trasmettere tramite SSL (tag <web-resource-collection>) ed
il tipo di trasporto da utilizzare (tag <transport-guarantee>) che pu essere di tre tipi :

- NONE : utilizza HTTP;
- INTEGRAL , CONFIDENTIAL : utilizza HTTPS;

<secur i t y- const r ai nt >
<di spl ay- name>SSL Const r ai nt </ di spl ay- name>
<web- r esour ce- col l ect i on>
<web- r esour ce- name>
Aut omat i c SLL For war di ng
</ web- r esour ce- name>
<ur l - pat t er n>[ pagi na. j sp] </ ur l - pat t er n>
<ht t p- met hod>GET</ ht t p- met hod>
<ht t p- met hod>PUT</ ht t p- met hod>
<ht t p- met hod>POST</ ht t p- met hod>
<ht t p- met hod>DELETE</ ht t p- met hod>
</ web- r esour ce- col l ect i on>
<user - dat a- const r ai nt >
<t r anspor t - guar ant ee>CONFI DENTI AL</ t r anspor t - guar ant ee>
</ user - dat a- const r ai n t >
</ secur i t y- const r ai nt >

Questo tipo di approccio evidenzia che la sicurezza strettamente legata
allarchitettura sulla quale in esecuzione lapplicazione e non dal framework con cui
stata realizzata.

8. Configurazione dellapplicazione

In generale, nellambito di una Web application realizzata con JSF, i
compiti principali dell Application architect sono tipicamente i seguenti :

- registrare gli oggetti di back-end in modo che siano accessibili da un qualsiasi
punto dellapplicazione;
- configurare i backing beans (managed beans) in modo che siano istanziati in
maniera corretta quando le pagine fanno riferimento ad essi;
- definire la navigazione tra le pagine dellapplicazione;
74
_________________________________________________________________
- eseguire il packaging dellapplicazione, includendo tutte le pagine, gli
oggetti e gli altri file, in modo che possa essere distribuita in un qualsiasi web
container;

La tecnologia JavaServer Faces mette a disposizione una modalit di configurazione
dellapplicazione che completamente portabile, mediante un documento XML
tipicamente chiamato faces-config.xml.
In realt, nel caso di applicazioni di grandi dimensioni, lapplicazione pu prevedere
anche pi di un file di configurazione, ciascuno dei quali permette di configurare una
parte delle funzionalit dellapplicazione stessa.
E da ricordare, inoltre, che lApplication developer pu sempre accedere direttamente da
codice al file faces-config.xml, grazie allutilizzo della classe Application. Infatti, allavvio
dellapplicazione, un parser XML legge le informazioni del file di configurazione e le
carica nellunica istanza della classe Application prevista.
8.1 Configurazione dei Backing Beans

Per istanziare i backing beans che vengono utilizzati in unapplicazione JSF
ed assegnarli ad un certo ambito di visibilit (scope), possibile utilizzare la
corrispondente funzionalit offerta nel file di configurazione XML. In questo modo,
quando una pagina fa riferimento ad un backing bean, limplementazione JSF lo
inizializza in maniera opportuna in accordo alle informazioni contenute nel file faces-
config.xml.
Attraverso tale funzionalit, si possono ottenere i seguenti vantaggi :

- registrare i beans in un unico file centralizzato, in modo da essere disponibili
nellambito di tutta lapplicazione o comunque essere istanziati solo nel
momento in cui sono necessari;
- personalizzare le propriet dei beans, direttamente nel file di configurazione
senza scrivere del codice aggiuntivo in Java;
- possibile assegnare dei valori iniziali alle propriet di un bean, nel momento
in cui viene creato;

75
_________________________________________________________________
Per registrare un backing bean nel file di configurazione, si utilizza lelemento XML
<managed-bean>, allinterno del quale si utilizzano ulteriori tag per specificare :

- il nome da assegnare al bean, per poterlo referenziare allinterno delle pagine
(<managed-bean-name>);
- la classe che implementa il bean (<managed-bean-class>);
- lambito di visiblit (scope) allinterno dellapplicazione (<managed-bean-
scope>);
- le relative propriet con eventuali valori iniziali (<managed-property>);

Le prime tre informazioni sono strettamente necessarie, mentre lultima facoltativa,
considerando che le propriet del bean vengono comunque definite nella
corrispondente classe Java. Per quanto riguarda lambito di visibilit, esso pu essere
del tipo : request, session, application e none (in questo caso il bean viene istanziato ogni
volta che deve essere utilizzato).

<managed- bean>
<managed- bean- name>backi ngBean</ managed- bean- name>
<managed- bean- cl ass>
package. Cl asseBacki ngBean
</ managed- bean- cl ass>
</ managed- bean>

8.2 Localizzazione, Internazionalizzazione e Messaggi

Una delle caratteristiche offerte dalla tecnologia JSF
lInternazionalizzazione (I18N), che permette di visualizzare il testo della Web
application, in un linguaggio diverso in base alla localizzazione geografica
dellutilizzatore. Per fare ci necessario creare uno o pi Resource Bundle, ciascuno
dei quali contiene i messaggi da visualizzare in un certo linguaggio, tra quelli
supportati dallapplicazione. In generale, i Resource Bundles non sono altro che dei
file con estensione properties, aventi tutti lo stesso nome pi il suffisso relativo al
linguaggio a cui ciascuno di essi fa riferimento.
Per rendere disponibile questa funzionalit allapplicazione, necessario registrare i
Resource Bundle allinterno del file faces-config.xml mediante lelemento <message-
76
_________________________________________________________________
bundle>. Ad esso, vanno poi aggiunti il default Locale e tutti i restanti Locale supportati
dallapplicazione, facendo uso di un solo elemento <default-locale> ed uno o pi
<supported-locale>.

<appl i cat i on>
<l ocal e- conf i g>
<def aul t - l ocal e>i t </ def aul t - l ocal e>
<suppor t ed- l ocal e>en</ suppor t ed- l ocal e>
</ l ocal e- conf i g>
<message- bundl e>Appl i cat i onResour ces</ message- bundl e>
</ appl i cat i on>

8.3 Registrare un Custom Validator

Se lApplication developer ha realizzato dei Custom Validators per eseguire
operazioni di validazione, necessario registrarli allinterno del file di configurazione
mediante lelemento <validator>, che conterr ulteriori tag per specificare le seguenti
informazioni :

- identificativo univoco del validator per referenziarlo allinterno della classe
che realizza il Tag Handler (<validator-id>);
- la classe che implementa il validator (<validator-class>);
- gli attributi previsti dal validator, con il relativo nome ed il tipo (<attribute>);

Le prime due informazioni sono necessarie, mentre lultima facoltativa
considerando che gli attributi del validator sono definiti nella classe che lo
implementa e nel suo Tag Handler.

<val i dat or >
<val i dat or - i d>i dVal i dat or </ val i dat or - i d>
<val i dat or - cl ass>package. Cl asseVal i dat or </ val i dat or - cl ass>
</ val i dat or >

8.4 Registrare un Custom Converter

Cos come nel caso di un validator, anche per la realizzazione di un Custom
Converter, si rende necessaria la registrazione allinterno del file di configurazione,
77
_________________________________________________________________
mediante lelemento <converter>. Questultimo, a sua volta, prevede ulteriori elementi
al suo interno, per specificare le seguenti informazioni :

- identificativo univoco del converter per poterlo referenziare nel tag di un
componente della UI che ne fa uso (<converter-id>);
- la classe che implementa il converter (<converter-class>);

<conver t er >
<conver t er - i d>i dConver t er </ conver t er - i d>
<conver t er - cl ass>package. Cl asseConver t er </ conver t er - cl ass>
</ conver t er >

8.5 Configurare le Navigation Rules

Come stato detto nel trattare il Navigation Model, la navigazione
allinterno dellapplicazione definita da un insieme di regole (navigation-rules) che
permettono di determinare quale sia la pagina successiva, nel momento in cui si clicca
su un bottone oppure su di un link. Tali regole sono configurate allinterno del file
faces-config.xml.
Ogni regola di navigazione specifica in quale direzione muoversi attraverso le pagine,
a partire da una certa pagina. Una volta individuata la regola, sulla base della pagina
attualmente visualizzata, si determina la pagina successiva sulla base di un outcome,
ossia una stringa che viene restituita da un metodo di un backing bean, associato al
componente (bottone o link) su cui si cliccato.
Ciascuna regola viene definita allinterno del file di configurazione, mediante
lelemento <navigation-rule>, il quale contiene al suo interno ulteriori tag per
specificare le seguenti informazioni :

- la pagina dalla quale si parte per la navigazione applicando tale regola (<from-
view-id>);
- le possibili pagine di destinazione, individuate attraverso dei casi di
navigazione (<navigation-case>), ciascuno dei quali specifica al suo interno :
loutcome (<from-outcome>) oppure una action (<from-action>) e la pagina stessa
di destinazione (<to-view-id>);
78
_________________________________________________________________

<navi gat i on- r ul e>
<f r om- vi ew- i d>/ pagi na. j sp</ f r om- vi ew- i d>
<navi gat i on- case>
<f r om- out come>nomeOut come</ f r om- out come>
<t o- vi ew- i d>/ pagi naDest i nazi one. j sp</ t o- vi ew- i d>
</ navi gat i on- case>
. . .
. . .
</ navi gat i on- r ul e>

8.6 Registrare un Custom Renderer in un Renderer Kit

Un Renderer Kit definisce un insieme di classi Renderer che vengono
utilizzate per poter eseguire la visualizzazione di uno o pi componenti della UI, in
maniera diversa in base al dispositivo client con cui si accede alla Web application.
Nel caso in cui lApplication developer crea un Custom Renderer, per la visualizzazione
di un certo componente, necessario che venga assegnato ad un Renderer Kit,
mediante la registrazione nel file di configurazione.
Lelemento XML adottato <renderer-kit>, il quale prevede al suo interno uno o pi
tag <renderer>, ciascuno dei quali contiene le informazioni seguenti relative ad uno
specifico renderer :

- la famiglia del componente della UI a cui associato il renderer (<component-
family>);
- il tipo del renderer (<renderer-type>), che viene utilizzato dal Tag Handler
associato al componente, per determinare quale renderer applicare su di esso;
- la classe che implementa il renderer (<renderer-class>);
- gli attributi eventuali del renderer (<attribute>) con il proprio nome
(<attribute-name>) e la classe (<attribute-class>);

In generale, non obbligatorio specificare il Renderer Kit di appartenenza di un
Custom Renderer; in questo caso, esso sar assegnato a quello di default HTML,
fornito con limplementazione JSF.

79
_________________________________________________________________
<r ender - ki t >
<r ender er >
<component - f ami l y>Fami gl i aComponent e</ component - f ami l y>
<r ender er - t ype>Ti poRender er </ r ender er - t ype>
<r ender er - cl ass>package. Cl asseRender er </ r ender er - cl ass>
</ r ender er >
. . .
. . .
</ r ender - ki t >

8.7 Registrare un Custom Component

Oltre alla registrazione di un Custom Renderer, si rende ovviamente
necessaria anche la registrazione del Custom Component a cui esso associato,
mediante lelemento <component>. Per ciascun componente, vengono specificate le
seguenti informazioni :

- il tipo del componente (<component-type>);
- la classe che implementa il componente (<component-class>);
- le propriet del componente (<property>), per ciascuna delle quali definito il
nome (<property-name>) e la classe (<property-class>);

Tipicamente, le prime due informazioni sono necessarie, mentre le successive sono
facoltative, in quanto tali propriet vengono comunque definite allinterno della
classe che implementa il componente.

<component >
<component - t ype>Ti poComponent e</ component - t ype>
<component - cl ass>package. Cl asseComponent e</ component - cl ass>
</ component >

80
Capitolo III Il framework Struts
_________________________________________________________________
C Ca ap pi it to ol lo o I II II I I Il l f fr ra am me ew wo or rk k S St tr ru ut ts s

1 . Introduzione

Struts un framework OpenSource per la realizzazione di Web application
secondo il pattern MVC (Model View Controller), caratterizzato da una serie di
classi e dalle relative API (Application Program Interface) che permettono di :

- acquisire i dati dei form riempiti dallutente durante la navigazione ed eseguire
le elaborazioni su di essi;
- individuare gli handlers (gestori) , detti anche actions, per esaudire ciascuna
richiesta;
- definire la navigazione fra le pagine allinterno della Web application;
- supportare linternazionalizzazione e laccessibilit;

Inoltre, include i due seguenti plug-in :

- Tiles : framework per la realizzazione del layout delle pagine con mattonelle
(tiles) componibili;
- Validator : plug-in che fornisce un vasto insieme di validatori, per la
validazione dei dati immessi dallutente nei form;

Infine, mette a disposizione tre librerie di tag (Tag Libraries) :

- Struts HTML : per la realizzazione dellinterfaccia utente, con una serie di tag
che permettono di introdurre i componenti della UI allinterno di ciascuna
pagina;
- Struts Bean : per poter accedere, direttamente da ciascuna pagina, alle
propriet dei JavaBeans che definiscono il Model dellapplicazione;
- Struts Logic : per definire dei costrutti di controllo (condizionali e ciclici) che
permettono la costruzione dinamica di una pagina;
81
_________________________________________________________________
Ci che rende Struts uno degli strumenti maggiormente utilizzati per lo sviluppo di
Web application, soprattutto il fatto di essere OpenSource. Infatti, milioni di
sviluppatori in tutto il mondo partecipano al miglioramento del framework,
realizzando classi aggiuntive che ne aumentano le potenzialit oppure migliorando
quelle preesistenti. Nel tempo, tutto ci ha reso Struts un strumento stabile e
fortemente maturo con un curva di apprendimento (learning curve) piuttosto bassa.
Infine, il vantaggio principale che scaturisce dallutilizzo di Struts, la netta
separazione tra lApplication processing layer (Model) ed il Presentation layer (View),
favorendo il team-working.
Esso si basa fortemente sugli strumenti che costituiscono principalmente
unapplicazione Web realizzata in Java : le pagine JSP e le Servlet. Infatti, il flusso di
esecuzione allinterno di ciascuna Web application gestito attraverso una Servlet, in
esecuzione nel Web Container.
Ovviamente, alle numerose classi che costituiscono il framework, possibile
aggiungere ulteriori classi che definiscono la business-logic, tipicamente realizzate
attraverso dei JavaBeans.
La semplicit di configurazione della Web application da realizzare garantita dalla
presenza di un file XML (struts-config.xml), nel quale vengono impostati tutti i
parametri e gli elementi costitutivi dellapplicazione stessa.
Infine, dalla versione 1.1, stata introdotta la possibilit di realizzare unapplicazione
di grandi dimensioni suddividendola in moduli, ciascuno dei quali definisce una parte
delle funzionalit complessive ed ha un proprio file di configurazione autonomo. In
questo modo, si pu gestire ciascun modulo separatamente dagli altri ma
ovviamente garantita la comunicazione fra di essi.
Tutti gli elementi che costituiscono il framework sono raggruppati in otto principali
package :

- action, actions : contengono le classi che costituiscono il Controller e le classi
che possono essere usate o estese allinterno della propria applicazione;
- config : contiene le classi che definiscono una rappresentazione in memoria,
della configurazione dellapplicazione specificata nel file struts-config.xml;
- taglib : contiene i Tag Handler, ossia le classi per la gestione delle librerie di
tag di Struts;
82
_________________________________________________________________
- tiles : include le classi utilizzate dal framework Tiles;
- upload : contiene le classi per eseguire lupload di file attraverso un browser
Web;
- util : include delle classi general-purpose, con delle utility sfruttate dal
framework;
- validator : contiene le classi specifiche di Struts per lo sviluppo di validatori
personalizzati;

Figura 1 - Packages Architettura Struts

2. Controller, Model and View Components

Basandosi sul pattern MVC (Model View Controller), ovvio che
Struts caratterizzato da una serie di componenti e di classi, che compongono
ciascuna delle tre parti del pattern stesso :

- Controller : le classi che gestiscono il flusso di esecuzione dellapplicazione e
garantiscono la comunicazione tra il Model e la View; ad esse si aggiungono
anche una serie di classi di utilit (Utility Classes);
83
_________________________________________________________________
- Model : le classi che definiscono lo stato dellapplicazione e le funzionalit
della business-logic;
- View : tipicamente le pagine JSP che utilizzano i tag delle librerie di Struts, per
la realizzazione dellinterfaccia utente (UI);

2.1 Controller Components

Il Controller di Struts si basa sul pattern Front Controller della J2EE
(Java2 Enterprise Edition), in modo da poter gestire tutte le richieste in maniera
centralizzata. Oltre ai numerosi vantaggi relativi alle funzionalit dellapplicazione, ne
scaturisce che alcuni servizi come la sicurezza, linternazionalizzazione ed il logging
sono concentrati nel Controller.
Facendo riferimento al pattern MVC, il Controller di Struts ha i seguenti compiti :

- ricevere tutte le richieste provenienti dai vari client;
- per ciascuna richiesta, determinarne il gestore, detto anche action, che avr il
compito di eseguire le elaborazioni richieste, utilizzando anche i JavaBeans
che costituiscono la business-logic;
- raccogliere i risultati delle elaborazioni per renderli disponibili al client;
- determinare la View alla quale passare il controllo per la visualizzazione dei
risultati;

Figura 2 - Pattern MVC

84
_________________________________________________________________
Struts prevede una serie di classi, legate fra loro, per la strutturazione del Controller.

Figura 3 - Class Diagram Controller Components

2.1.1 ActionServlet

La classe ActionServlet rappresenta la Servlet in esecuzione nel Web
Container, alla quale arrivano tutte richieste dei client, dirette allapplicazione stessa.
Quando la classe riceve una request di tipo HTTP (HttpRequest), esegue uno dei
metodi tipici di una Servlet, ossia doGet() oppure doPost(), in base al metodo che
stato utilizzato per inviare la richiesta. Ciascuno dei due metodi invoca il metodo
process(), il quale si occupa di eseguire le principali operazioni che competono alla
ActionServlet, tra cui individuare il modulo della Web application al quale destinata la
richiesta, se lapplicazione prevede una suddivisione in pi moduli.
Il framework da la possibilit allo sviluppatore di realizzare una classe che estenda
ActionServlet, per poter definire un Controller personalizzato, che va comunque
registrato nel Deployment Descriptor web.xml, per segnalare al Web Container quale
Servlet avviare per gestire lapplicazione.
Struts prevede una particolare fase di inizializzazione, nel momento in cui la prima
richiesta giunge alla Web application. In questa fase, ovviamente, viene istanziata la
ActionServlet ed invocato su di essa il metodo init(), nellambito del quale, la Servlet
esegue le seguenti operazioni :

- inizializza il ResourceBundle interno del framework con i messaggi per la
creazione dei files di log;
85
_________________________________________________________________
- carica i parametri di configurazione della Servlet dal file web.xml;
- carica ed inizializza il nome ed il mapping della Servlet;
- carica le informazioni di configurazione del modulo principale
dellapplicazione, dal file struts-config.xml, creandone una copia in memoria
nella classe ApplicationConfig, memorizzata nel ServletContext (contesto di
esecuzione della Servlet);
- carica ogni ResourceBundle assegnato al modulo di default e contenente i
messaggi da visualizzare allutente;
- carica le informazioni relative a ciascun data source specificato nel file di
configurazione;
- inizializza ed avvia i plug-in assegnati al modulo principale;
- eseguite tutte le operazioni suddette per il modulo di default, esse vengono
ripetute per tutti i moduli componenti lapplicazione;

Figura 4 - Operazioni di inizializzazione della ActionServlet

2.1.2 RequestProcessor

Dalla versione 1.1 del framework, alla classe ActionServlet stata affiancata la
classe RequestProcessor. Si resa necessaria tale introduzione, in virt del fatto che,
86
_________________________________________________________________
proprio da tale versione, stato introdotto il supporto di realizzazione di
unapplicazione in pi moduli separati. In questo caso, a partire dalla classe
ActionServlet, vengono create pi istanze della classe RequestProcessor, quanti sono i
moduli dellapplicazione, in modo tale che ciascuno di essi abbia il proprio request
handler, per la gestione delle richieste in ingresso.
Nel momento in cui arriva una richiesta alla ActionServlet, questultima determina il
modulo a cui essa destinata ed istanzia la relativa classe RequestProcessor, verso la
quale inoltra la richiesta e ne invoca il metodo process(). Allinterno di tale metodo,
vengono eseguite le seguenti operazioni :

- vengono caricate le informazioni per la gestione dei form multipart,
qualora la richiesta preveda lupload di un file;
- viene determinato il path della richiesta;
- individuato il Locale, per gestire linternazionalizzazione;
- viene invocato il metodo processPreprocess(), allinterno del quale vengono
eseguite le operazioni preliminari allinvocazione della action che dovr
gestire la richiesta. Tipicamente, se lo sviluppatore crea un proprio request
handler, estendendo RequestProcessor, inserisce allinterno di questo metodo
tutti i controlli che servono per valutare se la sessione corrente dellutente
valida;
- viene determinato il mapping delle action, per poter individuare quale di
queste dovr gestire la richiesta;
- vengono eseguiti i metodi per : individuare il formbean associato alla action
selezionata, caricarlo nello scope specificato nel file di configurazione,
popolarlo con i dati immessi dallutente e validarlo;
- viene invocata la action per la gestione della richiesta;
- terminata lesecuzione della action, viene eseguito il forward verso la View
per la visualizzazione dei risultati;

87
_________________________________________________________________
Nel caso di realizzazione di un proprio RequestProcessor, la signature del metodo
processPreprocess() soggetto ad overriding la seguente :

protected boolean pr ocessPr epr ocess( Ht t pSer vl et Request r equest ,
Ht t pSer vl et Response r esponse)
{
. . .
}

Si osservi il parametro di ingresso relativo alla request che deve essere gestita, dal
quale poter ricavare eventuali informazioni da controllare prima di una successiva
elaborazione.

2.1.3 Action

La classe Action pu essere considerata il cuore del framework. Essa
definisce un bridge (ponte) tra il Controller ed il Model, in virt del fatto che riceve
dal primo la richiesta da esaudire ed utilizza le classi del secondo per espletarla.
Per la gestione di una richiesta da parte di una action, viene invocato su di essa il
metodo execute(), allinterno del quale vengono istanziati gli oggetti che compongono
la business-logic ed eseguono lelaborazione richiesta. Tale metodo restituisce un
oggetto della classe ActionForward, che specifica la direzione verso la quale incanalare
il flusso dellapplicazione. Al termine dellesecuzione di tale metodo, il controllo
ritorna al Controller che determina, sulla base delloggetto ActionForward, a quale
View compete la visualizzazione.

public Act i onFor war d execut e( Act i onMappi ng mappi ng,
Act i onFor mf or m,
Ht t pSer vl et Request r equest ,
throws Except i on {
. . .
}

Si osservi che il metodo execute() riceve in ingresso loggetto ActionMapping che
contiene il mapping delle action dellapplicazione e serve per individuare i forward,
loggetto ActionForm che contiene i dati del form trasmesso dallutente ed infine, gli
oggetti HttpServletRequest ed HttpServletResponse relativi alla richiesta ed alla risposta.
88
_________________________________________________________________
La classe Action definita thread-safe, nel senso che, nellambito di
unapplicazione, viene creata sempre e solo ununica istanza di ciascuna action. Ci
vuol dire che tutti i client condividono la medesima istanza di ciascuna di esse e
possono invocare sulla medesima action il metodo execute() contemporaneamente,
proprio perch la gestione avviene con thread separati.
Lelenco delle action istanziate contenuto allinterno di una HashMap della classe
RequestProcessor. In virt dellapproccio thread-safe con cui vengono gestite le
action, consigliabile non utilizzare variabili di istanza per ciascuna di esse, che
altrimenti verrebbero condivise da tutti i client.
Inoltre, il framework mette a disposizione delle particolari classi che estendono il
funzionamento della classe Action :

- ForwardAction;
- DispatchAction;
- LookupDispatchAction;
- SwitchAction:

2.1.3.1 ForwardAction

In moltissime situazioni, c la necessit di passare da una pagina JSP
allaltra, senza il bisogno di utilizzare una Action. In generale, invocare direttamente
una pagina JSP un approccio non consigliato per molteplici motivazioni.
Il Controller ha il compito di selezionare opportunamente il modulo dellapplicazione
a cui diretta una richiesta per poterne caricare la configurazione ed i messaggi del
ResourceBundle. Se questa fase viene saltata, si corre il rischio che non vengano
visualizzati allutente i messaggi corretti.
Unaltra motivazione puramente concettuale, nel senso che, chiamare direttamente
una pagina JSP viola il pattern MVC, poich non si sfrutta il Controller.
Per risolvere questa problema, stata introdotta la classe ForwardAction che permette
di eseguire il forward da una pagina allaltra, passando attraverso il Controller.

89
_________________________________________________________________
2.1.3.2 DispatchAction - LookupDispatchAction

In moltissimi casi, unapplicazione Web caratterizzata da una serie di
funzionalit che sono pi o meno logicamente correlate. La soluzione di base sarebbe
quella di definire pi action separate, ciascuna delle quali svolga una delle
funzionalit, oppure definire ununica action ed allinterno del metodo execute() gestire
le diverse funzionalit sulla base dei parametri della request.
La migliore soluzione pu essere realizzata utilizzando la classe DispatchAction,
allinterno della quale possibile avere pi metodi, con la stessa signature del metodo
execute(), che implementano le diverse funzionalit.

public class Cl asseAct i on extends Di spat chAct i on {
. . .
public Act i onFor war d met odo1( Act i onMappi ng mappi ng,
. . .
}
public Act i onFor war d met odo2( Act i onMappi ng mappi ng,
. . .
}
. . .
. . .
}

Per poter distinguere linvocazione di un metodo da un altro, alla action viene
assegnato un parametro specificato allinterno del file di configurazione mediante
lattributo parameter. Di volta in volta, tale parametro pu assumere un valore diverso,
tipicamente il nome di uno dei metodi della classe DispatchAction, in modo tale da
utilizzare una delle funzionalit implementate.

<act i on i nput =" pagi na. j sp"
name=" nomeFor mBean" par amet er =" di spat ch"
pat h=" / nomeAct i on" scope=" r equest "
t ype=" package. Cl asseAct i on" >
<f or war d name=" nomeFor war d1" pat h=" pagi na1. j sp" / >
. . .
<f or war d name=" nomeFor war dN" pat h=" pagi naN. j sp" / >
</ act i on>
90
_________________________________________________________________

In conclusione, ciascuna request, destinata alla action, dovr specificare il nome di
questultima, seguito dal parametro con il suo relativo valore, per invocare uno dei
metodi interni alla classe.

<ht ml : f or mact i on=" / nomeAct i on. do?di spat ch=met odo1" >
. . .
</ ht ml : f or m>

Un ulteriore miglioramento stato introdotto dalla classe LookupDispatchAction, la
quale prevede il metodo getKeyMethodMap(), che restituisce un oggetto della classe
Map, facendo corrispondere ad un certo messaggio del ResourceBundle, il nome di
uno dei metodi della classe. In questo modo, la request non deve necessariamente
assegnare al parametro suddetto il nome del metodo da invocare, ma anche
eventualmente un messaggio del ResourceBundle.

2.1.3.3 SwitchAction

La classe SwithcAction stata introdotta dalla versione 1.1 del framework, in
concomitanza con la nuova potenzialit di poter sviluppare le applicazioni di grandi
dimensioni suddividendole in moduli separati. Tale classe, infatti, permette di passare
da un modulo allaltro ed in particolare raggiungere una delle risorse del modulo
scelto. Per fare questo, la action va invocata con due parametri :

- prefix : definisce il nome del modulo verso cui spostare il controllo;
- page: lURI della risorsa a cui accedere, allinterno del modulo scelto;

/ swi t ch. do?page=[ pagi na. j sp] &pr ef i x=[ pr ef i ssoModul o]

2.1.4 ActionForward

Come visto in precedenza, il metodo execute() della classe Action, che
gestisce una certa richiesta, fornisce come parametro di uscita un oggetto della classe
91
_________________________________________________________________
ActionForward. Tale classe rappresenta unastrazione logica di una risorsa Web, che
pu essere una pagina JSP, una Servlet oppure eventualmente unaltra action.
Essa costruita (wrapper) intorno a ciascuna risorsa, in modo da disaccoppiare
lapplicazione dalla locazione fisica delle stessa, che viene specificata nel file di
configurazione. Loggetto della classe ActionForward viene restituito dal metodo
execute() della action, utilizzando il metodo findForward() della classe ActionMapping.
Passando a tale metodo il nome con cui lActionForward mappato nel file struts-
config.xml, viene determinata la risorsa verso la quale inoltrare il flusso
dellapplicazione. Un oggetto ActionForward pu essere creato anche direttamente
allinterno del codice, mediante il suo costruttore, specificando lURL verso il quale
eseguire il forwarding.

2.2 Utility Classes

Nellambito della realizzazione di una Web application, ci sono molto
spesso una serie di operazioni che vanno ripetute pi volte. Tale situazione si verifica
anche con il framework Struts, il quale raggruppa tutte queste funzionalit in
opportune classi di utilit, in modo da poter essere condivise fra pi componenti ed
utilizzate da pi applicazioni.
Tali classi sono raggruppate in package separati e le principali sono le seguenti :

- classe RequestUtils : mette a disposizione una serie di metodi per gestire
ciascuna richiesta pervenuta alla Web application;
- classe ResponseUtils : ha un ruolo simile alla classe precedente, con la
differenza che orientata alla gestione delle response;
- commons-package BeanUtils : per la gestione dei JavaBeans definiti allinterno
dellapplicazione, in particolare per popolare i formbean con i dati immessi
dallutente ed accedere alle relative propriet;

92
_________________________________________________________________
2.3 Model Components

Nellambito del pattern MVC, il Model caratterizzato da tutte le classi che
costituiscono la business-logic ed implementano le funzionalit offerte
dallapplicazione.
Tali componenti devono essere completamente indipendenti dal tipo di framework
che viene adottato, in virt del fatto che in una architettura a livelli, i livelli superiori
devono essere legati a quelli inferiori, ma non vale il viceversa.
Nel momento in cui, allinterno delle classi della business-logic, utilizziamo elementi
del framework, si viola tale modello e si determina un accoppiamento tra due livelli
che devono essere indipendenti.

Figura 5 - Dipendenza dei livelli

Allinterno del Model, si definiscono i cosiddetti business-object (BO), i quali non
rappresentano nientaltro che delle astrazioni software delle entit del mondo reale.
Affinch una classe possa essere considerata un business-object, necessario che
abbia le seguenti caratteristiche :

- mantenga uno stato e definisca un comportamento;
- rappresenti una entit del dominio del problema;
- sia riutilizzabile;

Strutturando il Model in questo modo, esso diventa assolutamente indipendente dal
framework che verr adottato per realizzare la Web application. In alcuni casi, si
potrebbe pensare di utilizzarlo anche per lo sviluppo di unapplicazione desktop e
non orientata al Web.
93
_________________________________________________________________
In relazione al framework Struts, questultimo non vincola lo sviluppatore nel dover
realizzare il Model con una particolare tecnologia. I principali strumenti adottati per
la realizzazione dei business-object, sono tipicamente gli Enterprise JavaBeans (EJB)
oppure i pi semplici JavaBeans (JB), fortemente affermati nella programmazione
Java.
Mediante questi strumenti, possibili sviluppare le classi del Model definendone sia i
dati (lo stato dellapplicazione) che i metodi (il comportamento). Infine, per garantire
la persistenza delle informazioni, necessario fare in modo che tali oggetti siano
associati ad una base di dati. La mappatura tra i due elementi, pu essere realizzata in
due modi principali :

- JDBC : si realizzano ulteriori classi che sfruttano le funzionalit dei driver
JDBC (Java DataBase Connectivity) per accedere alle basi di dati. In questo
modo, ciascun oggetto della business-logic utilizza loggetto corrispondente
JDBC per garantirsi la propria persistenza;
- ORM Frameworks : si utilizzano dei particolari frameworks, detti ORM
Object to Relational Mapping, i quali eseguono la mappatura in maniera
automatica. Tra i pi importanti da ricordare Hibernate.

2.4 View Components

In generale, la View rappresenta la visualizzazione del Model
dellapplicazione, secondo una certa interfaccia utente. Ci vuol dire che possono
esistere pi View differenti a dispetto di un unico Model.
Tipicamente, nellambito di Struts, le differenti Views vengono realizzate attraverso le
pagine JSP, sfruttando le diverse librerie di tag che il framework mette a disposizione.
Un ruolo fondamentale, nellinterazione con lutente, giocato dalla classe
ActionForm, che permette di definire i formbean mediante i quali vengono raccolti i
dati che lutente immette attraverso i form dellapplicazione.

94
_________________________________________________________________
2.4.1 ActionForm

Generalmente, ogni Web application prevede linterazione con lutente e
quindi limmissione, da parte di questultimo attraverso dei form costituiti da uno o
pi campi, di dati su cui verranno eseguite le elaborazioni. Una volta che i dati
vengono trasmessi, lapplicazione deve farsi carico di acquisirli, validarli ed in caso di
errore visualizzare un messaggio allutente ed infine, di elaborarli.
Per poter eseguire tutte queste operazioni nel modo pi semplice possibile, Struts
mette a disposizione la classe ActionForm, la quale ha come compito principale quello
di raccogliere i dati dai form riempiti dallutente e metterli a disposizione di una
action, per eseguirne lelaborazione. Ulteriore funzionalit fornita da questa classe la
validazione mediante la quale possibile controllare che i dati immessi dallutente
siano corretti ed, in caso di esito negativo, segnalare gli errori a questultimo. In
generale, non bisogna dichiarare un formbean per ogni form HTML previsto
dallapplicazione, perch lo stesso formbean pu essere condiviso ed associato a pi
action. Ovviamente, necessario definirne anche lambito di visibilit , che pu
essere di due tipi :

- request : i dati del formbean sono memorizzati fino al completamento del ciclo
request-response, dopodich viene cancellato;
- session : i dati del formbean sono disponibili durante tutta la sessione utente;

Ciascun formbean prevede un particolare ciclo di vita, nellambito del quale si
possono distinguere le seguenti fasi :

- la richiesta arriva al Controller con i dati di un certo form;
- viene creato un nuovo formbean oppure riciclato quello esistente;
- viene invocato il metodo reset() che annulla un eventuale contenuto
precedente del formbean;
- il formbean viene memorizzato nellambito di visibilit (scope), specificato
nel file di configurazione;
- i dati della richiesta vengono trasferiti nel formbean, che viene cos popolato;
95
_________________________________________________________________
- viene eseguita la validazione dei dati, solo se espressamente specificata nel file
di configurazione;
- se ci sono errori, il controllo ritorna alla pagina di input dei dati altrimenti
viene invocato il metodo execute() della action, a cui il formbean associato,
per elaborare i dati;

Figura 6 - Ciclo di vita della ActionForm

La classe ActionForm , per, una classe astratta, per cui necessario implementare
una propria classe che la estenda per poter definire un formbean necessario
allinterno dellapplicazione. Tale classe avr al suo interno una serie di propriet che
corrispondono ai campi del form ed i relativi metodi getter e setter, per accedere ad
esse. Inoltre, necessario eseguire loverriding dei due seguenti metodi :

- reset() : per poter resettare il contenuto del formbean;
- validate() : per poter eseguire la validazione dei dati contenuti nel form e
restituire un oggetto ActionErrors con eventuali messaggi di errore, se la
validazione non ha avuto esito positivo;

96
_________________________________________________________________
public voi d r eset ( Act i onMappi ng mappi ng,
Ht t pSer vl et Request r equest ) {
. . .
}

public Act i onEr r or s val i dat e( Act i onMappi ng mappi ng,
Ht t pSer vl et Request r equest ) {
. . .
}

Ogni formbean realizzato va, inoltre, dichiarato allinterno del file di configurazine
XML ed assegnata, sempre allinterno di questultimo, alle action che potranno
eseguire sui dati le corrispondenti elaborazioni.

<f or m- bean name=" nomeFor mBean" t ype=" package. Cl asseAct i onFor m" / >

E da sottolineare, che la signature del metodo execute() di una action, prevede tra i
parametri di ingresso, proprio il formbean con i dati su cui andranno eseguite le
operazioni della business-logic.

2.4.2 ActionErrors

In generale, i dati che vengono immessi dallutente allinterno di un form
della Web application, sono sottoposti ad unoperazione di validazione. Lesito di
questultima non sempre positivo ed , in caso di errori, necessario visualizzare
allutente dei messaggi di errore, per segnalare che i dati immessi non sono corretti.
Tali errori vengono memorizzati nel sistema, mediante la classe ActionErrors.
Tipicamente, nel momento in cui richiesta la validazione dei dati, viene invocato il
metodo validate() del formbean, derivato da ActionForm. Se durante la validazione si
verificano uno o pi errori, viene creato un oggetto ActionErrors, il quale altro non
che una lista, allinterno della quale possono essere salvati tali errori con i relativi
messaggi da visualizzare allutente. La classe prevede il metodo add(), mediante il
quale si pu aggiungere un messaggio ed associarlo ad un elemento della View, in cui
verr eseguita la visualizzazione.

97
_________________________________________________________________
Le classi che permettono di creare dei messaggi di semplice segnalazione o di errore
allutente sono le seguenti :

- ActionMessage:
- ActionError;

2.4.2.1 ActionMessage ActionError

Il framework Struts prevede la classe ActionError, per creare dei messaggi di
warning o di errore da visualizzare allutente. Dalla versione 1.1, stata aggiunta la
classe ActionMessage, per un motivo puramente concettuale. Infatti, facendo uso
soltanto della classe ActionError, anche un messaggio qualsiasi, non di errore,
verrebbe interpretato come tale, dallo sviluppatore che legge o crea il codice. Per
poter distinguere un errore, da un semplice messaggio da visualizzare nella View,
stata introdotta la classe ActionMessage, la quale altro non che una generalizzazione
della ActionError. Ovviamente, stata aggiunta anche la classe ActionMessages che, alla
pari della classe ActionErrors, si fa carico di memorizzare pi messaggi allinterno di
una lista.

Figura 7 - Class Diagram Messages/Errors

98
_________________________________________________________________
2.4.3 DynaActionForm

Uno dei problemi che sorge nellutilizzo della classe ActionForm per la
realizzazione dei formbean, il numero elevato di classi da creare e da aggiungere al
proprio progetto software. Infatti, se i form HTML della Web application sono
numerosi, altrettanto numerose saranno le classi che dovranno derivare da
ActionForm e realizzare i formbean relativi. Per risolvere questo problema, alcuni
sviluppatori creano un unico formbean, le cui propriet corrispondono a tutti i campi
di tutti i form HTML Unaltra conseguenza delluso di pi classi ActionForm, deriva
dal fatto che, se vengono aggiunti o rimossi dei campi ad uno o pi form HTML, c
bisogno di modificare anche le classi dei formbean corrispondenti e ricompilarle.
Per questi motivi, stata introdotta la possibilit di realizzare dei formbean dinamici
facendo uso della classe DynaActionForm, la quale altro non che unestensione della
classe ActionForm.

Figura 8 - Class Diagram DynaActionForm/ActionForm

Le differenze sostanziali fra queste due classi, riguardano i tre seguenti aspetti :

- le propriet del formbean;
- il metodo validate();
- il metodo reset();
99
_________________________________________________________________

Le propriet di un formbean dinamico sono definite allinterno del file di
configurazione struts-config.xml. Durante lesecuzione della Web application, il
framework crea unistanza della classe e mette a disposizione dei metodi getter e
setter per accedere a tali propriet. La modifica oppure lintroduzione di uno o pi
propriet, prevede lintervento sul file di configurazione e tutto ci garantisce grande
potenza e flessibilit.

<f or m- bean name=" nomeFor mBeanDi nami co"
t ype=" or g. apache. st r ut s. val i dat or . DynaVal i dat or For m" >
<f or m- pr oper t y name=" por pr i et a1" t ype=" Cl assePr opr i et a1" / >
. . .
<f or m- pr oper t y name=" pr opr i et aN" t ype=" Cl assePr opr i et aN" / >
</ f or m- bean>

Il metodo reset() invocato allo stesso modo della classe ActionForm, con la differenza
che non si ha un maggior controllo delle operazioni che vanno eseguite al suo
interno. Il comportamento di default del metodo, prevede di assegnare alle propriet
del formbean dinamico, dei valori iniziali che vengono sempre specificati allinterno
del file dello stesso file di configurazione. Qualora si voglia modificare tale
comportamento, necessario realizzare una classe che estenda DynaActionForm e
quindi eseguire loverriding del metodo reset(). Infine, la validazione di un formbean
dinamico potrebbe essere eseguita realizzando una classe che estenda DynaActionForm
ed esegua loverriding del metodo validate(). In generale, per evitare lo sviluppo di
classi aggiuntive, si fa uso del plug-in Validator, il quale mette a disposizione una
serie di regole di validazione gi pronte per luso.

2.4.4 Tag Libraries

Nellambito della View, oltre alle classi che permettono di gestire tutto ci
che riguarda linterazione e lo scambio dei dati tra utente ed applicazione, rientrano
anche le librerie di tag che Struts mette a disposizione per la realizzazione della UI.
Queste ultime, non soltanto offrono la possibilit di introdurre gli elementi grafici in
una pagina JSP, ma ne permettono anche la costruzione dinamica, oltre alla
possibilit di accedere alle propriet dei beans previsti dallapplicazione.
100
_________________________________________________________________
La libreria Struts HTML mette a disposizione tutti gli elementi che permettono di
realizzare i form e che definiscono quella che la grafica dellapplicazione. Il limite
principale del framework dettato dalla non indipendenza dal dispositivo con cui si
accede alla Web application, per cui viene fornita una libreria che permette di definire
linterfaccia utente solo ed esclusivamente per un browser Web.
La libreria Struts Bean dispone di tutti i tag per poter visualizzare e modificare i valori
delle propriet dei bean previsti dallapplicazione. Ciascun tag ha sempre gli attributi
che permettono di identificare il bean e la propriet di interesse, separatamente luno
dallaltro. Non supportato lutilizzo dellExpression Language, per accedere alle
propriet di un bean con la consueta dot notation, tipica della programmazione ad
oggetti. Per usufruire di questa funzionalit, necessario utilizzare la versione evoluta
di questa libreria oppure fare affidamento alle librerie JSTL.
Infine, la libreria Struts Logic fornisce una serie di tag che permettono di definire dei
costrutti logici e condizionali allinterno di una pagina JSP, per poter costruire il
contenuto di questultima in maniera dinamica e sulla base di particolari condizioni.
Anche in questo caso, la specifica delle condizioni viene eseguita attraverso gli
attributi dei tag che non supportano lEL, mediante il quale le operazioni
diventerebbero notevolmente pi semplici, potendo utilizzare gli operatori logici del
linguaggio Java.

3. Ciclo di vita di una richiesta

Il ciclo di vita di una richiesta ha una struttura standard, tipica del pattern
MVC. Il client invia la richiesta al Web Container, il quale si fa carico di smistarla
verso la ActionServlet che gestisce lapplicazione. Questultima utilizza listanza della
classe RequestProcessor, alla quale trasferisce la richiesta sottoposta al server. In
memoria, prevista limmagine del file di configurazione strutturata mediante una
serie di classi, attraverso le quali viene eseguita loperazione di action mapping, ossia
individuare quale sia la action che deve occuparsi della gestione della richiesta.
Inoltre, vengono istanziati, popolati e validati i formbean che contengono i dati della
richiesta. A questo punto, termina il primo intervento del Controller, il quale invoca
la action individuata per permettere lesecuzione delle elaborazioni richieste. La
action si pone come un bridge tra Controller e Model, utilizzando i formbean,
101
_________________________________________________________________
contenenti i dati da elaborare, e gli oggetti delle business-logic. Al termine
dellesecuzione della action, viene restituito il forward attraverso il quale, il
Controller, determina la pagina JSP della View verso la quale far proseguire la
navigazione.

Figura 9 - Ciclo di vita di una richiesta

4. Exception Handling

Prima delle versione 1.1, il framework Struts forniva un meccanismo di
gestione delle eccezioni piuttosto semplice, che spingeva gli sviluppatori a realizzare
soluzioni differenti per poter gestire le condizioni di errore nelle proprie applicazioni.
Dalla versione 1.1, stato introdotto un meccanismo non molto ampio ma
abbastanza efficiente, che permette di gestire le eccezioni in due modalit :

- dichiarativa : le eccezioni, che possono essere sollevate nellambito
dellapplicazione, sono dichiarate allinterno del file di configurazione e
gestite in maniera automatica dal framework;
- programmatica : le eccezioni sono gestite direttamente nel codice delle action,
nella modalit consueta del linguaggio Java;

La gestione delle eccezioni viene eseguita mediante lutilizzo della classe
ExceptionHandler, della quale Struts ne fornisce una versione di base ma con la
102
_________________________________________________________________
possibilit di estenderla, per poter realizzare un gestore delle eccezioni
personalizzato. Tale classe dotata del metodo execute(), allinterno del quale viene
creato un oggetto ActionError, per contenere le informazioni riguardanti lerrore
verificatesi e restituisce un oggetto ActionForward che specifica la risorsa verso la quale
proseguire la navigazione per segnalare allutente il verificarsi delleccezione.

4.1 Approccio Dichiarativo

Nel caso in cui uneccezione non sia gestita in maniera programmatica
allinterno di una action, il RequestProcessor si fa carico di verificare se essa sia
dichiarata allinterno del file di configurazione, utilizzando la classe ExceptionConfig. Il
contenuto di quesultima definito in fase di start-up dellapplicazione, quando viene
eseguito il parsing del file struts-config.xml e le eccezioni dichiarate vengono caricate in
memoria. La classe RequestProcessor prevede il metodo processException(), allinterno del
quale vengono individuate le informazioni relative alleccezione che stata sollevata e
viene istanziato lExceptionHandler per la sua gestione.

Figura 10 - Gestione delle eccezioni

Uno dei vantaggi principali dellapproccio dichiarativo riguarda soprattutto la
gestione delle eccezioni che si verificano al tempo di esecuzione (runtime). Tali
eccezioni, facenti parte della classe RuntimeException, sono notoriamente
103
_________________________________________________________________
unchecked, ossia non controllate e non possono essere gestite mediante i tipici
blocci try-catch-finally. In questi casi, per evitare che lapplicazione si blocchi fornendo
un messaggio poco user-friendly allutente, possibile dichiarare uneccezione globale
di questo tipo nel file di configurazione, assegnandole una pagina verso la quale
redirezionare lutente, per segnalargli il problema in maniera pi amichevole.

<gl obal - except i ons>
<except i on bundl e=" Appl i cat i onResour ces"
key=" chi aveMessaggi oEr r or e"
pat h=" / pagi naEr r or e. j sp"
t ype=" j ava. l ang. Runt i meExcept i on" / >
</ gl obal - except i ons>

4.2 Approccio programmatico

Un approccio alternativo a quello dichiarativo, lapproccio
programmatico. Questultimo prevede che la gestione delle eccezioni venga eseguita
completamente attraverso il codice allinterno di una action e non preveda lutilizzo
di informazioni del file di configurazione. Ovviamente, tale approccio rende la
gestione molto pi complessa, in quanto lo sviluppatore che deve occuparsi di
catturare uneccezione, salvare i messaggi di errore negli oggetti ActionError e
produrre gli oggetti ActionForward per far proseguire la navigazione.
I due tipi di approcci non sono mutuamente esclusivi, ma viceversa possono essere
utilizzati contemporaneamente. Infatti, la prima opportunit di catturare
uneccezione allinterno della classe Action che la solleva e, nel caso in cui non se ne
sia prevista la gestione, essa viene catturata nel metodo processActionPerfom() della
classe RequestProcessor, la quale proseguir con lapproccio dichiarativo.

4.3 ModuleException

Il framework mette a disposizione una particolare classe, nota come
ModuleException, per sollevare delle eccezioni che possano poi essere gestite mediante
lapproccio dichiarativo. Infatti, allinterno del metodo execute() di una action, qualora
si verificasse una condizione di errore, possibile sollevare uneccezione di questo
104
_________________________________________________________________
tipo, che in maniera completamente automatica crea loggetto ActionError nel quale
possibile specificare il messaggio da visualizzare allutente.

. . .
Modul eExcept i on me = new Modul eExcept i on( " chi aveMessaggi oEr r or e" ) ;
throw me;
. . .

Tipicamente, tale eccezione sar dichiarata allinterno del file di configurazione, per
cui sar il RequestProcessor che si occuper di catturarla e delegarne la gestione alla
classe ExceptionHandler .

t ype=" or g. apache. st r ut s. ut i l . Modul eExcept i on" / >

Lunico limite nellutilizzo di questa classe di determinare un accoppiamento tra
lapplicazione e la modalit di gestione delle eccezioni di Struts, rendendo pi
complesso il procedimento di sostituzione del framework adottato, lasciando
inalterato lo strato applicativo sottostante.

5. Internazionalizzazione (I18N)

Tipicamente, gli sviluppatori focalizzano la loro attenzione sulla
realizzazione di unapplicazione per la risoluzione di un certo problema. Nella
maggior parte dei casi, viene perso di vista un aspetto fondamentale che riguarda il
pubblico a cui diretto lutilizzo dellapplicazione stessa. Soprattutto nel caso di Web
application fruibili attraverso Internet, si pone il problema di permettere lutilizzo di
questultima, a persone di paesi e lingue differenti.
LInternazionalizzazione (I18N) un processo che prevede lo sviluppo di un
software per poter supportare nel tempo pi lingue e stati diversi , in modo tale che
non ci sia bisogno di reingegnerizzare il sistema nel momento in cui sar necessario
fornire supporto per ulteriori di essi.
105
_________________________________________________________________
Le caratteristiche principali di un software che supporta lInternazionalizzazione sono
le seguenti :

- le lingue devono essere supportate senza la necessit di apportare modifiche
al codice;
- i messaggi da visualizzare agli utenti sono contenuti in risorse esterne e
completamente al di fuori del codice;

Il framework Struts mette a disposizione tali caratteristiche utilizzando le principali
classi Java che si occupano dellinternazionalizzazione : Locale e ResourceBundle.
La classe Locale contiene le informazioni relative appunto al locale associato
allutente che utilizza lapplicazione. Con il termine locale si intende una regione
nellambito della quale sono condivisi costumi, culture e lingue. Attraverso tale classe,
possibile risalire alle informazioni relative alla valuta, alla formattazione delle date e
delle ore ed a tante altre informazioni specifiche.
La classe ResourceBundle permette, invece, di definire la risorsa esterna allinterno della
quale sono salvati i messaggi da visualizzare allutente in una certa lingua. Attraverso
lutilizzo di questa classe, possibile accedere ad essi direttamente da codice,
mediante un meccanismo key-message (chiave-messaggio), in base al quale,
specificando una chiave, si ricava il messaggio corrispondente associato.
Generalmente, quando un utente accede ad una Web application realizzata con
Struts, questultimo memorizza allinterno della sessione utente, il locale definito dal
browser che questultimo sta adottando. Mediante questa informazione, quindi
possibile accedere al giusto Resource Bundle, da cui prelevare i messaggi da
visualizzare allutente nella sua lingua.
Struts prevede la definizione di uno o pi file .properties, aventi lo stesso nome ma un
suffisso diverso, che specifica la lingua adottata nei messaggi contenuti nel file,
attraverso le coppie key-message.

106
_________________________________________________________________
6. JavaServer Pages Standard Tag Library (JSTL)

Per la realizzazione della View, Struts mette a disposizione alcune librerie di
tag, attraverso le quali, dalle pagine JSP, possibile eseguire le seguenti operazioni:

- visualizzare gli elementi costitutivi dei form e che caratterizzano
completamente linterfaccia utente;
- accedere alle propriet dei bean che caratterizzano lapplicazione;
- eseguire delle operazioni logiche, in modo da permettere la costruzione di
ciascuna pagina in base al verificarsi o meno di determinate condizioni;

Attraverso queste librerie, possibile eseguire tutte le operazioni necessarie, anche se
manca uno strumento molto potente come lExpression Language. Questultimo, a
differenza del framework JSF, non supportato in forma nativa in Struts, per cui
dalle pagine JSP non possibile accedere a metodi e propriet dei bean utilizzando le
tipiche espressioni dellEL, caratterizzate dalla dot notation. Per superare questo
limite, stata realizzata una versione evoluta delle librerie del tutto uguali a quelle
di base, con lunica differenza che i tag supportano lExpression Language. Nella
maggior parte dei casi, per, si preferisce utilizzare un particolare set di librerie di tag
noto come JSTL (JavaServer Pages Standard Tag Library) che ovviamente supporta
lEL. Queste librerie sono complessivamente cinque, cos definite :

- Core : per laccesso alle propriet dei bean dellapplicazione, per gestire il
flusso di controllo attraverso costrutti condizionali ed iterativi e per la
gestione degli URL ;
- Internationalization : per la gestione dellinternazionalizzazione (I18N), per la
visualizzazione e formattazione dei messaggi;
- XML : per la manipolazione di documenti XML direttamente da una pagina
JSP;
- SQL : per effettuare accessi ed operazioni a basi di dati;
- Functions : fornisce una serie di funzioni di uso comune da poter applicare a
variabili oppure propriet dei bean;

107
_________________________________________________________________
Tipicamente, per la realizzazione di unapplicazione con Struts, sono necessarie
soltanto le prime due che vanno a sostituire le librerie HTML, Bean e Logic. La
libreria XML viene utilizzata solo nel caso in cui sia necessario gestire direttamente
da una pagina JSP dei documenti XML, mentre la libreria Functions trova
applicazione qualora si abbia bisogno di funzioni particolari da eseguire. Infine, la
libreria SQL viene utilizzata solo nel caso di applicazioni di dimensioni estremamente
ridotte, in quanto non mai una buona soluzione, introdurre il codice per accedere
alle basi di dati, allinterno della View. Nella maggior parte dei casi, si preferisce
realizzare delle classi che si occupano esclusivamente dellaccesso ai database, in
modo da separare nettamente queste operazioni dalla presentazione dei risultati.

7. Estensioni con i PlugIn

Il framework Struts mette a disposizione un particolare meccanismo
mediante il quale possibile estenderne la struttura, ossia la definizione e luso del
plug-in. Basti pensare che gli stessi Tiles e Validator sono dichiarati come tali
allinterno del file di configurazione, in quanto non sono parte integrante
dellarchitettura di Struts. Ovviamente, lo sviluppatore ha la possibilit di realizzare
una classe che implementi linterfaccia PlugIn per poter disporre di un proprio plug-in
con cui estendere le funzionalit dellapplicazione sviluppata. Luso di un plug-in pu
essere particolarmente conveniente quando necessario effettuare una serie di
elaborazioni una sola volta, nella fase di start-up dellapplicazione. Infatti, il
framework effettua il caricamento dei plug-in configurati nella fase di inizializzazione
della Web application, cos come la corrispondente eliminazione nel caso di
shutdown oppure riavvio del Web Container. In entrambi i casi, vengono eseguiti i
due corrispondenti metodi di cui deve essere sempre dotata una classe che
rappresenta un plug-in :

- initi() : viene eseguito allavvio dellapplicazione e pu contenere tutte le
operazioni necessarie allo startup della Web application;
- destroy() : viene invocato alla chiusura dellapplicazione per distruggere il
plug-in;
108
_________________________________________________________________

public void i ni t ( Act i onSer vl et act i onSer vl et ,
Modul eConf i g modul eConf i g)
throws Ser vl et Except i on {
. . .
}

public void dest r oy( ) {
. . .
}

Una volta effettuato loverriding dei due metodi suddetti, basta dichiarare il plug-in
allinterno del file struts-config.xml.

<pl ug- i n cl assName=" package. Cl assePl ugI n" / >

8. Validator framework

Per poter eseguire la validazione dei dati immessi dallutente allinterno dei
form, il framework Struts prevede che la classe ActionForm, utilizzata per definire un
formbean, abbia il metodo validate() che venga eseguito subito dopo linvio del form
stesso. Un approccio di questo tipo , ovviamente, programmatico e talvolta pu
presentare una serie di limitazioni.
In primo luogo, c da dire che la maggior parte dei form presenti in una Web
application, hanno dei campi che possono contenere dei dati soggetti allo stesso tipo
di validazione, per cui si costretti a realizzare pi metodi validate() praticamente
uguali. Nel momento in cui c la necessit di effettuare una modifica, questultima
andr eseguita in tutti i metodi realizzati e comporter la ricompilazione del codice.
Per questi motivi, stato implementato un particolare framework che permette di
gestire la validazione dei dati in maniera dichiarativa. Dato il suo notevole utilizzo, da
parte degli sviluppatori, si deciso di considerarlo un progetto Jakarta ed introdurlo
in ogni distribuzione di Struts.
Il framework Validator permette di trasferire la logica della validazione
completamente fuori dalle classi ActionForm, configurando in maniera dichiarativa
tutte le regole di validazione in un file XML. Esso fornisce una serie di funzioni
standard per le validazioni pi comuni ma completamente estendibile, in quanto
109
_________________________________________________________________
permette allo sviluppatore di realizzare e configurare dei metodi di validazione
personalizzati.
La distribuzione del framework prevede una serie di classi ed in particolare due file
XML, che ne permettono la configurazione in maniera semplice :

- validation-rules.xml;
- validation.xml;

Il file validation-rules.xml contiene una serie di funzioni che permettono di eseguire le
validazioni tipiche, come ad esempio :

- valutare se linput immesso dallutente sia o meno di un certo tipo (Integer,
Float, Double, Long,);
- valutare se un data immessa abbia un formato corretto;
- valutare se linput ricada entro un certo range oppure abbia una lunghezza
che rispetto un limite minimo e massimo fissati;
- valutare se lutente abbia immesso un valore in un campo che sia
obbligatorio;
- valutare se un certo dato soddisfi un particolare pattern;
- valutare se un valore che debba rappresentare una carta di credito oppure un
indirizzo email, abbia un formato corretto;

Ovviamente, a queste funzioni incluse nel framework ne possono essere aggiunte
delle ulteriori, estendendo le classi principali del framework stesso.
Il file validation.xml permette di configurare tutti i form della Web application, i cui
campi debbano essere soggetti a validazione e, per ogni form, specificare per ciascun
campo la funzione di validazione da applicare. Il tag <formset> viene utilizzato per
raggruppare tutti i form suddetti, ciascuno dei quali viene definito mediante il tag
<form>. Inoltre, allinterno di questultimo sono previsti uno o pi tag <field> che
permettono di specificare i campi che costituiscono il form in questione. Per
ciascuno di essi possibile specificarne il nome, mediante lattributo property, e la
regola di validazione da applicare, mediante lattributo depends.

110
_________________________________________________________________
<f or mname=" nomeFor m" >
<f i el d depends=" r equi r ed" pr oper t y=" pr opr i et a1" / >
. . .
<f i el d depends=" r equi r ed, mi nl engt h" pr oper t y=" pr opr i et aN" >
</ f or m>

Generalmente, i form e le relative propriet specificate allinterno di questo file,
devono coincidere con le informazioni dei corrispondenti formbean che sono
configurati allintero del file struts-config.xml dellapplicazione.
Lultima considerazione da fare legata al fatto che il framework Validator
perfettamente integrato con Struts ed il suo utilizzo prevede che esso venga
dichiarato allinterno del file di configurazione come se fosse un plug-in, specificando
i percorsi dei file XML che lo caratterizzano.

<pl ug- i n cl assName=" or g. apache. st r ut s. val i dat or . Val i dat or Pl ugI n" >
<set - pr oper t y pr oper t y=" pat hnames"
val ue=" / WEB- I NF/ val i dat or - r ul es. xml ,
/ WEB- I NF/ val i dat i on. xml " / >
</ pl ug- i n>

9. Tiles framework

Tiles un framework mediante il quale possibile realizzare il Presentation
Layer di una Web application, separando il layout dai contenuti (contents). Mentre il
layout definisce la struttura di una pagina, con la caratteristica che pi pagine
possono avere il medesimo layout, il contents definisce il contenuto di ciascuna di
esse e pu essere diverso da pagina a pagina oppure eventualmente uguale in alcuni
casi. E notevolmente importante poter separare luno dallaltro, in modo tale che
apportando delle modifiche al primo non sussiste alcuna influenza sul secondo e
viceversa. Il framework permette di costruire le pagine assemblando i cosiddetti
tiles, il cui significato banalmente mattonelle evidenziando che sono dei
componenti riutilizzabili che possono essere disposti in una struttura predefinita.
Nella maggior parte dei casi, ogni tile non nientaltro che una pagina JSP che a sua
volta pu essere composta da altri tiles. E possibile distinguerne due tipologie :

- tile Layout : tile che definisce la struttura di una pagina. Esso riceve da una
pagina (tile non-Layout) il contenuto e lo dispone secondo tale struttura;
111
_________________________________________________________________
- tile non-Layout : tile che utilizza un layout (tile Layout) passando a questultimo
degli attributi che rappresentano il contenuto da disporre secondo una certa
struttura;

Generalmente, nellambito di una Web application, il tile Layout unico e definisce la
struttura di tutte le pagine, mentre ciascuna pagina definita attraverso un proprio
tile non-Layout.
Luso dei tiles pu essere paragonato alluso dei metodi in Java. Un metodo in Java
costituito da un body che ne definisce lelaborazione e dai parametri di ingresso che
specificano i dati su cui questultima va effettuata. Un tile pu essere considerato
come un metodo, in quanto bisogna definirne la struttura e passargli dei parametri,
detti attributi, che ne descrivano il contenuto. Ciascuno di essi memorizzato nel
context del tile stesso, attraverso la classe ComponentContext facente parte del
framework. Infine, ogni attributo pu essere una stringa oppure tipicamente una
pagina JSP.
Nella maggior parte dei casi, il layout utilizzato per ciascuna pagina proposto in
figura.

Figura 11 - Layout Header/Footer/Menu/Body

Esso prevede fondamentalmente quattro parti : header, footer, menu e body.
Tipicamente, lheader ed il footer sono comuni a tutte le pagine, per cui il loro
contenuto viene definito ununica volta. Il vantaggio che ne scaturisce dato dal fatto
che se deve essere apportata una modifica ad uno di essi, questultima va eseguita
112
_________________________________________________________________
ununica volta e non per tutte le pagine della Web application. Il menu, invece, pu
essere lo stesso nellambito di tutta lapplicazione e quindi avr il medesimo
vantaggio di header e footer oppure pu variare in relazione alla pagine visitate.
Infine, il body tipicamente diverso da pagina a pagina.
Per quanto riguarda la relazione con Struts, Tiles perfettamente integrato con
questultimo, in quanto contenuto in ciascuna distribuzione, e viene dichiarato
allinterno del file di configurazione in termini di plug-in.

<pl ug- i n cl assName=" or g. apache. st r ut s. t i l es. Ti l esPl ugi n" >
<set - pr oper t y pr oper t y=" def i ni t i ons- conf i g"
val ue=" / WEB- I NF/ t i l es- def s. xml " / >
<set - pr oper t y pr oper t y=" modul eAwar e" val ue=" t r ue" / >
</ pl ug- i n>

9.1 Definitions

I tiles possono essere descritti attraverso le cosiddette definitions, dichiarate
in un file XML e che permettono :

- una dichiarazione centralizzata di una pagina;
- se si dispone di pi tiles non-Layout con un contenuto uguale (es. le pagine
hanno il medesimo header e footer), al posto di definire tale contenuto
pagina per pagina, lo si definisce ununica volta rendolo comune a tutte le
pagine;
- supporto alla derivazione, descrivendo una nuova definition che ne estenda
una preesistente, ereditandone le caratteristiche ed aggiungendone delle altre;

Generalmente, il file che contiene le definitions noto come tiles-defs.xml e ciascuna di
esse dichiarata attraverso il tag <definition> che mediante i suoi attributi permette di
specificare le seguenti informazioni :

- nome della definition per referenziarla allinterno di un tile che ne far uso
(name);
- percorso del tile Layout che descrive la struttura associata alla definition
(path);
113
_________________________________________________________________
- definition da cui eseguire la derivazione (extends);

Per specificare gli attributi della definition, possibile utilizzare uno o pi tag <put>,
ciascuna dei quali prevede le seguenti informazioni :

- nome dellattributo;
- valore dellattributo che pu essere una stringa, una pagina JSP oppure
unaltra definition se si prevede di utilizzare la composizione di pi
definitions;

<t i l es- def i ni t i ons>
<def i ni t i on name=" page. t empl at e" pat h=" / pagi naLayout . j sp" / >
<def i ni t i on name=" page. header " pat h=" / header . j sp" / >
<def i ni t i on name=" page. f oot er " pat h=" / f oot er . j sp" / >
<def i ni t i on name=" page. menu" pat h=" / menu. j sp" / >
</ t i l es- def i ni t i ons>

9.2 Costruzione di una pagina

La costruzione di una pagina JSP secondo un certo layout e con uno
specifico contenuto realizzata attraverso lutilizzo di particolari tag della libreria
Struts Tiles. Il tag che permette di inserire un contenuto oppure utilizzare una
definition allinterno di una pagina JSP <tiles:insert>, il quale prevede le seguenti
informazioni :

- percorso della pagina da inserire (page);
- nome dellattributo (attribute);
- nome della definition da adottare allinterno di un tile non-Layout (definition);

Ovviamente, la definition utilizzata allinterno di ciscuna pagina avr dei contenuti
comuni fra le pagine ma queste ultime potrebbero anche avere alcuni contenuti
differenti. Per inserire un contenuto nel layout, specificato da una definition,
possibile utilizzare il tag <tiles:put>, il quale descrive le seguenti informazioni :

- nome dellattributo (name);
114
_________________________________________________________________
- valore dellattributo che pu essere una stringa oppure una pagina JSP (value);

<t i l es: i nser t def i ni t i on=" page. t empl at e" >
<t i l es: put name=" t i t l e" val ue=" Ti t ol o" / >
<t i l es: put name=" body"
val ue=" / BodyCont ext . j sp"
t ype=" page" / >
</ t i l es: i nser t >

Attraverso questo meccanismo, le pagine possono avere contenuti comuni che non
devono ulteriormente specificare in quanto definiti allinterno della definition
utilizzata. Nel caso in cui alcuni contenuti debbano essere differenti, basta utilizzare il
tag <tiles:put> mediante il quale il contenuto specificato va a sostituire quello di
default.

10. Sicurezza

La sicurezza di unapplicazione realizzata con il framework Struts
rappresenta un aspetto completamente indipendente da questultimo e pu essere
gestita mediante le funzionalit offerte dal Web Container. Parlare di sicurezza
attraverso la rete significa soprattutto garantire la trasmissione delle informazioni e
dei dati in modalit crittografata, in modo tale da essere inaccessibili dallesterno. Il
meccanismo principale messo a disposizione si basa sul protocollo SSL (Secure
Socket Layer), sulla base del quale stata creata in passato una nuova versione del
protocollo HTTP, ossia lHTTPS. Mediante questultimo, infatti, le informazioni
sono trasmesse dal client al server e viceversa in modalit crittografata, anche sulla
base dellutilizzo di un regolare certificato digitale. Per poter fare in modo che le
pagine di unapplicazione implementata con Struts, utilizzino tale protocollo,
necessario in primo luogo abilitarlo allinterno del Web Container e successivamente
modificare il Deployment Descriptor web.xml dellapplicazione stessa. Allinterno di
questultimo possibile dichiarare dei vincoli di sicurezza (tag <security-constraint>) e
le pagine che ne sono soggette (tag <web-resource-collection>), oltre al tipo di trasporto
da utilizzare (tag <transport-guarantee>) che pu essere di tre tipi :

- NONE : utilizza HTTP;
115
_________________________________________________________________
- INTEGRAL , CONFIDENTIAL : utilizza HTTPS;

<ur l - pat t er n>[ pagi na. j sp] </ ur l - pat t er n>
<ht t p- met hod>PUT</ ht t p- met hod>
<ht t p- met hod>POST</ ht t p- met hod>
</ user - dat a- const r ai nt >

Quanto detto mette in evidenza che la sicurezza di unapplicazione realizzata con
Struts, gestita allo stesso modo di una qualsiasi applicazione Web in Java e quindi
completamente indipendente dal framework.

11. Configurazione dellapplicazione

Il framework Struts utilizza uno o pi file di configurazione per poter
creare e caricare in fase di start-up dellapplicazione, tutte le risorse ed i componenti
necessari a questultima. Tali file permettono di specificare in maniera dichiarativa il
comportamento degli elementi dellapplicazione, evitando che tali specifiche siano
definite allinterno del codice. Questo permette agli sviluppatori di realizzare delle
estensioni e di utilizzarle nella Web application, garantendo che il framework sia
capace di sfruttarle in maniera dinamica. I file di configurazione si basano sul
linguaggio XML e possono essere anche pi di uno, nel momento in cui
lapplicazione realizzata con moduli indipendenti. Ciascuno di essi ha le proprie
informazioni di configurazione, inclusi i Resource Bundles, ed completamente
indipendente dagli altri. Tutto ci favorisce lo sviluppo di unapplicazione di grandi
dimensioni, anche da team di lavoro distinti.
Con la versione 1.1 del framework Struts, stato introdotto il package config,
allinterno del quale ci sono una serie di classi che permettono di memorizzare le
informazioni di configurazione, nel momento in cui queste ultime vengono lette dal
116
_________________________________________________________________
file XML. In questo modo, si ha a disposizione una visione di queste informazioni in
termini di classi, residenti nella memoria e quindi accessibili dallo sviluppatore
direttamente da codice.
Ciascuna classe del package contiene le informazioni che riguardano una parte
specifica del file di configurazione. Dopo che stato eseguito il parsing e la
validazione del file di configurazione, il framework istanzia ed alloca in memoria, gli
oggetti contenenti le informazioni ad essi pertinenti.

Figura 12 - Class Diagram Configurazione

La classe centrale del package l ApplicationConfig, la quale legata a tutte le altre
classi contenenti le informazioni di configurazione. Attraverso listanza di tale classe,
possibile accadere a tutte le altre e quindi alle informazioni in esse memorizzate. Se
lapplicazione sviluppata in moduli, ciascun modulo ha a sua disposizione una
corrispondente istanza di tale classe.

11.1 DataSource

Generalmente, una Web application prevede lutilizzo di un database
allinterno del quale sono memorizzate le informazioni in maniera permanente.
117
_________________________________________________________________
Lutilizzo di una base di dati, oppure pi generalmente di un datasource, pu essere
specificato allinterno del file di configurazione. Per questo scopo, messo a
disposizione il tag <data-source>, che va utilizzato pi volte in relazione al numero di
database di cui dispone lapplicazione, distinguendo un datasource dallaltro
attraverso la specifica di una chiave (key). Inoltre, possibile definire una serie di
propriet caratteristiche del datasource, utilizzando al suo interno uno o pi tag <set-
property>. Le informazioni tipicamente configurate sono le seguenti :

- una descrizione del datasource;
- la classe che implementa il driver per laccesso alla base di dati. In generale,
sono utilizzati i driver JDBC, ma in molti casi si pu fare anche uso di driver
specifici per il connection-pooling;
- lo username e la password per accedere alla base di dati;
- l URL in cui si trova il database;

Tutte queste informazioni sono memorizzate, in fase di start-up dellapplicazione,
nella classe DataSourceConfig, mediante la quale possibile accedere alle propriet del
datasource, ed eventualmente modificarle, direttamente da codice.

<dat a- sour ces>
<dat a- sour ce key=" dat abase" >
<set - pr oper t y pr oper t y=" dr i ver Cl assName"
val ue=" com. mysql . j dbc. Dr i ver " / >
<set - pr oper t y pr oper t y=" ur l "
val ue=" j dbc: mysql : / / l ocal host / dat abase" / >
<set - pr oper t y pr oper t y=" user name" val ue=" admi n" / >
<set - pr oper t y pr oper t y=" passwor d" val ue=" sar a" / >
</ dat a- sour ce>
</ dat a- sour ces>

11.2 FormBean

Ciascun formbean realizzato come estensione della ActionForm ed utilizzato
allinterno dellapplicazione, deve essere specificato nel file di configurazione
mediante luso del tag <form-bean>.

118
_________________________________________________________________
Questultimo permette di specificare le seguenti informazioni :

- il nome del formbean mediante il quale si far riferimento ad esso nel resto
del file (name). Ad esempio, quando si definisce una action che utilizza i dati
di un certo formbean, va specificato il nome di questultimo;
- la classe che implementa il formbean (type). Tipicamente, questa pu essere la
classe ActionForm oppure DynaActionForm o eventualmente una delle classi
che derivano da esse. In alcuni casi, invece una classe realizzata dallo
sviluppatore, che comunque estende una delle classi suddette;

<f or m- bean name=" nomeFor mBean" t ype=" package. Cl asseAct i onFor m" / >

E ovvio che, nel caso in cui la classe che implementa il formbean sia stata realizzata
dallo sviluppatore, le propriet del formbean stesso sono esattamente le propriet
della classe, che non devono essere ulteriormente specificate nel file di
configurazione. Nel caso in cui, si preferisce adottare ad esempio un formbean
dinamico, necessario specificare le propriet del formbean allinterno del file struts-
config.xml, non essendoci una classe realizzata ad hoc.
Per questo scopo, il tag <form-bean> pu contenere uno o pi tag <form-property>,
ciascuno dei quali permette di definire una propriet del formbean, specificandone le

- il nome della propriet (name);
- la classe (oppure il tipo di dato primitivo) della propriet (type);
- leventuale valore iniziale, quando il formbean vuoto (initial);

<f or m- bean name=" nomeFor mBeanDi nami co"
<f or m- pr oper t y name=" por pr i et a1" t ype=" Cl assePr opr i et a1" / >
. . .
<f or m- pr oper t y name=" pr opr i et aN" t ype=" Cl assePr opr i et aN" / >
</ f or m- bean>

Tutte queste informazioni sono memorizzate allinterno delle classi FormBeanConfig e
FormPropertyConfig, che contengono rispettivamente tutto ci che riguarda in generale
il formbean e le relative propriet.
119
_________________________________________________________________
11.3 Global Exceptions

Il framework Struts mette a disposizione la possibilit di gestione delle
eccezioni che possono essere sollevate allinterno delle action. Ovviamente,
possibile definire, per ciascuna action, le eventuali eccezioni che essa pu sollevare,
ma in moltissimi casi, esistono delle eccezioni che possono essere sollevate da pi
action diverse. In questi casi, la soluzione migliore non certamente quella che
prevede di specificare la stessa eccezione per ogni action, ma bens di definire una
eccezione come globale. In questo modo, quando una action solleva uneccezione,
l ExceptionHandler valuta in primo luogo se essa specifica della action che lha
sollevata oppure di tipo globale e va gestita in un certo qual modo. Ciascuna
eccezione globale viene specificata nel file di configurazione, allinterno del tag
<global-exceptions>, facendo uso del tag <exception>, il quale permette di definire le

- la chiave relativa al Resource Bundle e corrispondente al messaggio da
visualizzare, quando leccezione viene sollevata (key);
- il percorso della pagina alla quale lutente verr redirezionato (path);
- la classe handler che si occuper di gestire leccezione. Per default, essa la
classe ExceptionHandler, ma ovviamente lo sviluppatore pu realizzarne una
propria estendendo questultima;
- la classe che rappresenta il tipo di eccezione (type);

La classe che memorizza tutte queste informazioni la ExceptionConfig.


120
_________________________________________________________________
11.4 Global Forwards

Quando una action, allinterno del metodo execute(), termina le operazioni
relative al proprio scopo, essa restituisce un oggetto ActionForward con il quale si
definisce la risorsa verso la quale proseguire la navigazione. Per ciascuna action,
allinterno del file di configurazione, vengono specificati i forward ad essa associati.
In alcuni casi, pu essere utile fare uso dei forward globali, i quali non sono
specifici di una action, ma possono essere referenziati ad una qualsiasi action
allinterno dellapplicazione. Ciascun forward globale viene specificato nel file di
configurazione, allinterno del tag <global-forwards>, facendo uso del tag <forward>, il
quale permette di definire le seguenti informazioni :

- il nome del forward per referenziarlo allinterno di una Action (name);
- il percorso della risorsa fisica a cui fa riferimento il forward logico (path);

Queste informazioni sono memorizzate nella classe ForwardConfig.

<gl obal - f or war ds>
<f or war d name=" nomeFor war d" pat h=" pagi na. j sp" / >
. . .
</ gl obal - f or war ds>

11.5 Action Mapping

Il contenuto principale del file di configurazione di Struts il mapping delle
action, attraverso il quale possibile specificare tutte le action utilizzate allinterno del
framework, associarle ad un percorso logico per la loro invocazione e specificarne i
forward per proseguire la navigazione da ciascuna di esse.
Per definire ciascuna action, viene utilizzato il tag <action>, mediante il quale sono
descritte le seguenti informazioni :

- il percorso (URI) della action per poter essere invocata da un qualsiasi punto
dellapplicazione (path);
121
_________________________________________________________________
- la classe che implementa la action, tipicamente realizzata dallo sviluppatore,
estendendo la classe di base Action oppure una delle sue derivate (type);
- il nome del formbean, i cui dati saranno oggetto dellelaborazione della action
(name);
- la visibilit del formbean (scope), distinguendo fra request e session;
- la pagina alla quale ritornare il controllo, qualora si verificassero errori di
validazione dei dati nel formbean (input);
- un eventuale parametro che permette di specificare quale metodo della action
eseguire nel caso in cui si tratti di una DispatchAction;

Inoltre, attraverso lattributo validate, possibile specificare se, prima di invocare la
action, debba essere eseguita o meno la validazione dei dati contenuti nel formbean
associato.
Infine, al termine dellesecuzione del metodo execute(), la action restituisce loggetto
ActionForward che specifica la risorsa verso la quale proseguire la navigazione.
Attraverso uno o pi tag <forward>, inclusi nel tag <action>, possibile specificare
tutti i forward che pu restituire la action stessa. Le informazioni principali sono
tipicamente le seguenti :

- il nome del forward per referenziarlo allinterno di una action (name);
- il percorso della risorsa fisica a cui fa riferimento il forward logico (path);

Inoltre, possibile specificare anche le eccezioni che possono essere sollevate da
ciascuna action, facendo uso del tag <exception> cos come vengono definite le
eccezioni globali.
Tutte le informazioni descritte vengono memorizzate nella classe ActionConfig, in
stretta relazione con le classi ForwardConfig ed ExceptionConfig.

<act i on i nput =" pagi na. j sp"
name=" nomeFor mBean" par amet er =" di spat ch"
pat h=" / nomeAct i on" scope=" r equest "
t ype=" package. Cl asseAct i on" >
<f or war d name=" nomeFor war d1" pat h=" pagi na1. j sp" / >
. . .
<f or war d name=" nomeFor war dN" pat h=" pagi naN. j sp" / >
</ act i on>
122
_________________________________________________________________
11.6 Controller

Il framework, nellambito della gestione di tutte le richieste che arrivano alla
Web application, utilizza le versioni di default per le classi ActionServlet e
RequestProcessor, che realizzano il Controller. Nel momento in cui lo sviluppatore
decide di realizzare un Controller personalizzato, non fa altro che estendere la classe
RequestProcessor e definire al suo interno le elaborazioni da eseguire. Nel file di
configurazione, va specificato quale deve essere il Controller da adottare, facendo uso
del tag <controller>, mediante il quale, tra le altre informazioni, va specificata in
particolare la seguente :

- la classe che implementa il Controller, la quale pu essere quella di default
RequestProcessor oppure una classe che derivi da questultima (processorClass);

Le informazioni riguardanti il Controller sono memorizzate nella classe
ControllerConfig.

<cont r ol l er pr ocessor Cl ass=" cont r ol l er . Cust omRequest Pr ocessor " / >

11.7 Message resources

Per garantire linternazionalizzazione, il framework Struts mette a
disposizione la possibilit di realizzare una serie di file, allinterno di ciascuno dei
quali salvare i messaggi da visualizzare allutente, in una lingua specifica. Tali file sono
anche noti come Resource Bundles o Message Resources e vanno specificati nel file
di configurazione. In realt, non necessario definire lelenco di tutti questi file, ma
unicamente il file associato al linguaggio di default, poich tutti gli altri avranno
esattamente lo stesso nome, con in pi un suffisso che ne distingue la lingua
utilizzata. Per questo scopo, viene adottato il tag <message-resources>, nel quale
possibile specificare il nome del Resource Bundle, mediante lattributo parameter.
Tali informazioni sono memorizzate nella classe MessageResourcesConfig.

<message- r esour ces par amet er =" Appl i cat i onResour ces" / >

123
_________________________________________________________________
11.8 Plug-In

Dalla versione 1.1 del framework, stato introdotta la possibilit di
utilizzare dei plug-in, mediante i quali estendere le potenzialit di questultimo. I due
esempi tipici sono il Validator Plug-In, per la validazione dei dati, ed il framework
Tiles, per la definizione del layout dellapplicazione. Lo sviluppatore ha comunque la
possibilit di realizzare una classe che estenda linterfaccia PlugIn del framework, per
implementare un proprio plug-in che venga eseguito in fase di start-up
dellapplicazione. E ovvio che ciascun plug-in utilizzato va specificato nel file di
configurazione, facendo uso del tag <plug-in>, nel quale, tra le altre informazioni, va
segnalata principalmente la seguente :

- la classe che estende linterfaccia PlugIn ed implementa il plug-in (className);

Tutte le informazioni relative ad un plug-in sono memorizzate nella classe
PlugInConfig.

<pl ug- i n cl assName=" package. Cl assePl ugI n" / >

124
Capitolo IV I framework a confronto
_________________________________________________________________
C Ca ap pi it to ol lo o I IV V I I f fr ra am me ew wo or rk k a a c co on nf fr ro on nt to o

1. Introduzione

Per molti anni, Struts stato il framework pi popolare ed ampiamente
utilizzato per la realizzazione di Web application mediante il linguaggio Java. In tempi
recenti, stato introdotto un nuovo framework, JavaServer Faces, che stato
definito in termini di standard ed ha posto la questione di dover scegliere quale delle
due tecnologie adottare ed in quali condizioni unapplicazione realizzata con Struts
dovesse utilizzare le nuove potenzialit di JSF.
Le principali caratteristiche di Struts possono essere cos riassunte :

- unarchitettura basata sul pattern di sviluppo MVC (Model View
Controller);
- capacit di gestione dei form (form management) mediante i cosiddetti
formbean che rappresentano lo stato dei dati di input sul server, ai quali va
aggiunto un framework per la validazione lato client e lato server;
- presenza del framework Tiles per la definizione del layout delle pagine
mediante dei templates facilmente modificabili, che riducono i tempi di
manutenzione grafica dellapplicazione;
- librerie di tag da utilizzare nelle pagine JSP per la definizione della View e che
lavorano in stretta collaborazione con la parte di form-management e di
controllo;

A tali caratteristiche, si aggiunge lelevato livello di maturit che caratterizza il
framework, in quanto stato realizzato nella sua prima versione nellanno 2000,
diventando uno standard de facto per lo sviluppo di Web application su piattaforma
J2EE (Java2 Enterprise Edition). Un limite pu essere dettato dal fatto che Struts
rappresenti unimplementazione e quindi sia unico, ma comunque migliorabile ed
estendibile.

125
_________________________________________________________________
Dal lato opposto si pone il framework JavaServer Faces, le cui caratteristiche
peculiari sono le seguenti :

- architettura basata sul pattern MVC, ma focalizzata in particolar modo alla
View;
- componenti riutilizzabili ed estendibili per la realizzazione dellinterfaccia
utente (UI);
- modello di gestione degli eventi e dei corrispondenti handlers, basato su
JavaBeans;
- utilizzo dellEL (Expression Language) per realizzare il value-binding e
method-binding, mediante il quale possibile legare le propriet dei
componenti della UI, rappresentati con tag nelle pagine JSP, direttamente con
la business-logic, senza che tali componenti abbiano alcuna conoscenza della
struttura delle classi di quesultima;
- ciclo di vita di una richiesta ben definito attraverso una serie di fasi;
- navigazione delle pagine basata sulla pagina attuale e le possibili destinazioni a
partire da essa;
- possibilit di gestione dei backing beans (managed beans) costituenti la
business-logic che possono essere istanziati in un qualsiasi momento on
demand;

La prima release di questo framework stata definita nel Marzo del 2004, il che
evidenzia un livello di maturit ancora basso rispetto a Struts. Daltro canto,
JavaServer Faces rappresenta uno standard del quale ne esistono due
implementazioni differenti : JSF RI (Reference Implementation) della Sun
Microsystems e MyFaces di Apache. Inoltre, il creatore di Struts, Craig McClanahan,
ha contribuito alla creazione di JSF portando con se un enorme bagaglio di
esperienza nella realizzazione di framework per lo sviluppo Web. Nella piattaforma
J2EE 5.0 sar prevista in forma nativa, un implementazione della tecnologia
JavaServer Faces. In riferimento al pattern MVC, su cui si basano entrambi i
framework, esso anche noto come Front Controller, in quanto tutto le richieste che
arrivano alla Web application vengono gestite e distribuite mediante un Controller
126
_________________________________________________________________
unico dellapplicazione. A questo punto, prendendo in considerazione le
caratteristiche dei due framework, si possono porre le seguenti domande :

- quale framework adottare per lo sviluppo di una nuova Web application ?
- disponendo di unapplicazione realizzata in Struts, conviene utilizzare i
componenti aggiuntivi di JSF, svilupparla dallinizio con quesultimo oppure
eseguire una migrazione da un framework allaltro ?

Per rispondere a queste domande, si rende necessario un confronto approfondito tra
queste due tecnologie, nonch bisogna tenere conto delle caratteristiche e delle
dimensioni dellapplicazione da realizzare.

2. Ciclo di vita di una richiesta

Una delle principali differenze tra i due framework risiede nel ciclo di vita
di una richiesta (request life-cycle), ossia cosa accade dal momento in cui arriva una
richiesta (request) allapplicazione fino alla produzione della corrispondente risposta
(response).
In Struts, il ciclo di vita relativamente semplice e pu essere schematizzato nei
seguenti passi principali :

- il Controller riceve una richiesta in ingresso;
- i parametri della richiesta vengono trasferiti nel corrispondente formbean;
- viene determinata la action, che rappresenta un bridge tra Controller e Model,
che dovr gestire tale richiesta;
- il formbean viene passato alla action individuata e ne viene avviata
lesecuzione;
- allinterno della action vengono utilizzati gli oggetti della business-logic;
- al termine dellelaborazione, la action restituisce un forward al Controller
che, sulla base di questultimo, determina la View che visualizzer la risposta
al client;
127
_________________________________________________________________
4 4. . P Pa as ss sa ag gg gi io o d de el l
f fo or rm mb be ea an n a al ll la a a ac ct ti io on n

VIEW
7 7. . D De et te er rm mi in na az zi io on ne e
d de el ll la a V Vi ie ew w
6 6. . R Re es st ti it tu uz zi io on ne e f fo or rw wa ar rd d
a al l C Co on nt tr ro ol ll le er r
5 5. . U Ut ti il li iz zz zo o o og gg ge et tt ti i
d de el ll la a B Bu us si in ne es ss s- -L Lo og gi ic c
3 3. . D De et te er rm mi in na az zi io on ne e
d de el ll la a a ac ct ti io on n
CONTROLLER
1 1. . R Ri ic ch hi ie es st ta a
C Cl li ie en nt t
formbean action
2 2. . T Tr ra as sf fe er ri im me en nt to o
d da at ti i d de el ll la a r ri ic ch hi ie es st ta a
8 8. . R Ri is sp po os st ta a
C Cl li ie en nt t
MODEL

Figura 1 - Struts : ciclo di vita di una richiesta

JavaServer Faces ha una gestione molto pi complicata, caratterizzata anche dal fatto
che possibile distinguere due tipi differenti di richieste : initial request e postback.
Inoltre, ciascuna richiesta viene manipolata attraverso sei fasi differenti, i cui passi
principali sono i seguenti :

- il Controller riceve una richiesta in ingresso;
- viene ricostruito lo stato iniziale della View, qualora si tratti di una initial
request, oppure uno stato precedente nel caso di un postback;
- i valori dei parametri della richiesta vengono trasferiti nelle propriet
corrispondenti dei componenti della UI;
128
_________________________________________________________________
- viene eseguita la validazione dei dati;
- assumendo che i dati siano validi, essi vengono trasferiti dai componenti alle
propriet dei backing beans ad essi associati;
- viene eseguita la gestione di eventuali eventi sui componenti della UI e le
elaborazioni della business-logic, specificate nei backing beans;
- infine, viene eseguita la fase di rendering per la produzione della risposta;
1 1. . R Ri ic ch hi ie es st ta a
C Cl li ie en nt t
CONTROLLER
Restore View
Apply Request
Values
Process
Validations
Update Model
Values
Invoke
Application
Render
Response
VIEW
Componenti UI
2 2. . R Ri ip pr ri is st ti in no o
s st ta at to o V Vi ie ew w
MODEL
Backing Beans
3 3. . T Tr ra as sf fe er ri im me en nt to o
d da at ti i d de el ll la a r ri ic ch hi ie es st ta a
4 4. . V Va al li id da az zi io on ne e d da at ti i
5 5. . T Tr ra as sf fe er ri im me en nt to o d da at ti i d da ai i
c co om mp po on ne en nt ti i U UI I a ai i b ba ac ck ki in ng g b be ea an ns s
6 6. . M Me et to od di i
B Bu us si in ne es ss s- -L Lo og gi ic c
7 7. . R Re en nd de er ri in ng g
d de el ll la a V Vi ie ew w
8 8. . R Ri is sp po os st ta a
C Cl li ie en nt t

Figura 2 - JSF : Ciclo di vita di una richiesta
129
_________________________________________________________________
3. Controller Tier

Entrambi i framework prevedono un Controller realizzato attraverso una
Servlet, in esecuzione nel Web Container, la quale ha il compito di acquisire le
richieste provenienti dai client e determinare per ciascuna di esse il corrispondente
handler, facente parte del Model, che dovr gestirla. Infine, sulla base dei risultati
prodotti, la stessa Servlet si fa carico di determinare la View che rappresenter la
risposta fornita al client. Limplementazione del Controller ovviamente differente e
prevede le seguenti classi :

- Struts : la classe ActionServlet che viene coadiuvata da una o pi istanze dalla
classe RequestProcessor;
- JSF : la classe FacesServlet;

In Struts, la presenza di due classi rappresenta una prerogativa necessaria per la
realizzazione di una Web application in pi moduli separati. Infatti, listanza della
ActionServlet unica mentre, per ciascun modulo dellapplicazione , prevista
unistanza della classe RequestProcessor. Quando una richiesta arriva al Web Container,
la ActionServlet la smista verso listanza della RequestProcessor che associata al modulo
a cui la richiesta stessa destinata. Detto ci, tutti i compiti tipici del Controller
vengono svolti dalla classe RequestProcessor.
Questa differenza pu rappresentare un vantaggio per il framework Struts, per
quanto riguarda lestendibilit del Controller. Infatti, lo sviluppatore deve
semplicemente realizzare una classe che estenda la RequestProcessor ed esegua
loverriding del metodo processPreprocess(), qualora voglia eseguire delle operazioni
preliminari alla gestione di una richiesta. Viene quindi messo a disposizione un
metodo, tipicamente non utilizzato dal framework, per estendere il Controller.

130
_________________________________________________________________
ActionServlet
RequestProcessor
R Ri ic ch hi ie es st ta a C Cl li ie en nt t
P Pu un nt to o d di i e es st te en ns si io on ne e
d de el l C Co on nt tr ro ol ll le er r

MODEL

Figura 3 - Struts : Controller Tier

In JSF, lestensione pi complicata, in quanto la gestione della richiesta avviene in
pi fasi separate. Per questo motivo, possibile creare un oggetto PhaseListener,
relativo ad una specifica fase ed associarlo allistanza della classe Lifecycle, che gestisce
il ciclo di vita di una richiesta. In corrispondenza di tale oggetto, possibile
specificare le elaborazioni da eseguire prima e dopo la fase associata, eseguendo
loverriding dei metodi afterPhase() e beforePhase().
Rispetto a Struts, tale approccio ha una complessit nettamente superiore, dettata
soprattutto dalla notevole differenza che c nel ciclo di vita di una richiesta.
Per questo motivo, in Struts basta estendere la sola classe RequestProcessor ed eseguire
loverriding del metodo processPreprocess() prima che una richiesta venga gestita, mentre
in JSF, considerando la presenza di pi fasi, possibile intervenire con una maggiore
granularit in corrispondenza di ogni fase, addirittura definendo delle operazioni
specifiche da eseguire prima e dopo ciascuna di esse.

131
_________________________________________________________________

FacesServlet
R Ri ic ch hi ie es st ta a C Cl li ie en nt t
Lifecycle
Restore View
Apply Request
Values
Render
Response
Process
Validation
Update Model
Values
Invoke
Application
P Pu un nt ti i d di i e es st te en ns si io on ne e
d de el l C Co on nt tr ro ol ll le er r

Figura 4 - JSF : Controller Tier

132
_________________________________________________________________
4. Interfaccia Utente (UI)

ellinterfaccia utente di una Web application uno degli
spetti in cui il framework JavaServer Faces pu considerarsi nettamente superiore
rispetto a
controllo, ad esempio con lutilizzo di Swing. Ciascun
In JSF, i componenti della gerarchia di classi che ne
eterminano il comportamento, le funzionalit, la gestione degli eventi e lo stato,
La realizzazione d
a
Struts.
Infatti, JSF introduce il concetto di componente cos come nelle applicazioni desktop
previsto il concetto di
componente rappresenta un elemento costitutivo dellinterfaccia utente e pu avere
forme diverse partendo dai componenti pi semplici quali un campo di testo, un
radio button, una checkbox, una drop-down list, un bottone, un link fino a
considerare componenti notevolmente complessi che sono realizzati estendendo
oppure collegando tra loro i precedenti. Ovviamente, anche Struts permette di
realizzare uninterfaccia utente caratterizzata da elementi di questo tipo ma ci che
differenzia i due framework la diversa implementazione e gestione degli stessi.

Stato

Figura 5 - JSF : UI Components

UI sono definiti attraverso una
d
T Ta ag g X XM ML L- -l li ik ke e
V Va al lu ue e & & M Me et th ho od d
B Bi in nd di in ng g
Renderers
Converters
Validators
Event Listeners
Backing Bean
Tag Handle
V Va al lo or ri i e ed d
E Ev ve en nt ti i
r
JavaBean Class
Component
133
_________________________________________________________________
concetto non presente in Struts, che viene salvato tra una richiesta e laltra sul server
oppure eventualmente sul client. I componenti che costituiscono una pagina JSF
sono organizzati secondo una struttura ad albero (view) a partire da un nodo radice
(root). Essi sono realizzati attraverso dei JavaBeans che hanno delle propriet, che
rappresentano i propri attributi, dei metodi, che ne definiscono le funzionalit ed
infine dei listeners per la gestione dei corrispondenti eventi. Inoltre, la loro
visualizzazione pu essere eseguita in maniera autonoma oppure delegata ai
renderers. Il vantaggio principale di questa caratteristica dato dal fatto che
possibile definire una sola volta il comportamento di un componente ma
associandogli differenti renderers, per la visualizzazione su dispositivi client che
utilizzano linguaggi di markup diversi. Ci permette alla tecnologia JSF di supportare
lo sviluppo di Web application, utilizzabili con device differenti, quali personal
computer, palmari e cellulari, partendo da componenti comuni ma sfruttando
visualizzazioni diversificate.
Renderer HTML

Figura 6 - JSF : Rendering per device differenti

Nel caso delle semplici pagine JSP, ogni componente viene introdotto mediante
utilizzo di un tag corrispondente, nel quale possibili fissare gli attributi del
ed i corrispondenti tag che permettano la visualizzazione dei componenti con un

l
componente stesso. Limplementazione JSF RI fornisce le classi di base dei
componenti ed in un pi un renderer kit e la libreria di tag associata, per la
visualizzazione degli stessi, con client HTML. Nulla vieta di realizzare un renderer kit
JavaBean Class
Component
Renderer WML
134
_________________________________________________________________
linguaggio di markup diverso, quale XML oppure WML. Struts, invece, mette a
disposizione una libreria di tag per i client HTML, ma non fornisce il supporto di
indipendenza dai client, nel senso che non possibile permette la visualizzazione
dellapplicazione, da un dispositivo diverso da un browser web.

Figura 7 - Struts : Elementi UI

Infine, JSF fornisce allo sviluppatore la possibilit di estendere le classi che
implementano i componenti, per realizzarne di propri e personalizzati, caratteristica
assolutamente non presente i vuole realizzare un form
.util.Date
da passare alla business-logic.
in Struts. Ad esempio, se s
costituito da pi campi di input, che magari dovr essere utilizzato in pi pagine, con
JSF si pu realizzare un unico componente e quindi un unico tag da immettere nelle
pagine JSP. La logica ed il comportamento, interni al componente, permetteranno di
trattare i dati come un unico input. Con Struts, sar necessario introdurre i controlli
separatamente nelle pagine ed utilizzare pi tag, uno per ogni campo di input ed
inoltre, si avr lonere di raggruppare i dati ottenuti. Un caso tipico pu essere quello
relativo ad un componente che permetta allutente di selezionare una data, ad
esempio quella di nascita. Con JSF, si realizza un unico Custom Component
(DateSelectComponent) ed il relativo Tag Handler, per disporre di un unico tag mediante
il quale inserire lelemento allinterno della pagina. Questultimo costituito da tre
drop-down list, relative al giorno, al mese e allanno, che sono trattate come un unico
controllo della UI. La data selezionata viene gestita automaticamente dal componente
che produce un oggetto java.util.Date, il quale viene immediatamente memorizzato in
una corrispondente propriet di un backing bean, mediante il value-binding.
Con Struts, necessario realizzare tre drop-down list separate i cui valori sono
copiati in tre propriet distinte di un formbean. Sar compito della action eseguita,
prelevare questi valori e comporli in modo da generare un unico oggetto java
T Ta ag g X XM ML L- -l li ik ke e
FormBean
Tag Handler
135
_________________________________________________________________

DateSelect
Component Class

FormBean

Figura 8 - JSF e Struts : esempio di componente composto

Quanto detto, evidenzia il fatto che JSF sia nettamente orientato alla realizzazione
della View di una Web application, permettendo una flessibilit ed una espandibilit
nettamente superiori a Struts.
Struts lintroduzione del concetto
sociato ad un componente. Tale concetto da sempre presente nelle
applicazioni desktop, in cui su di un controllo dellinterfaccia utente pu scatenarsi

5. Events e Listeners

Un aspetto innovativo di JSF rispetto a
di evento as

Action Struts
java.util.Date Object
giorno mese anno
Backing Bean
java.util.Date Object
Business Object
S St tr ru ut ts s
J JS SF F
136
_________________________________________________________________
un evento, come la pressione di un bottone oppure il cambiamento del contenuto di
n campo di input. Lapplicazione prevede una serie di listeners che intercettano gli
eventi e n
n applicato anche nelle Web application, per cui
i agli eventi scatenati. Tali listeners possono essere realizzati
lla pressione di un bottone
ecuzione di un
u
e eseguono la gestione, effettuando delle elaborazioni. Tale approccio da
sempre noto come event-driven, ossia pilotato da eventi, nel senso che ogni
computazione eseguita dal software avviata al verificarsi di un evento su un
controllo dellinterfaccia utente.
In Struts tale concetto non esiste, in quanto lunico evento che viene considerato tale
la semplice richiesta HTTP, per cui linvio dei dati di un form, la pressione di un
bottone, il click su un collegamento ipertestuale, vengono trattati come semplici
richieste HTTP.
Con JSF, il modello event-drive
alla normale gestione delle richieste HTTP, si aggiunta la particolare gestione degli
eventi. Ci vuol dire che ogni tipo di azione che lutente esegue attraverso
linterfaccia pu essere trattata come una normale richiesta oppure gestita attraverso i
listeners associat
attraverso dei metodi dei backing beans, la cui tipica applicazione la realizzazione
della navigazione tra le pagine, oppure mediante delle classi specifiche, che
implementano delle particolari interfacce del framework.
Il vantaggio sostanziale degli eventi dettato dal fatto che un evento, scatenato su un
certo componente, pu essere gestito anche in modalit immediata, senza che la
richiesta HTTP sottostante segua tutto il ciclo di vita previsto da JSF.
Con JavaServer Faces, la navigazione completamente gestita attraverso il
meccanismo degli eventi di tipo action, ossia riferiti a
oppure il click su di un link. Infatti, nel momento in cui si vogliono inviare i dati di
un form oppure si vuole passare ad una nuova pagina attraverso un collegamento
ipertestuale, viene generato un evento di questo tipo che prevede les
metodo di un backing bean associato al componente, che eseguir delle elaborazioni
e restituir loutcome per il proseguimento della navigazione. Questo evento pu essere
gestito anche creando una classe che implementa linterfaccia ActionListener , anche se
in tal caso non potr essere utilizzato per la navigazione ma esclusivamente per
eseguire particolari elaborazioni alla pressione di un pulsante oppure di un link.

137
_________________________________________________________________

Figura 9 - JSF : Evento "action"

In Struts, una situazione di questo tipo viene gestita avviando una action cos come
in tutti gli altri casi.

Figura 10 - Struts : Avvio di una action
ction. La differenza di un pulsante deve
ella
on si ha laccesso al componente che intercettato levento;
viceversa ci possibile con un ActionListener;

E comunque da sottolineare che la presenza dellevento action per la gestione
della navigazione non differenzia di molto i due framework, in quanto se da un lato si
avvia lesecuzione di un metodo di un backing bean, dallaltro c lesecuzione di una
a si evidenzia quando la pressione
comportare unelaborazione immediata rimanendo alla medesima pagina (postback).
Concettualmente, ci possibile con JSF tenendo conto del fatto che sul server
residente lo stato di tutti i componenti come se fosse in esecuzione unapplicazione
desktop e quindi la richiesta inviata servir semplicemente a notificare levento da
gestire. Con Struts si esegue una normale action, in quanto levento gestito come
una tipica richiesta HTTP e si forza il concetto di navigazione sulla stessa pagina.
La differenze sostanziali tra una action di Struts ed un ActionListener di JSF possono
essere cos riassunte :

- La action implementa parte della Business-Logic, lActionListener rientra n
User Interface Logic;
- In una action n
E Ev ve en nt to o a ac ct ti io on n
E Ev ve en nt to o a ac ct ti io on n
Backing Bean
O Ou ut tc co om me e
ActionListener
p pr re es ss si io on ne e
Action
F Fo or rw wa ar rd d
138
_________________________________________________________________
- La action restituisce sempre il forward per la navigazione mentre un
ActionListener non partecipa alla fase di navigazione;

Laltro nge, che viene scatenato nel
mo n
lutente richiesta, viene scatenato
evento ed in maniera automatica verr avviato il listener per la sua gestione.
aniera completamente automatica in JSF,
u intervenire
tipo di evento previsto in JSF il value-cha
me to in cui cambia il contenuto di un componente. Ci vuol dire che, quando
modifica il valore immesso in un campo ed invia la
l
Questultimo pu essere realizzato mediante un metodo di un backing bean oppure
attraverso una classe che implementa linterfaccia ValueChangeListener.

Figura 11 - JSF : Evento "value-change"

In Struts, per realizzare un qualcosa di simile, bisogna avviare una solita action che
abbia la possibilit di confrontare il valore precedente con il valore attuale del
componente ed in caso di differenza gestire levento simulato. Tutto ci avviene in
m considerando che c la gestione dello
stato dei componenti che viene memorizzato fra una richiesta e laltra.
Ulteriore tipologia di evento prevista in JSF quella relativa alle fasi che
caratterizzano il ciclo di vita di una richiesta. Infatti, linizio e la fine di ciascuna fase
determinano il verificarsi di un corrispondente evento al quale pu essere associato
un listener per eseguirne una particolare gestione. In questo modo, si p
in maniera molto specifica durante la manipolazione di una richiesta, in una qualsiasi
delle fasi. Ovviamente, questa caratteristica non prevista in Struts, in cui possibile
intervenire nel ciclo di vita di una richiesta, soltanto prima dellavvio della sua
gestione e non durante.

E Ev ve en nt to o
v va al lu ue e- -c ch ha an ng ge e
Backing Bean
ValueChangeListener
139
_________________________________________________________________
6. Mappatura delle richieste sulla Business-Logic

Uno degli aspetti che differenzia notevolmente Struts e JSF soprattutto la
modalit con cui tutte le richieste dei client vengono mappate in corrispondenza degli
framework Struts prevede un forte utilizzo del file di configurazione XML, in
quanto allinterno di questultimo che
n da eseguire per la sua gestione. Per
XML ed ogni richiesta i di questi ultimi. Essi
no associati ai componenti dellinterfaccia utente, nel senso che il valore di un
oggetti della business-logic che dovr gestirle.
Il
viene eseguita loperazione di action-
mapping, attraverso la quale si fa corrispondere ad una certa richiesta, pervenuta per
un determinato URL, la corrispondente actio
ogni action, viene inoltre specificato il formbean che conterr i dati su cui essa dovr
eseguire le elaborazioni. Allarrivo di una richiesta, quindi, grazie al mapping
caricato in memoria in fase di start-up, viene popolato il formbean con i dati
trasmessi ed individuata e successivamente avviata la action per la relativa gestione.
Lespandibilit fornita dal framework, prevede che ogni classe che debba gestire una
richiesta, estenda la classe Action oppure una delle sue derivate, cos come ogni classe
che definisce un formbean debba derivare dalla classe ActionForm oppure da una delle
classi che la estendono.

Figura 12 - Struts : Mapping delle actions

Con JSF, lapproccio completamente differente, in quanto vengono definiti i
backing beans, anche noti come managed beans, allinterno del file di configurazione
prevede lesecuzione di uno dei metod
so
Action Mapping
Action 1
Action 2
Action N
struts-config.xml
formbean
formbean
R Ri ic ch hi ie es st ta a
formbean
C Co on nt tr ro ol ll le er r
140
_________________________________________________________________
componente pu corrispondere alla propriet di un bean, cos come levento
verificatosi su un componente pu comportare lesecuzione di un metodo del bean
stesso. Tutto ci garantito mediante il value-binding e method-binding facendo
uso dellExpression Language.
In questo modo, i dati della richiesta vanno a popolare i campi di un backing bean e
le elaborazioni da eseguire su di essi sono implementate allinterno di un metodo di
questultimo. In pratica, i backing bean sono una combinazione tra i formbean e le
action di Struts, non separando operazioni e dati e sono concettualmente simili alle

el caso di Struts, si possono individuare le seguenti possibili soluzioni :
ss-logic, che utilizzano le classi di
accesso alla base di dati, che sono completamente indipendenti dal
i dati dai
classi di code-behind dei WebForms della tecnologia ASP.Net. La loro gestione
completamente automatica e gestita in maniera trasparente dal framework, che si
preoccupa di crearne le istanze sulla base dellambito di visiblit (scope) che viene
specificato nel file di configurazione.

Figura 13 - JSF : Backing Beans

Sulla base di questa differenza tra i due framework, la business-logic pu essere
collocato nellapplicazione in pi modi diversi.
N

1. si definiscono gli oggetti della busine
framework adottato. Le action non fanno altro che acquisire
faces-config.xml Backing Bean 1
Backing Bea
CONTROLLER
n 2
Backing Bea
n N
141
_________________________________________________________________
formbean, trasferirli negli oggetti della business-logic ed invocare i metodi su
di essi;
gli oggetti della business-logic vengono implementati estendendo la classe
ActionForm e quindi trattati come formbean. In questo modo, le loro
propriet
2.
sono automaticamente popolate dal framework al momento

ione della Business-Logic

enza dagli oggetti della business-
logic rispetto alle classi tipiche del framework, per cui tali oggetti possono essere
tilizzati anche per sviluppare lapplicazione con un framework diverso. La seconda
dellinvio della richiesta ed poi compito delle action invocare su di essi i
metodi per le elaborazioni;

Figura 14 Struts : Locaz
La prima soluzione prevede una marcata indipend
u
soluzione ha il vantaggio di ridurre il numero di classi da adottare, in quanto i
formbean diventano gli oggetti della business-logic, ma ha lo svantaggio di rendere
non pi portabili tali oggetti tra un framework e laltro.

DBAccess Object
Action
Business Object
(formbean)
Action
formbean
Business Object
DBAccess Object
142
_________________________________________________________________
La tecnologia JSF prevede le seguenti soluzioni :
1. i backing beans coincidono perfettamente con gli oggetti della business-logic.
elle loro propriet ed attraverso i
propri metodi eseguono le elaborazioni su di essi;

ione della Business-Logic

mette in risalto lenorme potenza del
framework, incapsulando dati ed operazioni , anche se a scapito della riusabilit, in
uanto allinterno dei metodi degli oggetti della business-logic si sfruttano le classi

Essi acquisiscono i dati della richiesta n
2. si definiscono gli oggetti della business-logic in maniera indipendente dal
framework e poi separatamente si introducono i backing beans, i quali non
fanno altro che invocare i metodi dei primi;

Figura 15 - JSF : Locaz
La prima soluzione, maggiormente adottata,
q
tipiche del framework. La seconda soluzione favorisce lutilizzo delle classi della
business-logic con framework diversi, senza necessit di dover riprogettare il
software, ma prevede anche una certa duplicazione e ridondanza, in quanto le
propriet dei backing beans saranno presumibilmente uguali alle propriet degli
oggetti della business-logic, cos come i loro metodi non faranno nientaltro che
invocare i metodi di questi ultimi.
Business Object
Backing Bean Business Object
(Backing Bean)
DBAccess Object
DBAccess Object
143
_________________________________________________________________
Attraverso lutilizzo dei managed beans, JSF fornisce il supporto per lInversion of
Control (IoC), anche noto come Dependency Injection, in quanto le istanze degli oggetti
vengono create automaticamente dal framework quando necessario, senza la
I dati che lutente immette nei form, che costituiscono linterfaccia della
, sono generalmente destinati ad essere trasferiti allinterno degli
ggetti della business-logic, in maniera diretta o indiretta, per poi essere soggetti alle
elaborazio
gina JSP, in corrispondenza di un certo
lici e non complessi come ad esempio una data, invece supportata da
necessit di intervento da parte dello sviluppatore. In un certo senso, anche Struts
fornisce un supporto di questo tipo, istanziando i formbean e le action, ma il
concetto di IoC molto pi ampio, cos come viene interpretato in JSF.

7. Conversione

Web application
o
ni richieste. Facendo riferimento alla fase di immissione dei dati, allinterno
dei campi dellinterfaccia utente, essi sono sempre rappresentati attraverso delle
semplici stringhe per poi essere trasferiti al server attraverso la rete. Le propriet dei
bean, a cui i valori sono destinati, possono essere di tipo qualsiasi e non
necessariamente di tipo stringa, per cui richiesta unoperazione di conversione.
Per quanto riguarda questo aspetto, il framework JavaServer Faces ancora una volta
superiore rispetto a Struts, mettendo a disposizione dei meccanismi allo stesso tempo
potenti e semplicemente espandibili.
Infatti, JSF fornisce in primo luogo un insieme di convertitori per i tipi di dato pi
comuni, ai quali sono associati una serie di tag in modo da poter utilizzare ciascun
convertitore allinterno di una pa
componente. Ogni convertitore viene utilizzato sia nella fase di decoding, per
trasferire il valore del componente nella corrispondente propriet del backing bean
associato, sia nella fase di encoding per svolgere la funzione inversa. Loperazione di
conversione, quindi, prevede di passare da un valore stringa ad un tipo di dato
specifico nel primo caso oppure, viceversa, da un certo tipo di dato ad una stringa nel
secondo caso.
Struts supporta un meccanismo di conversione molto pi semplice, implementato
attraverso le classi del progetto common-beanutils che forniscono supporto per i
tipi di dati semp
144
_________________________________________________________________
JSF. Per questo motivo, si preferisce sempre fare in modo che i formbean, che
ricevono i dati di input, abbiano tutte le propriet di tipo stringa in modo che non sia
eseguita alcuna conversione a partire dai valori del form. Successivamente, in fase di
trasferimento di tali valori verso gli oggetti della business-logic, si eseguono le
opportune conversioni.
Con JSF, invece, c la possibilit di realizzare dei convertitori personalizzati ed i
corrispondenti tag, per tipi di dati non previsti dal framework, che magari possono
far parte dellapplicazione realizzata. Lo sviluppo di un Custom Converter prevede la

In generale, tutti i sistemi software prevedono unoperazione di validazione,
le valutare se i dati immessi dallutente siano corretti rispetto a ci
he ci si attende. In questo modo, possibili evitare errori di elaborazione, dovuti a
valori non
di base, molto pi
realizzazione di una classe che implementa linterfaccia Converter ed eventualemente,
di un Tag Handler per la definizione di un tag con cui associare il convertitore ad un
componente in un pagina JSP.

V Va al lo or re e
Figura 16 - JSF e Struts : Conversione

8. Validazione
attraverso la qua
c
validi, in quanto tale controllo viene eseguito a priori.
Per quanto concerne tale aspetto, in riferimento al confronto tra i due framework in
questione, si pu dire che Struts ha delle potenzialit superiori rispetto a JSF, il quale
per fornisce un meccanismo di estensione delle funzionalit
semplice.
Common-beanutils formbean
Backing Bean Converter
S St tr ru ut ts s
J JS SF F
145
_________________________________________________________________
In Struts, le funzionalit di base per la validazione sono integrate allinterno dei
formbean, in quanto la classe ActionForm prevede un metodo validate(), del quale
Ovviamente, questo tipo di approccio non pu essere adottato per i formbean
inamici, che non prevedono limplementazione di una classe. Per questo motivo,
d i corrispondenti campi che dovranno essere
soggetti alla validazione e quali saranno le funzioni di validazione da adottare
-

Il p - alidazione predefinite
i comuni : dal controllo che il valore di un campo non sia vuoto fino al controllo
eseguire loverriding per potervi immettere il codice che effettui la validazione dei
dati del form stesso.

Action
formbean

validate()

Figura 17 - Struts : Validazione formbean con il metodo validate()

d
nella maggior parte dei casi, la validazione dei dati realizzata sfruttando un plug-in
esterno, noto come Validator, che stato integrato nel framework a partire dalla
versione 1.1. Tale plug-in si basa sullutilizzo di due file di configurazione XML, i
quali permettono rispettivamente di :

- dichiarare quali sono i form e
per ciascuno di essi;
definire tali funzioni, dette anche regole di validazione;
lug in Validator mette a disposizione una serie di regole di v
p
che un valore, che dovrebbe rappresentare un indirizzo email oppure il codice di
carta di credito, abbia un formato corretto passando per i semplici controlli per cui
un valore immesso sia di un certo tipo oppure soddisfi un certo pattern. Ovviamente,
146
_________________________________________________________________
possibile integrare queste regole, realizzando delle funzioni personalizzate che
permettano di eseguire delle operazioni di validazione non previste dal plug-in.

Action
formbean
Validator
PlugIn
validation-rules.xml validation.xml

Figura 18 - Struts : Validazione formbean con il plug-in Validator

framework JSF, invece, fornisce soltanto tre validatori standard relativi al controllo
er quanto concerne ques
Il
che un certo valore rientri in un range oppure che abbia una lunghezza compresa tra
un minimo ed un massimo prefissati. Per poter eseguire delle operazioni di
validazione personalizzate, possibile utilizzare i metodi dei backing beans oppure
realizzare delle classi che implementano linterfaccia di base Validator.
Validator Backing Bean
V Va al lo or re e

Figura 19 - JSF : Validazione

P to aspetto del confronto, Struts fornisce numerosi
validatori standard ed inoltre, oltre alla validazione lato server, supporta la
validazione lato client, non prevista in JSF. Infatti, nella libreria HTML fornito un
147
_________________________________________________________________
tag che ha la capacit di generare in maniera automatica il codice Javascript di una
qualsiasi regola di validazione.
9. Navigazione
Le applicazioni Web, sviluppate prima dellintroduzione di framework
specifici,
ica, in cui la
- pagina di origine;
estinazione;

he vengono definiti attraverso le regole di navigazione (navigation-rules) ed i casi di
arico di acquisire loutcome
preliminari al proseguimento della navigazione.

hanno sempre previsto la cosiddetta navigazione statica nellambito della
quale, per poter passare da una pagina allaltra, necessario utilizzare i collegamenti
ipertestuali, specificando per ciascuno di essi la pagina di destinazione.
Struts e JavaServer Faces introducono il concetto di navigazione dinam
pagina di destinazione determinata in seguito ad una elaborazione eseguita dalla
business-logic. Inoltre, in entrambi i framework, la navigazione attraverso le pagine
specificata allinterno del file di configurazione, per cui si parla di navigazione
dichiarativa, anche se utilizzando due modalit differenti.
Il framework JSF prevede tre elementi fondamentali :

- outcome;
- pagina di d
c
navigazione (navigation-case). Pi precisamente, ciascuna regola di navigazione
caratterizzata dalla pagina di origine e da una o pi pagine di destinazione, verso le
quali proseguire la navigazione sulla base delloutcome che viene manipolato.
Questultimo pu essere specificato direttamente allinterno di un tag di una pagina
JSP, relativamente ad un link oppure ad un bottone, oppure pu essere determinato
in seguito allesecuzione di un metodo di un backing bean.
Nota la pagina di origine, la classe NavigationHandler si fa c
prodotto e cercarlo tra i casi di navigazione specificati nella copia in memoria del file
di configurazione. Una volta trovato loutcome, ad esso corrisponder la pagina di
destinazione verso la quale redirezionare il flusso dellapplicazione. Tale classe
assolutamente espandibile, permettendo allo sviluppatore di eseguire delle operazioni
148
_________________________________________________________________

Figura 20 - JSF : Navigazione

In Struts, la navigazione si basa sul concetto di forward che pu essere locale
ppure eventualmente globale. Infatti, una volta avviata lesecuzione del metodo o
execute() di una action, questultimo produce in uscita un oggetto ActionForward che
individua appunto un elemento XML di tipo forward definito nel file di
configurazione. Tale elemento avr un nome e la pagina di destinazione verso la
quale proseguire la navigazione. Esso pu essere locale, nel senso che pu essere
riferito solo ed esclusivamente da una certa action, oppure globale in quanto pu
essere condiviso tra pi action differenti.

S St ta ar rt t P Pa ag ge e
faces-config.xml
NavigationRule 1

Start Page
NavigationCase 1

Outcome 1 Dest Page 1
NavigationCase N

Outcome N Dest Page N
NavigationHandler
Destination Page
149
_________________________________________________________________

Figura 21 - Struts : Navigazione
struts-config.xml

10. Expression Language
LExpression Language un linguaggio attraverso il quale possibile fare
riferimen
erizzano le librerie di JSF, in corrispondenza di

to ai JavaBeans previsti dallapplicazione, allinterno dei tag di una pagina
JSP. Lutilizzo di questo linguaggio previsto in forma nativa nel framework
JavaServer Faces ma non in Struts.
La maggior parte dei tag che caratt
specifici attributi, supportano il value-binding ed il method-binding, attraverso i
quali si pu fare riferimento alle propriet oppure ai metodi dei backing bean. Tale
riferimento viene esplicitato attraverso lutilizzo dellExpression Language, facendo
Action 1

Forward 1 Dest Page 1
Forward N Dest Page N
CONTROLLER
Destination Page
Global Forwards

Forward 1 Dest Page 1
ActionForward
150
_________________________________________________________________
uso della tipica dot notation che, attraverso un punto, separa il nome del bean dalla
propriet o dal metodo a cui si interessati.

M Me et th ho od d- -b bi in nd di in ng g
V Va al lu ue e- -b bi in nd di in ng g
TAG JSF
BackingBean
Attributo

#{backingBean.proprieta}
proprieta
metodo
TAG JSF
Attributo

#{backingBean.metodo}

Figura 22 - JSF : Value/Method binding con l' EL

Questa potenzialit non prevista in Struts, se non attraverso lutilizzo delle librerie
JSTL (JavaServer Pages Standard Tag Library) oppure attraverso un estensione
particolare delle librerie proprie del framework.
La prima soluzione prevede di utilizzare i tag appartenenti alle librerie JSTL che sono
completamente indipendenti dal framework. La modalit di utilizzo dellEL
allinterno di questi tag la stessa di JSF.
La seconda soluzione prevede di utilizzare le stesse librerie di Struts ma con
lestensione allExpression Language. Infatti, le tre librerie di base previste non
supportano tale linguaggio, ma ne sono state create delle versioni evolute, con
suffisso el, che forniscono le medesime funzionalit delle prime, ma con in pi la
possibilit di utilizzare lExpression Language in corrispondenza dei propri attributi.
E comunque da sottolineare che, seppure utilizzando lEL, con Struts non ci si pu
riferire ad un metodo di un bean, in quanto sempre prevista lesecuzione di una
action.

151
_________________________________________________________________
TAG Struts
TAG JSTL / Struts-EL
Attributo

Attributo

bean
Attributo

proprieta
Bean
proprieta
#{bean.proprieta}
S St tr ru ut ts s
S St tr ru ut ts s- -E EL L/ /J JS ST TL L

Figura 23 - Struts : Riferimenti ai beans con e senza EL

In relazione a tale aspetto, si pu dire che JSF avvantaggiato rispetto a Struts
perch, mentre il primo fornisce il supporto dellEL in forma nativa, con il secondo
necessario lutilizzo di librerie esterne o estensioni di quelle interne.

11. Eccezioni

Uno degli aspetti che rappresenta un netto vantaggio di Struts rispetto a
JSF, la gestione delle eccezioni. Infatti, il framework Struts permette di dichiarare,
allinterno del file di configurazione, le eccezioni che potranno essere sollevate
dallapplicazione ed i corrispondenti gestori.

152
_________________________________________________________________
In particolare, sono previste le due seguenti classi :

- ModuleException : permette di definire una eccezione alla quale associare un
messaggio di errore prelevato dal Resource Bundle;
- ExceptionHandler : permette di gestire una qualsiasi eccezione dichiarata nel
file di configurazione;

In pratica, allinterno del file struts-config.xml pu essere dichiarata uneccezione che
tipicamente del tipo ModuleException oppure una classe che la estende. Inoltre, ad
essa viene associato un gestore che pu essere quello di default oppure una classe che
estenda ExceptionHandler. Nel momento in cui, durante lesecuzione dellapplicazione,
viene sollevata uneccezione di questo tipo, essa viene intercettata e gestita in maniera
completamente automatica, senza la necessit di blocchi try-catch-finally allinterno del
codice.

struts-config.xml
ExceptionHandler
Global Exceptions

Exception 1
Exception N Error Page N
Error Page 1
E Ex xc ce ep pt ti io on n
Error Page

Figura 24 - Struts : Eccezioni dichiarative

Questa potenzialit non assolutamente prevista in JSF, nellambito del quale le
eccezioni devono essere completamente gestite dallo sviluppatore, secondo le
funzionalit offerte dal linguaggio Java.

153
_________________________________________________________________

Figura 25 - JSF : Eccezioni programmatiche

12. Internazionalizzazione (I18N)
Linternazionalizzazione una caratteristica comune di JSF e Struts che
viene pra
- il Locale (localizzazione geografica dellutente) permette di individuare il
- individuare il messaggio da visualizzare,

ticamente gestita allo stesso modo. Infatti, entrambi i framework offrono la
possibilit di definire uno o pi Resource Bundle (Message Resource), allinterno dei
quali ci sono i messaggi di testo che devono essere visualizzati nelle pagine
dellapplicazione, in lingue diverse. In questo modo, sulla base della locazione
geografica dellutente, il sistema riesce ad utilizzare il Resource Bundle corretto,
contenente i messaggi nella lingua adatta. Laccesso al file .properties, contenete i
messaggi, effettuato allo stesso modo ossia specificando la chiave (key) associata al
messaggio da visualizzare. Il meccanismo pu essere schematizzato in questo modo :

Resource Bundle da utilizzare;
la chiave (key) permette di
nellambito del Resource Bundle precedentemente selezionato;
BackingBean
metodo

catch (Exception) NavigationHandler
Error Page
154
_________________________________________________________________
Message Resources
Resource Bundle IT
Resource Bundle EN
Resource Bundle FR
Resource Bundle DE
B Be en nv ve en nu ut to o ! !
W We el lc co om me e ! !
B Bi ie en nv ve en nu u ! !
W Wi il ll lk ko om mm me en n ! !
Locale
Key = msg.benvenuto

Figura 26 - JSF e Struts : Internazionalizzazione

13. Sicurezza

Una delle pi importanti garanzie che deve fornire una Web application ai
propri visitatori la sicurezza nella comunicazione e nello scambio dei dati. In
moltissimi casi, lapplicazione prevede il trasferimento di informazioni sensibili, come
ad esempio il numero di una carta di credito, per le quali si rende necessaria
unoperazione di crittografia. Mediante questultima, possibile rendere i dati
illeggibili a chiunque li intercetti durante il trasferimento, a meno del destinatario che
ha a propria disposizione la chiave per decrittografarne il contenuto. Il meccanismo
che permette di garantire la sicurezza nelle comunicazioni in rete prevede lutilizzo
del protocollo SSL (Secure Sochet Layer) ed in particolare del protocollo HTTPS
(HTTP basato su SSL). Per quanto riguarda questo aspetto, i due framework a
confronto sono perfettamente uguali, in quanto non prevedono approcci differenti
per garantire la sicurezza delle pagine delle Web application realizzate. La tecnica
adottata quella comune a tutte le applicazioni Web implementate in Java e fa uso
delle funzionalit messe a disposizione dal Web Container. La sicurezza, quindi,
155
_________________________________________________________________
gestita allo stesso modo, in quanto tale compito completamente demandato
allambiente di esecuzione delle applicazioni, allinterno del quale viene abilitato il
supporto al protocollo SSL. Le Web application prevedono alcune semplici
modifiche al Deployment Descritpor web.xml, allinterno del quale va specificato il
livello di protezione e quali sono le pagine che ne devono essere soggette. In questo
modo, ogni qual volta arriva una richiesta ad una pagina tra quelle suddette, il Web
Container esegue la redirezione sulla porta impostata per il protocollo SSL e la
trasmissione avverr attraverso lHTTPS.

Web Container Deployment Descriptor
Pagine SSL Connector HTTPS
Web Application
R Ri ic ch hi ie es st ta a p pa ag gi in na a S SS SL L
https://WebApplication/...

Figura 27 - JSF e Struts : Sicurezza

14. Configurazione

La configurazione di una Web application, realizzata con Struts oppure JSF,
uno degli aspetti in cui i due framework sono piuttosto simili. Infatti, entrambi
prevedono la configurazione attraverso un file XML, per quanto concerne tutte le
caratteristiche principali dellapplicazione. Nella fase di start-up, per ciascuno di essi
prevista unoperazione di lettura e parsing del file, per poter generare una copia in
156
_________________________________________________________________
memoria delle informazioni di configurazione allinterno di specifiche classi. Ci che
cambia tra i due framework soltanto la sintassi XML ed ovviamente le
caratteristiche che possono essere configurate, che dipendono dalle potenzialit che
ha ciascuno dei due.

Classi in memoria
struts-config.xml
Configurazione

faces-config.xml
Configurazione

Application
Lifecycle
NavigationHandler
ApplicationConfig
ActionConfig
ControllerConfig
parsing
parsing

Figura 28 - JSF e Struts : Configurazione

15. Web Application Layout

Per quanto riguarda la definizione del layout delle pagine che compongono
lapplicazione, la distribuzione di Struts ingloba il framework Tiles. Questultimo
permette di definire la struttura di una pagina JSP, mediante una tecnica di
composizione di pi parti separate, i tiles appunto, che sono praticamente ulteriori
pagine JSP. In questo modo, possibile evitare la replicazione dei contenuti e
157
_________________________________________________________________
facilitare la manutenzione, in quanto la modifica di un gruppo di informazioni va
eseguita una ed una sola volta.
JavaServer Faces non dispone di questo supporto, per comunque possibile
importare le librerie di Tiles allinterno di un progetto JSF, per poterne sfruttare le
potenzialit.
Potendo utilizzare Tiles con entrambi i framework, sembrerebbe non esserci alcuna
differenza tra essi sotto questo punto di vista. In realt, essendo Tiles inglobato in
Struts, c una perfetta integrazione con la modalit di navigazione prevista da
questultimo. Infatti, se unapplicazione realizzata in Struts prevede lutilizzo di Tiles,
la classe che si occupa delle gestione delle richieste, non esattamente la
RequestProcessor ma la pi specifica TilesRequestProcessor, contenuta nelle librerie di Tiles.
Questa classe gestisce le richiesta allo stesso modo della precedente e garantisce una
perfetta sinergia con le operazioni di forwarding tra le pagine, cos come previsto in
Struts. Inoltre, la sua dichiarazione viene effettuata allinterno del file di
configurazione di Struts come se fosse semplicemente un plug-in.

CONTROLLER
TilesRequestProcessor

Figura 29 - Struts : Integrazione con Tiles

Invece, per poter utilizzare Tiles allinterno di JSF, necessario dichiararlo nel
Deployment Descriptor attraverso una Servlet, la nota TilesServlet, che viene avviata
immediatamente dopo la FacesServlet. Ci mette in evidenza che, mentre in Struts le
classi di questultimo e Tiles comunicano internamente al framework, in JSF invece si
ha a che fare con due Servlet indipendenti che scambiano informazioni.
CONTROLLER
TilesServlet
FacesServlet

Figura 30 - JSF : Interazione con la TilesServlet
158
_________________________________________________________________
16. Migrazione da Struts a JavaServer Faces

In passato, molti sviluppatori hanno scelto Struts per la realizzazione di
Web application, sulla base delle notevoli funzionalit offerte da questultimo e dai
tools di sviluppo forniti dalle case produttrici. Ad oggi, in virt dellintroduzione del
framework JavaServer Faces, ogni team di sviluppo deve prendere in considerazione
la possibilit di migrare verso questa nuova tecnologia, in riferimento ad
unapplicazione realizzata con Struts. La migrazione consigliata soprattutto nel caso
in cui, la Web application debba essere ulteriormente potenziata, nel qual caso si pu
fare uso degli strumenti innovativi di JSF. Nel caso in cui, debba essere previsto
esclusivamente un processo di manutenzione, si pu pensare di mantenere
larchitettura attuale realizzata in Struts.

16.1 Strategie di migrazione

Larchitettura fortemente espandibile di JSF mette a disposizione diversi
approcci per poter essere adottata in applicazioni preesistenti. Lapproccio
maggiormente conservativo prevede semplicemente di utilizzare i componenti di JSF,
senza alcun altra caratteristica del framework. Laltra possibilit quella di eseguire
una migrazione incrementale oppure completa.

16.1.1 Components Only

Utilizzare i componenti JSF in unapplicazione realizzata con un altro
framework, fornisce il vantaggio di poter sfruttare componenti eventualmente gi
presenti sul mercato, senza la necessit di riscriverli per la propria applicazione. Tutto
ci comporta un enorme beneficio, soprattutto nel caso in cui si ha a che fare con
unapplicazione di grandi dimensioni e tempi di sviluppo piuttosto stringenti.
Struts mette a disposizione una libreria chiamata Struts-Faces, mediante la quale
possibile costruire componenti della UI come in JSF, ma continuando ad utilizzare
contemporaneamente le action. Ci possibile grazie a particolari listeners JSF, che
159
_________________________________________________________________
entrano in gioco garantendo lesecuzione del tipico ciclo di vita di una richiesta
previsto in Struts, in maniera del tutto trasparente rispetto allesecuzione delle action.
Questo tipo di evoluzione, possibile in virt del fatto che sia Struts che JSF sono
implementati mediante lutilizzo delle proprie Servlets che sono in esecuzione
allinterno della stessa applicazione, in modo da poter condividere le variabili e la
logica applicativa.

F Fa ac ce es s
r re eq qu ue es st t
F Fa ac ce es s
r re es sp po on ns se e
S St tr ru ut ts s
Client
ActionServlet
Event
Listeners
FacesServlet
Specialized RequestProcessor
S St tr ru ut ts s

Figura 31 - Migrazione "Components Only"

Ogni Struts request viene inoltrata verso la ActionServlet, la quale non utilizza il
RequestProcessor di default, ma bens una versione specifica, per poter intercettare
eventuali eventi sui componenti JSF. Se la richiesta non prevede lintervento di questi
ultimi, viene prodotta una Struts response. Viceversa, se viene scatenato quale evento
su un componente della UI, realizzato con JSF, il controllo passa alla FacesServlet la
quale produrr una Faces response. E ovvio che se a monte, arriva una Faces
request, essa viene gestita direttamente dalla FacesServlet, la quale attraverso i listeners,
passa il controllo al RequestProcessor che avvier le action Struts per la gestione della
richiesta. Al termine dellesecuzione, si potrebbe generare una Struts response oppure
una Faces response.
160
_________________________________________________________________
E da mettere in evidenza che, grazie allutilizzo di componenti JSF, si elimina il
limite di Struts che riguarda la non indipendenza dal dispositivo client. Infatti ,
possibile accedere alla Web application, non necessariamente attraverso un browser
Web ma eventualmente mediante cellulari, palmari o dispositivi di questo genere.

16.1.2 Incremental migration

Quando si ha come obiettivo una migrazione verso larchitettura JSF, il
primo approccio pu essere quello incrementale, mediante il quale si possono trarre i
principali vantaggi di JSF ma con un impatto minimo sullinfrastruttura preesistente.
Tale migrazione utile quando c la necessit di introdurre nuove funzionalit
nellapplicazione e contemporaneamente eseguire lupgrade verso JSF.
La migrazione incrementale prevede come primo passo lutilizzo di componenti JSF,
cos come la component-only, e poi successivamente lo spostamento della business-
logic allinterno dei backing bean. Inoltre, essa pu essere eseguita convertendo parte
dellapplication logic dopo aver realizzato le pagine basate sui componenti JSF,
oppure eseguire queste operazioni contemporaneamente. Ci possibile perch tutto
il codice necessario allinterno delle stessa applicazione, per cui le parti che
utilizzano JSF e le parti che utilizzano un altro framework, come Struts, condividono
i medesimi oggetti.
Dalla figura seguente, si osserva che gli event-listeners di JSF e le classi della logica
applicativa di un altro framework, in questo caso le action di Struts, condividono le
medesime classi della business-logic e le classi per laccesso alla base di dati. Tutto ci
garantisce la convivenza di due framework nellambito della medesima applicazione.
161
_________________________________________________________________
Client
Non-FacesServlet FacesServlet
F Fa ac ce es s
F Fa ac ce es s
N No on n- -F Fa ac ce es s
N No on n- -F Fa ac ce es s
Event
Listeners
Application
Logic
State &
Application
Beans
Business-Logic
& Data Access

Web Application

Figura 32 - Migrazione : Incremental migration

Nel caso di una Faces request, la FacesServlet utilizza i listener degli eventi che
sfruttano i beans e gli oggetti della business-logic, oltre che dellaccesso alla base di
dati. Nel caso di un Non-Faces request, per esempio orientata a Struts, ci sar una
certa logica applicativa, le action nel caso di Struts, che acceder ai medesimi oggetti
suddetti. Si riesce a far convivere porzioni di codice di JSF e di Struts, facendo
riferimento agli stessi oggetti della business-logic.
Di seguito, si evidenziano le corrispondenze che ci sono tra Struts e JSF e quindi
quali sono i compiti da svolgere, nel caso di una migrazione incrementale dalluno
allaltro.

162
_________________________________________________________________

Configuration
(forwards, actions, etc.)
Configuration
(navigation rules, backing
beans, etc.)
JSP pages
(with Struts tags)
JSP pages
(with JSF component tags)
Application Layer
(actions, action forms,etc.)
Application Layer
(backing beans,
event listeners, etc.)
Business Layer
(JBs, EJBs, Web services)
Business Layer
(JBs, EJBs, Web services)
Integration Layer
(Data Access Objects)
Integration Layer
(Data Access Objects)
Data Service
(DataBase, JBs,
EJBs, Web services)
S St tr ru ut ts s J Ja av va aS Se er rv ve er r F Fa ac ce es s
M
i
g
r
a
t
i
o
n

L
a
y
e
r
s

Data Service
(DataBase, JBs,
EJBs, Web services)
Figura 33 - Migrazione : Migration Layers

Come si pu osservare, i livelli contenenti la business-logic e le classi per laccesso
alle basi di dati, sono perfettamente coincidenti e quindi non c bisogno di alcun
accorgimento nel passaggio da un framework allaltro.

163
_________________________________________________________________
Ci che ovviamente va rivisto sono :

- il livello applicativo : in Struts sono previste le action ed i formbean, mentre in
JSF i backing beans ed i listeners;
- le pagine JSP : Struts fornisce i tag delle proprie librerie, neutre JSF mette a
disposizione i componenti evoluti della UI;
- configurazione : i file di configurazione XML utilizzano degli elementi
completamente differenti;

16.1.3 Full migration

La migrazione pu essere eseguita in maniera completa in una sola volta, al
posto di una migrazione incrementale in pi passi successivi. Questo tipo di
soluzione pu essere adottata quando i tempi di sviluppo a disposizione sono
piuttosto ampi, in quanto deve essere rivista la completa architettura
dellapplicazione. Dal punto di vista concettuale, essa simile alla migrazione
incrementale, considerando i livelli da modificare o meno, passando da Struts a JSF.
La differenza sostanziale sta nel fatto che non necessario utilizzare una libreria di
integrazione, in quando il vecchio framework viene completamente sostituito.
164
Capitolo V Case Study : Analisi e Progettazione
_________________________________________________________________
C Ca ap pi it to ol lo o V V C Ca as se e S St tu ud dy y : : A An na al li is si i e e P Pr ro og ge et tt ta az zi io on ne e

1. Introduzione

La presentazione dei due principali framework, quali Struts e JavaServer
Faces, utilizzati per la realizzazione di Web application ha come obiettivo principale
la possibilit di poterne effettuare un confronto. Una volta evidenziate le potenzialit
delluno e dellaltro, si rende necessario lo sviluppo di unapplicazione con ciascuno
di essi, in modo da individuare pregi e difetti di entrambi e vantaggi o svantaggi
delluno rispetto allaltro. Tale confronto relativo a tutti gli aspetti che riguardano la
realizzazione di una Web application, con strumenti che si basano sul pattern MVC,
quali appunto i framework presi in considerazione.
In questa sede, stata realizzata unapplicazione Web che permetta agli utilizzatori di
usufruire di contenuti audio, quali brani musicali in formato MP3 (MPEG Layer 3),
mettendo a disposizione degli utenti e dellamministratore del sistema una serie di
funzionalit definite dalle specifiche assegnate.
La Web application stata realizzata con lutilizzo di entrambi i framework,
usufruendo , l dove possibile, di tutte le potenzialit di ciascuno di essi.
Le fasi di sviluppo hanno seguito il tipico ciclo di vita del software secondo il
modello a cascata, Waterfall Model, e possono essere riassunte di seguito :

- studio di fattibilit;
- analisi e specifica dei requisiti;
- progettazione;
- codifica ed implementazione;
- testing;
- messa in esercizio;
- manutenzione;

Lo studio di fattibilit, in questo caso, stato immediatamente superato, in quanto
non cerano da fare considerazioni riguardo le possibili soluzioni da adottare, le
165
_________________________________________________________________
risorse finanziarie ed umane a disposizione, tenendo conto che sono stati fissati a
priori gli strumenti da utilizzare.
LAnalisi e la specifica dei requisiti ha previsto la realizzazione del Documento di
Specifica dei Requisiti Software (SRS Software Requirements Specification),
elencando tutte le funzionalit fornite dal sistema software sia allutente che
allamministratore e considerando per ciascuna di esse, una breve descrizione, gli
input previsti, le elaborazioni eseguite ed i possibili output prodotti.
Nella fase di progettazione, sono stati realizzati i principali diagrammi UML (Unified
Modelling Language) previsti per lo sviluppo, quali :

- Class Diagram;
- Use Case Diagram;
- Sequence Diagram;
- Activity Diagram;
- Statechart Diagram;

Ad essi, vanno poi aggiunti il Conceptual Data Model ed il Physical Data Model, per
la descrizione concettuale e fisica della base di dati utilizzata dalla Web application.
Lo sviluppo ha poi previsto due distinte fasi di codifica, realizzando lapplicazione
con entrambi i framework. Facendo riferimento alla struttura del Model prevista dal
pattern MVC, il sottolivello di Data Access stato realizzato separatamente dagli altri
e le classi che ne sono scaturite, sono state utilizzate per entrambe le
implementazioni. Per quanto concerne i sottolivelli superiori, Business-Logic e
External Interface, si preferita una modalit di fusione, pi legata a JavaServer
Faces che non a Struts.
La fase di testing ha permesso la correzione di errori e problemi rilevati durante il
funzionamento del software.
Infine, non sono state previste delle vere e proprie fasi di messa in esercizio e
manutenzione.
Lo strumento software di tipo CASE, che stato utilizzato per la realizzazione di
tutti i diagrammi della fase di progettazione, il noto Sybase Power Designer.

166
_________________________________________________________________
2. Requisiti

Il case study (caso di studio) preso in esame, prevede lo sviluppo di una
Web application che permette allutenza in generale, di usufruire di contenuti audio,
quali brani musicali in formato MP3 (MPEG Layer 3).
Gli utilizzatori possono avere permessi di accesso diversi e quindi funzionalit
differenziate, sulla base della distinzione dei seguenti ruoli :

- utente;
- amministratore;

Per ciascuno di essi, le funzionalit accessibili nellapplicazione sono descritte di
seguito.

Utente :

- registrazione base per lascolto in streaming dei brani musicali e la gestione
di playlist personalizzate;
- registrazione estesa che permetta lacquisto dei brani musicali e la
possibilit di eseguirne il download, oltre alle funzionalit di base;
- acquisto e successive ricariche di una scheda prepagata virtuale, mediante
pagamento con carta di credito, che permetta lacquisto dei brani musicali;
- accesso allarchivio musicale, con possibilit di fissare diversi criteri di ricerca
dei brani desiderati e di visionarne le informazioni, per poterne eseguire
lascolto, lacquisto ed il download;
- gestione di una o pi playlist, con la possibilit di ascolto, nonch di
aggiungere ed eliminare da ciascuna di esse dei brani musicali;
- gestione dei propri dati personali per un eventuale aggiornamento;
- richiesta di una mail, contenente username e password di accesso, in caso di
dimenticanze;
- operazioni di login e logout;

167
_________________________________________________________________
Amministratore :

- gestione completa dellarchivio musicale, con la possibilit di inserire,
modificare e cancellare i brani, usufruendo della funzionalit automatica del
sistema di garantire coerenza tra i tag ID3v1 degli stessi e le informazioni
immesse nella base di dati;
- accesso allarchivio musicale, con possibilit di fissare diversi criteri di ricerca
dei brani desiderati e di visionarne le informazioni, per poterne eseguire
lascolto;
- gestione degli utenti registrati, con la possibilit di visionarne i dati ed
eseguire le operazioni di cancellazione e sblocco, qualora un utente abbia
commesso pi di due tentativi errati di accesso al sistema;
- gestione dei propri dati di accesso per un eventuale aggiornamento;
- operazioni di login e logout;

Sulla base di tali requisiti stato redatto il Documento di Specifica dei Requisiti
Software (SRS), di fondamentale importanza per le fasi successive di sviluppo.

3. Progettazione

La fase di progettazione ha previsto la realizzazione dei principali
diagrammi UML, in relazione soprattutto allanalisi del software e non tanto alla sua
corrispondente implementazione. Essi costituiscono unastrazione di alto livello del
sistema e sono completamente indipendenti da quelli che possono essere gli
strumenti utilizzati nella codifica.

3.1 Use Case Diagrams

I diagrammi dei casi duso (Use Case Diagrams) costituiscono uno
strumento utile per catturare il comportamento esterno del sistema da sviluppare,
senza dover specificare come tale comportamento debba essere realizzato; il sistema
visto come una scatola nera (black-box). Essi forniscono una descrizione dei
168
_________________________________________________________________
modi in cui il sistema potr essere utilizzato, ossia ci che lutente pu fare su di
esso e come questultimo risponde alle sollecitazioni. La realizzazione dei diagrammi
ha previsto un approccio top-down, partendo dallo scenario di carattere generale, in
cui le modalit duso logicamente correlate sono accorpate, fino ad una
decomposizione in cui sono descritti i casi di utilizzo non ulteriormente
scomponibili.

3.1.1 Generale

Facendo riferimento ai requisiti assegnati, stato definito un Use Case
Diagram Generale, che si pone al livello di astrazione pi elevato del sistema,
mettendo in evidenza tutte quelle che sono le modalit di utilizzo dello stesso, da
parte dellutente e dellamministratore. Questi ultimi rappresentano gli attori che
possono accedere alle funzionalit offerte dal sistema, di cui alcune sono condivise
ossia accessibili da entrambi, mentre altre sono prerogativa esclusiva di uno dei due
ruoli.
<<include>>
Utente
Amministratore
Login Sistema
Gestione Dati Personali
Logout Sistema
Gestione Utenti
Registrazione
Gestione Scheda Prepagata
Verifica Copertura Carta Credito
Azioni su brani MP3
Gestione Archivio brani MP3

Figura 1 - Use Case Diagram Generale
169
_________________________________________________________________

A partire da questo diagramma, possibile effettuare una decomposizione scendendo
ad un livello di astrazione minore, in cui si prendono in considerazione nel dettaglio
le modalit di utilizzo del sistema.
In particolare, le modalit accessibili esclusivamente dallutente sono le seguenti :

- Gestione Scheda Prepagata;
- Registrazione;
- Azioni su brani MP3;

3.1.2 Gestione Scheda Prepagata

La modalit di Gestione Scheda Prepagata relativa a tutte le azioni che
lutente pu eseguire in relazione alla scheda prepagata, ossia lacquisto, la ricarica e la
visualizzazione delle informazioni.

<<extend>>
<<include>>
Utente
Acquisto Scheda Prepagata
Ricarica Scheda Prepagata
Visualizzazione Informazioni Scheda
Verifica Copertura Carta Credito

Figura 2 - Use Case Diagram Gestione Scheda Prepagata

170
_________________________________________________________________
3.1.3 Registrazione

La modalit di Registrazione pu essere considerata atomica e non
ulteriormente decomponibile, facendo riferimento alla procedura eseguita dallutente
per registrarsi ed usufruire dei servizi della Web application.

3.1.4 Azioni su Brani

Infine, la modalit delle Azioni su brani MP3 da considerarsi la pi
complessa, in quanto al suo interno prevede tutte le possibili azioni che lutente pu
eseguire allinterno dellapplicazione sui contenuti audio offerti. In particolare, sono
da evidenziare le opportunit di visualizzare le informazioni di un brano, lascolto in
streaming di questultimo, il relativo acquisto e download, nonch la visualizzazione
dellelenco dei brani disponibili per genere oppure in base a dei criteri di ricerca
prefissati. E prevista inoltre la modalit Gestione Playlist, che non pu essere
considerata atomica ma che possibile ulteriormente decomporre scendendo ad un
livello di astrazione molto pi basso.

<<include>>
<<include>>
<<include>>
<<extend>>
Utente
Visualizzazione brani MP3
Ricerca brani MP3
Visualizzazione Informazioni brano MP3
Ascolto brano MP3
Acquisto/Download brano MP3
Gestione Playlist

Figura 3 - Use Case Diagram Azioni su Brani MP3
171
_________________________________________________________________
3.1.5 Gestione Playlist

Per quanto riguarda la modalit Gestione Playlist, essa comprende tutte
le azioni che lutente pu eseguire sulle playlist, in particolare :

- creazione di una nuova playlist specificandone il nome;
- visualizzazione dellelenco delle playlist create in precedenza dallutente;
- visualizzazione dei brani MP3 contenuti in una specifica playlist;
- azioni di visualizzazione e ricerca dei brani allinterno dellarchivio, con la
possibilit di aggiungere uno o pi di essi allinterno di una playlist specificata;
- possibilit di rimuovere uno o pi brani da una playlist;
- ascolto della playlist;
- cancellazione di uno o pi playlist;

Sulla base dei suddetti modi duso, lo Use Case Diagram assume una forma
abbastanza complessa ed ampia.
Osservandone la struttura, si evidenzia la presenza di due scenari distinti associati alle
modalit duso di cancellazione di una playlist e di inserimento di un brano MP3. Nel
primo caso, possibile cancellare una o pi playlist selezionandole dallelenco,
oppure visualizzare lelenco dei brani di una playlist e richiedere la cancellazione di
questultima. Nel secondo caso, possibile inserire uno o pi brani MP3
selezionandoli da un elenco, visualizzato al termine di una ricerca, oppure inserire un
singolo brano dalla schermata di visualizzazione delle informazioni corrispondenti.
Secondo la sintassi UML, entrambi i casi duso includono le modalit di utilizzo
che danno luogo ai due scenari suddetti.

172
_________________________________________________________________
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<include>>
<<include>>
Utente
Visualizzazione Elenco Playlist
Creazione Playlist
Cancellazione Playlist
Visualizzazione brani MP3 Playlist
Ascolto Playlist
Inserimento brano MP3 Playlist
Cancellazione brano MP3 Playlist
Ricerca brani MP3
Ha due scenari alternativi, in
base alla visualizzazione di
pi brani o del singolo brano
base alla visualizzazione di pi
playlist o della singola playlist

Figura 4 - Use Case Diagram Gestione Playlist

3.1.6 Gestione Utenti

Considerando nuovamente il diagramma dei casi duso Generale, si evince
che ci sono le modalit Gestione Utenti e Gestione Archivio brano MP3 che
sono accessibili solo ed esclusivamente dallamministratore.
173
_________________________________________________________________
In particolare, Gestione Utenti comprende alcune azioni basilari che possono
essere eseguite sugli utenti registrati, in particolare la visualizzazione di un elenco di
questi ultimi, la cancellazione, la visualizzazione dei dati anagrafici di un singolo
utente e loperazione di sblocco, qualora lutente abbia commesso due tentativi errati
consecutivi di accesso al sistema e sia stato bloccato.

<<include>>
<<include>>
<<include>>
<<include>>
Amministratore
Visualizzazione Utenti
Cancellazione Utente
Visualizzazione Dati Anagrafici Utente
base alla visualizzazione di pi
utenti o del singolo utente
Sblocco Utente

Figura 5 - Use Case Diagram Gestione Utenti

3.1.7 Gestione Archivio Brani

La modalit duso pi complessa certamente la Gestione Archivio Brani
MP3, nellambito della quale, lamministratore esegue tutte le operazioni di gestione
dellarchivio del sistema contenente i brani in formato MP3. In particolare, le
operazioni possibili sono le seguenti :

- visualizzazione dei brani in base ad un genere oppure sulla base di criteri di
ricerca opportunamente fissati;
- visualizzazione e modifica delle informazioni di un brano;
174
_________________________________________________________________
- inserimento di un nuovo brano MP3 in archivio con lupload del file MP3
associato;
- cancellazione di uno o pi brani dallarchivio;
- ascolto di un singolo brano MP3;

<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<extend>>
Amministratore
Ricerca brani MP3
Inserimento brano MP3
Modifica Informazioni brano MP3
Cancellazione brano MP3
base alla visualizzazione di
pi brani o del singolo brano
Ascolto brano MP3

Figura 6 - Use Case Diagram Gestione Archivio Brani MP3

175
_________________________________________________________________
3.1.8 Casi duso comuni : Login, Logout, Gestione Dati Personali

Infine, le modalit di utilizzo del sistema che sono comuni allutente ed
allamministratore, riguardano il Login Sistema ed il Logout Sistema che
possono essere considerate atomiche e la Gestione Dati Personali che comprende
le operazioni di gestione dei propri dati di registrazione e di accesso per entrambi i
ruoli. In particolare, lamministratore ha la possibilit di modificare esclusivamente la
propria Password, non essendo registrati per questultimo altri dati nel database. Per
quanto riguarda lutente, il tutto dipende dal tipo di registrazione che ha effettuato in
precedenza : nel caso di registrazione base pu eseguire le stesse azioni
dellamministratore, viceversa nel caso di registrazione estesa, essendo stati
registrati anche i dati anagrafici, ha ovviamente la possibilit di modificarli. Un modo
di utilizzo ulteriore disponibile soltanto allutente, riguarda la possibilit di richiedere
una mail contenente Username e Password di accesso in caso di dimenticanza.

<<extend>>
Utente
Amministratore
Modifica Username/Password
Modifica Dati Anagrafici
Richiesta Username/Password

Figura 7 - Use Case Diagram Gestione Dati Personali

176
_________________________________________________________________
3.2 Class Diagram

Mediante il Class Diagram possibile definire tutte quelle che sono le entit
caratteristiche del sistema software e le relazioni che ci sono tra di esse. Ciascuna
entit ovviamente modellabile attraverso il concetto di classe, che ne definisce le
caratteristiche (i dati) ed il comportamento (le operazioni). Ovviamente, anche il
Class Diagram pu essere realizzato a diversi livelli di astrazione, passando da un
livello elevato, definito di seguito, ad un livello pi basso e strettamente legato alla
fase di implementazione e quindi relazionato al framework ed al linguaggio utilizzato.
Attraverso questo diagramma possibile modellare la vista statica del sistema,
tenendo anche conto di quelle che sono le funzionalit offerte da questultimo e rese
disponibili attraverso le entit che lo compongono.
Sulla base delle specifiche definite per lapplicazione, il sistema prevede le seguenti
entit e le relative classi che le modellano :

- Ruolo : definisce un generico utilizzatore del sistema, da distinguere tra utente
ed amministratore;
- Utente : generico utente registrato che accede al sistema;
- Amministratore : amministratore del sistema;
- Accesso : classe astratta che contiene le informazioni relative allaccesso al
sistema da parte di un utilizzatore qualsiasi;
- AccessoUtente : informazioni di accesso di un utente;
- AccessoAmministratore : informazioni di accesso dellamministratore;
- CartaCredito : contiene le informazioni della carta di credito con cui lutente
pu acquistare una scheda prepagata;
- SchedaPrepagata : scheda attraverso la quale lutente pu acquistare e scaricare i
brani MP3;
- Ricarica : singola operazione di ricarica della scheda;
- BranoMP3 : contiene le informazioni relative ad un singolo brano MP3
presente nellarchivio;
- FileMP3 : rappresenta il file MP3 fisico associato ad un certo brano;
- Download : generica operazione di download di un brano;
- Playlist : definisce una playlist creata da uno specifico utente;
177
_________________________________________________________________
Il diagramma definito di seguito si pone ad un livello di astrazione intermedio,
nellambito del quale i membri di ciascuna classe (campi e metodi), fanno riferimento
al linguaggio utilizzato nellimplementazione, ossia il Java. Ovviamente, astraendosi
da questultimo, facile osservare che la struttura del sistema che ne scaturisce
completamente indipendente dallimplementazione.
In riferimento alle dipendenze che ci sono tra le varie classi, si possono fare le
seguenti osservazioni :

- le classi AccessoUtente ed AccessoAmministratore costituiscono una
specializzazione della classe Accesso, pi da un punto di vista concettuale che
pratico;
- la classe Ruolo generalizza le classi Utente ed Amministratore, in quanto queste
ultime definiscono un particolare tipo di utilizzatore del sistema, luno
diverso dallaltro ma con alcune caratteristiche comuni;
- la classe Ricarica di tipo associativo, in quanto lUtente legato alla
SchedaPrepagata, non soltanto sulla base di unoperazione di acquisto ma anche
di ricarica;
- la classe Download di tipo associativo, nellambito della relazione che c tra
Utente e BranoMP3;
- tra Playlist e BranoMP3 c un legame di tipo aggregation, tenendo conto
che una playlist costituita da uno o pi brani, ma che comunque eliminando
una playlist (il tutto) non elimino i brani dallarchivio (le parti),
differentemente da quanto accade in una composition;

Le altre tipologie di relazioni previste sono autoesplicative, in quanto esprimono il
legame tra unentit e le altre, sulla base delle specifiche e delle funzionalit del
sistema. Infine, alle classi suddette sono associate, per ciascuna di esse, le
corrispondenti classi per laccesso alla base di dati per garantire la permanenza delle
informazioni.

178
_________________________________________________________________

0..*
0..*
1..1
0..*
0..*
0..*
1..1
0..*
1..1
0..*
1..1
0..1
1..1
0..*
1..1
1..1
<<extends>>
<<extends>>
<<extends>>
<<extends>>
Utente
-
-
-
-
-
-
-
-
-
-
-
-
-
nome
cognome
indirizzo
citta
provincia
CAP
stato
telefono
dataNascita
sesso
email
dataOraRegistrazione
acquistoMP3
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.util.Date
: char
: java.lang.String
: java.util.Date
: boolean
+
+
+
+
+
+
#
#
#
#
#
#
<<Override>>
<<Override>>
<<Override>>
<<Override>>
<<Override>>
<<Override>>
registrazione ()
elimina ()
modificaDatiAnagrafici ()
visualizzaElencoUtenti ()
visualizzaDatiAnagrafici ()
richiediUserNamePassword ()
login ()
logout ()
modificaUserNamePassword ()
blocca ()
sblocca ()
controlloBlocco ()
: Utente
: void
: Utente
: java.util.List
: Utente
: void
: Ruolo
: void
: Ruolo
: void
: void
: Ruolo
Amministratore
#
#
#
#
#
#
<<Override>>
<<Override>>
<<Override>>
<<Override>>
<<Override>>
<<Override>>
login ()
logout ()
blocca ()
sblocca ()
controlloBlocco ()
: Ruolo
: void
: Ruolo
: void
: void
: Ruolo
Playlist
-
-
nome
dataOraCreazione
: java.lang.String
: java.util.Date
+
+
+
+
+
+
+
+
inserisciBrano ()
eliminaBrano ()
ascolta ()
elimina ()
crea ()
visualizzaElencoPlaylist ()
visualizzaElencoBraniMP3Playlist ()
visualizzaInfo ()
: void
: void
: FileMP3
: void
: Playlist
: java.util.List
: java.util.List
: Playlist
BranoMP3
-
-
-
-
-
-
-
-
genere
titolo
autore
album
durata
costo
dimensione
nomeFileMP3
: java.lang.String
: java.lang.String
: java.lang.String
: java.lang.String
: java.sql.Time
: float
: long
: java.lang.String
+
+
+
+
+
+
+
+
+
inserisci ()
elimina ()
ascolta ()
acquista ()
modificaInfo ()
visualizzaInfo ()
ricerca ()
visualizzaElencoBraniMP3 ()
avviaDownload ()
: BranoMP3
: void
: FileMP3
: BranoMP3
: BranoMP3
: BranoMP3
: java.util.List
: java.util.List
: void
AccessoUtente
#
#
#
<<Override>>
<<Override>>
<<Override>>
inserisci ()
aggiorna ()
leggi ()
: Accesso
: Accesso
: Accesso
AccessoAmministratore
#
#
#
<<Override>>
<<Override>>
<<Override>>
inserisci ()
aggiorna ()
leggi ()
: Accesso
: Accesso
: Accesso
SchedaPrepagata
-
-
-
importoResiduo
dataOraAcquisto
dataScadenza
: float
: java.util.Date
: java.util.Date
+
+
+
+
+
+
+
ricarica ()
acquista ()
elimina ()
visualizzaInfo ()
controlloScadenza ()
controlloImportoResiduo ()
aggiornaImportoResiduo ()
: SchedaPrepagata
: SchedaPrepagata
: void
: SchedaPrepagata
: boolean
: boolean
: SchedaPrepagata
Ricarica
-
-
importo
dataOra
: float
: java.util.Date
+ esegui () : Ricarica
Download
- dataOrtaAcquisto : java.util.Date
+ inserisci () : Download
CartaCredito
-
-
-
-
tipo
numero
codiceSegreto
dataScadenza
: java.lang.String
: java.lang.String
: java.lang.String
: java.util.Date
+ verificaCopertura () : boolean
FileMP3
-
-
-
-
-
-
nomeFile
filePath
dimensione
tagTitolo
tagAutore
tagAlbum
: java.lang.String
: java.lang.String
: long
: java.lang.String
: java.lang.String
: java.lang.String
+
+
+
+
+
+
leggiTag ()
aggiornaTag ()
riproduci ()
upload ()
download ()
elimina ()
: Tag
: FileMP3
: void
: FileMP3
: FileMP3
: void
Accesso
{abstract}
#
#
#
#
#
dataOraLogin
dataOraLogout
loginValido
tentativo
indirizzoIP
: java.util.Date
: java.util.Date
: boolean
: byte
: java.lang.String
#
#
#
inserisci ()
aggiorna ()
leggi ()
: Accesso
: Accesso
: Accesso
Ruolo
#
#
#
#
userName
password
bloccato
loggedIn
: java.lang.String
: java.lang.String
: boolean
: boolean
#
#
#
#
#
#
login ()
logout ()
blocca ()
sblocca ()
controlloBlocco ()
: Ruolo
: void
: Ruolo
: void
: void
: Ruolo

Figura 8 - Class Diagram

179
_________________________________________________________________
3.3 Activity Diagrams Sequence Diagrams

Facendo riferimento a quelle che sono le funzionalit offerte dal sistema e
le modalit di utilizzo di questultimo, attraverso gli Activity Diagrams possibile
modellare le azioni necessarie per compiere unattivit ed il flusso di controllo tra di
esse. Ciascuna activity rappresenta unazione che viene eseguita dal sistema oppure
dallutilizzatore e pu essere atomica oppure scomposta in pi action elementari.
Nella gestione del flusso di controllo, possibile definire esecuzioni parallele di
operazioni e la loro sincronizzazione, nonch esecuzioni condizionali. Inoltre,
attraverso lo strumento dell object flow possibile specificare quali sono gli
oggetti del sistema che entrano in gioco per ciascuna azione eseguita e quale sia il
loro stato.
Invece, attraverso i Sequence Diagrams possibile descrivere la vista dinamica del
sistema, enfatizzando le interazioni dovute allo scambio di messaggi tra gli oggetti e il
loro ordinamento temporale. Ciascun diagramma evidenzia il modo in cui uno
scenario, ossia uno specifico percorso in un caso duso, viene risolto dalla
collaborazione tra un insieme di oggetti. Generalmente, per, al posto di realizzare
un diagramma per ciascuno scenario, si preferisce definire un unico diagramma
allinterno del quale vengono descritte le situazioni alternative, facendo uso dei
numeri di sequenza sui messaggi.
E da osservare che nellambito dei Sequence Diagrams sono previsti degli oggetti di
tipo Interfaccia, che definiscono le parti del sistema che interagiscono con lutente,
ossia la cosiddetta UI (User Interface). In questa fase, non viene specificata la
tipologia di interfaccia utente, in modo da poter sfruttare i diagrammi realizzati anche
con implementazioni diverse. E ovvio che, nel caso di una Web application,
linterfaccia utente sia caratterizzata da pagine Web e dai relativi form che le
compongono.
E stato definito un Activity Diagram di carattere generale, che si pone ad un elevato
livello di astrazione e che descrive tutte le possibili azioni ed il relativo flusso, che
possono essere eseguite da un utente non registrato, da un utente registrato ed
ovviamente dallamministratore.
180
_________________________________________________________________
Inserimento Username e Password
[Utente registrato oppure
Amministratore - login]
[1 errore - Password errata
oppure Ruolo gi loggato]
Utente/Amministratore bloccato
[Username e Password corretti]
Login Sistema
Registrazione
[Utente non registrato]
[2 errore - Password errata]
Acquisto Scheda Prepagata
[Prevede acquisto/download
di brani MP3]
Verifica copertura Carta di Credito
[Carta di Credito scoperta] [Carta di Credito coperta]
[Non prevede
acquisto/download di brani
MP3]
Richiedi Password
[Utente registrato - password
dimenticata]
Logout Sistema
Gestione Dati Personali
Gestione Scheda Prepagata
Visualizzazione/Ricerca brani MP3
Ascolto brani MP3
Gestione Utenti
Gestione Archivio brani MP3
Gestione Playlist
[Utente]
[Amministratore]
Acquisto/Download brani MP3
Richiesta Servizio
Attivit comuni a
Utente e
Amministratore
Attivit distinte fra
Utente e
Amministratore

Figura 9 - Activity Diagram Generale

A partire da esso, possibile scendere ad un livello di dettaglio maggiore,
specificando la sequenza delle azioni per ogni funzionalit del sistema.
181
_________________________________________________________________
3.3.1 Login

Per quanto riguarda il Login dellutente e dellamministratore, le azioni da
eseguire sono praticamente le stesse a meno degli oggetti che entrano in gioco.
Una volta inseriti Username e Password, il sistema ne effettua il controllo della
correttezza, valutando in primo luogo se lo Username esiste e successivamente
verificando la validit della Password. Ovviamente, a colui che tenta di accedere,
viene sempre dato un messaggio generico di errore, senza mai specificare quale dei
due parametri sia errato.
Per evitare tentativi di accesso continuamente errati, magari eseguiti non
effettivamente dalla persona titolare dellaccount, il sistema blocca lutilizzatore dopo
due tentativi di accesso consecutivi errati. Tale blocco pu essere rimosso
esclusivamente contattando lamministratore del sistema, che ha i diritti di accesso
alla gestione degli utenti.
Ovviamente, nel caso in cui Username e Password siano corretti, si valuta comunque
se attivo un blocco causato da tentativi errati precedenti ; nel caso di login
consentito, si esegue laggiornamento delle informazioni di accesso.
La monitorizzazione e registrazione degli accessi, validi o non validi, relativi agli
utilizzatori della Web application, pu essere considerato uno strumento mediante il
quale sia possibile eseguire delle statistiche o comunque ricercare eventuali frodi e
tentativi di accesso non legittimi al sistema.
Nellambito del Sequence Diagram, possibile osservare lo scenario di Username
errata e quello di Username corretta, nellambito del quale si possono verificare le
seguenti situazioni distinte :

- Password errata al 1 tentativo;
- Password errata al 2 tentativo che comporta il blocco dellutilizzatore;
- Password corretta ma lutilizzatore bloccato;
- Utilizzatore gi loggato;
- Login consentito;

182
_________________________________________________________________

Utente Sistema
Login Sistema
[1 errore - Password errata oppure Utente gi loggato]
Controllo Username e Password
[Username errata]
:AccessoUtente
[creato]
:AccessoUtente
[aggiornato]
Aggiornamento del numero di
tentativi errati di accesso
[Username corretta -
1 tentativo]
2 tentativo]
:Utente
[letto] : 1
:Utente
[bloccato]
Visualizzazione Menu Utente
Controllo blocco
:Utente
[letto] : 2
[Utente non bloccato]
[Utente bloccato]

Figura 10 - Activity Diagram Login Utente

183
_________________________________________________________________

Amministratore Sistema
Controllo Username e Password
[Username errata]
:AccessoAmministratore
[creato]
1 tentativo]
[1 errore - Password errata oppure Amministratore gi loggato]
2 tentativo]
Login Sistema
[aggiornato]
Aggiornamento del
numero di tentativi errati
di accesso
:Amministratore
[letto] : 1
:Amministratore
[bloccato]
Visualizzazione Menu Amministratore
Controllo blocco
:Amministratore
[letto] : 2
[Amministratore non
bloccato]
[Amministratore bloccato]

Figura 11 - Activity Diagram Login Amministratore

184
_________________________________________________________________

Figura 12 - Sequence Diagram Login Utente
1
:

r
i
c
h
i
e
s
t
a

d
i

l
o
g
i
n
2
:

c
r
e
a
t
e
3
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

U
s
e
r
n
a
m
e

e

P
a
s
s
w
o
r
d
5
:

e
s
e
g
u
i

l
o
g
i
n
6
:

c
r
e
a
t
e
7
:

l
o
g
i
n
(

)
8
:

l
e
g
g
i
(

)
9
:

c
a
r
i
c
a

d
a
t
i
4
:

i
n
s
e
r
i
m
e
n
t
o

U
s
e
r
n
a
m
e

e

P
a
s
s
w
o
r
d
9
.
1
:

e
r
r
:

U
s
e
r
n
a
m
e

e
r
r
a
t
a
9
.
1
.
1
:

s
e
g
n
a
l
a
z
i
o
n
e

e
r
r
o
r
e
9
.
2
.
1
:

c
r
e
a
t
e
9
.
2
.
1
.
1
:

i
n
i
z
i
a
l
i
z
z
a
z
i
o
n
e

e
s
e
g
u
i
t
a
1
0
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

e
r
r
a
t
a

a
l

1

t
e
n
t
a
t
i
v
o
1
0
.
1
.
1
:

s
e
g
n
a
l
a
z
i
o
n
e

e
r
r
o
r
e
1
0
.
2
:

e
r
r
:

P
a
s
s
w
o
r
d

e
r
r
a
t
a

a
l

2

t
e
n
t
a
t
i
v
o
1
0
.
2
.
1
:

b
l
o
c
c
a
(

)
1
0
.
2
.
2
:

s
c
r
i
v
i
(

)
1
0
.
2
.
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
1
0
.
2
.
4
:

b
l
o
c
c
o

e
s
e
g
u
i
t
o
1
0
.
2
.
5
:

n
o
t
i
f
i
c
a

b
l
o
c
c
o

u
t
e
n
t
e
1
0
.
3
:

P
a
s
s
w
o
r
d

c
o
r
r
e
t
t
a
1
0
.
3
.
1
:

c
o
n
t
r
o
l
l
o
B
l
o
c
c
o
(

)
1
0
.
3
.
2
:

l
e
g
g
i
(

)
1
0
.
3
.
3
:

c
a
r
i
c
a

d
a
t
i
1
0
.
3
.
3
.
1
:

e
r
r
:

U
t
e
n
t
e

b
l
o
c
c
a
t
o
1
0
.
3
.
3
.
1
.
1
:

u
t
e
n
t
e

b
l
o
c
c
a
t
o

:

i
m
p
e
d
i
t
o

l
'
a
c
c
e
s
s
o
1
1
:

i
n
s
e
r
i
s
c
i
(

)
1
2
:

i
n
s
e
r
i
s
c
i
(

)
1
3
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
4
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
0
.
3
.
3
.
2
:

l
o
g
i
n

c
o
n
s
e
n
t
i
t
o
1
0
.
3
.
3
.
2
.
1
:

c
r
e
a
t
e
1
5
:

d
e
s
t
r
o
y
1
0
.
3
.
3
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

m
e
n
u

U
t
e
n
t
e
1
6
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
7
:

d
e
s
t
r
o
y
1
0
.
4
:

e
r
r
:

U
t
e
n
t
e

g
i

l
o
g
g
a
t
o
1
0
.
4
.
1
:

n
o
t
i
f
i
c
a

U
t
e
n
t
e

g
i

l
o
g
g
a
t
o
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

L
o
g
i
n
:
U
t
e
n
t
e
U
t
e
n
t
e
D
B
:
A
c
c
e
s
s
o
U
t
e
n
t
e
A
c
c
e
s
s
o
D
B
I
n
t
e
r
f
a
c
c
i
a

M
e
n
u

U
t
e
n
t
e
L
o

c
r
e
o

s
o
l
o

i
n

c
a
s
o

d
i

s
c
e
n
a
r
i
o

"
U
s
e
r
n
a
m
e

c
o
r
r
e
t
t
a

-

1

t
e
n
t
a
t
i
v
o
"
.

S
e

s
o
n
o

a
l

2

t
e
n
t
a
t
i
v
o
,

g
i

l
'
h
o

c
r
e
a
t
o

a

q
u
e
l
l
o

p
r
e
c
e
d
e
n
t
e
.
S
e
q
u
e
n
z
a

a
z
i
o
n
i

c
o
m
u
n
i

a

t
u
t
t
i

g
l
i

s
c
e
n
a
r
i
,

p
e
r

l
'
a
g
g
i
o
r
n
a
m
e
n
t
o

d
e
l
l
e

i
n
f
o
r
m
a
z
i
o
n
i

d
i

a
c
c
e
s
s
o
S
c
e
n
a
r
i
o

2

:

U
s
e
r
n
a
m
e

c
o
r
r
e
t
t
a
S
c
e
n
a
r
i
o

1

:

U
s
e
r
n
a
m
e

e
r
r
a
t
a
185
_________________________________________________________________

Figura 13 - Sequence Diagram Login Amministratore
1
:

r
i
c
h
i
e
s
t
a

d
i

l
o
g
i
n
2
:

c
r
e
a
t
e
3
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

U
s
e
r
n
a
m
e

e

P
a
s
s
w
o
r
d
4
:

i
n
s
e
r
i
m
e
n
t
o

U
s
e
r
n
a
m
e

e

P
a
s
s
w
o
r
d
5
:

e
s
e
g
u
i

l
o
g
i
n
6
:

c
r
e
a
t
e
7
:

l
o
g
i
n
(

)
8
:

l
e
g
g
i
(

)
9
:

c
a
r
i
c
a

d
a
t
i
9
.
1
:

e
r
r
:

U
s
e
r
n
a
m
e

e
r
r
a
t
a
9
.
1
.
1
:

s
e
g
n
a
l
a
z
i
o
n
e

e
r
r
o
r
e
9
.
2
.
1
:

c
r
e
a
t
e
9
.
2
.
1
.
1
:

i
n
i
z
i
a
l
i
z
z
a
z
i
o
n
e

e
s
e
g
u
i
t
a
1
0
.
1
.
1
:

s
e
g
n
a
l
a
z
i
o
n
e

e
r
r
o
r
e
1
0
.
2
.
1
:

b
l
o
c
c
a
(

)
1
0
.
2
.
2
:

s
c
r
i
v
i
(

)
1
0
.
2
.
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
1
0
.
2
.
4
:

b
l
o
c
c
o

e
s
e
g
u
i
t
o
1
0
.
2
.
5
:

n
o
t
i
f
i
c
a

b
l
o
c
c
o

a
m
m
i
n
i
s
t
r
a
t
o
r
e
1
0
.
3
:

P
a
s
s
w
o
r
d

c
o
r
r
e
t
t
a
1
0
.
3
.
1
:

c
o
n
t
r
o
l
l
o
B
l
o
c
c
o
(

)
1
0
.
3
.
2
:

l
e
g
g
i
(

)
1
0
.
3
.
3
:

c
a
r
i
c
a

d
a
t
i
1
0
.
3
.
3
.
1
:

e
r
r
:

A
m
m
i
n
i
s
t
r
a
t
o
r
e

b
l
o
c
c
a
t
o
1
0
.
3
.
3
.
1
.
1
:

b
l
o
c
c
a
t
o

:

i
m
p
e
d
i
t
o

l
'
a
c
c
e
s
s
o
1
0
.
3
.
3
.
2
:

l
o
g
i
n

c
o
n
s
e
n
t
i
t
o
1
0
.
3
.
3
.
2
.
1
:

c
r
e
a
t
e
1
0
.
3
.
3
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

m
e
n
u

A
m
m
i
n
i
s
t
r
a
t
o
r
e
1
1
:

i
n
s
e
r
i
s
c
i
(

)
1
4
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
5
:

d
e
s
t
r
o
y
1
6
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
7
:

d
e
s
t
r
o
y
1
0
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

e
r
r
a
t
a

a
l

1

t
e
n
t
a
t
i
v
o
1
0
.
2
:

e
r
r
:

P
a
s
s
w
o
r
d

e
r
r
a
t
a

a
l

2

t
e
n
t
a
t
i
v
o
1
2
:

i
n
s
e
r
i
s
c
i
(

)
1
3
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
0
.
4
:

e
r
r
:

A
m
m
i
n
i
s
t
r
a
t
o
r
e

g
i

l
o
g
g
a
t
o
1
0
.
4
.
1
:

n
o
t
i
f
i
c
a

A
m
m
i
n
i
s
t
r
a
t
o
r
e

g
i

l
o
g
g
a
t
o
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

L
o
g
i
n
:
A
m
m
i
n
i
s
t
r
a
t
o
r
e
A
m
m
i
n
i
s
t
r
a
t
o
r
e
D
B
:
A
c
c
e
s
s
o
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

M
e
n
u

A
m
m
i
n
i
s
t
r
a
t
o
r
e
A
c
c
e
s
s
o
D
B
L
o

c
r
e
o

s
o
l
o

i
n

c
a
s
o

d
i

s
c
e
n
a
r
i
o

"
U
s
e
r
n
a
m
e

c
o
r
r
e
t
t
a

-

1

t
e
n
t
a
t
i
v
o
"
.

S
e

s
o
n
o

a
l

2

t
e
n
t
a
t
i
v
o
,

g
i

l
'
h
o

c
r
e
a
t
o

a

q
u
e
l
l
o

p
r
e
c
e
d
e
n
t
e
.
S
e
q
u
e
n
z
a

a
z
i
o
n
i

c
o
m
u
n
i

a

t
u
t
t
i

g
l
i

s
c
e
n
a
r
i
,

p
e
r

l
'
a
g
g
i
o
r
n
a
m
e
n
t
o

d
e
l
l
e

i
n
f
o
r
m
a
z
i
o
n
i

d
i

a
c
c
e
s
s
o
S
c
e
n
a
r
i
o

2

:

U
s
e
r
n
a
m
e

c
o
r
r
e
t
t
a
S
c
e
n
a
r
i
o

1

:

U
s
e
r
n
a
m
e

e
r
r
a
t
a
186
_________________________________________________________________
3.3.2 Logout

Anche la funzionalit Logout prevede le medesime azioni per lutente e
lamministratore, a meno degli oggetti che vengono utilizzati per le operazioni
necessarie.
Utente Sistema
Richiesta di Logout
:AccessoUtente
[aggiornato]
Inserisce data ed ora di logout
Registrazione informazioni di logout

Figura 14 - Activity Diagram Logout Utente
Richiesta di Logout
[aggiornato]
Inserisce data ed ora di logout
Registrazione informazioni di logout

Figura 15 - Activity Diagram Logout Amministratore
187
_________________________________________________________________

1: richiesta di logout
2: logout( )
3: aggiorna( )
4: modifica( )
5: aggiornamento eseguito
10: notifica logout
12: visualizzazione home
7: destroy
11: destroy
8: modifica()
Utente
Interfaccia Home :Utente :AccessoUtente AccessoDB UtenteDB

Figura 16 - Sequence Diagram Logout Utente

1: richiesta di logout
2: logout( )
3: aggiorna( )
7: destroy
10: notifica logout
11: destroy
12: visualizzazione home
4: modifica( )
8: modifica()
Amministratore
Interfaccia Home :Amministratore :AccessoAmministratore AccessoDB AmministratoreDB

Figura 17 - Sequence Diagram Logout Amministratore

188
_________________________________________________________________
3.3.3 Registrazione

Per quanto riguarda la registrazione dellutente, per poter usufruire dei
servizi della Web application, ne sono previste due tipologie : la versione base ed
estesa, che differiscono dal fatto che questultima fornisce in pi la possibilit di
acquisto e download dei brani MP3.
La registrazione di base prevede limmissione da parte dellutente, soltanto dei dati di
accesso, Username e Password, oltre che dellindirizzo email. In questo modo, si ha
la possibilit di usufruire dei servizi in maniera del tutto gratuita, con la limitazione di
poter esclusivamente ascoltare i brani in streaming, senza la possibilit di download.
Lutente ha poi la possibilit di decidere se voler usufruire della funzionalit di
acquisto e download dei brani, nel qual caso deve immettere anche i dati anagrafici.
Oltre a questi ultimi, sono necessarie le informazioni relative alla scheda prepagata da
acquistare e della carta di credito da utilizzare per il pagamento, della quale il sistema
esegue loperazione di verifica della copertura.
Ovviamente, sono previste tutte le operazioni di validazione dei dati, necessarie a
garantire che i dati immessi dallutente rispettino i formati attesi dallapplicazione.
Al termine della registrazione, viene eseguito il login automatico al sistema,
visualizzando allutente le voci di men relative alle funzionalit abilitate.
Per quanto riguarda il Sequence Diagram, si evidenziano i due possibili scenari
relativi alla registrazione base ed estesa, oltre alla funzionalit di login
automatico, che non prevede tutti i controlli tipici di questa operazione, trattandosi di
un nuovo utente. Il diagramma, inoltre, ha un riferimento al Sequence Diagram che
riguarda lacquisto della scheda prepagata, in quanto questa operazione pu essere
eseguita dallutente anche in un secondo momento e non necessariamente in fase di
registrazione. Per questo motivo prevista una funzionalit a parte con gli Activity e
Sequence Diagrams corrispondenti.

189
_________________________________________________________________

Utente Sistema
Inserimento dati Anagrafici
Inserimento dati Carta di Credito ed Importo Scheda
:Utente
[creato]
[Prevede acquisto/download
di brani MP3]
:CartaCredito
[creato]
[Carta di Credito scoperta]
:SchedaPrepagata
[acquistata]
[Carta di Credito coperta]
Login Automatico
[Non prevede acquisto/download di brani MP3]
:AccessoUtente
[creato]
:Utente
[registrato]
Registrazione Acquisto
Registrazione dati Anagrafici
Controllo correttezza dati
[Dati corretti]
[Dati non corretti]
Controllo correttezza dati carta

Figura 18 - Activity Diagram Registrazione

190
_________________________________________________________________

Figura 19 - Sequence Diagram Registrazione

1
:

r
i
c
h
i
e
s
t
a

d
i

r
e
g
i
s
t
r
a
z
i
o
n
e
2
:

c
r
e
a
t
e
3
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i
4
:

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i
5
:

e
s
e
g
u
i

r
e
g
i
s
t
r
a
z
i
o
n
e
6
:

c
o
n
t
r
o
l
l
o

c
o
r
r
e
t
t
e
z
z
a

d
a
t
i
6
.
1
:

e
r
r
:

d
a
t
i

n
o
n

c
o
r
r
e
t
t
i
6
.
2
.
1
.
1
:

c
r
e
a
t
e
6
.
2
.
1
.
2
:

e
s
e
g
u
i

a
c
q
u
i
s
t
o

s
c
h
e
d
a
6
.
2
.
1
.
3
:

n
o
t
i
f
i
c
a

a
c
q
u
i
s
t
o

e
s
e
g
u
i
t
o
6
.
2
.
1
.
4
:

d
e
s
t
r
o
y
6
.
2
:

c
r
e
a
t
e
7
:

r
e
g
i
s
t
r
a
z
i
o
n
e
(

)
8
:

i
n
s
e
r
i
s
c
i
(

)
9
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
0
:

r
e
g
i
s
t
r
a
z
i
o
n
e

e
s
e
g
u
i
t
a
1
1
:

n
o
t
i
f
i
c
a

r
e
g
i
s
t
r
a
z
i
o
n
e

e
s
e
g
u
i
t
a
1
2
:

c
r
e
a
t
e
1
3
:

i
n
s
e
r
i
s
c
i
(

)
1
4
:

i
n
s
e
r
i
s
c
i
(

)
1
5
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
6
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
7
:

d
e
s
t
r
o
y
1
8
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
1
9
:

d
e
s
t
r
o
y
2
0
:

c
r
e
a
t
e
2
1
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

m
e
n
u

U
t
e
n
t
e
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

R
e
g
i
s
t
r
a
z
i
o
n
e
:
U
t
e
n
t
e
U
t
e
n
t
e
D
B
I
n
t
e
r
f
a
c
c
i
a

A
c
q
u
i
s
t
o
R
i
c
a
r
i
c
a

S
c
h
e
d
a
S
c
e
n
a
r
i
o

:

l
'U
t
e
n
t
e

p
r
e
v
e
d
e

d
i

a
c
q
u
i
s
t
a
r
e

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

A
c
q
u
i
s
t
o

S
c
h
e
d
a

P
r
e
p
a
g
a
t
a
:
A
c
c
e
s
s
o
U
t
e
n
t
e
A
c
c
e
s
s
o
D
B
I
n
t
e
r
f
a
c
c
i
a

M
e
n
u

U
t
e
n
t
e
E
s
e
c
u
z
i
o
n
e

d
e
l

L
o
g
i
n

i
n

a
u
t
o
m
a
t
i
c
o
191
_________________________________________________________________
3.3.4 Richiesta Username / Password

Nel caso in cui un utente registrato abbia perso oppure dimenticato le
informazioni relative allaccesso, possibile utilizzare la funzionalit del sistema che
permette di inviare una mail contenente tali informazioni.
Lutente deve semplicemente fornire al sistema lindirizzo email con cui ha effettuato
la registrazione, dopodich il sistema stesso eseguo il controllo di correttezza del
formato dellindirizzo e verifica che questultimo sia correttamente registrato. In caso
di esito positivo, lutente ricever una mail con tutte le informazioni richieste.

Utente Sistema
Inserimento indirizzo Email
:Utente
[letto]
[Indirizzo email non presente in archivio]
Invio Email con Username e Password
[Indirizzo email presente in archivio]
Controllo indirizzo Email
[Dati corretti]
[Dati non corretti]

Figura 20 - Activity Diagram Richiesta Username/Password

192
_________________________________________________________________

1: richiesta Username e Password
2: create
3: richiesta inserimento email
4: inserimento email
5: esegui richiesta
6: controllo formato email
6.1: err: formato email non valido
6.2.1: create
6.2.2: richiediUserNamePassword( )
6.2.3: leggi( )
6.2.4: carica dati
6.2.4.1.1: utente non registrato
6.2.4.1.2: err: indirizzo email non presente in archivio
6.2.4.2.2: invio email eseguito
6.2.4.2.3: notifica invio mail
6.2.4.2.1: invio mail
6.2.5: destroy
Utente
Interfaccia Richiesta Username/Password
Interfaccia Home
:Utente
UtenteDB

Figura 21 - Sequence Diagram Richiesta Username/Password

3.3.5 Acquisto, Ricarica e Visualizzazione Info Scheda Prepagata

Lacquisto di una scheda prepagata si rende necessario nel momento in cui
lutente abbia intenzione di acquistare e scaricare brani MP3. Loperazione di
acquisto pu essere eseguita in fase di registrazione oppure in un secondo momento,
quando lutente ha gi effettuato in passato la registrazione base.
Le informazioni necessarie al sistema per svolgere la funzionalit sono relative
allimporto della scheda ed alla carta di credito, mediante la quale eseguire il
pagamento. Una volta verificata ed accertata la copertura di questultima, viene
completato lacquisto della scheda.

193
_________________________________________________________________
Utente Sistema
Inserimento dati Carta di Credito ed Importo Scheda
:CartaCredito
[creato]
:SchedaPrepagata
[acquistata]
Registrazione Acquisto
[Dati non corretti]
[Dati corretti]

Figura 22 - Activity Diagram Acquisto scheda prepagata

194
_________________________________________________________________
1: richiesta inserimento dati
2: inserimento dati
3: esegui acquisto scheda
4: controllo correttezza dati
4.1: err: dati non corretti
4.2.1: create
4.2.2: verificaCopertura( )
4.2.2.1.1: err: carta di credito scoperta
4.2.2.1.2: err: carta di credito scoperta
4.2.2.2.1: carta di credito coperta
4.2.2.2.2: destroy
4.2.2.2.3: create
4.2.2.2.4: acquista( )
4.2.2.2.5: inserisci( )
4.2.2.2.6: acquisto eseguito
4.2.2.2.7: acquisto eseguito
4.2.2.2.8: destroy
4.2.2.2.9: notifica acquisto eseguito
Utente
Interfaccia AcquistoRicarica Scheda
:CartaCredito
:SchedaPrepagata
SchedaPrepagataDB

Figura 23 - Sequence Diagram Acquisto scheda prepagata

La scheda prepagata viene utilizzata per lacquisto ed il download dei brani MP3
disponibili nellarchivio, per cui limporto residuo destinato a diminuire nel tempo.
Il sistema fornisce una funzionalit di ricarica, mediante la quale lutente ha la
possibilit di ricaricare la scheda aumentandone limporto.
Loperazione di ricarica del tutto simile a quella di acquisto, nel senso che le
informazioni necessarie riguardano limporto della ricarica e la carta di credito
necessaria al pagamento. Una volta eseguiti i dovuti controlli di copertura di
questultima, la ricarica viene eseguita e registrata dal sistema ed inoltre, viene
aggiornato limporto residuo della scheda, nonch prolungata la data di scadenza.

195
_________________________________________________________________

Utente Sistema
Inserimento Dati Carta di Credito ed Importo Ricarica
:CartaCredito
[creato]
Esecuzione Ricarica
:SchedaPrepagata
[ricaricata]
:Ricarica
[eseguita]
Aggiornamento importo,
scadenza e data/ora
[Dati corretti]
[Dati non corretti]

Figura 24 - Activity Diagram Ricarica scheda prepagata

196
_________________________________________________________________

Figura 25 - Sequence Diagram Ricarica scheda prepagata
1
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i
2
:

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i
3
:

e
s
e
g
u
i

r
i
c
a
r
i
c
a

s
c
h
e
d
a
4
:

c
o
n
t
r
o
l
l
o

c
o
r
r
e
t
t
e
z
z
a

d
a
t
i
4
.
1
:

e
r
r
:

d
a
t
i

n
o
n

c
o
r
r
e
t
t
i
4
.
2
.
1
:

c
r
e
a
t
e
4
.
2
.
2
:

v
e
r
i
f
i
c
a
C
o
p
e
r
t
u
r
a
(

)
4
.
2
.
2
.
1
.
1
:

e
r
r
:

c
a
r
t
a

d
i

c
r
e
d
i
t
o

s
c
o
p
e
r
t
a
4
.
2
.
2
.
1
.
2
:

e
r
r
:

c
a
r
t
a

d
i

c
r
e
d
i
t
o

s
c
o
p
e
r
t
a
4
.
2
.
2
.
2
.
1
:

c
a
r
t
a

d
i

c
r
e
d
i
t
o

c
o
p
e
r
t
a
4
.
2
.
2
.
2
.
2
:

d
e
s
t
r
o
y
4
.
2
.
2
.
2
.
3
:

c
r
e
a
t
e
4
.
2
.
2
.
2
.
4
:

r
i
c
a
r
i
c
a
(

)
4
.
2
.
2
.
2
.
5
:

c
r
e
a
t
e
4
.
2
.
2
.
2
.
7
:

i
n
s
e
r
i
s
c
i
(

)
4
.
2
.
2
.
2
.
8
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
4
.
2
.
2
.
2
.
6
:

e
s
e
g
u
i
(

)
4
.
2
.
2
.
2
.
9
:

r
i
c
a
r
i
c
a

e
s
e
g
u
i
t
a
4
.
2
.
2
.
2
.
1
2
:

m
o
d
i
f
i
c
a
(

)
4
.
2
.
2
.
2
.
1
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

i
m
p
o
r
t
o

r
e
s
i
d
u
o

e
s
e
g
u
i
t
o
4
.
2
.
2
.
2
.
1
4
:

r
i
c
a
r
i
c
a

e
s
e
g
u
i
t
a
4
.
2
.
2
.
2
.
1
0
:

d
e
s
t
r
o
y
4
.
2
.
2
.
2
.
1
5
:

d
e
s
t
r
o
y
4
.
2
.
2
.
2
.
1
6
:

n
o
t
i
f
i
c
a

r
i
c
a
r
i
c
a

e
s
e
g
u
i
t
a
4
.
2
.
2
.
2
.
1
1
:

a
g
g
i
o
r
n
a
I
m
p
o
r
t
o
R
e
s
i
d
u
o
(

)
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

A
c
q
u
i
s
t
o
R
i
c
a
r
i
c
a

S
c
h
e
d
a
:
C
a
r
t
a
C
r
e
d
i
t
o
:
S
c
h
e
d
a
P
r
e
p
a
g
a
t
a
:
R
i
c
a
r
i
c
a
R
i
c
a
r
i
c
a
D
B
S
c
h
e
d
a
P
r
e
p
a
g
a
t
a
D
B
197
_________________________________________________________________
Lapplicazione prevede di visualizzare tra le voci di menu, le informazioni relative ad
un eventuale scheda prepagata acquistata dallutente, senza che questultimo attivi
una particolare funzionalit del sistema.
Tali informazioni riguardano limporto residuo e la data di scadenza ed un eventuale
messaggio di avvertimento per lutente, qualora la scheda sia scaduta.

Utente Sistema
Richiesta visualizzazione informazioni Caricamento dati
:SchedaPrepagata
[letto]
Visualizzazione informazioni Scheda

Figura 26 - Activity Diagram Visualizzazione info scheda prepagata

1: richiesta informazioni scheda
2: create
3: create
4: visualizzaInfo( )
5: leggi( )
6: carica dati
8: informazioni scheda
9: destroy
10: visualizzazione informazioni scheda
7: controlloScadenza( )
Utente
Interfaccia Home
Interfaccia Info Scheda
:SchedaPrepagata
SchedaPrepagataDB

Figura 27 - Sequence Diagram Visualizzazione info scheda prepagata
198
_________________________________________________________________
3.3.6 Visualizzazione e Ricerca Brani

Per poter accedere allarchivio dei brani e visualizzarne il contenuto, il
sistema mette a disposizioni due modalit :

- visualizzazione dei brani sulla base di un genere musicale;
- ricerca dei brani sulla base dei criteri impostati relativi al titolo, autore, album
e genere musicale;

Gli Activity Diagrams che descrivono queste funzionalit sono due, in quanto fanno
riferimento alla richiesta da parte dellutilizzatore ed alle operazioni eseguite dal
sistema. Si preferita una scomposizione in questi termini, poich tali diagrammi
diventano componenti dei diagrammi che descrivono funzionalit pi complesse che
prevedono la visualizzazione dei brani. In questo modo si riesce a modellare il
sistema mediante livelli di astrazione successivi. Il Sequence Diagram, invece,
evidenzia i due possibili scenari sulla base dei quali lutilizzatore pu richiedere la
visualizzazione dei brani presenti allinterno dellarchivio.

199
_________________________________________________________________
Selezione modalit visualizzazione brani MP3
Richiesta visualizzazione brani MP3 per genere
Richiesta ricerca Brano
Inserimento criteri di ricerca

Figura 28 - Activity Diagram Richiesta Visualizzazione e ricerca brani MP3

Ricerca brani MP3 Caricamento elenco brani MP3
[Richiesta
ricerca]
[Richiesta visualizzazione per
genere]
:BranoMP3
[letto]

Figura 29 - Activity Diagram Visualizzazione e ricerca brani MP3

200
_________________________________________________________________

Figura 30 - Sequence Diagram Visualizzazione e ricerca Brani MP3

1
.
1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i

p
e
r

g
e
n
e
r
e
1
.
1
.
1
:

s
e
l
e
z
i
o
n
e

g
e
n
e
r
e
1
.
1
.
2
:

e
s
e
g
u
i

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e
1
.
1
.
3
:

c
r
e
a
t
e
1
.
1
.
4
:

c
r
e
a
t
e
1
.
1
.
5
:

v
i
s
u
a
l
i
z
z
a
E
l
e
n
c
o
B
r
a
n
i
M
P
3
(

)
1
.
1
.
6
:

l
e
g
g
i
(

)
1
.
1
.
7
:

c
a
r
i
c
a

d
a
t
i
1
.
1
.
7
.
1
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
1
.
1
.
7
.
1
.
2
:

n
o
t
i
f
i
c
a

a
s
s
e
n
z
a

b
r
a
n
i

p
e
r

i
l

g
e
n
e
r
e

s
e
l
e
z
i
o
n
a
t
o
1
.
1
.
7
.
2
.
1
:

b
r
a
n
i

c
a
r
i
c
a
t
i
1
.
1
.
7
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

d
e
l

g
e
n
e
r
e

s
e
l
e
z
i
o
n
a
t
o
1
.
2
:

r
i
c
h
i
e
s
t
a

r
i
c
e
r
c
a

b
r
a
n
i

M
P
3
1
.
2
.
1
:

c
r
e
a
t
e
1
.
2
.
2
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

c
r
i
t
e
r
i

d
i

r
i
c
e
r
c
a
1
.
2
.
3
:

i
n
s
e
r
i
m
e
n
t
o

c
r
i
t
e
r
i

d
i

r
i
c
e
r
c
a
1
.
2
.
4
:

e
s
e
g
u
i

r
i
c
e
r
c
a
1
.
2
.
5
:

c
r
e
a
t
e
1
.
2
.
6
:

r
i
c
e
r
c
a
(

)
1
.
2
.
7
:

l
e
g
g
i
(

)
1
.
2
.
8
:

c
a
r
i
c
a

d
a
t
i
1
.
2
.
8
.
1
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
1
.
2
.
8
.
1
.
2
:

n
o
t
i
f
i
c
a

a
s
s
e
n
z
a

b
r
a
n
i

p
e
r

i

c
r
i
t
e
r
i

d
i

r
i
c
e
r
c
a

i
m
p
o
s
t
a
t
i
1
.
2
.
8
.
2
.
1
:

b
r
a
n
i

c
a
r
i
c
a
t
i
1
.
2
.
8
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
i

b
r
a
n
i

r
e
l
a
t
i
v
i

a
i

c
r
i
t
e
r
i

d
i

r
i
c
e
r
c
a

i
m
p
o
s
t
a
t
i
1
.
1
.
8
:

d
e
s
t
r
o
y
1
.
2
.
9
:

d
e
s
t
r
o
y
U
t
e
n
t
e
/
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
:
B
r
a
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
I
n
t
e
r
f
a
c
c
i
a

R
i
c
e
r
c
a

M
P
3
S
c
e
n
a
r
i
o

2

:

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

s
u
l
l
a

b
a
s
e

d
i

u
n
a

r
i
c
e
r
c
a

p
e
r
s
o
n
a
l
i
z
z
a
t
a
S
c
e
n
a
r
i
o

1

:

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

p
e
r

g
e
n
e
r
e
201
_________________________________________________________________
3.3.7 Inserimento, Modifica ed Eliminazione Brano dallArchivio

Nellambito della gestione dellarchivio dei brani, lamministratore ha
ovviamente la possibilit di inserire un nuovo brano MP3. Le informazioni richieste
dal sistema riguardano il titolo, lautore, lalbum, il genere musicale, la durata oltre al
costo, necessario per lacquisto del brano, ed al file MP3 che bisogna caricare sul
server.
Le informazioni suddette non sono tutte strettamente necessarie, se non il genere ed
il costo. La durata pu anche non essere impostata, cos come le informazioni
caratteristiche del brano. Una scelta di questo tipo potrebbe portare a pensare ad un
grave errore di progettazione, permettendo il caricamento di brani senza specificarne
il titolo, lautore e lalbum di appartenenza.
In realt, il sistema prevede un meccanismo di accesso ai cosiddetti tag ID3v1,
caratteristici dei file in formato MP3 (MPLEG Layer 3), che contengono tutte le
informazioni caratteristiche del brano, tra cui appunto il titolo, lautore e lalbum. In
questo modo, si da allamministratore la possibilit di non specificare tali
informazioni in fase di inserimento, se queste ultime possono essere ricavate dai tag
stessi. Nel caso in cui anche questi siano vuoti, si segnala allutente che le
informazioni sono necessarie. E ovvio che viene garantita sempre la coerenza tra le
informazioni del brano inserite nellarchivio ed i tag del file MP3 corrispondente, per
cui se le informazioni del brano sono specificate dallamministratore, il sistema
provvede ad aggiornarne i valori nei corrispondenti tag. Questo meccanismo
permette di risparmiare una grande quantit di tempo, se si dispone di un gruppo di
brani, le cui informazioni principali sono gi specificate attraverso i tag ID3v1.
Il Sequence Diagram evidenzia le possibili situazioni di caricamento del singolo
brano, attraverso due scenari distinti.

202
_________________________________________________________________

Inserimento informazioni brano e file MP3
Controllo informazioni brano MP3 e upload file
Ricava informazioni dai tag MP3 Scrivi informazioni nei tag MP3
Registrazione dati in archivio
:FileMP3
[upload]
:FileMP3
[aggiornato] :FileMP3
[letto]
[Informazioni brano inserite]
[Informazioni brano non inserite]
:BranoMP3
[creato]
[Dati corretti]
[Dati non corretti]

Figura 31 - Activity Diagram Inserimento brano MP3 in archivio

203
_________________________________________________________________

Figura 32 - Sequence Diagram Inserimento brano MP3 in archivio

1
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

b
r
a
n
o

M
P
3
2
:

c
r
e
a
t
e
3
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

i
n
f
o
r
m
a
z
i
o
n
i

e

s
e
l
e
z
i
o
n
e

b
r
a
n
o
4
:

i
n
s
e
r
i
m
e
n
t
o

i
n
f
o
r
m
a
z
i
o
n
i

e

s
e
l
e
z
i
o
n
e

b
r
a
n
o

d
a

c
a
r
i
c
a
r
e
5
:

e
s
e
g
u
i

i
n
s
e
r
i
m
e
n
t
o

b
r
a
n
o
6
:

c
o
n
t
r
o
l
l
o

c
o
r
r
e
t
t
e
z
z
a

d
a
t
i
6
.
1
:

e
r
r
:

d
a
t
i

n
o
n

v
a
l
i
d
i
6
.
2
.
1
:

c
r
e
a
t
e
6
.
2
.
2
:

u
p
l
o
a
d
(

)
6
.
2
.
3
:

t
e
r
m
i
n
e

u
p
l
o
a
d
6
.
2
.
4
:

v
e
r
i
f
i
c
a

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
6
.
2
.
4
.
1
.
1
:

l
e
g
g
i
T
a
g
(

)
6
.
2
.
4
.
1
.
2
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o

r
i
c
a
v
a
t
e

d
a
i

t
a
g

M
P
3
6
.
2
.
4
.
2
.
1
:

a
g
g
i
o
r
n
a
T
a
g
(

)
6
.
2
.
4
.
2
.
2
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o

s
c
r
i
t
t
e

n
e
i

t
a
g

M
P
3
6
.
2
.
5
:

d
e
s
t
r
o
y
6
.
2
.
6
:

c
r
e
a
t
e
6
.
2
.
7
:

i
n
s
e
r
i
s
c
i
(

)
6
.
2
.
8
:

i
n
s
e
r
i
s
c
i
(

)
6
.
2
.
9
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
6
.
2
.
1
0
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
6
.
2
.
1
1
:

n
o
t
i
f
i
c
a

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

I
n
s
e
r
i
m
e
n
t
o

B
r
a
n
o

M
P
3
:
F
i
l
e
M
P
3
I
n

b
a
s
e

a
l

f
a
t
t
o

c
h
e

l
'
A
m
m
i
n
i
s
t
r
a
t
o
r
e

a
b
b
i
a

i
n
s
e
r
i
t
o

o

m
e
n
o

l
e

i
n
f
o
r
m
a
z
i
o
n
i

d
e
l

b
r
a
n
o
,

q
u
e
s
t
e

v
e
n
g
o
n
o

s
c
r
i
t
t
e

o

r
i
c
a
v
a
t
e

n
e
i
/
d
a
i

t
a
g

M
P
3
:
B
r
a
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
204
_________________________________________________________________
Una volta che un brano stato inserito, ovviamente disponibile una funzionalit
mediante la quale lamministratore pu visualizzare e modificare le informazioni dello
stesso. Cos come per linserimento, viene sempre garantita la coerenza tra le
informazioni memorizzate nella base di dati ed i tag ID3v1 del file MP3, i quali
vengono aggiornati nel caso in cui lamministratore decidesse di modificare il titolo,
lautore e lalbum.
La visualizzazione dei dati prevede un Activity Diagram che diventa componente in
quello di modifica, considerando che la funzionalit di visualizzazione utilizzata in
molteplici situazioni.

Caricamento dati brano MP3
:BranoMP3
[letto]
Visualizzazione dati MP3

Figura 33 - Activity Diagram Visualizzazione info brano MP3

Inoltre, lActivity Diagram relativo alla funzionalit di modifica sfrutta i diagrammi di
visualizzazione e ricerca dei brani, tra i quali selezionare il brano di cui modificarne le
informazioni.

205
_________________________________________________________________

Richiesta visualizzazione brani MP3per gene
Richiesta ricerca Bran
Richiesta visualizzazione brani MP3
Ricercabrani MP3 Caricamentoelencobrani MP3
[Richiesta
ricerca]
[Richiestavisualizzazioneper
genere]
Visualizzazionebrani MP3
:BranoMP3
[letto]
Visualizzazione elenco brani MP3
[Assenza brani]
[Presenza brani]
Selezione brano MP3
:BranoMP3
[letto]
Visualizzazione dati brano MP3
Inserimento nuovi dati
Registrazione nuovi dati
:BranoMP3
[aggiornato]
[Dati corretti]
[Dati non corretti]
:FileMP3
[aggiornato]

Figura 34 - Activity Diagram Modifica brano MP3

206
_________________________________________________________________

Figura 35 - Sequence Diagram Modifica brano MP3

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i
2
:

c
r
e
a
t
e
2
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i
2
.
2
.
1
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o

d
a

m
o
d
i
f
i
c
a
r
e
2
.
2
.
2
:

c
r
e
a
t
e
2
.
2
.
3
:

c
r
e
a
t
e
2
.
2
.
4
:

v
i
s
u
a
l
i
z
z
a
I
n
f
o
(

)
2
.
2
.
5
:

l
e
g
g
i
(

)
2
.
2
.
6
:

c
a
r
i
c
a

d
a
t
i
2
.
2
.
7
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
8
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
9
:

i
n
s
e
r
i
m
e
n
t
o

n
u
o
v
e

i
n
f
o
r
m
a
z
i
o
n
i

d
e
l

b
r
a
n
o
2
.
2
.
1
0
:

e
s
e
g
u
i

a
g
g
i
o
r
n
a
m
e
n
t
o

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
1
1
:

c
o
n
t
r
o
l
l
o

c
o
r
r
e
t
t
e
z
z
a

d
a
t
i
2
.
2
.
1
1
.
1
:

e
r
r
:

d
a
t
i

n
o
n

v
a
l
i
d
i
2
.
2
.
1
1
.
2
.
1
:

m
o
d
i
f
i
c
a
I
n
f
o
(

)
2
.
2
.
1
1
.
2
.
2
:

m
o
d
i
f
i
c
a
(

)
2
.
2
.
1
1
.
2
.
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
1
1
.
2
.
4
:

c
r
e
a
t
e
2
.
2
.
1
1
.
2
.
5
:

a
g
g
i
o
r
n
a
T
a
g
(

)
2
.
2
.
1
1
.
2
.
6
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
1
1
.
2
.
7
:

d
e
s
t
r
o
y
2
.
2
.
1
1
.
2
.
8
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
1
1
.
2
.
9
:

d
e
s
t
r
o
y
2
.
2
.
1
1
.
2
.
1
0
:

n
o
t
i
f
i
c
a

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

p
e
r

G
e
n
e
r
e

o

R
i
c
e
r
c
a

p
e
r
s
o
n
a
l
i
z
z
a
t
a
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
I
n
t
e
r
f
a
c
c
i
a

I
n
f
o

B
r
a
n
o

M
P
3
:
B
r
a
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
:
F
i
l
e
M
P
3
207
_________________________________________________________________
Lultima funzionalit fondamentale per la gestione dellarchivio permette
leliminazione di un brano MP3. Tale operazione prevista secondo due possibili
modalit :

- eliminazione di uno o pi brani selezionandoli dallelenco attualmente
visualizzato;
- eliminazione di un singolo brano nellinterfaccia di visualizzazione delle
informazioni dello stesso;

Tali modalit sono descritte attraverso i due corrispondenti scenari allinterno del
Sequence Diagram
Nel momento in cui lamministratore richiede leliminazione di uno o pi brani, per
garantire la coerenza delle informazioni in archivio e dei file MP3 presenti nel file
system del server, il sistema esegue le seguenti attivit su ciascun di essi :

- cancella le informazioni del brano dalla base di dati;
- elimina il file MP3 ad esso associato;
- aggiorna le informazioni di composizione delle playlist degli utenti;

Lultima operazione non strettamente legata allazione di cancellazione del brano,
ma serve ad evitare che allinterno delle playlist degli utenti rimanga un riferimento ad
un brano non pi presente in archivio e per il quale non disponibile il file MP3 da
ascoltare.

208
_________________________________________________________________

[Richiesta
ricerca]
genere]
:BranoMP3
[letto]
[Assenza brani]
[Presenza brani]
Selezione brano MP3
:BranoMP3
[letto]
Richiesta cancellazione brano/i MP3
Cancellazione brano MP3
:BranoMP3
[cancellato]
Selezione dei brani MP3 da cancellare
:FileMP3
[cancellato]
:Playlist
[aggiornato]

Figura 36 - Activity Diagram Eliminazione brano MP3 dall'archivio

209
_________________________________________________________________

Figura 37 - Sequence Diagram Eliminazione brano MP3 dall'archivio

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i
2
:

c
r
e
a
t
e
2
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i
2
.
2
.
2
.
1
.
1
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o
/
i

d
a

c
a
n
c
e
l
l
a
r
e
2
.
2
.
2
.
1
.
2
:

e
s
e
g
u
i

c
a
n
c
e
l
l
a
z
i
o
n
e
2
.
2
.
1
:

c
r
e
a
t
e
2
.
2
.
2
:

c
r
e
a
t
e
2
.
2
.
2
.
1
.
3
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
1
.
4
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
1
.
5
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
1
.
6
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
1
.
7
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
1
.
8
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
1
.
9
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
1
.
1
0
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
1
.
1
1
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o

M
P
3
2
.
2
.
2
.
2
.
2
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o

b
r
a
n
o
2
.
2
.
2
.
2
.
3
:

c
r
e
a
t
e
2
.
2
.
2
.
2
.
4
:

v
i
s
u
a
l
i
z
z
a
I
n
f
o
(

)
2
.
2
.
2
.
2
.
5
:

l
e
g
g
i
(

)
2
.
2
.
2
.
2
.
6
:

c
a
r
i
c
a

d
a
t
i
2
.
2
.
2
.
2
.
7
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
2
.
2
.
8
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
2
.
2
.
9
:

r
i
c
h
i
e
s
t
a

c
a
n
c
e
l
l
a
z
i
o
n
e

b
r
a
n
o
2
.
2
.
2
.
2
.
1
0
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
2
.
1
1
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
2
.
1
2
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
3
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
2
.
1
4
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
5
:

e
l
i
m
i
n
a
(

)
2
.
2
.
2
.
2
.
1
6
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
7
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
8
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
2
0
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
2
.
2
.
2
.
2
.
1
9
:

d
e
s
t
r
o
y
2
.
2
.
3
:

d
e
s
t
r
o
y
2
.
2
.
4
:

d
e
s
t
r
o
y
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

p
e
r

G
e
n
e
r
e

o

R
i
c
e
r
c
a

p
e
r
s
o
n
a
l
i
z
z
a
t
a
S
c
e
n
a
r
i
o

1

:

e
l
i
m
i
n
a
z
i
o
n
e

d
i

b
r
a
n
i

s
e
l
e
z
i
o
n
a
n
d
o
l
i

d
a
l
l
'e
l
e
n
c
o
:
B
r
a
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
C
o
m
p
o
s
i
z
i
o
n
e
P
l
a
y
l
i
s
t
D
B
:
F
i
l
e
M
P
3
I
n
t
e
r
f
a
c
c
i
a

I
n
f
o

B
r
a
n
o

M
P
3
S
c
e
n
a
r
i
o

2

:

e
l
i
m
i
n
a
z
i
o
n
e

d
i

b
r
a
n
i

s
e
l
e
z
i
o
n
a
n
d
o
n
e

u
n
o

e

v
i
s
u
a
l
i
z
z
a
n
d
o
n
e

l
e

i
n
f
o
r
m
a
z
i
o
n
i
210
_________________________________________________________________
3.3.8 Ascolto di un singolo Brano

Tra i servizi offerti dalla Web application, c la possibilit da parte
dellutente di poter ascoltare una sequenza di brani che compongono una propria
playlist.
La funzionalit di ascolto messa a disposizione anche nel caso di un singolo MP3,
sia per lutente che per lamministratore. Per poter usufruire di questa funzione,
ovviamente necessario accedere alle informazioni del singolo brano che si desidera
ascoltare. Una volta effettuata tale richiesta, il sistema eseguir il caricamento di un
player MP3, che permetter lo streaming del file associato al brano. Lavvio
dellascolto, non impedisce allutente di poter proseguire la navigazione allinterno
dellapplicazione, usufruendo degli altri servizi.

211
_________________________________________________________________

Utente/Amministratore Sistema
[Assenza brani]
[Presenza brani]
Selezione brano MP3
:BranoMP3
[letto]
Richiesta ascolto brano MP3
Riproduzione brano MP3
Richiesta visualizzazione brani MP3per gener
[Richiesta
ricerca]
genere]
:BranoMP3
[letto]
:FileMP3
[streaming]

Figura 38 - Activity Diagram Ascolto singolo brano MP3

212
_________________________________________________________________

Figura 39 - Sequence Diagram Ascolto singolo brano MP3

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i
2
:

c
r
e
a
t
e
2
.
1
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
2
.
2
.
1
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i
2
.
2
.
2
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o

M
P
3
2
.
2
.
3
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o

b
r
a
n
o
2
.
2
.
4
:

c
r
e
a
t
e
2
.
2
.
5
:

c
r
e
a
t
e
2
.
2
.
6
:

v
i
s
u
a
l
i
z
z
a
I
n
f
o
(

)
2
.
2
.
7
:

l
e
g
g
i
(

)
2
.
2
.
8
:

c
a
r
i
c
a

d
a
t
i
2
.
2
.
9
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
1
0
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
1
1
:

r
i
c
h
i
e
s
t
a

a
s
c
o
l
t
o

b
r
a
n
o
2
.
2
.
1
2
:

a
s
c
o
l
t
a
(

)
2
.
2
.
1
3
:

c
r
e
a
t
e
2
.
2
.
1
4
:

r
i
p
r
o
d
u
c
i
(

)
2
.
2
.
1
5
:

r
i
p
r
o
d
u
z
i
o
n
e
2
.
2
.
1
6
:

r
i
p
r
o
d
u
z
i
o
n
e
2
.
2
.
1
7
:

r
i
p
r
o
d
u
z
i
o
n
e

b
r
a
n
o
2
.
2
.
1
8
:

f
i
n
e

r
i
p
r
o
d
u
z
i
o
n
e
2
.
2
.
1
9
:

f
i
n
e

r
i
p
r
o
d
u
z
i
o
n
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

p
e
r

G
e
n
e
r
e

o

R
i
c
e
r
c
a
I
n
t
e
r
f
a
c
c
i
a

I
n
f
o

B
r
a
n
o

M
P
3
:
B
r
a
n
o
M
P
3
:
F
i
l
e
M
P
3
B
r
a
n
o
M
P
3
D
B
2
.
2
.
1
7
:

r
i
p
r
o
d
u
z
i
o
n
e

b
r
a
n
o
U
t
e
n
t
e
213
_________________________________________________________________

La gestione delle playlist rappresenta il servizio principale offerto dalla Web
application per gli utenti registrati, anche esclusivamente con la modalit base.
Attraverso questo servizio possibile :

- creare ed eliminare le proprie playlist preferite;
- inserire e cancellare brani da ciascuna playlist;
- ascoltare una playlist;

Loperazione di creazione relativamente semplice, in quanto lunica informazione
associata ad una playlist il nome che pu essere specificato dallutente.

Utente Sistema
Inserimento informazioni Playlist
Registrazione informazioni Playlist
:Playlist
[creato]
[Dati non corretti]
[Dati corretti]

Figura 40 - Activity Diagram Creazione playlist

214
_________________________________________________________________
1: richiesta creazione playlist
2: create
3: richiesta inserimento informazioni playlist
4: inserimento informazioni playlist
5: esegui creazione playlist
6: controllo correttezza dati
6.1: err: dati non validi
6.2.1: create
6.2.2: crea( )
6.2.3: inserisci( )
6.2.4: inserimento eseguito
6.2.5: inserimento eseguito
6.2.7: notifica creazione playlist
6.2.6: destroy
Utente
Interfaccia Home
Interfaccia Creazione Playlist
:Playlist
PlaylistDB

Figura 41 - Sequence Diagram Creazione playlist

Una volta create una o pi playlist, possibile visualizzarne lelenco ed accedere a
ciascuna di esse per visualizzarne i brani MP3 che la compongono. Gli Activity
Diagram seguenti fanno riferimento a quanto detto e sono molto semplici in virt del
fatto che sono utilizzati come parti componenti dei diagrammi pi complessi che
prevedono queste funzionalit.
Caricamenti elenco Playlist dall'archivio
:Playlist
[letto]
Visualizzazione Playlist

Figura 42 - Activity Diagram Visualizzazione elenco playlist
215
_________________________________________________________________
Caricamento elenco brani MP3 in Playlist
:BranoMP3
[letto]
Visualizzazione contenuto Playlist

Figura 43 - Activity Diagram Visualizzazione elenco brani MP3 nella playlist

Per quanto riguarda i corrispondenti Sequence Diagram, non previsto quello
relativo alla visualizzazione delle playlist, in quanto le azioni necessarie vengono
svolte direttamente nei diagrammi delle funzionalit che lo prevedono. Viceversa,
definito un diagramma la visualizzazione dei brani allinterno di una playlist, in
quanto comporta uno scambio di messaggi molto pi complessi che vale la pena
mettere in risalto.
La funzionalit di eliminazione delle playlist prevede due distinte modalit :

- eliminazione di una o pi playlist selezionandole dallelenco;
- eliminazione di una singola playlist, visualizzandone lelenco dei brani che la
compongono;

In entrambi i casi, per ciascuna playlist ne vanno eliminate le informazioni
caratteristiche e quelle relative alla composizione, ovviamente non cancellando
dallarchivio i brani MP3.

216
_________________________________________________________________

Figura 44 - Sequence Diagram Visualizzazione elenco brani MP3 nella playlist

1
:

r
i
c
h
i
e
s
t
a

e
l
e
n
c
o

p
l
a
y
l
i
s
t
2
:

c
r
e
a
t
e
3
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
E
l
e
n
c
o
P
l
a
y
l
i
s
t
(

)
5
:

l
e
g
g
i
(

)
6
:

c
a
r
i
c
a

d
a
t
i
6
.
1
.
1
:

e
r
r
:

a
s
s
e
n
z
a

p
l
a
y
l
i
s
t
6
.
1
.
2
:

n
o
t
i
f
i
c
a

a
s
s
e
n
z
a

p
l
a
y
l
i
s
t
6
.
2
.
1
:

p
l
a
y
l
i
s
t

c
a
r
i
c
a
t
e
6
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

p
l
a
y
l
i
s
t
6
.
2
.
3
:

s
e
l
e
z
i
o
n
e

p
l
a
y
l
i
s
t
6
.
2
.
4
:

c
r
e
a
t
e
6
.
2
.
5
:

v
i
s
u
a
l
i
z
z
a
E
l
e
n
c
o
B
r
a
n
i
M
P
3
P
l
a
y
l
i
s
t
(

)
6
.
2
.
6
:

l
e
g
g
i
(

)
6
.
2
.
7
:

c
a
r
i
c
a

d
a
t
i
6
.
2
.
8
:

l
e
g
g
i
(

)
6
.
2
.
9
:

c
a
r
i
c
a

d
a
t
i
6
.
2
.
9
.
1
.
1
:

e
r
r
:

p
l
a
y
l
i
s
t

v
u
o
t
a
6
.
2
.
9
.
1
.
2
:

n
o
t
i
f
i
c
a

p
l
a
y
l
i
s
t

v
u
o
t
a
6
.
2
.
9
.
2
.
1
:

b
r
a
n
i

c
a
r
i
c
a
t
i
6
.
2
.
9
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

n
e
l
l
a

p
l
a
y
l
i
s
t
6
.
2
.
1
0
:

d
e
s
t
r
o
y
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

P
l
a
y
l
i
s
t
:
P
l
a
y
l
i
s
t
P
l
a
y
l
i
s
t
D
B
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
C
o
m
p
o
s
i
z
i
o
n
e
P
l
a
y
l
i
s
t
D
B
B
r
a
n
o
M
P
3
D
B
217
_________________________________________________________________
Utente Sistema
Richiesta visualizzazione elenco Playlist
Caricamenti elenco Playlistdall'archivio
:Playlist
[letto]
Visualizzazione elenco Playlist
[Assenza Playlist]
[Presenza Playlist]
Selezione delle Playlist da cancellare
Richiesta cancellazione Playlist
:BranoMP3
[letto]
Visualizzazione elenco brani MP3 in Playlist
Cancellazione Playlist
:Playlist
[eliminato]
Selezione Playlist

Figura 45 - Activity Diagram Eliminazione playlist

218
_________________________________________________________________

Figura 46 - Sequence Diagram Eliminazione playlist

Ovviamente lutente ha la possibilit di inserire uno o pi brani allinterno di una
playlist, secondo le due seguenti modalit, evidenziate nel Sequence Diagram :

- selezionando uno o pi brani dallelenco corrente;
- inserendo un singolo brano, dallinterfaccia di visualizzazione delle
informazioni;
1
:

r
i
c
h
i
e
s
t
a

e
l
e
n
c
o

p
l
a
y
l
i
s
t
2
:

c
r
e
a
t
e
3
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
E
l
e
n
c
o
P
l
a
y
l
i
s
t
(

)
5
:

l
e
g
g
i
(

)
6
:

c
a
r
i
c
a

d
a
t
i
6
.
1
.
1
:

e
r
r
:

a
s
s
e
n
z
a

p
l
a
y
l
i
s
t
6
.
1
.
2
:

n
o
t
i
f
i
c
a

a
s
s
e
n
z
a

p
l
a
y
l
i
s
t
6
.
2
.
1
:

p
l
a
y
l
i
s
t

c
a
r
i
c
a
t
e
6
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

p
l
a
y
l
i
s
t
6
.
2
.
2
.
1
.
1
:

s
e
l
e
z
i
o
n
e

p
l
a
y
l
i
s
t

d
a

c
a
n
c
e
l
l
a
r
e
6
.
2
.
2
.
1
.
2
:

e
s
e
g
u
i

c
a
n
c
e
l
l
a
z
i
o
n
e
6
.
2
.
2
.
1
.
3
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
1
.
4
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
1
.
5
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
1
.
6
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
1
.
7
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
1
.
8
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
1
.
9
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a

e

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

p
l
a
y
l
i
s
t
6
.
2
.
2
.
2
.
1
:

s
e
l
e
z
i
o
n
e

p
l
a
y
l
i
s
t

e

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

c
o
n
t
e
n
u
t
i
6
.
2
.
2
.
2
.
2
:

c
r
e
a
t
e
6
.
2
.
2
.
2
.
3
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i

c
o
n
t
e
n
u
t
i

n
e
l
l
a

p
l
a
y
l
i
s
t
6
.
2
.
2
.
2
.
4
:

r
i
c
h
i
e
s
t
a

d
i

c
a
n
c
e
l
l
a
z
i
o
n
e

d
e
l
l
a

p
l
a
y
l
i
s
t
6
.
2
.
2
.
2
.
5
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
2
.
6
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
2
.
7
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
2
.
8
:

e
l
i
m
i
n
a
(

)
6
.
2
.
2
.
2
.
9
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
2
.
1
0
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
2
.
1
1
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
6
.
2
.
2
.
2
.
1
3
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

p
l
a
y
l
i
s
t
6
.
2
.
2
.
2
.
1
2
:

d
e
s
t
r
o
y
6
.
2
.
3
:

d
e
s
t
r
o
y
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

P
l
a
y
l
i
s
t
:
P
l
a
y
l
i
s
t
P
l
a
y
l
i
s
t
D
B
C
o
m
p
o
s
i
z
i
o
n
e
P
l
a
y
l
i
s
t
D
B
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

P
l
a
y
l
i
s
t
S
c
e
n
a
r
i
o

1

:

e
l
i
m
i
n
a
z
i
o
n
e

d
i

P
l
a
y
l
i
s
t

s
e
l
e
z
i
o
n
a
n
d
o
l
e

d
a
l
l
'e
l
e
n
c
o
S
c
e
n
a
r
i
o

2

:

e
l
i
m
i
n
a
z
i
o
n
e

d
i

P
l
a
y
l
i
s
t

s
e
l
e
z
i
o
n
a
n
d
o
n
e

u
n
a

e

v
i
s
u
a
l
i
z
z
a
n
d
o
n
e

i
l

c
o
n
t
e
n
u
t
o
219
_________________________________________________________________
Utente Sistema
Selezione modalit visualizzazionebrani MP3
Richiestaricerca Bran
[Richiesta
ricerca]
genere]
:BranoMP3
[letto]
[Assenza brani]
[Presenza brani]
Selezione brano MP3
Selezione dei brani MP3 da inserire
:BranoMP3
[letto]
Visualizzazionedati MP3
Richiesta inserimento brano/i MP3
Inserimento brano/i MP3 nella Playlist
:Playlist
[aggiornato]

Figura 47 - Activity Diagram Inserimento brano MP3 nella playlist

Ovviamente, si esegue laggiornamento della composizione della playlist.
220
_________________________________________________________________

Figura 48 - Sequence Diagram Inserimento brano MP3 nella playlist

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i
2
:

c
r
e
a
t
e
2
.
1
:

e
r
r
:

a
s
s
e
n
z
a

b
r
a
n
i
2
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i
2
.
2
.
2
.
1
.
1
:

s
e
l
e
z
i
o
n
e

p
l
a
y
l
i
s
t

e

b
r
a
n
i

d
a

i
n
t
r
o
d
u
r
r
e
2
.
2
.
2
.
1
.
2
:

e
s
e
g
u
i

i
n
s
e
r
i
m
e
n
t
o

b
r
a
n
o
/
i

n
e
l
l
a

p
l
a
y
l
i
s
t
2
.
2
.
1
:

c
r
e
a
t
e
2
.
2
.
2
.
1
.
3
:

i
n
s
e
r
i
s
c
i
B
r
a
n
o
(

)
2
.
2
.
2
.
1
.
4
:

m
o
d
i
f
i
c
a
(

)
2
.
2
.
2
.
1
.
5
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
2
.
1
.
6
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
2
.
1
.
7
:

n
o
t
i
f
i
c
a

b
r
a
n
o
/
i

i
n
s
e
r
i
t
o
/
i

n
e
l
l
a

p
l
a
y
l
i
s
t

s
e
l
e
z
i
o
n
a
t
a
2
.
2
.
2
.
2
.
2
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
2
.
2
.
1
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o

d
a

i
n
s
e
r
i
r
e

n
e
l
l
a

p
l
a
y
l
i
s
t
2
.
2
.
2
.
2
.
3
:

c
r
e
a
t
e
2
.
2
.
2
.
2
.
4
:

c
r
e
a
t
e
2
.
2
.
2
.
2
.
5
:

v
i
s
u
a
l
i
z
z
a
I
n
f
o
(

)
2
.
2
.
2
.
2
.
6
:

l
e
g
g
i
(

)
2
.
2
.
2
.
2
.
7
:

c
a
r
i
c
a

d
a
t
i
2
.
2
.
2
.
2
.
8
:

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
2
.
2
.
1
0
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

i
n
f
o
r
m
a
z
i
o
n
i

b
r
a
n
o
2
.
2
.
2
.
2
.
1
1
:

s
e
l
e
z
i
o
n
e

p
l
a
y
l
i
s
t

e

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

b
r
a
n
o
2
.
2
.
2
.
2
.
9
:

d
e
s
t
r
o
y
2
.
2
.
2
.
2
.
1
2
:

i
n
s
e
r
i
s
c
i
B
r
a
n
o
(

)
2
.
2
.
2
.
2
.
1
3
:

m
o
d
i
f
i
c
a
(

)
2
.
2
.
2
.
2
.
1
4
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
2
.
2
.
1
5
:

i
n
s
e
r
i
m
e
n
t
o

e
s
e
g
u
i
t
o
2
.
2
.
2
.
2
.
1
6
:

n
o
t
i
f
i
c
a

b
r
a
n
o

i
n
s
e
r
i
t
o

n
e
l
l
a

p
l
a
y
l
i
s
t

s
e
l
e
z
i
o
n
a
t
a
2
.
2
.
2
.
2
.
1
7
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i
2
.
2
.
3
:

d
e
s
t
r
o
y
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

M
P
3

p
e
r

G
e
n
e
r
e

o

R
i
c
e
r
c
a

p
e
r
s
o
n
a
l
i
z
z
a
t
a
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
C
o
m
p
o
s
i
z
i
o
n
e
P
l
a
y
l
i
s
t
D
B
:
P
l
a
y
l
i
s
t
S
c
e
n
a
r
i
o

1

:

i
n
s
e
r
i
m
e
n
t
o

d
i

b
r
a
n
i

i
n

u
n
a

p
l
a
y
l
i
s
t
,

s
e
l
e
z
i
o
n
a
n
d
o
l
i

d
a
l
l
'e
l
e
n
c
o
I
n
t
e
r
f
a
c
c
i
a

I
n
f
o

B
r
a
n
o

M
P
3
:
B
r
a
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
S
c
e
n
a
r
i
o

2

:

i
n
s
e
r
i
m
e
n
t
o

d
i

u
n

b
r
a
n
o

i
n

u
n
a

p
l
a
y
l
i
s
t
,

s
e
l
e
z
i
o
n
a
n
d
o
l
o

e

v
i
s
u
a
l
i
z
z
a
n
d
o
n
e

l
e

i
n
f
o
r
m
a
z
i
o
n
i
221
_________________________________________________________________
Leliminazione dei brani da una playlist prevede unicamente la possibilit di
selezionarli dallelenco.

Utente Sistema
:Playlist
[letto]
Selezione Playlist
Richiesta visualizzazione brani MP3 in Playlist
:BranoMP3
[letto]
Selezione dei brani MP3 da cancellare
Richiesta cancellazione brano/i MP3
Cancellazione brano/i MP3 da Playlist
:Playlist
[aggiornato]
[Presenza Playlist]
[Assenza Playlist]
[Assenza Brani]
[Presenza Brani]

Figura 49 - Activity Diagram Eliminazione brani MP3 dalla playlist

222
_________________________________________________________________

C
o
m
p
o
s
i
z
i
o
n
e
P
l
a
y
l
i
s
t
D
B
4
.
1
.
5
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
4
.
1
.
4
:

e
l
i
m
i
n
a
(

)

Figura 50 - Sequence Diagram Eliminazione brani MP3 dalla playlist

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

i
n

u
n
a

p
l
a
y
l
i
s
t
2
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

b
r
a
n
i

c
o
n
t
e
n
u
t
i

n
e
l
l
a

p
l
a
y
l
i
s
t
4
.
1
.
1
:

s
e
l
e
z
i
o
n
e

b
r
a
n
o
/
i

d
a

c
a
n
c
e
l
l
a
r
e
4
.
1
.
2
:

r
i
c
h
i
e
s
t
a

c
a
n
c
e
l
l
a
z
i
o
n
e

b
r
a
n
o
/
i

s
e
l
e
z
i
o
n
a
t
o
/
i
4
.
1
.
3
:

e
l
i
m
i
n
a
B
r
a
n
o
(

)
4
.
1
.
6
:

b
r
a
n
o
/
i

e
l
i
m
i
n
a
t
o
/
i
4
.
1
.
7
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

b
r
a
n
o
/
i

s
e
l
e
z
i
o
n
a
t
o
/
i
3
:

c
r
e
a
t
e
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
:
P
l
a
y
l
i
s
t
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

P
l
a
y
l
i
s
t
223
_________________________________________________________________
Lultima funzionalit relativa alle playlist relativa allascolto, ed fornita dal sistema
mediante lausilio di un player MP3 che viene avviato nel momento in cui ne viene
fatta richiesta dallutente.

Utente Sistema
:Playlist
[letto]
Selezione Playlist
:BranoMP3
[letto]
[Presenza Playlist]
[Assenza Playlist]
Richiesta ascolto Playlist
Riproduzione Playlist
:FileMP3
[streaming]

Figura 51 - Activity Diagram Ascolto playlist

224
_________________________________________________________________

Figura 52 - Sequence Diagram Ascolto playlist
1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

p
l
a
y
l
i
s
t
2
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

b
r
a
n
i

c
o
n
t
e
n
u
t
i

n
e
l
l
a

p
l
a
y
l
i
s
t
5
:

r
i
c
h
i
e
s
t
a

a
s
c
o
l
t
o

p
l
a
y
l
i
s
t
3
:

c
r
e
a
t
e
6
:

a
s
c
o
l
t
a
(

)
1
3
:

r
i
p
r
o
d
u
z
i
o
n
e
1
4
:

r
i
p
r
o
d
u
z
i
o
n
e

p
l
a
y
l
i
s
t
7
:

c
r
e
a
t
e
8
:

a
s
c
o
l
t
a
(

)
9
:

c
r
e
a
t
e
1
0
:

r
i
p
r
o
d
u
c
i
(

)
1
1
:

r
i
p
r
o
d
u
z
i
o
n
e
1
2
:

r
i
p
r
o
d
u
z
i
o
n
e
1
5
:

f
i
n
e

r
i
p
r
o
d
u
z
i
o
n
e
1
6
:

f
i
n
e

r
i
p
r
o
d
u
z
i
o
n
e
1
7
:

f
i
n
e

r
i
p
r
o
d
u
z
i
o
n
e
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

B
r
a
n
i

M
P
3
S
e
q
u
e
n
c
e

D
i
a
g
r
a
m

V
i
s
u
a
l
i
z
z
a
z
i
o
n
e

B
r
a
n
i

P
l
a
y
l
i
s
t
:
P
l
a
y
l
i
s
t
:
F
i
l
e
M
P
3
:
B
r
a
n
o
M
P
3
P
e
r

o
g
n
i

b
r
a
n
o

d
e
l
l
a

p
l
a
y
l
i
s
t
225
_________________________________________________________________
3.3.10 Acquisto/Download Brano

Se lutente ha effettuato una registrazione estesa oppure, partendo da una
registrazione base, ha deciso di acquistare una scheda prepagata in un secondo
momento, automaticamente acquisisce il diritto di poter acquistare e scaricare i brani
MP3 oltre che di ascoltarli in streaming.
Lutente pu effettuare lacquisto di un brano partendo dalla visualizzazione di un
elenco di brani ottenuti sulla base di una ricerca oppure contenuti allinterno delle
proprie playlist precedentemente create. Selezionando il brano di interesse, accede
alla scheda contenente le informazioni dello stesso ed ha poi la possibilit di
confermarne lacquisto.
Ovviamente, il sistema esegue i dovuti controlli, verificando che limporto residuo
presente sulla scheda sia sufficiente allacquisto. Nel caso di esito negativo, si invita
lutente alla ricarica della scheda mentre nel caso di esito positivo lo si abilita al
download del brano. Contestualmente allavvio del download, viene aggiornato
limporto residuo della scheda e viene registrato lacquisto eseguito dallutente, in
modo da avere a disposizione un archivio storico con gli acquisti eseguiti e poter, ad
esempio, generare delle statistiche dei brani maggiormente scaricati.

226
_________________________________________________________________
Utente Sistema
[Assenza Brani]
[Assenza Playlist]
Selezione Playlist
Richiesta visualizzazione brani MP3 in Playlist
[Presenza Playlist]
[Assenza Brani]
Selezione brano MP3
[Presenza Brani]
[Presenza Brani]
Controllo Importo residuo su Scheda
:SchedaPrepagata
[letto]
[Importo insufficiente]
[Importo sufficiente]
Registrazione Acquisto/Download brano MP3
Avvio Download
:Download
[registrato]
:SchedaPrepagata
[aggiornato]
Registrazione acquisto brano
MP3 ed aggiornamento Importo
residuo della Scheda
Richiesta Download brano MP3
:FileMP3
[download]

Figura 53 - Activity Diagram Acquisto/Download brano MP3
227
_________________________________________________________________

Figura 54 - Sequence Diagram Acquisto/Download brano MP3

1
:
ri
c
h
i
e
s
ta

v
i
s
u
a
li
z
z
a
z
io
n
e

b
ra
n
i
2
:

c
re
a
t
e
2
.1
:

e
r
r:

a
s
s
e
n
z
a

b
ra
n
i
2
.
2
.1
:

v
is
u
a
l
iz
z
a
z
io
n
e

e
le
n
c
o

b
ra
n
i
2
.2
.
2
:
s
e
le
z
io
n
e

b
ra
n
o

M
P
3
2
.
2
.3
:

r
ic
h
ie
s
t
a

v
is
u
a
l
iz
z
a
z
io
n
e

i
n
fo

b
ra
n
o
2
.
2
.4
:

c
re
a
t
e
2
.
2
.5
:

c
re
a
t
e
2
.
2
.
6
:
v
i
s
u
a
li
z
z
a
In
f
o
(
)
2
.2
.
7
:
le
g
g
i
(
)
2
.
2
.8
:

c
a
ri
c
a

d
a
ti
2
.2
.9
:

i
n
fo
r
m
a
z
io
n
i

b
r
a
n
o
2
.
2
.1
0
:

v
is
u
a
li
z
z
a
z
i
o
n
e

i
n
fo
r
m
a
z
io
n
i

b
r
a
n
o
2
.2
.
1
1
:
ri
c
h
ie
s
t
a

a
c
q
u
is
t
o
/d
o
w
n
lo
a
d

b
ra
n
o
2
.
2
.1
2
:

a
c
q
u
is
t
a
(
)
2
.2
.
1
3
:
c
r
e
a
te
2
.
2
.1
4
:

c
o
n
tr
o
ll
o
Im
p
o
r
to
R
e
s
id
u
o
(

)
2
.
2
.1
5
:

l
e
g
g
i(

)
2
.2
.
1
6
:
c
a
r
ic
a

d
a
t
i
2
.2
.
1
6
.1
.
1
:
e
rr
:
im
p
o
rt
o

in
s
u
f
fi
c
i
e
n
te
2
.
2
.1
6
.
1
.2
:
e
rr
:
im
p
o
rt
o

r
e
s
id
u
o

in
s
u
f
fi
c
i
e
n
t
e
2
.2
.
1
6
.1
.
3
:
n
o
ti
fi
c
a

im
p
o
rt
o

in
s
u
f
fi
c
i
e
n
te

p
e
r
a
c
q
u
i
s
to
/
d
o
w
n
lo
a
d

b
ra
n
o
2
.2
.
1
6
.2
.
1
:
a
g
g
io
r
n
a
Im
p
o
r
to
R
e
s
id
u
o
(

)
2
.
2
.1
6
.
2
.2
:

m
o
d
if
ic
a
(
)
2
.
2
.1
6
.2
.
3
:
a
g
g
io
r
n
a
m
e
n
t
o

e
s
e
g
u
i
to
2
.2
.
1
6
.2
.
4
:
a
g
g
io
r
n
a
m
e
n
to

e
s
e
g
u
it
o
2
.
2
.1
6
.
2
.5
:

d
e
s
tr
o
y
2
.
2
.1
6
.2
.
6
:
c
r
e
a
te
2
.
2
.
1
6
.2
.
7
:
in
s
e
r
is
c
i(

)
2
.
2
.1
6
.
2
.8
:
in
s
e
r
is
c
i(

)
2
.2
.
1
6
.2
.
9
:
in
s
e
ri
m
e
n
t
o

e
s
e
g
u
i
to
2
.
2
.1
6
.
2
.1
0
:
in
s
e
r
im
e
n
to

e
s
e
g
u
it
o
2
.2
.1
6
.
2
.1
1
:

d
e
s
t
ro
y
2
.2
.
1
6
.
2
.1
2
:

a
c
q
u
is
t
o

e
f
fe
t
tu
a
t
o
2
.
2
.1
6
.
2
.1
3
:

n
o
t
if
ic
a

a
c
q
u
i
s
to

e
s
e
g
u
it
o

e
d

a
b
il
it
a
z
i
o
n
e

a
l
d
o
w
n
l
o
a
d
2
.2
.
1
6
.
2
.1
4
:

e
s
e
g
u
i

d
o
w
n
lo
a
d
2
.2
.
1
6
.
2
.1
5
:

a
v
v
i
a
D
o
w
n
lo
a
d
(

)
2
.
2
.1
6
.
2
.1
6
:
c
r
e
a
te
2
.
2
.1
6
.
2
.1
7
:
d
o
w
n
l
o
a
d
(
)
2
.
2
.1
6
.
2
.1
8
:

t
e
r
m
i
n
e

d
o
w
n
lo
a
d
2
.
2
.1
6
.2
.
1
9
:
d
e
s
tr
o
y
2
.
2
.1
6
.2
.
2
0
:
te
r
m
i
n
e

d
o
w
n
lo
a
d
2
.2
.
1
6
.2
.
2
1
:
d
e
s
tr
o
y
2
.2
.
1
6
.2
.
2
2
:

n
o
t
if
ic
a

t
e
rm
in
e

d
e
l
d
o
w
n
l
o
a
d
U
te
n
t
e
I
n
te
r
fa
c
c
i
a

I
n
fo

B
r
a
n
o

M
P
3
I
n
te
r
fa
c
c
i
a

H
o
m
e
I
n
t
e
rf
a
c
c
ia

E
l
e
n
c
o

B
r
a
n
i
M
P
3
S
e
q
u
e
n
c
e

D
ia
g
r
a
m

V
i
s
u
a
li
z
z
a
z
i
o
n
e

B
ra
n
i

M
P
3

p
e
r
G
e
n
e
re
,
R
i
c
e
r
c
a

o

in

u
n
a

P
la
y
li
s
t
:
B
ra
n
o
M
P
3
B
r
a
n
o
M
P
3
D
B
:
S
c
h
e
d
a
P
r
e
p
a
g
a
ta
S
c
h
e
d
a
P
re
p
a
g
a
t
a
D
B
:
D
o
w
n
lo
a
d
D
o
w
n
lo
a
d
D
B
:
F
i
l
e
M
P
3
228
_________________________________________________________________
3.3.11 Modifica Dati Personali

Lutente e lamministratore hanno entrambi lopportunit di modificare i
propri dati di accesso. In particolare, lamministratore ha esclusivamente la possibilit
di modificare la password, in quanto non ci sono ulteriori informazioni ad esso
associate. Viceversa, per lutente si possono presentare due scenari differenti:

- nel caso in cui non possegga una scheda prepagata, avr la possibilit di
modificare la propria password e lindirizzo email, ma non lo username;
- nel caso in cui possegga una scheda prepagata, avr ovviamente la possibilit
di modificare i dati di accesso suddetti oltre a tutte le informazioni
anagrafiche, fornite nella fase di acquisto della scheda;

In entrambi i casi, il sistema visualizza i dati attuali, permettendo allutilizzatore di
modificarne i valori e confermarne laggiornamento.
A questo punto, lapplicazione esegue in primo luogo un controllo di correttezza sui
dati, per verificare che siano del formato atteso ed in particolare chiede
allutilizzatore, utente o amministratore che sia, di inserire una conferma della
password scelta. Ovviamente, viene verificato che la password scelta e la sua
conferma coincidano, altrimenti non si consente la modifica dei propri dati.
La funzionalit di modifica dei dati, pu essere considerata del tutto simile, senza
alcuna distinzione, tra lutente e lamministratore, tenendo esclusivamente conto dei
limiti di aggiornamento che pu eseguire il secondo.
Si preferito comunque sviluppare gli Activity e Sequence Diagram in maniera
separata, considerando che gli oggetti in gioco sono sostanzialmente diversi, poich
fanno riferimento a due utilizzatori differenti.

229
_________________________________________________________________

Utente Sistema
Richiesta modifica dati personali Caricamento dati attuali
:Utente
[letto]
Visualizzazione dati attuali
Inserimento nuovi dati
Controllo Password vecchia
Controllo Password nuova e conferma
[Password errata]
[Password corretta]
[Password nuova e conferma non coincidono]
[Password nuova e conferma coincidono]
Registrazione nuovi dati
:Utente
[aggiornato]
[Dati corretti]
[Dati non corretti]

Figura 55 - Activity Diagram Modifica dati personali Utente

230
_________________________________________________________________

Figura 56 - Sequence Diagram Modifica dati personali Utente

1
:

r
i
c
h
i
e
s
t
a

m
o
d
i
f
i
c
a

d
a
t
i

p
e
r
s
o
n
a
l
i
2
:

c
r
e
a
t
e
3
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
D
a
t
i
A
n
a
g
r
a
f
i
c
i
(

)
5
:

l
e
g
g
i
(

)
6
:

c
a
r
i
c
a

d
a
t
i
7
:

d
a
t
i

a
t
t
u
a
l
i

U
t
e
n
t
e
8
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

d
a
t
i

a
t
t
u
a
l
i

d
e
l
l
'
U
t
e
n
t
e
9
:

i
n
s
e
r
i
m
e
n
t
o

n
u
o
v
i

d
a
t
i
1
0
:

e
s
e
g
u
i

m
o
d
i
f
i
c
a

d
a
t
i
1
1
:

c
o
n
t
r
o
l
l
o

c
o
r
r
e
t
t
e
z
z
a

d
a
t
i
1
1
.
1
:

e
r
r
:

d
a
t
i

n
o
n

v
a
l
i
d
i
1
1
.
2
:

m
o
d
i
f
i
c
a
U
s
e
r
N
a
m
e
P
a
s
s
w
o
r
d
(

)
1
1
.
2
.
1
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

c
o
r
r
e
n
t
e

e
r
r
a
t
a
1
1
.
2
.
1
.
2
:

n
o
t
i
f
i
c
a

P
a
s
s
w
o
r
d

c
o
r
r
e
n
t
e

e
r
r
a
t
a
1
1
.
2
.
2
.
1
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

n
u
o
v
a

e

C
o
n
f
e
r
m
a

d
i
v
e
r
s
e
1
1
.
2
.
2
.
1
.
2
:

n
o
t
i
f
i
c
a

P
a
s
s
w
o
r
d

n
u
o
v
a

e

C
o
n
f
e
r
m
a

n
o
n

c
o
i
n
c
i
d
o
n
o
1
1
.
2
.
2
.
2
.
1
:

P
a
s
s
w
o
r
d

e

C
o
n
f
e
r
m
a

c
o
i
n
c
i
d
o
n
o
1
1
.
2
.
2
.
2
.
2
:

m
o
d
i
f
i
c
a
D
a
t
i
A
n
a
g
r
a
f
i
c
i
(

)
1
1
.
2
.
2
.
2
.
3
:

m
o
d
i
f
i
c
a
(

)
1
1
.
2
.
2
.
2
.
4
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
1
1
.
2
.
2
.
2
.
5
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
1
1
.
2
.
2
.
2
.
6
:

a
g
g
i
o
r
n
a
m
e
n
t
o

d
a
t
i

e
s
e
g
u
i
t
o
1
2
:

d
e
s
t
r
o
y
U
t
e
n
t
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

M
o
d
i
f
i
c
a

D
a
t
i

P
e
r
s
o
n
a
l
i
:
U
t
e
n
t
e
U
t
e
n
t
e
D
B
231
_________________________________________________________________

Inserimento Password vecchia, nuova e conferma Controllo Password vecchia
:Amministratore
[letto]
[Password errata]
[Password corretta]
Controllo Password nuova e conferma
[Password nuova e conferma non coincidono]
Registrazione nuova Password
[Password nuova e conferma coincidono]
:Amministratore
[aggiornato]

Figura 57 - Activity Diagram Modifica password Amministratore

232
_________________________________________________________________

Figura 58 - Sequence Diagram Modifica password Amministratore
1
:

r
i
c
h
i
e
s
t
a

m
o
d
i
f
i
c
a

P
a
s
s
w
o
r
d
2
:

c
r
e
a
t
e
3
:

r
i
c
h
i
e
s
t
a

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i

p
e
r

c
a
m
b
i
o

P
a
s
s
w
o
r
d
4
:

i
n
s
e
r
i
m
e
n
t
o

d
a
t
i
5
:

e
s
e
g
u
i

c
a
m
b
i
o

P
a
s
s
w
o
r
d
6
:

m
o
d
i
f
i
c
a
U
s
e
r
N
a
m
e
P
a
s
s
w
o
r
d
(

)
7
:

l
e
g
g
i
(

)
8
:

c
a
r
i
c
a

d
a
t
i
8
.
1
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

c
o
r
r
e
n
t
e

e
r
r
a
t
a
8
.
1
.
2
:

n
o
t
i
f
i
c
a

P
a
s
s
w
o
r
d

c
o
r
r
e
n
t
e

e
r
r
a
t
a
8
.
2
.
1
.
1
:

e
r
r
:

P
a
s
s
w
o
r
d

n
u
o
v
a

e

C
o
n
f
e
r
m
a

d
i
v
e
r
s
e
8
.
2
.
1
.
2
:

n
o
t
i
f
i
c
a

P
a
s
s
w
o
r
d

n
u
o
v
a

e

C
o
n
f
e
r
m
a

n
o
n

c
o
i
n
c
i
d
o
n
o
8
.
2
.
2
.
1
:

m
o
d
i
f
i
c
a
(

)
8
.
2
.
2
.
2
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
8
.
2
.
2
.
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
8
.
2
.
2
.
4
:

a
g
g
i
o
r
n
a
m
e
n
t
o

P
a
s
s
w
o
r
d

e
s
e
g
u
i
t
o
9
:

d
e
s
t
r
o
y
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

M
o
d
i
f
i
c
a

P
a
s
s
w
o
r
d
:
A
m
m
i
n
i
s
t
r
a
t
o
r
e
A
m
m
i
n
i
s
t
r
a
t
o
r
e
D
B
233
_________________________________________________________________

Lamministratore ha accesso ad una particolare sezione della Web
application, mediante la quale pu effettuare delle semplici operazioni relative alla
gestione degli utenti.
La prima funzionalit disponibile quella che permette la visualizzazione dellelenco
degli utenti registrati, con la possibilit di selezionare uno o pi utenti e di eseguirne
la cancellazione dal sistema.
A partire da tale elenco, inoltre possibile selezionare uno degli utenti per poterne
visualizzare le informazioni di registrazione, ovviamente esclusa la password di
accesso al sistema. Le informazioni visualizzate dipendo dal tipo di registrazione che
ha eseguito lutente e dal fatto che possegga o meno una scheda prepagata. In virt di
questa distinzione, saranno visualizzate solo le informazioni di accesso oppure anche
i dati anagrafici.
In corrispondenza dellinterfaccia di visualizzazione dei dati del singolo utente,
lamministratore pu eseguire due semplici operazioni :

- eliminare lutente;
- sbloccare lutente, qualora questultimo risulti bloccato in virt del fatto che
sono stati eseguiti due accessi consecutivi errati al sistema;

Il Sequence Diagram evidenzia i due scenari possibili per la cancellazione di uno o
pi utenti, nonch la funzionalit di sblocco.

234
_________________________________________________________________

Richiesta visualizzazione elenco Utenti
Caricamento elenco Utenti
:Utente
[letto] : 1
Visualizzazione elenco Utenti
Selezione Utente
Richiesta cancellazione Utente Cancellazione Utente dall'archivio
:Utente
[cancellato]
Richiesta visualizzazione dati Utente
Caricamento dati Utente
:Utente
[letto] : 2
Visualizzazione dati Utente
[Cancella Utente]
[Uscita dal servizio]
[Presenza Utenti]
[Assenza Utenti]
Richiesta sblocco Utente
Sblocco Utente
:Utente
[sbloccato]

Figura 59 - Activity Diagram Gestione Utenti

235
_________________________________________________________________

Figura 60 - Sequence Diagram Gestione Utenti

1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

u
t
e
n
t
i
2
:

c
r
e
a
t
e
3
:

c
r
e
a
t
e
4
:

v
i
s
u
a
l
i
z
z
a
E
l
e
n
c
o
U
t
e
n
t
i
(

)
5
:

l
e
g
g
i
(

)
6
:

c
a
r
i
c
a

d
a
t
i
6
.
1
:

e
r
r
:

n
o
n

c
i

s
o
n
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
6
.
1
.
1
:

n
o
t
i
f
i
c
a

e
r
r
o
r
e

n
o
n

c
i

s
o
n
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
6
.
2
.
1
:

e
l
e
n
c
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
6
.
2
.
2
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
7
.
1
.
1
:

s
e
l
e
z
i
o
n
e

u
t
e
n
t
e
/
i

d
a

c
a
n
c
e
l
l
a
r
e
7
.
1
.
2
:

e
l
i
m
i
n
a
(

)
7
.
1
.
3
:

e
l
i
m
i
n
a
(

)
7
.
1
.
4
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
7
.
1
.
5
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
7
.
1
.
6
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a

e

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
7
.
2
.
1
:

r
i
c
h
i
e
s
t
a

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

d
a
t
i

a
n
a
g
r
a
f
i
c
i

d
i

u
n

U
t
e
n
t
e

s
e
l
e
z
i
o
n
a
t
o
7
.
2
.
4
:

l
e
g
g
i
(

)
7
.
2
.
5
:

c
a
r
i
c
a

d
a
t
i
7
.
2
.
2
:

c
r
e
a
t
e
7
.
2
.
3
:

v
i
s
u
a
l
i
z
z
a
D
a
t
i
A
n
a
g
r
a
f
i
c
i
(

)
7
.
2
.
6
:

d
a
t
i

a
n
a
g
r
a
f
i
c
i

u
t
e
n
t
e
7
.
2
.
7
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

d
a
t
i

a
n
a
g
r
a
f
i
c
i

u
t
e
n
t
e
7
.
2
.
7
.
1
:

r
i
c
h
i
e
s
t
a

e
l
i
m
i
n
a
z
i
o
n
e

u
t
e
n
t
e
7
.
2
.
7
.
1
.
1
:

e
l
i
m
i
n
a
(

)
7
.
2
.
7
.
1
.
2
:

e
l
i
m
i
n
a
(

)
7
.
2
.
7
.
1
.
3
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
7
.
2
.
7
.
1
.
4
:

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
7
.
2
.
7
.
1
.
5
:

n
o
t
i
f
i
c
a

e
l
i
m
i
n
a
z
i
o
n
e

e
s
e
g
u
i
t
a
7
.
2
.
7
.
1
.
6
:

v
i
s
u
a
l
i
z
z
a
z
i
o
n
e

e
l
e
n
c
o

u
t
e
n
t
i

r
e
g
i
s
t
r
a
t
i
7
.
2
.
7
.
2
:

r
i
c
h
i
e
s
t
a

s
b
l
o
c
c
o

u
t
e
n
t
e
7
.
2
.
7
.
2
.
1
:

s
b
l
o
c
c
a
(

)
7
.
2
.
7
.
2
.
2
:

m
o
d
i
f
i
c
a
(

)
7
.
2
.
7
.
2
.
3
:

a
g
g
i
o
r
n
a
m
e
n
t
o

e
s
e
g
u
i
t
o
7
.
2
.
7
.
2
.
4
:

s
b
l
o
c
c
o

e
s
e
g
u
i
t
o
7
.
2
.
7
.
2
.
5
:

n
o
t
i
f
i
c
a

s
b
l
o
c
c
o

e
s
e
g
u
i
t
o
7
.
3
:

d
e
s
t
r
o
y
A
m
m
i
n
i
s
t
r
a
t
o
r
e
I
n
t
e
r
f
a
c
c
i
a

H
o
m
e
I
n
t
e
r
f
a
c
c
i
a

E
l
e
n
c
o

U
t
e
n
t
i
:
U
t
e
n
t
e
U
t
e
n
t
e
D
B
I
n
t
e
r
f
a
c
c
i
a

A
n
a
g
r
a
f
i
c
a

U
t
e
n
t
e
S
c
e
n
a
r
i
o

2

:

c
a
n
c
e
l
l
a
z
i
o
n
e

d
i

u
n

s
i
n
g
o
l
o

U
t
e
n
t
e

o
p
p
u
r
e

s
b
l
o
c
c
o

d
i

u
n

U
t
e
n
t
e
S
c
e
n
a
r
i
o

1

:

c
a
n
c
e
l
l
a
z
i
o
n
e

u
t
e
n
t
i

s
e
l
e
z
i
o
n
a
n
d
o
l
i

d
a
l
l
'
e
l
e
n
c
o
236
_________________________________________________________________
3.4 Statechart Diagrams

Gli Statechart Diagrams costituiscono uno strumento mediante il quale
possibile descrive una state machine, enfatizzando il flusso di controllo tra gli state.
Una state machine definisce un comportamento che specifica i vari state che un
oggetto pu assumere durante la sua vita in risposta a certi eventi. Ogni state
rappresenta una condizione di un oggetto, in cui sono soddisfatti certi requisiti ,
mentre un evento la specificazione di un accadimento significativo, posizionabile
nel tempo e nello spazio, che determina una transizione di stato da parte delloggetto.
Questultima esprime il fatto che, un oggetto a partire da un certo stato ed al
verificarsi di un determinato evento passa in uno stato differente, poich sono
cambiate le condizioni in cui si trova. Sulla base di quanto detto, un diagramma di
questo tipo pu rappresentare unestensione della descrizione di un automa a stati
finiti.
Considerando il case study sviluppato, sono stati definiti gli Statechart Diagrams per
quegli oggetti che possono compiere delle transizioni significative durante la vita della
Web application. In particolare sono :

- Amministratore;
- Utente;
- BranoMP3;
- CartaCredito;
- Playlist;
- SchedaPrepagata

Per quanto riguarda lAmministratore, questultimo pu trovarsi
fondamentalmente in due possibili stati : loggato e bloccato. Ovviamente, bisogna
tener conto che la condizione di Amministratore non loggato rappresenta il punto di
inizio del diagramma. Lo stato loggato si raggiunge dopo aver eseguito
correttamente il login, mentre lo stato bloccato dopo aver commesso due errori
consecutivi di accesso.

237
_________________________________________________________________

/ 2 errori consecutivi di login / login
/ sblocco
/ logout
Bloccato
Loggato

Figura 61 - Statechart Amministratore

LUtente prevede una situazione leggermente complicata, in quanto si parte
da uno stato iniziale in cui lutente non registrato. Una volta eseguita la
registrazione, lutente passa nello stato registrato ed allinterno di esso pu evolvere
tra gli stessi stati dellamministratore, ossia loggiato e bloccato, sulla base dei
medesimi eventi.
Lo Statechart Diagram prevede una struttura innestata, nellambito della quale
allinterno dello stato registrato previsto un ulteriore diagramma che descrive le
possibili transizioni di stato dellutente che ha eseguito la registrazione.

238
_________________________________________________________________

/ registrazione Utente
/ cancellazione Utente
/ 2 errori consecutivi di login
/ sblocco
/ login
/ logout
Bloccato Loggato
Registrato

Figura 62 - Statechart Utente

Il BranoMP3 ha unevoluzione notevolmente complicata, considerando che
si parte da una condizione in cui il brano non stato inserito nellarchivio ed
eseguendo tale operazione, si passa allo stato archiviato. In corrispondenza di tale
stato, il brano pu subire diverse transizioni :

- passare nello stato di in ascolto;
- passare nello stato di acquistato;
- passare nello stato in playlist;

239
_________________________________________________________________
Lo stato acquistato a sua volta prevede la possibilit, da parte del brano, di passare
nello stato di downloading, considerando che la condizione necessaria per scaricare
un brano effettuarne lacquisto. Allo stesso modo, lo stato in playlist permette al
brano di passare nello stato in ascolto ed acquistato, per poter esplicitare il fatto
che lascolto e lacquisto di un brano MP3 possono essere eseguiti nei casi in cui
lutente abbia o meno delle playlist preferite.

/ inserimento brano
/ cancellazione brano
/ ascolta
/ fine ascolto
/ acquista
/ acquistoeseguito
/ aggiungi a playlist
/ cancelladaplaylist
InAscolto
/ avviodownload
/ terminedownload
Downloading
Acquistato
/ascolta
/fine ascolto
/acquista
/acquisto eseguito
inAscolto Acquistato2
InPlaylist
Archiviato

Figura 63 - Statechart BranoMP3
240
_________________________________________________________________

/ avvio download
/ termine download
Downloading

/ ascolta
/ fine ascolto
/ acquista
/ acquisto eseguito
in Ascolto Acquistato2

Figura 64 - Statecharts BranoMP3 acquistato/in playlist

Loggetto CartaCredito unevoluzione abbastanza semplice, in quanto
lunico stato in cui pu transitare in verifica, nellambito del quale il sistema sta
valutando se la carta di credito sia coperta o meno.

/ verifica copertura
/ termine verifica
In Verifica

Figura 65 - Statechart CartaCredito

241
_________________________________________________________________
La Playlist pu essere paragonato al BranoMP3 ma con una complessit
inferiore. Eseguendo loperazione di creazione, la Playlist passa nello stato
archiviata, nellambito del quale pu trovarsi o meno nello stato di ascolto.

/ creazione
/ cancellazione
/ ascolta
/ fine ascolto
Ascolto
Archiviata

Figura 66 - Statechart Playlist

Loggetto SchedaPrepagata prevede probabilmente una delle evoluzioni pi
complesse. Effettuando loperazione di acquisto, da parte dellutente, la scheda passa
nello stato acquistata, allinterno del quale pu effettuare diverse transizioni.

242
_________________________________________________________________

/ acquisto
/ scaduta
Acquistata

Figura 67 - Statechart SchedaPrepagata

Lo stato acquistata composto, per cui allinterno di esso pu essere definito un
ulteriore Statechart Diagram certamente pi complesso.

/ richiesta ricarica
/ termine ricarica
/ acquisto brano
/ importo residuo esaurito
/ importo residuo aggiornato
/ scadenza scheda
Ricaricata Esaurita
In Uso
Scaduta

Figura 68 - Statechart SchedaPrepagata acquistata

243
_________________________________________________________________
Allinterno del diagramma si possono evidenziare i seguenti stati :

- scaduta : quando la data odierna va oltre la data di scadenza della scheda;
- in uso : quando ne viene aggiornato limporto residuo, perch stato
effettuato lacquisto di un brano MP3;
- esaurita : quanto limporto residuo azzerato;
- ricaricata : quando viene eseguita unoperazione di ricarica;

3.5 Conceptual Data Model

La definizione del modello concettuale rappresenta il primo passo verso la
progettazione della base di dati. Esso permette di descrivere tutte quelle che sono le
entit del mondo reale e le relazioni che ci sono fra di esse. Inoltre, per ciascuna
entit o relazione che sia, possibile definirne gli attributi caratteristici. In un certo
senso, lo stesso Class Diagram pu essere considerato in moltissimi casi il modello
concettuale di un database, poich le entit e le relazioni rappresentate sono
praticamente le stesse, a meno di un formalismo differente.
Facendo riferimento alla Web application in esame, le entit del modello sono le
seguenti :

- AccessoUtente ed AccessoAmministratore : rappresentano le informazioni di
accesso dellutente e dellamministratore. Esse rappresentano una
specializzazione dellentit Accesso, alla quale sono legate con una relazione del
tipo Generalizzazione/Specializzazione.
- Utente ed Amministratore : definiscono le informazioni di un utente e
dellamministratore. Sono una specializzazione dellentit Ruolo;
- BranoMP3 : contiene le informazioni di un brano MP3;
- Playlist : rappresenta la generica playlist creata da un utente;
- SchedaPrepagata : rappresenta le informazioni della scheda prepagata;

E da osservare che, rispetto al Class Diagram non presente lentit CartaCredito, in
virt del fatto che lapplicazione non memorizza in maniera permanente le sue
244
_________________________________________________________________
informazioni allinterno della base di dati, ma utilizza sempre un oggetto in memoria
che al termine dei controlli necessari viene distrutto.

Inoltre, le relazioni che legano queste entit sono :

- LoginLogout Utente : associa a ciascun Utente le relative informazioni di accesso
dellentit AccessoUtente;
- LoginLogout Amministratore : associa lAmministratore alle informazioni relative
agli accessi eseguiti dellentit AccessoAmministratore;
- Download : associa lUtente con un BranoMP3. E da osservare che nel Class
Diagram, questa entit rappresentata da una classe associativa;
- Creazione : lega lUtente con la Playlist. Essa non presente nel Class Diagram;
- Composizione : descrive la composizione di una playlist, associando un
BranoMP3 con la Playlist di appartenenza. E prevista anche nel Class Diagram
ma con un formalismo diverso, la relazione di aggregazione;
- Acquisto e Ricarica : legano lUtente con la SchedaPrepagata. E da osservare che
tra queste due entit sussistono due relazioni, poich da un punto di vista
concettuale sono differenti e ciascuna di esse ha delle informazioni proprie,
diverse dallaltra;

Infine, per ciascuna entit e per ciascuna relazione sono specificati gli attributi che le
caratterizzano con il corrispondente tipo di dato. E da osservare che alcune relazioni
non hanno attributi, in quanto servono ad esprimere esclusivamente unassociazione
tra due entit ma non hanno informazioni proprie. Nel modello logico, alcune di
queste sono destinate a scomparire, ossia LoginLogout Utente e LoginLogout
Amministratore, mentre Composizione sar necessaria per definire la relazione molti-a-
molti che esiste tra BranoMP3 e Playlist.

245
_________________________________________________________________

<<extends>>
Utente Ruolo
<<extends>>
Amministratore Ruolo
<<extends>>
AccessoUtente Accesso
<<extends>>
AccessoAmministratore Accesso
0,1
1,1
0,n
0,n
0,n
1,1
0,n
1,1
0,n
0,n
0,n
0,n
0,n
1,1
Utente
nome
cognome
indirizzo
citta
provincia
CAP
stato
telefono
dataNascita
sesso
email
acquistoMP3
VA15
VA15
VA50
VA30
VA30
VA5
VA15
VA15
D
A1
VA50
DT
BL
Amministratore
Ruolo
userName
password
bloccato
loggedIn
VA20
VA15
BL
BL
Accesso
dataOraLogin
dataOraLogout
loginValido
tentativo
indirizzoIP
DT
DT
BL
BT
VA15
AccessoUtente
AccessoAmministratore
SchedaPrepagata
importoResiduo
dataScadenza
DC5,2
D
Acquisto
dataOraAcquisto DT
Ricarica
importo
dataOra
DC5,2
DT
LoginLogout Utente
LoginLogout Amministratore
BranoMP3
genere
titolo
autore
album
durata
costo
dimensione
nomeFileMP3
VA15
VA50
VA30
VA50
T
DC3,2
I
VA255
Playlist
nome VA15
Composizione
Download
dataOraAcquisto DT
Creazione
dataOraCreazione DT

Figura 69 - Conceptual Data Model
246
_________________________________________________________________
3.6 Physical Data Model

Per completare la progettazione della base di dati, necessario effettuare la
trasformazione del modello concettuale nel modello logico, anche detto modello
fisico. Questultimo costituito da una serie di tabelle e le relative colonne che
prendono il posto delle entit e delle relazioni con i relativi attributi, presenti nel
modello concettuale. La trasformazione viene eseguita sulla base di una serie di
regole, che permettono di adattare il mondo reale, rappresentato dal modello
concettuale, allimplementazione fisica che verr successivamente adottata per uno
specifico DBMS (DataBase Management System).
Le principali operazioni di trasformazione sono le seguenti :

- eliminare tutte le relazioni del tipo Generalizzazione/Specializzazione, sulla
base di tre possibili alternative;
1. accorpamento delle entit figlie nel padre, con lintroduzione di un
attributo che le possa distinguere;
2. accorpamento del padre nelle entit figlie;
3. sostituzione delle generalizzazioni con semplici associazioni;
- scegliere uno o pi attributi di ciascuna entit che possano costituirne una
chiave primaria, ossia tale da individuare ogni istanza dellentit stessa in
maniera univoca. Nel caso in cui lentit non sia caratterizzata da attributi con
questo tipo di funzionalit, possibile introdurre un nuovo attributo che
abbia il solo ruolo di chiave primaria;
- ogni entit va rappresentata con una tabella, le cui colonne sono esattamente
gli attributi dellentit stessa;
- una relazione uno-a-molti tra due entit non viene rappresentata con una
tabella ma viene assorbita dallentit lato uno;
- una relazione molti-a-molti viene rappresentata attraverso una tabella che sar
legata alle due tabelle relative alle entit in gioco, sulla base delle loro chiavi
primarie;
- una relazione uno-a-uno non viene rappresentata attraverso una tabella ma
assorbita indifferentemente da una delle entit legate;

247
_________________________________________________________________

FK_IDUTENTE
FK_IDBRANOMP3
FK_IDUTENTE
FK_IDSCHEDAPREPAGATA
FK_IDPLAYLIST
FK_IDBRANOMP3
FK_IDUTENTE
FK_IDAMMINISTRATORE
FK_IDUTENTE
Utente
idUtente
nome
cognome
indirizzo
citta
provincia
CAP
stato
telefono
dataNascita
sesso
email
acquistoMP3
userName
password
bloccato
loggedIn
int
varchar(15)
varchar(15)
varchar(50)
varchar(30)
varchar(30)
varchar(5)
varchar(15)
varchar(15)
date
char
varchar(50)
datetime
bool
varchar(20)
varchar(15)
bool
bool
<pk>
SchedaPrepagata
idSchedaPrepagata
idUtente
importoResiduo
dataScadenza
dataOraAcquisto
int
int
decimal(5,2)
date
datetime
<pk>
<fk>
Ricarica
idRicarica
idSchedaPrepagata
importo
dataOra
int
int
decimal(5,2)
datetime
<pk>
<fk>
BranoMP3
idBranoMP3
genere
titolo
autore
album
durata
costo
dimensione
nomeFileMP3
int
varchar(15)
varchar(50)
varchar(30)
varchar(50)
time
decimal(3,2)
int unsigned
varchar(255)
<pk>
Download
idUtente
idBranoMP3
dataOraAcquisto
int
int
datetime
<fk1>
<fk2>
Playlist
idPlaylist
idUtente
nome
dataOraCreazione
int
int
varchar(15)
datetime
<pk>
<fk>
Accesso
idAccesso
idRuolo
ruolo
dataOraLogin
dataOraLogout
loginValido
tentativo
indirizzoIP
int
int
char
datetime
datetime
bool
tinyint unsigned
varchar(15)
<pk>
<fk1,fk2>
Amministratore
idAmministratore
userName
password
bloccato
loggedIn
int
varchar(20)
varchar(15)
bool
bool
<pk>
ComposizionePlaylist
idPlaylist
idBranoMP3
int
int
<fk1>
<fk2>
ruolo : distingue tra le entit figlie (AccessoUtente ed
AccessoAmministratore)
idRuolo : l'ID di un Utente o di un Amministratore

Figura 70 - Physical Data Model

248
_________________________________________________________________
Sulla base delle regole suddette, il modello logico risultante ha le seguenti
caratteristiche :

- in tutte le tabelle stato introdotto un attributo (colonna) che ne rappresenti
la chiave primaria, con un nome del tipo idNomeTabella per esprimere che
si tratta di un identificativo univoco;
- la relazione Generalizzazione/Specializzazione avente come padre lentit
Accesso e come figlie le entit AccessoUtente ed AccessoAmministratore stata
eliminata accorpando queste ultime nel padre. Per poter distinguere le
occorrenza delluna e dellaltra, stata introdotto lattributo ruolo nella
tabella Accesso definitiva. La scelta della soluzione da adottare basata sul
fatto che le due entit figlie sono caratterizzate da occorrenza
concettualmente diverse ma che hanno le medesime informazioni;
- la relazione Generalizzazione/Specializzazione avente come padre lentit
Ruolo e come figlie le entit Utente ed Amministratore stata eliminata
accorpando allinterno di queste ultime, lentit padre. Tutto ci determina la
presenza di due tabelle distinte per lutente e per lamministratore ed da
sottolineare che la scelta fatta motivata dalla presenza di informazioni
completamente diverse che caratterizzano i due utilizzatori;
- le relazioni uno-a-molti da Utente ed Amministratore verso Accesso, sono state
risolte introducendo allinterno di questultima tabella una chiave esterna
idRuolo che corrisponde alle chiavi primarie idUtente ed
idAmministratore. E da osservare che lidentificazione univoca di un
accesso, appartenente ad un utente oppure allamministratore, individuata
dalla coppia idRuolo-ruolo;
- la relazione molti-a-molti tra Utente e BranoMP3 stata trasformata nella
tabella Download contenente le chiavi primarie di queste ultime. Esse,
considerate in coppia, formano la chiave primaria della tabella stessa;
- la relazione uno-a-molti tra Utente e Playlist stata assorbita dal lato uno
(Playlist) trasferendone il proprio attributo. Per questo motivo, la tabella
Playlist ha una chiave esterna che la lega alla tabella Utente;
249
_________________________________________________________________
- la relazione molti-a-molti tra BranoMP3 e Playlist relativa alla composizione di
questultima stata trasformata nella tabella Composizione, che contiene
semplicemente le chiavi primarie delle due tabelle legate;
- la relazione uno-a-uno tra Utente e SchedaPrepagata poteva essere risolta
attraverso una sola tabella, ma in questo caso si sarebbe persa la differenza
concettuale che c tra le due entit. Per questo motivo sono state definite
due tabelle separate e la relazione stata assorbita dal lato SchedaPrepagata,
contenendo attributi che riguardano strettamente questultima;
- la relazione molti-a-molti tra Utente e SchedaPrepagata relativa alle operazioni di
ricarica stata trasformata nella tabella Ricarica. Essa prevede una chiave
esterna che la lega alla tabella SchedaPrepagata. Il legame con la tabella Utente
stato eliminato in quanto, non solo dal punto di vista concettuale la ricarica
strettamente legata alla scheda, ma anche perch si sarebbe venuta a creare
uninutile relazione circolare. E sempre possibile passare dallUtente alla
Ricarica attraverso la SchedaPrepagata;

Oltre queste trasformazioni, sono stati introdotti dei particolari vincoli (costraints) di
cascade sugli eventi onDelete, in modo da non lasciare informazioni inutili che
rendano il database sporco. Qui di seguito sono elencate le tabelle interessate, le
chiavi esterne e le motivazioni dei vincoli :

- le due chiavi esterne della tabella Composizione, in modo che se viene
cancellato un brano MP3 dallarchivio, esso scompare anche dalle
composizioni delle playlist. Inoltre, se viene cancellata una playlist, vengono
cancellati tutti i riferimenti ai brani che la componevano;
- le due chiavi esterne della tabella Download, in modo che se si cancella un
utente si perdono anche le tracce dei brani scaricati, cos come se viene
cancellato un brano non si hanno pi riferimenti agli utenti che ne hanno
eseguito il download;
- la chiave esterna della tabella SchedaPrepagata verso Utente, in modo che
cancellando un utente vengono automaticamente eliminate le informazioni di
uneventuale scheda prepagata ad esso associata;
250
_________________________________________________________________
- la chiave esterna della tabella Ricarica, in modo che cancellando una scheda
prepagata vengono eliminate anche tutte le operazioni di ricarica eseguite su
di essa;
- la chiave esterna della tabella Playlist, in modo che cancellando un utente
siano eliminate anche le playlist ad esso associate;

Attraverso i legami che ci sono tra le tabelle ed i vincoli di cascade definiti sugli
eventi onDelete, si determinano delle operazioni di cancellazione a catena che
permettono di lasciare nel database solo ed esclusivamente i dati necessari. Ad
esempio, cancellando un utente vengono eliminate le playlist ad esso associate e
quindi le informazioni della loro composizione, nonch un eventuale scheda
prepagata con tutte le operazioni di ricarica ed infine le operazioni di download dei
brani MP3. Questo il pi completo degli scenari che si possa presentare nelle
operazioni di cancellazione delle informazioni dalla base di dati.

251
Capitolo VI Case Study : Implementazioni a confronto
_________________________________________________________________
C Ca ap pi it to ol lo o V VI I C Ca as se e S St tu ud dy y : : I Im mp pl le em me en nt ta az zi io on ni i a a c co on nf fr ro on nt to o

1. Introduzione

Il confronto tra due tecnologie, che nel caso specifico sono i due
framework di sviluppo Web Struts e JavaServer Faces, pu essere considerato
effettivamente valido soltanto nel momento in cui viene supportato da una prova sul
campo. Infatti, non basta semplicemente descrivere in maniera puramente discorsiva
le caratteristiche delluno e dellaltro framework, ma necessario applicare le due
tecnologie ad un medesimo caso di studio, per poter dare maggior risalto al
confronto teorico.
Per questo motivo, la Web application precedentemente progettata stata
implementata sia con Struts che JSF, in modo da valutare con quali modalit i due
framework permettano di realizzare le medesime funzionalit. Ovviamente, facendo
seguito alla stessa fase di Progettazione, il sistema software risultante ha
unarchitettura diversa per ciascuna tecnologia, sulla base delle potenzialit che
differenziano luna dallaltra.
I termini di paragone possono riguardare :

- la semplicit con cui un framework permetta di realizzare una funzionalit
rispetto allaltro, attraverso gli strumenti che fanno parte della propria
architettura;
- la necessit da parte di un framework di utilizzare strumenti esterni alla
propria implementazione;
- la possibilit di estensione e la flessibilit di un framework rispetto allaltro, in
modo da poter definire degli strumenti di sviluppo personalizzati;

Sulla base di questi aspetti pu essere impostato un confronto pratico, che non faccia
altro che confermare quanto descritto nel Capitolo IV.

252
_________________________________________________________________
Per quanto riguarda il caso di studio preso in esame, gli strumenti software utilizzati
per lo sviluppo e gli ambienti di esecuzione sono i seguenti :

- Piattaforma J2SE (Java 2 Second Edition);
- Ambiente IDE Eclipse 3.1 con i plug-in di Exadel Studio, per lo sviluppo
grafico dei file di configurazione di JavaServer Faces e Struts, e UML Omondo,
per la realizzazione dei Class Diagrams per le classi implementate;
- Web Container/Server Jakarta Apache Tomcat 5.0.28;

La piattaforma J2SE (Java2 Standard Edition) rappresenta la base per lo sviluppo e
lesecuzione delle applicazioni Java, in quanto mette a disposizione la JVM (Java
Virtual Machine), oltre a tutte le classi principali e le librerie del linguaggio.
Unestensione di questa piattaforma rappresentata dalla J2EE (Java2 Enterprise
Edition) che fornisce il supporto per strumenti avanzati come i Web Services, gli EJB
(Enterprise Java Beans) e JavaServer Faces. In questo caso, non si reso necessario
lutilizzo della piattaforma J2EE, in quanto la distribuzione del framework JSF pu
essere gestita anche semplicemente mediante le librerie JAR (Java ARchive) che
contengono le classi dellarchitettura. Nelle successive versioni della piattaforma Java,
in particolare a partire dalla Java5, JSF ne diventer parte integrante.
Per lambiente di sviluppo IDE (Integrated Development Environment), la scelta
caduta sul progetto OpenSource Eclipse 3.1, dopo un rapido confronto con
lantagonista NetBeans. Ha nettamente prevalso il primo, considerando il supporto
fornito per lo sviluppo di applicazioni Web basate appunto su Struts e JSF, grazie al
plug-in free di Exadel. Il secondo, invece, fino alla versione 4.1 non ha ancora fornito
tale supporto, introdotto a partire dalla versione 5 in fase di Beta Testing. Prendendo
in esame tale versione, la semplicit ed il supporto offerti da Eclipse 3.1 sono
comunque nettamente superiori.
Lambiente stato ulteriormente ampliato utilizzando il plug-in free di Omondo per
la realizzazione dei diagrammi UML, a partire dalle classi implementate. Tale
strumento stato utilizzato solo ed esclusivamente per generare i Class Diagrams a
livello di implementazione.
253
_________________________________________________________________
Per quanto riguarda il Web Container, la scelta ovviamente caduta sul progetto
OpenSource Jakarta Apache Tomcat 5.0.28, sicuramente tra i migliori per
lesecuzione di applicazioni Web realizzate in ambiente Java.
E altres necessario specificare che, per quanto riguarda Struts, stata utilizzata la
versione 1.1 mentre per JavaServer Faces stata scelta limplementazione JSF-RI
(Refernce Implementation) 1.0 e non MyFaces. In questo modo, possibile
confrontare due tecnologie realizzate da sviluppatori diversi, in quanto Struts rientra
tra i progetti Jakarta, cos come MyFaces, mentre JSF-RI stato realizzato dalla Sun
Microsystems.

2. Struttura dellapplicazione

Il primo aspetto preso in considerazione riguarda la struttura
dellapplicazione, in termini di eventuali moduli che la compongono, oltre che delle
pagine, le immagini, gli eventuali fogli di stile (CSS) e di tutti gli altri elementi che ve
ne fanno parte.
Per quanto riguarda limplementazione con JSF, larchitettura del sistema prevede un
unico modulo al quale ovviamente associato un file di configurazione (faces-
config.xml). I file componenti il progetto riguardano lapplet che implementa il player
MP3 per lascolto dei brani, i templates che definiscono il layout delle pagine
mediante lutilizzo di Tiles ed il relativo file delle definizioni (tiles-defs.xml), le pagine
ed i relativi contenuti, le immagini, il foglio di stile (styles.css) per la formattazione della
grafica ed un Tag Library Descriptor (components.tld) che contiene i tag associati ai
componenti della UI implementati. Infine, oltre alla librerie che contengono le classi
costituenti larchitettura del framework, sono utilizzati i seguenti gruppi di ulteriori
librerie :

- JavaMail : framework per linvio delle mail basato su JAF (JavaBeans
Activation Framework);
- JDBC MySQL Connector : contiene le classi relative ai driver JDBC (Java
DataBase Connectivity) per laccesso alla base di dati realizzata con il DBMS
MySQL;
254
_________________________________________________________________
- Tiles : framework per la definizione del layout delle pagine;
- Java MP3 Tag Library : classi per laccesso ai tag ID3v1 dei file MP3;
- Commons Project File Upload e Tomahawk : contiene una serie di funzionalit
aggiuntive, tra cui il componente per eseguire lupload di un file sul server;

Per quanto riguarda limplementazione con Struts, lapplicazione ha unarchitettura
che prevede tre moduli distinti :

- default : modulo principale che fornisce le funzionalit generiche di login,
registrazione di un nuovo utente e richiesta dei dati di accesso via mail;
- user : modulo contenente tutte le funzionalit disponibili ad un utente
registrato;
- admin : modulo che fornisce le funzionalit per lamministratore;

Ciascuno di questi moduli ha il proprio file di configurazione allinterno del quale
descrivere il mapping delle action, i forward, le pagine e le eccezioni.
Il modulo default viene avviato al momento della prima richiesta di un client. Nel
momento in cui lutilizzatore effettua unoperazione di login, in base al fatto che si
tratti di un utente oppure dellamministratore, viene eseguito lo switch verso il
modulo corrispondente. Invece, se viene eseguita unoperazione di registrazione,
poich questa seguita da un login automatico, si passa direttamente al modulo
user. Il passaggio inverso dai moduli user e admin verso il modulo default viene
effettuato in seguito ad unazione di logout.
Attraverso la scomposizione in moduli, non soltanto si ha il notevole vantaggio di
raggruppare concettualmente le funzionalit legate ad un particolare utilizzatore ma
anche quello di dover gestire tre file di configurazione differenti di dimensione
ridotta, in luogo di un unico file di grandi dimensioni.
La struttura in termini di file prevede, similmente a JSF, lapplet che implementa il
player MP3, i templates per il layout delle pagine mediante Tiles ed il relativo file
delle definizioni (tiles-defs.xml), le pagine ed i relativi contenuti, le immagini, il foglio di
stile (styles.css) per la formattazione della grafica. Tali file sono opportunamente
separati in corrispondenza dei tre moduli.

255
_________________________________________________________________
Oltre alle librerie proprie di Struts, che includono Tiles ed il plug-in Validator, sono
utilizzati anche i seguenti gruppi di librerie :

- JavaMail : framework per linvio delle mail basato su JAF (JavaBeans
Activation Framework);
- JDBC MySQL Connector : contiene le classi relative ai driver JDBC (Java
DataBase Connectivity) per laccesso alla base di dati realizzata con il DBMS
MySQL;
- Java MP3 Tag Library : classi per laccesso ai tag ID3v1 dei file MP3;
- JSTL : contiene i tag, che sfruttano lExpression Language, per la costruzione
del contenuto delle pagine;

Rispetto allimplementazione in JSF, si evince che il framework Tiles incluso nella
distribuzione di Struts ed perfettamente integrato con questultimo, cos come non
necessario il Commons Project File Upload, in quanto la libreria Struts HTML
fornisce un tag per lupload di file. Lutilizzo di JSTL pu essere considerato non
necessario, in quanto le librerie del framework forniscono tutto il necessario, anche
se JSTL supporta lExpression Language che permette di semplificare laccesso alle
propriet dei JavaBeans mediante lutilizzo della dot notation.
Il plug-in Exadel dellambiente Eclipse mette a disposizione la possibilit di realizzare
i file di configurazione di Struts in modalit grafica, stabilendo le relazioni che ci sono
tra le pagine, le action ed i forward. La medesima funzionalit non offerta per
JavaServer Faces, per cui di seguito viene riportata la struttura dei tre moduli che
costituiscono la Web application in Struts.

256
_________________________________________________________________

Figura 1 - Struts : Modulo "default"

257
_________________________________________________________________

Figura 2 - Struts : Modulo "admin"

258
_________________________________________________________________

Figura 3 - Struts : Modulo "user"
259
_________________________________________________________________
Per quanto riguarda il modulo default, si osserva che dalla homepage sia possibile
accedere alla funzionalit di login e di registrazione, seguita dalleventuale acquisto
della scheda prepagata. Inoltre, possibile richiedere linvio di una mail contenente i
dati di accesso in caso di dimenticanza. Si osservi che sono definiti due forward,
associati ad una SwitchAction, che permettono di passare al modulo user oppure
admin. Infine, definita uneccezione globale nel caso si verifichi un errore di
accesso alla base di dati.
La struttura del modulo user prevede laccesso alle seguenti funzionalit :

- modifica dei dati dellutente;
- acquisto e ricarica della scheda prepagata;
- visualizzazione e ricerca dei brani MP3;
- gestione delle playlist;
- ascolto brani e playlist;
- operazione di logout, associata ad una SwitchAction, che permette di tornare al
modulo default;

Anche in questo caso definita uneccezione globale nel caso si verifichi un errore di
accesso alla base di dati.
Infine, larchitettura del modulo admin fornisce i seguenti servizi :

- modifica dei dati dellamministratore;
- gestione degli utenti;
- visualizzazione e ricerca dei brani MP3;
- inserimento, modifica ed ascolto dei brani MP3;
- operazione di logout, associata ad una SwitchAction, che permette di tornare al
modulo default;

Analogamente agli altri due moduli, definita uneccezione globale che viene
sollevata qualora si verifichi un errore di accesso alla base di dati.
Per completare lanalisi della struttura complessiva della Web application, bisogna
descrivere quelli che sono i package contenenti le classi ed il loro ruolo.
260
_________________________________________________________________
Le due implementazioni hanno dei package comuni, in base al fatto che le
funzionalit sono sostanzialmente le stesse. Ovviamente, le classi contenute
allinterno di essi possono presentare delle differenze. Nel dettaglio, i package
comuni sono i seguenti :

- accesso : classi relative alle informazioni di accesso dellutente e
dellamministratore;
- cartacredito : classe relativa alla carta di credito;
cesso alla base di dati. E da sottolineare che
elle due implementazioni, a meno
caso si verifichi un errore di accesso
riferimento al pattern MVC ed in particolare ai
osserva che questo package costituisce il Data Access
- lativa allacquisto e download dei brani;
- exception : classi che implementano delle eccezioni personalizzate, estendendo
oni;
trollo;
- mail : classe per linvio delle mail;
list;
mentano i possibili utilizzatori del sistema;
a ed alle corrispondenti ricariche;

I pa a

- components : classi che implementano dei Custom Components, realizzati per
ors, utilizzati per la
- brani : classi relative ai brani ed i corrispondenti file MP3;
- database : classi relative allac
questo package perfettamente uguale n
della tipologia di eccezioni sollevate nel
al database. Facendo
sottolivelli del Model, si
Sublayer, completamente indipendente dai sottolivelli che lo precedono;
download : classe re
la classe di base Exception. Anche questo package perfettamente uguale nelle
due implementazi
- listeners : classi che intervengono in particolari situazioni di con
- playlist : classi per la gestione delle play
- ruolo : classi che imple
- scheda : classi relative alla scheda prepagat
ck ge specifici dellimplementazione con JavaServer Faces sono i seguenti :
linterfaccia utente (UI);
- validators : classi che implementano alcuni Custom Validat
validazione dei dati;

261
_________________________________________________________________
Infine, i package relativi allimplementazione con Struts sono :

- defaultactions : classi che implementano le action del modulo default;
- adminactions : classi che implementano le action del modulo admin;
- useractions : classi che implementano le action del modulo user;
- ealizza un Controller personalizzato;
ntre i restanti sono
el file di configurazione;

Un ult
dalla W
particol
unulter no i
mes g , a meno di alcuni
mes g
framew
Infine, ci sono da motivare le scelte relative alla realizzazione del Model,
sos z
In entrambi i casi, il sottolivello Data Access completamente indipendente dagli
altr perfettamente uguali tra le due
implementazioni. Questo ne favorisce la portabilit, qualora si prenda in
con e rk
ifferente. Per quanto riguarda i sottolivelli di Business Logic ed External Interface,
che
eglio si adattino ai due framework : separazione e fusione.
Per u
realizzando i backing beans in modo tale da contenere la business-logic e
lint a
dover realizzare un ulteriore strato di classi che implementi lExternal Interface
blayer, il cui scopo sia quello di invocare i metodi sulle classi della business-logic ed
utilizzare gli oggetti interni al framework. Lo svantaggio ovviamente la perdita di
- commonactions : classi che implementano alcune action comuni a pi moduli;
controller : classe che r
- formbean : classi che implementano alcuni dei formbean, me
di tipo dinamico ed dichiarati esclusivamente n
- plugin : classe che realizza un plug-in per linizializzazione di alcuni dati;
eriore considerazione riguarda linternazionalizzazione (I18N), supportata
eb application attraverso la definizione di due Resource Bundle. In
are, ne previsto uno per la localizzazione di default, ossia lItalia, e laltro per
iore localizzazione supportata, in lingua Inglese. I file che contengo
sa gi sono perfettamente identici nelle due implementazione
sa gi relativi agli errori di validazione, che hanno chiavi diverse in relazione al
ork utilizzato.
tan ialmente diverso tra le due implementazioni.
i e le classi che lo implementano sono
sid razione lipotesi di realizzare la Web application con un ulteriore framewo
d
si fatta una scelta diversa per evidenziare le due possibili modalit di approccio
m
q anto riguarda JavaServer Faces, si utilizzato lapproccio di fusione,
erf cciamento con le classi del framework. Tale scelta ha il vantaggio di non
su
262
_________________________________________________________________
portabilit, in quanto i backing beans utilizzano delle classi che non sarebbero
resenti in framework diversi.
Nel s lassi che
imp vocano i
met i amente da
inte c te
ind n dere agli oggetti di
que u
portabi con
fram w delle
ction, che comunque previsto dalla struttura del framework.
default. Seppur in maniera
nte dellutilizzatore;
p
ca o di Struts, la scelta in un certo senso obbligatoria, in quanto le c
lementano le action accedono agli oggetti propri del framework ed in
od delle classi della business-logic, fungendo automatic
rfa ciamento. La Business-logic, invece, prevede delle classi completamen
ipe denti dal framework, in quanto non hanno lonere di acce
st ltimo, grazie allintervento delle action. Il vantaggio rappresentato dalla
lit in quanto il medesimo strato di business-logic pu essere adottato
e ork differenti, lo svantaggio dato dalla presenza dello strato in pi
a
Si osserva che le scelte hanno i propri pregi e difetti e ciascuna di esse pu essere
considerata ugualmente valida cos come le altre. In molti casi, la propensione verso
una di esse pu dipendere dal framework e dalle dimensioni dellapplicazione da
realizzare.

3. Controller

Ciascuno dei due framework fornisce le proprie classi di base che
implementano la struttura del Controller di
completamente diversa, possibile intervenire in Struts e JSF per poter
personalizzare tali classi, in modo da aggiungere particolari funzionalit che vanno
applicate durante la fase di comunicazione tra Model e View. Nel caso di studio in
esame, si reso necessario lintervento sul Controller, per poter gestire due situazioni
particolarmente delicate :

- la gestione delle sessioni non concluse correttame
- la possibilit di accesso a pagine protette senza la necessaria operazione di
login;

La prima problematica stata risolta allo stesso modo nelle due implementazioni, in
quanto pi legata alla gestione delle Servlet che non alle classi di uno specifico
263
_________________________________________________________________
framework. Il secondo problema stato affrontato in maniera completamente
diversa, considerando la differente architettura che assume il Controller in Struts e
te la fase di logout, le informazioni di accesso vengono aggiornate
opportunamente la data e lora di uscita dal sistema, nonch viene azzerato
base per segnalare che lutente offline. Ci sono moltissime situazioni
cui un utente chiude direttamente il browser, senza completare correttamente il
logout. I
el browser, a meno che questa azione non venga eseguita
mpre mediante codice. Per questo ed altri motivi, stato introdotto il concetto di
sess n utilizza
lap c
associat ncetto di timeout, per cui se non si rileva attivit da parte dellutente
no allo scattare di questultimo, ne viene eseguita linvalidazione. E in
JSF.

3.1 Gestione delle sessioni

Uno dei principali problemi da cui sono afflitte tutte le Web application,
la gestione delle sessioni che non vengono concluse correttamente da un utente. Nel
caso specifico, quando lutilizzatore, utente o amministratore che sia, effettua il login
al sistema, vengono memorizzate allinterno della base di dati le informazioni relative
allaccesso, ossia la data ed lora di ingresso, lindirizzo IP del client ed il numero di
tentativi effettuati. Inoltre, viene settato un flag nel database che indica che lutente
online, in modo che un tentativo fraudolento di accesso da parte di un secondo
utente che disponga dei dati del primo, venga ovviamente bloccato. Nelleffettuare
correttamen
settando
il flag nel data
in
n questo caso necessario intervenire per ristabilire la coerenza delle
informazioni contenute nel database rispetto alla realt. Levento di chiusura del
browser non pu essere intercettato dal server, sul quale in esecuzione la Web
application, ma ovviamente solo dal client. Il linguaggio di scripting lato client, che
permette di eseguire elaborazioni su questultimo ovviamente il JavaScript, il quale
per non mette a disposizione la possibilit di intercettare un semplice evento come
la chiusura di una finestra d
se
io e, mediante la quale si stabilisce un legame tra lutente che
pli azione ed il server, su cui questultima in esecuzione. Alla sessione
o un co
fi
corrispondenza di questo evento, che si pu intervenire effettuando le operazioni che
garantiscano la coerenza delle informazioni nel sistema. Da qui, la necessit di
264
_________________________________________________________________
realizzare un listener, che allo scadere del timeout di sessione, intervenga per poter
permettere allo sviluppatore di effettuare delle elaborazioni necessarie.
La realizzazione di un listener di questo tipo favorita dallutilizzo dellinterfaccia
ttpSessionListener e della classe HttpSessionEvent. La prima mette a disposizione i
metodi da eseguire al momento della creazione e distruzione di una sessione, mentre
sessione stessa.
Per entrambe le implementa
H
la seconda permette di ricavare un riferimento alla
zioni stata realizzata la classe InactivityListener,
nellambito della quale il metodo sessionCreated() ha il compito di settare il timeout di
sessione e sessionDestroyed() ha lonere di cambiare lo stato del flag nel database, per
segnalare che lutente offline. Questultimo metodo viene appunto invocato nel
momento in cui scatta il timeout, in quanto lutente non sta pi generando attivit sul
server e presumibilmente ha chiuso il browser senza eseguire correttamente il logout.

Figura 4 - JSF e Struts : InactivityListener

Questo aspetto non pu essere considerato un termine di confronto tra i due
framework, in quanto le classi in gioco non sono specifiche di Struts e JSF, ma
rientrano nellarchitettura delle Servlet in generale.
Inoltre, la configurazione che specifica lutilizzo del listener uguale per entrambi i
framework e non prevede lintervento sui file faces-config.xml e struts-config.xml, ma
bens sul Deployment Descriptor web.xml mediante la seguente dichiarazione :

<l i st ener >
<l i st ener - cl ass>l i st ener s. I nact i vi t yLi st ener </ l i st ener - cl ass>
</ l i st ener >

265
_________________________________________________________________
3.2 Protezione pagine

La seconda problematica in cui necessario lintervento sul Controller,
riguarda la possibilit che un utilizzatore voglia accedere alle pagine protette
dellapplicazione, senza avere eseguito correttamente loperazione di login.
Ovviamente, il sistema deve intercettare unazione di questo tipo, redirezionando
ifferente, data la diversa struttura del Controller, i punti in cui possibile estendere
questultimo ed il differente ciclo di vita a cui sottoposta una generica richiesta.
Per quanto riguarda JavaServer Faces, noto che la gestione di una richiesta del
client viene eseguita attraverso sei fasi distinte. In corrispondenza di ciascuna di esse,
pu essere utilizzato un listener che permetta di eseguire delle operazioni prima e
dopo lesecuzione della fase stessa. La soluzione adottata prevede la realizzazione
della classe LoginCheck che implementa linterfaccia PhaseListener ed esegue i controlli
necessari prima della fase di Render Response. Essa prevede che il metodo
afterPhase() sia vuoto, mentre allinterno del metodo beforePhase() ci sia il controllo che
lutilizzatore, utente o amministratore che si ente loggato oppure la
chiesta si riferisca a pagine non protette da login. Nel caso di esito positivo, la
rificatesi, ossia lesecuzione della
lutente alla homepage, nella quale costretto ad eseguire laccesso. Dallanalisi del
problema, si evince che lintervento deve essere eseguito per ciascuna richiesta che
arrivi dal client, in modo da sincerarsi che lutilizzatore sia correttamente loggato,
qualunque sia la pagina a cui vuole accedere, escluse le pagine relative alla
registrazione ed alla richiesta dei dati di accesso via mail.
I due framework prevedono una risoluzione della problematica completamente
d
a, risulti correttam
ri
navigazione procede normalmente, altrimenti viene ricavato un riferimento al
NavigationHandler, il quale permette di spostare il flusso dellapplicazione verso la
homepage. Le informazioni relative allevento ve
fase di Render Response, sono contenute nella classe PhaseEvent.

266
_________________________________________________________________

Figura 5 - JSF : LoginCheck

La configurazione del listener prevede di associare questultimo allistanza della classe
Lifecycle che si occupa di gestire il ciclo di vita di ogni singola richiesta.

<l i f ecycl e>
<phase- l i st ener >l i st ener s. Logi nCheck</ phase- l i st ener >
</ l i f ecycl e>

La soluzione con Struts completamente diversa, in quanto il ciclo di vita di una
richiesta certamente pi semplice e prevede esclusivamente lintervento della classe
RequestProcessor. Per questo motivo, dovendo eseguire delle operazioni di controllo
prima che la richiesta venga elaborata, la soluzione prevede di realizzare la classe
ustomRequestProcessor che estende la classe base RequestProcessor. In realt, osservando
il codice, si evince che la classe estesa TilesRequestProcessor che comunque deriva da
RequestProcessor. E necessaria la derivazione dalla prima, in quanto lutilizzo di Tiles
per il layout prevede lintervento del proprio Controller. Il metodo che contiene il
codice delle operazioni da eseguire processPreprocess(), il quale viene appunto eseguito
prima di iniziare la gestione della richiesta. Se lutilizzatore risulta correttamente
C
267
_________________________________________________________________
loggato, la navigazione prosegue normalmente altrimenti si viene redirezionati alla
homepage.

Figura 6 - Struts : CustomRequestProcessor

E da osservare che la classe CustomRequestProcessor registrata nei moduli admin e
user e non nel modulo default, in quanto questultimo non contiene pagine
rotette, per cui pu utilizzare il
<con ssor Cl ass=" cont r ol l er . Cust omRequest Pr ocessor " / >

. View
RequestProcessor di base. In entrambi i file di p
configurazione struts-config-user.xml e struts-config-admin.xml presente la seguente
dichiarazione :

t r ol l er pr oce
4

La realizzazione dellinterfaccia utente (UI) sicuramente uno degli aspetti
nei quali si evidenzia la netta differenza tra JavaServer Faces e Struts, in quanto il
primo strettamente orientato allo sviluppo del Presentation Layer dellapplicazione.
Per quanto riguarda la produzione delle pagine JSP, limplementazione in Struts ha
previsto lutilizzo delle librerie di tag JSTL, in particolare Core e Formatting, oltre alla
libreria Struts HTML. La libreria Core sostituisce completamente le librerie Struts
Bean e Struts Logic per laccesso alle propriet dei bean e la definizione di costrutti
condizionali allinterno di ciascuna pagina. La libreria Formatting viene utilizzata
soprattutto per la visualizzazione dei messaggi allutente, prelevandoli dal Resource
268
_________________________________________________________________
Bundle. Infine, la libreria Struts HTML contiene tutti i tag necessari alla costruzione
dei form per limmissione dei dati, cos come i tag per la visualizzazione dei messaggi
i errore. La formattazione delle pagine ha previsto prevalentemente luso di tag
HTML, in particolar modo lutilizzo delle tabelle.
Limplementazione in JSF ha previsto lutilizzo delle due librerie proprie del
framework, ossia Core ed HTML, la prima per quanto riguarda aspetti avanzati come
luso dei validatori mentre la seconda per la costruzione dei form, la visualizzazione
dei messaggi e la formattazione del contenuto delle pagine.
Con entrambi i framework stato previsto lutilizzo di Tiles, del quale stato
necessario importarne la libreria in JSF ma non in Struts, essendo incluso nella
distribuzione di questultimo.
Inoltre, sfruttando lenorme potenzialit di JSF, sono stati realizzati dei Custom
Components ed il re da utilizzare questi
omponenti allinterno delle pagine con un corrispondente tag.
.1 Le librerie Standard

Per quanto riguarda le librerie di tag standard che i due framework mettono
dei due prevalga sullaltro. Sia JSF che
nno i propri vantaggi e svantaggi, per quanto concerne i tag che possono
essere uti

d
lativo Tag Library Descriptor, in modo
c
Infine, limplementazione mediante Struts ha previsto lutilizzo dei formbeans per
lacquisizione dei dati dei form, mentre con JSF bastato utilizzare i backing beans e
le relative propriet.

4
a disposizione, si pu affermare che nessuno
truts ha S
lizzati per definire gli elementi costitutivi di ciascuna pagina JSP.
E da osservare, per, che mentre JSF utilizza solo ed esclusivamente le proprie
librerie, Core ed HTML, invece con Struts si preferisce utilizzare le librerie JSTL,
Core e Formatting, in luogo di Struts Bean e Struts Logic, considerando il supporto
per lExpression Language.
Inoltre, c una differenza in termini di configurazione delle librerie da adottare, in
quanto JSF non prevede alcun tipo di modifica nel Deployment Descriptor web.xml,
mentre Struts prevede lelenco delle librerie che verranno utilizzate nellapplicazione.

269
_________________________________________________________________
<t agl i b>
<t agl i b- ur i >/ WEB- I NF/ st r ut s- ht ml </ t agl i b- ur i >
<t agl i b- l ocat i on>/ WEB- I NF/ st r ut s- ht ml . t l d</ t agl i b- l ocat i on>
</ t agl i b>
. . .
<t agl i b>
<t agl i b- ur i >/ WEB- I NF/ c</ t agl i b- ur i >
<t agl i b- l ocat i on>/ WEB- I NF/ c. t l d</ t agl i b- l ocat i on>
</ t agl i b>
. . .

4.1.1 I form : contenuto e layout

Per quanto riguarda la costruzione dei form, entrambi i framework
dispongono di tag equivalenti, ovviamente con sintassi diversa. Un limite di JSF ,
i un brano allinterno
awk. Questultimo prevede una particolare libreria di tag con
nzionalit evolute che rientra nellimplementazione di JavaServer Faces realizzata
dal gruppo Apache, ossia MyFaces. Ovviamente, oltre al TLD (Tag Library
na libreria di classi che permettono di gestire i corrispondenti
tag. Insie
isto il tag
per, rappresentato dalla mancanza di un tag che permetta di selezionare un file
allinterno del file system locale, per poi tresferirlo sul server. Nel caso di studio in
esame, tale funzionalit si resa necessaria per linserimento d
dellarchivio e quindi il caricamento sul server del file MP3 associato. Per ovviare a
questo problema, stato previsto lutilizzo del tag <t:inputFileUpload> facente parte
del progetto Tomah
fu
Descriptor) prevista u
me al progetto Tomahawk, si resa necessaria limportazione del Commons
Project File Upload, sempre del gruppo Apache, contenente le classi che permettono
di gestire il caricamento del file sul server. Tale aspetto rappresenta un vantaggio per
Struts, in quanto allinterno della libreria standard Struts HTML prev
<html:file> che fornisce tale funzionalit. Inoltre, il Commons Project File Upload
contenuto allinterno della distribuzione del framework e non deve essere importato
dallesterno cos come nella JSF RI della Sun Microsystems.

Figura 7 - Form upload file

270
_________________________________________________________________
Da un punto di vista puramente grafico, si evince che non sussiste alcuna differenza
tra a
funzionalit ben diverso tra i due framework.
Un della struttura dei form ed il
po ione in Struts
ha previsto il semplice utilizzo delle tabelle messe a disposizione del linguaggio
TML, in quanto il framework non dispone di tag particolari per poter svolgere un
le due implementazioni, anche se il procedimento adottato per usufruire di quest
a differenza sostanziale riguarda la definizione
sizionamento degli elementi allinterno della pagina. Limplementaz
H
compito di questo tipo.

<ht ml : f or mst yl eI d=" r egFor m" act i on=" / r egi st r azi one. do" >
<t abl e>
<t r >
<t d col span=" 3" cl ass=" f or msHeader Text " >
<f mt : message key=" r egHeader " / >
</ t d>
</ t r >
<t r >
<t d cl ass=" col umsLabel For m" >
<f mt : message key=" r egUser nameLabel " / > *
</ t d>
<t d cl ass=" col umsI nput For m" >
<ht ml : t ext pr oper t y=" user Name" maxl engt h=" 20" / >
</ t d>
<t d cl ass=" er r or Message" >
<ht ml : er r or s pr oper t y=" user Name" / >
<ht ml : er r or s pr oper t y=" r egi st r azi one" / >
</ t d>
. . .

Ben diversa limplementazione in JSF, poich questultimo introduce il concetto di
Panel per la formattazione dei contenuti. Tale concetto ben noto nellambito dello
sviluppo delle applicazione desktop tramite le librerie AWT e Swing ed stato
introdotto nelle Web application, come passo verso ununificazione tra le due
tipologie di applicazioni. La libreria JSF HTML fornisce i tag <h:panelGrid> e
<h:panelGroup> di cui il primo definisce appunto un Panel, costituito da un fissato

mette di raggruppare pi campi, facendo in modo che nel Panel vengano
trattati come un unico elemento. Inoltre, allinterno del Panel possibile specificare
le intestazioni delle colonne, mediante il tag <f:facet>, cos come gli stili da applicare,
efiniti allinterno di un file C

numero di colonne, allinterno del quale vengono disposti gli elementi mentre il
secondo per
d SS esterno.
271
_________________________________________________________________
<h: f or mi d=" r egFor m" >
<h: panel Gr i d col umns=" 3" header Cl ass=" f or msHeader Text "
col umnCl asses=" col umsLabel For m,
col umsI nput For m, col umsEr r or For m" >
<f : f acet name=" header " >
<h: out put Text val ue=" #{bundl e. r egHeader }" / >
</ f : f acet >

<h: out put Text val ue=" #{bundl e. r egUser nameLabel } * " / >
<h: i nput Text i d=" user Name"
val ue=" #{ut ent e. user Name}"
r equi r ed=" t r ue"
maxl engt h=" 20" / >
<h: panel Gr oup>
<h: message f or =" user Name"
st yl eCl ass=" er r or Message" / >
<h: message f or =" r egFor m" i d=" r egEr r or "
st yl eCl ass=" er r or Message" / >
l Gr oup>

4.1. le dei contenuti

otevole differenza riguarda la costruzione condizionale di
una o
men dizioni. Per quanto riguarda JSF,
luni poss o ciascun tag
della libreria JSF HTML. Tale attributo pu assumere un valore booleano che indica
ppunto se il tag ed relativo contenuto debba essere renderizzato o meno. Facendo
i definire dei costrutti condizionali e ciclici.
ome gi detto in precedenza, per, tale libreria non supporta lExpression
Language, per cui un qualsiasi riferimento agli attributi di un bean, deve essere
</ h: pane
. . .
2 Costruzione condiziona
Un ulteriore n
pagina, che consiste nel fare in modo che un certo contenuto sia visualizzato
o onda del verificarsi di opportune con a sec
ca ibilit quella di utilizzare lattributo rendered di cui dotat
a il
uso dellExpression Language e del value-binding, possibile definire unespressione
nella quale entrino in gioco le propriet dei backing beans, in modo da esprimere
condizioni complesse sulla base delle quali visualizzare o meno il componente.
Nellesempio che segue, il contenuto del Panel viene visualizzato soltanto nel caso in
cui lutente abbia effettuato il login.

<h: panel Gr i d r ender ed=" #{ut ent e. l oggedI n}" >
. . .
</ h: panel Gr i d>

Il framework Struts, invece, dispone della libreria Struts Logic allinterno della quale
ci sono una serie di tag che permettono d
C
272
_________________________________________________________________
eseguito utilizzando attributi distinti dei tag. Per ovviare a questo limite, si utilizzano
na
caratterizzato
appunto le librerie JSTL ed in particolare la libreria Core, la quale contiene anche u
serie di tag per la costruzione condizionale dei contenuti. Un esempio
dal tag <c:if> che definisce il tipico costrutto ifthen dei linguaggi di
programmazione.

<c: i f t est =" ${r equest Scope. emai l I nvi at a == t r ue}" >
<di v cl ass=" Text " ><f mt : message key=" r i chi est aOk" / ></ di v>
</ c: i f >
. . .

4.1.3 DataTable JSF e Cicli JSTL

Nellambito della Web application realizzata, si pi volte posto il
enti in forma tabellare, come nel caso dei
rani MP3, le playlist e gli utenti registrati.
Limplem
problema di visualizzare un elenco di elem
b
entazione JSF ha previsto lutilizzo del potentissimo tag <h:dataTable>, il
quale permette di specificare la lista degli elementi da visualizzare ed eventualmente le
informazioni di formattazione. Inoltre, ciascuna colonna viene definita con il tag
<h:column>, allinterno del quale ne viene specificato uneventuale intestazione ed il
relativo contenuto.

<h: dat aTabl e val ue=" #{sessi onScope. br ani MP3}"
var =" br anoMP3"
header Cl ass=" header Dat aTabl e"
col umnCl asses=" l i nkDat aTabl e, i nf oDat aTabl e,
i nf oDat aTabl e, checkBoxDat aTabl e"
r owCl asses=" r owDat aTabl e" >
<h: col umn>
<h: out put Text val ue=" #{bundl e. t i t ol oLabel }" / >
</ f : f acet >
aI nf o}" > <h: commandLi nk act i on=" #{br anoMP3. vi sual i zz
o}" / > <h: out put Text val ue=" #{br anoMP3. t i t ol
k> </ h: commandLi n
</ h: col umn>

<h: col umn>
<h: out put Text val ue=" #{bundl e. aut or eLabel }" / >
</ f : f acet >
<h: out put Text val ue=" #{br anoMP3. aut or e}" / >
</ h: col umn>
. . .
273
_________________________________________________________________
Dallesempio si osserva che lattributo value specifica una variabile di sessione che
contiene lelenco dei brani MP3, mentre lattributo var definisce il nome della
variabile che identifica ciascun elemento allinterno della lista. Nel momento in cui si
clicca sul titolo di un brano, per poterne visualizzare le informazioni, loggetto
corrente specificato nellattributo var viene trasferito tra i parametri della request, per
ui sar disponibile alla pagina di visualizzazione.
N e permette di
re i
e la lista degli elementi da scorrere attraverso lattributo items ed una
variabile che individua loggetto corrente attraverso lattributo var.
c
el caso di Struts, si reso necessario lutilizzo del tag <c:forEach> ch
alizzare un vero e proprio ciclo for allinterno di una pagina. Esso permette d
specificar

<t abl e wi dt h=" 500" >
. . .
<c: f or Each i t ems=" ${sessi onScope. br ani MP3}" var =" br anoMP3" >
<t r cl ass=" r owDat aTabl e" >
<t d cl ass=" l i nkDat aTabl e" >
<ht ml : l i nk act i on=" / br anoMP3. do?di spat ch=vi sual i zza"
par amName=" br anoMP3" par amPr oper t y=" i d"
par amI d=" i dBr anoMP3" >
<c: out val ue=" ${br anoMP3. t i t ol o}" / >
</ ht ml : l i nk>
</ t d>
<t d cl ass=" i nf oDat aTabl e" >
<c: out val ue=" ${br anoMP3. aut or e}" / >
</ t d>
<t d cl ass=" i nf oDat aTabl e" >
<c: out val ue=" ${br anoMP3. al bum}" / >
</ t d>
. . .
</ c: f or Each>
<

D er
e le svantaggio che c rispetto
a
l
li
u a lidentificativo del brano selezionato. Infine, sar
c le informazioni del
b
/ t abl e>
allesempio, si evince che il tag viene utilizzato allinterno di una tabella p
ffettuarne una costruzione riga per riga. Il notevo
llimplementazione JSF, che nel momento in cui si clicca sul titolo di un brano,
oggetto corrente non viene posto nella request, per cui possibile superare questo
mite inserendo nel link alla pagina di visualizzazione delle informazioni del brano,
na query string in cui compai
ompito della action invocata, ricavare lid dalla request e leggere
rano dalla base di dati per poi visualizzarle.
274
_________________________________________________________________
4.2 Tiles

Il framework Tiles stato utilizzato con entrambe le implementazioni per
poter dare alla Web application una struttura basata sul concetto di template, in
modo che nel momento in cui si renda necessaria una modifica al contenuto delle
pagine, questa debba essere eseguita una sola volta e non replicata. Tale framework
el caso di JavaServer Faces necessario modificare il Deployment Descriptor
rappresenta un elemento intrinseco di JSF ma di una

mew o ad esso e va quindi specificato a

incluso nella distribuzione di Struts con il quale si integra perfettamente, soprattutto
per quanto riguarda la navigazione, mentre da importare nel progetto con JSF. La
differenza sostanziale sta nella configurazione di Tiles, che completamente diversa
tra un framework e laltro.
N
web.xml, che di per se non
generica Web application in Java. Questo mette in evidenza il fatto che per JSF, il
fra ork Tiles uno strumento del tutto estern
livello di applicazione. In particolar modo, viene dichiarato attraverso la TilesServlet,
che viene avviata subito dopo la FacesServlet e che ha come parametro iniziale il file
XML delle definizioni dei layouts.

<ser vl et >
<ser vl et - name>Ti l esSer vl et </ ser vl et - name>
<ser vl et - cl ass>
or g. apache. st r ut s. t i l es. Ti l esSer vl et
</ ser vl et - cl ass>
<i ni t - par am>
<par amname>def i ni t i ons- conf i g</ par amname>
<par am- val ue>/ WEB- I NF/ t i l es- def s. xml </ par am- val ue>
</ i ni t - par am>
<l oad- on- st ar t up>2</ l oad- on- st ar t up>
</ ser vl et >

Si osservi che la classe TilesServlet fa parte della distribuzione di Tiles allinterno di
Struts.
Il fatto che Tiles venga dichiarato mediante una Servlet mette in evidenza che non c
integrazione con JSF, nel senso che i due framework comunicano fra loro attraverso
uno scambio di informazioni tra Servlet e quindi al di fuori dellarchitettura dello
stesso JavaServer Faces.
Il framework Struts prevede la dichiarazione dellutilizzo di Tiles allinterno del
proprio file di configurazione, struts-config.xml, in termini di plug-in.
275
_________________________________________________________________

<pl ug- i n cl assName=" or g. apache. st r ut s. t i l es. Ti l esPl ugi n" >
<set - pr oper t y pr oper t y=" def i ni t i ons- conf i g"
val ue=" / WEB- I NF/ t i l es- def s. xml " / >
<set - pr oper t y pr oper t y=" modul eAwar e" val ue=" t r ue" / >
</ pl ug- i n>

Con questo tipo di approccio, il TilesRequestProcessor prende il posto del RequestProcessor
di Struts dal quale deriva, per cui le richieste pervenute allapplicazione sono gestite
direttamente nel framework, sia per quanto riguarda lelaborazione che la
visualizzazione del layout delle pagine.
Prendendo in considerazione proprio il layout, le relative componenti sono note
come tiles, ossia mattonelle, da qui il nome del framework. Inoltre, stata scelta la
struttura maggiormente utilizzata nelle applicazioni, che prevede le seguenti quattro
parti fondamentali : un intestazione (Header), un fondo pagina (Footer), un menu ed
un body.

Figura 8 - Layout Web Application

276
_________________________________________________________________
LHeader ed il Footer sono componenti comuni di tutte le pagine, mentre possono
variar che
rappr
Il lay zione lo
tilizza, inserendo di volta in volta le quattro componenti suddette. In questo modo,
siderato in relazione al menu, essendo anche
tato previsto un unico file di menu, il cui contenuto viene visualizzato o
eno a seconda dellutilizzatore che accede al sistema.

e il menu, in relazione al tipo di utilizzatore, ma soprattutto il body
esenta ogni volta un contenuto differente.
out definito attraverso un unico file e ciascuna pagina dellapplica
u
tutte le pagine hanno la stessa struttura ma con contenuti diversi. Per quanto riguarda
lHeader ed il Footer, il vantaggio principale quello di poter eseguire una modifica
su ciascuno di essi una sola volta, senza la necessit di replicarla su tutte le pagine. Lo
stesso tipo di vantaggio pu essere con
questultimo comune a tutte le pagine accessibili da un certo tipo di utilizzatore.
Il file delle definizioni, tiles-defs.xml, leggermente diverso tra le due implementazioni,
in quanto entrambi definiscono le parti fisse di ciascuna pagina, ossia il file contente
il layout, lHeader ed il Footer, ma si differenziano per la specifica del menu. Infatti,
in JSF s
m
<def i ni t i on name=" page. t empl at e"
pat h=" / t empl at es/ mai nLayout . j sp" / >
<def i ni t i on name=" page. header " pat h=" / t empl at es/ header . j sp" / >
<def i ni t i on name=" page. f oot er " pat h=" / t empl at es/ f oot er . j sp" / >
<def i ni t i on name=" page. menu" pat h=" / t empl at es/ menu. j sp" / >

Invece, in Struts sono stati usati tre file distinti contenenti i menu diversi per i tre
moduli.

<def i ni t i on name=" page. t empl at e"
pat h=" / t empl at es/ mai nLayout . j sp" / >
<def i ni t i on name=" page. header " pat h=" / t empl at es/ header . j sp" / >
<def i ni t i on name=" page. f oot er " pat h=" / t empl at es/ f oot er . j sp" / >

Ciascuna delle pagine della Web application utilizza il layout fissato e, per ciascuna
efinition, specifica il tile da inserire allinterno del layout stesso.

d
277
_________________________________________________________________
Nel caso di JSF, la struttura di ogni pagina di questo tipo :

<t i l es: put name=" t i t l e" val ue=" Ti t ol o Regi st r azi one" / >
val ue=" / cont ext / r egi st r azi oneCont ext . j sp"
t ype=" page" / >

e come si pu osservare non viene specificato il menu, oltre allHeader ed al Footer.
Con Struts, invece, si ha una cosa del tipo :

<t i l es: put name=" t i t l e" val ue=" Ti t ol o Regi st r azi one" / >
val ue=" / cont ext / r egi st r azi oneCont ext . j sp"
t ype=" page" / >
<t i l es: put name=" menu" val ue=" / t empl at es/ menu. j sp"
t ype=" page" / >

in cui vengono specificati tutti i tile da utilizzare, tranne lHeader ed il Footer.

4.

e che
onsiste nel poter estendere le classi dei componenti della UI, per implementare
er ciascuno di essi, necessario eseguire le seguenti fasi :
ortamento del componente, oltre alle
i
decode ed encode;
- definire le propriet del tag allinterno di un file TLD (Tag Library
Descriptor);
3 JavaServer Faces Custom Components
Il framework JSF mette a disposizione una potenzialit notevol
c
componenti personalizzati, molto pi potenti, da utilizzare nella propria interfaccia
utente. P

- realizzare la classe che definisce il comp
fasi di decoding e di encoding se vanno gestite in maniera autonoma;
- viceversa, realizzare la classe renderer che si occupi delle operazioni d
- realizzare la classe che costituisce il Tag Handler, per poter gestire il tag
associato al componente;

278
_________________________________________________________________
Nella Web application in questione, sono stati realizzati i seguenti componenti :
za tre drop-down list
con ad
lla
noltre permette di visualizzare unetichetta associata ed un
visualizza semplicemente una drop-down
list ma con la possibilit di specificarne unetichetta e visualizzare un
Tim er
no
delle
non
irettamente la classe di base UIComponent, in modo tale da poter sfruttare il
omponente di input, potenziandone le
aratteristiche. Inoltre, i componenti DateSelectComponent e TimeSelectComponent
svologon
nente prevede un
roprio Tag Handler realizzato mediante una classe che estende UIComponentTag.

4.3.1 D

e di questo componente stata presa in considerazione,
per t
data di a della carta di credito, nelle fasi di registrazione e
di a u

- DateSelectComponent : componente che visualiz
tenente giorni, mesi ed anni, per la selezione di una data. Utilizzato,
esempio, per limmissione della data di nascita e della data di scadenza de
carta di credito. I
eventuale messaggio di errore;
- DDListComponent : componente che
eventuale messaggio di errore;
- eSelectComponent : componente che permetta la selezione di una durata, p
esempio del brano MP3, attraverso due drop-down list che contengo
minuti e secondi. Inoltre, permette di visualizzare unetichetta al fianco
drop-down list;

Le classi che implementano i suddetti componenti estendono la classe UIInput e
d
comportamento di default di un c
c
o in maniera autonoma le operazioni di deconding e di encoding, per cui
non hanno bisogno di un renderer. Viceversa, il componente DDListComponent
delega tali operazioni ad una classe renderer corrispondente, implementata
estendendo la classe base Renderer. Ovviamente, ciascun compo
p
ateSelectComponent
Limplementazion
po er permettere allutente di specificare in maniera piuttosto banale la propria
nascita e la data di scadenz
cq isto o ricarica della scheda prepagata.
279
_________________________________________________________________

Si pu
serie di drop-down list ed un eventuale messaggio di errore. Inoltre, la sua
intr u
relativi
visualiz ese e dellanno. Nel caso della data di nascita
son e
ultime d

Figura 9 JSF : Esempi d'uso del DateSelectComponent
osservare che il componente prevede la visualizzazione di un etichetta, una
od zione allinterno di una pagina JSP, prevede un unico tag ed attraverso i
attributi possibile specificare il testo delletichetta e quali drop-down list
zare, tra quelle del giorno, del m
o n cessarie tutte mentre nel caso della scadenza della carta di credito bastano le
ue.
<component s: dat eSel ect i d=" dat aNasci t a"
val ue=" #{ut ent e. dat aNasci t a}"
showDay=" t r ue"
showMont h=" t r ue"
showYear =" t r ue"
t ype=" bi r t h" / >

Lulteriore vantaggio dato dal fatto che una volta selezionata ed inviata la data,
tramite un form, il componente non prevede due o tre valori separati che
rappresentano giorno, mese ed anno ma bens un unico valore di tipo Date. Se si
fosse pensato di utilizzare i tag delle librerie di base, sarebbero stati necessari due o
tre tag <h:selectOneListbox> oppure <h:selectOneMenu> per le drop-down list, pi un
tag <h:outputText> per letichetta. Inoltre, i valori ottenuti sul server sarebbero stati
ente indipendenti e si sarebbero rese necessarie ulteriori elaborazioni per
comporli e ricavare una data valida. Questo componente permette di sottolineare le
truzione della View ed i notevoli vantaggi che comporta
er il Page author. Per quanto riguarda lo sviluppo, la prima classe realizzata quella
relativa al
completam
potenzialit di JSF nella cos
p
componente vero e proprio, ossia DateSelectComponent. Quesultima estende
la classe UIInput, in modo da ereditarne il comportamento di base, al quale aggiunge
le proprie caratteristiche specifiche.

280
_________________________________________________________________

F 10 : DateSelectComponent, DateSe igura - JSF lectTag

li attributi principali della classe servono per specificare letichetta da visualizzare al
ti, invocati nel metodo principale encodeBegin(),
enerando i tag HTML per la visualizzazione delletichetta e le drop-down list. Al
componente associato il Tag Handler realizzato mediante la classe DateSelectTag che
G
fianco del componente, quali campi visualizzare tra giorno, mese ed anno ed infine
che tipo di data dovr contenere, nascita o scadenza, in modo da generare lelenco
degli anni in maniera differente. Loperazione di deconding viene eseguita allinterno
del componente stesso attraverso il metodo decode(), allinterno del quale vengono
ricavati dalla richiesta i parametri che rappresentano i valori del giorno, del mese e
dellanno, i quali vengono utilizzati per creare un oggetto Calendar che rappresenti la
data selezionata. Si evince quindi che il componente restituisce un valore di tipo Date,
che pu essere destinato direttamente ad una propriet di un backing bean dello
stesso tipo. Loperazione di validazione pressoch superflua, considerando che il
componente guida lutente nella scelta della data ed inoltre va sottolineato che, nel
caso di data incoerente (es. 31 febbrario 2006), lo stesso oggetto Calendar, in maniera
del tutto automatica, ripristina la data valida pi vicina. La fase di encoding viene
eseguita attraverso dei metodi priva
g
281
_________________________________________________________________
estende UIComponentTag. Essa dispone di tutti gli attributi di cui sar dotato il tag
nella pagina JSP, ma in particolar modo del metodo setProperties(), che ha il compito di
caricare i valori di tali attributi che il Page author specifica nel tag, in corrispondenza
dei campi della classe DateSelectComponent. Inoltre, previsto il metodo release(), che
permette di rilasciare le risorse allocate per gli attributi, una volta che il componente
sia stato renderizzato. Infine, per la descrizione del tag relativo a questo componente
cos come agli altri, stato creato un Tag Library Descriptor (components.tld) in cui c
la descrizione degli attributi associati al tag stesso.

<t ag>
<name>dat eSel ect </ name>
<t ag- cl ass>component s. Dat eSel ect Tag</ t ag- cl ass>
<at t r i but e>
<name>i d</ name>
<descr i pt i on>I dent i f i cat i vo del component </ descr i pt i on>
</ at t r i but e>
<at t r i but e>
<name>val ue</ name>
<descr i pt i on>Val or e del component </ descr i pt i on>
</ at t r i but e>
. . .

E ovviamente necessaria la registrazione del componente allinterno del file di
configurazione, specificandone la classe che lo implementa.

<component >
<component - t ype>Dat eSel ect </ component - t ype>
<component - cl ass>
component s. Dat eSel ect Component
</ component - cl ass>
</ component >

282
_________________________________________________________________
4.3.2 DDListComponent

La realizzazione di questo componente potrebbe sembrare assolutamente
superflua, considerando che le librerie di base mettono a disposizione i tag
<h:selectOneListbox> e <h:selectOneMenu>, per la visualizzazione della drop-down list,
insieme ai tag <f:selectItem> e <f:selectItems>, per specificare gli elementi contenuti
nella lista.

<component s: dr opDownLi st i d=" st at o"
val ue=" #{ut ent e. st at o}"
i t ems=" #{i t emsBean. st at i }"
r equi r ed=" t r ue" / >

I van lla possibilit
di visualizzare unetichetta ed un eventuale messaggio di errore, ma soprattutto di
oter specificare la lista degli elementi da visualizzare, non mediante ulteriori tag, ma
re la fase di deconding e
i encoding ad un renderer, in modo da evindeziare il differente approccio rispetto al
DateSelectCom ciare ad un
medesimo componente pi renderers differenti linguaggi di markup
diversi. In q na sola volta ma le
isualizzazion ci, in virt della possibilit di accedere alla Web
pplication con dispositivi client diversi.
implementazione necessita quindi di tre o pi classi : una relativa al componente,
na relativa al corrispondente Tag Handler ed una o pi classi relative ai renderer.
el caso di studio in esame, stato realizzato un unico rendeder per il linguaggio di
arkup HTML, assumendo che lapplicazione sia accessibile solo ed esclusivamente
ediante un browser Web.

1 JSF : Esempio d'uso del DDListComponent Figura 1
taggi principali ottenuti dallutilizzo del componente sono relativi a
p
bens con un proprio attributo (items).
Per quanto riguarda limplementazione, si pensato di delega
d
ponent. Tale modalit ha il notevole vantaggio di poter asso
, magari relativi a
ento viene definito u uesto modo, il comportam
v i sono moltepli
a
L
u
N
m
m
283
_________________________________________________________________

Figura 12 JSF : DDListComponent, DDListTag, DDListRenderer

La classe DDListComponent, che estende UIInput, non prevede tutti gli attributi del
componente, in quanto alcuni di essi possono essere direttamente gestiti dal Tag
Handler, per cui in molti casi si preferisce ometterli nella definizione del
componente. Essa prevede il metodo validateValue(), il quale esegue una validazione
del valore immesso dallutente, invocando semplicemente la versione della
(), per caricare i valori degli attributi nel componente e
rilasciare le risorse allocate.
Infine, la classe DDListRenderer estende la classe base Renderer per poter implementare
il renderer HTML associato al componente. Essa prevede al suo interno il tipico
superclasse. Si osservi che in questo caso, mancano i metodi relativi al deconding ed
allencoding, poich tali fasi vengono eseguite dal renderer.
La classe DDListTag, che deriva da UIComponentTag, specifica tutti gli attributi del
componente che saranno presenti nel tag corrispondente ed implementa i tipici
metodi setProperties() e release
284
_________________________________________________________________
metodo encodeBegin(), il quale utilizza dei metodi privati per la visualizzazione del
componente. Inoltre, stato eseguito loveridding del metodo getConvertedValue(), per
poter gestire allinterno del renderer stesso la conversione del valore selezionato. In
molte situazioni, tale operazione non strettamente necessaria, in quanto il
framework che esegue le conversioni in maniera automatica. In questo caso, si rende
necessaria loperazione di conversione in quanto il componente viene utilizzato per
visualizzare sia liste con valori numerici (es. importo scheda prepagata) che stringhe
(es. stato).
La descrizione del tag contenuta allinterno del file components.tld e per quanto
riguarda la configurazione, necessario registrare sia il componente che il renderer.
Questultimo va tipicamente inserito allinterno di un Render Kit, in base al
dispositivo client di accesso, ma in questo caso stato registrato in quello di
default relativo al linguaggio HTML.

<r ender er >
<component - f ami l y>Dr opDownLi st </ component - f ami l y>
<r ender er - t ype>Dr opDownLi st Render er </ r ender er - t ype>
<r ender er - cl ass>component s. DDLi st Render er </ r ender er - cl ass>
</ r ender er >

.3.3 TimeS 4 electComponent

Questo componente stato realizzato per uno scopo ben preciso, ossia
permettere allamministratore di specificare la durata di un brano MP3,
semplicemente selezionando i valori di minuti e secondi mediante due drop-down
list.

<component s: t i meSel ect i d=" dur at a"
val ue=" #{br anoMP3. dur at a}" / >

Figura 13 JSF : Esempio d'uso del TimeSelectComponent

Il tipico vantaggio sempre quello di evitare lutilizzo di pi tag, soprattutto per la
visualizzazione delle due drop-down list e del loro contenuto. Inoltre, il componente
restituisce automaticamente un oggetto di tipo Time, in luogo di due valori distinti
285
_________________________________________________________________
che rappresentano i minuti ed i secondi. Per quanto riguarda limplementazione, esso
stato realizzato in modo tale da gestire in maniera autonoma le fasi di decondig e di
encoding.

Figura 14 JSF : TimeSelectComponent, TimeSelectTag

estende UIInput e definisce i metodi necessari per le
operazioni di
bbano visualizzare le informazioni di un brano MP3, tra cui appunto la
tomaticamente la lista dei valori da poter
selezionare.
Il Tag Handler realizzato mediante la classe TimeSelectTag, che estende
UICompon metodi
per gestire il caricamento dei valori di questi ultimi allinterno del componente e per
lasciare le risorse allocate.
La classe TimeSelectComponent
decode e di encode. In particolare, il metodo decode() ricava dalla request
i parametri relativi ai minuti ed i secondi selezionati e li compone in modo da ricavare
un unico oggetto Time. La fase di encoding, ovviamente, esegue loperazione inversa,
qualora si de
durata. Inoltre, lo stesso metodo genera au
en contiene tutti gli attributi previsti nel tag ed i tipici tTag, la quale
ri
Il tag associato ovviamente descritto allinterno del file components.tld ed il
componente registrato allinterno del file di configurazione.

286
_________________________________________________________________

Figura 15 - JSF : Custom Components

.3.4 e Struts ?
ta, la data di scadenza della carta di credito e la durata di un brano MP3.
4

Il framework Struts non mette assolutamente a disposizione un
meccanismo che permetta di implementare dei componenti personalizzati come in
JSF. La realizzazione dellinterfaccia utente pu essere svolta utilizzando tutti quelli
che sono i tag della libreria Struts HTML, senza possibilit di estensione. Tale limite
si evidenziato soprattutto per alcuni campi necessari nei form, come ad esempio la
data di nasci
Con JavaServer Faces, queste necessit particolari sono state risolte attraverso la
realizzazione di corrispondenti Custom Components, mentre nel caso di Struts, si
preferito utilizzare dei semplici campi di testo.

Figura 16 - Struts : Esempio campo di input di una data

287
_________________________________________________________________
Si sarebbe potuto pensare di servirsi dei tag relativi alle drop-down list, ma in quel
caso sarebbe stato necessario far gestire alla action ricevente, loperazione di
comporre i valori separatamente ricavati dalla request per ottenere un unico valore
corrispondente. Lutilizzo di un semplice campo di testo ha permesso di avvalersi di
una particolare regola di validazione, prevista nel plug-in Validator, relativa alle date.
In questo modo, si pu comunque effettuare un opportuno controllo per verificare
che lutente abbia immesso una data valida.

4.4 I formbean di Struts

In riferimento allacquisizione dei dati contenuti nei form ed inviati
dallutente, il framework Struts introduce il concetto di formbean, il quale altro non
che una particolare classe le cui propriet sono destinate a contenere i valori dei
campi del form stesso. Nel momento in cui viene inviata una richiesta, compito del
RequestProcessor popolare il formbean ed effettuare la validazione dei dati in esso
contenuti, per poi passar estire la richiesta.
generale, un formbean pu essere di due tipi :
- statico : realizzato attraverso una classe che estende la classe ActionForm
o

lo alla action che dovr occuparsi di g
In

ppure una delle sue derivate e poi dichiarato nel file di configurazione;
- dinamico : dichiarato direttamente allinterno del file di configurazione, senza
la necessit di implementare una classe corrispondente;

Tipicamente, si preferisce utilizzare i formbean dinamici, anche se sussistono alcune
situazioni in cui si rende necessaria limplementazione delle classi per quelli statici.
Anche nel caso della Web application realizzata, si fatto uso di entrambe le
tipologie di formbean, dinamici l dove possibile e statici l dove fossero necessari per
un certo motivo.

288
_________________________________________________________________
4.4.1 Login, Registrazione e Richiesta password

La funzionalit di Login prevede un semplice form con due campi,
allinterno dei quali specificare lo Username e la Password.

Figura 17 - Form di Login
Ad esso
con
asse dellazione di login.

stato associato un formbean di tipo statico, implementando la classe
LoginForm che estende la classe base ActionForm. E stata scelta questa soluzione, in
quanto facendo riferimento alla fase di registrazione, quando lutente termina la
procedura, viene eseguita unoperazione di login automatico per cui era necessario
riempire il form di login direttamente dal codice. Attraverso la realizzazione della
classe LoginForm, stato possibile istanziare un oggetto di questo tipo, popolarlo
i dati di accesso ed invocare la action che si occup

Figura 18 - Struts : LoginForm
implementazione notevolmente semplice, in quanto le propriet della classe non
no altro che i campi previsti nel form : userName e password. Non stato effettuato
overriding del metodo validate(), in quanto la validazione dei dati immessi non
ecessaria per due motivi :
L
so
l
n
289
_________________________________________________________________

- Lo username e la password possono contenere caratteri alfanumerici
q
plicemente laccesso;
Infine, il formbean stato registrato allinterno del modulo default, dal quale
accessibile la funzionalit di login, specificandone il nome e la classe che lo
implementa.

<f or m- bean name=" l bean. Logi nFor m" / >
ualsiasi;
- Se non viene immesso alcun valore, si impedisce sem

ogi nFor m" t ype=" f or m

La funzionalit di Registrazione prevede in primo luogo il form per i dati di accesso
che sono indispensabili e poi eventualmente il form di acquisto della scheda
prepagata, qualora lutente voglia avvalersi di questo servizio. Poich questultima
funzionalit disponibile anche per un utente gi registrato, ma non ancora in
possesso di una scheda, verr trattata successivamente.

Figura 19 - Form di Registrazione

Ad esso associato un formbean realizzato mediante la classe RegistrazioneForm, la
quale estende ValidatorForm e non semplicemente ActionForm Limplementazione
ella classe si resa necessar ntato di Struts, dovuto
na chechbox non selezionata, lActionForm associato al
.
d ia per una sorta di bug docume
alla presenza della checkbox con la quale lutente pu scegliere se proseguire la
procedura di registrazione, acquistando anche la scheda prepagata. Dalla
documentazione ufficiale di Struts si legge ATTENZIONE : per poter acquisire
correttamente il valore di u
290
_________________________________________________________________
form in questione deve contenere, allinterno del metodo reset(), unistruzione che
setti a fa
deriva d rForm, in quanto la validazione dei dati viene eseguita attraverso il
plug
lse il valore della checkbox, da qui il motivo della classe. Inoltre, questultima
a Validato
-in Validator e non mediante il metodo validate().

Figura 20 - Struts : RegistrazioneF

orm
elle propriet che corrispondono ai campi del form ed il
metodo reset() per il motivo suddetto. Ovviamente, il formbean registrato nel file di
configurazione allo stesso modo del bean precedente.
Infine, la funzionalit di richiesta della password prevede che lutente inserisca molto
semplicemente lindirizzo email con cui si registrato per poter ricevere una mail con
i dati di accesso.

La classe realizzata ha d

Figura 21 - Form di Richiesta Username/Password

In questo caso bastato realizzare un formbean dinamico semplicemente
dichiarando nel file di configurazione e specificandone le propriet relative.

<f or m- bean name=" r i chi edi Passwor dFor m"
<f or m- pr oper t y name=" emai l " t ype=" j ava. l ang. St r i ng" / >
</ f or m- bean>
291
_________________________________________________________________
Come si pu osservare, il formbean sar unistanza della classe DynaValidatorForm
essendo dinamico e poich su di esso verr eseguita la validazione attraverso il plug-
in Validator. Inoltre, viene specificata lunica propriet che ne fa parte con il relativo
tipo.
4.4.2 Acquisto/Ricarica scheda prepagata

La funzionalit di acquisto della scheda prepagata accessibile in fase di
registrazione oppure in un qualsiasi momento, nel caso di un utente registrato che
non ha deciso di usufruire di questo servizio in precedenza. Essa prevede un form
allinterno del quale lutente deve immettere i propri dati personali, limporto della
scheda e le informazioni della carta di credito.

Figura 22 - Form di Acquisto scheda prepagata
292
_________________________________________________________________
Il form associato ad un formbean di tipo dinamico, dichiarato nei file di
configurazione del modulo default e admin, da cui la funzionalit accessibile.
Tale formbean del tipo DynaValidatorForm, tenendo sempre conto che la
validazione viene eseguita mediante il plug-in Validator. Inoltre, le sue propriet
corrispondono perfettamente ai campi del form.

<f or m- bean name=" acqui st oSchedaFor m"
<f or m- pr oper t y name=" dat aScadenzaCC" t ype=" j ava. l ang. St r i ng" / >
<f or m- pr oper t y name=" dat aNasci t a" t ype=" j ava. l ang. St r i ng" / >
<f or m- pr oper t y i ni t i al =" M" name=" sesso"
t ype=" j ava. l ang. St r i ng" / >
. . .
</ f or m- bean>

La funzionalit di ricarica della scheda prepagata prevede un semplice form
allinterno del quale lutente deve specificare limporto della ricarica e le informazioni
della carta di credito.

Figura 23 - Form di Ricarica scheda prepagata

Anche in questo caso stato definito un formbean dinamico, del tipo
DynaValidatorForm, dichiarato solo ed esclusivamente nel file di configurazione del
modulo user.

293
_________________________________________________________________
4.4.3 Modifica dati utente ed amministratore

Attraverso la corrispondente funzionalit, lutente ha la possibilit di
modificare i propri dati di accesso ed i dati anagrafici, nel caso abbia a disposizione
una scheda prepagata della quale ne abbia effettuato lacquisto. Il form previsto una
rta di unione tra il form di registrazione e quello per lacquisto di una scheda
p limmissione della conferma della
p

so
repagata, a meno di un campo in pi che prevede
assword scelta. Un parte di esso visibile nella figura seguente.

Figura 24 - Frammento del Form di Modifica dati Utente

Il formbean ad esso associato dinamico e del tipo DynaValidatorForm e le sue
propriet corrispondono ai campi del form. Esso dichiarato sempre allo stesso
modo nel file di configurazione del modulo user.
Unanaloga funzionalit prevista per lamministratore, il quale per ha la possibilit
di modificare solo ed esclusivamente la password, non essendo associate ad esso
ulteriori informazioni. Il form perfettamente uguale a quello previsto per lutente ed
il formbean associato comunque di tipo dinamico, ma dichiarato ovviamente nel
le di configurazione del modulo admin.
zione e ricerca dei brani
La visualizzazione dellelenco dei brani presenti in archivio prevista sulla
la prima permette di scegliere un genere
fi

4.4.5 Visualizza

base di due modalit differenti, di cui
294
_________________________________________________________________
musicale mentre la seconda di impostare dei criteri di ricerca pi precisi basati sul
tolo, lautore e lalbum.
Il form d
ti
ella prima modalit banale in quanto caratterizzato da un'unica drop-
down list allinterno della quale selezionare il genere musicale a cui si interessati.

Figura 25 - Form di Visualizzazione brani MP3 per genere

Il formbean associato del tipo DynaValidatorForm ed ha ovviamente ununica
propriet associata al campo del form.
La seconda modalit di visualizzazione prevede un form leggermente pi complesso,
in quanto, oltre al genere possibile impostare criteri di ricerca specifici sulle altre
informazioni del brano.

Figura 26 - Form di Ricerca brani MP3

Esso prevede un formbean dinamico con le propriet genere, titolo, autore ed album
relative ai campi del form. Esso registrato correttamente sia nel modulo admin
che user.

<f or m- bean name=" r i cer caBr ani MP3For m"
t ype=" or g. apache. st r ut s. act i on. DynaAct i onFor m" >
<f or m- pr oper t y name=" gener e" t ype=" j ava. l ang. St r i ng" / >
<f or m- pr oper t y name=" t i t ol o" t ype=" j ava. l ang. St r i ng" / >
<f or m- pr oper t y name=" aut or e" t ype=" j ava. l ang. St r i ng" / >
<f or m- pr oper t y name=" al bum" t ype=" j ava. l ang. St r i ng" / >
</ f or m- bean>

295
_________________________________________________________________
Una volta eseguita la richiesta di visualizzazione oppure terminata la ricerca, se ci
sono dei brani che soddisfano i criteri impostati, viene visualizzato un elenco degli
he
ermettono allamministratore di selezionare i brani da eliminare ed allutente di
selezionare i brani da aggiungere ad un certa playlist.

stessi. Nel caso in cui lutilizzatore sia lamministratore oppure un utente che ha delle
playlist create in precedenza, al fianco dei brani sono visualizzate delle checkbox c
p

Figura 27 - Form d

i Visualizzazione ed eliminazione brani MP3 dall'archivio

Figura 28 - Form di MP3 in una playlist
delle checkbox, il formbean stato implementato mediante la classe
raniMP3Form che estende ActionForm, che ha le seguenti propriet :

- dei
delle
- idPlaylist : contiene lidentificativo della playlist scelta dallutente allinterno
della quale immettere i brani selezionati;
Visualizzazione ed inserimento dei brani

Ovviamente, le checkbox devono far parte di un form che verr inviato alla action
che dovr occuparsi dellelaborazione. Avendo utilizzato il tag <html:multibox> per la
generazione
B
idBraniMP3Selezionati : un array di stringhe che contiene gli identificativi
brani scelti, riempito automaticamente dal framework sulla base
checkbox selezionate;
296
_________________________________________________________________
Ovviamente, la prima propriet utilizzata sia nel caso di accesso dellamministratore
che dellutente, mentre la seconda solo ed esclusivamente in questultimo caso.

Figura 29 - Struts : BraniMP3Form

Il formbean registrato nei file di configurazione del modulo admin e user.

4.4.6 Inserimento/Modifica brani

Per effettuare linserimento di un nuovo brano allinterno dellarchivio,
lamministratore ha a disposizione un form nel quale poter inserire le informazioni
del brano e selezionare il file MP3 di cui eseguirne il caricamento sul server. Per
quanto riguarda la modifica, tale funzionalit disponibile nellinterfaccia che
visualizza le informazioni di un certo brano e da essa possibile eseguire anche le
pera nte, o zioni di eliminazione ed ascolto. Il form praticamente uguale al precede
salvo il fatto che non prevede il campo di selezione del file MP3.

Figura 30 - Form di Inserimento brano MP3
297
_________________________________________________________________

Figura 31 - Form di Modifica brano MP3
associata ad un campo hidden che ovviamente non visibile. La necessit di questa
i due pulsanti di submit, modifica ed elimina,
llinterno di questultimo. Tali pulsanti non avviano due action differenti, ma come
si vedr d
na finestra pop-up
llinterno della quale viene caricato il player MP3 ed avviato lascolto del brano.
I formbean sono ovviamente dinamici e dichiarati unicamente nel file di
configurazione del modulo admin.


Per quanto riguarda la creazione di una playlist, previsto un semplice
form costituito da un unico campo allinterno del quale specificarne il nome.

I formbean associati ai due form sono sostanzialmente simili a meno del fatto che
quello relativo alla modifica del brano, prevede la propriet dispatch, la quale
propriet legata alla presenza d
a
i seguito definita ununica action che contiene una serie di metodi che
eseguono le possibili azioni su un brano MP3, per cui la propriet dispatch necessaria
per distinguere quale metodo invocare. Alla pressione di uno dei due pulsanti, viene
assegnato un valore appropriato a tale propriet e questultima viene inserita nella
query string. Il RequestProcessor, sulla base di tale valore, avvia lesecuzione del metodo
corrispondente della action invocata. Viceversa, al pulsante di ascolto non legata
alcuna action, in quanto la sua pressione comporta lapertura di u
a
298
_________________________________________________________________

Figura 32 - Form di Creazione playlist

Il formbean associato di tipo statico ed stato implementato mediante la classe
PlaylistForm che deriva da ValidatorForm, per poter effettuare la validazione sul nome
della playlist.

Figura 33 - Struts : PlaylistForm

E inoltre prevista un ulteriore propriet, idPlaylistSelezionate, la quale viene utilizzata
per la selezione delle playlist da cancellare. Infatti, lutente ha la possiblit di
visualizzare lelenco di tutte le playlist create in precedenza ed , attraverso delle
checkbox, pu selezionare quali playlist eliminare.

Figura 34 - Form di Visualizzazione ed eliminazione delle playlist
Cos come n
an in questione, quindi, viene utilizzato

el caso della gestione dei brani, il framework riempie automaticamente
larray di stringhe idPlaylistSelezionate, con gli identificativi delle playlist scelte
attraverso le checkbox selezionate. Il formbe
299
_________________________________________________________________
nella gestione delle due funzionalit suddette ed registrato ovviamente solo nel
modulo user.

elli da cancellare attraverso delle checkbox.

Lamministratore dispone di semplici funzionalit per poter gestire gli
utenti registrati. In particolare, possibile visualizzare lelenco degli utenti e
selezionare qu

Figura 35 - Form di Visualizzazione ed eliminazione degli utenti

Per poter eseguire loperazione di eliminazione, viene invocata una particolare action,
la quale riceve un formbean implementato attraverso la classe UtentiForm che deriva
a ActionForm e che ha una propriet, idUtentiSelezionati, che contiene lelenco degli d
identificativi degli utenti scelti per la cancellazione.

Figura 36 - Struts : UtentiForm

oltre, prevista la propriet dispatch, in quanto la action che si occupa della In
cancellazione permette di eseguire tutte le operazioni possibili sulloggetto Utente. Per
questo motivo, assegnando il valore opportuno a questa propriet allinterno della
300
_________________________________________________________________
query string, possibile segnalare al RequestProcessor, quali dei metodi della action debba
essere avviato. Infine, il formbean registrato unicamente nel modulo admin.
aces ?
omponents che sono stati
alizzati con JavaServer Faces. Per quanto riguarda le operazioni di acquisizione dei
dati, questultimo non prevede assolutamente il concetto di formbean. I campi di
ciascun form sono associati alle propriet dei backing beans, cos come la pressione
di un bottone per linvio dei dati non prevede lesecuzione di una action esterna ai
bean, ma bens di uno dei metodi del backing bean stesso. Tutto ci ha il vantaggio di
non dover utilizzare un oggetto intermedio, il formbean appunto, che abbia il
compito del t .
considerando la funzionalit di login, essa prevede il medesimo form
<h: f or mi d=" l ogi nFor m" . . .

4.4.9 e JavaServer F

Rispetto a Struts, il framework JSF ha una gestione completamente diversa
dai form. Dal punto di vista puramente grafico, questi ultimi sono sostanzialmente
identici a meno della possibilit di utilizzare i Custom C
re
rasferimento dei dati dallutente alla elaborazione da eseguire
Ad esempio,
dellimplementazione in Struts, con la differenza che i valori di Username e Password
sono destinati allinterno delle propriet del backing bean ruolo della classe Ruolo ed
alla pressione del pulsante, viene invocato il metodo login() delloggetto.

. . .
<h: out put Text val ue=" #{bundl e. menuUser nameLabel }" / >
<h: i nput Text i d=" user Name" val ue=" #{r uol o. user Name}" / >

<h: out put Text val ue=" #{bundl e. menuPasswor dLabel }" / >
<h: i nput Secr et i d=" passwor d" val ue=" #{r uol o. passwor d}" / >

<h: out put Text val ue=" " / >
<h: commandBut t on act i on=" #{r uol o. l ogi n}"
val ue=" #{bundl e. menuBut t onLogi nLabel }"
st yl eCl ass=" but t onFor m" / >
</ h: f or m>

In questo modo, i dati sono immediatamente disponibili e lelaborazione da eseguire
su di essi si trova allinterno della classe stessa. Il backing bean dichiarato allinterno
del file di configurazione, specificandone anche lambito di visibilit (scope).
301
_________________________________________________________________

<managed- bean>
<managed- bean- name>r uol o</ managed- bean- name>
<managed- bean- cl ass>r uol o. Ruol o</ managed- bean- cl ass>
</ managed- bean>

Questo tipo di approccio utilizzato in tutte le altre funzionalit e pu essere
considera
el caso si
percorsi dei
rani in modo da renderli accessibili al player.
Dal punto di vista dellinterfaccia utente, viene aperta una finestra pop-up allinterno
della ire con
ques e e di
bilan E da
osse di
pros lascolto della propria
play
che specifica la locazione del file da

to un vantaggio a favore del framework JavaServer Faces.

4.5 Player MP3

Il Player MP3 adottato per lascolto dei brani MP3 e delle playlist
implementato mediante unapplet, JLGUIApplet, disponibile gratuitamente su
Internet. Attraverso il file di inizializzazione jlgui.ini, esso mette a disposizione la
possibilit di modificare una serie di opzioni tra cui, in particolre, il percorso del file
MP3 da ascoltare oppure del file M3U che contiene lelenco dei brani, n
tratti di una playlist. Lascolto di un singolo brano prevede la definizione del percorso
del file MP3 associato allinterno del file system mentre nel caso in cui lutente
desideri ascoltare una propria playlist, lapplicazione non fa altro che leggere la
composizione della stessa dalla base di dati e creare un file M3U con i
b
quale viene caricata lapplet. Da qui, lutente ha la possibilit di interag
tultima modificando la sequenza dei brani, utilizzando i controlli di volum
ciamento, nonch di sfruttare lequalizzatore messo a disposizione.
rvare che, con questo approccio, lutente ha comunque la possibilit
eguire la navigazione allinterno del sistema, proseguendo
list.
Lunico limite del player che il percorso
ascoltare, deve fare riferimento al medesimo host con cui si accede alla Web
application e specificato nella barra degli indirizzi del browser.

302
_________________________________________________________________

Figura 37 - Player MP3

4.6 Internazionalizzazione (I18N)

Attraverso il meccanismo dellInternazionalizzazione (I18N), possibile
differente. Per quanto riguarda questo aspetto, i framwork Struts e JSF sono
rce Bundle contenenti
messaggi da visualizzare nelle due lingue. Ciascuno di essi costituito da una serie di
oppie key-message, attraverso le quali possibile visualizzare un certo messaggio
mplicemente specificando la chiave ad esso associata.
visualizzare il testo presente nella Web application in lingue diverse, in relazione alla
localizzazione geografica da cui si collega lutente oppure sulla base delle
impostazioni della lingua del browser. Nel caso dellapplicazione realizzata, si
previsto il supporto per la lingua italiana, considerata di default, e per la lingua
inglese. In questo modo, senza la necessit di dover sviluppare due volte la medesima
Web application, possibile comunque garantire lutilizzo di questultima a persone
di lingua
perfettamente identici, in quanto forniscono tale supporto allo stesso modo, anche in
virt del fatto che questo concetto proprio del linguaggio Java.
In entrambe le implementazioni sono stati realizzati due Resou
i
c
se
303
_________________________________________________________________

. . .
r egSt at oLabel =St at o :
r egTel ef onoLabel =Tel ef ono :
r egDat aNasci t aLabel =Dat a di nasci t a :
. . .
ResourceBundle IT

. . .
r egSt at oLabel =St at e :
r egTel ef onoLabel =Phone Number :
r egDat aNasci t aLabel =Dat e of bi r t h :
. . .
ResourceBundle EN

Come si pu osservare, in entrambi i file (con estensione properties) le chiavi sono
perfettamente identiche mentre i messaggi sono in lingua diversa. Inoltre, i file stessi
hanno praticamente il medesimo nome, ossia ApplicationResources ed
ApplicationResources_en, a meno del file in lingua inglese che ha il suffisso en.
Tipicamente, il file che non ha alcun suffisso quello relativo alla lingua di default
mentre i file associati alle altre lo stesso nome del primo ma
isto la registrazione dei Resource Bundle, con una
ggera differenza. Nel caso di JSF stato necessario specificare la localizzazione
(Locale) d
lingue devono avere
seguito da un suffisso che identifica la lingua.
Entrambi i framework hanno prev
le
i default e quella supportata, oltre al nome del file contenente i messaggi.

<appl i cat i on>
<l ocal e- conf i g>
<def aul t - l ocal e>i t </ def aul t - l ocal e>
<suppor t ed- l ocal e>en</ suppor t ed- l ocal e>
</ l ocal e- conf i g>
<message- bundl e>Appl i cat i onResour ces</ message- bundl e>
</ appl i cat i on>

Invece, Struts ha previsto semplicemente la dichiarazione del Resource Bundle.

<message- r esour ces par amet er =" Appl i cat i onRes

our ces" / >
Per quanto riguarda lutilizzo dellinternazionalizzazione allinterno delle pagine
dellapplicazione, le librerie di entrambi i framework mettono a disposizione un tag
che permette di specificare quale sia il bundle dal quale prelevare i messaggi.
304
_________________________________________________________________
JavaServer Faces prevede lutilizzo del tag <f:loadBundle> in cui lattributo basename
specifica il nome source Bundle mentre var permette di assegnargli un nome
mediante il quale f JSP.

<f : l oadBundl e basename=" Appl i cat i onResour ces" var =" bundl e" / >
Nellimplementazio Struts stato utilizzato il tag <fmt:setBundle> della librearia
Formatting JSTL, i er specificare il nome
del bundle.
Per poter individuare un messa , viene utilizzato un approccio
ifferente. Con JSF si utilizza lExpression Language e la tipica dot notation,
del Re
arvi riferimento allinterno della pagina

ne in
l quale prevede lunico attributo basename p
ggio da visualizzare
d
specificando il nome del bundle e la chiave del messaggio da visualizzare.

<h: out put Text val ue=" #{bundl e. r egAnagr af i caHeader }" / >

Viceversa, con Struts non si fa uso dellEL ma attraverso un particolare tag si
specifica semplicemente la chiave associata al messaggio.

<f mt : message key=" r egAnagr af i caHeader " / >

Utilizzando il medesimo strumento, seppure con sintassi leggermente diverse, dal
punto di vista grafico le due implementazioni forniscono il medesimo risultato.

Figura 38 - Esempio di Form con localizzazioni differenti
n limi cui la
rtano il

U te legato allInternazionalizzazione riguarda il fatto che, nel caso in
navigazione tra le pagine non sia definita attraverso collegamenti ipertestuali ma
attraverso elementi grafici, non possibile visualizzare un elemento al posto di un
altro in base alla differente lingua di accesso. I Resource Bundle suppo
305
_________________________________________________________________
contenuto testuale e non eventuali immagini che costituisco i bottoni per la
navigazione.

5.
isiede nel fatto che JSF mette a disposizione un proprio meccanismo per
riusabilit e
lla rapidit di sviluppo, sfruttando l dove possibile tutti gli strumenti a
disposiz
JavaSe ri standard che
ermettono di valutare se un certo valore ha una certa lunghezza entro un minimo ed
iante
attributo required del tag associato al componente in questione.
Un esempio di obbligatoriet di un campo pu essere la richiesta dello Username in
fase di registrazione, come mostrato in figura.

Validazione

La validazione dei dati immessi nei form da parte dellutente uno degli
aspetti su cui si differenziano maggiormente i framework a confronto. La differenza
sostanziale r
la validazione e per la sua estensione mentre Struts, nella maggior parte dei casi, si
affida al plug-in Validator anche se previsto un metodo di validazione interno al
framework. Le scelte fatte nelle due implementazioni sono fondate sulla
su
ione.

5.1 JavaServer Faces Custom Validators

rver Faces mette a disposizione soltanto tre validato
p
un massimo prefissati oppure se il medesimo valore rientra in un certo range. Per
quanto riguarda lobbligatoriet di un campo, questultima viene specificata med
l

Figura 39 - JSF : Esempio di campo obbligatorio

Per quanto riguarda il controllo che un valore di un campo debba avere una
lunghezza minima prefissata, si pu fare riferimento al tag <f:validateLength>
utilizzato in fase di registrazione per la richiesta della password, per la quale stata
fissata una lunghezza minima di 5 caratteri alfanumerici.

306
_________________________________________________________________
<h: i nput Secr et i d=" passwor d"
val ue=" #{ut ent e. passwor d}"
maxl engt h=" 15" >
<f : val i dat eLengt h mi ni mum=" 5" / >
</ h: i nput Secr et >

Figura 40 - JSF : Esempio di ValidateLength
Lultimo validatore standard, relativo al controllo che un certo valore rientri in un
range fissato, stato utilizzato nella fase di inserimento di un nuovo brano MP3 in
archivio nellambito della specifica del costo di questultimo. Tale validatore fornito
dal framework attraverso i tag <f:validateDoubleRange> e <f:validateLongRange>, sulla
base del tipo di dato del valore da validare.

<h:inputText id="costo"
value="#{branoMP3.costo}"
required="true"
size="5">
<f:validateDoubleRange minimum="0.0"/>
</h:inputText>

Figura 41 - JSF : Esempio di ValidateDoubleRange

Considerando il numero limitato di controlli standard che possono essere eseguiti, il
framework mette a disposizione due meccanismi per la realizzazione di ulteriori
evede lo sviluppo di una classe che
plementi linterfaccia Validator, alla quale pu poi essere associato o meno un tag.
Tipicamente la prima soluzione strettamente limitata alluso dello specifico backing
bean e non permette di utilizzare il validatore su pi componenti che prevedono lo
esso tipo di controllo, a meno di non effettuare un copia-incolla del metodo di
validatori. Il primo consiste nel realizzare un metodo che esegua la validazione
allinterno di un backing bean, il secondo pr
im
st
validazione nei vari backing beans. Per questo motivo, si preferita la seconda
soluzione grazie alla quale un unico validatore pu essere facilmente associato a pi
componenti.

307
_________________________________________________________________
Limplementazione in JSF ha previsto lo sviluppo dei tre seguenti validatori :

- EmailV n indirizzo email sia o
meno c
- SeqCifreValidator : per valutare se un certo valore rappresentato da una
sequenza di ci
- TelefonoValidator : per verificare se un numero di telefono abbia un formato
Questo validatore viene utilizzato nella fase di registrazione di un utente
oppure nel momento in cui questultimo richiede linvio di una mail con i propri dati
di accesso, specifican alidator implementa
linterfaccia Validator metodo validate() per valutare
se lindirizzo email immesso dallutente abbia un formato corretto.

alidator : permette di valutare se il formato di u
orretto;
fre;
valido, del tipo prefisso-numero;

5.1.1 EmailValidator

do il proprio indirizzo. La classe EmailV
della quale esegue loverriding del

Figura 42 - JSF : EmailValidator

308
_________________________________________________________________
Per poter effettuare il controllo, allinterno del metodo validate() viene utilizzato lo
rumento delle Regular Expression (Espressione Regolare) fornito dal linguaggio Java.
In p ti
email p erato corretto e si valuta se il valore immesso dallutente
cor o

.
Pat t er n mask = Pat t er n. compi l e(
Mat cher mat cher = mask. mat cher ( val ue. t oSt r i ng( ) ) ;

/ / se i l val or e non cor r i sponde al pat t er n
if ( ! mat cher . mat ches( ) ) {
throw new Val i dat or Except i on( msg) ;
}
. . .
ha ovviamente previsto una registrazione allinterno del file di
configurazione, cos come tutti gli elementi personalizzati che si creano con JSF.

st
ar colare, si specifica quale sia il pattern a cui deve essere conforme un indirizzo
er essere consid
risp nda ad esso.
. .
" \ \ w+@{1}\ \ w+\ \ . {1}\ \ w+" ) ;
. . .
. . .

Si osserva che se il valore immesso dallutente non conforme al pattern specificato,
viene sollevata un eccezione la quale contiene il messaggio da visualizzare allutente.
Tale messaggio viene prelevato dal Resource Bundle.
Il validatore
<val i dat or >
<val i dat or - i d>emai l Val i dat or </ val i dat or - i d>
<val i dat or - cl ass>val i dat or s. Emai l Val i dat or </ val i dat or - cl ass>
</ val i dat or >

Per quanto riguarda il suo utilizzo allinterno di una pagina JSP, si preferito non
realizzare un tag appropriato ma di utilizzare il tag standard messo a disposizione da
JSF, ossia <f:validator>, il quale prevede lattributo validatorId che permette di
specificare lidentificativo del validatore da utilizzare, cos come stato registrato.

<h: i nput Text i d=" emai l "
val ue=" #{ut ent e. emai l }"
maxl engt h=" 50" >
<f : val i dat or val i dat or I d=" emai l Val i dat or " / >
</ h: i nput Text >

309
_________________________________________________________________
Limmissione da parte dellutente di un indirizzo con un formato errato, prevede una
segnalazione del tipo mostrato in figura.

Figura 43 - JSF : Esempio d'uso dell'EmailValidator
5.1.2

serie di campi dei form
che prevedono limmissione di un valore caratterizzato solo ed esclusivamente da una
seque o della carta di credito.
Per verificare che lutente immetta un valore corretto, stato realizzata la classe
eqCifreValidator che implementa linterfaccia Validator.

SeqCifreValidator
Nellambito dellapplicazione realizzata, ci sono una
nza di cifre, come ad esempio il C.A.P ed il numer
S

Figura 44 - JSF : SeqCifreValidator

Allinterno
n valore caratterizzato esclusivamente da cifre e viene sollevata uneccezione
del metodo validate() viene definito il pattern a cui deve essere conforme
u
310
_________________________________________________________________
qualora il controllo abbia esito negativo, in modo da visualizzare un messaggio di
errore allutente.

. . .
Pat t er n mask = Pat t er n. compi l e( " \ \ d+" ) ;

/ / se i l val or e non cor r i sponde al pat t er n
if ( ! mat cher . mat ches( ) ) {
izzato
. . .
. . .
}
. . .

Infine, eseguita la registrazione nel file di configurazione, il validatore viene util
mediante il tag <f:validator>.

<h: i nput Text i d=" cap"
val ue=" #{ut ent e. cap}"
maxl engt h=" 5"
si ze=" 5" >
<f : val i dat or val i dat or I d=" seqCi f r eVal i dat or " / >
</ h: i nput Text >

Nel caso in cui il controllo abbia un esito negativo, viene visualizzato un opportuno
messaggio di errore prelevato dal Resource Bundle.

5.1.3 TelefonoValidator

Generalmente, il valore di un campo che deve rappresentare un numero di
telefono caratterizzato da un formato particolare del tipo prefisso-numero.
Nel caso dellapplicazione realizzata, una situazione di questo tipo si verifica nella
fase di registrazione di un utente o comunque nellacquisto di una scheda prepagata,
in cui tra i dati facoltativi c anche la richiesta del numero di telefono.
Per poter garantire che , si resa necessaria la
alizzazione di un validatore opportuno mediante la classe TelefonoValidator che
lutente immetta un valore valido
re
implementa linterfaccia Validator.

311
_________________________________________________________________

Figura 45 - JSF : TelefonoValidator

Il criterio degli altri validatori ed basato
sulla defin fono per
ssere considerato valido.
Pat t er n mask = Pat t er n. compi l e( " \ \ d+- {1}\ \ d+" ) ;

l or e non cor r i sponde al pat t er n
r . mat ches( ) ) {
. . .
adottato per la validazione il medesimo
izione di un pattern a cui deve essere conforme un numero di tele
e

. . .
/ / se i l va
if ( ! mat che
. . .
}
. . .

Allo stesso modo, il validatore stato registrato nel file di configurazione ed
utilizzato nelle pagine JSP mediante il tag <f:validator>.

<h: i nput Text i d=" t el ef ono"
val ue=" #{ut ent e. t el ef ono}"
maxl engt h=" 15" >
<f : val i dat or val i dat or I d=" t el ef onoVal i dat or " / >
</ h: i nput Text >

312
_________________________________________________________________
Nel caso di esito negativo della validazione, il messaggio di errore prelevato dal
Resource Bundle del tipo in figura.

Figura 46 - JSF : Esempio d'uso del TelefonoValidator

5.2 Plug-in Validator Struts

Per poter effettuare la validazione dei dati contenuti nei form, il framework
Struts mette a disposizione un proprio meccanismo che strettamente legato ai
formbeam associati a questi ultimi. Nellambito della realizzazione di un formbean
mediante limplementazione di una classe che estende ActionForm oppure una delle
sue derivate, possibile effettuare loverriding del metodo validate() allinterno del
quale va immesso il co metodo viene invocato
che il formbean sia stato popolato. Con
il plug-in Validator allinterno della propria
distribuzio
La prima c terno del
file di conf file delle regole di
validazione -rules.xml) e del file in cui sono dichiarati i form da validare
(validation.x

dice per la validazione. Tale
automaticamente nel framework subito dopo
questo meccanismo, similmente a quanto accade in JSF, se esistono dei form distinti
aventi dei campi che prevedono le medesime validazioni, necessario riscrivere il
metodo validate() per tutti i formbean associati. Per evitare problemi di manutenzione
del software, il framework ingloba
ne, il quale rappresenta uno strumento notevolmente potente.
onsiderazione da fare che il plug-in va registrato come tale allin
igurazione dellapplicazione, specificando il percorso del
(validator
ml).
<pl ug- i n cl assName=" or g. apache. st r ut s. val i dat or . Val i dat or Pl ugI n" >
<set - pr oper t y pr oper t y=" pat hnames"
val ue=" / WEB- I NF/ val i dat or - r ul es. xml ,
/ WEB- I NF/ val i dat i on. xml " / >
</ pl ug- i n>

Per quanto riguarda le regole di validazione, queste ultime non sono state
assolutam n quanto il plug-
in mette anche il
ente modificate e non ne sono state create delle ulteriori, i
a disposizione le funzionalit di validazione pi comuni, tra cui
313
_________________________________________________________________
controllo di correttezza di un indirizzo email. Le principali validation-rules utilizzate
sono le seguenti :

- required : controlla che un campo non sia vuoto, in quanto obbligatoria
limmissio
- email : verifica che un valore abbia il formato corretto di un indirizzo email;
il valore di un campo rispetti una lunghezza minima
prefissata;
- m
i formbean
le con una sintassi di questo tipo.
ne di un valore;
- minlength : valuta se
ask : controlla che un certo valore sia conforme ad un pattern specificato;
- date : verifica che un campo contenga una data corretta, secondo un certo
formato;
- float : valuta che un certo valore sia del tipo float;

La disponibilit di queste regole non ha reso necessaria lestensione del plug-in,
realizzando delle funzioni che implementassero ulteriori regole di validazione. Da
questo punto di vista, il framework Struts si pu considerare superiore a JSF,
tenendo conto che i validatori standard di questultimo sono soltanto tre.
Unanalisi pi attenta richiesta dal file validation.xml, allinterno del quale sono stati
dichiarati tutti i form ed i relativi campi sui quali devono essere applicate delle regole
di validazione specifiche. Tali form devono corrispondere esattamente a
registrati nel file di configurazione, cos come le propriet di questi ultimi devono
coincidere con i campi soggetti a validazione.
Ad esempio, considerando il form per la registrazione di un utente, esso dichiarato
allinterno del fi

<f or mname=" r egi st r azi oneFor m" >
<f i el d depends=" r equi r ed" pr oper t y=" user Name" / >
<f i el d depends=" r equi r ed, mi nl engt h" pr oper t y=" passwor d" >
<var >
<var - name>mi nl engt h</ var - name>
<var - val ue>5</ var - val ue>
</ var >
<ar g0 key=" ${var : mi nl engt h}"
name=" mi nl engt h"
r esour ce=" f al se" / >
</ f i el d>
<f i el d depends=" r equi r ed, emai l " pr oper t y=" emai l " / >
</ f or m>
314
_________________________________________________________________
Il nome specificato per il form deve coincidere con quello del formbean ad esso
associato. Per ciascun campo ne viene specificato il nome, coincidente con la
ropriet corrispondente nel formbean suddetto, e la regola di validazione da
app ar
tutti ob inoltre al campo relativo allindirizzo email stato
app at ta
anc l
parame so indicante il valore di questultima; nel caso specifico, si prevede
che p
Una g
in relazione ad un certo pattern specificato. Tale regola, nota come mask, prevede un
par e ontrollo della conformit. Il
aso principale di utilizzo stato quello relativo ai valori che dovevano essere
p
lic e. Sulla base di quanto detto, si osserva che i campi previsti dal form sono
bligatori, regola required, ed
lic a la regola email. Infine, per quanto riguarda la password stata utilizza
he a regola di lunghezza minima, minlength, per la quale stato dichiarato un
tro di ingres
la assword non sia lunga meno di 5 caratteri alfanumerici.
re ola particolarmente utilizzata quella che permette la validazione di un valore
am tro di ingresso che rappresenta il pattern per il c
c
caratterizzati esclusivamente da una sequenza di cifre (es. C.A.P, numero della carta
di credito, etc..) oppure nel caso del numero di telefono.

<f or mname=" acqui st oSchedaFor m" >
<f i el d depends=" r equi r ed" pr oper t y=" nome" / >
<f i el d depends=" r equi r ed" pr oper t y=" cognome" / >
. . .
. . .
<f i el d depends=" mask" pr oper t y=" cap" >
<var >
<var - name>mask</ var - name>
<var - val ue>[ 0- 9] +</ var - val ue>
</ var >
<msg key=" ci f r eEr r or " name=" mask" / >
</ f i el d>
. . .
<f i el d depends=" mask" pr oper t y=" t el ef ono" >
<var >
<var - name>mask</ var - name>
<var - val ue>[ 0- 9] +- {1}[ 0- 9] +</ var - val ue>
</ var >
<msg key=" numTel ef onoEr r or " name=" mask" / >
</ f i el d>
. . .
</ f or m>

La f n ingresso, un pattern differente in
relaz colarmente
inter tazione in
JSF, non si reso necessario un controllo di questo tipo, in quanto il Custom
unzione mask ha previsto di volta in volta i
ione al valore da validare. Infine, una regola di validazione parti
essante quella relativa alla validazione di una data. Nellimplemen
315
_________________________________________________________________
Component realizzato impedisce la selezione di una data non valida. Nel caso di
Struts, si deciso di utilizzare un semplice campo di testo per linserimento di una
data, in modo da poter utilizzare questa potente regola di validazione disponibile nel
plug-in.

. . .
<f i el d depends=" dat e" pr oper t y=" dat aNasci t a" >
<var >
<var - name>dat e</ var - name>
<var - val ue>dd/ MM/ yyyy</ var - val ue>
</ var >
</ f i el d>
. . .

Si osserva che la funzione date prevede un parametro di ingresso che definisce
secondo quale pattern la data debba essere considerata corretta.
Infine, un ulteriore vantaggio delluso del plug-in Validator dato dal fatto che
questultimo supporta anche la validazione lato client., in quanto le regole di
validazione non prevedono soltanto una serie di classi e metodi che le implementano
vascript. Per poter usufruire di questa
funzionalit a pagina JSP
di interesse

6. Model

I icazione realizzata, in
quanto costituito da tutte quelle classi che definiscono la business-logic. Cos come
anticipato SF ha previsto lo sviluppo dei
backing be stema.
Con Struts le classi della
business-logic risultano notevolmente pi leggere. Ovviamente, la logica che alla
se delle praticamente la stessa, con la differenza che in JSF
ma anche i corrispondenti codici in Ja
necessario utilizzare il tag <html:javascript> allinterno dell
, specificando il nome del form su cui effettuare la validazione.
l Model pu essere considerato il cuore dellappl
in precedenza, limplementazione in J
ans e dei relativi metodi che realizzano le funzionalit del si
si resa necessaria la realizzazione delle action, per cui
ba funzionalit
completamente incapsulata nei metodi dei backing beans mentre in Struts
distribuita fra gli oggetti della business-logic e le action. Queste ultime prevedono
tutto ci che riguarda laccesso agli elementi del framework, mentre i primi eseguono
316
_________________________________________________________________
le operazioni previste dallapplicazione. Infine, sono state implementate alcune classi
comuni tra le due implementazioni e che hanno i seguenti ruoli :

- una serie di eccezioni che possono essere sollevate da particolari elaborazioni;
- una serie di classi che gestiscono le operazioni di accesso alla base di dati;

6.1 Classi Ex

Lapplicazione prevede alcune funzionalit nellambito delle quali si
ossono verificare delle condizioni di errore che vanno opportunamente gestite. Uno
realizzate le seguenti
- UsernameEsistente : eccezione che si verifica in fase di registrazione, quando
ente ha specificato una username gi presente nella base di dati;
- RuoloBloccato : eccezione sollevata quando un utilizzatore tenta di eseguire il
lo
propriet idRuolo che permette di individuare lutilizzatore che ha immesso lo
ception
p
dei metodi pi eleganti lutilizzo del meccanismo delle eccezioni messo a
disposizione dal linguaggio Java. Per questo motivo, sono state
classi che estendono la classe base Exception :

- PasswordErrata : eccezione che si verifica nel caso in cui un utilizzatore abbia
tentato un accesso al sistema sbagliando la password;
- UsernameErrata : eccezione sollevata nel momento in cui un utilizzatore tenta
di effettuare il login con una username non registrata;
lut
gin con username e password corretti, ma il suo account risulta bloccato a
causa di tentativi di accesso errati in precedenza;
- RuoloLoggato : eccezione che viene sollevata nel momento in cui un
utilizzatore tenta di accedere al sistema ma risulta gi loggato;

Queste classi sono perfettamente identiche tra le due implementazioni ed inoltre
sono praticamente tutte una semplice estensione della classe Exception alla quale non
aggiungono alcuna funzionalit. Lo scopo della loro realizzazione soprattutto
concettuale, per poter distinguere allinterno del codice le eccezioni di tipo diverso.
Soltanto la classe PasswordErrata leggermente diversa dalla altre, in quanto ha la
317
_________________________________________________________________
username corretto ma la password sbagliata, per cui bisogna tenere conto dei
tentativi di accesso errati e bloccarlo nel caso in cui sia necessario.

Figura 47 - JSF e Struts :

Classi Exception
6.2 Classi di interfacciamento con il DataBase

are in locale
opp e
attraver operazioni di lettura e
scri r

- ersistenza ad unaltra classe

on lo scopo di disaccoppiare le funzionalit della business-logic dalle operazioni di
Nella realizzazione di un sistema software che debba funzion
ur in rete, ci sono tipicamente degli oggetti per i quali va garantita la persistenza
so lutilizzo delle basi di dati. Per poter gestire le
ttu a nel database, sono previste due possibili soluzioni :
- ogni oggetto gestisce la propria persistenza in maniera autonoma, prevedendo
dei metodi che accedono alla base di dati;
ogni oggetto delegata la gestione delle propria p
che mette a disposizione una serie di metodi di accesso al database;
C
accesso alla base di dati, generalmente si preferisce adottare la seconda soluzione. Ci
stato fatto anche nella Web application realizzata, implementando il sottolivello
Data Access del Model attraverso unulteriore insieme di classi, una per ciascuna
corrispondente classe della business-logic.

318
_________________________________________________________________
Per laccesso vero e proprio alla base di dati, sono state utilizzate le seguenti classi
JDBC (Java DataBase Connectivity) :

- Connection : rappresenta una connessione alla base di dati;
- Statement : definisce una generica query da eseguire sul database;
- ResultSet : rappresenta un gruppo di record, risultato di una query eseguita
sulla base di dati;
- DriverMananger : classe che stabilisce la connessione con la base di dati
utilizzando i driver JDBC;
- SQLException : definisce uneccezione generica che sollevata nel caso in cui
si verifichi un errore di accesso al database;

Ogni classe realizzata che rappresentano la
onnessione (conn), una generica query (stmt), un resultSet (rs) ed infine la stringa di
er poter garantire lutilizzo dellapplicazione con un qualsiasi tipo di DBMS (es.
MySQL,
- driver : il driver da utilizzare per la connessione al database;
- ase con opportuni privilegi;

e classi che si interfacciano con il database utilizzano le propriet della classe
completamente centralizzata in ununica
lasse.
prevede una serie di propriet private
c
interrogazione (sQuery).
P
MS SQL Server, MS Access, Oracle, ) e facilitarne il passaggio dalluno
allaltro, stata realizzata la classe astratta InfoDBMS che non ha metodi ma
eslusivamente le seguenti propriet :

- connString : la stringa di connessione che specifica lURL del database;
user : il nome dellutente che accede al datab
- userPassword : la password dellutente suddetto;
L
suddetta, per impostare i parametri di accesso con i quali stabilire la connessione alla
base di dati. In questo modo, possibile utilizzare di volta in volta un DBMS
differente, semplicemente modificando i campi statici allinterno della classe
InfoDBMS, senza alcun intervento allinterno delle altre classi. Un ulteriore vantaggio
dato dal fatto che la configurazione
c

319
_________________________________________________________________

Figura 48 - JSF e Struts : InfoDBMS

Per a
ciascuno di essi la seguente.

...
tr

Cl a
conn=Dr i ver Manager . get Connect i on( I nf oDBMS. connString,
I nf oDBMS. user,
quer y st r i ng . . .
} finally {

try {i f ( r s ! =
e) {}
try {}
}
. .

iene eseguita unoperazione di caricamento dei Driver JDBC e di apertura della
un record nella tabelle degli accessi. Il metodo inserisci() ed aggiorna()
qu nto riguarda limplementazione dei metodi di accesso, la struttura tipica di
y {
ss. f or Name( I nf oDBMS. driver) ;

I nf oDBMS. userPassword) ;

st mt =conn. cr eat eSt at ement ( ) ;

. . . cr eazi one del l a

r s=st mt . execut eQuer y( sQuer y) ;

. . . gest i one del r esul t set . . .

} catch ( SQLExcept i on e) {

. . . gest i one eccezi oni . . .

null catch ) r s. cl ose( ) ; } ( SQLExcept i on se) {}
try {i f ( st mt ! =null) st mt . cl ose( ) ; } catch ( SQLExcept i on s
{i f ( conn ! =null) conn. cl ose( ) ; } catch ( SQLExcept i on se)
.
V
connessione alla base di dati specificata, dopodich si crea la query string contenente
linterrogazione, la si esegue e si manipola il gruppo di record risultanti. E prevista
inoltre la gestione di uneventuale eccezione sollevata e la chiusura definitiva degli
oggetti utilizzati.
Per quanto riguarda le informazioni di accesso alla Web application stata
realizzata la classe AccessoDB, la quale dispone dei metodi per inserire, aggiornare e
leggere
320
_________________________________________________________________
prevedono in ingresso un oggetto della classe Accesso, oltre allidentificativo del ruolo
a cui le informazioni si riferiscono e la tipologia del ruolo stesso, utente oppure
amministratore. Essi non restituiscono alcun valore, in quanto il loro scopo
eseguire unoperazione di scrittura nella base di dati. Il metodo leggi() prevede soltanto
li ultimi due parametri tituisce loggetto Accesso g suddetti, accede al database e res
corrispondente. Infine, ci sono due metodi privati che permettono la conversione e la
formattazione degli oggetti Date, sottolineando per che le date memorizzate
allinterno del database non sono di tipo stringa.

Figura 49 - JSF e Struts : AccessoDB

Le informazioni che riguardano lamministratore sono gestite attraverso la
classe AmministratoreDB che mette a disposizione i metodi per eseguire loperazione
di login, per leggere ed aggiornare un record ed infine bloccare lamministratore.

321
_________________________________________________________________

Figura 50 - JSF e Struts : AmministratoreDB

In particolare, il metodo login() prevede in ingresso la username e la password
dellamministratore e ne verifica la validit, con la possibilit di sollevare una delle
eccezioni introdotte in precedenza, se si verifica una particolare condizione di errore.
Ovviamente, questo metodo invocato dalla funzionalit della business-logic che
permette di effettuare il login ed il suo scopo solo ed esclusivamente di accesso alla
base di dati. I metodi leggi() e blocca() prevedono in ingresso lidentificativo
dellamministratore di cui leggere le informazioni oppure da bloccare, mentre
aggiorna() riceve un oggetto Amministratore.
In maniera del tutto analoga definita la classe UtenteDB che permette di
arantire la persistenza d osizione i
metodi t
isci()
revedono un oggetto Utente. E da osservare che loperazione di inserimento
piuttosto generica, in quanto essa viene utilizzata nella funzionalit di registrazione
della business-logic, certamente pi complessa.
Il metodo login() opera allo stesso modo come per la classe AmministratoreDB. Inoltre
sono previsti i seguenti ulteriori metodi :

- blocca() : permette di bloccare o di sbloccare un utente;
g elle informazioni dellutente. Esso mette a disp
ipici per la lettura, laggiornamento, linserimento e leliminazione di un
record. I metodi leggi() ed elimina() prevedono in ingresso lidentificativo dellutente di
cui leggere le informazioni oppure da eliminare, mentre i metodi aggiorna() ed inser
p
322
_________________________________________________________________
- elencoUtenti() : produce la lista degli utenti registrati;
- esisteUsername() : verifica lesistenza di uno username in fase di registrazione.
- esisteEmail() : verificano lesistenza di un indirizzo email. Viene utilizzato nella
funzionalit di richiesta via mail delle informazioni di accesso da parte
dellutente e restituisce lidentificativo di questultimo in caso di esito
positivo;

Figura 51 - JSF e Struts : UtenteDB

La gestione della permanenza di tutto ci che strettamente legato ai brani MP3
viene eseguita mediante le tre seguenti classi :

- BraniMP3DB;
- PlaylistDB;
- ComposizionePlaylistDB;

323
_________________________________________________________________
Attraverso la classe BranoMP3DB possibile gestire le informazioni di
cias n ,
elim a
caricare
richieda
viene ef operazione di ricerca in base a dei criteri specificati. I parametri di
gresso previsti sono relativi al genere, il titolo, lautore e lalbum dei brani da
cercare.

cu brano allinterno dellarchivio. Oltre ai tipici metodi di inserimento
in zione, lettura ed aggiornamento previsto il metodo ricerca() che permette di
dal database una lista di brani. Esso viene utilizzato sia nel caso in cui si
di visualizzare i brani sulla base di un genere specificato, sia nel caso in cui
fettuata un
in

Figura 52 - JSF e Struts ; BranoMP3DB
permanenza delle informazioni delle
laylist, stata realizzata la classe PlaylistDB che prevede le operazioni di inserimento,
eliminazione e lettura oltre al metodo elencoPlaylist() che genera lelenco delle playlist
archiviate. In particolare, il metodo inserisci() prevede come parametri di ingresso un
ogg o dellutente a cui esso associato.

Per quanto riguarda la gestione della
p
ett Playlist e lidentificativo

324
_________________________________________________________________

Figura 53 - JSF e Struts : PlaylistDB

Lultima classe, ComposizionePlaylistDB, non ha una classe corrispondente
nella business-logic e mette a disposizione i metodi per poter inserire ed eliminare un
brano MP3 da una playlist specificata oltre al metodo per generare lelenco dei brani
appartenenti ad essa. Il metodo inserisci() ha in ingresso lidentificativo della playlist e
lidentificativo del brano da introdurre, allo stesso modo opera il metodo elimina(),
mentre il metodo composizionePlaylist() riceve in ingresso lidentificativo di una playlist
e restituisce lelenco dei brani MP3 che sono al suo interno.

325
_________________________________________________________________

Figura 54 - JSF e Struts : ComposizionePlaylistDB

er quanto concerne le i epagata, alle ricariche ed
allacquist
se per linserimento, la
ttura, laggiornamento e leliminazione di ciascun record che contiene le
informazioni relative ad una generica scheda prepagata. In particolare, il metodo
inserisci() prevede un oggetto SchedaPrepagata e lidentificativo dellutente che ne ha
effettuato lacquisto.

P nformazioni relative alla scheda pr
o dei brani MP3, sono state realizzate le seguenti classi :

- SchedaPrepagataDB;
- RicaricaDB;
- DownloadDB;

La classe SchedaPrepagataDB fornisce i metodi ba
le
326
_________________________________________________________________

Figura 55 - JSF e Struts : SchedaPrepagataDB

RicaricaDB permette di inserire allinterno della base di dati le
informazioni relative ad una ricarica eseguita su una scheda prepagata. Non prevista
noperazione di cancellazione, in quanto nella definizione della tabella
corrispon
nza delle informazioni nella base di dati, senza dare lonere di
uesta operazione alle classi del software.

La classe
u
dente nel database stato specificato un vincolo di cascade sullevento
onDelete sulla chiave esterna verso la tabella della scheda prepagata. In questo
modo, effettuando una cancellazione di una scheda prepagata, vengono cancellati
direttamente dal DBMS tutti i record delle corrispondenti ricariche. In questo modo
si garantisce la coere
q
327
_________________________________________________________________

Figura 56 - JSF e Struts : RicaricaDB

Infine, la classe DownloadDB mette a disposizione un unico metodo che
ermette di inserire un nuovo acq
download. Non prevede alcun metodo di eliminazione in quanto la tabella
p uisto di un brano MP3 e quindi il relativo
corrispondente ha due chiavi esterne verso le tabelle relative ai brani ed agli utenti
con un vincolo di cascade sullevento onDelete. In questo modo, eliminando un
brano MP3 oppure un utente, vengono cancellati tutti i record relativi ai
corrispondenti download direttamente dal DBMS. Anche in questo caso, si
garantisce la coerenza delle informazioni nel database, sollevando lesecuzione di
queste operazioni dalle classi del software.
328
_________________________________________________________________

Figura 57 - JSF e Struts : DownloadDB

6.3 Le Action di Struts

Prima di analiz ema e come esse sono
state implem

- package defaultactions
- LoginAction : gestisce loperazione di login al sistema;
- RegistrazioneAction : esegue la registrazione di un utente;
- RichiediPasswordAction : fornisce la funzionalit di richiesta dei dati di
accesso via mail;
zare le funzionalit offerte dal sist
entate allinterno della business-logic, per quanto riguarda il framework
Struts si rende necessario un approfondimento sulle action che assumono un ruolo di
collegamento (bridge) tra il Controller ed il Model vero e proprio. Bisogna tenere
conto del fatto che allinterno di esse prevista una parte del codice che interagisce
con gli oggetti del framework ed utilizza i metodi delle classi della business-logic, che
in parte inevitabilmente presente in ciascuna action.
Sono state suddivise in pi package, a secondo che vengano utilizzate allinterno di
uno specifico modulo dellapplicazione oppure siano comuni a pi moduli.
Di seguito riportato lelenco dei suddetti package :
329
_________________________________________________________________
- package adminactions
- AmministratoreAction : esegue tutte le funzionalit relative
allamministratore;
- package useractions
- PlaylistAction : offre le funzionalit di gestione delle playlist;
- RicaricaSchedaAction : gestisce loperazione di ricarica di una scheda;
- package commonactions
- AcquistoSchedaAction : effettua loperazione di acquisto di una scheda
prepagata;
- BranoMP3Action : fornisce tutte le funzionalit relative ai brani MP3;
- UtenteAction : mette a disposizione le funzionalit che riguardano gli
utenti;
- LogoutAction : permette di eseguire loperazione di logout;

per interazioni con gli oggetti del framework, si intende dire
he allinterno di ciascuna action vengono eseguite le operazioni di accesso alle
variabili d
switch appartenente alla classe
hiarata allinterno di uno o pi
oduli e ad essa sono stati associati i forward che permettono la navigazione
allinterno della Web application.

E da sottolineare che,
c
i sessione e di ciascuna richiesta oltre al salvataggio dei messaggi di errore
da visualizzare allutente. Tali operazioni prevedono lutilizzo delle classi di Struts o
comunque legate alle Servlet in generale, per cui non sono eseguite allinterno degli
oggetti della business-logic in modo da favorire il disaccoppiamento di questultima
dal framework stesso.
Tali action sono state effettivamente implementate, ciascuna attraverso una
corrispondente classe, ma ad esse va aggiunta la action
SwitchAction che stata soltanto dichiarata nei file di configurazione dei tre moduli ed
il cui scopo quello di permettere il passaggio fra un modulo e laltro.
Ciascuna delle action suddette stata ovviamente dic
m
330
_________________________________________________________________

Figura 58 - Struts : Action ed interazione con le classi del Model
331
_________________________________________________________________
La classe LoginAction deriva dalla classe base Action, per cui prevede lunico
metodo execute() allinterno del quale ci sono le elaborazioni effettuate dalla action
stessa. Inoltre, prevede due metodi privati che permettono di gestire le condizioni di
password errata e di login effettuato in maniera corretta.

Figura 59 - Struts : LoginAction

Il metodo execute() contiene tutte le operazioni necessarie per valutare la username e
la password immessa dallutilizzatore, invocando il metodo login() della classe Ruolo,
permettendo laccesso nel caso di esito positivo oppure catturando una delle
eccezioni relative alle possibili condizioni di errore e salvandone i corrispondenti
messaggi. Il metodo privato loginCorretto() ha il compito di salvare le informazioni
332
_________________________________________________________________
relative a
l caso di due tentativi errati
onsecutivi. Infine, allinterno del metodo execute(), se il login va a buon fine per un
utente, vengono caricate in sessione le informazioni di uneventuale scheda prepagata
associata a questultimo ed eventualmente segnalata la sua scadenza. Lultima
operazione eseguita lutilizzo del forward verso la action switch per passare al
modulo corretto, a seconda che laccesso sia stato eseguito da un utente oppure
dallamministratore.
La registrazione della action nel file di configurazione del modulo di default permette
di associarle il formbean loginForm ed il forward in caso di errore.

llaccesso mediante la classe Accesso e le sue derivate e di inserire in sessione
le informazioni dellutente oppure dellamministratore che ha effettuato il login. Il
metodo passwordErrata() segnala lerrore di password errata, ne tiene traccia mediante
la classe Accesso e blocca eventualmente lutilizzatore ne
c
<act i on i nput =" / pages/ home. j sp" name=" l ogi nFor m" pat h=" / l ogi n"
scope=" r equest " t ype=" def aul t act i ons. Logi nAct i on" >
<f or war d name=" f ai l ur e" pat h=" / pages/ home. j sp" / >
</ act i on>

La classe RegistrazioneAction estende anchessa la classe Action ed allinterno
del proprio metodo execute() gestisce le operazioni che riguardano la registrazione
dellutente, intercettando leventuale errore nel caso in cui la username scelta sia gi
presente in archivio oppure completando loperazione in maniera corretta. Essa
permette il passaggio alla action per la gestione dellacquisto della scheda prepagata,
se lutente sceglie di voler usufruire di tale servizio. Infine, una volta completata la
registrazione in maniera corretta viene invocato un forward per richiamare la action
LoginAction ed eseguire il login automatico al sistema.
Attraverso la dichiarazione del file di configurazione del modulo default viene
assegnato il formbean registrazioneForm ed i forward per la navigazione.

<act i on i nput =" / pages/ r egi st r azi one. j sp" name=" r egi st r azi oneFor m"
pat h=" / r egi st r azi one" scope=" sessi on"
t ype=" def aul t act i ons. Regi st r azi oneAct i on"
val i dat e=" t r ue" >
<f or war d name=" l ogi n" pat h=" / l ogi n. do" / >
<f or war d name=" acqui st oScheda"
pat h=" / pages/ acqui st oScheda. j sp" / >
<f or war d name=" f ai l ur e" pat h=" / pages/ r egi st r azi one. j sp" / >
</ act i on>

333
_________________________________________________________________

Figura 60 - Struts : RegistrazioneAction

etodo
ex , facente parte
ella business-logic, per inviare la mail con i dati di accesso. Ovviamente, nel caso in
cui lindir
La classe RichiediPasswordAction estende Action ed allinterno del m
ecute(), utilizza il metodo richiediUsernamePassword() della classe Utente
d
izzo email specificato non risulti registrato allinterno dellarchivio, viene
salvato un messaggio di errore.

Figura 61 - Struts : RichiediPasswordAction

334
_________________________________________________________________
La registrazione viene eseguita soltanto del file struts-config.xml associando alla action il
formbean richiediPasswordForm.

<act i on i nput =" / pages/ r i chi est aPasswor d. j sp"
name=" r i chi edi Passwor dFor m" pat h=" / r i chi edi Passwor d"
scope=" r equest " t ype=" def aul t act i ons. Ri chi edi Passwor dAct i on"
val i dat e=" t r ue" >
<f or war d name=" esegui t a" pat h=" / pages/ r i chi est aPasswor d. j sp" / >
</ act i on>

La classe AmministratoreAction deriva da DispatchAction, in quanto non ha il
compito di effettuare un unico tipo di elaborazione ma di svolgere tutte le principali
funzionalit legate allamministratore. Ovviamente, una cosa di questo tipo non pu
essere gestita attraverso la derivazione dalla classe Action che contiene un unico
metodo execute() o comunque sarebbe necessario definire allinterno di questultimo
na serie di costrutti c
effettuare
eguire.
particolare, la classe AmministratoreAction prevede i due seguenti metodi :

- visualizza() : esegue le operazioni necessarie alla visualizzazione delle
informazioni dellamministratore;
- modifica() : effettua le elaborazioni relative alla modifica della password
richiesta dallamministratore, ovviamente segnalando eventuali condizioni di
errore;

u ondizionali per poter distinguere che tipo di operazioni
. La soluzione pi elegante per ovviare a questo problema luso della
classe DispatchAction che non prevede un unico metodo execute() ma pi metodi,
ciascuno dei quali realizza una specifica funzionalit. Quando tale action viene
invocata, attraverso una particolare parametro dispatch possibile distinguere di volta
in volta quale dei suoi metodi es
In
335
_________________________________________________________________

Figura 62 - Struts : AmministratoreAction

Essa registrata esclusivamente nel modulo admin associandole il formbean
modificaPasswordForm ed i forward in caso di visualizzazione/modifica oppure di
ione del
arametro dispatch attraverso lattributo parameter.

insuccesso dovuto ad errori nellaggiornamento. E da osservare la dichiraz
p
< aDat i Ammi ni st r at or e. j sp" act i on i nput =" / pages/ modi f i c
name=" modi f i caPasswor dFor m" par amet er =" di spat ch"
pat h=" / ammi ni st r at or e" scope=" r equest "
t ype=" admi nact i ons. Ammi ni st r at or eAct i on"
val i dat e=" f al se" >
r d name=" vi sual i zzaDat i " <f or wa
pat h=" / pages/ modi f i caDat i Ammi ni st r at or e. j sp" / >
<f or war d name=" f ai l ur e"
pat h=" / pages/ modi f i caDat i Ammi ni st r at or e. j sp" / >
</ act i on>

Anche la classe PlaylistAction estende DispatchAction, in quanto mette a
disposizione tutte le funzionalit relative alla gestione delle playlist.

336
_________________________________________________________________
Essa costituita dai seguenti metodi, invocati sulla base di un opportuno parametro
dispatch :

- visualizzaElencoPlaylist() : permette di caricare lelenco delle playlist relative
allutente in sessione oppure di segnalarne lassenza;
- eliminaPlaylists() : gestisce leliminazione di pi playlist selezionate dallelenco,
ritornando poi alla visualizzazione dellelenco aggiornato;
- crea() : esegue le operazioni relative alla creazione della playlist per lutente in
sessione;
- elimina() : gestisce leliminazione della playlist corrente;
- visualizzaElencoBraniMP3Playlist() : permette la visualizzazione dellelenco dei
brani MP3 contenuti nella playlist corrente oppure di segnalarne lassenza;
- ascolta() : gestisce la creazione sul file system del server di un file M3U
contente i percorsi ai file MP3 da eseguire ed avvia il player MP3 per lascolto
della playlist;

Figura 63 - Struts : PlaylistAction

337
_________________________________________________________________
Essa registrata esclusivamente nel modulo user associandole il formbean
playlistForm per la creazione e cancellazione delle playlist ed i forward per le richieste
i visualizzazione.

d
<act i " pat h=" / pl ayl i st " on name=" pl ayl i st For m" par amet er =" di spat ch
scope=" r equest " t ype=" user act i ons. Pl ayl i st Act i on"
val i dat e=" f al se" >
<f or war d name=" vi sual i zzaEl encoPl ayl i st "
pat h=" / pages/ gest i onePl ayl i st . j sp" / >
<f or war d name=" f ai l ur e" pat h=" / pages/ gest i onePl ayl i st . j sp" / >
<f or war d name=" vi sual i zzaEl encoBr ani Pl ayl i st "
h=" / pages/ vi sual i zzaEl encoBr ani Pl ayl i st . j sp" / > pat
</ act

soltanto le
ope i
dipende
prima e la seconda per poterle istanziare rispettivamente con limporto scelto
allutente e le informazioni della carta di credito e lultima per poter eseguire
loperazione di ricarica vera e propria della scheda prepagata, la quale opera sugli
oggetti suddetti.

i on>
La classe RicaricaSchedaAction deriva da Action e di conseguenza prevede
il metodo execute(), in quanto il suo unico scopo quello di gestire
raz oni per la ricarica di una scheda prepagata. Essa ovviamente ha dei legami di
nza con la classe Ricarica, CartaCredito e SchedaPrepagata della business-logic. La
d

Figura 64 - Struts : RicaricaSchedaAction

Anche in questo caso la d re solo nel modulo user
ricaricaSchedaForm associato.
ichiarazione della action compa
con il formbean
338
_________________________________________________________________

<act i on i nput =" / pages/ r i car i caScheda. j sp"
name=" r i car i caSchedaFor m"
pat h=" / r i car i caScheda" scope=" r equest "
t ype=" user act i ons. Ri car i caSchedaAct i on" val i dat e=" t r ue" >
<f or war d name=" success" pat h=" / home. j sp" / >
</ act i on>

La classe AcquistoSchedaAction deriva da Action e mette a disposizione la
un
e due
ossibili situazioni la action stata invocata, per determinare se si rende necessaria
una preve
funzionalit di acquisto di una scheda prepagata sia nella fase di registrazione per
nuovo utente sia per un utente gi registrato ma che vuole usufruire del servizio di
download dei brani MP3. Allinterno del metodo execute(), si valuta in quale dell
p
ntiva operazione di registrazione dellutente oppure direttamente lacquisto
della scheda prepagata. Negli oggetti del tipo SchedaPrepagata e CartaCredito vengono
copiate le informazioni relative agli importi ed alla carta di credito, prelevate dal
formbean, per poi eseguire lacquisto. In caso di registrazione, il metodo termina
invocando la action per lesecuzione del login in automatico.
La action stata registrata sia nel modulo default che user considerando le due
possibili situazioni in cui previsto lacquisto della scheda prepagata.

Figura 65 - Struts : AcquistoSchedaAction

339
_________________________________________________________________
La classe BranoMP3Action una delle pi complesse in quanto deriva da
D di che permettono di gestire
t seguenti :

aElencoBraniMP3() : permette la visualizzazione dei brani MP3 sulla
b
er e la gestione della
ecifico brano in
una variabile di sessione, garantendo una visualizzazione diversa a seconda
che la richiesta sia stata fatta dallutente oppure dallamministratore;
- elimina() : permette di effettuare leliminazione del brano corrente
dallarchivio, nonch la cancellazione del file MP3 associato;
- modifica() : permette allamministratore di modificare le informazioni di un
brano, aggiornando anche i tag ID3v1 del file MP3 corrispondente;
- inserisciBraniMP3Playlist() : effettua linserimento di una serie di brani
selezionati dallelenco corrente allinterno di una playlist scelta e salvata in
sessione;
- eliminaBraniMP3Playlis() : permette leliminazione di pi brani da una playlist,
selezionandoli dallelenco di composizione;
- inserisciPlaylist() : permette di inserire il brano corrente allinterno di una
playlist selezionata;
- acquista() : effettua loperazione di acquisto di un brano MP3 e ne abilita la
funzionalit di download;

ispatchAction e mette a disposizione una serie di meto
utte le possibili funzionalit sui brani MP3. Tali metodi sono i
- visualizz
ase del genere specificato, inserendo la lista ricavata dal database allinterno
di una variabile di sessione;
- ricercaBraniMP3() : esegue la ricerca dei brani sulla base dei criteri di ricerca
fissati ed opera allo stesso modo del metodo precedente;
- eliminaBraniMP3() : gestisce leliminazione di pi brani contemporaneamente,
selezionati dallelenco corrente. Oltre alla cancellazione delle informazioni
dallarchivio, vengono cancellati anche i file MP3 corrispondenti dal file
system del server;
- inserisci() : permette linserimento di un brano in archivio nonch il
caricamento del corrispondente file MP3 sul serv
coerenza dei tag ID3v1 con le informazioni inserite;
- visualizza() : esegue il caricamento delle informazioni di uno sp

340
_________________________________________________________________
Essa pr
di metodi
iversi.

aticamente legata a tutte le classi che riguardano i brani, il loro acquisto e la
composizione delle playlist. Infine, essa dichiarata sia nel modulo corrispondente
allutente che allamministratore ovviamente garantendo lesecuzione
d

Figura 66 - Struts : BranoMP3Action

strettam . Essa prevede i seguenti metodi :

- caricamento dei dati dellutente in sessione per
permetterne la modifica oppure esclusivamente la visione allamministratore;
La classe UtenteAction estende DispathAction e fornisce tutte le funzionalit
ente legate allutente
visualizza() : permette il
341
_________________________________________________________________
- modifica() : effettua loperazione di aggiornamento dei dai dellutente,
segnalando eventuali condizioni di errore;
- elimina() : permette allamministratore di eliminare lutente selezionato;
- visualizzaUtenti() : esegue il caricamento dellelenco degli utenti registrati in
una variabile di sessione, per la successiva visualizzazione;
- eliminaUtenti() : permette allamministratore di eliminare uno o pi utenti
selezionati dallelenco;
- sblocca() : esegue loperazione di sblocco di un utente;

Si osservi che essa strettamente legata solo ed esclusivamente alla classe Utente della
business-logic, in quanto utilizza i metodi di questultima che agiscono sullutente.
Inoltre, anche in questo caso la registrazione stata effettuata nei moduli admin e
user.

Figura 67 - Struts : UtenteAction
342
_________________________________________________________________
Lultima classe, LogoutAction, deriva da Action in quanto attraverso lunico
execute() permette allutente oppure allamm metodo inistratore di eseguire il logout dal
sist a

em .

Figura 68 - Struts : LogoutAction

Invoca il metodo di logout() della classe Utente oppure Amministratore ed utilizza la
classe Playlist per eliminare eventuali file MP3 di playlist ascoltate dallutente. La
dichiarazione nel modulo user e admin associa ad essa il forward verso la action
switch per ritornare al modulo default.
Considerando loperazione di passaggio da un modulo allaltro durante la
navigazione, stata realizzata la action switch del tipo SwitchAction, la quale viene
invocata con una sintassi di questo tipo :

/ swi t ch. do?page=[ pagi na. j sp] &pr ef i x=[ pr ef i ssoModul o]

in cui il parametro prefix permette di specificare il modulo verso il quale eseguire il
passaggio (/admin, /user oppure una stringa vuota per il modulo di default) mentre
page indica la pagina verso la quale essere redirezionati allinterno del modulo stesso.

343
_________________________________________________________________
6.4 Busin
Considerando le due implementazioni con JSF e Struts, le classi che
ostituiscono la business-logic sono caratterizzate dalle seguenti differenze :

- con JSF costituiscono a tutti gli effetti i backing beans, per cui la maggior
parte dei metodi restituiscono gli outcome per la navigazione essendo invocati
direttamente dalle pagine JSP; con Struts vengono utilizzate allinterno delle
action per cui non devono assolutamente occuparsi della navigazione;
- con JSF i metodi accedono agli oggetti del framework, cos come alle variabili
di sessione e di ciascuna richiesta; con Struts tali operazioni vengono eseguite
dalle action in modo che gli oggetti della business-logic siano disaccoppiati
dal framework stesso;

Facendo riferimento alle elaborazioni es a funzionalit, basta
sservare che nel caso di JSF sono concentrate nei metodi delle classi stesse, mentre
nto riguarda linserimento e la lettura degli
allutilizzatore corrente, di cui bisogna
antenerne lo stato durante la navigazione. Per poter gestire le operazioni di lettura e
scrittura ici che
HttpSession. Questo tipo di
odice allinterno delle action ma ci non toglie che, a meno dei metodi
gic dellimplementazione in Struts sono
e riutilizzabili con framework diversi.
ess-Logic e funzionalit del sistema

c
eguite per ciascun
o
con Struts sono distribuite tra questi ultimi e le action. Inoltre, da sottolineare che
dal punto di vista concettuale sono sostanzialmente identiche, tenendo comunque
conto che la Web application la medesima.
Una precisazione doverosa per qua
oggetti del sistema allinterno delle variabili di sessione. Queste ultime sono
ampiamente utilizzate per memorizzare alcuni oggetti della business-logic che
contengono le informazioni associate
m
in sessione, le classi sono state dotate di alcuni metodi stat
ovviamente necessitano dellaccesso allistanza della classe
operazione non comporta nulla sullimplementazione con JSF, mentre sembrerebbe
introdurre una contraddizione nellimplementazione con Struts, perch in questo
modo si introduce un legame con il framework. La scelta stata fatta per rendere pi
snello il c
statici suddetti, le classi della business-lo
assolutamente indipendenti dal framework
344
_________________________________________________________________
Tali metodi statici, previsti esclusivamente per alcune classi, hanno una nomenclatura
i questo tipo :

oggetto
appartenente a questa classe;
-
- o della

d
- getClasseSession : permette di recuperare dalla sessione un
- removeClasseSession : elimina dalla sessione loggetto della classe;
putClasseSession : inserisce allinterno della sessione un oggetto di questa
classe;
isClasseSession : verifica se un oggetto della classe presente allintern
sessione corrente;
Pagina JSP

Figura 69 - JSF e Struts : Accesso agli oggetti della Business-Logic

Di seguito sono descritte le classi che compongono il Model in entrambe le
implementazioni, evidenziando linterazione tra di esse e le differenze che sussistono
tra le loro realizzazioni in unimplementazione e nellaltra.

Elaborazioni
Action

Elaborazioni
Oggetto BL
(Backing Bean)
Pagina JSP
Oggetto BL
345
_________________________________________________________________
6.4.1 Package accesso

Questo package contiene le classi che permettono di gestire le informazioni
che ig
dallam izzato dalla classe astratta Accesso dalla quale
der n nicamente da
un u
dellamministratore.
In e ra

- id : identificativo dellaccesso;
- dataOraLogin, dataOraLogout : data ed ora in cui stato eseguito il login ed il
logout;
- loginValido : valore booleano che indica se laccesso andato a buon fine o
meno;
- tentativo : intero che indica in corrispondenza di quale tentativo c stato
laccesso oppure eventualmente il blocco;
- indirizzoIP : indirizzo IP del client;

Ovviamente, nella classe Accesso i metodi sono tutti astratti ma sono implementati
allinterno delle classi derivate e sono i seguenti :

- inserisci() : permette di inserire le informazioni relative ad unazione di login.
Prevede in ingresso lidentificativo dellutilizzatore che ha effettuato laccesso;
ni dellaccesso in fase di
logout, ricevendo in ingresso lidentificativo dellutilizzatore che sta
abbandonando il sistema;
elle due implementazioni, queste classi sono perfettamente uguali considerando che
non sono utilizzate direttamente dalle pagine JSP oppure dalle action, ma da altre
classi della business-logic ed in particolar modo dagli oggetti Ruolo, Utente ed
r uardano tutte le operazioni di login e di logout eseguite dagli utenti e
ministratore. Esso caratter
iva o le classi AccessoUtente ed AccessoAmministratore per distingure, u
p nto di vista concettuale, le informazioni di accesso dellutente e
nt mbe le implementazioni, le propriet delle classi sono le seguenti :
- leggi() : permette di leggere le informazioni dellaccesso di un utilizzatore,
specificando in ingresso il suo identificativo;
- aggiorna() : permette di aggiornare le informazio

N
346
_________________________________________________________________
Amministratore. La differenza sostanziale relativa ai metodi che accedono alla
ssione, in quanto con JSF si utilizza la classe del framework FacesContext, mentre
con Strut
se
s direttamente loggetto HttpSession.

Figura 70 JSF : package accesso

347
_________________________________________________________________

Figura 71 - Struts : package accesso

Questo package non rappresenta un termine di paragone tra le due implementazioni
e potrebbe essere banalmente interscambiato facendo gli opportuni accorgimenti
ellaccesso alle variabili di

6.4.2 Package ruolo

Il package ruolo contiene le classi relative agli utilizzatori della Web
application. In particolare, la classe Ruolo generalizza le due sottoclassi Utente ed
Amministratore, tenendo conto del fatto che prima di essere registrato o comunque di
n sessione.
348
_________________________________________________________________
eseguire il login, un utilizzatore dellapplicazione non pu essere classificato. In
entrambe le implementazioni, essa prevede le seguenti propriet :

- id : identificativo univoco del ruolo;
- userName : username del ruolo;
- password : password di accesso del ruolo;
- bloccato : indica se il ruolo risulta bloccato o meno;
- loggedIn : indica se il ruolo loggato o meno al sistema;
- tipo : presente soltanto nellimplementazione in Struts per poter distinguere
un utente e lamministratore in fase di login, considerando che tale
operazione viene gestita da una action esterna;

Ovviamente, esse sono ereditate dalle classi Utente ed Amministratore essendo
informazioni comuni ad entrambi, con la differenza che mentre la seconda non
aggiunge ulteriori propriet, la prima ha delle propriet in pi che rappresentano tutti
i dati anagrafici dellutente. Inoltre, sono previste le propriet dataOraRegistrazione ed
acquistoMP3 che indica se lutente ha deciso di usufruire del servizio di acquisto e
download dei brani. Nellimplementazione in JSF, la classe Utente necessita di una
propriet in pi, elimina, che tiene conto del fatto che lutente sia stato selezionato o
meno allinterno dellelenco degli utenti registrati per poter essere cancellato. Tale
propriet non si resa necessaria in Struts, grazie allutilizzo delle multibox, come
visto nella descrizione della View.
Prima di descrivere in li ei metodi previsti nelle
fortemente FacesContext per poter
re con Struts soltanto le classi Utente ed
ono alle istanze di HttpServletRequest ed HttpSession. Queste ultime
no state utilizzate per far gestire a tali classi la propria permanenza in sessione ma,
come ant
nea generale il comportamento d
classi, opportuno osservare le dipendenze che ci sono tra di esse e le altre classi del
Model oltre ad eventuali classi del framework adottato, in modo da poter
comprendere alcune differenze tra le due implementazioni.
Nellimplementazione con JSF, le classi utilizzano
accedere alle variabili di sessione, ment
Amministratore acced
so
icipato, non sono strettamente necessarie e potrebbero essere usate dalle
action esterne. La classe Ruolo non assolutamente legata a queste classi, in quanto il
suo uso principale avviene nella action di login , LoginAction, che gestisce la
349
_________________________________________________________________
persistenza in sessione delle informazioni di un utente oppure dellamministratore,
utilizzando i metodi delle classi corrispondenti. In entrambe le implementazioni, la
lasse Ruolo utilizza le classi UtenteDB ed AmministratoreDB per poter effettuare
lop z
essere sollevate in fase di accesso al sistema. Con JSF, Ruolo utilizza la classe Accesso e
le s d lle informazioni di accesso, mentre
con r llimplementazione in JSF,
la c se accessibili dallutente,
tra cui
dipende
E da so con JSF che non con Struts e
tto ci giustificato dal fatto che nel primo caso, le classi devono gestire tutto in
c
era ione di login, cos come in entrambi i casi legata alle eccezioni che possono
ue erivate per poter gestire il salvataggio de
St uts questo compito delegato alle action. Infine, ne
las Utente accede a tutte quelle classi legate a funzionalit
Playlist, SchedaPrepagata, CartaCredito e Mail, mentre con Struts alcune di queste
nze mancano essendo previste nelle action.
ttolineare che sussistono molte pi dipendenze
tu
maniera autonoma interagendo tra loro e con gli oggetti del framework, mentre nel
secondo caso, le action si occupano di alcune di queste interazioni, per cui le classi
della business-logic non fanno altro che eseguire semplici operazioni utilizzando le
classi di accesso alla base di dati.

350
_________________________________________________________________

Figura 72 - JSF : package ruolo
351
_________________________________________________________________

F igura 73 - Struts : package ruolo
352
_________________________________________________________________
Per quanto riguarda i metodi, la classe Ruolo prevede :

- login(), logout() : per effettuare le operazioni di login e di logout al sistema;
- blocca(), sblocca() : per bloccare o sbloccare un ruolo. Essi non hanno corpo in
entrambe le implementazioni ma vengono utilizzate le versioni soggette ad
overriding delle classi Utente ed Amministratore;

Nel caso dellimplementazione con JSF, da osservare che sono presenti alcuni
metodi privati che invece, nellimplementazione con Struts, si trovano nella
LoginAction.
Il metodo login() opera secondo una modalit di questo tipo :

- tenta di valutare se al sistema sta accedendo un utente invocando
UtenteDB.login();
- se lo username non registrato tra gli utenti, tenta di valutare se sta
accedendo lamministratore invocando AmministratoreDB.login();
- nel caso di username inesistente in entrambi i casi viene segnalato un errore,
mentre in caso di esito positivo e di password corretta viene consentito
laccesso. Se si tratta di un utente, vengono caricate le informazioni di
uneventuale scheda prepagata e ne viene valutata la scadenza;
- in tutti gli altri casi, le classi di accesso alla base di dati possono sollevare le
eccezioni relative a password errata, ruolo loggato e ruolo bloccato;

La differenze principali tra le due implementazioni sono le seguenti :

- con JSF, il parametro di ritorno del metodo sar comunque una stringa che
rappresenta loutcome con il quale proseguire la navigazione. Con Struts, viene
restituito un oggetto Ruolo che pu puntare ad unistanza di Utente oppure
Amministratore. Tale oggetto verr utilizzato dalla LoginAction che invoca
questo metodo;
- con JSF, le eccezioni sollevate nelle possibili condizioni di errore vengono
catturate e poi ne viene gestita la segnalazione. Con Struts, considerando ch

il metodo login() n, le eccezioni vengono
e
viene invocato dalla LoginActio
353
_________________________________________________________________
catturate e poi risollevate a questultima che avr il compito di salvare i
messaggi di errore nella request;
uita
- informazioni di uneventuale
scheda prepagata vengono caricate allinterno del metodo login() stesso. Con
lcune elaborazioni siano eseguite nella LoginAction, per quanto riguarda
eseguono soltanto le
perazioni che competono loro da un punto di vista concettuale.
Il m o
linvalidazione della sessione mentre altre operazioni specifiche vengono eseguite
dall e
tale me ente le sue
vers n
anche d
La class

la logout(),
in entrambe le implementazioni, aggiorna le informazioni di uscita dal
- visualizzaDati() : ha il compito di permettere la visualizzazione dei dati
- con JSF, la memorizzazione delle informazioni di accesso viene eseg
allinterno della classe Ruolo attraverso dei metodi privati. Con Struts, gli stessi
metodi sono previsti nella LoginAction;
con JSF, nel caso di accesso di un utente, le
Struts, tale operazione delegata alla LoginAction.

Il fatto che a
luso di Struts, evidenzia che gli oggetti della business-logic
o
et do logout() completamente diverso, in quanto con JSF, esegue semplicemente
a v rsione soggetta ad overriding delle classi Utente ed Amministratore. Con Struts,
todo non ha corpo in quanto vengono utilizzate esclusivam
io i sovrascritte che sono invocate allinterno della LogoutAction che si occupa
i invalidare la sessione;
e Amministratore prevede i seguenti metodi :
- login(), logout() : versioni sovrascritte delle medesime funzioni di Ruolo. La
login() non fa altro che invocare la versione della superclasse mentre
sistema;
dellamministratore per uneventuale modifica. Con JSF, ricava le
informazioni dalloggetto Amministratore in sessione e restituisce loutcome per
la navigazione alla pagina di visualizzazione. Con Struts, esegue la lettura dei
dati dal database con AmministratoreDB.leggi(), restituendo loggetto
Amministratore;
- modificaDati() : esegue la modifica dei dati dellamministratore. Con JSF,
esegue laggiornamento invocando AmministratoreDB.aggiorna() oppure segnala
eventuali errori e fa proseguire la navigazione restituendo loutcome. Con
354
_________________________________________________________________
Struts, effettua laggiornamento allo stesso modo ma viene invocato dal
metodo modifica() di AmministratoreAction, che ha il compito di gestire gli errori
-
ministratoreDB.blocca();

La class
metodi
ioni di uscita dal
allutente, che vorr modificare i propri dati, oppure
arli. Con Struts, esegue la lettura
dei dati dal database con UtenteDB.leggi(), restituendo loggetto Utente;
mento allo stesso modo ma viene invocato dal metodo modifica() di
-
- resente soltanto nellimplementazione in JSF, utile per non
e passare alla pagina di visualizzazione;
blocca() : perfettamente uguale in entrambe le implementazioni, bloccando
lamministratore mediante il metodo Am
e Utente sicuramente una delle pi complesse, in quanto prevede i seguenti
:

- login(), logout() : versioni sovrascritte delle medesime funzioni di Ruolo. La
login() non fa altro che invocare la versione della superclasse mentre la logout(),
in entrambe le implementazioni, aggiorna le informaz
sistema;
- registrazione() : permette di effettuare la registrazione dellutente;
- visualizzaDati() : ha il compito di permettere la visualizzazione dei dati
dellutente. Con JSF, ricava le informazioni dalloggetto Utente in sessione e
restituisce un outcome diverso per la navigazione, in base al fatto che la
richiesta sia stata fatta d
dallamministratore che potr soltanto vision
- modificaDati() : esegue la modifica dei dati dellutente. Con JSF, esegue
laggiornamento invocando UtenteDB.aggiorna() oppure segnala eventuali errori
e fa proseguire la navigazione restituendo loutcome. Con Struts, effettua
laggiorna
UtenteAction, che ha il compito di gestire gli errori e passare alla pagina di
visualizzazione;
blocca(), sblocca() : sono uguali in entrambe le implementazioni ed eseguono le
operazioni di blocco e sblocco di un utente, mediante i corrispondenti metodi
della classi che accedono alla base di dati;
sbloccaUtente() : p
alterare la struttura comune dei metodi precedenti e pu essere invocato da
una pagina JSP per sbloccare lutente e restituire loutcome per la navigazione;
355
_________________________________________________________________
-
per la navigazione. Con Strust, viene
tale lista nella
sessione;
utenti selezionati dallelenco. In entrambe le implementazioni viene
utilizzato uno o pi volte il metodo UtenteDB.elimina(). Con JSF, viene gestito
ne;
ulta essere gi
- tenente

Unosservazione da fare che i metodi visualizzaElencoUtente() ed eliminaUtenti() sono
dich ra
ad una
eseguono operazioni legate ad uno specifico utente ma agli utenti in generale. Con
JSF
direttam
Inoltre, ,
appartenenti ai backing beans dichiarati, ma non metodi statici.
visualizzaElencoUtenti() : permette la visualizzazione dellelenco degli utenti
registrati. Con JSF, invoca UtenteDB.elencoUtenti() e salva la lista in una
variabile di sessione restituendo loutcome
invocato dal metodo visualizzaUtenti() della UtenteAction al quale restituisce la
lista degli utenti registrati. E la action che si occupa di salvare
- elimina(), eliminaUtenti() : permettono di eliminare un singolo utente oppure
pi
laggiornamento dellelenco in sessione e restituito loutcome per la navigazione.
Con Struts, tali operazioni vengono eseguite dai metodi elimina() ed
eliminaUtenti() della UtenteAction che gestisce anche il proseguimento della
navigazio
- verificaUsername() : permette di valutare se un certo username ris
associato ad un utente registrato. Esso viene utilizzato in fase di registrazione
e limplementazione con JSF, una volta terminata la verifica, restituisce un
outcome per la navigazione. Con Struts, restituisce semplicemente un valore
booleano e viene utilizzato dalla RegistrazioneAction. In entrambi i casi, viene
utilizzato il metodo UtenteDB.esisteUsername();
richiediUsernamePassword() : permette allutente di ricevere una mail con
i dati di accesso al sistema. Con JSF, verifica lesistenza della mail utilizzando
UtenteDB.esisteEmail(), invia i dati mediante la classe Mail oppure segnala
eventuali errori. Con Struts, invia la mail allo stesso modo e restituisce un
semplice valore booleano alla RichiediPasswordAction da cui viene invocato;
ia ti statici con Struts ma non con JSF. Il fatto di essere statici, ossia non legati
specifica istanza della classe, plausibile tenendo conto del fatto che non
, non possibile dichiararli statici in quanto la loro invocazione avviene
ente dalle pagine JSP e loggetto Utente istanziato e presente in sessione.
lutilizzo del method-binding prevede di poter invocare metodi di istanza
356
_________________________________________________________________
Il m o
comple
UtenteD
una str
registra
che tali operazioni sono eseguite anche nellimplementazione in Struts ma non
alli r
registra

-
-
- lutente vuole usufruire del servizio di acquisto e download dei
-

Nel cas
dei form acquisto della scheda prepagata,
la s a
nelle d
registraz

.4.3 Package brani
et do registrazione() merita unanalisi a parte, in quanto ha unimplementazione
tamente diversa fra Struts e JSF. Con Struts, non fa altro che invocare
B.inserisci() per salvare le informazioni dellutente nellarchivio. Con JSF, ha
uttura notevolmente complessa, poich esegue tutte le operazioni legate alla
zione che non prevede soltanto il salvataggio dellutente in archivio. E ovvio
nte no di questo metodo, bens nella RegistrazioneAction. La funzionalit di
zione, in entrambi i casi, caratterizzata dalle seguenti fasi :
si valuta se lutente abbia scelto di acquistare una scheda prepagata;
se cos non fosse, viene semplicemente salvato lutente in archivio oppure
vengono segnalati eventuali errori dei dati;
viceversa, se
brani MP3, vengono ricavate le informazioni della carta di credito e verificata
la copertura, per poi eseguire lacquisto della scheda prepagata;
viene effettuato il login automatico al sistema;
o dellimplementazione in Struts, tutte le operazioni che riguardano la lettura
con i dati, la verifica della carta di credito, l
egn lazione degli errori e la gestione delle variabili di sessione vengono eseguite
ue action RegistrazioneAction ed AcquistoSchedaAction, delegando al metodo
ione() il solo compito di salvare lutente in archivio.
6

Il package brani contiene fondamentalmente le due classi relative alla
gestione dei brani MP3 presenti in archivio : BranoMP3 e FileMP3. Per quanto
riguarda le propriet che le caratterizzano, esse sono completamente uguali tra le due
implementazioni, in quanto la classe BranoMP3 contiene le informazioni relative ad
un generico brano, mentre FileMP3 ha alcune propriet che permettono di accedere
al file MP3 associato ad un brano ed altre che rappresentano i tag ID3v1. La
differenza sostanziale, sempre in relazione alle propriet, caratterizzata dal fatto che
357
_________________________________________________________________
limplementazione in JSF ne prevede delle ulteriori per poter gestire gli elenchi dei
brani. La propriet elimina permette di valutare se un brano stato selezionato per
leliminazione dallarchivio attraverso una corrispondente checkbox, cos come
inserisciInPlaylist ed eliminaDaPlaylist permettono di verificare se un brano stato
selezionato per essere inserito oppure eliminato da una playlist. Tali propriet non
sono previste con Struts, in quanto gli elenchi dei brani prevedono luso delle
multibox, come visto nella descrizione della View. Unulteriore differenza riguarda la
propriet mp3 della classe FileMP3. Tale propriet ha il compito di contenere un
ferimento al file MP3 residente in locale, che stato selezionato dallamministratore
per p one della
Vie S
corrispo alle estensioni di MyFaces, ossia al
pro t
proprie
signific
Dai a nze che ci sono tra queste due
lassi e le restanti classi del Model, con le quali interagiscono. Per entrambe le
llinterno dellarchivio;
- eseguire loperazione di acquisto di un brano;
- garantire il legame con lutente, in virt di un acquisto e del download;

ri
lu load sul server. Facendo riferimento a quanto detto nella descrizi
w, truts mette a disposizione il tag per la selezione del file e quindi la classe
ndente FormFile, mentre JSF deve affidarsi
get o Tomahawk che prevede la classe UploadedFile. Per questo motivo, la
t mp3 di tipo diverso considerando le due implementazioni, ma il suo
ato ed il relativo uso sono i medesimi.
di grammi UML possibile evidenziare le dipende
c
implementazioni, la classe BranoMP3 legata alle classi Download, BranoMP3DB,
SchedaPrepagata ed Utente, rispettivamente per :

- tenere traccia del download di un brano;
- gestire la persistenza delle informazioni del brano a

358
_________________________________________________________________

Figura 74 - JSF : package brani

359
_________________________________________________________________

Figura 75 - Struts : package brani

La classe FileMP3 utilizza le classi MP3File e ID3v1 della Java MP3 Tag Library per
poter accedere ai tag ID3v un brano e garantirne la
oerenza con le informazioni di questultimo presenti in archivio. Inoltre, essa
gata alle classi File, InputStream ed OutputStream per stabilire un riferimento alla
irectory sul server in cui caricare il file MP3 e gestire la lettura del file in locale con
la corrispondente scrittura in remoto, attraverso due stream di byte.
Le differenze sostanziali tra le due implementazioni riguardano :

- il legame tra FileMP3 e UploadedFile con JSF ma con FormFile con Struts, in
virt di quanto detto in precedenza;
1 del file MP3 associato ad
c
le
d
360
_________________________________________________________________
- la permanenza delle informazioni di un brano allinterno di una variabile di
sessione. Cos come per tutte le altre classi che la prevedono, JSF utilizza la
classe FacesContext mentre con Struts si usano direttamente le classi
HttpServletRequest ed HttpSession. E da ricordare e sottolineare che in
questultimo caso, la gestione delle variabili in sessione potrebbe essere
eseguita dalle action che agiscono sui brani e non sono strettamente
necessarie nelle classi della business-logic;

Analizzando in linea generale i metodi della classe BranoMP3, essi svolgono le
seguenti funzionalit :

- visualizzaInfo() : permette la visualizzazione delle informazioni di un brano
selezionato. Con JSF, il brano automaticamente presente nella request e
viene spostato in sessione, restituendo un outcome diverso per la navigazione
in base al fatto che la richiesta sia stata fatta dallamministratore, che potr
modificare le informazioni del brano, oppure dallutente che potr
esclusivamente visionarle. Con Struts, tale metodo viene invocato dal metodo
visualizza() della BranoMP3Action. Il suo compito quello di ricavare le
informazioni del brano dal database mediante BranoMP3DB.leggi() restituendo
un oggetto BranoMP3 alla action che avr il compito di salvarla in sessione e
far proseguire la navigazione;
- modificaInfo() : permette la modifica delle informazioni di un brano,

Ovviamente, viene invocato il metodo BranoMP3DB.aggiorna() per garantire la
modifica allinterno dellarchivio e viene restituito loutcome per la navigazione.
garantendo la coerenza con i tag ID3v1 del file MP3 associato.
Limplementazione di questo metodo sostanzialmente diversa nei due casi,
in quanto se con JSF tutte le elaborazioni necessarie sono concentrate nel
metodo, con Struts alcune di esse sono eseguite dal metodo modifica() della
BranoMP3Action. In particolare, con JSF viene individuato il percorso del file
sul server utilizzando la classe FileMP3 e viene effettuato laggiornamento dei
tag sulla base delle nuove informazioni immesse dallamministratore.
Con Struts, il metodo si limita ad aggiornare le informazioni in archivio,
361
_________________________________________________________________
mentre compito della action corrispondente effettuare le operazioni di
coerenza con i tag ID3v1 e far proseguire la navigazione;
visualizzaElencoBraniMP3(), ricerca() : questi due metodi operano allo stesso
modo, nel senso che permettono la visualizzazione di un elenco di brani sulla
base di un genere selezionato oppure in virt di criteri di ricerca pi raffinati.
Con JSF, utilizzano il metodo BranoMP3DB.ricerca() e caricano la lista ottenuta
allinterno della sessione, restituendo poi
-
loutcome per la navigazione. Con
Struts, essi vengono invocati rispettivamente dai metodi
ggetto contenente la lista dei brani. E compito della action
salvare tale elenco in sessione e far proseguire la navigazione;
- ento di un nuovo brano in archivio ed il
proseguimento della navigazione;
visualizzaElencoBraniMP3() e ricercaBraniMP3() della BranoMP3Action,
restituendo un o
- acquista() : permette di effettuare lacquisto di un brano. La sua
implementazione pi o meno la stessa in entrambi i casi, in quanto vengono
utilizzate le classi SchedaPrepagata e Download, rispettivamente per controllare
limporto residuo sulla scheda ed effettuare lacquisto e poi abilitare il
download. La differenza sta nel fatto che con JSF si accede alle informazioni
della scheda direttamente dalla sessione, si segnalano eventuali errori e viene
restituito loutcome per la navigazione, mentre con Struts le informazioni della
scheda sono passate con un parametro di ingresso e laccesso alla sessione
viene eseguito dal metodo acquista() della BranoMP3Action;
inserisci() : permette linserim
caricamento del file MP3 corrispondente sul server. Opera allo stesso modo
del metodo modifica() ed implementato in maniera diversa nei due casi. Con
JSF, viene individuato il path sul server in cui caricare il file e lupload viene
eseguito attraverso il metodo FileMP3.upload(), dopodich viene valutata la
coerenza tra i tag ID3v1 e le informazioni immesse dallamministratore. Nel
caso di esito positivo, viene invocato il metodo BranoMP3DB.inserisci() mentre
in caso di esito negativo vengono segnalati gli errori. In entrambi i casi viene
restituito loutcome per proseguire la navigazione. Con Struts, il metodo esegue
semplicemente linserimento delle informazioni del brano in archivio, mentre
il metodo inserisci() della BranoMP3Action che si occupa delle operazioni di
upload del file, del controllo della coerenza dei tag ID3v1 e del
362
_________________________________________________________________
-
elenco. Entrambi

Unosse
alcuni m modificaInfo() ed
inserisci()
un ogg
aggiorn
necessa
il meth
BranoM
tipo Fil
questu
ed il ca che da una pagina
JSP ie
Infine,
informa
direttam
BranoM
metodo
classe
SchedaP
dalle ac

elimina(), eliminaBraniMP3() : permettono di eseguire leliminazione di un
singolo brano oppure di pi brani selezionati da un
utilizzano uno o pi volte il metodo BranoMP3DB.elimina(), per cancellare le
informazioni del/i brano/i dallarchivio. Per quanto riguarda leliminazione
del/i corrispondente/i file/s MP3 nel file system, con JSF questa operazione
viene eseguita allinterno di questi metodi, invocando FileMP3.elimina(),
mentre con Struts allinterno dei metodi corrispondenti elimina() ed
eliminaBraniMP3() della BranoMP3Action.
rvazione interessante da fare, riguarda la differenza di signature che hanno
etodi tra limplementazione con JSF e con Struts. I metodi
non prevedono parametri di ingresso con JSF ed al loro interno istanziano
etto della classe FileMP3 per eseguire su di esso le operazioni di
amento dei tag ID3v1 ed il caricamento del file MP3 sul server. Ci
rio perch da una generica pagina JSP, questi metodi sono invocati attraverso
od-binding e facendo riferimento ad un backing bean associato alla classe
P3. Nel caso di Struts, i due metodi prevedono un parametro di ingresso del
eMP3 che viene passato dai metodi corrispondenti della BranoMP3Action. E
ltima che istanza loggetto FileMP3 gestendo laggiornamento dei tag ID3v1
ricamento del file. La distinzione resa possibile dal fatto
, v ne invocata la action e non direttamente i metodi della classe BranoMP3.
il metodo acquista() non ha parametri di ingresso con JSF, in quanto le
zioni sullutente in sessione e della sua scheda prepagata vengono ricavate
ente allinterno del metodo. Con Struts, invece, il metodo acquista() della
P3Action che si occupa di accedere a queste variabili di sessione passandole al
acquista() della classe BranoMP3. Tutto ci evidenzia la riusabilit di questa
della business-logic in altri contesti, in quanto gli oggetti Utente e
repagata potrebbero essere generati da un meccanismo completamente diverso
tion.
363
_________________________________________________________________
Per a

-
- P3 residente sul server. Con JSF,
viene determinato il percorso del file sulla base dei parametri di ingresso,
una
package playlist contiene ununica classe che implementa tutte le
nzionalit che riguardano la gestione delle playlist, la classe Playlist. In entrambe le
plementazioni, le propriet della classe sono le seguenti :
- id : identificativo univoco della playlist;
qu nto riguarda la classe FileMP3, essa presenta i seguenti metodi :
upload() : esegue il caricamento del file MP3 sul server. Limplementazione
praticamente la stessa con JSF e Struts e prevede lapertuna di uno stream di
ingresso associato al file in locale, lapertura di uno stream di uscita associato
al file da creare sul server e la scrittura da uno stream allaltro per il
trasferimento;
elimina() : permette di eliminare il file M
genere e nomeFileMP3. Con Struts, non previsto alcun parametro in quanto le
informazioni sul path vengono specificate dal metodo elimina() della
BranoMP3Action, che poi invoca il metodo in questione;
- aggiornaTag() : esegue laggiornamento dei tag ID3v1 del file MP3.
Limplementazione la stessa in entrambi i casi e prevede lutilizzo degli
oggetti MP3File ed ID3v1 della Java MP3 Tag Library. Per ciascuna
informazione tra titolo, autore ed album, viene valutato se essa specificata
tra le informazioni del brano oppure nel corrispondente tag del file. In base al
fatto che uno dei due pu essere vuoto, viene eseguito il trasferimento del
valore dalluno allaltro;

E da sottolineare che per quanto riguarda il percorso dei file MP3, esso ha
struttura standard che dipende ovviamente dal nome del file ed anche dal genere
musicale. Tale struttura la seguente :

/ [ di r NomeWebAppl i cat i on] / mp3/ [ di r Gener e] / nomeFi l e. mp3

6.4.4 Package playlist

Il
fu
im

364
_________________________________________________________________
- nome : nome assegnato alla playlist;
- dataOraCreazione : data ed ora di creazione della playlist;

Limple
playlist
checkb
gi visto nella descrizione della View.
Per a
prevista
operazi
compos
BranoM

-
-
-

La prima differenza tra le due implementazioni riguarda la dipendenza con la classe
tente, presente con JSF ma non con Struts. Nel primo caso si rende necessaria per
FacesContext,
entre in Struts attraverso le classi HttpServletRequest e HttpSession.

mentazione con JSF prevede una propriet in pi, elimina, che indica se la
stata selezionata per leliminazione da un elenco di playlist attraverso una
ox. Con Struts, non necessaria in quanto sono utilizzate le multibox come
qu nto riguarda le dipendenze con altri classi, in entrambe le implementazioni
unassociazione con ComposizionePlaylistDB, mediante la quale poter gestire le
oni di inserimento e cancellazione di un brano nella playlist e quindi la
izione della stessa. Inoltre, ci sono delle dipendenze con le classi File,
P3 e PlaylistDB rispettivamente per :
creare e cancellare il file M3U con lelenco dei brani della playlist, necessario
al player MP3 per lascolto;
le operazioni di inserimento e cancellazione dei brani dalla playlist;
la gestione della permanenza delle informazioni associate alla playlist;
U
ricavare lutente a cui associata la playlist, mentre nel secondo caso tale operazione
viene gestita dalla action PlaylistAction. Infine, la tipica differenza relativa allaccesso
alle variabili di sessione, che con JSF viene effettuata tramite la classe
m

365
_________________________________________________________________

Figura 76 - JSF : package playlist

366
_________________________________________________________________

Figura 77 - Struts : package playlist

I metodi previsti dalla classe sono i seguenti :

- crea() : permette la . Con JSF, viene ricavato
dalla session lidentificativo dellutente che sta creando la playlist e viene
invocato il metodo PlaylistDB.inserisci(), per poi restituire loutcome per la
navigazione. Con Struts, riceve in ingresso lidentificativo dallutente che gli
viene passato dal metodo crea() della PlaylistAction da cui viene invocato ed
esegue linserimento nel database. E compito della action gestire la
navigazione nel caso o meno di errori;
creazione di una playlist vuota
367
_________________________________________________________________
- visualizzaInfo() : permette il caricamento delle informazioni della playlist
selezionata, che restituisce come parametro di uscita. La sua implementazione
perfettamente uguale in entrambi i casi;
- visualizzaElencoPlaylist() : permette di visualizzare lelenco delle playlist relative
ad un certo utente. Con JSF, ricava lidentificativo dellutente dalla session,
invoca PlaylistDB.elencoPlaylist(), salva la lista nella session e restituisce loutcome
per la navigazione. Con Struts, viene invocato dal metodo
visualizzaElencoPlaylist() della PlaylistAction, dal quale riceve lidentificativo
dellutente e restituisce la lista delle playlist associate a questultimo. E
compito della action salvare lelenco nella session e far proseguire la
navigazione;
- elimina(), eliminaPlaylists() : metodi che permettono di eliminare una singola
playlist oppure pi playlist selezionate da un elenco. In entrambi i casi, invoca
una o pi volte PlaylistDB.elimina(). La differenza tra le due implementazioni
sta nel fatto che con JSF, laggiornamento della lista in sessione viene fatto
allinterno di questi metodi mente con Struts, viene eseguito dai
corrispondenti metodi elimina() ed eliminaPlaylists() della PlaylistAction;
- eliminaM3U() : permette di eliminare i file M3U associati alle playlist di uno
specifico utente. Il principio di funzionamento lo stesso per entrambe le
implementazioni : una volta noto lidentificativo dellutente, viene ricavato
lelenco delle playlist associate. Si esegue un ciclo per scorrere tutte le playist e
per ciascuna di ess
- visualizzaElencoBraniMP3Playlist() : permette la visualizzazione dellelenco dei
orrente. Con JSF, viene invocato il
metodo ComposizionePlaylistDB.composizionePlaylist() e lelenco dei brani ricavato
-
linvocazione del metodo
ComposizionePlaylistDB.inserisci() una o pi volte. Con JSF, allinterno di questi
e ne viene cancellato il corrispondente file M3U;
brani che compongono la playlist c
viene salvato nella session, per poi restituire loutcome per la navigazione. Con
Struts, vine invocato dal corrispondente metodo della PlaylistAction al quale
restituisce lelenco dei brani contenuti nella playlist. E poi compito della
action salvare la lista in sessione e far proseguire la navigazione;
inserisciBranoMP3(), inserisciBraniMP3() : permettono di inserire un singolo
brano oppure pi brani allinterno di una specifica playlist. In entrambe le
implementazioni, prevedono
368
_________________________________________________________________
metodi vengono ricavate le informazioni dei brani da inserire e restituito
loutcome per la navigazione. Con Struts, queste operazioni vengono eseguite
nei metodi inserisciPlaylist() e inserisciBraniMP3Playlist() della BranoMP3Action;
-
aylistDB.composizionePlaylist() e la creazione di un file M3U in cui

E da o
statici
concett
general to dalle
pag
della cla
metodi
invocar
E da p playlist,
nec a
ha un n
della ste

/ [

- eliminaBraniMP3() : effettua leliminazione di uno o pi brani selezionati
dallelenco di composizione della playlist. In entrambe le implementazioni
viene eseguito un ciclo sullelenco dei brani selezionati per invocare il metodo
ComposizionePlaylistDB.elimina().
ascolta() : permette lascolto di una playlist. La sua implementazione
fondamentalmente la stessa con JSF e con Struts in quanto prevede il
caricamento dei brani costituenti la playlist con il metodo
ComposizionePl
scrivere i percorsi dei file MP3 associati ai brani da ascoltare;
sservare che i metodi visualizzaElencoPlaylist() ed eliminaPlaylists() sono definiti
nellimplementazione con Struts ma non con JSF. Da un punto di vista
uale ci corretto, in quanto le funzionalit sono relative alle playlist in
e e non ad una specifica playlist. Con Struts, ci possibile in quan
ine JSP vengono invocati i metodi delle action che a loro volta utilizzano i metodi
sse Playlist. Con JSF, invece, dalle pagine JSP si invocano direttamente questi
utilizzando il backing bean associato a questa classe, per cui non possibile
e metodi statici ma soltanto metodi di istanza.
recisare che il file M3U con i percorsi dei brani MP3 contenuti nella
ess rio per come opera il player MP3 utilizzato. Per rendere tale file univoco, esso
ome caratterizzato dallidentificativo della playlist concatenato con il nome
ssa. Il percorso in cui sono salvati tali file il seguente :
di r NomeWebAppl i cat i on] / mp3/ pl ayl i st / [ i d+nomePl ayl i st ] . m3u
369
_________________________________________________________________
6.4.5 P

a
disp iz
corrispo
proprie

-
-
-
ito per il pagamento
elle operazioni di acquisto e ricarica ed alla classe Utente, essendo associata ad un
ten so
FacesContext nel caso di JSF e direttamente con
HttpServletRequest ed HttpSession con Struts.

ackage scheda
Il package scheda contiene le classi SchedaPrepagata e Ricarica che mettono
os ione le funzionalit per la gestione della scheda prepagata e delle
ndenti operazioni di ricarica. La classe SchedaPrepegata prevede le stesse
t per entrambe le implementazioni :
- id : identificativo della scheda;
importoResiduo : importo presente sulla scheda;
dataOraAcquisto : data ed ora di acquisto della scheda;
dataScadenza : data di scadenza della scheda (ad un anno dallacquisto oppure
dallultima ricarica);

Allo stesso modo, la classe Ricarica prevede le seguenti propriet :

- id : identificativo delloperazione di ricarica;
- importo : importo della ricarica;
- dataOra : data ed ora in cui stata effettuata la ricarica;

Esse sono ovviamente legate fra loro, considerando che unoperazione di ricarica
sempre associata alla scheda su cui stata effettuata.
Per quanto riguarda le dipendenze con le altre classi dellapplicazione, la classe
Ricarica legata soltanto a RicaricaDB per gestire la permanenza delle operazioni di
ricarica. La classe SchedaPrepagata, invece, associata alla classe SchedaPrepagataDB per
gestire la persistenza delle sue informazioni, alla classe CartaCred
d
u te registrato. La differenza tra le due implementazioni risiede sempre nellacces
alle variabili di sessione, effetuato con
le classi

370
_________________________________________________________________

Figura 78 - JSF : package scheda

371
_________________________________________________________________

Figura 79 - Struts : package scheda

372
_________________________________________________________________
Per quanto riguarda la classe SchedaPrepagata, i suoi metodi sono i seguenti :
- acquista() : metodo che permette ad un utente lacquisto di una scheda
prepagata. Con JSF, esso ricava dalla session loggetto dellutente che sta
effettuando lacquisto e le informazioni della carta di credito e ne verifica la
copertura, calcola la data di scadenza della scheda, la inserisce nellarchivio
mediante il metodo SchedaPrepagataDB.inserisci() ed infine restituisce loutcome
per la navigazione. Con Struts, viene invocato dal metodo execute() della
AcquistoSchedaAction e riceve da questultima, in ingresso, gli oggetti relativi
allutente ed alla carta di credito che la action ha ricavato dai form. Opera allo
stesso modo dellimplementazione con JSF ma compito della action gestire
la navigazione;
- visualizzaInfo() : perfettamente identico nelle due implementazioni, poich
carica le informazioni della scheda mediante il metodo
SchedaPrepagataDB.leggi() e restituisce loggetto SchedaPrepagata corrispondente;
- ricarica() : permette di effettuare unoperazione di ricarica sulla scheda
corrente. Con JSF, ricava le informazioni della carta di credito dalla session e
quelle della ricarica dalla request, esegue il metodo Ricarica.esegui(), aggiorna
limporto residuo e la data di scadenza, aggiorna le informazioni nellarchivio
con il metodo SchedaPrepagatDB.aggiorna() ed infine restituisce loutcome per la
navigazione. Con Struts, viene invocato dal metodo execute() della
RicaricaSchedaAction dalla quale riceve gli oggetti SchedaPrepagata e Ricarica, le
cui informazioni sono prelevate dalla action dai form. Opera allo stesso
modo dellimplementazione con JSF ma compito della action gestire la
navigazione;
- controlloImportoResiduo() : viene utilizzato in fase di acquisto di un brano per
valutare se limporto residuo sufficiente, in relazione al costo ricevuto come
parametro di ingresso. E perfettamente uguale nelle due implementazioni;
- aggiornaImportoResiduo() : aggiorna limporto residuo della scheda una volta
effettuato lacquisto di un brano. Utilizza il metodo
SchedaPrepagataDB. te identico nelle due
implementazioni;

aggiorna() ed perfettamen
373
_________________________________________________________________
- controlloScadenza() : permette di valutare se la scheda sia scaduta o meno. Con
JSF, effettua il confronto della data di scadenza con la data attuale e nel caso

Cos co
due imp
prevede redito e Ricarica, grazie ai quali poter effettuare loperazione di
rica a
busines
essere g
La ss
due im
queste i

6.4.6 Packag

informa
una sc
caratter seguenti :

-
-
-

in cui la scheda sia scaduta la elimina dalla base di dati, aggiorna lutente che
non sar pi abilitato allacquisto di brani MP3 e restituisce un valore
booleano. Con Struts, effettua semplicemente il confronto tra le date ma le
operazioni di eliminazione della scheda, nel caso in cui sia scaduta, ed
aggiornamento dellutente vengono eseguite dalla LoginAction in cui il metodo
invocato;
me in altri casi, si osserva che il metodo ricarica() ha una signature diversa nelle
lementazioni. Con JSF non prevede parametri di ingresso mentre con Struts
loggetto CartaC
ric sulla scheda. In questo modo, si evidenzia lindipendenza della classe della
s-logic dal framework, in quanto gli oggetti ricevuti in ingresso potrebbero
enerati con meccanismi completamente diversi dalle action.
cla e Ricarica prevede banalmente lunico metodo esegui() il quale identico nelle
plementazioni e non fa altro che salvare la data e lora correnti e di inserire
nformazioni nellarchivio con il metodo RicaricaDB.inserisci().
e cartacredito
Questo package contiene soltato la classe CartaCredito che contiene le
zioni della carta di credito utilizzata dallutente per lacquisto o la ricarica di
heda prepagata. Per entrambe le implementazioni, le propriet che la
izzano sono le
tipo : tipologia di carta di credito (VISA, MasterCard, etc);
numero : numero della carta;
- codiceSegreto : codice segreto associato alla carta;
dataScadenza : data di scadenza della carta;
374
_________________________________________________________________

Figura 80 - JSF : package cartacredito

Figura 81 - Struts : package cartacredito
Essa non prevede una corrispondente classe per la gestione della persistenza, in
quanto una volta utilizzata, le relative informazioni vengono eliminate dalla sessione.

375
_________________________________________________________________
E stata realizzata a scopo puramente dimostrativo infatti, il suo unico metodo
verificaCopertura() restituisce sempre il valore true ad indicare che la carta di credito
coperta per il pagamento. Le uniche dipendenze previste sono con FacesContext in
JSF e le classi HttpServletRequest e HttpSession in Struts per semplificare laccesso in
sessione.

6.4.7 Package download

Il package download contiene la classe Download attraverso la quale si tiene
traccia dellacquisto di un brano MP3. La classe prevede lunica propriet
dataOraAcquisto che rappresenta la data e lora dellacquisto del brano, nonch
caratterizzata da un unico metodo, inserisci(), il quale non fa altro che invocare
ownloadDB.inserisci() per introdurre nellarchivio linformazione relativa
allacquisto/download di un brano da parte di un certo utente. Essa perfettamente
identica in entrambe le implementazioni.

D

Figura 82 - JSF e Struts : package download

6.4.8 Package mail

Il package mail contiene solo la classe Mail la quale perfettamente identica
in entrambe le implementazioni, non ha alcuna propriet e prevede soltanto il
metodo sendMessage() mediante il quale possibile inviare una mail. Esso utilizza la
classe Properties per fissare nelle propriet del sistema lhost che dovr occuparsi
dellinvio e la classe Ses mail server. Genera un
essaggio del tipo MimeMessage definendone il mittente, il destinatario, loggetto ed il
sion per stabilire una sessione con il
m
376
_________________________________________________________________
corpo che riceve come parametri di ingresso. Infine, invia il messaggio invocando il
metodo Transport.send().

Figura 83 - JSF e Struts : package mail
6.5 I Backing Beans di JavaServer Faces

Nellimplementazione realizzata utilizzando JavaServer Faces, tutte le classi
che costituiscono il Model sono dichiarate allinterno del file di configurazione come
backing beans (manag rantisce due antaggi
ndamentali :
ellinterfaccia utente pu essere associato ad una
p
method-binding, in modo da poter effettuare delle elaborazioni sui dati
contenuti nel backing bean stesso;

ed beans). Questo tipo di approccio ga v
fo

- ciascun componente d
ropriet di un backing bean attraverso il value-binding, in modo tale che
quando il form a cui appartiene il componente viene trasmesso, il valore che
assume il componente viene trasferito nella corrispondente propriet a cui
legato;
- utilizzando gli eventi , action e value-change, possibile invocare
direttamente da un componente un metodo di un backing bean, attraverso il
377
_________________________________________________________________
In base a quanto detto, evidente la netta differenza rispetto al framework Struts, per
quanto riguarda lacquisizione dei dati dai form e lesecuzione delle elaborazioni su di
ssi. Infatti, Struts utilizza i formbean le cui propriet sono associate ai campi di un
form in modo che, una volta che questultimo sia stato trasmesso, i valori dei campi
stessi vengano copiati nel formbean corrispondente. Sar compito della action che
riceve il formbean copiare tali dati nelle corrispondenti propriet di un oggetto del
Model, per poterne eseguire una qualsiasi elaborazione. JSF evita questa passaggio
intermedio facendo in modo che i valori dei campi dei form vengano copiati
direttamente nelle corrispondenti propriet di un backing bean.
Per quanto riguarda lavvio delle elaborazioni da una pagina JSP, Struts prevede il
concetto di action che viene invocata ad esempio alla pressione di un bottone oppure
di un link. La action riceve un formbean con i dati da elaborare, li trasferisce nelle
corrispondenti propriet di un oggetto del Model e su di esso invoca un metodo per
eseguire lelaborazione richiesta. JSF permette di avviare direttamente da una pagina
JSP un metodo di un backing bean, ossia di un oggetto del Model, nel quale ci
saranno automaticamen esto caso, si evita un
assaggio intermedio che riguarda lutilizzo delle action di Struts.
ne, faces-config.xml, possibile dichiarare
pportunamente ciascun backing bean specificandone il tipo, ossia la classe che lo
implemen
re lallocazione e la deallocazine dei backing bean quando necessario,
razie al meccanismo dell IoC (Inversion of Control) noto anche come DI (Dependency
Injection)
Un sem
al quale
ruolo.Ut
informazioni dellutente siano sempre accessibili durante la sua sessione di utilizzo
dell p

e
te i dati da elaborare. Anche in qu
p
Allinterno del file di configurazio
o
ta, e lambito di visibilit (scope) per indicare se sia accessibile soltanto
nellambito di una richiesta (request), di una sessione utente (session) oppure nel
contesto della servlet (application). In maniera del tutto automatica compito del
framework gesti
g
.
plice esempio la seguente dichiarazione del backing bean relativo allutente,
viene associato un nome, ne viene specificata la classe di appartenenza,
ente, ed infine indicato lambito di visibilit, session, in modo che le
ap licazione.
378
_________________________________________________________________
<managed- bean>
<managed- bean- name>ut ent e</ managed- bean- name>
<managed- bean- cl ass>r uol o. Ut ent e</ managed- bean- cl ass>
<managed- bean- scope>sessi on</ managed- bean- scope>
</ managed- bean>

Per completare il confronto tra JSF e Strus, relativo a questo aspetto, si prenda in
considerazione loperazione di login. Nel caso di JSF, stato dichiarato il backing
bean ruolo con unambito di visibilit strettamente legato alla richiesta.

<managed- bean>
<managed- bean- name>r uol o</ managed- bean- name>
<managed- bean- cl ass>r uol o. Ruol o</ managed- bean- cl ass>
</ managed- bean>

La pagina JSP, contenente il form per effettuare laccesso al sistema, prevede due
campi di testo associati alle propriet userName e password del backing bean suddetto,
cos come al bottone di invio associata lesecuzione del relativo metodo login().

. . .
<h: out put Text val ue=" #{bundl e. menuUser nameLabel }" / >
<h: i nput Text i d=" user Name" val ue=" #{r uol o. user Name}" / >

<h: out put Text val ue=" #{bundl e. menuPasswor dLabel }" / >
<h: i nput Secr et i d=" passwor d" val ue=" #{r uol o. passwor d}" / >

<h: out put Text val ue=" " / >
<h: commandBut t on act i on=" #{r uol o. l ogi n}"
val ue=" #{bundl e. menuBut t onLogi nLabel }"
st yl eCl ass=" but t onFor m" / >
. . .

Struts prevede unimplementazione completamente diversa, in cui nel file di
configurazione dichiarato il formbean loginForm, del tipo LoginForm, associato alla
action LoginAction.

. . .
<f or m- bean name=" l ogi nFor m" t ype=" f or mbean. Logi nFor m" / >
. . .
<act i on i nput =" / pages/ home. j sp" name=" l ogi nFor m" pat h=" / l ogi n"
scope=" r equest " t ype=" def aul t act i ons. Logi nAct i on" >
<f or war d name=" f ai l ur e" pat h=" / pages/ home. j sp" / >
</ act i on>
. . .

379
_________________________________________________________________
La pagina JSP prevede un form con due campi di testo associati alle propriet del
formbe

<ht ml : f or mact i on=" / l ogi n. do" >
an ed un bottone che avvia lesecuzione della action.
. . .
<t r >
<f mt : message key=" menuUser nameLabel " / >
</ t d>
<ht ml : t ext pr oper t y=" user Name" / >
</ t d>
</ t r >
<t r >
<f mt : message key=" menuPasswor dLabel " / >
</ t d>
<ht ml : passwor d pr oper t y=" passwor d" / >
</ t d>
</ t r >
. . .
<ht ml : submi t st yl eCl ass=" but t onFor m" >
<f mt : message key=" menuBut t onLogi nLabel " / >
</ ht ml : submi t >
</ ht ml : f or m>

Allint mbean
allogg su
quest

new Ruol o( ) ;
f or mToRuol o( f or m, r uol o) ;
7. Plug-in di Struts

e
le d allo
stesso Tiles che vengono dichiarati allinterno del file di configurazione appunto
ome plug-in. Ovviamente, lo sviluppatore ha la possibilit di realizzarne uno proprio
erno della action ci sar il codice che copia i dati del form dal for
etto corrispondente della business-logic, per poi invocare il metodo login()
ultimo.
. . .
/ / r i cavo l e i nf or mazi oni sul r uol o che t ent a di acceder e
Ruol o r uol o =
. . .
. . .
/ / i nvoco i l l ogi n sul Ruol o
r uol o = r uol o. l ogi n( ) ;

Il framework Struts prevede un particolare meccanismo per poter estender
sue funzionalit legato al concetto di plug-in. Basti pensare al Validator e
c
380
_________________________________________________________________
mediante una classe che implementi linterfaccia PlugIn. Il loro uso pu risultare utile
quando c la necessit di eseguire una certa operazione una sola volta ed allavvio
ellapplicazione. Proprio questa modalit di utilizzo stata adottata
nellimplme in StartupManager che, una volta
avviato, crea le liste di items che verrano usate in tutte le drop-down list
dellapplicaz s via.

d
netazione con Struts, realizzando il plug-
ione, ad esempio quella relativa alle province, agli stati e co

Figura 84 - Struts : StartupManager

Tale classe prevede i due tipici metodi di un plug-in :

- e le
p della Web application;
- ra dellapplicazione per distruggere il
prevede inoltre la propriet sc che unistanza della classe
ervletContext, in quanto allinterno di questultima che verranno salvate le liste
generate.
initi() : viene eseguito allavvio dellapplicazione e pu contenere tutt
operazioni necessarie allo startu
destroy() : viene invocato alla chiusu
plug-in;

Il plug-in realizzato
S
Infatti, ogni oggetto salvato allinterno del contesto della servlet ha un
ambito di visibilit di tipo application ed quindi accessibile in un qualsiasi punto
dellapplicazione ed comune a tutti gli utenti.
381
_________________________________________________________________
La generazione delle liste viene eseguita nel metodo init(), cos come il salvataggio nel
contesto della servlet, invocando il metodo setAttribute() sulla propriet sc. Infine, il
plug-in stato dichiarato nellopportuna sezione allinterno del file di configurazione.

<pl ug- i n cl assName=" pl ugi n. St ar t upManager " / >

Nellimplementazione con JSF, non essendo disponibile uno strumento come i plug-
in di Struts, stato realizzata la classe ItemsBean per la quale ne stato dichiarato un
backing bean nellambito di visibilit application.

Figura 85 - JSF : ItemsBean

Si osservi che le propriet della classe corrispondono esattamente alle liste necessarie
allinterno dellapplicazio eseguita allinterno del
framework istanzia questo backing bean.
8. N v

che differenzia maggiormente i due framework, in quanto essi sfruttano due
eccanismi diversi che comunque possono essere paragonati luno allaltro.

ne. La generazione delle liste viene
costruttore e quindi nel momento in cui il

a igazione
La navigazione allinterno dellapplicazione certamente uno degli aspetti
m
JavaServer Faces si basa sul concetto delle navigation-rules, allinterno di ciascuna delle
quali va definita la pagina di partenza della specifica regola e vanno definiti uno o
pi navigation-case che specificano, sulla base delloutcome rinvenuto dal
NavigationHandler, quale sia la pagina verso la quale proseguire la navigazione.

382
_________________________________________________________________
In base a quanto detto, ogni regola prevede :

- la pagina che rappresenta il punto di partenza di riferimento;
- uno o pi pagine destinazione che possibile raggiungere dalla suddetta
pagina
ultimo, il
NavigationHandler esegue una ricerca nel file di configurazione e determina verso
quale pagina deve proseguire la navigazione. Nel caso della Web application
implementata si evidenziata la non perfetta integrazione tra JSF e Tiles. Infatti, se si
utilizza questo framework per la definizione del layout, non possibile utilizzare le
regole di navigazione come spiegato in precedenza, ma necessario definire ununica
regola, senza alcuna pagina associata, allinterno della quale ci sono tutti i navigation-
case.
, ciascuna delle quali distinta da un differente outcome;

Ci vuol dire che, nel momento in cui viene invocato un metodo di un backing bean
da una certa pagina JSP, questultimo dovr restituire come parametro di uscita una
loutcome di navigazione. Sulla base di quest stringa che rappresenti

<navi gat i on- r ul e>
<f r om- out come>r egi st r azi one</ f r om- out come>
<t o- vi ew- i d>/ pages/ r egi st r azi one. j sp</ t o- vi ew- i d>
<f r om- out come>home</ f r om- out come>
<t o- vi ew- i d>/ pages/ home. j sp</ t o- vi ew- i d>
<f r om- out come>acqui st oRi car i caScheda</ f r om- out come>
<t o- vi ew- i d>/ pages/ acqui st oRi car i caScheda. j sp</ t o- vi ew- i d>
</ n
erendo
on il NavigationHandler.
e in JSF la definizione della navigazione viene dichiarata in termini generali, con
Struts descritta in maniera pi specifica e localizzata, allinterno delle action
avi gat i on- case>
. . .
</ navi gat i on- r ul e>

Il motivo di questo limite dato dal fatto che nel Deployment Descriptor web.xml
dellapplicazione realizzata con JSF, lutilizzo di Tiles specificato attraverso la
dichiarazione di unulteriore servlet, TilesServlet, che viene avviata immediatamente
dopo la FacesServlet e che intercetta per prima le richieste verso le pagine, interf
c
S
383
_________________________________________________________________
mediante il concetto di forward. Infatti, ciascuna action prevista dallapplicazione pu
vere un unico metodo execute() oppure pi metodi, nel caso di una DispatchAction,
che co iascun forward
spe ic
del file
a
munque restituiscono un oggetto del tipo ActionForward. C
cif a la pagina verso la quale proseguire la navigazione ed dichiarato allinterno
di configurazione, secondo due modalit :

- locale : relativo ad una specifica action che lunica che permette la
navigazione verso la pagina ad esso associata;
- globale : comune a tutte le action, in modo tale che ciascuna di esse possa
redirezionare il flusso dellapplicazione verso la pagina ad esso associata;

<act i on i nput =" / pages/ r egi st r azi one. j sp" name=" r egi st r azi oneFor m"
pat h=" / r egi st r azi one" scope=" sessi on"
t ype=" def aul t act i ons. Regi st r azi oneAct i on" val i dat e=" t r ue" >
<f or war d name=" l ogi n" pat h=" / l ogi n. do" / >
<f or war d name=" acqui st oScheda" pat h=" / pages/ acqui st oScheda. j sp" / >
<f or war d name=" f ai l ur e" pat h=" / pages/ r egi st r azi one. j sp" / >
</ act i on>

In un certo senso, il nome del forward restituito pu essere paragonato alloutcome di
JSF e ciascun forward pu essere equiparato ad un navigation-case cos come la
dic

9.

messa a
dis
possibile dichiarare uneccezione nel file di configurazione in modo tale che, nel caso
cui venga sollevata all terno del codice, entri in gioco in maniera automatica
hiarazione della action ad una navigation-rule.
Eccezioni
La gestione delle eccezioni dichiarative una potenzialit
posizione solo ed esclusivamente da Struts ma non da JSF. Infatti, con Struts,
in in
lExceptionHandler che si fa carico di gestirla. Inoltre, alleccezione stessa possibile
associare una pagina verso la quale redirezionare il flusso dellapplicazione.

<except i on bundl e=" Appl i cat i onResour ces" key=" er r or Dat abase"
pat h=" / pages/ er r or . j sp"

384
_________________________________________________________________
Nel caso di studio in esame, stato previsto lutilizzo delle eccezioni dichiarative per
poter visualizzare allutente una pagina di errore, qualora si verificasse qualche
problema di accesso alla base di dati. Moltissime applicazioni, in questi casi,
prevedono semplicemente la visualizzazione di errori di accesso assolutamente
incomprensibili allutente. Per evitare una situazione di questo tipo, si fatto in modo
he, se durante laccesso al database si verifica un errore, viene sollevata una
Mod E
configu visualizzata la pagina ad essa
asso at

. . .
catch
ricorso
lla semplice funzionalit di navigazione. Pi precisamente, nel caso in cui si verifichi

maniera
audolenta.

c
ule xception la quale intercettata dallExceptionHandler che la ricerca nel file di
razione e fa in modo che allutente venga
ci a.
} ( SQLExcept i on e) {
Modul eExcept i on me = new Modul eExcept i on( " er r or Dat abase" ) ;
throw me;
} finally {
. . .

JavaServer Faces non fornisce questa potenzialit per cui in questo caso si
a
un errore di accesso alla base di dati, viene sollevata uneccezione che, intercettata
allinterno del codice stesso, fa in modo che il metodo del backing bean in questione
restituisca loutcome verso la pagina di errore.

10. Sicurezza

La Web application realizzata prevede una funzionalit particolare,
nellambito della quale sono trasmessi dei dati fortemente sensibili, quali il numero ed
il codice della carta di credito, per lacquisto e la ricarica di una scheda prepagata. In
una situazione di questo tipo, si rende necessario lutilizzo di un meccanismo di
sicurezza mediante il quale sia possibile crittografare i dati inviati attraverso la rete, in
modo da renderli incomprensibili a chiunque riesca ad intercettarli in
fr
385
_________________________________________________________________
Gli elementi principali che permettono un approccio di questo tipo sono
fondamentalmente due :

- lacquisizione di un certificato digitale;
- uso del protocollo HTTPS, ossia HTTP basato su SSL (Secure Socket Layer);

Attraverso un certificato digitale, rilasciato dalla CA (Certification Authority),
sempre possibile essere a conoscenza dellidentit dellinterlocutore e decidere se
accettare o meno di stabilire una comunicazione con qeustultimo. Uno strumento di
uesto tipo risulta notevolmente utile, in virt del fatto che ci si potrebbe ritrovare a
scambiare informazioni con unentit sulla rete che non quella da noi attesa, ma che
ne n
cer tato rinosciuto da terze parti e quindi si ha la certezza che i dati
a verranno acquisiti dal destinatario corretto. Una delle funzionalit che
co HTTP basato su SSL (Secure Socket
ayer), che garantisce una cifratura con chiave a 128 bit.
Nel caso di studio in esame, per garantire la sicurezza, si sono rese necessarie le
ioni :
- cr
ssi a disposizione dallSDK di Java2, ossia keytool, che produce un
osiddetto keystore. Questultimo permette inoltre di specificare il tipo di algoritmo da
tilizzare per la crittografia, che nel caso specifico lRSA.

q
abbia preso il posto in maniera fraudolenta. Chiunque sia in possesso di u
tificato digitale s
tr smessi
possibile sfruttare mediante i certificati digitali la crittografia, mediante la quale
possibile cifrare i dati trasmessi e renderli illeggibili durante il loro invio. Soltanto il
destinatario, riconosciuto sulla base di un certificato digitale, avr la possibilit di
decrittografarli attraverso lutilizzo di una chiave. La comunicazione avviene
attraverso il protocollo HTTPS, ossia il tipi
L
seguenti operaz

eazione di un certificato digitale di esempio;
- abilitazione del Connector SSL nel Web Container Apache Tomcat;
- configurazione della pagine protette nel Deployment Descriptor
dellapplicazione;

La creazione del certificato digitale stata effettuta facendo uso di uno degli
strumenti me
c
u
386
_________________________________________________________________
keyt ool - genkey - al i as t omcat - keyal g RSA

Una volta creato il certificato, bisogna abilitare il Connector SSL del Web Container
Tomcat, mediante il quale possible redire municazioni protette,
verso una porta specificata e tramite protocollo HTTP. Per fare questo necessario
apportare u
keystore da utilizzare e la relativa password.
zionare tutte le co
na modifica al file di configurazione server.xml, allinterno del quale va
specificato il

<Connect or
por t =" 8443" maxThr eads=" 150" mi nSpar eThr eads=" 25"
maxSpar eThr eads=" 75" enabl eLookups=" f al se"
di sabl eUpl oadTi meout =" t r ue" accept Count =" 100" debug=" 0"
scheme=" ht t ps" secur e=" t r ue" cl i ent Aut h=" f al se"
ssl Pr ot ocol =" TLS" keyst or ePass=" changei t "
keyst or eFi l e=" C: \ Document s and Set t i ngs\ Paol o\ . keyst or e" / >

Per quanto riguarda la modifica da applicare alla Web application, essa del tutto
analoga in entrambe le implementazioni, tenendo conto del fatto che JSF e Struts
demandano la gestione della sicurezza al Web Container sottostante e non
forniscono un proprio particolare strumento. Allinterno del Deployment Descriptor
web.xml possibile specificare le pagine, la cui trasmissione deve essere effettuata su
protocollo HTTPS. In questo caso si deciso di rendere tutta lapplicazione sicura,
garantendo la trasmissione tramite SSL per tutte le pagine a partire dalla pagina di
ben venuto index.jsp.

<ur l - pat t er n>/ i ndex. j sp</ ur l - pat t er n>
PUT</ ht t p- met hod> <ht t p- met hod>
POST</ ht t p- met hod> <ht t p- met hod>
</ user - dat a- const r ai nt >

387
_________________________________________________________________
In questo modo irezione verso
cato digitale. La trasmissione dei dati tra
, alla richiesta dellURL iniziale viene segnalata la red
una connessione sicura garantita da un certifi
client e server avverr tramite il protocollo SSL in modalit crittografata.
Nella figura seguente, visibile il messaggio del browser Web che segnala il passaggio
ad una modalit di comunicazione protetta mediante protocollo SSL. E possibile
visionare le informazioni relative al certificato digitale, in modo da essere a
conoscenza dellinterlocutore e decidere se accettare o meno la trasmissione dei dati.

Figura 86 - Segnalazione del certificato digitale

Una avigazione allinterno della
Web application prosegue normalmente, ma visibile nella parte bassa del browser
(es. I garanzia di una comunicazione
prote
volta accettato il passaggio al protocollo HTTPS, la n
nternet Explorer 6) un lucchetto che indica la
tta e cifrata.
388
_________________________________________________________________

Figura 87 - Indicazione modalit protetta con SSL
389
Appendice A SRS Web Application MP3-Web
_________________________________________________________________
A Ap pp pe en nd di ic ce e A A S SR RS S W We eb b A Ap pp pl li ic ca at ti io on n M MP P3 3- -W We eb b

1. Introduzione

1.1 Propositi

Questo documento ha lo scopo di definire i requisiti e le specifiche del prodotto
software MP3 - Web, al fine di facilitarne la realizzazione e la validazione.
E destinato sia al committente del prodotto software che allo sviluppatore, al fine di
definire una base di riferimento per la validazione del prodotto e creare le premesse
per la produzione di un software di alta qualit.

1.2 Obiettivi

Il prodotto software MP3 - Web ha come obiettivo la realizzazione di una Web
application che permetta agli utilizzatori di usufruire di contenuti audio, quali brani
musicali in formato MP3 (MPEG Layer 3). Il sistema permette lautomatizzazione
delle seguenti operazioni, per quanto riguarda linterazione con lUtente :

1. Registrazione nelle versioni base ed estesa;
2. Identificazione dellUtente tramite lo Username e la Password;
3. Accesso allarchivio dei brani MP3;
4. Ricerche avanzate nellarchivio dei brani MP3;
5. Ascolto di un singolo brano MP3;
6. Gestione ed ascolto di playlist personalizzate contenenti brani MP3;
7. Acquisto e ricarica di una scheda prepagata per effettuare il download dei
brani MP3;
8. Acquisto e Download dei brani MP3;
9. Gestione dei propri dati personali;
10. Richiesta dei propri dati di accesso via mail;
11. Uscita dal sistema;
390
_________________________________________________________________
LAmministratore disporr di funzionalit avanzate, mediante le quali saranno
consentite le seguenti operazioni :

1. Identificazione dellAmministratore tramite lo Username e la Password;
2. Gestione dellarchivio dei brani MP3 per laccesso, la ricerca, linserimento, la
modifica e lascolto;
3. Gestione degli utenti registrati;
4. Gestione dei propri dati di accesso;
5. Uscita dal sistema;

1.3 Definizioni, Acronimi ed Abbreviazioni

Utente :
persona che ha effettuato la registrazione (base oppure estesa) e che risulta
abilitata allutilizzo dei servizi resi disponibili dalla scelta effettuata;

Amministratore :
persona addetta alla gestione degli archivi degli utenti e alla gestione dei servizi offerti
dal sistema;

Utilizzatore Ruolo :
persona non ancora identificata tra Utente ed Amministratore, che non ha effettuato
laccesso al sistema;

Servizio :
ciascuna delle attivit accessibili e consentite ad un qualunque tipo di utente o
allamministratore;

Registrazione :
contratto stipulato dallUtente, necessario per poter usufruire dei servizi offerti dal
sistema. Pu essere di due tipologie :

- base : permette di accedere a tutti i servizi a meno del download di brani MP3;
391
_________________________________________________________________
- esteso : offre i medesimi servizi della registrazione base ed in pi permette
lacquisto ed il download di brani MP3, previo lacquisto di una scheda
prepagata;

Username :
identificativo univoco dellUtente oppure dellAmministratore;

Password :
password di accesso al sistema dellUtente oppure dellAmministratore;

Playlist :
sequenza di ascolto dei brani musicali definita dallUtente;

1.4 Riferimenti

Standard IEEE 830-1993.

1.5 Generalit

Lintento di questo documento quello di descrivere le funzionalit che il software
deve soddisfare, le quali saranno specificate nel capitolo successivo in modo chiaro e
conciso.
Il resto del documento contiene lelenco delle funzioni che il prodotto software deve
avere insieme ai vincoli che deve soddisfare. Pi avanti nel testo sono presentate
linterfaccia (sia verso lUtente sia verso lAmministratore) dei servizi messi a
disposizione dal prodotto e linterfaccia verso lhardware. Al presente documento ne
sono allegati altri contenenti i diagrammi realizzati secondo lo standard UML,
necessari per la miglior comprensione del dominio applicativo.

392
_________________________________________________________________
2. Descrizione Generale

2.1 Prospettive del prodotto

Questo prodotto non si integra con nessun altro sistema software ed indipendente
ed autonomo per quanto riguarda lelaborazione(stand-alone).

2.2 Funzionalit

Il prodotto software MP3 - Web dovr :
nei confronti dellAmministratore fornire le seguenti funzionalit :
- accesso al sistema;
- registrazione dellaccesso;
- modifica della propria Password di accesso;
- gestione dellarchivio di brani MP3, che prevede :
- visualizzazione dei brani sulla base di criteri di ricerca specifici;
- inserimento di un nuovo brano in archivio;
- modifica delle informazioni di un brano;
- eliminazione di uno o pi brani dallarchivio;
- ascolto di un brano;
- gestione degli utenti registrati, che prevede :
- eliminazione di un utente;
- sblocco di un utente bloccato;
- uscita dal sistema;
- registrazione delluscita;
nei confronti dellUtente fornire le seguenti funzionalit :
- registrazione;
- richiesta via mail dei dati di accesso;
- accesso al sistema;
- registrazione dellaccesso;
393
_________________________________________________________________
- modifica dei propri dati personali;
- accesso allarchivio dei brani, che prevede :
- visualizzazione dei brani sulla base di criteri di ricerca specifici;
- ascolto di un brano;
- acquisto e download di un brano;
- gestione di playlist personalizzate, che prevede :
- visualizzazione delle playlist gi create in precedenza;
- creazione di una nuova playlist;
- eliminazione di una o pi playlist;
- inserimento ed eliminazione di brani da una playlist;
- ascolto di una playlist;
- acquisto e download di un brano presente in una playlist
- gestione di una propria scheda prepagata, che prevede :
- acquisto di una scheda prepagata;
- ricarica della propria scheda prepagata;
- uscita dal sistema;
- registrazione delluscita;

2.3 Caratteristiche Utente

Il prodotto software destinato ad utenti che abbiano una conoscenza di base
nellutilizzo di Personal Computer e relativi software per la produttivit personale;
mentre gli amministratori, che usano il software di gestione, hanno bisogno di una
conoscenza informatica di base.

394
_________________________________________________________________
2.4 Vincoli Generali

I vincoli generali sono i seguenti :

- LUtente che richiede laccesso ai servizi del sistema deve digitare
esclusivamente il proprio Username e la relativa Password;
- LUtente non pu inserire pi di 2 volte una Password errata;
- AllUtente non permesso lacquisto oppure la ricarica di una scheda
prepagata, se il credito su conto corrente, cui fa riferimento la carta di
credito per il pagamento, insufficiente.
- LUtente non pu acquistare ed effettuare il relativo download di un
brano MP3 se non in possesso di una scheda prepagata oppure se il
credito residuo sulla scheda prepagata insufficiente;
- LAmministratore non pu inserire pi di 2 volte una Password errata;
- LAmministratore che richiede laccesso ai servizi del sistema deve
digitare esclusivamente il proprio Username e la relativa Password;
- La Password di accesso dellUtente o dellAmministratore pu essere
composta da almeno 5 caratteri alfanumerici;

2.5 Assunzioni e Dipendenze

Il Sistema software dovr essere utilizzato su una macchina dotata di sistema
operativo Windows 95/98/Me/2000/Xp oppure di una distribuzione Linux, con
128 Mb di memoria RAM, Hard Disk da 10 GB ed una connessione Internet
consigliata ADSL.

395
_________________________________________________________________
3. Requisiti Specifici

3.1 Requisiti di interfaccia esterna

3.1.1 Interfaccia Utente

E richiesta uninterfaccia utente visuale, con finestre, bottoni e form di immissione
dati.

3.1.2 Interfaccia Hardware

Il sistema software non si interfaccia con alcun particolare sistema hardware.

3.1.3 Interfaccia Software

Il sistema software non si integra e non comunica con nessun altro sistema software.

3.1.4 Interfaccia di Comunicazione

La comunicazione fra il sistema software lato client e quello lato server, si svolge
utilizzando la rete Internet e si basa fondamentalmente sullaccesso di un database
condiviso localizzato sul server stesso.

396
_________________________________________________________________
3.2 Requisiti Funzionali

Classe Amministratore
3.2.1 Login

3.2.1.1 Introduzione
Questa funzionalit permette allAmministratore di accedere al sistema.
3.2.1.2 Input
Username (obbligatorio)
Password (obbligatorio)
3.2.1.3 Elaborazione
Visualizzazione di un form per linput dei dati, sui quali il sistema esegue
le seguenti operazioni :

Controlla che la Username e la Password siano corrette e cio
corrispondano a quelle memorizzate nellarchivio. Se il controllo
va a buon fine, viene permesso laccesso, altrimenti viene
concesso un altro tentativo ed in caso di un ulteriore errore, viene
registrato laccaduto e bloccato laccesso al sistema;
Controlla che lAmministratore non sia gi loggato;
Registrazione dei dati relativi allaccesso;
Verifica dei diritti di accesso;
Visualizzazione del men per accedere alle aree di gestione;
3.2.1.4 Output
Menu di accesso alle aree di gestione.
Dati relativi allaccesso registrati in archivio :
Data ed Ora di login
Indirizzo IP
Validit login
Tentativo

397
_________________________________________________________________
Messaggi :
Username e/o Password errati
Tentativi di accesso esauriti : sistema bloccato
Gi loggato

3.2.2 Modifica Password Amministratore

Questa funzionalit permette allAmministratore di modificare i propri
dati di accesso al sistema, nella fattispecie soltanto la password. E
ovviamente previsto che lAmministratore abbia gi eseguito il login,
altrimenti la funzionalit non disponibile.
3.2.2.2 Input
Identificativo Amministratore (obbligatorio)
Password nuova (obbligatorio)
Conferma Password nuova (obbligatorio)

Controlla che la Password nuova e Conferma Password siano
almeno di 5 caratteri e visualizza eventualmente un messaggio di
errore;
Controlla che la Password nuova e la Conferma Password
coincidano, altrimenti visualizza un messaggio di errore;
Registrazione dei nuovi dati inseriti;
3.2.2.4 Output
Parte dei dati letti in input che vengono registrati in archivio :
Password nuova;

Messaggi :
La Password nuova e la sua Conferma non coincidono
398
_________________________________________________________________
La Password deve avere una lunghezza di almeno 5 caratteri
La Conferma Password deve avere una lunghezza di almeno 5
caratteri
Aggiornamento effettuato con successo

3.2.3 Visualizzazione elenco brani MP3 per genere musicale

Questa funzionalit permette allAmministratore di visualizzare lelenco
dei brani MP3 presenti in archivio, relativamente ad un determinato
genere musicale
3.2.3.2 Input
Genere Musicale (obbligatorio)
Visualizzazione di un form con lelenco dei generi musicali disponibili,
sulla base del quale, effettuando una scelta, il sistema effettua le seguenti
operazioni :

Controlla che sia stato selezionato un Genere Musicale;
Caricamento dei dati presenti in archivio;
Visualizzazione dellelenco dei brani MP3 sulla base del genere
musicale scelto;
3.2.3.4 Output
Elenco dei brani musicali relativi al genere scelto

Messaggi :
Nessun genere musicale selezionato
Nessun brano disponibile in archivio per questo genere

399
_________________________________________________________________
3.2.4 Ricerca di un brano MP3 secondo uno o pi criteri

Questa funzionalit permette allAmministratore di cercare uno o pi
brani MP3 allinterno dellarchivio, sulla base di propri criteri, per poter
effettuare su di essi delle eventuali operazioni.
3.2.4.2 Input
Titolo
Autore
Genere Musicale
Album
Visualizzazione di un form che permette allAmministratore di stabilire i
propri criteri di ricerca dei brani MP3. Inoltre, il sistema effettua le
seguenti operazioni :

Controlla che almeno uno fra i campi Titolo, Autore, Genere
Musicale e Album non sia vuoto;
Visualizzazione dellelenco dei brani MP3;
3.2.4.4 Output
Elenco dei brani musicali che corrispondono ai criteri impostati.

Messaggi :
Nessun brano corrisponde ai criteri impostati
Non stato impostato alcun criterio di ricerca

400
_________________________________________________________________
3.2.5 Inserimento di un brano MP3

Questa funzionalit permette allAmministratore di inserire un nuovo
brano MP3 in archivio. Le informazioni relative al brano possono essere
specificate dallAmministratore oppure vengono lette dal sistema
direttamente dal file MP3 caricato sul server, tramite i tag MP3.
3.2.5.2 Input
Titolo
Autore
Album
Durata
Costo (obbligatorio)
File MP3 del brano (obbligatorio)
Visualizzazione di un form per linput dei dati sui quali il sistema esegue

Controlla che sia stato selezionato un File MP3 da caricare nel
sistema;
Nel caso in cui lAmministratore non abbia specificato le
informazioni del brano, queste vengono estratte direttamente dal
File MP3 caricato, tramite i tag MP3 e si controlla comunque che
alcuni tag MP3 non siano specificati;
Verifica che ci sia coerenza tra le informazioni immesse
dallAmministratore ed i tag MP3;
Registrazione dei dati di input in archivio;
3.2.5.4 Output
Tutti i dati letti in input registrati in archivio.
Altri dati registrati in archivio :
Dimensione (in byte)
401
_________________________________________________________________

Messaggi :
Inserimento brano effettuato con successo
Il tag relativo al titolo vuoto
Il tag relativo al genere musicale vuoto
Il tag relativo allautore vuoto

3.2.6 Visualizzazione informazioni di un brano MP3

Questa funzionalit permette allAmministratore di visualizzare le
informazioni dettagliate di un brano MP3 presente in archivio.
3.2.6.2 Input
Identificativo brano MP3 (obbligatorio)
Dati caricati dal sistema provenienti dallarchivio.
Visualizzazione delle informazioni dettagliate del brano selezionato;
3.2.6.4 Output
Informazioni dettagliate del brano selezionato.

3.2.7 Modifica informazioni di un brano MP3

Questa funzionalit permette allAmministratore di modificare le
informazioni di un brano MP3 presente in archivio, garantendo la
coerenza con i tag MP3 del brano stesso.

3.2.7.2 Input
Titolo
Autore
402
_________________________________________________________________
Album
Durata
Costo (obbligatorio)
Visualizzazione di un form, contenente i dati attuali relativi al brano MP3,
caricati dallarchivio, per linput dei nuovi dati sui quali il sistema esegue
le seguenti operazioni:

Controlla che i campi relativi a Genere Musicale e Costo non
siano vuoti;
Aggiornamento dei tag MP3 del brano per garantire la coerenza
con le informazioni in archivio;
3.2.7.4 Output

Messaggi :
Non stato selezionato alcun genere musicale

3.2.8 Cancellazione di un brano MP3

Questa funzionalit permette allAmministratore di cancellare uno o pi
brani MP3 presenti in archivio.
3.2.8.2 Input
Visualizzazione di un form, contenente lelenco dei brani MP3 per genere
musicale oppure sulla base di una specifica ricerca, con possibilit di
selezionare i brani da cancellare. E possibile cancellare un brano anche
403
_________________________________________________________________
dalla funzionalit di visualizzazione delle sue informazioni dettagliate.
Inoltre, il sistema effettua le seguenti operazioni :

Controlla che sia stato selezionato almeno un brano MP3;
Eliminazione dei dati presenti in archivio relativi al/i brano
selezionato/i;
Visualizzazione dellelenco dei brani;
3.2.8.4 Output
Elenco dei brani.

Messaggi :
Eliminazione effettuata con successo
Non stato selezionato alcun brano

3.2.9 Ascolto di un brano MP3

Questa funzionalit permette allAmministratore di ascoltare in streaming
un brano MP3.
3.2.9.2 Input
Visualizzazione di un form per lavvio della riproduzione del brano MP3
selezionato. Inoltre, il sistema effettua le seguenti operazioni :

Controlla che sia stato selezionato un brano MP3 da ascoltare;
Caricamento del player MP3 per la ricezione in streaming e la
riproduzione del brano;
3.2.9.4 Output
Messaggi :
Non stata selezionata alcun brano da ascoltare

404
_________________________________________________________________
3.2.10 Visualizzazione elenco utenti

Questa funzionalit permette allAmministratore di visualizzare lelenco
degli utenti iscritti.
3.2.10.2 Input
Visualizzazione dellelenco degli utenti;
3.2.10.4 Output
Elenco degli utenti.

Messaggi :
Nessun utente registrato

3.2.11 Cancellazione di un utente

Questa funzionalit permette allAmministratore di cancellare uno o pi
utenti presenti in archivio.
3.2.11.2 Input
Identificativo Utente (obbligatorio)
Visualizzazione di un form, contenente lelenco degli utenti, con
possibilit di selezionare gli utenti da cancellare. E possibile cancellare un
utente anche dalla funzionalit di visualizzazione dei suoi dati anagrafici.
Inoltre, il sistema effettua le seguenti operazioni :

Controlla che sia stato selezionato almeno un utente;
Eliminazione dei dati presenti in archivio relativi all/gli utente/i
selezionato/i;
405
_________________________________________________________________
Visualizzazione dellelenco degli utenti;
3.2.11.4 Output
Elenco degli utenti.

Messaggi :
Nessun utente stato selezionato

3.2.12 Visualizzazione dati anagrafici utente

Questa funzionalit permette allAmministratore di visualizzare i dati
anagrafici di un utente presente in archivio.
3.2.12.2 Input
Visualizzazione dei dati anagrafici dellutente selezionato;
3.2.12.4 Output
Dati anagrafici dellutente selezionato.

3.2.13 Sblocco di un utente

Questa funzionalit permette allAmministratore di sbloccare un Utente
che ne abbia fatto richiesta ufficiale via telefono o via mail.
3.2.13.2 Input
Registrazione dei dati in archivio, ossia del sblocco dellUtente.

406
_________________________________________________________________
3.2.13.4 Output
Sblocco Utente.

3.2.14 Logout

Questa funzionalit permette allAmministratore di eseguire il logout dal
sistema.
3.2.14.2 Input
Identificativo Amministratore (obbligatorio)
Registrazione dei dati in archivio che tengono traccia del logout;
3.2.14.4 Output
Dati relativi alluscita dal sistema registrati in archivio :
Data ed Ora di logout

Classe Utente

3.2.15 Login

Questa funzionalit permette allUtente di accedere al sistema.
3.2.15.2 Input

Controlla che la Username e la Password siano corrette e cio
corrispondano a quelle memorizzate nellarchivio. Se il controllo
va a buon fine, viene permesso laccesso, altrimenti viene
407
_________________________________________________________________
concesso un altro tentativo ed in caso di un ulteriore errore, viene
registrato laccaduto e bloccato laccesso al sistema;
Controlla che lUtente non sia gi loggato;
Registrazione dei dati relativi allaccesso;
Verifica dei diritti di accesso;
Visualizzazione del men per laccesso alle aree di utente;
3.2.15.4 Output
Men di accesso alle aree di utente.
Dati relativi allaccesso registrati in archivio :
Data ed Ora di login
Indirizzo IP
Validit login
Tentativo

Messaggi :
Username e/o Password errati
Tentativi di accesso esauriti : impedito laccesso
Gi loggato

3.2.16 Registrazione

Questa funzionalit permette allUtente di effettuare la registrazione, per
usufruire dei servizi offerti dalla web application.
3.2.16.2 Input
Dati dellUtente :
Email (obbligatorio)
Acquisto MP3 (si/no)

408
_________________________________________________________________

Controlla che i campi relativi allEmail, Username, Password e
non siano vuoti o non validi, in particolare lEmail abbia una
struttura corretta e la Password abbia una lunghezza di almeno 5
caratteri;
Controlla che lo Username non sia gi presente in archivio;
Passaggio alla funzionalit di acquisto scheda prepagata qualora
lUtente voglia usufruire della funzionalit di download;
3.2.16.4 Output
Altri dati registrati :
Data/Ora registrazione

Messaggi :
Registrazione effettuata con successo
Email non valida
Il campo relativo allemail non pu essere vuoto
Il campo relativo alla Username non pu essere vuoto
Il campo relativo alla Password non pu essere vuoto
La Password deve essere almeno di 5 caratteri

3.2.17 Acquisto scheda prepagata per il download di brani MP3

Questa funzionalit permette allUtente di acquistare una scheda
prepagata virtuale, mediante la quale pu eseguire lacquisto e quindi il
download degli MP3.
409
_________________________________________________________________
3.2.17.2 Input
Nome (obbligatorio)
Cognome (obbligatorio)
Indirizzo (obbligatorio)
Citt (obbligatorio)
Provincia
CAP
Stato (obbligatorio)
Telefono
Data di Nascita
Sesso
Tipo Carta di Credito (obbligatorio)
Numero Carta di Credito (obbligatorio)
Data scadenza Carta di Credito (obbligatorio)
Codice Segreto (obbligatorio)
Importo (obbligatorio)

Controlla che i campi relativi al Nome, Cognome, Indirizzo, Citt
e Stato non siano vuoti;
Controlla che sia stato selezionato un Tipo di Carta di Credito;
Controlla che il campo relativo al Numero Carta di Credito non
siano vuoto o non valido;
Controlla che sia stata specificata la Data di Scadenza;
Controlla che il campo relativo al Codice Segreto della carta non
sia vuoto;
Controlla che sia stato selezionato un Importo;
Controllo dei dati attraverso il sistema bancario;
410
_________________________________________________________________
Registrazione dati relativi allimporto della scheda prepagata,
registrati in archivio;
3.2.17.4 Output
Alcuni dei dati di input registrati in archivio :
Importo
Altri dati registrati in archivio
Data/Ora acquisto scheda prepagata
Data scadenza scheda prepagata

Messaggi :
Il Controllo sul circuito bancario non ha avuto successo
Scheda prepagata acquistata con successo
Non stata selezionata alcuna carta di credito
Il campo relativo al numero carta di credito non pu essere vuoto
Il campo relativo al numero carta di credito ha un formato non
valido
Non stata specificata la data di scandenza
Il campo relativo al codice segreto non pu essere vuoto
Non stato selezionato alcun importo per la scheda prepagata
Il campo relativo al nome non pu essere vuoto
Il campo relativo al cognome non pu essere vuoto
Il campo relativo allindirizzo non pu essere vuoto
Il campo relativo alla citt non pu essere vuoto
Il campo relativo allo stato non pu essere vuoto

3.2.18 Ricarica scheda prepagata per il download di brani MP3

Questa funzionalit permette allUtente di ricaricare la scheda prepagata
virtuale, mediante la quale pu eseguire lacquisto e quindi il download
degli MP3.

411
_________________________________________________________________
3.2.18.2 Input
Identificativo utente (obbligatorio)
Tipo Carta di Credito (obbligatorio)
Numero Carta di Credito (obbligatorio)
Data scadenza Carta di Credito (obbligatorio)
Codice Segreto (obbligatorio)
Importo Ricarica (obbligatorio)

Controlla che sia stato selezionato un Tipo di Carta di Credito;
Controlla che il campo relativo al Numero Carta di Credito non
siano vuoto o non valido;
Controlla che sia stata specificata la Data di Scadenza;
Controlla che il campo relativo al Codice Segreto della carta non
sia vuoto;
Controlla che sia stato selezionato un Importo di Ricarica;
Controllo dei dati attraverso il sistema bancario;
Registrazione dati relativi allimporto della ricarica, registrati in
archivio;
3.2.18.4 Output
Alcuni dei dati di input registrati in archivio :
Importo Ricarica
Altri dati registrati in archivio
Data/Ora ricarica

Messaggi :
Il Controllo sul circuito bancario non ha avuto successo
Ricarica eseguita con successo
Non stata selezionata alcuna carta di credito
Il campo relativo al numero carta di credito non pu essere vuoto
412
_________________________________________________________________
Il campo relativo al numero carta di credito ha un formato non
valido
Non stata specificata la data di scandenza
Il campo relativo al codice segreto non pu essere vuoto
Non stato selezionato alcun importo per la ricarica

3.2.19 Visualizzazione importo residuo e scadenza scheda prepagata

Questa funzionalit permette allUtente di visualizzare limporto residuo e
la data di scadenza della scheda prepagata virtuale, mediante la quale
pu eseguire lacquisto e quindi il download degli MP3.
3.2.19.2 Input
Controlla che la scheda non sia scaduta;
Visualizzazione dellimporto residuo e della data di scadenza;
3.2.19.4 Output
Importo residuo e data di scadenza della scheda prepagata.

Messaggi :
Attenzione ! La scheda scaduta

3.2.20 Modifica dati personali

Questa funzionalit permette allUtente di modificare i propri dati
personali.
3.2.20.2 Input
Dati dellUtente :
Nome (obbligatorio)
413
_________________________________________________________________
Cognome (obbligatorio)
Indirizzo (obbligatorio)
CAP
Stato (obbligatorio)
Provincia
Citt (obbligatorio)
Telefono
Data di Nascita
Sesso
Password nuova (obbligatorio)
Conferma Password nuova (obbligatorio)
Visualizzazione di un form, contenente i dati attuali relativi allUtente
caricati dallarchivio, per linput dei nuovi dati sui quali il sistema esegue
le seguenti operazioni

Controlla che i campi relativi allEmail, Username, Password
vecchia e nuova e Conferma Password non siano vuoti o non
validi, in particolare lEmail abbia una struttura corretta e la
Password abbia una lunghezza di almeno 5 caratteri;
Controlla che i campi relativi al Nome, Cognome, Indirizzo, Citt
e Stato non siano vuoti;
Controlla che la Password nuova e la Conferma Password
coincidano, altrimenti visualizza un messaggio di errore;
3.2.20.4 Output

414
_________________________________________________________________
Messaggi :
Email non valido
Il campo relativo allemail non pu essere vuoto
Il campo relativo alla Username non pu essere vuoto
Il campo relativo alla Password nuova non pu essere vuoto
Il campo relativo alla Conferma Password non pu essere vuoto
La Password deve essere di almeno 5 caratteri
la Password ed il relativo campo di Conferma non coincidono
Il campo relativo al nome non pu essere vuoto
Il campo relativo al cognome non pu essere vuoto
Il campo relativo allindirizzo non pu essere vuoto
Il campo relativo alla citt non pu essere vuoto
Il campo relativo allo stato non pu essere vuoto

3.2.21 Visualizzazione elenco playlist

Questa funzionalit permette allUtente di visualizzare lelenco delle
playlist create in precedenza per poterle ascoltare.
3.2.21.2 Input
Visualizzazione dellelenco delle playlist;
3.2.21.4 Output
Elenco delle playlist.

Messaggi :
Nessuna playlist creata in precedenza

415
_________________________________________________________________
3.2.22 Creazione di una playlist

Questa funzionalit permette allUtente di creare una nuova playlist.
3.2.22.2 Input
Nome Playlist (obbligatorio)
Visualizzazione di un form, per linput dei dati sui quali il sistema esegue
le seguenti operazioni

Controlla che il campo relativo al Nome Playlist non sia vuoto;
3.2.22.4 Output
Data/Ora creazione

Messaggi :
Playlist creata con successo
Il campo relativo al nome della playlist non pu essere vuoto

3.2.23 Cancellazione di una playlist

Questa funzionalit permette allUtente di cancellare uno o pi playlist
create in precedenza.
3.2.23.2 Input
Identificativo Playlist (obbligatorio)
Visualizzazione di un form, contenente lelenco delle playlist, con
possibilit di selezionare quali cancellare. Inoltre, il sistema effettua le
seguenti operazioni :
416
_________________________________________________________________

Controlla che sia stato selezionata almeno una playlist;
Eliminazione dei dati presenti in archivio relativi alla/e playlist
selezionata/e;
Visualizzazione dellelenco delle playlist;
3.2.23.4 Output

Messaggi :
Non stata selezionata alcuna playlist

3.2.24 Visualizzazione brani presenti nella playlist

Questa funzionalit permette allUtente di visualizzare lelenco dei brani
MP3 che compongono una particolare playlist.
3.2.24.2 Input
Visualizzazione dellelenco dei brani;
3.2.24.4 Output
Elenco dei brani MP3 presenti allinterno della playlist.

Messaggi :
La playlist vuota

417
_________________________________________________________________
3.2.25 Ascolto della playlist

Questa funzionalit permette allUtente di ascoltare in streaming i brani
MP3 che costituiscono una playlist.
3.2.25.2 Input
Visualizzazione di un form per lavvio della riproduzione dei brani
contenuti nella playlist. Inoltre, il sistema effettua le seguenti operazioni :

Controlla sia stata selezionata una playlist da ascoltare;
riproduzione della playlist;
3.2.25.4 Output
Messaggi :
Non stata selezionata alcuna playlist da ascoltare

3.2.26 Visualizzazione elenco brani MP3 per genere musicale

Questa funzionalit permette allUtente di visualizzare lelenco dei brani
MP3 presenti in archivio, relativamente ad un determinato genere
musicale
3.2.26.2 Input
Visualizzazione di un form con lelenco dei generi musicali disponibili,
sulla base del quale, effettuando una scelta, il sistema effettua le seguenti
operazioni :

Controlla che sia stato selezionato un Genere Musicale;
418
_________________________________________________________________
Visualizzazione dellelenco dei brani MP3 sulla base del genere
musicale scelto;
3.2.26.4 Output
Elenco dei brani musicali relativi al genere scelto

Messaggi :
Nessun genere musicale selezionato
Nessun brano disponibile in archivio per questo genere

3.2.27 Ricerca di un brano MP3 secondo uno o pi criteri

Questa funzionalit permette allUtente di cercare uno o pi brani MP3
allinterno dellarchivio, sulla base di propri criteri, per poter effettuare su
di essi delle eventuali operazioni, tra cui lascolto, il download e
linserimento in una playlist.
3.2.27.2 Input
Titolo
Autore
Genere Musicale
Album

Visualizzazione di un form che permette allUtente di stabilire i propri
criteri di ricerca dei brani MP3. Inoltre, il sistema effettua le seguenti
operazioni :

Controlla che almeno uno fra i campi Titolo, Autore, Genere
Musicale e Album non sia vuoto;
Visualizzazione dellelenco dei brani musicali;
419
_________________________________________________________________
3.2.27.4 Output
Elenco dei brani musicali che corrispondono ai criteri impostati.

Messaggi :
Nessun brano corrisponde ai criteri impostati
Non stato impostato alcun criterio di ricerca

3.2.28 Visualizzazione informazioni di un brano MP3

Questa funzionalit permette allUtente di visualizzare le informazioni
dettagliate di un brano MP3 presente in archivio.
3.2.28.2 Input
Visualizzazione delle informazioni dettagliate del brano selezionato;
3.2.28.4 Output
Informazioni dettagliate del brano selezionato.

3.2.29 Ascolto di un brano MP3

Questa funzionalit permette allUtente di ascoltare in streaming un
brano MP3.
3.2.29.2 Input
Visualizzazione di un form per lavvio della riproduzione del brano MP3
selezionato. Inoltre, il sistema effettua le seguenti operazioni :

420
_________________________________________________________________
Controlla che sia stato selezionato un brano MP3 da ascoltare;
riproduzione dle brano;
3.2.29.4 Output
Messaggi :
Non stata selezionata alcun brano da ascoltare

3.2.30 Inserimento di un brano MP3 allinterno di una playlist

Questa funzionalit permette allUtente di inserire un brano MP3
allinterno di una playlist.
3.2.30.2 Input
Identificativo brano MP3 (obbligatorio);
Nome Playlist (obbligatorio);

Visualizzazione di un form per linput dei dati sui quali il sistema esegue

Controlla che sia stato selezionato un brano MP3 da aggiungere
ad una playlist;
Controlla che sia stata selezionata la Playlist di destinazione nella
quale inserire il brano;
3.2.30.4 Output

Messaggi :
Inserimento brano effettuato con successo
Non stata selezionata la playlist di destinazione
421
_________________________________________________________________
3.2.31 Cancellazione di un brano MP3 da una playlist

Questa funzionalit permette allUtente di cancellare uno o pi brani
MP3 dalla playlist selezionata.
3.2.31.2 Input
Identificativo brano MP3 (obbligatorio);
Identificativo playlist (obbligatorio);

Visualizzazione di un form per la selezione del/i brani da rimuovere. Il
sistema, inoltre, effettua le seguenti operazioni :

Controlla che sia stato selezionato almeno un brano;
Eliminazione dei dati presenti in archivio relativi al/i brani
selezionati;
3.2.31.4 Output
Elenco dei brani presenti nella playlist.

Messaggi :

3.2.32 Acquisto/Download di un brano MP3

Questa funzionalit permette allUtente di acquistare ed effettuare il
download di un brano MP3 presente in archivio.
3.2.32.2 Input

422
_________________________________________________________________
Il sistema controlla che limporto residuo sia sufficiente allacquisto
del brano MP3. In caso negativo, avvia la funzionalit di acquisto di
una scheda prepagata oppure di ricarica.
Caricamento dei dati dallarchivio relativi al brano selezionato;
Riduzione dellimporto residuo nella scheda prepagata in base al
costo del brano;
Abilitazione al download;
Registrazione dei dati in archivio;
3.2.32.4 Output
Tutti i dati letti in input registrati in archivio
Data acquisto

Messaggi :
Acquisto del brano eseguito con successo
Importo insufficiente sulla scheda prepagata, prego ricaricare
Nessuna carta prepagata a disposizione, effettuarne lacquisto

3.2.33 Richiesta username/password

Questa funzionalit permette allUtente di chiedere linvio di una mail
contenente la username e la password, qualora se ne fosse dimenticato.
3.2.33.2 Input
Visualizzazione di un form per linserimento dei dati, sui quali il sistema
effettua le seguenti operazioni :

Controlla che il campo relativo alla Email non sia vuoto e sia
valido;
423
_________________________________________________________________
Invio della mail contenente username e password;
3.2.33.4 Output
Messaggi :
Mail inviata con successo
Il campo relativo alla Email non pu essere vuoto
LEmail ha un formato non valido
Email non registrata in archivio

3.2.34 Logout

Questa funzionalit permette allUtente di eseguire il logout dal sistema.
3.2.34.2 Input
Identificativo utente (obbligatorio)
Registrazione dei dati in archivio che tengono traccia del logout;
3.2.34.4 Output
Dati relativi alluscita dal sistema registrati in archivio :
Data ed Ora di uscita

3.3 Requisiti di prestazioni

Nessuno.

3.4 Vincoli di progetto

Nessuno.

424
_________________________________________________________________
3.5 Attributi

3.5.1 Sicurezza

Come strumento di protezione previsto lutilizzo di una Password al fine di evitare
accessi al sistema da parte di persone non autorizzate.

3.6 Altri requisiti

3.6.1 Database

Il sistema software prevede lutilizzo di un database relazionale per larchiviazione dei
dati.
425
Riferimenti Bibliografici
_________________________________________________________________
R Ri if fe er ri im me en nt ti i B Bi ib bl li io og gr ra af fi ic ci i

C Ca ap pi it to ol lo o I I

N. Ford - Art of Java Web Development - Ed. Manning

K. D. Mann - JavaServer Faces in Action - Ed. Manning

C. Cavaness - Programming Jakarta Struts 2nd Edition - Ed. OReilly

M. Pianciamore - Principi di Ingegneria del Software Design Pattern - CEFRIEL

G. Mecca - Applicazioni Web J2EE : Java Servlet, corso di Tecnologie di sviluppo
per il Web - Universit della Basilicata

J. Falkner, K. Jones - Servlets and JavaServer Pages : The J2EE technology Web tier - Ed.
Addison Wesley
C Ca ap pi it to ol lo o I II I

E. Armstrong, J. Ball, S. Bodoff, D.B. Carson, I. Evans, D. Green, K. Haase, E.
Jendrock - The J2EE 1.4 Tutorial (cap. 17,18,19,20,21) - Sun Microsystems

K. D. Mann - JavaServer Faces in Action - Ed. Manning

Doris Chen Ph.D. - JavaServer Faces and Sun Java Studio Creator : Experience the Next
Generation Web-Application Framework, Sun Tech Days 2005 - Sun Microsystems

D. Goyal, V. Varma - Introduction to JavaServer Faces (JSF) - Sun Microsystems

E. Burns - About Faces : The JavaServer Faces API and how it relates to Struts - Sun
Microsystems
426
_________________________________________________________________

S. Shin - J2EE Advanced (www.javapassion.com) - Sun Microsystems

M. Hall - Tutorial JavaServer Faces 1.1 (www.coreservlets.com)

A. Winder, C. Straub - Extreme Reuse in JavaServer Faces Technology , JavaOne -
Suns 2005 Worldwide Java Developer Conference - Oracle

J. Pardi JavaServer Faces, 25 Maggio 2005
C Ca ap pi it to ol lo o I II II I

Apache Software Foundation - Official Struts documentation

Apache Software Foundation, C. Dumoulin - Official Struts Tiles documentation

C. Cavaness - Programming Jakarta Struts 2nd Edition - Ed. OReilly

J. Holmes - Struts : The Complete Reference - Ed. McGraw/Hill

S. Spielman - The Struts framework : Practical guide for Java programmers - Ed. Morgan
Kaufmann

T. Husted, C. Dumoulin, G. Franciscus, D. Winterfeldt - Struts in action : building
Web applications with the leading Java framework - Ed. Manning

S. Shenoy - Struts survival guide : basics to best practices Ed. ObjectSource

M. Robinson, E. Finkelstein - Jakarta Struts for dummies - Ed. Wiley Publishing

R. W. Barnes - Introduction to Struts - Project Refinery

S. Shenoy - Struts for J2EE Developers (www.objectsource.com)
427
_________________________________________________________________

C. Cavaness - Jakarta Struts 1.1 : ready for prime time, Atlanta Java Users Group
(AJUG) 2002

D. Lucek - Basic Struts Web development (www.lucek.com)
C Ca ap pi it to ol lo o I IV V

E. Burns - About Faces : The JavaServer Faces API and how it relates to Struts - Sun
Microsystems

C. McClanahan The Best of Both Worlds: Integrating JSF with Struts in Your J2EE
Applications (www.oracle.com)

R. Barcia - JavaServer Faces vs Struts : A brief comparison (websphere.sys-con.com)

C. McClanahan - JavaServer Faces and Struts : Competition or Coexistence ?

SAML Security JavaServer Faces : A comparative study (www.oneinfoplace.com)

K.D. Mann Migrating from Struts to JavaServer Faces - Virtua

K. D. Mann - From Struts to JavaServer Faces , Evolving your Web applications to support
the new standard (www.jsfcentral.com)

C. McClanahan - The evolution of Web application architectures, OReilly Open Source
Convention 2005

D. Geary - JavaServer Faces : Finally, a component model for enterprise Java!, Denver Java
Users Group 2003

428
_________________________________________________________________
C Ca ap pi it to ol lo o V V

R.S. Pressman - Principi di Ingegneria del Software - Ed. McGraw/Hill

P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone - Basi di dati, seconda edizione -
Ed. McGraw/Hill

G. A. Di Lucca - Corso di Ingegneria del Software, slide a.a. 2003-2004 - Universit
degli Studi del Sannio

Sybase - Sybase Power Designer : Conceptual Data Model , Users Guide

Sybase - Sybase Power Designer : Object Oriented Model , Users Guide

Sybase - Sybase Power Designer : Physical Data Model , Users Guide
C Ca ap pi it to ol lo o V VI I

A. Cioroianu - Upload Files with JSF and MyFaces (www.onjava.com)

B. Dudney - Creating JSF Custom Components (www.java.net)

R. Hightower - JSF for nonbelievers : JSF component development (www.ibm.com)

Apache Software Foundation - Apache Jakarta Tomcat 5 official documentation : SSL
Configuration How-to

S. Smirnov - How to use Tiles with JSF Exadel
A Ap pp pe en nd di ic ce e A A S SR RS S W We eb b A Ap pp pl li ic ca at ti io on n M MP P3 3- -W We eb b

Software Engineering Standards Committee of the IEEE Computer Society
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1993
429

Pa Tierno

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Pa Tierno

Caricato da

Copyright:

Formati disponibili

Universit degli studi di Napoli Federico II

Potrebbero piacerti anche