UniboEnv

Durante l'iterazione si è venuti a conoscenza di un ambiente per la gestione delle interazioni a scambio di messaggi funzionante anche in ambiente distribuito. Pertanto si è valutata positivamente la possibilità di introdurlo durante una seconda iterazione. Le strade che si aprono dopo una approfondita analisi sono le seguenti:

1. ripensare i componenti appoggiandosi direttamente al framework
2. scrivere degli opportuni adattatori tra i vari componenti e il framework
3. non usare il framework e realizzare l'interazione in ambiente distribuito in altra maniera

La prima ipotesi comporta una riscrittura pressochè totale della documentazione, del codice e di buona parte del collaudo.

La seconda comporta la scrittura di un adapter per ognuno dei componenti che si vuole interfacciare usando il framework. Il vantaggio è che i componenti sono già stati tutti testati e che in un futuro volendo passare ad un altro framework basterà riscrivere solo gli adapter e i loro test. La terza ipotesi comporta la ricerca di una strada alternativa non troppo onerosa in termini di ore di lavoro.

GenericGraphicConsole

Potrebbe essere strategico realizzare una Console di I/O in che possa contenere un numero non definito a compile time di pulsanti/display.

Comunicazione

Si e' scelto di non appoggiare la messaggistica tra HumanDevicesController e Display e tra HumanDevicesController e CounterController. La progettazione e la realizzazione di CounterController e di Display sono state assegnate a due team interni diversi e ognuno si e' occupato di HumanDevicesController solo per quel che riguardava la propria parte di interazione. Il risultato e' stato che non si e' scelta una modalita' univoca per la comunicazione con HumanDevicesController.

CounterController passa il dato da visualizzare mediante notifyActualValue(int val,String kind), mentre HumanDevicesController notifica il dato da visualizzare incapsulandolo in un oggetto di tipo IMessage e invocando sui Display interessati notifyUpdate(IMessage mess).

Volendo sostituire/adattare HumanDevicesController con un framework che realizzi l'astrazione di message-passing (UniboEnv ad esempio) si sara' costretti a realizzare adapters ad-hoc per ognuna delle parti che andranno ad interfacciarsi col framework.

Probabilmente se sin da principio si fosse usata una codifica uniforme (ad esempio marshalling e unmarshalling di documenti xml e la definizione di alcune primitive di I/O) di molte delle parti degli eventuali adapter sarebbero potute essere messe a fattor comune.

Deploy

Il deploy degli artefatti si e' rivelato abbastanza dispendioso in termini di tempo. Gli automatismi introdotti da maven venivano in parte sviliti dalla necessita' di un pesante intervento umano per interfacciarsi a moodle. Purtoppo in questa fase non si e' avuto modo di configurare e testare a fondo strumenti di Continuus integration quali Maestro o CruiseControl che si sarebbero integrati in maniera abbastanza agevole con il sito di sviluppo su sourceforge.net.

Logging

Al momento non si sono introdotti strumenti di logging quali Log4j poiche' non ci sono stati grossi problemi nel collaudo dell'applicazione. ma, laddove si e' ricorso alle System.out.println per esternalizzare lo stato dell'applicazione e' stato affiancato un commento // TODO LOG4j al fine di ritrovare in fretta i punti in cui e' opportuno eseguire del logging. In vista di una migrazione verso un ambiente distribuito l'introduzione di Log4j e' pressoche' obbligatoria per poter raccogliere le informazioni nel miglior modo possibile in un ambiente non piu' coeso.