"Riconoscimento Vocale e Smartphones":

UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica e dell'automazione "Riconoscimento Vocale e Smartphones": Sviluppo di un'applicazione capace di dialogo su piattaforma Android Tesi di: Nicola Sturari Relatore: Prof. Aldo Franco Dragoni Anno Accademico 2011/2012

Indice Generale Introduzione...3 1. Il Sistema Android......4 1.1. Panoramica...4 1.2. Struttura del sistema...5 1.3. Activity.6 1.4. Sviluppare per Android 8 2. Riconoscimento Vocale 12 2.1. Panoramica..12 2.2. Principi di funzionamento...13 2.3. Sviluppi recenti 15 3. Lo Standard VoiceXML...16 3.1. Origine.16 3.2. Tag...17 3.3. Considerazioni su VoiceXML. 19 4. L'interprete VoiceXML...20 4.1. Interpreti gratuiti e open-source..20 4.2. Il parsing..22 4.3. VxmlInterpreter...24 5. Realizzazione dell'applicazione...26 5.1. Il primo prototipo 26 5.2. App finale 28 6. Conclusioni 30 Appendice A..31 Diagramma delle classi...31 Diagramma di sequenza..32 Codici relativi all interprete 33 Appendice B..44 Codice dell Activity 44 Bibliografia 48 2

Introduzione Questo lavoro nasce dalla volontà di esplorare ed integrare due tecnologie nate in periodi diversi, verso cui si manifesta un crescente interesse da parte dei produttori di software, dalle grandi aziende, come Google, ai piccoli sviluppatori indipendenti, come noi durante il nostro tirocinio. I primi due capitoli di questa tesi si concentrano quindi sull esplorare e spiegare i due grandi temi che la caratterizzano, da una parte il sistema Android, di cui ormai anche chi non si intende di informatica e nuove tecnologie avrà almeno sentito parlare, e dall altra il Riconoscimento Vocale, una tecnologia sempre più presente nella vita di ogni persona. Il tirocinio, svoltosi presso il Dipartimento di Ingegneria dell Informazione dell Università Politecnica delle Marche, ha avuto come obiettivo finale la realizzazione di un applicazione Android capace di dialogare con l utente. Nel tirocinio ha lavorato con me un altro studente del corso di Ingegneria Informatica e dell Automazione, Emanuele Cardelli. Pur affrontando insieme tutti i problemi, ognuno di noi si è dedicato maggiormente ad aree diverse del progetto, motivo per cui questo elaborato non tratta in modo specifico della Sintesi Vocale, tecnologia anch essa necessaria e presente nell applicazione finale. Inoltre, durante lo sviluppo, per gestire la logica dei dialoghi, abbiamo deciso di utilizzare un particolare linguaggio di markup che si propone come standard per le applicazioni vocali: VoiceXML. A questo argomento è dedicato il terzo capitolo. Per poter utilizzare il linguaggio VoiceXML si rende necessario disporre di un interprete ed è in questa parte del lavoro che abbiamo incontrato le maggiori difficoltà, non riuscendo ad utilizzare con successo interpreti open-source prodotti da terze parti. Di ciò si parla nel quarto capitolo, che illustra anche la nascita di una soluzione temporanea a questi problemi, un interprete VoiceXML realizzato da noi. Infine nel quinto capitolo si analizzano le varie fasi dello sviluppo della applicazione, con spiegazione di alcuni dei meccanismi di funzionamento, dal primo prototipo al prodotto finale. Il capitolo conclusivo contiene considerazioni sull esperienza complessiva e le prospettive future di questo lavoro. Nelle appendici trovano posto due diagrammi, che aiutano la comprensione della struttura dell interprete e del suo funzionamento in relazione con il thread principale dell applicazione, e i codici finali del progetto. 3

1. Il Sistema Android 1.1. Panoramica Android è un sistema operativo basato su Linux, ideato principalmente per dispositivi mobili come smartphones e tablet. Il progetto ha avuto origine con la società Android, Inc. fondata a Palo Alto, California nell Ottobre del 2003 da Andy Rubin, Rich Miner e Chris White per sviluppare dispositivi mobili più intelligenti che siano più consapevoli della posizione e delle preferenze del proprio possessore. Nell Agosto del 2005 viene acquisita da Google mantenendo nello staff i membri chiave del progetto originale. Il 5 Novembre 2007, l associazione Open Handset Alliance, composta da 86 aziende che si occupano di hardware, software e prodotti per le telecomunicazioni, tra cui Google, Broadcom Corporation, HTC, Intel, LG, Marvell Technology Group, Motorola, Nvidia, Qualcomm, Samsung Electronics, T-Mobile e Texas Instruments, si rivela al pubblico con lo scopo dichiarato di sviluppare standard aperti per dispositivi mobili. Nello stesso giorno viene svelato il loro primo prodotto: Android. La versione originale è rilasciata sotto licenza Apache e si basa sul kernel Linux versione 2.6, a cui si aggiungono librerie e API scritte in C e una speciale Java Virtual Machine. Discuteremo il sistema nel dettaglio più avanti nel corso di questo capitolo. Lo sviluppo e la manutenzione di Android sono affidati all AOSP (Android Open Source Project), che cerca di realizzare una singola implementazione, ulteriormente personalizzabile dalle aziende partecipanti, come Samsung, HTC, LG. Gli smartphones dei diversi produttori, infatti, presentano sistemi leggermente diversi e con differenti applicativi, mantenendo però una completa compatibilità. Pochi giorni dopo l uscita della beta di Android, viene rilasciato il Software Development Kit, un insieme di strumenti necessari per lo sviluppo delle applicazioni. La mossa di Google potrebbe sembrare azzardata, perché vengono investite grandi risorse su Android senza che ci sia inizialmente un prodotto commerciale a sfruttarlo. Questa strategia si rivela però vincente in quanto al momento del lancio commerciale di Android 1.0 nel Settembre del 2008 con il primo dispositivo Android, l HTC Dream, si è già formata un ampia e attiva comunità di sviluppatori pronti ad offrire le loro applicazioni sull Android Market. Da questo momento si susseguono una serie di versioni a distanza di pochi mesi l una dall altra, 4

Android 1.1 (Febbraio 2009), Android 1.5 Cupcake (Aprile 2009), Android 1.6 Donut (Settembre 2009), Android 2.0 Éclair (Ottobre 2009), Android 2.2 Froyo (Maggio 2010), Android 2.3 Gingerbread (Dicembre 2010), tutte basate su linux kernel 2.6. Vengono introdotte sempre nuove funzionalità e miglioramenti a quelle esistenti, di particolare interesse per questo lavoro risultano le funzionalità di Voice Input e Text-to-Speech dalla versione 1.6 in avanti. Nel Febbraio 2011 esce Android 3.0 Honeycomb, versione dedicata esclusivamente ai tablet. Infine nell Ottobre 2011 viene rilasciata pubblicamente l ultima versione, Android 4.0 Ice Cream Sandwich, basata su kernel Linux 3.0. Per dare un idea delle dimensioni raggiunte, nell Ottobre del 2011 erano presenti più di 500,000 applicazioni disponibili per Android con un numero stimato di download totali superiore ai 10 miliardi dall Android Market. Già dalla fine del 2010 Android è diventata la piattaforma più usata per gli smartphones, nel primo quadrimestre del 2012 ha una quota di mercato del 59% con una base di 331 milioni di dispositivi. 1.2. Struttura del sistema Android è composto da un kernel basato su Linux, al quale sono aggiunti i driver per il controllo dell hardware come lo schermo, la tastiera, la fotocamera. 5

Appena sopra il kernel troviamo una serie di librerie di base, tutte open-source, che offrono funzionalità importanti per il sistema, per citarne alcune OpenGL per la grafica, SQLite che permette di avere database relazionali basati su SQL, con un motore estremamente leggero. Abbiamo poi un blocco fondamentale, Android Runtime, che costituisce l ambiente di esecuzione di tutte le applicazioni sviluppate per Android. Qui sono presenti una macchina virtuale, la Dalvik Virtual Machine, e un insieme di librerie Java, che derivano in gran parte dalla Standard Edition, ma senza contenerla totalmente, e in parte sono specifiche per la piattaforma Android, infatti il prefisso del nome di molti package è android. Anche la Dalvik si differenzia da una Java Virtual Machine tradizionale, in quanto non esegue Java bytecode, ma uno speciale formato.dex (Dalvik Executable), che generalmente è tradotto dal Java bytecode. Questa macchina virtuale inoltre è stata creata in modo specifico per Android e quindi ottimizzata per i dispositivi che costituiscono il target di questo sistema. Il penultimo strato è composto da una serie di servizi di cui fanno uso direttamente o indirettamente le applicazioni e che sono indispensabili per il loro funzionamento. Tra gli altri citiamo il Location Manager e il Resource Manager, che servono rispettivamente a fornire la posizione del dispositivo e a richiamare risorse esterne necessarie all applicazione. Da ultimo, al livello più alto, troviamo le applicazioni, alcune delle quali standard e pre-installate come il browser e l app telefono, ma anche tutte quelle scaricate e aggiunte dall utente. Di default ogni applicazione Android viene fatta girare su un proprio processo Linux con una propria virtual machine. Il sistema avvia il processo ogni qual volta c è bisogno di eseguire un componente (ad esempio se un altra app chiede una funzione eseguibile da un componente della prima, come nel caso in cui abbiamo bisogno di scattare una foto o, come nel nostro progetto, di eseguire un riconoscimento vocale). 1.3. Activity I componenti più presenti nelle applicazioni sono senza dubbio le Activity. Una Activity potrebbe essere identificata come una singola azione che l utente vuole compiere, ma, a livello più pratico, è un compente dell applicazione che fornisce all utente una schermata con cui interagire per fare qualcosa. Ciascuna Activity ha una finestra su cui viene disegnata l interfaccia, solitamente è a tutto schermo, ma può anche essere più piccola e trovarsi sopra ad altre finestre. Generalmente un applicazione Android è composta da più Activity, una delle quali è definita come main ed è quella mostrata all utente all avvio dell app, ma questa non è l unico punto di ingresso, infatti una seconda applicazione può lanciare direttamente una delle altre Activity. 6

Ogni volta che viene creata una nuova Activity questa viene messa in primo piano e ottiene il focus (ad essa viene indirizzato l input dell utente), mentre la precedente viene messa in una pila, che prende il nome di Back Stack, gestita con disciplina Last-In-First-Out. L operazione di impilare un nuovo elemento è fatta al lancio di una nuova Activity, mentre un elemento viene rimosso dalla cima quando termina il compito per cui era stato lanciato o quando l utente preme il tasto back per tornare all Activity precedente. Come si può intuire da quanto appena detto, ogni Activity ha un suo ciclo di vita caratterizzato da una serie di transizioni di stato, che possono essere causate dall utente, ma anche dal sistema se ad esempio ha bisogno di liberare memoria. Vediamo un altro diagramma che mostra molto bene questi passaggi. Al lancio l Activity transita per tre differenti stati, creazione, avvio e ripristino, prima di iniziare la vera e propria esecuzione. Questi eventi possono essere intercettati con gli appositi metodi che appaiono nella figura. Quando una nuova Activity passa in primo piano, quella corrente viene messa in pausa, se, ad esempio, arriva una telefonata mentre stiamo usando il browser. In questo caso è possibile riprendere rapidamente l attività precedente. Se invece l utente passa ad una nuova attività che rende la precedente non più visibile, dopo essere 7

messa in pausa viene anche sospesa. Anche qui è possibile un ritorno abbastanza rapido, sempre che l attività non sia stata distrutta. Infatti in caso di mancanza di memoria, il sistema può distruggere le attività sospese e in pausa, salvandone però lo stato, in modo da poterle ricreare con i dati presenti alla chiusura quando l utente vuole ritornare ad esse. Abbiamo precedentemente detto che possiamo lanciare nuove attività da quella attualmente in esecuzione, questo viene fatto tramite il metodo startactivity() che è fornito dalla classe Activity. L argomento principale che dobbiamo passare per lanciare una nuova attività è un oggetto di tipo Intent, letteralmente intenzione, che individua quale Activity vogliamo mandare in esecuzione. Questo oggetto Intent può individuare una specifica Activity se lo creiamo riferendoci direttamente alla classe (Intent esplicito), oppure possiamo soltanto indicare l azione che vogliamo eseguire, ad esempio Intent.ACTION_SEND per l invio di una mail (Intent implicito). Nell oggetto Intent, inoltre, possono essere aggiunte opzioni aggiuntive, flag per specificare in che modo deve essere avviata la nuova attività e i dati su cui deve lavorare. Si tratta dunque di un oggetto potenzialmente molto complesso. In alcuni casi è necessario ottenere un risultato dall attività lanciata, per questo esiste il metodo startactivityforresult() analogo al precedente che prende come argomento aggiuntivo un codice per identificare l Activity al momento di ricevere i risultati. La ricezione si ottiene implementando il metodo onactivityresult(), che ha come parametri il codice di riconoscimento usato al momento del lancio, un codice per indicare come si è conclusa l attività e, da ultimo, il risultato, che viene passato sotto forma di Intent. 1.4. Sviluppare per Android Per sviluppare applicazioni in grado di girare su sistemi Android, è necessario installare un apposito kit di sviluppo, il già citato Android SDK, completo di librerie, emulatore e documentazione. È fornito gratuitamente nel sito dedicato agli sviluppatori android e per essere funzionante, visto che le applicazioni android sono scritte in Java, richiede la presenza del kit di sviluppo Java (JDK). Questa è la base, tuttavia, per uno sviluppo efficiente, non si può fare a meno di utilizzare un ambiente di sviluppo integrato. La scelta in questo caso è quasi obbligata, perché Android ha deciso di supportare ufficialmente Eclipse, un IDE conosciuto e ampiamento usato, totalmente gratuito e open-source. Nello stesso sito in cui si trova l SDK è disponibile per il download il plug-in Android Development Tools for Eclipse (ADT) che ci permette di creare applicazioni in modo molto naturale, quasi come fossero normali programmi Java. 8

Direttamente dall IDE possiamo avviare l AVD Manager, lo strumento che ci permette di gestire i nostri Android Virtual Device. Questi sono a tutti gli effetti delle macchine virtuali android, è possibile, in fase di creazione, impostarne le proprietà, come dimensioni e tipo di schermo, caratteristiche hardware e versione del sistema operativo. Questo si rivela molto utile per testare il comportamento delle applicazioni sulle diverse versioni di android. Una volta impostata, è possibile avviare la macchina emulata, ottenendo una finestra simile a quanto si vede nell immagine sottostante. Questa ci permette di interagire con il device virtuale, anche se ovviamente ci sono delle limitazioni, trattandosi di un emulatore. Quando vogliamo provare un applicazione l IDE Eclipse provvederà a richiamare il tool apposito dell SDK Android per installarla nel dispositivo emulato e avviarla in automatico. Per quanto riguarda lo sviluppo vero e proprio, la stesura del codice non è differente dallo scrivere un applicazione con interfaccia grafica in Java, una volta che abbiamo creato e definito i componenti grafici si scrivono le funzione per gestire gli eventi di interazione con l utente, come il click su un bottone, il cambiamento del contenuto di una casella di testo. Essendo Java non si può fare a meno di programmare secondo i principi della Programmazione ad Oggetti, la cui trattazione esula gli scopi di questo elaborato, in ogni caso Eclipse è un buon IDE che aiuta notevolmente nella scrittura del codice. Nella parte finale di questo capitolo, vogliamo parlare degli elementi più caratteristici dei progetti 9

delle applicazioni android, in particolare la gestione dell interfaccia grafica e delle risorse esterne. I componenti grafici sono per lo più quelli tradizionali che siamo abituati a vedere in quasi tutti i programmi, cioè pulsanti, checkbox, caselle di testo editabili, etichette. In Android sono divisi in due grandi tipologie, i ViewGroup, che hanno la funzione di contenitori, e le View che sono i veri e propri elementi grafici.. Il layout grafico delle activity viene definito in un file XML all interno della cartella res/layout. Questo particolare è molto importante, in quanto la gestione dei file aggiuntivi delle nostro progetto deve seguire una specifica organizzazione, ogni elemento trova il suo posto, ad esempio le immagini devono essere inserite nelle cartelle res/drawable. Come si può vedere dalla figura precendente è possibile creare graficamente l interfaccia. Questo funzione è fornita dal plug-in ADT per Eclipse che comprende un editor grafico per i file.xml principali. Possiamo trascinare, aggiungere e modificare gli elementi e verrà automaticamente generato il codice xml corrispondente. Oltre al layout, troviamo il file AndroidManifest.xml, che descrive le caratteristiche principali della nostra applicazione, e nella cartella res/values il file strings.xml dove possono essere inseriti i valori delle stringhe da usare nel nostro programma. Anche questi file possono essere modificati con l editor grafico. Ad ognuno di questi elementi, valori delle stringhe, componenti grafici, possiamo associare un 10

identificativo. Questo ci permette di ritrovarli all interno del codice del programma, grazie ad una speciale classe R che ci consente di ottenere l ID dell oggetto desiderato passando dall ID che abbiamo assegnato all elemento nel file xml corrispondente. A questo punto tramite degli appositi metodi possiamo ottenere un riferimento all oggetto passando come argomento l ID, per fare un esempio findviewbyid(r.id.salva) può essere utilizzato per trovare un ipotetico pulsante per il salvataggio. Le applicazioni Android sono distribuite sotto forma di file APK (Android Package). Al loro interno vengono raccolti gli eseguibili in formato DEX, le eventuali risorse associate e una serie di descrittori, tra cui il manifest. Infine le app sviluppate possono essere inserite sull Android Market, ora Google Play, e rese disponibili agli utenti finali per l acquisto e il download. 11

2. Riconosimento Vocale 2.1. Panoramica Un sistema di riconoscimento vocale ha come obiettivo quello di associare ad un input audio (un parlato) una stringa di caratteri, o meglio una sequenza coerente di parole. L ambito di lavoro di questa tecnologia è piuttosto complesso, infatti generalmente ci si trova ad operare in un ambiente rumoroso che non consente di avere una buona qualità del segnale in ingresso. Inoltre, per sua stessa natura, il parlato varia con il genere, l età, la provenienza geografica dell interlocutore e anche con il suo stato emotivo. Nonostante queste difficoltà, l interazione vocale è uno dei modi più naturali per comunicare e la possibilità di avere a disposizione un sistema affidabile di riconoscimento ha molte applicazioni di notevole interesse, dai sistemi automatici per la dettatura, ai servizi di assistenza via telefono, fino ad applicazioni di tipo command & control per comandare dispositivi elettromeccanici e sistemi intelligenti. Le ricerche su questo argomento iniziano già negli anni 50, inizialmente con lo scopo di effettuare un riconoscimento all interno di un set molto limitato di vocaboli. Nel 1952 dai laboratori Bell viene sviluppato il primo sistema in grado di riconoscere le cifre da 0 a 9 dettate al telefono con una percentuale di successo del 98%. Importanti sviluppi nascono dal programma Speech Understanding Research presso la Carnegie Mellon University a partire dagli anni 70, ma la potenza di calcolo richiesta per l epoca è enorme. Con il passare gli anni le capacità dei calcolatori sono aumentate esponenzialmente, rimangono tuttavia alcuni notevoli problemi: L ampiezza del vocabolario; idealmente per poter riconoscere un parlato naturale serve un vocabolario estremamente ampio, ma con l aumentare delle dimensione diminuiscono le prestazioni del sistema, sia in termini di efficienza computazionale che di percentuale di errore. In questo senso non aiuta la presenza di parole con pronunce molto simili che aumenta la difficoltà del riconoscimento. Indipendenza dal soggetto parlante; i modelli utilizzati attualmente si basano tutti su una fase di training per poter effettuare con successo il riconoscimento. Può essere fatta sull utente finale per poter avere migliori risultati, però questa strategia non si rivela adatta a sistemi utilizzati da molti utenti diversi per brevi periodi di tempo, nel qual caso il training è 12

effettuato in fase di sviluppo e su un campione eterogeneo, garantendo tuttavia risultati peggiori. Parlato continuo; molti dei sistemi presenti, per avere buoni risultati richiedono di scandire e separare le parole, limitando in questo modo le alterazioni della pronuncia che si generano tra parole vicine e identificare più facilmente dove iniziano e finiscono. Questo ovviamente non permette all utente di avere un dialogo naturale. 2.2. Principi di funzionamento Il primo passo del riconoscimento consiste nell analizzare il segnale del parlato, campionandolo ad una determinata frequenza generalmente 16KHz o 8KHz e quantizzando l insieme dei valori che assume per poterlo rappresentare con un numero finito di bit. A questo punto il segnale viene ulteriormente processato con tecniche quali la trasformata di Fourier (nella versione Fast Fourier Transformation), o l analisi cepstrale, un applicazione della TdF che passa attraverso il logaritmo dello spettro di potenza, per poterlo comprimere e evidenziare le componenti più importanti. Il risultato è una sequenza di finestre temporali ad ognuna delle quali è associata una serie di coefficienti che rappresentano il parlato originale. Questo è l input per l analisi acustica, un processo che rientra nella categoria dei metodi di Pattern Recognition e che può essere effettuata basandosi su diversi modelli. L approccio più semplice si basa su un confronto diretto con una serie di schemi conosciuti scegliendo come risultato l elemento più simile. Questa tecnica presenta notevoli svantaggi perché non può modellare variazioni, ad esempio nella pronuncia di una parola, se non prevedendo più elementi per ognuna, ed è in pratica utile solo per modelli di confronto sull intera parola e in sistemi di dimensioni ridotte. Una tecnica più flessibile consiste nel modellare una parola come una sequenza di stati e ad ognuno di essi assegnare una distribuzione di probabilità che rappresenta i suoni che è possibile udire in quel segmento della parola. La lunghezza di questo segmento può essere un fonema, l unità fondamentale del parlato, ma anche un difono o un trifono. Questo modello necessità di una fase di training per stimare i parametri inserite nelle funzioni di probabilità. La tecnica più flessibile e tradizionalmente usata con successo è quella basata su degli Hidden Markov Model (Modello Markoviano Nascosto). Un HMM è un insieme di stati collegati da archi di transizione, ad ognuno dei quali è associata la probabilità di transizione, con uno degli stati definito come iniziale. 13

Ogni stato inoltre si caratterizza da una serie di output che può produrre, ciascuno con una determinata probabilità (posto che la somma di queste debba essere 1, cioè l evento unione è l evento certo, come anche per gli archi di transizione in uscita da un determinato stato). In generale le probabilità sugli archi di transizione e degli output può essere nota, ciononostante il modello viene definito come nascosto perché non è possibile osservare la sequenza degli stati, ma soltanto la sequenza degli output. Pur con delle semplificazioni questa tecnica fornisce una buona modellazione del fenomeno del parlato ed ha il vantaggio che può essere applicata gerarchicamente a più livelli, fonema, parola o frase. È da notare che in questo caso le transizioni sono vincoli temporali e le uniche permesse sono il ritorno sullo stato attuale, che indica un protrarsi nel tempo, e il passaggio allo stato successivo. Nell ambito dell Automatic Speech Recognition, questo modello va allenato con un processo di tentativi e feedback per migliorare le stime delle probabilità che non sono conosciute a priori. A seconda del modello scelto, abbiamo a disposizione diversi algoritmi, tra cui il Dynamic Time Warping e l algoritmo di Viterbi, che ci permettono di ottenere il risultato finale, cioè una sequenza di parole con un indice di confidenza, anche se spesso si preferisce fornire più risultati alternativi in una lista ordinata in base all accuratezza. Allo stato dell arte le ultime tecniche sviluppate fanno uso di reti neurali, anche affiancate ai modelli stocastici descritti precedentemente, che offrono come vantaggi una maggiore robustezza e flessibilità, nonché un parallelismo naturale che le rende compatibili a sistemi di calcolo fortemente paralleli. 14

2.3. Sviluppi recenti Un nuovo impulso nell ambito della ricerca sul riconoscimento vocale è venuto negli ultimi anni da Google. Il colosso dell informatica ha mosso i primi passi rendendo disponibile l applicazione Google Voice Search per i cellulari Android. Questa app fornisce all utente la possibilità di effettuare una ricerca sul web pronunciando a voce le parole chiave. Per quanto possa risultare non entusiasmante di per sé, la tecnologia sviluppata per questa prima funzione ha trovato un numero crescente di applicazioni. Dalla versione 2.2 di Android è iniziato il supporto alle Voice Actions, con la possibilità di effettuare una chiamata o mandare una e-mail totalmente con la voce; inoltre, in fase sperimentale, è possibile la generazione automatica dei sottotitoli per i video di Youtube (anche se, onestamente, per ora questa beta feature non mostra buoni risultati). In ogni caso è notevole l interesse e lo sforzo di Google per migliorare questa tecnologia ed integrarla in un numero crescente di servizi, dalle parole dello stesso Mike Cohen, a capo della sezione che sviluppa il sistema, l obiettivo a lungo termine è di renderla totalmente onnipresente. Qualunque sia l applicazione, qualunque sia quello che stai cercando di fare con il tuo telefono, vogliamo che tu sia in grado di parlarci. La chiave del funzionamento del sistema di Google, al di là dei modelli e degli algoritmi, risiede nell avere a disposizione enormi centri di calcolo con immense quantità di dati immagazzinate, in grado di fornire materiale per il training e tempi di risposta decisamente rapidi. Il riconoscimento vocale di Google, infatti, avviene nel cloud, cioè l utente registra il parlato e lo invia agli appositi server di Google, che si occupano di elaborare e soddisfare la richiesta restituendo poi i risultati come una lista di frasi possibili abbinate ognuna ad un indice di confidenza. Nell ultimissima versione annunciata di Android, la 4.0, è stata ulteriormente aggiornata la tecnologia del riconoscimento, offrendo all utilizzatore un microfono sempre aperto per un riconoscimento del parlato in streaming. Al di là delle modalità di funzionamento e dell efficacia di questa nuova introduzione, che sono ancora da verificare al momento della stesura di questo elaborato, una cosa è certa: Google sta lavorando molto su questa tecnologia e sicuramente non mancheranno novità interessanti nei prossimi anni. 15

3. Lo Standard VoiceXML 3.1. Origine VoiceXML è uno standard basato su XML, sviluppato per creare dialoghi che prevedono sintesi vocale, riconoscimento vocale e di input telefonici, registrazione di parlato e conversazioni ad iniziativa mista. Le origine del VoiceXML risalgono al 1995, anno in cui una divisione di ricerca dell azienda americana AT&T inizia presso i suoi laboratori lo sviluppo di un progetto chiamato Phone Markup Language. Nel frattempo anche Lucent e Motorola sviluppano i propri linguaggi per applicazioni vocali e, in seguito, si aggiungono ulteriori compagnie ognuna intenta a sviluppare un proprio linguaggio. Nel 1998 il World Wide Web Consortium (W3C) organizza una conferenza sui browser vocali, a cui partecipano le aziende già citate, nonché compagnie del calibro di IBM e HP. A seguito di questo incontro viene costituito un forum, comprendente le aziende interessate, per raggruppare gli sforzi di ricerca, con lo scopo di definire un linguaggio standard per creare dialoghi che gli sviluppatori potessero usare per costruire le loro applicazioni vocali. Come base di partenza viene scelto l XML (extensible Markup Language) una tecnologia dalla grande flessibilità che si affermava sempre più in numerosi campi differenti. Nel 2000 viene annunciato al pubblico la prima versione, VoiceXML 1.0, e a breve distanza viene esposto al W3C per essere la base di partenza di un nuovo standard internazionale. Da questo momento i gruppi di lavoro del W3C, grazie al feedback pubblico e delle aziende partecipanti, proseguono l evoluzione di questo linguaggio, arrivando a rilasciare nel 2000 la nuova versione, VoiceXML 2.0, che introduce novità essenziali. Seguono poi rispettivamente nei mesi di Giugno del 2007 e del 2009, le versioni 2.1 e 3.0 che mantengono la retrocompatibilità, aggiungendo nuove estensioni. 16

3.2. Tag In un file VoiceXML il primo tag che incontriamo e che si chiude soltanto alla fine del documento è <vxml>. La sua funzione è proprio quella di caratterizzare il nostro file come un VoiceXML e non un XML generico. Gli attributi principali e immancabili sono la versione dello standard che stiamo utilizzando, il namespace con il suo nome e l indicazione della locazione a cui si trova lo schema delle linguaggio. Questi attributi sono importanti per andare a verificare se il file è scritto correttamente e permettono per esempio ad un generico parser XML di lavorare su questo documento che contiene dei propri tag particolari. All interno di questo primo tag trovano posto tutti gli altri, innanzitutto quelli relativi ai dialoghi. Lo standard VoiceXML ne prevede essenzialmente due tipi, <form> e <menu>, entrambi caratterizzati da un attributo identificativo id che serve a riferirsi allo specifico dialogo in ogni parte del documento. Un dialogo di tipo form prevede l interazione con l utente che deve fornire informazioni per riempire un certo numero di campi, può essere utilizzato, ad esempio, per effettuare una prenotazione o inoltrare una richiesta. All inizio della conversazione, generalmente, si vuole dare un benvenuto e una piccola introduzione all utente, questo viene fatto tramite il tag <prompt> che è utilizzato ogni qual volta l applicazione deve generare un output sonoro, sia esso un suono registrato o una frase per il sintetizzatore vocale. L altro tag fondamentale che troviamo all interno del form è <field> che serve proprio a rappresentare i campi di si parlava precedentemente. Ognuno di essi ha un attributo per indicarne il nome e all interno un ulteriore tag <prompt> che viene riprodotto quando l applicazione chiede all utente di riempire quello specifico campo. Un altro importante elemento che troviamo principalmente nei form è costituito dalle grammatiche. Queste sono realizzate attraverso il tag <grammar> e possono essere inserite al livello del dialogo per avere validità per tutta la sua durata o a livello del singolo campo. La loro funzione è quella di specificare che tipo di input ci aspettiamo dall utente, ad esempio un numero per un ipotetico campo età. Le grammatiche a livello di dialogo sono più complesse in quando servono ad intercettare l evento in cui l interlocutore esprime una frase in grado di riempire più campi contemporaneamente, del tipo Voglio ordinare una pizza margherita per le 8. Lo standard VoiceXML supporta delle grammatiche predefinite, come per i numeri, le date, i valori booleani, ma è possibile crearne di personalizzate nella forma Speech Recognition Grammar Specification [SRGS], sempre proposta dal W3C, addirittura mettendo la definizione in un file separato e indicandone la locazione all interno del tag <grammar>. 17

L algoritmo che si occupa di interpretare il dialogo (Form Interpretation Algorithm) scorre ogni volta gli elementi del form eseguendo il primo che non è stato marcato come completato. I campi vengono contrassegnati come completati quando l utente fornisce un input valido che rispetti le grammatiche attive. Al termine del dialogo trovano posto dei tag del tipo <submit> e <goto> che servono a direzionare l applicazione alla riproduzione di un nuovo dialogo, il primo dei due invia anche i dati immessi nei campi del form, e <exit> per uscire dall applicazione e ritornare il controllo all interprete. Un dialogo di tipo menu, invece, ha la funzione di offrire all utente delle scelte per decidere in che direzione far andare la conversazione. Una speciale forma di menu è quello DTMF in cui la scelta viene effettuata premendo uno dei tasti del telefono. Anche nel menu si trova generalmente un <prompt> iniziale che si caratterizza per la possibilità di inserire al suo interno un tag <enumerate> che serve ad elencare le scelte disponibili. Ognuna di queste è rappresentata da un tag <choice> il cui contenuto è di default utilizzato nell elencazione generata dal tag <enumerate> e anche dall interprete del dialogo per confrontare l input dell utente e individuare la scelta effettuata. Ad ogni scelta è associato anche un attributo next che serve per indicare il dialogo da riprodurre successivamente se l utente la seleziona. Esiste infine una serie di altri tag più avanzati, come <script>, <var>, <catch>, utilizzati rispettivamente per lanciare l esecuzione di uno script, creare una variabile a cui è possibile riferirsi all interno del dialogo, intercettare eventi, cioè particolari condizioni nella riproduzione del dialogo, come la mancanza di input, o frasi pronunciate dall utente, come una richiesta di aiuto. La lista completa dei tag ovviamente non si esaurisce qui e ognuno di essi possiede attributi aggiuntivi che possono modificare il funzionamento standard. Quanto qui esposto è comunque volto a fornire una comprensione di base del VoiceXML che è sufficiente per il progetto su cui si basa questo elaborato. In ogni caso la specifica completa può essere consultata all indirizzo ufficiale del W3C per questo standard che è http://www.w3.org/tr/voicexml20/, grazie alla quale sono stati sviluppati i contenuti di questa sezione. 18

3.3. Considerazioni su VoiceXML In questa ultima sezione vogliamo sviluppare alcune considerazioni su VoiceXML, in particolare sul target per cui nasce e la sua conseguente architettura, e illustrare i vantaggi offerti che ci hanno portato a scegliere di inserirlo nel nostro progetto. L architettura di riferimento è mostrata nella figura sottostante. Il Document Server si occupa di fornire i dialoghi all interprete che esegue il suo lavoro all interno di un contesto. L interprete e il suo Context comunicano direttamente con la Implementation Platform che ha il compito di gestire l interazione con l utente. Va ricordato che questo linguaggio nasce inizialmente per sviluppare applicazioni vocali a cui si accede via telefono e, con la seguente cura da parte del W3C, si apre a portali vocali con l aiuto della tecnologia VoIP (Voice over Internet Protocol). Le richieste e l invio dei dati delle form, secondo la specifica del W3C, dovrebbero avvenire attraverso metodi http. Fondamentalmente il modello di interazione è di tipo client-server, in cui gli utilizzatori delle applicazioni vocali si collegano al fornitore di servizi attraverso il telefono o programmi specifici di tipo Voice Browser. In alcuni casi l interprete si trova sul lato server, per ovvi motivi nel caso di accesso da telefono, ma anche per ridurre lo sforzo computazionale a carico dei client nelle altre situazioni. Vediamo infine i principali vantaggi dell utilizzo di VoiceXML: Facilità di scrittura e lettura dei dialoghi essendo un derivato del linguaggio XML Possibilità di creazione grafica con appositi tool Separazione della logica del dialogo dal codice dell applicazione, questo permette una più facile manutenzione e possibilità di cambiare i dialoghi senza riscrivere tutto il codice 19

4. L interprete VoiceXML 4.1. Interpreti gratuiti e open-source Per poter utilizzare il linguaggio VoiceXML serve uno specifico programma interprete in grado di analizzare il documento, comprenderne gli elementi e gestire il flusso del dialogo, oltre che relazionarsi con la Implementation Platform per l input e l output vocale. Software di questo tipo sono stati sviluppati da diverse aziende che forniscono la possibilità di acquistare la licenza d uso o di usufruire dei servizi direttamente dai loro server, previo un contratto che prevede un compenso in base al numero utenti serviti. Nel nostro progetto, che ha lo scopo di esplorare le potenzialità dell interazione vocale su smartphone, queste soluzioni ci sono apparse sconvenienti, nonostante alcune di esse offrano brevi periodi di prova gratuiti. Quello che ci è sembrato ideale per la nostra applicazione è un interprete gratuito, che si possa integrare bene con un programma Java, possibilmente open-source per poterne comprendere meglio il funzionamento, effettuare più facilmente eventuali modifiche per il porting su Android e realizzare il collegamento con il riconoscimento vocale e il sintetizzatore forniti dal sistema. Con una breve ricerca è stato possibile trovare un progetto che corrispondeva esattamente a tutte queste caratteristiche, un interprete open-source totalmente scritto in Java: JVoiceXML. Questo progetto è stato avviato da Dirk Schnelle-Walka nel 2005 durante il suo dottorato presso la Technical University di Darmstadt (Germania), il cui obiettivo era di utilizzare interfacce vocali, tra cui VoiceXML, in ambienti intelligenti ; la necessità di realizzare un interprete nasceva dal fatto che i sistemi commerciali disponibili al momento erano troppo costosi per un istituto di ricerca e quelli gratuiti supportavano solo l accesso via telefono. Negli anni successivi nuovi membri si sono aggiunti al progetto, occupandosi, per interesse o per scopi accademici, quali tesi di laurea o master, delle differenti sezioni, dal processore per le grammatiche alle librerie per i tag VoiceXML. JVoiceXML è rilasciato sotto la licenza GNU Library General Public License, è attivo e in sviluppo al momento della stesura di questo elaborato e le persone che se ne occupano cercano di renderlo sempre più conforme alle specifiche del W3C. Purtroppo il suo utilizzo nella nostra applicazione non si è rivelato semplice come inizialmente sperato. 20

Una volta acquisite le informazioni sul progetto abbiamo deciso di effettuare dei test su i nostri pc prima di tentare di portarlo su Android. Qui sono iniziati i problemi perché si tratta di un progetto piuttosto vasto e complesso che richiede precise configurazioni. I tentativi effettuati, in parallelo su due macchine diverse una Windows e una Linux, hanno compreso diverse installazioni con più o meno implementazioni aggiuntive per la sintesi e il riconoscimento, la modifica delle variabili d ambiente del sistema, dei file di configurazione nelle cartelle del progetto, il debug passo passo cercando di interpretare le eccezioni riportate sulla console al lancio. Dopo più di una settimana di prove siamo giunti a delle considerazioni che ci hanno portato a desistere: L architettura di JVoiceXML prevede che l interprete venga lanciato come un servizio e che le applicazioni, che ne hanno bisogno e girano su altre JVM, accedano in remoto grazie alla Java Naming and Directory Interface e al protocollo di Remote Method Invocation. Questo modello si rivela un po troppo elaborato per il nostro progetto che è idealmente costituito da un unica applicazione che ingloba al suo interno un modulo per l interprete. Potrebbe inoltre sorgere un ulteriore problema poiché le librerie per queste tecniche di accesso sono piuttosto avanzate e non è detto che siano supportate dalla piattaforma Java presente su Android che ricordiamo essere diversa dalla Java SE. Proprio durante lo svolgimento del tirocinio siamo venuti a conoscenza della nascita di un progetto di porting su Android a cura dello stesso team che si occupa dell originale; ci è sembrato più opportuno evitare di investire ulteriori risorse nel cercare di effettuare un nostro porting, attendendo che il lavoro degli sviluppatori arrivi ad uno stadio maturo per poterlo integrare nella nostra applicazione. 21

Il porting in questione ha pochi mesi di vita ed è consultabile all indirizzo http://jvoicexml.svn.sourceforge.net/viewvc/jvoicexml/core/branches/android/ Dopo aver ricercato altre soluzioni adatte al nostro caso, senza successo, volevamo comunque arrivare a produrre un applicazione capace di dialogo senza rinunciare al VoiceXML. Per questo abbiamo deciso di realizzare un nostro semplice interprete. 4.2. Il parsing Il primo passo per lavorare con un file xml è quello di effettuarne il parsing. Questa operazione consiste nell analizzare il file, che è di base una sequenza di caratteri, e individuare gli elementi (tag), i loro attributi e la struttura gerarchica in cui sono ordinati. Il risultato di questa analisi è diverso a seconda dell approccio che decidiamo di utilizzare e ne esistono fondamentalmente due tipologie, SAX e DOM. Un parser SAX (Simple Api for Xml) è di tipo event-driven: ogni qual volta incontra un tag genera un evento che deve essere intercettato; è presente un gestore di default (default-handler) che può essere esteso (e generalmente questo è indispensabile) per effettuare azioni specifiche a seconda del tag incontrato. Questo tipo di approccio è piuttosto difficile da gestire perché bisogna sostanzialmente implementare un metodo per ogni differente azione che vogliamo eseguire e ognuno di questi gestori di eventi va registrato nel parser. Il vantaggio è dato dalla velocità e poca memoria richiesta, ma non è possibile lavorare sul documento in toto, è possibile farlo solo sequenzialmente tag per tag. L altro modello a disposizione è DOM (Document Object Model), una specifica del W3C ormai consolidata al punto che il gruppo di lavoro relativo è stato chiuso nel 2004. DOM è un interfaccia indipendente dalla piattaforma e dal linguaggio per permettere a programmi e script di accedere e modificare contenuto, struttura e stile dei documenti, nel nostro caso file xml. Sostanzialmente il documento viene rappresentato come un albero che rispecchia la struttura gerarchica del file ed è possibile accedere ad ognuno dei nodi, modificarlo, cancellarlo o crearne uno nuovo. Questa tecnica permette di lavorare più facilmente con il file xml perché abbiamo una sua rappresentazione completa accessibile in ogni parte, con un prezzo da pagare in una velocità di parsing inferiore e una maggiore occupazione di memoria. Vista la maggiore vicinanza con lo stile di programmazione Java che è ad oggetti abbiamo deciso di adottare questo secondo modello, considerando che nelle librerie standard di Java è incluso il parser 22

Xerces di Apache, che è in grado sia di generare eventi SAX sia di produrre un albero DOM, e i package org.xml.sax e org.w3c.dom per utilizzare entrambi gli approcci. Lavorando con questo modello ci siamo resi conto di alcune limitazioni dovute alla neutralità rispetto al linguaggio di questa specifica, che può essere implementata anche in linguaggi non ad oggetti; per citarne alcune la possibilità di effettuare ricerche selettive solo dal nodo radice, la presenza di tantissimi nodi vuoti che si incontrano navigando l albero, il testo compreso in un tag non memorizzato all interno del nodo che rappresenta l elemento ma in un nodo figlio a parte. Il risultato è che gli algoritmi scritti per navigare l albero ed estrarre le informazioni desiderate risultano più complessi e contorti di quando sarebbe necessario con una struttura più pulita e che sfrutti appieno le potenzialità di Java. Fortunatamente non siamo i soli ad aver fatto queste considerazioni, infatti da esse ed altre sull implementazione Java di DOM, è nato nel 2000 il progetto JDOM, che è disponibile con una licenza open-source in stile Apache e consiste in una libreria specifica per Java per operare con file xml. Il progetto non costituisce un implementazione di DOM, anche se si può interfacciare sia con oggetti di quel tipo che con sequenze di eventi SAX, ma piuttosto un alternativa che va incontro alle aspettative e al modo di pensare dei programmatori Java, offrendo loro numerose funzioni utili, oggetti che fanno uso della classi standard Java per le collezioni e risulta alla fine molto più comoda. Per questi motivi abbiamo deciso di utilizzarla nel nostro interprete e ne abbiamo tratto notevoli vantaggi in fase di sviluppo. Una volta creato l oggetto JDOM che rappresenta il file xml, l interprete, tramite apposite funzioni, che estrapolano le informazioni contenute nei vari nodi, genera ulteriori oggetti java con i quali effettua poi la riproduzione dei dialoghi. Struttura e funzionamento dell interprete sono descritti nel capitolo successivo, mentre nell appendice A trova posto il codice dell interprete che contiene anche le funzioni relative al parsing, tutte definite static; in particolare nella classe Vxml si trovano parsefile che è la funzione in cui viene creato il parser e sono effettuate le prime operazioni per ottenere un oggetto JDOM passando prima attaverso un oggetto DOM, parsedoc che viene richiamata dalla precedente per lavorare sull oggetto appena ottenuto, parseform e parsemenu che si occupano di generare gli oggetti che rappresentano i dialoghi delle due differenti tipologie. 23

4.3. VxmlInterpreter L obiettivo del nostro interprete è quello di riprodurre dialoghi semplici, senza funzioni avanzate. Per questo ci siamo limitati a supportare i tag principali (quelli in più eventualmente presenti non creano problemi venendo semplicemente ignorati), una struttura in cui i dialoghi sono tutti in uno stesso file xml, niente grammatiche perché sarebbe stato necessario un ulteriore modulo apposito per processarle. Il package realizzato è vxmlinterpreter, che contiene al suo interno diverse classi, per la cui comprensione può risultare utile consultare il diagramma delle classi presente nell appendice A. La classe principale è Vxml, che, oltre ad esporre le funzioni per il parsing come metodi statici, funge anche da contenitore per i dialoghi, che sono inseriti in una struttura HashMap con l id dei dialoghi a fare da chiave. Un istanza di questa classe rappresenta a tutti gli effetti l interprete, espone infatti la funzione playdialog() che avvia la riproduzione del primo dialogo trovato nel file xml e una sua versione in overload che accetta come argomento l id del dialogo da cui iniziare. Come si può vedere dall architettura del VoiceXML discussa nel capitolo 3, l interprete non interagisce direttamente con l utente, ma lo fa comunicando con la Implementation Platform. Nella nostra implementazione questo modello è realizzato utilizzando l interfaccia SpeechPlatform, che prevede sostanzialmente tre metodi da implementare, uno per riprodurre l output, uno per ottenere l input (in cui va eseguito anche l eventuale il riconoscimento vocale) e un ultimo per l invio dei dati ottenuti dai form. Nel package è presente la classe Utils che fornisce un implementazione banale di questa interfaccia, basata su I/O testuale da console, utilizzata nella fase di sviluppo dell interprete avvenuta separatamente dall applicazione Android. Un istanza di Utils è automaticamente assegnata al campo platform_ dell oggetto Vxml in fase di inizializzazione, ma è possibile specificare una piattaforma diversa con il metodo setplatform(speechplatform platform). Ulteriori elementi presenti in Vxml e alcune particolarità dei metodi, qui non descritti, derivano da un problema di sincronizzazione di cui si discute nel capitolo successivo. La rappresentazione dei dialoghi è basata sulla classe astratta Dialog, che espone il metodo astratto play(), richiamato dall oggetto Vxml nella funzione playdialog(). La gestione di come effettuare la riproduzione è quindi delegata dall interprete ai dialoghi, questo per poter differenziare la logica dei form da quella dei menu e perché in questo modo l accesso alle informazioni necessarie richiede meno passaggi. Questa soluzione pone tuttavia un problema nell effettuare operazioni di I/O che i dialoghi non possono svolgere autonomamente dovendo passare attraverso l oggetto Vxml, perciò ogni dialogo ha bisogno del riferimento all interprete, memorizzato nel campo voiceapplication_ e 24

impostabile con il metodo setinterpreter (Vxml interpreter). La funzione play() ha un valore di ritorno di tipo stringa che rappresenta l id del dialogo successivo da eseguire, in caso di stringa vuota (non un riferimento nullo, ma una stringa di zero caratteri) l esecuzione termina. La classe Dialog contiene anche il campo id e un valore di default da assegnare ad esso nel caso non sia specificato l attributo id del dialogo nel file xml. L implementazione del metodo play() è fornita dalle classi Menu e Form che ereditano da Dialog e segue le due logiche differenti di interazione spiegate nel capitolo 3, cioè una lista di elementi da riprodurre e contrassegnare come completati per il form e una scelta da individuare per direzionare al dialogo successivo nel caso di un menu. Gli elementi all interno dei dialoghi sono modellati dalla classe astratta Item che si specializza in Command, Prompt, Field, Choice. L attributo abstract assegnato in questo caso alla classe non è dovuto tanto a ragioni tecniche quali metodi non implementati, ma è motivata dalla non esistenza di oggetti Item non specializzati. Riguardo le classi figlie, Prompt, Field e Choice sono una rappresentazione abbastanza fedele, con qualche semplificazione, degli omonimi tag. Command raggruppa invece i vari <goto>, <submit>, <exit> che prevedono un passaggio da un dialogo ad un altro con eventuale invio dei dati. 25

5. Realizzazione dell applicazione 5.1. Il primo prototipo La prima fase del tirocinio su Android è stata dedicata all acquisire conoscenze sul sistema, su come si sviluppano applicazioni, facendo le prime prove che partono dal classico Hello World per prendere praticità con gli strumenti e l ambiente. Una volta apprese le basi ci siamo dedicati all obiettivo specifico del nostro progetto, cioè fare uso del riconoscimento vocale e del sintetizzatore. Il primo traguardo che abbiamo fissato è stato quello di realizzare un applicazione pappagallo con una semplicissima interfaccia, un bottone espanso a tutto schermo con un immagine di sfondo per renderlo più presentabile. Il funzionamento è il seguente: al click sul bottone (qualsiasi punto della schermata in pratica va bene) compare un breve messaggio di avviso, viene lanciato il riconoscimento, si prende come risultato la stringa con il punteggio di confidenza più alto e questa viene inviata al sintetizzatore per la riproduzione. Il passaggio più importante è di creare l Intent per l attività di riconoscimento, con l istruzione Intent intent = new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH), a cui vanno aggiunte ulteriori opzioni tramite il medoto intent.putextra( ). A questo punto si può lanciare l activity che effettua il riconoscimento nel modo già descritto nel capitolo 1, cioè con il metodo startactivityforresult(intent intent, Int codice_riconoscimento). Per quanto riguarda la ricezione dei risultati, nel metodo onactivityresult() è presente un istruzione del tipo mresult=data.getstringarraylistextra(recognizerintent.extra_results).get(0), che serve ad ottenere in primo luogo un ArrayList di String che rappresenta tutti i risultati e poi selezionarne il primo elemento. L interazione con il sintetizzatore si rivela lievemente più semplice, in quanto le librerie di Android già dalla versione utilizzata nel nostro progetto, contengono la classe TextToSpeech che permette di istanziare e inizializzare un sintetizzatore, nel nostro caso questo viene fatto all interno di oncreate(), e di inviare ad esso le stringhe da sintetizzare con il metodo speak(). Va rilevato che, nonostante le apparenze, anche la sintesi vocale viene effettuata al di fuori della nostra activity, è infatti possibile avviare il sintetizzatore in modo simile a quanto fatto per il riconoscimento ottenendo lo stesso effetto. La classe TextToSpeech serve quindi a mascherare il funzionamento interno e semplificarne l utilizzo per lo sviluppatore di applicazioni, in perfetta linea con i principi della programmazione ad oggetti. In versioni successive delle librerie è presente una 26

classe analoga per il riconoscimento, il cui utilizzo rimane comunque più complicato di quello del sintetizzatore, per cui abbiamo deciso di mantenere il codice originale. Anche in questa prima fase non sono mancati i problemi: in particolare sul sitema Android pulito del device virtuale non vi è installata di default un applicazione in grado di effettuare il riconoscimento, per cui è stato necessario reperire un file apk e procedere all installazione sul dispositivo emulato tramite il tool adb fornito con l sdk di Android. Nonostante questo, all avvio del riconoscimento si è presentato un problema audio, che dopo un alcune ricerche e tentativi di debugging, sembra dovuto all impossibilità da parte dell emulatore di interfacciarsi con successo al microfono del pc, per cui abbiamo dovuto rinunciare alla possibilità di effettuare il testing sull avd e provare installando l applicazione su un dispositivo reale. Questo è uno dei motivi per cui poi lo sviluppo dell interprete, discusso nel capitolo precedente, è avvenuto in un package separato ed indipendente, anche per una maggiore velocità nell effettuare i test e mantenere separati i blocchi funzionali. Il primo prototipo è stato comunque un successo che ci ha spinto a dedicarci alla gestione della logica dei dialoghi con VoiceXML, di cui si è parlato nei capitoli 3 e 4, e infine all integrare i vari moduli per realizzare il prodotto completo. 27

5.2. App finale L ultimo passo del progetto è stato di inserire l interprete VoiceXML da noi realizzato all interno dell activity. Per fare questo abbiamo importato il package vxmlinterpreter nel progetto Android e aggiunto la clausola per implementare l interfaccia SpeechPlatform nella nostra activity. Abbiamo quindi inserito il codice precedentemente sviluppato per il riconoscimento e la sintesi vocale all interno dei metodi input() e output() e implementato sendresults() per concatenare i risultati dei form in un unica stringa. Poiché l unica parte del codice in cui è possibile ricevere i risultati del riconoscimento è il metodo onactivityresult(), si è reso necessario limitare la funzione input() all effettuare solo una richiesta di riconoscimento e aggiungere un metodo setinput() all interprete per comunicare che il riconoscimento è avvenuto e inviarne il risultato. L interfaccia è stata aggiornata e prevede una casella di testo editabile, sei differenti bottoni per svolgere le seguenti funzioni: effettuare un riconoscimento, sintetizzare la stringa presente nella casella di testo, riprodurre tre differenti dialoghi d esempio salvati su differenti file xml, l ordinazione di una pizza, un sondaggio di sport ed un esempio di applicazione di supporto all anziano; l ultimo bottone serve ad aggiornare la casella di testo dopo la riproduzione di un dialogo, questo perché si è rivelato necessario eseguire l interprete come un thread separato e Android impedisce l aggiornamento dell interfaccia grafica da thread differenti da quello principale dell activity (UIThread). Esistono dei metodi per eseguire questa operazione in modo più elegante senza richiedere un interazione da parte dell utente ma per il nostro progetto abbiamo preferito utilizzare questa soluzione più semplice. La trasformazione dell oggetto Vxml in un thread è stata una scelta obbligata per un problema di sincronizzazione: l esecuzione dell activity principale non viene interrotta per la sintesi del parlato, che avviene in background senza che un nuovo componente debba prendere posto sulla schermata del cellulare, né per il riconoscimento, che, pur prevedendo un componente grafico da visualizzare all utente, non blocca immediatamente il thread dell activity. Ricordiamo che il sistema Android è multiprogrammato in grado di eseguire più thread contemporaneamente, benché lo stato delle attività non visibili sia in sospeso. Gli effetti negativi causati da questo comportamento sono l avvio del riconoscimento mentre è ancora in corso la riproduzione da parte del sintetizzatore e anche sovrapposizioni, troncamenti o inversioni dell output. La soluzione iniziale prevedeva di bloccare l activity o impegnarla in un ciclo di busy waiting ad ogni operazione di riconoscimento o sintesi, fino al loro termine, che nel caso della sintesi può essere controllato con il metodo isspeaking() dell oggetto TextToSpeech. Questa tecnica porta il sistema Android a sollevare un application error: application not 28

responding, infatti il thread dell activity non può essere bloccato o impegnato in alcuna operazione che duri più di pochi secondi, deve essere sempre libero per ricevere segnalazioni di eventi da parte del sistema, in particolare le interazione dell utente. Abbiamo quindi modificato la classe Vxml per estendere la classe Thread che fornisce un metodo start() per avviarlo, nella nostra applicazione è invocato quando viene premuto uno dei bottoni corrispondenti ai dialoghi. La sincronizzazione avviene nel seguente modo: quando il thread dell interprete deve effettuare una sintesi testa il valore della variabile speaking_ dell activity che indica se è in corso una sintesi o meno, se il valore è false prosegue, altrimenti aspetta 100 millisecondi; se procede mette a true la variabile, invia il testo al sintetizzatore e effettua un ciclo di attese di 100 ms, testando il metodo isspeaking() dell oggetto TextToSpeech, fino alla fine della riproduzione; per quanto riguarda il riconoscimento si replica il test sulla variabile speaking_ dell activity, se procede, l interprete mette una propria variabile waiting_ a true ed effettua un ciclo di attese di 100 ms su di essa; la variabile waiting_ dell interprete viene messa a false dall activity, dopo che ha ricevuto e inviato il risultato del riconoscimento. Può essere utile, per una rappresentazione visiva dell esecuzione, consultare il diagramma di sequenza riportato nell appendice A. Questa soluzione minimizza il codice eseguito dal thread dell activity, anche se non è possibile sfuggire dal metodo di callback onactivityresult(). Nel codice finale dell activity, riportato nell appendice B, anche per la prova di semplice riconoscimento, avviata dal bottone rappresentato da un microfono, viene lanciato un thread separato della classe Vxml_Thread realizzata per effettuare i primi test di sincronizzazione nella fase di sviluppo. 29

6. Conclusioni L applicazione finale è stata realizzata e testata con successo, è possibile anche vedere il video di un esempio di utilizzo disponibile sul canale youtube dell università (l indirizzo per visualizzarlo al momento è http://www.youtube.com/watch?v=dx6mqrue2ug). L esperienza di questo progetto è stata indubbiamente positiva e ciò è influenzato da diversi fattori che andiamo qui ad illustrare. In primo luogo iniziare a sviluppare applicazioni android è reso semplice sia dalla bontà della documentazione ufficiale sia dalla community attiva e disponibile, ma è anche interessante e non mancano le sfide quando si vuole approfondire e realizzare cose più complesse. Le funzioni di riconoscimento e sintesi sono di discreto livello, considerando la possibilità di averle su uno smartphone; c è da dire, però, che queste tecnologie hanno ancora tanta strada davanti per riuscire a supportare un dialogo veramente naturale. Lo standard VoiceXML si è rivelato utile ai nostri scopi, anche nell ottica di generalizzare il progetto come abbiamo voluto mostrare con i tre dialoghi disponibili; questo linguaggio offre tantissime funzioni, quasi troppe, che però devono essere supportate dall interprete, per non rimanere solo sulla carta. L unica parte da valutare negativamente è quella relativa ai problemi inattesi con l interprete VoiceXML, che ci hanno sottratto diverso tempo e impedito di realizzare un applicazione più significativa di un semplice prototipo d esempio. In effetti uno degli sviluppi futuri di questo lavoro sarebbe proprio quello di sviluppare un applicazione vocale mirata ad uno scopo specifico, come potrebbe essere il supporto all anziano. Per quanto sia più recente, una piattaforma smartphone offre una maggiore mobilità e anche facilità di utilizzo grazie al touchscreen rispetto ad una tradizionale postazione pc. Fare ciò richiederebbe sicuramente di integrare nel progetto un vero interprete VoiceXML, ad esempio il porting di JVoiceXML, ma buona parte delle conoscenze e dei moduli sviluppati per questo lavoro potrebbero essere riutilizzati. Siamo infine certi che, viste anche le risorse investite da grandi aziende come Google, il campo delle applicazioni vocali avrà un notevole sviluppo nei prossimi anni e questa esperienza ci ha permesso di effettuare una prima esplorazione delle tecnologie disponibili e delle loro potenzialità. 30

Appendice A Diagramma delle classi 31

Diagramma di sequenza 32