Persistenza delle categorie

Per ciò che riguarda la gestione della persistenza delle categorie di documenti ham e spam utilizzati per addestrare il sistema, si era deciso in primo luogo di serializzare su file gli oggetti software che le rappresentano. Per questo motivo la classe del modello PersistentCategory non fa altro che tenere le informazioni essenziali della classe EmailCategory (che è quella effettivamente utilizzata dall'applicazione nello svolgere i compiti della logica applicativa): essa veniva quindi serializzata su file attraverso la libreria pickle del linguaggio Python.

C'è da dire che le due classi software non comunicavano direttamente fra di loro, ma in mezzo risiedeva la classe PersistencyHandler, che si occupa, a partire da una EmailCategory, di istanziare a partire da essa una PersistentCategory e infine serializzarla su file. La classe PersistencyHandler svolgeva anche il compito opposto: deserializza da file una PersistentCategory e costruiva a partire da essa una EmailCategory, che veniva poi utilizzata dall'applicazione.

Entrando nel dettaglio, le due categorie serializzate venivano salvate nei file hamcategory e spamcategory all' interno della cartella personale contenente la configurazione di SpamGAME per l'utente. Tutto ciò per l' utilizzatore dell' applicazione è comunque assolutamente trasparente.

La motivazione di conservare questi dati di fondamentale utilizzo e quanto più rapido accesso sul file system attraverso la libreria pickle di Python era stata dettata soprattutto dalla rapidità di sviluppo che tale strategia consentiva, e soprattutto perchè l' utilizzo di una base di dati (e quindi di un DBMS) per conservare in modo persistente i dati non sarebbe strettamente necessario perchè:

• tali categorie persistenti non verranno accedute in maniera concorrente da più istanze (o dalla stessa istanza) dell' applicazione. Pertanto non necessitano della gestione della concorrenza che un DBMS offre

• l' utilizzo di una base di dati avrebbe necessitato, nella maggior parte dei casi, che tale base di dati venisse predisposta (o creata al momento dell' installazione) sul sistema usato dall' utente, rendendo quindi meno immmediata l' installazione e l' utilizzo dell' applicazione

• la serializzazione degli oggetti da parte della libreria pickle di Python è sufficiente veloce e adatta al tipo di dati che bisogna serializzare su file

In fase successiva è avvenuto un cambio di strategia: invece che serializzare su file in formato pickle, si è scelto di utilizzare una base di dati. In particolare è stato usato un embedded db (Berkeley DB [41]), che ha presentato i seguenti vantaggi:

• dai confronti effettuati ha mostrato maggior velocità di esecuzione in fase di de-serializzazione dei dati rispetto all' uso della serializzazione nativa Python e ha evidenziato circa lo stesso ordine di grandezza di velocità in fase di serializzazione

• poichè i dati da salvare altro non sono che due grosse hash table, la natura ``a dizionario'' dei record della base di dati del Berkeley DB ha soddisfato pienamente i requisiti della persistenza

• le librerie per l' utilizzo del Berkeley DB sono incluse nelle librerie standard distribuite con Python, quindi non hanno necessitato l' installazione di pacchetti addizionali per il funzionamento dell' applicazione

Nel concreto la serializzazione viene effettuata sempre dalla classe software PersistencyHandler, che si occupa di scrivere (leggere) sulle (dalle) due basi di dati ham.db e spam.db di cui ciascun utente dell' applicazione dispone. Anche in questo caso la gestione della persistenza è assolutamente trasparente per l' utente.