UNIVERSITÀ DEGLI STUDI DI PADOVA
DIPARTIMENTO DI MATEMATICA
CORSO DI LAUREA TRIENNALE IN INFORMATICA
TESI DI LAUREA
SVILUPPO DEL GIOCO GEISTER CON
L’AUSILIO DI WEB SERVICE
Relatore:
Candidato:
Prof. Claudio E. Palazzi
Luca Semenzato
Matricola: 540620 / SIN
Anno Accademico: 2011/2012
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
2
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
For long you live and high you fly
and smiles you'll give and tears you'll cry
and all your touch and all you see
is all your life will ever be.
Run, rabbit run.
Dig that hole, forget the sun,
And when at last the work is done
Don't sit down it's time to dig another one.
Pink Floyd – Breathe
3
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Un ringraziamento speciale al prof. Palazzi e al prof. Aiolli: grazie per tutto l’aiuto, le
indicazioni precise e la grande fiducia che avete riposto in me. Questo lavoro è stato
per me fonte di grande esperienza, e per questo vi sarò sempre grato.
4
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
SOMMARIO ...................................................................................................................................9
Capitolo 1. INTRODUZIONE ............................................................................................. 11
1.1 IL GIOCO ............................................................................................................................................................ 12
1.2 DOMINIO ATTUALE ..................................................................................................................................... 13
1.3 OBIETTIVI ........................................................................................................................................................ 14
Capitolo 2. TECNOLOGIE COINVOLTE .......................................................................... 17
2.1 WEB SERVICE ................................................................................................................................................. 17
2.2 APACHE AXIS 2 E TOMCAT....................................................................................................................... 22
2.3 JAVA .................................................................................................................................................................... 22
2.4 MySQL ................................................................................................................................................................ 23
2.5 ECLIPSE ............................................................................................................................................................. 23
2.6 ANDROID .......................................................................................................................................................... 24
2.7 KSOAP2 PER ANDROID .............................................................................................................................. 25
2.8 TORTOISE SVN ............................................................................................................................................... 25
Capitolo 3. ANALISI DEI REQUISITI............................................................................... 27
3.1 LISTA DEI REQUISITI .................................................................................................................................. 27
3.1.1 Obbligatori ............................................................................................................................................... 27
3.1.2 Desiderabili .............................................................................................................................................. 28
3.1.3 Opzionali ................................................................................................................................................... 28
3.2 DIAGRAMMI USE-CASE .............................................................................................................................. 29
3.2.1 USE-CASE A: ACCESSO ......................................................................................................................... 29
3.2.2 Use-case A.1: Registrazione ............................................................................................................... 29
3.2.3 Use-case A.2: Login ............................................................................................................................... 30
3.2.4 Use-case A.3: Credits............................................................................................................................. 31
3.2.5 Use-case A.4: Manuale ......................................................................................................................... 31
3.2.6 USE-CASE B: PROFILO ......................................................................................................................... 32
3.2.7 Use-case B.1: GESTIONE ANAGRAFICA ......................................................................................... 32
3.2.8 Use-case B.2: POLLING SFIDATO ..................................................................................................... 33
3.2.9 Use-case B.3: GESTIONE AMICI ........................................................................................................ 33
3.2.10 Use-case B.4: LANCIA SFIDA ........................................................................................................... 34
3.2.11 USE-CASE C: GESTIONE AMICI ...................................................................................................... 35
3.2.12 Use-case C.1: VISUALIZZA AMICI .................................................................................................. 35
3.2.13 Use-case C.2: INSERISCI NUOVO AMICO .................................................................................... 35
3.2.14 Use-case C.3: ELIMINA AMICO ....................................................................................................... 37
3.2.15 USE-CASE D: LANCIA SFIDA ........................................................................................................... 38
3.2.16 Use-case D.1: SFIDA UTENTE REGISTRATO ............................................................................. 38
3.2.17 Use-case D.2: SFIDA INTELLIGENZA ARTIFICIALE ............................................................... 38
3.2.18 USE-CASE E: GESTIONE SFIDA A UTENTE REGISTRATO ................................................... 40
3.2.19 Use-case E.1: CREA SFIDA ............................................................................................................... 40
3.2.20 Use-case E.2: ACCETTA SFIDA ....................................................................................................... 41
5
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.21 Use-case E.3: INSERISCI POSIZIONI INIZIALI .......................................................................... 41
3.2.22 Use-case E.4: VISUALIZZA POSIZIONI AVVERSARIO ............................................................. 42
3.2.23 Use-case E.5: INSERISCI MOSSE .................................................................................................... 43
3.2.24 Use-case E.6: VISUALIZZA MOSSE AVVERSARIO .................................................................... 43
3.2.25 Use-case E.7: CONTROLLO FINE SFIDA...................................................................................... 44
3.2.26 USE-CASE F: SFIDA INTELLIGENZA ARTIFICIALE ................................................................ 45
3.2.27 Use-case F.1: CREA SFIDA ................................................................................................................ 45
3.2.28 Use-case F.2: ACCETTA SFIDA IA .................................................................................................. 45
3.2.29 Use-case F.3: CREA SFIDA ................................................................................................................ 46
3.2.30 Use-case F.4: INSERISCI POSIZIONI IA ....................................................................................... 46
3.2.31 Use-case F.5: VISUALIZZA POSIZIONI AVVERSARIO ............................................................. 46
3.2.32 Use-case F.6: INSERISCI MOSSE .................................................................................................... 46
3.2.33 Use-case F.7: INSERISCI MOSSE IA .............................................................................................. 47
3.2.34 Use-case F.8: VISUALIZZA MOSSE AVVERSARIO .................................................................... 47
3.2.35 Use-case F.9: CONTROLLO FINE SFIDA ...................................................................................... 47
Capitolo 4. PROGETTAZIONE .......................................................................................... 49
4.1 DATABASE ....................................................................................................................................................... 51
4.1.1 utenti .......................................................................................................................................................... 52
4.1.2 sessioni ....................................................................................................................................................... 53
4.1.3 amici ........................................................................................................................................................... 53
4.1.4 partite ........................................................................................................................................................ 53
4.1.5 posizioni_iniziali .................................................................................................................................... 54
4.1.6 mosse .......................................................................................................................................................... 54
4.1.7 learners ..................................................................................................................................................... 54
4.1.8 rankers....................................................................................................................................................... 54
4.1.9 learners_rankers .................................................................................................................................... 55
4.1.10 profili_u_l_r ............................................................................................................................................ 55
4.1.11 log ............................................................................................................................................................. 55
4.2 WEB SERVICE - WSUtenti ......................................................................................................................... 56
4.3 WEB SERVICE - WSGame ......................................................................................................................... 57
4.4 WEB SERVICE - WSData ............................................................................................................................ 57
4.5 PROGETTAZIONE HARDWARE SERVIZI ........................................................................................... 58
4.6 PROGETTAZIONE SOFTWARE SERVIZI .............................................................................................. 59
4.7 AUTENTICAZIONE ........................................................................................................................................ 60
4.8 CLIENT ............................................................................................................................................................... 61
4.9 ALTRI MODULI COINVOLTI...................................................................................................................... 66
4.9.1 Stored Procedure ................................................................................................................................... 66
4.9.2 Algoritmi di Intelligenza Artificiale ............................................................................................... 66
Capitolo 5. SVILUPPO ......................................................................................................... 69
5.1 IMPLEMENTAZIONE WEB SERVICE..................................................................................................... 69
6
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.2 WSDATA – MySkeleton.java ..................................................................................................................... 72
5.2.1 Dichiarazione classe e metodi: ......................................................................................................... 72
5.2.2 Metodi principali: .................................................................................................................................. 73
5.3 WSUTENTI – MySkeleton.java................................................................................................................. 74
5.3.1 Dichiarazione classe e metodi: ......................................................................................................... 74
5.3.2 Metodi principali: .................................................................................................................................. 74
5.4 WSGAME – MySkeleton.java .................................................................................................................... 75
5.4.1 Dichiarazione classe e metodi: ......................................................................................................... 75
5.4.2 Metodi principali: .................................................................................................................................. 75
5.5 TABELLA ERRORI WEB SERVICE .......................................................................................................... 75
5.6 USO DI STUB NEI CLIENT ......................................................................................................................... 76
5.7 CLIENT ANDROID ......................................................................................................................................... 77
5.7.1 Package Handler ................................................................................................................................... 78
5.7.2 Package Exception ................................................................................................................................ 78
5.7.3 Package polling ...................................................................................................................................... 79
5.7.4 Package android .................................................................................................................................... 80
5.8 CLIENT SCREENSHOT ................................................................................................................................. 87
5.9 INTEGRAZIONE INTELLIGENZA ARTIFICIALE ............................................................................... 90
5.9.1 Learner ...................................................................................................................................................... 91
5.9.2 LearnerServer ......................................................................................................................................... 91
5.9.3 Ranker........................................................................................................................................................ 93
5.10 TEST ................................................................................................................................................................. 93
Capitolo 6. CONCLUSIONI ................................................................................................. 99
6.1 CONSIDERAZIONI PERSONALI ............................................................................................................... 99
6.2 SVILUPPI FUTURI ...................................................................................................................................... 100
Capitolo 7. PIANO DI LAVORO ..................................................................................... 101
Capitolo 8. GLOSSARIO ................................................................................................... 105
Capitolo 9. BIBLIOGRAFIA ............................................................................................ 109
9.1 Libri .................................................................................................................................................................. 109
9.2 Siti ..................................................................................................................................................................... 109
Capitolo 10. RINGRAZIAMENTI................................................................................... 111
7
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
8
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
SOMMARIO
Con il continuo progresso delle tecnologie e dei mezzi di comunicazione anche il
mondo dei giochi interattivi ha subito una forte spinta verso il cambiamento. Giochi
una volta ritenuti solo “da tavolo” hanno conosciuto una nuova evoluzione
significativa verso il loro riadattamento in chiave moderna, estendendo il concetto di
tavolo all’idea di cerchia virtuale di conoscenze, promossa da Internet e da un
approccio più social-oriented. Il ricorso al web ha permesso a tanti giochi classici di
vivere una nuova fase creativa, mantenendo immutate le regole di base, ma
proponendo un nuovo modo di associare il giocatore all’avversario, più rivolto alla
creazione di una rete di contatti da sfidare, potenzialmente più grande e
soddisfacente di un singolo tavolo da gioco. Il gioco Geister si inserisce in questo
contesto, forte della sua ottima giocabilità, ma povero di strategie di accesso alla rete
e di una piattaforma di sviluppo congruente alle aspettative di diffusione e raccolta
dei dati. Il progetto punta alla creazione di questa piattaforma, scegliendo gli
strumenti opportuni per gestire il gioco attraverso Internet, per assecondare il
maggior numero possibile di utenti inter-connessi, e per raccogliere dati utili allo
studio di algoritmi di Intelligenza Artificiale. L’intrinseco aspetto di gioco ad
informazione incompleta rende Geister molto accattivante per l’analisi del
comportamento tenuto dai giocatori, sempre spinti al raggiungimento della vittoria
attraverso l’uso di tattiche di dissimulazione e di mascheramento delle condizioni
delle proprie pedine. Il progetto pone le basi per un concreto utilizzo di algoritmi di
Intelligenza Artificiale precedentemente creati in altre esperienze di stage, che
sappiano catalogare il profilo di gioco di ogni giocatore, e ne stimino la disposizione
dei pezzi in campo, adottando la giusta contro-strategia, mossa dopo mossa. A
differenza dei giochi a informazione completa, Geister pone interessanti
interrogativi sull’efficacia nell’uso di algoritmi standard di Intelligenza Artificiale in
giochi ad alto grado di mascheramento. Grazie all’uso della piattaforma
implementata sarà possibile avere delle prime risposte in questo senso. Ciò che ci si
propone di fare in questo lavoro è di creare la piattaforma di gioco e raccolta dati, di
integrare gli algoritmi di profilazione e generazione delle mosse per l’Intelligenza
Artificiale precedentemente creati, e di dare una prima stima sul comportamento di
tali algoritmi.
9
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
10
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 1. INTRODUZIONE
Il progetto di sviluppo software del gioco Geister è nato con il duplice obiettivo di
creare una piattaforma interattiva accattivante e fruibile da tutti in maniera
semplice, e di raccogliere i dati di gioco di tutti i giocatori per avviare una fase di
studio sulle giocate mascherate, obiettivo molto importante dal punto di vista
scientifico. Infatti, mentre è relativamente semplice creare algoritmi di Intelligenza
Artificiale per giochi a informazione completa, diventa più complicato trattare quelli
a informazione incompleta (ovvero quelli in cui il giocatore non ha a disposizione
tutte le informazioni rispetto allo stato di gioco). In questi casi è interessante
studiare quali tecniche si possano adottare per far comportare il sistema in modo
simile a un giocatore reale includendo anche dissimulazione e mascheramento.
Un’idea è quella di usare gli algoritmi di SVM (Support Vector Machine) per profilare
i giocatori, e usare poi i profili ottenuti per generare le mosse dell’Intelligenza
Artificiale, adattando così la strategia di gioco alle caratteristiche emerse nell’analisi
del comportamento dei singoli giocatori. Questa strategia è già stata implementata
in altre esperienze di stage, ma per poter verificarne l’efficacia serve un gioco che
funga da banco di prova sperimentale per raccogliere dati su partite reali. Il gioco
inoltre deve essere facilmente usufruibile e accattivante in modo da attrarre
giocatori a partecipare a tante sessioni, così da avere a disposizione una quantità
sufficiente di dati tali da poter essere usati in uno studio scientifico. Di qui nasce
l’intrinseca necessità di un client facile da reperire, che sia attraente dal punto di
vista della giocabilità e che sappia incentivare la propria diffusione, in modo da
portare visibilità al progetto, ma soprattutto per stimolare la sfida, e quindi la
raccolta di dati preziosi. La scarsa diffusione del gioco da tavolo ha reso arduo il
compito di ampliare il bacino degli utenti che possono essere interessati. Per questo
motivo, il progetto segue l’idea di poggiare la propria architettura su una
piattaforma orientata al web, consentendo di creare dinamiche di rete sociale atte
agli scopi preposti. La diffusione del gioco online porterà alla sua crescita sul profilo
dei dati raccolti, grazie al passaparola, ma anche grazie alla possibilità di creare una
rete di amicizie virtuali con cui confrontarsi e sfidarsi. Questa peculiarità sarà una
novità per un gioco che altrimenti avrebbe necessariamente ospitato solo due
giocatori e pochi spettatori attorno ad un tavolo. La capacità di Internet di essere
prima di tutto rete di contatti offrirà nuova spinta verso la sua diffusione. Tutto
questo viaggerà di pari passo con lo studio delle partite effettuate, e la possibilità di
creare algoritmi di Intelligenza Artificiale sempre più raffinati e complessi, con cui
gli utenti potranno confrontarsi in assenza di amici online.
11
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
1.1 IL GIOCO
Geister, il cui titolo originale è “Geister - Die guten und die bösen Geister” (in inglese
Ghosts!, in italiano Fantasmi) è un gioco in scatola creato da Alex Randolph nel
1980.1 Ogni giocatore ha a disposizione 8 fantasmini, 4 dei quali con il pallino rosso
(fantasmi cattivi) e 4 con il pallino blu (fantasmi buoni) da disporre su una
scacchiera di 6x6 celle. L'identità in campo dei fantasmini dell'avversario è celata (i
pallini rossi e blu colorano solo il lato del fantasmino visibile al giocatore che lo
controlla) fino a che questi non vengono mangiati (ed eliminati). La disposizione
iniziale dei fantasmini avviene nelle otto caselle centrali delle prime due righe, ed è a
totale discrezione del giocatore, che potrà così prevedere la miglior strategia di
partenza per attuare il suo mascheramento (vedi Figura 1.1). Nel proprio turno un
giocatore deve muovere uno dei suoi fantasmini in una qualunque direzione (avanti,
dietro, destra, sinistra, tranne in diagonale). Se nell’effettuare la propria mossa
finisce su una casella occupata da un fantasma avversario, quest'ultimo viene
"mangiato" ed eliminato. Solo a questo punto viene smascherata l’identità del
fantasma, e si conosce l’esito della propria mangiata. Il gioco finisce in uno dei tre
modi seguenti:
-
quando si mangiano tutti i 4 fantasmi buoni (blu) dell’ avversario;
quando si costringe l’avversario a mangiare i 4 propri fantasmi cattivi
(rossi);
quando uno dei propri fantasmi buoni riesce ad "uscire" dalla plancia da uno
dei due cancelli di uscita, posti negli angoli in alto a sinistra e destra rispetto
alla propria visuale della scacchiera (e quindi posti come uscita “alle spalle”
dell’avversario).
Il terzo modo di uscita in particolare sfrutta l’idea di far passare ad uno dei propri
fantasmi buoni la “barriera” composta dai fantasmi dell’avversario, e richiama a
giochi ben più noti come la dama o gli scacchi. A differenza di questi ultimi però,
dove le pedine non sono mascherate, e le mosse sono sempre chiare e visibili, tutto,
in Geister, è basato su una serie di bluff, a partire dal posizionamento iniziale, fino
allo studio di una strategia di vittoria che sposti i fantasmi nella scacchiera in modo
da trarre in inganno l’avversario. Quanto più si riuscirà a mascherare l’identità dei
propri fantasmi, tante più probabilità di successo si avranno. Inoltre, la triplice
strategia di vittoria permessa, crea molte variabili di offuscamento aggiuntive,
spostando continuamente l’attenzione dell’avversario tra la geometria dei pezzi in
gioco e la loro identità (e quindi pericolosità).
1
2
Fonte: boardgamegeek.com
Vedi tesi di Amir Gharaba: “Reingegnerizzazione del software Geister ed interfacciamento
12
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 1.1: Geister: pannello gioco e posizionamento iniziale.
1.2 DOMINIO ATTUALE
Il tentativo di portare il gioco Geister su una piattaforma software ha già generato
un notevole percorso di successo. Allo stato attuale, il progetto ha coinvolto diversi
studenti che ne hanno aggiunto e raffinato il codice come attività di stage.
La versione attuale, su cui è possibile giocare da soli o con un compagno, è stata
sviluppata usando il linguaggio Java e ha prodotto un software standalone, giocabile
in pc con Java Virtual Machine installata, alternando il giocatore e l’avversario sulla
postazione stessa. La giocabilità è sufficiente agli scopi, ma non permette di
diffondere agevolmente il progetto ad altri utenti. Il passaparola derivante dalla
diffusione di questo tipo di gioco è prevedibilmente piuttosto scarso, e si limita ad
una rete di utenti reali interessati allo stesso, non dissimile dal contesto del gioco in
scatola prestato ad amici e parenti. Inoltre, i dati di gioco sono salvati in file di log
nel computer stesso, cosa che rende difficoltosa la raccolta di tutte le partite per
avviare la fase di studio dei profili. I vantaggi derivanti dall’aver creato il software
del gioco sono notevoli, ma vanno indirizzati verso una miglior strategia di
diffusione. Recentemente, una reingegnerizzazione del progetto2, ha portato ad una
buona piattaforma di partenza, che va però adattata all’uso via Internet e ad una
raccolta dati più efficace e meno dispersiva. La parte di gestione dei dati e di studio
di una efficace Intelligenza Artificiale è in continua evoluzione, ma stenta ad entrare
a pieno regime per mancanza di risultati effettivi con cui confrontarsi e su cui basare
un’adeguata strategia. E’ basilare quindi poter contare su una buona piattaforma di
gioco via Internet, impreziosita da meccanismi di incentivazione alla sfida e alla
diffusione del programma. Inoltre andranno poggiate le basi per una piattaforma
che sia sufficientemente consona agli scopi, che sopporti notevoli carichi di richieste
potenzialmente contemporanee, e sappia far fronte a tutte le dinamiche inerenti il
multitasking sia tra utenti che tra utenti e Intelligenza Artificiale.
Vedi tesi di Amir Gharaba: “Reingegnerizzazione del software Geister ed interfacciamento
con infrastruttura web”.
2
13
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 1.2 - Videata del programma standalone attuale.
In Figura 1.2 possiamo vedere una videata del programma attuale, nella sua
versione standalone scritta in linguaggio Java.
1.3 OBIETTIVI
Dopo aver definito l’importanza della diffusione del gioco e della conseguente
raccolta dei dati inerenti le partite giocate, è facile prevedere come gli obiettivi
preposti siano legati allo sviluppo della piattaforma adeguata. L’obiettivo primario è
quello di scegliere uno strumento atto alla gestione contemporanea di più richieste,
alla raccolta di dati in una basi di dati unica, e alla gestione separata di logica di
gioco e interfaccia con l’utente. Strettamente derivanti da ciò, emergono l’uso di un
sistema client/server che utilizzi Internet come mezzo di trasmissione, e la raccolta
dati tramite database relazionale. Le richieste server dovranno essere assecondate
con strumenti fortemente orientati al web, facili da chiamare con svariati tipi di
client e che possano garantire livelli sufficienti di performance e modularità. É
importante scegliere strumenti che diano il giusto compromesso tra facilità di
gestione e performance ottimali. I servizi che il lato server dovrà poter evadere
devono far fronte a tutte le richieste riguardanti:
-
le informazioni relativi a tutti i giocatori che si iscrivono tramite i client
(anagrafiche e relazioni di amicizie, disponibilità al gioco, ecc.) ;
-
le informazioni di gioco relative alle partite effettuate da coppie di giocatori
o da singoli giocatori contro profili di Intelligenza Artificiale;
-
la logica di gioco delle partite, gestendo i turni delle mosse e le mosse
possibili, registrando i valori e comunicando mosse ed eventi relativi al
gioco.
Sarà cura del lato server salvare tutti i dati in un opportuno database che sia
accessibile a futuri scopi di studio per la creazione di algoritmi di Intelligenza
Artificiale sempre più abili e complessi. Obiettivo auspicabile è quello di ottimizzare
le trasmissioni di dati via rete, riducendo al minimo lo spreco della banda di
14
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
comunicazione al server. Ulteriore obiettivo è quello di creare un client di base che
sia di moderna concezione, per poter “cavalcare” la diffusione di una piattaforma di
gaming utile agli scopi; a questo proposito viene già prefissata la creazione di un
client per dispositivi touch-screen in Android, vista la sua ampia diffusione
commerciale.
15
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
16
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 2. TECNOLOGIE COINVOLTE
Il problema primario da risolvere è la scelta di una adeguata piattaforma
client/server che possa fornire al tempo stesso affidabilità ed efficienza. La
soluzione inizialmente studiata prevedeva l’utilizzo di trasmissioni dirette
client/server tramite il protocollo TCP/IP. In particolare, si era pensato all’utilizzo
di una trasmissione via socket e la creazione di un protocollo di comunicazione
opportunamente studiato per gestire il dialogo tra client e server. Questa soluzione,
per quanto vantaggiosa, si prestava ad una serie di accurate e dispendiose analisi
per valutare il protocollo di comunicazione, e offriva lo svantaggio di una obbligata
negoziazione nella gestione della porta di trasmissione che avrebbe potuto essere
fonte di blocchi da parte di firewall interposti tra client e server. Si è deciso di
passare quindi ad una architettura che garantisse il miglior compromesso tra
velocità di trasmissione, gestione di molteplici chiamate contemporanee, capacità di
trasmissione senza vincoli di rete particolari. La necessità di spostare la
comunicazione ad un livello più alto, per non cadere in vincoli di porte e firewall, ha
diretto l’attenzione verso l’uso di protocolli che sfruttino pienamente il web. La
scelta è caduta ben presto sui web service.
2.1 WEB SERVICE
Secondo la definizione del W3C un web service è un sistema software progettato per
supportare l'interoperabilità tra diversi elaboratori su di una medesima rete. Un
web service è un servizio (una funzionalità, un calcolo, ecc.) messo a disposizione da
parte di un’applicazione sul web, che può essere utilizzato attraverso un colloquio
instaurato tra web service e consumer (Service Requestor). In questo senso, i web
service permettono l'interoperabilità tra diverse applicazioni software su diverse
piattaforme hardware e consentono di condividere e riutilizzare ciò che è
disponibile su altri siti senza conoscere la struttura interna del fornitore (Service
Provider). Tecnicamente un web service è un sistema software in grado di mettersi
al servizio di un’applicazione comunicando su di una medesima rete tramite un
protocollo applicativo (solitamente HTTP). Quindi un web service si presta a tutti
quegli scopi di interoperabilità attraverso la rete in un ambito “machine-tomachine”, consentendo alle applicazioni che vi si collegano di usufruire delle
funzioni che mette a disposizione. Grande vantaggio dei web service risiede proprio
nell’utilizzo di protocolli e standard definiti “aperti” e quindi sempre a disposizione
degli sviluppatori. La filosofia che sta alla base dei Web Service richiama
all’architettura SOA (Service-Oriented Architecture), che viene definita così dal
gruppo OASIS (Organizzazione per lo sviluppo di standard sull'informazione
strutturata): Un paradigma per l'organizzazione e l'utilizzazione delle risorse
distribuite che possono essere sotto il controllo di domini di proprietà differenti.
Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di
produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.
Seguendo questa filosofia i web service non solo espongono dei servizi
all’utilizzatore finale ma sono anche auto-descrittivi: sono in grado cioè di offrire sia
il servizio, che la descrizione delle sue caratteristiche, come i punti di accesso al
servizio, i protocolli utilizzati, le operazioni disponibili e l’elenco dei relativi
17
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
parametri, la tipologia di incapsulamento utilizzato, ecc. Tutto questo è gestito
tramite file WSDL, che vedremo tra poco.
Questa caratteristica dei web service è estremamente utile se si considera che
possono essere richiamati senza conoscerne l’effettiva architettura interna. Inoltre,
utilizzando l'UDDI3 (Universal Description, Discovery and Integration), un servizio di
directory disponibile sul Web dove gli interessati possono registrare e cercare
servizi web (Service Directory), sarà possibile cercare il servizio richiesto tra altri
messi a disposizione dal singolo “registro”. Inizialmente si pensava di gestire tutti i
descrittori di servizi istituendo una sola istituzione pubblica, l’Universal Business
Registry. Il progetto si è arenato e attualmente i servizi UDDI sono relegati ad un
ambiente Intranet come repository aziendale centralizzato dei WSDL, fornendo il
vantaggio al client di una maggior indipendenza dall’indirizzo del server.
Normalmente comunque il file WSDL è ospitato (e reso naturalmente disponibile
online) nel server che ospita i web service. In Figura 2.1 vediamo uno schema di
definizione dei web service secondo l’architettura SOA. In particolare possiamo
notare come i servizi vengano esposti da un Provider, che ne mette a disposizione
dell’UDDI la relativa descrizione. Il Requestor può recuperare la descrizione del
servizio cercato tramite l’UDDI stesso, e potrà successivamente connettersi al
Provider e ottenere le informazioni da esso, senza conoscere preventivamente
l’architettura alla base del Provider, né l’implementazione dei servizi esposti.
Figura 2.1 - Descrizione web service nella SOA.
La forte aspettativa di interoperabilità propria dei web service viene garantita
mediante l’uso di strategie quanto più possibili standard. La descrizione stessa dei
servizi esposti viene gestita tramite un linguaggio basato su XML (eXtensible Markup
Language): WSDL (Web Services Description Language). Questo linguaggio offre la
possibilità di creare un’interfaccia alla quale i richiedenti si collegano per scoprire
informazioni preziose del web service cercato. Il file di tipo WSDL può essere
ospitato dall’UDDI, ed è composto da:
- una parte astratta: descrive i messaggi che possono essere scambiati – e la
loro composizione per la gestione di operazioni;
- una parte concreta: per l’indirizzamento, mediante URI (URL o URN), e la
modalità di trasporto.
3
UDDI: http://uddi.xml.org
18
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Di seguito vediamo un estratto di file WSDL, relativo al servizio che gestisce la logica
di gioco, nominato WSGame:
<?XML VERSION="1.0" ENCODING="UTF-8"?>
<WSDL:DEFINITIONS XMLNS:WSDL="HTTP://SCHEMAS.XMLSOAP.ORG/WSDL/"
XMLNS:NS1="HTTP://ORG.APACHE.AXIS2/XSD" XMLNS:NS="HTTP://GAME"
XMLNS:WSAW="HTTP://WWW.W3.ORG/2006/05/ADDRESSING/WSDL"
XMLNS:HTTP="HTTP://SCHEMAS.XMLSOAP.ORG/WSDL/HTTP/"
XMLNS:XS="HTTP://WWW.W3.ORG/2001/XMLSCHEMA"
XMLNS:MIME="HTTP://SCHEMAS.XMLSOAP.ORG/WSDL/MIME/"
XMLNS:SOAP="HTTP://SCHEMAS.XMLSOAP.ORG/WSDL/SOAP/"
TARGETNAMESPACE="HTTP://GAME">
<WSDL:DOCUMENTATION>
WS GAME – SERVIZIO LOGICA DI GIOCO – VER. 1.0
</WSDL:DOCUMENTATION>
<WSDL:TYPES>
<XS:SCHEMA ATTRIBUTEFORMDEFAULT="QUALIFIED" ELEMENTFORMDEFAULT="QUALIFIED"
TARGETNAMESPACE="HTTP://GAME">
... OMISSIS ...
<XS:ELEMENT NAME="LISTAPOSIZIONIINIZIALI">
<XS:COMPLEXTYPE>
<XS:SEQUENCE>
<XS:ELEMENT MINOCCURS="0" NAME="IDTOKEN" NILLABLE="TRUE"
TYPE="XS:STRING"/>
<XS:ELEMENT MINOCCURS="0" NAME="USERNAME" NILLABLE="TRUE"
TYPE="XS:STRING"/>
<XS:ELEMENT MINOCCURS="0" NAME="NOMEPARTITA" NILLABLE="TRUE"
TYPE="XS:STRING"/>
</XS:SEQUENCE>
</XS:COMPLEXTYPE>
</XS:ELEMENT>
<XS:ELEMENT NAME="LISTAPOSIZIONIINIZIALIRESPONSE">
<XS:COMPLEXTYPE>
<XS:SEQUENCE>
<XS:ELEMENT MINOCCURS="0" NAME="RETURN" NILLABLE="TRUE"
TYPE="XS:STRING"/>
</XS:SEQUENCE>
</XS:COMPLEXTYPE>
</XS:ELEMENT>
... OMISSIS ...
<WSDL:MESSAGE NAME="LISTAPOSIZIONIINIZIALIREQUEST">
<WSDL:PART NAME="PARAMETERS" ELEMENT="NS:LISTAPOSIZIONIINIZIALI"/>
</WSDL:MESSAGE>
<WSDL:MESSAGE NAME="LISTAPOSIZIONIINIZIALIRESPONSE">
<WSDL:PART NAME="PARAMETERS" ELEMENT="NS:LISTAPOSIZIONIINIZIALIRESPONSE"/>
</WSDL:MESSAGE>
<WSDL:PORTTYPE NAME="WSGAMEPORTTYPE">
... OMISSIS ...
<WSDL:OPERATION NAME="LISTAPOSIZIONIINIZIALI">
<WSDL:INPUT MESSAGE="NS:LISTAPOSIZIONIINIZIALIREQUEST"
WSAW:ACTION="URN:LISTAPOSIZIONIINIZIALI"/>
<WSDL:OUTPUT MESSAGE="NS:LISTAPOSIZIONIINIZIALIRESPONSE"
WSAW:ACTION="URN:LISTAPOSIZIONIINIZIALIRESPONSE"/>
</WSDL:OPERATION>
</WSDL:PORTTYPE>
... OMISSIS ...
<WSDL:BINDING NAME="WSGAMESOAP11BINDING" TYPE="NS:WSGAMEPORTTYPE">
<SOAP:BINDING TRANSPORT="HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/HTTP" STYLE="DOCUMENT"/>
... OMISSIS ...
<WSDL:SERVICE NAME="WSGAME">
<WSDL:PORT NAME="WSGAMEHTTPSOAP11ENDPOINT" BINDING="NS:WSGAMESOAP11BINDING">
<SOAP:ADDRESS
LOCATION="HTTP://LOCALHOST:8080/WSGAME/SERVICES/WSGAME.WSGAMEHTTPSOAP11ENDPOINT/"/>
19
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
</WSDL:PORT>
</WSDL:SERVICE>
</WSDL:DEFINITIONS>
In questo estratto possiamo riconoscere le informazioni relative ad uno delle
possibili operazioni richiamabili (listaPosizioniIniziali), ai parametri da inviare e ai
relativi valori di ritorno, ai metodi di incapsulamento dei tipi (binding SOAP) al suo
indirizzo URL, ecc.
Dopo aver chiamato il servizio, la trasmissione delle comunicazioni tra client e
server avviene attraverso il protocollo HTTP, tramite l’invio di messaggi incapsulati
attraverso protocolli standard. Nel nostro caso è stato scelto l’invio di pacchetti
SOAP (Simple Object Access Protocol). SOAP può operare su differenti protocolli di
rete, ma HTTP è il più comunemente utilizzato e l'unico ad essere stato
standardizzato dal W3C. SOAP si basa sul metalinguaggio XML e la sua struttura
segue la configurazione Head-Body, analogamente ad HTML. Il segmento
obbligatorio Body trasporta il contenuto informativo e talora viene detto carico
utile, o payload. Questo deve seguire uno schema definito dal linguaggio XML
Schema. Il segmento opzionale Header contiene meta-informazioni come quelle che
riguardano il routing, la sicurezza, le transazioni e parametri per l'orchestration.
Vediamo un esempio di pacchetto SOAP realmente inviato al servizio di gestione
della logica di gioco, WSGame:
<V:ENVELOPE XMLNS:I="HTTP://WWW.W3.ORG/2001/XMLSCHEMA-INSTANCE"
XMLNS:D="HTTP://WWW.W3.ORG/2001/XMLSCHEMA"
XMLNS:C="HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENCODING/"
XMLNS:V="HTTP://SCHEMAS.XMLSOAP.ORG/SOAP/ENVELOPE/">
<V:HEADER />
<V:BODY>
<N0: LISTAPOSIZIONIINIZIALI XMLNS:N0="HTTP://GAME">
<IDTOKEN>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</IDTOKEN>
<USERNAME>LUCASEME</USERNAME>
<NOMEPARTITA>LUCASEME-PIPPO-XXXXX</NOMEPARTITA>
</N0: LISTAPOSIZIONIINIZIALI>
</V:BODY>
</V:ENVELOPE>
20
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
In Figura 2.2 possiamo vedere la struttura del pacchetto SOAP, mentre in Figura 2.3
possiamo vedere il riassunto dell’architettura SOA applicata ai web service, con i
relativi protocolli coinvolti e appena descritti.
Figura 2.2 - Struttura pacchetto SOAP.
Figura 2.3 - Web service e protocolli coinvolti.
L’utilizzo di SOAP come standard per i messaggi permette di raggiungere il livello
massimo di interoperabilità. Web service definiti con un linguaggio di
programmazione possono comunicare con client definiti non solo con un altro
linguaggio, ma potenzialmente residenti in architetture completamente differenti
dal server. Inoltre, la garanzia di utilizzo di uno standard non dà spazio a errori di
interpretazione dei dati, sia per la conversione dei tipi, sia per logica di invio. In
Figura 2.4 è possibile vedere come i messaggi vengano incapsulati e trasportati via
rete attraverso lo scambio di messaggi SOAP. Il Requestor e il Provider ignorano le
reciproche implementazioni, ma raggiungono un efficace livello di comunicazione
grazie all’uso di questo standard.
Figura 2.4 - Incapsulamento e trasmissione con SOAP.
21
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
2.2 APACHE AXIS 2 E TOMCAT
Nelle intenzioni di IBM, che per prima propose nel 2000 il modello WSDL come
linguaggio di interfaccia per la descrizione dei web service, c’era la volontà di
utilizzare un sistema basato su XML che fosse rapidamente diffuso e accettato da
tutti. Il W3C lo inserì successivamente tra gli standard di riferimento, ma quello che
in teoria doveva essere un documento creato in un formato leggibile e facilmente
modificabile dall’uomo, divenne nella pratica piuttosto verboso e complesso, tanto
che attualmente la prassi consigliata è di approcciare alla generazione di questo file
attraverso l’uso di tool specificamente costruiti.
Uno di questi tool è Axis 2, distribuito da Apache Software Foundation, erede del
progetto Apache Axis SOAP. Axis 2 è un tool completo di creazione, gestione e
utilizzo di web service. Si utilizza via riga di comando e permette di generare un web
service partendo dalla definizione (classe o interfaccia) delle operazioni da esporre.
Recentemente Axis 2 è stato integrato come plugin dell’IDE di sviluppo Eclipse,
rendendo più sicura e facile la gestione delle varie operazioni.
Nonostante l’implementazione di Axis 2 fornisca librerie anche per il linguaggio C, la
scelta fatta è stata quella di rimanere in un ambiente consono al linguaggio utilizzato
nelle precedenti esperienze di stage, ponendo così le basi per un eventuale riutilizzo
del codice già prodotto. La scelta è ricaduta quindi su Axis2/Java, utilizzato
all’interno di Eclipse come plugin. Il prodotto finale del lavoro del tool è composto
da una Web Application che ospita i web service all’interno di un servlet container.
Quest’ultimo è appunto Apache Tomcat, scelta pressoché obbligata dal contesto, e
altamente consigliata da Apache Software Foundation stessa.
2.3 JAVA
Java è un linguaggio di programmazione orientato agli oggetti, creato da Sun
Microsystems nel 1995. Attualmente il linguaggio è mantenuto e gestito da Oracle.
La sintassi è simile al C++, ma con una filosofia completamente orientata agli oggetti.
La sua ampia diffusione è dovuta ad una relativa semplicità d’uso, grazie a scelte
progettuali atte a facilitare il lavoro del programmatore, e ad una politica di
creazione di una ampia libreria di funzioni che permettano di scrivere programmi
trasferibili in grado di scavalcare i sistemi operativi proprietari. La scelta di Java
come linguaggio è stata condizionata dal codice finora prodotto per il progetto di
ingegnerizzazione del gioco Geister nelle precedenti esperienze di stage fatte da altri
studenti. In un’ottica di riuso del codice, è stato naturale proseguire il percorso
indicato. La scelta è stata poi confermata in sedi di analisi dell’architettura, avendo
trovato validi strumenti di contorno, tutti operanti in ambiente affine al linguaggio
Java e agli eseguibile con esso generati.
22
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
2.4 MYSQL
MySQL è un RDBMS (Relational Data Base Management System) ovvero un Sistema
per la Gestione di Basi Dati Relazionali. Come recita la home page del sito web
ufficiale4 :“Il database MySQL® è diventato il database open source più conosciuto al
mondo grazie a prestazioni veloci, elevata affidabilità e facilità d'uso”. Al di là di facili
auto-sponsorizzazioni, la facile reperibilità di questo database, in abbinata con le
ottime performance di lavoro, e la possibilità di gestire praticamente qualsiasi tipo
di realizzazione di base di dati, ne hanno fatto uno strumento eccezionale per la
raccolta di dati in database. Inoltre, MySQL, presentato con questo nome dal 1996, è
stato rilevato da Sun Microsystem nel 2008, ed è ora mantenuto e gestito da Oracle.
Come è facile intuire, è perfettamente integrato in tutti i pacchetti sviluppati prima
da Sun e poi da Oracle, e questo l’ha reso lo strumento perfetto per lo sviluppo di
lavori che coinvolgano Java. Inoltre, grazie alla stretta collaborazione con strumenti
per lo sviluppo di applicazioni web, MySQL è la scelta migliore per la raccolta dei
dati del progetto. L’interfacciamento con il database sarà reso possibile grazie ai
Driver messi a disposizione da MySQL per Java (mysql-connector-java-5.1.7). In
particolare la connessione avviene tramite l’utilizzo della libreria JDBC (Java
DataBase Connectivity), una API che consente ad un qualsiasi programma scritto in
java di accedere ad un qualsiasi DBMS (JDBC è simile a ODBC, JDBC è specifico per i
programmi scritti in java mentre ODBC si può usare indipendentemente dal
linguaggio utilizzato).
2.5 ECLIPSE
Eclipse è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma.
Eclipse può essere utilizzato per la produzione di software di vario genere, si passa
infatti da un completo IDE per il linguaggio Java (JDT, "Java Development Tools") a un
ambiente di sviluppo per il linguaggio C++ (CDT, "C/C++ Development Tools") e a
plug-in che permettono di gestire XML, Javascript, PHP e persino di progettare
graficamente una GUI per un'applicazione JAVA (Eclipse VE, "Visual Editor"),
rendendo di fatto Eclipse un ambiente RAD (Rapid application development). Il
programma è scritto in linguaggio Java, ma anziché basare la sua GUI su Swing, il
toolkit grafico di Sun Microsystems, si appoggia a SWT, librerie di nuova concezione
che conferiscono ad Eclipse un'elevata reattività. La piattaforma di sviluppo è
incentrata sull'uso di plug-in, delle componenti software ideate per uno specifico
scopo, per esempio la generazione di diagrammi UML, ed in effetti tutta la
piattaforma è un insieme di plug-in, versione base compresa, e chiunque può
sviluppare e modificare i vari plug-in. Nella versione base è possibile programmare
in Java, usufruendo di comode funzioni di aiuto quali: completamento automatico
(“Code completion”), suggerimento dei tipi di parametri dei metodi, possibilità di
accesso diretto a CVS e riscrittura automatica del codice (funzionalità questa detta di
Refactoring) in caso di cambiamenti nelle classi. Ad Eclipse è stato installato
successivamente il plugin Axis 2 – Code Generator, sviluppato appositamente per
aiutare nella generazione del file WSDL a partire da una classe scritta in JAVA.
4
www.mysql.com
23
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
2.6 ANDROID
Per quanto riguarda il client, la scelta è stata presa in fase preliminare con la
richiesta di sviluppo su ambiente Android. Android è un sistema operativo per
dispositivi mobili costituito da uno stack software che include un sistema operativo
di base, i middleware per le comunicazioni e le applicazioni di base. Ha avuto
successo perché alcune versioni sono state open source e perché è basato su kernel
Linux. La piattaforma usa il database SQLite, la libreria dedicata SGL per la grafica
bidimensionale e supporta lo standard OpenGL ES 2.0 per la grafica tridimensionale.
Le applicazioni vengono eseguite tramite la Dalvik virtual machine, una macchina
virtuale adattata per l'uso su dispositivi mobili. È ottimizzata per sfruttare la poca
memoria presente nei dispositivi mobili, consente di far girare diverse istanze della
macchina virtuale contemporaneamente e nasconde al sistema operativo
sottostante la gestione della memoria e dei thread. Dalvik è spesso associato alla
Macchina virtuale Java, perché le librerie utilizzate sono richiamabili in linguaggio
Java, ma il bytecode con cui lavora non è Java. Altre differenze con la JVM
tradizionale sono la diversa gestione delle eccezioni. Dalvik non esegue, come la Java
Virtual Machine, byte code standard, ma il linguaggio DEX (Dalvik EXecutable).
Eclipse integra completamente i tool di sviluppo per Android. Con l’Android SDK ed
Eclipse sembrerà di utilizzare la regolare Java Virtual Machine perché l’ambiente di
sviluppo provvede alla generazione del codice DEX, ri-compilando il byte code che a
sua volta è frutto di una compilazione Java.
Figura 2.5 - Architettura Android.
24
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
2.7 KSOAP2 PER ANDROID
A causa delle differenze strutturali tra Java Virtual Machine e Dalvik, non è possibile
utilizzare il codice generato da Axis 2 per le chiamate ai web service dal client
Android. In particolare, le classi generate da Axis 2, e utilizzabili perfettamente in
ambiente Java (infatti saranno comunque usate per le chiamate interne tra web
service e per i test effettuati a lato server), utilizzano classi di gestione delle
interruzioni non incluse in Android SDK e non utilizzabili in alcun modo. Per questo
motivo si è dovuto cercare una libreria opportuna per l’interfacciamento di Android
con i web service esposti. Nonostante il disguido, questa scelta si è rivelata utile per
esprimere le potenzialità di interoperabilità dell’architettura scelta, che si è adattata
perfettamente alle esigenze iniziali. La scelta della libreria è ricaduta su KSOAP 2, un
progetto open - source, esterno alle librerie standard di Android, che comunque non
offre alcuna soluzione nativa. KSOAP2 deriva dal progetto originale KSOAP, una
libreria SOAP per client web service utile per prodotti Java come Applet o
applicazioni J2ME (CLDC / CDC / MIDP). KSOAP 2 è stato completamente riscritto
sulla base degli errori trovati su KSOAP 1.x, e adattato per l’uso di in dispositivi
moderni, compreso Android.
2.8 TORTOISE SVN
Tortoise SVN è un client per Subversion, implementato come estensione della shell
di Microsoft Windows. Si tratta di un software gratuito rilasciato sotto la GNU
(General Public License). Subversion è un sistema di controllo del versionamento dei
file, nato nel 2000 grazie a CollabNet Inc. ed utilizzato per mantenere versioni
correnti e storiche di file come codici sorgenti, pagine web e documentazione.
Subversion può essere utilizzato in un file server proprietario o ospitato in un
servizio gratuito di project hosting, come ProjectLocker5, utilizzato in questo
progetto.
5
www.projectlocker.com
25
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
26
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 3. ANALISI DEI REQUISITI
Dopo una prima fase di studio del progetto e del dominio attuale, sono stati
individuati diversi requisiti. I requisiti sono stati suddivisi in varie classi a seconda
della piattaforma di appartenenza (client, server o entrambi) e della priorità dei
requisiti stessi. Sono stati individuati pertanto le seguenti categorie di requisiti:
Obbligatori: requisiti che sono fondamentali per il successo del progetto.
Comprendono le richieste esplicite del committente e tutti i requisiti impliciti che
emergono dall'analisi e che sono necessari al soddisfacimento delle attese del
cliente. Vengono indicati con le iniziali “Ob”.
Desiderabili: requisiti richiesti dal committente che non compromettono le
funzionalità del programma in caso di loro assenza. Ogni requisito desiderabile
aggiunge valore al prodotto. Vengono indicati con le iniziali “De”.
Opzionali: requisiti relativamente utili, richiesti o emersi durante l’analisi,
aggiungono nuove caratteristiche al prodotto, anche se non sono necessari. Dettano
una linea per sviluppi futuri, ma sono totalmente contrattabili. Vengono indicati con
le iniziali “Op”.
Ogni requisito viene identificato dalle iniziali della classe e da un numero intero
progressivo. La coppia “iniziale – numero” rende univoco il requisito. Accanto alla
descrizione del requisito viene esplicitato per chiarezza il dominio della piattaforma
di appartenenza (client, server, client/server per entrambi)
3.1 LISTA DEI REQUISITI
Vediamo ora la lista dei requisiti individuati:
3.1.1 OBBLIGATORI
Ob01Ob02Ob03Ob04Ob05Ob06Ob07Ob08Ob09Ob10Ob11-
Studio dei servizi da esporre come web service (server);
Creazione di un client sviluppato per ambiente Android (client);
Raccolta dati relativi ad utenti, partite e log in database (server);
Gestione della logica di gioco nel server e risposta alle richieste di mossa del
client (client/server);
Visualizzare schermata di presentazione all’avvio della partita (client);
Possibilità di login o creazione nuovo utente (client/server);
Possibilità di sfidare gli amici (client);
Mascheramento dei fantasmi avversari durante il match (client);
Visualizzazione delle mosse permesse per il fantasma scelto (client);
Visualizzazione dei fantasmi mangiati e relativo tipo (client);
Presenza del manuale per spiegare il funzionamento del gioco (client);
27
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.1.2 DESIDERABILI
De01- Presenza di una breve sezione di credits con storia e sviluppi del gioco
(client);
De02- Possibilità di scelta dell’avversario tra umano e IA (client);
De03- Possibilità di sfidare qualsiasi utente connesso (client);
De04- Presenza di una pagina profilo con amici e statistiche (client);
3.1.3 OPZIONALI
Op01- Possibilità di richiedere pareggio all’avversario (client);
Op02- Possibilità di accettare o rifiutare sfida (client);
Op03- Gestione di opportuni time-out per la chiusura della mossa o della partita
(client/server);
Op04- Suggerimenti di gioco per utente umano da IA (client/server);
Op05- Visualizzazione di un indicatore di attesa mossa dell’avversario (client);
Op06- Visualizzazione del countdown del timer per la mossa (client);
Op07- Visualizzazione a fine partita di una schermata riassuntiva dei risultati
(client);
Op08- Studio di una strategia di incentivo al gioco (client/server);
Op09- Creazione di un client con linguaggio a scelta, ma diverso da Android (client);
28
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2 DIAGRAMMI USE-CASE
Di seguito sono esposti i principali diagrammi use-case per una miglior
comprensione delle dinamiche intercorse tra il client e il server.
Nei diagrammi sono presenti le seguenti tipologie di attori:
-
Utente generico: utente che accede al software client Geister ma non effettua
la login, e quindi non è identificato dal sistema;
Utente registrato: utente che accede al software client Geister ed effettua con
successo la login;
Server: entità astratta che identifica in maniera logica il Server che gestisce
lo logica di gioco, la raccolta e distribuzione dei dati anagrafici e delle partite.
3.2.1 USE-CASE A: ACCESSO
3.2.2 USE-CASE A.1: REGISTRAZIONE
Attori coinvolti:
- Utente generico
- Server
Descrizione:
Illustra la registrazione di un nuovo utente per poter accesso al sistema di gioco.
Pre-condizioni:
L’utente generico ha installato e avviato Geister su dispositivo Android.
Flusso base di eventi:
- L’utente generico inserisce i propri dati personali per la registrazione al
sistema;
- Il client fa un primo controllo sintattico dei dati inseriti per controllare se ve
ne sono di mancanti e/o non corretti.
29
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
Il server controlla se i dati sono corretti (ed univoci per e-mail e username),
quindi li salva nel database.
Flusso alternativo di eventi:
- Il client trova errori sintattici o dati obbligatori mancanti, e manda un avviso
di errore.
- Il server restituisce un messaggio d’errore se i dati inseriti non sono
accettabili, o se è intercorso un problema di connessione;
- Dopo la visualizzazione del messaggio di errore, il client dà la possibilità di
correggere gli errori e ritentare il salvataggio.
Post-condizioni:
L’utente generico è registrato e può accedere al sistema.
3.2.3 USE-CASE A.2: LOGIN
Attori coinvolti:
- Utente generico
- Server
Descrizione:
Illustra l’accesso al proprio account personale tramite identificazione con username
e password.
Pre-condizioni:
L’utente generico ha installato e avviato Geister su dispositivo Android. L’utente è in
possesso di una login (coppia username + password) valida.
Flusso base di eventi:
- L’utente generico inserisce i propri username e password per l’accesso al
sistema;
- Il server controlla se i dati sono corretti, quindi restituisce la validazione del
processo di login, fornendo un gettone (token) univoco per l’accesso al
profilo dell’utente e alle altre funzioni del gioco.
Flusso alternativo di eventi:
- Il server restituisce un messaggio d’errore se i dati inseriti non trovano
riscontro nel database degli utenti , o se è intercorso un problema di
connessione;
- Dopo la visualizzazione del messaggio di errore, il client dà la possibilità di
correggere gli errori e ritentare la login.
Post-condizioni:
L’utente generico accede al proprio profilo e quindi alle altre funzioni del sistema.
30
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.4 USE-CASE A.3: CREDITS
Attori coinvolti:
- Utente generico
Descrizione:
Illustra l’accesso alla sezione Credits del client.
Pre-condizioni:
L’utente generico ha installato e avviato Geister su dispositivo Android.
Flusso base di eventi:
L’utente generico clicca sul bottone “Credits” e accede alla sezione;
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente generico accede alla sezione Credits.
3.2.5 USE-CASE A.4: MANUALE
Attori coinvolti:
- Utente generico
Descrizione:
Illustra l’accesso alla sezione Manuale del client.
Pre-condizioni:
L’utente generico ha installato e avviato Geister su dispositivo Android.
Flusso base di eventi:
L’utente generico clicca sul bottone “Manuale” e accede alla sezione dove troverà un
manuale d’uso del client step-by-step;
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente generico accede alla sezione Manuale.
31
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.6 USE-CASE B: PROFILO
3.2.7 USE-CASE B.1: GESTIONE ANAGRAFICA
Attori coinvolti:
- Utente registrato
- Server
Descrizione:
Illustra l’ingresso da parte dell’utente registrato nella sezione di gestione dei dati
anagrafici .
Pre-condizioni:
L’utente registrato ha effettuato correttamente la login ed è entrato nel proprio
profilo.
Flusso base di eventi:
- L’utente registrato visualizza i propri dati anagrafici, inseriti in fase di
registrazione;
- L’utente può modificare alcuni dati che lo riguardano.
- L’utente salva le modifiche.
- Il Client esegue un primo controllo di correttezza dei dati inseriti.
- Il server controlla se i dati sono corretti, quindi li salva nel database.
Flusso alternativo di eventi:
- Il client trova errori sintattici, e manda un avviso di errore.
- Il server restituisce un messaggio d’errore se i dati inseriti non sono
accettabili, o se è intercorso un problema di connessione;
- Dopo la visualizzazione del messaggio di errore, il client dà la possibilità di
correggere gli errori e ritentare il salvataggio.
Post-condizioni:
L’utente registrato ha visualizzato e/o modificato correttamente i propri dati
anagrafici.
32
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.8 USE-CASE B.2: POLLING SFIDATO
Attori coinvolti:
- Utente registrato
- Server
Descrizione:
Illustra il controllo dello stato di sfidato da parte dell’utente registrato, con chiamate
temporizzate al server.
Pre-condizioni:
L’utente registrato ha effettuato correttamente la login ed è entrato nel proprio
profilo.
Flusso base di eventi:
L’utente registrato, tramite il client di gioco, interroga il server a intervalli di tempo
regolari per sapere se qualcuno richiede di sfidarlo;
Flusso alternativo di eventi:
Il processo di richiesta viene interrotto per chiusura del client o per fine dei termini
temporali di controllo.
Post-condizioni:
L’utente sa se è stato sfidato da qualcuno o no.
3.2.9 USE-CASE B.3: GESTIONE AMICI
Attori coinvolti:
- Utente registrato
Descrizione:
Illustra la gestione dell’elenco degli amici dell’utente registrato, con possibilità di
inserimento, ricerca e cancellazione.
Pre-condizioni:
L’utente registrato ha effettuato correttamente la login ed è entrato nel proprio
profilo.
Flusso base di eventi:
L’utente registrato può gestire le relazioni di amicizia con altri utenti registrati.
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente registrato ha gestito le relazioni di amicizia con altri utenti registrati.
33
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.10 USE-CASE B.4: LANCIA SFIDA
Attori coinvolti:
- Utente registrato
Descrizione:
Illustra il lancio di una sfida da parte dell’utente.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo;
- L’utente ha selezionato un utente amico da sfidare.
Flusso base di eventi:
- L’utente sfida l’amico;
- L’utente entra nella schermata di gioco.
Flusso alternativo di eventi:
- L’utente amico non è online e la richiesta di sfida viene annullata.
Post-condizioni:
L’utente registrato è nella schermata di gioco e può giocare con l’avversario.
34
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.11 USE-CASE C: GESTIONE AMICI
3.2.12 USE-CASE C.1: VISUALIZZA AMICI
Attori coinvolti:
- Utente registrato
- Server
Descrizione:
Illustra il processo di visualizzazione da parte dell’utente, della sua lista di amici.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo;
- L’utente ha richiesto l’elenco degli amici.
Flusso base di eventi:
- L’utente registrato chiede l’elenco dei suoi amici al Server.
- Il Server invia l’elenco richiesto.
Flusso alternativo di eventi:
Il Server non trova alcuna relazione di amicizia tra l’utente registrato e altri utenti, e
invia una lista vuota.
Post-condizioni:
L’utente registrato visiona l’elenco dei suoi amici.
3.2.13 USE-CASE C.2: INSERISCI NUOVO AMICO
Attori coinvolti:
- Utente registrato
- Server
Descrizione:
Illustra il processo di inserimento da parte dell’utente di un nuovo amico.
Pre-condizioni:
35
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
L’utente ha richiesto di inserire una nuova relazione di amicizia con un altro
utente.
L’utente richiesto esiste come utente già registrato.
Flusso base di eventi:
- L’utente registrato chiede l’inserimento del nuovo amico;
- Il Server controlla l’esistenza dell’amico;
- Il Server controlla che non esistano eventuali relazioni di amicizia tra i due
utenti;
- Il Server registra la nuova relazione di amicizia e comunica l’avvenuto
inserimento.
Flusso alternativo di eventi:
- Il Server non trova nessun utente con le informazioni fornite dall’utente.
- Il Server trova una precedente relazione tra i due utenti.
Post-condizioni:
L’utente registrato ha una nuova relazione di amicizia con un altro utente.
36
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.14 USE-CASE C.3: ELIMINA AMICO
Attori coinvolti:
- Utente registrato
- Server
Descrizione:
Illustra il processo di eliminazione da parte dell’utente registrato di una relazione di
amicizia con un altro utente.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
- L’utente registrato ha richiesto di eliminare una relazione di amicizia con un
altro utente.
- L’utente richiesto esiste come utente già registrato.
Flusso base di eventi:
- L’utente registrato chiede l’eliminazione dell’utente dalla lista degli amici;
- Il Server controlla l’esistenza dell’amico;
- Il Server controlla l’esistenza della relazione di amicizia tra i due utenti;
- Il Server elimina la relazione di amicizia e comunica il risultato positivo
dell’operazione.
Flusso alternativo di eventi:
- Il Server non trova nessun utente con le informazioni fornite dall’utente.
- Il Server non trova una precedente relazione tra i due utenti.
Post-condizioni:
L’utente registrato eliminato la relazione di amicizia con un altro utente.
37
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.15 USE-CASE D: LANCIA SFIDA
3.2.16 USE-CASE D.1: SFIDA UTENTE REGISTRATO
Attori coinvolti:
- Utente registrato
Descrizione:
Illustra il processo di sfida ad un altro utente registrato.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
- L’utente registrato ha deciso di sfidare un altro utente registrato.
Flusso base di eventi:
- L’utente registrato chiede la creazione della sfida con un altro utente
registrato, opportunamente scelto;
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente registrato ha generato una richiesta di sfida con un altro utente registrato.
3.2.17 USE-CASE D.2: SFIDA INTELLIGENZA ARTIFICIALE
Attori coinvolti:
- Utente registrato
Descrizione:
Illustra il processo di sfida all’Intelligenza Artificiale, sia essa espressione di un
profilo di un utente registrato, o di un profilo astratto.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
- L’utente registrato ha deciso di sfidare l’Intelligenza Artificiale.
38
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Flusso base di eventi:
- L’utente registrato chiede la creazione della sfida con l’Intelligenza
Artificiale, espressione di un profilo di un utente registrato, o di un profilo
astratto;
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente registrato ha generato una richiesta di sfida con l’Intelligenza Artificiale.
39
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.18 USE-CASE E: GESTIONE SFIDA A UTENTE REGISTRATO
3.2.19 USE-CASE E.1: CREA SFIDA
Attori coinvolti:
- Utente registrato 1: da considerare come l’utente che lancia la sfida, o utente
sfidante.
- Server
Descrizione:
Illustra il processo di creazione della sfida, con invio di partecipanti e dati ausiliari al
Server e quindi al database.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
- L’utente registrato ha scelto chi sfidare e invia la richiesta di nuova sfida al
Server.
Flusso base di eventi:
- L’utente sfidante chiede la creazione della sfida al Server;
- Il Server verifica che non esista già una sfida ancora attiva tra i due giocatori;
- Il Server salva i dati iniziali di sfida nel database e crea la sfida;
- L’utente sfidante ottiene la conferma di creazione della sfida e attende
risposta dall’utente sfidato.
Flusso alternativo di eventi:
40
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Il Server trova una precedente partita attiva tra i due sfidanti (anche con ruoli
sfidante/sfidato invertiti) e annulla la creazione della sfida inviata.
Post-condizioni:
La partita tra i due giocatori è creata. L’utente sfidante rimane in attesa di risposta
dall’utente sfidato, che a sua volta ora è in grado di vedere la sfida generata e
decidere se accettare o meno.
3.2.20 USE-CASE E.2: ACCETTA SFIDA
Attori coinvolti:
- Utente registrato 2: da considerare come l’utente che risponde alla richiesta
di sfida, o utente sfidato.
- Server
Descrizione:
Illustra il processo di risposta ad una richiesta di sfida inviata dall’utente registrato
sfidante.
Pre-condizioni:
- L’utente registrato ha effettuato correttamente la login ed è entrato nel
proprio profilo.
- L’utente registrato periodicamente richiede al Server se è stato sfidato da
qualcuno (richiede 3.2.8 Use-case B.2: POLLING SFIDATO).
Flusso base di eventi:
- L’utente sfidato, dopo aver chiesto al Server se è in stato di sfida, decide se
accettare o meno la sfida creata;
- L’utente sfidato accetta la sfida e invia la propria decisione al Server;
- Il Server cambia stato alla sfida, in modo che l’utente sfidante possa
accorgersi della conferma di sfida da parte dell’utente sfidato.
Flusso alternativo di eventi:
- L’utente sfidato rifiuta la sfida e lo comunica al Server.
- Il Server cambia stato alla sfida, in modo che l’utente sfidante possa
accorgersi della rinuncia di sfida da parte dell’utente sfidato.
- La sfida viene annullata.
Post-condizioni:
La partita tra i due giocatori è confermata. Entrambi i giocatori posso passare alla
fase di inserimento delle pedine sulla scacchiera.
3.2.21 USE-CASE E.3: INSERISCI POSIZIONI INIZIALI
Attori coinvolti:
- Utente registrato 1 o 2.
- Server
Descrizione:
Illustra il processo di inserimento delle pedine nelle posizioni iniziali.
41
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Pre-condizioni:
- L’utente registrato ha avuto conferma di sfida e può disporre le pedine sulla
scacchiera.
Flusso base di eventi:
- L’utente registrato dispone le pedine sulla scacchiera secondo le sue
preferenze;
- Finita la fase di inserimento di tutte le pedine, conferma il posizionamento e
chiede di salvare le pedine al Server;
- Il Server controlla il posizionamento corretto delle pedine e salva la
disposizione.
Flusso alternativo di eventi:
- Il Server valuta scorretto il posizionamento delle pedine e respinge la
richiesta di salvataggio.
- L’utente registrato può disporre nuovamente le pedine.
Post-condizioni:
L’utente registrato ha inserito correttamente le pedine nelle loro posizioni iniziali.
3.2.22 USE-CASE E.4: VISUALIZZA POSIZIONI AVVERSARIO
Attori coinvolti:
- Utente registrato 1 o 2.
- Server
Descrizione:
Illustra il processo di visualizzazioni delle posizioni iniziali dell’avversario.
Pre-condizioni:
- L’utente registrato ha inserito correttamente le sue posizioni iniziali.
- L’utente resta in attesa dell’inserimento delle posizioni avversarie.
Flusso base di eventi:
- L’utente registrato ottiene dal Server le posizioni delle pedine avversarie;
- Le pedine vengono correttamente disposte sulla scacchiera;
- Essendo le pedine proprie dell’avversario, viene offuscato il reale colore
delle pedine;
Flusso alternativo di eventi:
- Il Server non ottiene in tempo utile le pedine dell’avversario (tempo limite di
attesa superato) e marca la sfida come finita;
- La sfida è annullata.
Post-condizioni:
L’utente registrato ha visualizzato correttamente le pedine dell’avversario e può ora
iniziare la fase di gioco vero e proprio, con lo scambio di mosse tra utenti.
42
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.23 USE-CASE E.5: INSERISCI MOSSE
Attori coinvolti:
- Utente registrato 1 o 2.
- Server
Descrizione:
Illustra il processo di inserimento delle mosse dell’utente che ha il turno di gioco.
Pre-condizioni:
- L’utente registrato ha posizionato le pedine sul tavolo;
- L’utente registrato ha visualizzato le pedine dell’avversario;
- L’utente registrato detiene il turno di gioco;
Flusso base di eventi:
- L’utente registrato decide quale mossa effettuare e la esegue;
- Il Server controlla che la mossa sia accettabile rispetto alle posizioni attuali e
salva la disposizione.
Flusso alternativo di eventi:
- Il Server valuta scorretto il posizionamento delle pedine e respinge la
richiesta di salvataggio della mossa.
- L’utente registrato può tentare nuovamente la mossa.
Post-condizioni:
L’utente registrato ha inserito correttamente una mossa e rimane in attesa di quella
dell’utente avversario. La mossa avversaria dovrà essere disegnata (estensione
3.2.24 Use-case E.6: VISUALIZZA MOSSE AVVERSARIO)e gestita per scoprire se si è
raggiunta la fina della sfida (estensione 3.2.25 Use-case E.7: CONTROLLO FINE
SFIDA).
3.2.24 USE-CASE E.6: VISUALIZZA MOSSE AVVERSARIO
Attori coinvolti:
- Utente registrato 1 o 2.
- Server
Descrizione:
Illustra il processo di visualizzazioni delle mosse dell’avversario.
Pre-condizioni:
- L’utente registrato ha inserito correttamente la sua mossa.
- L’utente resta in attesa dell’inserimento della mossa avversaria.
Flusso base di eventi:
- L’utente registrato ottiene dal Server la mossa effettuata dall’avversario;
- Viene aggiornata la scacchiera con il posizionamento della mossa avversaria
e gestite le mangiate;
- Essendo le pedine proprie dell’avversario, viene offuscato il reale colore
delle pedine;
Flusso alternativo di eventi:
43
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
Il Server non ottiene in tempo utile le pedine dell’avversario (tempo limite di
attesa superato) e marca la sfida come finita;
La sfida è annullata.
Post-condizioni:
L’utente registrato ha visualizzato correttamente le mosse dell’avversario, non è
stato interrotto da errori o comunicazioni di fine sfida, può inserire una nuova
mossa se è il suo turno, altrimenti attende.
3.2.25 USE-CASE E.7: CONTROLLO FINE SFIDA
Attori coinvolti:
- Utente registrato 1 o 2.
- Server
Descrizione:
Illustra il processo di controllo e comunicazione di fine sfida.
Pre-condizioni:
- L’utente registrato ha inserito correttamente la sua mossa o ha ricevuto
correttamente la mossa avversaria.
Flusso base di eventi:
- L’utente registrato controlla lo stato della scacchiera per vedere se ci sono i
presupposti per terminare la sfida;
- Viene trovato un criterio di fine sfida e assegnato un vincitore;
- L’utente registrato comunica al server il fine sfida;
- Il Server cambia stato alla sfida e la conclude.
Flusso alternativo di eventi:
- Non viene trovato un criterio di fine sfida. La sfida prosegue normalmente
senza cambio stato da parte del Server.
Post-condizioni:
L’utente registrato ha concluso correttamente la sfida, e può conoscere se ha vinto o
perso.
44
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.26 USE-CASE F: SFIDA INTELLIGENZA ARTIFICIALE
3.2.27 USE-CASE F.1: CREA SFIDA
Vedi 3.2.19 Use-case E.1: CREA SFIDA
3.2.28 USE-CASE F.2: ACCETTA SFIDA IA
Attori coinvolti:
- Server
Descrizione:
Illustra il processo di accettazione automatica di una sfida che coinvolga
l’Intelligenza Artificiale.
Pre-condizioni:
- L’utente registrato ha sfidato l’Intelligenza Artificiale.
Flusso base di eventi:
- Il Server accetta automaticamente la sfida lanciata dall’utente registrato.
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
L’utente registrato ottiene la conferma di sfida e può posizionare le sue pedine sulla
scacchiera.
45
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.29 USE-CASE F.3: CREA SFIDA
Vedi 3.2.21 Use-case E.3: INSERISCI POSIZIONI INIZIALI
3.2.30 USE-CASE F.4: INSERISCI POSIZIONI IA
Attori coinvolti:
- Server
Descrizione:
Illustra il processo di inserimento delle posizioni iniziali dell’Intelligenza Artificiale.
Pre-condizioni:
- L’utente registrato ha inserito correttamente le sue pedine iniziali e attende
che venga fatto lo stesso per l’Intelligenza Artificiale.
Flusso base di eventi:
- Il Server genera le posizioni iniziali per l’Intelligenza Artificiale.
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
Vengono generate le posizioni iniziali per l’Intelligenza Artificiale.
3.2.31 USE-CASE F.5: VISUALIZZA POSIZIONI AVVERSARIO
Vedi 3.2.22 Use-case E.4: VISUALIZZA POSIZIONI AVVERSARIO
3.2.32 USE-CASE F.6: INSERISCI MOSSE
Vedi 3.2.23 Use-case E.5: INSERISCI MOSSE
46
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
3.2.33 USE-CASE F.7: INSERISCI MOSSE IA
Attori coinvolti:
- Server
Descrizione:
Illustra il processo di inserimento delle mosse dell’Intelligenza Artificiale.
Pre-condizioni:
- L’utente registrato ha inserito correttamente la sua mossa e attende che
venga fatto lo stesso per l’Intelligenza Artificiale.
Flusso base di eventi:
- Il Server genera la mossa opportuna per l’Intelligenza Artificiale.
Flusso alternativo di eventi:
Non previsto.
Post-condizioni:
Vengono generate le mosse per l’Intelligenza Artificiale.
3.2.34 USE-CASE F.8: VISUALIZZA MOSSE AVVERSARIO
Vedi 3.2.24 Use-case E.6: VISUALIZZA MOSSE AVVERSARIO
3.2.35 USE-CASE F.9: CONTROLLO FINE SFIDA
Vedi 3.2.25 Use-case E.7: CONTROLLO FINE SFIDA
47
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
48
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 4. PROGETTAZIONE
La prima parte della fase di progettazione è dedicata al disegno ad alto livello delle
strutture che compongono la piattaforma informatica. L’obiettivo principale è quello
di soddisfare i requisiti introdotti in analisi, mantenendo il più alto grado di
interoperabilità possibile, in virtù delle proprietà architetturali esposte nella scelta
dei web service. Inoltre, in un’ottica di sviluppo e mantenimento futuro, si è
privilegiata una struttura che aumentasse quanto più possibile la modularità dei
componenti usati, a scapito di una soluzione immediata, ma meno flessibile.
A livello architetturale, l’entità definita come “Server” nella fase di analisi, ha subito
un radicale cambiamento, frammentandosi in tre sotto-unità, che mantengono
intrinseche le caratteristiche di esposizione di web service, ma che si specializzano
ognuno in opportuni scopi, diventando espressione di uno specifico flusso di eventi
e chiamate. Le tre unità create, corrispondenti a tre web service, sono:
-
WSUtenti;
WSGame;
WSData;
La descrizione delle singole unità verrà affrontata a breve. La scelta progettuale
aumenta la complessità di sviluppo del singolo pacchetto e delle chiamate client
relative alle diverse funzioni, ma rende la piattaforma di sviluppo estremamente
flessibile. Lo studio della separazione dei servizi è stato fatto in visione di una
separazione ed evoluzione dei vari componenti coinvolti nel progetto. La modularità
della piattaforma permetterà alle singole unità di ottimizzare e gestire
autonomamente il proprio sviluppo, integrandosi con le altre strutture solo nei
punti di integrazione tipici di un sistema a moduli. Le peculiarità intrinseche di ogni
servizio esposto potranno così essere gestite indipendentemente dalle scelte
effettuate dagli altri servizi, siano queste dovute a cambiamenti hardware o
software.
Inoltre, la separazione dei servizi esposti permetterà di bilanciare con estrema
accuratezza il carico di lavoro sulle macchine coinvolte, per far fronte al potenziale
numero elevato di client che accederanno ai servizi.
Vediamo ora lo schema generale della piattaforma di gioco, e passiamo alla
descrizione dei singoli componenti e della loro implementazione.
49
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.1: Schema piattaforma generale.
50
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
In Figura 4.1 è illustrato lo schema generale di funzionamento della piattaforma
concepita. Il Client Geister, su cui verrà installata l’interfaccia di gioco, comunica
attraverso Internet con i web service esposti. A seconda dell’operazione richiesta, i
servizi chiamati saranno diversi: se l’operazione riguarda l’anagrafica utente, le
relazioni di amicizia, o la fase di login, il servizio che si prenderà cura di gestire le
richieste del client sarà WSUtenti; se invece, si tratterà di assecondare tutti gli
aspetti del gioco (inizio sfida, posizionamento iniziale, inserimento mosse, controllo
dello stato della sfida, comunicazione turno, comunicazione fine sfida, ecc.) allora ad
essere chiamato sarà il servizio WSGame. Sarà comunque cura del Client
interfacciarsi opportunamente con il giusto servizio a seconda degli eventi scatenati
dall’interazione con l’utente. Il terzo servizio, WSData, non è direttamente coinvolto
dalle chiamate del Client, ma funge da interfaccia da e verso il database per le
richieste provenienti dai due servizi appena descritti. Alle spalle di WSData,
direttamente collegato con esso, c’è il database, che raccoglie tutti i dati spediti da
quest’ultimo, e ne asseconda le richieste. Infine, sono previsti anche alcune
funzionalità di contorno, che per loro natura possono lavorare in maniera asincrona
rispetto alle precedenti strutture, e che si occupano di mantenere l’integrità e la
coerenza dei dati raccolti (stored procedure) o di analizzare i dati raccolti per la
profilazione degli utenti (LearnerServer).
4.1 DATABASE
Il database è la parte del sistema responsabile dello storage dei dati. Da esso il
servizio WSData, e di riflesso gli altri servizi e il client, attingono i dati per la
gestione degli accessi, i dati anagrafici degli utenti registrati, le relazioni di amicizia,
i dati di gestione delle partite e i dati dei profili dei giocatori da utilizzare nella
gestione delle mosse dell’Intelligenza Artificiale. Per quanto riguarda il RDBMS da
usare, la scelta è ricaduta su MySQL per le seguenti principali motivazioni:
-
Buona integrazione con Java
Prestazioni
Semplicità
Licenza di tipo Open Source
Lo schema del database utilizzato è visibile in Figura 4.2.
51
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.2: Schema del database.
Le tabelle del database sono:
4.1.1 UTENTI
Contiene i dati anagrafici dell’utente registrato, i dati di ingresso al gioco e alcune
variabili di sistema. I campi di questa tabella sono:
-
id: identificativo univoco dell’utente, intero, chiave primaria, auto-increment.
nome: nome dell’utente, string.
cognome: cognome dell’utente, string.
email: e-mail dell’utente, stringa. Utilizzata per comunicazioni all’utente o, in
chiave futura, per gestire la registrazione con invio conferma a e-mail valida.
username: username univoca, string.
password: password decisa dall’utente in fase di registrazione, string.
is_ia: definisce se l’utente è l’espressione di una Intelligenza Artificiale,
booleano.
is_online: definisce se l’utente risulta essere online, boolean.
52
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
-
is_admin: in previsione futura, serve a definire se l’utente è amministratore,
e potrà quindi avere accesso ad ulteriori servizi gestiti solo dagli
administrator (servizi statistici, modifiche di anagrafiche altrui, ecc.),
boolean.
vinte, pareggiate, perse: campi contatore delle partite rispettivamente vinte,
pareggiate e perse dall’utente, intero.
data_creazione: data di generazione del record.
4.1.2 SESSIONI
Contiene i dati di sessione generati dall’utente al momento della login. La sessione
viene gestita dal token generato durante la login e dalla data di creazione del record,
che serve a gestire la scadenza del token stesso:
-
id: identificativo univoco della sessione, intero, chiave primaria, autoincrement.
idtoken: token generato per essere usato dall’utente nelle sue chiamate,
string.
id_utente: chiave esterna riferimento dell’utente, tabella utenti, intero.
data_inizio: data/tempo di inizio sessione. Serve per decidere se la sessione è
scaduta, e quindi il token va rinnovato.
4.1.3 AMICI
Contiene le relazioni di amicizia tra i diversi utenti registrati. I campi di questa
tabella sono:
-
id: identificativo univoco dell’amicizia, intero, chiave primaria, autoincrement.
id_utente1: id dell’utente registrato che ha creato la relazione di amicizia,
chiave esterna riferimento dell’utente, tabella utenti, intero.
id_utente2: id dell’utente registrato che è stato coinvolto nella relazione di
amicizia, chiave esterna riferimento dell’utente, tabella utenti, intero.
data_creazione: data di generazione del record.
4.1.4 PARTITE
Contiene tutte le partite create e i dati di intestazione delle partite stesse. I campi di
questa tabella sono:
-
-
id: identificativo univoco della partita, intero, chiave primaria, autoincrement.
id_utente1: id dell’utente registrato che ha creato la partita (sfidante) –
primo giocatore, chiave esterna riferimento dell’utente, tabella utenti, intero.
id_utente2: id dell’utente registrato che ha accettato la sfida (sfidato) –
secondo giocatore, chiave esterna riferimento dell’utente, tabella utenti,
intero.
n_giocatore_init: numero che identifica il giocatore che per primo inizia a
muovere sulla scacchiera (1 per giocatore sfidante, 2 per giocatore sfidato),
byte.
livello1, livello2: livello delle intelligenze artificiali applicate rispettivamente
al giocatore1 e al giocatore2.
allenamento1, allenamento2: per futuri scopi, ad uso delle intelligenze
artificiali applicate a giocatore1 e giocatore2 nel caso di allenamento o aiuti
per l’utente.
53
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
-
tipo: serve per capire il tipo di sfida in corso (nuova, confermata, gestione
posizioni iniziali, gestione mosse, annullata, finita…). Rappresenta lo stato
parziale o finale di una sfida, intero.
data_creazione: data di creazione della partita.
4.1.5 POSIZIONI_INIZIALI
Contiene tutte le disposizioni delle pedine nelle posizioni iniziali. I campi di questa
tabella sono:
-
id: identificativo univoco della posizione iniziale, intero, chiave primaria,
auto-increment.
id_partita: id della partita, chiave esterna riferimento della partita, tabella
partite ,intero.
pedina: identifica la pedina che da posizionare, string.
posizione: identifica la posizione iniziale assunta dalla pedina, intero.
data_creazione: data di generazione del record.
4.1.6 MOSSE
Contiene tutte le mosse delle pedine effettuate durante le partite. I campi di questa
tabella sono:
-
id: identificativo univoco della mossa, intero, chiave primaria, autoincrement.
id_partita: della partita, chiave esterna riferimento della partita, tabella
partite ,intero.
id_utente: id dell’utente registrato che ha generato la mossa, chiave esterna
riferimento dell’utente, tabella utenti, intero.
pos_iniziale: identifica la posizione iniziale assunta dalla pedina, intero.
pos_finale: identifica la posizione finale assunta dalla pedina nello
spostamento, intero.
mangia: identifica se nello spostamento c’è stata una mangiata e di che tipo,
string.
data_creazione: data di generazione del record.
4.1.7 LEARNERS
Contiene i nomi dei learner usati nell’analisi dei profili di gioco del giocatore.
Tengono un riferimento utile per la generazione della mossa dell’Intelligenza
Artificiale. I campi di questa tabella sono:
-
id: identificativo univoco del learner, intero, chiave primaria, autoincrement.
nome: campo che contiene il nome del Learner implementato e usato dal
Learner Server per la creazione dei profili, text.
4.1.8 RANKERS
Contiene i nomi dei ranker usati all’interno del servizio WSGame, nella generazione
della mossa dell’Intelligenza Artificiale. Per offrire un’interfaccia usabile dall’utente,
i vari ranker sono associati ad un utente di tipo Intelligenza Artificiale, associato
tramite il campo id_IA. I campi di questa tabella sono:
-
id: identificativo univoco del learner, intero, chiave primaria, autoincrement.
54
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
nome: campo che contiene il nome del Learner implementato e usato dal
Learner Server per la creazione dei profili, text.
Id_IA: id dell’utente fittizio Intelligenza Artificiale che fa da interfaccia agli
altri utenti, chiave esterna riferimento dell’utente, tabella utenti, intero.
4.1.9 LEARNERS_RANKERS
Contiene i campi di collegamento tra i learner ed i ranker e serve per esprimere una
relazione N a N tra queste due tabelle. In questo modo è possibile associare
opportuni analizzatori di profili (learner) ad opportuni valutatori di mosse (ranker),
con il massimo grado di libertà di relazione. I campi di questa tabella sono:
-
id: identificativo univoco della relazione tra learner e ranker, intero, chiave
primaria, auto-increment.
nome: campo che contiene il nome del Learner implementato e usato dal
Learner Server per la creazione dei profili, text.
id_IA: id dell’utente fittizio Intelligenza Artificiale che fa da interfaccia agli
altri utenti, chiave esterna riferimento dell’utente, tabella utenti, intero.
4.1.10 PROFILI_U_L_R
Contiene tutti i profili utente generati dai learner usati come supporto per
l’Intelligenza Artificiale. La relazione è tra un utente e la sua coppia learner/ranker.
Attualmente la tabella può contenere dati ridondanti, in quanto il profilo è
espressione dei soli learner, e quindi in caso di inserimento di valori multipli di
learner con ranker diversi, i campi profilo saranno uguali per tuple diverse. In attesa
di definire meglio l’uso di ulteriori ranker, si è preferito mantenere la ridondanza
per non rischiare di avere dati non modificabili. I campi di questa tabella sono:
-
-
id: identificativo univoco della relazione tra utente e coppia learner/ranker,
intero, chiave primaria, auto-increment.
id_utente: identificativo univoco dell’utente, intero, chiave primaria, chiave
esterna riferimento dell’utente, tabella utenti, auto-increment.
id_learner_ranker: identificativo univoco della coppia learner/ranker, intero,
chiave primaria, chiave esterna riferimento della tabella learners_rankers,
auto-increment.
profilo: campo che contiene il profilo generato per quell’utente per quella
coppia learner/ranker, text.
4.1.11 LOG
Contiene tutti i log di errori o operazioni gestite dai server. I campi di questa tabella
sono:
-
id: identificativo univoco della riga di log, intero, chiave primaria, autoincrement.
log: testo del log generato, string.
data_log: data/ora di immissione del log.
function: richiamo testuale alla funzione (operazione, metodo, eccezione,
ecc.) che ha generato il log, string.
55
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
4.2 WEB SERVICE - WSUTENTI
WSUtenti è il servizio che si occupa di rispondere a tutte le richieste che coinvolgono
le anagrafiche utenti e le relazioni tra i vari giocatori. Il client chiama questo servizio
per interrogare la piattaforma su dati anagrafici propri o di altri utenti registrati. Il
servizio mette a disposizione diverse operazioni, illustrate in Figura 4.3.
Figura 4.3: WSUtenti – interfaccia delle operazioni esposte.
56
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
4.3 WEB SERVICE - WSGAME
WSGame è il servizio che si occupa di rispondere a tutte le richieste che coinvolgono
la sfida tra due giocatori, siano essi due giocatori registrati o un giocatore e
un’Intelligenza Artificiale. WSGame viene coinvolto in una fase successiva, quando
due giocatori sono intenzionati alla sfida. Dal momento di creazione della sfida alla
fine della stessa, WSGame è a disposizione dei client per rispondere a tutte le
operazioni di inserimento mosse, controllo delle stesse e recupero delle mosse
dell’avversario. WSGame è responsabile per la logica di gioco e inoltre implementa
le operazioni di generazione delle mosse per l’Intelligenza Artificiale. Le operazioni
esposte da questo servizio sono visibili in Figura 4.4.
Figura 4.4:WSGame - interfaccia delle operazioni esposte.
4.4 WEB SERVICE - WSDATA
WSData è il servizio che si occupa di fare da interfaccia per l’immagazzinamento dei
dati. E’ un servizio interno, pensato per essere chiamato direttamente dai due servizi
precedenti per tutte le operazioni di inserimento, modifica, cancellazione dei dati nel
database. Questo servizio vuole fornire un’interfaccia che nasconda
l’implementazione e le scelte progettuali del database, in modo da rende il più
possibile indipendente lo sviluppo nella gestione dei dati dallo sviluppo nella
gestione della logica di gioco. Questo passaggio intermedio offre inoltre il vantaggio
di coprire l’accesso diretto al database da un servizio esposto in Internet (WSUtenti
e WSGame). In Figura 4.5 possiamo vedere l’interfaccia che esprime le operazioni
esposte dal servizio.
57
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.5: WSData - interfaccia delle operazioni esposte.
4.5 PROGETTAZIONE HARDWARE SERVIZI
La separazione della logica Server in tre diversi servizi permette anche una
un’indubbia flessibilità nella gestione hardware. Ricordando che ogni servizio
necessita di un web server che si occupi della sua esposizione (e che può contenere
anche il file descrittivo del servizio stesso), la creazione di tre servizi separati offre
l’opportunità di gestire i carichi di lavoro su server fisicamente separati, e
potenzialmente posti in luoghi diversi l’uno dall’altro. Il servizio intermedio WSData,
che fa da interfaccia per il database, è pensato per essere posto in una macchina
differente dagli altri servizi, proprio per la sua peculiarità di offrire solo operazioni
di back - end, che nulla hanno a che fare con il client. Inoltre questo servizio si presta
anche a operazioni di protezione sulla rete: fermo restando che i dati tra client e
servizio, e tra servizio e servizio, passano attraverso il web con chiamate HTTP,
WSData può essere protetto a livello hardware, esponendo il suo servizio in una rete
raggiungibile solo dai due servizi che lo utilizzano. La rete in questione potrebbe
essere una intranet, nel caso di una logica server fisicamente alloggiata in una
struttura unica, o una rete separata che faccia uso di regole firewall per limitarne
l’accesso, nel caso di macchine server distribuite in luoghi diversi. La scelta di
aumentare la modularità dei servizi esposti ha un costo in termini di quantità di dati
scambiati in rete: tutti i passaggi da e per il database soffrono di un potenziale
58
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
rallentamento, dovuto alla minor velocità di trasmissione del dato. Altresì, macchine
diverse hanno processori dedicati al singolo servizio, aumentando notevolmente la
capacità di gestione di numerosi client. Questi ragionamenti rimandano ad una
futura analisi del carico con la piattaforma a regime. Sono state individuate
comunque, nei servizi WSUtenti e WSGame, delle operazioni disponibili all’uso di
sistemi di caching, totalmente trasparenti al client, e quindi perfetti per la gestione
separata auspicata. In particolare, possiamo ricavare esempi di uso di dati utilizzanti
caching in: utenti disponibili, dati anagrafici raccolti e non modificati, dati di gioco
parziali non modificati, o operazioni che non debbano esporre dati sempre
aggiornati. Inizialmente i web service verranno ospitati in un unico server fornito di
Apache + TomCat 6.x. La scelta della versione di TomCat è vincolante; tutti i servizi
generati infatti sono ottimizzati per questa versione; è possibile scegliere una
versione differente, ma bisognerà rifare il deploy dei servizi a partire dal codice
sorgente. Il database MySQL non ha regole particolari di installazione, ma è stato
scelta la versione 5.5. Il database potrà già essere ospitato in una macchina separata
rispetto al web server; sarà comunque necessario cambiare l’indirizzo di
connessione nei sorgenti di WSData, e ricostruire il pacchetto del servizio.
4.6 PROGETTAZIONE SOFTWARE SERVIZI
Come illustrato precedentemente, l’uso di web service pone una serie di questioni
aperte nella scelta dell’architettura opportuna. Molte scelte hanno coinvolto il lato
progettuale del software. Il trasferimento dei dati, e il ciclo di vita degli stessi
all’interno dei web service dipendono da una scelta ben precisa: l’utilizzo di
pacchetti stateless o stateful. Per ottenere la miglior resa possibile in termini di
performance nella gestione dei pacchetti, è altamente consigliato da Apache
Software Foundation di sposare una filosofia quanto più possibile stateless. La
differenza sostanziale tra i due approcci riconduce all’uso o meno di sessioni che
mantengano in vita il dato anche dopo che il metodo sia stato chiuso e l’operazione
evasa. I dati mantenuti tramite le sessioni sono poi richiamabili nei successivi
accessi al servizio, ritrovando così in vita le istanze degli oggetti costruiti all’interno
della sessione stessa. Questa filosofia, stateful, richiede l’uso intensivo di header
nella costruzione e passaggio dei pacchetti SOAP, con conseguente rallentamenti e
perdita di performance di rete (pacchetti più grandi da trasferire) e di
processamento nel server (dati da conservare, tempo di vita delle sessioni da
gestire). Inoltre, il sistema stateful è attualmente in continua evoluzione, e risulta
ben lontano da uno standard che ne risolva tutti i problemi di interoperabilità
(pietra miliare nell’uso dei web service). La filosofia stateful, nonostante l’approccio
che avrebbe facilitato la gestione del dato, è stata quindi scartata e sostituita con la
scelta di usare i web service in maniera stateless: con questa filosofia ogni chiamata
alle operazioni è indipendente dalla precedente e genera potenzialmente un nuovo
thread di gestione, completamente isolato dalla “storia” precedente del dato. La
filosofia stateless è dichiarata come più performante dalla stessa Oracle6:
“Stateless Beans Offer Performance and Scalability Advantages. Because stateless
session beans are never written to secondary storage, they typically offer better
6
http://docs.oracle.com/cd/E14571_01/web.1111/e13719/design_best_practices.htm
59
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
performance than stateful beans. For applications that require large numbers of
clients, stateless session beans offer better scalability than stateful session beans.”
Questo approccio non è comunque esente da problematiche di gestione, una fra
tutte, la più importante, è l’autenticazione: conoscere l’identità del chiamante è una
problematica che riguarderà ogni singola chiamata ad operazioni di ogni singolo
servizio. Per ridurre al minimo il passaggio di dati sensibili, e per ottenere
comunque una soluzione efficace e leggera (in termini di byte passati tra client e
web service), è stato deciso di gestire l’autenticazione con l’ausilio di token di
sessione, ospitati nel database.
4.7 AUTENTICAZIONE
L’autenticazione del client avviene tramite controllo di login e password attraverso
il servizio WSData, che richiama il database ed effettua la comparazione.
Successivamente il web service crea e salva nel database un token di sessione per
l’utente autorizzato. Il token, generato con un hash opportuno, univoco per utente e
per sessione, sostituisce login e password in ogni singola chiamata alle operazioni di
tutti i web service. Ciò che viene richiesto ai web service è di implementare il
controllo di esistenza del token, e il conseguente recupero dell’utente autorizzato,
per svolgere le successive operazioni richieste. Per aumentare la sicurezza nella
trasmissione dei dati, la password viene opportunamente mascherata in invio, come
vediamo in Figura 4.6.
Figura 4.6: Sequenza login e creazione Token.
La fase di mascheramento della password è la seguente: il client chiama WSUtenti e
passa login in chiaro, hash della password (applicazione dell’algoritmo SHA-1 di
password+randomSeed) e randomSeed (intero random). Il servizio WSUtenti
chiama il servizio WSData e passa i dati raccolti. WSData recupera i dati dal
database, genera l’hash della password+randomSeed ricevuto dall’utente inviante e
controlla se i dati passati sono uguali a quelli attesi. Se sono uguali, dà conferma e
genera il token. Il servizio WSUtenti a sua volta propaga la risposta di WSData al
client. L’utente potrò poi chiedere il Token. Quest’ultimo è generato come hash
60
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
prodotto dall’uso dell’algoritmo SHA-1 con input concatenato di: login, password,
randomSeed, timestamp di data/ora della richiesta (in modo da generare sempre
token differenti per utenti e momenti differenti).
4.8 CLIENT
Il client si occupa di fornire un’interfaccia di gioco per l’utente. Inoltre, gestisce tutta
la parte riguardante il profilo dell’utente registrato, la sua rete di contatti e la
comunicazione delle informazioni da e per i servizi. Il client è coinvolto in tutte le
fasi che riguardano l’approccio dell’utente al gioco. Per meglio individuare l’albero
delle operazioni fornite all’utente, vediamo uno schema generale di approccio
dell’utente a Geister.
Figura 4.7: Diagramma attività Client.
In Figura 4.7 possiamo vedere il flusso di attività generali che coinvolgono il Client.
L’utente può scegliere di effettuare la registrazione come nuovo utente, o entrare
attraverso la login, al client vero e proprio. Sono presenti pagine ausiliarie, come
Credits o Manuale, per la consultazione anche da utente non registrato. Solo chi ha
effettuato la login può entrare nel profilo. Da questo si possono gestire i dati
anagrafici o visualizzare gli amici. L’elenco amici può essere modificato inserendo o
eliminando le relazioni di amicizia con altri utenti. E’ possibile naturalmente
scegliere un amico (fisico o Intelligenza Artificiale) e far partire la sfida.
Sono stati indicati anche i web service coinvolti nelle attività, rispettivamente con le
lettere:
61
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
U: WSUtenti
D: WSData
G: WSGame
Vediamo nel dettaglio la sequenza per la sotto-attività che descrive la fase di
creazione di una sfida.
Figura 4.8: Sequenza creazione sfida.
L’utente registrato chiama il servizio WSUtenti per recuperare la lista degli utenti
amici. WSUtenti gira la richiesta a WSData, che è l’unico ad avere accesso diretto al
database. Dopo che i servizi ritornano la lista all’utente, quest’ultimo può scegliere
l’amico da sfidare. L’utente chiede a WSGame di generare la sfida, passando come
parametro l’amico scelto. WSGame chiama WSData e genera la sfida. Il successivo
diagramma illustra la gestione di risposta dell’utente amico, che nel frattempo
interroga il servizio WSGame per sapere se è nello stato di sfidato.
62
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.9: Sequenza dialogo utente sfidato.
L’utente 2 è in attesa di essere sfidato, e interroga a intervalli regolari WSGame per
sapere se esiste qualche sfida in cui lui sia stato coinvolto (polling a intervalli
regolari). Quando utente 1 crea la sfida, all’ennesima domanda di utente 2, WSGame
è pronto a rispondere positivamente. Utente 2 può decidere di sua iniziativa se
confermare la sfida. Quando la sfida è nello stato di confermata, i due giocatori
passano alla fase successiva e posso inserire le pedine nelle posizioni iniziali ed
iniziare la fase di gioco vero e proprio. Se la sfida è annullata, Utente2 aspetta solo la
conferma di annullamento, mentre utente1 verrà a conoscenza di questo stato solo
nel momento in cui interrogherà il server per aver la conferma.
Se la sfida avviene tra utente registrato e Intelligenza Artificiale, la sequenza è
leggermente diversa, perché l’Intelligenza Artificiale si rende sempre disponibile alla
creazione di una nuova sfida, e quindi l’utente che crea la sfida conosce subito l’esito
della sua richiesta, non appena la sfida viene creata. WSGame si occuperà di
rispondere all’istanza di richiesta di una nuova sfida contro l’Intelligenza Artificiale,
e gestirà anche le successive fasi di inserimento mosse. Nel diagramma di sequenza
in Figura 4.10 viene descritta la fase di sfida tra l’utente registrato e l’Intelligenza
Artificiale.
63
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.10: Sequenza creazione sfida tra utente ed IA.
Dopo aver creato la sfida, le successive fasi riguardano l’inserimento delle pedine
nelle posizioni iniziali e la fase di gioco vero e proprio, con l’inserimento alternato
delle mosse. La strategia alla base del dialogo tra utenti e servizi nella gestione delle
mosse è la seguente: se l’utente ha il turno, può salvare la sua mossa, altrimenti deve
attendere di avere il turno. Il turno viene gestito dal servizio WSGame, che chiede i
dati delle mosse effettuate a WSData, controlla l’ultima mossa effettuata e decide di
chi è il turno. In questo modo le mosse si alternano e il turno viene dato all’utente
solo se l’ultimo inserimento è stato dell’avversario o se è il primo a muovere.
64
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.11: Sequenza inserimento mossa
In Figura 4.11 possiamo vedere la sequenza di inserimento mossa da parte
dell’utente registrato. WSGame chiede l’elenco delle mosse per decidere se l’utente
ha il turno. Una volta che gli è stato assegnato il turno di gioco, l’utente può inserire
la mossa. La validità della mossa viene controllata sia a livello di client (per filtrare
mosse palesemente scorrette), sia a livello di servizio, per evitare sovrapposizioni
con mosse dell’avversario o per inibire eventuali mosse scorrette forzate con un
client qualsiasi. Se la mossa è ritenuta corretta, viene salvata nel database e
confermata al client. A questo punto il Client attende di conoscere l’inserimento
dell’avversario e chiede a WSGame il recupero della relativa mossa. A tal proposito
si distinguono due casi:
1. L’utente registrato sta giocando contro un’Intelligenza Artificiale (single
player): la mossa viene generata direttamente da WSGame tramite l’uso di
opportuni algoritmi implementati al suo interno; il servizio poi si preoccupa
di contattare WSData per salvare la mossa nel database, prima di
comunicarla al Client.
2. L’utente registrato sta giocando contro un altro utente (multi player): la
mossa viene chiesta ripetutamente a WSGame (tramite l’uso di chiamate
temporizzate continue, polling), che chiede a WSData l’elenco delle mosse,
ed estrapola l’ultima mossa effettuata; se la mossa è dell’avversario, la
comunica al client.
65
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
4.9 ALTRI MODULI COINVOLTI
L’ultima parte della progettazione è dedicata a quei moduli ausiliari che completano
l’architettura offrendo azioni di supporto al database, o di generazione di dati di
profilazione, utili in fase di gioco.
4.9.1 STORED PROCEDURE
Il database ha bisogno di operazioni di elaborazione temporizzata sui dati. Sono stati
individuati possibili punti di interesse per la creazione di stored procedure che si
occupino di aggiornare i dati per mantenere la coerenza e l’efficacia logica ad essi
richiesta. In particolare le stored procedure implementate nel database possono
rispondere ad esigenze come:
-
Far scadere a intervalli regolari le sessioni di gioco degli utenti, per
costringere i client a rinnovare i token.
Modificare il campo is_online dell’utente, che identifica se l’utente è connesso
in quel momento, mettendo il valore a zero a intervalli regolari, per
costringere il client a rinnovare questa informazione, in modo da mantenerla
il più possibile coerente con la reale situazione dei client.
4.9.2 ALGORITMI DI INTELLIGENZA ARTIFICIALE
Gli algoritmi per l’uso dell’Intelligenza Artificiale sono stati messi a disposizione da
progetti derivanti da precedenti esperienze di stage. La filosofia derivante da questi
algoritmi si compone di due azioni principali:
-
-
Profilazione del comportamento di ogni utente, analizzando i log delle
partite effettuate e facendo emergere le caratteristiche significative di
strategia e dissimulazione (fase di learning);
Classificazione dei pezzi (e generazione della mossa) per la partita in corso,
confrontando i dati attuali con il comportamento salvato nel profilo utente
(fase di ranking e generazione mossa).
L’integrazione di questi algoritmi ha richiesto innanzitutto una attenta analisi per la
collocazione fisica dei moduli necessari allo scopo: a differenza del software
standalone, i dati coinvolti per l’uso dei suddetti algoritmi si trovano in aree diverse
della piattaforma, cosa che ha comportato una fase di studio preliminare. Dall’analisi
è emersa la necessità di separare le fasi di profilazione da quelle di generazione della
mossa; questa separazione ha permesso non solo di collocare i moduli in aree
diverse della piattaforma, ma di renderle indipendenti l’una dall’altra. Vediamo ora
uno schema di integrazione dei moduli coinvolti nell’uso dell’Intelligenza Artificiale.
66
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 4.12: Schema di integrazione algoritmi di Intelligenza Artificiale.
In Figura 4.12 vediamo uno schema della disposizione dei moduli di Intelligenza
Artificiale all’interno della piattaforma, descrivendo anche il flusso di richieste e
risposte coinvolte nelle operazioni di profilazione e generazione delle mosse
dell’Intelligenza Artificiale:
A) Gli utenti che accedono ad una sfida inviano i dati verso i web service
coinvolti. Anche l’Intelligenza Artificiale è vista nel lato Client come un
utente sempre sfidabile. Fisicamente i moduli principali di gestione
dell’Intelligenza Artificiale si trovano all’interno del servizio WSGame, che
risponde in automatico qualora un utente desiderasse giocare contro
l’Intelligenza Artificiale ( IA);
B) Sia che le partite coinvolgano due utenti, sia che si tratti di un utente contro
l’IA, tutti i dati delle partite (utenti coinvolti, posizionamento pedine, mosse,
stato della partita,…) vengono inviati dai web service al database;
C) Un software separato, chiamato Learner Server si occupa dell’analisi di tutte
le partite presenti nel database. Si tratta di un server standalone, creato in
Java, direttamente collegato al database. L’uso di questo server permette di
analizzare le partite secondo gli algoritmi sviluppati al suo interno, e di
creare e salvare nel database (tabella utenti_profili) i profili di ogni singolo
utente, per ogni singolo algoritmo implementato. L’avvio del server coincide
con l’avvio delle analisi, quindi questo programma può essere usato
periodicamente con uno scheduler di processi per raffinare i profili utente,
sulla base delle partite svolte fino a quel momento. La fase di learning
avviene in modo completamente asincrono rispetto all’esecuzione delle
partite. Avviare o meno questo server permette di avere profili di utenti più
o meno raffinati e precisi;
D) Quando l’IA si trova coinvolta in una partita, il servizio WSGame si trova a
dover generare le mosse in risposta a quelle effettuate da un utente umano.
Il servizio richiama al suo interno i metodi di generazione dell’Intelligenza
Artificiale, per effettuare la mossa opportuna. Questa decisione necessita
innanzitutto della valutazione dei pezzi dell’avversario umano presenti sulla
67
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
scacchiera di gioco. Per fare ciò WSGame si serve del modulo Ranker, che
utilizza i profili dell’utente avversario, salvati nel database dal Learner
Server. Dai profili, il Ranker estrae le caratteristiche principali di strategia
dell’avversario e, applicandole al tavolo della partita in corso, cerca di capire
il colore di ogni fantasma avversario (fase di ranking). In caso di assenza di
un profilo avversario valido (non esiste ancora, o non è utilizzabile per
l’algoritmo in uso), il Ranker usa un profilo di default e applica usa scelta
pseudo-casuale;
E) Una volta ottenuta la presunta disposizione dei pezzi avversari, WSGame
elabora la mossa migliore, cercando di uscire il prima possibile, o tentando
di mangiare un pezzo avversario ritenuto blu, o cercando di scappare da una
pericolosa situazione.
Per i dettagli di implementazione dei moduli di integrazione dell’Intelligenza
Artificiale, si rimanda al sotto-capitolo 5.9 INTEGRAZIONE INTELLIGENZA
ARTIFICIALE).
68
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 5. SVILUPPO
In questo capitolo illustriamo lo sviluppo concreto dei vari moduli progettati, e
descriviamo l’implementazione completa delle classi, compresi i metodi principali.
5.1 IMPLEMENTAZIONE WEB SERVICE
L’implementazione dei web service è strutturata nello stesso modo per tutti e tre i
componenti esposti, e segue lo schema generale descritto da Apache Software
Foundation e implementato nella pratica con l’uso di Axis2. Ad alto livello di
progettazione Axis2 usa il modello ad Oggetti Distribuiti, che è uno dei modelli usati
per la descrizione e l’implementazione dei sistemi distribuiti. Axis2 implementa le
API di JAX-WS (javax.jws.*) per semplificare lo sviluppo e la distribuzione di Java
Web Services (JWS) basati sul protocollo SOAP. Lo schema progettuale del modello,
ad alto livello, si può vedere in Figura 5.1:
Figura 5.1: Modello ad oggetti distribuiti in JAX-WS.
La parte importante della gestione è data dalle sezioni Stub e Skeleton (Tie in
figura). In particolare:
Lo Stub:
- rappresenta il Proxy del Server lato Client, cioè offre in locale all’applicazione
Client gli stessi metodi del Server.
- Nasconde i dettagli della comunicazione sulla rete all’applicazione Client.
Lo Skeleton:
-
Riceve i dati dalla rete inviati dallo stub (il nome della funzionalità da
invocare e i parametri necessari)
Invoca il metodo sull’oggetto remoto che implementa anch’esso l’interfaccia
remota.
Restituisce il risultato allo Stub.
Lo Stub e lo Skeleton rappresentano il middleware di tale sistema distribuito.
69
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Axis2 è uno strumento molto versatile e permette non solo di esporre il servizio e il
suo file descrittivo, ma anche di generare lo Skeleton lato server e lo Stub lato client
per l’implementazione dei metodi decisi in fase di progettazione. Da notare che si
parla di “metodi”, e non più di operazioni, proprio perché in questo contesto ci
troviamo nella parte interna del servizio, che quindi verrà trattato come una classe,
completa di variabili e metodi. Una volta che si genereranno le opportune strutture
middleware e il servizio sarà esposto sul web service si parlerà di “operazioni del
web service”.
Axis2 permette di implementare il servizio con due approcci:
Top - down
-
Partire creando il documento WSDL che descrive il Web Service
WSDL > Java
Genera per il lato server: Skeleton Java e file per l’esposizione del web
service
Bottom - up
-
Partire da una classe o interfaccia Java che contiene i metodi che il web
service dovrà esporre
Java > WSDL
WSDL > Java (Come nel caso top-down)
L’approccio usato in questo progetto è stato quello bottom-up, avendo già creato in
fase di progettazione le interfacce descrittive dei singoli web service. Usando Eclipse
con il plugin di Axis 2 è stato generato il web service7. Eclipse genera tutte le classi
previste dal modello ADB (Axis Data Binding), ovvero:
-
<NOME
SERVIZIO>SKELETON.JAVA:
<NOME
SERVIZIO>MESSAGGERECEIVERXY.JAVA:
la classe “main” del servizio.
da 1 a 4 classi che si occupano di gestire
il trasporto nei 4 casi di MEP possibili (InOut, OutIn, In e Out).
EXTENSIONMAPPER.JAVA: mappa le estensioni (es. i sotto elementi) dei messaggi
XML nei relativi oggetti Java.
Per risalire al nome del servizio dal nome di queste classi occorre fare attenzione
alla capitalizzazione, ad esempio. WSUtentiSkeleton è la classe principale del servizio
avente nome WSUtenti. Oltre a queste classi, Eclipse genera una classe per ogni
complex type definito nel WSDL. Nel progetto sono stati evitati complex type nel
passaggio dati, non tanto per la scalabilità (garantita da una buona trasformazione
in xml del tipo complesso), quanto per cercare di ridurre la quantità di dati inviati (e
quindi i byte di traffico) al minimo indispensabile.
Non volendo interferire con il lavoro automatico di scrittura dei file di Axis 2, tutta
l’implementazione del servizio è stata ospitata in una classe (MySkeleton.java)
contenuta nel package Skeleton, i cui metodi venivano richiamati dai metodi
omonimi nella classe automatica <nomeServizio>Skeleton.java.
Tutorial di generazione:
http://www.eclipse.org/webtools/community/tutorials/BottomUpAxis2WebService/bu_tut
orial.html
7
70
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Vediamo le dichiarazioni dei metodi nelle classi MySkeleton e una descrizione dei
metodi principali. Per la descrizione completa si rimanda alla Javadoc presente
all’interno dei codici sorgenti.
71
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.2 WSDATA – MYSKELETON.JAVA
5.2.1 DICHIARAZIONE CLASSE E METODI:
Figura 5.2: WSData - Descrizione classe MySkeleton.
72
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.2.2 METODI PRINCIPALI :
Metodi GET*(…) / SET*(…): restituiscono o settano le variabili visibili dal nome stesso
del metodo (es. getNome, restituisce il nome dell’utente, setEmail setta l’email
dell’utente,…).
MODIFICAUTENTE(…), CANCELLAUTENTE(…): metodi di inserimento,
modifica, cancellazione degli utenti nel database. In particolare NuovoUtente è
chiamato per la registrazione di un nuovo utente.
NUOVOUTENTE(…),
metodo che genera il token di sessione per l’utente che comunica login
e password cifrata+randomseed. Ritorna la stringa con il token o una stringa di
errore
GETIDTOKEN(…):
CANCELLAAMICO(…), CANCELLAAMICI(…):
metodi di inserimento e
cancellazione delle relazioni di amicizia tra il chiamante e un altro utente.
CANCELLAAMICI elimina in una sola chiamata, tutte le relazioni di amicizia del
chiamante.
NUOVOAMICO(…),
INSERTPARTITA(…), DELETEPARTITA(…):
metodi di inserimento, cancellazione delle partite
nel database.
UPDATETIPO(…):metodo
che aggiorna il tipo della partita, modificando l’informazione
utile per conoscere la fase attuale di gioco: partita iniziata, confermata, annullata,
finita,ecc.
INSERTPOSIZIONEINIZIALE(…), INSERTMOSSA(…):
metodi di inserimento di singole posizioni
iniziali e mosse.
73
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.3 WSUTENTI – MYSKELETON.JAVA
5.3.1 DICHIARAZIONE CLASSE E METODI:
Figura 5.3:WSUtenti - Descrizione classe MySkeleton.
5.3.2 METODI PRINCIPALI :
Metodi GET*(…) / SET*(…): restituiscono o settano le variabili visibili dal nome stesso
del metodo, richiamando i metodi di WSData per il recupero dei dati nel database
(es. getNome, restituisce il nome dell’utente, setEmail setta l’email dell’utente,…).
Metodi NUOVOUTENTE(…) / MODIFICAUTENTE(…): Creano un nuovo utente in fase di
registrazione, e modificano i dati secondari se il client lo richiede, sempre
richiamando i metodi opportuni in WSData.
Metodo LOGIN(…): recupera il token da WSData passando i dati di login e password
arrivati dall’utente e ritorna la stringa con il token di sessione.
Metodi INSERTAMICO (…) / CANCELLAAMICO(…): si occupano del richiamo dei metodi
opportuni di WSData per l’inserimento e la cancellazione di relazioni di amicizia tra
utenti.
Metodo GETLISTAMICI(…): ritorna una stringa concatenata di tutti gli username amici
del chiamante.
74
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.4 WSGAME – MYSKELETON.JAVA
5.4.1 DICHIARAZIONE CLASSE E METODI:
Figura 5.4: WSGame - Descrizione classe MySkeleton.
5.4.2 METODI PRINCIPALI :
Metodo INSERTPARTITADB(…), NUOVAPARTITA(…): si occupano dell’inserimento della
partita, controllando che non vi siano partite in corso tra gli utenti, e che tutti i
parametri siano correttamente assegnati. L’inserimento avviene richiamando il
metodo opportuno in WSData.
Metodo MODIFICATIPO(…): si occupa di modificare il tipo della partita, inserendo valori
che identificano la fase di gioco (partita iniziata, confermata, posizioni iniziali
inserite, fase di gioco, partita finita, partita annullata) richiamando il metodo
opportuno in WSData.
Metodi LISTAPOSIZIONIINIZIALI(…),LISTAMOSSE(…): ritornano le liste delle posizioni iniziali
e le mosse di una partita, come stringhe opportunamente concatenate.
Metodo ESEGUIMOSSA(…): metodo che controlla la validità della mossa passata e la salva,
richiamando il metodo opportuno in WSData.
Metodo GENERAMOSSAIA (…): metodo che genera la mossa opportuna per l’Intelligenza
Artificiale e la salva, richiamando il metodo in WSData.
5.5 TABELLA ERRORI WEB SERVICE
Nella comunicazione verso i client, ogni web service usa una codifica di stringhe
create opportunamente per dare una rapida interpretazione dell’errore intercorso.
Viene qui riportata la tabella completa delle stringhe di errore:
75
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
ERR:
Errore generico, cattura di un’eccezione non prevista, serve per
catturare eventuali eccezioni del sistema non controllate direttamente o
non conosciute.
ERR:NOCONN
Errore di connessione, impossibile aprire una connessione al database.
ERR:INVALIDTOKENREQUEST
Errore del token. Token scaduto o inesistente.
ERR:NOTOKEN
Errore nella creazione del token, nessun utente o password errata.
ERR:NOUSER
Non esiste utente con quella username o, in caso di inserimento, l’utente
è già stato creato.
ERR:NOUPDATE
Errore in modifica del record. Possibile errore da cercare nella query,
infatti è usato in ultimo step.
Usato in WSUtenti
ERR:NODELETE
Errore in cancellazione record. Possibile errore da cercare nella query,
infatti è usato in ultimo step.
Usato in WSUtenti.
ERR:NOINSERT
Errore in inserimento record. Possibile errore da cercare nella query,
infatti è usato in ultimo step.
Usato in WSUtenti. Usato in WSGame, inserimento mosse, pos iniziali
ERR:NOFRIEND
Errore in lista Amici. Non ci sono amici per l’utente. La lista è vuota.
Usato in WSUtenti.
ERR:INVALIDUSERS
Utenti non validi per una partita. Usato in WSData, inserimento partita,
controllo nome match.
ERR:INVALIDMATCH
Match già esistente tra due giocatori. Creazione di un nuovo match non
valida. Usato in WSData, inserimento partita. Usato in WSGame, nuova
partita.
ERR:INVALIDMATCHNAME
Nome del match già usato da altri. Usato in WSData, inserimento partita.
ERR:NOMATCH
Nessun match disponibile con le credenziali date. Usato in WSData,
controllo nome match.
ERR:INVALIDROUND
Turno non valido per l’operazione richiesta. Usato in WSGame,
inserimento mossa.
5.6 USO DI STUB NEI CLIENT
Per meglio comprendere il livello di incapsulamento delle classi Stub e Skeleton,
vediamo nel dettaglio una chiamata eseguita a livello client verso un metodo gestito
da un servizio.
WSDATASTUB STUB = NEW WSDATASTUB();
WSDATASTUB.GETNOMEPARTITA PARTITASTUB = NEW WSDATASTUB.GETNOMEPARTITA();
PARTITASTUB.SETIDTOKEN(IDTOKEN);
PARTITASTUB.SETUSERNAME(USERNAME);
PARTITASTUB.SETUSERNAME_SFIDATO(USERNAME_SFIDATO);
WSDATASTUB.GETNOMEPARTITARESPONSE DATARESP=STUB.GETNOMEPARTITA(PARTITASTUB);
76
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
STRING
RETURN=DATARESP.GET_RETURN();
Questa chiamata prepara i parametri nella classe intermedia GetNomePartita e
chiama il metodo implementato nello Stub, che si occupa di contattare l’omonimo
metodo nello Skeleton del Server (attraverso la chiamata SOAP, incapsulando il
relativo envelope in un pacchetto HTTP) e restituire il valore di ritorno.
Le chiamate Stub generate con Axis 2 sono ad uso dei client che vogliono
interfacciarsi ai web service; nel progetto sono state usate anche all’interno dei web
service stessi (WSUtenti e WSGame) per le chiamate al servizio WSData quando si
doveva interagire con il database.
5.7 CLIENT ANDROID
Il Client sviluppato in Android si occupa dell’interfaccia con l’utente. I package che
compongono il Client sono visibili in Figura 5.5.
Figura 5.5: Package del client Android.
Il package principale è client, mentre gli altri sono importati da precedenti progetti
per la generazione delle mosse dell’Intelligenza Artificiale. Il package client è a sua
volta composto da ulteriori package, come si vede in Figura 5.6.
Figura 5.6: Package 'client'.
77
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Vediamo in dettaglio la descrizione dei package:
5.7.1 PACKAGE HANDLER
Figura 5.7: Package Handler - classi.
Il package handler contiene alcune classi che estendono le interfacce per la
personalizzazione di alcuni aspetti grafici, legati alla digitazione di un area di
inserimento testo o al cambio del focus tra un oggetto grafico e l’altro. Queste classi
vengono usate nei componenti che compongono la parte grafica del gioco, e sono
chiamati in più punti nelle finestre di gioco (Activity).
5.7.2 PACKAGE E XCEPTION
Figura 5.8: Package Exception - Classi.
In questo package è contenuta la classe EccezioneDialog, che viene lanciata per la
gestione controllata di tutte le eccezioni catturate durante l’esecuzione delle varie
fasi del gioco. Lo scopo principale di questa classe è quella di offrire un messaggio
che interpreti l’errore occorso e lo presenti all’utente in maniera facile da leggere e
da gestire. Laddove l’errore fosse grave, la classe ordinerà anche la chiusura
dell’applicazione, altrimenti si limiterà alla sola visualizzazione dello stesso. La
gestione dei vari errori e i messaggi da comunicare vengono gestiti grazie ad un
oggetto di classe GestioneErrore, alla quale viene affidato il compito di analizzare il
78
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
testo dell’errore catturato, decidere il messaggio da restituire e decretare la gravità
della situazione mediante una variabile intera.
EccezioneDialog class
Classe per la gestione controllata e visualizzazione degli errori catturati.
Metodi principali:
GETLIVELLOERRORE():
metodo che restituisce il livello di gravità dell’errore, dopo aver
interpretato il messaggio lanciato dal server o dall’eccezione gestita. Se l’errore sarà
grave, il valore di ritorno sarà >0, e decreterà la chiusura della finestra chiamante. In
caso di errore sconosciuto, il livello è ritenuto sempre grave.
metodo che disegna la finestra e
mostra il messaggio di errore interpretato. La finestra contiene un bottone che
scatena l’evento di chiusura della sola finestra (errore parziale o non grave), o anche
della finestra chiamante (errore grave).
DRAWDIALOG(MESSAGGIO:STRING, CONTESTO:CONTEXT):
GestioneErrori class
Questa classe si occupa di interpretare il messaggio d’errore e di valutarne la
gravità, se possibile.
Metodi principali:
GETLIVELLOERRORE():
metodo che restituisce il livello dell’errore interpretato.
SETLIVELLOERRORE(LIVELLO:INT):
metodo che forza il livello dell’errore, in caso di
interpretazione particolare. Viene usato se si vuole aumentare il livello di un errore
in un contesto in cui si ritiene necessario.
ANALIZZA():
metodo che interpreta l’errore arrivato e ne restituisce il messaggio
opportuno da mostrare all’utente.
5.7.3 PACKAGE POLLING
Figura 5.9: Package polling - classi.
Il package polling contiene tutti i thread che effettuano operazioni di polling, cioè
chiamate a intervalli regolari, verso il server. Le implementazioni delle chiamate ai
server non sono inserite dentro il package polling, ma all’interno delle classi
79
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
chiamanti, come da specifiche dell’SDK. Il modello prevede un insieme di classi
definite nel package android.os che implementa un meccanismo che comprende
una coda di messaggi condivisa dal main e worker thread. Il worker thread in questo
caso 'produce' i messaggi e il main thread li 'consuma'. Questi messaggi possono
tradursi in azioni, cioè il worker thread invia un messaggio che indica di settare un
valore ad un controllo grafico ed il main thread lo esegue. La classe principale che si
occupa di gestire questo meccanismo è android.os.Handler:
-
Il main thread (Activity) crea un'istanza dell'Handler ridefinendo il metodo
handleMessage(Message msg) dove vengono recapitati i messaggi;
Il worker thread invece ha un riferimento all'Handler ed ogni qualvolta deve
notificare un'azione invia un messaggio attraverso il metodo
sendMessage(Message msg) dell'oggetto Handler.
I thread contenuti nel package polling sono i worker thread: una volta avviati,
generano a intervalli prestabiliti dei messaggi che devono essere intercettati e
gestite all’interno della classe del chiamante. Il package contiene tre classi, che
rappresentano le tre fasi di polling gestite nel client.
Le classi sono:
ThreadSfidaAvversario class
Classe che genera il polling per sapere se si è stati sfidati da qualche altro utente
registrato.
Threadposizioniiniziali class
Classe che genera il polling per sapere se sono state inserite tutte le posizioni
iniziali, in modo da passare alla fase di gioco.
Threadturnomossa class
Classe che genera il polling per sapere se si possiede il turno per effettuare la mossa.
Dentro le classi sono implementati i metodi di start e stop del thread, mentre il
metodo NOTIFYMESSAGE(…) si occupa di generare il messaggio che verrà catturato
dall’handler all’interno della classe chiamante.
Tra le costanti, le più importanti sono TIME_POLLING, che gestisce l’intervallo di tempo
(in millisecondi) tra l’invio di un messaggio e il successivo, e TIMEMAX_POLLING, che
gestisce l’intervallo di tempo massimo (in millisecondi) di vita del Thread.
5.7.4 PACKAGE ANDROID
Il package android contiene le classi principali di interfaccia del gioco con l’utente e
gestione delle fasi di gioco. Le classi presenti in questo package rappresentano le
finestre mostrate all’utente e richiamano i metodi del server per il recupero delle
informazioni riguardanti l’utente e la partita. Ogni classe contiene le variabili e i
metodi d’uso inerenti alla finestra presentata.
80
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 5.10: Package android - classi, prima parte.
81
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 5.11: Package android - classi, seconda parte.
Le classi sono:
MainActivity class
Questa è la classe di avvio del gioco, contiene i bottoni per l’avvio delle azioni
principali:
-
-
Registrazione: con un click si crea una nuova Activity (REGISTRAZIONEACTIVITY) e
si accede all’area di registrazione di un nuovo utente.
Login: con un click si crea una nuova Activity (LOGINACTIVITY) e si accede
all’area di login / logout dell’utente registrato.
Profilo: con un click si crea una nuova Activity (PROFILOACTIVITY) e si accede
all’area personale dell’utente registrato.
Credits: con un click si crea una nuova Activity (CREDITSACTIVITY) e si accede
all’area di visualizzazione dei Credits, con l’elenco delle persone coinvolte
nel progetto.
Manuale: con un click si crea una nuova activity (MANUALEACTIVITY) e si accede
all’area contenente il manuale utente.
Metodi principali:
ONCREATE(…):
lanciato automaticamente all’evento di creazione della classe, inizializza
il layout grafico della finestra, compresi i bottoni inseriti e le immagini di sfondo,
82
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
inizializza le variabili principali e genera gli Handler per la gestione dei click sui
bottoni.
RegistrazioneActivity class
Questa è la classe di registrazione di un nuovo utente, contiene tutti i campi per
l’inserimento di un nuovo utente.
Metodi principali:
SALVADB(NOME:STRING, COGNOME:STRING, USERNAME:STRING, PASSWORD:STRING, EMAIL:STRING):
lanciato alla pressione del bottone di salvataggio del record, invia i dati inseriti (e
verificati) al servizio WSUtenti, che si occuperà di richiamare il servizio WSData per
il salvataggio sul database del nuovo utente.
CALLSERVER(SOAPACTION:STRING, METHOD:STRING, PARAMETRI:PROPERTYINFO[*],
: metodo che si occupa di creare fisicamente il pacchetto SOAP
per l’invio delle richieste al servizio richiesto. E’ un metodo generico, che viene usato
anche in altre classi; fa uso delle chiamate alla libreria KSOAP 2. Richiede come
parametri il nome del servizio e dell’operazione da contattare, e l’elenco dei
parametri da inviare. Ritorna una stringa dei risultati recuperati dal pacchetto di
ritorno SOAP.
LOGHEADER:STRING)
CreditsActivity class
Questa è la classe che visualizza i Credits del gioco. Essendo una classe richiamabile
dal menù principale, può essere vista anche da utenti non registrati.
ManualeActivity class
Questa è la classe che visualizza il manuale utente del gioco. Essendo una classe
richiamabile dal menù principale, può essere vista anche da utenti non registrati.
Istanzia una gallery a scorrimento di immagini con didascalie che illustrano le varie
fasi del gioco.
LoginActivity class
Questa è la classe attraverso la quale l’utente può effettuare il login e il logout dal
gioco. Vengono richiesti i parametri di username e password (nascosta). Una volta
confermati, la classe richiama il servizio WSUtenti per la verifica dei dati. Se tutto è
andato bene, l’utente ottiene un token di sessione, che viene salvato in una variabile
ambientale, visibile da tutte le classi del gioco.
Metodi principali:
LOGIN():
lanciato al momento del click sul bottone di login, chiama il servizio
WSUtenti, passando i dati immessi dall’utente per il controllo della validità della
login, e il recupero del token di sessione.
ProfiloActivity class
Questa è la classe di gestione del profilo utente. Contiene i dati anagrafici dell’utente,
inseriti in fase di registrazione, e richiamati dal servizio WSUtenti. Si occupa di
visualizzare l’elenco degli amici dell’utente e permette di accedere a due altre sottosezioni:
-
Sfida: scegliendo un utente dall’elenco e cliccando il bottone, si accede
all’activity che si occupa della sfida (SFIDAACTIVITY);
83
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
-
Amici: si entra nella sezione di controllo dell’elenco amici, per poter inserire
o eliminare altri utenti dalla propria cerchia di amicizia (CERCAAMICIACTIVITY).
Inoltre, gestisce il polling con il servizio WSUtenti per sapere se l’utente è stato
sfidato, lanciando un oggetto di classe THREADSFIDAAVVERSARIO.
Metodi principali:
CARICANOME(),CARICACOGNOME(),CARICAEMAIL():
metodi che recuperano i dati anagrafici
dell’utente dal servizio WSUtenti.
Metodo che recupera dal servizio WSUtenti l’informazione
riguardante l’utente selezionato dall’elenco degli amici. Se è una Intelligenza
Artificiale, predispone la richiesta di sfida all’Intelligenza Artificiale.
CARICAISIA():
SALVANOMEDB(),SALVACOGNOMEDB(), SALVAEMAILDB
():
metodi che inviano i dati modificati
dell’anagrafica al servizio WSUtenti.
POLLINGSFIDAAVVERSARIO():metodo
che istanza l’oggetto
thread per il controllo dello stato di sfidato.
THRSFIDAAVVERSARIO
e fa partire il
CercaAmiciActivity class
Questa è la classe di gestione delle amicizie dell’utente. Da questa classe è possibile
inserire nuovi amici, conoscendone lo username o selezionandolo da un elenco di
utenti online o preselezionati dal servizio WSUtenti.
Metodi principali:
CARICALISTAONLINE():
carica la lista degli utenti attualmente online e che possono
essere aggiunti come amici.
SALVAAMICODB(IN USERNAME_AMICO:STRING):
salva la nuova relazione di amicizia con
l’utente desiderato. Questo metodo viene lanciato al momento del click sul bottone
di salvataggio. Di norma, si comporta in questo modo. Se trova uno username
indicato nel box di testo, cerca di inserire quello, altrimenti cerca di inserire quello
dell’elenco degli utenti online. Il salvataggio vero e proprio è naturalmente delegato
al servizio WSUtenti (e di riflesso a WSData).
SfidaActivity class
Questa è la classe di interfaccia della sfida. In questa classe viene disegnato il tavolo
da gioco, vengono richiamati i metodi di gestione dei turni di sfida e dei turni di
gioco, vengono visualizzate le mosse sul tavolo, sia dell’utente che dell’avversario.
Infine, viene gestita l’eventuale vincita o perdita, mostrando un opportuno
messaggio e terminando la sfida. Questa classe viene chiamata quando si ha un
utente valido da sfidare, o se si conferma di accettare la sfida, nel caso di utente
sfidato.
Metodi principali:
NUOVASFIDA():
metodo che viene chiamato alla creazione della finestra per istanziare
correttamente le variabili di gioco e preparare il tavolo.
SALVANUOVAPARTITADB(IDTOKEN:STRING, NOMEPARTITA:STRING, GIOCATOREINIT:INT,
USERNAME:STRING, USERNAME_SFIDATO:STRING, LIVELLO1:INT, LIVELLO2:INT,
ALLENAMENTO1:BOOLEAN, ALLENAMENTO2:BOOLEAN):
metodo chiama il servizio WSGame
84
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
chiedendo di inserire la nuova sfida in database. Questo metodo viene richiamato
dallo sfidante, che per primo ha istanziato la sfida. Una volta che il record sarà
creato, anche l’utente sfidato verrà a conoscenza della sfida.
ABILITABOTTONI(),DISABILITABOTTONI(): Metodi che ripristinano lo stato dei bottoni e/o
azzerano i rispettivi tag (informazione interna dello stato logico del bottone) e
cambiano l’immagine impressa sul bottone. Vengono chiamati quando si deve
bloccare l’uso del tavolo o ripristinarne la funzionalità.
ABILITABOTTONEMOSSA(I:INT, J:INT),:
abilita il bottone alla mossa, e quindi a essere
cliccato.
IMPOSTAPOSINIZIALE(IN RESID:INT, IN I:INT, IN J:INT):
metodo che disegna nella
gestione delle posizioni iniziali , il bottone i-esimo/j-esimo, la tipologia di fantasma
scelto per il tipo di click effettuato o in base ai fantasmi già posizionati.
DISEGNAPOSIZIONIAVVERSARIO(POS:STRING[*]):
metodo che disegna le posizioni nel tavolo
grafico tramite un parametro in ingresso di tipo array di String, rappresentante
l’array delle pedine e delle relative posizioni.
SALVAPOSIZIONIINIZIALIDB(ABILITAIA:BOOLEAN):
metodo che salva le posizioni iniziali sul
database, richiamando il servizio WSGame. Se abilita è settato a true, il salvataggio
riguarda l’Intelligenza Artificiale.
POLLINGTHREADPOSINI():
metodo che istanzia il thread per il controllo dell’avvenuto
inserimento delle posizioni iniziali da parte dell’avversario. Questo metodo viene
lanciato nel momento della conferma di inserimento delle proprie posizioni, e
controlla lo stato dell’avversario. Nel frattempo l’utente è in attesa, e non potrà
avanzare finché l’avversario non avrà affettivamente inserito i suoi dati.
POLLINGTHREADTURNOMOSSA():
metodo che istanzia il thread per il controllo del turno della
mossa. Questo metodo viene lanciato nel momento della conferma di inserimento
della propria mossa, e controlla lo stato dell’avversario. Nel frattempo l’utente è in
attesa, e non potrà avanzare finché l’avversario non avrà affettivamente inserito i
suoi dati.
CHECKTURNODB():
metodo che chiede al servizio WSGame di conoscere di chi è il turno.
GESTISCIMOSSA(RESID:INT, I:INT, J:INT):
metodo che controlla il tipo di click effettuato
sul bottone e decidere se abilitare o meno la mossa.
MUOVI(SETTAMANGIATA:STRING):
metodo che muove la pedina da una posizione di partenza
ad una posizione di arrivo, aggiornando i dati del tavolo e visualizzando lo
spostamento.
MUOVITAVOLOLOGICO(IN MOSSAPARTENZA:STRING, IN MOSSAARRIVO:STRING):
metodo che esegue la
mossa sul tavolo logico, cambiando le pedine che riguardano il punto di partenza e
di arrivo della mossa.
MANGIA(TAG:INT):
metodo che effettua una mangiata del tipo definito dal tag,
aggiornando il tavolo.
MANGIA_AVV(TAG:INT):
metodo che effettua una mangiata avversaria del tipo definito dal
tag, aggiornando il tavolo.
85
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
SALVAMOSSADB(M1:STRING, M2:STRING, MANGIATA:STRING, MOSSAIA:BOOLEAN):
metodo che salva
la mossa effettuata nel database, richiamando il servizio WSGame. M1 rappresenta la
mossa di partenza, M2 la mossa di arrivo, MANGIATA è la stringa che identifica se c’è stata
la mangiata di una pedina nella mossa.
GETMOSSEDB():
metodo che recupera dal servizio WSGame l’elenco delle mosse inserite
nel database.
DISEGNAMOSSAAVVERSARIO():
metodo che disegna la mossa dell’avversario sul tavolo
grafico.
PREPARATAVOLOLOGICO():
Metodo usato nella preparazione della richiesta della mossa
dell’Intelligenza Artificiale. Prepara l’oggetto tavoloLogico, creando un “mapping” tra
il tavolo attuale e il tavolo da passare al servizio WSGame per l’analisi delle mosse e
la creazione di una mossa valida per l’Intelligenza Artificiale.
PRINTTAVOLOLOGICO():
Restituisce una stringa che rappresenta l’attuale disposizione
delle pedine nell’oggetto tavoloLogico.
IAGENERAPOSIZIONIINIZIALI():
metodo che si occupa della generazione delle posizioni
iniziali per l’Intelligenza Artificiale.
GETMOSSAIADB():
richiama il servizio WSGame per ottenere la mossa valida per
l’Intelligenza Artificiale, nel caso la sfida si stia giocando in single player.
IAGENERAMOSSA():
metodo generale per la gestione della mossa da parte
dell’Intelligenza Artificiale. Richiama altri metodi nel giusto ordine per preparare il
tavolo logico, controllare il turno, chiamare la generazione della mossa ed eseguirla.
SALVATIPODB():
metodo che salva il tipo di sfida nel database, chiamando il servizio
WSGame. In base alla fase di gioco, o alle decisioni prese dall’utente, il tipo della
sfida verrà cambiato con questo metodo.
CHECKFINE():
metodo che controlla se lo stato attuale del tavolo identifica la fine del
gioco. Il metodo è chiamato dopo l’inserimento di una mossa o l’arrivo di una mossa
avversaria.
PRINTMESSAGEBOARD(BOARDGIOCATORE:INT,
MESSAGGIO:STRING):
metodo
che
disegna
un
messaggio sulla Board del giocatore.
86
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
5.8 CLIENT SCREENSHOT
Vediamo ora una serie di screenshot del client Android, con una breve descrizione
delle varie finestre. La tabella seguente può sostituire il manuale utente per il client,
comunque presente all’interno del programma stesso sottoforma di immagini
corredate da didascalie di aiuto.
La finestra principale del Client Android presenta 6 bottoni:
Nuovo Utente: permette di entrare nella sezione di
registrazione di un nuovo utente;
Login: permette di entrare nella sezione di login in cui
inserire username e password di un utente già
registrato;
Gioca: si abilita solo dopo aver effettuato la login,
permette di entrare nella fase di scelta dell’utente
avversario e avvio della sfida;
Profilo: si abilita solo dopo aver effettuato la login,
permette di entrare nel profilo dell’utente e modificare i
relativi dati anagrafici;
Crediti: Visualizza una schermata con i dati di versione
del client installato e i contatti degli autori;
Manuale: Visualizza una finestra con una gallery di
immagini complete di didascalie per una rapida
comprensione delle principali funzionalità del client.
La finestra Crediti contiene le informazioni relative alla versione
del client installata e i contatti degli autori. E’ consigliato
controllare questa finestra ogni volta che si installa una nuova
versione del client, per avere conferma dell’avvenuta
installazione.
Il secondo passaggio consigliato è quello di aprire la finestra del
Manuale Utente. Il Manuale contiene una serie di immagini di
gioco accompagnate da brevi didascalie che aiutano l’utente nella
navigazione tra le varie finestre di gioco. La gallery si può
scorrere a destra e sinistra; ogni volta che si preme sopra una
delle piccole immagini poste in alto, viene richiamata l’immagine
ingrandita desiderata, completa di didascalie e descrizioni dei
comandi principali.
87
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Se non è mai stato creato l’utente, è possibile registrarne uno
nuovo dal menù principale, premendo in Nuovo Utente. I dati
richiesti riguardano il nome e cognome dell’utente, la username
univoca scelta e la relativa password, utili per entrare nel sistema,
ed una email a cui possono essere spedite comunicazioni
riguardanti il gioco stesso.
Una volta inserito l’utente è possibile effettuare la login,
inserendo i dati negli appositi campi della finestra Login Utente.
Sarà sempre possibile in seguito effettuare il logout per entrare
con un altro username, e usare il device con un altro profilo. I dati
inseriti con la login vengono comunque registrati e salvati nel
client, per permettere di connettersi più facilmente ai successivi
accessi al software.
Una volta che sia stata validata la login, si può accedere al proprio
profilo, dove sono ammesse alcune modifiche dell’anagrafica
comunicata nella fase di registrazione.
La finestra per l’introduzione al gioco viene abilitata solo a login
effettuata. Premendo il tasto Gioca dal menù principale si entra
nella finestra dove è possibile selezionare un amico e sfidarlo.
Essendo necessario conoscere l’utente sfidato, è possibile
aumentare l’elenco delle proprie conoscenze entrando nella
sezione Amici. Una volta scelto il proprio avversario, si può
avviare la sfida. L’elenco degli amici comprende anche le
intelligenze artificiali messe a disposizione dal sistema, ed
evidenziate nell’elenco con un’icona diversa (un omino per gli
utenti umani, un piccolo monitor per le intelligenze artificiali). Di
default, tutti gli utenti al primo accesso sono relazionati con
l’intelligenza principale chiamata “MasterIA”, in modo che sia
possibile iniziare a giocare anche se non si hanno ancora amici
umani da sfidare.
88
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Dal menù Amici è possibile aprire una finestra di gestione delle
amicizie. E’ possibile cercare un amico se si conosce il relativo
username esatto, oppure è possibile scegliere nell’elenco tra gli
utenti proposti dal sistema.
Inoltre, si possono eliminare relazioni di amicizia con utenti non
più graditi.
Essendo le intelligenze artificiali gestite come utenti veri e propri,
è possibile inserire o eliminare relazioni di amicizia con esse, per
giocare contro il computer secondo algoritmi di analisi diversi. Si
ricorda infatti che gli utenti IA presentati, rappresentano in
maniera intuitiva i vari algoritmi di analisi implementati
all’interno del servizio di gioco.
Una volta iniziata la sfida (per sfida creata, o in relazione ad una
risposta di sfida) è possibile inserire gli 8 fantasmini nelle
posizioni di partenza (4 rossi – cattivi, 4 blu - buoni). Per
procedere si possono toccare solo i bottoni bianchi. Con un tocco
si posiziona un fantasmino rosso, con due tocchi un fantasmino
blu, con tre tocchi si annulla la scelta. Se si sono posizionati già
quattro fantasmini dello stesso colore, gli altri bottoni saranno
vincolati ai fantasmini del colore mancante.
Una volta inseriti tutti i fantasmini è possibile confermare le
posizioni, premendo sul bottone che comparirà a posizionamento
completato.
Posizionati i fantasmini, c’è una fase di attesa per il
posizionamento dell’avversario. Quando tutti e due i contendenti
sono pronti, si passa alla fase di gioco dove, alternativamente,
ognuno dei giocatori può effettuare la mossa: si clicca sul
fantasmino da muovere, poi si clicca su uno dei bottoni adiacenti
e sottolineati in giallo. La mossa è possibile solo nelle posizioni a
nord, sud, est, ovest rispetto al fantasmino, e comunque non
sopra ai fantasmini della propria squadra. Se si vuole annullare la
mossa basta cliccare una seconda volta sul fantasmini scelto.
L’utente che ha il turno può controllare l’ultima mossa
dell’avversario tenendo premuto il tasto con l’icona degli occhiali.
Verranno evidenziate le due celle coinvolte dallo spostamento
avversario precedente. Le celle saranno sottolineate di giallo se il
movimento non ha comportato mangiate, oppure di rosso o blu se
è stato mangiato un fantasmino proprio del rispettivo colore.
Una volta effettuata la mossa si deve attendere che l’avversario
faccia altrettanto e si prosegue a fasi alterne per il resto della
gara.
89
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
A seconda del risultato della sfida viene mostrata una finestra che
comunica il successo o l’insuccesso della gara. Premendo il tasto
Esci si torna al menù di scelta del gioco o al proprio profilo. Se si
vuole, si può premere il bottone con la freccia Indietro del proprio
device per controllare lo stato finale della sfida. Non sarà più
possibile interagire con essa, ma può essere utile per studiare
l’ultima mossa che ha portato alla vittoria/sconfitta.
5.9 INTEGRAZIONE INTELLIGENZA ARTIFICIALE
Come detto in precedenza, lo studio e la progettazione degli strumenti utili per
l’integrazione di una Intelligenza Artificiale era stata portata avanti in precedenti
esperienze di stage. Il lavoro eseguito è stato quindi focalizzato sull’adattare e
riutilizzare il più possibile il codice a disposizione per non perdere la preziosa
esperienza acquisita precedentemente. I problemi principali da affrontare si
possono riassumere in questi punti:
-
-
-
Piattaforma originale molto diversa da quella attuale: il programma
precedente permetteva una completa integrazione degli oggetti all’interno
della logica di gioco, rendendo facile lo scambio dati tra parti client e parti
server per il recupero di informazioni preziose che servissero allo scopo. Il
sistema attuale, con una logica completamente separata e servizi stateless ha
richiesto lo sforzo ulteriore di re-ingegnerizzare il passaggio dati attraverso
la rete e verso i servizi di controllo, in modo da poter mantenere almeno i
metodi di generazione della mossa;
Dati salvati in log testuali: questa problematica non ha rappresentato uno
sforzo enorme, perché sono stati aggiunti i metodi opportuni di uso del
database all’interno del servizio WSGame. Il problema principale che si pone,
e sarà oggetto di studio futuro, è sulla forma dei dati raccolti: i dati testuali
infatti non avevano il problema di tabelle relazionate, ma in un’ottica di
ottimizzazione, alcune funzionalità andranno riscritte e opportunamente
legate a tabelle normalizzate.
Sviluppo difficoltoso: le soluzioni adattate soffrono di una notevole
complessità di analisi; la parte di lavoro sulle classi che integrano
l’Intelligenza Artificiale è stata solo adattata nel suo schema di base, ma è
sempre stata gestita come un prodotto prototipale, perché il suo sviluppo
coincide con la messa a regime del progetto attuale. Lo studio e la
raffinazione delle Intelligenze Artificiali (plurali in quanto legate alla
definizione di più algoritmi di analisi) è strettamente legato all’aumento
della raccolta delle partite tra giocatori. Perciò, il punto finale di questo
progetto si lega con l’inizio di una nuova fase di analisi dei dati raccolti.
90
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Le problematiche riscontrate non hanno impedito comunque di integrare nel
progetto due strutture fondamentali all’analisi delle partite e alla generazione di
mosse valide per l’Intelligenza Artificiale: il Learner e il Ranker.
5.9.1 LEARNER
Il Learner si occupa di analizzare i log delle partite avvenute e di creare i profili degli
utenti, caratterizzati da una serie di dati che rispecchiano le strategie intraprese
dagli utenti rispetto a delle caratteristiche che descrivono il gioco (features). In
particolare il software applica una serie di algoritmi di learning prestabiliti e genera
un profilo per ogni utente, per ognuno degli algoritmi.
Per la sua caratteristica intrinseca di asincronia rispetto al sistema client/server, la
fase di learning si presta ad essere gestita con un modulo a parte, che viva
esternamente alla piattaforma primaria e che possa essere implementata in maniera
indipendente, legata solo al database delle partite. Per questo motivo, questa fase è
stato separata dalle altre classi e inserita in un pacchetto standalone scritto in java,
chiamato LearnerServer.
La filosofia di questo pacchetto è quella di essere utilizzato solo nei momenti in cui si
ha bisogno di analizzare i log delle partite, per raffinare i profili degli utenti rispetto
alle partite pervenute.
5.9.2 LEARNER SERVER
Questo pacchetto esterno è composto dai package precedentemente sviluppati,
modificati opportunamente per l’integrazione con la piattaforma attuale. Il
LearnerServer è composto dai package visibili in Figura 5.12.
Figura 5.12: Package di LearnerServer.
Il package principale è apprendimento, che contiene il main e le classi principali per
l’analisi e la creazione dei profili. Il package utility contiene le classi di collegamento
al database, mentre il package logica contiene gli oggetti astratti che compongono il
gioco, dal tavolo ai pezzi, ai giocatori, ecc.
Questa parte del lavoro è stata sviluppata in altre tesi, e non verrà trattata in
dettaglio. Per capire il funzionamento del programma, vediamo uno scorcio delle
classi che compongono il package apprendimento.
91
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Figura 5.13: Package apprendimento - classi.
Vediamo un estratto del main del LearnerServer:
PUBLIC STATIC VOID MAIN(STRING[] ARGS)
{
FEATURECOLLECTOR FC = NEW FEATURECOLLECTOR();
FOR(INT I=0;I<18;I++){
FC.ADDFEATURE(NEW
MOSSEAVANTI());
}
LEARNER MEDIA=NEW MEDIAVETTORI(FC);
LEARNER MEDIA2=NEW MEDIAVETTORI2(FC);
LEARNEREXECUTOR L1=NEW LEARNEREXECUTOR();
L1.AGGIUNGILEARNER(MEDIA);
L1.AGGIUNGILEARNER(MEDIA2);
L1.EXECUTE();
}
Il main richiama un oggetto di classe FeatureCollector, che si occupa di collezionare
una serie di Feature da applicare agli algoritmi di learning. Successivamente
vengono istanziati gli oggetti relativi alle classi di learning. Possono essere creati
tanti algoritmi di analisi delle partite. Nel nostro caso viene creato un oggetto di
classe MediaVettori, ed uno di classe MediaVettori2. Questi vengono passati al
LearnerExecutor, che è la classe che “lancia” fisicamente l’analisi rispetto a tutte le
partite presenti, per ogni algoritmo caricato, per ogni utente coinvolto nelle singole
partite. Una volta lanciata l’analisi, la classe si collega al database per inserire nuovi
Learner nella tabella learners. Viene poi creata un’associazione tra un learner e il
ranker che dovrà usare i dati da esso prodotti, cercando prima il nome del ranker in
tabella rankers e poi creando una relazione tra i due in tabella learners_rankers.
Questa tabella esprime una relazione N a N tra i learner e i ranker, per poter avere
massima libertà di inserimento: un learner potrà essere gestito da più ranker, e un
ranker potrà analizzare più learner. A questo punto, per ogni utente presente nel
database, vengono analizzate tutte le partite in cui l’utente ha giocato. Vengono
scelte partite iniziate (con almeno una mossa effettuata), ma non necessariamente
terminate. Per ogni partita vengono eseguiti gli algoritmi di analisi caricati, e
preparati i vettori rappresentanti le caratteristiche di gioco del giocatore (a seconda
delle features caricate in precedenza). Ad analisi ultimata vengono inseriti (o
aggiornati) i record del profilo utente, per lo specifico learner, contenuti in tabella
profili_u_l_r.
92
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Il LearnerServer si presta molto bene ad una schedulazione di esecuzione che si
applichi a intervalli prestabiliti, non necessariamente sincronizzati.
5.9.3 RANKER
La classe Ranker è la classe adibita al ranking, ossia alla classificazione dei pezzi
durante la partita, è cioè la parte dell'apprendimento che potrà comunicare
all'Intelligenza Artificiale la previsione su quali siano i pezzi buoni e quali i pezzi
cattivi, basandosi su quelli attualmente in gioco. La classe è stata integrata dentro il
servizio WSGame, e viene richiamata quando un giocatore gioca contro l’Intelligenza
Artificiale. Per rendere fruibili più ranker all’utente si è scelto di associare il ranker
ad un utente fittizio, che una volta sfidato, richiamerà nel servizio la classe Ranker
specifica. L’utente vedrà nell’elenco degli amici o degli utenti sfidabili, anche le varie
Intelligenze Artificiali, che faranno da alias a classi Ranker costruite appositamente
nel server. Attualmente è presente un solo ranker, e l’utente di riferimento è
chiamato MasterIA.
L’estratto di codice seguente mostra come la classe IntelligenzaArtificiale,
implementata nel servizio WSGame dentro il metodo generaMossaIA(…) chiami il
Ranker e passi i dati della partita e del tavolo attuale:
PUBLIC INTELLIGENZAARTIFICIALE(TAVOLO T, DOUBLE LIV,DOUBLE LIVAVV, GIOCATORE GIOC_CORR,
GIOCATORE AVV, VECTOR<STRING> EUR, LEARNER LEARNER,STRING NOMEPAR){
TAV = T;
LIVELLO=LIV;
LIVELLOAVVERSARIO=LIVAVV;
GIOCATORE_CORRENTE = GIOC_CORR;
AVVERSARIO = AVV;
EURISTICHE=EUR;
NOMEPARTITA=NOMEPAR;
PROFILO = NEW RANKER(TAV,GIOC_CORR,AVV,LIVELLOAVVERSARIO,LEARNER,NOMEPARTITA);
ATTIVAPROFILO(TRUE);
}
Il Ranker recupera le informazioni della partita dal chiamante, e successivamente
estrae dal database il profilo dell’utente stesso(con il metodo OTTIENIPROFILO(…)). In
base all’algoritmo da applicare, estrae dal profilo la stringa descrittiva dell’utente
per l’algoritmo scelto, e poi applica l’algoritmo per generare la mossa da suggerire.
5.10 TEST
Sono stati eseguiti test dinamici di funzionalità sia per la parte Server che per la
parte Client. Per quanto riguarda i web service, per ogni operazione esposta è stato
creato il relativo client Stub che chiama il servizio e ne testa la funzionalità passando
direttamente i parametri opportuni e analizzando la risposta. I client Stub sono stati
in parte usati per le chiamate dei servizi WSUtenti e WSGame a WSData, ma fanno
parte comunque di pacchetti separati utilizzabili per ulteriori analisi. Non sono stati
effettuati per problemi di tempo i test automatici con strumenti come JUnit.
Per la parte Client i test si sono concentrati sull’uso delle interfacce e l’analisi dei log.
E’ stato utilizzato lo strumento di emulazione di terminali Android (Android Virtual
Device) fornito insieme all’SDK e richiamabile da Eclipse.
93
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
L’uso di due emulatori attivi in contemporanea ha permesso di testare efficacemente
la simulazione di varie partite tra due utenti diversi. Inoltre, il vantaggioso ambiente
di sviluppo ha permesso di seguire passo-passo ogni singola chiamata attraverso
messaggi visibili nella console di debug. Si sono testate anche partite in single player
contro l’Intelligenza Artificiale, e sono stati corretti i primi bug legati soprattutto
all’interfaccia nel Client. I test di funzionalità non si possono definire conclusi: le
molteplici soluzioni sviluppate portano alla luce una serie di problematiche software
e hardware che vanno seguite con costanza. Nonostante questo, la realizzazione di
un pacchetto client/server piuttosto stabile ha permesso di installare i web service
in una macchina8 di testing, ospitata nei server del Dipartimento di Matematica, e
configurata con Apache Tomcat 6 e MySQL 5.5. Il client a sua volta è stato distribuito
ad un primo gruppo di utenti selezionati, che hanno testato il software su
smartphone dotati di Android 2.3 e tablet dotati di Android 3.2, e hanno raccolto
impressioni e bug in una mailing list9 comune. Per fornire loro un client sempre
aggiornato con le ultime modifiche, si è scelto di esporre il pacchetto di installazione
in un sito dedicato al progetto10, dove è possibile anche essere aggiornati sugli
sviluppi e sulle informazioni generali dello stesso.
Dopo un primo periodo di gioco, i dati raccolti nel database sono stati analizzati per
determinare in modo tangibile l’efficacia degli algoritmi di learning e ranking
applicati all’Intelligenza Artificiale. I dati si riferiscono allo studio di un campione di
30 partite, raccolte tra diversi utenti. I seguenti grafici espongono le percentuali di
vittoria/sconfitta dell’Intelligenza Artificiale nelle partite analizzate, mostrando in
percentuale, la quantità di partite vinte e perse rispetto al totale delle partite
analizzate, e i relativi motivi di vittoria e sconfitta, sempre in percentuale.
Performance Intelligenza Artificiale
56,7%
43,3%
Vinte
Perse
Figura 5.14: Grafico performance Intelligenza Artificiale.
Come si vede in Figura 5.14 l’Intelligenza Artificiale ha saputo tenere testa ai
giocatori umani, arrivando per il 43% dei casi alla vittoria.
Indirizzo Server di test: semenzato.math.unipd.it
Mailing List: http://groups.google.com/group/geister-per-android
10 Sito del progetto: https://sites.google.com/site/geisterandroid/
8
9
94
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Analisi VITTORIA Intelligenza Artificiale
23,1%
23,1%
ESCE DA CANCELLO
MANGIA BLU AVVERSARI
SI FA MANGIARE ROSSI
53,8%
Figura 5.15: Grafico analisi vittoria Intelligenza Artificiale.
Analisi SCONFITTA Intelligenza Artificiale
35,3%
64,7%
AVVERSARIO ESCE DA CANCELLO
MANGIA ROSSI AVVERSARI
Figura 5.16: Grafico analisi sconfitta Intelligenza Artificiale.
Nei due grafici precedenti vengono mostrati i motivi per cui l’Intelligenza Artificiale
ha vinto (Figura 5.15) e perso (Figura 5.16): è possibile notare come le percentuali
maggiori siano legate ad un atteggiamento dell’Intelligenza Artificiale volto a
mangiare le pedine avversarie, sia in termini positivi che negativi.
Nel tentativo di analizzare il comportamento dell’Intelligenza Artificiale nella fase di
ranking, cioè nella fase di valutazione della bontà dei fantasmi avversari, si è
proceduto con l’analisi delle singole mosse presenti in tutte le partite di un
campione scelto. Per analizzare l’accuratezza nella valutazione dei pezzi, si è scelto
un campione di partite di un singolo giocatore e si è proceduto alla simulazione di
ogni singola mossa in ogni partita: è stato “chiesto” all’Intelligenza Artificiale di
valutare ogni singola mossa, ripercorrendo passo-passo tutte le fasi della partita. Per
ogni mossa, l’Intelligenza Artificiale ha estratto le informazioni riguardanti la bontà
dei pezzi avversari residenti sul tavolo in quel momento. Ogni singola valutazione
estratta è stata messa a confronto con le reali caratteristiche del pezzo in analisi, per
scoprire se la valutazione fatta fosse corretta.
Le partite sono state analizzate a gruppi di 5, 10, 15, 20, 25 e 30 alla volta. Per ogni
gruppo sono state scelte n-1 partite per effettuare l’apprendimento e creare un
profilo utente, grazie al quale si è provveduto ad analizzare l’n-esima partita
(rimasta esclusa dal gruppo di apprendimento). Con questa strategia sono state
testate a rotazione tutte le n partite del gruppo, e sono state prese le medie di
95
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
accuratezza nella valutazione dei pezzi buoni da parte dell’Intelligenza Artificiale. Il
grafico in Figura 5.17 rispecchia l’andamento medio per ogni gruppo, esprimendo il
tasso di errore nella valutazione dei pezzi (in numero di pezzi errati medio di una
partita), rispetto al numero di partite usate per la creazione del profilo. Come si può
vedere, aumentando il numero di partite nella fase di apprendimento e creazione del
profilo (learning), si hanno meno errori nella valutazione della bontà dei singoli
pezzi (ranking).
30,00
29,50
29,00
28,50
28,00
27,50
27,00
26,50
26,00
25,50
25,00
0
Errori
valutazione
pezzi buoni
Grafico di accuratezza
n° pezzi errati
5
10
15
20
25
30
n° partite usate
35 nella fase di learning
Figura 5.17: Grafico accuratezza nella valutazione dell'IA della bontà dei pezzi avversari.
La successiva analisi ha interessato la valutazione della resistenza al rumore
presente nella gestione della fase di ranking. Sono state prese in considerazioni 30
partite di più giocatori, e valutate le singole mosse di ogni partita. A differenza
dell’analisi precedente, qui il profilo era fisso per giocatore; ciò che invece variava
era la quantità di rumore presente nella fase di ranking. Si è cercato di capire se
l’applicazione del rumore nella valutazione dei pezzi potesse condizionarne la resa.
Per fare questo, è stato ripetuta l’analisi in quattro casi diversi:
-
Profilo senza rumore: caso presunto ottimale, rumore assente e stima di
bontà dei pezzi aderente alla bontà teorica prevista dall’algoritmo di
ranking;
Profilo con rumore medio: introduzione di un errore random di grado
medio;
Profilo con rumore massimo: introduzione di un errore random di grado
massimo;
Profilo assente: azzeramento totale delle informazioni del profilo. Simula la
condizione iniziale di ogni giocatore, quando non ci sono partite presenti nel
database e il profilo dell’utente non denota alcuna caratteristica emergente;
in questo caso la bontà dei pezzi è una stima fortemente condizionata dalla
casualità.
L’analisi ha fatto emergere i risultati visibili nel grafico seguente.
96
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
n° pezzi errati
Grafico resistenza al rumore
285
280
275
270
265
260
255
Profilo senza rumore Profilo con rumore
medio
Profilo con rumore
massimo
Profilo assente
Figura 5.18: Grafico dell’errore medio nella valutazione di bontà dei pezzi avversari.
Nel grafico in Figura 5.18 possiamo vedere l’errore medio di valutazione della bontà
dei pezzi avversari (in numero di errori medio nel campione), suddiviso rispetto alle
categorie sopra citate. E’ interessante notare come l’errore aumenti in maniera
significativa all’aumentare del rumore applicato agli algoritmi di valutazione.
L’ultima colonna, rispecchiante la valutazione senza profilo applicato, esprime la
condizione di ingresso standard per tutti gli utenti, e risulta essere la peggiore in
termini di efficacia.
97
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
98
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 6. CONCLUSIONI
In questo capitolo verranno illustrate le conclusioni del progetto, le impressioni
personali e gli sviluppi futuri.
6.1 CONSIDERAZIONI PERSONALI
Ho affrontato il progetto con entusiasmo sin dalle sue fasi iniziali. La sfida
rappresentata dall’uso di strumenti per me assolutamente nuovi, come web service
e Android, in un contesto di piattaforma per il gioco, mi ha coinvolto da subito. Il
progetto ha offerto la possibilità di mettermi alla prova in un ambiente in cui non
avevo esperienza, forzandomi a dare il massimo per raggiungere il risultato
prefissato con i tempi stabili. Questa alchimia di variabili è stata la molla per
affrontare intensamente il periodo di stage. Il lavoro si è articolato con una grossa
fase di studio iniziale, indispensabile per mettere insieme le conoscenze e affinare
gli strumenti per un buon prosieguo. L’analisi della complessa implementazione dei
web service è andata a rilento. L’impressione che ho avuto è stata quella di studiare
un campo ancora aperto a continui sviluppi: è capitato infatti di porre le basi per
l’uso di strumenti che poi si sono rivelati già vecchi o abbandonati (Axis 1.x). I web
service sono largamente usati, ma le continue modifiche e la frammentazione delle
soluzioni proposte dalle varie aziende non facilitano lo studio dei concetti base.
Nonostante questo devo dire che i pacchetti utilizzati si sono comportati secondo le
aspettative, e gli errori fatti si possono inquadrare in un normale iter di
apprendimento. Oggi mi sento più formato su questo campo e la cosa decisamente
positiva è che confermerei le scelte fatte a inizio stage, quando il quadro della
situazione non era ancora completo.
Per quanto riguarda la scelta del client è stata per me una fonte di divertimento e di
soddisfazione lavorare con Android e il suo SDK. Devo dire che ho apprezzato fin da
subito la logica di lavoro e le librerie messe a disposizione. Tutto è andato per il
meglio e l’ambiente integrato in Eclipse offre un strumento di sviluppo potente, ma
facile da gestire. Il punto dolente riguarda la tempistica non ben distribuita: avendo
investito più tempo nello studio e nell’implementazione dei web service, che
comunque giustifico perché si tratta pur sempre del cuore del sistema,
l’implementazione del client è stata forse un po’ frettolosa. Il client è migliorabile
anche sotto il profilo grafico. Non mi sono trovato del tutto a mio agio con la
creazione dei layout, anche se apprezzo molto che la costruzione degli stessi sia
stata pensata con file XML.
Per quanto concerne il riuso di codice proveniente dai lavori precedenti, mi sono
trovato in difficoltà da subito. I lavori svolti sono stati eccellenti sotto tanti profili,
ma l’interpretazione del codice scritto e lo studio dei pacchetti richiedeva una
profondità di studio e di tempo che non avevo a disposizione. Ho deciso quindi di
recuperare la logica di gioco, sposandone spesso la filosofia, ma magari riscrivendo
il codice adattato per la piattaforma di gioco che stavo costruendo. A volte il
tentativo di riuso si è rivelato semplicemente impossibile: la logica fortemente
client/server di questo lavoro mi ha costretto a separare le chiamate e a dividere gli
oggetti, che nel contesto precedente usufruivano di relazioni del tutto differenti. Ho
99
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
comunque fatto tesoro del lavoro dei colleghi, e ne ho approfittato ampiamente nella
gestione dell’Intelligenza Artificiale, che altrimenti sarebbe stata impossibile da
implementare, vista la vastità e la complessità degli algoritmi esposti.
A conclusione di tutto posso dire di essere soddisfatto, ma ritengo questo lavoro
ancora migliorabile e tuttora in fase di sviluppo. Quello che per me è fondamentale è
aver gettato le basi per una piattaforma che possa essere specializzata in ogni sua
parte in maniera autonoma, senza dover interferire troppo tra client e server o tra
servizio e servizio.
6.2 SVILUPPI FUTURI
Il progetto si trova in una fase abbastanza avanzata. Ciò nonostante, sono sorte in
corso d’opera delle nuove problematiche che potrebbero permettere un futuro
sviluppo dell’applicazione. L’obiettivo primario è dare continuità al progetto,
usando le basi poste in questa fase per mettere in produzione una struttura stabile
ed efficace. Per quanto riguarda gli strumenti creati, le potenzialità di sviluppo sono
molteplici:
-
I web service sono completi, ma ne andranno testate le funzionalità nella
piattaforma di test installata per l’occasione;
Per la parte client, in ottica di mettere a disposizione un prodotto stabile e
funzionante, e per questo accattivante, sarà necessario completare i test di
funzionalità del pacchetto, gestire eventuali eccezioni, aumentare i feedback
all’utente e migliorare la giocabilità. Inoltre, come si vedrà dal piano di
lavoro, alcuni obiettivi sono stati trascurati. Bisognerà vedere se integrarli in
questa prima fase, o se andare in testing con un prototipo stabile e inserire
eventuali altre funzionalità in una seconda riprogettazione, seguendo il
modello incrementale come ciclo di vita del software.
Gli sviluppi futuri veramente auspicabili riguardano l’Intelligenza Artificiale. Come
già detto, l’entrata a regime dell’attuale progetto coinciderà con l’inizio di una nuova
fase, atta a implementare nuovi algoritmi di Intelligenza Artificiale a partire dalle
partite svolte. In questo scenario, bisognerà dar seguito alle eventuali modifiche da
apportare alla struttura server per accogliere i nuovi modelli di learning e di
ranking.
Ulteriori sviluppi possono coinvolgere la parte sociale del gioco, inserendo metodi di
login ausiliari e più diffusi (utilizzando le login di social network come Facebook o
Twitter), e creando nuovi obiettivi di sfida (classifiche generali, punti premio,
diverse Intelligenze Artificiali a diversi livelli di difficoltà, ecc.).
100
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 7. PIANO DI LAVORO
A conclusione dell’attività svolta, si va ora ad analizzare e valutare la distribuzione
dell’orario nelle fasi di lavorazione: verranno evidenziate le principali di differenze
riscontrate tra i risultati finali ottenuti e le aspettative iniziali.
Vediamo in tabella un riepilogo dell’attività svolta:
Attività
Ricerca tecnologie utilizzabili
Studio iniziale e apprendimento piattaforma web service
Studio iniziale e apprendimento piattaforma Android
Analisi dei requisiti
Studio contesto e individuazione funzionalità da realizzare
Progettazione e Realizzazione del Server
Progettazione del database
Progettazione del servizio Utenti
Progettazione del servizio Dati
Progettazione del servizio Gioco
Realizzazione del database
Realizzazione del servizio Utenti
Realizzazione del servizio Dati
Realizzazione del servizio Gioco
Progettazione e Realizzazione del Client
Progettazione finestre di gioco e grafica
Progettazione eventi di chiamata ai servizi
Progettazione logica di gioco lato client
Realizzazione finestre di gioco e grafica
Realizzazione eventi di chiamata ai servizi
Realizzazione logica di gioco lato client
Verifica e testing
Documentazione aggiuntiva (client e documentazione ai servizi)
Totale
Ore
preventivate
Ore
effettuate
30
30
40
30
20
20
10
10
10
20
10
20
20
30
10
15
15
25
8
20
20
30
10
10
10
10
5
10
25
30
320
10
10
8
8
5
8
20
25
327
Come evidenziato dal rendiconto in tabella, l’orario totale di lavoro effettivamente
svolto è stato pressoché in linea con quanto preventivato, fatto salvo per una
differenza di 7 ore in più. Ciò che invece è stato modificato è il bilanciamento delle
fasi interne: la fase di analisi e sviluppo dei web service ha tolto risorse alle altre
fasi, riducendo in maniera significativa la fase finale di test e produzione di
documentazione, e coinvolgendo parzialmente anche lo sviluppo del client. Vediamo
con il grafico in Figura 7.1 lo sbilanciamento delle varie fasi:
101
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Distribuzione fasi
Ore preventivate
Ore effettuate
350
300
250
200
150
100
50
0
Figura 7.1: Grafico distribuzione delle fasi.
102
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
La parte conclusiva riporta l’elenco dei requisiti, evidenziando con una diversa
colorazione i requisiti soddisfatti (colore verde – targhetta OK), parzialmente
soddisfatti(arancio– targhetta ok) o disattesi (colore rosso – targhetta KO).
Obbligatori
Ob01Ob02Ob03Ob04Ob05Ob06Ob07Ob08Ob09Ob10Ob11-
OK - Studio dei servizi da esporre come web service (server);
OK - Creazione di un client sviluppato per ambiente Android (client);
OK - Raccolta dati relativi ad utenti, partite e log in database (server);
OK - Gestione logica di gioco server e risposta alle richieste di mossa del client (client/server);
OK - Visualizzare schermata di presentazione all’avvio della partita (client);
OK - Possibilità di login o creazione nuovo utente (client/server);
OK - Possibilità di sfidare gli amici (client);
OK - Mascheramento dei fantasmi avversari durante il match (client);
OK - Visualizzazione delle mosse permesse per il fantasma scelto (client);
OK - Visualizzazione dei fantasmi mangiati e relativo tipo (client);
OK - Presenza del manuale per spiegare il funzionamento del gioco (client);
Desiderabili
De01De02De03De04-
OK - Presenza di una breve sezione di credits con storia e sviluppi del gioco (client);
OK - Possibilità di scelta dell’avversario tra umano e IA (client);
OK - Possibilità di sfidare qualsiasi utente connesso (client);
ok - Presenza di una pagina profilo con amici e statistiche (client);
Opzionali
Op01- KO - Possibilità di richiedere pareggio all’avversario (client);
Op02- OK - Possibilità di accettare o rifiutare sfida (client);
Op03- OK - Gestione di opportuni time-out per la chiusura della mossa o della partita
(client/server);
Op04- KO - Suggerimenti di gioco per utente umano da IA (client/server);
Op05- OK - Visualizzazione di un indicatore di attesa mossa dell’avversario (client);
Op06- KO - Visualizzazione del countdown del timer per la mossa (client);
Op07- ok - Visualizzazione a fine partita di una schermata riassuntiva dei risultati (client);
Op08- ok - Studio di una strategia di incentivo al gioco (client/server);
Op09- KO - Creazione di un client con linguaggio a scelta, ma diverso da Android (client);
Concludendo, il lavoro svolto è stato ridistribuito nelle sue fasi interne, ma ha
prodotto i risultati attesi nei tempi richiesti.
103
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
104
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 8. GLOSSARIO
API
Application Programming Interface API (Interfaccia di Programmazione di
un'Applicazione) si indica ogni insieme di procedure disponibili al
programmatore, di solito raggruppate a formare un set di strumenti specifici per
l'espletamento di un determinato compito all'interno di un certo programma.
HTTP
HyperText Transfer Protocol (HTTP) (protocollo di trasferimento di un ipertesto)
è usato come principale sistema per la trasmissione d'informazioni sul web. Le
specifiche del protocollo sono gestite dal World Wide Web Consortium (W3C). Un
Server HTTP generalmente resta in ascolto sulla porta 80 usando il protocollo
TCP.
JDBC
(Java DataBase Connectivity)[1], è un connettore per database che consente
l'accesso alle basi di dati da qualsiasi programma scritto con il linguaggio di
programmazione Java, indipendentemente dal tipo di DBMS utilizzato. È
costituita da una API, raggruppata nel package java.sql, che serve ai client per
connettersi a un database. Fornisce metodi per interrogare e modificare i dati. È
orientata ai database relazionali ed è Object Oriented. La piattaforma Java 2
Standard Edition contiene le API JDBC, insieme all'implementazione di un bridge
JDBC-ODBC, che permette di connettersi a database relazionali che supportino
ODBC. Questo driver è in codice nativo e non in Java.
MIDDLEWARE
Con il termine inglese middleware si intende un insieme di programmi
informatici che fungono da intermediari tra diverse applicazioni e componenti
software. Sono spesso utilizzati come supporto per sistemi distribuiti complessi.
OASIS
Organizzazione per lo sviluppo di standard sull'informazione strutturata.
http://www.oasis-open.org/
PLUGIN
Il plugin in campo informatico, è un programma non autonomo che interagisce
con un altro programma per ampliarne le funzioni. La capacità di un software di
supportare i plugin è generalmente un'ottima caratteristica, perché rende
possibile l'ampliamento e la personalizzazione delle sue funzioni da parte di terzi,
in maniera relativamente semplice e veloce.
POLLING
In ambito informatico il termine Polling viene utilizzato per riferirsi a quella
richiesta, che viene fatta in un intervallo di tempo periodico, riguardante la
disponibilità o la variazione di un componente con l'obiettivo di fare in modo che
ci possa essere una eventuale interazione con lo stesso, in un momento
successivo. In generale, questo termine è utilizzato come una metafora per la
descrizione dell'azione di colui che tenta di mettersi in contatto in maniera ciclica
con una entità per capire se è disponibile.
105
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
RDBMS
Il termine Relational database management system (RDBMS) (sistema per la
gestione di basi di dati relazionali) indica un database management system
basato sul modello relazionale.
SOA
Nell'ambito dell'informatica, con la locuzione inglese di Service-Oriented
Architecture (SOA) si indica generalmente un'architettura software adatta a
supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi sistemi
così da consentire l'utilizzo delle singole applicazioni come componenti del
processo di business e soddisfare le richieste degli utenti in modo integrato e
trasparente.
SOAP
SOAP (inizialmente acronimo di Simple Object Access Protocol) è un protocollo
leggero per lo scambio di messaggi tra componenti software, tipicamente nella
forma di componentistica software. La parola object manifesta che l'uso del
protocollo dovrebbe effettuarsi secondo il paradigma della programmazione
orientata agli oggetti. SOAP è la struttura operativa (framework) estensibile e
decentralizzata che può operare sopra varie pile protocollari per reti di
computer. I richiami di procedure remote possono essere modellizzati come
interazione di parecchi messaggi SOAP. SOAP dunque è uno dei protocolli che
abilitano i servizi Web.
SOCKET
In informatica, nei sistemi operativi moderni, con il termine socket si indica
un'astrazione software progettata per poter utilizzare delle API standard e
condivise per la trasmissione e la ricezione di dati attraverso una rete oppure
come meccanismo di IPC. È il punto in cui il codice applicativo di un processo
accede al canale di comunicazione per mezzo di una porta, ottenendo una
comunicazione tra processi che lavorano su due macchine fisicamente separate.
Dal punto di vista di un programmatore un socket è un particolare oggetto sul
quale leggere e scrivere i dati da trasmettere o ricevere.
STORED PROCEDURE
Una stored procedure è un programma scritto in SQL od in altri linguaggi,
mantenuto nel database stesso, archiviato nel cosiddetto database data
dictionary. Spesso è scritta in versioni proprietarie di SQL, che sono dei veri e
propri linguaggi strutturati, come il PL/pgSQL di PostgreSQL o il PL/SQL di
Oracle, all'interno dei quali è possibile scrivere codice SQL.
TCP/IP
In informatica e telecomunicazioni la suite di protocolli Internet è un insieme di
protocolli di rete su cui si basa il funzionamento della rete Internet. A volte, per
sineddoche, è chiamata suite di protocolli TCP/IP, in funzione dei due più
importanti protocolli in essa definiti: il Transmission Control Protocol (TCP) e
l'Internet Protocol (IP).
UDDI
L'UDDI (acronimo di Universal Description Discovery and Integration) è un
registry (ovvero una base dati ordinata ed indicizzata), basato su XML ed
indipendente dalla piattaforma hardware, che permette alle aziende la
pubblicazione dei propri dati e dei servizi offerti su internet. UDDI, un'iniziativa
106
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
"open" sviluppata tra il 1999 ed il 2000 e sponsorizzata dall'Organization for the
Advancement of Structured Information Standards (consorzio internazionale per
lo sviluppo e l'adozione di standard nel campo dell'e-business e dei web service
spesso indicato anche come OASIS), permette la scoperta e l'interrogazione dei
servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne.
URI (URN - URL)
Un URL (Uniform Resource Locator) è un URI che, oltre a identificare una risorsa,
fornisce mezzi per agire su o per ottenere una rappresentazione della risorsa
descrivendo il suo meccanismo di accesso primario o la sua "ubicazione"
("location") in una rete. Per esempio, l'URL http://www.unipd.it/ è un URI che
identifica una risorsa (l'home page di Unipd) e lascia intendere che una
rappresentazione di tale risorsa (il codice HTML della versione corrente di tale
home page) è ottenibile via HTTP da un host di rete chiamato www.unipd.it. Un
URN (Uniform Resource Name) è un URI che identifica una risorsa mediante un
"nome" in un particolare dominio di nomi ("namespace").
WSDL
Il Web Services Description Language (WSDL) è un linguaggio formale in formato
XML utilizzato per la creazione di "documenti" per la descrizione di web service.
XML
XML (sigla di eXtensible Markup Language) è un metalinguaggio di markup,
ovvero un linguaggio marcatore che definisce un meccanismo sintattico che
consente di estendere o controllare il significato di altri linguaggi marcatori.
XML-SCHEMA
L'XML Schema o Schema XML è l'unico linguaggio di descrizione del contenuto di
un file XML che abbia per ora raggiunto la validazione (la 1.1) ufficiale del W3C.
Come tutti i linguaggi di descrizione del contenuto XML, il suo scopo è delineare
quali elementi sono permessi, quali tipi di dati sono ad essi associati e quale
relazione gerarchica hanno fra loro gli elementi contenuti in un file XML. Ciò
permette principalmente la convalida del file XML, ovvero la verifica che i suoi
elementi siano in accordo con la descrizione in linguaggio XML Schema.
107
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
108
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 9. BIBLIOGRAFIA
9.1 LIBRI
Concetti di informatica e fondamenti di Java 2 – Cay S. Horstmann – Apogeo
Developing Web Services with Apache CXF and Axis2 - Kent Ka Iok Tong – TipTec
Development
Android Programming – PuntoInformatico – Edizioni Master
9.2 SITI
Homepage ufficiale Java
http://www.java.com
Riferimento italiano per guide e articoli
http://www.html.it
Articolo sull’uso di Dalvik
http://www.redsend.org/2011/05/04/android-dalvik-virtual-machine/
Uso di KSOAP2 in Android
http://people.unica.it/bart/2010/12/03/ksoap2-patch-for-user-defined-objects-andarrays/
Homepage progetto KSOAP2
http://code.google.com/p/ksoap2-android/
Articolo sull’uso di AXIS2
http://www.adriani.altervista.org/author/stuff/05_AXIS2_quick_start.pdf
Articolo su hashing della password e relativo passaggio in rete
http://phpsec.org/articles/2005/password-hashing.html
Breve articolo sull’uso di web service stateless
http://programmazione.html.it/guide/lezione/5241/stateless-autodefinizione-ecollegamenti-tra-risorse/
Slides e materiale su web service, approfondimenti su linguaggi e rete
http://www.dis.uniroma1.it/~degiacom/
Slide introduttive ai web service
http://www.slideshare.net/AndrewRiot/lezione-8-introduzione-ai-web-service
109
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Articolo illustrativo su web service
http://java.html.it/articoli/leggi/3017/tomcat-web-server-o-application-server
Tutorial per l’utilizzo di Axis2 per la generazione di web service
http://www.eclipse.org/webtools/community/tutorials/BottomUpAxis2WebService/bu_tut
orial.html
http://www.eclipse.org/webtools/jst/components/ws/1.5/tutorials/TopDownWebService
/TopDownWebService.html
Articolo sull’analisi architetturale di SOAP
http://www.devx.com/java/Article/30459/1954
Articolo sull’approccio ai thread e alle GUI in Android
http://www.simplesoft.it/android/gestire-thread-e-gui-nelle-applicazioni-android.html
Vari link a comunità di sviluppo per Android
http://androidforums.com
http://www.anddev.it
http://www.simplesoft.it/android
110
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
Capitolo 10. RINGRAZIAMENTI
Il giorno in cui decisi di iscrivermi all’Università ero consapevole di affrontare
un’avventura molto importante per la mia crescita. Si trattava di un ambizioso
progetto di vita, le cui sorti dipendevano dalle mie capacità e i cui risultati avrebbero
richiesto molto tempo e molta fatica. Mi sono sempre imposto una certa disciplina,
impegnandomi un passo alla volta, a testa bassa, senza cedere, mettendo tutte le ore
libere a disposizione per lo studio. Ho scoperto di potercela fare, ho dovuto credere
di potercela fare, per andare oltre gli ostacoli e le paure, per lavorare sui miei limiti,
e spostarli ogni volta un po’ più in là. A volte ho fantasticato sulla metafora della
scalata, sulle fatiche di andare un passo alla volta verso la vetta, sorretto dalla voglia
di vedere cosa il mondo mi offrirà una volta arrivato in cima. A differenza di uno
scalatore però, io non sono mai stato solo. Il mio grazie va a chi mi ha accompagnato,
a chi mi ha sorretto, a chi mi spronato, a chi mi ha sfidato, a chi non mi ha
abbandonato. L’elenco dei miei grazie è infinito e poche parole non bastano a far
capire quanto il mio sentimento sia vivo e ricolmo di amore incondizionato. Grazie
con tutto il cuore a mamma e papà, sono un figlio fortunato. Ho avuto così tanto
amore da loro che posso solo piangere di gioia mentre penso a quando siano stati
genitori presenti e fantastici. Spero con queste parole di potervi restituire un po’ del
mio infinito debito con voi. Sarete per sempre il mio modello di riferimento, le mie
guide perfette, la mia Semenzlandia. Grazie a Niala, per essere la sorella adorabile
che è. Sarà sicuramente perplessa nel leggere come io possa scrivere delle smancerie
del genere, ma io so che dentro di lei batte un cuore dolcissimo e questo mi rende un
fratello orgoglioso, pieno di miele e cuoricini. A lei devo aiuto e solidarietà,
commenti acidi e pedate a cena. A lei devo soprattutto un abbraccio fortissimo.
Grazie a Martina. Il significato della parola Amore ha per me preso forma grazie a lei.
Vivo con la gioia immensa di poter costruire con lei ogni singolo istante. Sento il
bisogno di essere lieve per non rovinare un sentimento molto forte, che non saprò
mai spiegare a parole. Martina è il mio sole, è la mia roccia, è l’aria che respiro, la
poesia nel mio cuore. Ogni giorno in più con lei, è un giorno per cui dire grazie.
Grazie a Claire, cugina ormai scienziata a tutti gli effetti, pazzia compresa. Solo chi ha
avuto il piacere di condividere l’avventura universitaria come abbiamo fatto noi, può
capire il peso di ogni singolo ringraziamento, cosicché tutti gli sforzi vengano
ricompensati alla fine, in un abbraccio rotante che ci faccia volare nell’Olimpo di chi
alla fine ci è riuscito. Ti voglio bene. Un bacio anche al cuginone Diego… no vabbè
dai, può bastare un abbraccio. E’ strano doverti ringraziare come cugino, quando la
vita ci ha fatto crescere come fratelli. Grazie per i Lego, per le macchinette, per i
giochi e le avventure. Grazie per avermi reso cugi-zio del piccolo Davide, e grazie a
Margherita per aver compiuto il miracolo di fargli mettere la giacca. Un bacio
enorme a nonna Imelda e nonno Bruno, spero di avervi fatto un regalo, spero di
avervi resi orgogliosi di me. Non ci saranno mai dottori al mondo capaci di insegnare
qualcosa a voi. Voi siete dottori da sempre, e il fatto che non ve ne rendiate conto, ne
è la prova finale. Avrei voluto poter dire le stesse cose anche a nonna Adriana e
nonno Livio, i miei secondi genitori. In qualche modo vorrei che queste parole
arrivassero anche a loro, e so che così sarà. Un abbraccio fortissimo agli zii Paolo e
Arianna, Sabrina e Alberto, Luca e Anna, Massimo e Patrizia: siete stati sempre con
me, in qualunque contesto. Vi accumuna un incondizionato tifo nei miei confronti, mi
avete spronato ad andare avanti e siete stati sempre presenti, la mia curva sud. Vi
adoro. Un grazie anche ai cuginetti che ormai toccano il soffitto, Elia, Gioele e
Giacomo. Non capirò mai perché fino a ieri vi tenevo in braccio e adesso potrebbe
111
Luca Semenzato
Anno Accademico 2011/2012
Tesi di Laurea in Informatica
benissimo accadere il contrario, ma tant’è… grazie per la compagnia e le partite a
qualsiasi cosa. Ringrazio i miei amici di sempre, gli amici che non mi hanno
abbandonato mai, neanche quando sentivo di non poter dare loro tutto quello che
avrei voluto. Loro sono sempre stati lì, sempre in contatto nonostante la distanza:
grazie ad Antonio per essere il fratello che non ho, la nostra capacità di essere amici
telepatici mi sorprende sempre, gli devo molte esperienze e risate, gli sono debitore
praticamente di tutti i momenti divertenti della mia vita; grazie a Davide per aver
condiviso con me i pensieri più intimi, per essere stato spesso la mia coscienza
inconsapevole, per avermi ascoltato, per avere discusso con me della vita e tutto il
resto, per avermi mostrato la vera Arte, per essere presente ancora, nonostante le
nostre vite procedano in luoghi diversi. Grazie al Fante, per avermi reso meno amaro
il periodo scolastico, grazie perché sei inimitabile, grazie per la tua vitalità, per
l’allegria di tante avventure insieme, per riuscire a scrollarmi di dosso la mia aria da
musone pensieroso. Grazie per le feste, le grigliate, il sano divertimento neanche poi
così tanto sano. Grazie per non aver mai mollato nell’invitarmi a mille eventi. Prima
o poi saprò sdebitarmi. Grazie a Camilla per avergli fatto mettere la testa al posto
giusto e per averlo reso papà, cosa su cui tutti non avremmo scommesso un euro! W
il piccolo Tommy!!! Un grazie collettivo anche a tutti quegli amici incontrati nel
corso di questi anni, non siete meno importanti, nessuno lo è, ma dovrei scrivere
troppo, e comunque troppo poco: grazie a Fabio, Niccolò, Samuele, Andrea Cif,
Andrea F., Carlo per aver condiviso lo studio con me, per gli appunti, per gli esercizi,
le dritte, i libri, per la vostra infinita pazienza nell’aiutarmi. Siete stati generosi oltre
il ripagabile. Grazie a Benny e Cate, ad Ale e Francesca, a Mattia, a Giorgia e
Giuseppe: la vostra compagnia mi ha reso meno difficile il cammino, siete stati amici
di mille serate importanti. Grazie a Paola, Annalisa e Paolo perché la Nutella è
speciale, ma in vostra compagnia si gusta decisamente meglio. Grazie a tutti i ragazzi
del volley: mi avete regalato la gioia del gioco, donandomi momenti di puro
spettacolo; non sarò mai Giba, ma con voi tutto è possibile! Un ringraziamento va a
tutti i miei colleghi, lontani e vicini, Tigran, Sara, Denis, Diego, Giuseppe, Mauro,
Massimiliano, Stefano, Jacopo, Pietro: lavorare con voi è prima di tutto un piacere, e
poi un onore. Siete stati sempre presenti, amici prima che colleghi, comprensivi e
preparati; un pezzo di questa avventura vi appartiene. Un ringraziamento
particolare a Sandro: quando anni fa hai scelto di darmi l’occasione di entrare nel
vostro gruppo, hai dato il via a tutto questo, facendomi lavorare in ottime condizioni
e permettendomi di portare avanti lavoro e studio insieme, un privilegio di cui ti
sono debitore. Grazie anche a Giuliano, Marco, Mario, Maria Grazia, Ilaria, Marta,
Veronica, Francesca, Matteo, Michele, Alberto: la vostra amicizia mi onora, siete
persone eccezionali e non fate mai pesare la vostra enorme preparazione. L’ultimo
ringraziamento va ad un amico speciale, inarrivabile nella sua bontà, insostituibile
cane di pezza, sempre con me in tutti gli anni di studio, e comunque presente in
ognuno di noi: questa laurea è per Brit.
Sono in cima. Da qui vedo un paesaggio stupendo. Mi lascio andare un attimo
al tenero abbraccio della vittoria. Della mia vittoria. In fondo, oltre il versante
che non potevo vedere, altre cime ben più alte mi attendono, ma per un attimo
volgo lo sguardo altrove, smetto di preoccuparmi, e alzo le mani al cielo.
Per un momento. Solo per un momento. Oggi. Sono invincibile. Grazie. Luca
112
