ConwayLife Sprint1

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

Per Cell, dopo aver parlato con il committente, formalizzo il seguente modello:
ICell: ICell.java.
Test plan per Cell: CellTest.java

Il committente ha un'idea di Grid composta da Cell. La Grid è un'entità a due dimensioni, con righe e colonne.
IGrid: IGrid.java.
Test plan per Grid:
Sviluppo un test plan per definire il comportamento atteso della griglia.

1. Mi assicuro che i metodi get restituiscano un numero naturale
2. Nella reset controllo che tutte le celle siano morte

GridTest.java

Il committente non sa cosa sia Life, ma mi dice che è la logica del gioco e contiene le regole del gioco. Strutturalmente, Life è composta da una griglia.
LifeInterface: LifeInterface.java
Test plan per Life:
Sviluppo un test plan per definire il comportamento atteso di Life.

1. Imposto una configurazione conosciuta e controllo che segua le regole
2. Nella reset imposto una cella, chiamo nextGeneration e controllo che sia morta

LifeTest.java

Definisco inoltre il LifeController, al cui interno ha un thread (play), che dà vita ai vari elementi trasferendo loro il controllo. LifeController definisce le interfacce per permettere a qualsiasi dispositivo di visualizzare la griglia. Si tratta di un componente proattivo (quando attivato, il thread play chiama ripetutamente nextGeneration) e reattivo (se c’è un input device che dice start/stop, lui parte/si ferma).
LifeController.java

• Natura Proattiva: il sistema deve evolvere autonomamente secondo le regole di Conway. Questo implica la necessità di un'entità (Controllo) capace di scandire il tempo e invocare la generazione successiva senza interventi esterni costanti.
• Natura Reattiva: il sistema deve restare in attesa di eventi asincroni (comandi dell'utente come Start, Stop, Clear o click sulle celle). È necessario quindi un meccanismo che permetta di interrompere o modificare lo stato del sistema proattivo in modo sicuro.
• Indipendenza della Vista: come indicato in Problema della vista del gioco, la visualizzazione del gioco non deve essere cablata nel sistema. È necessario definire un 'linguaggio di output' astratto (interfaccia IOutDev) che permetta di iniettare diverse implementazioni della vista (Mock, Swing, HTML) a seconda del contesto di deployment, garantendo il disaccoppiamento tra logica e rappresentazione.
• Architettura Logica e Interazione: Come mostrato nel modello logico del sistema, i componenti comunicano attraverso messaggi/eventi. Il Controller deve fungere da mediatore tra i comandi provenienti dai dispositivi di input e lo stato del Modello, garantendo che le azioni dell'utente (es. switch di una cella) siano gestite correttamente rispetto al ciclo proattivo di evoluzione.
  Rappresentazione dell'Architettura Logica:
  
  
  Il diagramma evidenzia la separazione tra il controllo (LifeController), il dominio (Life) e i dispositivi di I/O.

Il progetto traduce l'architettura logica in componenti software seguendo il principio del disaccoppiamento:

• Il sistema si basa su interfacce che definiscono il comportamento dei componenti senza vincolarli a un'implementazione (LifeInterface, IGrid, ICell, IOutDev).
• La classe Life implementa la transizione di stato. Per garantire l'invarianza, utilizza una griglia corrente e una griglia next. Il calcolo della generazione avviene leggendo dalla prima e scrivendo nella seconda, effettuando poi uno swap dei riferimenti.
• LifeController implementa GameController e gestisce il comportamento autonomo del sistema tramite un thread interno. Questo permette di mantenere il battito del gioco (generationTime) separato dalla gestione dei comandi Start/Stop/Clear.
• Il MainConwayLifeJava agisce come configuratore del sistema, istanziando i componenti concreti e iniettandoli nel Controller, realizzando così il sistema finale.

Codice di Configurazione (Main)

Il deployment del sistema è basato sull'utilizzo di Gradle come strumento di automazione per la build. Tramite il task jar definito nel file build.gradle, il sistema viene compilato in un unico archivio eseguibile che include tutte le librerie necessarie (unibo.basicomm23, uniboInterfaces, ecc.).
Il file JAR così generato permette l'esecuzione del gioco Conway su qualsiasi macchina dotata di Java Runtime Environment, senza la necessità di un IDE (Eclipse) o di configurazioni manuali del classpath.
Il comando per l'avvio del sistema distribuito è: java -jar conway26Java-1.0.jar.