MasterMind, il famoso gioco da tavolo realizzato in Java per il corso di laurea L-31 presso Unicam, nell'anno accademico 2018/2019, realizzato dagli studenti Francesco Coppola e Francesco Pio Stelluti per il progetto di Programmazione Avanzata seguendo i canoni di sviluppo proposti

• Unicam • Documentazione • Licenza • Contribuisci •

Il progetto è stato indirizzato ad all'implementazione tramite linguaggio Java del gioco da tavolo Mastermind.

Nell'ideare la struttura del progetto si è puntato alla massima modularità possibile, per quanto non totale, ottenuta tramite l'applicazione di determinati design pattern.

L'avvio del programma è delegato ad una classe che estende MainManager, classe astratta contenente il funzionamento effettivo e a più alto livello del programma. La particolare estensione di tale classe è delegata a definire quali implementazioni delle classi GameViewFactory e StartView si è scelto di impiegare.

Le classi GameViewFactory e StartView sono fondamentali in quanto estendibili con classi mirate a fornire delle viste finalizzate all'interazione con gli utenti fisici. Il funzionamento di MainManager si basa sulla creazione, esecuzione e monitoraggio di istanze personalizzate di SingleMatch, rappresentanti singole partite di gioco.

La corrente implementazione di MainManager consente la gestione di una singola istanza di SingleMatch alla volta. All'interno dell'esecuzione effettiva del metodo di avvio presente in SingleMatch si ha poi l'interazione di due entità rappresentanti i giocatori, rispettivamente un CodeMaker (colui che definisce la sequenza di ColorPegs da indovinare) e un CodeBreaker (colui che definisce sequenze di ColorPegs valide come tentativi), con l'entità BoardController, attraverso la quale viene aggiornata un'istanza di BoardModel (rappresentante una plancia di gioco).

Lo svolgimento di un SingleMatch si conclude quando si è arrivati ad una delle tre condizioni di vittoria, rappresentate dalla sconfitta del CodeBreaker a causa di una sua resa o per l'esaurimento dei tentativi disponibili e dalla sconfitta del CodeMaker a causa della definizione di una corretta sequenza tentativa da parte del CodeBreaker. L'interazione con l'utente fisico all'interno del programma è svolta da istanze estensione di StartView (mirate alla fase di preparazione dei singoli match) e da istanze estensione di GameView (mirate alla gestione delle azioni da eseguire durante i match).

L'estendibilità del progetto si sostanzia nella possibilità di definire nuove implementazioni per le seguenti responsabilità:

• Gestione dell'avvio e del monitoraggio delle singole partite, rappresentata da MainManager.
• Gestione dell'interazione con l'utente fisico per l'avvio di nuove partite, rappresentata da StartView.
• Gestione dell'interazione con l'utente fisico per la gestione delle azioni all'interno di singole partite, rappresentata da GameView.
• Fornire istanze di implementazioni di GameView, rapprsentata da GameViewFactory.
• Rappresentazione di un giocatore che decide la sequenza da indovinare, rappresentata da CodeMaker.
• Fornire istanze di implementazioni di CodeMaker, rappresentata da MakerFactory.
• Rappresentazione di un giocatore che cerca di indovinare la sequenza, rappresentata da CodeBreaker.
• Fornire istanze di implementazioni di CodeBreaker, rappresentata da BreakerFactory.

Esempi di implementazioni già incluse nella release attuale del progetto sono:

• ConsoleMainManager, ad estensione di MainManager.
• ConsoleStartView, implementazione di StartView.
• ConsoleGameView, estensione di GameView.
• ConsoleGameViewFactory, implementazione di GameViewFactory.
• InteractiveMaker, RandomBotMaker, estensioni di CodeMaker.
• InteractiveMakerFactory, RandomBotMakerFactory, implementazioni di MakerFactory.
• InteractiveBreaker, RandomBotBreaker, DonaldKnuthBreaker, estensioni di CodeBreaker.
• InteractiveBreakerFactory, RandomBotBreakerFactory, DonaldKnuthBreakerFactory, estensioni di BreakerFactory.

Per ulteriori informazioni circa le classi elencate si rimanda alle relative sezioni.

Il caricamento a runtime delle informazioni relative alle classi factory, grazie alle quali ottenere istanze di classi che estendono CodeBreaker e CodeMaker, è stato reso possibile grazie alla definizione di classi implementazione PlayerFactoryRegistry, classi le cui istanze sono indirizzate alla lettura a runtime di file di input e al caricamento di istanze di BreakerFactory e MakerFactory. Il formato delle informazioni di tali file di input è molto importante ed in loro assenza ne vengono generati automaticamente altri (all'interno della cartella GameResources) contenenti le istruzioni necessarie per un corretto avvio del programma. Il caricamento a runtime di tali informazioni permette l'aggiunta di nuove funzionalità del programma, nei limiti di estendibilità già trattati, senza avere la necessità di ricompilare tutte le classi del progetto.

Maker Factory	Breaker Facotry

Si rimanda alle sezioni per ulteriori informazioni circa le implementazioni di PlayerFactoryRegistry fornite.

1. Model View Controller: Rappresenta la struttura alla base del funzionamento delle singole partite. È stata implementata tramite le classi GameView, BoardModel e BoardCoordinator, classi le cui istanze comunicano all'interno di SingleMatch.

2. Observer: Implementato fornendo come classe da osservare BoardModel e come classi che osservano GameView e MatchState, classi estensione di BoardObserver. Dalla versione 9 di Java l'interfaccia Observer, pensata nell'ottica di questo design pattern, risulta deprecata. La sua implementazione all'interno di questo progetto è quindi da vedere in un'ottica puramente accademica e finalizzata all'apprendimento del concetto alla base del pattern.

3. Factory: Implementato tramite le classi PlayerFactory, MakerFactory, BreakerFactory e le loro implementazioni per poter fornire istanze di giocatori CodeMaker e CodeBreaker. Lo stesso pattern è stato inoltre implementato con GameViewFactory per poter fornire istanze di GameView all'inizializzazione dei vari SingleMatch.

Sono stati ideati dei test, scritti sotto ambiente JUnit 5, per poter testare in modo mirato le singole funzionalità del progetto.

Per ulteriori informazioni si rimanda alle sezioni riguardanti le implementazioni di tali test.

Nell'ottica di garantire continuità al progetto si è deciso anche di implementare il tool di building Gradle, in versione 5.4.1, per facilitare il deploy e la distribuzione di tale software all'interno di altri sistemi.

La Continuous Integration, proprio come la Continuous Delivery, viene apprezzata soprattutto nello sviluppo agile di software. L'obiettivo di questo moderno metodo è quello di suddividere il lavoro in porzioni più piccole per rendere il processo stesso di sviluppo più efficiente e poter reagire con maggiore flessibilità alle modifiche. La Continuous Integration è stata nominata per la prima volta nella descrizione della metodologia agile Extreme Programming di Kent Beck.

Mediante l'implementazione di Gradle, illustrata in precedenza, si è riuscito a integrare all'interno della natura del progetto anche il software Travis CI.

Quest'ultimo garantisce all'intero progetto la possibilità di sviluppare una integrazione continua all'interno di un team di lavoro in primo luogo, e di consegunza, una seria di vantaggi non indifferenti, quali:

• Resa del build auto-testante

  • Ogni volta che il codice sorgente viene buildato ed impacchettato vengono eseguiti dei test sul sorgente affinché la qualità del codice venga tenuta sotto controllo ed eventuali bug vengano scoperti il prima possibile.

• Ogni commit lancia una build

  • Ogni modifica al codice sorgente condiviso potrebbe generare dei bug e quindi compilare e testare subito dà la possibilità di intervenire immediatamente su eventuali falle del sistema.

• Esecuzione di test in un clone dell'ambiente di produzione

  • L'ambiente di lavoro può differire in base all'OS adottato e dal hardware stesso della macchina che si adopera, per questo è fondamentale creare un clone del workspace che sia il medesimo per tutti i membri del progetto e incontro a tale evenienza viene in aiuto Docker.

• Repository del codice sorgente

  • Questo elemento è propedeutico a tutti gli altri principi descritti in precedenza, poichè senza avere un repository del codice è impossibile automatizzare il build ed i test.

Aver inserito anche una feature come quella del CI rende sicuramente l'intero parco software robusto, elegante e flessibile.

Lo sviluppo di tale codice è da attribuire interamente agli studenti Francesco Coppola e Francesco Pio Stelluti, i quali hanno perso sangue, sudore e diverse diottrie durante la stesura di quest'ultimo.