DRAUGHTS Linguaggi e Modelli Computazionali LS Linguaggio e interprete per effettuare una partita di dama inglese contro un’intelligenza artificiale Progetto.

Presentazione sul tema: "DRAUGHTS Linguaggi e Modelli Computazionali LS Linguaggio e interprete per effettuare una partita di dama inglese contro un’intelligenza artificiale Progetto."— Transcript della presentazione:

1 DRAUGHTS Linguaggi e Modelli Computazionali LS Linguaggio e interprete per effettuare una partita di dama inglese contro un’intelligenza artificiale Progetto di:Docente: Michele DinardoEnrico Denti

2 Scopo del lavoro Progettare un sistema che permetta di effettuare una partita di dama inglese, draughts, contro un’intelligenza artificiale. Occorre, quindi: 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 ingresso 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. Realizzare uno strumento grafico che:  visualizzi l’andamento della partita;  riporti lo storico delle azioni richieste. 1 febbraio 20092Michele Dinardo

3 Draughts: regole del gioco È giocata su una damiera standard di 64 caselle. Il cantone, ossia la casella nera d’angolo, è in basso a sinistra. Ciascun giocatore dispone di 12 pedine. Prima mossa al nero. Le pedine si muovono solo in avanti ma possono prendere anche le dame. Se dopo una presa è possibile eseguirne un’altra, allora essa deve essere effettuata. In caso di più possibilità di presa c’è libera scelta. Se una pedina raggiunge l'ultima riga viene promossa a Re e viene abilitata a muoversi anche indietro. Anche in caso di eventuali prese, la mossa è sempre finita. Curiosità Curiosità:nel 2007 è stata risolta da un gruppo di lavoro che, sviluppando il programma Chinook, ha dimostrato che una partita senza errori finisce necessariamente in parità. 1 febbraio 2009Michele Dinardo3

4 Analisi del problema Il linguaggio dovrà quindi offrire i costrutti per: o iniziare una nuova partita:  settare, se richiesto, la difficoltà dell’intelligenza artificiale;  scegliere il colore dei propri pezzi; o eseguire una mossa sulla partita in corso:  definire la nozione di posizione di partenza e di arrivo di una pedina;  offrire la possibilità di compiere eventuali prese;  esprimere il concetto di promozione a Re; 1 febbraio 2009Michele Dinardo4

5 Caratteristiche 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. 1 febbraio 2009Michele Dinardo5

6 Grammatica EBNF (1/2) 1 febbraio 2009Michele Dinardo6 ::= | ::=start [ ] ::=set ::=choose ::=beginner | intemediate | expert ::=white | black Scopo Inizia nuova partita Esempi di frasi lecite, alla scopo di iniziare una nuova partita, sono: – start choose white – start set expert choose black

7 1 febbraio 2009Michele Dinardo7 Grammatica EBNF (2/2) 1 febbraio 2009Michele Dinardo7 ::=move to { } [ ] ::= ::= take ::= ::=A | B | C | D | E | F | G | H ::=1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ::=king Prosegui partita in corso Esempi di frasi lecite, allo scopo di proseguire la partita in corso, sono: – move b6 to a5 – move b6 to d4 take c5 – move c5 to g1 take d4 take f2 king

8 Osservazioni sulla grammatica 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 director symbols giacché nessun metasimbolo genera la stringa vuota. È possibile, allora, utilizzare l’analisi ricorsiva discendente. 1 febbraio 2009Michele Dinardo8

9 Architettura del sistema 1 febbraio 2009Michele Dinardo9 Linguaggio di programmazione: o Java 1.6.0_11 Generazione parser e scanner: o JavaCC 4.2 Generazione APT e visitor: o JTB 1.3.2 Ambiente di sviluppo: o Eclipse 3.4.1 Ambiente di test: o JUnit 4.0

10 Il sottosistema game 1 febbraio 2009Michele Dinardo10 Le viste e il controller Partita implementano assieme il pattern Observer. Il controller Partita sincronizza, ad ogni turno, gli attori Umano e Computer all’uso della damiera. La classe Umano verifica la correttezza della mossa richiesta e, in caso positivo, la esegue. La classe Motore implementa la ricerca alpha/beta, calcola il risultato della funzione di valutazione ed esegue la mossa ritenuta ottimale. L’entità Damiera memorizza lo stato delle celle ed offre i metodi di gestione delle stesse.

11 L’integrazione al package visitor 1 febbraio 2009Michele Dinardo11 Sono stati implementati due visitor: DraughtsGameVisitor: visita l’APT e inoltra al controller Partita le azioni rilevate al fine di verificarne la correttezza e, in caso positivo, l’esecuzione. DraughtsTreeVisitor: 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 double dispatch.

12 Il package gui in esecuzione 1 febbraio 2009Michele Dinardo12 Area inserimento frasi Unione APT della partita in corso Messaggi generati dall’I.A. Evoluzione partita

13 Collaudo 1 febbraio 2009Michele Dinardo13 Sono state implementati due suite di test JUnit: ControllerTest: verifica la correttezza dei metodi dei singoli attori, il corretto andamento della partita e la capacità di riscontrare e notificare azioni illecite. LanguageTest: verifica le stesse funzionalità del test precedente avvalendosi del linguaggio e dell’interprete progettato.

14 Limiti e sviluppi futuri La gestione delle condizioni di fine partita è la caratteristica non sviluppata più rilevante. Possibili sviluppi futuri possono essere: Introduzione di costrutti circa l’esito della partita. Introduzione della possibilità di effettuare partite tra due giocatori: in tal caso si rivela utile la scomposizione del linguaggio in due sottolinguaggi, uno relativo all’eventuale programmazione dell’intelligenza artificiale, l’altro relativo all’inizio di una partita ed alla sua conduzione. Realizzazione di un sistema client/server che permetta a due utenti remoti di condurre una partita. 1 febbraio 2009Michele Dinardo14