Obiettivi

1. Obiettivi • Progettare un sistema che permetta di effettuare una partita a MemoryPlus: • Progettare un linguaggio che sia in grado di esprimere le azioni topiche di una tale partita. • Realizzare un’interprete per tale linguaggio che: • accetti in input una stringa di caratteri; • esegua un’analisi sintattica al fine di riconoscere se la stringa è una frase lecita del linguaggio; • esegua le azioni corrispondenti alla semantica della frase immessa. Vito La Porta

2. MemoryPlus: come si gioca • MemoryPlus è un gioco di memoria • Si gioca su una griglia di carte inizialmente coperte • Si possono scegliere tre livelli di difficoltà: 4x4, 6x6, 8x8 • Lo scopo del gioco è individuare le coppie di carte uguali • Il giocatore, all’inizio della partita, può scegliere di visualizzare le carte per un certo numero di secondi, con l’obiettivo di memorizzare gli accoppiamenti • Scelta una carta è possibile richiedere un aiuto: il sistema evidenzia la carta che si accoppia con quella selezionata più un certo numero di carte definito dall’utente, tutte sempre coperte Vito La Porta

3. Costrutti del linguaggio • Il linguaggio dovrà quindi offrire i costrutti per: • iniziare una nuova partita: • settare, se richiesto, il livello di difficoltà del gioco; • settare, se richiesto, il tempo in cui saranno visualizzate le carte scelte ma non accoppiate • settare, se richiesto, il tempo in cui inizialmente saranno visualizzate tutte le carte • scegliere la coppia di carte: • definire la nozione di posizione della prima carta e della seconda carta; • offrire la possibilità di richiedere l’aiuto Vito La Porta

4. Proprietà del linguaggio • Il linguaggio che si intende progettare deve essere: • semplice: sono sufficienti poche frasi per soddisfare le richieste di un’utente che usufruisce del sistema; • descrittivo: le frasi lecite del linguaggio devono riflettere il pensiero del giocatore che in quel momento sta richiedendo una particolare azione; • comprensibili a chiunque: non legate quindi a notazioni chiare solo a professionisti. Vito La Porta

5. Grammatica EBNF (1/2) <MemoryPlus>: := <StartGame> | <ChoosePair> Scopo • Esempi di frasi lecite: • start level beginner • start level intemediate time 4 • start level expert time 3 view 7 <StartGame> ::= start [<SetLevel> ] [ <SetTime>] [ <ViewTable>] <SetLevel> ::= level <Level> <SetTime> ::= time <Number> <ViewTable> ::= view <Number> Inizia nuova partita Vito La Porta

6. Grammatica EBNF (2/2) <Choose> ::= choose < FirstCard > (- < SecondCard > | <Help>) <FirstCard> ::= <Position> <SecondCard>::= <Position> <Help> ::= help <Number> • Esempi di frasi lecite: • choose b6 - a5 • choose a3 help 4 Azioni partita in corso <Level> ::= beginner | intemediate | expert <Number> ::= ["1"-"9"] { [ “0"-"9“ ] } <Position> ::= <Row> <Column> <Row> ::= A | B | C | D | E | F | G | H <Column> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 Token Vito La Porta

7. Grammatica: proprietà • Secondo la classificazione di Chomsky, la grammatica è di tipo 2, ovvero libera dal contesto, poiché le produzioni non sono regolari. • L’assenza di self-embedding assicura però che il linguaggio generato è di tipo 3, ovvero regolare. • Non sono presenti ε-rules: il linguaggio non comprende, quindi, la stringa vuota in quanto essa non avrebbe alcun significato rilevante. • Gli starter symbols corrispondenti alle parti destre delle produzioni alternative sono disgiunti: la grammatica è, quindi, LL(1). Non è necessario ricorrere ai directorsymbols giacché nessun metasimbolo genera la stringa vuota. • È possibile, allora, utilizzare l’analisi ricorsiva discendente. Vito La Porta

8. Architettura del sistema • Linguaggio di programmazione: • Java 1.6.0_13 • Generazione parser e scanner: • JavaCC 4.2 • Generazione APT e visitor: • JTB 1.3.2 • Ambiente di sviluppo: • Eclipse 3.4.1 • Ambiente di test: • JUnit 4.0 Vito La Porta

9. Sottosistema game Il modello seguito nella progettazione è quello BCE: • La boundary MemoryPlus implementa l’interfaccia grafica e mette a disposizione dell’utente un’area di testo in cui è possibile definire le azioni desiderate. • Il controller Partita verifica la correttezza delle azioni richieste e, in caso positivo, le esegue. • L’entitàMatrix implementa la griglia delle carte e memorizza lo stato di ciascuna di esse. Vito La Porta

10. Package visitor • Sono stati implementati due visitor: • MemoryPlusGameVisitor: visita l’APT e inoltra al controller Partita le azioni rilevate al fine di verificarne la correttezza e, in caso positivo, l’esecuzione. • MemoryPlusTreeVisitor:visita l’APT e ne fornisce una rappresentazione grafica sotto forma di albero. L’unione degli alberi relativi ad una stessa partita determina lo storico della stessa. • Ciascun visitor realizza una visita di tipo depth first avvalendosi del meccanismo del doubledispatch. Vito La Porta

11. Interfaccia grafica Unione APT della partita in corso Evoluzione partita Area inserimento frasi Vito La Porta

12. Collaudo: JUnit testing • E’ stata implementatia una suite di test JUnit: • TestController: verifica la correttezza dei metodi, il corretto andamento della partita e la capacità di riscontrare e notificare azioni illecite. Vito La Porta

13. Limiti e sviluppi futuri • Il principale limite è la mancanza di un sistema di punteggi, basato sul numero di tentativi e sul tempo utilizzato, che permetta di definire classifiche delle diverse partite. • Possibili sviluppi futuri possono essere: • Introdurre un sistema di punteggi • Permettere all’utente la possibilità di definire un limite di tempo entro cui completare una partita. • Introdurre la possibilità di effettuare partite tra due giocatori. Vito La Porta