Prova Tesi ver. 3.7 _ margini _ - Raoul Musci
annuncio pubblicitario
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
