scieee AI-readable full text Open interactive document viewer

Gestión de cines de España mediante una interfaz vocal : Seventhart

Bekkali, Hassnae

Full text

1 a 2 1 Dedicatoria………………………………………………………………….…...3 Agradecimientos…………………………………………………………….…..4 Introducción……………………………………………………………….….....5 PRIMERA PARTE : PRESENTACIÓN DEL TRABAJO 1. Objetivo del trabajo………………………………………………….……...8 2. Organización de la memoria………………………………………..……...8 SEGUNDA PARTE : FASE CONCEPTUAL 3. F ase conceptual………………………………………………………....….11 3.1. Diagrama de clases…………….……………………………….….....11 3.2. Diagrama de flujo……………………………………………….…....17 3.3. Diseño de la base de datos……………………………………………33 3.3.1. Alojamiento de la base de datos………………………………...33 3.3.2. Estructura de la base de datos………………………………….33 3 2 TERCERA PARTE : FASE DESARROLLO 4. Fase del desarrollo………………………………………………………….41 4.1. Desarrollo de la IVR…………………………………………………..45 4.1.1. Gramáticas………………………………………………....………45 4.1.1.a. Gramáticas estáticas…………………………………………45 4.1.1.b. Gramáticas DTMF…………………………………………...46 4.1.1.c. Gramáticas dinámicas……………………………………….47 4.1.1.d. Gramáticas propias del VXML o gramáticas builtin……..48 4.1.2. Tecnología utilizada…………………………………………….....50 4.1.2.a. Vxml…………………………………………………….……...50 4.1.2.b. Javascript…………………………………………………...…57 4.1.2.c. Java y Jsp……………………………………………………...63 4.1.2.d. Json…………………………………………………………….63 4.2. Desarrollo de la WEB…………………………………………………65 4.2.1. WEB : consultas…………………………………………………...65 4.2.2. WEB : insertar datos……………………………………………...73 CUARTA PARTE : FASE DE PRUEBAS 5. Fase de pruebas…………………………………………………………….75 Test y traza de ejecución………………………………………..….........75 Conclusión………………………………………………………………….…81 Bibliografía……………………………………………………………….…..82 Glosario de términos…………………………………………………………83 4 3 Dedico est Dedico estDedico est Dedico este trabajo a e trabajo ae trabajo a e trabajo a: :: : • Mis padres porque todo lo que soy es gracias a Mis padres porque todo lo que soy es gracias a Mis padres porque todo lo que soy es gracias a Mis padres porque todo lo que soy es gracias a dios y a dios y a dios y a dios y a ellos ellosellos ellos. .. . • Mi profesor David Mi profesor David Mi profesor David Mi profesor David por su por su por su por su apoyo, su apoyo, suapoyo, su apoyo, su ayuda y su ayuda y su ayuda y su ayuda y su amabilidad. amabilidad.amabilidad. amabilidad. • M MM Mis hermanos por ser mis compañero is hermanos por ser mis compañerois hermanos por ser mis compañero is hermanos por ser mis compañeros incondicionales. s incondicionales.s incondicionales. s incondicionales. • M MM Mi futuro marido por su gran ayuda y sus consejos. i futuro marido por su gran ayuda y sus consejos.i futuro marido por su gran ayuda y sus consejos. i futuro marido por su gran ayuda y sus consejos. • Todos mis amigos Todos mis amigosTodos mis amigos Todos mis amigos y aquellos que me quieren. y aquellos que me quieren.y aquellos que me quieren. y aquellos que me quieren. Hassnae HassnaeHassnae Hassnae 5 4 En primer lugar, expreso mi gratitud a la comisión docente de la Facultad de Informática por haber aceptado el tema desarrollado. De igual forma, agradezco a mi supervisor Dr. David Picó Vila por sus valiosas aportaciones y el tiempo dedicado al desarrollo de este trabajo. También hago un agradecimiento especial a Youssef por sus consejos, su gran apoyo y por compartir su conocimiento. A todas las personas que facilitan información por internet, consejos y tutoriales. Finalmente agradezco a todas las demás personas que han compartido de una u otra forma, el proceso de elaboración de este proyecto. 6 5 En los últimos años ha surgido un nuevo tipo de interfaces hombremáquina que combina varias tecnologías de habla, con el fin de permitir a las personas la interacción vocal con los ordenadores. Hoy en día, muchas personas están familiarizadas con las aplicaciones vocales de respuesta automática (IVR), como son por ejemplo las aplicaciones de atención al cliente o banca telefónica. Estas aplicaciones hacen uso de recursos como el reconocimiento de voz y la síntesis de voz para obtener información del usuario y proporcionarle la información requerida, respectivamente. VoiceXML es un lenguaje basado en XML desarrollado por la W3C para la creación de diálogos vocales que hacen uso de recursos de reconocimiento de voz, síntesis de voz, reconocimiento DTMF, audio digital y grabación de audio en el contexto de aplicaciones telefónicas o interacción a través de la voz en general. Otra característica muy interesante del VoiceXML es que proporciona los mecanismos para la creación de diálogos de iniciativa mixta, que hacen posible una forma de interacción con el usuario mucho más rica. La gran ventaja en el uso de VoiceXML es que se ha convertido en el estándar más utilizado para el diseño de aplicaciones vocales, proporcionando una arquitectura abierta para la programación de este tipo de aplicaciones frente a los antiguos sistemas IVR cerrados o propietarios. Los sistemas iniciales estaban muy limitados en cuanto al tipo de frases que los usuarios podían pronunciar y al tipo de tareas a realizar; sin embargo, durante las 7 6 tres últimas décadas su complejidad ha aumentado notablemente, permitiendo una interacción más natural y cercana a la humana. No obstante, y a pesar de los logros alcanzados, su funcionalidad sigue estando limitada a dominios de aplicación claramente restringidos, que permiten incorporar conocimiento y expectativas acerca de las posibles palabras, tipos de frases e intenciones de los usuarios. Una de las causas del éxito de VoiceXML es el hecho de haber llevado las ventajas del desarrollo WEB y el acceso a contenidos WEB al desarrollo de aplicaciones IVR. De esta forma desarrollar una aplicación Vocal con VoiceXML se convierte en algo muy similar y casi análogo a desarrollar un formulario WEB utilizando HTML. En más adelante, veremos con detalle las características de este lenguaje. 8 7 9 8 1. Objetivo del trabajo : Este trabajo tiene como finalidad: Diseñar una interfaz vocal capaz de gestionar los cines de España, que lleva el nombre de “SeventhArt”. Esta interfaz permite a los usuarios hacer reservas en los distintos cines del país mediante llamadas telefónicas y de forma sencilla. Se trata de una interfaz dirigida a personas de todas las generaciones, a diferencia de las aplicaciones clásicas, con interfaces web, que implican tener mucha idea de navegar por internet, y dedicar mucho tiempo para acceder a los distintos servicios de las empresas. 2. Organización de la memoria : La estructura del proyecto presentado en esta memoria es la siguiente: En principio, se hace una introducción sobre las aplicaciones IVR y sobre el lenguaje VXML. También se dan a conocer los objetivos del trabajo desarrollado. En el capítulo 2, se describe con detalle la parte analítica del sistema. Se presenta una descripción detallada del diagrama de clases y del flujo de llamada, donde se reflejan los distintos caminos que sigue el usuario a la hora de comunicarse con la interfaz. Posteriormente, se realiza una descripción de la base de datos con sus distintas tablas y los distintos campos. Al mismo tiempo, se cuenta en qué servidor esta alojada la base de datos para posteriores accesos. En el capítulo 3, se presenta la parte del desarrollo completo del sistema. Se incluyen las gramáticas usadas y sus distintos tipos. También se presenta la tecnología que fue utilizada para llevar a cabo la implementación de la interfaz. 16 15 • Film : Esta clase representa las películas que se emiten en un determinado cine. Sus atributos son: Film_id: la clave primaria de la clase. Title: el título de la película. Recognition: el conjunto de frases, que representan el título, pronunciadas por parte del usuario y reconocidas por el sistema. Description: este campo representa una pequeña descripción de la película y un resumen de la misma. • Category : Esta clase simboliza las distintas categorías que pueden tener las películas. Category_id: funciona como clave primaria. Category_name: expresa el nombre de la categoría. Recognition: indica lo mismo que los campos de Recognition anteriormente mencionados, éste está relacionado con el atributo Category_name. • User : Representa los administradores encargados del mantenimiento de la base de datos y también los empleados de los cines. User_id: actúa como identificador de la clase. User_name: almacena el nombre del administrador. Login: indica el nombre de usuario para acceder a la página web. Password: almacena la contraseña del usuario para acceder a la página web. Type: este campo indica el tipo de privilegio de los diferentes usuarios que acceden a la página web. 17 16 • CreditCard : Esta clase nos permite almacenar los datos bancarios asociados a una tarjeta bancaria determinada. CreditCard_id: el identificador de la clase. Number: representa el número de la tarjeta de crédito. Owner: indica el nombre del titular de la tarjeta bancaria. ExpirationDate : fecha de caducidad. Last3Digits : indica el número de verificación de la tarjeta de crédito. Corresponde a los tres últimos dígitos que se encuentran impresos sobre la banda de firma, situada en el reverso de la tarjeta de crédito. Así para proporcionar más seguridad y proteger al titular contra fraudes. Balance: para almacenar el saldo de la cuenta bancaria. DigitalSignature: corresponde a la firma digital asociada a la tarjeta de crédito en cuestión, también para ofrecer la máxima seguridad contra fraudes. Type: indica el tipo de la tarjeta de crédito. • Reservation: Toda la información relacionada con una determinada reserva, la almacenamos en esta clase. Sus atributos son: Reservation_id: la clave primaria de la clase. Reservation_date: la fecha de la realización de la reserva. Reservation_time: la hora de la realización de la reserva. NumberOfTickets: el número de asientos reservados asociados a una reserva. Las clases User, Category, Film, Show, Cinema y City son los elementos que forman la página web. Así que el administrador puede realizar las siguientes acciones identificandose previamente: 18 17  dar de alta a una nueva película.  dar de alta a un nuevo cine.  dar de alta a un nuevo turno.  modificar una película que ya existe en la base de datos.  modificar un cine que ya está dado de alta en la base de datos.  modificar un turno.  borrar una película.  borrar un cine.  borrar un turno. Por otro lado, la interfaz vocal incluye todas las clases menos la de User. 3.2. Diagrama de flujo : Es una técnica utilizada para representar esquemáticamente bien sea la secuencia de instrucciones de un algoritmo o los pasos de un proceso. En nuestro caso es para representar los distintos pasos de las llamadas al sistema. Estos diagramas facilitan la representación de cantidades considerables de información en un formato gráfico sencillo. Adicionalmente, los diagramas de flujo facilitan a otras personas la comprensión de la secuencia lógica de la solución planteada. 19 18 Fig.2 Diagrama de Flujo: página de inicio 20 19 La [Fig.2] corresponde a la página de inicio del diagrama de flujo. Como podemos observar se trata de un conjunto de estados y transiciones. Cuando un usuario llama al sistema el primer estado que se accede es “Welcome” donde se produce un mensaje de bienvenida y se transita al siguiente estado que corresponde al de “GetCity” donde el usuario debería elegir una ciudad para poder continuar. Una vez seleccionada la ciudad, el sistema le pregunta al usuario por el patrón de búsqueda y como ilustra la figura, hay dos opciones: o bien buscar por nombre de película o bien por nombre de cine. En los estados “FilmLookup” y “CinemaLookup” se accede a la base de datos con el fin de recuperar la lista de películas y de cines respectivamente. Si se ocurre un error, se transita al estado “FailureBehavior”, y en caso contrario se pasa a los estados “GetFilm” y “GetCinema”, respectivamente. En “GetFilm” y “GetCinema” el usuario tiene dos alternativas, si conoce el nombre de la película o el nombre del cine, lo puede facilitar al sistema, si no, tiene la posibilidad de escuchar toda la lista de todas las películas o los cines almacenados en la base de datos. En el caso de que el usuario opte por la opción de escuchar toda la lista de películas, se le pregunta por la categoría de películas que le interesa, para poder hacerle escuchar solamente las de la categoría seleccionada. Esto se hace en el estado “GetFilmForSelectedCategory”. Y cuando ya está escogida la película, se transita al estado “ConfirmFilm” para confirmar el nombre de la película, y así evitar arrastrar cualquier error a los siguientes estados. Lo mismo ocurre con el nombre del cine. Tras haber confirmado el nombre de la película o del cine, se pasa al estado “GetDate” para poder elegir la fecha de la reserva. 21 20 Fig.3 Diagrama de Flujo: Obtener la fecha de reserva Esta parte del diagrama corresponde a la de validar los datos de entrada asociados a la fecha seleccionada por el usuario. Como vemos en la [Fig.3], primero se le pregunta al usuario la fecha, luego se confirma para validarla. Si se trata de una fecha válida, y tras confirmarla, se pasa al estado siguiente “Criteria”, en caso contrario, se vuelve a preguntársela al usuario una vez más. 22 21 Fig.4 Diagrama de Flujo: En caso de error En cuanto a las situaciones de error, se transita al estado “FailureBehavior” en el cual se produce un mensaje avisando al usuario de lo ocurrido, y luego se pasa al estado final correspondiente a “GoodBye”, como está representado en la [Fig.4]. 23 22 Fig.5 Diagrama de Flujo: Obtener la hora de reserva y realizar el pago 24 23 En esta figura [Fig.5] está reflejado el proceso de especificar la hora del turno por parte del usuario y el proceso del pago en el caso de que el usuario esté interesado en hacer la reserva. Debe observarse que existen dos caminos distintos. El primero corresponde a la situación donde exista solamente un turno en la fecha seleccionada. Esto se ve en el estado “OneTime”. En tal caso el usuario puede aceptar o rechazar la hora hallada, si la acepta, y a continuación se va al estado de “AskPayment”, en el cual tiene tres alternativas, volver al menú principal, salir de la aplicación o bien empezar el proceso del pago. En este último caso, se transita al estado “AskNumberOfTickets” para pedirle el número de asientos a reservar. Después de confirmar este número se hace una consulta a la base de datos para averiguar la disponibilidad de asientos en la fecha especificada, lo cual da lugar a dos posibles caminos. Una posibilidad es que el número de asientos a reservar supere lo que queda por reservar, si esto ocurre, el sistema da al usuario la posibilidad de elegir otra fecha. Sin embargo, si el número de asientos a reservar está por debajo del número total de asientos disponibles, se pasa al estado “ConfirmPayment” para comenzar el procedimiento del pago. En el otro caso, de que el usuario rechaza la hora encontrada, el sistema le lleva al estado “ChooseAnotherDate” para poder escoger otra fecha. Por otra parte, en el otro camino que describe la situacion de muchos turnos, sucede lo mismo que en la otra alternativa previamente mencionada, con la diferencia de que el usuario tiene la posibilidad de elegir un turno entre muchos, y se transita al estado “ChooseAnotherDate” solamente si ninguno de los turnos hallados conviene al usuario. 25 24 Fig.6 Diagrama de Flujo: Introducir los datos de la tarje ta bancaria 32 31 Fig.11 Diagrama de Flujo: Confirmación del pago 33 32 Por último, presentamos los estados correspondientes a la confirmación del pago. Como observamos, en el estado “ConfirmPayment”, el usuario puede continuar para efectuar la reserva, volver al menú principal para realizar otra búsqueda o bien salir de la aplicación. Confirmar el pago lleva al usuario al estado “CreditCardModule” que incluye todos los estados que hemos visto antes, asociados con la introducción de los datos bancarios. Si fijamos en la figura [Fig.11], hay un estado llamado “PlayPrompt” que es accesible desde el último estado del “CreditCardModule” en el cual, se reproduce un mensaje para recordar el usuario la información de la reserva, como por ejemplo el nombre de la película seleccionada, el número de asientos reservados, el total recaudado de la cuenta bancaria,etc,... Desde este estado “PlayPrompt”, tenemos tres caminos diferentes, uno correspondiente al caso de éxito cuando se hace la reserva correctamente (lleva la etiqueta “result=succes”) y luego se transita al menú principal para realizar otra acción, el segundo con la etiqueta “result=failure”, éste ocurre cuando ha habido un error a la hora de realizar la reserva y se ha intentado las veces suficientes permitidas por el sistema, de este estado con estas condiciones se pasa al estado “FailureBehavior”. Y el último, corresponde al camino etiquetado como “result=GoodBye” en el cual el usuario no ha superado el número de intentos permitidos, y se transita al estado “GoodBye”. 34 33 3.3. Diseño de la base de datos : 3.3.1. Alojamiento de la base de datos : Para que mi aplicación pueda funcionar debería alojarla en un servidor que soporte: java y mysql. Después de haber buscado por internet encontré uno de alojamiento gratis que cumple los requisitos, que permite crear cuentas, de forma totalmente gratuita, para disfrutar de los servicios que ofrece. El servidor era : http://www.eatj.com/ que tiene muchas ventajas. Creando una cuenta, se puede tener 50 MB de espacio. También, después de crear la base de datos se puede guardar como fichero extensión “sql” para, en el caso de pérdida de datos, solo con la opción de importar, poder crearla nuevamente, en pocos segundos, a partir del fichero previamente mencionado. 3.3.2. Estructura de la base de datos : Ahora veamos cómo está organizada nuestra base de datos con sus tablas y sus atributos. La [Fig.12] representa la página principal de nuestro servidor correspondiente a la sección de administrar la base de datos. La base de datos lleva el nombre “seventhart” y tiene asociadas ocho tablas, como se indica en la figura [Fig.13]. A continuación, representamos figuras que muestran todas las tablas reflejando tanto los atributos como los datos. 35 34 Fig.12 Servidor de alojamiento de la base de datos: página principal Fig.13 Las tablas de la base de datos. 36 35 Fig.14 Tabla “Category”: atributos. Fig.15 Tabla “Category”: datos. Fig.16 Tabla “Cinema”: atributos. 37 36 Fig.17 Tabla “Cinema”: algunos datos. Fig.18 Tabla “City”: atributos. Fig.19 Tabla “City”: datos. Fig.20 Tabla “CreditCard”: atributos. 38 37 Fig.21 Tabla “CreditCard”: datos. Fig.22 Tabla “Film”: atributos Fig.23 Tabla “Film”: parte de los datos. 39 38 Fig.24 Tabla “Reservation”: atributos. Es importante indicar que en un principio, la tabla “Reservation” se encuentra vacía. Se rellena a medida que se va llamando a la aplicación. Fig.25 Tabla “Show”: atributos. Fig.26 Tabla “Show”: algunos datos. 40 39 Fig.27 Tabla “User”: atributos. . Fig.28 Tabla “User”: datos. 41 40 48 47 Según el ejemplo, da igual que el usuario diga “start over”, “main menu” o pulsar la tecla asterisco del teclado telefónico (ésta última está representada mediante la gramática DTMF) para expresar la acción de volver al menú principal, ya que todas son equivalentes. La gramática DTMF, se indica mediante la palabra reservada “dtmf” delante del número o símbolo de la tecla en cuestión. 4.1.1.c. Gramáticas dinámicas : Ahora, explicamos otro tipo de gramáticas que hemos usado para la implementación de nuestra aplicación: el tipo dinámico . Las gramáticas dinámicas son parecidas a las estáticas, salvo que contienen una parte que está implementada en java (jsp + servlets), cuyo contenido se genera a partir de datos existentes en la base de datos. Con el uso de esta técnica, la interacción entre la aplicación y el usuario no se ve limitada en un conjunto de frases incambiable, sino, da la posiblidad a la gramática de depender radicalmente de la base de dato, no cabe ninguna duda de que cualquier cambio que afecta a los datos almacenados en la base de datos se verá en la gramática. Veamos un ejemplo para tener una idea de lo que acabamos de mencionar. La gramática dinámica “GetFilm.jsp” retornará la lista de todas las películas almacenadas en nuestra base de datos. Una actualización de la base de datos es más que suficiente para que esta gramática devuelva otra lista de películas. El contenido de la gramática “GetFilm.jsp” es: MAINMENU [ (start over) (main menu) (dtmf-star) ] 49 48 El resultado de “GetFilm.jsp” después de la ejecución es el siguiente: En el ejemplo, podemos observar que la parte escrita en color morado es la correspondiente a la dinámica, como vemos se trata de código java.. 4.1.1.d. Gramáticas propias del VXML o gramáticas builtin : Son gramáticas especialmente diseñadas para las tareas más comunes, y a menudo difíciles, que han sido integradas en el reconocedor como un recurso incorporado.Las gramáticas básicas incorporadas no son solamente la definición de las reglas sino el procesado interno de los resultados. Los tipos integrados, a veces, proporcionan la entrada tanto en forma de voz como DTMF. Las builtin especificadas por el estándar de VoiceXML son las siguientes:  Boolean: para reconocer respuestas positivas o negativas. FILMS [ (?I_WANT [ ((?(lara croft) tomb raide)) {<choice "Tomb Raider">} ((treas of ?the sun)) {<choice "Tears of the Sun">} ((point break)) {<choice "Point Break">} ((?a walk ?to remember)) {<choice "A Walk to Remember">} ((addams family ?values)) {<choice "Addams Family Values">} ((domestic disturbance)) {<choice "Domestic Disturbance">} ((scary movie two)) {<choice "Scary Movie 2">} ] ?please) ] FILMS [ (?I_WANT [ <% String jsonFilms = GrammarUtil.addQuestionMarks(request.getParameter("films")); out.println(GetFilm.slots(jsonFilms)); %> ] ?please) ] 50 49  Currency: para reconocer cantidades monetarias.Para la entrada de DTMF, la tecla “*” actuará como el punto decimal.  Date: se usa este tipo para el reconocimiento de fechas.  Digits: permite el reconocimiento de secuencias de dígitos, de longitud limtada o no.  Number: para reconocer números.  Phone: este tipo integrado permite el reconocimiento de números de teléfono.  Time: en esta builtin, se incorporan expresiones de tiempo que especifican horas y minutos. A continuación, mostramos ejemplos que ilustran la sintaxis y como se incluyen estas builtin en el código. Ésta, como vemos, corresponde a la builtin booleana, si fijamos bien, observamos que la gramática está parametrizada, se indica la forma de introducir los datos, entonces se asocia la tecla 1 con respuestas afirmativas mientras que la tecla 2 para proporcionar las negativas. Es importante destacar, que la forma de incluir estas builtin es siempre la misma, es necesario añadir la palabra que indica el tipo para especificar de qué clase se trata. A veces, es necesario definir parámetros para que la gramática se comporte de la manera requerida.En este ejemplo de la builtin “digits”, está indicado que la secuencia debe de ser exactamente de dieciséis dígitos. <grammar src="builtin:grammar/digits?length=16"/> <grammar src="builtin:grammar/time"/> <grammar src="builtin:grammar/number"/> <grammar src="builtin:grammar/date"/> < grammar src="builtin:grammar/boolean?y=1;n=2"/> 51 50 4.1.2. Tecnología utilizada: En este apartado, describiremos los lenguajes que hemos empleado en el desarrollo de nuestra aplicación. También, hablaremos de las herramientas usadas para esta finalidad. 4.1.2.a. Vxml: Definición del VXML : VoiceXML (Voice eXtensible Markup Language) es un lenguaje de programación estándar abierto para el desarrollo de aplicaciones de voz, y no propietario de la familia XML. A principios de 2001, fue considerado, por el W3C, el lenguaje estándar basado en etiquetas para crear este tipo de sistemas.Poco después, el VBWG (Voice Browser Working Group), un subgrupo de trabajo del W3C dedicado a la evolución del estándar, comenzó a trabajar en la versión 2.0, cuya versión inicial apareció en octubre de 2004. VoiceXML funciona mediante un navegador de voz cuya salida es audio, y cuya entrada es audio y teclado.La entrada de audio está controlada por un reconocedor de voz integrado con el navegador de VoiceXML.La salida de audio consiste en audio pre-grabado y/o en voz sintetizada por un sistema de Text-To-Speech. Un sistema VoiceXML para una aplicación concreta consiste en un sistema de documentos, en los que se describen las interacciones con el usuario.El resulatdo de una interacción lleva a la siguiente, por lo que un sistema VoiceXML puede definirse como una máquina de estados finitos.Los documentos VoiceXML incorporan, por cada interacción, los mensajes del sistema, la gramática que 52 51 debe utilizarse para reconocer la respuesta del usuario y la siguiente acción a realizar por cada posible respuesta del usuario. El VoiceXML (o VXML) tiene por objetivo simplificar la creación y el despliegue de servicios vocales por telefonía. Ventajas del VXML: Los motivos por los cuales es tan importante la penetración y el enfoque de la tecnología VoiceXML: En primer lugar, porque el teléfono es una herramienta con mucho poder. Actualmente hay más de 2.2 billones de teléfonos en uso.Una cifra muy superior a la de usuarios que disponen de ordenador con conexión a Internet. Además los teléfonos son fáciles de usar y no necesitan ni tiempo de arranque ni sistemas operativos. En segundo lugar, porque la voz es importante en el teléfono.La voz siempre ha sido la forma natural de comunicarse a través del teléfono.Aunque algunos móviles disponen de navegadores WAP o XHTML, sus pequeñas pantallas y teclados, hacen complicada la navegación, especialmente en algunas circunstancias como por ejemplo durante la conducción. Finalmente, VoiceXML es una tecnología independiente de la plataforma, que permite la portabilidad y transferencia de datos entre aplicaciones heterogéneas. Etiquetas del VoiceXML: Como ya hemos mencionado antes, el VXML es un lenguaje basado en etiquetas.Una etiqueta es una palabra clave encerrada entre dos corchetes ( <y >), que puede tener atributos que van dentro de los corchetes, estos atributos 53 52 consisten en nombre y valor, separados por un signo igual ( =) y el valor debe escribirse entre comillas. Cada etiqueta de apertura “<palabra clave>” debe de tener su etiqueta de cierre correspondiente “</palabra clave>”. Debido a que el VXML incluye varias etiquetas, a continuación, describeremos solamente algunas de ellas, entre otras que hemos usado en nuestra implementación.  <vxml> : Todo el contenido de un documento VoiceXML está comprendido entre la <vxml> etiqueta de inicio y la </vxml>etiqueta final. La etiqueta <vxml> incluye varios atributos, pero los más importantes son : Versión: indica la versión VXML que ha sido utilizada en este documento. Xmlns: para especificar el espacio de nombres designado para VXML.Este espacio de nombres se define como http://www.w3.org/2001/vxml. En el ejemplo ilustrativo, observamos que la versión utilizada es la 2.0.  <form>: Como ya hemos explicado antes, un sistema VXML consiste en un conjunto de interacciones con el usuario, o mejor dicho, un conjunto finito de estados. Cada interacción está contenida entre la etiqueta inicio <form> y la etiqueta final </form>.Hay que tener en cuenta, que cuando se llega al final de un cuadro de dialogo (o form), la ejecución no se pasa al siguiente cuadro de dialogo en el documento, sino, que se indica explícitamente la transición dentro de la interacción actual. <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"> . . . </vxml> 54 53 Igual que en el caso anterior, la etiqueta <form> tiene asociada atributos, pero el que hay que indicarlo obligatoriamente es: Id: especifica el nombre de la interacción. Este ejemplo, corresponde a la primera interacción que se ejecuta cuando se interactúa con nuestro sistema.La interacción lleva el nombre de “Welcome”.  <audio>: Sirve para reproducir un fichero de audio dentro de un sistema. Como puede verse en el ejemplo adjunto, la etiqueta <audio> consta de un atributo llamado “expr”, el cual indica la ruta donde está almacenado el fichero de audio especificado. En nuestro ejemplo, el valor de este atributo consiste en una función javascript, “promptPath()”, que devuleve la ruta del archivo de audio llamado “welcome” que le pasamos como parámetro. Este atributo es solo uno de los varios que incluye esta etiqueta.  <property>: <audio expr="promptPath('welcome')"> <value expr="promptValue('welcome')"/> </audio> <form id="Welcome"> <block> <audio expr="promptPath('welcome')"> <value expr="promptValue('welcome')"/> </audio> <prompt> <break time="1s"/> </prompt> <assign name="context.vars.comingFrom" expr="'Welcome'"/> <goto next="#GetCity"/> </block> </form> 55 54 Establece los valores que afectan el comportamiento de la plataforma y contola los ajustes de la misma. Tiene tres atributos en total, sin embargo, solo es imprescindible indicar los dos siguientes: Name: para especificar el nomre de la propiedad.El nombre puede ser cualquiera de las propiedades admitidas para el VXML. Valor: Valor de la propiedad.Los valores permitidos dependen de la propiedad especificada. Veamos ahora nuestro ejemplo, observamos que se ha especificado la propiedad “bevocal.maxdialogerrors” y se ha establecido el valor 5, esto significa que el número máximo de errores del habla que puede ocurrir dentro de cada interacción no puede superar el valor establecido, en este caso 5. Se refiere a error del habla, a errores de reconocimiento (que el usuario no ha pronunciado algo bien o lo que ha proporcionado no se ve reflejado en la gramática) y también expiración del tiempo de espera a la hora de esperar una entrada de datos del usuario.  <script>: Permite ejecutar un script en código javascript, o definir funciones en javascript que serán llamadas por expresiones en el mismo ámbito que el elemento que contiene la etiqueta <script>. Todos los atributos de esta etiqueta son opcionales.En el siguiente ejemplo, no hemos incluido ningún atributo, se ve claramente que se realiza una llamada a una función JavaScript “resetVariables()”. <script> resetVariables(); </script> <property name="bevocal.maxdialogerrors" value="5" /> 56 55  <grammar>: Esta etiqueta tiene como propósito especificar una gramática que se utiliza en la interacción que la incluye. La etiqueta <grammar> admite un conjunto de atributos, sin embargo, no vamos a explicar todos de ellos, pero solamente el que aparece en nuestro ejemplo. Srcexpr: contiene expresión javascript que indica la ruta de la gramática que va a ser utilizada. En el ejemplo, nuestra expresión javascript, indica la ruta de ubicación de la gramática, “context.path.grammar”, concatenada con el nombre del fichero que contiene la gramática “Global.gsl” y indicando el nombre de la gramática en cuestión “#REPEAT”.  <foreach>: Itera sobre los elementos de un vector.Tiene asociados dos atributos: Item: suele indicar la variable de iteración, que no puede ser una palabra clave reservada de javascript. Array: representa el vector sobre el cual iteramos. El ejemplo muestra una iteración sobre el vector “filmForSelectedCategoryArray”, en tal caso la variable de iteración corresponde a “film”. <foreach item="film" array="filmsForSelectedCategoryArray"> ….. </foreach> <grammar srcexpr="context.paths.grammar + 'Global.gsl#REPEAT'"/> 57 56  <subdialog>: Invoca a otro diálogo como subdiálogo del actual. <subdialog> se considera como un mecanismo para la reutilización de los cuadros de diálogo comunes. El contexto del subdiálogo y del diálogo invocante son independientes, aunque estén en el mismo documento. El subdiálogo se especifica mediante la referencia indicada en el atributo src.Se pasan parámetros al subdiálogo mediante la inclusión de la etiqueta <param>. Tiene varios atributos, pero solo comentaremos los siguientes: Src: especifica la ruta del subdiálogo. Name: el nombre de la variable en la cual el resultado devuelto por el subdiálogo estará almacenado.Para acceder a los valores de retorno del subdiálogo se utiliza la sintaxis: “Name.returnVariableName”. En nuestra aplicación “Seventhart”, hemos invocado a un solo subdiálogo que se encarga de realizar el proceso del pago (recogida de los datos bancarios del usuario, realizar el pago y efectuar su reserva). Este subdiálogo tiene como ruta “CCM.vxml.jsp” y está ubicado en la misma carpeta que el documento principal o invocante, mientras que “CCModule” es el nombre del subdiálogo y de la variable que nos permite acceder a los valores devueltos por éste, efectivamente, “CCModule.result” es el valor devuleto por este subdiálogo. <subdialog name="CCModule" src="CCM.vxml.jsp"> <param name="subcontext" expr="context"/> <filled> <log>CreditCardModule subdialog end</log> <assign name="context.vars.result" expr="CCModule.result"/> <goto next="#PlayPrompt" /> </filled> </subdialog> 64 63 4.1.2.c. Java y Jsp: JSP (JavaServer Pages ) es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. Las JSP's permiten la utilización de código Java mediante scripts. Hemos contado con esta tecnología para implementar Servlets permitiendo el acceso a la base de datos y la realización de consultas SQL. Además, la utilización de JSP ha sido en las gramáticas dinámicas que su contenido depende de la base de datos. 4.1.2.d. Json: JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. Es un subconjunto del lenguaje JavaScript que se basa en la construcción de una lista ordenada de valores, listas de objetos, que pueden incluir a su vez tablas hash, objetos con una colección de pares nombre/valor. La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML. En nuestra aplicación, los datos que nos devuelven los Servlets/Jsp, vienen en forma de objetos JSON. Para entender bien lo que proporciona esta tecnología, observemos este ejemplo que corresponde a un objeto JSON cuyo contenido es una lista de cines: { "status" : "success", "cinemas" : [ {"name" : "Cinesa Bonaire", "recognition" : "(?cinesa bonaire)"}, {"name" : "El punt de la Ribera", "recognition" : "[(el punt ?de ?la ribera) ribera]"}, {"name" : "ABC Gran Turia Multicines", "recognition" : "(?(a b c) ?gran turia ?multicines)"} ] } 65 64 Este objeto JSON está formado por dos elementos principales: • El atributo “status”: es una cadena de caracteres cuyo valor nos indica si el acceso a la base de datos ha tenido éxito o fallo. • El atributo “cinemas”: se trata de un vector que contiene tres elementos (cada elemento está contenido entre dos llaves: {}), cada uno es a su vez un objeto de dos atributos simples que representan: el nombre del cine, recognition respectivamente. 66 65 4.2. Desarrollo de la WEB: 4.2.1. WEB : consultas: En capítulos anteriores hemos mencionado que en nuestra base de datos disponemos de tres tipos de usuarios: • Tipo C: representa los empleados de las taquillas de los cines. Acceden a la página web para poder mostrar las distintas reservas realizadas para una película en concreto en una fecha dada. • Tipo B: es el encargado de mantener la base de datos (insertar una nueva película, borrar una película, modificar un turno de emisión, etc.). • Tipo A: este tipo hace referencia a los administradores de la base de datos. Más adelante veremos las tareas de cada tipo de usuarios. En este apartado describiremos la página web desarrollada para el tipo C. Los tres tipos citados anteriormente tienen una página en común donde introducen el nombre de usuario y la contraseña. Fig.31 Página de identificación. 67 66 Dependiendo del tipo se accede a una página o a otra ya que cada usuario tiene una página distinta del resto de los usuarios. Después de haber introducido los datos de identificación, se validan éstos mediante un servlet java y se accede a la página de menú asociada al usuario C. Se trata de una página muy sencilla. Primero, se introduce una fecha, de la que queremos mostrar sus reservas asociadas. Fig.32 Campo para seleccionar la fecha. Se da al botón enviar y se muestra una lista de películas emitidas en dicha fecha. En el caso de que no haya ninguna película emitida en esta fecha se muestra un mensaje de aviso. 68 67 Fig.33 Lista de las películas emitidas en la fecha introducida. Fig.34 Caso de no existir ninguna película emitida en la fecha seleccionada. 69 68 Luego se selecciona la película y se da al botón de aceptar, y se muestra a continuación otra lista que representa los distintos turnos de emisión de la película elegida previamente. Fig.35 Lista de los turnos de emisión de la película elegida. Al seleccionar un turno se muestra una tabla con todas las reservas efectuadas para este turno. Los datos mostrados en esta tabla son: el nombre de la persona que realizó la reserva, el número de asientos reservados, etc. 70 69 Fig.36 Tabla con todas las reservas efectuadas para la película, el turno y la fecha seleccionados. En el caso de que no se ha realizado ninguna reserva se muestra un mensaje de error. Ver [Fig.37]. 71 70 Fig.37 El caso de no existir reservas realizadas. Solo para recordar, las reservas se hacen normalmente mediante la aplicación vocal y la recogida de los tickets se realiza en la taquilla. Para facilitar la operación de recogida y evitar cualquier situación de error, hemos añadido un nuevo campo en la tabla de reservation llamado “TicketsDelivery_datetime” que en principio es una cadena vacía, lo cual significa que no se han recogido aún los tickets. En otro caso, cuando se han recogido los tickets, se almacena en este campo la fecha de recogida. Teniendo en cuenta estos dos casos, el aspecto de la tabla que muestra las reservas efectuadas varía según el caso. 72 71 • Aparece una casilla cuyo contenido representa la fecha de recogida [Fig.38]. • Cuando no se han recogido aún, esta casilla aparece como un botón, el cual si se pulsa se ejecuta un servlet java cuya función es actualizar la base de datos insertando la fecha de recogida. Fig.38 Reservas con tickets recogidos. Fig.39 Reservas con tickets pendientes de recoger. 73 72 La página incorpora un enlace para permitir al usuario desconectarse en cualquier momento. El desarrollo de estas páginas se ha hecho mediante: servlets java, html y jquey. En nuestra web se controla la entrada de datos antes de validarlos. Dicho de otra forma, se muestra un mensaje cuando no se introduce el nombre de usuario, la contraseña o ambos en el proceso de identificación. Fig.40 Mensaje de error cuando no se ha introducido algún campo de identificación. 80 79 Como podemos observar, hay varios colores, sin embargo comentaremos solamente los más importantes que hemos utilizado en nuestras trazas de ejecución. • Error Message : Indica los errores de implementación mostrando el número de línea donde se encuentra éste. Esta línea indica que hay un error de implementación de sintaxis JavaScript en la línea 393 del código. • Recognition Info : Representa las frases o palabras pronunciadas por parte del usuario. En este ejemplo, se observa claramente que el usuario ha pronunciado la palabra Valencia a la hora de seleccionar la ciudad. • HTTP Header Info: Señala los detalles de cada petición-respuesta del servidor HTTP asociadas a cada fichero utilizado por parte de la aplicación. 81 80 • Warning Message: Como su nombre indica, representan les warnings de implementación. Se trata de un ejemplo de un warning que se ha dado en nuestra aplicación. • Variables Trace: Indica las distintas declaraciones y asignaciones de variables que se han efectuado en el código. Según el fragmento mostrado, se puede observar que se ha asignado el valor “FilmLookup” a la variable “context.vars.coming”. Del mismo modo, se ha inicializado la variable “city” con el valor almacenado en la variable “context.vars.city”. 82 81 En este trabajo hemos presentado un sistema que gestiona todos los cines del país mediante una interfaz vocal. Este sistema ha sido diseñado para facilitar la reserva y la compra de tickets en los distintos cines del país mediante llamadas telefónicas y está dirigido a personas de todas las edades, sin necesidad de tener mucho conocimiento de informática para poder utilizarlo. Esta aplicación ha sido desarrollada en inglés (los prompts, las gramáticas, etc.). Por lo cual, podemos definir nuestro trabajo futuro que podemos resumir en: desarrollar la versión en español (u otro idioma). Esta mejora necesita: definir las gramáticas en español, grabar los mensajes de audio o prompts en español y definir una interacción (o estado) al principio en la cual el usuario debería elegir un idioma para poder continuar la interacción con el sistema. 83 82 • The Eduteka : http://www.eduteka.org/modulos.php?catx=4&idSubX=116 • Crossroads The ACM Student Magazine : http://www.acm.org/crossroads/ • Sonify : Interactice Sound For The Web & Wireless: http://www.sonify.org • Página oficial de W3C: http://www.w3.org/TR/voicexml20/#dmlABuiltins • http://www.webestilo.com/javascript/ • La Wikipedia : http://es.wikipedia.org/wiki/JSON http://es.wikipedia.org/wiki/Voz_sobre_IP • Página oficial de Bevocal o Nuance : http://cafe.bevocal.com/ 84 83 • ASP: Active Server Pages, es una tecnología de Microsoft para páginas web generadas dinámicamente. • TTS : Text to Speech, es una técnica que permite generar oralmente cualquier mensaje en forma de texto mediante un sintetizador de voz. • ASR: Speech Recognition. Componente de reconocimiento de voz VXML. • DTMF: Dual Tone Multifrecuency. Tonos en diferentes hertz que utiliza una telefonía para marcar números. Cada número u opción del teléfono tiene su tono que le identificado en la telefonía. • IVR: Interactive Voice Response , sistema de navegación telefónica interactiva. • VoIP: voice over IP. Es un grupo de recursos que hacen posible que la señal de voz viaje a través de Internet empleando un protocolo IP (Protocolo de Internet). Esto significa que se envía la señal de voz en forma digital, en paquetes, en lugar de enviarla en forma digital o analógica, a través de circuitos utilizables sólo para telefonía. 85 UPV Camino de Vera, s/n 46022 – Valencia ESPA Ñ A