UNIVERSITA DI PISA

Facolt di Ingegneria --------------------------Corso di Laurea Specialistica in INGEGNERIA INFORMATICA PER LA GESTIONE DAZIENDA

Calcetto 3.0
Autori Federico Bianucci, Fabio Aiuto, Irene Bont

Progetto del corso di SERVIZI E APPLICAZIONI DELLE RETI INFORMATICHE

--------------------------------Anno Accademico 2010 2011

Sommario
Capitolo 1 - Specifica dei requisiti ..................................................................................................................... 4 1.1. 1.2. 1.3. Presentazione .................................................................................................................................... 4 Specifiche Informali del Sistema ....................................................................................................... 4 Requisiti Funzionali ............................................................................................................................ 6

Capitolo 2 Caratteristiche tecniche .............................................................................................................. 10 2.1. 2.2. 2.3. Architettura del Sistema .................................................................................................................. 10 Scelte Progettuali ............................................................................................................................ 10 Scelte Implementative ..................................................................................................................... 12 Web Application Framework: Struts ....................................................................................... 12 Gestione dei Dati ..................................................................................................................... 12 Gestione della Presentazione e dellInterfaccia Utente .......................................................... 12 Gestione della Logica di Business ............................................................................................ 12

2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4.

Ulteriori Accorgimenti Tecnici ......................................................................................................... 13 Registrazione e Gestione degli Accessi .................................................................................... 13 Gestione della Concorrenza..................................................................................................... 13

2.4.1. 2.4.2.

Capitolo 3 Descrizione del Sistema............................................................................................................... 14 3.1. 3.2. 3.3 3.4. 3.5. 3.6. 3.7. Pattern Model View Control ............................................................................................................ 14 Model Domain Object (Model)........................................................................................................ 14 Enterprise JavaBeans (Model) ......................................................................................................... 16 Servlet (Control) .............................................................................................................................. 22 Java Server Pages (View) ................................................................................................................. 23 Filter ................................................................................................................................................. 24 Realizzazione di alcuni casi duso .................................................................................................... 25

Capitolo 4 Installazione dellapplicativo ....................................................................................................... 26 4.1. 4.2. 4.3. Predisposizione del Database .......................................................................................................... 26 EJB container Glassfish ................................................................................................................. 28 Servlet Container Tomcat ............................................................................................................. 28

Capitolo 5 Sviluppi futuri .............................................................................................................................. 30

Indice delle figure

Figura 1 - User Case Diagram............................................................................................................................. 9 Figura 2 - Architettura del sistema .................................................................................................................. 11 Figura 3 - Diagramma delle classi del dominio ................................................................................................ 15 Figura 4 - MatchesBean ................................................................................................................................... 16 Figura 5 - PlayersBean ..................................................................................................................................... 17 Figura 6 ReportBean ..................................................................................................................................... 18 Figura 7 TeamsBean...................................................................................................................................... 19 Figura 8 TournamentBean ............................................................................................................................ 20 Figura 9 UsersBean ....................................................................................................................................... 21 Figura 10 - Calcetto database .......................................................................................................................... 22 Figura 11 - Login: Sequence Diagram .............................................................................................................. 25 Figura 12 - Show Players List: Sequence Diagram ........................................................................................... 25

Capitolo 1 - Specifica
1.1. Presentazione

dei requisiti

Il sistema consiste in un'applicazione di supporto alla gestione di un torneo di calcetto. Lo scopo del sistema quello di offrire agli utenti un supporto informatico al fine di poter svolgere pi agevolmente i loro compiti. Il sistema deve essere in grado di ricevere le iscrizioni delle squadre e dei giocatori, comunicare calendario e risultati degli incontri, vedere le varie fase del torneo. Il tutto fruibile via web attraverso un sito che funge da interfaccia col sistema.

1.2.

Specifiche Informali del Sistema

Il SW in questione deve essere in grado di far iscrivere nuove squadre al torneo e aggiungere nuovi giocatori all'interno di squadre gi create. La figura del capitano registra la squadra al torneo e contestualmente, tramite linserimento dei propri dati personali, si registra al sistema anche come primo giocatore della squadra creata. Non possono esistere squadre senza giocatori. Il primo giocatore iscritto il capitano. Solo il capitano, previa autenticazione, pu aggiungere, modificare o cancellare giocatori dalla sua squadra. Il capitano pu decidere a quale torneo iscrivere la propria squadra. Una squadra pu partecipare ad un solo torneo alla volta. Per ogni torneo esiste una data prefissata di fine iscrizione, decisa e pubblicata sul sito dallorganizzatore, oltre la quale non si possono pi iscrivere squadre a quel torneo. La consegna del certificato medico e della quota sono effettuate manualmente dal capitano allorganizzatore del torneo. Solo lorganizzatore ha la possibilit di notificare al sistema l'avvenuto pagamento. Un organizzatore pu organizzare un solo torneo.

Passata la data di fine iscrizione, un organizzatore libero di fare iniziare il torneo quando vuole. In quel momento le squadre che non hanno versato la quota di partecipazione vengono escluse. Vengono escluse anche le squadre con meno di 3 giocatori. Vengono escluse anche le squadre per cui esiste almeno un giocatore che non abbia consegnato il certificato medico. Solo dopo la scadenza dei termini per liscrizione e quando lorganizzatore decide, il sistema fornisce il numero delle squadre partecipanti al torneo. Considerando la natura ad accoppiamenti del torneo, il torneo inizia solo se ci sono un numero di squadre pari a 2, 4, 8, 16 e cos via per potenze del 2. Gli organizzatori (iscritti al sistema immettendo i loro dati personali e dotati di username e password) possono vedere sul sito la lista definitiva delle squadre, i relativi accoppiamenti (scelti casualmente dal sistema), decidere le date delle partite, inserire i report di ogni partita. Un organizzatore non pu modificare date o report di partite di altri tornei. I report delle partite di qualunque torneo in corso sono visibili dallorganizzatore, dallamministratore e da qualunque capitano. Quando un torneo termina, i relativi report non sono pi visibili a nessuno, ma solo i risultati E possibile sempre vedere i giocatori di squadre che sono iscritte al torneo. Ogni visitatore pu visualizzare lelenco delle squadre partecipanti con i relativi giocatori, ma non i report delle partite. Il sistema dovr essere in grado di gestire le squalifiche: se un giocatore viene espulso in una partita non potr disputare la partita successiva. Gli organizzatori tramite il sistema possono emettere multe per singoli giocatori o intere squadre. Un amministratore pu esportare in un file xml tutti i report di tutte le partite. E richiesta anche limplementazione dei seguenti meccanismi di sicurezz a: il personale amministrativo deve autenticarsi (mediante una password, che unica per tutto il personale amministrativo e decisa al momento dellistallazione del sistema) prima di poter effettuare qualsiasi tipo di operazione. Anche le operazioni degli organizzatori e dei capitani sono permesse previa autenticazione, mediante username e password personali.

1.3. Requisiti Funzionali

I requisiti funzionali definiscono i comportamenti attesi del sistema in termini di funzionalit e/o servizi offerti all'utente. Il diagramma dei casi d'uso in Figura 1 illustra come tali requisiti vengono percepiti e utilizzati dagli attori del sistema. CAPITANO Il sistema deve consentire al capitano di autenticarsi Il sistema deve consentire al capitano di registrare una squadra al torneo attraverso la sua registrazione Il sistema deve consentire al capitano di aggiungere nuovi giocatori alla sua squadra Il sistema deve consentire al capitano di cancellare giocatori della sua squadra Il sistema deve consentire al capitano di cambiare i dati dei giocatori Il sistema deve consentire al capitano di una squadra di richiedere il ritiro della sua squadra dal torneo solo prima o dopo il torneo. Non possibile ritirarsi se il torneo al quale si partecipa in corso. Il sistema deve consentire al capitano di conoscere gli accoppiamenti, le date degli incontri, i risultati delle partite Il sistema deve consentire al capitano di vedere i referti di tutte le partite Il sistema deve consentire al capitano di visualizzare lelenco dei giocatori della sua squadra, con relative informazioni sui certificati consegnati Il sistema deve consentire al capitano di richiedere il ritiro della sua squadra dal torneo solo prima o dopo il torneo. Non possibile ritirarsi se il torneo per cui si partecipa in corso. Il sistema deve consentire al capitano di cambiare torneo se quello per cui partecipa non in corso e quello a cui intende iscriversi non abbia una data di scadenza per le iscrizioni gi superata. Il sistema non deve consentire al capitano di modificare o aggiungere giocatori durante un torneo in corso VISITATORE Il sistema deve consentire allutente di visualizzare gli accopp iamenti e i risultati delle partite nonch i giocatori della squadre iscritte. Comparir la lista solo delle squadre che al termine del torneo non abbiano chiesto un ritiro o che non abbiano cambiato torneo.

AMMINISTRATORE Il sistema deve consentire allamministratore di autenticarsi Il sistema deve consentire allamministratore di creare gli account per gli organizzatori Il sistema deve consentire allamministratore di cambiare i dati di un organizzatore Il sistema deve consentire allamministratore di cancellare un organizzatore Il sistema non deve consentire allamministratore di cancellare o modificare un organizzatore per il quale il torneo in corso. Il sistema deve consentire allutente di visualizzare gli accoppiame nti, le date degli incontri, risultati e i report delle partite nonch i giocatori della squadre iscritte. Comparir la lista solo delle squadre che al termine del torneo non abbiano chiesto un ritiro o che non abbiano cambiato torneo

ORGANIZZATORE Il sistema deve consentire allorganizzatore di autenticarsi Il sistema deve consentire all organizzatore di notificare i pagamenti effettuati Il sistema deve consentire all organizzatore di notificare per ogni giocatore la consegna del certificato medico Il sistema deve consentire all organizzatore di cancellare unintera squadra dal sistema solo prima o dopo il torneo ma non durante Il sistema non deve consentire all organizzatore di notificare la consegna del certificato di giocatori di squadre che stanno partecipando al suo torneo in corso Il sistema deve consentire allorganizzatore di conoscere per ogni squadra la situazione del loro pagamento nonch lelenco dei giocatori registrati con linformazione sulla consegna dei loro certificati. Il sistema deve consentire all organizzatore di decidere la data di scadenza delle iscrizioni Passata la data di scadenza delle iscrizioni il sistema deve consentire all organizzatore di decidere lui quando far porre inizio al torneo eliminando dunque le squadre che non rispettano i requisiti Il sistema deve consentire allorganizzatore di avere, dopo la chiusura delle iscrizioni, gli accoppiamenti creati casualmente dal sistema Il sistema deve consentire allorganizzatore di inserire il referto di ogni partita con i relativi risultati Il sistema deve consentire allorganizzatore di cambiare le date degli incontri Il sistema deve consentire allorganizzatore di vedere i report di partite per i tornei in corso
7

Il sistema deve consentire allorganizzatore di predisporre multe a singoli giocatori o ad intere squadre Il sistema non deve consentire ad un organizzatore di modificare date o report di partite di altri tornei o delle fasi precedenti del suo torneo. Il sistema deve consentire allorganizzatore di poter decidere quando passare ad una fase successiva del torneo.

Figura 1 - User Case Diagram

Capitolo 2

Caratteristiche tecniche

2.1. Architettura del Sistema

L'applicazione stata sviluppata utilizzando lo schema Model-View-Controller (MVC)1, in modo da separare la logica di presentazione dalla logica applicativa e favorire la riusabilit del codice. Il sistema sviluppato quindi costituito da alcuni moduli complementari, questi secondo lo schema di progetto MVC sono dedicati rispettivamente alla gestione dei seguenti aspetti: gestione dei dati; gestione della presentazione e dell'interfaccia utente; gestione della logica di business.

2.2. Scelte Progettuali

Il progetto stato sviluppato operando le seguenti scelte progettuali: Web Application Framework: Struts2, web application framework che supporta lo schema di progetto MVC; Servlet Container: Tomcat3, servlet container con il quale si sono gestite le servlet e le JSP; EJB Container: GlassFish4, Application server con cui sono gestiti gli EJB; DBMS: PostgreSQL5 per gestire la persistenza dei dati.

1 2

http://java.sun.com/blueprints/patterns/MVC-detailed.html http://struts.apache.org/ 3 http://tomcat.apache.org/ 4 http://glass_sh.java.net/ 5 http://www.postgresql.org/

10

Figura 2 - Architettura del sistema

In Figura 2 rappresentata l'architettura descritta ed utilizzata da noi nello sviluppo dell'applicazione e nel testing delle funzionalit.

11

2.3. Scelte Implementative 2.3.1.

Web Application Framework: Struts

Per lo sviluppo dell'applicazione si utilizzato il Web Application Framework Struts che implementa il design pattern Model View Control. La scelta effettuata ha consentito di mantenere ben distinta la logica di presentazione sia dal modello dei dati che dalla logica di controllo.

2.3.2. Gestione dei Dati

Per gestire la persistenza dei dati si utilizzato Java Persistence API (JPA), che fa parte della specifica EJB 3.06 e fornisce un modello di persistenza di POJO (Plain Old Java Object) per ORM (Object-relational mapping). In pratica le tuple del database sono istanze di classi POJO a cui sono state aggiunte delle annotazioni.

2.3.3. Gestione della Presentazione e dellInterfaccia Utente

Per la gestione dell'interfaccia con l'utente si scelto di utilizzare pagine JSP che utilizzano JavaServer Pages Standard Tag Library (JSTL): una libreria inclusa come componente della piattaforma di sviluppo per applicazioni Web Java EE. un'estensione di JSP ed incorpora un insieme di tag HTML definiti tramite file XML e programmati in linguaggio Java. Il principale vantaggio dellutilizzo di JSTL consiste nel distinguere il compito dello sviluppatore Java da quello del web designer

2.3.4. Gestione della Logica di Business

Il Controller implementato da Servlet che attraverso RMI interagiscono con Session EJB remoti, questi eseguono le operazioni sui model object. Come noto esistono due tipologie di session EJB (stateless e stateful), nel nostro caso si optato per l'utilizzo di session EJB stateless poich non c'era l'esigenza di mantenere lo stato della comunicazione. L'utilizzo di Session EJB Stateless consente di servire le richieste con un pool di istanze limitato rispetto al caso di EJB Stateful. Ad ogni richiesta da parte del client viene recuperata un'istanza del session bean di tipo stateless dal pool e assegnata al client, quando la richiesta si conclude, l'istanza torna al pool per un successivo riutilizzo. Diversamente nel caso dei Session EJB Stateful si ha un'istanza dedicata per ogni sessione, con un overhead minore legato alla gestione del pool di istanze, ma pagando in termini di utilizzo delle istanze, infatti queste sarebbero inutilizzate nei tempi che trascorrono tra due successive richieste.

http://jcp.org/aboutJava/communityprocess/_nal/jsr220/index.html

12

2.4. Ulteriori Accorgimenti Tecnici

2.4.1.

Registrazione e Gestione degli Accessi

Per la gestione di aspetti legati alla sicurezza dell'applicazione si sono utilizzati alcuni accorgimenti che dovrebbero garantire protezione da attacchi di malintenzionati alle prime armi. Chiaramente laddove l'applicazione dovesse essere resa pubblica si dovrebbero prevedere misure di sicurezza molto pi complesse. Il meccanismo di sicurezza attualmente implementato lutilizzo di filtri per controllo degli accessi. Con i filtri verifichiamo che determinate azioni del sistema vengano esclusivamente effettuate da chi ne ha il privilegio Ad esempio una delle funzionalit accessibile unicamente dall'amministratore l'esportazione dei report in un documento XML. Questo potrebbe risultare utile anche come interfaccia con applicativi che richiedono tali informazioni codificate con un formato standard. Inoltre stato realizzato un semplice meccanismo di criptazione delle password di accesso al sistema, che consente unicamente di salvare le password criptate nel database.

2.4.2. Gestione della Concorrenza

Una caratteristica fondamentale del sistema che ogni partita viene giocata su un unico campo in cui vengono disputate tutte le partite. Rimane dunque necessario mettere in atto un meccanismo di gestione della sincronizzazione che eviti la possibilit che organizzatori di tornei diversi possano contemporaneamente richiedere che una partita venga giocata nello stesso orario. Abbiamo pertanto deciso di sincronizzare la action che gestisce linserimento della data nel database. In tale modo solo ad un organizzatore viene data la possibilit di prenotare il campo per una determinata partita. Finita la prenotazione, il successivo organizzatore che richiede di fare la medesima operazione potr adesso accedere alla action, la quale gli comunicher che il campo in quellorario occupato

13

Capitolo 3 Descrizione del Sistema

Il funzionamento del nostro sistema analogo a quello di tutti i sistemi sviluppati nel rispetto del pattern MVC, in ogni caso opportuno descrivere alcuni aspetti nel dettaglio.

3.1. Pattern Model View Control

Il pattern basato sulla separazione dei compiti fra i componenti software che interpretano i tre ruoli principali: il model fornisce i metodi per accedere ai dati dell'applicazione; il view visualizza i dati contenuti nel model e si occupa dell'interazione con utenti e agenti; il controller che riceve i comandi dell'utente (in genere attraverso il view) e li attua modificando lo stato degli altri due componenti.

In particolare, vediamo il dettaglio del funzionamento delle applicazioni sviluppate nel rispetto del design pattern: L'utente accede alla view interagendo con la stessa e dall'interazione si generano chiamate ad una controller servlet che esegue il routing delle richieste smistandole. Attraverso le interazioni con la vista il controller richiama i metodi degli EJB che eseguono sulle classi del modello le operazioni che la logica del controller ha richiesto.

3.2. Model Domain Object (Model)

Come accennato anche in precedenza la persistenza gestita mediante Java Persistence API (JPA). In particolare, per rendere persistenti gli oggetti del domain model stato necessario codificare il dominio utilizzando annotazioni in modo da fornire al persistence provider le necessarie informazioni circa: gli oggetti del domain model, le modalit per la loro identificazione univoca, le relazioni esistenti tra gli oggetti e la mappatura degli oggetti su una tabella del DB. In questo progetto il dominio stato modellato con le seguenti classi (Figura 3): Matches, che modella un match; MatchesPK, che modella la chiave primaria di un match; Players, che modella un giocatore; Report, che modella un report; ReportPK, che modella la chiave primaria di un report; Teams, che modella una squadra; Tournament, che modella un torneo; Users, che modella un utente del sistema.

Abbiamo scelto di utilizzare queste entit per tenere traccia dei dati di tutti gli utenti, dei giocatori, delle squadre e dei tornei, nonch le informazioni su come sono andate tutte le partite che vengono disputate in ogni torneo e tutti i report che riguardano le prestazioni di ogni giocatore in una determinata partita di un determinato torneo.
14

15
Figura 3 - Diagramma delle classi del dominio

3.3 Enterprise JavaBeans (Model)

Gli EJB esportano i metodi necessari allinterazione con le classi che modellano il dominio e nel nostro caso sono sei: MatchesBean (figura 4), che interagisce con le entity Matches, gestendo le operazioni pi comuni che interessano una partita; PlayerBean (figura 5), che gestisce prevalentemente le operazioni sulle giocatori; ReportBean (figura 6), che interagisce prevalentemente con entity di tipo Report, gestendo le statistiche di un giocatore che partecipa ad una determinata partita di un torneo TeamsBean (figura 7), che interagisce prevalentemente con entity di tipo Teams, gestendo le operazioni relative alle squadre; TournamentBean (figura 8), che gestisce le informazioni relative ai tornei; UsersBean (figura 9), che gestisce le informazioni relative agli utenti;

Figura 4 - MatchesBean

16

Figura 5 - PlayersBean

17

Figura 6 ReportBean

18

Figura 7 TeamsBean

19

Figura 8 TournamentBean

20

Figura 9 UsersBean

21

Figura 10 - Calcetto database

3.4. Servlet (Control)

Le servlet implementano la logica di controllo e richiamano i metodi degli EJB per interagire con il modello. Vengono richiamate da operazioni eseguite sulle pagine JSP e, per integrarsi meglio con queste, usano dei componenti di supporto: gli ActionForm. Questi salvano lo stato dei dati contenuti nei form delle pagine JSP come attributi accessibili attraverso metodi getter e setter e li passano automaticamente alle servlet che li utilizzano. Alcune delle servlet create sono:
22

Users, registra un utente che ha fornito informazioni valide al sistema; Login, consente lautenticazione dellutente; StartTourn, consente allorganizzatore di dare inizio al torneo; NextPhase, consente allorganizzatore di avanzare a una fase successiva del torneo; ExportXMLReport, consente allamministratore di esportare i report dei tornei.

3.5. Java Server Pages (View)

Le JSP costituiscono la componente View del pattern, la vista dell'applicazione. Le JSP proprio come le Servlet sono eseguite nel servlet container. In sostanza ciascuna richiesta individua in modo univoco una determinata azione, la Servlet che ha il ruolo di controller utilizza i valori dei form per l'esecuzione del metodo execute della azione specifica alla quale riferita la richiesta. Nella nostra applicazione abbiamo definito un discreto numero di JSP, che possono essere raggruppate in base alla tipologia di operazioni alle quali consentono di accedere attraverso il meccanismo descritto: Pagine per la gestione del login e della registrazione; Pagine per la gestione dei profili utente e delle richieste di servizio; Pagine per la gestione delle squadre e dei giocatori; Pagine per la gestione dei tornei.

Vediamo adesso un elenco delle principali pagine presenti.

Pagine per la gestione del login e della registrazione: login.jsp, mostra i form necessari al login utente; logout.jsp, consente il logout dellutente; addPlayer.jsp, consente a un capitano la registrazione di un nuovo giocatore; addUser.jsp, consente la registrazione di un nuovo utente; credentials.jsp, comunica le credenziali di registrazione a un nuovo utente.

Pagine per la gestione dei profili utente e delle richieste di servizio: contacts.jsp, presenta i recapiti per contattare gli amministratori del sito; home.jsp, costituisce la pagina iniziale dalla quale si accede alle varie sezioni del sito; manageTeams.jsp, visualizza a un organizzatore la lista delle squadre che partecipano al proprio torneo, con la possibilit di modificarle o eliminarle; profile.jsp, visualizza il profilo di un utente, in maniera differente che si tratti di un amministratore, di un organizzatore o di un capitano; showPlayersList.jsp, consente di visualizzare la lista dei giocatori di una squadra; showReport.jsp, consente di visualizzare il report di una partita; showTeamsList.jsp, consente di visualizzare la lista delle squadre partecipanti a un torneo;

23

Pagine per la gestione delle squadre e dei giocatori: modifyPlayer.jsp, consente di modificare le informazioni relative a un giocatore; modifyTeam.jsp, consente di modificare le informazioni relative a una squadra; modifyUsers.jsp, consente di modificare le informazioni relative a un utente; managePlayers.jsp, consente di eliminare, modificare o aggiungere un giocatore; manageTeams.jsp, consente a un organizzatore di cancellare o modificare una squadra;

Pagine per la gestione dei tornei: changeDate.jsp, consente a un organizzatore di fissare o modificare la data di una partita; insertReport.jsp, consente a un organizzatore di inserire il report di una partita; performance.jsp, consente di modificare le informazioni di un giocatore riguardo una partita disputata; scores.jsp, consente di visualizzare la lista dei giocatori delle squadre di una partita; selectTourn.jsp, visualizza lelenco di tornei in corso; tournament.jsp, consente di visualizzare i risultati e landamento di un torneo.

3.6. Filter
I filtri sono delle componenti dell'applicazione web utilizzati per intercettare ed elaborare gli oggetti ServletRequest e ServletResponse, prima che vengano passati alla servlet. Nel nostro caso ne abbiamo utilizzati cinque: AdminControlFilter, controlla che l'utente che sta accedendo ad una determinata porzione dell'applicazione abbia le credenziali di amministratore; CaptainControlFilter, controlla che l'utente che sta accedendo ad una determinata porzione dell'applicazione abbia le credenziali di capitano; OrgControlFilter, controlla che l'utente che sta accedendo ad una determinata porzione dell'applicazione abbia le credenziali di organizzatore; PlayerOrgOrCapFilter, controlla che laggiornamento dei dati di un giocatore sia fatto esclusivamente da un capitano o da un organizzatore UserVisitorOrAdminFilter, controlla che la registrazione di un nuovo utente che effettuata esclusivamente da un utente non loggato (che vuole registrare un nuovo capitano) o da un amministratore (che vuole registrare un nuovo organizzatore)

Tutti i filtri in questione verificano il ruolo con cui un utente sta richiamando una determinata azione: se il ruolo identificato non tra quelli che ha diritto allaccesso allora il filtro ridiriger lutente nella sua home page.

24

3.7. Realizzazione di alcuni casi duso

Sono qui di seguito riportati i sequence diagram dei casi d'uso, al fine di illustrare l'interazione tra le componenti.

Figura 11 - Login: Sequence Diagram

Figura 12 - Show Players List: Sequence Diagram

25

Capitolo 4 Installazione dellapplicativo

4.1. Predisposizione del Database
Per l'esecuzione di Calcetto necessario prima di tutto predisporre un database al quale potersi collegare attraverso un DBMS relazionale. Per quanto riguarda il DBMS la nostra scelta ricaduta su Postgresql. Il database dell'applicazione deve contenere tutte le tabelle necessarie al corretto funzionamento, queste ovviamente devono avere gli attributi specificati nel modello di cui in figura 10. Di seguito viene mostrato il codice SQL per creare le tabelle nel Database:

CREATE TABLE matches ( team_in character varying(255) NOT NULL, team_out character varying(255) NOT NULL, macthday_date timestamp without time zone, goal_in integer, goal_out integer, played boolean, tourn_name character varying NOT NULL, phase integer, CONSTRAINT matches_pkey PRIMARY KEY (team_in , team_out , tourn_name ) ); CREATE TABLE players ( player_id integer NOT NULL, player_name character varying(255) NOT NULL, team_name character varying(255), player_role character varying(10), player_medical boolean, player_state boolean, yellow_card integer, red_card integer, goals integer, fee integer, CONSTRAINT players_pkey PRIMARY KEY (player_id ), CONSTRAINT players_player_name_key UNIQUE (player_name ) ); CREATE TABLE report ( 26

player_name character varying(255) NOT NULL, team_in character varying(255) NOT NULL, team_out character varying(255) NOT NULL, goals integer, fee integer, yellow integer, red integer, tourn_name character varying NOT NULL, CONSTRAINT report_pkey PRIMARY KEY (player_name , team_in , team_out , tourn_name ) ); CREATE TABLE teams ( team_name character varying(255) NOT NULL, team_state character varying(255), fee integer, captain character varying(255), tourn_name character varying, team_quote boolean, CONSTRAINT teams_pkey PRIMARY KEY (team_name ) ); CREATE TABLE tournament ( tourn_name character varying NOT NULL, start_date timestamp without time zone, started boolean, phases integer, CONSTRAINT tournament_pkey PRIMARY KEY (tourn_name ) ); CREATE TABLE users ( user_id integer NOT NULL, user_name character varying(255) NOT NULL, user_address character varying(255), user_city character varying(255), user_role character varying(255), pwd character varying(255), firstname character varying(255), lastname character varying(255), tourn_name character varying, CONSTRAINT users_pkey PRIMARY KEY (user_id ), CONSTRAINT users_user_name_key UNIQUE (user_name ) );

27

4.2. EJB container Glassfish

LEJB container che abbiamo utilizzato Glassfish, per indicazioni riguardo alla corretta procedura di installazione possibile consultare direttamente la documentazione messa a disposizione dal sito del produttore7. Una volta installato sulla macchina, lEJB container deve essere configurato. necessario innanzi tutto predisporre Glassfish al collegamento con il DBMS. Per farlo si pu accedere direttamente alla console di Glassfish attraverso il browser e accedendo al menu Resources JDBC Connection Pools e completando i campi richiesti con i dati corretti. Successivamente necessario creare la risorsa JDBC, il cui nome andr riportato nel file persistence.xml dellEJB Module sviluppato, per fare questo sempre dalla console di Glassfish sufficiente accedere al menu Resources JDBC JDBC Resources selezionare new e seguire il wizard, ricordandosi di impostare il Pool Name a quello creato nello step precedente. Dopo la configurazione di Glassfish per laccesso al DBMS si pu passare allinstallazione dellEJB Module sviluppato. Questa operazione pu essere sempre eseguita dalla console di Glassfish, per fare ci necessario accedere al menu Applications e selezionare Deploy. Questo ci porter ad un form in cui selezioneremo il jar file del nostro EJB Module dal filesystem locale per caricarlo sull'EJB Container. Inoltre richiesto anche di selezionare il tipo di applicazione/modulo di cui stiamo eseguendo il deploy (visto che Glassfish pu fungere da Application Server anche per altri tipi di applicazioni). In caso di installazione di Glassfish e Tomcat su due macchine diverse si deve specificare nella configurazione di Glasshfish l'indirizzo IP sul quale attendere le richieste del Servlet container. Tale impostazione fattibile attraverso il menu ORB IIOP Listeners orb-listener-1 inserendo lindirizzo IP dellhost di Glassfish in Network Address, la porta su cui sar in ascolto e abilitare il servizio Listener dellapposita check box.

4.3. Servlet Container Tomcat

Tomcat essendo solamente un Servlet Container non implementa tutta la specifica JEE in particolar modo il lato EJB, compito di Glassfish. Per permettere a Tomcat di dialogare con Glassfish necessario creare una cartella shared nella root di installazione di Tomcat. Copiare le directory lib e modules contenute nella root di Glassfish e posizionarle nella directory shared creata precedentemente nella root di Tomcat. Successivamente necessario impostare il parametro shared.loader del file catalina.properties (file che si trova all'interno della directory conf dell'installazione di Tomcat) come riportato di seguito: shared.loader=${catalina.home}/shared/lib,${catalina.home}/shared/lib/*.jar Infine, se installiamo Glassfish su un server diverso da quello in cui in esecuzione Tomcat, necessario modificare il descrittore di deployment della web application (file web.xml) impostando
7

http://glassfish.java.net/docs/

28

tra le varie propriet l'indirizzo IP e la porta dell'IIOP Listener configurati su Glassfish, a cui abbiamo fatto riferimento nel paragrafo precedente. Per il deploy vero e proprio della web application possiamo procedere accedendo all'interfaccia web di controllo di Tomcat, aprire il Tomcat Manager e da qui selezionare il file Progetto_Calcetto.war dal filesystem locale e fare l'upload. A questo punto pu essere necessario dare lo start all'applicazione dall'apposita voce che si creata nella lista delle applicazioni disponibili sul servlet container. Al primo avvio dell'applicazione, viene creato un utente amministratore di default se non gi presente sul database, con credenziali: Username: admin Password: admin

29

Capitolo 5 Sviluppi

futuri

Prima di rendere disponibile lapplicazione in rete, sarebbe opportuno effettuare alcune modifiche ed ampliamenti alle funzionalit in modo da migliorarne anche lappetibilit per lutenza. I principali aspetti che chiederebbero un ulteriore lavoro sono risolubili attraverso alcuni semplici interventi: Miglioramento del processo di criptazione e decriptazione della password nello scambio con lhost contenente il database Migliorare il meccanismo di registrazione di un utente attraverso linvio di una mail di avviso registrazione con un link per la conferma Messa in sicurezza dellapplicazione.

30