Soluzione proposta

Per poter proporre una soluzione è necessario andare ad analizzare i punti discussi nei paragrafi precedenti, cercando una soluzione che possa adattarsi nel modo più consono al progetto in questione.

Per quanto riguarda il tipo di piattaforma si è scelto di utilizzare una architettura SOA in modo che l’applicazione possa essere quanto più scalabile e facile da manutenere possibile (nel tempo possono essere aggiunte nuove funzionalità), indipendente dai vari tipi di client e possa interagire con altri sistemi simili (utilizzo di altri web service). L’insieme dei servizi web faranno da “motore” ad una applicazione web che verrà usata dagli utenti. I web service dunque, saranno completamente trasparenti agli utenti.

Per quanto riguarda la scelta del linguaggio di programmazione, si ritiene opportuno utilizzare il linguaggio Java in ambiente J2EE; il linguaggio Java, a differenza degli altri, offre i seguenti vantaggi:

• Ambiente di sviluppo totalmente gratuito (non proprietario)

• Portabilità del software: possibilità di installare l’applicazione su vari tipi di server (server Windows o server UNIX-based)

Il linguaggio Java sarà utilizzato sia per lo sviluppo dei web service sia per lo sviluppo dell’applicazione web. Per l’implementazione dei web service verranno utilizzati gli EJB che andranno a contenere le effettive attività da svolgere (business) dell'applicazione. Gli EJB si occupano di interfacciarsi con il database che memorizza tutti i dati inerenti all'applicazione tramite dei connettori JDBC. L’intera applicazione sarà sviluppata utilizzando come ambiente di sviluppo il software Eclipse (Uno degli IDE più usati a livello internazionale per lo sviluppo di software, consigliato anche dalla SUN

Microsystems, sviluppatore di Java).

Come DBMS è stato scelto Postgresql 9.2 che oltre ad essere distribuito con licenza GNU GPL (licenza per software libero) è molto flessibile in quanto può essere utilizzato sia su sistemi Unix sia su sistemi Windows. Inoltre Postgresql 9.2 si interfaccia perfettamente con il server scelto, ovvero JBoss 7.1.1.

Si prevede di installare uno o più server presso il “Dipartimento di Ingegneria dell'Informazione”, quantomeno per le prime versioni rilasciate dell'applicazione. In seguito tali server saranno spostati o aggiunti ex-novo in sede dell'azienda. Il carico che andremo a gestire sul server può essere variabile, dipenderà in maniera esponenziale al numero degli utenti che andranno ad utilizzare l'applicazione. Nella prima versione consideriamo di andare a coprire un carico “medio-basso” consistente di circa 100 richieste l'ora; dunque basta utilizzare un server di fascia media purché disponga di una discreta memoria di archiviazione (date le grandi dimensioni dipendenti dal numero elevato dei tweet da archiviare). Alle caratteristiche di base sopra elencate, dovremmo aggiungere un disco rigido con capacità di 1 Tb per poter garantire, almeno inizialmente, lo spazio di archiviazione necessario.

Il server deve essere installato in una location nella quale la temperatura in media (giornalmente) sia inferiore ai 25°C per evitare il surriscaldamento della macchina.

La macchina server inoltre dovrà essere collegata ad un gruppo di continuità per permettere il corretto funzionamento anche in caso di assenza di corrente elettrica (almeno per un certo intervallo di tempo). Per poter garantire una corretta funzionalità del prodotto è necessario avere una connessione alla rete internet con indirizzo IP statico ed una velocità di connessione che possa

permettere il trasferimento dei dati in tempi ragionevoli anche in caso di accessi concorrenti. In release future ci si aspetta di dover potenziare il server (magari installandone più di uno in parallelo) in modo tale da poter gestire un numero di richieste all'applicazione “reale”. Inoltre si pensa di andare a sviluppare delle App per smartphone in grado di consentire agli utenti di usufruire dei servizi in maniera semplice, diretta e mobile. Nel caso in cui si voglia estendere l'uso dell'applicazione non solo nella ricezione di eventi legati al traffico e alla mobilità stradale, ma al verificarsi di eventi d'interesse generale, si prevede ovviamente una crescita esponenziale del numero di richieste d'accesso all'applicazione software. Questo può essere gestito potenziando in maniera adeguata sia il database (incrementando la memoria disponibile) sia il server (aumentandone qualità e numero) sia la banda della connessione internet. Nel caso che si prevedano un numero di richieste superiore alle 350 l'ora si dovrà andare a stipulare un contratto commerciale con Twitter al fine di entrare in quella che viene definita una “white list” di applicazioni che hanno accesso al social network con 20.000 richieste l'ora.

Nei servizi esportati si usufruirà della GoogleMapsApi per effettuare le geo- localizzazioni e tradurre in indirizzo le coordinate espresse come coppie latitudine-longitudine, se lo sviluppo dell'uso dei servizi esportati volge verso uno scenario di grandi dimensioni si dovrà andare a stipulare un contratto di collaborazione commerciale anche con Google al fine di estendere il numero delle richieste disponibili da 300 l'ora a nessuna limitazione.

Le operazioni di text mining saranno effettuate tramite l'uso di alcune delle API messe a disposizione da Weka. Weka, acronimo di "Waikato Environment for Knowledge Analysis", è un software per l'apprendimento automatico sviluppato nell'università di Wakaito in Nuova Zelanda. È open source e viene

rilasciato con licenza GNU General Public Licence [37]. Curiosamente la sigla corrisponde al nome di un simpatico animale simile al Kiwi (uccellino simbolo del programma), presente solo nelle isole della Nuova Zelanda. Weka è un ambiente software interamente scritto in Java, risultando quindi estremamente customizzabile e integrabile con la piattaforma software obiettivo. Un semplice metodo per utilizzare questo software consiste nell'applicare dei metodi di apprendimento automatici (learning methods) ad un set di dati (dataset) e analizzarne il risultato. Le API fornite da Weka saranno utilizzate all'interno della piattaforma software sia per allenare i modelli di classificazione, sia per svolgere tutte le operazioni necessarie al processo di text mining, ovvero la classificazione vera e propria dei tweet per ricercare tramite essi il verificarsi degli eventi critici individuati legati alla viabilità.

All'interno della piattaforma software il processo di pre-elaborazione dei dati verrà demandato a lato software, ovvero sarà implementato in parte tramite delle apposite funzioni Java che si occupano di effettuare Data Cleaning e Data Integration sui tweet, in parte sfruttando appieno le potenzialità offerte da Weka tramite l'uso dei filtri.

Le funzioni che saranno implementate useranno le espressioni regolari RegEx [38] (Regular Expressions) per andare ad effettuare pulizia sulla parte testuale dei tweet tramite l'uso delle funzioni Matcher e Pattern derivanti dalla teoria Java sulle stringhe testuali [39]. Saranno eliminati dalla parte testuale dei tweet tutti quei caratteri e le informazioni che non portano alcuna informazione aggiuntiva ma che invece potrebbero generare rumore e inesattezze di risultato nei passi successivi del processo di pre-elaborazione dei dati e della classificazione vera e propria.

Per quanto concerne i problemi legati all'applicazione delle tecniche di text mining [21] su tweet in lingua italiana deve essere posta particolare attenzione all'implementazione dello stemmer e del file contenente le stopwords da rimuovere come la teoria del text mining propone. Inoltre, si deve prestare attenzione alla costruzione del data set di training con cui si va ad allenare il modello di classificazione: si deve cercare di inserire in esso un buon numero di casi particolari e ambiguità sulle parole inerenti all'evento critico (es. traffico stradale, che identifica l'evento traffico e traffico di droga che non lo deve identificare) per far si che il modello riesca a distinguere, una volta “allenato”, il giusto contesto delle parole.

Infine per quanto riguarda la parte relativa alla classificazione vera e propria verranno utilizzati dei modelli di classificazione progettati “ad hoc” sugli eventi che si andrà ad individuare come critici. Questi saranno progettati e costruiti tramite l'uso del software Weka integrato all'interno della piattaforma software e saranno poi utilizzati per la reale classificazione dei tweet in maniera efficiente. Deve inoltre essere posta particolare attenzione alle ottimizzazioni del codice Java inerente la classificazione dei tweet per ridurre al minimo il tempo necessario al server per classificare i tweet e per restituire i risultati.