Mesos / progetto di gruppo di ingegneria del software
Una partita online, client diversi, un solo server.
Abbiamo trasformato Mesos in un gioco client-server in Java. Nella stessa partita possono entrare giocatori con interfaccia grafica o testuale e con collegamento Socket o RMI; il server mantiene per tutti lo stesso stato del gioco.
Politecnico di Milano, anno accademico 2025/26. Team di quattro persone; valutazione finale: 30/30.
- Esito
- 30/30
- Team
- 4 persone
- Il mio lavoro
- Server, Controller, Socket e RMI
- Verifica
- Test unitari e di integrazione
Il gioco
I giocatori creano o raggiungono una partita dalla lobby, giocano i turni secondo le regole di Mesos e vedono il risultato finale. Il server può gestire più partite contemporaneamente e conserva la classifica delle partite concluse in un database.
Il mio contributo
Ho implementato il lato server: il Controller che riceve le azioni e coordina le partite, e i due percorsi di comunicazione Socket e RMI. Ho contribuito con il team ai diagrammi UML del model e del server e ho lavorato sulle classi del giocatore nel model.
Le regole del gioco, le interfacce e la classifica sono il risultato del lavoro collettivo.
Due protocolli, una logica di gioco
Prendi l'ingresso di un giocatore in una partita: con Socket la richiesta viaggia come messaggio, con RMI come chiamata remota. In entrambi i casi arriva allo stesso Controller, che aggiorna la partita e invia lo stato ai client collegati.
Le interfacce comuni VirtualServer e VirtualView tengono il trasporto fuori dalle regole. Nel percorso Socket, ogni messaggio contiene l'azione da eseguire (pattern Command). Il server può così mescolare client Socket e RMI nella stessa partita.
Il model: partite e regole separate
Nel model, LobbyManager tiene distinte le partite. Ogni partita ha un GameManager e uno stato che rappresenta la fase corrente: lobby, piazzamento, azioni o punteggio. Una mossa non valida per quella fase viene respinta dal relativo stato.
Gli effetti speciali delle carte sono oggetti separati: il gioco li richiama tramite un'interfaccia comune, invece di cercare il tipo concreto della carta in una lunga serie di condizioni. Sono applicazioni dei pattern State e Strategy visibili nel model del team.
Come abbiamo separato i test
La struttura permette di verificare un pezzo senza avviare ogni volta l'intero gioco. Il team ha coperto regole, coordinamento, rete e persistenza con prove a livelli diversi.
Regole del gioco
Test del model e del passaggio fra le fasi senza server né interfaccia.
Controller
Partite e client simulati: si verifica a chi arrivano aggiornamenti ed errori.
Socket e RMI
Test di integrazione con comunicazione reale e Controller simulato, per isolare il trasporto.
Classifica
Repository sostituibile: dati in memoria nei test, H2 per l'integrazione, PostgreSQL nell'applicazione.
Il team lavorava su branch per funzionalità; prima del merge i test erano assegnati a una persona diversa da chi aveva implementato quella funzione.
Materiali del progetto
La relazione riassume funzionalità, ruoli, pattern e copertura dei test. Il repository contiene codice, test e deliverable; è privato e il collegamento funziona per chi ha accesso.