Human-Computer vocal interaction: analisi dello

Transcript

Università Politecnica delle Marche
Facoltà di Ingegneria
Dipartimento di Ingegneria dell’Informazione
Corso di Laurea Triennale in Ingegneria Informatica e dell’Automazione
Human-Computer vocal interaction: analisi
dello standard VoiceXML
Tesi di:
Andreana Felicione
Relatore:
Prof. Aldo Franco Dragoni
Anno Accademico 2012/2013
i
Corso di Laurea Triennale in Ingegneria Informatica e dell’Automazione
Human-Computer vocal interaction: analisi
dello standard VoiceXML
Tesi di:
Andreana Felicione
Relatore:
Prof. Aldo Franco Dragoni
Anno Accademico 2012/2013
Via Brecce Bianche – 60131 Ancona (AN), Italy
Love Every Day Aimlessly.
Sommario
La continua introduzione di nuovi dispositivi interattivi informatici nelle nostre case, uffici,
auto, luoghi di commercio e turismo, implica la necessità di progettare un’usabilità pervasiva
nei vari contesti di utilizzo. Si apre in questo modo la possibilità di creare in futuro servizi
migratori, ovvero servizi interattivi che seguono l’utente nei suoi spostamenti e che si adattano
ai dispositivi disponibili nei nuovi ambienti in cui l’utente si viene a trovare. Il presente progetto
si prefigge lo scopo di dare un aiuto alla comprensione delle diverse tipologie di interazione uomocomputer che sono attualmente le principali protagoniste dello sviluppo tecnologico. L’intento di
questa tesi è inoltre, quello di presentare una descrizione del lavoro svolto circa la realizzazione
di un’applicazione Android capace di dialogare con l’utente. Il raggiungimento degli obiettivi è
stato possibile grazie ad un’approfontita analisi delle caratteristiche per documenti VoiceXML,
definito dallo standard del W3C; pertanto questo lavoro tratterà principalmente tale argomento.
Il sistema realizzato fornisce un ausilio attivo, in quanto partendo dalle esigenze dell’utente
espresse in linguaggio «naturale», ne estrae automaticamente le parole chiave per la formulazione
delle risposte.
vii
Indice
1 Introduzione
1
2 Stato dell’arte
2.1 L’interazione uomo-robot . . . . .
2.2 Tassonomia dell’HRI . . . . . . . .
2.3 Le diverse modalità di interazione .
2.4 L’interazione vocale . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
3 Android
3.1 Panoramica . . . . . . . . . . . . . . . .
3.2 Architettura . . . . . . . . . . . . . . . .
3.3 Storia delle versioni . . . . . . . . . . . .
3.4 Componenti di un’applicazione Android
3.5 Activities . . . . . . . . . . . . . . . . .
3.6 Sviluppare per Android . . . . . . . . .
3.6.1 Sistemi di controllo versione . . .
3.6.2 I pacchetti APK . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
13
15
16
19
20
20
4 Il riconoscimento vocale
4.1 ASR . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Distributed Speech Recognition (DSR)
4.2 TTS . . . . . . . . . . . . . . . . . . . . . . .
4.3 Gestione dei dialoghi . . . . . . . . . . . . . .
4.4 VoiceXML . . . . . . . . . . . . . . . . . . . .
4.5 JVoiceXML . . . . . . . . . . . . . . . . . . .
4.5.1 Configurazione delle implementazioni .
4.5.2 Parsing dei documenti VoiceXML . . .
4.5.3 Processing dei documenti VoiceXML .
4.5.4 Interpreter e ImplementationPlatform
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
24
25
26
27
30
32
32
33
34
.
.
.
.
.
37
38
39
41
43
43
5 Il lavoro svolto
5.1 Analisi dei requisiti . . . .
5.2 Progettazione . . . . . . .
5.3 Implementazione . . . . .
5.4 Standard W3C . . . . . .
5.4.1 Scopi e componenti
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
Indice
Indice
5.4.2
5.4.3
5.4.4
Struttura di un documento
5.4.2.1 Prolog . . . . . . .
5.4.2.2 Elementi . . . . .
Grammatiche . . . . . . . .
Gestione degli eventi . . . .
.
.
.
.
.
.
.
.
.
.
6 Conclusioni e sviluppi futuri
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
45
49
50
55
x
Elenco delle figure
2.1
2.2
Robot KAMRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Robot AIBO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
Architettura di Android . . . . . . . . . . . . . . . . . . . . . . . . . .
Numeri di distribuzione della piattaforma Android . . . . . . . . . . .
Ciclo di vita di un Activity . . . . . . . . . . . . . . . . . . . . . . . .
File AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . . . . . .
Editor messo a disposizione da Eclipse per il file AndroidManifest.xml
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
15
18
21
22
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Sistema di riconoscimento vocale . . .
Esempio documento VoiceXML . . . .
Architettura di un’applicazione vocale
Architettura di base di JVoiceXML .
Core di JVoiceXML . . . . . . . . . .
Costruttore VoiceXmlDocument . . . .
ImplementationPlatform . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
28
29
31
32
33
35
5.1
5.2
5.3
5.4
5.5
5.6
Analisi dei requisiti: modello a cascata . . . . . . . . . . .
Diagramma UML del primo tentativo di implementazione
Prolog integrale . . . . . . . . . . . . . . . . . . . . . . . .
Prolog semplificato . . . . . . . . . . . . . . . . . . . . . .
Elenco tag . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Catch Handlers . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
40
44
44
47
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
xi
Capitolo 1
Introduzione
La tecnologia di base necessaria per realizzare interfacce vocali ha dovuto affrontare problemi
piuttosto complessi ma, dopo decenni di ricerche, ha ormai raggiunto notevoli risultati. I sistemi
di riconoscimento vocale possono raggiungere un’accuratezza di circa l’85% e sono oggi una realtà
consolidata; si pensi, ad esempio, ai classici servizi clienti messi a disposizione dagli operatori
telefonici. Tali servizi, accessibili mediante telefonia fissa o mobile, sono in grado di operare
anche in condizioni fino a poco tempo fa impensabili. Essi infatti risultano essere efficienti sia
per diversi tipi di utenti (dai più esperti ai meno esperti), sia nei diversi tipi di ambiente. Per
ambiente si intende sia il luogo in cui il servizio vocale viene usato (dagli spazi chiusi come gli
uffici agli spazi aperti come le strade, dagli ambienti mobili come le auto agli ambienti molto
rumorosi come gli aereoporti), sia la linea telefonica usata per la trasmissione (fissa o mobile)
[1]. Tuttavia servizi di telefonia come quelli sopra citati rimangono limitati a pochi casi d’uso
e di conseguenza non sono tuttora diffusi come ci si aspetterebbe. Ciò nonostante, grazie alla
disponibilità di nuovi dispositivi mobili con ottime capacità di processing e memorizzazione, è
possibile pensare ad una estensione dei suddetti sistemi vocali.
In questo lavoro di tesi, dopo un’indispensabile dissertazione riguardante le questioni fondamentali dell’interazione uomo-computer (Capitolo 2), sarà esposta una trattazione del lavoro di
tirocinio svolto dall’autrice di questo testo assieme agli studenti Riccardo Cecchi, Eros Federici e Federico Fioravanti. Il tirocinio, svoltosi nel Dipartimento di Ingegneria dell’Informazione
dell’Università Politecnica delle Marche, si è concluso con la realizzazione di un’ applicazione
Android capace di dialogare con l’utente. Nello specifico, l’applicazione prodotta costituisce un
interprete di documenti VoiceXML, in grado di leggere ed eseguire file .vxml il cui linguaggio
rispetti le norme dello standard definito dal World Wide Web Consortium (W3C). Pertanto,
uno degli obiettivi di questa tesi sarà quello di fornire un’analisi approfondita di quelle che sono
le specifiche dello standard W3C.
Nel terzo e quarto Capitolo si introdurranno i due grandi temi che hanno caratterizzato questo
lavoro: il sistema Android, di cui anche i lettori meno esperti in materia avranno sicuramente sentito parlare e il sistema di riconoscimento vocale, facendo riferimento in particolare al
programma per PC JVoiceXML.
Nel quinto Capitolo trova spazio il corpo principale di questo lavoro che consiste nell’esposizione delle principali fasi che hanno caratterizzato il processo di sviluppo dell’applicazione. Si focalizzerà l’attenzione soprattutto sull’analisi preliminare delle specifiche definite dal suddetto standard per documenti VoiceXML, il W3C; tale analisi ha permesso la successiva implementazione
e realizzazione dell’applicazione vocale.
1
CAPITOLO 1. INTRODUZIONE
Come molti altri studenti che prima di noi si sono imbattuti nel mondo dell’interpretazione
vocale, abbiamo inizialmente intrapreso la strada che a prima vista sembrava essere la più semplice: realizzare un nostro interprete VoiceXML implementando solo le parti dello standard W3C
che interessavano il caso d’uso propostoci dal docente. Tradizionalmente, infatti, gli sviluppatori di software libero e open source si concentrano maggiormente sulle caratteristiche di una
specifica applicazione, il più delle volte ignorando la necessità di una progettazione user-centric.
Questa tendenza deriva principalmente dal fatto che gli sviluppatori hanno poca dimistichezza
con gli studi di interazione uomo-computer e sono carenti delle conoscenze di base [2]. In un
secondo tempo però, siamo venuti a conoscenza di un progetto, iniziato e non ancora portato
a termine, nel quale un dottorando spagnolo aveva tentato di realizzare il porting in Android
di un noto interprete vxml, JVoiceXML, scritto in Java per PC. Abbiamo quindi convenuto di
dover abbandonare la nostra implementazione iniziale per poterci dedicare al completamento del
progetto trovato. Siamo dunque riusciti a creare un interprete dell’intero standard W3C scritto
in Java e funzionante in Android.
L’applicazione da noi realizzata soddisfa tutte le specifiche richiesteci, ma presenta ancora
varie imperfezioni che verranno esaminate nel dettaglio nel sesto ed ultimo Capitolo di questa
tesi.
2
Capitolo 2
Stato dell’arte
2.1 L’interazione uomo-robot
L’interazione uomo-robot (HRI, Human-Robot Interaction) è un’area di ricerca multidisciplinare in costante sviluppo, ricca di spunti per ricerche avanzate e trasferimenti di tecnologia. Nel
corso degli anni sono stati utilizzati diversi dispositivi (tastiere, mouse, tavolette grafiche etc.)
per l’interazione uomo-computer (HCI, Human-Computer Interaction). Il rapporto tra i robot
e gli esseri umani è però, molto differente rispetto alle relazioni uomo-computer, al punto da
meritare un proprio settore di studio. I robot differiscono dalle macchine semplici e anche dai
computer complessi in quanto sono spesso progettati per essere mobili e autonomi [3]. Due enti
statunitensi, il National Science Foundation (NSF) e il Department of Energy (DOE), hanno
definito l’interazione uomo-robot di importanza strategica [4] e hanno sottolineato quanto la
ricerca in questo campo sia solo agli inizi.
La «comunicazione» tra un robot ed un essere umano può avvenire per mezzo dei dispositivi
“classici” dell’interazione uomo-computer (tastiera, mouse, touchpad, monitor, schermi sensibili
al tocco, etc.) oppure utilizzando modalità interattive più “naturali” (human-friendly), tipiche
dell’interazione uomo-uomo, in grado di coinvolgere tutti i sensi umani e i canali di comunicazione
come il parlato, la visione, la gestualità e il tatto [5]. La voce, in particolare, rappresenta una
modalità di interazione estremamente naturale per l’uomo, visto che rappresenta il metodo di
comunicazione preferenziale utilizzato ogni giorno. Per tale ragione, le tecnologie vocali hanno
rivestito e rivestono un particolare interesse all’interno della comunità scientifica.
Fino a poco tempo fa comunque, l’attenzione della comunità robotica è stata principalmente
“robot-centrica” con maggiore enfasi sulla sfida tecnologica per ottenere controllo e mobilità
intelligenti. Soltanto di recente i progressi scientifici e tecnologici hanno permesso di fare predizioni di questo tipo: “entro una decade, robot che rispondono al telefono, aprono la posta,
consegnano documenti a dipartimenti differenti, preparano il caffè, puliscono e passano l’aspirapolvere potrebbero occupare ogni ufficio.” [6]. Per fare in modo che i robot possano svolgere
questo tipo di compiti è opinione comune che necessitino di un’intelligenza di tipo “umano” e
che siano capaci di interagire con gli esseri umani nel modo in cui gli uomini comunicano tra
loro. Questo approccio alla robotica, di tipo “uomo-centrico”, enfatizza lo studio degli esseri
umani come modelli per i robot.
Prima che robot intelligenti siano sviluppati e integrati nella nostra società però, è necessario
studiare attentamente la natura delle relazioni uomo-robot e l’impatto che queste relazioni possono avere nel futuro della società umana. Una buona strategia per fare questo è attingere alla
3
CAPITOLO 2. STATO DELL’ARTE
2.2. TASSONOMIA DELL’HRI
grande esperienza già maturata nell’ambito della comunità dell’HRI, dove sono state studiate le
direzioni dello sviluppo tecnologico e il suo impatto sugli esseri umani [5].
2.2 Tassonomia dell’HRI
Per meglio comprendere la natura dell’interazione uomo-robot riportiamo di seguito una particolare tassonomia [7] che inquadra le possibili situazioni interattive. Tra le altre ricerche svolte
in questo senso citiamo Agah [8] in cui è presentata una tassonomia dell’interazione tra uomo
e sistemi intelligenti, Dudek et al. [9] e Balch [10] in cui sono studiate tassonomie concernenti
l’interazione con robot multipli.
• Livello di autonomia/livello di intervento. La prima categoria tassonomica concerne
il livello di intervento necessario per controllare un robot. Ad un estremo troviamo i
robot totalmente privi di autonomia. Un esempio è fornito da ROBONAUT della NASA,
ideato per soddisfare le esigenze di manipolazione abili di future missioni [11]. All’estremo
opposto si pongono i robot completamente autonomi come “Polly” che fa visitare il settimo
piano dell’Artificial Intelligence Laboratory del MIT [12].
• Rapporto numero di persone/numero di robot. Questa categoria indica semplicemente il rapporto tra il numero di persone coinvolte nell’interazione e il numero di
robot.
• Supporto alle decisioni per gli operatori. Questa categoria tassonomica concerne il
tipo di informazione disponibile all’operatore per il supporto alle decisioni (informazione
dei sensori disponibili, eventuali fusioni di informazione sensoriale ed infine il pre-processing
o verifica dello stato iniziale dei sensori).
• Criticità. La criticità misura quanto può essere dannosa l’esecuzione errata di un compito.
L’interazione con una sedia a rotelle robotica, ad esempio, avrà un alto valore di criticità:
se la sedia fallisce nel rilevare una rampa di scale in discesa può far precipitare il suo
operatore causando gravi lesioni. All’estremo opposto, un cagnolino robotico giocattolo
che non funziona bene non provoca alcun danno.
• Tassonomia spazio/temporale. Questa tassonomia [13] suddivide l’HRI in base allo
spazio che separa l’operatore dal robot (robot collocati o non collocati) e al tempo di
risposta dell’interazione (robot sincroni o asincroni).
• Composizione del team di robot. L’ultima categoria presentata riguarda la struttura
del team di robot che può essere composto da robot dello stesso tipo (team omogeneo) o
di tipo diverso (team non omogeneo).
2.3 Le diverse modalità di interazione
Nella maggior parte dei sistemi odierni i comandi vengono impartiti direttamente tramite
manipolazione del dispositivo di input, per esempio tramite tastiere, manopole e pulsanti. Il
processo di interazione viene controllato e gestito attraverso una rappresentazione grafica su uno
4
2.4. L’INTERAZIONE VOCALE
schermo, che può essere parte integrante del sistema robotico o meno. L’obiettivo che si desidera
ottenere è spostare il campo di interazione dalla superficie di uno schermo allo spazio reale di
una stanza [14] che l’utente e il robot possono condividere.
Tra le diverse modalità interattive di tipo human-friendly è possibile distinguere sei categorie
principali anche se, in alcuni casi, i confini tra le diverse tipologie di interazione appaiono sfumati.
1. vocale;
2. gestuale;
3. espressioni facciali;
4. tracciamento dello sguardo;
5. prossemica e cinesica (riguardanti rispettivamente la distanza tra gli interlocutori e le
modalità di movimento di una o più parti del corpo);
6. aptica (riguardante tutto ciò che concerne il senso del tatto).
Dal momento che l’argomento principale di questo elaborato si concentra sull’interazione vocale
tra l’uomo e i robot, dedicheremo il prossimo paragrafo interamente all’indagine della prima
categoria sopra citata.
2.4 L’interazione vocale
La predilezione per la modalità vocale non è solo una propensione riguardante questa tesi.
Come risulta dai dati raccolti attraverso un sondaggio d’opinione [15] la maggior parte delle
persone, interrogate circa i propri desideri in termini di HRI, preferisce nettamente l’uso del
parlato. Per questo motivo si rende necessario, da parte delle comunità interessate, procedere
con ricerche di usabilità al fine di investigare fino a che punto la tecnologia disponibile oggi sia
in grado di soddisfare le esigenze degli utenti.
In ogni caso non è detto che il parlato venga considerato il mezzo di comunicazione ideale in
ogni circostanza: in molti casi sono di gran lunga preferibili dispositivi di interazione “vecchio
stile”, come nei casi di tele-operazione (utilizzando dei joystick) oppure quando sia necessario
specificare al robot un certo obiettivo da raggiungere su una mappa (selezionando con un mouse
un punto su uno schermo).
E’ possibile comunque individuare due categorie di situazioni nelle quali può essere realizzata
con successo un’interfaccia vocale (speech interface):
• l’utente ha le mani e/o gli occhi occupati;
• l’uso di dispositivi convenzionali è considerato inopportuno e quindi sconsigliato.
Un primo esempio di interfaccia vocale è costituito da KANTRA, basata sul parlato e sviluppata presso l’Università di Karlsruhe e l’Università di Saarland. KANTRA è applicata ad un
robot mobile dotato di due braccia chiamato KAMRO (Figura 2.1), capace di ricevere istruzioni da frasi corte: il sistema è in grado di completare da solo un’informazione non specificata,
5
eliminando alcune componenti di incertezza presenti nell’istruzione vocale [16]. L’input è elaborato attraverso un parser basato su una grammatica di unificazione che produce la struttura di
superficie della frase che, a sua volta, viene elaborata dalla componente di valutazione.
Figura 2.1: Robot KAMRO
All’Università di Edimburgo, il robot mobile Godot [17] è stato usato come banco di prova
per un’interfaccia tra un sistema robotico di navigazione a basso livello e un sistema simbolico
basato sul dialogo.
Nell’ambito del progetto “Instruction Based Learning for Mobile Robots” del Robotic Intelligence Laboratory dell’Università di Plymouth è stato realizzato un robot mobile in grado di
ricevere istruzioni vocali su come spostarsi da un posto ad un altro all’interno di una città in
miniatura [18]. Il sistema è in grado di ricevere istruzioni del tipo “prendi la prima a sinistra”,
“prosegui dritto finché...”, “se la strada è bloccata prendi quest’altra”, etc.
Il sistema Kairai è il risultato di un progetto di ricerca congiunto tra l’Università di New York
ed il Tokyo Institute of Technology. Il sistema incorpora un certo numero di robot software
3-D con i quali è possibile conversare. Accetta comandi vocali, li interpreta ed esegue i relativi
compiti in uno spazio virtuale [19]. Nello spazio virtuale possono trovarsi diversi robot-software
contemporaneamente e per mezzo della voce dell’operatore, Kairai accetta un comando alla
volta.
Il progetto Hygeiorobot si è concluso nel 2001 ed ha coinvolto il National Centre for Scientific
Research “Demokritos” di Atene e l’Università di Piraeus nella realizzazione di metodi e stru-
6
menti per il controllo e la navigazione di un robot mobile di servizio per l’assistenza ospedaliera
[20]. In questo contesto si sono rivelati particolarmente adatti sistemi capaci di comunicare
attraverso la voce e in grado di gestire dialoghi, dal momento che il robot non trasportava una
tastiera o altri dispositivi di interazione comuni e doveva essere utilizzato da persone con poca
o nessuna esperienza informatica.
Tra i robot disponibili sul mercato spicca AIBO (Figura 2.2), un robot a quattro zampe realizzato dalla Sony in cui il parlato è parte integrante dell’interfaccia utente. Il suo comportamento
simula quello di un cane nella sua abilità di camminare e giocare con funzioni integrate per
simulare emozioni, istinti, apprendimento e crescita.
Figura 2.2: Robot AIBO
Il robot umanoide HERMES (Humanoid Experimental Robot for Mobile Manipulation and
Exploration Services) è stato creato presso la Bundeswehr University di Monaco di Baviera
[21]. HERMES è in grado di esplorare ambienti sconosciuti, eseguire compiti di trasporto e
manipolazione e, soprattutto, di interagire e comunicare anche con operatori inesperti, per
mezzo del linguaggio naturale.
Finora sono stati elencati una serie di dispositivi incentrati sul parlato, ma esiste un altro
campo di ricerca che riguarda le interfacce basate sulla conversazione. Le ricerche più recenti
mirano alla realizzazione di interfacce in grado di stabilire una conversazione tra una persona
e un robot riguardo ad un determinato compito da raggiungere. Lo sviluppo di interfacce ba7
sate sul linguaggio naturale può, comunque, trarre beneficio da una lunga tradizione di ricerca
nel contesto dell’Interazione Uomo-Computer, Elaborazione del Linguaggio Naturale e Tecnologie del Parlato e per di più, alcuni prodotti commerciali sono già disponibili sul mercato e
permettono di realizzare sistemi di dialogo dotati di un alto grado di robustezza e di affidabilità.
8
Capitolo 3
Android
3.1 Panoramica
Android è un sistema operativo creato per una vasta gamma di dispositivi con differenti fattori
di forma. Questa piattaforma si caratterizza per la struttura open-source (escluse alcune versioni
intermedie), [22, 23, 24] e il suo basarsi su kernel Linux. Proponendosi come toolkit software
open-source ed essendo ormai all’interno di milioni di telefoni cellulari e altri dispositivi mobili,
Android rappresenta il più importante ambiente di lavoro per gli sviluppatori di applicazioni
[25].
La società Android, nata nel 2003 a Palo Alto, in California, viene inizialmente acquistata da
Google nel 2005. Due anni dopo nasce l’associazione Open Handset Alliance (OHA), composta
da 86 aziende guidate da Google stessa e il 5 Novembre 2007 viene ufficialmente annunciato al
publico il loro primo prodotto: Android, una piattaforma basata sul sistema operativo Linux.
Il 12 novembre 2007 l’OHA ha rilasciato il Software Development Kit (SDK) che include:
strumenti di sviluppo, librerie, un emulatore del dispositivo, la documentazione, alcuni tutorial,
FAQ, e altro. Il kit pesa meno di 100 Megabyte ed è installabile su qualsiasi computer x86 che
usa come sistema operativo Windows XP o Vista, Mac OS X 10.4.8 e successivi, o Linux. L’SDK
permette allo sviluppatore di passare dalla compilazione della nostra applicazione all’effettiva
esecuzione sia in emulazione, sia su un dispositivo concreto.
Le applicazioni Android sono sviluppate all’interno di un framework, ossia all’interno di una
struttura dati specifica. La struttura del framework è molto chiara se si utilizza il plug-in
dell’SDK disponibile per Eclipse. Quest’ultimo è un ambiente di sviluppo integrato, multilinguaggio e multipiattaforma che permette di visualizzare in maniera semplice tutte le componenti di un’applicazione. Il mancato utilizzo di Eclipse, tuttavia, non impedisce di scrivere
applicazioni funzionanti.
La piattaforma Android ha a disposizione il database SQLite, la libreria dedicata SGL per la
grafica bidimensionale (invece del classico server X delle altre distribuzioni Linux) e supporta
lo standard OpenGL ES per la grafica tridimensionale [26]. Android è inoltre dotato di un
programma chiamato macchina virtuale, la Dalvik Virtual Machine (DVM), come ambiente di
runtime e una serie di applicazioni preinstallate come un browser, una rubrica e un calendario.
Tramite l’SDK, o meglio, tramite gli strumenti utilizzati mediante l’SDK, trasformiamo la
nostra applicazione Android in un codice intermedio chiamato bytecode che viene poi eseguito
dalla macchina virtuale (Virtual Machine, VM). In Android quindi accade esattamente quello
che avviene in Java, ma con una nuova VM ottimizzata dalla Sun Microsystem. A differenza
9
CAPITOLO 3. ANDROID
3.2. ARCHITETTURA
della Java Virtual Machine (JVM), infatti, la DVM è stata progettata per l’esecuzione di software
sui sistemi con risorse limitate, che possono essere ad esempio i dispositivi portatili come tablet
e smartphones.
Ogni terminale Android ha la sua DVM. Avremo quindi la seguente catena di esecuzione:
Applicazione Android: Compilazione: Bytecode: DVM:
esecuzione dell’applicazione
L’idea è questa: essendo la DVM uguale per tutti i dispositivi Android, ogni applicazione può
essere eseguita su ogni terminale, indipendentemente dal costruttore e dall’implementazione. Di
conseguenza molti costruttori di dispositivi mobili scelgono Android in modo da fornire ai propri
utenti un ambiente condiviso da moltissimi altri utenti. La compatibilità tra i vari dispositivi
è garantita dal progetto Android Open Source Project (AOSP) guidato da Google. Secondo
il progetto “l’obiettivo è quello di creare un vero e proprio successo, in modo da migliorare
l’esperienza mobile per gli utenti” [24].
Il primo dispositivo mobile dotato di sistema operativo Android è stato il T-Mobile G1, prodotto dalla società taiwanese HTC e commercializzato dal carrier telefonico T-Mobile. Il prodotto
è stato presentato il 23 Settembre 2008 a New York e messo in commercio il 22 Ottobre dello
stesso anno. Ad aprile 2009 l’HTC ha dichiarato di averne venduti oltre 1 milione.
3.2 Architettura
L’architettura Android si presenta divisa in diversi livelli (Figura 3.1). Alla base dello stack
troviamo un kernel Linux nella versione 2.6.. A differenza di un kernel Linux standard, per Android sono stati aggiunti ulteriori moduli oltre ai già presenti driver per il controllo dell’hardware
come lo schermo, la tastiera e la fotocamera:
• Binder InterProcess Communication (IPC) Driver, un driver dedicato che permette
a processi di fornire servizio ad altri processi attraverso un insieme di API (Application
Programming Interface) di più alto livello rispetto a quelle presenti su un kernel Linux
standard; ciò permette la comunicazione tra processi con un costo computezionale minore
e un relativo minore consumo di batteria;
• Low Memory Killer, un sistema che si preoccupa di terminare i processi liberando
così spazio nella memoria centrale per soddisfare le richieste di un altro processo. La
terminazione dei processi avviene secondo un sistema di ranking che assegna dei punteggi
ai processi; i processi che verranno terminati saranno quelli con punteggio più alto. Il
processo init (primo processo che il kernel manda in esecuzione) non può essere terminato;
• Ashmem (Anonimous Shared Memory), sistema di memoria condiviso anonimo. Il
vantaggio di Ashmem rispetto ai sistemi Linux che fanno uso della memoria condivisa,
è che viene fornito al kernel uno strumento per recuperare dei blocchi di memoria non
utilizzati;
10
CAPITOLO 3. ANDROID
3.2. ARCHITETTURA
Figura 3.1: Architettura di Android
• RAM Console e Log devices, per agevolare il debugging Android fornisce la capacità di
memorizzare i messaggi di log generati dal kernel in un buffer RAM. È disponibile inoltre
un modulo separato che permette ai processi utente di leggere e scrivere messaggi di log;
• Android Debug Bridge, uno strumento che permette di gestire in maniera versatile
un’istanza dell’emulatore o eventualmente di un dispositivo reale;
• Power Management, sezione progettata per permettere alla CPU di adattare il proprio
funzionamento al fine di non consumare energia se nessuna applicazione o servizio ne fa
richiesta.
Esistono poi delle librerie native, realizzate in C o in C++, che si trovano sopra al livello kernel
e che rappresentano il vero e proprio core del sistema oeprativo:
• Surface Manager, è il modulo che gestisce le View. Funziona praticamente come uno
scheduler per la gestione della visualizzazione delle interfacce grafiche e previene eventuali
11
CAPITOLO 3. ANDROID
3.2. ARCHITETTURA
problemi di accavallamento scoordinato sul display. E’ un componente di vitale importanza
per un terminale che fa delle interfacce grafiche un punto di forza del suo funzionamento;
• Open GL ES, è una libreria grafica, versione light della libreria OpenGL per terminali
mobili, che permette di utilizzare grafica 3D;
• SGL (Scalable Graphics Library), libreria scritta in C++ che permette di gestire la
grafica 2D;
• Media Framework, componente in grado di gestire i contenuti multimediali (codificatore
per l’acquisizione e riproduzione di contenuti audio e video);
• FreeType, componente che gestisce i font;
• SQLite, database piccolo ed efficiente messo a disposizione dello sviluppatore per la
persistenza dei dati nelle varie applicazioni sviluppate;
• WebKit, browser engine open source (utilizzato anche per i più conosciuti browser web
Safari e Chrome). Da sottolineare che non si tratta di un browser web, bensì di un motore
di rendering capace di visualizzare sullo schermo il contenuto formattato presente nei
documenti di mark up come HTML e XML;
• SSL (Secure Socket Layer), si tratta del noto protocollo di rete ormai sostituito dal
TLS (Transport Layer Security) che permette una comunicazione sicura end-to-end (da
sorgente a destinatario) su reti TCP/IP (come ad esempio Internet).
Per quanto riguarda infine l’Application Framework, lo sviluppatore ha a disposizione una serie
di API che sfruttano le librerie sottostanti di Android. Sono presenti i seguenti moduli:
• Activity Manager, modulo che gestisce tutto il ciclo di vita delle activity. Le activity
sono entità associate ad una schermata, rappresentano quindi l’interfaccia verso l’utente. Il
compito dell’Activity Manager è quello di gestire le varie activity sul display del terminale
e di organizzarle in uno stack in base all’ordine di visualizzazione sullo schermo;
• Package Manager, modulo che gestisce i processi di installazione e rimozione delle
applicazioni dal sistema;
• Telephony Manager, modulo che gestisce l’interazione con le funzioni tipiche di un
cellulare;
• Content Provider, modulo che gestisce la condivisione di informazioni tra i vari processi
attivi. Il suo utilizzo è simile a quello di un repository comune nel quale i vari processi
possono leggere e scrivere informazioni;
• Resource Manager, modulo deputato alla gestione delle informazioni relative ad una
applicazione (file di configurazione, file di definizione dei layout, immagini utilizzate, etc.);
• View System, gestisce l’insieme delle viste utilizzate nella costruzione dell’interfaccia
verso l’utente (bottoni, griglie, text boxes, etc.);
12
CAPITOLO 3. ANDROID
3.3. STORIA DELLE VERSIONI
• Location Manager, modulo che mette a disposizione dello sviluppatore una serie di API
che si occupano della localizzazione. Esistono due provider per la localizzazione: GPS e
NETWORK. GPS utilizza i satelliti geostazionari per il posizionamento geografico, ha bisogno però della vista del cielo e risente delle cattive condizioni atmosferiche. NETWORK
utilizza punti dei quali si conosce la posizione geografica come ad esempio reti wireless
geolocalizzate (Hot Spot);
• Notification Manager, mette a disposizione una serie di meccanismi utilizzabili dalle
applicazioni per notificare eventi al dispositivo, che intraprenderà delle particolari azioni
in conseguenza della notifica ricevuta.
Molti dei moderni sistemi operativi per smartphone supportano lo sviluppo di applicazioni di
terze parti con le API di sistema open-source. Oltre a una API “aperta”, il sistema operativo
Android però, fornisce anche un elaborato sistema di scambio di messaggi tra applicazioni. La
piattaforma Android quindi incoraggia la collaborazione tra le applicazioni e riduce il fardello
dello sviluppatore facilitando il riutilizzo dei componenti [27].
3.3 Storia delle versioni
Dal 2008 gli aggiornamenti di Android per migliorarne le prestazioni e per eliminare i bug delle
precedenti versioni sono stati molti. Ogni aggiornamento (o release) segue un ordine alfabetico
e possiede l’originale caratteristica di prendere il nome dai dolciumi. Oltre il vero e proprio
sistema mobile, infatti, una delle più grandi peculiarità di Android risiede nella nomenclatura
utilizzata sin dalla sua nascita dai suoi sviluppatori.
La prima vera e propria release Android che ha segnato la storia della piattaforma è stata
Cupcake 1.5 e a seguire Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich,
e Jelly Bean. Meno note sono le versioni precedenti alla 1.5. Prima di Android 1.5, infatti, non
c’è stato alcun Android 1.4, ma soltanto due antecedenti release: Android 1.0 ed 1.1.
La versione italiana della più celebre enciclopedia del web per Android 1.0 ed 1.1 indica rispettivamente “Astro” e “Bender”. Stando sempre a questa fonte, il nome Bender è stato successivamente sostituito con “Banana Bread” per completare la cerchia dei dolci. Molto probabilmente
però, la nomenclatura delle prime versioni di Android, riportata dalla nota enciclopedia, è stata
il semplice frutto dell’immaginazione di qualcuno poiché, a differenza degli altri nomi, non ha
un reale riscontro.
Per fare chiarezza su questo argomento hanno voluto dire la loro gli ingegneri di Google:
Jean-Baptiste Queru, Dianne Hackborn e Romain Guy. Queru spiega come inizialmente non ci
sono stati nomi in codice fino al rilascio della versione 1.1. In effetti all’interno degli archivi ufficiali dell’SDK troviamo versioni come "m3-rc20a", "m3-rc37a", "m5-rc14". Queste build definite
milestone (pietre miliari), progredivano tramite un numero di serie e non avevano nulla a che
vedere con le release successive: m5, ad esempio, dispone di sole 4 applicazioni, non ha nessun
app drawer (menu con l’elenco delle applicazioni) ed un dekstop non utilizzabile. Ovviamente
la complessità di questa nomenclatura ha portato non pochi problemi nelle comunicazioni via
email degli sviluppatori. Molto spesso, infatti, veniva solamente indicato il codice numerico sen-
13
CAPITOLO 3. ANDROID
3.3. STORIA DELLE VERSIONI
za riferimento alla versione della milestone, perciò si decise di risolvere il problema rinominando
con un nome proprio ogni release a partire dalla 1.1, Petit Four.
Per quanto riguarda i nome Astro e Bender, Dianne Hackborn afferma che sicuramente sono
stati nomi in codice con i quali hanno contrassegnato le prime tappe dello sviluppo di release
pre-1.0. La Hackborn ci tiene a precisare in un post su Google+: “Il nome in codice iniziale
era Astro Boy, non Astro. Il piano era di usare nomi in codice che sono stati i nomi dei robot
del cinema e della televisione, e li stavamo pensando in ordine alfabetico. Andando avanti però,
i piani sono cambiati e quelle milestone sono state modificate. Ad un certo punto ci siamo
ritrovati con la versione 1.1 e l’abbiamo rinominata Petit Four perché il nostro PM era molto
ghiotto. Abbiamo quindi continuato a seguire questa linea guida.”
Quindi Astro Boy e Bender erano reali, ma sono andati persi con la milestone super-precoce;
la timeline completa delle versioni è questa:
• Android milestone builds (tra le quali fluttuano rimasugli di codice di Astro Boy e Bender);
• Android 1.0 (senza nome in codice);
• Android 1.1 - Petit Four;
• Android 1.5 - Cupcake;
• Android 1.6 - Donut;
• Android 2.0 - Éclair;
• Android 2.2 - Froyo;
• Android 2.3 - Gingerbread;
• Android 3.0 - Honeycomb;
• Android 4.0 - Ice Cream Sandwich;
• Android 4.1 - Jelly Bean.
Ogni mese Google pubblica i risultati di distribuzione mondiale ottenuti dal proprio sistema
operativo. Purtroppo, a causa della frammentazione e delle diverse caratteristiche dei device,
ancora oggi esistono smartphones con Android 2.1 o altre vecchie release. Questo preoccupante
fenomeno ostacola mese per mese la crescita della distribuzione di ogni nuova versione rilasciata.
Nella Figura 3.2 sono mostrati degli interessanti grafici che mostrano il rapporto di diffusione
ed altri fattori di ogni singola major release Android. In particolare sono riportati i dati relativi
all’1 Ottobre 2012, a pochi mesi dall’uscita della release 4.1 Jelly Bean, e al 3 Giugno 2013, a
pochi mesi dall’uscita della release 4.2 Jelly Bean.
Seppur Jelly Bean abbia avuto un incremento di circa il 30% in 8 mesi e Gingerbread un
decremento del 20%, quest’utlimo continua ad essere in testa. L’andamento dell’ultima versione
di Android quindi è ancora abbastanza deludente, ma i futuri aggiornamenti promessi aiuteranno
probabilmente la crescita di questi numeri.
14
CAPITOLO 3. ANDROID
3.4. COMPONENTI DI UN’APPLICAZIONE ANDROID
(a) 1 Ottobre 2012
(b) 3 Giugno 2013
Figura 3.2: Numeri di distribuzione della piattaforma Android
Le altre versioni nel frattempo si stanno muovendo come previsto. Cupcake è rimasta stabile
allo 0,1%, Eclair è scesa dal 3,4% all’1,5%, Froyo è scivolata al 3,2% dal 12,9%, Honeycomb è
in leggero calo come anche Ice Cream Sandwich.
Si spera di poter presto vedere lo stato di Jelly Bean crescere ed eliminare il gap dalle altre
distribuzioni, soprattutto dopo il lancio della prossima release 4.3 che verrà lanciata tra poche
settimane, insieme alla presentazione del nuovo tablet Nexus 7. Si conta anche su una rapida crescita di Jelly Bean dopo l’annunciato aggiornamento 5.0 Key “Lime Pie” nel prossimo
autunno.
3.4 Componenti di un’applicazione Android
Come abbiamo già accennato al termine del Paragrafo 3.2, un’innovativa caratteristica della
piattaforma Android che la differenzia da altre piattaforme è un supporto per il riutilizzo di
componenti. Con componente si intende un qualsiasi programma, applicazione o servizio implementati. Le applicazioni non sono più pensate come entità a sé stanti, ma come un insieme
di componenti disponibili nel sistema e richiamabili all’occorrenza, nel momento in cui servono.
15
CAPITOLO 3. ANDROID
3.5. ACTIVITIES
Ne scaturisce un vantaggio non indifferente per lo sviluppatore che si traduce in una maggiore
velocità nella realizzazione di una applicazione, in quanto non serve reimplementarla dall’inizio.
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 di eseguire un riconoscimento
vocale).
In un’applicazione Android esistono sostanzialmente quattro tipologie di componenti:
• Activities, sono probabilmente il modello più diffuso in Android e si realizzano estendendo
la classe base android.app.Activity. Stando alla documentazione ufficiale, un’Activity è
“una singola e precisa cosa che l’utente può fare”. Pìù precisamente, le Activities sono
quei blocchi di un’applicazione che interagiscono con l’utente utilizzando lo schermo e i
dispositivi di input messi a disposizione dallo smartphone;
• Services, sono dei task che vengono eseguiti in background per un indefinito periodo di
tempo e si realizzano estendendo la classe android.app.Service. Sono ad esempio i processi
che lavorano sotto all’interfaccia grafica per elaborare le informazioni inserite dall’utente,
oppure i processi che riproducono un bravo MP3 mentre l’utente utilizza delle Activity
per fare altro. Buona norma è far eseguire un Service, soprattutto per compiti di lunga
durata, in un thread separato rispetto al main thread;
• Broadcast Receivers, sono dei componenti che hanno il compito di eseguire delle azioni
solo in seguito alla ricezione di un determinato evento, una sorta di gestione degli interrupt.
Sono realizzati estendendo la classe android.content.BroadcastReceiver. Un evento può
essere ad esempio la notifica del basso livello della batteria o il cambio di fuso orario.
Un’applicazione può avere più di un Broadcast Receiver per rispondere agli annunci che
si reputano importanti;
• Content Providers, si possono creare estendendo la classe astratta android.content.ContentProvider.
I Content Providers sono utilizzati per mettere a disposizione uno specifico sottoinsieme di
dati della propria applicazione ad altre applicazioni costituendo un canale di comunicazione
tra le differenti applicazioni installate nel sistema.
3.5 Activities
Un’applicazione Android è costituita quindi, da uno o più elementi, ma i componenti più
presenti nelle applicazioni sono indubbiamente le Activities [28]. Comunemente fanno uso di
componenti UI (User Interface) già pronti, come quelli presenti nel pacchetto android.widget,
ma questa non è necessariamente la regola. 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.
16
CAPITOLO 3. ANDROID
3.5. ACTIVITIES
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 (LIFO).
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.
In un sistema desktop il monitor è sufficientemente spazioso da poter mostrare più finestre
simultaneamente, perciò non è affatto raro lavorare con più programmi contemporaneamente
attivi le cui finestre vengono affiancate o sovrapposte. Gli smartphone, invece, funzionano
diversamente. Prima di tutto il display è piccoloe pertanto ha poco senso affiancare due o più
finestre di applicazioni differenti. Poi non bisogna dimenticare che le risorse di calcolo sono
modeste, perciò non è buona cosa tenere simultaneamente in vita troppi programmi. Per questi
motivi le attività di Android hanno carattere di esclusività. È possibile mandare in esecuzione
più Activities simultaneamente, ma soltanto un’Activity alla volta può occupare il display.
L’Activity che occupa il display è in esecuzione e interagisce direttamente con l’utente. Le
altre, invece, sono ibernate e tenute nascoste in background, in modo da ridurre al minimo
il consumo delle risorse di calcolo. L’utente, naturalmente, può ripristinare un’Activity ibernata e riprenderla da dove l’aveva interrotta, riportandola in primo piano. L’Activity dalla
quale ci si sta allontanando, invece, sarà ibernata e mandata in sottofondo al posto di quella
ripristinata. Il cambio di Activities può anche avvenire a causa di un evento esterno. Il caso
più ricorrente è quello della telefonata in arrivo: se il telefono squilla mentre si sta usando la
calcolatrice, quest’ultima sarà automaticamente ibernata e mandata in sottofondo. L’utente,
conclusa la chiamata, potrà richiamare l’Activity arrestata e riportarla in vita, riprendendo i
calcoli esattamente da dove li aveva interrotti.
Visto che le attività ibernate, in termini di risorse di calcolo, non consumano nulla, in Android
il concetto di chiusura delle attività è secondario e tenuto nascosto all’utente. Ciò, di solito,
spiazza chi è al suo primo confronto con la programmazione dei dispositivi portatili. Le Activities
di Android non dispongono di un bottone “x”, o di un tasto equivalente, con il quale è possibile
terminarle. L’utente, di conseguenza, non può chiudere un’Activity, ma può solo mandarla in
sottofondo. Questo, comunque, non significa che le Activities non muoiano mai.
Per prima cosa le Activities possono morire spontaneamente quando hanno terminato il loro
compito; inoltre, anche se il sistema non ci fornisce automaticamente un bottone “chiudi”,
possiamo sempre includerlo noi nelle nostre applicazioni. In alternativa, la distruzione delle
attività è completamente demandata al sistema. I casi in cui un’Activity può terminare sono
due:
• l’Activity è ibernata e il sistema, arbitrariamente, decide che non è più utile e perciò la
distrugge;
• il sistema è a corto di memoria e per recuperare spazio inizia a “uccidere” bruscamente le
Activities in sottofondo.
17
CAPITOLO 3. ANDROID
3.5. ACTIVITIES
Figura 3.3: Ciclo di vita di un Activity
I differenti passaggi di stato di un’attività attraversano alcuni metodi della classe Activity
che i programmatori possono ridefinire per intercettare gli eventi di nostro interesse. La Figura
3.3 illustra la sequenza di chiamate ai metodi di Activity eseguite durante i passaggi di stato
dell’attività. Entriamo nel dettaglio:
18
CAPITOLO 3. ANDROID
3.6. SVILUPPARE PER ANDROID
• protected void onCreate(android.os.Bundle savedInstanceState), richiamato non
appena l’Activity viene creata. L’argomento savedInstanceState serve per riportare un
eventuale stato dell’attività salvato in precedenza da un’altra istanza che è stata terminata.
L’argomento è null nel caso in cui l’Activity non abbia uno stato salvato;
• protected void onRestart(), richiamato per segnalare che l’Activity sta venendo riavviata dopo essere stata precedentemente arrestata;
• protected void onStart(), richiamato per segnalare che l’attività sta per diventare
visibile sullo schermo;
• protected void onResume(), richiamato per segnalare che l’attività sta per iniziare
l’interazione con l’utente;
• protected void onPause(), richiamato per segnalare che l’attività non sta più interagendo con l’utente;
• protected void onStop(), richiamato per segnalare che l’attività non è più visibile sullo
schermo;
• protected void onDestroy(), richiamato per segnalare che l’applicazione sta per essere
terminata.
3.6 Sviluppare per Android
Per realizzare applicazioni Android è necessario scegliere un ambiente di sviluppo composto
da vari componenti. Gli elementi costitutivi dell’ambiente di sviluppo scelto per realizzare la
nostra applicazione sono stati: JDK, Eclipse, Android SDK e ADT.
La prima cosa di cui uno sviluppatore android ha bisogno è il Java Development Kit (JDK),
scaricabile dal sito http://java.sun.com/javase/downloads/.Andando ad installare il JDK si installeranno automaticamente le dipendenza come Java Runtime Enviroment (JRE). Una volta
installato il JDK si deve procedere con il download dell’IDE Eclipse. Potremmo scaricare l’intero
software per Java EE, ma per la creazioni di applicazioni android è sufficiente scaricare Eclipse
per Java Developers.
Tra i tanti ambienti di sviluppo integrati esistenti, è stato scelto Eclipse in quanto è un progetto
IDE (Integrated Development Environment) open-source e ufficialmente supportato da Android.
Eclipse fornisce una serie di strumenti che aiutano lo sviluppatore nella programmazione, ad
esempio la possibilità di includere e creare librerie, JavaDoc (sistema di documentazione del
codice), suggerimenti sulle classi e metodi da utilizzare. Tramite una serie di plugin permette
di interfacciarsi con tutti i componenti che si sono resi necessari allo sviluppo dell’applicativo,
in particolare:
• Subclipse, plugin per l’accesso ed il controllo direttamente da Eclipse di SVN;
• Android Developer Tools (ADT): plugin per l’integrazione dell’Android SDK in Eclipse, per poter gestire l’emulatore Android e una serie di altri componenti (ad esempio
DDMS, Dalvik Debug Monitor Server) utili nello sviluppo di applicazioni per Android.
19
CAPITOLO 3. ANDROID
3.6.1 Sistemi di controllo versione
L’SVN (Subversion) è il sistema di “controllo versione” scelto per la nostra applicazione. Si
tratta di un sistema che gestisce la continua evoluzione del codice sorgente del progetto, tenendo
traccia di tutte le modifiche apportate e dell’evoluzione delle versioni.
Esistono vari tool in questo campo oltre a SVN (CVS, Mercurial, etc.). Le motivazioni
che spingono alla scelta di un sistema di controllo della versione sono molteplici, le principali
potrebbero però essere:
• evitare perdite di dati e di tempo per involontarie cancellazioni;
• programmazione asincrona: quando più sviluppatori fanno parte del progetto, la gestione
concorrente dello sviluppo è un fattore cruciale al fine di evitare i cosiddetti “salvataggi
fantasma”;
• evitare di dover fare dei backup quando viene realizzata una release stabile e di doverli
distribuire tra i vari componenti del gruppo di sviluppo;
• confrontare velocemente le varie versioni, visto che solitamente i sistemi di controllo della
versione utilizzano i diff, cioè un meccanismo che permette di memorizzare solo le differenze
tra un file di una versione e quello modificato.
L’utilizzo di sistemi di controllo è molto utile e consigliato, ma solitamente dev’essere accompagnato dalla possibilità di avere un repository online (accessibile tramite Internet) e non in locale
per dare la possibilità, anche a persone che si trovano a chilometri di distanza, di partecipare
allo sviluppo del codice del progetto.
Per il presente progetto si è scelto, anche per continuare sulla strada intrapresa da chi ha
dato un contributo in precedenza, di utilizzare SVN come sistema di gestione della versione e
di ospitare il codice scritto nei repository online di Ubuntu One. Ubuntu One è un servizio di
cloud sviluppato da Canonical con lo scopo di mettere a disposizione degli utenti ad esempio
la possibilità di memorizzare e condividere documenti in remoto e di sincronizzare applicazioni
utilizzando internet [29]. Il servizio di base è gratuito e limitato a 5GB di spazio libero, inoltre per
ogni persona presentata a Ubuntu One mediante il link di affiliazione di cui ogni utente dispone,
è possibile estendere lo spazio gratuito offerto di ulteriori 500Mb. Ubuntu One è disponibile
anche per utenti che utilizzano i sistemi Windows e i dispositivi Apple o Android [30].
3.6.2 I pacchetti APK
Le applicazioni Android sono distribuite sotto forma di file APK (Android Package). Al loro
interno vengono raccolti gli eseguibili in formato DEX (Dalvik EXecutable), il bytecode eseguito
dalla Dalvin Virtual Machine, diverso dal bytecode stardard di Java.
Nel file APK sono inoltre contenute le eventuali risorse associate e una serie di descrittori che
delineano il contenuto del pacchetto. In particolare, nel descrittore noto come manifest vengono
dichiarate le attività, i servizi, i provider e i receiver compresi nel pacchetto, in modo che il
sistema possa agganciarli e azionarli correttamente [28].
20
CAPITOLO 3. ANDROID
Figura 3.4: File AndroidManifest.xml
All’interno del file AndroidManifest.xml si devono dichiarare i componenti del software. Eclipse, all’atto di creazione del progetto, ha già eseguito su di esso alcune configurazioni iniziali. Ad
esempio (nella Figura 3.4) ha registrato l’Activity CiaoMondoAndroidActivity, ha specificato
le proprietà generali dell’applicazione e ha anche generato e impostato un’icona per il nostro
programma (res/drawable/icon.png). Ovviamente queste scelte possono essere alterate, e nuovi componenti possono essere aggiunti al progetto. Si deve prestare particolare attenzione al
numero di versione relativo all’SDK indicato nel file. Molto spesso infatti, un’applicazione può
dare problemi in fase di compilazione se non si è appropriatamente modificato questo particolare
parametro. Con lo speciale editor visuale messo a disposizione da Eclipse (Figura 3.5), risulterà
tutto molto semplice: è sufficiente fare un po’ di pratica e approfondire di volta in volta l’aspetto
d’interesse.
Una volta che il lavoro è stato completato, è possibile esportare il file APK da distribuire
ai possessori di un sistema Android. Prima di distribuire in giro il pacchetto è però necessario
apporre su di esso una firma digitale. In caso contrario, Android non potrà installarne i contenuti.
Questo è l’unico vincolo imposto dal sistema. Il fatto che un pacchetto debba essere firmato
non deve preoccupare lo sviluppatore: non è necessario che una certification authority riconosca
la chiave utilizzata per la firma. Di conseguenza è possibile firmare un pacchetto APK anche
servendosi di un certificato “fatto in casa”. In parole semplici: non bisogna pagare nessuno
perché i nostri software siano autorizzati, possiamo fare tutto da noi.
Le chiavi digitali solitamente sono raccolte e conservate all’interno di un keystore che è possibile
creare e riempire in Eclipse: ancora una volta, è questione di qualche clic. Quando il pacchetto
APK è stato generato e firmato è pronto per essere installato su un qualsiasi dispositivo Android
supportato.
21
CAPITOLO 3. ANDROID
Figura 3.5: Editor messo a disposizione da Eclipse per il file AndroidManifest.xml
22
Capitolo 4
Il riconoscimento vocale
Le tecnologie di speech-processing (Figura 4.1) sono state una costante area di ricerca per
più di 50 anni. Lo scopo finale della ricerca vocale è costruire un sistema di mimica delle
capacità cognitive umane, generando e codificando un dialogo per modalità d’interazione di tipo
uomo-uomo e uomo-macchina [31].
Il primo passo da compiere nella progettazione di un’interfaccia basata sul parlato concerne
l’Elaborazione del Linguaggio Naturale (NLP, Natural Language Processing). Per poter instaurare una comunicazione bidirezionale si rendono necessarie tecniche di Comprensione del
Linguaggio Naturale (NLU, Natural Language Understanding) e di Generazione di Linguaggio
Naturale (NLG, Natural Language Generation). In particolare, il sistema deve essere dotato
della capacità di comprendere comandi vocali per mezzo di tecniche di Riconoscimento del Parlato (Speech Recognition) per tradurre la frase parlata nella relativa rappresentazione testuale
interna. Analogamente, sarà necessario fare uso della Generazione di Parlato (Speech Synthesis)
per tradurre in voce le frasi che la macchina dovrà rivolgere all’utente.
A livello di software, l’operatore interagisce sostanzialmente con l’applicazione attraverso i
sistemi ASR (Automatic Speech Recognition), e TTS (Text-To-Speech), inoltre deve essere
disponibile anche la possibilità di registrare e riprodurre memo audio. Sproat conferma [32] che
in questi ultimi anni, il riconoscimento vocale automatico (ASR) e la sintesi vocale (TTS) sono
diventate tecnologie sufficientemente mature: esse infatti, costituicoscno modalità efficaci sia in
telefonia, sia in altre piattaforme multimodali [33].
I miglioramenti della scorsa decade nel campo delle tecniche di elaborazione del linguaggio
hanno permesso di realizzare interfacce vocali abilitate che rappresentano un modo più naturale
di interagire per operatori umani e consentono una vera e propria risorsa per i casi in cui non si
dispone di abilità visiva o manuale [34].
Figura 4.1: Sistema di riconoscimento vocale
23
CAPITOLO 4. IL RICONOSCIMENTO VOCALE
4.1. ASR
4.1 ASR
Il riconoscimento automatico del parlato, o ASR, è la parte dell’interfaccia vocale che mira
a trascrivere in testo quanto è stato pronunciato dall’utente. Un sistema ASR riconosce frasi
complete o comandi derivanti da particolari combinazioni di parole contenute in un vocabolario.
L’insieme di tutte le combinazioni di parole che un sistema ASR può riconoscere compone la
grammatica. Migliore è la grammatica, migliore sarà il riconoscimento: le parti del discorso vengono riconosciute quasi perfettamente e si hanno meno probabilità di errore. Generalmente, un
sistema di dialogo fa uso di diverse grammatiche a seconda dell’argomento del dialogo trattato.
Pertanto, il sistema deve essere in grado di gestire diverse grammatiche attive contemporaneamente e di passare da una grammatica ad un’altra. L’argomento riguardante le grammatiche
sarà meglio esposto nel Sottoparagrafo 5.4.3.
4.1.1 Distributed Speech Recognition (DSR)
Integrare questa tecnologia in un’architettura di rete wireless impone diversi vincoli tecnici
che giustificano la necessità di distribuire i processi ASR su entrambi i terminali mobili e fissi,
ottenendo così un sistema di Distributed Speech Recognition (DSR). La distribuzione dei processi
riguardanti l’ASR deve tenere conto di diversi argomenti d’interesse:
• Le capacità di calcolo e di memoria dei dispositivi mobili possono essere molto limitati
mentre alcune parti di un sistema di riconoscimento vocale richiedono un grande utilizzo
di CPU. Questo molto spesso limita la parte di processing raggiunta sul terminale mobile.
• Nell’ambito di una connessione wireless, la banda disponibile risulta essere un criterio
importante nella scelta delle tecnologie implementate.
• La manutenzione delle applicazioni (database, aggiornamenti dei modelli, etc.) è un altro
aspetto che dovrebbe essere preso in considerazione. Infatti, è preferibile evitare, per quanto possibile, le operazioni di manutenzione sui terminali mobili che potrebbero aumentare
la complessità del sistema.
Questi problemi sono stati ampiamente discussi negli ultimi anni all’interno dalla ETSI (European Telecomunication Standard Institute) [35]. Il progetto internazionale AURORA [36] è
stato creato al fine di proporre soluzioni e infine, di stabilire uno standard internazionale per il
DSR.
Secondo l’ETSI, il riconoscimento vocale può essere diviso approssimativamente in quattro
fasi:
1. rilevazione di attività vocale (VAD), che isola il segnale vocale utile dal flusso di
segnale acquisito dal microfono;
2. analisi acustica, che mira ad estrarre dal segnale parlato una rappresentazione pertinente
e non ridondante del suo contenuto acustico;
3. modellazione acustica, che mira a classificare le caratteristiche acustiche in unità acustiche dipendenti dal linguaggio;
24
4.2. TTS
4. decodifica, che integra il vocabolario e la grammatica in un sistema basato su Hidden
Markov Model (HMM) per ottenere le possibili sequenze di parole [37]. 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. Pur con delle semplificazioni,
questa tecnica fornisce una buona modellazione del fenomeno del parlato ed ha il vantaggio
di poter essere applicata gerarchicamente a più livelli.
Lo standard ETSI fa eseguire il rilevamento di attività vocale e l’analisi acustica sul dispositivo
mobile, mentre la modellazione acustica e la decodifica vengono realizzati sul terminale fisso.
Questa soluzione di DSR soddisfa tutti i vincoli sopra elencati. Infatti, l’analisi acustica richiede
memoria fissa molto limitata e carichi di lavoro della CPU. La codifica delle caratteristiche
acustiche è efficiente e non ha quasi alcun impatto sulle prestazioni di riconoscimento (lo standard
ETSI suggerisce un bit rate di 4,8 kbit/s). Infine, l’estrazione di caratteristiche acustiche non
richiede dati esterni come banche dati o modelli ed è indipendente dalla lingua dell’applicazione
in modo che la manutenzione del software incorporato possa essere ridotta al minimo.
Non si devono poi trascurare i diversi parametri esterni (conversazione di sottofondo, rumori
ambientali, traffico, etc.) o i diversi disturbi interni insiti nella natura del dispositivo (bassa
qualità del microfono incorporato) che possono alterare i sistemi di riconoscimento vocale. Tecniche di riduzione del rumore devono quindi, essere integrate in uno dei vari livelli del processo di
riconoscimento; può per esempio, essere inserita nell’analisi acustica come suggerisce lo standard
ETSI.
4.2 TTS
La sintesi vocale (in inglese speech synthesis) è la tecnica per la riproduzione artificiale della
voce umana. Un sistema usato per questo scopo è detto sintetizzatore vocale e può essere realizzato tramite software o via hardware. I sistemi di sintesi vocale sono noti anche come sistemi
Text-To-Speech (TTS) per la loro possibilità di convertire il testo in parlato (letteralmente “dal
testo al parlato”). Un sistema Text-To-Speech mira quindi a trascrivere i testi leggibili in segnali
sonori vocali.
In molti casi, i messaggi vocali (informazioni, domande, etc.) possono essere inviati all’utente
con file audio preregistrati. Questa tecnica sembra semplice ma in realtà, è molto dispendiosa a
causa dell’obbligo di pre-registrazione di tutte le richieste audio. E’ preferibile quindi che le richieste audio siano generate automaticamente dal testo di ogni prompt, evitando la registrazione
audio di tutti i possibili output vocali.
La sintesi vocale è permessa grazie al Natural Language Processing (NLP) che è il processo
di trattamento automatico delle informazioni scritte o parlate nel linguaggio umano o naturale,
mediante un calcolatore elettronico. Questo processo è reso particolarmente difficile e complesso
a causa delle caratteristiche intrinseche di ambiguità del linguaggio umano. Per questo motivo
il processo di elaborazione viene suddiviso in fasi diverse e tuttavia simili a quelle che si possono
riscontrare nel processo di elaborazione di un linguaggio di programmazione:
• analisi lessicale, cioè la scomposizione di un’espressione linguistica in token (blocchi di
testo categorizzato, costituiti da caratteri non divisibili; in questo caso le parole);
25
4.3. GESTIONE DEI DIALOGHI
• analisi grammaticale, cioè l’associazione delle parti del discorso a ciascuna parola del
testo;
• analisi sintattica, cioè l’arrangiamento dei token in una struttura sintattica (ad albero:
parse tree);
• analisi semantica, cioè l’assegnazione di un significato alla struttura sintattica e, di
conseguenza, all’espressione linguistica.
L’NLP richiede ingenti risorse di memoria e CPU, in quanto una frase e la relativa trascrizione
fonetica costituiscono un elemento molto consistente. Tuttavia, la maggior parte delle frasi
rimane invariata per giorni e giorni di utilizzo dell’applicazione. Quindi, il recupero di trascrizioni
da frasi precedentemente usate, utilizzando un meccanismo di cache prima di inviare una frase
per il processo di NLP, riduce drasticamente il fabbisogno di risorse.
Sistemi TTS necessitano di database [37, 38]. La dimensione di tali banche dati, tipicamente
circa 30 Mb, non è compatibile con le risorse del dispositivo mobile. A causa delle limitate
risorse incorporate e del tasso di trasmissione della rete wireless, l’implementazione del TTS è
divisa in due parti.
La parte fissa del TTS è l’NLP, che mira a tradurre i testi leggibili in trascrizioni fonetiche.
Nella trascrizione fonetica sono comprese le caratteristiche prosodiche: l’intonazione, il ritmo,
la durata (isocronia) e l’accento del linguaggio parlato. La parte incorporata (“mobile”) è il
sintetizzatore vocale vero e proprio, che mira a tradurre trascrizioni fonetiche in streaming
audio. Il bit-rate richiesto per trasmettere trascrizione fonetica dall’NLP al sintetizzatore vocale
è inferiore a 1,5 kbit/s e quindi molto basso.
4.3 Gestione dei dialoghi
Le applicazioni di abilitazione vocale non sono caratterizzate solo dal riconoscimento vocale
e dalla sintesi vocale. Sono infatti, necessari elementi di gestione dell’interazione per arrivare
ad ottenere una conversaziona vocale ben strutturata. Un sistema di dialogo parlato può essere
formalizzato come uno schema a stati finiti, che passi da uno stato all’altro in base ai risultati
delle azioni che ogni stato svolge nel suo ambiente. Nel nostro caso, il sistema di dialogo si
stabilisce tra l’operatore umano e l’Information Management System (IMS).
Tutte le comunicazioni con l’IMS vengono effettuate tramite il server di documenti di dialogo
che può supportare noti linguaggi server side (PHP, Perl CGI, script batch, etc.). Ad esempio, è
possibile accedere ad un sistema di informazione dei clienti IMS basato su un sistema di database
relazionale tramite le query SQL. Il termine query viene utilizzato per indicare l’interrogazione
ad un database, finalizzata a compiere operazioni sui dati (selezione, inserimento, cancellazione
dati, etc.). Solitamente una query viene interpretata dal linguaggio SQL (Structured Query
Language) per renderla più comprensibile al DBMS (DataBase Management System). Queste
query possono essere parametrizzate anche con i risultati di riconoscimento vocale, inoltre i
risultati della query possono essere inclusi in prompt audio.
Quindi la progettazione di una strategia di dialogo ottimale può essere vista come la creazione
di una mappatura che comprende gli spazi di stato del dialogo e il gruppo di prompt possibili.
26
4.4. VOICEXML
La progettazione di una struttura di dialogo efficiente, composta da una sequenza appropriata
di interazioni che permetta il raggiungimento dell’obiettivo dell’operatore, rimane un compito
abbastanza complesso da realizzare ed è oggetto di molte ricerche degli ultimi anni [39]. Il
comportamento dell’interfaccia vocale è comunque ampiamente descritto negli script VXML
(Paragrafo 4.4) e PHP utilizzati per strutturare il dialogo.
4.4 VoiceXML
VoiceXML (Voice eXtensible Markup Language) conosciuto anche come VXML, è il linguaggio derivato dall’XML e utilizzato per “gestire” applicazioni vocali. XML è un linguaggio che
permette di creare e gestire documenti e dati sul web mediante la creazione di “vocabolari arbitrari” formalmente definiti come “schema”. Un “XML schema” può definire un documento
particolare, un altro un’equazione matematica e così via. VoiceXML non è altro che un “XML
schema” i cui scopi sono quelli di rendere i contenuti e le informazioni Internet consultabili ed
accessibili per mezzo di input/output vocali. In pratica VoiceXML permette di gestire un vero
e proprio dialogo vocale tra utente e sistema, senza la necessità di intermediazioni visive o di
puntatori.
Una delle prime società che si è interessata allo sviluppo di tali interfacce è stata IBM che
qualche anno fa sviluppò un apposito linguaggio che chiamò SpeechML. Quasi parallelamente
anche AT&T e Lucent Technologies definirono dei propri linguaggi denominati con lo stesso
nome PML (Phone Markup Language), anche se diversi tra di loro. Motorola sviluppò nello
stesso periodo un ulteriore metalinguaggio che denominò VoxML.
Nel 1998, il W3C ha ospitato una conferenza sui browser vocali alla quale hanno partecipato
le compagnie sopracitate e molte altre, ognuna delle quali con un proprio linguaggio di Markup
(ad esempio TalkML di HP e VoiceHTML di PipeBeach). In questa occasione è stato formato
il VoiceXML Forum per iniziativa di AT&T, Lucent Technologies, IBM e Motorola. Lo scopo
del VoiceXML Forum è stato quello di definire un linguaggio standard di progettazione del
dialogo, utilizzabile dagli sviluppatori per creare applicazioni vocali. E’ stato scelto XML come
linguaggio di markup base perchè era chiaro a tutti che quasta era la direzione verso la quale si
stava muovendo la tecnologia.
Sempre per iniziativa di AT&T, IBM, Lucent e Motorola, il VoiceXML Forum ha rilasciato al
pubblico le specifiche (standardizzate dal W3C) VoiceXML 0.9 (17 Agosto 1999), la successiva
1.0 (07 Marzo 2000) e le piu’ recenti 2.0 del 24 Aprile 2002 e 3.0 del 16 Dicembre 2010 [40].
Per una trattazione più completa delle specifiche dello standard W3C si rimanda il lettore al
Paragrafo 5.4. Per ora ci limiteremo a dare un esempio di documento VoiceXML mostrato in
Figura 4.2.
27
4.4. VOICEXML
Figura 4.2: Esempio documento VoiceXML
L’elemento di livello principale è <vxml>, che è fondamentalmente un contenitore per le finestre
di dialogo. Ci sono due tipi di finestre di dialogo: form e menu. La tag form rappresenta
l’informazione e raccoglie l’input; la tag menu offre varie opzioni possibili tra le quali scegliere.
Questo esempio ha un unico modulo, contenente una tag block che sintetizza e presenta "Ciao
Mondo!" all’utente. Dal momento che la form nell’esempio non ha un dialogo successivo, la
conversazione finisce.
Al fine di comprendere il funzionamento di una applicazione vocale che utilizza documenti
VoiceXML, ci aiuteremo facendo dei paragoni con le ben più note pagine Internet. Un browser VoiceXML è modellato infatti allo stesso modo di un browser internet che accede alle
informazioni tramite protocollo HTTP (HyperText Transfer Protocol) [41].
Possiamo dire che l’architettura tipica di una applicazione web comprende il server che ospita
il sito e, in funzione dell’architettura progettata, un application server che gestisce i database e
il core dell’ applicazione. Gli utenti di un sito web (a sinistra nella Figura 4.3) che accedendo
attraverso il loro browser all’applicazione, navigheranno il sito inviando richieste all’applicazione
attraverso i metodi GET o POST del protocollo HTTP.
L’applicazione risponderà inviando, sempre attraverso lo stesso protocollo HTTP, una pagina
di risposta o eseguendo una determinata operazione.
Supponiamo per semplicità che la nostra applicazione sia una webmail, ovvero una serie di
pagine web che permetteranno all’utente di interfacciarsi con la propria casella di posta.
Il primo strato della “comunicazione”, che potremmo definire superficiale, viene spesso chiamato “presentation layer” (strato di presentazione), e si preoccupa unicamente del modo in cui
vengono inviati i dati all’utente, alla loro rappresentazione e formattazione, ed è connesso ad uno
strato più interno, detto “application layer” (strato dell’applicazione). Questo secondo strato è
quello che si farà carico dell’autenticazione utente, della lettura delle mail dal server di posta e,
più genericamente, di tutte le logiche applicative.
Questa architettura, che rappresenta un grado di complessità medio, nel momento in cui
decidiamo di rendere la nostra applicazione vocale, sarà mantenuta inalterata e si creerà un
nuovo layer di presentazione dei dati: l’interfaccia vocale.
28
4.4. VOICEXML
Figura 4.3: Architettura di un’applicazione vocale
Una delle principali peculiarità del linguaggio VoiceXML è quella di essere costruito per sviluppare applicazioni voice-enabled orientate al Web: si possono produrre pagine VoiceXML anche
attraverso linguaggi server side (ASP, ASP.NET, JSP, PHP, ecc.).
Immaginiamo che l’utente si connetta tramite il telefono al Voice Gateway, quindi senza dover
ricorrere ad un particolare browser o plugin (linea blu in Figura 4.3). Il Voice Gateway è,
fondamentalmente, un server con i seguenti requisiti:
• la capacità di elaborare file VoiceXML: ovvero ha un intreprete VoiceXML in grado di
accettare più chiamate contemporaneamente. Per tornare al nostro parallelo con le tipiche
pagine internet, questo è il nostro web-server;
• uno o più motori di riconoscimento vocale (ASR: Automatic Speech Recognition) che
servono per ascoltare gli input degli utenti;
• uno o più motori di sintesi vocale (TTS: Text-To-Speech) che vengono utilizzati per
produrre un output vocale da un testo sintetizzato;
• una scheda telefonica per accettare flussi telefonici in ingresso. Ovviamente al posto della
scheda telefonica si può veicolare la telefonata attraverso VOIP o SIP.
Ecco perciò cosa accade quando un utente si connette ad una applicazione vocale:
29
4.5. JVOICEXML
• l’utente compone il numero collegato al Voice Gateway;
• attaverso la linea pubblica telefonica (PSTN) la voce dell’utente raggiunge il Gateway;
• il Gateway interpreta le istruzioni contenute nel file VoiceXML, ricevendo ed interpretando
gli input dell’utente (ASR) e producendo un messaggio vocale attraverso la sintesi (TTS);
• il Voice Gateway dialoga con il web server attraverso il protocollo HTTP e invia dati
all’“application layer”;
• il server web riceve le richieste dal Voice Gateway
• il server web rende disponibili i file VoiceXML per la loro interpretazione.
Semplificando ulteriormente, possiamo affermare che il Voice Gateway si preoccupa soltanto di
leggere il contenuto dei file VoiceXML inviati dal server Web e di raccogliere gli input dell’utente e che una applicazione vocale rappresenta un ulteriore “presentation layer” della nostra
applicazione ed una sua naturale verticalizzazione.
Tornando alla nostra applicazione di web mail, qualora volessimo renderla accessibile via voce
sarà sufficiente dotarsi di un Voice Gateway, connetterlo alla linea telefonica e creare delle pagine
di input e di output vocali. A questo punto il nostro utente potrà agevolmente accedere alla sua
casella di posta attraverso qualiasi telefono.
4.5 JVoiceXML
Come abbiamo appena visto nel Paragrafo 4.4 il Voice Gateway possiede al suo interno un
interprete VoiceXML capace di “dare un senso” al contenuto dei file .vxml. La maggior parte
degli interpreti presenti sul mercato attualmente sono a pagamento e sono forniti da famose compagnie sviluppatrici di software come Voxeo, ScanSoft, SandCherry e Holly Connects. Voxeo,
in particolare ha reso anche disponibili applicazioni che lavorano tramite Voice Over Internet
Protocol (VoIP). Supporta quindi, le chiamate utilizzando il software VoIP Skype. Altri fornitori di piattaforme tuttavia, offrono anche interpreti VoiceXML gratuiti come Elvira (Masaryk
University, Brno, Repubblica Ceca), OpenVXI (Carnegie Melon University, Pittsburgh, USA),
publicVoiceXML (Public Voice Lab, Vienna, Austria) e JVoiceXML (TU Darmstadt, Germania) [42]. Questi programmi, essendo per lo più sviluppati in ambito accademico, spesso non
hanno necessariamente la pretesa di essere completi. Inoltre nessuno di essi è installabile in un
dispositivo mobile, ma necessitano tutti di un hardware specifico: il PC.
In questo Paragrafo si esaminerà in particolare l’interprete JVoiceXML per specifiche VoiceXML 2.0, che ha caratterizzato interamente questo lavoro, in quanto scritto in Java ed
adattabile ad un porting per il sistema operativo Android.
Basando il nostro studio sulla guida di JVoiceXML scritta dallo stesso sviluppatore Dr. Dirk
Schnelle-Walka [43], possiamo affermare che la principale novità nel rilascio di questo software
rispetto alle precedenti versioni di interpreti open source è l’introduzione di una struttura modulare nell’implementazione. Questa struttura infatti riflette in tutto e per tutto l’architettura
del funzionamento di un’applicazione vocale (Figura 4.4).
30
4.5. JVOICEXML
Vi sono principalmente due modi per far interagire i client con JVoiceXML, ovvero utilizzando
JNDI (Java Naming and Directory Interface) o utilizzando il CallMananger. La maggior parte
dei client utilizzano il demo JNDI per accedere al JVoiceXML, connettendosi a un JVoice-Server
XML, ma JVoiceXML permette anche di avere tutto il funzionamento sul lato server, con l’aiuto
di un CallManager.
Figura 4.4: Architettura di base di JVoiceXML
L’architettura di base del JVoiceXML consiste in tre componenti principali:
• document server;
• VoiceXML interpreter context che include il VoiceXML interpreter;
• implementation platform.
Il core (pacchetto principale) org.jvoicexml (Figura 4.5) contiene le interfacce e le classi che
servono come punto di ingresso per l’interpretazione VoiceXML. Queste classi e interfacce sono
organizzate in diversi packages tipici del linguaggio Java. Oltre ai packages corrispondenti ai tre
componenti principali citati sopra avremo anche:
• application, rappresenta le applicazioni;
• config, gestisce i problemi di configurazione;
• logging, gestisce i problemi di registrazione;
31
4.5. JVOICEXML
• xml, consente l’analisi e la creazione di documenti VoiceXML;
• event, definisce gli eventi che possono essere generati da tutti gli altri componenti e che
sono individuati dal componente principale VoiceXML Interpreter Context;
• jndi, abilita l’accesso remoto all’interprete.
Figura 4.5: Core di JVoiceXML
4.5.1 Configurazione delle implementazioni
All’interno dei vari packages troviamo quindi interfacce e classi organizzate in modo modulare.
In particolare si nota subito che i file sono disposti a coppie con nomi del tipo ImplementationPlatform.java e JVoiceXmlImplementationPlatform.java o anche InitializationTagStrategyFactory.java e JVoiceXmlInitializationTagStrategyFactory.java. In queste coppie, il primo file (Nome.java) rappresenta l’interfaccia e il secondo file (JVoiceXmlNome.java) rappresenta la classe
che la implementa.
Questa divisione di file in coppie consente ad uno sviluppatore di implementare una qualsiasi
interfaccia con una classe personalizzata. JVoiceXML permette inoltre di far caricare al programma, in fase di avvio, l’implementazione personale al posto di quella di defoult propria di
JVoiceXML. Per istruire il programma su quali implementazioni caricare per ciascun modulo si
utilizzano i file di configurazione, contenuti all’interno del package org.jvoicexml.config.
4.5.2 Parsing dei documenti VoiceXML
Il parsing o analisi sintattica è il processo atto ad analizzare uno stream continuo in input
(letto dal file VoiceXML nel nostro caso), in modo da determinare la sua struttura grammaticale
grazie ad una data grammatica formale. Un parser è un programma che esegue questo compito.
Una volta effettuato il parsing si ottiene una mappatura dell’intero documento .vxml a forma di
32
4.5. JVOICEXML
albero sintattico. L’allbero è costituito da nodi e sottonodi che costruiscono la struttura delle
tag e degli attributi (Capitolo 5) contenuti nel file VoiceXML.
La classe che rappresenta un documento VoiceXml all’interno di JvoiceXml, è VoiceXmlDocument, sottoclasse di XmlDocument che a sua volta implementa l’interfaccia Document (package
esterno org.w3c.dom).
Figura 4.6: Costruttore VoiceXmlDocument
Al termine della chiamata al costruttore, viene effettuato il parsing (mediante la chiamata
a classi appartenenti al package esterno javax.xml.parsers) del documento VoiceXML associato
all’oggetto source (Figura 4.6). In questo modo quindi l’oggetto Document viene inizializzato
con il documento “parsato”: ogni nodo ha un nome, degli attributi, dei nodi figli, etc..
E’ importante specificare che ogni nodo contenuto in VoiceXmlDocument espone l’interfaccia
VoiceXmlNode, che è un estensione dell’interfaccia XmlNode, a sua volta estensione di Node
(package esterno org.w3c.dom). Inoltre bisogna fare un’altra considerazione: l’interfaccia Document rappresenta un documento VoiceXML visto come insieme di generici nodi XML e non
VoiceXML. Essendo VoiceXmlDocument discendente da Document, apparirà anch’esso formato
da generici nodi XML.
Diventa quindi necessario discutere di altri due elementi degni di nota: l’interfaccia XmlNodeFactory e l’interfaccia VoiceXmlNodeFactory.
• XmlNodeFactory si occupa di convertire un’istanza dell’interfaccia Node in un’istanza di
XmlNode.
• VoiceXmlNodeFactory si occupa di convertire un’istanza dell’interfaccia Node in un’istanza
di VoiceXmlNode
4.5.3 Processing dei documenti VoiceXML
Il processing di un documento VoiceXml rappresentato da un oggetto VoiceXmlDocument
impegna molte classi e richiede numerose elaborazioni diverse. Per questo motivo in questo
Paragrafo accenneremo solo ai passaggi fondamentali e agli elementi principali che interessano
la fase di esecuzione dei documenti VoiceXML. Rimandiamo alla lettura della tesi di laurea
“Human-Computer vocal interaction: porting di JVoiceXML su Android” di Riccardo Cecchi
per una trattazione sulle classi e i metodi protagonisti della fase di processing.
Il primo passo del processing consiste nell’estrazione dei dialoghi (corrispondenti ad un nodo
form o ad un nodo menu) contenuti all’interno dell’oggetto VoiceXmlDocument. A questo punto
i dialoghi vengono processati uno dopo l’altro dalla classe FormInterpretationAlgorithm, dopo
essere stati convertiti in oggetti FormIntem.
33
4.5. JVOICEXML
La classe FormInterpretationAlgorithm è un’implementazione dell’algoritmo ricorsivo FIA
chiaramente descritto nel sito ufficiale del W3C [40] e di cui riportiamo il funzionamento. Il
main loop del FIA si compone di tre fasi:
• la fase di select, nella quale l’ultimo oggetto FormItem ancora non processato viene
selezionato per essere visitato;
• la fase di collect, nella quale l’oggetto FormItem selezionato nella precedente fase di select
viene visitato. Vengono eseguiti i tag, fin quando non si richiede un input dall’utente. In tal
caso vengono abilitate le grammatiche appropriate e l’algoritmo rimane in attesa dell’input
o di un evento (richiesta di aiuto o mancato input);
• la fase di process, nella quale viene convalidato e processato l’input ricevuto dall’utente.
Per quanto riguarda gli eventi, vengono fatti processare dall’EventHandler appropriato.
Se nella fase di select o di collect si verifica un evento, il FIA passa forzatamente alla fase di
process per poter gestire l’evento.
4.5.4 Interpreter e ImplementationPlatform
Entrambe le classi VoiceXmlDocument (che rappresenta il documento VoiceXML) e FormInterpretationAlgorithm sono incapsulate all’interno dell’interprete che costituisce l’elemento più
importante di JVoiceXML.
Particolare importanza riveste anche l’InterpreterContext, già citato all’inizio del Paragrafo.
Le specifiche del W3C infatti, richiedono la presenza di un contesto nel quale far eseguire l’interprete. In JVoiceXML il contesto è rappresentato dalla classe VoiceXmlInterpreterContext.
Il concetto è che l’interprete non viene utilizzato direttamente, bensì per mezzo dell’interfaccia
del context. Inoltre il contesto mantiene in memoria tutte le informazioni necessarie per l’interpretazione come ad esempio le grammatiche attive e il riferimento all’ImplementationPlatform
che ha il compito di gestire l’interazione con l’utente. Il riferimento all’ImplementationPlatform
avviene per mezzo dell’oggetto JVoiceXmlSession che implementa l’interfaccia Session. JVoiceXML prevede che il contesto venga eseguito all’interno di un thread Session; nel nostro porting
quest’architettura verrà riadattata ad un contesto non più dipendente dalla sessione.
Per quanto riguarda l’ImplementationPlatform possiamo dire che permette l’accesso alle risorse di cui l’applicazione VoiceXML ha bisogno:
• sintesi vocale (TTS) attraverso l’interfaccia SystemOutput;
• riconoscimento vocale (ASR) attraverso l’interfaccia UserInput;
• telefonia (PSTN) attraverso l’interfaccia CallControl.
La Figura 4.7 mostra come è articolata la struttura che collega l’ImplementationPlatform alle
risorse sopra citate.
34
Figura 4.7: ImplementationPlatform
35
4.5. JVOICEXML
Capitolo 5
Il lavoro svolto
Il lavoro di tirocinio svolto dall’autrice di questa tesi assieme agli studenti Riccardo Cecchi,
Eros Federici e Federico Fioravanti ha portato alla realizzazione di un software che costituisce
un affidabile interprete VoiceXML per il sistema operativo Android. Nei primi tre Paragrafi
di questo Capitolo verranno descritti i principali problemi incontrati nel corso del lavoro e le
strategie adottate per risolverli. Saranno quindi esposte le principali fasi che hanno caratterizzato
il processo di sviluppo dell’applicazione, sulla base dell’usuale modello a cascata (Figura 5.1).
La parte finale del Capitolo si concentrerà invece sulle specifiche dello standard W3C.
Figura 5.1: Analisi dei requisiti: modello a cascata
37
CAPITOLO 5. IL LAVORO SVOLTO
5.1. ANALISI DEI REQUISITI
5.1 Analisi dei requisiti
In ingegneria del software, l’analisi dei requisiti (talvolta detta semplicemente analisi o requirements) è un’attività preliminare allo sviluppo di un sistema software, il cui scopo è quello di
definire le funzionalità che il nuovo prodotto deve offrire, ovvero i requisiti che devono essere
soddisfatti dal software sviluppato [44]. Nel tradizionale modello a cascata (Figura 5.1), l’analisi dei requisiti è la prima fase del processo di sviluppo, e deve concludersi con la stesura di
una dettagliata specifica dei requisiti che descrive le funzionalità del nuovo software nella loro
interezza; tale specifica guida le fasi successive di sviluppo, che complessivamente sono volte a
realizzare quanto previsto da tale specifica [45].
Il nostro lavoro nasce dalla volontà del Dipartimento di Ingegneria dell’Informazione dell’Università Politecnica delle Marche di implementare un prototipo di applicazione che si occupi
del servizio di portineria. Requisito fondamentale del sistema doveva essere quindi la possibilità di interagire vocalmente con i visitatori (studenti o altri utenti). Si è supposto inoltre che
l’applicazione dovesse avere a disposizione le seguenti informazioni:
• Orari di ricevimento degli strutturati (professori e ricercatori) e dei non strutturati (dottorandi, assegnisti, professori a contratto);
• Presenza (o non presenza) in ufficio al momento attuale;
• Orari di lezione dei docenti;
• Posizione dei singoli uffici, dei laboratori, della biblioteca, etc.
Tali informazioni avrebbero dovuto essere memorizzate in un database, ma per quanto riguarda
la fase di progettazione dell’applicazione abbiamo deciso di fornirle in maniera statica; tenendo
comunque conto che una successiva versione dell’applicazione farà accesso ai dati presenti su
un database. Le informazioni di cui sopra saranno utilizzate nel corso dell’interazione vocale
con i visitatori del dipartimento. Una interazione vocale inizierà con dei convenevoli da parte
dell’applicazione; in seguito ci si aspetta una domanda da parte del visitatore, cui l’applicazione
dovrà fornire risposta. Il ciclo domanda-risposta potrà ripetersi una o più volte, fino a terminare
con dei saluti da parte dell’applicazione. In pratica l’applicazione mimerà le funzioni tipiche di
un portiere umano, come descritto nella tesi di laurea «Human-Computer vocal interaction: un
portiere robotico» di Eros Federici. Per semplificare la realizzazione del prototipo, si è supposto
che l’applicazione rispondesse soltanto a domande relative a:
• Posizione degli uffici a quota 165, corridoio ex DIIGA, dal laboratorio di Intelligenza
Artificiale fino all’ufficio di Domenico Potena;
• Presenza o meno in ufficio della persona cercata, eventualmente specificando se la persona
cercata si trova in quel momento a lezione;
• Orari di ricevimento della persona cercata;
Naturalmente, le domande che il visitatore rivolgerà all’applicazione non avranno una struttura predefinita, ma dovranno riguardare uno degli argomenti sopra indicati. In caso contrario
l’applicazione risponderà con una frase standard che indicherà la non disponibilità di quella
38
5.2. PROGETTAZIONE
informazione. Si prevede, inoltre, la possibilità per il visitatore di lasciare un messaggio per la
persona cercata.
Un esempio di conversazione, fornitaci dal Dott. Andrea Claudi, è il seguente (V-visitatore,
A-applicazione):
V – si ferma per almeno tre secondi di fronte al sistema, che ne rileva la presenza
A – Buongiorno. Posso aiutarla?
V – Ehm, non so, penso di sì.
A – Domandi pure.
V – Vorrei sapere dov’è l’ufficio del prof. Cucchiarelli.
A – Segua il corridoio, poi giri a destra. Lo troverà alla sua sinistra, è la quarta porta lungo
il corridoio.
V – Grazie. (pausa) Ah, sa mica se è in ufficio?
A – Purtroppo no, è a lezione di Linguaggi di Programmazione. Vuole lasciare un messaggio?
V – No, grazie. Sa quando finisce la lezione?
A – Purtroppo non ho questa informazione.
V – Allora quando posso trovarlo in ufficio?
A – Non ho capito. Può ripetere?
V – Quando posso trovare in ufficio il professor Cucchiarelli?
A – Il professor Cucchiarelli ha ricevimento il lunedì dalle 14:30 alle 17:30.
V – Grazie mille.
A – Prego. Buona giornata.
Era richiesto infine che l’applicazione fosse implementata su Android, nel rispetto degli standard relativi al VoiceXML definiti dal W3C.
5.2 Progettazione
La seconda fase del processo di sviluppo del software riguarda la progettazione (talvolta detta
anche progetto o disegno, dall’inglese design). Sulla base della specifica dei requisiti prodotta
dall’analisi, il progetto definisce come tali requisiti saranno soddisfatti entrando nel merito della
struttura che dovrà essere data al sistema software da realizzare.
La progettazione è una fase distinta dalla programmazione o codifica, che corrisponde alla
traduzione in un particolare linguaggio di programmazione delle decisioni prese in sede di progettazione, cioè dunque la fase implementativa. Talvolta però, a causa della natura "impalpabile"
del software e a seconda degli strumenti che si utilizzano nel processo, il confine fra progettazione
e codifica può essere anche praticamente impossibile da identificare.
Un linguaggio grafico molto utilizzato per la progettazione di software è l’UML (Unified Modeling Language). Questo linguaggio di modellazione permette di realizzare diagrammi basati
sul paradigma object-oriented, contenenti elementi grafici e testuali formali che rispettano una
semantica precisa e rigorosa. L’UML è stato progettato con l’obiettivo esplicito di facilitare il
supporto software alla costruzione di modelli e l’integrazione di questo supporto con gli ambienti
integrati di sviluppo.
39
5.2. PROGETTAZIONE
Figura 5.2: Diagramma UML del primo tentativo di implementazione
40
5.3. IMPLEMENTAZIONE
Nel nostro lavoro di tirocinio, come abbiamo già accennato nel Capitolo 1, il primo tentativo di realizzazione del software mirava all’implementazione di un interprete che soddisfava solo
parzialmente le specifiche dello standard W3C. Un’implementazione completa dello standard
infatti, avrebbe comportato un lavoro di enorme portata che esulava dal nostro compito. Ponendoci come unico obiettivo quello di sviluppare un’applicazione capace di sostenere il dialogo
riportato nel Paragrafo precedente, era difatti sufficiente implementare esclusivamente le parti
dello standard che interessavano il nostro caso d’uso.
In questo contesto siamo quindi arrivati a produrre un nostro diagramma UML (Figura 5.2)
che comprendeva classi e interfacce relative all’implementazione parziale dello standard. Prima
ancora di poter proseguire con la fase successiva alla progettazione ed iniziare quindi a «codificare» il diagramma UML da noi prodotto, siamo venuti però a conoscenza di un progetto che
ci ha spinti ad intraprendere un’altra via risolutiva. Come già introdotto nel Capitolo 1, tale
progetto mirava a realizzare il porting di JVoiceXML (Paragrafo 4.5) nella piattaforma Android,
ma l’applicazione era stata postata online ancora incompleta. Già dopo una prima analisi del
codice comunque, appariva chiaro che la parte mancante al completamento del lavoro era comunque minima. Potevamo quindi decidere di continuare con l’implementazione modellata sul
nostro diagramma UML o scegliere di completare il progetto di porting già avviato. Dopo un
primo momento di indecisione, abbiamo convenuto che optare per la seconda opzione ci avrebbe
condotti a risultati di maggiore rilevanza. Portare a termine il porting infatti, significava realizzare un software non ancora esistente sul mercato, capace di interpretare un qualsiasi documento
VoiceXML standard, sfruttando la struttura del JVoiceXML.
In questo nuovo scenario, abbiamo quindi abbandonato il nostro progetto iniziale, e ci siamo
dedicati allo studio del software incompleto. Riportare in queste pagine il diagramma UML
corrispondente al nuovo progetto sarebbe impossibile, in quanto si tratta di uno schema talmente
vasto da poter essere navigato solo mediante visualizzazione virtuale.
5.3 Implementazione
L’implementazione (talvolta detta anche programmazione o codifica) costituisce la fase principale del modello a cascata presentato in Figura 5.1. Questo stadio del processo di sviluppo del
softwarere è caratterizzato da due punti principali:
• scelta del linguaggio di programmazione;
• traduzione del diagramma prodotto nella precedente fase di progettazione, nel linguaggio
di programmazione scelto.
La decisione di utilizzare il linguaggio di programmazione Java della Oracle è stata una scelta obbligata, in quanto è l’unico linguaggio con cui è possibile compilare un’applicazione per
Android. In realtà recentemente la compagnia software californiana Xamarin ha rilasciato un
framework open-source per Android, chiamato MonoDroid e basato sul dominio di primo livello
generico .NET che consente di scrivere applicazioni Android in C # [46]. Abbiamo comunque
41
5.3. IMPLEMENTAZIONE
deciso di optare per la scelta del linguaggio Java per evitare possibili problemi di incompatibilità
che si sarebbero potuti presentare utilizzando un nuovo IDE non ancora ben testato.
Come è stato già precisato nel Paragrafo precedente, il primo tentativo di implementazione è
stato abbandonato ancora prima di iniziare la stesura del codice. Tuttavia, unitamente ai diagrammi UML erano state prodotte delle linea guida per una futura implementazione. Riportiamo
di seguito a titolo di esempio la struttura logica della classe VXML.
• metodo run (la classe VXML è un thread!)
1. crea una lista List di elementi dialogo (form e menu);
2. richiama la funzione parsingFile che scorre gli elementi mediante l’utilizzo di un ciclo for
passandogli come inidice iniziale 0;
• metodo parsingFile:
1. in base all’indice passatogli esegue il form o il menu corrispondente;
2. prosegue con l’esecuzione degli elementi successivi fino all’ultimo dialogo.
Come si può notare l’intenzione iniziale era quella di utilizzare la struttura dati della Lista per
costruire una mappatura dell’albero sintattico di un documento VoiceXML. Con la decisione di
abbandonare questo primo tentativo di implementazione e intraprendere la strada del porting
però, le strutture logiche delle classi sono state completamente rinnovate. Dovendo affrontare
un numero di classi e interfacce molto più elevato (più di 600) la gestione e la comprensione della
struttura del programma è stata possibile solo grazie all’analisi dello standard W3C (Paragrafo
5.4) sul quale JVoiceXML è stato modellato.
Per quanto riguarda l’implementazione delle classi che hanno permesso il porting, rimandiamo
alla tesi “Human-Computer vocal interaction: porting di JVoiceXML su Android” di Riccardo
Cecchi. In questo lavoro ci limitiamo ad esporre le classi che sono state protagoniste dell’implementazione dell’interprete. Un’implementazione personale dell’intero sistema è costituita infatti
dalla progettazione di queste sole classi:
• l’applicazione principale, che deve solo creare un’istanza di JVoiceXmlInterpreter e lanciarne opportunamente i metodi;
• una classe che implementa l’interfaccia ImplementationPlatformFactory;
• una classe che implementa l’interfaccia ImplementationPlatfrom;
• una classe che implementa le interfacce UserInput, SystemOutput, SinthetizedOutput e
SpokenInput;
• una classe che implementa l’interfaccia DocumentServer.
Gran parte di queste classi era già stata quasi interamente implementata dallo studente spagnolo
autore del tentato porting. Una parte che mancava completamente nel sistema era l’implementazione del supporto all’ASR di Android, che abbiamo provveduto ad inserire nella classe dedicata
MySynthetizedOutput.
42
5.4. STANDARD W3C
5.4 Standard W3C
5.4.1 Scopi e componenti
Prima di definire le specifiche vere e proprie che lo standatd impone per i documenti VoiceXML, chiariamo quali sono gli scopi e i componenti che interessano questo metalinguaggio.
VoiceXML è un linguaggio di markup che:
• riduce al minimo le interazioni client/server specificando interazioni multiple per ciascun
documento;
• nasconde agli autori di un’applicazione il codice di più basso livello e i dettagli specifici
della piattaforma;
• è facile da usare per le interazioni semplici, ma fornisce anche funzionalità di linguaggio
per sostenere dialoghi complessi.
Il linguaggio inoltre descrive l’interazione uomo-macchina fornita da sistemi di risposta vocale,
che comprende:
• output prodotto da un sistema di sintesi vocale (TTS);
• output costituito da file audio pre-registrati;
• riconoscimento dell’input di tipo vocale (ottenuto da un sistema di riconoscimento ASR)
o tramite tastiera telefonica (DTMF, Dual-Tone Multi-Frequency);
• sistema di registrazione di input vocali;
• controllo del flusso di dialogo, tramite l’uso di variabili;
• funzionalità di telefonia, come ad esempio il trasferimento di chiamata.
5.4.2 Struttura di un documento
Essendo VoiceXML una sorta di dialetto dell’XML, la struttura dei suoi documenti riprende
quella dei documenti XML da cui discendendono.
Il termine documento ricorre spesso nella terminologia XML e VoiceXML. Anche se esso può
far pensare a pagine Web o ad altri prodotti dell’elaborazione di testo, è utilizzato nella sua
accezione più ampia di contenitore di informazioni. Concretamente, un documento XML è un
file di testo che contiene una serie di tag, attributi e testo secondo regole sintattiche ben definite.
Un documento VoiceXML è intrinsecamente caratterizzato da una struttura gerarchica. Esso
è composto da componenti denominati elementi (o tag), ciascun dei quali rappresenta un componente logico del documento e può contenere altri elementi (sottoelementi) o del testo. Gli
elementi possono avere associate altre informazioni che ne descrivono le proprietà. Queste informazioni sono chiamate attributi. L’organizzazione degli elementi segue un ordine gerarchico
o arboreo che prevede un elemento principale, chiamato root element, o semplicemente root o
radice. La radice contiene l’insieme degli altri elementi del documento. Si può rappresentare
graficamente la struttura di un documento VoiceXML tramite un albero, generalmente noto
come document tree.
43
5.4. STANDARD W3C
Figura 5.3: Prolog integrale
Figura 5.4: Prolog semplificato
5.4.2.1 Prolog
La prima cosa da conoscere per scrivere del codice VoiceXML è la struttura del prolog:
ovvero la sezione di un documento XML che contiene le dichiarazioni XML. Esso deve contenere
la tag root xml, e nel nostro caso anche quella vxml, può inoltre contenere una Document Type
Declaration (DTD), commenti, e istruzioni di processing.
Il prolog, nella forma riportata nelle specifiche W3C appare come mostrato in Figura 5.3:
Come si può notare si compone di due parti, la prima indica che il nostro file è sostanzialmente
un file XML, la seconda, introdotta dalla tag <vxml> che indica al processore che si tratta di
un file di tipo VoiceXML, fornendo lo schema di riferimento e la sua versione.
Lo stesso prolog molto spesso è indicato molto più semplicemente con la formula presentata
in Figura 5.4.
Gli attributi della tag <vxml> sono:
• version, che rappresenta la versione del documento. Attualmente la versione usata è la
3.0, ma il software JVoiceXML di cui abbiamo realizzato il porting è stato modellato sulla
versione 2.0;
• xmlns, che indica quali siano i namespace per il VoiceXML, è stato definito come:
http://www.w3.org/2001/vxml;
• xml:base, che rappresenta la URI (Universal Resource Identifiers) di base per il documento
corrente come definito nelle specifiche XML-Base. Ricordiamo infatti che come per i
documenti XML, anche i VoiceXML possono essere collegati ad altri documenti attraverso
identificatori URI;
44
5.4. STANDARD W3C
• xml:lang, che indica la lingua del documento, questa indicazione diventa fondamentale
nel momento in cui ci si trova a dover gestire più lingue all’interno di un’applicazione o di
un documento;
• application, che indica la URI del documento radice (detto anche documento di root); la
tag <vxml> di un documento principale non dispone di un attributo application.
L’esecuzione di un’applicazione multi-documento avviene selezionando un documento come documento principale dell’applicazione, e il resto come documenti foglia dell’applicazione. Ogni
documento foglia nomina il documento radice nel suo elemento <vxml> servendosi dell’attributo
apllication descritto sopra.
Ogni volta che l’interprete è chiamato ad eseguire un documento foglia, carica quest’ultimo
solo dopo aver caricato il documento radice dell’applicazione. In questo modo il documento
principale dell’applicazione rimane attivato fino a quando all’interprete non viene chiesto di
caricare un documento che appartiene ad una diversa applicazione.
Ci sono diversi vantaggi nell’utilizzare applicazioni multi-documento; i principali sono:
• le variabili del documento principale sono disponibili e utilizzabili dai suoi documenti foglia,
in questo modo le informazioni possono essere condivise e riutilizzate;
• le grammatiche del documento principale rimangono attive quando l’utente si trova in un
documento foglia, in questo modo l’utente è in grado di interagire con i form, i link e i
menu del documento principale.
5.4.2.2 Elementi
Riportiamo nella Figura 5.5 l’elenco completo delle tag esistenti per documenti VoiceXML
con le relative descrizioni. Forniremo una descrizione più approfondita delle tag relative alle
strutture di dialogo form e menu e dell’elemento dedicato all’output vocale, il prompt.
I form sono i componenti chiave dei documenti VoiceXML. Un form contiene:
• un insieme di form items, elementi che vengono visitati nel ciclo principale dell’algoritmo di interpretazione. I form items vengono suddivisi in input items che possono essere «riempiti» da input dell’utente (<filled>) e i control items che non possono essere
«riempiti»;
• dichiarazioni di variabili;
• gestori di eventi.
Gli attributi della tag form sono:
• id, che rappresenta il nome del form. Se specificato, il form può essere referenziato all’interno del documento in cui esso è contenuto o in un altro documento. Questo attributo
permette di passare ad un menu attraverso un <goto> o un <submit>;
• scope, che denota l’ambito di eventuali grammatiche contenute nel form. Se è assegnato
uno scope ’dialog’ (default), le grammatiche del form sono attive solo all’interno del form.
45
5.4. STANDARD W3C
Se è assegnato uno scope ’document’, le grammatiche del form sono attive in qualsiasi
dialogo contenuto nello stesso documento. Se tuttavia, lo scope è impostato come ’document’ nel root document dell’applicazione, la grammatica del form sarà attiva in tutta
l’applicazione.
Gli input items si dividono in:
• <field>, il cui valore si ottiene tramite le grammtiche ASR o DTMF;
• <record>, il cui valore è un file audio registrato dall’utente;
• <transfer>, responsabile del trasferimento di chiamata;
• <object>, che invoca uno specifico oggetto «piattaforma» con vari parametri che andrà a
costituire un ECMAScript Object, ovvero un oggetto del metalinguaggio ECMAScript;
• <subdialog>, che è molto simile ad una chiamata di funzione. Con questa tag si richiama un altro dialogo contenuto nel documento corrente o si invoca un altro documento
VoiceXML. Anche questa tag restituisce un oggetto ECMAScript come risultato.
I control items si dividono invece in:
• <block>, che costituisce una sequenza di istruzioni procedurali utilizzate per il prompting e il calcolo, ma non per la raccolta di input. Un block ha una variabile form item
(normalmente implicita) impostata su ’true’ appena prima di essere interpretato;
• <initial>, i cui prompt sono scritti per incoraggiare l’utente a dire qualcosa che abbia
una corrispondenza nella grammatica del form corrispondente. Questa tag ha tre attributi: name, expr e cond, che si riferiscono rispettivamente al nome, valore e condizione
di accessibilità della variabile. Il FIA (Sottoparagrafo 4.5.3) visita ed esegue solo le tag
<initial> che hanno la cond settata come ’true’, d’altra parte la cond viene settata ’true’
solo se l’attributo expr è indefinito (expr=""). Quando si ha un «match» nella grammatica
corrente, l’attributo expr viene settato come ’true’ e di conseguenza non essendo più un
valore indefinito, la cond si setterà automaticamente a ’false’;
Una tag menu è una comoda abbreviazione sintattica di una tag form. Essa infatti contiene un
singolo field anonimo e chiede all’utente di fare una scelta a seconda della quale, il FIA passerà
all’esecuzione della parte di documento corrispondente. Come una normale form, può avere la
sua grammatica con il relativo scope da impostare.
Gli attributi della tag menu sono:
• id, che rappresenta l’identificatore del menu. Questo attributo permette di passare ad un
menu attraverso un <goto> o un <submit>;
• scope, che denota l’ambito di eventuali grammatiche contenute nel menu. Se è assegnato
uno scope ’dialog’ (default), le grammatiche del menu sono attive solo all’interno del menu.
46
5.4. STANDARD W3C
Figura 5.5: Elenco tag
47
5.4. STANDARD W3C
Se è assegnato uno scope ’document’, le grammatiche del menu sono attive in qualsiasi
dialogo contenuto nello stesso documento. Se tuttavia, lo scope è impostato come ’document’ nel root document dell’applicazione, la grammatica del menu sarà attiva in tutta
l’applicazione;
• dtmf, che serve per l’assegnazione implicita delle scelte proposte nel menu. Se questo attributo è impostato su ’true’, assegnerà alle prime 9 scelte di menu i valori della grammatica
DTMF in modo automatico (da 1 a 9), a meno che le scelte non abbiano già un’assegnazione esplicita. Se non diversamente specificato, il valore predefinito per l’attributo dtmf
è ’false’, non consentendo in tal modo l’assegnazione implicita;
• accept, che serve per definire la certezza del riconoscimento delle choice. Se questo attributo è impostato su ’exact’ (impostazione di default), il testo degli elementi choice del
menu definisce la frase esatta che dovrà essere riconosciuta «alla lettera». Quando l’attributo accept è impostato su ’approximate’, il testo degli elementi choice definisce una frase
di riconoscimento approssimativo. Ogni <choice> può ignorare questa impostazione.
Un altro elemento degno di nota è il prompt, in quanto è la tag che controlla l’output sottoforma
di sintesi vocale o di audio pre-registrato. Concettualmente, i prompt sono istantaneamente
messi in coda per la riproduzione al momento del parsing del file. L’interpretazione procede
finché l’utente non deve fornire un input; a questo punto, i prompt vengono riprodotti, e il
sistema attende l’input dell’utente. Una volta ricevuto l’input da parte del sottosistema di
riconoscimento vocale ASR (o da parte del riconoscitore DTMF), l’interpretazione procede per
il resto del documento.
Gli attributi della tag prompt sono:
• bargein, con il quale si decide se un utente può interrompere un prompt. L’impostazione
di default è ’true’;
• bargeintype, che consente allo sviluppatore di indicare quali valori di bargein sono validi.
Se questo attributo è impostato su ’speech’ (impostazione di default) qualsiasi espressione
da parte dell’utente interromperà il prompt. Quando l’attributo bargeintype è settato su
’hotword’, il bargein sarà valido solo per alcune parole specifiche definite dallo sviluppatore;
• cond, un’espressione booleana che deve avere valore ’true’ affinchè il prompt venga riprodotto. L’impostazione di default è ’true’;
• count, che può assumere valore numerico e che consente di emettere differenti prompt se
l’utente fa qualcosa ripetutamente. Se omesso, il valore predefinito è ’1’;
• timeout, che rappresenta il tempo concesso per l’emissione del successivo input dell’utente.
Il valore è un tempo espresso in secondi. L’impostazione di default è ’5s’;
• xml:lang, che rappresenta l’identificatore della lingua per il prompt. Se omesso, il valore
di default è ereditato dalla gerarchia del documento;
• xml:base, che rappresenta la URI di base per il prompt corrente.
48
5.4. STANDARD W3C
Una tag prompt può avere le seguenti tag figlie: audio, break, desc, emphasis, lexicon, mark,
meta, metadata, p, phoneme, prosody, say-as, s, sub, voice. L’utilizzo di tali tag aggiuntive
permette di caratterizzare in modo ancora più personale l’output di un’applicazione.
5.4.3 Grammatiche
Abbiamo osservato che al fine di guidare il riconoscimento dell’input, sia esso vocale o tramite tastiera telefonica (DTMF), vengono usati dei particolari dizionari, chiamati grammatiche.
L’uso delle grammatiche dunque si rivela fondamentale all’interno di un’applicazione vocale, in
quanto consente di riconoscere tutti i valori che gli utenti devono poter pronunciare e le possibili
combinazioni di questi valori.
Le grammatiche possono essere di tre tipi:
• Built In o predefinite;
• Interne o “in linea”;
• Esterne (su file esterno).
Per alcuni campi risulta vantaggioso utilizzare delle grammatiche predefinite, questo ci permette
di semplificare lo sviluppo di un’applicazione e richiamare il tipo di grammatica necessaria senza
doverla costruire. Per richiamare una grammatica predefinita è sufficiente settare l’attributo type
della tag field con il valore opportuno. Le varie tipologie esistenti sono:
• ’boolean’, che accetta i valori ’si’ o ’no’;
• ’digits’, che accetta sequenze di numeri (DTMF) da 1 a 9;
• ’number’, che accetta numeri a più di una cifra;
• ’date’, che accetta valori di DTMF del tipo ’yyyymmdd’ rappresentanti una data;
• ’currency’, che accetta valori di DTMF del tipo ’UUUmmmm,nn’ rappresentanti una data
valuta (UUU) e una quantità monetaria (mmmm,nn);
• ’phone’, che accetta numeri telefonici.
L’elemento grammar viene utilizzato per fornire una grammatica che
• specifica un insieme di enunciati che un utente può pronunciare per eseguire un’azione o
avere un’informazione;
• per un’eventuale corrispondenza, restituisce una corrispondente interpretazione semantica.
L’elemento <grammar> è progettato per ospitare qualsiasi formato di grammatica che risponde a questi due requisiti. Nelle attuali specifiche W3C vi sono due possibili formati per le
grammatiche:
• Augmented BNF syntax (ABNF): sono grammatiche di tipo plain-text, simili alle
tradizionali grammatiche telefoniche (BNF), e a molte rappresentazioni delle grammatiche
usate nel campo della speech recognition tra cui le JSpeech Grammar Format (JSGF) dalle
quali sono derivate;
49
5.4. STANDARD W3C
• XML: sono grammatiche che usano XML per rappresentare i costrutti delle grammatiche,
conformi alle specifiche del W3C Speech Recognition Grammar Specification (SRGS).
Gli attributi della tag grammar definiti dall’SRGS per i documenti XML sono:
• version, che definisce la versione della grammatica utilizzata;
• xml:lang, che rappresenta l’identificatore della lingua della grammatica utilizzata. Se
omesso, il valore di default è ereditato dalla gerarchia del documento;
• mode, che definisce la modalità della grammtica seguendo le specifiche definite dall’SRGS;
• root, che definisce la tag rule che agisce come regola principale della grammatica utilizzata;
• tag-format, che definisce il formato del contenuto di ogni tag presente nella grammatica
utilizzata;
• xml:base, che dichiara l’URI di base dal quale discende la grammatica utilizzata.
Gli attributi della tag grammar aggiunti con la versione VoiceXML 2.0 sono:
• src, che rappresenta l’URI relativo della grammatica e facoltativamente un rulename
interno alla grammatica, nel caso di grammtica esterna;
• scope, che può assumere valore ’document’, e nel qual caso rende la grammatica attiva in
tutte le finestre di dialogo del documento corrente (e relativi documenti foglia dell’applicazione). Nel caso in cui sia settato come ’dialog’, rende la grammatica attiva in tutto il
form attuale. Se omesso, viene caricato il valore di scope dell’elemento padre.
• type, che specifica il tipo di file grammatica utilizzato. I valori accettabili per questo
attributo sono ’application/grammatica-xml’. Si noti che a differenza di altri attributi,
questo è obbligatorio; se lasciato non specificato, allora si verificherà un error.badfetch;
• weight, che specifica il peso della grammatica;
• fetchhint, viene utilizzato per specificare quando una risorsa dovrebbe essere presa durante l’esecuzione dell’applicazione. I valori possibili e le relative descrizioni sono i seguenti:
’prefetch’ se si vuole recuperare una risorsa al momento dell’esecuzione del documento
iniziale o ’safe’ se si vuole recuperare la risorsa solo quando viene espressamente definito;
• fetchtimeout, che viene usato per indicare per quanto tempo, (in secondi o millisecondi), l’interprete deve cercare di recuperare il contenuto prima di lanciare un’eccezione
error.badfetch.
5.4.4 Gestione degli eventi
La piattaforma VoiceXML genera eventi quando l’utente non risponde, non risponde in un
modo che l’applicazione capisce, in caso di richieste di aiuto, etc. L’interprete genera eventi se
trova un errore semantico in un documento VoiceXML, o quando incontra un elemento <throw>.
50
5.4. STANDARD W3C
Figura 5.6: Default Catch Handlers
Ciascun elemento in cui può verificarsi un evento ha un insieme di catch elements, che
comprendono le tag: catch, error, help, noinput, nomatch.
L’elemento throw lancia un evento di tipo predefinito o definito dall’applicazione.
Gli attributi della tag throw sono:
• event, che corrisponde all’evento che si vuole generare;
• eventexpr, che corrisponde ad un espressione ECMAScript che valuta il nome dell’evento
che deve essere generato;
• message, che fornisce ulteriori informazioni sull’evento da generare sottoforma di stringa.
Per gli errori predefiniti, il valore di questi attributi dipende dalla piattaforma;
• messageexpr, che corrisponde ad un espressione ECMAScript che valuta la stringa contenuta nell’attributo message.
L’interprete dovrebbe fornire impliciti gestori di catch predefiniti per le tag noinput, help, nomatch, cancel, exit, e per gli eventi d’errore (se lo sviluppatore non ha provveduto a specificare
la loro gestione).
Il comportamento di default del sistema per la gestione dei vari eventi ed errori è riassunto
nella Figura 5.6 che specifica:
• se deve essere fornita una risposta audio;
• come l’esecuzione viene influenzata.
Ovviamente nel caso in cui è fornita una risposta audio, il contenuto effettivo del prompt è
dipendente dalla piattaforma.
Gli eventi sono identificati da stringhe di caratteri; di seguito riportiamo l’elenco degli eventi
e degli errori predefiniti. Le parti in corsivo delle stringhe vanno sostituite con le informazioni
relative al particolare evento considerato, ad esempio in error.unsupported.element, la parola element viene sostituita con il nome dell’elemento VoiceXML che non è supportato come
error.unsupported.transfer.
• cancel: l’utente ha richiesto di annullare la riproduzione del messaggio corrente;
51
5.4. STANDARD W3C
• connection.disconnect.hangup: l’utente ha riagganciato;
• connection.disconnect.transfer: l’utente è stato trasferito incondizionatamente a un’altra linea e non tornerà;
• exit: l’utente ha chiesto di uscire;
• help: l’utente ha chiesto aiuto;
• noinput: l’utente non ha fornito alcun input entro il tempo di timeout;
• nomatch: l’input dell’utente non è stato riconosciuto;
• maxspeechtimeout: l’input dell’utente è stato troppo lungo e ha superato il valore
dell’attributo ’maxspeechtimeout’;
• error.badfetch: l’interpreter context lancia questo evento quando il recupero di un documento non è riuscito e l’interpreter context ha raggiunto un posto nell’interpretazione
del documento in cui è richiesto il recupero del risultato;
• error.badfetch.http.response_code e error.badfetch.protocol.response_code: nel
caso di un fetch fallito, l’interpreter context deve utilizzare un tipo di evento dettagliato
che informi riguardo a quale codice di risposta HTTP specifico o altro protocollo specifico
è stato rilevato. Ciò consente alle applicazioni di trattare differenzialmente un documento
mancante da un documento vietato. Il valore del codice di risposta per altri protocolli
(come HTTPS, RTSP, e così via) dipende dal tipo di protocollo;
• error.semantic: è stato rilevato un errore di run-time nel documento VoiceXML; ad
esempio, è stato fatto riferimento ad una variabile non definita;
• error.noauthorization: è generato quando l’applicazione tenta di eseguire un’operazione
che non è autorizzata dalla piattaforma. Ad esempio questo errore si potrebbe verificare
con la composizione di un numero telefonico non valido o che l’utente non è autorizzato a
chiamare;
• error.noresource: si è verificato un errore di run-time a seguito di una richiesta ad una
risorsa non disponibile durante l’esecuzione;
• error.unsupported.builtin: la piattaforma non supporta un tipo di grammatica predefinita richiesta;
• error.unsupported.format: la risorsa richiesta ha un formato che non è supportato
dalla piattaforma, ad esempio un formato di grammatica non supportato;
• error.unsupported.language: la piattaforma non supporta la lingua o per la sintesi
vocale o per il riconoscimento vocale;
• error.unsupported.objectname: la piattaforma non supporta un particolare oggetto
specifico della piattaforma. E’ importante notare che ’objectname’ è una stringa fissa e
non viene sostituita con il nome o il tipo dell’oggetto non supportato;
52
5.4. STANDARD W3C
• error.unsupported.element: la piattaforma non supporta l’elemento dato.
Tipi di eventi specifici dell’applicazione dovrebbero utilizzare la convenzione del nome di dominio
Internet invertito, al fine di evitare conflitti di denominazione. Per esempio:
• error.com.example.voiceplatform.noauth: l’utente non è autorizzato ad effettuare
chiamate in uscita su questa piattaforma;
• org.example.voice.someapplication.toomanynoinputs: l’utente è stato troppo a lungo in silenzio.
53
Capitolo 6
Conclusioni e sviluppi futuri
Trattandosi di un porting di un software già esistente e funzionante su PC, si è cercato di
correggere, per quanto possibile, eventuali errori causati da parti di codice che si comportavano in
modo anomalo o risultavano incompatibili all’interno della piattaforma Android. L’applicazione
finale da noi prodotta è stata realizzata e testata con successo. E’ inoltre possibile visualizzare
il video di un esempio di utilizzo, disponibile sul canale youtube dell’Artificial Intelligence and
Real Time Systems Laboratory (AIRT Lab) del Dipartimento di Ingegneria dell’Informazione
dell’Università Politecnica delle Marche.
Le funzioni di riconoscimento e di sintesi vocale offerte da Android ed utilizzate all’interno
del nostro lavoro, sono di discreto livello, considerando anche i limiti intrinsechi nella struttura
hardware degli smartphone. C’è da dire, però, che le tecnologie riguardanti l’ASR e il TTS hanno
ancora un lungo percorso da compiere per raggiungere il traguardo di un dialogo veramente
naturale.
Di enorme utilità si è rivelata la consultazione delle specifiche definite dallo standard messo a
disposizione dal World Wide Web Consortium (W3C). Senza di essa infatti, non sarebbe stato
possibile lo studio del software originale JVoiceXML e la successiva realizzazione del porting in
Android.
La versione finale del software si può comunque considerare non più che un prototipo e, in
quanto tale, soffre di errori e incongruenze che lo portano a non rispettare interamente le iniziali
promesse di funzionamento del sistema. Non si escludono quindi, oggettivamente, dei necessari
aggiustamenti in particolare per quanto riguarda la gestione delle informazioni. Attualmente
infatti non è stato progettato alcun database: i dati sono contenuti all’interno del documento
VoiceXML e forniti in maniera statica.
Un altro bug del sistema è costituito dal mancato funzionamento dell’applicazione in caso
di utilizzo di grammatiche interne, mentre con quelle esterne non sembra esserci alcun tipo di
problema. Ciò nonostante, pur trattandosi di una versione ancora da migliorare, il sistema
ha dimostrato una certa stabilità nell’utilizzo e complessivamente le soluzioni implementate
hanno apportato un valore aggiunto non indifferente nel mondo dello sviluppo di applicazioni
Android. Le funzionalità ora supportate sono sicuramente un sostanzioso passo avanti per la
struttura globale del riconoscimento vocale e questo non esclude pertanto una possibile futura
commercializzazione.
55
Bibliografia
[1] C. Delogu, “Perchè le interfacce vocali non sono così diffuse come ci si aspetterebbe,” Sistemi
Intelligenti, 2002, Agosto.
[2] G. Çetin, D. Verzulli, and S. Frings, “An analysis of involvement of hci experts in distributed
software development: Practical issues,” Online Communities and Social Computing, vol.
4564, pp. 32–40, 2007.
[3] E. Rogers, “Human-robot interaction,” Berkshire Encyclopedia of Human-Computer
Interaction, pp. 328–332, 2004, 1 Gennaio.
[4] R. Murphy and E. Rogers, “Final report for darpa/nsf study on human-robot interaction,”
2001.
[5] A. Cappelli and E. Giovannetti, “L’interazione uomo-robot,” Robocare Technical Report,
2003, Novembre.
[6] L. Lorek, “March of the a.i. robots,” Interactive Week, 2001, 30 Aprile.
[7] H. A. Yanco and J. L. Drury, “A taxonomy for human-robot interaction,” in AAAI Technical
Report FS-02- 03. Falmouth, Massachusetts: Proceedings of the AAAI Fall Symposium
on Human-Robot Interaction, Novembre 2002, pp. 111–119.
[8] A. Agah, “Human interactions with intelligent systems: research taxonomy,” vol. 27, pp.
71–107, 2001.
[9] G. Dudek, M.Jenkin, and E. Milios, “A taxonomy of multirobot systems,” Robot Teams,
pp. 3–22, 2002.
[10] T. Balch, “Taxonomies of multirobot task and reward,” Robot Teams, vol. 3-22, 2002.
[11] R. O. Ambrose, H. Aldridge, R. S. Askew, R. R. Burridge, W. Bluethmann, M. Diftler, C. Lovchik, D. Magruder, and F. Rehnmark, “Robonaut: Nasa’s space humanoid,”
Intelligent Systems and their Applications, IEEE, vol. 15, pp. 57–63, 2000, Luglio/Agosto.
[12] I. Horswill, “Analysis of adaptation and environment,” Artificial Intelligence, vol. 73(1-2),
pp. 1–30, 1995.
[13] C. A. Ellis, S. J. Gibbs, and G. L. Rein, “Groupware: some issues and experiences,”
Communications of the ACM, vol. 34, pp. 39–58, 1991.
[14] R. A. Bolt, “Put-that-there: Voice and gesture at the graphics interface,” Computer
Graphics, vol. 14, pp. 262–270, 1980.
57
Bibliografia
Bibliografia
[15] Z. Khan, “Attitudes towards intelligent service robots, iplab, nada, royal institute of
technology,” 1998.
[16] A. Herskovits, “Language and spatial cognition,” An Interdisciplinary Study of the
Prepositions in English, Cambridge University Press, 1986.
[17] C. Theobalt, J. Bos, T. Chapman, A. Espinosa-Romero, M. Fraser, G.Hayes, A. Klein,
T. Oka, and R. Reeve, “Talking to godot: dialogue with a mobile robot,” in Intelligent
Robots and Systems. IEEE/RSJ International Conference on, vol. 2, 2002, pp. 1338–1343.
[18] G. Bugmann, “Challenges in verbal instruction of domestic robots,” 2003.
[19] H. Tanaka, T. Tokunaga, and Y. Shinyama, “Animated agents that understand natural
language and perform actions,” Proceedings of Lifelike Animated Agents (LAA), 2002.
[20] D. Spiliotopoulos, I. Androutsopoulos, and C. D. Spyropoulos, “Human-robot interaction
based on spoken natural language dialogue,” Proceedings of the European Workshop on
Service and Humanoid Robots, 2001.
[21] R. Bischoff and V. Graefe, “Hermes – an intelligent humanoid robot, designed and tested for
dependability,” Experimental Robotics VIII, Proceedings of the 8th International Symposium
ISER02, vol. 5 of Springer Tracts in Advanced Robotics (STAR), 2003.
[22] 5 reasons why android may take half the netbook market. [Online]. Available:
http://blog.laptopmag.com/5-reasons-why-android-may-take-half-the-netbook-market
[23] E. Lopez and D. Magnani. (2011, 4 Aprile) Cos’è android? la storia del sistema
operativo mobile di google. [Online]. Available: http://www.androiditaly.com/articoli/
speciali/189-cose-android-la-storia-del-sistema-operativo-mobile-di-google.html
[24] Android torna open source con la versione 4.0. [Online]. Available: http://www.zeusnews.
it/index.php3?ar=stampa&cod=16187#axzz1muuOQbj4
[25] E. Burnette, Hello, Android:
Pragmatic Bookshelf, 2009.
Introducing Google’s Mobile Development Platform.
[26] What is android? [Online]. Available: http://developer.android.com/about/index.html
[27] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner, “Analyzing inter-application communication in android,” MobiSys ’11 Proceedings of the 19th international conference on Mobile
systems, applications, and services, pp. 239–252, 2011.
[28] C. Pelliccia, “Android programming,” Io Programmo.
[29] Ubuntu one: Guida alla configurazione. [Online]. Available: http://www.ubuntu-linux.it/
ubuntu-one-configurazione-servizi-sincronizzazione/
[30] Rilasciato ubuntu one per windows. [Online]. Available: http://www.oneopensource.it/30/
09/2011/rilasciato-ubuntu-one-per-windows/
58
Bibliografia
[31] P. Taylor, Text-to-speech synthesis.
Bibliografia
Cambridge University Press, 2009.
[32] R. W. Sproat and J. P. Olive, “Text-to-speech synthesis,” AT AND T TECHNICAL
JOURNAL, vol. 74, pp. 35–35, 1995.
[33] S.-A. Selouani, T.-H. Lê, C. Moghrabi, B. Lanteigne, and J. Roy, “Online collaborative
learning system using speech technology,” in Proceedings of World Academy of Science,
Engineering and Technology, vol. 15, 2006.
[34] M. Bagein, O. Pietquin, C. Ris, and G. Wilfart, “Enabling speech based access to information management systems over wireless network,” in proceedings of ASWN. Citeseer,
2003.
[35] European telecommunications standards institute. [Online]. Available: http://www.etsi.
org/index.php
[36] Project aurora. [Online]. Available:
http://catalog.elra.info/search.php?page=
1&affichage=long&restrict=;exclude=products_all;config=htdig_elra_cat;method=and;
format=normal;sort=score;matchesperpage=;words=aurora
[37] T. Dutoit, An introduction to text to speech synthesis.
Springer, 1997, vol. 3.
[38] P. Taylor, A. W. Black, and R. Caley, “The architecture of the festival speech synthesis
system,” 1998.
[39] E. Levin, R. Pieraccini, W. Eckert, G. Di Fabbrizio, and S. Narayanan, “Spoken language dialogue: From theory to practice,” in Proc. IEEE Workshop on Automatic Speech
Recognition and Understanding, ASRUU99. Citeseer, 1999.
[40] W3c-world wide web consortium. [Online]. Available: http://www.w3.org/TR/voicexml20/
[41] J. Rouillard and H. Dutter, “Harnessing the power of a voicexml engine to sms based hci,”
2005.
[42] C. Bünte, “Design und implementierung eines grammatikprozessors für einen w3c
standardkonformen voicexml 2.0 interpreter,” 2005, Ottobre 10.
[43] D. Schnelle-Walka, “Jvoicexml 0.7. 4.1. gauser guide,” 2011.
[44] Requirements analysis. [Online]. Available: http://cnx.org/content/m14621/latest/
[45] Software development: The waterfall model. [Online]. Available: http://www.cs.odu.edu/
~cs333/website-s11/Lectures/waterfall/pages/index.html
[46] A. Puder and O. Antebi, “Cross-compiling android applications to ios and windows phone
7,” Mobile Networks and Applications, vol. 18, no. 1, pp. 3–21, 2013.
59

Human-Computer vocal interaction: analisi dello

Transcript

Documenti analoghi

5E programma svolto 2014-15 - progetti

Scarica il pdf.

Io Robot - DivxMania

Loquendo Piattaforma VoxNauta

indice generale

Software di supervisione Vijeo Citect

Cedam - Il reato aberrante di Dacqui` Giuseppe - Libri

Scarica il bando completo

Campetella Robotic Center Srl

Capitolo 4 - L`allestimento del laboratorio nella scuola G.Marcati

Press Kit 2012