Progetto e realizzazione di un framework per applicazioni...

Progetto e realizzazione di un framework per applicazioni vocali in

formato VXML

Sommario 1 INTRODUZIONE ............................................................................................................................ 3

1.1 IL CONTESTO PROGETTUALE ............................................................................................................... 3 1.2 OBIETTIVI DEL FRAMEWORK ............................................................................................................... 4 1.3 ATTIVITÀ E STATO DI AVANZAMENTO................................................................................................. 5 1.4 ORGANIZZAZIONE DEL DOCUMENTO ................................................................................................... 6

1.4.1 Prima Parte. .......................................................................................................................... 6 1.4.2 Seconda Parte........................................................................................................................ 6 1.4.3 Altri capitoli........................................................................................................................... 7

PRIMA PARTE ......................................................................................................................................... 8 2 LE APPLICAZIONI VOCALI ....................................................................................................... 9

2.1 INTRODUZIONE.................................................................................................................................... 9 2.2 RICONOSCIMENTO DEL PARLATO ...................................................................................................... 10

2.2.1 Cenni storici ........................................................................................................................ 12 2.2.2 Ambiti d'uso ......................................................................................................................... 14 2.2.3 Command and control ......................................................................................................... 14 2.2.4 Le applicazioni Dictation .................................................................................................... 16 2.2.5 Prospettive........................................................................................................................... 16

2.3 SINTESI DEL PARLATO ....................................................................................................................... 17 3 LE PIATTAFORME VOCALI..................................................................................................... 19

3.1 INTRODUZIONE.................................................................................................................................. 19 3.1.1 I sistemi IVR ........................................................................................................................ 19 3.1.2 I Voice Portal ...................................................................................................................... 22

3.2 PIATTAFORME VOCALI VOICEXML .................................................................................................. 23 3.2.1 Architettura fisica ................................................................................................................ 23 3.2.2 Architettura logica............................................................................................................... 26 3.2.3 Il VoiceXML......................................................................................................................... 28

3.3 LE SOLUZIONI DI MERCATO ............................................................................................................... 30 3.3.1 Gli standard......................................................................................................................... 30 3.3.2 I protagonisti ....................................................................................................................... 31

4 GLI OBIETTIVI DEL FRAMEWORK ...................................................................................... 33 4.1 INTRODUZIONE.................................................................................................................................. 33 4.2 OBIETTIVI DEI FINANZIATORI ............................................................................................................ 34 4.3 OBIETTIVI DEI COMMERCIALI ............................................................................................................ 35 4.4 OBIETTIVI DEGLI SVILUPPATORI........................................................................................................ 36 4.5 OBIETTIVI DEGLI UTILIZZATORI ........................................................................................................ 36 4.6 ESEMPI DI RIFERIMENTO.................................................................................................................... 36

4.6.1 “Servizio notte”................................................................................................................... 37 4.6.2 “Rubrica Aziendale” ........................................................................................................... 37

5 “VISION” DELLA SOLUZIONE ................................................................................................ 38 5.1 LOGICA DI BUSINESS ......................................................................................................................... 38

5.1.1 I Ruoli .................................................................................................................................. 39 5.1.2 Il Processo ........................................................................................................................... 41

5.2 TECNOLOGIA..................................................................................................................................... 48 5.2.1 Web Application .................................................................................................................. 49 5.2.2 Model View Control 2.......................................................................................................... 50 5.2.3 J2EE .................................................................................................................................... 51

5.3 ARCHITETTURA FISICA...................................................................................................................... 51 5.3.1 Runtime................................................................................................................................ 52 5.3.2 Designer .............................................................................................................................. 53

5.4 ARCHITETTURA LOGICA.................................................................................................................... 54 5.5 ORGANIZZAZIONE DELL’INFORMAZIONE PER IL VOCALE................................................................... 56

5.5.1 Introduzione......................................................................................................................... 56 5.5.2 Caso “Servizio Notte” ......................................................................................................... 57 5.5.3 Caso “Rubrica Aziendale”.................................................................................................. 66

5.6 MODELLO PER LA RAPPRESENTAZIONE INTERNA .............................................................................. 69 5.6.1 Applicazioni Vocali.............................................................................................................. 69 5.6.2 Nodi ..................................................................................................................................... 70 5.6.3 Variabili............................................................................................................................... 71 5.6.4 Grammatiche ....................................................................................................................... 71 5.6.5 Servizi .................................................................................................................................. 72

5.7 APPLICAZIONE DEL MODELLO .......................................................................................................... 72 5.7.1 Caso “Servizio Notte” ......................................................................................................... 72

SECONDA PARTE ................................................................................................................................. 75 6 REQUISITI..................................................................................................................................... 76

6.1 INTRODUZIONE.................................................................................................................................. 76 6.2 MODULO DESIGNER.......................................................................................................................... 77 6.3 MODULO RUNTIME ........................................................................................................................... 79 6.4 CASI D’USO....................................................................................................................................... 80

6.4.1 Attori.................................................................................................................................... 81 6.4.2 Designer .............................................................................................................................. 82 6.4.3 Runtime................................................................................................................................ 96

7 PROGETTAZIONE....................................................................................................................... 99 7.1 INTRODUZIONE.................................................................................................................................. 99 7.2 ARCHITETTURA DEL SOFTWARE........................................................................................................ 99

7.2.1 Designer ............................................................................................................................ 100 7.2.2 Runtime.............................................................................................................................. 102

7.3 “DESIGN MODEL” ........................................................................................................................... 104 7.3.1 Nodi ................................................................................................................................... 104 7.3.2 Schemi VXML .................................................................................................................... 105

7.4 TIPI DI NODO................................................................................................................................... 107 7.4.1 Nodo: Leggi Testo ............................................................................................................. 107 7.4.2 Nodo: Esegui Servizio ....................................................................................................... 108

7.4.3 Nodo: Link......................................................................................................................... 109 7.4.4 Nodo: Menu....................................................................................................................... 109 7.4.5 Nodo: Acquisisci Dato....................................................................................................... 111 7.4.6 Nodo: Cambia Applicazione.............................................................................................. 113 7.4.7 Nodo: Imposta Variabili .................................................................................................... 113 7.4.8 Nodo: Trasferimento di Chiamata..................................................................................... 114

7.5 REALIZZAZIONE DEI CASI D’USO .................................................................................................... 114 7.5.1 Caso d’Uso: “Crea Applicazione”.................................................................................... 114 7.5.2 Caso d’Uso: “Crea Nodo”................................................................................................ 116 7.5.3 Caso d’Uso: “Specifica Nodo di Inizio” ........................................................................... 117

7.6 SINTESI DELLE FASI DI SVILUPPO..................................................................................................... 118 8 CONCLUSIONI ........................................................................................................................... 120

8.1 OBIETTIVI RAGGIUNTI ..................................................................................................................... 120 8.2 I LIMITI DEL PROGETTO ................................................................................................................... 121 8.3 SVILUPPI FUTURI ............................................................................................................................. 121

FONTI..................................................................................................................................................... 123

APPENDICI ........................................................................................................................................... 124 LA TECNOLOGIA DI RICONOSCIMENTO VOCALE................................................................. 125

APPROCCIO DELLA PATTERN RECOGNITION.......................................................................................... 126 IL MODELLO ACUSTICO DI LOQUENDO................................................................................................... 127

LA TECNOLOGIA DI SINTESI DEL PARLATO............................................................................ 128 TIPI DI UNITÀ DEL PARLATO .................................................................................................................. 128

ESTRATTO DELLE “W3C RECOMMENDATION” PER IL VOICEXML 2.0........................... 131 OVERVIEW ............................................................................................................................................ 131

Introduction....................................................................................................................................... 132 Background ....................................................................................................................................... 134 Concepts ............................................................................................................................................ 138 VoiceXML Elements .......................................................................................................................... 141 Document Structure and Execution................................................................................................... 143

1 Introduzione

Il contesto progettuale

Obiettivi del framework

Attività e stato di avanzamento

Organizzazione del documento

L’oggetto di questa tesi è il progetto e la realizzazione di un framework per applicazioni vocali in formato VXML.

1.1 Il contesto progettuale Per “applicazione vocale” si intende l’insieme di codice che, se eseguito da una piattaforma vocale, realizza un servizio automatico in voce, tipicamente per il canale telefonico.

Oggi le applicazioni vocali sono ampiamente utilizzate in supporto a sistemi industriali e aziendali di una certa dimensione, come ad esempio per i servizi di Customer Relationship Management - CRM (call center, help desk, operatori telefonici automatici) o in altri settori, come il marketing e le vendite (telemarketing, teleselling e indagini di mercato), nella lettura vocale di posta elettronica o altre informazioni, nella logistica, nella gestione di ordini, negli impieghi finanziari e informativi (quotazioni, brokeraggio e home banking) e infine nei servizi pubblici come il tele-voto o il pagamento elettronico.

Il linguaggio VXML (o VoiceXML), utilizzato per la definizione delle applicazioni vocali, è stato sviluppato soltanto negli ultimi anni ( la specifica della versione 1.0 risale al marzo 2000 ), quando le tecnologie di “test to speech” e di “speech recognition”, su cui si fondano i sistemi a cui è destinato, sono diventate tanto affidabili da suscitare l’interesse delle più importanti aziende d’informatica e di telecomunicazione.

1 - I N T R O D U Z I O N E 4

Di fatto è stato proprio questo interesse a stimolare la nascita del “VoiceXML Forum”, ossia di un’organizzazione industriale appositamente fondata per creare e promuovere la diffusione del VoiceXML. Oggi il VoiceXML è uno standard internazionalmente riconosciuto per la definizione dell’accessibilità, con la voce ed il telefono, ai contenuti ed ai servizi basati su Internet.

È in questo panorama che risulta interessante lo sviluppo di un framework che, in modo più semplice e veloce, permetta la definizione e la messa in esercizio di applicazioni vocali secondo il linguaggio VXML.

1.2 Obiettivi del framework Per framework si intende, con l’accezione informatica, un ambiente software fatto su misura per i bisogni di uno specifico ambito. Un framework raccoglie l’insieme di componenti software, concetti e tecnologie tali da ridurre il livello di conoscenza richiesto allo sviluppatore che deve risolvere una specifica tipologia di problema.

Il framework in oggetto, che successivamente indicheremo col nome di VocAppBuilder, costituisce una soluzione pensata per la costruzione di servizi telefonici automatici per le piattaforme vocali di ultima generazione, con la specifica finalità di rendere la programmazione accessibile anche a personale non specializzato. Il primo obiettivo, quindi, deve essere quello di ridurre al minimo, ed al limite annullare, la necessità di conoscere il linguaggio VXML, perché, se da una parte formalizza in modo efficiente una descrizione adatta all’interpretazione da parte di una macchina, dall’altra risulta spesso difficilmente comprensibile agli occhi di un uomo.

Normalmente i produttori di piattaforme vocali forniscono degli ambienti di sviluppo che aiutano nella scrittura del codice VXML. Tipicamente, questi ambienti di sviluppo sono, tuttavia, di supporto alla pura stesura del codice che realizza l’applicazione e non esulano chi li utilizza dal dover di fatto conoscere il linguaggio in tutta la sua complessità.

La qualità fondamentale di questa soluzione è quella di occultare completamente la complessità della stesura del codice VXML. Il framework VocAppBuilder fornisce, pertanto, un modello di rappresentazione dell’informazione e dell’interazione vocale più adatto all’interpretazione e, di conseguenza, all’elaborazione da parte del pensiero umano.

Questo risultato è ottenuto definendo un framework software che implementa un suo specifico modello della “conversazione” (ossia dell’applicazione vocale), e fornisce, inoltre, i metodi per la sua gestione ed il suo utilizzo. La definizione e la gestione del modello è affidata ad un componente del framework che chiameremo Designer, mentre il motore che utilizza il modello è racchiuso in un secondo componente che chiameremo Runtime.

Il modello interno gestito dal modulo Designer, è assimilabile alla definizione di un grafo diretto e tipizzato. Sintetizzando molto, possiamo dire che la definizione della struttura di


questo grafo rappresenta la determinazione della logica della conversazione, mentre la sua tipizzazione, determina la definizione delle singole frasi scambiate tra uomo e macchina.

Il modulo di Runtime si occupa dell’interpretazione di questo modello nella fase di esecuzione. In altre parole questo modulo si occupa di generare e fornire dinamicamente i contenuti VXML per la piattaforma vocale che sta sostenendo la conversazione con l’utente.

VocAppBuilder si pone, inoltre, l’obiettivo di ridurre i costi di tutto il ciclo di vita di un’applicazione vocale. Non solo, quindi, nella fase di progetto e sviluppo, ma anche nella gestione delle modifiche e nell’aggiornamento dei contenuti. Questo obiettivo sarà perseguito integrando nel framework i comportamenti ed i processi tipici dei sistemi di publishing. Infatti framework con obiettivi in qualche modo analoghi sono contenuti nei sistemi di web-publishing, pensati per la realizzazione e gestione dei siti web.

Il framework stesso, in quanto prodotto software, deve realizzare diversi obiettivi, quali: massimizzare la portabilità, utilizzare tecnologie standard, essere fortemente scalabile e non ultimo minimizzare il costo della sua manutenzione. In questo caso il risultato è frutto delle scelte architetturali e dell’integrazione di alcuni altri framework e design pattern molto accreditati sul mercato.

Un ulteriore importante obiettivo del framework è quello di semplificare l’integrazione delle funzioni di business-logic realizzate da sistemi esterni. Anche in questo caso la soluzione è ottenuta con la particolare definizione del modello interno e con l’utilizzo di una architettura basata sulle tecnologie del mondo internet.

1.3 Attività e stato di avanzamento Il framework VocAppBuilder, è stato realizzato dall’autore in qualità di responsabile tecnico per la società Tidysoft, azienda specializzata in soluzioni software multicanale e nella “system integration”, nell’ambito di un progetto per il quale ha coordinato e partecipato alle attività di analisi, progettazione e sviluppo.

Il framework è stato adottato ed implementato all’interno del sistema Tidytalk™ Vocal Interface System, che rappresenta attualmente il prodotto software di eccellenza commercializzato da Tidysoft.

Il marchio Tidytalk è stato registrato nel giugno 2004 ed il prodotto Tidytalk, in commercio dall’estate 2004, è già stato acquistato da ItalgasPiù per il servizio di “stato bolletta” e dal Ministero degli Affari Esteri Italiano per il servizio “viaggiare sicuri”. Molti sono inoltre i potenziali clienti attualmente in trattativa, che per motivi di privacy non possono essere citati.


1.4 Organizzazione del documento Il documento è organizzato in due parti corrispondenti rispettivamente alla fase di progettazione ed a quella si sviluppo del framework.

1.4.1 Prima Parte.

I titoli dei capitoli relativi alla fase di progettazione sono:

CAPITOLO 2 - LE APPLICAZIONI VOCALI. Cenni sulle tecnologie di riconoscimento e sintesi del parlato, che costituiscono gli elementi di base per la comprensione e determinazione del concetto di applicazione vocale.

CAPITOLO 3 - LE PIATTAFORME VOCALI. Valutazione delle soluzioni di mercato. In particolare viene osservata l’architettura della piattaforma Voxnauta di Loquendo, che sarà utilizzata come piattaforma di riferimento.

CAPITOLO 4 - GLI OBIETTIVI DEL FRAMEWORK. Determinazione degli obbiettivi del progetto e relative osservazioni.

CAPITOLO 5 - “VISION” DELLA SOLUZIONE. E’ il capitolo principale, dedicato alla descrizione della soluzione. Questo capitolo raccoglie sostanzialmente la descrizione del comportamento e l’organizzazione del sistema in cui si colloca il framework. Per cominciare viene descritto il processo di produzione che si vuole ottenere con l’uso del framework; si prosegue poi con la descrizione dell’architettura del software e della logica di business che si intende realizzare per ottenerlo.

1.4.2 Seconda Parte.

I titoli della seconda parte del documento, dedicata alle fasi di sviluppo, sono:

CAPITOLO 6 - REQUISITI. Raccoglie i requisiti, ossia una definizione più formale degli obiettivi del framework. Questi requisiti sono stati formalizzati con la definizione dei Casi d’Uso del sistema.

CAPITOLO 7 - PROGETTAZIONE. Descrive gli elementi principali dell’implementazione del framework realizzata per Tidysoft e che costituisce parte integrante del suo sistema Tidytalk.

CAPITOLO 8 - CONCLUSIONI. Osservazioni a conclusione di questo progetto.


1.4.3 Altri capitoli.

Il documento prosegue con alcuni capitoli di supporto. In particolare viene presentato un esempio di utilizzo pratico dell’implementazione del framework. In appendice, inoltre, è stato riportato un estratto delle “W3C Recommendation” per il VoiceXML 2.0, che ha costituito il riferimento fondamentale per lo sviluppo dei concetti e delle idee raccolte in questa tesi.

PRIMA PARTE Progettazione

2 Le Applicazioni Vocali

Introduzione

Riconoscimento del parlato

Sintesi del parlato

2.1 Introduzione Prima di affrontare i dettagli della soluzione proposta è bene inquadrare gli elementi che contribuiscono a definire il problema che si intende risolvere.

Innanzitutto è necessario approfondire il concetto di applicazione vocale.

In generale vengono indicate come applicazioni vocali tutte quelle soluzioni che in qualche misura utilizzano una o entrambe le tecnologie di “Automatic Speech Recognition” (ASR) e di “Text To Speech” (TTS), rispettivamente riconoscimento e sintesi del parlato.

Come già indicato nell’introduzione, in questa tesi il significato di “applicazione vocale”è in realtà più ristretto e si limita ad indicare “la componente di codice che può essere eseguita da una piattaforma vocale”.

Le piattaforme vocali sono quei sistemi di hardware e di software in grado di sostenere un’interazione vocale con le persone. Si parla di piattaforme, in particolare, nel caso di sistemi destinati all’automazione di servizi telefonici.

Tutte le piattaforme vocali, in qualche forma, contengono e implementano entrambe le tecnologie di ASR e TTS.

La componente di codice che definisce l’applicazione vocale deve essere scritta, naturalmente, nel linguaggio utilizzato dalla piattaforma. Attualmente, lo standard al quale, tutte le piattaforme si sono o si stanno adeguando è il linguaggio VXML.

2 – L E A P P L I C A Z I O N I V O C A L I 1 0

Il framework VocAppBuilder prevede la disponibilità di una piattaforma vocale che utilizza il linguaggio VXML.

TTSASR

Pia

ttafo

rma

Voca

le

Applicazione Vocale

VXML

Figura 1 - Applicazione vocale nel contesto delle piattaforme vocali

Nei successivi paragrafi di questo capitolo vengono descritte brevemente le due tecnologie, ASR e TTS, che costituiscono il cuore delle piattaforme vocali e che danno significato e valore a questo progetto.

2.2 Riconoscimento del parlato I sistemi di riconoscimento vocale (in inglese Speech Recognition) costituiscono una delle modalità più innovative per gestire l'interazione tra attori umani e sistemi informativi. Si definisce “sistema di speech recognition” ogni sistema in grado di convertire un input vocale in una stringa digitale di parole corrispondenti. Visto da un'altra prospettiva, un sistema di questo genere consente di fornire un input a una macchina con il semplice uso della voce, anziché con una periferica quale potrebbe essere una tastiera, un mouse, una penna ottica o altro.

Per realizzare un processo di riconoscimento vocale è necessario un software chiamato Speech recognition engine, vale a dire un motore di riconoscimento vocale. La funzione primaria dell’engine è tradurre gli input vocali in formati testuali o in altri formati comprensibili alla macchina.


Il meccanismo che permette di effettuare la traduzione prevede in forma estremamente schematica, tre passaggi: la scomposizione dell'input vocale in sequenze rilevanti; l'attivazione di un modello di linguaggio (contenente tutte le parole e combinazioni di parole riconosciute dal sistema) e infine il Matching, cioè il confronto fra i risultati. Durante questo processo il motore si avvale di una (o più) grammatiche di supporto. Con il termine grammatica si intendono tutte le parole e sequenze di parole riconosciute come valide dal sistema. La grammatica prevede una sintassi, che costituisce in un certo senso il contesto dell'interazione con lo strumento di speech recognition. La grammatica può essere rigida (predefinita quindi e non modificabile) o, nella maggior parte dei casi, ampliabile sulla base delle scelte dell'utente.

Riconoscimento Vocale Comprensione

Riconoscimento della Lingua

Riconoscimento del Parlatore

Parole

Segnale Acustico

Significato

Lingua

Parlatore

Figura 2 - Modalità di interpretazione del segnale acustico

Le tecnologie di riconoscimento vocale operano in un ambito non semplice. Sulla trasposizione in digitale delle parole umane influiscono diversi fattori, tra i quali i più significativi sono le caratteristiche del parlante (come il sesso, l'età, le caratteristiche di pronuncia, lo stato emotivo e la modalità di eloquio), le caratteristiche dell'ambiente (come la presenza o l'assenza di rumore, riverberi ed eco) e infine le caratteristiche del canale audio (cioè la qualità della trasmissione o della registrazione).

I problemi iniziali dovuti alla scarsa potenza di calcolo si possono dire ormai ampiamente superati, anche se a fronte di un transfer rate estremamente modesto come quello richiesto dal parlato (di soli 50 bit/s circa) è comunque necessario un notevole apporto di Cpu e memoria per l'elaborazione dei dati.

Alcuni limiti iniziali, come la necessità di effettuare un training dei singoli utenti per l'uso degli strumenti di riconoscimento vocale, sono sul punto di scomparire.


Nonostante la crescita della potenza di calcolo e la maturità tecnologica, le applicazioni di Speech recognition hanno conquistato un certo mercato ma stentano a decollare.

2.2.1 Cenni storici

Si racconta, che il primo successo nella storia del riconoscimento vocale ha avuto luogo in una fabbrica di giocattoli. Radio Rex era un cane di peluche elettromeccanico, capace di rispondere se chiamato con il suo nome. Il funzionamento era elettromagnetico e non ci sono notizie del successo commerciale. Ciononostante la sua immagine si è fissata come quella del pioniere di una nuova tecnologia.

Alla fine degli anni quaranta il governo statunitense finanziò il settore di ricerca per motivi bellici, con l’intento di intercettare messaggi sovietici e costruire un traduttore automatico. Il primo passo di questa complessa sfida fu proprio la costruzione di un motore capace di riconoscere il parlato. I risultati furono fallimentari, ma la ricerca continuò con la fondazione del programma Speech Understanding Research (Sur) presso la Carnegie Mellon University (Usa).

Il primo sistema di Speech recognition è stato sviluppato nel 1952 dai laboratori Bell: era in grado di riconoscere le cifre da 0 a 9, dettate al telefono, con una accuratezza del 98%, ma si trattava ancora di un sistema analogico. Pochi anni dopo, venne sviluppato un apparato analogo in grado di riconoscere vocali e consonanti. All’inizio degli anni Settanta il programma Sur ottenne i primi risultati digitali; Harpy, un sistema complesso che impiegava una potenza di calcolo incredibile per l'epoca (un cluster di una cinquantina di computer sempre alla Camegie Mellon University) fu in grado di riconoscere frasi complete all'interno di un set predeterminato di strutture grammaticali.

Giunti a questo punto della ricerca, sono stati essenzialmente tre gli ostacoli per la realizzazione dei primi sistemi commerciali: la potenza di calcolo, la difficoltà di riconoscere il parlato di qualunque persona e non di una voce particolare e la possibilità di riconoscere un discorso tenuto con linguaggio naturale, senza obbligare l’interlocutore a una parlata artefatta.

Alcune di queste limitazioni rimangono tuttora, nondimeno, i successi raggiunti dalla ricerca hanno stimolato le prime realizzazioni commerciali.

Le due società protagoniste della prima commercializzazione di sistemi di riconoscimento vocale sono state Speechworks e Dragon Systems. Il primo risultato ottenuto nelle applicazioni commerciali è stata la costruzione di software capaci di funzionare con la potenza di calcolo disponibile nei normali sistemi informatici. L'evoluzione tecnologica e la legge di Moore hanno favorito gli sviluppi successivi fino a sorpassare, oggi, la potenza necessaria per far funzionare un sistema di riconoscimento vocale.


Nel 1996 Chades Schwab, uno dei più noti broker statunitensi, ha implementato il primo sistema di riconoscimento vocale come interfaccia per il suo sistema, Voice Broker. Le innovazioni tecnologiche sono continuate nel 1997, con l'arrivo di Naturally Speaking da parte di Dragon Systems, il primo software di dettatura per parlato continuo. Agli inizi del 2000, TellMe (www.tellme.com) ha presentato un portale globale comandabile con la voce, mentre molte aziende si sono focalizzate sulla ricerca di modalità di accesso a Internet e al Web che richiedono la sola voce. Dal 1997 a oggi, dopo l’eliminazione della dettatura discreta e dall'obbligo di una procedura di addestramento, non si sono visti grandi salti qualitativi, ma solo miglioramenti negli ambiti della usabilità e della diminuzione del tasso di errore.

Figura 3 - Evoluzione dei modelli matematici per la tecnologia ASR

In Italia i primi esperimenti sono di Luigi Stringa, dell’ELSAG. Mentre le principali attività di ricerca e sviluppo in ambito industriale sono state svolte da:

Olivetti (laboratorio di Torino, chiuso nel 1990) per sistemi di dettatura per PC e Sintesi da testo (VoxPC);

IRST (laboratorio di Trento, dell’Istituto Trentino di Cultura) su sistemi di dettatura e sistemi di dialogo;

CSELT, ora TILAB (a Torino, dal 1975 al 2000, poi confluito in Loquendo) su riconoscimento della voce e sintesi da testo.


2.2.2 Ambiti d'uso

La tecnologia di riconoscimento vocale fornisce supporto per due tipi di attività: l’interpretazione dell’input vocale oppure la sua trascrizione. La prima è utilizzata nelle applicazioni Command and control, dove l'utente fornisce un input (del tipo "Apri browser") per istruire la macchina a compiere determinate azioni. La seconda riguarda la semplice trasformazione della voce in testo; le applicazioni che usano questa attività sono chiamate Dictation.

Le applicazioni di tipo Command and control presentano potenzialità di sviluppo in moltissimi campi, anche se i sistemi operativi in uso nel mondo del personal computing, tutti basati su una interfaccia costruita con la metafora della scrivania, sono decisamente poco utilizzabili con un sistema di comando vocale. Da questo punto di vista il freno all’espansione di sistemi di Command and control nell’uso quotidiano sembrerebbe essere proprio l’intrinseca natura del personal computer come oggi lo conosciamo: solo un drastico cambiamento nei sistemi operativi potrebbe dare impulso a nuovi utilizzi della tecnologia.

Per questo motivo, le applicazioni Command and control hanno fortuna, come si è detto, soprattutto nell’integrazione con sistemi industriali e aziendali più ampi, come succede ormai diffusamente per i servizi di CRM (call center, help desk, operatori telefonici automatici) o in altri ambiti, come il marketing e le vendite (per servizi di telemarketing, teleselling e sondaggi di mercato), nella gestione ordini, nella lettura vocale di posta elettronica e allegati, nella logistica, negli impieghi finanziari e informativi (quotazioni, brokeraggio e home banking) e infine negli ambiti di e-government, come il televoto o il pagamento elettronico.

Lo studio e la parziale realizzazione di uno standard unico, come il Voice Xml (Voice Extensible Markup Language) o il Salt (Speech Application Language Tags) potrebbe espandere le possibilità di utilizzo del riconoscimento vocale, ampliando le possibilità di integrazione anche con sistemi preesistenti.

2.2.3 Command and control

Date le difficoltà di integrazione del comando vocale in un sistema di personal computing che non è orientato al linguaggio, le applicazioni più tipiche dello Speech recognition in modalità Command and control sono i Voice Portal, servizi telefonici in cui gli utenti usano il telefono per ottenere informazioni di vario genere, come quotazioni, risultati sportivi e previsioni del tempo. I Voice Portal, più veloci e flessibili, stanno lentamente sostituendo la generazione di sistemi precedenti, chiamati IVR (Interactive Voice Response) il cui funzionamento prevedeva voci registrate limitando l’interazione all’uso dei toni telefonici (ad esempio: digitare “1 per l'assistenza clienti”, “2 per le vendite e così via”).

Appartengono alla categoria dei Voice Portal le diverse tipologie di portale prodotte da Loquendo e Waycom come Loquendo Virtual Operator: un operatore virtuale di centralino,


che risponde alle chiamate e interagisce con l’interlocutore. Per collegarsi a un interno specifico, è sufficiente pronunciare il nome della persona o dell'ufficio desiderato, eliminando così il problema di conoscere il numero telefonico interno. Per l’utilizzo dei Voice Portal esistono ovvi vantaggi legati alla produttività, primo tra tutti l’ampliamento dei servizi di accoglienza e di centralino a tutto l'arco delle ventiquattro ore e dei giorni festivi.

Per il futuro, si prevede una grande espansione di servizi costruiti su questo concetto, anche in contesti diversi rispetto al telefono, per esempio sul fronte delle intranet attivabili a voce o dei servizi di notificazione.

Altre applicazioni di questo genere, destinate a indubbia fortuna nei contesti più diversi, sono gli E-mail Reader, software che consentono di interrogare la propria casella di posta elettronica attraverso la voce o il telefono, per verificare quante e quali nuove comunicazioni sono arrivate e, mediante la sintesi vocale permettono di farsi leggere quelle di proprio interesse, ricevere la notifica di nuove email e rispondere o inviare messaggi.

Nell'ambito del comando vocale stanno assumendo particolare valore i sistemi di supporto alla navigazione automobilistica. Lo Speech recognition funge da sub-sistema all'interno di un'architettura più ampia, attraverso la quale il guidatore dialoga con il sistema di navigazione automatizzato per pianificare il viaggio.

La statunitense CU-Move (cslr.colorado.edu) porta avanti un progetto che punta a sviluppare algoritmi e tecnologie per un accesso affidabile all’informazione in contesti diversi, per ridurre i problemi legati al rumore di fondo, classificare e distinguere le diverse tipologie di ambienti sonori presentati dall'automobile e per connettere l'automobile a un sistema basato sul Web per reperire suggerimenti per la navigazione automobilistica. La maggior parte dei produttori di sistemi di riconoscimento vocale si sta muovendo in questo campo.

Anche l'e-learning potrebbe trarre vantaggio da questa tecnologia, come in parte già avviene, ma in maniera piuttosto pionieristica, soprattutto per lo studio delle lingue e l'analisi della pronuncia dello studente.

Un progetto italiano, il Munst (Muitilingual Natural Speech Technology, munst.itc.it), portato avanti dall’istituto Trentino di Cultura (Itc) tra gli altri obiettivi punta alla realizzazione di sistemi di traduzione automatica.

Da segnalare infine i progetti che prevedono l’utilizzo del riconoscimento vocale in ambito di Data-mining per estrarre informazioni da archivi audio e video. Alcune importanti aziende si sono cimentate nella realizzazione di motori di ricerca di questo genere ma considerazioni commerciali hanno reso noto che il mercato non è ancora maturo. L’implementazione di un sistema di ricerca di questo genere, qualora i progetti fossero portati a termine, permetterebbe di indicizzare e trovare con facilità, anche in strutture di rete, ogni sorta di filmato e registrazione digitale.

Non mancano le applicazioni per i sistemi di sicurezza: le versioni più evolute dei sistemi di Speech recognition integrano il tracking della voce con la raccolta di dati visivi e sono usati


in maniera crescente all’interno degli impianti di controllo, nel settore che riguarda le nuove tecniche biometriche.

2.2.4 Le applicazioni Dictation

Le applicazioni di tipo Dictation sono il secondo grande campo di battaglia del riconoscimento vocale. Esistono in commercio sistemi di dettatura come Ibrn Via-voice e Scansoft Dragon Naturally Speaking, anche ottimizzati per figure professionali specifiche, come i medici e gli avvocati, il cui lavoro presuppone la stesura di lunghi memoriali e cartelle. In generale, l'uso di questi programmi migliora la velocità di scrittura, dove questi software superano una media di 250 battute al minuto anche al primo utilizzo, senza cioè un periodo di training che può migliorare i risultati complessivi. Al momento, il limite principale delle applicazioni di Dictation è dato proprio dal parlante, poiché l’utilizzo del software prevede una capacità non sempre intrinseca di esprimere linearmente il proprio pensiero. Non mancano i vincoli tecnologici: difficoltà del riconoscimento in ambienti rumorosi o in movimento e la necessità di un addestramento, sia per il software sia per l'utente. I sistemi di digitalizzazione automatica del parlato, possibili in futuro, troverebbero applicazioni pratiche nella produzione televisiva (si pensi a notiziari immediatamente disponibili in forma cartacea) e in ambienti come tribunali, assemblee parlamentari o aule di lezione. dove è fondamentale la trascrizione fedele e immediata dei dibattiti in corso.

2.2.5 Prospettive

I progressi presentati dalle ultime generazioni di software di riconoscimento vocale sono positivi: l’integrazione con input sensoriali di natura diversa, l'ampliamento e la maggiore flessibilità dei vocabolari di riferimento, l’impiego di tecnologie per abbattere i rumori d’ambiente migliorano in modo critico l’efficienza dei sistemi. Malgrado ciò, la tecnologia non è prosperata come ci si poteva aspettare a metà degli anni Novanta.

La responsabilità di questo ritardo si può trovare in parte nella necessità di alcuni miglioramenti: un'integrazione più stretta con le tecnologie per il riconoscimento del linguaggio naturale, maggiore semplicità nella gestione di parole che non si trovano all'interno del vocabolario e l’indifferenza alla pronuncia dei parlanti (la cosiddetta "Speaker's indifference" che è sostanzialmente ancora da acquisire).

In parte la stessa interfaccia bidimensionale degli attuali sistemi di computing rendono la voce una modalità di input valida in determinate circostanze (essenzialmente quando non è possibile o comodo usare le mani) ma non più efficiente della tastiera o di altri sistemi di immissione dati.

Le applicazioni di Command and control o Dictation hanno quindi futuro in ambiti ancora limitati e perlopiù legati alla telefonia. Per lo sviluppo di sistemi rivoluzionari di Speech


recognition, occorre guardare alla frontiera di nuovi progetti complessivi, come il Web semantico (cioè il tentativo di strutturare le informazioni presenti sul Web per un'interrogazione più semplice e vicina al linguaggio naturale, www.w3.org/2001/sw ).

Infine è necessario ancora un raffinamento del feedback: i sistemi tradizionali, di fronte a una frase o parola incomprensibile, rispondono con l’alternativa “Ho capito/Non ho capito” e non consentono di perfezionare la domanda in caso di problemi. Per questa ragione sono allo studio anche le innovazioni dei sistemi di risposta, che prevedono tra l'altro l'evoluzione di una tecnologia parallela: la sintesi vocale.

2.3 Sintesi del parlato

Generazione Sintesi Vocale

Segnale Acustico

TestoSignificato

Figura 4 - Modalità di sintesi del parlato

La sintesi del parlato (in inglese Text To Speech) è la generazione automatizzata delle forme d’onda che costituiscono una voce.

Prima che la ricerca tecnologica mettesse a punto dei "chips" specializzati per la produzione di linguaggio sintetico (nel 1978), il parlato sintetico era generato da computer interfacciati alle volte con un modello analogico del tratto vocale.

Oggi, strumenti per la sintesi del parlato, sono disponibili anche come software a basso costo per i Personal Computer. Questa recente diffusione è dovuta, in parte, al progresso tecnologico dei circuiti integrati, ma anche al miglioramento nella metodologia per la produzione del parlato sintetico.

La sintesi del parlato realizzata dagli "speech synthesizer" è un processo che converte un testo in ingresso, che consiste di parole o di frasi, in una forma d’onda, usando algoritmi specializzati e blocchi di forma d’onda vocali, precedentemente preparati. I sintetizzatori del parlato possono essere caratterizzati a seconda delle unità del parlato che essi mettono insieme in uscita (output), oppure a seconda dei metodi utilizzati per la codifica, la catalogazione, e la sintesi del parlato. Utilizzando un buon numero di unità di parlato, come successioni di parole o frasi, si può avere in uscita un parlato sintetico di buona qualità, ma questo processo richiede che il sistema possieda una grande quantità di memoria. Metodi efficienti di codifica riducono il bisogno di memoria, ma molto spesso, degradano la qualità del parlato.


I sintetizzatori del parlato in commercio, sono di due tipi: sistemi cosidetti "Voice Response" e sistemi "Text-to Speech".

I sistemi "Voice Response" maneggiano, in input, testi con vocabolario e sintassi limitati, riproducendo messaggi vocali direttamente dal parlato precedentemente codificato, e utilizzando principalmente tecniche di processo di segnali. Questi sistemi sono fondamentalmente codificatori del parlato che raccolgono i loro campioni nella memoria del computer per utilizzarli attraverso un decoder, quando è necessario il parlato sintetico.

I sitemi "Text-to Speech", accettano invece tutti i tipi di testo. Questi ultimi sistemi costruiscono il parlato dal testo, si basano su piccole unità di parlato in memoria e un intenso processo linguistico.

3 Le piattaforme vocali

IVR e Voice Portal

Piattaforme vocali VoiceXML

Le soluzioni di mercato

3.1 Introduzione Come già detto le piattaforme vocali sono quei sistemi di hardware e di software in grado di sostenere un’interazione vocale con le persone. Si parla di piattaforme, in particolare, nel caso di sistemi destinati all’automazione di servizi telefonici.

Per il canale telefonico si possono distinguere due categorie principali. La prima è rappresentata dai sistemi detti IVR, la seconda da tutti i sistemi che a vario titolo rifiutano la definizione di IVR preferendo la definizione di Voice Portal.

L’inclusione in una data categoria di ciascun sistema, viene risolta, in ambito commerciale, valutando alcune loro caratteristiche funzionali. Tra queste quelle più discriminanti sono, di fatto, la capacità di utilizzare le tecnologie di ASR e TTS.

3.1.1 I sistemi IVR

L’acronimo IVR significa Interactive Voice Response, ossia “risposta vocale interattiva”. Questa definizione letteralmente sarebbe adatta a rappresentare tutti i sistemi vocali, mentre, in pratica, per motivi sostanzialmente storici, con questo acronimo si indicano i risponditori automatici per la telefonia che utilizzano come canale di input i toni telefonici (DTMF), e rispondono all’utente attraverso composizioni di messaggi pre-registrati. Questo si spiega semplicemente con il fatto che i sistemi IVR sono più vecchi delle tecnologie vocali TTS e ASR, nella loro forma commercializzabile.

3 – L E P I A T T A F O R M E V O C A L I 2 0

Una definizione di IVR è la seguente: “una tecnologia telefonica per la quale un utente utilizza i toni telefonici per interagire con una base di dati per acquisire informazioni o inserirvi dati”.

Quella che segue è invece la definizione proposta da Webopedia, un dizionario online per le definizioni legate ai computer ed ad Internet ( www.webopedia.com ).

“Short for Interactive Voice Response, a telephony technology in which someone uses a touch-tone telephone to interact with a database to acquire information from or enter data into the database. IVR technology does not require human interaction over the telephone as the user's interaction with the database is predetermined by what the IVR system will allow the user access to. For example, banks and credit card companies use IVR systems so that their customers can receive up-to-date account information instantly and easily without having to speak directly to a person. IVR technology is also used to gather information, as in the case of telephone surveys in which the user is prompted to answer questions by pushing the numbers on a touch-tone telephone.”

Le aziende produttrici normalmente dichiarano in modo esplicito l’appartenenza o meno dei propri prodotti alla categoria degli IVR. Ma oggi la tendenza di molti produttori di sistemi nati come IVR, è quella di cercare di introdurre nelle loro architetture, il supporto delle tecnologie TTS ed ASR. L’obiettivo è chiaramente quello di non perdere le quote di mercato che i sistemi più recenti promettono di sottrae loro. L’offerta di Cisco e HP, ad esempio, sta seguendo questo percorso. Il prodotto “Cisco IP IVR” distribuito da HP, è nato come sistema IVR, ma può oggi integrare i motori di TTS e ASP prodotti da Nuance, e dispone di un interprete VXML. Questo gli permette, quindi, di presentarsi sul mercato come piattaforma vocale VXML.

Le infrastrutture tecnologiche e le architetture software su cui sono nati questi sistemi sono in massima parte precedenti alla diffusione di Internet. Per questo motivo le aziende che per prime hanno voluto offrire sul mercato sistemi automatici per la telefonia, in assenza di una tecnologia standard, consolidata e diffusa, hanno progettato e sviluppato soluzioni verticali, il più delle volte utilizzando tecnologie e protocolli proprietari.

Sostanzialmente in assenza di motori di TTS ed ASR affidabili, le soluzioni tecnologiche, che sono state sfruttate dai sistemi IVR, sono sostanzialmente due:

la capacità di gestire ed inviare verso l’utente messaggi pre-registrati

la capacità di acquisire i toni DTMF inviati dall’utente.

Il primo obiettivo di questi sistemi è stato quello di realizzare centralini telefonici evoluti. Con un sistema IVR il centralino automatico può rispondere alle telefonate e gestire una “conversazione” con l’utente, realizzando alcune semplici funzioni:

gestire le code di chiamate in ingresso

interrogare l’utente e smistare la chiamata secondo le sue risposte


fornire informazioni predefinite

Utente Telefonico

SistemaIVR

Benvenuto…Per ascoltare i messaggi digiti “1"...

“1”

Messaggio ricevuto il...

[Riproduzione del messaggio]

“6”

Per ascoltare il messaggio successivo , digiti “6”...

Non ci sono altrimessaggi

Figura 5 - Esempio di appicazione vocale con IVR

L’architettura di questi sistemi è incentrata sulla presenza e le caratteristiche dalle schede (hardware) che gestiscono fisicamente le linee telefoniche. Le funzionalità offerte da queste ultime, determinano le capacità ed i limiti dei sistemi IVR.

IVR

Back-End

Funzioni di lettura e scrittura

Codice Proprietario

Utente Telefonico

CentralinoTelefonico

Programmazione del centralino

Figura 6 – Canali di comunicazione con l’esterno dei sistemi IVR


In sintesi i sistemi IVR offrono:

Servizi vocali solo via DTMF

Ambiente di sviluppo proprietario

3.1.2 I Voice Portal

Il termine “Voice Portal” è direttamente derivato da “Web Portal”. Per una sua definizione si è fatto riferimento al sito Webopedia, la cui dicitura si ritiene condivisibile:

“Commonly referred to as simply a portal, a Web site or service that offers a broad array of resources and services, such as e-mail, forums, search engines, and on-line shopping malls. […].”

Con il temine Portale Web si indicano cioè in modo generalizzato, i siti Internet che offrono, attraverso le loro pagine, gli insiemi più vari di servizi, risorse e contenuti.

I Portali Vocali possono rappresentare la trasposizione di questo tipo di offerta sul canale telefonico. Questo però non esclude che il canale vocale possa essere semplicemente un ulteriore canale per interagire con le pagine del sito Web. Questo ultimo, ad esempio, è il principale obbiettivo dello standard SALT, “concorrente” del VXML, che persegue l’idea della comunicazione multimodale; quando, cioè, più modalità di input/output sono integrate all’interno della stessa interfaccia.

Figura 7 - Interazione multimodale

Bisogna notare che con il temine Voice Portal non si indica una particolare tecnologia, ma piuttosto un obbiettivo ambizioso, che per contro si realizza solo con la disponibilità di una serie di tecnologie specifiche per il vocale.

“In its most generic sense a voice portal can be defined as "speech-enabled access to Web-based information." In other words, a voice portal provides telephone users with a natural-language interface to access and retrieve Web content. An Internet browser can provide


Web access from a computer but not from a telephone. A voice portal is a way to do that. (http://www.iec.org/online/tutorials/voice_portal/)”

Per quanto detto, un sistema pensato per gestire un Portale Vocale prevede una forte dipendenza dall’architettura del mondo Web, dovuta alla necessità di una forte integrazione con questo ultimo. Anche nel caso in cui il Portale sia esclusivamente destinato al canale telefonico, nel parlare di Portale Vocale, si sottintende normalmente che l’architettura del sistema si integra in modo naturale con il mondo Web.

L’integrazione, come vedremo, avviene sostanzialmente nella parte di definizione dei contenuti e della logica di navigazione, attraverso l’utilizzo di un linguaggio che utilizza lo stesso protocollo di comunicazione di Internet, come ad esempio il VXML che, come l’HTML delle pagine Web, utilizza il protocollo http.

Il vantaggio sostanziale è che la generazione e gestione dei contenuti può sfruttare a pieno quanto di meglio è fino ad ora già stato sviluppato per il Web, in tutti i suoi aspetti: architetture, hardware e software, con la possibilità di sfruttare tutte le competenze tecniche di chi opera nel mondo Web.

In sintesi i sistemi Voice Portal offrono:

Servizi vocali con voce e DTMF

Ambiente di sviluppo standard, in particolare quelli VXML

3.2 Piattaforme vocali VoiceXML Le piattaforme vocali VoiceXML, appartengono alla categoria delle piattaforme destinate alla gestione dei Voice Portal.

La specifica VXML definisce e vincola in modo inequivocabile la modalità di interazione con le piattaforme vocali che adottano questo standard, di conseguenza il comportamento e l’architettura del nostro framework potrà essere completamente indipendente dalla scelta di un determinato produttore.

Volendo analizzare e commentare l’architettura di una piattaforma vocale VXML, possiamo fare quindi una scelta arbitraria, ad esempio considerando la piattaforma Voxnauta di Loquendo.

3.2.1 Architettura fisica

Riportiamo come esempio le specifiche tecniche della piattaforma vocale Voxnauta (www.loquendo.com/it/products/voxnauta_architecture.htm).


Tabella 1 - Specifiche tecniche della piattaforma Voxnauta

VoiceXML 2.0 Vocal Browsers

HTML (proprietary format)

EURO ISDN E1-DSS1 Nortel DMS-100 ISDN

AT&T 4ESS ISDN; AT&T 5ESS ISDN

Standard Telephony Support

US National ISDN 2

Platform configuration and service provisioning systems, which include an automatic service provisioning interface for content delivery. SNMP Agent for all the hardware and software components. Integrated SNMP Manager for operating status supervision. Automatic service usage data collection: • Call details • Requested contents • Advertising banners • Charging criteria following specific content. Relational Database for data storage (Microsoft SQL Server).

Management

Optional centralized management for multi-platform configurations. Web based Service creation modules. Service Creation

Environment VoiceXML and HTML conversion to vocal service specific tools. Optional features: Genesys™ Call Center integration. Conference Call support. Advertising Service. Outbound Call support.

Advanced Features

Included features: Automatic time synchronization.

Technical Assistance Standard hardware component use. Hardware and Software technical assistance Additional Service Level Agreement available for specific needs

LAN Connectors 100BaseT Fast-Ethernet RJ-45

Telephonic Interfaces RJ48C – 120


Inbound, Outbound, Bi-directional Telephonic Front End configuration features Call transfer during voice browsing

sessions ISDN, DSS1, ISUP Supported Standards

HTTP, SQL, SMTP, SNMP, LDAP, ODBC

Leggendo le specifiche di questa piattaforma si può notare che non ci sono riferimenti alle infrastrutture hardware e software necessarie alla piattaforma per la sua istallazione. Questo si spiega con la scelta del produttore, di fornire la piattaforma come una “black-box”, ossia come un sistema isolato ed indipendente. Le specifiche, infatti, definiscono in modo accurato esclusivamente i protocolli accettati delle interfaccie del sistema: lato client verso i centralini telefonici e, lato server, indicando i protocolli supportati per l’integrazione delle funzioni di business logic esterne.

In ogni caso l’indicazione di Microsoft SQL Server come base dati di sistema, tradisce la presenza internamente di una architettura Windows. Si tratta infatti di una piattaforma basata su piattaforma Windows 2000 Server.

In sostanza l’architettura fisica di questa piattaforma può essere rappresentata da un unico blocco con due canali di comunicazione verso l’esterno, da una parte verso la rete telefonica e dall’altra verso il back-end.

Piattaforma Vocale

Back-End

Figura 8 - Architettura fisica di un sistema con piattaforma vocale


In questo modello viene in realtà trascurato il canale di amministrazione della piattaforma che utilizza il canale e l’architettura del web.

3.2.2 Architettura logica

L’osservazione dell’architettura logica può essere più interessante, perché ci permette di chiarire la posizione ed il significato del framework all’interno dell’architettura del sistema.

Il cuore dell’architettura logica delle piattaforme vocali è costituito da quattro elementi, come rappresentato in Figura 9: un elemento che rappresenta l’interfaccia verso la rete telefonica, uno rappresenta il motore di “Text To Speech”, un altro il motore di “Automatic Speech Recognition” ed in fine il “VXML Browser”.

Piattaforma Vocale VXML

TTS

ASR

VxmlBrowser

SchedaTelefonica

Voce di sintesi

Voce dell’utente

http response

http request

Figura 9 - Architettura logica di una piattaforma vocale VXML

Lo schema evidenzia il processo di trasformazione dell’informazione da voce in testo (VXML) e viceversa. Il VXML è, al pari dell’HTML, un linguaggio di markup, inoltre l’architettura logica appena descritta presenta come interfacce di comunicazione da un lato il canale vocale verso l’utente telefonico, dall’altro un canale http verso un web server. Il comportamento complessivo è, di conseguenza, del tutto assimilabile ad un comune browser web, dove però, l’interfaccia utente è di tipo vocale e l’elaborazione delle pagine del sito (l’applicazione vocale) viene eseguita in maniera centralizzata dalla piattaforma, per conto di tutti i client telefonici connessi.

L’elaborazione centralizzata del browsing di ogni client è obbligata dal fatto che i telefoni, almeno quelli di telefonia fissa, non possiedono alcuna capacità di calcolo, ossia non sono pensati per poter ospitare alcun tipo di browser. Ma anche i telefoni cellulari più recenti continuano a non essere sufficientemente potenti da poter ospitare un browser vocale con le


caratteristiche di Voxnauta. Ma è chiaramente solo questione di tempo. La stessa Loquendo, ad esempio, sta attualmente lavorando su prototipi di suoi motori di TTS per PocketPC.

Piattaforma Voxnauta

TTS

ASR

VxmlBrowser

SchedaTelefonica

Voce di sintesi

Voce dell’utente

http response

http request

VXML

ApplicationServer

Figura 10 - Architettura logica della piattaforma Voxnauta

La piattaforma Voxnauta, come già detto, si propone sul mercato come “black-box”, ossia come un sistema “chiuso” che realizza in modo autonomo tutto il processo per l’erogazione di un servizio telefonico. Per questo la sua architettura logica può essere completata come descritto in Figura 10.

Questo schema presenta un elemento in più, indicato come “Application Server”. Il suo compito è quello di gestire i documenti (o pagine) VXML, che definiscono le applicazioni vocali. Nel caso di Voxnauta questo elemento è implementato da un Microsoft Internet Information Server.

Con l’introduzione del framewok si intende, in pratica, soppiantare il ruolo di questo componente.

Piattaforma Vocale VXML Framework Back-end

Voce di sintesi

Voce dell’utente

http response

http request

TCP/IP

“client” server

Figura 11 - Posizione del framework nell'architettura


Il risultato è che, con riferimento alla tradizionale architettura client-server, il ruolo della piattaforma si riduce alla gestione del livello di presentazione (client), mente il framework prende in carico il livello di gestione della logica, sia di navigazione che di gestione dei contenuti (server).

3.2.3 Il VoiceXML

Il contenuto di questo paragrafo è stato estratto dalle “W3C Recommendation” per il “Voice Extensible Markup Language (VoiceXML) Version 2.0” del 16 March 2004 (www.w3.org/TR/voicexml20/). Una “W3C Recommendation” è una specifica o insieme di linee guida; le “W3C Recommendation” sono simili agli standard pubblicati da altre organizzazioni.

Il VoiceXML è un linguaggio basato sul formalismo XML. Gli esempi che seguono vogliono semplicemente mettere in evidenza questo aspetto.

Vediamo due esempi di codice VoiceXML. Il primo di questi è il classico “Salve Mondo”:

<?xml version="1.0" encoding="UTF-8"?>

<vxml xmlns="http://www.w3.org/2001/vxml"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.w3.org/2001/vxml

http://www.w3.org/TR/voicexml20/vxml.xsd"

version="2.0">

<form>

<block>Salve Mondo!</block>

</form>

</vxml>


L’elemento di livello più alto è il tag <vxml>, che è principalmente un contenitore per i “dialoghi”. Ci sono due tipi di dialoghi: forms e menus. Le “form” presentano informazioni e raccolgono input; i “menu” offrono la scelta dell’azione successiva. Questo esempio contiene una singola form che genera la sintesi e presenta le parole “Salve Mondo!” all’utente. Dato che questa form non indica un dialogo successivo, la conversazione termina.

Il secondo esempio chiede all’utente di scegliere una bevanda e invia la scelta al server:






version="2.0">

<form>

<field name="drink">

<prompt> Vuoi caffè, tea, latte o nulla?</prompt>

<grammar src="drink.grxml" type="application/srgs+xml"/>

</field>

<block>

<submit next="http://www.drink.example.com/drink2.asp"/>

</block>


</form>

</vxml>

Un field è in campo di input. L’utente deve fornire un valore per il campo prima che sia processato il passo successivo. Un esempio di interazione è:

C (computer): Vuoi caffè, tea, latte o nulla?

P (persona): Succo di frutta.

C: Non capisco cosa hai detto. (messaggio predefinito sulla piattaforma vocale)

C: Vuoi caffè, tea, latte o nulla?

P: Tea

C: (continua con il documento successivo: drink2.asp )

Il tag <grammar> indica l’indirizzo di un file (drink.grxml) che contiene la grammatica, ossia l’elenco delle parole valide, in questo caso ad esempio: “caffè”, “tea”, “latte” e “nulla”.

Data l’enorme importanza delle “W3C Recommendation” nei confronti delle scelte e dei contenuti di questo progetto, ne è stato allegato in appendice un estratto più ampio.

3.3 Le soluzioni di mercato

3.3.1 Gli standard

La maggior parte delle società impegnate nella ricerca di sistemi standard per la traduzione della voce si sono riunite nel Voice Xml Forum, il cui obiettivo è la creazione e promozione di un modello unificato per le applicazioni di riconoscimento vocale basato sull'Xml, chiamato appunto Voice Xml (Voice Extensible Markup Language). Il Voice Xml Forum vede la partecipazione di circa 600 membri, che comprendono At&t, Lucent, Ibm e Motorola. Nell'ottobre del 2001, il World Wide Web Consortium (W3C) ha formalmente accettato lo standard Voice Xml, allo scopo di produrre applicazioni Web-based di riconoscimento vocale, accessibili attraverso le linee telefoniche. Contemporaneamente, un gruppo di aziende che comprende Cisco, Comverse, Intel, Microsoft e in passato anche Philips e SpeechWorks (ora legate a ScanSoft) si sono riunite nel Salt Forum (www.saltforum.org) con l'obiettivo di creare un secondo standard apparentemente non in competizione con il primo. Nelle dichiarazioni di intenti, Voice Xml dovrebbe trovare il suo sviluppo nella telefonia mentre Salt (Speech Application Language Tags) avrebbe applicazioni in tutto il resto.


3.3.2 I protagonisti

Le principali società impegnate nel settore del riconoscimento e sintesi del parlato sono SpeechWorks, Nuance, Scansoft, Ibm e Loquendo.

SPEECHWORKS (www.speechworks.com), società americana con sede a Boston, attualmente in trattative per la fusione con ScanSoft, si è specializzata nella realizzazione di Voice Portal e applicazioni per i service provider che utilizzano tecnologie di riconoscimento, sintesi e verifica vocale. È stata tra le prime a portare sul mercato prodotti basati su standard Voice Xml e a studiare, assieme alle tecnologie di rete, tecnologie embedded per dotare di riconoscimento vocale le automobili, i sistemi di intrattenimento domestico, i device mobili e i cellulari.

NUANCE (www.nuance.com) si occupa di riconoscimento e sintesi vocale, autenticazione della voce e prodotti per il browsing vocale, prevalentemente attraverso il telefono, rivolgendosi a imprese e società di telecomunicazione. Fondata nel 1994 in California ha commercializzato il primo motore di riconoscimento vocale sviluppando un sistema industriale su larga scala per la Charles Schwab Corporation..

SCANSOFT (www.scansoft.com) attualmente in forte espansione, è un partner recentemente entrato sulla scena del riconoscimento vocale con una serie di acquisizioni e alleanze. Si occupa tanto di software di imaging quando di riconoscimento vocale. Suo è il software Dragon NaturallySpeaking, al momento tra le migliori applicazioni consumer nel settore Dictation e Command and control. Scansoft sviluppa soluzioni di automatizzazione, applicazioni per la gestione dei documenti personali e per la progettazione di moduli elettronici.

PHILIPS. La Telephony and Voice Control Business Unit di Philips dedicata al riconoscimento vocale (www.speech.be.philips.com) per più di quaranta anni attiva nella ricerca sulla dettatura, la trascrizione e il riconoscimento vocale, è stata acquisita nel gennaio 2003 da Scansoft. Oltre alla telefonia, si occupa di controllo vocale per automobili, dispositivi mobili ed elettronica di consumo.

IBM Voice System, business unit di IBM dedicata al riconoscimento vocale e produttrice, tra l'altro, dei noti software ViaVoice e WebSphere è impegnata da oltre quaranta anni nella ricerca e realizzazione di oltre 150 brevetti software. Al momento, circolano voci non ufficiali di una sua possibile acquisizione.

LOQUENDO. Tra le aziende italiane, si segnala Loquendo (www.loquendo.com), società di Telecom Italia con sede a Torino, nata nel 2001; propone soluzioni per la realizzazione di servizi vocali, l'automazione di Call Center, l'introduzione del canale vocale nelle applicazioni di Crm, Intranet e Unified Messaging e la creazione di soluzioni di infomobilità.

WAYCOM. La ligure Waycom (www.waycom.it) offre alle aziende servizi per internetworking, messaging e telefonia computerizzata, compresa la realizzazione di Voice


Portal e altri strumenti software per dare "voce" alle aziende e alle applicazioni gestionali, utilizzando come media il telefono.

4 Gli obiettivi del framework

Introduzione

Obiettivi dei finanziatori

Obiettivi dei commerciali

Obiettivi degli sviluppatori

Obiettivi degli utilizzatori

Esempi di riferimento

4.1 Introduzione Per la definizione degli obiettivi di progetto si procede alla descrizione di un contesto reale di riferimento. Si è considerato lo scenario in cui un’azienda produttrice di software decida di investire nella realizzazione di un prodotto software per la realizzazione di applicazioni vocali. Il processo di produzione prevede che si definiscano innanzitutto gli obiettivi del progetto.

Per rispettare questo scenario e per migliorare l’organizzazione della trattazione, nei capitoli successivi ed in particolare nella seconda parte del documento, si farà riferimento alla definizione di un processo per la progettazione e contestuale documentazione del software. Il processo scelto è una forma semplificata del RUP (Rational Unified Process).

La modalità con cui si arriva alla definizione degli obiettivi di un progetto software non viene di solito considerata come parte del processo di produzione. I processi come il RUP, nella forma più semplice, considerano come punto di partenza del progetto due tipi di

4 – G L I O B I E T T I V I D E L F R A M E W O R K 3 4

documento: gli “Stakeholder Requests” e la “Vision” (o “Product Requirement Document”). Entrambi questi tipi di documento, raccolgono una descrizione molto generale del progetto, dove i vincoli sono costituiti principalmente dalle esplicite richieste dei finanziatori. In questo capitolo si cerca di ricostruire le fasi e le considerazioni che precedono la stesura di questi documenti.

Per la definizione degli obiettivi, si considerano i diversi punti di vista degli attori coinvolti dalla realizzazione di un simile progetto e dal suo utilizzo finale.

Si possono dividere gli attori coinvolti in quattro gruppi: finanziatori, commerciali, sviluppatori e utilizzatori.

FINANZIATORI. Si tratta dell’ente, società o persone che finanziano il progetto. Il contributo diretto, di questi attori, nella definizione degli obiettivi è tipicamente molto piccolo, ma il peso del loro giudizio è, per ovvi motivi, molto alto.

COMMERCIALI. Sotto questa voce si raggruppano, per semplicità, il marketing ed i venditori. Gli attori di questo gruppo sono normalmente i promotori ed i responsabili dell’idea di fondo del progetto. Gli obiettivi proposti da questo gruppo possono costituire lo scheletro di partenza per i requisiti funzionali.

SVILUPPATORI. Sono gli analisti, i progettisti e gli sviluppatori che partecipano alla realizzazione del progetto. Nella definizione degli obiettivi il loro intervento è limitato alla necessità di accertarne la fattibilità.

UTILIZZATORI. Questa voce raccoglie un insieme di attori che nella fase di definizione degli obiettivi, risulta inevitabilmente difficile da definire, essendo essi stessi parte della definizione. Per questo il loro contributo è molto piccolo.

Per ognuno di questi gruppi si è voluto riassumere i concetti da loro espressi direttamente o indirettamente nel corso di incontri formali e non; con scambi di idee, opinioni ed esperienze.

L’unione di questi concetti costituirà l’elemento di confronto per la misura della validità della soluzione formulata dall’autore.

4.2 Obiettivi dei finanziatori [Ob1.1] - “Realizzare un prodotto software che permetta di abbattere il costo di

realizzazione di applicazioni vocali per piattaforme vocali quali Voxnauta di Loquendo”

[Ob1.2] - “Questo software deve essere orientato al mercato delle piattaforme vocali per la realizzazione dei servizi telefonici automatici”

[Ob1.3] - “Il prodotto deve costituire una valida alternativa agli attuali strumenti per la realizzazione delle applicazioni vocali”


Attualmente, in Italia, la piattaforma che offre le migliori prestazioni in termini di TTS ed ASR è la piattaforma Voxnauta di Loquendo. Il motivo principale è il fatto che l’azienda è italiana e di conseguenza ha sviluppato con particolare attenzione i dizionari e modelli fonetici per la lingua italiana. Altri produttori, come Nuance ad esempio, offrono engine TTS ed ASR altrettanto validi, ma non nel caso della lingua italiana.

La piattaforma Voxnauta rappresenta quindi il mercato riferimento. Per realizzare una applicazione vocale per questa piattaforma, Loquendo stessa offre la propria consulenza professionale e richiede in ogni caso il controllo delle attività sulla piattaforma. Di conseguenza, se il cliente non possiede le necessarie competenze techiche, anche la semplice modifica di un testo, contenuto nella descrizione dell’applicazione, richiede l’intervento del produttore, con un costo generalmente non trascurabile.

Si richiede quindi la realizzazione di uno strumento che, una volta fornito al cliente che utilizza la piattaforma, gli permetta di gestire, con la massima autonomia possibile, la creazione e la modifica dei servizi telefonici che intende erogare attraverso la piattaforma.

4.3 Obiettivi dei commerciali [Ob2.1] - “Il software deve poter essere usato da personale senza competenze

tecniche e di programmazione”

[Ob2.2] - “Il sistema deve essere web-based”

[Ob2.3] - “Il target del prodotto sono le grosse aziende in grado di sostenere l’investimento necessario all’acquisto di una piattaforma vocale”

[Ob2.4] - “Si deve prevedere la possibilità di fornire il prodotto come servizio in affitto”

[Ob2.5] - “Il sistema deve essere scalabile rispetto al numero di applicazioni vocali che deve gestire, sia in fase di sviluppo, sia in fase di esecuzione”

[Ob2.6] - “Il sistema dovrebbe utilizzare convenzioni e terminologie familiari agli utenti, sfruttando ad esempio le possibili analogie con il web”

[Ob2.7] - “Considerare che gli acquirenti delle piattaforme vocali hanno molto probabilmente già avuto esperienze con sistemi IVR”

L’acquisto di una piattaforma Voxnauta, che abbiamo preso in precedenza come riferimento di mercato, rappresenta per un’azienda un investimento non indifferente. In pratica solo le grosse aziende o aziende che fanno dei servizi telefonici la propria fonte profitto rientrano nel target di questo tipo di piattaforme.

Uno strumento pensato per interagire con una piattaforma vocale deve quindi tener conto della complessità e delle aspettative di questo tipo di aziende, in cui dovrà operare. Gli obiettivi elencati rispecchiano questa attenzione.


4.4 Obiettivi degli sviluppatori [Ob3.1] - “I componenti software del sistema devono essere indipendenti dalla

piattaforma di riferimento”

[Ob3.2] - “Il codice deve essere portabile ed adatto alla complessità delle architetture dei sistemi informativi dei clienti”

[Ob3.3] - “Porre attenzione alla separazione tra le fasi di sviluppo dell’applicazione vocale e la sua esecuzione”

[Ob3.4] - “Per la realizzazione prediligere l’utilizzo di framework ed architetture riconoscibili e consolidate”

Anche gli obiettivi degli sviluppatori come quelli commerciali devono tenere in particolare considerazione le complessità delle infrastrutture informatiche con cui dovrà interagire il sistema.

4.5 Obiettivi degli utilizzatori [Ob4.1] - “Sarebbe utile poter intervenire sui contenuti dell’applicazione vocale

senza dover richiedere l’intervento di un tecnico”

[Ob4.2] - “L’accesso all’utilizzo del sistema deve essere controllato e sicuro”

[Ob4.3] - “Ciò che viene prodotto dal sistema è implicitamente e formalmente corretto”

Questo elenco rappresenta solo un accenno di quello che è, tipicamente, il punto di vista dell’utilizzatore del sistema. Quello che si vuole evidenziare è che di fronte all’opportunità di definire uno nuovo strumento, in genere l’utilizzatore (non tecnico) non riesce a contribuire con delle specifiche particolarmente significative.

4.6 Esempi di riferimento Sono stati selezionati alcuni esempi di applicazioni vocali, da utilizzare nel corso della trattazione.


4.6.1 “Servizio notte”

Si tratta di un servizio telefonico automatico che viene inserito alla chiusura degli uffici e disinserito alla loro apertura. Il servizio deve fornire informazioni come ad esempio l’orario dell’ufficio, il numero del FAX o situazioni di anomalia come la condizione di sciopero.

Questo tipo di servizi rientra nel caso delle “informative generali”, ossia servizi telefonici che si limitano a fornire una serie di informazioni statiche o a “bassa variabilità”, ed organizzate secondo uno schema predefinito. Utilizzeremo questo caso come esempio di “applicazione vocale statica”.

4.6.2 “Rubrica Aziendale”

Implementazione di una rubrica telefonica aziendale. Questo caso, semplice nella composizione della logica e dei contenuti, è significativo dal punto di vista delle implicazioni tecniche, se i dati che compongono la rubrica sono contenuti in una base dati.

Questa applicazione vocale verrà utilizzata per esemplificare il meccanismo di interrogazione, e più in generale di integrazione, dei sistemi informativi esterni. Utilizzeremo questo caso come esempio di “applicazione vocale dinamica”.

5 “Vision” della soluzione

Logica di business

Tecnologia

Architettura fisica

Architettura logica

Organizzazione dell’informazione per il vocale

Modello per la rappresentazione interna

Si tratta ora di definire e progettare una soluzione software in grado di soddisfare tutti gli obbiettivi identificati nel capitolo precedente. In questo capitolo viene descritta ad alto livello questa soluzione.

5.1 Logica di business Sono qui definiti gli scenari di utilizzo previsti dalla soluzione. Innanzitutto sono definiti i ruoli in cui si possono dividere gli attori del gruppo “Utenti”. Per la definizione della terminologia si è scelto di utilizzare la metafora del sistema di web publishing [Ob2.6]. Per la definizione della logica di business, infatti, l’analogia con i sistemi di publishing (quelli per le aziende) può essere pressoché completa. Come sarà evidenziato in seguito, questa scelta è giustificata anche dagli aspetti tecnologici e di architettura. Questi sistemi di web publishing sono anche noti come Content Manager System.

5 – “ V I S I O N ” D E L L A S O L U Z I O N E 3 9

CONTENT MANAGER SYSTEM (WEB PUBLISHING). Una definizione possibile è la seguente:

“Applicazione che permette ad un utente di aggiungere e/o modificare contenuti per un sito web. Tipicamente un CMS è costituito da due elementi: il Content Management Application (CMA) e il Content Delivery Application (CDA). Il CMA permette al content manager o all’autore, che possono non conoscere l’HTML, di gestire la creazione, la modifica e l’eliminazione dei contenuti dal sito web senza la necessità di avere le competenze di un web master. Il CDA utilizza e processa quelle informazioni per aggiornare il sito web.”

Lo scopo ultimo di un tale sistema è dunque quello di gestire l’intero ciclo di vita di oggetto informativo secondo il processo tipico di una redazione, ad esempio: un autore realizza il contenuto informativo, un revisore lo verifica e ne decide la pubblicazione.

A seconda delle esigenze, ogni redazione può definire gli stati, le figure professionali e le attività come ritiene opportuno. I software in commercio assecondano queste esigenze fornendo gli opportune funzionalità, principalmente:

Un editor adeguato alla tipologia di content che si desidera trattare

Un motore di workflow in grado di gestire la macchina a stati che sovrintende al ciclo di vita

Un meccanismo di autenticazione/autorizzazione in base ai ruoli che le figure professionali ricoprono all’interno della redazione

Un repository che gestisce la persistenza dei content

5.1.1 I Ruoli

Gli utenti del nostro sistema si dividono innanzitutto rispetto al canale utilizzato per interagire con il sistema stesso. Ricordiamo che lo scopo del sistema è quello di permettere la creazione e l’esecuzione di applicazioni vocali, di conseguenza i canali di interazione con il sistema sono sostanzialmente due: da una parte le interfacce di amministrazione del sistema; dall’altra il canale telefonico, attraverso il quale agiscono gli utenti delle applicazioni vocali.


Utenti delle interfaccedi amministrazione

Utenti telefonici

Sistema

Figura 12 - Canali di interazione con il sistema

Per Interfacce di Amministrazione si intende l’insieme completo delle interfacce di utilizzo, gestione e configurazione del sistema. Queste interfacce secondo l’indicazione dell’obbiettivo [Ob2.2] devono essere web-based, ossia costituite da pagine accessibili via browser web.

Gli utenti del canale telefonico rappresentano gli utenti finali del sistema, ossia i fruitori dei servizi telefonici implementati dalle applicazioni vocali. In seguito indicheremo questo gruppo semplicemente come “Utenti Telefonici”.

UTENTI TELEFONICI. Questi attori sono coinvolti solo indirettamente dalle scelte di progetto. Il motivo è che essi sono utenti solamente del “risultato” dell’utilizzo del sistema, rappresentato dall’esecuzione delle applicazioni vocali. Gli Utenti Telefonici non sono tenuti a conoscere il processo che ha portato alla realizzazione del servizio che stanno utilizzando. Gli Utenti Telefonici sono, in altre parole, gli utenti di ciò che viene prodotto dal sistema, prodotto che in seguito sarà sempre indicato come “Applicazione Vocale”.

Sistema

Utenti delle interfaccedi amministrazione

Utenti telefonici

Ambientedi sviluppo Applicazioni

Vocali

Figura 13 - Scomposizione del sistema rispetto ai canali di interazione


Gli utenti delle interfacce di amministrazione del sistema, facendo riferimento ai sistemi di web publishing ad uso aziendale, possono essere così suddivisi: Amministratori, Disegnatori, Autori, Tecnici.

AMMINISTRATORI. Sono le persone incaricate della gestione dei diritti di accesso e dell’assegnazione dei ruoli. Gli utenti amministratori hanno l’accesso e il controllo completo al sistema e nel caso specifico sono gli utenti che decidono la creazione di una nuova Applicazione Vocale.

DISEGNATORI. Nei sistemi di publishing i disegnatori si occupano del disegno, della struttura e in generale della grafica delle pagine che compongono il sito web. In questo contesto non ha chiaramente senso parlare di grafica dell’Applicazione Vocale, per contro così come per i siti web i disegnatori definiscono l’organizzazione delle pagine e dei loro contenuti, nel caso delle Applicazioni Vocali il Disegnatore dovrà occuparsi di definire la struttura e la dinamica della conversazione tra Utente Telefonico e piattaforma vocale.

AUTORI. Si occupano della definizione dei contenuti dell’Applicazione Vocale. I contenuti per il canale vocale sono sostanzialmente diversi da quelli per il canale web, questo significa che le competenze di un “Content Manager” non sono automaticamente trasferibili nel contesto delle Applicazioni Vocali, ma il ruolo è sostanzialmente lo stesso. Per esemplificare la differenza di approccio nella definizione dei contenuti, si può considerare la differenza che intercorre tra lo scrivere una lettera e fare una telefonata, o tra scrivere un romanzo e scrivere una sceneggiatura.

TECNICI. In questo ruolo raggruppiamo per ora tutte le figure professionali richieste dalle fasi del ciclo di vita di un sistema di questo tipo: installazione, configurazione, mantenimento in esercizio, monitoraggio, sviluppo di componenti di integrazione e personalizzazione del sistema. Una suddivisione più accurata di questo gruppo sarà specificata con la definizione dei requisiti.

5.1.2 Il Processo

Si descrive qui il processo di produzione di un’Applicazione Vocale, ipotizzando di avere a disposizione una piattaforma vocale e un gruppo di progetto che comprenda i ruoli definiti in precedenza.

Si considera il caso più complesso dal punto di vista dei ruoli coinvolti, che si verifica quando l’applicazione vocale richiede l’integrazione di dati e/o operazioni forniti da sistemi esterni, come ad esempio per l’applicazione vocale dinamica “Rubrica Aziendale”.

Gli schemi seguenti rappresentano alcuni casi salienti dove la scomposizione in sotto-processi è determinata dal diverso ruolo competente. Ogni ruolo fornisce un contributo specifico legato alle caratteristiche della qualifica professionale che sottintende. I casi presi in considerazione sono: la creazione di una nuova Applicazione Vocale, la modifica di una


parte statica e la sua cancellazione. Per ogni caso vengono considerati gli scenari con e senza l’utilizzo di un sistema specifico come quello proposto.

Nella definizione dei vari scenari è stata omessa l’indicazione delle fasi di test.

5 . 1 . 2 . 1 C R E A Z I O N E

La creazione è intesa in senso lato come processo di “prima realizzazione” di una determinata Applicazione Vocale. Le fasi che compongono il processo di creazione sono: la progettazione, lo sviluppo e l’esecuzione.

Analizziamo ogni fase e per ciascuna ogni sotto-processo che la compone, cominciando dal caso di assenza di un sistema specifico. Facciamo riferimento allo schema di Figura 14 applicato all’esempio della “Rubrica Aziendale”.

La prima fase è la progettazione. Un attore con il ruolo di amministratore decide che è necessario realizzare una determinata Applicazione Vocale, per fare questo assegna ad altri attori, a seconda delle loro competenze, i ruoli di disegnatore, autore e tecnico.

Al Disegnatore viene richiesto di progettare la logica della conversazione che realizza il servizio. Il risultato di questo progetto è, di norma, la definizione di un diagramma di flusso in cui sono indicate in qualche modo le interazioni tra l’utente telefonico e il sistema. Per il nostro caso di esempio, si veda Figura 24 al paragrafo 5.5.3.2 “Rubrica Aziendale”.

A fronte di questo schema il compito dell’Autore è quello di definire esattamente le parole che compongono la conversazione. Deve indicare i testi che saranno pronunciati dal sistema e la composizione delle grammatiche, queste ultime sono l’insieme di parole pronunciabili dall’utente per utilizzare il servizio. Per esemplificare se il Disegnatore decide che il servizio inizia con un messaggio di benvenuto, l’Autore decide com’è composto il messaggio di benvenuto.


AUTORESpecifica dei

contenuti

DISEGNATORESpecifica della

logica del dialogo

TECNICOSpecifica delle funzionalità da

integrare

Progettazione

TECNICORealizzazione delle pagine

VXML

TECNICORealizzazione del

codice di integrazione

Sviluppo Esecuzione

TECNICOPosizionamento ed attivazione

sulla piattaforma

Documenti di specifica Codice

AMMINISTRATORESupervisione e

validazione


validazione

Publicazione


validazione

Figura 14 – Processo di creazione in assenza di uno strumento specifico

Il Tecnico riceve il risultato di questo lavoro e lo completa aggiungendo la specifica delle funzionalità da integrare. Nel nostro esempio, definisce la modalità con cui deve essere consultata la rubrica contenuta, si ipotizza, in una base dati.

Normalmente un progetto richiede più cicli di revisione Disegnatore-Autore-Tecnico o, in ogni caso, una forma di collaborazione e condivisione fra questi ruoli. Il risultato del loro lavoro costituisce i documenti di specifica.

Raggiunta una certa maturità del progetto può avere inizio la fase di sviluppo. Il Tecnico prende in carico i documenti di specifica e inizia la scrittura del codice. Nel caso delle Applicazioni vocali lo sviluppo richiede due competenze tecniche: la conoscenza del VXML e di un linguaggio di programmazione che permetta la realizzazione o l’integrazione delle funzioni di Business Logic.

Un Amministratore supervisiona e valida i risultati di queste attività. Quando necessario, può richiedere una revisione del progetto.


Quando il codice generato rispetta i requisiti del progetto, l’Amministratore può decidere di “pubblicare” l’applicazione vocale. Può così avere inizio la fase di esecuzione. Un Tecnico prende in carico il codice generato nella fase di sviluppo e lo posiziona all’interno di un Application Server abbinato alla piattaforma vocale e attiva il servizio.

Se l’Applicazione Vocale che si intende realizzare non richiede l’integrazione di funzioni di Business Logic, la composizione delle fasi può essere semplificata, eliminando l’intervento del Tecnico per la parte in questione e liberando, teoricamente, la fase di progettazione dalla necessità di coinvolgere un ruolo tecnico.

Il processo di creazione di un’Applicazione Vocale che si vuole ottenere con l’introduzione del Framework è rappresentato in Figura 15.

La fase di progettazione è sostanzialmente la stessa del caso precedente e non richiede ulteriori commenti.

All’interno della fase di sviluppo viene rappresentato il Framework come elemento di supporto alle attività (sottoprocessi) che la compongono. In particolare, osserviamo come in presenza del Framework il ruolo del Tecnico esperto di VXML viene sostituito da un attore con il ruolo e le competenze del Disegnatore, fatto importante poiché rappresenta l’obiettivo principale del Framework.


FrameworkFramework

AUTORESpecifica dei

contenuti

DISEGNATORESpecifica della

logica del dialogo

TECNICOSpecifica delle funzionalità da

integrare

Progettazione

TECNICORealizzazione del

codice di integrazione

Sviluppo Esecuzione

Documenti di specifica

Descrittore di Applicazione

Vocale


validazione


validazione

Publicazione


validazione

DISEGNATORERealizzazione

dell’applicazione vocale

Figura 15 - Processo di creazione desiderato

Il risultato della fase di sviluppo non è necessariamente codice VXML. Conclusa questa fase l’Amministratore può decidere la pubblicazione, ma diversamente dal caso precedente, la fase di esecuzione non richiede l’intervento del tecnico.

La parte di Framework delegata alla gestione della fase di esecuzione fornisce all’Amministratore gli strumenti necessari per consentirgli di pubblicare ed attivare in modo autonomo l’Applicazione Vocale.

Come nel caso precedente, se l’Applicazione Vocale che si intende realizzare non richiede l’integrazione di funzioni di Business Logic, la composizione delle fasi può essere semplificata, eliminando l’intervento del Tecnico per la parte in questione. Quello che si ottiene è la definizione di un processo completamente privo della necessità di un attore con competenze tecniche.


5 . 1 . 2 . 2 M O D I F I C A

Per processo di modifica intendiamo l’insieme di attività da svolgere per realizzare un cambiamento nei contenuti e/o nella struttura dell’Applicazione Vocale precedentemente realizzata.

Analizziamo ora le fasi che compongono il processo di modifica, in assenza di uno strumento specifico (si faccia riferimento alla Figura 16).

AUTORESpecifica dei

contenuti

Progettazione

TECNICOModifica delle pagine VXML

Sviluppo Esecuzione

TECNICOPosizionamento ed attivazione

sulla piattaforma

Documenti di specifica Codice


validazione


validazione

Publicazione


validazione

Figura 16 - Processo di modifica in assenza di uno strumento specifico

Come per il processo di creazione le fasi sono ancora di progettazione, sviluppo ed esecuzione. Riprendendo l’esempio della Rubrica aziendale, supponiamo che si voglia modificare il messaggio di benvenuto del servizio.

La progettazione, di fatto, non è altro che la definizione del nuovo messaggio da parte dell’Autore. Conclusa questa fase, è necessario l’intervento di un Tecnico che riporti il testo del messaggio all’interno del codice VXML (fase di sviluppo). Infine, in seguito alla richiesta di pubblicazione, il Tecnico aggiorna il codice in esecuzione con la versione modificata (fase di esecuzione).

In presenza del Framework la struttura del processo si semplifica, come rappresentato in Figura 17. Il Framework fornisce all’Autore gli strumenti necessari a modificare autonomamente il messaggio di benvenuto. Allo stesso tempo, come per il caso della creazione, l’Amministratore può autonomamente pubblicare ed attivare l’Applicazione vocale modificata, di conseguenza non è più necessaria la figura del Tecnico.


L’aspetto più interessante nella definizione di questo processo è che se, come spesso accade, l’Autore è anche un Amministratore dell’Applicazione vocale, può gestire in completa autonomia tutto il processo di modifica.

FrameworkFramework

AUTORESpecifica dei

contenuti

Progettazione

AUTOREModifica

Sviluppo Esecuzione

Documenti di specifica

Descrittore di Applicazione

Vocale


validazione


validazione

Publicazione


validazione

Figura 17 - Processo di modifica desiderato

5 . 1 . 2 . 3 C A N C E L L A Z I O N E

Supponiamo di aver realizzato e attivato un’Applicazione vocale. Per processo di cancellazione consideriamo semplicemente l’azione di disattivazione di questa Applicazione.

Esecuzione

TECNICORimozione dalla

piattaforma


validazione

Figura 18 - Processo di cancellazione in assenza di uno strumento specifico


In assenza di uno strumento specifico, il processo richiede in ogni caso almeno due figure: l’Amministratore, che decide per la disattivazione del servizio, e il Tecnico che esegue la disattivazione.

In presenza del Framework, l’Amministratore può autonomamente eseguire la disattivazione.

Framework

Esecuzione

AMMINISTRATORERimozione dalla

piattaforma

Figura 19 - Processo di cancellazione desiderato

5.2 Tecnologia Visti gli obiettivi, le scelte tecnologiche sembrano essere relativamente obbligate.

Il sistema deve essere “Web-based” [Ob2.2] ed eventualmente “in service” [Ob2.4] , quindi, si tratta di sviluppare una Web Application. Gli acquirenti previsti sono grosse aziende [Ob2.3] , ed è ragionevole pensare ad architetture Enterprise.

Il framework deve essere indipendente dalla piattaforma [Ob3.1] e adattabile alle architetture dei sistemi informativi dei clienti [Ob3.2]. Questo suggerisce l’utilizzo di un environment Java.

Infine si consideri che anche il “canale vocale” verso la piattaforma vocale è rappresentato da un normale canale http, come verso un qualunque browser. Anche questo aspetto contribuisce all’idea di impostare il sistema in forma di web application.

La soluzione migliore risulta quindi essere una Web Application per Application Server di tipo J2EE (Java 2 Enterprise Edition).

Stabilito che si deve realizzare una Web Application per environment J2EE, rimangono in ogni caso ancora molti gradi di libertà nella definizione dell’architettura del software. Tra questi quello da vincolare il prima possibile è la scelta del design model per il livello


presentation. Nella fasi di sviluppo di una web application la scelta della modalità di integrazione tra contenuti grafici e logici delle interfacce utente, rappresenta un aspetto molto critico e che non deve essere trascurato.

Definiamo questo vincolo, tenendo conto della richiesta degli sviluppatori di prediligere l’utilizzo di framework ed architetture riconoscibili e consolidate [Ob3.4]. Decidiamo di utilizzare una implementazione del design pattern MVC2, in particolare sarà utilizzato il framework Struts 1.1.

Per inquadrare meglio le tecnologie ora citate, in particolare il significato di Web Application, MVC2 e J2EE, sono state riportate, nei paragrafi successivi, delle loro definizioni condivisibili.

5.2.1 Web Application

La seguente definizione di Web Application è tratta dal sito wordIQ.com (www.wordiq.com):

In software engineering, a web application is an application delivered to users from a web server over a network such as the World Wide Web or an intranet. Web applications are popular due to the ubiquity of the web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of clients is another reason they are popular. Applications like webmail, Amazon.com and eBay are well known examples of web applications but they have uses in many other areas of business and science.

Though many variations are possible, a web application is commonly structured as a three-tiered application. In its most common form, a web browser is the first tier, an engine created using some dynamic web content technology (e.g., CGI, PHP, Java servlets or Active Server Pages) is the middle tier, and a database is the third tier. The web browser sends requests to the middle tier, which services them by making queries and updates against the database and generating a user interface.

An emerging strategy for application software companies is to provide web access to software that has heretofore been distributed as local applications. These programs allow the user to pay a monthly or yearly fee for use of a software application without having to install it on a local hard drive. A company which follows this strategy is known as an application service provider (ASP), and ASPs are currently receiving much attention in the software industry.


5.2.2 Model View Control 2

Definizione tratta dalle linee guida fornite da Sun per il web-tier e contenute del documento “Designing Enterprise Applications with the J2EE Platform, Second Edition” (java.sun.com/blueprints/guidelines):

Model-View-Controller ("MVC") is the BluePrints recommended architectural design pattern for interactive applications. MVC, organizes an interactive application into three separate modules: one for the application model with its data representation and business logic, the second for views that provide data presentation and user input, and the third for a controller to dispatch requests and control flow. Most Web-tier application frameworks use some variation of the MVC design pattern. […]

The literature on Web-tier technology in the J2EE platform frequently uses the terms "Model 1" and "Model 2" without explanation. This terminology stems from early drafts of the JSP specification, which described two basic usage patterns for JSP pages. While the terms have disappeared from the specification document, they remain in common use. Model 1 and Model 2 simply refer to the absence or presence (respectively) of a controller servlet that dispatches requests from the client tier and selects views.

A Model 1 architecture consists of a Web browser directly accessing Web-tier JSP pages. The JSP pages access Web-tier JavaBeans that represent the application model, and the next view to display (JSP page, servlet, HTML page, and so on) is determined either by hyperlinks selected in the source document or by request parameters. A Model 1 application control is decentralized, because the current page being displayed determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). In some Model 1 architectures, choosing the next page to display occurs in scriptlet code, but this usage is considered poor form.

A Model 2 architecture introduces a controller servlet between the browser and the JSP pages or servlet content being delivered. The controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state. The controller also handles view selection, which decouples JSP pages and servlets from one another. Model 2 applications are easier to maintain and extend, because views do not refer to each other directly. The Model 2 controller servlet provides a single point of control for security and logging, and often encapsulates incoming data into a form usable by the back-end MVC model. For these reasons, the Model 2 architecture is recommended for most interactive applications. […]

An MVC application framework can greatly simplify implementing a Model 2 application. Application frameworks such as Apache Struts and JavaServer FacesTM include a configurable front controller servlet, and provide abstract classes that can be extended to handle request dispatches. Some frameworks include macro languages or other tools that simplify application construction.


5.2.3 J2EE

Definiamo l’acronimo J2EE. Per fase questo riportiamo ancora una definizione tratta dal sito wordIQ.com (www.wordiq.com):

Java 2 Platform, Enterprise Edition or J2EE is a Standard (albeit with no ISO or ECMA standard) for developing distributed Multi-tier architecture applications, based on modular components. It uses several technologies, including JDBC and CORBA, and extends their functionality with Enterprise Java Beans, Java Servlets, Java Server Pages and XML technologies. This allows the developer to create an Enterprise Application that is portable between platforms and scalable, while integrating with several legacy technologies.

La definizione che segue è invece tratta della documentazione ufficiale fornita da Sun, in particolare si tratta dell’introduzione del già citato documento “Designing Enterprise Applications with the J2EE Platform, Second Edition”:

The J2EE platform specifies technologies to support multitier enterprise applications. These technologies fall into three categories: component, service, and communication.

The component technologies are those used by developers to create the essential parts of the enterprise application, namely the user interface and the business logic. The component technologies allow the development of modules that can be reused by multiple enterprise applications. The component technologies are supported by J2EE platform's system-level services. These system-level services simplify application programming and allow components to be customized to use resources available in the environment in which they are deployed.

Since most enterprise applications require access to existing enterprise information systems, the J2EE platform supports APIs that provide access to databases, enterprise information systems such as SAP and CICS, and services such as transaction, naming and directory, and asynchronous communication. Finally, the J2EE platform provides technologies that enable communication between clients and servers and between collaborating objects hosted by different servers.

5.3 Architettura fisica L’architettura del framework deve prevedere due moduli software indipendenti. Questo per realizzare la richiesta di separazione tra le fasi di sviluppo delle applicazioni vocali e la loro esecuzione [Ob3.3].

Si definiscono , quindi, le caratteristiche di questi due moduli, cominciando dai loro nomi: Designer e Runtime.


Il modulo Designer realizza il sistema per la definizione delle applicazioni vocali, mentre il modulo Runtime realizza il sistema che le esegue. La distinzione a livello logico è molto netta e questo facilita la loro separazione fisica.

Una gestione completamente separata di questi due moduli presenta molti vantaggi:

I moduli possono essere eseguiti su server indipendenti.

Il tipo di server può essere differente.

Un’istanza di Designer potrebbe alimentare più istanze di Runtime.

Un’istanza di Runtime potrebbe essere alimentata da più istanze di Designer.

5.3.1 Runtime

Piattaforma Vocale

Framework(Modulo Runtime)

VXML (http/https)

(Un protocollo TCP/IP)

Sistemi Legacy

Voce (Linea telefonica)

Luogo 1

Luogo 2

Luogo 3

Luogo 4

Figura 20 - Architettura Fisica del sistema in fase di runtime

L’architettura che include il modulo di Runtime deve realizzare l’esecuzione delle applicazioni vocali. Come già detto, per fare questo il framework si deve appoggiare ad una piattaforma vocale.


Commentiamo lo schema di Figura 20. In questo schema sono rappresentati quattro elementi del sistema, tra i quali viene messa in evidenza l’indipendenza dal punto di vista della collocazione fisica.

Per quanto riguarda il telefono e la piattaforma vocale, viene abbastanza naturale immaginare che si trovino in luoghi differenti (è lo scopo del telefono). La separazione fisica tra piattaforma e framework è invece tutto altro che scontata.

Il framework è una web application, la piattaforma si comporta come un browser ed il canale di comunicazione è in protocollo http. Vista in questi in termini l’interazione tra i due blocchi non può che essere geograficamente distribuita. Eppure piattaforme vocali come Voxnauta di Loquendo prevedono normalmente l’includere della web application all’interno della piattaforma, imponendo tra l’altro l’utilizzo di Internet Information Server come application server.

Volendo essere indipendenti dalle piattaforme e dagli application server, non resta che pensare il modulo di Runtime come un componente fisicamente separato.

Il modulo di Runtime deve eseguire la definizione delle applicazioni vocali e niente altro. Per questo motivo è necessario che qualunque altra funzione di business sia realizzata da un componente separato (qui indicato come “sistemi legacy”). In questo caso la separazione fisica (su server differenti) non è strettamente necessaria, ma in ogni caso preferibile. Anche perché bisogna pensare che uno stesso server di Runtime potrebbe dover servire contemporaneamente più applicazioni vocali indipendenti e un disservizio su una non deve compromettere il funzionamento delle altre.

Si noti che non è indicata la presenza di una base dati. L’idea è che un descrittore di applicazione vocale, una volta generato non può che essere composto di contenuti statici ed al limite istruzioni per l’invocazione di metodi di business, da parte del modulo che lo sta eseguendo. In questi termini la definizione dell’applicazione vocale può essere rappresentata da un semplice file che il Runtime deve caricare in memoria ad un certo momento.

5.3.2 Designer

Consideriamo ora le interazioni del modulo Designer e la sua collocazione fisica, facendo riferimento alla Figura 21. La struttura risulta immediatamente più famigliare, perché coincide con quella di una classica web application e in effetti il modulo Designer lo è a tutti gli effetti. Si accede alle interfacce via browser web ed il livello di persistenza dei dati è delegato ad un base dati esterna.


Framework(Modulo Designer)

HTML (http/https)

Luogo 6

Luogo 5

Base Dati

JDBC / ODBC (TCP/IP)

Luogo 7

Figura 21 - Architettura Fisica del sistema in fase di design

Nel rappresentare i canali di comunicazione dei due moduli con il resto dei rispettivi sistemi, si è tralasciata la definizione della comunicazione tra i moduli. Questo canale è “proprietario” e come tale può essere in teoria definito a piacere, al limite potrebbe anche non esistere un canale diretto. Il descrittore di applicazione vocale potrebbe ad esempio essere generato come file da scaricare, da parte del Designer, ed essere richiesto come file da caricare (upload), da parte del modulo di Runtime. L’utilizzo del dell’upload, ad esempio, è tipico degli application server.

5.4 Architettura logica Formuliamo ora un’ipotesi per l’organizzazione dell’architettura logica dei due moduli precedentemente definiti. Gli obiettivi da tener presente in questo caso sono fondamentalmente: la necessità che il sistema sia scalabile rispetto al numero di applicazioni vocali che deve gestire, sia in fase di sviluppo, sia in fase di esecuzione [Ob2.5]; si deve prediligere l’utilizzo di framework ed architetture riconoscibili e consolidate [Ob3.4] .

Il punto di partenza è la loro collocazione all’interno della logica complessiva del sistema. Lo schema di Figura 22 mette in evidenza questo ruolo all’interno di una architettura a tre livelli, tipica dei sistemi client-server.


Runtime DesignerPubblicazione

Piattaforma Vocale

Requ

est

Resp

onse

Requ

est

Resp

onse

Presentazione

Logica

Persistenza

Base Dati

Sistemi Legacy

Figura 22 - Architerrura logica al massimo livello di astrazione

Il livello più basso è rappresentato dalla persistenza dei dati.

BASE DATI. Lo schema indica la necessità di una base dati d’appoggio per le attività del modulo designer. Questa base dati deve mantenere la definizione delle Applicazioni Vocali in tutte le fasi della loro lavorazione; deve contenere la definizione degli utenti, dei ruoli e delle loro relazioni con le applicazioni; deve contenere tutte le informazioni necessarie alla gestione del modello interno di rappresentazione delle Applicazioni Vocali.

DESIGNER. Rappresenta la web application delegata alla creazione e gestione delle Applicazioni Vocali. Questo raccoglie, quindi, la definizione di tutte le interfacce di amministrazione e tutta la logica di gestione del modello interno di rappresentazione delle Applicazioni Vocali.

In particolare nello schema è indicata la modalità di comunicazione unidirezionale verso un elemento Runtime. La necessità di questo comunicazione è rappresentata dall’evento di pubblicazione di una data Applicazione Vocale. In questa fase di definizione della soluzione ipotizziamo che la pubblicazione possa essere realizzato come un evento asincrono pilotato dal modulo Designer, verso uno o più moduli Runtime.

PERSONAL COMPUTER. Il PC rappresentato al livello presentazione il media per l’accesso web alle interfacce di amministrazione della web application “Designer”.


SISTEMI LEGACY. Con questo termine si indicano generalmente i sistemi proprietari esterni al sistema considerato, ma con i quali è in ogni caso necessario interagire. Spesso sono semplicemente una base dati specifica. La presenza e ed il comportamento di questo componente dipende esclusivamente dalle necessità di ogni singola Applicazione Vocale.

Nella definizione dell’architettura logica i Sistemi Legacy rappresentano, in relazione al modulo Runtime, il livello di persistenza. Il motivo è che il livello logico nell’esecuzione di una Applicazione Vocale è rappresentato esclusivamente delle regole che determino l’avanzamento della conversazione, mentre le elaborazioni ed i risultati forniti dai sistemi esterni rappresentano la parte dinamica dei dati che costituiscono la definizione dell’Applicazione Vocale.

RUNTIME. Anche in questo caso, come per il Designer, è rappresentata una web application. Le pagine prodotte ed inviate come “response” alle richieste della piattaforma vocale, sono però rappresentate da documenti in formato VXML. La generazione di questi documenti è data dall’interpretazione del descrittore di Applicazione Vocale ricevuto in precedenza dal modulo Designer.

PIATTAFORMA VOCALE. La modalità di comunicazione di questo elemento verso il Runtime è quella tipica si un browser. L’analogia è corretta sotto tutti i punti di vista, quindi la piattaforma vocale è collocata al livello logico della presentazione. Genera la rappresentazione vocale dei documenti VXML prodotti del modulo Runtime.

5.5 Organizzazione dell’informazione per il vocale Di seguito sono riportate alcune considerazioni sull’organizzazione dell’informazione, quando essa deve essere scambiata attraverso canali esclusivamente vocali.

5.5.1 Introduzione

Il funzionamento di un’applicazione vocale è, in qualche modo, analogo a quello di un sito web: ci sono voci di menu da selezionare, pagine da leggere, comandi di avanzamento e form da compilare. Rispetto al web, però, il canale vocale presenta alcune specificità di cui tenere conto.

La navigazione di un’Applicazione Vocale non è totalmente di tipo ipertestuale, ma si avvicina più al modello sequenziale. L’utente può scegliere differenti percorsi di navigazione man mano che questi gli vengono proposti, ma può anche scegliere di saltare l’esposizione dei contenuti da parte del sistema pronunciando il comando necessario. Il limite, che rende la navigazione sostanzialmente sequenziale, è che l’utente non può conoscere i comandi disponibili finché il sistema stesso non glieli indica (per lo meno al primo utilizzo).


La quantità di informazione che può essere veicolata attraverso il canale vocale è necessariamente limitata, a causa delle caratteristiche del mezzo. La fruizione è, infatti, legata alla lettura del contenuto da parte di un programma di sintesi vocale: bisogna evitare pertanto di sottoporre all’utente testi particolarmente lunghi e difficili, poiché non è possibile scorrere e rileggere porzioni di contenuto come avviene sul web o su una pagina cartacea. Inoltre, non è possibile proporre contenuti diversi da quelli di tipo testuale ed audio, come immagini e video.

L’interazione tra l’utente e l’Applicazione Vocale deve essere semplice, rapida ed intuitiva, altrimenti corre il rischio di diventare frustrante. Bisogna costruire il servizio vocale in modo tale da sfruttare l’immediatezza del canale vocale, piuttosto che tentare di re-impiegare soluzioni ideate per altri mezzi.

Nel progettare un’Applicazione Vocale si deve necessariamente tenere conto di questi limiti, ma in questo, un aiuto importante lo si può ricevere anche dall’impostazione dello strumento di sviluppo utilizzato. Se lo strumento di sviluppo impone un certo modello di costruzione, da una parte questo può costituire un limite alla fantasia del progettista, dall’altra però può ridurre il rischio di ottenere Applicazioni Vocali non “accessibili”.

Riprendiamo i nostri due esempi di riferimento. Per il primo esempio proviamo a definire una implementazione VXML che tenga conto di quanto appena osservato sull’organizzazione dei contenuti e sulla dinamica della conversazione. Per il secondo esempio ci limitiamo in questo capitolo a definire una possibile organizzazione dei contenuti.

5.5.2 Caso “Servizio Notte”

Come già descritto al paragrafo 4.6.1, questo esempio descrive un servizio telefonico automatico che viene inserito alla chiusura degli uffici e disinserito alla loro apertura. Il servizio deve fornire informazioni come ad esempio l’orario dell’ufficio, il numero del FAX o situazioni di anomalia come la condizione di sciopero.

5 . 5 . 2 . 1 S C E N A R I O B A S E

Il centralino è impostato per deviare tutte le chiamate in ingresso verso il numero di telefono su cui è attestata l’Applicazione Vocale “Servizio Notte”.

L’utente telefonico compone il numero del centralino;

Il centralino devia la chiamata sull’Applicazione Vocale;

L’Applicazione Vocale risponde con un messaggio di benvenuto;

L’Applicazione Vocale chiede all’utente se è interessato a conoscere gli orari di apertura o gli altri numeri dell’azienda;


Se l’utente pronuncia “orari”, l’Applicazione Vocale prosegue leggendo gli orari di apertura dell’azienda;

Se l’utente pronuncia “numeri”, l’Applicazione Vocale prosegue elencando gli altri numeri dell’azienda (es. il FAX e i numeri di altre sedi);

L’applicazione torna a proporre la scelta tra orari e numeri telefonici;

L’utente chiude la telefonata.

5 . 5 . 2 . 2 S C H E M A D E L L ’ O R G A N I Z Z A Z I O N E D E L L ’ I N F O R M A Z I O N E

Benvenuto

Menu:- orari di apertura- numeri telefonici

Input vocale

Orari di apertura Numeri telefonici

“orari” “numeri”

Figura 23 - Organizzazione dell'informazione del "Servizio Notte"

5 . 5 . 2 . 3 I M P L E M E N T A Z I O N E V X M L

Del codice VXML che implementa il “Servizio Notte” così modellato può essere il seguente:

<?xml version="1.0"?>

<vxml version="1.0" >


<form id="benvenuto">

<field name="mainField">

<prompt timeout="0s"> Buonasera. Risponde la segreteria automatica della "Pizza e Fichi". Siamo spiacenti, i nostri uffici a quest'ora sono chiusi. </prompt>

</field>

<filled/>

<noinput>

<goto next="#menuPrincipale" />

</noinput>

</form>

<menu id="menuPrincipale">

<prompt>

Selezioni una delle seguenti opzioni.

Per conoscere i nostri orari di ufficio, dica: orari.

Per conoscere gli altri nostri numeri di telefono,

dica: numeri.

</prompt>


<choice next="#orari">

<grammar>orari</grammar>

</choice>

<choice next="#numeri">

<grammar>numeri</grammar>

</choice>

</menu>

<form id="orari">


<prompt timeout="0s">

Gli nostri uffici sono aperti, dal lunedì al

venerdi. La mattina: dalle ore 9 alle ore 13.

Il pomeriggio: dalle ore 14 alle ore 18.

Il sabato e la domenica gli uffici sono chiusi.

</prompt>

</field>

<filled/>


<noinput>

<goto next="#benvenuto" />

</noinput>

</form>

<form id="numeri">



Elenco gli altri nostri numeri di telefono:

il numero di fax è: 011555333.

il numero della sede di Milano è: 02555444.

il numero della sede di Roma è: 06555888.

</prompt>

</field>

<filled/>

<noinput>

<goto next="#benvenuto" />

</noinput>


</form>

</vxml>

La complessità di un documento VXML è subito evidente. L’applicazione vocale appena definita è semplicissima, ma la complessità del documento.vxml che la implementa non lo è certamente per chi non è avvezzo ai linguaggi di programmazione.

Vediamo ora come questa stessa applicazione può scomposta in documenti più piccoli,per agevolare la comprensione della sua logica e trovare una maggiore corrispondenza con il diagramma che la rappresenta, definito precedentemente.

BENVENUTO.VXML. Documento VXML che rappresenta implementa il messaggio di benvenuto.



<form id="mainForm">


<prompt timeout="0s"> Buona sera. Risponde la segreteria automatica della "Pizza e Fichi". Siamo spiacenti, i nostri uffici a quest'ora sono chiusi. </prompt>

</field>

<filled/>

<noinput>

<goto next="menu.vxml" />

</noinput>


</form>

</vxml>

Il codice presenta un unico blocco <form> che, secondo la specifica VXML, identifica una unità di dialogo. Questo blocco contiene un <prompt> ossia l’indicazione di un testo da pronunciare. Contiene anche l’indicazione del documento da richiamare nel caso non vi sia risposta da parte dell’utente (noinput). Poiché il tempo utile per la risposta è impostato a zero (<prompt timeout="0s">), la piattaforma, terminata la pronuncia del testo, segue immediatamente l’indicazione del blocco <noinput>, passando così all’esecuzione del documento “menu.vxml”.

MENU.VXML. Questo documento VXML include il comportamento i seguenti elementi del diagramma: “menu”, “input vocale”, arco “orari” ed arco “numeri”.

<?xml version="1.0" ?>

<vxml version="1.0">

<menu id="this_menu">

<prompt>

Selezioni una delle seguenti opzioni.

Per conoscere i nostri orari di ufficio, dica: orari.

Per conoscere gli altri nostri numeri di telefono,

dica: numeri.

</prompt>

<choice next="orari.vxml">

<grammar>orari</grammar>


</choice>

<choice next="numeri.vxml">

<grammar>numeri</grammar>

</choice>

</menu>

</vxml>

La struttura di base a differenza del documento “benvenuto.vxml”, ora è rappresentata da un elemento <menu> che, secondo la specifica VXML, rappresenta la seconda modalità di specifica di una unità di dialogo. Al suo interno troviamo oltre all’indicazione del <prompt>, due blocchi <choice>, che specificano le voci del menu. Per ciascuna voce è indicata la grammatica (<grammar>) che determina la selezione della voce e il nome del documento da richiamare in seguito alla selezione.

Osserviamo che il questo codice non viene specificato il comportamento nel caso in cui la piattaforma non trova corrispondenze con le grammatiche non non riceve un input dall’utente. In questo caso la piattaforma reagisce seguendo le proprie impostazioni predefinite a livello di piattaforma.

ORARI.VXML. Documento VXML analogo a “benvenuto.vxml”, diverso solo per i contenuti del messaggio e per il nome del documento successivo.







Gli nostri uffici sono aperti, dal lunedì al

venerdi. La mattina: dalle ore 9 alle ore 13.

Il pomeriggio: dalle ore 14 alle ore 18.

Il sabato e la domenica gli uffici sono chiusi.

</prompt>

</field>

<filled/>

<noinput>

<goto next="benvenuto.vxml" />

</noinput>

</form>

</vxml>

NUMERI.VXML. Documento VXML analogo a “benvenuto.vxml”, diverso solo per i contenuti del messaggio e per il nome del documento successivo.







Elenco gli altri nostri numeri di telefono:

il numero di fax è: 011555333.

il numero della sede di Milano è: 02555444.

il numero della sede di Rima è: 06555888.

</prompt>

</field>

<filled/>

<noinput>

<goto next="benvenuto.vxml" />

</noinput>

</form>

</vxml>

5.5.3 Caso “Rubrica Aziendale”

Il caso qui descritto è una possibile semplificazione di un tipo di applicazione vocale proposto da molti produttori di piattaforme vocali.


5 . 5 . 3 . 1 S C E N A R I O B A S E

Su un dato numero di telefono un’azienda ha attestato l’Applicazione Vocale che realizza il servizio di rubrica. Gli utenti sono i dipendenti stessi dell’azienda e conoscono l’uso del servizio.

L’utente telefonico chiama il numero del servizio;

Il sistema risponde chiedendo nome e cognome del dipendente desiderato;

L’utente pronuncia nome e cognome;

Il sistema risponde pronunciando il numero di telefono corrispondente;

Il sistema chiede all’utente se deve ripetere il numero o cercarne un altro;

L’utente chiude la comunicazione.


5 . 5 . 3 . 2 S C H E M A D E L L ’ O R G A N I Z Z A Z I O N E D E L L ’ I N F O R M A Z I O N E

Richiesta di Nome e Cognome

Input vocale

Determinazione del numero

Nessun input

Valore non presentein grammatica

Messaggio di mancato

riconoscimento

Valore riconosciuto

Definizione della grammatica dei

nomi

Pronuncia del numero

Menu di avanzamento

Input vocale

“ripeti”

“numero”

Figura 24 - Organizzazione dell'informazione di "Rubrica Aziendale"

Questo diagramma rappresenta una possibile organizzazione della conversazione. A differenza del caso precedente possiamo osservare la presenza di due elementi che non definiscono direttamente il comportamento vocale, ma che sono in ogni caso indispensabili.


Il primo elemento è il processo di determinazione della grammatica dei nomi, il secondo è il processo che a fronte di un nome selezionato dall’utente associa e restituisce il numero di telefono.

La definizione del comportamento di un’Applicazione Vocale richiede quindi anche la presenza di elementi di supporto come gli elementi di integrazione verso funzioni esterne di Business Logic.

5.6 Modello per la rappresentazione interna Come detto in precedenza le piattaforme vocali considerate utilizzano il linguaggio VoiceXML ed il sistema qui presentato utilizzerà questo linguaggio nella fase di esecuzione. Si è anche già osservato come questo linguaggio non sia di semplice utilizzo. Per tanto, per realizzare quanto previsto dei requisiti è indispensabile poter fornire a chi deve realizzare le applicazioni vocali, un “linguaggio” più semplice.

Questo risultato sarà ottenuto definendo un modello per la rappresentazione interna delle applicazioni vocali, più semplice del VXML. Il modello non intende essere un linguaggio alternativo, ma deve realizzare un livello di astrazione più alto di quello proposto dal codice. La complessità (semplicità) del modello deve essere misurata sui requisiti riguardanti gli utilizzatori delle interfacce di amministrazione, in particolare Autori e Disegnatori, ai quali si intende mascherare completamente la complessità del codice VXML.

Per arrivare a definire il modello di rappresentazione interna, rivediamo e “congeliamo” con un certo significato, nel contesto del framework, alcuni concetti e definizioni chiave.

5.6.1 Applicazioni Vocali

Si è partiti assegnando, per il contesto del framework, un significato specifico, al termine applicazione vocale. In seguito, questo termine, quando riferito al contesto del framework, sarà indicato con le iniziali maiuscole. La stessa convenzione editoriale sarà utilizzata anche per le altre definizioni.

Un’Applicazione Vocale può essere definita come un software in grado di interagire con l’utente attraverso la voce. Per realizzare tale interazione è necessario programmare l’Applicazione Vocale con una serie di istruzioni che le consentano di svolgere alcune funzioni fondamentali:

riconoscere ed acquisire gli input provenienti dall’utente;

utilizzare i valori di input per l’esecuzione di metodi di business;

restituire all’utente gli opportuni output.


ricordare le scelte dell’utente

Si può immaginare l’Applicazione Vocale come il contenitore che ospita tutti i componenti che danno vita ad un servizio vocale. In altre parole l’Applicazione Vocale rappresenta il programma che, se eseguito, realizza un determinato servizio.

Questo contenitore raccoglie diversi insiemi di elementi: Nodi, Variabili, Grammatiche e Servizi. I paragrafi successivi descrivono il significato di ciascuno di essi.

5.6.2 Nodi

I Nodi di navigazione sono i componenti di base delle Applicazioni Vocali. Essi rappresentano i crocevia attraverso i quali l’utente telefonico compie il proprio percorso di navigazione. Continuando l’analogia con il sito web, i Nodi possono essere associati alle pagine del sito: presentano contenuti attraverso la lettura di un testo, propongono scelte di menu, ricevono dati immessi dall’utente, rendono disponibili comandi di navigazione. In altre parole, gli insiemi di Nodi definiscono e consentono l’interazione dell’utente telefonico con l’Applicazione Vocale.

Creare e collegare i Nodi significa programmare, in ogni momento della navigazione, in quale modo l’utente debba relazionarsi con l’Applicazione Vocale.

L’esecuzione di una Applicazione Vocale si concretizza nell’esecuzione, in successione, dei singoli Nodi che la compongono. Ogni Nodo può presentare più di un scelta come Nodo successivo, i fattori che determinano tale scelta saranno il disegno dell’Applicazione Vocale e le parole pronunciate dall’utente.

Secondo questo modello per definire un’Applicazione Vocale sarà necessario definire e collegare un certo numero di Nodi.

L’idea è quella di individuare una serie di tipi predefiniti di Nodo. Ogni tipo dovrà presentare un comportamento specifico, ma parametrico.

Si devono prevedere diverse tipologie di Nodi che rispondono a differenti esigenze di navigazione. Le principali sono:

far ascoltare un testo;

proporre all’utente delle scelte tra cui effettuare una selezione;

ricevere e memorizzare un dato dall’utente;

utilizzare una funzionalità esterna, come un’interrogazione ad un database esterno.

Ogni Nodo può essere distinto in base al comportamento che genera in fase di esecuzione, ossia come si comporta il sistema passando per quel tipo di Nodo.


La scelta del termine “nodo” deriva dal fatto che si chiamano in questo modo degli elementi, per certi versi analoghi, previsti dai sistemi IVR. I nodi di un IVR definiscono in effetti la struttura ed il comportamento del servizio, come indicato dalla nostra definizione. Per questi sistemi però, la definizione dei nodi, il più delle volte, è un’attività che deve essere svolta da personale specializzato.

5.6.3 Variabili

Le Variabili sono i veicoli attraverso cui viaggiano i dati in entrata e in uscita dall’Applicazione Vocale. Costituiscono gli elementi di memoria che registrano lo stato di esecuzione del servizio, come le parole pronunciate dall’utente o i valori recuperati da una base dati. Esse possono essere richiamate in diversi punti di un’Applicazione Vocale, ad esempio rispetto all’interazione con l’utente: in entrata, nei Nodi di acquisizione dati; in uscita, se inserite all’interno dei testi pronunciati dal servizio.

Più in generale le Variabili per un’Applicazione Vocale hanno lo stesso significato delle variabili per i comuni linguaggi di programmazione.

5.6.4 Grammatiche

Una Grammatica nel contesto di una Applicazione Vocale non è altro che un insieme di parole valide organizzate in determinate successioni. La piattaforma vocale che esegue l’Applicazione Vocale, quando si mette in ascolto dell’utente telefonico, cerca di trovare una possibile corrispondenza tra la voce dell’utente e le parole presenti nella Grammatica.

Una piattaforma vocale non è in grado di comprendere parole diverse da quelle presenti nella Grammatica. In ogni istante la piattaforma vocale cerca di interpretare la voce dell’utente confrontandola con tutte le Grammatiche a sua disposizione in quello stesso istante.

In assenza di un Sistema specifico per la gestione e definizione dell’Applicazione Vocale, la definizione delle Grammatiche diventa uno dei fattori più critici e complessi. La grammatiche sono definite con un linguaggio specifico, l’SRGS (Speech Recognition Grammar Specification www.w3.org/TR/speech-grammar/ ), anch’esso definito come standard dal W3C.

L’idea è che la complessità delle Grammatiche possa essere risolta dall’organizzazione a Nodi dell’Applicazione Vocale. In questo modo il contesto di validità di ogni Grammatica si riduce ad un singolo Nodo, portando la complessità della definizione ad un semplice elenco di parole.


5.6.5 Servizi

I Servizi permettono di eseguire le elaborazioni di dati e le funzioni specifiche richieste dall’Applicazione Vocale. Ad esempio, svolgono un ruolo fondamentale quando è necessario relazionare i dati con un database esterno o quando si devono eseguire operazioni tra le Variabili.

I Servizi definiscono ed utilizzano il canale di comunicazione (non vocale) tra l’Applicazione Vocale e gli altri sistemi informativi.

5.7 Applicazione del Modello Applichiamo il modello di rappresentazione dell’informazione vocale appena definito, ai casi di esempio precedentemente analizzati.

5.7.1 Caso “Servizio Notte”

Riconsideriamo l’analisi dell’Applicazione Vocale “Servizio Notte” del capitolo 5.5.2. Consideriamo in particolare i frammenti di codice che sono stati identificati come migliore approssimazione del modello logico della conversazione. Questi frammenti hanno determinato la definizione di quattro documenti vxml autonomi.

Vediamo ora come questa scomposizione ci ha avvicinato all’idea del modello proposto in questo capitolo.

Osserviamo la definizione di documenti VXML “benvenuto.vxml”, “giorni.vxml” e “numeri.vxml”. E’ subito evidente che la struttura è identica, la finalità del codice (pronunciare un testo) anche. Proviamo, quindi, a generalizzare la struttura.






<prompt timeout="0s"> {testo_da_pronunciare} </prompt>

</field>

<filled/>

<noinput>

<goto next="{prossimo_nodo}" />

</noinput>

</form>

Il frammento di codice così generalizzato è un Nodo. In particolare abbiamo definito la struttura di un Nodo adatto alla semplice lettura di un testo.

<?xml version="1.0" ?>

<vxml version="1.0">

<menu id="this_menu">

<prompt>

{testo_introduttivo}

{testo_voce_di_menu_1}

{testo_voce_di_menu_2}

…


{testo_voce_di_menu_N}

</prompt>

<choice next="{nodo_successivo_voce_di_menu_1}">

<grammar>{grammatica_voce_di_menu_1}</grammar>

</choice>

<choice next="{nodo_successivo_voce_di_menu_2}">

<grammar>{grammatica_voce_di_menu_2}</grammar>

</choice>

…

<choice next="{nodo_successivo_voce_di_menu_N}">

<grammar>{grammatica_voce_di_menu_N}</grammar>

</choice>

</menu>

SECONDA PARTE Realizzazione

6 Requisiti

Modulo Designer

Modulo Runtime

Casi d’Uso

6.1 Introduzione In questo capitolo vengono definiti i requisiti che dovrà possedere il framework, con un livello di dettaglio superiore a quello proposto nei capitoli precedenti. La specifica dei requisiti rappresenta, in un processo di realizzazione di un software, il documento di riferimento per la determinazione di tutte le fasi successive ed in particolare costituisce l’elemento di confronto per la valutazione di quanto realizzato.

Volendo realizzare un sistema che rispetti l’architettura logica proposta al capitolo precedente, manteniamo nella specifica dei requisiti, la separazione in due moduli software indipendenti.

DESIGNER. Rappresenta la web application delegata alla creazione e gestione delle Applicazioni Vocali. Raccoglie la definizione di tutte le interfacce di amministrazione e tutta la logica di gestione del modello interno di rappresentazione delle Applicazioni Vocali.

RUNTIME. E’ una web application. Le pagine prodotte ed inviate come “response” alle richieste della piattaforma vocale, sono però rappresentate da documenti in formato VXML. La generazione di questi documenti è data dall’interpretazione del descrittore di Applicazione Vocale ricevuto dal modulo Designer.

6 – R E Q U I S I T I 7 7

6.2 Modulo Designer Sotto questo titolo sono raccolti i requisiti funzionali che definiscono il modulo Designer. Una descrizione più accurata delle singole funzioni è riportata successivamente nella definizione dei Casi d’Uso.

ATTORI. Insieme dei tipi di utente previsti. Amministratore.

Disegnatore.

Autore.

Configuratore.

Sviluppatore.

GESTIONE UTENTI. Interfacce di gestione degli utenti.

Crea / Modifica / Elimina Utente.

Associa Utente-Ruolo.

Associa Utente-Applicazione.

GESTIONE AUTENTICAZIONE. Funzioni di login e logout.

Login / Logout. Funzioni di autenticazione per l’accesso alle interfacce.

Cambia Password. Ogni utente può modificare la propria password di accesso.

GESTIONE / AMMINISTRA APPLICAZIONI. Crea / Elimina / Rinomina Applicazione.

Visualizza Dettagli Applicazione.

Visualizza Elenco Applicazioni Abilitate.

Visualizza Dettagli Applicazione.

Importa / Esporta Applicazione.

Elenca Runtime.

Apri Runtime.

Pubblica Applicazione su un Runtime.

GESTIONE NODI. Funzioni di gestione dei Nodi.

Specifica Nodo di Inizio.

Associa Link Globali.

Crea / Elimina / Rinomina Nodo.

6 – R E Q U I S I T I 7 8

Visualizza Elenco Nodi.

Verifica Nodi. Funzione che lancia un processo di validazione della struttura fino a quel momento definita.

MODIFICA NODO. Per modifica di un Nodo si intende anche la sua definizione successiva alla creazione. Si devono prevedere dei tipi di Nodo che coprano le seguenti funzionalità:

Leggi Testo. Definisce un Nodo che legge il testo in esso contenuto.

Esegui Servizio. Definisce la modalità di richiamo di una funzione esterna al sistema.

Link. Un comando invocabile in qualunque momento della conversazione.

Menu. Modella un insieme di opzioni predefinite.

Acquisisci Dato. Definisce la modalità di acquisizione di un dato pronunciato dall’utente.

Cambia Applicazione. Serve a definire il passaggio all’esecuzione di un’altra Applicazione Vocale.

Imposta Variabili. Serve ad assegnare in modo diretto dei valori alle Variabili.

Trasferimento di Chiamata. Definisce il comportamento di un trasferimento di chiamata.

GESTIONE VARIABILI. Tutte le funzioni di gestione delle Variabili.

Crea / Elimina / Rinomina Variabile.

Visualizza Elenco Variabili.

GESTIONE SERVIZI. Funzioni di gestione delle istanze dei Servizi.

Crea / Elimina Istanza di Servizio.

Visualizza Elenco Istanze di Servizio. GESTIONE CONFIG. Interfacce per la gestione della configurazione.

Visualizza Elenco Descrittori di Configurazione.

Crea / Modifica / Elimina Descrittore di Configurazione.

Visualizza Elenco Schemi VXML.

Crea / Modifica / Elimina Schema VXML.

6 – R E Q U I S I T I 7 9

6.3 Modulo Runtime Qui di seguito sono raccolti i requisiti funzionali che definiscono il modulo Runtime. Una descrizione più accurata delle singole funzioni è riportata successivamente nella definizione dei Casi d’Uso.

FUNZIONI DI ESECUZIONE.

Richiama un’Applicazione Vocale.

Richiama il Nodo successivo.

Interpreta un Nodo.

Esegue un’azione sul Server.

Genera la definizione del Nodo Successivo.

FUNZIONI DI AMMINISTRAZIONE.

Visualizza Elenco Applicazioni.

Esegue Applicazione col Debugger.

Attiva / Disattiva Applicazione.

Rimuovi Applicazione.

Associa Canali.

6 – R E Q U I S I T I 8 0

6.4 Casi d’Uso Gli schemi che seguono sono diagrammi dei Casi d’Uso secondo il formalismo del linguaggio UML. Gli elementi previsti da questi schemi sono, fondamentalmente: “omini”, ellissi, rettangoli e frecce di congiunzione. Essi rappresentano rispettivamente: gli Attori, le funzioni, gruppi di funzioni (package) e le loro relazioni.

Nei diagrammi dei Casi d’Uso le relazioni tra Attori e funzioni, se non diversamente indicato, significano “utilizza” o “esegue”. Mentre quelle tra le funzioni indicano la composizione o l’inclusione.

Una corretta documentazione del software prevedrebbe la definizione di un documento di dettaglio per ogni Caso d’Uso. Per brevità qui ci si è limitati ad una breve spiegazione di ogni schema.

Designer

Runtime

Utente Applicazio...

Amministratore

Fornitore Applicazio...

Disegnatore

Autore

Configuratore

Sviluppatore

Legacy Adapter

Figura 25 - Schema principale dei Casi d'Uso

6 – R E Q U I S I T I 8 1

6.4.1 Attori

Gli Attori sono divisi in due classi base: “Utente Applicazione Vocale” e “Fornitore Applicazione Vocale”.

UTENTE APPLICAZIONE VOCALE. Rappresenta un generico utente telefonico. Questi utenti utilizzano il modulo di Runtime mediante l’interazione con la piattaforma vocale.

FORNITORE APPLICAZIONE VOCALE. Si tratta di una classe astratta, definita per raccogliere la definizione degli Attori che utilizzano le interfacce web di amministrazione del sistema.

Il significato di questa suddivisione degli Attori ha lo scopo di chiarire il significato del ruolo che ognuno di essi rappresenta. Ogni utilizzatore reale rappresenta uno o più di questi Attori secondo la definizione del proprio ruolo.

AMMINISTRATORE. L’Attore Amministratore gestisce gli utenti, le istanze delle Applicazioni Vocali e la loro pubblicazione. Accede a tutte le interfacce del modulo Designer esclusa quella di configurazione.

DISEGNATORE. Definisce la composizione e il comportamento dell’Applicazione Vocale: i tipi di Nodo ed i loro legami. Accede esclusivamente alla definizione delle Applicazioni Vocali alle quali è stato abilitato dall’amministratore.

AUTORE. Definisce i contenuti delle aree di testo previsti dalle definizione dei Nodi che compongono l’Applicazione Vocale. Accede esclusivamente alla definizione delle Applicazioni Vocali alle quali è stato abilitato dall’amministratore.

CONFIGURATORE. Accede all’area dell’interfaccia web con le pagine per la configurazione del sistema. Non ha accesso alle interfacce per la definizione delle Applicazioni Vocali.

SVILUPPATORE. Questo utente non utilizza le interfacce del framework ma rappresenta chi si occupa della definizione e dello sviluppo degli adattatori verso le funzioni di business messe a disposizione da altri sistemi.

All’utente Sviluppatore pur appartenendo alla classe dei “Fornitori”, non è associato un ruolo specifico nell’interfaccia del modulo Designer. L’attività dello Sviluppatore si svolge, infatti, al di fuori del contesto dell’Applicazione Vocale. Lo Sviluppatore, in teoria, sviluppa funzioni di business logic o adattatori verso funzioni di business logic, secondo le indicazioni del Disegnatore per poi lasciare che il Configuratore definisca i descrittori necessari al sistema per interagire con queste funzioni (Servizi).

6 – R E Q U I S I T I 8 2

6.4.2 Designer

Amministratore

(from Use Case View)

Applicazioni

Config

Utenti

Disegnatore


Autore


Configuratore


Autenticazione

Figura 26 - Package Designer

Il package Designer rappresenta un modulo software indipendente, corrispondente al modulo Designer previsto dall’architettura logica e fisica del framework, ed è destinato a raccogliere tutte le interfacce di gestione. Queste interfacce si dividono in quattro gruppi: Gestione Utenti, Gestione Autenticazione, Gestione Applicazioni e Gestione Config.

PACKAGE GESTIONE UTENTI. Interfacce di gestione degli utenti.

PACKAGE GESTIONE AUTENTICAZIONE. Funzioni di login e logout.

PACKAGE GESTIONE APPLICAZIONI. Questo è il gruppo più corposo, in cui sono raccolte tutte le funzioni operative del modulo Designer.

PACKAGE GESTIONE CONFIG. Interfacce per la gestione della configurazione.

6 – R E Q U I S I T I 8 3

6 . 4 . 2 . 1 G E S T I O N E U T E N T I

Crea Utente

Amministratore


Associa Utente-Applicazione

Modifica Dati Utente

Associa Utente-Ruolo

Elimina Utente

Elenca Utenti

Figura 27 - Package Gestione Utenti

La gestione degli utenti è delegata al ruolo Amministratore.

UC CREA UTENTE. Crea un nuovo utente per il Designer.

UC ELENCA UTENTI. Può visualizzare l’elenco di tutti gli utenti definiti per il Designer.

UC ASSOCIA UTENTE-RUOLO. Associa ad ogni utente uno o più ruoli. Il ruolo dell’amministratore predefinito non può essere modificato.

UC MODIFICA DATI UTENTE. Modifica l’anagrafica di un utente.

UC ASSOCIA UTENTE-APPLICAZIONE. Determina per ogni utente a quali Applicazioni Vocali può accedere. Ogni Applicazione Vocale è automaticamente associata all’Amministratore che la crea.

UC ELIMINA UTENTE. Elimina un utente. L’utente amministratore predefinito non può essere eliminato.

6 – R E Q U I S I T I 8 4

6 . 4 . 2 . 2 G E S T I O N E A U T E N T I C A Z I O N E

Login

Logout

Cambia Password



Figura 28 - Package Gestione Autenticazione

Le funzioni di questo gruppo sono accessibili a tutti i ruoli del package Designer.

UC LOGIN. Funzione di autenticazione per l’accesso alle interfacce. Il successo dell’autenticazione determina la definizione di una sessione per l’utente.

UC LOGOUT. L’uscita tramite logout determina la chiusura della sessione corrente.

UC CAMBIA PASSWORD. Ogni utente può modificare la propria password di accesso. L’amministratore può modificare la password di tutti gli utenti.

6 – R E Q U I S I T I 8 5

6 . 4 . 2 . 3 G E S T I O N E A P P L I C A Z I O N I V O C A L I

Modifica Applicazione

Amministra Applicazione

Apri Runtime

Pubblica Applicazione su un Runtime

Elenca Runtime

Esporta Applicazione

Disegnatore


Autore


Visualizza Dettagli ApplicazioneVisualizza Elenco Applicazioni

Abilitate

Amministratore


Figura 29 – Package Gestione Applicazioni Vocali

Questo package raccoglie le funzionalità operative del modulo Designer, ossia le funzioni legate alla generazione e gestione delle Applicazioni Vocali. Da questo gruppo è escluso il ruolo di Configuratore.

PACKAGE AMMINISTRA APPLICAZIONE. Insieme di funzioni di gestione per il solo utente Amministratore.

PACKAGE MODIFICA APPLICAZIONE. Insieme delle funzioni di modifica e di specifica degli elementi che compongono l’Applicazione Vocale.

UC VISUALIZZA ELENCO APPLICAZIONI ABILITATE. La visualizzazione dell’elenco delle applicazioni è condizionata dalle autorizzazioni definite dall’Amministratore. In questo modo, tra l’altro, è possibile definire gruppi di lavoro indipendenti, su applicazioni diverse. Questa funzione viene invocata come home page dell’area “Applicazioni”.

UC VISUALIZZA DETTAGLI APPLICAZIONE. Il dettaglio dell’Applicazione Vocale selezionata consiste in un descrizione analitica della composizione dell’Applicazione, come il numero di Nodi, Variabili e Servizi che la compongono.

6 – R E Q U I S I T I 8 6

UC ESPORTA APPLICAZIONE. Questa funzione genera un descrittore, in forma di file compresso, che il sistema fa scaricare sulla macchina locale dell’utente che loha richiesto. Questo descrittore è identico a quello generato e trasportato dal sistema nell’ambiente di Runtime.

UC ELENCA RUNTIME. Visualizza l’elenco dei server di Runtime accessibili. La definizione dei server di Runtime è a cura del Configuratore. Ogni server può essere associato ad uno o più ruoli. Quindi l’elenco, per ogni utente, dipende dai ruoli che esso ricopre. In questo modo si realizza una definizione per ruolo dei diritti di accesso a server di Runtime con diverso “scopo”, come, ad esempio, quelli di sviluppo, test e produzione.

UC APRI RUNTIME. Funzione accessibile dall’elenco dei Runtime. Apre la console di amministrazione di un server di Runtime.

UC PUBBLICA APPLICAZIONE SU UN RUNTIME. Funzione accessibile dall’elenco dei Runtime. Pubblica l’Applicazione Vocale corrente sul server di Runtime selezionato. La pubblicazione consiste nella generazione e successivo invio, al server specificato, del descrittore dell’Applicazione Vocale corrente. Questo non significa necessariamente che l’Applicazione Vocale diventa “on-line” perché questo stato dipende dalla configurazione del server di Runtime che prende in carico il descrittore.

6.4.2.3.1 Amministra Applicazione Vocale

Crea Applicazione

Importa Applicazione

Amministratore


Elimina Applicazione

Rinomina Applicazione

Visualizza Dettagli Applicazione

(from Applicazioni)

Figura 30 - Package Amministra Applicazioni Vocali

6 – R E Q U I S I T I 8 7

Queste funzioni di amministrazione sono delegate al ruolo di Amministratore.

UC IMPORTA APPLICAZIONE. Esegue il caricamento (upload) di un descrittore di Applicazione Vocale. Una volta acquisito il descrittore, l’interfaccia richiede di indicare il nome della nuova Applicazione Vocale rappresentata dal descrittore. La nuova Applicazione Vocale generata è automaticamente associata all’utente che la ha importata.

UC CREA APPLICAZIONE. Crea il contesto per una nuova Applicazione Vocale. Richiede un nome identificativo, verifica che non esista un’altra applicazione con lo stesso nome, quindi genera la struttura di base.

UC VISUALIZZA DETTAGLI APPLICAZIONE. (Vedi “Package Gestione Applicazioni Vocali”) Genera un report che descrive la composizione dell’Applicazione Vocale: quanti Nodi, quante Variabili, quanti Servizi, etc.

UC ELIMINA APPLICAZIONE. Elimina l’Applicazione Vocale corrente. Viene rimosso tutto il contesto relativo all’applicazione: Nodi, Variabili, Istanze di Servizio e le associazioni con gli Utenti.

UC RINOMINA APPLICAZIONE. Rinomina l’Applicazione Vocale corrente. Dal punto di vista del modulo di Runtime, una Applicazione Vocale con un nome differente è a tutti gli effetti un’altra Applicazione Vocale.

6 – R E Q U I S I T I 8 8

6.4.2.3.2 Modifica Applicazione Vocale

Nodi

Variabili

Servizi

Specifica Nodo di Inizio

Associa Link Globali

Disegnatore


Autore


Figura 31 - Package Modifica Applicazione Vocale

PACKAGE GESTIONE NODI. Package che raccoglie tutte le funzioni di gestione dei Nodi: creazione, modifica, cancellazione, etc.

PACKAGE GESTIONE VARIABILI. Package che raccoglie tutte le funzioni di gestione delle Variabili. Accessibile solo al ruolo Disegnatore.

PACKAGE GESTIONE SERVIZI. Accessibile solo al ruolo Disegnatore. Package che raccoglie tutte le funzioni di gestione delle istanze dei Servizi.

UC SPECIFICA NODO DI INIZIO. Accessibile solo al ruolo Disegnatore. Definisce il Nodo di inizio dell’Applicazione Vocale.

UC ASSOCIA LINK GLOBALI. Accessibile solo al ruolo Disegnatore. Definisce l’insieme dei Link Globali validi per l’Applicazione Vocale. I Link Globali sono, in altre parole, la definizione di “comandi vocali” sempre disponibili durante l’esecuzione dell’Applicazione Vocale. Si chiamano Link perché l’unica azione associata al “comando vocale” si può

6 – R E Q U I S I T I 8 9

considerare come l’equivalente di un link su di una pagina web, ossia passa al Nodo indicato dalla definizione del Link.

6.4.2.3.3 Gesione Nodi

Elimina Nodo

Crea Nodo

Rinomina Nodo

Verifica Nodi

Disegnatore


Visualizza Elenco NodiAutore


Modifica Nodo

<<include>>

Figura 32 - Package Gestione Nodi

PACKAGE MODIFICA NODO. Per modifica di un Nodo si intende anche la sua definizione successiva alla creazione, per questo motivo questo package ha una relazione di inclusione con la funzione di creazione di un Nodo. Questo package rappresenta la specifica di tutti i tipi di Nodo previsti dal sistema.

UC CREA NODO. Accessibile solo al ruolo Disegnatore. Funzione di creazione di un nuovo Nodo. La creazione consiste sostanzialmente nella definizione del nome e del tipo di Nodo. Una volta determinato il tipo, il processo di creazione prosegue con la definizione (modifica) dei suoi parametri. Ogni nuovo Nodo deve essere inserito nell’insieme dei Nodi dell’Applicazione Vocale ma non deve compromettere il suo funzionamento.

6 – R E Q U I S I T I 9 0

UC ELIMINA NODO. Accessibile solo al ruolo Disegnatore. Elimina il Nodo. Il framework deve far si che l’eliminazione di un Nodo non comprometta l’integrità formale dell’Applicazione Vocale.

UC RINOMINA NODO. Accessibile solo al ruolo Disegnatore. Modifica il nome del Nodo. Questa modifica non deve compromettere la definizione dell’Applicazione Vocale. Il nome deve quindi essere inteso come nome di “visualizzazione”.

UC VISUALIZZA ELENCO NODI. Visualizza l’elenco dei Nodi che compongono l’Applicazione Vocale. Questo elenco costituisce il pannello di controllo per l’accesso alle funzioni sui singoli Nodi. Inoltre fornisce informazioni di supporto per la comprensione della struttura dell’Applicazione Vocale.

UC VERIFICA NODI. Funzione che lancia un processo di validazione della struttura fino a quel momento definita. La validazione è finalizzata alla determinazione di incompletezza della definizione, come, ad esempio, l’individuazione dell’uso in un Nodo di una Variabile non valorizzata (esiste un percorso che non la valorizza).

6.4.2.3.4 Modifica Nodo (Tipi di Nodo)

Esegui Servizio

Acquisisci Dato Cambia Applicazione

Link MenuLeggi Testo

Imposta Variabili

Trasferimento di Chiamata

Figura 33 – Package Modifica Nodo (Tipi di Nodo)

LEGGI TESTO. Definisce un Nodo che legge il testo in esso contenuto. All’interno del testo è possibile utilizzare le Variabili, con la notazione “[nomevariabile]”. Le Variabili vengono risolte con il valore corrente al momento del passaggio per il Nodo.

ESEGUI SERVIZIO. Definisce la modalità di richiamo di una funzione esterna al sistema, come ad esempio una operazione di somma tra due numeri o una lettura su una base dati. Pre definire un Nodo Esegui Servizio si deve selezionare una delle Istanza di Servizio precedentemente definite con l’apposita interfaccia.

La composizione esatta dell’interfaccia per la definizione di questo tipo di Nodo dipende dal descrittore di Servizio a cui fa riferimento l’Istanza utilizzata. In generale si richiede: la

6 – R E Q U I S I T I 9 1

definizione dei parametri di ingresso della funzione, assegnando a ciascuno una Variabile; dove registrare i valori restituiti, indicando per ciascuno una Variabile di destinazione; per ogni Codice di Ritorno previsto dal Servizio deve essere indicato un Nodo successivo. Questo nodo non presenta un comportamento vocale.

LINK. Specifica una grammatica che rappresenta un comando invocabile in qualunque momento della conversazione. Ad ogni Link è associato un Nodo successivo, invocato quando viene pronunciato il comando.

MENU. Modella un insieme di opzioni predefinite. Per ogni voce di menù è prevista la pronuncia di un testo, la definizione di una grammatica e l’indicazione del Nodo successivo. Quando l’utente pronuncia una parola contenuta in una di queste grammatiche, viene richiamato il Nodo della relativa voce di menu.

Questa definizione descrive anche il comportamento nel caso in cui la piattaforma vocale segnala di non trovare corrispondenze con la grammatica, oppure di non aver sentito. Per ogni caso è possibile specificare un testo da pronunciare e un Nodo successivo.

ACQUISISCI DATO. Definisce la modalità di acquisizione di un dato pronunciato dall’utente. Questo nodo ha una struttura che dipende dal tipo di dato che si intende acquisire. In particolare se si tratta di acquisire una o più parole, è necessario che sia specificata la grammatica di riferimento. La definizione della grammatica può essere occupata da una Variabile, che si presuppone conterrà la specifica di questa grammatica.

Quando l’utente ha pronunciato il dato il Runtime lo registra nella Variabile indicata dalla definizione del Nodo. Questa definizione descrive anche il comportamento nel caso in cui la piattaforma vocale segnala di non trovare corrispondenze con la grammatica, oppure di non aver sentito. Per ogni caso è possibile specificare un testo da pronunciare e un Nodo successivo.

CAMBIA APPLICAZIONE. Serve a definire il passaggio all’esecuzione di un’altra Applicazione Vocale. Nel definire la chiamata è possibile indicare l’insieme di parametri da trasmettere, indicandone il nome e per ciascuno viene associata la Variabile che contiene il valore. Non presenta un comportamento vocale.

IMPOSTA VARIABILI. Serve ad assegnare in modo diretto dei valori alle Variabili. Non presenta un comportamento vocale.

TRASFERIMENTO DI CHIAMATA. Definisce il comportamento di un trasferimento di chiamata. Richiede l’indicazione di un numero di telefono e la definizione del Nodi successivi relativi ai possibili casi di errore (occupato, non risponde, ecc.).

6 – R E Q U I S I T I 9 2

6.4.2.3.5 Gestione Variabil i

Crea Variabile

Rinomina Variabile

Elimina Variabile

Visualizza Elenco Variabili

Disegnatore


Figura 34 - Package Gestione Variabili

UC CREA VARIABILE. Crea la definizione di una nuova Variabile. Per la definizione viene richiesto il nome, il tipo ed una descrizione. Il tipo di variabile viene selezionato da un elenco predefinito, proposto dal sistema. I tipi base sono: numero, intero, testo e data.

UC VISUALIZZA ELENCO VARIABILI. Visualizza l’elenco di tutte le variabili definite per l’Applicazione Vocale. Ogni voce dell’elenco presenta il nome, il tipo e la descrizione di una variabile. Per ogni voce mette a disposizione il comando “Rinomina” e se la Variabile non è utilizzata il comando “Elimina”.

UC RINOMINA VARIABILE. Cambia il nome e la descrizione della Variabile. Il nome della Variabile non è l’identificativo interno al modello (la chiave primaria che la identifica è gestita in modo automatico), per questo motivo la modifica del nome non richiede interventi sul modello dell’Applicazione Vocale.

UC ELIMINA VARIABILE. Elimina la definizione di una Variabile.

6 – R E Q U I S I T I 9 3

6.4.2.3.6 Gestione Istanze di Servizio

Crea Istanza di Servizio

Disegnatore


Elimina Istanza di Servizio

Visualizza Elenco Istanze di Servizio

Figura 35 - Package Gestione Istanze di Servizio

UC CREA ISTANZA DI SERVIZIO. Definisce una nuova istanza di un Servizio. Le Istanze di Servizio definiscono un contesto statefull per l’esecuzione di un determinato Servizio all’interno di una Applicazione Vocale. Esempio: Se il Configuratore ha definito che una certa applicazione vocale può utilizzare il Servizio “Somma di due interi”, il Disegnatore del servizio può definire un’istanza di tale servizio da utilizzare richiamandola in un Nodo di tipo “Esegui Servizio”.

UC VISUALIZZA ELENCO ISTANZE DI SERVIZIO. Il Disegnatore può visualizzare l’elenco delle Istanze di Servizio definite per una data Applicazione Vocale.

UC ELIMINA ISTANZA DI SERVIZIO. Il Disegnatore può eliminare una Istanza di Servizio che non sia utilizzata all’interno dell’Applicazione Vocale.

6 – R E Q U I S I T I 9 4

6 . 4 . 2 . 4 G E S T I O N E C O N F I G U R A Z I O N I

Crea Descrittore di Configurazione

Elimina Descrittore di Configurazione

Modifica Descrittore di Configurazione

Visualizza Elenco Descrittori di Configurazione

Configuratore


Crea Schema VXML

Elimina Schema VXML

Modifica Schema VXML

Visualizza Elenco Schemi VXML

Figura 36 - Package Gestione Configurazione

L’accesso alle funzioni di configurazione è limitato agli utenti con ruolo Configuratore. Questo livello di configurazione è relativo al contesto di ogni singola Applicazione Vocale.

UC VISUALIZZA ELENCO DESCRITTORI DI CONFIGURAZIONE. Visualizza l’elenco di tutti Descrittori di configurazione dell’Applicazione Vocale corrente. I numero dei tipi di Descrittore dipende dalla definizione di un Descrittore di configurazione a livello di sistema.

UC CREA DESCRITTORE DI CONFIGURAZIONE. Crea un nuovo Descrittore di configurazione. Il Configuratore seleziona il tipo di Descrittore desiderato tra quelli disponibili ed il framework lo genera utilizzando come modello un template associato al tipo. I template dei Descrittori costituiscono parte della configurazione del sistema.

6 – R E Q U I S I T I 9 5

UC ELIMINA DESCRITTORE DI CONFIGURAZIONE. Elimina il Descrittore di configurazione selezionato.

UC MODIFICA DESCRITTORE DI CONFIGURAZIONE. Modifica la definizione ed il contenuto di un Descrittore di configurazione.

UC VISUALIZZA ELENCO SCHEMI VXML. Visualizza l’elenco di tutti gli Schemi VXML disponibili. Ogni Schema rappresenta l’implementazione di uno specifico tipo di Nodo.

UC CREA SCHEMA VXML. Definisce una nuova implementazione di un determinato tipo di Nodo. La composizione dello Schema è vincolata dagli elementi dinamici previsti dal Nodo che vuole implementare.

UC ELIMINA SCHEMA VXML. Elimina la definizione di uno Schema VXML.

UC MODIFICA SCHEMA VXML. Modifica la definizione ed il contenuto di uno Schema VXML.

6 – R E Q U I S I T I 9 6

6.4.3 Runtime

Utente Applicazio...


Associa Canali



Rimuovi Applicazione

Disattiva Applicazione

Attiva Applicazione

Esegue Applicazione col Debugger

Visualizza Elenco Applicazioni

Esecuzione

<<extend>>

Figura 37 - Package Runtime

PACKAGE ESECUZIONE. Questo insieme rappresenta l’engine che risponde alle richieste http di una Piattaforma Vocale generando gli opportuni documento VXML. La risposta è ottenuta assemblando gli Schemi VXML con i contenuti statici del Descrittore di Applicazione Vocale e con il valore delle Variabili definite in sessione.

UC VISUALIZZA ELENCO APPLICAZIONI. Presenta l’elenco di tutti i Descrittori di Applicazione Vocale pubblicati nel modulo Runtime. Ogni Applicazione Vocale in elenco può essere attivata o disattivata.

UC ESEGUE APPLICAZIONE COL DEBUGGER. L’interfaccia del debugger esegue un “override” dell’engine di runtime, applicando ad ogni tipo di Nodo un determinato template HTML al posto dello Schema VXML previsto. In questo modo è possibile interagire via browser con l’Applicazione Vocale effettivamente in esecuzione. Questa funzione permette

6 – R E Q U I S I T I 9 7

di verificare il comportamento di un’Applicazione Vocale senza necessariamente disporre di una Piattaforma Vocale.

UC ATTIVA APPLICAZIONE. Campia lo stato di un’Applicazione Vocale da Disattivata ad Attivata. Un’Applicazione Vocale quando Attivata risponde alle richieste http provenienti dalla Piattaforma Vocale e del debugger.

UC DISATTIVA APPLICAZIONE. Campia lo stato di un’Applicazione Vocale da Attivata ad Disattivata. Un’Applicazione Vocale quando Disattivata non risponde alle richieste provenienti dalla Piattaforma Vocale e del debugger.

UC RIMUOVI APPLICAZIONE. Rimuove il descrittore dell’Applicazione Vocale selezionata.

UC ASSOCIA CANALI. Il modulo Runtime prevede un insieme predefinito di Canali di accesso (indirizzi http) sui quali attestare i numerici telefono gestiti dalla Piattaforma Vocale. Attraverso questa interfaccia è possibile associare ad ogni canale una specifica Applicazione Vocale.

6 . 4 . 3 . 1 P A C K A G E E S E C U Z I O N E

Genera la definizione del Nodo Successivo

Interpreta un Nodo

Esegue un'azione sul Server

Voice Browser

Richiama un'Applicazione Vocale

Richiama il Nodo successivo

Fornitore Applicazione Vocale


Utente Applicazione Vocale


Figura 38 - Package Esecuzione

6 – R E Q U I S I T I 9 8

VOICE BROWSER. Dal punto di vista del Modulo Runtime, gli utenti dell’engine che realizza l’esecuzione delle Applicazioni Vocali sono rappresentati da un voice browser, ossia da un client http in grado di interagire con l’engine secondo il linguaggio VXML. Le funzioni descritte da questo insieme di Casi d’Uso descrivono le possibili iterazioni tra il Voice Browser e il modulo Runtime.

UC RICHIAMA UN’APPLICAZIONE VOCALE. Una determinata composizione dell’indirizzo http determina l’inizio dell’esecuzione di un’Applicazione Vocale. L’inizio dell’esecuzione coincide con l’inizializzazione di una nuova sessione http.

UC RICHIAMA IL NODO SUCCESSIVO. Il Voice Browser richiama uno degli indirizzi contenuti del documento VXML prodotto dal modulo di Runtime. Questo indirizzo contiene un attributo che, una volta valutato dal controller contenuto nell’engine, determina la produzione del documento VXML che realizza il Nodo successivo.

UC INTERPRETA UN NODO. L’interpretazione di ogni Nodo è composta di due fasi: la prima è realizzata dal modulo di Runtime e riguarda l’interpretazione del modello rappresentato dal descrittore di Applicazione Vocale; la seconda fase è realizzata dall’interpretazione da parte del voice browser. L’interpretazione di un Nodo è a carico del Voice Browser solo se il Nodo determina la produzione di un documento VXML. Alcuni tipo di Nodo, come quelli di tipo “Esegui Servizio” vengono interpretati esclusivamente dall’engine, perché non definiscono un comportamento vocale.

UC ESEGUE UN’AZIONE SUL SERVER. Funzione richiesta dai Nodi di tipo “Esegui Servizio”, per i quali l’interpretazione del Nodo definisce generalmente l’invocazione delle funzioni di Business Logic realizzate da un sistema esterno.

UC GENERA LA DEFINIZIONE DEL NODO SUCCESSIVO. Funzione richiesta da tutti i tipi di Nodo che definiscono un comportamento vocale.

7 Progettazione

Architettura del software

“Design Model”

Tipi di Nodo

Realizzazione dei Casi d’Uso

7.1 Introduzione In questo capitolo viene descritta l’implementazione del framework VocAppBuilder utilizzata all’interno del prodotto Tidytalk. Queste descrizioni sono volutamente limitate ad un certo livello di dettaglio, per rispettare la riservatezza delle informazioni richiesta dall’azienda Tidysoft che ha commissionato il prodotto. Per questo stesso motivo le descrizioni che seguono non utilizzano i formalismi e la rigorosità della documentazione tecnica del prodotto.

Non dovendo scendere al livello di dettaglio tipico della documentazione di progetto, si è scelto di non utilizzare un linguaggio formale di modellazione, a favore di una descrizione meno tecnica ma più accessibile.

7.2 Architettura del software Sostanzialmente, come più volte ripetuto, i moduli cha compongono il framework e di conseguenza il prodotto Tidytalk, sono Web Application sviluppate su tecnologie Java. Ciò nonostante, l’architettura del software di ciascun modulo è molto diversa.

7 – P R O G E T T A Z I O N E 1 0 0

7.2.1 Designer

Il modulo Designer è a tutti gli effetti una applicazione J2EE. Osserviamo lo schema di Figura 39, che riassume i livelli logici che compongono la sua architettura.

Struts

J2EE

Action Class

Entity EJB ( CMP 2.0 )

Session EJB

SQL

Database Relazionale

Session EJB Client

Presentazione

Logica

Persistenza

Value Object

Record Set

IE 5.5

Javascript

SERVER SIDE

TagLibs

JSP

HTML

Bean

DOM

CLIENT SIDE

Figura 39 - Architettura Logica del modulo Designer

7 – P R O G E T T A Z I O N E 1 0 1

DATABASE RELAZIONALE. Partendo dal basso, troviamo il livello “Database relazionale” che sfrutta il linguaggio SQL. Questo livello rappresenta lo strato di persistenza, ossia la conservazione duratura dell’informazione.

ENTITY EJB. Salendo di un livello troviamo gli “Entity Enterprise Java Bean”, che appartengono strettamente alla tecnologia J2EE. Questo livello definisce un modello in linguaggio Java dello strato di persistenza sottostante, in pratica per ogni elemento della base dati esiste un corrispondente Java, per ogni “Tabella” un “Entiy Bean”.

In particolare per questo livello si è scelto di utilizzare la specifica del J2EE 1.3 nota come CMP 2.0; questa specifica permette di realizzare una definizione degli Entity Bean completamente svincolata dalla scelta di una particolare implementazione (o marca) di database. In pratica lo strato di persistenza SQL può essere implementato su un qualsiasi tipo di database relazionale, senza la necessità di sviluppare degli adattatori.

La comunicazione tra lo strato SQL e quello J2EE avviene in modo trasparente dal punto di vista dell’utilizzatore degli oggetti Java; gli oggetti che realizzano il trasporto dei dati, i recordset, sono gestiti in modo automatico dal container J2EE su cui viene eseguita la web application.

SESSION EJB. Salendo ancora troviamo un livello che appartiene ancora fortemente alla specifica J2EE. Si tratta degli oggetti “Session” destinati alla gestione della logica applicativa, ed unica interfaccia di accesso allo strato di persistenza sottostante.

L’implementazione del framework prevede l’utilizzo esclusivamente di Session Bean di tipo “stateless”, ossia senza stato. In queste classi si raccoglie tutta la logica di gestione del grafo diretto ed agli altri elementi che compongono il modello interno di rappresentazione delle Applicazioni Vocali.

SESSION EJB CLIENT. Una buona regola per l’utilizzo di oggetti di tipo Session Bean è quello di utilizzare delle classi client come interfaccia di accesso. Gli strati superiori potranno accedere alle funzioni di logica applicativa solo attraverso le API realizzate da questa collezione di interfacce.

Gli oggetti che realizzano il trasporto dei dati tra i vari Session Bean e con le classi client, sono normali “JavaBean”, ma a questo livello per convenzione sono indicati come “Value Object”.

Gli strati superiori sono tutti dedicati alla “Presentation”, ossia alla definizione delle interfacce utente. L’implementazione in oggetto utilizza il framework Struts 1.1 per la definizione di questi livelli.

ACTION CLASS. Ogni Action Class definisce una specifica funzione dell’interfaccia utente. In pratica ad ogni specifica di un Caso d’Uso, corrisponde una Action Class. Il compito di queste classi è quello di gestire gli oggetti della sessione http (la sessione utente) ed invocare le necessarie funzioni esposte dalle API esposte dallo strato sottoastante.

Gli oggetti di sessione trattari dalle Action sono normali JavaBean.

7 – P R O G E T T A Z I O N E 1 0 2

JSP. Le “Java Server Page” rappresentano il livello che chiude la parte server-side dell’architettura. Ogni pagina ha il compito di presentare all’utente, in modo adeguato, i contentuti degli oggetti di sessione e deve esporre i comandi per l’invocazione delle Action.

Le interfacce del modulo Designer sono costituite da pagine JSP, ed utilizzano una serie di tag library proposte dal progetto Jakarta. Inoltre viene utilizzato il motore di templating (Tiles) contenuto in Struts.

HTML. Il risultato dell’interpretazione delle JSP da parte del Servlet Engine (nel nostro caso ad esempio Tomcat 4.1) sono le pagine HTML che vengono interpretate dal browser. Ogni pagina realizza all’interno del browser la definizione di un oggetto noto come DOM (Document Object Model) che costituisce l’oggetto du cui può operare il codice Javascript.

JAVASCRIPT. La logica contenuta a questo livello ha lo scopo di migliorare la presentazione e la gestione degli elementi dell’interfaccia.

7.2.2 Runtime

L’architettura del modulo Runtime, si veda Figura 40, è più semplice di quella del Designer. Il motivo principale di questa differenza è legato alla necessità di garantire alte prestazioni in fase di esecuzione. La scelta per il Designer di utilizzare la tecnologia J2EE, presenta molti vantaggi, ma pochi in questa direzione.

Struts

Action Class

Integration Adapter Client

Castor

Descrittori (XML)

Presentazione

Logica

Persistenza

SERVER SIDE

Velocity

VM

VXML

Bean

CLIENT SIDE

Value Object

Figura 40 - Architettura Logica del modulo Runtime

7 – P R O G E T T A Z I O N E 1 0 3

DESCRITTORI. Partendo ancora dal livello più basso, possiamo notare innanzi tutto l’assenza di una base dati. Lo strato di persistenza è rappresentato da descrittori, ossia file in formato XML. Le informazioni relative alla specifica di ogni Applicazione Vocale, una volta pubblicata, sono statiche, di qui l’opportunità di gestire l’informazione come file.

I descrittori, al momento opportuno, vengono caricati in RAM come oggetti di sessione, garantendo in questo modo la massima velocità di accesso ai loro contenuti.

La conversione dei descrittori in oggetti Java e viceversa viene realizzata tramite l’utilizzo di un altro framework, noto come Castor. Questi oggetti vanno a costituire buona parte dei Value Object necessari.

INTEGRATION ADAPTER CLIENT. La definizione del contenuto di questo livello dell’architettura non dipende dall’implementazione del framework, ma delle necessità di ogni singola Applicazione Vocale.

Da parte sua VocAppBuilder richiede semplicemente l’adozione di un determinato protocollo, espresso nella specifica di in un documento XML, ed l’utilizzo di una specifica interfaccia Java per l’implementazione delle classi client che accedono ai metodi di business logic di altri sistemi.

ACTION CLASS. Anche per il Runtime è stato utilizzato il framework Struts 1.1. In questo caso però la funzione di gestore della navigazione è limitata alle pagine di amministrazione (non indicate nello schema dell’architettura). Per la parte vocale l’elemento che realizza la funzione di “Controller” (secondo il modello MVC2) è realizzata da una Action Class che utilizza come “Model” la specifica del grafo che rappresenta l’Applicazione Vocale.

VM. Di fatto si tratta di pagine JSP. Le pagine VM gestite dal framework Velocity presentano però una struttura più semplice, rispetto alle JSP. Questo vantaggio è importante in quanto queste pagine VM non sono altro che degli Schemi VXML dei vari tipi di Nodo, previsti dal modello.

VXML. Il risultato dell’interpretazione delle pagine VM con il contenuto dei JavaBean prodotti dalla classe Action che fa da “Controller”, realizza infine le pagine VXML.

A fronte delle “request” provenienti da una Piattaforma Vocale, il Runtime risponde componendo i template (VM) con i contenuti e le regole contenute nel modello del grafo. Sia le VM che il modello del grafo sono prevaricati in memoria RAM, quindi la generazione delle pagine VXML è svolta con la massima efficienza.

Notiamo infine che per la parte VXML non è stata prevista la presenza di codice Javascript. Si tratta di una scelta, perchè anche se tecnicamente possibile, non ne è sorta la necessità.

7 – P R O G E T T A Z I O N E 1 0 4

7.3 “Design Model” “The design model is an object model describing the realization of use cases, and serves as an abstraction of the implementation model and its source code. The design model is used as essential input to activities in implementation and test.” ( www.upedu.org – Analysis & Design Artifact Set )

Quella citata è una definizione formale di Design Model, che descrive bene l’intento di quanto segue. La trattazione sarà però limitata ad una descrizione dei Casi d’Uso più significativi, in particolare quelli relativi alla definizione dell’Applicazione Vocale ed alla gestione della sua rappresentazione interna.

7.3.1 Nodi

Per cominciare ricordiamo che secondo l’idea della “Vision” (capitolo 6), si intende modellare ogni Applicazione Vocale, come un insieme di Nodi specializzati. Questo modello prevede in altre parole la definizione di un grafo dove i Nodi sono rappresentati da vertici tipizzati e l’interazione tra i Nodi (la navigazione) è descritta dagli archi che congiungono i vertici.

Formalmente il modello adottato è un “grafo diretto”, perchè ogni arco può essere “navigato” solo in una determinata direzione.

Arco

Vertice

Figura 41 - Esempio di grafo diretto

La definizione di Nodo all’interno del framework corrisponde alla composizione di un vertice con uno o più archi uscenti. In particolare ogni nuovo Nodo, aggiunto ad una Applicazione Vocale, presenta sempre almeno un arco uscente.

7 – P R O G E T T A Z I O N E 1 0 5

Nodo

[code-N] [code-2]

[code-1]

Ogni Nodo possiede quindi un certo numero di attributi: Nome, Descrizione, Tipo ed una collezione di Archi uscenti, ciascuno dei quali e identificato da un Code. Il significato degli archi ed del codice che li identifica dipende esclusivamente dal tipo di Nodo. In generale l’arco indica il Nodo successivo ed il suo Code contiene il valore discriminante per la sua scelta, rispetto agli altri archi uscenti dallo stesso Nodo.

Si supponga, ad esempio, che un certo Nodo rappresenti un menu (Nodo di tipo “Menu”). In questo caso esiste un arco uscente per ogni voce di menu, dove il Code di ciascun arco è un intero che indica semplicemente la posizione della voce nell’elenco.

7.3.2 Schemi VXML

La determinazione e definizione dei tipi di Nodo, è stata il risultato di due attività: da una parte un’attenta analisi della specifica VXML, dell’altra la formulazione di alcune “ragionevoli” limitazioni alle possibilità di interazione. Ciò che si è ottenuto è una collezione di blocchi di codice VXML, ciascuno dei quali realizza un determinato comportamento vocale, anche relativamente complesso. L’aspetto più importante è che alcune parti di questi blocchi di codice sono stati resi parametrici, ottenendo di fatto una collezione di template (modelli predefiniti). Questi template sono indicati nel framework come Schemi XVML.

I tipi di Nodo si differenziano quindi per il diverso tipo si Schema VXML che utilizzano e di conseguenza per il diverso comportamento vocale, ma soprattutto per la diversa composizione delle aree parametriche dello schema.

In fase di Design la definizione dei Nodi consiste nella determinazione e compilazione dei contenuti da inserire nelle aree parametriche. Questi contenuti vanno a costituire il Content, ossia la parte di “contenuto” del descrittore, che insieme all’indicazione del nome dello schema ed altri valori, costituisce la specifica di ciascun Nodo.

Per esemplificare questi concetti consideriamo il caso del Nodo di tipo “Leggi Testo” utilizzato nell’esempio “Servizio Notte”.

7 – P R O G E T T A Z I O N E 1 0 6

7 . 3 . 2 . 1 S C H E M A V X M L

Nello schema possiamo osservare la presenza di due “segnaposto” relativi rispettivamente al testo da pronunciare ed il nome del server che va a comporre l’indirizzo http del Nodo successivo.





<prompt timeout="0s">${vRequest.content.textField}</prompt>

</field>

<filled/>

<noinput>

<goto next="${vSession.webRoot}vocal-action.do?next=default" />

</noinput>

</form>

</vxml>

7 – P R O G E T T A Z I O N E 1 0 7

7 . 3 . 2 . 2 C O N T E N T

Il nome del server è un parametro definito a livello di Applicazione e non costituisce parte dei parametri del Nodo. Il Content che definisce la specifica del Nodo, quindi, è composto da un solo elemento.


<vertex-output-content valid="true">

<text-field>Buona sera. Risponde la segreteria automatica della "Pizza e Fichi".

Siamo spiacenti, i nostri uffici a quest'ora sono chiusi.</text-field>

</vertex-output-content>

Possiamo notare che il Content non contiene informazioni relative al nome del Nodo successivo. Questa informazione infatti, secondo il design pattern MVC2, non gli compete. Il nodo “Leggi Testo” prevede un unico arco di uscita con nome “default” e l’associazione di questo arco con il Nodo successivo è registrata nel grafo.

7.4 Tipi di Nodo I paragrafi seguenti descrivono la struttura di ciascun tipo di Nodo. Per ogni tipo viene indicata una descrizione del comportamento vocale (ossia dal punto di vista dell’utente telefonico), una descrizione del comportamento dal punto di vista del sistema (il Runtime) e la composizione delle parti parametriche che vanno a comporre la relativa interfaccia sul modulo Designer.

7.4.1 Nodo: Leggi Testo

FUNZIONE VOCALE Legge un testo.

7 – P R O G E T T A Z I O N E 1 0 8

Testo Testo che deve essere pronunciato dalla piattaforma vocale. Il testo può contenere delle variabili nella forma:[NomeVariabile].

Schema Selezionare uno schema. Lo schema di default utilizza le impostazioni di default della piattaforma.

CAMPI DELL’INTERFACCIA

Nodo Successivo

La definizione prevede un solo caso di uscita, invocato al termine della pronuncia del testo.

COMPORTAMENTO IN RUNTIME

Il Sistema recupera il testo, sostituisce il valore delle variabili ed applica lo schema indicato. La piattaforma vocale legge il testo ottenuto, indipendentemente dalle parole pronunciate dall’utente.

7.4.2 Nodo: Esegui Servizio

FUNZIONE VOCALE Esegue l’Azione appartenente ad un Servizio.

PARAMETRI RICHIESTI

Nome Parametro (0-N occorrenze)

Variabile dal quale recuperare il valore per il parametro.

PARAMETRI RESTITUITI

Nome Parametro (0-N occorrenze)

Variabile al quale assegnare il valore del parametro.

CODICE DI RITORNO

Codice (1-N occorrenze)

Nodo da richiamare nel caso la funzione restituisca il codice indicato.


Il Sistema esegue una funzione logica o un accesso in lettura/scrittura su di un sistema esterno. La funzione eseguita è quella indicata come Azione e scelta tra le funzioni fornite dal Servizio. Per l’esecuzione il Sistema utilizza come valori di ingresso le Variabili indicate come Parametri richiesti e scrive i valori generati nelle Variabili associate ai Parametri Restituiti. L’esecuzione di una Azione può prevedere diversi casi di risposta, l’insieme dei Codici di ritorno permette di associare ad ogni codice uno specifico Nodo (eventualmente lo stesso).

7 – P R O G E T T A Z I O N E 1 0 9

7.4.3 Nodo: Link

FUNZIONE VOCALE Definisce un comando vocale valido in tutta l’Applicazione Vocale

Grammatica Una parola, o un elenco di parole separate dal carattere “|”.



Nodo Successivo

Nodo richiamato dalla piattaforma quando riceve il comando vocale pronunciato dall’utente telefonico.


Le grammatiche specificate nei Nodi Link sono sempre attive nel corso dell’esecuzione dell’Applicazione Vocale. Quando l’utente pronuncia una parola contenuta in una di queste grammatiche, il Sistema reagisce richiamando il Nodo corrispondente. ATTENZIONE. Per essere attivi, i nodi Link devono essere associati all’Applicazione Vocale nella definizione dei Link Globali.

7.4.4 Nodo: Menu

FUNZIONE VOCALE Legge un testo composto da una introduzione ed certo numero di voci di menu. Quando l’utente pronuncia una parola corrispondente ad una voce di menu, il Sistema passa al Nodo successivo associato a quella voce di menu.

Testo Testo che deve essere pronunciato dalla piattaforma vocale. Il testo può contenere delle variabili nella forma:[NomeVariabile].



7 – P R O G E T T A Z I O N E 1 1 0

Testo

Testo della voce di menu. Il testo deve indicare all’utente qual è la parola da pronunciare per selezionare la voce stessa. La parola deve essere una di quelle indicate nella grammatica. Se la parola chiave non viene indicata la voce ed il relativo link comunque attivo. Il testo può contenere delle variabili nella forma:[NomeVariabile].

Grammatica

Una parola, un elenco di parole separate dal carattere “|” oppure una variabile nel formato:[NomeVariabile].

DTMF Una singola cifra da 0 a 9.

Voce di menu (1-N occorrenze)

Nodo Successivo

Indica il nodo invocato quando l’utente pronuncia una delle parole definite nella grammatica.

Testo

Testo pronunciato in occorrenza dell’evento di noinput generato dalla piattaforma quando “non ha sentito”, ossia quando la piattaforma stabilisce che l’utente non ha parlato. Noinput

(1-3 occorrenze)

Nodo Successivo

Indica il Nodo da richiamare in occasione dell’evento di noinput. Selezionando - REPROMPT - si indica alla piattaforma che dopo aver pronunciato il Testo si desidera venga ripetuto il comportamento del Nodo.

7 – P R O G E T T A Z I O N E 1 1 1

Nomatch (1-3 occorrenze)

Testo

Testo pronunciato in occorrenza dell’evento di nomatch generato dalla piattaforma quando “non ha capito”, ossia quando le parole pronunciate dall’utente non trovano alcuna corrispondenza con le parole contenute nella grammatica di riferimento.

Nodo Successivo

Indica il Nodo da richiamare in occasione dell’evento di nomatch. Selezionando - REPROMPT - si indica alla piattaforma che dopo aver pronunciato il Testo si desidera venga ripetuto il comportamento del Nodo.


Il Sistema compone un testo composto dal testo dell’introduzione seguito dai testi delle varie voci di menu, nell’ordine in cui sono rappresentate sull’interfaccia. Sostituisce il valore delle variabili ed applica lo schema indicato. La piattaforma vocale legge il testo ottenuto rimanendo contemporaneamente in ascolto delle parole dell’utente. Quando trova una corrispondenza con una parola contenuta in una delle Grammatiche, richiama il Nodo successivo associato alla Grammatica, senza attendere la conclusione della lettura.

7.4.5 Nodo: Acquisisci Dato

FUNZIONE VOCALE Acquisisce un valore pronunciato dall’utente telefonico e lo assegna ad una Variabile.

CAMPI DELL’INTERFACCIA Testo

Testo che deve essere pronunciato dalla piattaforma vocale. Il testo può contenere delle variabili nella forma: [NomeVariabile].

7 – P R O G E T T A Z I O N E 1 1 2

Grammatica

Questo campo è presente solo nel caso in cui l’acquisizione sia di tipo testo. La grammatica può essere costituita da una Variabile ( si indica il nome tra parentesi quadre [NomeVariabile] ).

Variabile L’elenco propone Variabili di tipo compatibile al tipo acquisizione scelto.


Noinput (1-3 occorrenze)

Testo

Testo pronunciato in occorrenza dell’evento di noinput generato dalla piattaforma quando “non ha sentito”, ossia quando la piattaforma stabilisce che l’utente non ha parlato.

Nodo Successivo

Indica il Nodo da richiamare in occasione dell’evento di noinput. Selezionando - REPROMPT - si indica alla piattaforma che dopo aver pronunciato il Testo si desidera venga ripetuto il comportamento del Nodo.

Nomatch (1-3 occorrenze)

Testo

Testo pronunciato in occorrenza dell’evento di nomatch generato dalla piattaforma quando “non ha capito”, ossia quando le parole pronunciate dall’utente non trovano alcuna corrispondenza con le parole contenute nella grammatica di riferimento.

7 – P R O G E T T A Z I O N E 1 1 3

Nodo Successivo

Indica il Nodo da richiamare in occasione dell’evento di nomatch.Selezionando - REPROMPT - si indica alla piattaforma che dopo aver pronunciato il Testo si desidera venga ripetuto il comportamento del Nodo.


La piattaforma vocale legge il testo, inteso a definire la richiesta del dato. Quando l’utente telefonico pronuncia una parola (un serie di numeri o una frase), il Sistema confronta il valore con la grammatica di riferimento. Se trova corrispondenza assegna il valore rilevato alla Variabile indicata nella specifica del Nodo, quindi passa al Nodo successivo.

7.4.6 Nodo: Cambia Applicazione

FUNZIONE VOCALE Richiama e passa il controllo ad un URL

URL

Indirizzo http di una web application in VXML. Può essere l’indirizzo di attivazione di un’altra Applicazione Vocale anche su un diverso server di Runtime (nel formato: http://nomeserver : porta/TidytalkRuntime/vocal-start.do?vApplicationId=nomeApplicazioneVocale)


In caso di Errore

Nodo richiamato in caso di errore nell’invocazione dell’URL.


Il Sistema richiama l’URL indicato in modo equivalente alla selezione di un link su di una pagina web.

7.4.7 Nodo: Imposta Variabili

FUNZIONE VOCALE Imposta valori costanti alle Variabili.


Nodo Successivo

Nodo richiamato successivamente alla valorizzazione delle Variabili.

7 – P R O G E T T A Z I O N E 1 1 4

Variabile Nome della variabile da valorizzare

Valore Valore da assegnare alla Variabile

Voce (0-N occorrenze)

Descrizione Descrizione del significato dell’assegnazione


I Sistema nel passaggio da questo tipo di Nodo, valorizza le Variabili con i valori impostati nella specifica del Nodo.

7.4.8 Nodo: Trasferimento di Chiamata

FUNZIONE VOCALE Richiama e passa il controllo ad un'altra linea telefonica

Telefono Numero di telefono chiamato dalla piattaforma vocale. CAMPI

DELL’INTERFACCIA In caso di Errore

Nodo richiamato in caso di errore a seguito del tentativo di trasferimento di chiamata.


Il Sistema richiama il numero di telefono e quando l’utente chiamato risponde il sistema mette in comunicazione i due utenti.

7.5 Realizzazione dei Casi d’Uso Di seguito sono riportate le descrizioni delle implementazioni di alcuni dei Casi d’Uso più significativi. Il loro scopo è semplicemente quello di esemplificare l’utilizzo del modello di rappresentazione interno (il grafo) descritto in precedenza.

7.5.1 Caso d’Uso: “Crea Applicazione”

Quando un utente Amministratore richiede la creazione di una nuova Applicazione Vocale, il framework esegue due azioni in successione. Prima chiede all’Amministratore di indicare un nome con cui identificare l’Applicazione Vocale, quindi procede con la creazione degli elementi che costituiscono la definizione minima di Applicazione Vocale per il modello interno.

7 – P R O G E T T A Z I O N E 1 1 5

ApplicazioneVocale

Nodi Variabili Servizi

Figura 42 - Tipi di elementi associati a ciascuna Applicazione Vocale

Il contesto generato per ciascuna Applicazione Vocale prevede tre diversi insiemi di elementi: l’insieme dei Nodi, l’insieme delle Variabili e l’insieme delle istanze di Servizi (più brevemente Servizi). Gli insiemi delle Variabili e dei Servizi sono inizialmente vuoti. L’insieme dei Nodi prevede, al contrario, un insieme minimo di Nodi, in modo tale che l’Applicazione Vocale appena creata anche se “non fa nulla”, sia formalmente corretta e di fatto immediatamente eseguibile dal modulo di Runtime. Questo insieme contiene da subito tre Nodi particolari: Start, End e Global.

Nodi

START

EXIT

[default] GLOBAL

[global]

Figura 43 - Applicazione Vocale "minima"

Il Nodo “Start” è un tipo specifico (tipo Start) e rappresenta l’unico punto di ingresso dell’Applicazione Vocale. A questo Nodo non è associato alcun comportamento “vocale”, semplicemente nel momento in cui il sistema di Runtime deve dare inizio all’esecuzione di una Applicazione Vocale, esso cerca il Nodo “Start”, per poi seguire l’arco con Code uguale “default” che porta al vero e proprio Nodo di inizio dell’Applicazione Vocale. Il passaggio

7 – P R O G E T T A Z I O N E 1 1 6

per il Nodo “Start” determina l’attivazione di una nuova sessione, ossia l’inizializzazione di un contesto isolato dedicato esclusivamente all’utente telefonico corrente.

Il Nodo “Exit” è anch’esso un tipo specifico (tipo Exit) e rappresenta l’unico punto di uscita dell’Applicazione Vocale. Tutti i Nodi, con la sola eccezione del Nodo “Global”, quando vengono generati possiedono un arco verso il Nodo “Exit”. Quando il Runtime raggiunge il Nodo “Exit”, il contesto (la sessione) dell’Applicazione Vocale in esecuzione viene cancellato.

Il Nodo “Glogal” è ancora una volta un tipo specifico (tipo Global) ed è un Nodo di “utilità”. Come il Nodo “Exit” rappresenta un’eccezione rispetto alla regola di specifica dei Nodi, perché al momento della sua creazione non possiede un arco uscente. Inizialmente questo Nodo non ha alcuna utilità operativa. Il suo significato ed il dettaglio del suo comportamento sarà chiarito in seguito.

Complessivamente questo insieme rappresenta il supporto per la collocazione dei Nodi veri e propri. Si può dire che questi tre Nodi rappresentano il contenitore dell’insieme dei Nodi.

7.5.2 Caso d’Uso: “Crea Nodo”

Creare un nuovo Nodo significa aggiungere al un nuovo vertice al grafo, con un numero di archi uscenti che dipende dal tipo di Nodo. La funzione di creazione di un nuovo Nodo accessibile agli utenti Disegnatori.

Nodi

START

EXIT

[default] GLOBAL

[global]

"Benvenuto"

[default]

Figura 44 - Nuovo Nodo di tipo "Leggi Testo" in una Applicazione Vocale vuota

Il framework richiede la specifica del tipo di Nodo e di un nome identificativo, quindi genera la nuova istanza di Nodo relazionando con il Nodo “Exit” in modo automatico tutti gli archi uscenti previsti dal tipo di Nodo scelto. In questo modo il Nodo entra a far parte dell’insieme

7 – P R O G E T T A Z I O N E 1 1 7

dei Nodi dell’Applicazione Vocale, ma non essendo ancora puntato da alcun altro Nodo, non è di fatto raggiungibile. Il nuovo Nodo non è raggiungibile, quindi l’Applicazione Vocale non risente ancora di questa aggiunta.

Nei diagrammi di rappresentazione del grafo che modella l’Applicazione Vocale,per convenzione, il colore del Nodo indica il Tipo. Il colore azzurro è utilizzato per il tipo "Leggi Testo".

Nel diagramma non viene rappresentata la parte di contenuto statico associata al Nodo, perché non è significativa dal punto di vista della gestione del modello. Non bisogna comunque dimenticare che per alcuni tipi di Nodo il modello prevede una relazione con un Content (una unità di informazione strutturata), che contiene le informazioni necessarie all’esecuzione del singolo Nodo. Con riferimento all’esempio del “Servizio Notte”, il Nodo “Benvenuto” rappresentato nel diagramma di Figura 44 deve essere di tipo “Leggi Testo” e deve quindi possedere una relazione con un il Content che contiene la specifica del testo.

"Benvenuto"

[default]

Buonasera. Risponde la segreteria automatica della "Pizza e Fichi". Siamo spiacenti, i nostri uffici a quest'ora sono chiusi.

Figura 45 - Esempio di riferiemnto al Content

7.5.3 Caso d’Uso: “Specifica Nodo di Inizio”

Specificare il Nodo di inizio, significa agganciare il Nodo “Start” dell’Applicazione Vocale al Nodo desiderato. Per fare un esempio supponiamo di trovarci nella condizione descritta dalla Figura 44, che descrive il caso in cui è stato appena creato un Nodo di tipo “Leggi Testo” per pronunciare un messaggio di benvenuto. Se si decide che questo Nodo è il Nodo di Inizio, il grafo sarà modificato come riportato nella figura che segue.

7 – P R O G E T T A Z I O N E 1 1 8

Nodi

START

EXIT

[default]

GLOBAL

[global]

"Benvenuto"

[default]

Figura 46 - Impostazione del Nodo di Inizio

Per quanto semplice e forse poco utile, quella descritta è un’Applicazione Vocale a tutti gli effetti. L’aggiunta di altri Nodi determina la crescita del grafo, ma seguendo questo modello, vi sarà sempre uno ed un solo Nodo di ingresso (Nodo Start) ed uno ed un solo Nodo di uscita (Nodo Exit), ed un numero indefinito di altri Nodi e di percorsi attraverso di essi.

7.6 Sintesi delle fasi di sviluppo Come indicato in precedenza per la definizione delle fasi di sviluppo di questo sistema, si è fatto riferimento ad un’implementazione semplificata del processo proposto dal Rational Unified Process. Questa versione è nota con il nome di “Unified Process Education” ed è consultabile all’indirizzo www.upedu.org.

In Figura 47 è rappresentato lo schema degli artifacts, ossia la documentazione prevista da questo processo, e la loro interazione.

7 – P R O G E T T A Z I O N E 1 1 9

Figura 47 - Composizione degli "Artifacts" previsti da UPEDU

In questo schema possiamo ritrovare la corrispondenza con alcune parti di questo documento:

Il capitolo 4, “Gli obbiettivi del framework”. Rappresenta le “stakeholder requests”

Il capitolo 5, “Vision” della soluzione, è ovviamente la “Vision”. Osserviamo però che questo parte è stata sviluppata in modo così ampio solo ai fini della tesi. Normalmente è un documento facoltativo.

Il capitolo 6, “Requisiti”, sintetizza i contenuti della “Software Requirements Specification” presentando un estratto dei diagrammi dei Casi d’Uso.

Il capitolo 8, “Progettazione”, in fine, fonde e riassume i contenuti dei documenti di “Software Architecture”, “Design Model” ed “Implementation Model”.

La parte relativa ai test, all’analisi dei rischi ed alla gestione del progetto è stata trascurata, perché in questo contesto (la tesi) non sono significativi.

Dal punto di vista pratico si può dire che tutte le fasi di sviluppo ora citate si sono svolte nell’arco di due anni, dall’estate del 2002 ad oggi.

8 Conclusioni

Obiettivi raggiunti

I limiti del progetto

Sviluppi futuri

8.1 Obiettivi raggiunti Come è stato illustrato, il framework VocAppBuilder, progettato per la costruzione di servizi telefonici automatici, è in grado di rendere la programmazione accessibile anche a personale non specializzato.

Questo obiettivo è stato ottenuto, sostanzialmente, attraverso il mascheramento della complessità della scrittura del codice VXML.

È stato usato, a tal fine, un approccio simile a quello adottato dai sistemi di web publishing, che mascherano agli utilizzatori non tecnici la complessità del codice HTLM. Questo approccio si fonda sull’introduzione di un modello di rappresentazione interna che separa i gruppi logici che costituiscono l’oggetto del sistema, in questo caso l’applicazione vocale. Questo modello permette di separare tra loro e rendere indipendenti:

la complessità del codice VXML e l’integrazione con i sistemi di back-end (Model);

la specifica dei testi delle frasi (View);

la logica della conversazione (Control).

L’adozione del framework, grazie a queste sue caratteristiche, garantisce una notevole riduzione dei costi tanto nella fase di progetto, quanto nella gestione delle modifiche e nell’aggiornamento dei contenuti.

8 – C O N C L U S I O N I 1 2 1

8.2 I limiti del progetto È da considerarsi che la semplificazione di cui sopra, ottenuta con il modello del grafo, costringe lo sviluppatore dell’applicazione a costruirla seguendo quel modello soltanto, vincolandone la libertà progettuale.

Inoltre, un limite intrinseco del framework è il suo utilizzo abbinato necessariamente alle piattaforme vocali, cosicché il suo successo dipende dalla diffusione di queste ultime.

Allo stato attuale, l’implementazione del framework è limitata nel numero di tipi di Nodi definiti. I Nodi definiti, infatti, non coprono tutte le funzioni e i dettagli resi disponibili dalla specifica del VXML. Questo limite, tuttavia, è facilmente superabile introducendo altri tipi di Nodo a seconda delle esigenze specifiche di un’applicazione.

8.3 Sviluppi futuri Il modello del grafo, che costituisce il cuore della soluzione, presenta numerose opportunità di sviluppo. Alcune delle più interessanti sono:

La possibilità di richiamare ed utilizzare nella definizione di una Applicazione Vocale, una o più altre Applicazioni Vocali, alla stregua di chiamate ad una procedura.

L’integrazione di un generatore di Grammatiche.

La realizzazione di un editor per la preparazione assistita degli Schemi VXML.

Infine si constata che il framework è per sua natura adatto ad un utilizzo di tipo ASP. Si può ipotizzare un potenziamento delle funzionalità anche in questa direzione.

Fonti

java.sun.com/blueprints/guidelines Raccoglie le pubblicazioni ufficiali circa la realizzazione di software basati sul linguaggio java.

www.w3.org/2001/sw

www.w3.org/TR/voicexml20/

Raccoglie la specifica dei principali standard utilizzati all’interno di questo progetto, in particolare la specifica del linguaggio VXML.

www.speechworks.com

www.nuance.com

www.scansoft.com

www.speech.be.philips.com

www.loquendo.com

www.waycom.it

www.tellme.com

Siti dei produttori di riferimento nel mercato delle piattaforme vocale.

www.webopedia.com

www.wordiq.com

http://www.iec.org/online/tutorials/voice_portal/

Siti utilizzati per recuperare alcune delle definizioni riportate nel testo.

www.loquendo.com/it/products/voxnauta_architecture.htm

Specifica dell’architettura della piattaforma vocale Voxnauta.

www.upedu.org

Sito internet che contiene la specifica del “Unified Process Education”, la versione ridotta del RUP che è stata utilizzata come riferimento nelle fasi di progettazione e sviluppo del framework.

www.apache.org

www.jdom.org

www.castor.org

Siti ufficiali dei produttori dei framework e componenti software utilizzati ed integrati all’interno del framework VocAppBuilder.

APPENDICI

La Tecnologia di Riconoscimento Vocale

Il processo coinvolto sia per la sintesi che per il riconoscimento presuppone che l'input sia diviso in piccoli pezzi, perchè la processazione sia efficiente, e, nel caso del parlato, i segmenti devono essere elementi linguistici significativi. Nella sintesi "text-to speech", il testo in ingresso è facilmente diviso in parole e lettere; mentre il segnale parlato, che serve come input per un ASR, fornisce soltanto indicazioni dei confini del segmento fonetico. Cambi evidenti e veloci nello spettro del parlato o l'ampiezza, sono spesso usati per valutare i confini del segmento, che sono irrilevabili a causa del fenomeno della coarticolazione. I confini che corrispondono alle parole sono molto difficili da determinare, tranne quando il soggetto fa le pause.

Il problema della segmentazione può essere parzialmente superato attraverso particolari stili del parlato. Si possono distinguere tre stili di parlato (presentati di seguito in ordine di difficoltà crescente): parlato che presenta parole isolate o frasi discrete, parlato con parole connesse, parlato continuo. Il riconoscimento del parlato continuo permette una conversazione naturale, con poco adattamento dello stile dell'utente al sistema. Il parlato continuo permette di ottenere l'input più veloce, ma è la classe più difficile da riconoscere.

La seconda differenza fra sintesi e riconoscimento riguarda l'adattamento. I soggetti umani che ascoltano modificano le loro aspettative quando odono il parlato sintetico e usualmente lo accettano, considerando il fenomeno della poca naturalezza del parlato sintetico come se fosse dovuto ad un accento dialettale o straniero. Nei sistemi ASR è il computer che deve adattarsi alle voci differenti usate in input. E' più facile produrre una voce sintetica alla quale il soggetto umano si adatta che progettare un algoritmo di riconoscimento che può riuscire ad identificare tutti i differenti modi con i quali i parlanti pronunciano la stessa frase, con variazioni anche all'interno dello stesso soggetto, in tempi differenti. I sistemi attuali richiedono che i parlanti si adattino attraverso una modificazione del parlato, per esempio facendo una pausa fra una parola e l'altra, parlando chiaramente e lentamente.

L A T E C N O L O G I A D I R I C O N O S C I M E N T O V O C A L E 1 2 6

Approccio della Pattern Recognition Il riconoscimento automatico del parlato (ASR) può essere visto come un compito di pattern recognition, applicando le tecniche sviluppate nel settore della robotica (identificazione di immagini) o comunicazioni di dati (conversione di segnali analogici in informazione digitale). In pratica, il riconoscimento del parlato richiede una mappatura tra il parlato e il testo, cosicchè ogni possibile forma di onda in input è identificata con il suo testo corrispondente. In questo contesto, il termine testo viene usato per identificare le parole, le frasi o altre unità linguistiche che il parlante pensa e verbalizza. Tutti i compiti di pattern recognition, incluso l'ASR, utilizzano due fasi: il training e il riconoscimento. La fase di training stabilisce una memoria di referenza o un dizionario di modelli del parlato, che sono assegnati alle etichette del testo. In sistemi indipendenti dal parlante, la fase di training è prodotta durante lo sviluppo del sistema e spesso combina metodi manuali e automatici. I sistemi di riconoscimento commerciali, dipendenti dal parlante, sono forniti dalle case produttrici. La fase di riconoscimento automatico tenta di assegnare una etichetta ai modelli di input sconosciuti.

Per comprendere il testo, i software di riconoscimento vocale devono innanzitutto costruire una rappresentazione digitale delle parole pronunciate. La digitalizzazione della voce trasforma una grandezza fisica in un valore numerico. L'onda sonora prodotta mette in moto le molecole nell’aria e nello spazio. Il microfono “cattura” questo movimento e lo converte in segnali elettrici. Questi segnali, che riproducono la voce, vengono sottoposti a due processi: il campionamento (sampling) e la quantizzazione.

Il campionamento consiste nella misurazione del segnale a intervalli fissi, per ottenere un certo numero di segmenti che consentono di ricostruire la sua variazione nel tempo. Tanto più piccoli saranno gli intervalli di tempo, tanto più precisa sarà la ricostruzione e minore sarà la quantità di informazione persa. Il numero di intervalli di campionamento viene espresso in numero di rilevazioni per secondo e si definisce “frequenza di campionamento”, la cui unità di misura è l'henz (1 Hz = l rilevazione al secondo). Lo standard della voce umana varia tra i 100 e 3.000 Hz.

Una volta campionato il suono, ci si trova di fronte a un secondo problema. Le variazioni possibili del segnale (e quindi i possibili valori dei campioni) sono teoricamente infinite ed è quindi impossibile assegnare a ciascuna un codice numerico. Con la quantizzazione si provvede a “semplificare” l'onda, eliminando l'intervallo di valori che si ritiene al di sotto della soglia percettiva umana. In questo modo si trasformano gli infiniti valori della grandezza fisica in una misurazione che può avere solo un determinato numero. Tanto più alto sarà il numero di intervalli, che si definiscono tecnicamente quanti, tanto più accurata sarà la rappresentazione del segnale e minore sarà l'informazione persa.

Digitalizzata la frase, il software provvede a scandirla in modo da suddividere le singole parole. In passato occorreva separare ogni parola con una breve pausa: oggi si è giunti a riconoscere il parlato continuo, grazie a particolari tecniche di analisi che individuano le

L A T E C N O L O G I A D I R I C O N O S C I M E N T O V O C A L E 1 2 7

brevi inflessioni che si pronunciano involontariamente tra una parola e l'altra. Le parole, a loro volta, vengono suddivise in fonemi, cioè nell'unità minima del parlato. La durata di un fonema oscilla tra i 10 e i 40 millisecondi, per cui le parole vengono divise in intervelli minimi di 10 millisecondi l'uno; questa operazione è conosciuta come "modellazione/classificazione".

Segue la fase di riconoscimento vero e proprio, chiamata "ricerca": i fonemi vengono confrontati con il modello acustico dell'utente (generato durante la fase di addestramento) e con il modello delle parole presenti nel vocabolario: si ricostruiscono in questo modo le parole. Per migliorare l'accuratezza, queste vengono confrontate con un modello lessicale e con un modello del linguaggio presenti nei dizionari dei programmi, in modo da estrapolare, in base alle regole grammaticali, le parole poco chiare. Il risultato di tutto il processo è la stringa di testo contenente la parola o la frase pronunciata dall'utente.

Il modello acustico di Loquendo Il modello acustico utilizzato ad esempio da Loquendo rientra nella categoria dei sistemi di Pattern Recognition. Il modello si basa sul concetto di unità acustiche di stazionarietà e transizione:

Le unità ad uno stato modellano la parte stazionaria di ciascun fonema

Le unità a due stati modellano gli effetti coarticolatori tra due fonemi adiacenti

Queste unità hanno una migliore accuratezza e occupazione di memoria rispetto ai Trifoni.

Per la lingua italiana Loquendo ha identificato secondo questo modello: 391 unità di stazionarietà e transizione e 27 fonemi indipendenti dal contesto.

La Tecnologia di Sintesi del Parlato

La concatenazione più semplice di parlato sintetico è quella di parole o frasi. Questo approccio può produrre parlato di alta qualità (in correlazione con il metodo di sintesi adottato), ma è limitato dal bisogno di conservare in memoria tutte le frasi che devono essere sintetizzate, dopo che sono state pronunciate da uno speeker, sia in isolamento che in contesto di frase.

Per raggiungere il massimo di naturalezza nel parlato sintetico, ogni parola o frase deve essere pronunciata con il tempo e l'intonazione appropriata per tutte le frasi. Così, se una parola potrebbe presentarsi in parecchie strutture sintattiche, la sua pronuncia dovrebbe essere registrata e archiviata utilizzando la simulazione delle sentenze in diversi contesti. La concatenazione di parole originalmente pronunciate in isolamento, di solito porta alla non intelligibilità e alla mancanza di naturalezza. La durata delle unità archiviate deve essere considerata, poiché varia in contesti differenti di frasi (specie per le unità più piccole delle parole).

Tipi di unità del parlato Per la sintesi dei testi, sistemi avanzati generano parlato da sequenze di suoni di base, che sostanzialmente riducono le necessità di memoria poiché molti linguaggi hanno soltanto 30-40 fonemi. Comunque, i tratti dello spettro di questi brevi suoni concatenati (50-200 ms), devono essere uniti, per evitare un parlato discontinuo. Il problema è che la pronuncia di un fonema in una parola o frase, è fortemente dipendente dal suo contesto fonetico (i fonemi vicini, l'intonazione e ritmo del parlato). Il processo di levigatura e di accordamento, così come il bisogno di calcolare una appropriata intonazione per ogni contesto, risulta, in sintetizzatori complessi, con un output parlato meno naturale.

I sistemi commerciali sono stati progettati perchè producessero parole o concatenazione di foni. Attualmente i ricercatori puntano allo sviluppo di un modello piùaccurato, legando unità di "taglia intermedia" di parlato archiviato, come sillabe, mezze sillabe e difoni. Una Sillaba consiste di un nucleo centrale (con vocali e dittonghi), più alcune consonanti vicine. Alcune volte i confini della sillaba sono incerti. Le demisillabe sono unità di parlato ottenute

L A T E C N O L O G I A D I S I N T E S I D E L P A R L A T O 1 2 9

dividento le sillabe a metà, con il taglio sulla vocale. I difoni sono ottenuti dividendo un’onda del parlato in unità fonetizzate, con il taglio nella metà di ogni fono.

L'appianamento dei parametri dello spettro ai confini tra unità, è più importante per unità piccole (foni) e decresce in importanza, man mano che la concatenatione di unità aumenta. Questo perchè diminuisce il numero dei confini per ogni secondo, nel parlato in uscita. Per unità di taglia uguale, l'appianamento è molto più semplice quando le unità da congiungere approssimativamente combaciano con gli spettri ai confini. I sistemi che congiungono i foni, devono comunque usare complesse regole di "smoothing" (appunto appianamento), per rappresentare la coarticolazione nel tratto vocale. Poichè non si sa ancora tutto intorno al fenomeno della coarticolazione, non è possibile stabilire un complesso insieme di regole che descrivano come i parametri dello spettro, per ogni fono, sono modificati dai foni che si articolano nelle vicinanze del punto preciso del tratto vocale dove il fono esaminato viene prodotto. I sintetizzatori "difoni" cercano di aggirare il problema, archiviando le transizioni del parametro da un fono al prossimo, in quanto la coarticolazione influenza in primo luogo solo i foni immediatamente adiacenti al punto di articolazione del fono che si sta esaminando.

Analisi del Testo

Sintesi Vocale

Segnale Acustico

Labels, Fonemi e Prosodia

Conoscenza della lingua

Dizionario Acustico

Testo di Input

- Progettazione Base Dati- Acquisizione segnale- Segmentazione fonemi- Analisi del segnale

Figura 48 - Modello delle fasi di preparazione del motore di sintesi vocale

Un algoritmo sintetizzatore generalmente consiste di: a) una riserva di memoria dei parametri del parlato, ottenuti dal parlato naturale e organizzati in termini di unità di parlato (dizionario acustico); b) un programma di regole per concatenare queste unità, levigando i parametri per creare traiettorie del tempo dove necessario (conoscenza della lingua).

L A T E C N O L O G I A D I S I N T E S I D E L P A R L A T O 1 3 0

Estratto delle “W3C Recommendation” per il VoiceXML 2.0

Questo capitolo di appendice riporta le parti più interessanti del capitolo introduttivo del documento “Voice Extensible Markup Language (VoiceXML) Version 2.0” pubblicato come “W3C Recommendation” il 16 March 2004. Il documento completo è consultabile all’indirizzo internet “www.w3.org/TR/voicexml20/”.

Overview […]

The origins of VoiceXML began in 1995 as an XML-based dialog design language intended to simplify the speech recognition application development process within an AT&T project called Phone Markup Language (PML). As AT&T reorganized, teams at AT&T, Lucent and Motorola continued working on their own PML-like languages.

In 1998, W3C hosted a conference on voice browsers. By this time, AT&T and Lucent had different variants of their original PML, while Motorola had developed VoxML, and IBM was developing its own SpeechML. Many other attendees at the conference were also developing similar languages for dialog design; for example, such as HP's TalkML and PipeBeach's VoiceHTML.

The VoiceXML Forum was then formed by AT&T, IBM, Lucent, and Motorola to pool their efforts. The mission of the VoiceXML Forum was to define a standard dialog design language that developers could use to build conversational applications. They chose XML as the basis for this effort because it was clear to them that this was the direction technology was going.

In 2000, the VoiceXML Forum released VoiceXML 1.0 to the public. Shortly thereafter, VoiceXML 1.0 was submitted to the W3C as the basis for the creation of a new international standard. VoiceXML 2.0 is the result of this work based on input from W3C Member companies, other W3C Working Groups, and the public.

V X M L - W 3 C R E C C O M E N D A T I O N 1 3 2

Introduction

VoiceXML is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed initiative conversations. Its major goal is to bring the advantages of Web-based development and content delivery to interactive voice response applications.

Here are two short examples of VoiceXML. The first is the venerable "Hello World":






version="2.0">

<form>

<block>Hello World!</block>

</form>

</vxml>

The top-level element is <vxml>, which is mainly a container for dialogs. There are two types of dialogs: forms and menus. Forms present information and gather input; menus offer choices of what to do next. This example has a single form, which contains a block that synthesizes and presents "Hello World!" to the user. Since the form does not specify a successor dialog, the conversation ends.

Our second example asks the user for a choice of drink and then submits it to a server script:







version="2.0">

<form>

<field name="drink">

<prompt>Would you like coffee, tea, milk, or nothing?</prompt>

<grammar src="drink.grxml" type="application/srgs+xml"/>

</field>

<block>

<submit next="http://www.drink.example.com/drink2.asp"/>

</block>

</form>

</vxml>

A field is an input field. The user must provide a value for the field before proceeding to the next element in the form. A sample interaction is:


C (computer): Would you like coffee, tea, milk, or nothing?

H (human): Orange juice.

C: I did not understand what you said. (a platform-specific default message.)

C: Would you like coffee, tea, milk, or nothing?

H: Tea

C: (continues in document drink2.asp)

Background

This section contains a high-level architectural model, whose terminology is then used to describe the goals of VoiceXML, its scope, its design principles, and the requirements it places on the systems that support it.

A R C H I T E C T U R A L M O D E L

The architectural model assumed by this document has the following components:

Figura 49 - Architectural Model


A document server (e.g. a Web server) processes requests from a client application, the VoiceXML Interpreter, through the VoiceXML interpreter context. The server produces VoiceXML documents in reply, which are processed by the VoiceXML interpreter. The VoiceXML interpreter context may monitor user inputs in parallel with the VoiceXML interpreter. For example, one VoiceXML interpreter context may always listen for a special escape phrase that takes the user to a high-level personal assistant, and another may listen for escape phrases that alter user preferences like volume or text-to-speech characteristics.

The implementation platform is controlled by the VoiceXML interpreter context and by the VoiceXML interpreter. For instance, in an interactive voice response application, the VoiceXML interpreter context may be responsible for detecting an incoming call, acquiring the initial VoiceXML document, and answering the call, while the VoiceXML interpreter conducts the dialog after answer. The implementation platform generates events in response to user actions (e.g. spoken or character input received, disconnect) and system events (e.g. timer expiration). Some of these events are acted upon by the VoiceXML interpreter itself, as specified by the VoiceXML document, while others are acted upon by the VoiceXML interpreter context.

G O A L S O F V O I C E X M L

VoiceXML's main goal is to bring the full power of Web development and content delivery to voice response applications, and to free the authors of such applications from low-level programming and resource management. It enables integration of voice services with data services using the familiar client-server paradigm. A voice service is viewed as a sequence of interaction dialogs between a user and an implementation platform. The dialogs are provided by document servers, which may be external to the implementation platform. Document servers maintain overall service logic, perform database and legacy system operations, and produce dialogs. A VoiceXML document specifies each interaction dialog to be conducted by a VoiceXML interpreter. User input affects dialog interpretation and is collected into requests submitted to a document server. The document server replies with another VoiceXML document to continue the user's session with other dialogs.

VoiceXML is a markup language that:

Minimizes client/server interactions by specifying multiple interactions per document.

Shields application authors from low-level, and platform-specific details.

Separates user interaction code (in VoiceXML) from service logic (e.g. CGI scripts).

Promotes service portability across implementation platforms. VoiceXML is a common language for content providers, tool providers, and platform providers.


Is easy to use for simple interactions, and yet provides language features to support complex dialogs.

While VoiceXML strives to accommodate the requirements of a majority of voice response services, services with stringent requirements may best be served by dedicated applications that employ a finer level of control.

S C O P E O F V O I C E X M L

The language describes the human-machine interaction provided by voice response systems, which includes:

Output of synthesized speech (text-to-speech).

Output of audio files.

Recognition of spoken input.

Recognition of DTMF input.

Recording of spoken input.

Control of dialog flow.

Telephony features such as call transfer and disconnect.

The language provides means for collecting character and/or spoken input, assigning the input results to document-defined request variables, and making decisions that affect the interpretation of documents written in the language. A document may be linked to other documents through Universal Resource Identifiers (URIs).

P R I N C I P L E S O F D E S I G N

VoiceXML is an XML application.

The language promotes portability of services through abstraction of platform resources.

The language accommodates platform diversity in supported audio file formats, speech grammar formats, and URI schemes. While producers of platforms may support various grammar formats the language requires a common grammar format, namely the XML Form of the W3C Speech Recognition Grammar Specification [SRGS], to facilitate interoperability. […]

The language supports ease of authoring for common types of interactions.


The language has well-defined semantics that preserves the author's intent regarding the behavior of interactions with the user. Client heuristics are not required to determine document element interpretation.

The language recognizes semantic interpretations from grammars and makes this information available to the application.

The language has a control flow mechanism.

The language enables a separation of service logic from interaction behavior.

It is not intended for intensive computation, database operations, or legacy system operations. These are assumed to be handled by resources outside the document interpreter, e.g. a document server.

General service logic, state management, dialog generation, and dialog sequencing are assumed to reside outside the document interpreter.

The language provides ways to link documents using URIs, and also to submit data to server scripts using URIs.

VoiceXML provides ways to identify exactly which data to submit to the server, and which HTTP method (GET or POST) to use in the submittal.

The language does not require document authors to explicitly allocate and deallocate dialog resources, or deal with concurrency. Resource allocation and concurrent threads of control are to be handled by the implementation platform.

I M P L E M E N T A T I O N P L A T F O R M R E Q U I R E M E N T S

This section outlines the requirements on the hardware/software platforms that will support a VoiceXML interpreter.

Document acquisition. The interpreter context is expected to acquire documents for the VoiceXML interpreter to act on. The "http" URI scheme must be supported. In some cases, the document request is generated by the interpretation of a VoiceXML document, while other requests are generated by the interpreter context in response to events outside the scope of the language, for example an incoming phone call. When issuing document requests via http, the interpreter context identifies itself using the "User-Agent" header variable with the value "<name>/<version>", for example, "acme-browser/1.2"

Audio output. An implementation platform must support audio output using audio files and text-to-speech (TTS). The platform must be able to freely sequence TTS and audio output. If an audio output resource is not available, an error.noresource event must be thrown. Audio files are referred to by a URI. The language specifies a required set of audio file formats which must be supported; additional audio file formats may also be supported.


Audio input. An implementation platform is required to detect and report character and/or spoken input simultaneously and to control input detection interval duration with a timer whose length is specified by a VoiceXML document. If an audio input resource is not available, an error.noresource event must be thrown.

It must report characters (for example, DTMF) entered by a user. Platforms must support the XML form of DTMF grammars described in the W3C Speech Recognition Grammar Specification. They should also support the Augmented BNF (ABNF) form of DTMF grammars described in the W3C Speech Recognition Grammar Specification.

It must be able to receive speech recognition grammar data dynamically. It must be able to use speech grammar data in the XML Form of the W3C Speech Recognition Grammar Specification. It should be able to receive speech recognition grammar data in the ABNF form of the W3C Speech Recognition Grammar Specification, and may support other formats such as the JSpeech Grammar Format [JSGF] or proprietary formats. Some VoiceXML elements contain speech grammar data; others refer to speech grammar data through a URI. The speech recognizer must be able to accommodate dynamic update of the spoken input for which it is listening through either method of speech grammar data specification.

It must be able to record audio received from the user. The implementation platform must be able to make the recording available to a request variable. The language specifies a required set of recorded audio file formats which must be supported; additional formats may also be supported.

Transfer The platform should be able to support making a third party connection through a communications network, such as the telephone.

Concepts

A VoiceXML document (or a set of related documents called an application) forms a conversational finite state machine. The user is always in one conversational state, or dialog, at a time. Each dialog determines the next dialog to transition to. Transitions are specified using URIs, which define the next document and dialog to use. If a URI does not refer to a document, the current document is assumed. If it does not refer to a dialog, the first dialog in the document is assumed. Execution is terminated when a dialog does not specify a successor, or if it has an element that explicitly exits the conversation.


D I A L O G S A N D S U B D I A L O G S

There are two kinds of dialogs: forms and menus. Forms define an interaction that collects values for a set of form item variables. Each field may specify a grammar that defines the allowable inputs for that field. If a form-level grammar is present, it can be used to fill several fields from one utterance. A menu presents the user with a choice of options and then transitions to another dialog based on that choice.

A subdialog is like a function call, in that it provides a mechanism for invoking a new interaction, and returning to the original form. Variable instances, grammars, and state information are saved and are available upon returning to the calling document. Subdialogs can be used, for example, to create a confirmation sequence that may require a database query; to create a set of components that may be shared among documents in a single application; or to create a reusable library of dialogs shared among many applications.

S E S S I O N S

A session begins when the user starts to interact with a VoiceXML interpreter context, continues as documents are loaded and processed, and ends when requested by the user, a document, or the interpreter context.

A P P L I C A T I O N S

An application is a set of documents sharing the same application root document. Whenever the user interacts with a document in an application, its application root document is also loaded. The application root document remains loaded while the user is transitioning between other documents in the same application, and it is unloaded when the user transitions to a document that is not in the application. While it is loaded, the application root document's variables are available to the other documents as application variables, and its grammars remain active for the duration of the application, subject to the grammar activation rules.

Figure 2 shows the transition of documents (D) in an application that share a common application root document (root).


Figura 50 - Transitioning between documents in an application

G R A M M A R S

Each dialog has one or more speech and/or DTMF grammars associated with it. In machine directed applications, each dialog's grammars are active only when the user is in that dialog. In mixed initiative applications, where the user and the machine alternate in determining what to do next, some of the dialogs are flagged to make their grammars active (i.e., listened for) even when the user is in another dialog in the same document, or on another loaded document in the same application. In this situation, if the user says something matching another dialog's active grammars, execution transitions to that other dialog, with the user's utterance treated as if it were said in that dialog. Mixed initiative adds flexibility and power to voice applications.

E V E N T S

VoiceXML provides a form-filling mechanism for handling "normal" user input. In addition, VoiceXML defines a mechanism for handling events not covered by the form mechanism.

Events are thrown by the platform under a variety of circumstances, such as when the user does not respond, doesn't respond intelligibly, requests help, etc. The interpreter also throws events if it finds a semantic error in a VoiceXML document. Events are caught by catch elements or their syntactic shorthand. Each element in which an event can occur may specify catch elements. Furthermore, catch elements are also inherited from enclosing elements "as if by copy". In this way, common event handling behavior can be specified at any level, and it applies to all lower levels.


L I N K S

A link supports mixed initiative. It specifies a grammar that is active whenever the user is in the scope of the link. If user input matches the link's grammar, control transfers to the link's destination URI. A link can be used to throw an event or go to a destination URI.

VoiceXML Elements

Element Purpose

<assign> Assign a variable a value

<audio> Play an audio clip within a prompt

<block> A container of (non-interactive) executable code

<catch> Catch an event

<choice> Define a menu item

<clear> Clear one or more form item variables

<disconnect> Disconnect a session

<else> Used in <if> elements

<elseif> Used in <if> elements

<enumerate> Shorthand for enumerating the choices in a menu

<error> Catch an error event

<exit> Exit a session

<field> Declares an input field in a form

<filled> An action executed when fields are filled

<form> A dialog for presenting information and collecting data

<goto> Go to another dialog in the same or different document

< > S if h iti DTMF


Element Purpose

<help> Catch a help event

<if> Simple conditional logic

<initial> Declares initial logic upon entry into a (mixed initiative) form

<link> Specify a transition common to all dialogs in the link's scope

<log> Generate a debug message

<menu> A dialog for choosing amongst alternative destinations

<meta> Define a metadata item as a name/value pair

<metadata> Define metadata information using a metadata schema

<noinput> Catch a noinput event

<nomatch> Catch a nomatch event

<object> Interact with a custom extension

<option> Specify an option in a <field>

<param> Parameter in <object> or <subdialog>

<prompt> Queue speech synthesis and audio output to the user

<property> Control implementation platform settings.

<record> Record an audio sample

<reprompt> Play a field prompt when a field is re-visited after an event

<return> Return from a subdialog.

<script> Specify a block of ECMAScript client-side scripting logic

<subdialog> Invoke another dialog as a subdialog of the current one

<submit> Submit values to a document server


Element Purpose

<throw> Throw an event.

<transfer> Transfer the caller to another destination

<value> Insert the value of an expression in a prompt

<var> Declare a variable

<vxml> Top-level element in each VoiceXML document

Document Structure and Execution

A VoiceXML document is primarily composed of top-level elements called dialogs. There are two types of dialogs: forms and menus. A document may also have <meta> and <metadata> elements, <var> and <script> elements, <property> elements, <catch> elements, and <link> elements.

E X E C U T I O N W I T H I N O N E D O C U M E N T

Document execution begins at the first dialog by default. As each dialog executes, it determines the next dialog. When a dialog doesn't specify a successor dialog, document execution stops.

Here is "Hello World!" expanded to illustrate some of this. It now has a document level variable called "hi" which holds the greeting. Its value is used as the prompt in the first form. Once the first form plays the greeting, it goes to the form named "say_goodbye", which prompts the user with "Goodbye!" Because the second form does not transition to another dialog, it causes the document to be exited.







version="2.0">

<meta name="author" content="John Doe"/>

<meta name="maintainer" content="[email protected]"/>

<var name="hi" expr="'Hello World!'"/>

<form>

<block>

<value expr="hi"/>

<goto next="#say_goodbye"/>

</block>

</form>

<form id="say_goodbye">

<block>

Goodbye!

</block>

</form>

</vxml>


Alternatively the forms can be combined:






version="2.0">

<meta name="author" content="John Doe"/>

<meta name="maintainer" content="[email protected]"/>

<var name="hi" expr="'Hello World!'"/>

<form>

<block>

<value expr="hi"/> Goodbye!

</block>

</form>

</vxml>

Attributes of <vxml> include:


version The version of VoiceXML of this document (required). The current version number is 2.0.

xmlns The designated namespace for VoiceXML (required). The namespace for VoiceXML is defined to be http://www.w3.org/2001/vxml.

xml:base The base URI for this document as defined in [XML-BASE]. As in [HTML], a URI which all relative references within the document take as their base.

xml:lang The language identifier for this document . If omitted, the value is a platform-specific default.

application The URI of this document's application root document, if any.

Table 2: <vxml> Attributes

Language information is inherited down the document hierarchy: the value of "xml:lang" is inherited by elements which also define the "xml:lang" attribute, such as <grammar> and <prompt>, unless these elements specify an alternative value.

E X E C U T I N G A M U L T I - D O C U M E N T A P P L I C A T I O N

Normally, each document runs as an isolated application. In cases where you want multiple documents to work together as one application, you select one document to be the application root document, and the rest to be application leaf documents. Each leaf document names the root document in its <vxml> element.

When this is done, every time the interpreter is told to load and execute a leaf document in this application, it first loads the application root document if it is not already loaded. The application root document remains loaded until the interpreter is told to load a document that belongs to a different application. Thus one of the following two conditions always holds during interpretation:

The application root document is loaded and the user is executing in it: there is no leaf document.

The application root document and a single leaf document are both loaded and the user is executing in the leaf document.


If there is a chain of subdialogs defined in separate documents, then there may be more than one leaf document loaded although execution will only be in one of these documents.

When a leaf document load causes a root document load, none of the dialogs in the root document are executed. Execution begins in the leaf document.

There are several benefits to multi-document applications.

The root document's variables are available for use by the leaf documents, so that information can be shared and retained.

Root document <property> elements specify default values for properties used in the leaf documents.

Common ECMAScript code can be defined in root document <script> elements and used in the leaf documents.

Root document <catch> elements define default event handling for the leaf documents.

Document-scoped grammars in the root document are active when the user is in a leaf document, so that the user is able to interact with forms, links, and menus in the root document.

Here is a two-document application illustrating this:

Application root document (app-root.vxml)






version="2.0">

<var name="bye" expr="'Ciao'"/>

<link next="operator_xfer.vxml">


<grammar type="application/srgs+xml" root="root" version="1.0">

<rule id="root" scope="public">operator</rule>

</grammar>

</link>

</vxml>

Leaf document (leaf.vxml)






version="2.0" application="app-root.vxml">

<form id="say_goodbye">

<field name="answer">

<grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/>

<prompt>Shall we say <value expr="application.bye"/>?</prompt>

<filled>


<if cond="answer">

<exit/>

</if>

<clear namelist="answer"/>

</filled>

</field>

</form>

</vxml>

In this example, the application is designed so that leaf.vxml must be loaded first. Its application attribute specifies that app-root.vxml should be used as the application root document. So, app-root.vxml is then loaded, which creates the application variable bye and also defines a link that navigates to operator-xfer.vxml whenever the user says "operator". The user starts out in the say_goodbye form:

C: Shall we say Ciao?

H: Si.

C: I did not understand what you said. (a platform-specific default message.)

C: Shall we say Ciao?

H: Ciao

C: I did not understand what you said.

H: Operator.

C: (Goes to operator_xfer.vxml, which transfers the caller to a human operator.)

Note that when the user is in a multi-document application, at most two documents are loaded at any one time: the application root document and, unless the user is actually interacting with the application root document, an application leaf document. A root document's <vxml> element does not have an application attribute specified. A leaf document's <vxml> element does have an application attribute specified. An interpreter


always has an application root document loaded; it does not always have an application leaf document loaded.

The name of the interpreter's current application is the application root document's absolute URI. The absolute URI includes a query string, if present, but it does not include a fragment identifier. The interpreter remains in the same application as long as the name remains the same. When the name changes, a new application is entered and its root context is initialized. The application's root context consists of the variables, grammars, catch elements, scripts, and properties in application scope.

During a user session an interpreter transitions from one document to another as requested by <choice>, <goto> <link>, <subdialog>, and <submit> elements. Some transitions are within an application, others are between applications. The preservation or initialization of the root context depends on the type of transition:

ROOT TO LEAF WITHIN APPLICATION. A root to leaf transition within the same application occurs when the current document is a root document and the target document's application attribute's value resolves to the same absolute URI as the name of the current application. The application root document and its context are preserved.

LEAF TO LEAF WITHIN APPLICATION. A leaf to leaf transition within the same application occurs when the current document is a leaf document and the target document's application attribute's value resolves to the same absolute URI as the name of the current application. The application root document and its context are preserved.

LEAF TO ROOT WITHIN APPLICATION. A leaf to root transition within the same application occurs when the current document is a leaf document and the target document's absolute URI is the same as the name of the current application. The current application root document and its context are preserved when the transition is caused by a <choice>, <goto>, or <link> element. The root context is initialized when a <submit> element causes the leaf to root transition, because a <submit> always results in a fetch of its URI.

ROOT TO ROOT. A root to root transition occurs when the current document is a root document and the target document is a root document, i.e. it does not have an application attribute. The root context is initialized with the application root document returned by the caching policy. The caching policy is consulted even when the name of the target application and the current application are the same.

SUBDIALOG. A subdialog invocation occurs when a root or leaf document executes a <subdialog> element. Subdialog invocation creates a new execution context. The application root document and its context in the calling document's execution context are preserved untouched during subdialog execution, and are used again once the subdialog returns. A subdialog's new execution context has its own root context and, possibly, leaf context. When the subdialog is invoked with a non-empty URI reference, the caching policy is used to acquire the root and leaf documents that will be used to initialize the new root and leaf contexts. If a subdialog is invoked with an empty URI reference and a fragment identifier,


e.g. "#sub1", the root and leaf documents remain unchanged, and therefore the current root and leaf documents will be used to initialize the new root and leaf contexts.

INTER-APPLICATION TRANSITIONS. All other transitions are between applications which cause the application root context to be initialized with the next application's root document.

If a document refers to a non-existent application root document, an error.badfetch event is thrown. If a document's application attribute refers to a document that also has an application attribute specified, an error.semantic event is thrown.

The following diagrams illustrate the effect of the transitions between root and leaf documents on the application root context. In these diagrams, boxes represent documents, box texture changes identify root context initialization, solid arrows symbolize transitions to the URI in the arrow's label, dashed vertical arrows indicate an application attribute whose URI is the arrow's label.

Figura 51 - Transitions that Preserve the Root Context

In this diagram, all the documents belong to the same application. The transitions are identified by the numbers 1-4 across the top of the figure. They are:

A transition to URI A results in document 1, the application context is initialized from document 1's content. Assume that this is the first document in the session. The current application's name is A.


Document 1 specifies a transition to URI B, which yields document 2. Document 2's application attribute equals URI A. The root is document 1 with its context preserved. This is a root to leaf transition within the same application.

Document 2 specifies a transition to URI C, which yields another leaf document, document 3. Its application attribute also equals URI A. The root is document 1 with its context preserved. This is a leaf to leaf transition within the same application.

Document 3 specifies a transition to URI A using a <choice>, <goto>, or <link>. Document 1 is used with its root context intact. This is a leaf to root transition within the same application.

The next diagram illustrates transitions which initialize the root context.

Figura 52 - Transitions that Initialize the Root Context

Document 1 specifies a transition to its own URI A. The resulting document 4 does not have an application attribute, so it is considered a root document, and the root context is initialized. This is a root to root transition.

Document 4 specifies a transition to URI D, which yields a leaf document 5. Its application attribute is different: URI E. A new application is being entered. URI E produces the root document 6. The root context is initialized from the content of document 6. This is an inter-application transition.

Document 5 specifies a transition to URI A. The cache check returns document 4 which does not have an application attribute and therefore belongs to application A, so the root context is initialized. Initialization occurs even though


this application and this root document were used earlier in the session. This is an inter-application transition.

S U B D I A L O G S

A subdialog is a mechanism for decomposing complex sequences of dialogs to better structure them, or to create reusable components. For example, the solicitation of account information may involve gathering several pieces of information, such as account number, and home telephone number. A customer care service might be structured with several independent applications that could share this basic building block, thus it would be reasonable to construct it as a subdialog. This is illustrated in the example below. The first document, app.vxml, seeks to adjust a customer's account, and in doing so must get the account information and then the adjustment level. The account information is obtained by using a subdialog element that invokes another VoiceXML document to solicit the user input. While the second document is being executed, the calling dialog is suspended, awaiting the return of information. The second document provides the results of its user interactions using a <return> element, and the resulting values are accessed through the variable defined by the name attribute on the <subdialog> element.

Customer Service Application (app.vxml)






version="2.0">

<form id="billing_adjustment">

<var name="account_number"/>

<var name="home_phone"/>

<subdialog name="accountinfo" src="acct_info.vxml#basic">

<filled>



<assign name="account_number" expr="accountinfo.acctnum"/>

<assign name="home_phone" expr="accountinfo.acctphone"/>

</filled>

</subdialog>

<field name="adjustment_amount">

<grammar type="application/srgs+xml" src="/grammars/currency.grxml"/>

<prompt>

What is the value of your account adjustment?


</prompt>

<filled>

<submit next="/cgi-bin/updateaccount"/>

</filled>

</field>

</form>

</vxml>

Document Containing Account Information Subdialog (acct_info.vxml)






version="2.0">

<form id="basic">

<field name="acctnum">

<grammar type="application/srgs+xml" src="/grammars/digits.grxml"/>

<prompt> What is your account number? </prompt>

</field>

<field name="acctphone">

<grammar type="application/srgs+xml" src="/grammars/phone_numbers.grxml"/>

<prompt> What is your home telephone number? </prompt>

<filled>



<return namelist="acctnum acctphone"/>

</filled>

</field>

</form>

</vxml>

Subdialogs add a new execution context when they are invoked.The subdialog could be a new dialog within the existing document, or a new dialog within a new document.

Subdialogs can be composed of several documents. Figure 5 shows the execution flow where a sequence of documents (D) transitions to a subdialog (SD) and then back.


Figura 53 - Subdialog composed of several documents returning from the last subdialog document

The execution context in dialog D2 is suspended when it invokes the subdialog SD1 in document sd1.vxml. This subdialog specifies execution is to be transfered to the dialog in sd2.vxml (using <goto>). Consequently, when the dialog in sd2.vxml returns, control is returned directly to dialog D2.

Figure 6 shows an example of a multi-document subdialog where control is transferred from one subdialog to another.


Figura 54 - Subdialog composed of several documents returning from the first subdialog document

The subdialog in sd1.vxml specifies that control is to be transfered to a second subdialog, SD2, in sd2.vxml. When executing SD2, there are two suspended contexts: the dialog context in D2 is suspending awaiting SD1 to return; and the dialog context in SD1 awaiting SD2 to return. When SD2 returns, control is returned to the SD1. It in turn returns control to dialog D2.

F I N A L P R O C E S S I N G

Under certain circumstances (in particular, while the VoiceXML interpreter is processing a disconnect event) the interpreter may continue executing in the final processing state after there is no longer a connection to allow the interpreter to interact with the end user. The purpose of this state is to allow the VoiceXML application to perform any necessary final cleanup, such as submitting information to the application server. For example, the following <catch> element will catch the connection.disconnect.hangup event and execute in the final processing state:

<catch event="connection.disconnect.hangup">


<submit namelist="myExit" next="http://mysite/exit.jsp"/>

</catch>

While in the final processing state the application must remain in the transitioning state and may not enter the waiting state. Thus for example the application should not enter <field>, <record>, or <transfer> while in the final processing state. The VoiceXML interpreter must exit if the VoiceXML application attempts to enter the waiting state while in the final processing state.

Aside from this restriction, execution of the VoiceXML application continues normally while in the final processing state. Thus for example the application may transition between documents while in the final processing state, and the interpreter must exit if no form item is eligible to be selected.

Progetto e realizzazione di un framework per applicazioni...

Documents

Transcript of Progetto e realizzazione di un framework per applicazioni...