SudoKiller

Indice

Requisiti

Descrizione

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.

Glossario

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.

Casi d'uso e scenari JPG.png}{attach:Schema dei casi d'uso

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.

Modello dei dati del sistema

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:
JPG.png}{attach:Struttura di SudokuScheme

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:

ModelloER.jpg

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.

Analisi

Architettura Logica

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.

JPG.png}{attach:Struttura applicazione Android

Struttura Server

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.

JPG.png}{attach:Struttura serverJPG.png}{attach:Struttura DB

Interazione applicazione-server

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.

JPG.png}{attach:*LOGIN* JPG.png}{attach:*REGISTRAZIONE* JPG.png}{attach:*PARTITA SINGOLA* JPG.png}{attach:*PARTITA MULTIGIOCATORE* JPG.png}{attach:*CLASSIFICA*

Comportamento

Comportamento lato applicazione
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

Activity-Logincomp.jpg Comunicator-Logincomp.jpg

REGISTRAZIONE

Activity-Registrationcomp.jpg Comunicator-Registrationcomp.jpg

PARTITA SINGOLA

Grid-SingleGamecomp.jpg Comunicator-SingleGamecomp.jpg

PARTITA MULTIGIOCATORE

Grid-MultiGamecomp.jpg Comunicator-MultiGamecomp.jpg

Comportamento lato server
In questo caso invece viene descritto il comportamento di ogni entità del server, senza alcuna suddivisione.

GamesCoordinator

GamesCoordinator.jpgSingleGameThread

SingleGameThread.jpgMultiGameThread

MultiGameThread.jpgMultiGameController

MultiGameController.jpgResolver

Resolver.jpg

Comportamento lato database
DBController

DBController.jpg

Tecnologie utilizzate

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).

Pattern individuati

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

Conclusioni

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.