ConwayLife Sprint3

Introduction

Realizzazione in Java del GAME OF LIFE DI CONWAY, con GUI del gioco mediante pagina Web.

Requirements

  1. Realizzare una versione in Java del gioco Life di Conway, come gioco zero-player. Il gioco consiste nell’introdurre una Griglia di Celle il cui stato (cella ‘viva’ o cella ‘morta’) evolve come stabilito dallle regole di ConwayLife.
  2. L’utente umano deve poter:
    • specificare la configurazione iniziale della griglia del gioco
    • vedere l’evoluzione del gioco in forma opportuna (si veda Problema della vista del gioco)
    • fermare e far ripartire l’evoluzione del gioco
    • pulire (a gioco fermo) la configurazione della griglia del gioco
  3. In particolare, il committente desidera che la vista del gioco (e la configurazione iniziale) sia realizzata mediante una pagina HTML, precisando che:
    • la pagina deve costituire un componente che si relaziona con l’applicazione secondo l'architettura riportata in IoJavalin esterno alla applicazione
    • il gestore del gioco sarà l’utente che ha aperto per primo (owner) una pagina HTML collegata al gioco. In altre parole, solo la pagina dell’owner avrà pulsanti di comando START/STOP/CLEAN/EXIT attivi
    • la pagina HTML deve essere aggiornata in modo automatico man mano il gioco procede
    • un utente non owner che si collega mentre il gioco è in corso, dovrebbe vedere lo stato attuale della griglia in modo corretto
    • il deployment del gioco deve avvenire mediante Docker

Requirement analysis

E’ opportuno riportare qui lo scenario architetturale menzionato nei requisiti:
Architettura Esterna
E’ necessario avvalersi di un server che deve svolgere due ruoli diversi. Il componente che utilizza il server viene indicato col nome iojavalin.
Nel caso di Javalin esterno, IoJavalin è parte di un componente (un servizio) esterno alla applicazione che deve relazionarsi con il LifeController applicativo mediante messaggi.
L' interazione applicazione-servizio può avvenire in due modi:
  1. utlizzando una connessione via Websocket sulla porta 8080
  2. utilizzando un diverso protocollo, ad esempio MQTT
Il committente ha già indicato il primo comportamento, almeno per il prototipo iniziale del sistema. In seguito si potrà discutere sulla seconda possibilità.
Come da requisito, la pagina mostra in ogni caso i pulsanti, ma un click su questi provoca effetti solo nel caso in cui la pagina sia owner del gioco.
Per quanto riguarda i piani di test, al momento, sulla base dei requisiti, possiamo limitarci a dire quanto segue:

Problem analysis

L'obiettivo è quello di realizzare un sistema distribuito, in cui:
  1. Una parte del sistema (l'erogazione di una pagina HTML, in breve GUI) è del tutto nuova (Job1) rispetto allo Sprint 2.
  2. Una parte del sistema (l'applicazione) è già disponibile e deve essere solo adattata a interagire con la GUI (Job2).
Le due diverse parti costituiranno un Sistema solo se capaci di interagire in modo opportuno scambiando informazioni via rete in forma di messaggi. L'analisi si concentra sulla natura di questi messaggi per delineare le interazioni tra i componenti, che chiamiamo: Il sistema opera con un vincolo implicito: il livello applicativo utilizza la stessa connessione stabilita per collegarsi al server ai fini dell'output anche per ricevere l'input.

Il Job1 consiste nel realizzare un componente che funge da servizio erogatore di una pagina connessa via WebSocket. Suddividiamo l'analisi in:
Il Job2 consiste nella realizzazione di una implementazione di IOutDev ( OutInGuiInteraction.java ) che stabilisca una connessione WebSocket con la GUI.
All'avvio, il componente invia un dispatch con id="setcontroller" per informare il server della sua esistenza.
OutInGuiInteraction implementa IObserver. I messaggi (ri)trasmessi dal guiserver vengono percepiti tramite il metodo update e inoltrati al LifeControllerAdhoc.java.
Per aggiornare la GUI, il controller invia dispatch al guiserver: CommUtils.buildDispatch("lifectrl", "eval", CMDDISPLAY, "guiserver").

Test plans

Il piano di test prevede la verifica della corretta interazione tra i componenti tramite:

Project

  1. Il file wscanvascontrol.js interpreta i messaggi scambiati via WebSocket:
    • Utilizzo della Canvas HTML5 per la rappresentazione della griglia (20x20), permettendo aggiornamenti grafici fluidi tramite la funzione draw(grid).
    • I comandi (START/STOP/CLEAR/cell) vengono inviati al server nel formato msg(do, dispatch, SENDER, lifectrl, CMD, 0), dove SENDER è l'identificativo univoco assegnato dal server.
  2. Il collegamento tra la logica Java e il mondo Web è gestito da OutInGuiInteraction.java:
    • All'avvio, il componente esegue informTheServerAboutController(), inviando un dispatch setcontroller al guiserver per registrare la propria presenza.
    • Essendo un IObserver, percepisce i comandi provenienti dal browser (tramite il server) e li inoltra al LifeControllerAdhoc.
  3. Per l'aggiornamento della griglia in GUI si è deciso di utilizzare esclusivamente messaggi di tipo dispatch (asincroni).
    Data la natura del gioco (evoluzione continua), l'uso di request risulterebbe troppo oneroso. Il server invia lo stato della griglia in formato JSON in modalità fire-and-forget a tutti i client connessi.
  4. Il requisito dell'utente owner è gestito all'interno di IoJavalin.java:
    • Il server mantiene una lista allConns di tutti i contesti WebSocket attivi.
    • Il primo utente che si connette viene memorizzato in firstCaller (Owner). Solo i messaggi provenienti da questo mittente vengono inoltrati al controller per l'esecuzione.
    • Tuttavia, grazie alla funzione sendToAll(message), ogni aggiornamento della griglia prodotto dal gioco viene inviato a tutte le connessioni attive, permettendo ai non-owner di osservare lo stato corrente correttamente.

Testing

Deployment

La procedura seguita è basata su Docker e prevede:
  1. Generazione dell'archivio distribuibile tramite il comando gradlew distTar.
  2. Creazione dell'immagine Docker personalizzata: docker build -t gui26html:1.0 ..
  3. Esecuzione del container con mappatura della porta 8080: docker run -p 8080:8080 gui26html:1.0.
Utilizzo Docker Compose per coordinare i diversi nodi del sistema (Logica e GUI) tramite il file conway26Guihtml.yaml, avviabile con il comando: docker-compose -f conway26Guihtml.yaml up

Maintenance



By Desirée Pellegrini email: desiree.pellegrini@studio.unibo.it, emiglio GIT repo: https://github.com/desypellegrini/IngegneriaSistemiSoftware2026.git