Prova Tesi ver. 3.7 _ margini _ - Raoul Musci

Introduzione alle Web Applications
UNICAL
Università della Calabria
Corso di Laurea in Ingegneria Informatica e
Applicazioni in Rete
Titolo tesi:
Sviluppo di un'applicazione Web Based
dedicata alla gestione di profili utente su un generico Web Site
interattivo con strumenti Open Source.
Una soluzione Open Source per lo sviluppo di
Web Applications tramite l’uso dei nuovi
framework “Struts” e “Hibernate”
Relatore:
Sergio Flesca
Candidato:
Musci Raoul
Mtr.57435
1
Introduzione alle Web Applications
Sommario
CAPITOLO I – INTRODUZIONE ALLE WEB APPLICATIONS ............................................... 4
1.0 STRUTTURA DI UNA WEB APPLICATION ......................................................................................... 4
1.1 PROBLEMATICA SULLE WEB APPLICATIONS .................................................................................. 6
1.2 IL FRAMEWORK STRUTS ............................................................................................................... 6
1.3 IL DESIGN PATTERN MVC ............................................................................................................ 7
1.3.1 JSP Model 1 ......................................................................................................................... 8
1.3.2 JSP Model 2 ......................................................................................................................... 9
1.4 LA PERSISTENZA DEI DATI .......................................................................................................... 11
1.5 IL FRAMEWORK HIBERNATE ....................................................................................................... 12
CAPITOLO II – SCELTE TECNOLOGICHE............................................................................... 14
2.0 LE TECNOLOGIE .......................................................................................................................... 14
2.0.1 Ambiente di sviluppo - Java (J2EE)................................................................................... 14
2.0.2 La scelta del Pattern di progetto ....................................................................................... 15
2.1 I FRAMEWORK OPENSOURCE...................................................................................................... 15
2.1.1 Perchè Apache Struts? ....................................................................................................... 16
2.1.2 Hibernate un aiuto alla persistenza ................................................................................... 16
2.1.3 JSP, XHTML e CSS............................................................................................................ 17
2.2 LA SCELTA DEL DBMS .............................................................................................................. 18
2.3 IL SERVER WEB TOMCAT ............................................................................................................ 19
2.4 L'AMBIENTE DI PROGRAMMAZIONE ............................................................................................ 19
2.4.1 Il plug-in Exadel Studio 3.6 ............................................................................................... 20
2.4.2 Il plug-in Omondo.............................................................................................................. 20
CAPITOLO III – ANALISI E PROGETTAZIONE....................................................................... 21
3.0 INTRODUZIONE ........................................................................................................................... 21
3.1 REQUISITI ................................................................................................................................... 22
3.2 PROGETTAZIONE ........................................................................................................................ 23
3.3 USE CASE DIAGRAMS ................................................................................................................. 23
3.3.1 Use Case “Generale” ........................................................................................................ 24
3.3.2 Use Case “Gestione Abbonamenti Utente” ....................................................................... 25
3.3.3 Use Case “Gestione dati personali” ................................................................................. 26
3.3.4 Use Case “Gestione Utenti”.............................................................................................. 27
3.3.5 Use Case “Gestioni Servizi” ............................................................................................. 28
3.3.6 Use Case “Registrazione nuova Utenza” .......................................................................... 29
3.3.7 Casi d’uso comuni: Login, Logout .................................................................................... 30
3.4 ACTIVITY DIAGRAMS ................................................................................................................. 31
3.4.1 Activity Diagram “Generale” ........................................................................................... 32
3.4.2 Activity Diagram “Login” ................................................................................................. 33
3.4.3 Activity Diagram “Recupero Psw” ................................................................................... 34
3.4.4 Activity Diagram “Registrazione nuova utenza” .............................................................. 35
3.4.5 Activity Diagram “Gestione dati personali” ..................................................................... 36
3.4.6 Activity Diagram “Gestione Abbonamenti Utente” .......................................................... 37
3.4.7 Activity Diagram “Gestione Servizi” ................................................................................ 38
3.4.8 Activity Diagram “Gestione Utenti” ................................................................................. 39
3.5 CLASS DIAGRAM ........................................................................................................................ 40
3.5.1 Progettazione del DBMS ................................................................................................... 44
2
Introduzione alle Web Applications
3.5.2 Conceptual Data Model ..................................................................................................... 45
3.5.3 Physical Data Model ......................................................................................................... 46
CAPITOLO IV – IMPLEMENTAZIONE ...................................................................................... 48
4.0 CONSIDERAZIONI INIZIALI .......................................................................................................... 48
4.1 STRUTTURA DELL’APPLICAZIONE .............................................................................................. 48
4.1.1 Directory dell’applicazione web ........................................................................................ 49
4.2 USO DEL PLUG-IN EXADEL ......................................................................................................... 52
4.3 SVILUPPO DELLA PERSISTENZA................................................................................................... 53
4.3.1 Implementazione per la didattica....................................................................................... 54
4.3.2 Realizzazione della Web-Application Struts: La sezione View e Controller...................... 62
4.4 ACCESSO ALLA SEZIONE AMMINISTRATIVA ................................................................................ 64
4.4.1 Funzionalità implementate ................................................................................................ 65
4.4.2 Gestione Utenti .................................................................................................................. 65
4.4.3 Gestione Servizi ................................................................................................................. 68
4.4.4 Gestione abbonamenti ....................................................................................................... 71
4.4.5 Registrazione nuove utenze ................................................................................................ 73
BIBLIOGRAFIA ................................................................................................................................ 75
3
Introduzione alle Web Applications
Capitolo I – Introduzione alle Web Applications
1.0 Struttura di una web application
Sebbene il Web sia nato come architettura per la disseminazione di contenuti digitali
multimediali, la sua rapida evoluzione ne ha reso evidente l'efficacia per la fornitura
di servizi e applicazioni avanzate, sia in ambito Internet sia nel contesto di sistemi
informativi aziendali in architettura intranet.
Un’applicazione web è un programma che risiede su un web server e produce pagine
statiche e dinamiche create secondo un linguaggio di markup ( Html ) in risposta alla
richiesta di un utente, il quale interagisce con essa, inviando richieste tipicamente
attraverso un browser, ad esempio cliccando su un link in una pagina Web. Lo
schema seguente mostra una vista ad alto livello di un’architettura web.
Web Server
Web Container
Java
Servlets
JSP
Page
Browser
DB
Per costruire una web application ci si riferisce alla piattaforma Java 2 Enterprise
Edition ( J2EE ), la quale provvede come supporto per le Servlets, le JSP e gli EJB,
etc..
4
Introduzione alle Web Applications
Il programma che gestisce questi componenti è chiamato web container e provvede
anche a fornire servizi come:
Sicurezza
Concorrenza
Gestione del ciclo di vita
Un esempio di web container è Apache Tomcat il quale rappresenta l’implentazione
ufficiale delle specifiche J2EE e JSP( una specifica è un documento che descrive tutti
i dettagli di una tecnologia ).
Tipicamente un web container in ogni modo funziona anche come web server
provvedendo a fornire un supporto HTTP di base agli utenti che vogliono accedere
alle informazioni sul sito. Ad esempio quando le richieste riguardano contenuti
statici, il web server soddisfa la richiesta direttamente senza includere Servlets o
pagine JSP. Mentre se vogliamo che la pagina di risposta si adatti in base ad una
specifica richiesta di un utente bisogna generare allora una pagina dinamica la quale
contenga una servlet e una porzione JSP.
5
Introduzione alle Web Applications
1.1 Problematica sulle web applications
Ponendoci ora in un contesto dove un programmatore con il compito di progettare
applicazioni web conosce sicuramente le basi delle Web application ed usa come
linguaggio di programmazione java perché potente e flessibile, sicuramente per
sviluppare pagine web interattive creerà delle servlets e delle pagine Jsp ( JavaServer
Pages ). Bene a questo punto lo sviluppo dell’applicazione web del programmatore
potrebbe via via diventare complessa e poco gestibile.
In questo scenario per permettere invece che la progettazione appaia a chi la
implementa più lineare e semplice e che possa inoltre prendere minori risorse di
tempo, possiamo usare il framework Jakarta Struts.
1.2 Il framework Struts
Jakarta Struts è un framework open source per lo sviluppo di applicazioni web,
basato, come riportato sul sito ufficiale http://struts.apache.org , su tecnologie
standard ed oramai consolidate, come:
Java Servlets: Programmi scritti in Java che risiedono su un Web server e
rispondono alle richieste degli utenti.
JavaServer Pages: Una tecnologia per generare pagine web sia con contenuti
statici che dinamici.
JavaBeans: Componenti che seguono regole specifiche.
Pensato per facilitare sviluppatori di web application pienamente aderenti alla
piattaforma J2EE della SUN, fornisce una infrastruttura unica, versatile e solida che
permette di costruire applicazioni web di grosse dimensioni e di alta qualità con una
forte riduzione dei tempi di sviluppo, agevolando la suddivisione dello sviluppo del
progetto fra vari sotto-team che potranno lavorare in parallelo. È facile immaginare,
come ciò si traduca in grossi vantaggi economici per chi lo adotta ed il perché in
breve tempo stia diventando il framework più usato dalla comunità di sviluppatori
Java.
6
Introduzione alle Web Applications
Il framework Struts è stato realizzato per la prima volta da Craig R. McClanahan ed è
stato poi donato alla Apache Software Foundation (ASF) nel 2000. Il progetto
inizialmente inquadrato come sotto-progetto di Apache Jakarta, dato il suo sviluppo,
è diventato oggi un progetto a se che coinvolge in maniera cospicua diversi soggetti
in tutto il mondo che contribuiscono alla buona riuscita del framwork.
In una definizione più dettagliata, potremmo dire che Struts è un MVC web
application framework, ovvero è un framework per lo sviluppo di applicazioni web
J2EE basato sul pattern Model-View-Controller. Lo sviluppatore dovrà quindi solo
riempire i pezzi della struttura. L’ MVC design pattern aiuta ad organizzare i vari
pezzi dell’applicazione per ottenere la massima efficienza e flessibilità.
1.3 Il design pattern MVC
Uno dei principali requisiti di qualsiasi applicazione web è quello di definire un
modello applicativo che consenta di disaccoppiare i diversi componenti
dell'applicazione in base al loro ruolo nell'architettura per ottenere vantaggi in
termini di riusabilità e manutenibilità. Esempio tipico di questo problema è l'utilizzo
nello sviluppo di una applicazione web J2EE di quei modelli applicativi che nella
letteratura sono indicati spesso come "JSP Model 1" e “JSP Model 2”, introdotti con
le prime specifiche delle JavaServer Pages.
7
Introduzione alle Web Applications
1.3.1 JSP Model 1
Da sole, JavaServer Pages consentono di realizzare applicazioni web dinamiche
accedendo a componenti Java contenenti logiche di business o alla base dati del
sistema. In questo modello il browser accede direttamente ad una pagina JSP che
riceve i dati di input, li processa utilizzando eventualmente oggetti Java, si connette
alla base dati effettuando le operazioni necessarie e ritorna al client la pagina html
prodotta come risultato della processazione dei dati.
In base a questo modello l'applicazione è costruita secondo una logica "JSP centric"
in base alla quale presentation , control e business logic dell'applicazione sono tutti a
carico delle pagine JSP. Il web browser accede direttamente alle pagine JSP
dell'applicazione che al loro interno contengono logica applicativa e logica di
controllo del flusso. Quando l'applicazione cresce in complessità non è pensabile
svilupparla seguendo un simile approccio.
8
Introduzione alle Web Applications
1.3.2 JSP Model 2
Il secondo modello, utilizza JavaServer Pages come strumento per sviluppare
template demandando completamente ad una particolare servlet la processazione dei
dati di input.
Nell’architetture Model 2 la richiesta del client viene intercettata prima da una
servlet, detta controller servlet. Questa gestisce l’elaborazione iniziale della richiesta
e determina quale pagina JSP deve essere visualizzata.
Dunque in questa architettura un client non invia mai direttamente una richiesta a una
pagina jsp. Ciò permette alla servlet di effettuare una elaborazione di front-end
comprendente
autorizzazione
ed
autenticazione,
logging
centralizzato
e
internazionalizzazione. Una volta terminata l’elaborazione della richiesta, la servlet
dirige la richiesta alla giusta pagina JSP. Come si vede la differenza principale tra le
due architetture è la presenza di questo punto di accesso ai servizi singolo,
rappresentato dalla servlet, il che incoraggia il riutilizzo e la separazione tra i vari
strati dell’applicazione. Proprio per questo il pattern Model 2 è più conosciuto come
pattern MVC (Model-View-Controller) Secondo questo pattern, i componenti di
un'applicazione vengono
9
Introduzione alle Web Applications
logicamente classificati a seconda che siano gestori di logiche di business e di
accesso ai dati (model), gestori di visualizzazione dati e dell'input dell'utente (viewer
o view) e gestori del flusso di controllo complessivo dell'applicazione (controller).
L’accoppiamento tra i vari livelli è minimo, con evidenti vantaggi in termini di
riusabilità, manutenibilità, estensibilità e modularità.
In pratica, si hanno innegabili vantaggi come:
indipendenza tra i business data (model) la logica di presentazione (view) e
quella di controllo (controller)
separazione dei ruoli e delle relative interfacce
viste diverse per il medesimo model
semplice supporto per nuove tipologie di client: bisogna scrivere la vista ed il
controller appropriati riutilizzando il model esistente
Di seguito è presentato un diagramma d’interazione che evidenza le responsabilità
dei tre componenti:
Controller
Browser
Model
View
JSP
10
Introduzione alle Web Applications
1.4 La persistenza dei dati
Di database relazionali n’è piena la terra, milioni di milioni di record vi trovano
posto ogni giorno oramai da diversi decenni. I database server relazionali sono
affidabili, stabili, lavorano bene con enormi quantità di dati, sono veloci nelle
operazioni d’ordinamento e ricerca. Dimostrano tutta la loro robustezza quando
gestiscono transazioni, accessi concorrenti e garantiscono vincoli di integrità
referenziale e correttezza di dati anche se condivisi da molteplici applicazioni. Al
giorno d’oggi l’ostacolo ricorrente è quello di memorizzare lo stato degli oggetti che
compongono il dominio applicativo in una base di dati, la maggior parte delle volte
costituita da un database relazionale. Le più recenti soluzioni per l’archiviazione di
grosse moli di dati orientate agli oggetti ed ancora all’xml non hanno avuto il
consenso inizialmente sperato, forse proprio per non essere state da subito all’altezza
degli RDBMS sul campo delle performance e della scalabilità. D’altro canto però, si
è dovuto ammettere, nel corso degli anni, che tabelle e record non sono al passo dei
tempi sul piano dell’astrazione semantica e della modellazione. Difficilmente
sapremmo più fare a meno dei vantaggi che ci offre il pensare ad oggetti le nostre
applicazioni in termini di suddivisione in componenti, riutilizzabilità, manutenibilità.
Proprio quando la programmazione orientata agli oggetti cerca ulteriori paradigmi
che ne amplino la potenza espressiva la mancanza di polimorfismo al modello
relazionale ed il carattere ancora prevalentemente procedurale ( e a volte inefficiente!
) delle stored procedure rendono necessarie linee e linee di codice (Java e soprattutto
SQL) per coordinare inserimenti, aggiornamenti, ricerche ed ancora conversioni tra
tipi di dati, gestione di driver. Hibernate si pone qui, nel bel mezzo del gap che c’è
tra il modello ad oggetti che tutti sappiamo tirar fuori dalla logica della nostra
applicazione ed il caos di tabelle, chiavi primarie, vincoli relazionali.
11
Introduzione alle Web Applications
Applicazione
Classe
Verticalizzazione
Hibernate
Framework
Driver JDBC
Database ( MySql )
Tabella
1.5 Il framework Hibernate
È un software free, open source e distribuito sotto licenza LGPL. Hibernate è stato
sviluppato da un team di programmatori Java sparsi per il mondo ( guidati da Gavin
King ). Hibernate fornisce un framework semplice da usare, che mappa un modello
di dominio orientato agli oggetti in un classico database relazionale. Hibernate non si
occupa solo di mappare dalle classi Java in tabelle del database, ma fornisce anche
degli aiuti per le query di dati, il recupero di informazioni e riduce significativamente
il tempo che altrimenti sarebbe speso lavorando manualmente in SQL e con JDBC.
Obiettivo di Hibernate è di esonerare lo sviluppatore dall'intero lavoro relativo alla
persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore,
sia se si parte da zero sia se da un database già esistente. Questo framework genera le
chiamate SQL e toglie allo sviluppatore dal lavoro di recupero manuale dei dati e
dalla sua conversione, mantenendo l'applicazione portabile in tutti i database SQL.
Inoltre fornisce una persistenza trasparente per "Plain Old Java Object"; l'unica
12
Introduzione alle Web Applications
grossa richiesta per la persistenza di una classe è la presenza di un costruttore senza
argomenti. In aggiunta un POJO disegnato in fase di modellazione del dominio
applicativo, per poter essere gestito da Hibernate deve semplicemente aderire alle
fondamentali regole dei più pratici java beans: metodi pubblici getXXX e setXXX
per le proprietà persistenti.
Livello Presentazione
Dominio Applicativo
Hibernate
DB Relazionale
Configuration
JDBC
Session
Factory
JDNI
Sessions
JTA
Hibernate.cfg.xm
l
13
Introduzione alle Web Applications
Capitolo II – Scelte Tecnologiche
In questo capitolo si vogliono descrivere le scelte tecnologiche fatte per la
realizzazione del progetto. Verrà descritto principalmente come esse si integrano
nell'architettura globale dell'applicativo, facendo riferimento anche ad alcune
tecnologie scartate in fase di progettazione, con annesse motivazioni.
2.0 Le tecnologie
Com'è noto, per sviluppare un'applicazione Web completa esistono svariati metodi di
sviluppo, i quali si basano su una moltitudine di linguaggi di programmazione
differenti e design pattern.
Ovviamente tra tutte queste tecnologie, è necessario scegliere quella, o quelle, che
permettono il raggiungimento dell'obiettivo, mantenendo saldi i canoni di sviluppo
richiesti dal progetto stesso.
Come concordato in fase di presentazione del progetto, in questo caso si voleva un
applicativo la cui struttura risultasse flessibile, aggiornabile ed espandibile. Per
ottenere tali risultati, è stato necessario scegliere prima di tutto un appropriato pattern
di sviluppo, in modo da avere ben chiara la modalità operativa e la struttura
dell'architettura.
2.0.1 Ambiente di sviluppo - Java (J2EE)
Una fase molto importante in fase di progettazione, è la scelta di un buon ambiente di
sviluppo. In questo caso si è deciso di sviluppare il tutto basandosi sulla piattaforma
“Enterprise” di Java, ovvero la versione J2EE.
Ovviamente sarebbe stato possibile implementare tutte le componenti tramite
linguaggi di scripting, come ASP o PHP. Ciò avrebbe sicuramente semplificato di
molto la fase iniziale e accorciato i tempi per la realizzazione dell'intero progetto;
ma, purtroppo l'utilizzo improprio di tali tecnologie rende spesso molto complicata la
manutenzione e l'evoluzione dell'applicazione.
Proprio per questa motivazione sono state scartate.
14
Introduzione alle Web Applications
Una volta selezionato Java, come base di questo applicativo, si è scelto di adottare la
versione J2EE in quanto include già di default alcune specifiche per “application
server”, ad esempio il supporto di Servlet e Jsp senza la richiesta di librerie
aggiuntive.
2.0.2 La scelta del Pattern di progetto
Come detto in precedenza, l'obiettivo primario è quello di realizzare un'applicazione
flessibile, sia dal punto di vista della realizzazione, sia dal punto di vista della
manutenzione. Al termine di queste considerazioni la scelta del Pattern MVC visto
nel capitolo precedente (Model View Controller) è sembrata quasi d'obbligo, in
quanto il suo intento è proprio quello di disaccoppiare il più possibile, tra loro, le
parti dell'applicazione, adibite al controllo, all'accesso dei dati e alla presentazione.
L'utilizzo di tale metodologia fornisce una serie d’innegabili vantaggi come:
Indipendenza tra i business data (model), la logica di presentazione
(view) e quella di controllo (controller)
Separazione dei ruoli e delle relative interfacce
Per futuri supporti a nuove tipologie di client, è su_ciente scrivere la
vista (view) ed il controller riutilizzando il model esistente
2.1 I Framework Opensource
L'intera applicazione è stata sviluppata tramite due grossi Framework Open Source,
portando grossi vantaggi in fase d'implementazione, tra cui la possibilità di ottenere
un prodotto facilmente aggiornabile e modificabile in futuro.
15
Introduzione alle Web Applications
2.1.1 Perchè Apache Struts?
Come sarà possibile vedere quasi tutta la sezione di controller è stata implementata
tramite un framework Open Source basato su Java, denominato Struts. In pratica
Struts estende le Java Servlet incoraggiando gli sviluppatori all'utilizzo del pattern
Model-View-Controller, all'interno di applicativi Web. Struts concentra la sua
attenzione nella divisione dei compiti fra le varie entità che gestisce. In prima battuta
possiamo dire che, data una successione di pagine da visionare, Struts vincola
l'ordine in cui queste devono essere visitate.
Ad esempio, se un utente cerca di accedere ad una pagina che richiede
un'autenticazione senza aver preventivamente fatto il login, il framework lo ridirigerà
verso il form di autenticazione.
Un altro motivo che ha influenzato nella scelta di questo interessante Framework, è
sicuramente la gestione della internazionalizzazione dei contenuti: tale strumento
permette infatti il controllo centralizzato dei file contenenti le stringhe testuali da
visualizzare in dipendenza della lingua impostata dal browser ( ottimo per le
estensioni future dell’applicazione). Una volta realizzata una piattaforma Web,
semplicemente traducendo un solo file di testo, è possibile supportare una nuova
lingua, senza modificare il codice.
In contrapposizione a Struts, ultimamente, altri framework MVC più leggeri, come
Spring, stanno raggiungendo un discreto successo; ad ogni modo si è preferito per la
soluzione d’Apache, in quanto è ben documentato in rete, e perché è pienamente
compatibile con Hibernate, un altro framework utilizzato e illustrato più avanti.
2.1.2 Hibernate un aiuto alla persistenza
Per completare la realizzazione del componente di Model si è deciso di inserire un
framework, che lavori come interfaccia tra questo componente e il Controller del
pattern MVC. Il framework prescelto si chiama Hibernate e fornisce una serie di
librerie Java da includere nel server web. Grazie a questo Framework è possibile
mappare le varie entità presenti nel database semplicemente tramite classi Java, cosa
che ha permesso di creare l'interfaccia tra la componente Model e la componente di
Controllor. Hibernate permette di lavorare indipendente dal DBMS scelto e di
16
Introduzione alle Web Applications
accedere a degli oggetti Java, tramite la programmazione object oriented, collegati
indirettamente alle tabelle vere e proprie del database. La scelta di Hibernate, ricade
sempre nell'ottica di permettere future modifiche anche alla base del nostro
applicativo, senza dover riscrivere linee di
codice. Ad esempio se si decidesse di utilizzare database Postgres o Oracle, sarà
sufficiente modificare una riga del file di configurazione di Hibernate (
hibernate.cfg.xml ).
Ovviamente lo studio di tale framework ha comportato inizialmente una perdita di
tempo non indifferente, ripagata durante lo sviluppo e soprattutto sul funzionamento
dell'applicazione.
Infine in questo progetto si è deciso di sfruttare le potenzialità di Hibernate in
parallelo con il DBMS MySQL, utilizzando una libreria apposita, MySQL
J/Connector, reperibile direttamente sul sito ufficiale.
2.1.3 JSP, XHTML e CSS
I due grandi framework appena illustrati, hanno permesso di realizzare a grandi linee
la parte di Model e Controller dell'applicazione, ma ovviamente, per ottenere un
pacchetto completo è necessario implementare anche ciò che riguarda la sezione di
View, l'unica 'parte' visibile agli utenti finali. Questo livello è composto da due
componenti fondamentali, che svolgono
operazioni distinte in ambienti diversi
JSP che opera in ambito server
XHTML gestito direttamente dal browser dell'utente
La separazione dei due compiti è naturale, dato che in un'applicazione web parte del
lavoro di presentazione dei dati è eseguito sul server e parte sul client. Proprio per
questo motivo si è deciso di sfruttare entrambe le tecnologie, assegnando ad ognuna
di esse un compito ben preciso.
La “sezione” di XHTML è quella che genera la struttura base della pagina, ovvero
quella mediante la quale si gestiscono le tabelle, i contenuti e le immagini, cioè la
parte di codice che l'utente finale può visualizzare. La seconda sezione viene gestita
17
Introduzione alle Web Applications
dal server e si avvale di una tecnica molto potente, JSP, basata sempre su Java.
Mediante questi due linguaggi, uno di formattazione e uno di scripting, è possibile
sfruttare dei costrutti compilati dal server che generano in modo automatico pezzi di
codice HTML. Per esempio, mediante JSP è possibile controllare la sessione di
lavoro dell'utente e di conseguenza gestirne il profilo, oppure utilizzare alcune
librerie di
“tag” specifici, per gestire altre risorse. Come detto in precedenza il livello di View è
stato pensato indipendentemente dagli altri livelli dell'applicazione, questo perché la
presentazione di contenuto statico avviene direttamente con le tecnologie JSP e
XHTML, mentre per quanto riguarda il contenuto dinamico ci si appoggia al
framework Struts che interagisce con il livello sottostante. Per gestire tutta la grafica
e l'intera veste del sito ci si è avvalsi invece di due fogli di stile CSS.
2.2 La scelta del DBMS
MySQL 5 è stato scelto considerando che è un prodotto open source, utilizzabile
liberamente per applicazioni non commerciali, e perché non richiede molte risorse
per l'esecuzione ed è pienamente supportato tramite framework (vedi Hibernate).
MySQL rappresenta un prodotto molto semplice da installare e da utilizzare, tanto
che è bastato installarne la versione base e utilizzare uno strumento d’interfaccia, nel
nostro caso MySQL Query Browser ( disponibile gratuitamente ) per caricarne gli
script di generazione del database.
MySQL Query Browser è risultato estremamente comodo, in quanto grazie alla sua
interfaccia grafica, alcuni inserimenti nel database, durante la fase di test, sonostati
estremamente semplici e veloci.
La realizzazione del database fornisce l'infrastruttura dove poggeranno tutti i livelli
successivi, quindi è necessario che questa base sia solida e ben costituita; con questo
non si vogliono escludere modifiche a posteriori o sviluppi futuri, ma almeno che le
informazioni base su cui è strutturata l'applicazione siano chiare e ben funzionanti.
18
Introduzione alle Web Applications
2.3 Il server web Tomcat
Terminata la progettazione, prima di iniziare lo sviluppo vero e proprio, è necessario
scegliere un Server Web su cui sviluppare ed eseguire l'intera applicazione. Dato che
la filosofia di base per lo sviluppo è Java, la scelta del server web è ricaduta su
Apache Tomcat 5, il quale fungerà sia da contenitore di pagine che da gestore delle
servlet, mediante le quali si realizzeranno le funzioni dinamiche del sito.
In ultimo Tomcat garantisce il funzionamento multi-piattaforma del nostro
applicativo, indipendentemente dal server Windows o O/S Linux. Altre alternative,
come Caucho Resin, sono state scartate, alla luce di alcune carenze dal punto di vista
della stabilità e supporto da parte di comunità Open Source.
2.4 L'ambiente di programmazione
Una volta selezionate tutte le tecnologie da utilizzare, è necessario anche decidere un
ambiente programmativo sul quale realizzare l'applicazione vera e propria. Eclipse è
stato scelto in quanto fornisce un ottimo IDE Java, è multi-piattaforma, cosa che ci
permette di programmare su diverse macchine con diversi sistemi operativi senza
alcun tipo di problema, ma soprattutto per l'ampia scelta di plugin disponibili sulla
rete.
Grazie a quest'unico Tool è di fatto possibile scrivere codice Java, gestire file XML e
progettare graficamente GUI per pagine Web. La scelta d’Eclipse è risultata quasi
ovvia, in quanto, grazie sempre ad alcuni plugin pensati per applicazioni J2EE, si è
semplificato l'utilizzo del framework Struts.
Dunque, una volta installato eclipse sulla nostra macchina, dovremo ancora andare a
scegliere i plug-in più adatti per poter implementare una web-application Struts. Data
la fama di questo Framework, si capisce subito, che la scelta non è per nulla limitata,
anzi negli ultimi tempi sono stati prodotti tantissimi plug-in, da aziende diverse, open
source o commerciali e più o meno validi. Prima di effettuare una scelta, ho fatto
varie prove, partendo da plug-in “minimalisti”, ovvero che svolgono una sola
funzione come: Struts-Console per la scrittura del struts-config.xml, oppure il plug-in
prodotto da Sysdeo per interfacciarsi con Tomcat dall’interno di Eclipse. Infine sono
19
Introduzione alle Web Applications
approdato a plug-in molto più complessi e completi, realizzati perassistere lo
sviluppatore di web application in quasi tutte le fasi della realizzazioni e che si
interfacciano perfettamente con Struts. Tra questi, il più performanti è stato
sicuramente Exadel Studio scaricabile dall’indirizzo http://www.exadel.com e di cui
la versione 3.6 è freeware;
2.4.1 Il plug-in Exadel Studio 3.6
Exdal Studio è un potente tool free per sviluppo di web-application che estende le
funzionalità di Eclipse, permettendo agli sviluppatori di utilizzare a pieno le tecniche
RAD (Rapid Application Development ).
Questa soluzione redditizia e semplificata include tra le caratteristiche fondamentali
importanti:
supporto per lo sviluppo di progetti con tecnologia JSF, Struts, Spring e
Hibernate
scrittura del codice assistita per pagine XML e JSP
supporto per il design e l’anteprima di pagine JSP
flessibilità e personalizzabilità dei progetti.
2.4.2 Il plug-in Omondo
L’ambiente è 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 ei Class Diagrams a
livello di implementazione.
20
Introduzione alle Web Applications
Capitolo III – Analisi e Progettazione
3.0 Introduzione
In questa sede, è stata realizzata un’applicazione Web che permette agli utilizzatori
di gestire l’accesso tramite autenticazione ad un web site interattivo. Questa web
application mette a disposizione degli utenti e dell’amministratore del sistema una
serie di funzionalità definite dalle specifiche di progetto.
La web application progettata in questo capitolo è stata realizzata con l’utilizzo dei
due principali framework visti in precedenza, usufruendo, li 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:
1. Studio di fattibilità
2. Analisi e specifica dei requisiti
3. Progettazione
4. Codifica e implementazione
5. Testing
6. Messa in esercizio
7. Manutenzione
Lo studio di fattibilità, in questo caso, è stato immediatamente superato, in quanto
non c’erano da fare considerazioni riguardo le possibili soluzioni da adottare, le
risorse finanziarie ed umane a disposizione, tenendo conto che sono stati fissati a
priori gli strumenti da utilizzare.
L’analisi 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 all’utente che
all’amministratore e considerando per ciascuna di esse, una breve descrizione, gli
input previsti, le elaborazioni eseguite ed i possibili output prodotti.
21
Introduzione alle Web Applications
Nella fase di progettazione, sono stati realizzati i principali diagrammi UML previsti
per lo sviluppo, quali:
Class Diagram ?
Use Case Diagram
Sequence Diagram ? No
Activity Diagram
Statechart Diagram ? No
Ad essi poi vanno aggiunti la progettazione del database.
La fase di testing ha permesso poi la correzione di errori e problemi rilevati durante
il funzionamento del software.
3.1 Requisiti
Il caso di studio preso in esame, prevede lo sviluppo di una Web application che
permetta all’utenza in generale l’autenticazione, la visione dei propri dati di
registrazione e il controllo dei servizi di abbonamento che il web site propone.
Gli utilizzatori possono avere permessi di accesso diversi e quindi funzionalità
diverse, sulla base della distinzione dei seguenti ruoli:
Utente
Amministratore
Per ciascuno di essi, le funzionalità accessibili nell’applicazione sono descritte di
seguito.
Utente:
Registrazione della sua utenza
Gestione dei propri dati personali per un eventuale aggiornamento
Modifica dati registrazione
Visualizzazione della lista dei propri abbonamenti
Disdetta di un particolare abbonamento
Operazioni di Login e Logout
22
Introduzione alle Web Applications
Amministratore:
Visualizzazione della lista degli utenti registrati
Gestione dei propri dati personali per un eventuale aggiornamento
Gestione dei dati degli utenti registrati per un eventuale
aggiornamento
Concessione e revoca del permesso di amministrazione ad un utente
generico
Cancellazione permanente di un utente
Registrazione di un nuovo utente
Visualizzazione dello stato della lista dei servizi di un particolare
utente
Abbonamento e disdetta di un particolare abbonamento per uno
specifico utente
Visualizzazione della lista degli abbonamenti possibili
Registrazione e cancellazione di un particolare servizio
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.2 Progettazione
La fase di progettazione ha previsto la realizzazione dei principali diagrammi UML, i
quali costituiscono un’astrazione di alto livello del sistema e sono completamente
indipendenti da quelli che possono essere gli strumenti utilizzati nella codifica.
3.3 Use Case Diagrams
I diagrammi dei casi d’uso ( Use case Diagrams ) costituiscono uno strumento utile
per catturare il comportamento esterno del sistema da sviluppare, senza dover
specificare come tale compartamento debba essere realizzato; il sistema è visto come
una scatola nera ( black-box). Essi forniscono una descrizione dei “modi” in cui il
sistema potrà essere utilizzato, ossia ciò che l’utente può fare su di esso e come
23
Introduzione alle Web Applications
quest’ultimo risponde alle sollecitazioni. La realizzazione dei diagrammi ha previsto
un approccio top-down, partendo dallo scenario di carattere generale, in cui le
modalità d’uso sono logicamente correlate sono accorpate, fino ad una
decomposizione in cui sono descritti i casi di utilizzo non ulteriormente
scomponibili.
3.3.1 Use Case “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 dell’utente
e dell’amministratore. 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.
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, la modalità accessibile
esclusivamente dall’utente è la gestione dei suoi abbonamenti ai servizi e la gestione
dei suoi dati personali.
24
Introduzione alle Web Applications
3.3.2 Use Case “Gestione Abbonamenti Utente”
In questa modalità le azioni che l’utente può eseguire in relazione ai suoi
abbonamenti sono, la richiesta di abbonamento ad un nuovo servizio, la disdetta di
un abbonamento, la visualizzazione della lista degli abbonamenti disponibili a cui
abbonarsi e la visualizzazione della lista degli abbonamenti effettuati.
Nello specifico l’abbonamento ad un nuovo servizio da parte di un utente avviene
tramite la richiesta di quest’ultimo. Una volta effettuata la richiesta di un servizio
questa viene visualizzata nella tabella delle richieste dell’utente con lo stato di
richiesta “In corso”, questo significa che l’amministratore dovrà poi in un secondo
momento confermarla per poter abbonare effettivamente il servizio all’utente.
25
Introduzione alle Web Applications
3.3.3 Use Case “Gestione dati personali”
Questo diagramma risalta la sola azione di modifica che un utente può effettuare
visualizzando i propri dati.
L’utente una volta visualizzati la propria scheda di registrazione può decidere in
qualsiasi momento di aggiornare le proprie informazioni cliccando sul bottone ”Edit”
presente nella pagina di riepilogo dell’utente. Questa azione lo dirigerà verso una
form che una volta compilata e salvata cambierà i dati dell’utenza corrente.
26
Introduzione alle Web Applications
3.3.4 Use Case “Gestione Utenti”
Considerando nuovamente il diagramma dei casi d’uso Generale, si evince che ci
sono le modalità “Gestione Utenti” e “Gestioni Servizi” che sono accessibili solo ed
esclusivamente dall’amministratore.
In particolare, “Gestioni 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 modifica dei dati di un particolare utente e la vista
dell’elenco degli abbonamenti per ciascun utente.
27
Introduzione alle Web Applications
3.3.5 Use Case “Gestioni Servizi”
Questo caso d’uso evidenzia come l’amministratore può gestire gli abbonamenti ai
servizi cui l’utente può fare richiesta per abbonarsi. L’amministratore quindi può
registrare un nuovo servizio o eventualmente rimuoverlo.
E’ da notare che la rimozione di un servizio dalla lista dei servizi disponibili
comporta la conseguente rimozione dell’abbonamento da parte di tutti gli utenti che
sono relazionati con esso.
28
Introduzione alle Web Applications
3.3.6 Use Case “Registrazione nuova Utenza”
Qui il seguente Use Case mostra come l’utente visitatore chiamato “Guest” può
registrarsi presso il sistema. La registrazione può avvenire anche da parte
dell’amministratore che ha il permesso di registrare nuove utenze sul DB del sistema.
Una volta che viene registrata la nuova utenza sul database la web application
visualizza una pagina riepilogativa con i dati per accedere all’utenza appena salvata.
29
Introduzione alle Web Applications
3.3.7 Casi d’uso comuni: Login, Logout
Infine, le modalità di utilizzo del sistema che sono comuni all’utente e
all’amministratore, riguardano il “Login Sistema” ed il “Logout Sistema”, dove
quest’ultima può essere considerata atomica.
Per quanto riguarda il login al sistema l’applicazione web è in grado di verificare i
dati inseriti e nel caso in cui lo username è corretto ma la password sbagliata è
possibile ricorrere al recupero della password digitando nella form specifica lo
username e l’email di registrazione dell’utente.
30
Introduzione alle Web Applications
3.4 Activity Diagrams
Facendo riferimento a quelle che sono le funzionalità offerte dal sistema e le
modalità di utilizzo di quest’ultimo, attraverso gli Activity Diagrams è possibile
modellare le azioni necessarie per compiere un attività ed il flusso di controllo tra di
esse. Ciascuna “activity” rappresenta un azione che viene eseguita dal sistema
oppure dall’utilizzatore e può essere atomica oppure scomposta in più action
elementari.
31
Introduzione alle Web Applications
3.4.1 Activity Diagram “Generale”
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
ovviamentre dall’amministratore.
32
Introduzione alle Web Applications
3.4.2 Activity Diagram “Login”
Per quanto riguarda il Login dell’utente e dell’amministratore, le azioni da eseguire
sono praticamente le stesse. 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. Nel caso in cui la password
sia errata ma l’utente è registrato si provvede al recupero di quest’ultima.
33
Introduzione alle Web Applications
3.4.3 Activity Diagram “Recupero Psw”
Un altro piccolo scenario della web application prevede il recupero della password di
registrazione. Un utente registrato dimenticando la sua password d’ accesso al
sistema può comunque recuperarla tramite la username e l’email di registrazione. In
questo caso il sistema verifica i dati immessi e in caso positivo provvede al recupero
del dato richiesto.
34
Introduzione alle Web Applications
3.4.4 Activity Diagram “Registrazione nuova utenza”
La registrazione di una nuova utenza come si può evincere dal diagramma può
essere svolta sia dall’utente visitatore che dall’amministratore. L’amministratore può
registrare più utenze e vedere in tempo reale la lista degli utenti aggiornarsi.
35
Introduzione alle Web Applications
3.4.5 Activity Diagram “Gestione dati personali”
L’utente può visualizzare ed eventualmente modificare i propri dati in qualsiasi
momento. La modifica dei dati personali dell’utente porta a un form con i campi
username, password ed email precompilati con le ultime informazioni registrate
presenti nel sistema.
36
Introduzione alle Web Applications
3.4.6 Activity Diagram “Gestione Abbonamenti Utente”
L’utente ha la possibilità una volta visualizzate la lista dei propri abbonamenti, di
disdire un abbonamento ad un servizio o di fare richiesta per l’abbonamento ad un
nuovo servizio non ancora incluso nella propria lista. In caso di richiesta di un nuovo
servizio la lista attinente alle richieste viene aggiornata immediatamente.
37
Introduzione alle Web Applications
3.4.7 Activity Diagram “Gestione Servizi”
L’amministratore ha la gestione dei servizi a cui gli utenti possono abbonarsi. Questo
gli permette di eliminare o di aggiungere in modo definitivo i servizi dal database del
sistema. In particolare la rimozione di un servizio dal db comporta la cancellazione
di quel servizio dalla lista degli abbonamenti di tutti gli utenti.
38
Introduzione alle Web Applications
3.4.8 Activity Diagram “Gestione Utenti”
L’amministrazione permette il controllo degli utenti e di tutti i loro servizi attinenti.
Nello specifico è possibile la cancellazione di un utente, la modifica dei dati di un
utente e la visualizzazione degli abbonamenti / richieste ai servizi per ogni utente.
39
Introduzione alle Web Applications
3.5 Class Diagram
Mediante il Class Diagram è possibile definire tutte quelle che sono le entità e le
relazioni che intercorrono tra esse, che nell’insieme rappresenta il model del sistema
in un approccio MVC.
Il model è un insieme di data business e di metodi a loro collegati, che effettuano le
elaborazioni e possono essere invocati da altri livelli come il controller o anche il
view. Dunque il primo scopo è quello di progettare questo model indipendentemente
dagli altri livelli, in teoria dovrebbe essere un progetto a se, magari realizzato da
qualcun altro e di cui il controller e il view conoscono solo le firme dei metodi senza
sapere ovviamente come sono implementati. Inoltre come abbiamo detto, Struts è un
framework che implementa essenzialmente il controller del pattern MVC lasciando
molta libertà nell’implementazione del model dove si può far uso di varie tecnologie
Java.
Un Business Object è semplicemente un’astrazione software di entità appartenente
alla realtà. Essi vengono implementati attraverso classi, ma una classe per essere un
business object, deve sottostare a diversi condizioni:
a. Possedere uno stato e comportamento
b. Rappresentare un oggetto o un concetto appartenente all’applicazione
c. Essere riutilizzabile
Ciascuna entità è ovviamente modellabile attraverso il concetto di classe, che ne
definisce le caratteristiche ( i dati ) e il comportamento ( le operazioni ). Ovviamente
anche il Class Diagram può essere realizzato a diversi livelli di astrazione, passando
da un livello elevato ad un livello più basso, definito di seguito, strettamente legato
alla fase d’implementazione e quindi relazionato al framework ed al linguaggio
utilizzato. Sulla base delle specifiche definite per l’applicazione, il sistema prevede le
seguenti classi
40
Introduzione alle Web Applications
41
Introduzione alle Web Applications
42
Introduzione alle Web Applications
La classe Utente e quella Servizi possono essere implementate attraverso un
JavaBeans ma questo potrebbe risultare in alcuni casi macchinoso e rallentare la
comunicazione perciò la proposta della SUN fu quella di unificare le due possibili
persistenze in Java, ovvero Enterprise Java Bean 3.0 e Java Data Object
introducendo i cosiddetti POJO (Plain old Java object).
In realtà se utilizziamo EclipseUML di Omondo per realizzare il diagramma delle
classi dei business object, questi verranno implementati automaticamente dal plugin,
attraverso dei POJO, conservando se esistono le associazioni con altri oggetti in
modo da ridurre il compito del programmatore.
Questi BO creati possono essere visti come dei semplici contenitori di dati, detti a
volte DTO ( Data Transfer Object ) perché hanno il compito di trasferire dati tra uno
strato e l’altro della nostra applicazione. Quindi verso l’alto, cioè verso il controller o
il view, oppure verso il basso, ovvero verso il DB.
Action
BO
DB
Creato il business object per l’applicazione bisogna creare un modello di database.
Infatti quando un’applicazione è in esecuzione, ogni istanza dei BO, possono
contenere dati che in quel momento risiedono in memoria, ma non possono restare li
per sempre e a seconda dei casi, devono essere cancellati o conservati per mezzo di
un processo di persistenza in una base di dati.
Inoltre in applicazioni complesse, potrebbe non esserci una corrispondenza netta tra
la struttura dei business object e lo schema DB e dunque il passaggio diviene più
delicato.
43
Introduzione alle Web Applications
3.5.1 Progettazione del DBMS
Realizzare un'applicazione scalabile e allo stesso indipendente dal livello
fisicosottostante non é sempre possibile. In questo caso lo scopo finale era quello di
riuscire a far funzionare un'applicazione Web svincolata non solo dalla macchina
server ma anche dal tipo del database su cui essa poggia.In seguito a questa
valutazione, il framework Hibernate risulta possedere alcune caratteristiche in
comune con lo scopo del progetto. L'obiettivo di Hibernate (spesso denominato H8)
é di esonerare lo sviluppatore dall'intero lavoro relativo alla persistenza dei dati. H8
genera le chiamate SQL ed evita il lavoro di recupero manuale dei dati e la relativa
conversione, mantenendo l'applicazione portabile in tutti i database SQL.
Immaginando l'applicazione come una pila di livelli, ad ognuno dei quali è assegnato
uno specifico compito, é possibile pensare Hibernate posto appena sopra il livello
fisico del Database e collegato direttamente agli oggetti persistenti Java.
Piattaforma
Oggetti Persistenti
Xml Mapping
DataBase
SQL
44
Introduzione alle Web Applications
In pratica ogni tabella presente nel database, qualunque esso sia, viene tradotta in un
oggetto Java serializzabile, contenente tanti attributi quanti campi (colonne)
compongono la tabella stessa. Ad ognuna di queste variabili vengono assegnati due
metodi, getters e setters, facilmente utilizzabili in qualsiasi momento, rispettivamente
per leggerne il valore e impostarne uno nuovo.
3.5.2 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 relazioni che sia, è possibile definire degli 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 praticamente
le stesse a meno di un formalismo differente. Facendo riferimento alla Web
Application in esame. Le entità del modello sono le seguenti:
Utente e Amministratore : rappresentano le informazioni di accesso
dell’utente e dell’amministratore. Esse rappresentano una specializzazione
dell’entità Guest, alla quale sono legate con una relazione del tipo
Generalizzazione/Specializzazione.
Servizi contiene l’informazione sul nome del servizio a cui è possibile
effettuare l’abbonamento.
Richiesta Servizio rappresenta l’entità di una richiesta di abbonamento ad un
servizio da parte di un utente registrato.
45
Introduzione alle Web Applications
3.5.3 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. Quest’ultimo è 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, all’implementazione fisica che verrà successivamente adottata per uno
specifico DBMS.
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 l’introduzione di
un attributo che le possa distinguere.
2. Accorpamento del padre nelle entità figlie.
3. Sostituzione delle generalizzazioni con semplici associazioni.
46
Introduzione alle Web Applications
Scegliere uno o più attributi di ciascuna entità che possono costituirne una
chiave primaria, ossia tale da individuare ogni istanza dell’entità stessa in
maniera univoca. Nel caso in cui l’entità non sia caratterizzata da attributi con
questo tipo di funzionalità, è possibile introdurre un nuovo attributo che abbia
il suo ruolo di chiave primaria.
Ogni entità va rappresentata con una tabella, le cui colonne sono esattamente
gli attributi dell’entità stessa.
Una relazione uno a molti tra due entità non viene rappresentata con una
tabella ma viene assorbita dall’entità 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.
47
Introduzione alle Web Applications
Capitolo IV – Implementazione
4.0 Considerazioni iniziali
Il progetto non vuole rappresentare la migliore soluzione possibile in termini di
completezza delle funzioni, robustezza e scalabilità. Sebbene tali requisiti siano stati
in una certa misura considerati, lo scopo principale di questo progetto è quello di
presentare un utilizzo concreto degli strumenti open source descritti per fornire una
sorta di guida applicativa alla realizzazione di web application che possa
rappresentare un punto di partenza per futuri lavori. Prima di addentrarci
nell’implementazione della nostra applicazione ci sono ancora due punti da trattare,
ovvero la struttura che deve avere una generica web-application e la preparazione
dell’ambiente di sviluppo.
4.1 Struttura dell’Applicazione
Dal punto di vista dello sviluppatore di applicazioni web basate su Java risulta
particolarmente importante la standardizzazione della struttura di tali applicazioni e
l'introduzione degli archivi WAR come strumento per il deployment delle
applicazioni web. Una applicazione web è vista come una gerarchia di file e
directory disposti secondo uno schema particolare.
Una applicazione web ha una propria directory radice (root) la /webapp. Il nome
della cartella corrisponde a ciò che nella terminologia delle servlet viene chiamato.
La directory radice contiene tutti gli altri elementi che compongono l'applicazione
web. Quindi la directory /webapp contiene i documenti HTML, le pagine JSP, le
immagini e le altre risorse che compongono l'applicazione web. Tali file possono
essere strutturati in directory esattamente come si farebbe per un sito web statico.
48
Introduzione alle Web Applications
4.1.1 Directory dell’applicazione web
/webapp/WEB-INF
All'interno della cartella root si trova una directory speciale, denominata WEB-INF.
La funzione di questa cartella è quella di contenere file riservati, come ad esempio il
file di configurazione dell'applicazione, web.xml. sempre in WEB-INF sono presenti
i files struts-config.xml, tiles-defs.xml, validation.xml e validator-rules.xml; Per
questo motivo le specifiche impongono che la cartella ed il suo contenuto debbano
risultare inaccessibili per gli utenti dell'applicazione.
/webapp/WEB-INF/web.xml
Il file web.xml comunemente denominato deployment descriptor. Si tratta del file di
configurazione dell'applicazione web; in esso, ad esempio, si definiscono gli alias
delle servlet, i parametri di inizializzazione, le mappature dei percorsi e così via
come visto nel secondo capitolo.
/webapp/WEB-INF/classes e /webapp/WEB-INF/lib
49
Introduzione alle Web Applications
Queste due directory sono destinate a contenere le classi e gli archivi Jar di cui la
nostra applicazione web necessita. Se dobbiamo utilizzare delle classi Java compilate
(file con estensione .class andremo a copiarle all'interno di /webapp/WEBINF/classes,
secondo l'usuale struttura di directory Java (così se abbiamo una
classe UserManager.class contenuta nel package demo.util il percorso del file
compilato sarà/webapp/WEBINF/classes/sito/servlet/MiaServlet.class).
Se dobbiamo utilizzare classi contenute in archivi Jar, sarà sufficiente copiarli in
/webapp/WEB-INF/lib.
50
Introduzione alle Web Applications
/webapp/WEB-INF/src
Questa cartella contiene i file sorgenti Java o più in generale interi package non
compilati.
51
Introduzione alle Web Applications
4.2 Uso del plug-in Exadel
Il plug-in di exadel permette come detto in precedenza lo sviluppo di web application
usando il framework Struts descritto. Per iniziare a lavorare lanciamo Eclipse con la
vista fornita da Exadel Studio e creiamo un nuovo progetto Struts. Dal menu:
File New Project scegliamo Struts Project.
Nelle finestre successive, assegniamo un nome al progetto, scegliamo la versione di
Struts con cui lavorare ( possiamo scegliere tra 1.1 e 1.2 ), la versione per le servlet
ed infine le librerie di custom
tag da importare nel nostro progetto. Ovviamente sono tutte scelte che possono
essere modificate nel corso dello sviluppo dell’applicazione.
52
Introduzione alle Web Applications
Nella struttura ci vengono caricate tutte le librerie relative a Struts nella directory
“Web App Library” ed inoltre, come si vede, già vengono generati i file xml come ad
esempio strutsconfig.xml che dovremo solo modificare. Nella cartella JavaSource
andremo invece a salvare i file sorgenti che scriveremo creando dei package.
4.3 Sviluppo della persistenza
Concettualmente sono tre i passi più importanti da compiere per lo sviluppo di questo
livello:
1. Disegnare e scrivere le classi del nostro dominio applicativo avendo
l’accortezza di rispettare le direttive Pojo e cioè implementare i metodi
pubblici getXXX e setXXX per le proprietà persistenti.
2. Disegnare lo schema relazionale su cui poggerà la nostra applicazione.
3. Preparare i file di configurazione e mapping necessari ad Hibernate.
Per Hibernate esistono ( sia all’interno del pacchetto di distribuzione originale, sia
come tool aggiuntivi sviluppati da terzi ) diversi strumenti per rendere più o meno
automatici i passi appena elencati. Partendo dalle classi Java è possibile, ad esempio,
generare automaticamente i file di configurazione e poi da questi, ancora
automaticamente, tirar fuori le istruzioni SQL per generare lo
schema relazionale. Oppure è possibile procedere all’inverso: creare i file di
configurazione Hibernate partendo dalle tabelle sul db server e da questi lasciarsi
abbozzare i sorgenti delle classi del nostro dominio applicativo.
53
Introduzione alle Web Applications
4.3.1 Implementazione per la didattica
Questa metodologia consiste nell’ affrontare passo passo le procedure di creazione
della persistenza per capire meglio come lavora hibernate in un approccio da un
punto di vista didattico. Come abbiamo visto precedentemente i passi da realizzare
sono tre.
Il primo consiste nello scrivere ogni singola classe che rappresenti un entità del
sistema. Qui allora potremmo iniziare a scrivere subito del codice cercando di
iniziare a fare un piccolo sforzo di astrazione o visto che usiamo EclipseUML
possiamo premere la combinazione di tasti “Ctrl+N” e creare un Uml Class Diagram
all’interno del nostro progetto.
In questo diagramma andremo a creare una nuova classe con nome Utenti, dopodichè
basterà solo definire le proprietà che l’oggetto dovrà avere. Infatti poi potremmo
generare i metodi getXXX and setXXX per ogni proprietà del nostro pojo in modo
automatico dal menu “Source” di Eclipse selezionando “Generate Getters and
Setters..”
54
Introduzione alle Web Applications
Avremo a procedura finita il nostro pojo completo. Ripetiamo quindi questo passo
anche per l’entità Servizi e per l’entità ServiziHasUtenti che rappresentano
rispettivamente i servizi a cui l’utente può abbonarsi e la classe java che permette la
dipendenza molti a molti tra i servizi e gli utenti. Il passo successivo sarà quello di
progettare il DB dove creare la tabella Utente, Servizi e Servizi_Has_Utenti.
Invece di creare il database e la tabella tramite linea di comando MySQL possiamo
utilizzare lo strumento “MySQL Administrator” che risulta essere molto semplice ed
intuitivo. Infatti una volta dichiarati i campi e le loro proprietà il tool stesso ci fornirà
un messaggio di conferma per l’ avvenuta creazione della tabella. Di seguito
riportiamo per ogni tabella la vista tramite il tool Administrator e le loro linee di
codice SQL.
55
Introduzione alle Web Applications
La precedente schermata corrisponde a digitare su linea di comando SQL il codice
qui riportato:
56
Introduzione alle Web Applications
Per la tabella servizi abbiamo la seguente vista su Administrator:
Alla quale corrisponderà a digitare su linea di comando il codice SQL qui riportato:
57
Introduzione alle Web Applications
Per la tabella servizi_has_utenti abbiamo la seguente vista su Administrator:
Alla quale corrisponderà a digitare su linea di comando il codice SQL qui riportato:
Fatto ciò non ci resta che creare i file di mappaggio relativi alle tabelle
precedentemente create insieme al file di configurazione Hibernate.cfg.xml. Iniziamo
quindi a configurare prima Hibernate. In questo caso come spiegato in precedenza
58
Introduzione alle Web Applications
potremmo procedere in diversi modi, ma per poter capire in fondo le peculiarità di
questo file procederemo creandolo e configurandolo manualmente tramite un editor
xml. Prepariamo un file xml denominato hibernate.cfg.xml tenendo cura di salvarlo
sempre all’interno del nostro progetto sotto WEB-INF/classes. Ecco di seguito il
contenuto del nodo principale:
Come potete vedere settiamo le informazioni relative al DB usato, host, username e
password e ci assicuriamo che la sessione hibernate sia un thread tramite la proprietà
current_session_context_class. Si potrebbe poi modificare il logging dei comandi
59
Introduzione alle Web Applications
SQL generati impostando a true la proprietà show_sql in modo da vedere i comandi
SQL generati a console ma naturalmente in un ambiente di produzione tale
funzionalità andrebbe disabilitata. Si noti inoltre che la proprietà dialect, utilizzata
per indicare ad Hibernate quale sia il db relazionale utilizzato. Già versione 2.1 di
Hibernate supporta ben 21 “dialetti” SQL, corrispondenti ad altrettanti noti server
relazionali, da Oracle a MySQL, da Microsoft SQL Server a PostgreSQL, da Sybase
a HyperSQL.
L’indicazione del dialetto permette ad Hibernate di migliorare le performance
sfruttando le specifiche caratteristiche di ogni database server. Infine, nel file di
configurazione generale è possibile specificare tutti gli ulteriori file da includere,
quelli cioè specifici per la descrizione del mapping di ciascuna delle classi coinvolte.
I mapping oggetto / relazione vengono definiti in un documento XML. Il documento
è progettato per essere leggibile e modificabile a mano. Il suo linguaggio di
definizione è java-centrico, nel senso che i mapping sono costruiti intorno alle
dichiarazioni delle classi persistenti, non sulle dichiarazioni delle tabelle. Andiamo
quindi a definire il mapping per le classi definite al primo passo.
La classe Utenti mappata nel file Utenti.hbm.xml sarà:
60
Introduzione alle Web Applications
La classe Servizi mappata nel file Servizi.hbm.xml sarà:
Infine la classe ServiziHasUtenti mappata nel file ServiziHasUtenti.hbm.xml sarà:
Analizzando questi file xml notiamo che nel tag radice <hibernate-mapping> vi
troviamo il package di default da utilizzare, se non diversamente specificato per i
singoli tag <class>. In quest’ultimo troviamo invece tutti i dettagli per il mapping
della classe: il nome della tabella che ne conterrà i dati e, di seguito elencate, tutte le
proprietà che corrispondono ai vari campi di ciascun record. Tralasciando la
descrizione delle proprietà più ovvie soffermiamoci sul tag <id> che permette di
specificare la configurazione della proprietà che farà da chiave primaria per le
istanze della classe e, rispettivamente, per le righe della tabella utilizzata.
61
Introduzione alle Web Applications
Con Hibernate le chiavi primarie delle tabelle assumono un’importanza
fondamentale, per esempio per poter capire se una istanza è già presente nel database
o se l’oggetto in questione non è mai stato salvato prima.
4.3.2 Realizzazione della Web-Application Struts: La sezione
View e Controller
Implementata la struttura di supporto della nostra applicazione web, ovvero il model
con tutta la logica di business, il passo successivo consiste nella progettazione e
realizzazione del view e del controller, dunque la vera e propria programmazione di
Struts. In un progetto di grosse dimensioni e professionale, il procedimento dovrebbe
essere quello di realizzare il controller, ovvero implementare tutte le action, dunque i
servizi offerti agli utenti del sito e successivamente realizzare il view (al solito
potrebbe essere un altro team a farlo) e configurare l’applicazione attraverso lo
struts-config.xml. Poiché questa applicazione non rappresenta un progetto di grosse
dimensioni, risulta più semplice progettare il sito web, definendo una sorta di
diagramma di sequenza tra le pagine JSP ed in parallelo programmare le action.
Dalla lettura delle specifiche e dall’analisi dei casi d’uso dalla homepage, viene data
la possibilità di effettuare il login e di registrare nuove utenze. In caso di insuccesso
nella operazione di login verrà segnalato un errore all’utente, in caso di successo
invece l’utente verrà inviato alla sua pagina personale a seconda che abbia diritti o
meno di amministrazione.
62
Introduzione alle Web Applications
Possiamo allora definire una sorta di diagramma di sequenza che descriva
l’applicazione, in modo che possa essere per noi una sorta di guida di sviluppo di
ogni singola pagina Jsp e Action allegata.
63
Introduzione alle Web Applications
4.4 Accesso alla sezione amministrativa
Per accedere ad una qualsiasi pagina protetta é stata implementata una forma di
autenticazione tramite Username e Password. Grazie a questo form ( login.jsp ) è
possibile inserire le credenziali per accedere o meno al menu personale.
Una volta loggati sia come amministratore che come semplice utente del sistema sarà
presente nella parte destra di ogni pagina un diagramma a blocchi dove ogni blocco
si illuminerà indicando la sezione della web-application nella quale l’utente si trova
in quel momento. Ciò è stato implementato per avere un immediata visione delle
possibili azioni che è possibile eseguire in quella precisa pagina.
64
Introduzione alle Web Applications
4.4.1 Funzionalità implementate
Un utente in possesso di username e una password può svolgere, in base ai propri
privilegi determinati dal gruppo di appartenenza, una serie di attività. La funzionalità
implementate nella sezione amministrativa sono:
•
Gestione utenti
•
Gestione servizi
•
Gestione abbonamenti ( admin / user )
•
Registrazione nuove utenze
( Con il termine gestione si intende la possibilità di inserire, modificare, visualizzare
ed eventualmente eliminare quel determinato dato ).
4.4.2 Gestione Utenti
La vista di questa pagina Jsp permette di visualizzare tutte le utenze salvate sul DB
insieme alle loro
proprietà. Dalla tabella presente in questa pagina è possibile
accedere a funzioni come modifica di un utente tramite il bottone “Edit”, a
cancellazione tramite il bottone “Delete” e infine tramite il bottone “View” e
possibile accedere per ogni utente alla scheda dei servizi a cui è abbonato e a cui ha
fatto richiesta per abbonarsi.
65
Introduzione alle Web Applications
Quanto visto precedentemente si traduce dentro il file struts-config.xml in forma di
diagramma:
Volendo prendere in considerazione particolare l’azione che preleva dal DB tutte le
istanze della tabella Utenti si ha in formato xml il codice seguente:
Il metodo che tira su la connessione con il DB ed effettua la query è cosi scritta:
All'avvio di una nuova transazione, l'oggetto HibernateUtil verifica se è già stata
attivata una sessione con il database e in caso affermativo si limiterà ad utilizzarla,
altrimenti verrà creata una nuova istanza. La classe UtenteListAction utilizza il
metodo getAllUtenti dell’istanza UserManager per ottenere una Collection di utenti
presenti nel database e successivamente rimandarla come input della tabella presente
nella pagina Jsp.
66
Introduzione alle Web Applications
67
Introduzione alle Web Applications
4.4.3 Gestione Servizi
Anche qui una tabella aiuta a visualizzare quelli che sono i servizi ai quali un utente
chiede di abbonarsi. Qui l’amministratore ha la possibilità di creare un nuovo
servizio o di eliminarne uno vecchio. Nel caso della cancellazione di un servizio,
questa operazione comporta la disdetta dell’abbonamento da parte di tutti gli utenti a
cui era associato quel servizio.
Vediamo nel dettaglio l’azione relativa all’inserimento di un nuovo servizio nella
web application. Come primo passo andiamo sempre a modificare il file xml strutsconfig aggiungendo la nostra azione che verrà presentata in forma di diagramma nel
seguente modo:
68
Introduzione alle Web Applications
La sezione xml che si occupa dell’inserimento di un nuovo servizio e riportata di
seguito:
Dove l’azione ServiceAddAction contiene un semplice redirect che porta alla pagina
RegisterService.jsp dove è possibile inserire la descrizione del nuovo servizio da
creare.
69
Introduzione alle Web Applications
Ecco quindi riportata di seguito la pagina di registrazione di un nuovo servizio. Una
volta agito sul bottone “Save!” presente nella form della pagina si porta a chiamare
l’azione ServiceRegisterAction che ha il compito di salvare la nuova tupla nella
tabella Servizi del DB.
70
Introduzione alle Web Applications
Si può notare che al termine dell'operazione la transazione può essere chiusa ed
eseguita sulla base di dati vera e propria tramite la riga di codice tx.commit();
4.4.4 Gestione abbonamenti
Gli abbonamenti di un utente vengono visualizzati tramite l’azione sul bottone
“View” dalla pagina dove è presente la tabella degli utenti.
Da qui è possibile vedere quali sono i servizi a cui un utente è abbonato, quali i
servizi disponibili a cui abbonarsi e infine quali sono le richieste d’abbonamento
dell’utente. Quindi ogni qualvolta un amministratore decide di abbonare un servizio
ad un utente che ne ha fatto richiesta la pagina viene aggiornata eliminando dalla
tabella “Richiesta servizi” il servizio appena abbonato all’utente e aggiungendolo
alla tabella “Servizi utente”.
71
Introduzione alle Web Applications
In forma diagrammatica avremo:
Nel caso particolare di abbonamento a un servizio nel file di struts-config.xml
scriveremo:
In questo caso l’attributo path definisce l’url /addSerUser, che corrisponde
all’indirizzo completo http://localhost:8080/Struts_Hibernate_Thesis/addSerUser.do .
Insieme al path viene indicato il type, che identifica la classe che implementa
l’azione eseguita quando l’utente accede all’url in oggetto.
L’azione in questione preleva l’id dell’utente a cui si vuole abbonare il servizio e
crea nel db tramite una sessione di hibernate una nuovo record nella tabella
Servizi_has_Utenti con l’id del servizio e l’id del servizio. Nel caso in cui l’utente
avesse fatto esplicita richiesta d’abbonamento a quel particolare servizio,
quest’ultimo viene eliminato dalla tabella “Richiesta Servizi” una volta che
l’amministratore esegue l’abbonamento verso quell’utente.
72
Introduzione alle Web Applications
4.4.5 Registrazione nuove utenze
La registrazione di una nuova utenza può avvenire in due diversi modalità o
attraverso l’accesso tramite il privilegio di amministratore o attraverso la pagina di
“Login” tramite il link “Registrati!” presente nella form, che porta alla pagina
http://localhost:8080/Struts_Hibernate_Thesis/pages/UtenteRegister.jsp .
Di seguito si riporta il codice xml relativa all’azione di registrazione
e il relativo grafico in forma diagrammatica fornito dal plug-in exadel integrato in
eclipse:
73
Introduzione alle Web Applications
La classe che si occupa dell’azione di registrazione di una nuova utenza e stata
implementata nel seguente modo:
La post-condizione di questa operazione dovrà portare ad avere una nuova tupla nella
tabella del DB implementato
74
Introduzione alle Web Applications
Bibliografia
C. Cavaness – “Programming Jakarta Struts 2nd Edition” – Ed. O’Really
Official Struts Web Site: http://struts.apache.org
First steps using Struts and Hibernate: http://www.laliluna.de
Official Hibernate Web Site: http://www.hibernate.org
Hibernate: Oggetti a lunga conservazione: http://www.javaportal.it
Official Tomcat Web Site: http://tomcat.apache.org
Official MySQL Web Site: http://www.mysql.com
Official Eclipse Web Site: http://www.eclipse.org
MVC Pattern: http://java.sun.com/blueprints/patterns/MVC-detailed.html
Wikipedia, l'enciclopedia libera http://it.wikipedia.org
Official Exadel Web Site: http://www.exadel.com;
75