Indice
Il team di sviluppo si propone l'obiettivo di realizzare un'applicazione per dispositivi mobile che permetta all'utente di risolvere schemi Sudoku, attraverso un'interfaccia grafica la quale deve essere costituita da una griglia e da tre pulsanti (start, aiuto, risoluzione). Ad ogni nuova partita, l'applicazione dovrà essere in grado di richiedere ad un server la generazione di un schema casuale 9x9, garantendo la possibilità di poter scegliere tra tre livelli di difficoltà (facile, medio, difficile). L'applicazione deve prevedere la possibilità di scegliere tra due modalità di gioco, singolo o multiplayer, e nel secondo caso richiedere al server la ricerca di utenti disponibili.
Il sistema inoltre deve essere in grado di verificare in modo autonomo la soluzione dello schema e di fornire suggerimenti all'utente se richiesti.
Per garantire l'integrità dell'algoritmo di risoluzione, queste operazioni non dovranno essere realizzate dal dispositivo stesso ma sempre demandate ad un server posto sotto il controllo degli amministratori del sistema.
Si prevede inoltre una classifica generale dei risultati ottenuti dagli utenti.
Termine |
Significato |
Sudoku |
Gioco di logica nel quale al giocatore viene proposta una griglia di 9×9 celle, ciascuna delle quali può contenere un numero da 1 a 9, oppure essere vuota; la griglia è suddivisa in 9 righe orizzontali, 9 colonne verticali e, da bordi in neretto, in 9 sotto-griglie di 3×3 celle contigue. Le griglie proposte al giocatore hanno da 20 a 35 celle contenenti un numero. Scopo del gioco è quello di riempire le caselle bianche con numeri da 1 a 9, in modo tale che in ogni riga, colonna e regione siano presenti tutte le cifre da 1 a 9 e, pertanto, senza ripetizioni. |
Interfaccia Grafica (Graphic Interface) |
Componente dell'applicazione che permette un' interazione facile ed intuitiva con l'utente, costituita da una griglia e da tre pulsanti: uno di start per avviare l'applicazione, uno di richiesta di aiuto e uno per ottenere la risoluzione. |
Multiplayer |
Modalità di gioco uno contro uno fra due utenti dispositivi mobile. |
Dispositivo Mobile |
Dispositivo generico dotato di connessione ad internet (smartphone, cellulare, palmare, tablet, ecc). |
Algoritmo di Risoluzione |
Procedimento per il completamento automatico dello schema secondo le regole del Sudoku. |
Server |
Entità computazionale, diversa dal dispositivo stesso, che si occupa dell'algoritmo di risoluzione e della ricerca dei giocatori disponibili per partite multiplayer. |
Amministratore |
Persona autorizzata alla modifica e al controllo dell'algoritmo di risoluzione. |
Di seguito viene riportata la specifica nel dettaglio dei casi d'uso illustrati nella figura precedente:
Campo |
Requisiti |
Nome |
UC1 - RICHIESTA SOLUZIONE/SUGGERIMENTO |
Descrizione |
Richiesta della risoluzione o di un suggerimento per completare lo schema. |
Attore |
Utente |
Precondizioni |
La partita sia stata avviata. |
Scenario Principale |
L'utente, dopo aver avviato una partita, può in qualsiasi momento richiedere al server la soluzione dello schema o un aiuto per continuare. |
Campo |
Requisiti |
Nome |
UC2 - INSERIMENTO NUMERI |
Descrizione |
Scrittura dei numeri nella griglia di gioco. |
Attore |
Utente |
Precondizioni |
La partita sia stata avviata. |
Scenario Principale |
L'utente, dopo aver avviato una partita, può inserire i numeri secondo le regole del Sudoku. |
Campo |
Requisiti |
Nome |
UC3 - CREAZIONE DI UNA GRIGLIA |
Descrizione |
Visualizza sull'interfaccia la griglia di gioco. |
Attore |
Server |
Precondizioni |
Nel caso l'utente scelga la modalità multiplayer, deve essere stato selezionato un altro utente. |
Scenario Principale |
Il server, una volta che l'utente ha selezionato la modalità di gioco, farà visualizzare la griglia. |
Campo |
Requisiti |
Nome |
UC4 - RICERCA UTENTI |
Descrizione |
Ricerca di un secondo utente con cui avviare una partita. |
Attore |
Server |
Precondizioni |
L'utente deve aver scelto la modalità multiplayer. |
Scenario Principale |
Il server si occupa di ricercare utenti disponibili a giocare in modalità multiplayer e metterli in contatto tra di loro. |
Unità fondamentale del sistema da noi studiato è lo schema Sudoku.
La sua struttura è caratterizzata da 81 celle aventi un numero di riga, di colonna e di zona. Inoltre queste celle hanno un valore corrispondente ad un numero intero da 1 a 9 (-1 se la cella è da considerarsi vuota).
Di seguito uno schema della struttura appena descritta:
Sempre per quanto riguarda la struttura dati del sistema si è pensato di modellare un piccolo database che gestisca gli utenti che usufruiranno dell'applicazione e le loro partite giocate. Questo perchè, dalla lettura dei requisiti, si evince la necessità di creare
una classifica generale dei risultati ottenuti dagli utenti.
Di seguito viene rappresentato lo schema ER primordiale del database:
Mentre qui di seguito vengono elencate gli elementi che compongono lo schema relazionale :
Entità |
Descrizione |
Users |
Rappresenta la categoria degli utenti: vengono identificati in base ad un nickname e possiedono una password per poter identificarsi all'aggiunta dei risultati delle partite. Opzionalmente possono inserire il loro indirizzo email all'atto di registrazione. |
Games |
Rappresenta le partite: vengono identificate in base ad un ID univoco auto-incrementale e possiedono attributi che definisco data/ora di fine della partita, difficoltà, tempo di gioco effettivo e se la partita è stata vinta o meno. |
Le effettive traduzioni in relazioni sono le seguenti:
- USERS (nickname, pwd, email*)
- GAMES (id, game_time, victory, datetime, difficulty, nickname_user)
- FK: nickname_user REFERENCES users
- On Update: CASCADE
- On Delete: CASCADE
Le possibili operazioni attuabili sul database risultano essere le seguenti:
- Registrazione di un nuovo utente
- Login di un utente
- Inserimento di una partita conclusa
- Generazione della classifica generale in base alla difficoltà
- Elenco delle statistiche di un utente
Per il momento non è stata prevista la possibilità di memorizzare contro chi si è giocato nelle partite in modalità multiplayer.
Struttura Applicazione Android
Per sviluppare un'applicazione Android è necessario fare uso di elementi quali Service e Activity. I primi utili a svolgere operazioni in background mentre le seconde permettono di creare una grafica personalizzata e interattiva con l'utente.
Nel nostro caso sono necessarie diverse Activity, una per ogni schermata utile alla gestione del gioco(login, scelta della partita, griglia, opzione, ecc..), le quali costituiscono lo sviluppo dell'interfaccia grafica dell'applicazione e un'entità Comunicator che si occupa di interagire con il server effettuando le richieste e attendendo le risposte.
L'entry-point principale del server è la classe GamesCoordinator.
Tale classe si occupa inizialmente di avviare il server che si occupa delle interazioni con il database (la classe DBController) e poi svolge la funzione di vero e proprio server: accetta le richieste dai client (sulla porta 4444) e, a seconda della modalità di gioco (single player o multi player) avvia i thread figli, demandando a loro la gestione della partita vera e propria (rispettivamente SingleGameThread e MultiGameThread).
Come già specificato qualsiasi interazione con il database avviene attraverso la classe DBController: questa è di fatto un server che accetta le richieste dai client sulla porta 4445 e le processa, restituendo poi i dati richiesti.
Per descrivere in modo più dettagliato e lineare possibile abbiamo suddiviso gli schemi per operazioni. Per cui avremo cinque schemi che riguarderanno: login, registrazione, partita singola, partita multigiocatore e registrazione punteggio con visualizzazione classifica.
Come nel caso dell'interazione, anche qui si è deciso di suddividere per operazioni. In tal caso sono quattro( login, registrazione, partita singola e partita multigiocatore).
LOGIN
REGISTRAZIONE
PARTITA SINGOLA
PARTITA MULTIGIOCATORE
In questo caso invece viene descritto il comportamento di ogni entità del server, senza alcuna suddivisione.
GamesCoordinator
SingleGameThread
MultiGameThread
MultiGameController
Resolver
DBController
Il database è realizzato in linguaggio MySQL.
Per quanto riguarda la connessione al database da parte del server sono state utilizzate 2 librerie:
- MySQL Connector: driver base per collegare un database MySQL con Java; per ulteriori informazioni visitare questo sito
- iBatis: permette di mappare i risultati di query SQL su oggetti Java tramite la descrizione di quest'ultimi in linguaggio XML e, inoltre, di eliminare tutto il codice SQL dall'utilizzatore del codice; per ulteriori informazioni visitare questo sito
Il server è realizzato in linguaggio Java. Per garantire la comunicazione tra server e client si è adottato lo scambio di oggetti Java, opportunamente serializzati, sotto forma di stream che avviene a livello di socket: si è quindi scelta la comunicazione TCP per quanto riguarda il layer di trasporto.
L'applicazione client è realizzata attraverso la piattaforma Android: in particolare è stata sfruttata la versione 2.1 (API Level 7).
Nella realizzazione del progetto sono stati individuati i seguenti pattern:
- Pattern Observer: utilizzato nella realizzazione del meccanismo di aggiornamento della lista di giocatori (entità ListManager e PlayersList)
- Pattern ad eventi: utilizzato nella realizzazione delle varie richieste del client al server nella dinamica di gioco
- Pattern MVC (Model-View-Control): utilizzato nella realizzazione dell'applicazione Android
Come conclusione, possiamo dire che sono stati analizzati tutti gli aspetti del problema. In alcuni casi i metodi di risoluzione sono stati semplicistici: si guardi, per esempio, al fatto che le password non vengono criptate nel loro viaggio attraverso la rete. Ovviamente questi aspetti vanno adeguatamente risolti nel caso in cui l'applicazione abbia un deployment ufficiale.
Sono state comunque analizzate tutte le possibili situazioni di errore (down del server, problemi di rete e connessione, ecc) in modo tale da non mettere in difficoltà l'utente nella sua esperienza di gioco.