UNIVERSITÀ DEGLI STUDI DI PADOVA -...

1

UNIVERSITÀ DEGLI STUDI DI PADOVA

FACOLTÀ DI INGEGNERIA GESTIONALE

Dipartimento di Tecnica e Gestione dei Sistemi Industriali

TESI DI LAUREA DI PRIMO LIVELLO

PROGETTAZIONE E SVILUPPO DI UN SITO WEB PER LA GEST IONE

DELLE ISCRIZIONI A TORNEI SPORTIVI USANDO PHP

DESIGN AND DEVELOPMENT OF A WEB SITE TO LOG SPORT

TOURNAMENTS DATA USING PHP

Relatore: PROF.SSA MONICA REGGIANI

Laureando: ANDREA BEGHIN

ANNO ACCADEMICO 2010 – 2011

3

Indice Introduzione ................................................................................................................... 6

CAPITOLO 1

Analisi del problema .............................. ..................................................................... 9

1.Affrontare il problema .......................... ............................................................ 10

1.1.L’ideazione ………………………………………………………………...….... 10

1.2.Requisiti evolutivi ……….……………………………………...…………...….. 10

2.Casi d’uso ...................................... .................................................................... 11

2.1.Definizione degli attori principali …………………………………………...… 11

2.2.I casi d’uso ………….……………………………………………………….….. 12

3.Problemi riscontrati ............................ .............................................................. 20

CAPITOLO 2

Definizione degli strumenti ....................... ................................................................ 23

1.Basi di dati ………………………………… ……..……………………………….…. 24

1.1.Basi di dati e sistemi di gestione di basi dati …………………………..…… 24

1.2.Modelli dei dati ……………………………………………………….………… 24

1.3.Linguaggi per basi di dati ………………………………………………...…… 25

2.Software ………………………………………………………………… ……………. 25

2.1.Ambiente di sviluppo ……………………………………………………..…… 25

2.1.1.Software proprietario ……………………………………….……….…… 25

2.1.2.Software non proprietario …………………………………………..…… 26

2.2.Sistema di gestione del database ……………………………………….…… 26

2.3.Web server ……….……………………………………………………..………. 26

2.4.Linguaggio di programmazione per l’applicazione web …….……………… 26

2.4.1.PHP ……………………………………………………………………..… 27

2.4.2.Java ……………………………………………….………………….…… 27

CAPITOLO 3

Implementazione ................................... .................................................................... 30

1.Struttura del database .......................... ......................................................... 31

1.1.Modello entità-relazione ............................................................................. 31

1.2.Modello logico ............................................................................................ 32

2.Struttura del sistema e diagrammi flow chart .... ......................................... 32

2.1.Caso d’uso UC1: Iscrizione squadre .......................................................... 32

2.2.Caso d’uso UC2: Iscrizione accompagnatori e giocatori ............................ 33

2.3.Caso d’uso UC3: Caricamento del logo ..................................................... 35

2.4.Caso d’uso UC4: Caricamento della foto ................................................... 36

4

2.5.Caso d’uso UC5: Squadre iscritte .............................................................. 36

2.6.Caso d’uso UC6: Elenco dettagli delle squadre iscritte .............................. 37

2.7.Caso d’uso UC7: Stato delle iscrizioni ....................................................... 37

2.8.Caso d’uso UC8: Impaginazione brochure ................................................. 38

2.9.Caso d’uso UC9: Creazione referti ............................................................. 38

3.Dettagli implementazione ........................ ........................................................ 39

CAPITOLO 4

Casi d’uso sviluppati ............................. .................................................................... 46

1.Caso d’uso UC1: Iscrizione squadre ............................................................... 47

2.Caso d’uso UC2: Iscrizione accompagnatori e gioca tori .............................. 49

3.Caso d’uso UC3: Caricamento del logo .......................................................... 54

4.Caso d’uso UC4: Caricamento della foto ........................................................ 56

5.Caso d’uso UC5: Squadre iscritte ................ ................................................... 58

6.Caso d’uso UC6: Elenco dettagli delle squadre isc ritte ................................ 58

7.Caso d’uso UC7: Stato delle iscrizioni ............................................................ 59

8.Caso d’uso UC8: Impaginazione brochure ..................................................... 59

9.Caso d’uso UC9: Creazione referti ............... ................................................... 60

CAPITOLO 5

Testing ........................................... ............................................................................. 63

1.Periodo e modalità di test ...................... .......................................................... 64

2.Valutazione ..................................... ................................................................... 64

3.Miglioramenti ..................................................................................................... 65

Conclusioni ................................................................................................................... 68

Bibliografia ................................................................................................................... 71

6

Introduzione Il progetto descritto in questa tesi ha come obiettivo la realizzazione di un sistema di

iscrizione in PHP che faciliti la raccolta dei dati relativi alle società che intendono

partecipare ad un torneo.

L’idea nasce dall’organizzazione di un torneo minibasket di Padova e provincia che è

cresciuto di dimensione negli anni fino a diventare il torneo minibasket più grande

d’Italia. Questa rapida espansione, il notevole numero di squadre partecipanti (oltre 50)

e quindi il numero elevato di bambini presenti e da iscrivere (oltre 700), ha spinto a

creare un sistema di iscrizione che faciliti la gestione di questa elevata quantità di dati,

gestione che prima avveniva in modo cartaceo e manuale.

Il sistema presenta un’interfaccia molto intuitiva in modo da facilitare il suo utilizzo a

ogni utente, dal dirigente poco pratico di computer al giovane istruttore più pronto dal

punto di vista informatico.

Inoltre l’utente può verificare lo stato della propria iscrizione consultando una semplice

pagina web che lo tiene al corrente sui passi dell’iscrizione già completati e sui passi

non ancora compilati.

In più il sistema di iscrizione non si limita alla semplice raccolta dei nominativi delle

società, dei bambini partecipanti e degli istruttori minibasket, ma consente di caricare il

logo e la foto di ogni squadra.

Questi dati possono poi essere utilizzati dal webmaster in modo molto agevole ed è

possibile controllare i dettagli ed i recapiti delle società iscritte, ottenere l’impaginazione

automatica della brochure che viene realizzata ad ogni edizione, e creare i referti di

gara precompilati in modo totalmente automatico di tutte le oltre 200 partite del torneo.

La presente tesi descrive le fasi che hanno portato alla realizzazione del sistema di

iscrizione.

In particolare nel primo capitolo sono spiegati i modi dell’approccio al problema, con la

presentazione dei casi d’uso possibili e delle problematiche riscontrate durante la

progettazione. Il secondo capitolo è dedicato alla definizione degli strumenti utilizzati, e

vengono introdotti i concetti generali di base di dati, dei linguaggi di programmazione, e

dei software. Nel terzo capitolo si vanno ad approfondire gli aspetti legati

all’implementazione, ponendo particolare attenzione a come si sono risolti i problemi

presentati nel primo capitolo. Nel quarto capitolo invece si analizzano in modo

approfondito tutti i casi d’uso, mostrando nel particolare tutte le procedure possibili

attraverso l’utilizzo di screenshot per illustrare il risultato finale. Nell’ultima parte della

tesi, il quinto capitolo, si riportano le impressioni finali e le valutazioni, i problemi

7

riscontrati e gli ulteriori miglioramenti futuri necessari che si sono osservati durante la

fase di test.

9

CAPITOLO 1

Analisi del problema

10

1.Affrontare il problema

Il processo di costruzione si è svolto analizzando per prima cosa gli obiettivi finali di

una simile realizzazione. In particolare si è data importanza alla gestione dei dati per

semplificare e velocizzare l’utilizzo delle informazioni raccolte. I principali obiettivi

individuati sono stati:

• semplificazione del modo di inviare i dati da parte dell’utente all’organizzazione

del torneo;

• permettere all’utente di verificare lo stato delle proprie iscrizioni;

• ottenere l’impaginazione automatica della brochure;

• realizzazione dei referti di gara precompilati in automatico e stampabili.

Si sono poi andati a verificare i dati necessari e le informazioni da raccogliere per

raggiungere e sviluppare questi obiettivi, si è scelto la struttura del database e come

sviluppare il sistema di iscrizione, ed infine si ha implementato il tutto.

1.1.L’ideazione

Lo scopo della fase di ideazione non è quella di definire tutti i requisiti del sistema né di

generare un piano di progetto preciso e esente da modifiche e miglioramenti futuri.

L’obiettivo è quello di analizzare il problema e gli scopi da raggiungere e di ottenere

un’idea di massima sul progetto da realizzare, sulle risorse e sul tempo necessario a

costruirlo e di valutare poi se ne vale o meno la pena.

Il fine del progetto è quello di fornire degli strumenti utili per la gestione dei dati raccolti,

in particolare nella gestione dei nominativi di bambini ed istruttori, oltre che dei recapiti

delle società e degli accompagnatori, senza trascurare la raccolta di dati multimediali

come il logo e la foto delle squadre.

Il tutto viene archiviato in un database MySql facilmente consultabile

dall’organizzazione tramite immediate pagine web facili ed intuitive.

1.2.Requisiti evolutivi

Il sistema di iscrizione è stato realizzato in modo da:

• avere e mantenere tutti i dati sempre disponibili;

• essere facile ed intuitivo da usare;

• utilizzare pagine il più possibili leggere e veloci;

• essere continuamente aggiornabile e ampliabile;

• essere usato da qualsiasi computer e da qualsiasi sistema operativo.

11

Inoltre il sistema di iscrizione è stato creato in modo da consentire sviluppi e

miglioramenti futuri, tra i quali:

• realizzazione delle pagine in altre lingue (es. inglese, utile vista l’internazionalità

del torneo);

• definizione dei calendari in automatico in base al numero delle squadre iscritte;

• realizzazione dei calendari delle seconde fasi e delle fasi finali in base ai

risultati conseguiti dalle squadre durante il torneo.

2.Casi d’uso

Per capire al meglio come sviluppare e comprendere i requisiti del progetto sono stati

presi come riferimento i casi d’uso. Il caso d'uso in informatica è una tecnica usata nei

processi di ingegneria del software per effettuare in maniera esaustiva e non ambigua

la raccolta dei requisiti al fine di produrre software di qualità. Vengono utilizzati per

l’individuazione e la registrazione dei requisiti funzionali scrivendo come un sistema

possa essere utilizzato per consentire agli utenti di raggiungere i loro obiettivi.

In questo capitolo vengono raccolti i casi d’uso elaborati per la realizzazione del

sistema di iscrizione.

Si è scelto di presentarli in forma sintetica ma la semplicità è finalizzata a ricordare

l’essenza base dei casi d’uso: individuare e registrare i requisiti funzionali che

permettono all’utente, per mezzo del sistema, di raggiungere i propri obiettivi.

Sono disponibili diversi template di formato per i casi d’uso dettagliati. Il formato più

comunemente utilizzato, dagli inizi degli anni ’90, è probabilmente il template creato da

Alistair Cockburn, autore del libro e dell’approccio più diffuso alla modellazione dei

casi d’uso. Nello sviluppo dei casi d’uso del progetto il template citato è stato preso

come modello.

2.1.Definizione degli attori principali

Nome: Responsabile società.

Descrizione: Il responsabile società si occupa dell’inserimento dei dati relativi alla

società, dei nominativi dei bambini ed istruttori, e del caricamento del logo e della foto

della squadra.

Aspettative-obiettivi:

• inserire i dati richiesti in modo rapido e senza problemi;

• verificare lo stato delle proprie iscrizioni;

• comunicare con l’organizzazione del torneo.

12

Nome: Webmaster.

Descrizione: Il webmaster è colui che gestisce i dati inseriti dal responsabile società.

Aspettative-obiettivi:

• visualizzare i dati in modo rapido e senza problemi;

• essere aggiornato in tempo reale sui dati inseriti dal responsabile società;

• poter comunicare con il responsabile società.

2.2.I casi d’uso

Caso d’uso UC1: Iscrizione squadre.

Livello: Obiettivo utente.

Attore primario: Responsabile società.

Parti interessate e Interessi:

• Responsabile società: vuole un inserimento dei dati preciso e rapido. Non vuole

errori.

• Webmaster: vuole essere in possesso dei dati sulle squadre il prima possibile

attraverso un servizio rapido, nel modo più semplice possibile. Vuole una

visualizzazione chiara dei dati inseriti. Vuole poter contattare il responsabile

società in modo rapido.

• Organizzazione: vuole registrare accuratamente le squadre iscritte e i loro

recapiti per possedere un archivio storico dei dati, utile per organizzare una

nuova edizione del torneo.

Pre-condizioni: Nessuna.

Garanzia di successo: La squadra viene salvata ed i dati inerenti ad essa sono visibili

in ogni momento tramite una pagina web accessibile solo dal webmaster.

Scenario principale di successo:

1. Il responsabile società inizia una nuova procedura di inserimento di una

squadra.

2. Il responsabile società seleziona il nome della sua squadra (se già presente

nell’elenco perché ha partecipato all’edizione precedente) oppure seleziona

“NUOVA SOCIETA’”.

3. Il responsabile società procede alla compilazione dei campi richiesti.

4. Il sistema procede alla registrazione dell’operazione e rende disponibili le

informazioni registrate.

5. Il sistema visualizza un messaggio di inserimento avvenuto con successo.

13

6. Il sistema invia un’e-mail che avvisa il webmaster che è avvenuta una nuova

iscrizione.

7. Il sistema invia un’e-mail che avvisa il responsabile società che l’iscrizione è

avvenuta con successo (nel caso il campo relativo all’indirizzo e-mail sia stato

compilato).

Il responsabile società può ripetere i passi 1-2-3-4-5-6-7 per iscrivere più squadre della

sua società.

Estensioni:

a. Il sistema non conferma l’inserimento:

1. non sono stati riempiti tutti i campi obbligatori;

2. il sistema segnala l’errore;

3. il sistema ripresenta la maschera di compilazione.

b. Il sistema fallisce l’inserimento:

1. il tipo di dato inserito è errato;

2. il sistema segnala l’errore e cancella il dato nel campo errato;

3. il sistema ripresenta la maschera di inserimento precedente alla modifica.

Requisiti speciali:

• dispositivo in grado di potersi collegare alla rete;

• presenza di una connessione web.

Frequenza di ripetizione: disponibilità continua.

Caso d’uso UC2: Iscrizione accompagnatori e giocato ri.




• Responsabile società: vuole un inserimento dei dati preciso e rapido. Non vuole

errori.

• Webmaster: vuole essere in possesso dei dati sulle squadre il prima possibile

attraverso un servizio rapido, nel modo più semplice possibile. Vuole una

visualizzazione chiara dei dati inseriti. Vuole poter contattare gli istruttori iscritti

in modo rapido.

• Organizzazione: vuole registrare accuratamente i nominativi degli istruttori e dei

bambini iscritti, utili per realizzare la brochure del torneo e i referti precompilati.

Vuole registrare i recapiti degli istruttori per invitarli ad una nuova edizione del

torneo.

Pre-condizioni: La procedura relativa all’iscrizione squadre deve essere completata

prima di procedere a questa fase.

14

Garanzia di successo: I dati relativi ad istruttori e bambini vengono salvati e sono

visibili in ogni momento tramite una pagina web accessibile solo dal webmaster.


1. Il responsabile società inizia una nuova procedura di inserimento dati di

istruttori e giocatori.

2. Il responsabile società seleziona la sua squadra.

3. Il responsabile società procede alla compilazione dei campi richiesti

sull’istruttore minibasket e sull’aiuto istruttore minibasket (facoltativo).

4. Il sistema, se presenti, mostra l’elenco dei bambini che hanno partecipato alla

edizione precedente e che possono essere re iscritti alla nuova edizione

(dipende dall’età dei bambini).

5. Il sistema mostra un modulo per inserire i dati relativi ai nuovi bambini

partecipanti.

6. Il sistema visualizza un riepilogo delle informazioni inserite ed è possibile

modificare i dati inseriti se necessario.




9. Il sistema invia un’e-mail che avvisa il webmaster che una società ha iscritto


10. Il sistema invia un’e-mail che avvisa gli istruttori che l’iscrizione è avvenuta con

successo (nel caso il campo relativo all’indirizzo e-mail degli istruttori sia stato

compilato).

Un singolo responsabile società può eseguire i passi elencati solo una volta per ogni

squadra iscritta.

Estensioni:


1. non sono stati riempiti tutti i campi obbligatori;


3. il sistema ripresenta la maschera di compilazione.

b. Il sistema fallisce l’inserimento:

1. il tipo di dato inserito è errato;

2. il sistema segnala l’errore e cancella il dato nel campo errato;

3. il sistema ripresenta la maschera di inserimento precedente alla modifica.

c. L’utente ha commesso errori di digitazione:

1. il responsabile società può modificare i dati digitati prima di confermare

l’iscrizione cliccando sul tasto modifica;

15

2. il responsabile società inserisce i dati corretti;

3. il responsabile società ritorna alla pagina di riepilogo.

Requisiti speciali:




Caso d’uso UC3: Caricamento del logo.




• Responsabile società: vuole un inserimento del logo più rapido possibile. Vuole

poter caricare il logo in ogni formato disponibile. Non vuole errori.

• Webmaster: vuole poter visualizzare il logo caricato il prima possibile,

attraverso un servizio rapido, nel modo più semplice possibile.

• Organizzazione: vuole salvare accuratamente i loghi per realizzare la brochure

del torneo e per poterli riutilizzare in futuro in una nuova edizione .



Garanzia di successo: I loghi vengono salvati nello spazio web messo a disposizione

dal servizio hosting in uso e l’url del logo viene salvato nel database nella riga relativa

alla squadra del responsabile società.


1. Il responsabile società inizia una nuova procedura di inserimento del logo.


3. Il responsabile società seleziona il logo da caricare.

4. Il sistema procede al caricamento del logo e lo rende disponibile.


6. Il sistema invia un’e-mail che avvisa il webmaster che è stato caricato un nuovo

logo.

Un singolo responsabile società può ripetere i passi 1-2-3-4-5-6 per sostituire il logo

caricato.

Estensioni:



2. le modifiche non confermate vengono perse.

16

Requisiti speciali:


• presenza di una connessione web;


Caso d’uso UC4: Caricamento della foto.




• Responsabile società: vuole un inserimento della foto più rapido possibile.

Vuole poter caricare le foto in ogni formato disponibile. Non vuole errori.

• Webmaster: vuole poter visualizzare la foto caricata il prima possibile,

attraverso un servizio rapido, nel modo più semplice possibile.

• Organizzazione: vuole salvare accuratamente le foto per realizzare la brochure.



Garanzia di successo: Le foto vengono salvate nello spazio web messo a

disposizione dal servizio hosting in uso e l’url della foto viene salvato nel database

nella riga relativa alla squadra del responsabile società.


1. Il responsabile società inizia una nuova procedura di inserimento della foto.


3. Il responsabile società seleziona la foto da caricare.

4. Il sistema procede al caricamento della foto e la rende disponibile.


6. Il sistema invia un’e-mail che avvisa il webmaster che è stata caricata una

nuova foto.

Un singolo responsabile società può ripetere i passi 1-2-3-4-5-6 per sostituire la foto

caricata.

Estensioni:



2. le modifiche non confermate vengono perse.

Requisiti speciali:



17


Caso d’uso UC5: Squadre iscritte.


Attore primario: Webmaster.


• Webmaster: vuole poter visualizzare l’elenco delle squadre iscritte in modo

rapido e semplice, con indicata anche la provincia di provenienza per

localizzarle nel territorio.

• Organizzazione: vuole poter tenere sotto controllo il numero delle squadre

iscritte per valutare l’eventuale necessità di una campagna pubblicitaria per

raggiungere il numero prefissato di squadre partecipanti.


Garanzia di successo: Il database contenente tutte le squadre iscritte è sempre

presente ed accessibile.


1. Il webmaster accede alla pagina web relativa alla visualizzazione delle squadre

iscritte.

2. Visualizza tutte le squadre iscritte alla prossima edizione del torneo in ordine

alfabetico.

Requisiti speciali:




Caso d’uso UC6: Elenco dettagli delle squadre iscri tte.




• Webmaster: vuole poter visualizzare l’elenco delle squadre iscritte e i loro

dettagli in modo rapido e semplice, con indicati il recapito telefonico e l’indirizzo

e-mail, oltre che la provincia di provenienza.

• Organizzazione: vuole consultare l’elenco delle squadre per individuare le

squadre provenienti da fuori regione e i loro dettagli per poter organizzare

l’ospitalità e i trasporti.


18

Garanzia di successo: Il database contenente tutte le squadre iscritte è sempre

presente ed accessibile.


1. Il webmaster accede alla pagina web relativa alla visualizzazione dei dettagli

delle squadre iscritte.

2. Sceglie l’anno di edizione del torneo di cui vuole visualizzare le squadre.

3. Visualizza i dettagli di tutte le squadre iscritte in ordine alfabetico e i loro dettagli

e l’elenco delle squadre provenienti da fuori regione e i loro dettagli.

Requisiti speciali:




Caso d’uso UC7: Stato delle iscrizioni.




• Responsabile società: vuole poter verificare lo stato delle proprie iscrizioni per

poter visualizzare quale procedura deve ancora effettuare.

• Webmaster: vuole poter verificare lo stato delle iscrizioni per eventualmente

avvisare i responsabili società di procedere al completamento delle iscrizioni.


Garanzia di successo: Il database con tutti i dati inseriti è sempre presente ed

accessibile.


1. Il responsabile società accede alla pagina web relativa alla visualizzazione dello

stato delle iscrizioni.

2. Visualizza lo stato delle iscrizioni delle squadre iscritte in ordine alfabetico,

visualizza se il logo e la foto sono caricate, e se istruttori e giocatori sono iscritti.

Requisiti speciali:




19

Caso d’uso UC8: Impaginazione brochure.




• Webmaster: vuole poter visualizzare i giocatori di ogni squadra in ordine

alfabetico e impaginati. Vuole visualizzare gli istruttori dando la precedenza

all’istruttore rispetto all’aiuto istruttore. Vuole un rapido accesso al logo e alla

foto delle squadre per realizzare in modo rapido la brochure.



accessibile.


1. Il webmaster accede alla pagina web relativa all’impaginazione della brochure.

2. Sceglie l’anno di edizione del torneo.

3. Visualizza i dati impaginati delle squadre elencate in ordine alfabetico.

Estensioni:

a. In qualsiasi momento il webmaster può accedere alla foto e al logo delle squadre:

1. visualizza i dati impaginati delle squadre elencate in ordine alfabetico;

2. clicca sul tasto relativo alla foto o al logo della squadra.

Requisiti speciali:




Caso d’uso UC9: Creazione referti.




• Webmaster: vuole poter visualizzare i referti di gara in modo semplice e

agevole. Vuole stampare i referti in più copie (squadra vincente, squadre

perdente, organizzazione).



accessibile.


1. Il webmaster accede alla pagina web relativa alla creazione dei referti.


20

3. Seleziona le due squadre contendenti e compila i campi richiesti.

4. Visualizza il referto di gara.

5. Stampa il referto di gara.

Requisiti speciali:


• presenza di una connessione web;

• presenza di una stampante collegata.


3.Problemi riscontrati

Durante la realizzazione del progetto sono state riscontrate diverse difficoltà.

Di seguito sono riportati i principali problemi incontrati durante la progettazione del

sistema di iscrizione:

• Durata della sessione

Uno dei più gravi problemi che si sono verificati è legato alla durata della

sessione. Alcune parti dell’iscrizione per alcuni utenti possono risultare lunghe

da compilare e quindi è sorto il rischio che la sessione di lavoro scadesse prima

che l’utente potesse terminare la compilazione, con la perdita di tutti i dati

inseriti e non ancora salvati nel database.

• Standardizzazione dei dati inseriti

Tra gli obiettivi principali di questo progetto c’è sicuramente la volontà di gestire

in modo efficace e ordinato i dati raccolti. Per questo una delle problematiche a

cui si è data subito parecchia importanza è legata alla forma con la quale i dati

vengono raccolti, nel tentativo di avere un insieme di dati tutti standardizzati. Si

sono effettuati controlli sulla presenza di caratteri non voluti, si sono eliminati

spazi inutili, sistemate le maiuscole e le minuscole, controllati i numeri e gli

indirizzi e-mail inseriti, oltre che il formato degli anni di nascita o le modalità di

inserimento della provincia di provenienza.

• Controllo errori

Una diretta conseguenza della standardizzazione dei dati raccolti è il controllo

degli errori. Ogni qualvolta il sistema rileva dei dati errati o la mancata

compilazione di un campo obbligatorio segnala l’errore. Si è cercato di

segnalare l’errore in modo chiaro e semplice, senza richiedere la ricompilazione

dei campi correttamente riempiti.

21

• Iscrizione aiuto istruttore facoltativa

Un’altra problematica riscontrata è legata all’iscrizione degli istruttori visto che

non tutte le squadre sono accompagnate da due istruttori. È stato dunque

necessario prevedere che la parte di iscrizione relativa all’inserimento dei dati

dell’aiuto istruttore potesse essere saltata senza difficoltà per l’utente.

• Impaginazione del referto di gioco

Il referto di gara presenta un’altezza variabile a seconda del numero dei

bambini iscritti dalle squadre partecipanti. Per sfruttare tutto lo spazio a

disposizione nel foglio si è voluto creare un referto che utilizza sempre la

massima larghezza disponibile, mentre l’altezza varia. In questo modo si riesce

a stampare i referti sempre nel formato più grande possibile compatibilmente

con lo spazio disponibile nel foglio e il numero di bambini delle squadre

contendenti.

23

CAPITOLO 2

Definizione degli strumenti

24

1.Basi di dati

1.1.Basi di dati e sistemi di gestione di basi dati

Una base di dati, detta anche database o banca dati, è un insieme di dati logicamente

correlati fra loro, utilizzati per rappresentare le informazioni di interesse per un sistema

informativo.

Un sistema informativo è l’insieme delle azioni (automatizzate o meno) utili ad

organizzare le informazioni necessarie per perseguire gli scopi di una certa attività.

Fino agli anni Sessanta in un sistema informativo una base di dati veniva manipolata

dai programmi applicativi, interfacciandosi direttamente con il sistema operativo. Tale

strategia è tuttora impiegata solo quando i dati hanno una struttura molto semplice, o

quando sono elaborati da un solo programma applicativo.

A partire dalla fine degli anni Sessanta, per gestire basi di dati complesse e condivise

da più applicazioni, si sono utilizzati appositi sistemi software, detti sistemi per la

gestione di basi di dati (DataBase Management System o DBMS). Uno dei vantaggi di

questi sistemi è la possibilità di non agire direttamente sui dati, ma di vederne una

rappresentazione concettuale.

I DataBase Management System sono quindi i prodotti software in grado di gestire i

database; le loro caratteristiche sono:

• capacità di gestire grandi quantità di dati;

• condivisione dei dati fra più utenti e applicazioni;

• utilizzo di sistemi di protezione e autorizzazione per l'accesso ai dati stessi.

Per la realizzazione di questo database si è utilizzato MySQL, le cui caratteristiche

verranno esposte in seguito.

1.2.Modelli dei dati

Per la realizzazione di una base di dati sono stati pensati diversi modelli che

organizzano i dati e ne descrivono la struttura.

Possiamo identificare diversi tipi di database, a seconda della loro struttura logica:

• Modello gerarchico: è il modello che ha conosciuto il maggior utilizzo fino agli

anni Ottanta. È basato su strutture ad albero nelle quali ogni dato che non sia a

livello radice ha uno e un solo padre.

• Modello reticolare: deriva da quello gerarchico rispetto al quale supera la

rigidità della struttura ad albero dell'interdipendenza dei dati, ma la cui

complessità ne ha impedito una larga diffusione.

• Modello relazionale: organizza i dati in tabelle basandosi sulle relazioni fra essi.

25

• Modello ad oggetti: è il modello più recente, estende i concetti del modello

relazionale adattandoli alla programmazione ad oggetti.

I database di tipo relazionale sono, attualmente, di gran lunga i più diffusi.

1.3.Linguaggi per basi di dati

I linguaggi tramite i quali è possibile manipolare una base di dati si possono distinguere

secondo il loro utilizzo:

• Data Definition Language (DDL): consente di definire la struttura della base di

dati e le autorizzazioni per l'accesso.

• Data Manipulation Language (DML): permette di interrogare e aggiornare le

istanze della base di dati, permette di inserire, cancellare, modificare i dati.

• Device Media Control Language (DMCL): consente di controllare i supporti

(memoria di massa) dove vengono memorizzati i dati.

• Data Control Language (DCL): permette di gestire gli utenti e i permessi.

• Query language (QL): dà la possibilità di interrogare il database, cioè di leggere

i dati.

Il linguaggio che si è utilizzato in questo progetto è SQL, di cui sono stati pubblicati

diversi standard, attualmente di gran lunga il linguaggio più utilizzato.

2.Software

Per la realizzazione di un database e per permettere a degli utenti l’accesso remoto via

browser allo stesso è necessario scegliere un ambiente di sviluppo, un sistema di

gestione del database, un web server ed un linguaggio di programmazione con cui

sviluppare l’applicazione web.

2.1.Ambiente di sviluppo

Un ambiente di sviluppo è un software che aiuta i programmatori nello sviluppo del

codice. Normalmente consiste in un editor di codice sorgente.

Si può distinguere tra open source, modello di sviluppo di software usato dal

movimento FOSS (free and open source software), e closed source (o software

proprietario).

2.1.1.Software proprietario

Il software proprietario ha delle restrizioni sul suo utilizzo, modifica, riproduzione o

distribuzione. Queste restrizioni sono imposte dai proprietari tramite la non

pubblicazione del codice sorgente o attraverso l’utilizzo di licenze o copyright.

26

2.1.2.Software non proprietario

Per quel che riguarda il software non proprietario, a differenza del software

proprietario, viene messo a disposizione il codice sorgente. Tra i software non

proprietari si distingue tra open source e software libero.

2.2.Sistema di gestione del database

I sistemi di gestione del database sono sistemi software che consentono la creazione

e la manipolazione efficiente di database, e vengono definiti Relational Database

Management System (RDBMS).

Tra i vari RDBMS open source si è utilizzato MySQL. MySQL è il più diffuso database

open source basato sul linguaggio SQL. Questo prodotto viene fornito dall'azienda

MySQL AB che sviluppa il proprio business erogando servizi basati su MySQL stesso.

MySQL si occupa della strutturazione e della gestione dei dati stessi, in modo da

velocizzarne l'accesso, la modifica e l'inserimento di nuovi elementi.

L'acronimo SQL significa "Structured Query Language" ed indica il linguaggio standard

di interrogazione dei Database.

2.3.Web server

Un server web è un servizio che si occupa di fornire, tramite software dedicato e su

richiesta dell'utente, file di qualsiasi tipo, tra cui pagine web (successivamente

visualizzabili dal browser sul computer dell'utente). Le informazioni inviate dal server

web all'utente viaggiano in rete trasportate dal protocollo HTTP. L'insieme di server

web dà vita al World Wide Web, uno dei servizi più utilizzati di Internet.

Normalmente un server web risiede su sistemi hardware dedicati, ma può essere

eseguito su un computer ove risiedano anche altri servizi offerti o su computer utilizzati

anche per altri scopi, previa l'installazione del relativo pacchetto software dedicato. Ad

esempio si può installare un server web su un normale personal computer allo scopo di

testare in locale il proprio sito web oppure per consentire l'accesso ai propri documenti

da altre postazioni o terminali host, sia in LAN, sia via Internet.

2.4.Linguaggio di programmazione per l’applicazione web

Nel progetto in questione si sono utilizzati soltanto linguaggi di programmazione open

source. Un linguaggio open source è un "codice aperto", quindi disponibile e

modificabile da tutti. Tra le alternative offerte dall’open source sono da segnalare

soprattutto il linguaggio Java, supportato da Apache o da Websphere, che realizza

connessioni con tutti i database, ed il linguaggio PHP, supportato da Apache, con

27

connessione nativa per i database in MySQL. Questi due linguaggi di programmazione

sono alla base del sistema di iscrizione realizzato.

2.4.1.PHP

A metà degli anni Novanta il web era ancora formato in gran parte da pagine statiche,

cioè da documenti HTML il cui contenuto non poteva cambiare fino a quando qualcuno

non interveniva manualmente a modificarlo. Con l'evoluzione di Internet, però, si

cominciò a sentire l'esigenza di rendere dinamici i contenuti, cioè di far sì che la stessa

pagina fosse in grado di proporre contenuti diversi, personalizzati in base alle

preferenze degli utenti, oppure estratti da una base di dati in continua evoluzione.

La popolarità di questo linguaggio è cresciuta esponenzialmente, anche grazie alla

forte integrazione di PHP con il web server Apache (il più diffuso in rete), e con il

database MySQL.

Oggi PHP è un linguaggio completo di scripting, sofisticato e flessibile, che può girare

praticamente su qualsiasi server web, su qualsiasi sistema operativo (Windows o

Unix/Linux, ma anche Mac, AS/400, Novell, OS/2 e altri), e consente di interagire

praticamente con qualsiasi tipo di database (SQLite, MySQL, PostgreSQL, SQL

Server, Oracle, SyBase, Access e altri). Si può utilizzare per i più svariati tipi di

progetti, dalla semplice home page dinamica fino al grande portale o al sito di e-

commerce.

Attualmente è utilizzato principalmente per sviluppare applicazioni web lato server.

2.4.2.Java

Java è un linguaggio di programmazione completamente orientato agli oggetti,

indipendente dalla piattaforma (può essere eseguito in qualunque ambiente in cui sia

installata l’apposita Java Virtual Machine), progettato per eseguire codice da sorgenti

remote in modo sicuro.

Java è quindi nato come linguaggio per la rete, per affiancare l'HTML. Quello che

serviva era una piattaforma per costruire applicazioni web che desse la possibilità di

trasferire informazioni sicure.

Una delle caratteristiche di Java che lo rendono nuovo rispetto ad altri suoi

predecessori come C e C++ è la modalità con cui vengono compilati ed eseguiti i

programmi. I sorgenti non vengono infatti compilati direttamente in linguaggio

macchina, ma tradotti in un codice detto Bytecode.

Il codice generato può essere lanciato sfruttando un software di runtime, detto Java

Virtual Machine (JVM), che interpreta il Bytecode ed esegue il programma sulla

macchina su cui è installato. È proprio questo software di runtime (la JVM) che,

28

fornendo uno strato intermedio tra il Bytecode e il sistema operativo, rende Java

indipendente dalla piattaforma e permette di eseguire lo stesso programma Java,

compilato una sola volta su una qualche macchina con un compilatore Java, su una

piattaforma Windows o su una piattaforma Linux, indifferentemente.

In più un punto di forza di Java che ne fa spesso la scelta preferita tra i linguaggi di

programmazione è la vastità delle librerie standard di cui è dotato, che contribuisce a

renderlo altamente integrabile con le altre tecnologie.

30

CAPITOLO 3

Implementazione

31

1.Struttura del database

Il database è stato pensato per avere una struttura molto semplice e chiara. Inoltre è

stato realizzato in modo da evitare la ripetizione di dati salvati o in più tabelle o in più

righe. La struttura del database viene ora presentata tramite le due modalità più

utilizzate: il modello entità-relazione e il modello logico.

1.1.Modello entità-relazione

La progettazione concettuale ha il compito di rappresentare le informazioni che

abbiamo ottenuto dalla raccolta dei requisiti con uno schema formale o più

precisamente detto schema concettuale. Questo schema in pratica ci consente di

organizzare i dati ad un alto livello di astrazione perché la finalità di questa fase è

quella di rappresentare il contenuto informativo della base dati.

Per entità si intende in generale un qualsiasi elemento della realtà che può essere

chiaramente individuato, nel nostro caso accompagnatore, squadra e giocatore. Il

collegamento tra le varie entità prende il nome di relazione. Una relazione è anche

caratterizzata da una cardinalità che ci dice quante volte un'istanza di una entità può

essere collegata a istanze di altre entità coinvolte. Nel nostro caso un accompagnatore

può essere responsabile solo di una squadra, mentre una squadra può avere uno

(cardinalità minima) o due istruttori (cardinalità massima). Un giocatore può

appartenere solo a una squadra, mentre a una squadra possono appartenere minimo

dieci bambini e massimo N.

32

1.2.Modello logico

Lo schema logico non è altro che la definizione delle tabelle relazionali. Tali tabelle si

ottengono a partire dallo schema concettuale. In maiuscolo viene indicato il nome della

tabella mentre tra parentesi tonde vengono indicati gli attributi, ovvero le colonne della

tabella. Sottolineato in ogni tabella è l’attributo id che è la chiave primaria che identifica

in modo univoco ogni istanza.

ACCOMPAGNATORE (id, cognome, nome, squadra, tel, email, qualifica, data)

GIOCATORE (id, cognome, nome, squadra, anno, data)

SQUADRA (id, nome, provincia, tel, email, data, urllogo, urlfoto)

2.Struttura del sistema e diagrammi flow chart

Per rappresentare in modo chiaro la struttura del sistema di iscrizione e le modalità

secondo cui agisce si è deciso di utilizzare i diagrammi flow chart, molto utili per

descrivere in maniera semplice e intuitiva le varie operazioni e decisioni che sono state

previste e implementate.

Per semplificare i diagrammi non vengono rappresentati tutti i controlli d’errore però è

doveroso ricordare che ogni qualvolta il sistema rileva un errore non consente di

proseguire al passo successivo ma ripresenta la pagina precedente indicando l’errore.

Quindi per ogni modulo si sarebbe dovuto rappresentare nei diagrammi la scelta “sono

presenti errori?” e le conseguenti due situazioni che si verificano.

Di seguito vengono presentati i diagrammi flow chart di tutti i casi d’uso individuati

corredati da una breve descrizione quando necessaria.

2.1.Caso d’uso UC1: Iscrizione squadre

Come si nota nel diagramma presente alla pagina successiva, per iscrivere una

squadra è possibile proseguire lungo due percorsi a seconda che si scelga una

squadra già presente nell’elenco oppure no. Nel primo caso è sufficiente compilare i

dati relativi al recapito telefonico e all’indirizzo e-mail, visto che il nome e la provincia di

provenienza della società rimangono invariati. Così facendo solo i due dati caricati

vengono aggiornati. Nel secondo caso invece vengono richiesti tutti i campi e una

nuova squadra viene aggiunta nel database.

33

2.2.Caso d’uso UC2: Iscrizione accompagnatori e giocatori

Questa parte dell’iscrizione risulta essere la più complessa come si può osservare

anche nel diagramma flow chart nella pagina successiva. L’iscrizione può seguire

diversi percorsi a seconda che si intenda o meno iscrivere un aiuto istruttore e a

seconda che siano presenti o meno bambini dell’edizione precedente che hanno un’età

che gli consente di ripartecipare al torneo.

35

2.3.Caso d’uso UC3: Caricamento del logo

La procedura per il caricamento del logo è analoga alla procedura per il caricamento

della foto. Il salvataggio dei dati comprende sia l’aggiunta di informazioni del database

sia il caricamento del file immagine nel server web.

36

2.4.Caso d’uso UC4: Caricamento della foto

2.5.Caso d’uso UC5: Squadre iscritte

37

2.6.Caso d’uso UC6: Elenco dettagli delle squadre iscritte

2.7.Caso d’uso UC7: Stato delle iscrizioni

38

2.8.Caso d’uso UC8: Impaginazione brochure

2.9.Caso d’uso UC9: Creazione referti

39

3.Dettagli implementazione

In questa sezione si dedica particolare importanza alla risoluzione dei problemi che

sono stati presentati nel capitolo uno. Per ognuno di essi viene ora mostrato il modo

con il quale è stato risolto ponendo attenzione solo alle linee di codice principali e

ritenute di maggior interesse.

• Durata della sessione

La durata di una sessione in PHP è di 1440 secondi, ovvero 24 minuti. Tale

durata è più che sufficiente a compilare le parti dell’iscrizione richieste dal

sistema ma durante la fase di test due utenti sono andati oltre il tempo massimo

previsto, portando quindi a termine l’iscrizione in modo errato. A titolo

precauzionale si è quindi scelto di aumentare la durata della sessione a 30

minuti utilizzando la semplice linea di codice riportata di seguito.

session_set_cookie_params() va inserito sempre prima dell’apertura della

sessione, ovvero prima di session_start(), e richiede un input in secondi,

impostato nel nostro caso a 10*30, ovvero a 1800 secondi, 30 minuti.

• Standardizzazione dei dati inseriti

Utilizzando semplici righe di codice si è potuto modificare i dati inseriti

dall’utente per renderli tutti standard in base alle esigenze. Si osservino per

esempio le seguenti righe di codice usate per standardizzare i dati compilati

dall’utente relativi alla squadra.

strtolower() trasforma in minuscole tutte le lettere della stringa, ucwords()

trasforma poi in maiuscola la prima lettera di ogni parola contenuta nella

stringa, e infine trim() elimina gli spazi bianchi all’inizio e alla fine della stringa.

In questo modo tutti i nomi delle squadre e delle province iniziano con la lettera

maiuscola e sono seguite da sole lettere minuscole e ogni spazio bianco inutile

prima o dopo viene eliminato.

40

Lo stesso procedimento, più semplificato, viene fatto per i numeri di telefono. In

questo caso infatti vengono semplicemente eliminati gli spazi bianchi prima e

dopo il numero.

Infine, per gli indirizzi e-mail, tutto viene ridotto a lettere minuscole, e come di

consueto, gli spazi bianchi vengono eliminati.

Questa procedura viene ripetuta per tutti i dati inseriti dall’utente in tutte le parti

dell’iscrizione.

• Controllo errori

Di sicuro uno degli aspetti chiave del sistema di iscrizione, sia per importanza

che per complessità realizzativa.

Tutti i dati inseriti dall’utente vengono raccolti nell’array $_SESSION[] fino al

momento in cui non vengono salvati nel database al termine della procedura.

A ogni pagina contenente un modulo corrisponde una pagina di controllo (non

visibile all’utente) che verifica i dati inseriti e in caso di errore ricarica la pagina

precedente evidenziando l’errore o gli errori presenti. Nel caso invece che tutti i

dati compilati siano corretti procede caricando la pagina successiva prevista.

Consideriamo come esempio per presentare la procedura l’iscrizione

dell’istruttore.

Il form che viene visualizzato è stato realizzato utilizzando le seguenti linee di

codice.

Come si può notare, oltre al tradizionale codice HTML utilizzato per la

visualizzazione di un form, sono presenti anche parti in PHP, ovvero gli errori

che vengono visualizzati quando l’utente non compila sezioni obbligatorie o

commette errori di digitazione. Tali parti vengono visualizzate solo quando il

41

valore di $_SESSION['err_cognomeistr'], o $_SESSION['err_nomeistr'], o

$_SESSION['err_telistr'], o $_SESSION['err_emailistr'] è impostato su true.

Per questo motivo, prima del form, sono state aggiunte le seguenti righe di

codice.

Nel dettaglio, il sistema verifica se durante la sessione attuale è già stato

salvato all’interno dell’array $_SESSION[] il cognome dell’istruttore, cioè

controlla se è la prima volta che la pagina viene visualizzata. Nel caso sia la

prima volta, tutti i valori vengono impostati su valore nullo e tutti i campi relativi

all’errore su false. In questo modo alla prima visualizzazione della pagina non

compare alcun errore.

Osserviamo ora la pagina che analizza i dati inseriti e controlla la presenza di

eventuali errori di compilazione.

Come si può notare i dati vengono inviati alla pagina successiva mediante il

metodo POST e dopo essere stati standardizzati vengono salvati all’interno

dell’array $_SESSION[].

Si passa poi al controllo degli errori vero e proprio: nel caso in cui il nome o il

cognome dell’istruttore oppure il campo relativo al recapito telefonico vengano

saltati, il sistema imposta in true il valore del campo relativo all’errore

42

corrispondente. Lo stesso accade se la stringa relativa all’indirizzo e-mail risulta

di lunghezza diversa da zero (quindi è stata inserita) e il carattere “@” non è

stato inserito.

Rimane solamente un’ultima scelta da implementare: a questo punto infatti si

deve valutare se procedere col passo successivo dell’iscrizione oppure

ricaricare la pagina precedente perché sono presenti degli errori.

Questa scelta viene fatta semplicemente tramite il codice seguente.

Fintanto che uno dei campi relativi all’errore risulta impostato su true il sistema

ripropone sempre la pagina precedente indicando l’errore del campo

corrispondente.

43

Tutti gli altri campi rimangono salvati correttamente nell’array $_SESSION[] e

precompilati nel form in modo che l’utente debba correggere solo il campo o i

campi che presentano errori.

• Iscrizione aiuto istruttore facoltativa

Questa problematica è stata risolta utilizzando un Java script, ed è l’unica volta

che si è utilizzato questo linguaggio in tutto il progetto.

All’utente viene concesso di spuntare o meno una casella a seconda che voglia

o meno iscrivere un aiuto istruttore. Nel caso la casella venga spuntata i campi

relativi all’aiuto istruttore si oscurano e non possono più essere compilati, e di

conseguenza i controlli d’errore su questi vengono saltati.

• Impaginazione del referto di gioco

Infine l’ultimo aspetto che si vuole presentare è relativo alla dimensione del

referto di gioco. Il referto non è altro che una tabella implementata utilizzando il

codice HTML i cui contenuti vengono inseriti tramite codice PHP mediante il

quale si vanno a prelevare i dati dal database.

Si è semplicemente impostata la larghezza della tabella sempre massima,

utilizzando la semplice riga presente alla pagina successiva.

44

Il numero delle righe invece varia, una per ogni giocatore iscritto. Quando si

procede alla stampa mediante un qualsiasi browser si può variare la

dimensione del referto in modo da farlo rientrare nei margini del foglio, ma la

larghezza rimarrà sempre la massima disponibile, mentre le righe varieranno di

altezza.

46

CAPITOLO 4

Casi d’uso sviluppati

47

1.Caso d’uso UC1: Iscrizione squadre

1. Il responsabile società inizia una nuova procedura di inserimento di una

squadra.

2. Il responsabile società seleziona il nome della sua squadra (se già presente

nell’elenco perché ha partecipato all’edizione precedente) oppure seleziona

“NUOVA SOCIETA’”.

3. Il responsabile società procede alla compilazione dei campi richiesti.

• Se si seleziona “NUOVA SOCIETA’”:

• Se si seleziona una società presente nell’elenco:

48




6. Il sistema invia un’e-mail che avvisa il webmaster che è avvenuta una nuova

iscrizione.

7. Il sistema invia un’e-mail che avvisa il responsabile società che l’iscrizione è

avvenuta con successo (nel caso il campo relativo all’indirizzo e-mail sia stato

compilato).

49

2.Caso d’uso UC2: Iscrizione accompagnatori e gioca tori

1. Il responsabile società inizia una nuova procedura di inserimento dati di



3. Il responsabile società procede alla compilazione dei campi richiesti

sull’istruttore minibasket e sull’aiuto istruttore minibasket (facoltativo).

• Se si decide di inserire i dati dell’aiuto istruttore:

50

• Se si decide di non inserire i dati dell’aiuto istruttore:

4. Il sistema, se presenti, mostra l’elenco dei bambini che hanno partecipato

all’edizione precedente e che possono essere re iscritti alla nuova edizione

(dipende dall’età dei bambini).

51

5. Il sistema mostra un modulo per inserire i dati relativi ai nuovi bambini

partecipanti.

52

6. Il sistema visualizza un riepilogo delle informazioni inserite ed è possibile

modificare i dati inseriti se necessario.




53

9. Il sistema invia un’e-mail che avvisa il webmaster che una società ha iscritto


10. Il sistema invia un’e-mail che avvisa gli istruttori che l’iscrizione è avvenuta con

successo (nel caso il campo relativo all’indirizzo e-mail degli istruttori sia stato

compilato).

54

3.Caso d’uso UC3: Caricamento del logo

1. Il responsabile società inizia una nuova procedura di inserimento del logo.


3. Il responsabile società seleziona il logo da caricare.

4. Il sistema procede al caricamento del logo e lo rende disponibile.

55


6. Il sistema invia un’e-mail che avvisa il webmaster che è stato caricato un nuovo

logo.

56

4. Caso d’uso UC4: Caricamento della foto

1. Il responsabile società inizia una nuova procedura di inserimento della foto.


3. Il responsabile società seleziona la foto da caricare.

4. Il sistema procede al caricamento della foto e la rende disponibile.

57


6. Il sistema invia un’e-mail che avvisa il webmaster che è stata caricata una

nuova foto.

58

5.Caso d’uso UC5: Squadre iscritte

1. Il webmaster accede alla pagina web relativa alla visualizzazione delle squadre

iscritte.

2. Visualizza tutte le squadre iscritte in ordine alfabetico.

6. Caso d’uso UC6: Elenco dettagli delle squadre is critte

1. Il webmaster accede alla pagina web relativa alla visualizzazione dei dettagli

delle squadre iscritte.

2. Sceglie l’anno di edizione del torneo di cui si vuole visualizzare l’elenco.

3. Visualizza i dettagli di tutte le squadre iscritte in ordine alfabetico e i loro dettagli

e l’elenco delle squadre provenienti da fuori regione e i loro dettagli.

59

7. Caso d’uso UC7: Stato delle iscrizioni

1. Il responsabile società accede alla pagina web relativa alla visualizzazione dello

stato delle iscrizioni.

2. Visualizza lo stato delle iscrizioni delle squadre iscritte in ordine alfabetico,

visualizza se il logo e la foto sono caricate, e se istruttori e giocatori sono iscritti.

8. Caso d’uso UC8: Impaginazione brochure

1. Il webmaster accede alla pagina web relativa all’impaginazione della brochure.


3. Visualizza i dati impaginati delle squadre elencate in ordine alfabetico.

60

9. Caso d’uso UC9: Creazione referti

1. Il webmaster accede alla pagina web relativa alla creazione dei referti.


3. Seleziona le due squadre contendenti e compila i campi richiesti.

61

4. Visualizza il referto di gara.

5. Stampa il referto di gara.

63

CAPITOLO 5

Testing

64

1.Periodo e modalità di test

Il sistema di iscrizione è stato messo in funzione nel mese di ottobre 2010 ed è rimasto

attivo fino al 15 novembre 2010, data prevista per la chiusura delle iscrizioni per

l’edizione 2011 del torneo.

Tutte le funzioni del progetto sono state attivate e testate regolarmente, fatta eccezione

per la creazione dei referti precompilati. In questo caso infatti abbiamo riscontrato un

problema non legato però al funzionamento delle pagine web e al codice

implementato, ma alla gestione dei bambini da parte delle società iscritte. Infatti si è

notato che l’elenco dei bambini iscritti non sempre corrisponde esattamente all’elenco

dei bambini effettivamente partecipanti. Non è quindi stato possibile usufruire dei referti

precompilati in automatico durante le gare del torneo nonostante dal punto di vista

funzionale non si sia riscontrato comunque nessun problema.

In generale il test è stato soddisfacente e non si sono riscontrati malfunzionamenti di

alcun genere.

Le 40 società partecipanti hanno usufruito di tutte le funzioni in modo agevole e senza

riscontrare errori durante le procedure. Nessun responsabile delle società ha richiesto

chiarimenti o aiuto sulle modalità di iscrizione.

2.Valutazione

Il sistema di iscrizione è risultato efficiente e funzionale come previsto, e tutti gli

obiettivi prefissati sono stati abbondantemente soddisfatti.

Il fatto che nessuna società abbia chiesto informazioni aggiuntive o richiesto assistenza

è sinonimo di un sistema semplice ed efficace, adatto ad ogni tipo di utente.

Il sistema ha agevolato notevolmente la gestione dei nominativi e dei recapiti,

velocizzando i tempi di ricerca dei dati e semplificando le operazioni di contatto con le

squadre.

La brochure è stata realizzata dal nostro grafico accedendo a tutte le informazioni

necessarie tramite la pagina web predisposta e ha potuto trovare tutti i dati necessari

ordinati e schematizzati, accessibili con un solo clic. Questo ha reso le operazioni di

disegno e progettazione della brochure immediate, consentendo un dimezzamento

delle ore di lavoro rispetto all’anno precedente, con un notevole risparmio economico

per l’organizzazione.

Al termine della manifestazione ogni società ha compilato un questionario relativo al

torneo ed è quindi stato possibile sondare anche l’opinione sul sistema di iscrizione.

Alla domanda relativa al sito internet e al sistema di iscrizione il 97% ha risposto che il

65

sistema è utile e semplifica le modalità di accreditamento, il 2% che non semplifica le

operazioni per aderire al torneo, l’1% ha risposto che risulta complesso da utilizzare.

3.Miglioramenti

Il sistema si iscrizione, nonostante le buone impressioni, non è esente da sviluppi

futuri.

Di seguito si riportano dei miglioramenti e delle estensioni che si intendono aggiungere

nei prossimi anni per rendere il progetto ancora più utile ed adatto alla manifestazione

in questione.

• Al momento attuale per effettuare l’iscrizione degli istruttori e dei

giocatori, o semplicemente per aggiungere un logo o una foto, è

sufficiente aver prima iscritto una squadra. Una volta effettuato quel

passo e scelto l’iscrizione desiderata, basta selezionare la squadra e

procedere. Di conseguenza chiunque può aggiungere informazioni

relative a un’altra squadra.

Si intende risolvere il problema inviando tramite e-mail al momento

dell’iscrizione della squadra una password che verrà richiesta nelle

iscrizioni successive per aggiungere istruttori, giocatori, foto e loghi.

• Un’altra funzione che si vuole modificare è il caricamento del logo e

della foto. Si è infatti notato durante il periodo di test che alcune società

dispongono di più loghi oppure intendono inviarci più di una foto. Il

sistema di iscrizione però nel caso in cui in una stessa edizione del

torneo una squadra carichi più di un logo o di una foto, sovrascrive quelli

precedenti e mantiene valido solo l’ultimo.

L’idea è di risolvere l’inconveniente comunicando tramite un messaggio

che il logo o la foto sono già stati caricati e che procedendo si

sovrascrive il precedente, oppure consentendo all’utente di scegliere se

aggiornare il file oppure di aggiungerne uno nuovo in alternativa. Questa

seconda soluzione richiede però un lavoro più complesso e più tempo,

si valuterà se ne vale la pena o meno.

• Un altro inconveniente che si è riscontrato durante il periodo di test

riguarda i formati con cui gli utenti hanno caricato le foto e i loghi. Il

sistema, per essere più flessibile possibile, al momento consente di

caricare file multimediali in qualsiasi formato voluto. Questo però ha

fatto si che qualche società ha caricato file di tipo *.doc (Microsoft Word)

66

all’interno dei quali poi erano salvati la foto o il logo, oppure ancora file

di tipo *.eml, ovvero e-mail, all’interno dei quali erano salvati foto e loghi.

Si intende risolvere il problema in modo molto semplice, andando cioè a

verificare il formato che si intende caricare e consentendo all’utente di

procedere solo se il formato è di tipo immagine. In tutti gli altri casi viene

visualizzato un messaggio di errore che informa l’utente del problema.

• Il torneo è cresciuto ed è diventato internazionale. Un miglioramento

risulta quindi evidente: la traduzione delle pagine web in altre lingue, in

particolare in inglese.

• Infine si intende aggiungere un’altra estensione legata alla crescita del

torneo. La manifestazione infatti apre il torneo anche a squadre

femminili. È quindi necessario prevedere nel form di iscrizione della

squadra la possibilità di indicare se si intende partecipare al torneo

dedicato ai bambini o alle bambine.

68

Conclusioni Il progetto ha visto la creazione di un sistema per la gestione delle iscrizioni di un

torneo utilizzando PHP come linguaggio di programmazione. Si è partiti da un’analisi

attenta delle problematiche per ricavarne i requisiti e le necessità e si è arrivati fino allo

sviluppo dei casi d’uso.

Lo studio delle caratteristiche è stato dapprima realizzato attraverso un’accurata

stesura dei casi d’uso utilizzando un template efficace e molto impiegato per descrivere

i casi d’uso riportati di seguito e individuati nella fase precedente. Iscrizione squadre,

un’interfaccia che permette all’utente di aggiungere la propria squadra alle partecipanti

del torneo; iscrizione accompagnatori e giocatori, che offre la possibilità all’utente di

iscrivere gli accompagnatori e i giocatori che partecipano alla manifestazione;

caricamento del logo, che consente l’upload del logo della squadra; caricamento della

foto, che analogamente al caso d’uso precedente, consente il caricamento della foto

della squadra; squadre iscritte, un’area che consente all’organizzazione di visualizzare

l’elenco e la provenienza delle squadre partecipanti; elenco dettagli delle squadre

iscritte, una sezione in cui è possibile visionare tutti i dettagli disponibili sulle squadre

iscritte; stato delle iscrizioni, un’interfaccia utilissima sia per gli utenti che per

l’organizzazione per monitorare l’avanzamento delle iscrizioni; impaginazione

brochure, area semplice e ordinata da cui prelevare i dati impaginati, raccolti durante le

iscrizioni; e infine creazione referti, sezione di fondamentale importanza per ottenere in

modo rapido i referti senza bisogno di doverli compilare manualmente.

L’analisi poi è proseguita con la definizione dell’architettura del database mediante la

progettazione concettuale e logica.

Individuate la struttura del sistema di iscrizione e le modalità secondo cui agisce

facendo largo uso dei diagrammi flow chart, noti i casi d’suo e la struttura del database,

si è infine passati alla scrittura del codice, ovvero all’implementazione del sistema vero

e proprio.

In questa tesi si è illustrato anche il funzionamento del sistema finale, sistema che

risolve i problemi individuati inizialmente, attraverso l’utilizzo di screenshot che

permettono di visualizzare come sono stati realizzati i diversi casi d’uso.

È stata creata un’applicazione ricca di strumenti per la gestione delle iscrizioni,

ben organizzata e strutturata in modo da risultare semplice da utilizzare ma efficace

allo stesso tempo. Un sistema usufruibile per qualunque tipo di torneo che veda la

partecipazione di squadre, un’applicazione solida e già ora sufficientemente articolata,

ma che è sicuramente espandibile e migliorabile.

69

Gli sviluppi futuri per l’applicazione potrebbero essere la traduzione in più lingue, la

possibilità di scelta tra torneo maschile o femminile, l’aumento della sicurezza

permettendo l’iscrizione di bambini, istruttori, e il caricamento di loghi e foto, solo ai

responsabili delle squadre stesse mediante uso di password, e il miglioramento del

sistema di upload dei file multimediali.

71

Bibliografia

[1] Mark Allen Weiss, “Data structures and problem solving using Java”, Addison-

Wesley.

[2] Ramez Elmasri, Shamkant B. Navathe, “Fundamentals of database system”.

[3] http://php.net

[4] http://www.html.it

UNIVERSITÀ DEGLI STUDI DI PADOVA -...

Documents

Transcript of UNIVERSITÀ DEGLI STUDI DI PADOVA -...