Calendario

Calendario

27/04/2018

1. implementazione locale
   1. Utenti vs controller
      1. identificazione a livello di controller (rmi provides only an identification based on ip. Using this as an identifier will result in a great limitation )
   2. toolcard
      1. decidere come suddividere l'applicazione/suddivisione parametri (con classi vere e proprie, array di oggetti, eventi)
      2. come comunicarne l'utilizzo al controller(dividiamo raccolta dati dall'utente e utilizzo sol model)
      3. implementazione (1..6)
      4. testing
   3. eventi
      1. validazione comportamento dell'utente (a livello di controller?, proxy?)
      2. verificare che non ne manchino
      3. rivedere visitor pattern
   4. calcolo dei punti
      1. sottrazione punti per spazi vuoti
      2. cambiare l'interfaccia delle objective card spostando checkCondition come privato? non si può -> classe astratta
      3. vincita
      4. determinare il vincitore
   5. controllare vincoli ed eccezioni ai vincoli
   6. in previsione della rete
      1. il client mantiene una copia del model ma non può modificarne il model contenuto nel server se non tramite richieste al controller
2. testing di unità
   1. mock
   2. testing di unità black box (sulle interface e non sulle particolari implementazioni)
   3. testing di condition coverage
   4. analisi con sonar
   ***

   1/04/2018

3. start doing it seriously
   1. toolcard
      1. terminare implementazione (7..12)
      2. testing delle nuove carte
   2. Multithreading
      1. Evitare stack di attivazione "infinito"
   3. rete
      1. model
         1. occuparsi della serializzazione: oscurare campi ivisibili da altri utenti
      2. socket
      1. socket proxy controller
      2. socket proxy view
      3. definire un protocollo imperniato sul pattern command: 2 tipologie di messaggi per ogni metodo richiamabile sul controller : 1 request, argomenti del metodo passati al suo interno, 1 response valore di ritorno passato come campo al suo interno
      4. decidere thin / vs thick
      1. Per ora il diagramma delle classi è talmente generale da rendere semplice realizzare sia thin che thick client.
      2. salvarsi le azioni compiute: optiamo per una scelta ibrida in questo momento per tenerci aperta la scelta thin o thick.

         PRO thin	CONTRO thin
         Meno responsabilità	si necessita ugualmente di dare alla view una copia del model/ anziché una rappresentazione come avviene nelle view normali
         Controlli che avvengono solo una volta (Però usando la gerarchia tra classi si potrebbe evitare di riscriverli)	nel single player si necessita ugualmente del server
         continue interazioni tramite rete

      3. testing integrazione
      3. rmi
4. view GUI
   1. rappresentazione grafica delle pattern card dinamiche
   2. testing integrazione
5. riconnessione
   1. modifiche
   2. testing integrazione
6. finire documentazione
   1. controllare tutte che tutte le classi siano in inglese
   2. documentare le classi