Riunione del 07/03
In questa prima riunione abbiamo parlato del materiale raccolto da ogni persona,esponendo i concetti che sono
alla base della moneta elettronica e cercando di capire come avvengono i pagamenti nel sistema monetario italiano.
Abbiamo deciso, inoltre, di chiarirci le idee su alcune forme di pagamento elettronico gia' presenti (Bancomat, Pos,
Borsellino elettronico della Bull).
Dopo di questo abbiamo deciso di inviare dei nostri dipendenti su Naxos per capire come si svolge la vita in questa
citta' e come sia organizzato il suo sistema monetario. Questo ci permettera' di adattare il nostro prodotto alle
esigenze degli abitanti di Naxos.
Riunione del 12/03
Alla riunione erano presenti solo i tre componenti presenti sulla terra.
Ci siamo trovati a discutere su una caratteristica della moneta: l'Identita'.
Abbiamo cercato di capire se anche la moneta elettronica doveva avere un numero d'ordine che la distinguesse e siamo
giunti alla decisione che noi non consideravamo questa opportunita' solo dopo accese e lunghe discussioni.
Riunione del 15/03
Nel calendario delle presenze i nostri due inviati ancora mancavano.
Abbiamo chiarito i seguenti concetti:
cosa si intende per "diversi livelli di anonimato" e come realizzarli conoscendo gli attuali su Naxos (cio' e' stato possibile grazie alle interazioni con i nostri inviati via satellite).
Abbiamo preso atto della situazione patrimoniale degli abitanti di Naxos e delle loro abitudini e inoltre di
quale sia il ruolo della banca all'interno del sistema.
Questo pero' solo in linea generale tramite i collegamenti con gli inviati, infatti aspettiamo un rapporto dettagliato.
Riunione del 17/03
I nostri inviati fortunatamente per loro sono ancora su Naxos.
In questa seduta abbiamo analizzato gli aspetti della sicurezza dei borsellini elettronici e delle transizioni.
Per il primo problema abbiamo pensato ad eventuali accessi al capitale tramite riconoscimento della retina(come
password, ed eventualmente anche un PIN).
Per il secondo problema abbiamo pensato a validi sistemi criptici, ancora non totalmente specificati.
Riunione del 20/03
Nella riunione odierna abbiamo analizzato le informazioni raccolte dai nostri inviati durante la loro
premanenza su Naxos e abbiamo fatto una prima stesura dello scenario.
Abbiamo, infine, portato il tutto in formato HTML e lo abbiamo reso ufficiale.
Inoltre oggi sospendiamo le attivita' per le vacanze di Pasqua,
pertanto auguriamo una " Buona Pasqua" a tutti i visitatori.
Fissiamo la prossima riunione per il giorno 7/4.
Riunione del 07/04
Da oggi parte la fase del progetto che mira a concretizzare una proposta del Sistema Monetario
Elettronico. Partendo da quello che era l'ultimo documento pubblicato, ora abbiamo iniziato a renderci
conto delle possibili difficolta' di progettazione, come i sistemi di riconoscimento dela retina...
Riunione del 10/04
L'attenzione si e' focalizzata sull'individuazione delle possibili forme di transazione che possono
avvenire tra gli abitanti di Naxos.
A questo proposito sono stati previsti 5 tipi di transazione, che danno luogo a 5 diversi tipi di
collegamenti tra gli utenti del Sistema Monetario Elettronico.
Riunione dell' 11/04
Quale Livello di Anonimato interviene in ogni collegamento individuato ?
Ecco che prendono forma 3 livelli diversi: da quello completo, a quello intermedio per finire alla totale
trasparenza della transazione.
Riunione del 14/04
Quello che ora ci preme di piu' e' rendere sicuro il Sistema Monetario Elettronico. E' vero che si vuole
sfruttare IntraNexos che offre gia' dei particolari sistemi di sicurezza, ma in piu' vogliamo dotare di
questa proprieta' anche gli strumenti del nostro Sistema. In particolare la WorkStation sara' in grado
di codificare i messaggi che compongono una transazione, nonche' di decodificarli. Lo Skill avra' un
suo processore per effettuare controlli sull'importo da caricare sulla Starcard. Questo perche' si vuole
tutelare l'utente e impedirgli di distruggere ingenti somme di e-money in caso di accidentale guasto,
distruzione o smarrimento della Starcard carica.
Riunione del 17/04
Anche di notte...
Per completare la stesura in formato HTML della proposta, abbiamo preferito presentare un diagramma
con i possibili collegamenti in modo da rendere piu' chiara la nostra visione.
Riunione del 18/04
Pubblicazione documento di proposta e partenza delle storie delle Versioni.
Riunione del 21/04
Da una prima lettura individuale del documento di proposta si sono ricavate 3 liste dei requisiti e
due glossari. Il lavoro ora e' di unificare glossario e requisiti.
Riunione del 23/04
Una prima bozza di lista dei requisiti ne conta circa 110. Mentre per il glossario si contano circa 60
termini.
Riunione del 28/04
Abbiamo preparato 2 tipi di listi dei requisiti: una da sottoporre alla verifica di comprensione di Cico,
l'altra in linguaggio piu' naturale. Stessa cosa per il glossario.
Riunione del 29/04
Senza farci prendere dallo sconforto...Cico ha delle difficolta' a comprenderci, o meglio siamo noi
che non sappiamo parlare la sua lingua. Bisogna cercare di non stravolgere il senso dei nostri requisiti.
Riunione del 30/04
Ora che Cico fornisce i suoi diagrammi, riusciamo ad individuare 3 sottosistemi principali nel nostro
Sistema Monetario Elettronico: la NaxosBank, la classe delle WorkStation e la classe degli Skill.
Riunione del 02/05
Pubblichiamo quello che siamo riusciti a elaborare con Cico anche se l'analisi presenta ancora degli
errori e dei resti. Contiamo di risolvere ogni problema entro la prossima settimana per prepararci poi
alla stesura dei diagrammi OMT.
Quello che Cico ci ha aiutato a capire e' che alcuni elementi che per noi erano essenziali, in realta'
erano trascurabili, in quanto non modellabili con le entita' e relazioni, ne' con i diagrammi dei flussi
di dati. Per questo scompaiono dai requisiti la rete di comunicazione, i livelli di anonimato e i tipi
di collegamenti.
Riunione del 12/05
In vista della prossima scadenza nella quale si dovranno pubblicare le prime versioni dei
diagrammi OMT, abbiamo finalmente risolto tutti i conflitti con Pandora e ottenuto da Cico
dei grafici piu' leggibili e piu' attinenti alle nostre specifiche. Ad ogni componente del gruppo
e' stato assegnato il compito di disegnare uno dei modelli.
Riunione del 19/05
Pubblicazione della prima versione dei modelli OMT.
Riunione del 28/05
Revisione dei diagrammi OMT: eliminazione di metodi ed alcuni attributi dal modello a
oggetti, nonche' la modifica di alcune transazioni ed etichette dal modello funzionale.
Si considera conclusa la fase di analisi per passare a quella di progettazione.
Si comincia a realizzare un'interfaccia utente che, sebbene dovrebbe simulare il comportamento
del sistema, in realta' e' costruita su un sistema di basi di dati e quindi perfettamente
funzionante.
Riunione del 03/06
Per iniziare la progettazione si e' pensato di espandere le azioni dei sottosistemi etichettate
con "elabora" nelle opportune operazioni. La WorkStation prima di inviare una richiesta la
codifichera', decodifichera' invece le richieste ricevute.
Ai fini della sicurezza:
-quando l'utente effettua una transazione con la banca, e' questa che si assume l'incarico di
modificare Riserva Locale e Conto Corrente, nonche' di aggiornare la History;
-quando un utente compie una transazione con un altro utente, e' il destinatario che si
assume l'incarico di aggiornare entrambe le Riserve Locali e le History. Il fatto che un
utente possa modificare la propria Riserva locale (incrementandola) e' permesso solo se c'e'
la richiesta di pagamento da parte di un altro utente;
-quando un utente carica o scarica la Starcard, sara' lo Skill a modificare la Riserva Locale e
ad aggiornare la History.
In ogni caso e' impossibile per un utente incrementare arbitrariamente i propri fondi, in
quanto la somma dovrebbe comunque essere scalata dal proprio conto corrente o Riserva
Locale o da una Riserva Locale di un utente debitore.
Riunione del 09/06
Si realizzano le impaginazioni dell'interfaccia costruita con Oracle e si pubblicano i
diagrammi OMT relativi alla fase di progettazione.
Riunione del 10/06
Backtracking finale. Pubblicazione dei diagrammi a entita' e relazioni grabbati da Cico.
Chiusura della progettazione.
Back