Repositorio Institucional de Documentos

A mis padres y a mi hermana. A mi abuelo, por los buenos consejos que me has hecho llegar. Ficha Técnica Proyecto Fin de Carrera Título: Interface de usuario multimodal asistido con agente virtual Autor: D. Daniel Martínez Millán DNI: 17762237-G Titulación: Ingeniería Informática Directores: Dr. Javier Marco Rubio Dr. Francisco J. Serón Arbeloa Departamento: Informática e Ingeniería de Sistemas Centro: Escuela de Ingeniería y Arquitectura Universidad: Universidad de Zaragoza Fecha: 20 de junio Agradecimientos A Javier y Paco, mis directores, por haberme ofrecido la posibilidad de realizar este proyecto, por su ayuda incondicional, por las horas dedicadas a apoyarme cuando no encontraba la solución a los problemas que me iban surgiendo, y por los buenos momentos que hemos pasado. A Marta y Antonio, mis compañeros de laboratorio que me han acompañado a lo largo de prácticamente todo mi proyecto, por la paciencia tan grande que han tenido cuando estaba probando la aplicación y me tenían que escuchar hablar con ella, sé que se saben qué es lo que responde a cada pregunta que se le hace. Vosotros me habéis hecho pasar muy buenos momentos en el laboratorio, me habéis ayudado cuando lo necesitaba, y siempre podía contar con vosotros cuando necesitaba hablar y expansionarme. Nunca lo olvidaré. A la gente que he conocido todos estos años de carrera, porque me habéis ayudado a llevarla mucho más tranquila. A mi familia, porque aunque seguramente no entendían lo que les contaba, siempre prestaban atención. En especial a mis padres y mi hermana, porque me habéis enseñado todo lo que sabíais, me habéis apoyado cuando más lo necesitaba y os habéis sacrificado en muchas cosas, demasiadas, para darme lo mejor. Me habéis enseñado que sin esfuerzo no se consigue nada, que las cosas no vienen solas, y que la vida te puede dar muchos golpes, algunos muy duros, pero hay que levantarse para seguir adelante. Y ya por terminar, quiero dar las gracias a mi abuelo Victorino. Te fuiste demasiado pronto, pero sé que sigues a mi lado todos los días. Quiero que sepas que, allá donde estés, siempre te llevaré conmigo. Derechos de autor Los derechos de la presente obra pertenecen a D. Daniel Martínez Millán y al Dr. D. Francisco José Serón Arbeloa, del Departamento de Informática e Ingeniería de Sistemas de la Escuela de Ingeniería y Arquitectura de la Universidad de Zaragoza. Queda prohibida la reproducción total o parcial de esta obra, por cualquier medio, sin el permiso escrito de los autores. Contexto del proyecto 2 1.1.1. Proyecto Alfa III GAVIOTA El proyecto Alfa III GAVIOTA (Grupos Académicos para la VIsualización Orientada por Tecnologías Apropiadas) [GAVIWEB] comenzó en Enero de 2011 como un proyecto de colaboración entre universidades, entre las que se encuentran la Universidad Pública de Navarra como coordinadora, la Universidad de Zaragoza, la Universidad de Ciencias Aplicadas Wuerzburg de Alemania y el Instituto Politécnico do Porto, sito en Portugal; junto con varias universidades de América Latina como la Universidad de Belgrano y la Universidad Nacional de San Luis, Argentina, la Universidad Privada de Sta. Cruz de la Sierra, Bolivia, la Universidad Federal de Pelotas, Brasil, la Universidade do Vale do Rio dos Sinos, sita en Sao Leopoldo, Brasil, la Universidad del Bío Bío, Concepción, Chile, la Universidad Tecnológica de Honduras, sita en San Pedro Sula, Honduras, y la Universidad de la República, sita en Montevideo, Uruguay. La finalidad de este proyecto Alfa es abordar tres problemas concretos. El primero viene dado por la inexperiencia de algunos miembros de América Latina en el campo de la Realidad Virtual, la Realidad Aumentada y la Interacción Avanzada, en adelante Realidad Digital Avanzada (RDA). El segundo problema que se pretende abordar es el déficit de recursos humanos cualificados en la región latinoamericana en el campo de la RDA. Este déficit se constata tanto dentro del nivel académico como fuera del mismo, a nivel profesional en la sociedad. Por último, como tercer problema se ha observado una desvinculación entre el trabajo de investigación aplicada y formación académica y el resto de la sociedad. Por estas razones, se ha marcado como objetivo del proyecto Alfa el desarrollo de un conjunto de herramientas industriales, educativas y de formación con el objetivo de introducir las técnicas de RDA en diferentes países latinoamericanos, tanto en Instituciones como las Universidades, como diferentes departamentos ministeriales e Industria importantes. Debido a su experiencia en el campo de la RDA, el grupo GIGA está comprometido en el desarrollo de varias aplicaciones prácticas de este tipo de tecnologías, en el contexto de la aplicación de nuevos recursos tecnológicos y web en entornos educativos [GIGAEDUC]. En concreto, el propósito final del trabajo asignado al grupo GIGA es, desde el punto de vista de la formación ofrecer a estudiantes una herramienta web que les permita obtener información relacionada con diversos temas científico-mecánicos, y desde el punto de vista industrial, introducir el uso de agentes virtuales en entornos de Web 3.0 [W3CWEB3]. El desarrollo de esta herramienta se ha dividido en dos proyectos, el primero es la implementación de la interfaz con el usuario, y el segundo es la gestión del conocimiento obteniendo información de la DBpedia [DBPWEB] mediante ontologías, siendo la parte relacionada con el interfaz la que se ha desarrollado en este PFC. Introducción 3 1.2. Objetivos del proyecto El objetivo principal de este PFC es la creación de un interface multimodal asistido por un agente autónomo e inteligente orientado a consultas a través de la Wikipedia sobre temas científico-mecánicos, y que además permita la integración de nuevas funcionalidades como consultas a distintas Web APIs (Application Programming Interface) disponibles en la red. El conjunto de requisitos que debe de cumplir este interfaz son los siguientes: - El usuario podrá solicitar la información que desee a través del habla o interaccionando directamente sobre la interfaz a través de ratón. - En el caso de interaccionar mediante voz, el usuario podrá formular las consultas de forma natural. - Se deberá utilizar Loquendo ASR como reconocedor de voz, al igual que Loquendo TTS para la síntesis de voz. - La información dirigida al usuario será entregada de forma visual y/o auditiva, es decir, se le mostrará por pantalla y/o mediante síntesis de voz. - La información que obtenga la aplicación y que se muestre al usuario deberá recibirse a través de Internet. - En caso de que no se pueda obtener alguna información, sólo se permitirá recogerla de forma local si esa información procede del Sistema Operativo donde se está ejecutando la aplicación. - Se permitirá la integración de nuevas funcionalidades de forma fácil y rápida. - La aplicación deberá ser multiplataforma. - El contenido de los artículos de los temas científico-mecánicos predefinidos disponibles podrá ser leído, y será de fácil acceso al usuario. - La aplicación podrá guardar información sobre las consultas realizadas, con el fin de mejorar la interacción natural del usuario. - Se integrará un módulo de visualización 3D para agentes realistas. Cabe destacar que para conseguir que la aplicación fuese multiplataforma, el lenguaje de programación utilizado ha sido JAVA [JAVAWEB], un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems que se encuentra liberado casi en su totalidad bajo licencia GNU GPL. Estado del arte 4 1.3. Estado del arte Hoy día son muchos y de muy distintos tipos los dispositivos digitales con los que la gente interacciona a diario. Recientemente están apareciendo nuevas herramientas que permiten la interacción multimodal con dichos dispositivos, buscando que sea de una forma más natural. Algunos ejemplos de herramientas multimodales recientes son SIRI para iPhone, Kinect de XBOX360, o la herramienta Maxine desarrollada por el GIGA. SIRI SIRI [SIRIWEB] es una aplicación asistente personal que ofrece una interacción alternativa a la tradicional en el manejo de los dispositivos móviles. SIRI permite al usuario realizar multitud de solicitudes mediante lenguaje natural, ya sea para responder preguntas, hacer recomendaciones o realizar cualquier acción que el usuario podría realizar mediante la interacción convencional con el dispositivo, como agregar notas en el calendario, responder a mensajes o controlar la reproducción de canciones. La metodología de funcionamiento de SIRI es similar a la utilizada en este PFC, ya que realiza consultas a través de un conjunto de servicios web que va en aumento, aunque no dispone actualmente de reconocimiento de voz en español ni permite su utilización en otros dispositivos móviles que no pertenezcan a Apple Inc. Kinect Kinect para Xbox 360 [KINECTWEB] fue y sigue siendo a día de hoy una revolución en el mundo de los videojuegos. Supuso un cambio absoluto en la forma de jugar con una videoconsola, ya que permite a los usuarios controlar e interactuar con la consola sin necesidad de tener contacto físico con un controlador de videojuegos tradicional. Esto se consigue mediante una interfaz natural de usuario que reconoce gestos, comandos de voz [KINVOZWEB], y objetos e imágenes, lo que otorga al usuario poder controlar y acceder a infinidad de contenidos multimedia sin la necesidad de manejar ningún mando, sólo utilizando la voz o mediante gestos. Introducción 5 Aplicaciones comerciales También existen otras aplicaciones además de SIRI que reconocen lenguaje natural aunque no sean interfaces multimodales, es decir, reconocen cualquier consulta escrita de forma natural. Un ejemplo de ello es la asistente interactiva Anna de IKEA® [IKEAWEB], un agente inteligente al que se le pueden formular consultas escritas de en lenguaje natural, entiende el significado de esas preguntas y responde consecuentemente simulando a un humano, pero siempre reorientando la respuesta hacia su cometido, informar sobre IKEA y sus productos. Maxine Maxine es una herramienta desarrollada por el GIGA que permite crear nuevas aplicaciones multimodales a través de scripts LUA. Ofrece un conjunto de herramientas de reconocimiento y síntesis de voz, reconocimiento de puntos faciales, comunicación vía socket y manejo de gráficos entre otras, que permiten a través de scripts poder realizar multitud de programas, ya sean educativos o de otra índole, como el PFC “E- Museum” [EMUSPFC], realizado en el año 2010. En este proyecto se creó un agente virtual inteligente que actúa como guía de museo y comenta detalles sobre cada uno de los cuadros presentes. Esta herramienta se lleva utilizando desde el año 2006 y sus funcionalidades se han visto incrementadas con otros proyectos y PFCs hasta convertirla en una herramienta de referencia. Actualmente sigue siendo operativa para distintos proyectos. Estructura de la memoria 6 1.4. Estructura de la memoria La memoria se encuentra dividida en 5 capítulos: - Capítulo 1 – Introducción: Breve introducción del proyecto Alfa III GAVIOTA en el que se engloba este PFC, los objetivos que se esperaban conseguir, y un breve estudio del arte referente a interfaces multimodales existentes. - Capítulo 2 – Proceso de Comunicación: Explicación del funcionamiento de la aplicación, fases por las que una consulta del usuario es procesada, desde su reconocimiento hasta la obtención de la respuesta a esa consulta, pasando por la obtención de los datos a través de la red. También se comentan las herramientas utilizadas, y en caso de poderse haber utilizado más de una, se explica la elección tomada. - Capítulo 3 – Servicios Web API: En este capítulo se explicará que son los servicios Web API, qué ofrecen y la facilidad de integrarlos en la interfaz de este PFC. - Capítulo 4 – Funcionamiento y resultados: Se mostrarán los resultados obtenidos en la ejecución de la aplicación, tanto de la parte referente a los datos obtenidos de DBpedia como de los obtenidos con las Web APIs, mostrando para estos últimos 4 casos concretos. - Capítulo 5 – Herramientas utilizadas: En este capítulo se detallan las herramientas utilizadas en el desarrollo de la aplicación, incluyendo una breve explicación del agente 3D. - Capítulo 6 – Conclusiones y trabajo futuro: Se expondrán las conclusiones obtenidas una vez finalizado este PFC y cómo podría orientarse el desarrollo de este trabajo para futuras aplicaciones, la evolución en el desarrollo del PFC mediante un diagrama de Gantt, y finalmente una valoración personal del trabajo realizado. La memoria viene acompañada de ocho anexos donde se explicará con más detalle los elementos desarrollados en el PFC: - Anexo A: Se describe la fase de análisis del proyecto. - Anexo B: Se describe la fase de diseño del proyecto. - Anexo C: Reconocedor de voz: Loquendo ASR. - Anexo D: Se explica la sintaxis de la gramática ABNF, el programa de apoyo que se ha utilizado para facilitar el entendimiento de la gramática, y los problemas encontrados y las soluciones propuestas para solventar dichos problemas. - Anexo E: Web APIs. Obtención de la información. - Anexo F: Síntesis de voz. Loquendo TTS y la generación de visemas. - Anexo G: Interfaz Swing e Integración de nuevas funcionalidades. - Anexo H: Pruebas realizadas. 7 Capítulo 2: Proceso de comunicación En este capítulo se va a explicar cómo funciona la aplicación desarrollada, detallando cuáles son las fases por las que una consulta atraviesa desde su formulación por el usuario hasta que éste recibe la respuesta. En la figura 1 se puede observar el esquema general del proceso de comunicación aplicado, el cual se va a detallar en las siguientes secciones. Contenido 2.1. Diseño de la Interacción Hombre-Máquina (Input) ...................................7 2.1.1 Reconocimiento por voz ....................................................................................... 7 2.1.2 Interfaz visual para la entrada de datos de consulta .........................................12 2.2. Obtención de la información. ................................................................. 13 2.2.1. Consulta a la DBpedia ........................................................................................13 2.2.2. Consulta a la Web APIs ......................................................................................14 2.2.3. Análisis de los datos de entrada ........................................................................15 2.2.4. Obtención de la respuesta .................................................................................16 2.3. Diseño de la Interacción Hombre-Máquina (Output) .............................. 19 2.1. Diseño de la Interacción Hombre-Máquina (Input) En esta sección se va a ver la interacción del usuario con la aplicación, diferenciando entre la interacción por voz y la interacción por dispositivo de entrada manual, ya sea ratón o teclado. 2.1.1 Reconocimiento por voz Cuando el usuario formula una pregunta al sistema, éste debe reconocer las palabras que el usuario ha utilizado y lo que ha solicitado. Para ello es necesaria una herramienta que además de reconocer la voz, interprete esas palabras y devuelva de alguna manera el significado de la consulta. A este tipo de herramientas se las conoce como herramientas de Reconocimiento Automático del Habla (RAH), o en inglés Automatic Speech Recognition (ASR). Un ASR es una herramienta software capaz de Diseño de la Interacción Hombre-Máquina (Input) 8 procesar la señal de voz emitida por el ser humano y reconocer la información contenida en ésta, convirtiéndola en texto o emitiendo órdenes que actúan sobre un proceso. Fig. 1. Esquema representativo de la comunicación vía voz. El Sistema de consulta semántica corresponde al PFC que se está desarrollando en paralelo. En este PFC, y por estar definido en los requisitos iniciales, se ha utilizado como reconocedor del habla la herramienta Loquendo ASR [LOQASRWEB], un software propietario de reconocimiento de voz de última generación para aplicaciones vocales, que ofrece completa independencia de la identidad del hablante y robustez frente al ruido exterior, entre otras muchas características. Dispone de librerías para varios lenguajes de programación entre ellos JAVA, lo que permite también cumplir el requisito de multiplataforma al que se hizo referencia en el apartado 1.2 de esta memoria. La entrada de audio Para hacer funcionar un ASR es necesario primero configurar el sistema de entrada con el que el reconocedor va a trabajar. Para ello hay que indicar el formato en que el sonido debe ser tratado, es decir, hay que decidir la frecuencia de muestreo, la precisión de la discretización y el formato de compresión del audio, con el fin de convertir la señal analógica del micrófono en señal digital. Para definir la configuración de Loquendo ASR se ha utilizado el estudio realizado en otro PFC [DAVANPFC], donde Proceso de comunicación 9 se definen las características óptimas para que el reconocedor pueda realizar su función de forma correcta. Una vez configurada la entrada de audio, se procede a la espera de que el usuario formule su pregunta o petición. La gramática utilizada Las herramientas actuales de reconocimiento del habla no son capaces de reconocer todas las palabras que un usuario puede llegar a decir sin verse afectado el tiempo de procesamiento de la entrada de audio. Por ello, estos sistemas tienen la necesidad de utilizar gramáticas que restringen lo que el usuario puede decir y el orden en que lo dice, con la finalidad de asegurar un reconocimiento más aproximado y obtener buenos resultados en el análisis de la entrada de audio. Estas gramáticas están formadas por palabras clave que, a su vez forman parte de frases variables, que sirven al sistema de reconocimiento del habla para reconocer no sólo las palabras que puede decir un usuario, sino la sintaxis de la propia frase. Uno de los aspectos importantes que hay que tener en cuenta para elegir correctamente una de las gramáticas disponibles para el reconocimiento del habla es si está considerada como estándar por el consorcio W3C [W3CWEB]. El W3C (World Wide Web Consortium) es una comunidad internacional donde distintas organizaciones, personal a tiempo completo y el público en general trabajan conjuntamente para desarrollar estándares Web con el fin último de guiar la Web hacia su máximo potencial. Este consorcio ha publicado dos estándares destinados a definir las especificaciones de las gramáticas para el reconocimiento del habla. Estos estándares son el SRGS (Speech Recognition Grammar Specification) [W3CSRGS], basado en la especificación de la gramática JSGF que se verá a continuación y que trata la parte sintáctica de las gramáticas; y el estándar SISR (Semantic Interpretation for Speech Recognition) [W3CSISR] que especifica la parte semántica de dichas gramáticas. Actualmente existen tres formatos de gramáticas que pueden ser utilizados por los ASR: - Gramática JSGF (JSpeech Grammar Format) [W3CJSGF]: Está basada en el lenguaje Java por lo que es independiente de la plataforma de ejecución. Utiliza una representación textual legible y fácilmente editable tanto por desarrolladores como por los propios ordenadores, y además permite la posibilidad de integrarse sobre el propio código fuente del programa. A pesar de estas facilidades y de servir de referencia a la especificación de las siguientes gramáticas, no se encuentra incluida en el estándar SRGS. Diseño de la Interacción Hombre-Máquina (Input) 10 - Gramática XMLF (XML Form) [W3CSRGS]: Es una de las formas de gramática más utilizada, su sintaxis es similar a la utilizada en ficheros XML. Es una de las gramáticas contempladas en los estándares SRGS y SISR. - Gramática ABNF (Augmented Backus–Naur Form) [W3CSRGS]: la sintaxis utilizada es muy similar a la utilizada en las gramáticas BNF, como Byson o Yacc. También está contemplada en los estándares SRGS y SISR. Como ya se comentó anteriormente, uno de los aspectos a tener en cuenta a la hora de elegir una gramática para el reconocimiento del habla es si dicha gramática está contemplada en los estándares de W3C. Esto es debido a que el uso de estándares en los ASR puede conducir a grandes ventajas, como por ejemplo aumentar la portabilidad, acelerar el desarrollo y ayudar a la reutilización de la gramática. Estos estándares también pueden reducir la carga de trabajo de los desarrolladores durante el aprendizaje de la sintaxis y la codificación de la gramática [STDASRFL]. Por estas razones y a pesar de ser una gramática bastante utilizada, se ha descartado el utilizar la gramática JSGF. A diferencia de la anterior, las gramáticas ABNF y XMLF son dos formatos reconocidos por el estándar SRGS. Este estándar recoge que ambos formatos son perfectamente equivalentes y transformables entre sí, es decir, una gramática expresada en XML puede ser transformada en ABNF y perfectamente transformada de nuevo en XML. La única diferencia que existe entre ambas es la forma en la que se presenta para el desarrollador. ABNF permite una codificación muy rápida debido a su sencillez y limpieza, mientras que XMLF es más adecuado para el manejo en entornos automáticos y la integración con lenguajes de diseño VUI basado en XML. A continuación se puede observar un ejemplo comparativo donde se pueden ver las diferencias de legibilidad entre ambos formatos, siendo el resultado final obtenido exactamente el mismo: http://blog.tropo.com/2009/12/17/advanced-grammar-topics-for-tropo/ Proceso de comunicación 11 Como se puede observar una gramática escrita en ABNF ofrece una mayor legibilidad que la misma gramática en XMLF. Por esta razón ABNF es el formato elegido para su utilización en la gramática que Loquendo ASR necesita. En el anexo D se explica detalladamente la sintaxis de una gramática ABNF, y la herramienta que se ha utilizado para verificar y corregir la gramática final desarrollada. Reconocimiento de la voz Después de configurar el reconocedor y haber definido la gramática que se va a utilizar y compilarla, es el momento de comenzar a analizar lo que el usuario vaya a decir. Para ello vamos a basarnos en la figura 2: Fig. 2. Fases del reconocimiento de voz. - Fase 0 (Previo): Se abre el micrófono para recibir la señal. El usuario comienza a hablar. La señal se almacena en un buffer previamente configurado para poder albergar la cantidad de datos que se van a recibir por el micrófono (ver anexo C). - Fase 1: El reconocedor va comparando de forma implícita y mediante un transcriptor fonético las palabras recogidas por el micrófono con las palabras definidas en la gramática. Para ello realiza un análisis de todas las frases posibles registradas en la gramática almacenadas en un RO (Recognition Object), las compara con la frase recibida y asigna a cada una de las palabras un valor de confianza entre 0 y 1, siendo 1 el valor de concordancia perfecta. El análisis de las frases se lleva a cabo de forma interna mediante un sistema de redes neuronales, con el que se va creando un árbol de frases posibles o hipótesis. Hay que destacar que esta fase está íntegramente desarrollada por Loquendo ASR, y es invisible al desarrollador. - Fase 2: Cuando el usuario deja de hablar el micrófono se cierra y se procede a analizar los datos almacenados. De todas las hipótesis posibles se extraen aquellas cuyos resultados de confianza sean mayores que un cierto valor límite. Estas hipótesis quedan ordenadas por el valor de confianza, siendo la hipótesis Obtención de la información 18 fuente de la página. Llegados a este punto se busca la etiqueta que referencia a la imagen, donde se encuentra finalmente la URL de la imagen que se estaba buscando. Para terminar, se carga la imagen en la interfaz. Respuesta de las Web APIs Como ya se comentó en el apartado 2.2.2, una consulta a las Web APIs consiste normalmente en una petición HTTP a la que se le añaden como parámetros los datos solicitados. Estas consultas devuelven la información que se ha solicitado en un determinado formato como JSON [JSONWEB] o XML [W3CXML] que en ocasiones puede ser elegido por el desarrollador. Hay que tener en cuenta que aunque se haya elegido el formato XML para las consultas a Web APIs, la estructura de la respuesta no es siempre la misma. En la figura 10 se pueden ver dos estructuras XML diferentes devueltas cada una por dos Web APIs utilizadas en este PFC. A la izquierda aparecen los datos obtenidos a través de una Web API que ofrece información del tiempo atmosférico, como temperatura o velocidad del viento entre otros, ya sea para el mismo día como para días siguientes; a la derecha aparecen los datos obtenidos de una Web API especializada en música, de donde se obtienen datos de canciones siguiendo los criterios de consulta especificados, y como se puede observar existen datos que llevan añadida información discriminatoria. Para obtener más información de las Web APIs utilizadas en este PFC, ver Anexo E. Fig. 10. Estructura de distintos XML. A la izquierda XML con datos del tiempo atmosférico, a la derecha XML con datos de canciones (los datos en color naranja indican atributos de los datos a los que están enlazados). La información obtenida de las Web APIs viene sin estructurar, es decir, se recibe como una cadena de bytes que hay que interpretar para poder obtener la información y seleccionar después los datos que se consideren de utilidad. Para poder sustraer la información de los XML, tanto en el caso de DBpedia como en el caso de las Web APIs, se han empleado unos parseadores de XML utilizando SAX (Simple API for XML) [SAXWEB], un API totalmente escrito en Java que se encuentra incluido dentro del JRE Proceso de comunicación 19 de Java y que nos permite crear nuestro propio parser de XML. Estos parsers utilizados recorren los documentos XML recibidos y almacenan en memoria los datos obtenidos para poder acceder a ellos en cualquier momento. Para obtener más información sobre los parseadores XML implementados, ver Anexo E. 2.3. Diseño de la Interacción Hombre-Máquina (Output) Una vez obtenida la información solicitada, se deben seleccionar los datos a mostrar y, en algunos casos, analizar si será necesario añadir controles de interacción para el usuario. Como se puede observar en la figura 7, y como ya se explicó en el apartado 2.1.2, se dispone de dos zonas diferenciadas, donde puede mostrarse la información recibida. Si los datos recibidos de los servicios Web contienen información que se puede utilizar para añadir nuevos controles de interacción, éstos pueden añadirse como se observa en la figura 11-3. Si los datos recibidos son simplemente texto plano, imágenes o de otro tipo que no requiere de nuevas interacciones con el usuario, pueden situarse en la parte central del lado derecho (figura 11-4), debajo del agente virtual autónomo. Fig. 11. Interfaz WIMP, diferenciando las distintas zonas disponibles para mostrar datos. 1 4 1 3 1 1 1 2 Diseño de la Interacción Hombre-Máquina (Output) 20 Además de mostrar los datos de forma visual, el agente 3D (figura 11-2) informa mediante voz natural. Para poder ofrecer este servicio es necesario utilizar un sintetizador de voz, es decir, un conversor de texto a audio, y para ello se ha utilizado Loquendo TTS [LOQTTSWEB] como se especificó en los requisitos iniciales. Esta herramienta ofrece soporte en Java por lo que se sigue manteniendo el compromiso de realizar una aplicación multiplataforma, pero además ofrece voz sintética natural en español, permite su utilización en aplicaciones cliente-servidor, ofrece un conjunto de expresiones predefinidas y onomatopeyas que permiten dar emoción y realismo a la aplicación; y permite obtener la transcripción fonética del texto a sintetizar, lo que será de utilidad para la creación de visemas que serán utilizados por el agente para simular una correcta sincronización labial. El concepto de visema deriva de las palabras visual phoneme, esto es, el patrón de referencia visual de un fonema, que se encuentran modelados como poses del personaje virtual en el módulo 3D [MH3DALB]. El funcionamiento del sistema desde que obtiene el texto a sintetizar hasta que es convertido a voz sintética es el que se muestra en la figura 12. En primer lugar, y de forma interna, Loquendo TTS analiza mediante un transcriptor fonético la frase a decir. Para ello utiliza el alfabeto X-SAMPA (Extended Speech Assessment Methods Phonetic Alphabet) [XSAMPAWEB], un alfabeto fonético que emplea una codificación ASCII que cubre todos los fonemas existentes en el Alfabeto Fonético Internacional (IPA) [IPAWEB]. Fig. 12. Proceso de conversión de texto a audio y visemas Después de obtener la transcripción fonética de Loquendo TTS, es necesario analizarla para ajustar los tiempos del habla y saber qué fonema corresponde con qué visema. Para poder asociar cada símbolo X-SAMPA de la transcripción fonética con el código que identifica a cada visema, se ha desarrollado un analizador léxico y sintáctico que, dada la transcripción fonética de una frase devuelve el código del visema asociado a cada uno de los símbolos que componen esa transcripción. Para crear este analizador Proceso de comunicación 21 se han utilizado dos herramientas que, trabajando en conjunto, son capaces de crear por sí solas las clases Java necesarias que componen el analizador final. Estas herramientas son JFlex [JFLEXWEB] que se encarga de la parte léxica, y CUP [CUPWEB] encargada de la parte sintáctico-semántica. Ambas herramientas están desarrolladas para poder trabajar de forma conjunta, y sobre todo permiten definir el conjunto de tokens y la gramática de forma similar a como lo hacen otros generadores como Lex y Flex, o Byson y Yacc respectivamente. Una vez desarrollado el analizador léxico y sintáctico se procede a analizar la secuencia de fonemas obtenida de Loquendo TTS, de donde se obtiene la secuencia de códigos que identifican a cada visema. Para más información sobre el analizador léxico y sintáctico y las herramientas utilizadas para su realización, ver anexo F. Después de obtener la secuencia de códigos de los visemas, éstos son enviados al agente 3D para que realice la asociación de cada código con su representación labial. Hay que destacar que la duración de cada uno de los fonemas obtenidos es desconocida, y no existen métodos en la documentación de Loquendo TTS para Java que ofrezcan este tipo de servicio, por lo que el módulo del agente 3D debe hacer una aproximación del tiempo de duración de cada uno de los visemas. 22 23 Capítulo 3: Servicios Web API Una vez explicado cómo es el proceso de comunicación con las Web API, tanto solicitud de información como análisis de la respuesta, se procede a explicar cómo añadir nuevas funcionalidades de consulta a otras Web API. Posteriormente se detalla el conjunto de servicios de consulta Web que se han utilizado en el desarrollo de esta aplicación. Contenido 3.1. Integración de nuevas funcionalidades ................................................... 23 3.2. Web APIs integradas .............................................................................. 25 Reconocimiento de IP pública .................................................................................. 25 Localización geográfica de una IP ............................................................................. 25 Servicio de pronóstico meteorológico ...................................................................... 26 Obtención de la hora y la fecha ................................................................................ 26 Servicio de noticias ................................................................................................... 26 Servicio de datos musicales ...................................................................................... 26 3.1. Integración de nuevas funcionalidades Un aspecto importante a tener en cuenta en el desarrollo de la aplicación ha sido si en un futuro podrían ampliarse las funcionalidades con nuevas herramientas que permitan al usuario obtener cualquier tipo de información. De hecho, aunque la aplicación se ha generado dentro del proyecto Alfa III GAVIOTA para la consulta de temas científico-mecánicos, se ha buscado diseñar una herramienta flexible sobre la que puedan añadirse y adaptarse nuevas consultas de información procedentes de distintos Servicios Web. Para poder integrar nuevas funcionalidades en la aplicación se ha dispuesto de los elementos necesarios para que la integración no suponga tener que cambiar la disposición del resto de componentes que forman parte de la interfaz. Estos elementos son paneles “cambiantes”, es decir, paneles que sirven de contenedores para otros paneles y que ofrecen la posibilidad de alternar la visibilidad de unos y otros sin alterar Integración de nuevas funcionalidades 24 el resto de componentes de la interfaz. Estos paneles se encuentran en la sección de la derecha en el centro (1), y en la pestaña de “Otras herramientas”, en la sección recuadrada (2) de la figura 13. Esta pestaña es la que contiene todos los servicios Web APIs integrados disponibles. Fig. 13. Secciones disponibles para integrar nuevas funcionalidades. Además de cambiar la interfaz, con el fin de mantener la interacción multimodal en la aplicación sería necesario ampliar las producciones en la gramática, permitiendo así que el usuario final pueda realizar las solicitudes posibles de esa nueva funcionalidad mediante el reconocimiento de voz. Para ello sólo es necesario modificar brevemente la gramática principal añadiendo la referencia a un nuevo fichero de gramática, que sería el que contenga los nuevos posibles reconocimientos. Para obtener más información de cómo hacer esta referencia a un fichero de gramática externo, ver anexo D. Después de ampliar la gramática y diseñar los paneles habría que añadir los métodos apropiados en los módulos que reconocen la consulta y que definen las respuestas a dar al usuario. Estos módulos están explicados en el anexo G. 1 1 1 2 Servicios Web API 25 3.2. Web APIs integradas Actualmente existen multitud de servicios Web que ofrecen la posibilidad de utilizar sus recursos para el desarrollo de nuevas aplicaciones. De hecho, para un único tipo de servicio existen gran cantidad de Web APIs disponibles. Para realizar la búsqueda de estos servicios y ayudar en la elección de los utilizados en este PFC, se ha empleado un servicio web [DIRAPISWEB] que ofrece un directorio de APIs con información sobre cada una de ellas, como el protocolo de llamada, el formato devuelto o si es necesaria una key para utilizarla; entre otros datos informativos. Entre todos los servicios Web disponibles, para este PFC se ha utilizado un servicio de reconocimiento de IP pública y localización geográfica de IPs, un servicio de pronóstico meteorológico, uno para obtener la hora y la fecha, un servicio de noticias y un servicio de datos musicales. A continuación se indican algunos detalles de estos servicios utilizados, aunque si se desea obtener más información se puede consultar el anexo E. Reconocimiento de IP pública En algunos casos, y dependiendo de la conexión a la red, se puede obtener del propio sistema la IP pública que tiene el ordenador. El inconveniente viene cuando el ordenador no se encuentra conectado directamente a internet, sino que se utiliza algún dispositivo que ofrece esa conexión. Es aquí cuando no se puede obtener a través del sistema la IP pública con la que el ordenador se comunica con el exterior, por lo que es necesario servirse de servicios externos para obtenerla. En este PFC se ha considerado la posibilidad de que ocurra este inconveniente, y para solucionarlo se ha utilizado el servicio GeoIP API [GEOIPWEB], un servicio gratuito que ofrece obtener IP pública del ordenador sin necesidad de un registro previo. La consulta a este servicio se hace de forma transparente al usuario. Localización geográfica de una IP Este tipo de servicio puede ser muy útil para localizar la ubicación del ordenador sobre el que está funcionando la aplicación, ya que permiten obtener información extra que puede ser útil cuando el usuario no da toda la información necesaria en una solicitud a la aplicación y ésta debe interpretar esos datos inexistentes. El inconveniente de estos servicios es que algunos no son completamente exactos ya que en ocasiones consideran la IP de uno de los nodos de la compañía que ofrece acceso a internet, y éste se encuentra en otra ciudad. Otros servicios en cambio, ofrecen resultados más exactos, pero sólo permiten su utilización previo pago. Web APIs integradas 26 La utilización de este tipo de servicio en este PFC se ha realizado a través de la misma API empleada para obtener la IP pública [GEOIPWEB], que además de ser un servicio gratuito, sus resultados demuestran que la localización de una IP llega a ser exacta incluso a nivel de ciudad. La consulta a este servicio también se hace de forma transparente al usuario. Servicio de pronóstico meteorológico Este servicio está habilitado para que el usuario pueda hacer consultas sobre él a través de nuestra interfaz. Permite consultar no sólo el pronóstico para el mismo día, sino que ofrece también la posibilidad de preguntar por el día siguiente o incluso por uno de los días de la semana. Estas consultas se apoyan en el servicio ofrecido por World Weather Online [WWEONWEB] que permite obtener de forma gratuita aunque limitada, un pronóstico del tiempo a cinco días vista, además de ofrecer distintas alternativas de búsqueda como búsqueda por IP, por ciudad-país o incluso por latitudlongitud [WWEATHWEB], aunque este último no se ha utilizado en este PFC. A pesar de ser gratuito, la utilización de este servicio requiere de una key obtenida previo registro. Obtención de la hora y la fecha Este es uno de los servicios más utilizados, y por ello también se ha querido incluir en el repertorio de opciones disponibles al usuario. El servicio Web utilizado para obtener esta información procede del mismo servicio que el del pronóstico meteorológico, aunque la dirección de consulta es distinta [WWETIWEB]. Este servicio también ofrece búsquedas por ciudad-país, IP y latitud-longitud, y la key necesaria para realizar la consulta puede ser la misma que la utilizada para el pronóstico meteorológico. Servicio de noticias Este es el único servicio Web implementado que no utiliza una Web API para obtener la información, ya que utiliza los RSS de distintas entidades especializadas en noticias. Un RSS (Really Simple Syndication) es un formato XML utilizado por determinadas entidades para ofrecer información actualizada a sus suscriptores. En este PFC se han utilizado los RSS de noticiarios a nivel nacional como RTVE [RTVERSS] del que se obtienen noticias generales, de economía, ciencia-tecnología y cultura; y MARCA [MARCARSS], líder nacional en noticias deportivas. Servicio de datos musicales Los servicios descritos hasta el momento utilizan un único servicio Web, a excepción de las noticias, en cambio, este servicio de datos musicales se apoya en dos servicios Servicios Web API 27 distintos, el primero es la API de Last.fm [LASTFMAPI], que ofrece un conjunto muy variado de métodos que permiten obtener entre otros, los listados de canciones más escuchadas de un estilo musical concreto. El segundo servicio utilizado es la API de Deezer.com [DEEZERAPI], que ha permitido obtener fragmentos de 30 segundos de las canciones que se habían recibido previamente de Last.fm. Utilización de las Web APIs 34 Solicitud de noticias de actualidad Como se comentó en el capítulo 3, también se ha añadido un servicio de consulta de noticias, donde el usuario puede ver las noticias más actuales gracias a los servicios RSS existentes en la red. A continuación se van a mostrar los resultados de una consulta de Ciencia y Tecnología, aunque el resto de resultados se obtienen de forma análoga: Fig. 21. Escenario principal de solicitud de noticias. Cuando un usuario solicita las noticias de actualidad de Ciencia y Tecnología, se le abre una ventana nueva con todas las noticias obtenidas del servicio RSS. El hecho de no utilizar los elementos existentes en la interfaz para mostrar las noticias es por cuestiones de legibilidad, ya que la información obtenida suele ser muy extensa y esto impedía una navegación más natural por parte del usuario. Del mismo modo, si el usuario desea abrir uno de los artículos de actualidad en la web, sólo lo puede hacer utilizando el ratón, ya que muchos de los titulares son demasiado extensos como para obligar al usuario a tener que recitarlo, mientras que si actúa con el ratón es más fácil y natural. En la figura 22 se puede ver la ventana obtenida tras la solicitud del usuario, y en la figura 23 se encuentra una captura de uno de los artículos obtenidos después de haberse seleccionado de entre los existentes. Funcionamiento y resultados 35 Fig. 22. Ventana de noticias de Ciencia y Tecnología obtenida del RSS de RTVE. Fig. 23. Página web de una noticia devuelta por el RSS de RTVE. Utilización de las Web APIs 36 Solicitud de canciones más escuchadas Cuando el usuario desee ver qué canciones de un estilo de música son las más escuchadas, obtendrá un listado donde se le ofrecerá la posibilidad de poder acceder a la compra de la canción o realizar una escucha previa de 30 segundos (figura 24). Para ambas opciones el usuario puede solicitarlo a través de la interfaz utilizando el ratón o mediante una orden por voz destacando que, para este último caso, en este PFC el usuario debe decir el título de la canción de forma “españolizada”, ya que sólo se encuentran instaladas con Loquendo ASR las librerías propias de la lengua española y de este modo la interpretación del reconocedor de voz puede ser más exacta. Fig. 24. Estado de la interfaz después de haber seleccionado ver el listado de canciones BLUES más escuchadas. Un aspecto a destacar en esta herramienta es el control del reproductor, donde el usuario puede detener la reproducción de la canción, ya sea mediante una orden de voz o utilizando el ratón. En cualquiera de los casos si se había pulsado un botón de reproducción, éste se encontraba en el estado de la figura 25-Izquierda, y cuando el usuario detiene la reproducción vuelve a su estado original (figura 25-Derecha): Funcionamiento y resultados 37 Fig. 25. Cambio de estado del control de reproducción. Uno de los inconvenientes que se pueden dar en esta herramienta es la cantidad de canciones de las que no se ha podido obtener el archivo de audio para ofrecer la escucha previa. Esto se produce porque al utilizar dos APIs (Last.fm y Deezer) y ser de la API de Last.fm de la que se obtiene el listado de las canciones más escuchadas, los datos enviados por ésta no incluyen la dirección URL de donde se puede obtener el archivo de audio. Por esto se ha tenido que realizar una búsqueda por artista utilizando la API de Deezer, que sí que ofrece la dirección para obtener el archivo de audio de 30 segundos. El hecho de tener que buscar en dos APIs diferentes origina otro inconveniente y es el tiempo de espera y el número de peticiones HTTP necesarias. Con el sistema de búsqueda y almacenamiento utilizado (anexo E), los accesos se reducen y por tanto el tiempo de espera también (68.37%), y el índice de fallos en la obtención del archivo es de un 10% (Figura 26) Fig. 26. Grafo de tiempo de búsqueda y acceso a los datos (Arriba) y porcentajes de aciertos y fallos al obtener el archivo de audio (Abajo). 0 2000 4000 6000 8000 10000 Tiempo (1º vez) Tiempo (siguientes) 10% 90% Fallos Aciertos Conversación natural con la aplicación 38 4.3. Conversación natural con la aplicación Aunque no se ha comentado en la memoria, el sistema también permite conversar con el usuario de una forma natural, es decir, la aplicación responde a saludos y despedidas, consultas sobre quién es, o en el caso de que no consiga reconocer correctamente la entrada de audio, solicita al usuario la repetición de la consulta. De hecho, el agente 3D puede realizar gestos faciales asociados a alguna de estas acciones: Fig. 27. Emociones del personaje 3D. De izquierda a derecha: Normal, alegre y enfadado. En este PFC se ha definido que cuando el usuario saluda o se despide, la aplicación reconoce esta acción y actúa en consecuencia, respondiendo con una expresión facial sonriente y devolviendo el saludo; mientras que si el sistema no ha reconocido lo que el usuario le ha dicho, el agente 3D ponga cara de enfado. 4.4. Resultados En el CD adjunto a esta memoria se pueden encontrar los vídeos demostrativos de la ejecución e interacción de la aplicación con el usuario, como se puede observar en la figura 28: Fig. 28. Interacción de un usuario con la aplicación. A la izquierda se puede ver al usuario interactuando mediante voz. A la derecha el usuario utiliza el ratón para comunicarse con la aplicación. 39 Capítulo 5: Herramientas utilizadas En este capítulo se van a identificar las herramientas que han sido utilizadas a lo largo del proyecto, indicando en qué área han resultado de utilidad. También se da una breve introducción al modelo 3D utilizado en el agente virtual integrado en la aplicación. Contenido 5.1. Herramientas utilizadas en el proyecto .................................................. 39 5.1.1. Entorno de desarrollo ........................................................................................39 5.1.2. Reconocimiento de voz .....................................................................................40 5.1.3. Síntesis de voz....................................................................................................40 5.1.4. Interfaz WIMP ....................................................................................................41 5.1.5. Memoria del proyecto .......................................................................................41 5.2. El agente 3D ........................................................................................... 41 5.1. Herramientas utilizadas en el proyecto A lo largo de este proyecto se han utilizado muy diversas herramientas que han facilitado el desarrollo de la aplicación, han permitido entender el funcionamiento de algunos elementos como las gramáticas ABNF, o han facilitado la implementación de otras herramientas necesarias, como el analizador léxico-sintáctico de fonemas. 5.1.1. Entorno de desarrollo Para programar en Java son de gran utilidad las herramientas que permiten tener un entorno de desarrollo preparado para compilar y ejecutar las aplicaciones que se van creando. Para este proyecto, los entornos de desarrollo utilizados han sido dos: Eclipse IDE para Java y JMonkey Engine. Eclipse IDE [ECLIPSEWEB] es un entorno de desarrollo integrado (Integrated Development Environment) de código abierto multiplataforma que permite crear programas, compilarlos y ejecutarlos. Para ello dispone de un editor de código, un compilador, un depurador y un sistema de ejecución de programas Java. Eclipse IDE se Herramientas utilizadas en el proyecto 40 encuentra disponible para distintos lenguajes de programación, aunque en este proyecto se ha utilizado exclusivamente el dedicado al lenguaje Java. JMonkey Engine [JMONKWEB] es un motor de videojuegos libre orientado al desarrollo de videojuegos en 3D, de hecho, es uno de los engines 3D más completos escritos en Java. En este proyecto, se ha utilizado como el entorno de desarrollo principal de la aplicación ya que contiene librerías especiales para realización de animaciones, necesarias para hacer funcionar el módulo del agente 3D en la aplicación. 5.1.2. Reconocimiento de voz Para el reconocimiento de voz, se ha utilizado la herramienta Loquendo ASR, ya que es un reconocedor de voz de última generación para aplicaciones vocales. Ofrece independencia del hablante y reconoce con gran fiabilidad un amplio vocabulario, incluso en ambientes ruidosos. Actualmente es utilizado por multitud de servicios de habla que procesan millones de llamadas cada día, como servicios de atención telefónica totalmente automatizados, portales de voz y aplicaciones para automóviles. Loquendo ASR se apoya en el uso de gramáticas para definir qué palabras o frases se pueden llegar a reconocer. Para poder probar la gramática desarrollada, y verificar su correcto funcionamiento una vez se encuentre instalada en el reconocedor, se ha utilizado el plugin Nugram IDE [NUGDOWN] para eclipse desarrollado por Nüecho Nugram Platform [NUGRAM]. Este plugin permite generar el fichero de la gramática con el formato especificado en el estándar SRGS [W3CSRGS], pero además permite introducir frases de prueba, ver el árbol sintáctico que genera y el conjunto de valores semánticos que se obtienen. El uso de este plugin se explica con más detalle en el anexo D. 5.1.3. Síntesis de voz Para convertir una cadena de texto a audio se ha utilizado la herramienta de síntesis de voz Loquendo TTS, un software capaz de leer cualquier texto en el idioma que se haya instalado, utilizando para ello voces sintéticas de alta calidad alta y además naturales. Estas voces poseen la expresividad de las voces humanas y son capaces incluso de reproducir onomatopeyas. Una de las características que ofrece Loquendo TTS es la obtención de la fonética de la frase a sintetizar, lo que es de gran utilidad para la sincronización labial del agente virtual. El analizador léxico-sintáctico desarrollado que asocia el conjunto de fonemas Herramientas utilizadas 41 que se pueden llegar a obtener con cada uno de los visemas que puede reproducir el agente 3D, se ha obtenido utilizando las librerías de JFlex [JFLEXWEB] y CUP [CUPWEB]. 5.1.4. Interfaz WIMP Para la generación y maquetación de la interfaz general y de cada uno de los servicios integrados, se ha utilizado la herramienta NetBeans IDE [NTBEWEB]. Este programa permite diseñar de forma gráfica cualquier interfaz WIMP, y además genera el código Java necesario para su creación. Este código es accesible, y puede ser utilizado para proyectos más grandes como el presente. 5.1.5. Memoria del proyecto Además de las herramientas utilizadas para la implementación y pruebas de la aplicación, también se han utilizado otras herramientas para el análisis, el diseño, el seguimiento temporal del desarrollo del proyecto y la escritura de la presente memoria. Estas herramientas son Microsoft Visio [MICVIS10] para crear los diagramas de la fase de análisis disponibles en el anexo A, Microsoft Project [MICPRJ10] para generar el Diagrama de Gantt con la evolución temporal del proyecto, y las distintas herramientas de Microsoft Office [MICOFF10] para crear los gráficos expuestos en este documento, y la memoria misma. 5.2. El agente 3D Al formar parte activa de la interfaz, y aunque no se haya desarrollado ninguno de sus módulos en este proyecto, se ha creído conveniente comentar los aspectos más importantes del modelo empleado para el agente 3D. Estos son el modelado geométrico, la apariencia, el movimiento, y por último las herramientas utilizadas para poder integrarlo en una aplicación Java. Para el modelo geométrico del agente se adquirieron bibliotecas de modelos humanos 3D altamente realistas, sobre los que posteriormente se hicieron optimizaciones en la geometría del modelo para adecuarla a su uso en motores gráficos 3D en tiempo real. La apariencia del agente 3D consiste en el conjunto de texturas que, al aplicarlas sobre el modelo geométrico, dan realismo a la escena. El conjunto de texturas utilizadas han sido adquiridas a entidades externas especializadas en este tipo de herramientas [TEXT3D]. Entre las texturas utilizadas se encuentran la textura de la piel, El agente 3D 42 texturas para las pestañas y los ojos, y texturas de la lengua y la mandíbula. Éstas se pueden observar en la figura 29. Fig. 29. Texturas utilizadas en el modelo 3D. Para el movimiento del agente 3D se han utilizado técnicas de rigging facial y ruido de Perlin, que permiten: - Movimientos de cabeza suaves y continuos - Atención visual - Parpadeos aleatorios - Deformaciones naturales para mostrar emociones - Deformaciones naturales para interpretar morfemas labiales. Estos dos últimos casos pueden verse con mayor detalle en la figura 30. Fig. 30. Ejemplos de deformaciones naturales al expresar emociones o interpretar morfemas labiales. 43 Capítulo 6: Conclusiones y trabajo futuro En este último capítulo se van a exponer las conclusiones finales del proyecto, indicando el cumplimiento de los objetivos definidos en el capítulo 1. También se muestra la evolución temporal del proyecto desde su comienzo hasta su finalización, detallando el tiempo dedicado a cada una de las fases de desarrollo. Para terminar se exponen algunas ideas para extender las funcionalidades de la aplicación desarrollada, y una valoración personal. Contenido 6.1. Conclusiones .......................................................................................... 43 6.2. Evolución temporal ................................................................................ 44 6.3. Trabajo futuro ....................................................................................... 48 6.4. Valoración personal ............................................................................... 48 6.1. Conclusiones Una vez finalizado el proyecto, se puede asegurar que se ha conseguido una interfaz que permite al usuario tener una comunicación de forma natural con la aplicación, y sobre la que se pueden añadir nuevas herramientas de consulta que la hagan más funcional. Respecto a los requisitos definidos al comienzo de este PFC se puede asegurar que: - El usuario puede solicitar la información que desee obtener interaccionando directamente sobre la interfaz a través de ratón, o formulando las consultas mediante voz de forma natural. En cualquier caso se guarda información relacionada con la consulta con el fin de mantener una comunicación usuarioaplicación más natural. - Los resultados devueltos se obtienen de servicios Web ajenos a la aplicación, y son mostrados al usuario a través de la interfaz y mediante voz sintética. - Se permite la integración de nuevas funcionalidades de forma fácil y rápida, al disponer de elementos que permiten añadir otros sin tener que modificar la estructura de la interfaz. - La interfaz incluye un área donde se muestra al agente 3D realista. Requisitos del sistema 50 La metodología que se ha seguido en el desarrollo de este proyecto se sustenta en la Orientación a Objetos, dado que el lenguaje de programación utilizado (Java) se apoya en esta metodología. El uso de la metodología orientada a objetos permite desarrollar los distintos módulos que componen la aplicación de forma unitaria, con sus fases de análisis, diseño e implementación propias de cada uno de ellos. El hecho de utilizar esta metodología se debe a que permite considerar cada uno de los módulos como proyectos más reducidos, pudiéndose volver a fases previas de forma más temprana sin tener que revisar módulos ya testeados, y una vez finalizados permite realizar pruebas sobre cada módulo de forma independiente. De este modo se consigue reducir la tasa de fallos de forma individual y al mismo tiempo asegurar una correcta integración con los módulos ya terminados. A.1. Requisitos del sistema. A continuación se especifican los requisitos que debe de cumplir la aplicación, obtenidos al inicio del proyecto, y que han servido de base en su desarrollo. Los requisitos funcionales del proyecto son:  RF-1: La aplicación debe poder trabajar utilizando reconocimiento y síntesis de voz.  RF-2: La aplicación deberá permitir una comunicación fluida y natural con el usuario.  RF-3: El idioma de comunicación deberá ser el español.  RF-4: El sistema deberá recordar datos de anteriores consultas para ofrecer una mejor comunicación con el usuario.  RF-5: Se permitirá la integración de nuevas funcionalidades de forma fácil y rápida.  RF-6: La aplicación deberá ser multiplataforma.  RF-7: La aplicación podrá guardar información sobre las consultas realizadas, con el fin de mejorar la interacción natural del usuario.  RF-8: Se integrará un módulo de visualización 3D para agentes realistas ya existente. Y los requisitos no funcionales que deben cumplirse en el proyecto son:  RNF-1: El usuario podrá solicitar la información que desee a través del habla o interaccionando directamente sobre la interfaz a través de ratón.  RNF-2: En el caso de interaccionar mediante voz, el usuario podrá formular las consultas de forma natural. Análisis del proyecto 51  RNF-3: Se deberá utilizar Loquendo ASR como reconocedor de voz, al igual que Loquendo TTS para la síntesis de voz.  RNF-4: La información dirigida al usuario será entregada de forma visual y/o auditiva, es decir, se le mostrará por pantalla y/o mediante síntesis de voz.  RNF-5: La información que obtenga la aplicación y que se muestre al usuario deberá recibirse a través de Internet.  RNF-6: En caso de que no se pueda obtener alguna información, sólo se permitirá recogerla de forma local si esa información procede del Sistema Operativo donde se está ejecutando la aplicación.  RNF-7: El contenido de los artículos de los temas científico-mecánicos predefinidos disponibles podrá ser leído, y será de fácil acceso al usuario. A.2. Casos de uso Los casos de uso que se pueden observar en la figura A.1 representan a un usuario interactuando sobre la interfaz con el fin de obtener la información que solicite. Como se puede observar el escenario expuesto es muy genérico, debido a que las funcionalidades referentes a las Web APIs pueden verse extendidas en cualquier momento, aunque todas ellas seguirían el mismo patrón de solicitudes. Usuario Solicitar artículos de un tema Actuar sobre un artículo Solicitar información Web APIs «uses» «uses» «uses» «uses» Actuar sobre elemento de Web API Interfaz Fig. A.1. Casos de uso de un usuario sobre la interfaz. Las funcionalidades que se representan en este esquema de casos de uso se dividen en dos temáticas principalmente: la primera hace referencia a las solicitudes al Sistema de consulta semántica con acceso a la DBpedia donde el usuario puede solicitar los artículos relacionados con un cierto tema y actuar sobre esos artículos resultantes, ya sea para leerlos o abrirlos en la web; la segunda hace referencia a las consultas de las Casos de uso 52 Web APIs donde puede solicitar la información y, en algunos casos como el de la música, puede actuar sobre los elementos devueltos. A.3. Modelo de objetos A continuación se va a detallar la estructura estática del sistema, mostrando los objetos del mismo, sus atributos y métodos más relevantes, y las relaciones entre los objetos. En la figura A.2 se puede observar el diagrama de clases empleado: Main Agente 3DMyThreadASR Respondedor LoquendoTTS MyASR MyAudioSource WebApisXML SimulaDBpedia ParserXML ParserXMLDBpedia ParserXMLMusic ParserXMLNews ParserXMLWeather ParserXMLTime Visemas ParserXMLIP Analizador_L_S Fig. A.2. Esquema de clases utilizado. La clase Analizador_L_S de la figura A.2 hace referencia al conjunto de clases autogeneradas por los programas JFlex y CUP, empleados en la creación de los analizadores léxico y sintáctico necesarios para obtener los visemas asociados a las transcripciones fonéticas de la síntesis de voz. A.3.1. Clase MyThreadASR Extiende la funcionalidad de la clase Thread. Es la encargada de mantener el reconocedor de voz en un hilo de ejecución paralelo al resto de la aplicación, consiguiendo así que el reconocimiento de voz sea continuo aun estando en ejecución cualquier otro módulo, como la síntesis de voz. run(): Método de ejecución del Thread. Mantiene en un bucle la ejecución del reconocedor de voz, recogiendo la información que el usuario pronuncia por el micrófono. Se encarga de llamar a los métodos necesarios para que el reconocedor recargue la gramática y, de este modo, poder ampliar su funcionalidad. Cuando obtiene algún dato del reconocedor, invoca al método whatSaid() para su análisis. whatSaid(): Este método se encarga de analizar el tipo de consulta recogida por el reconocedor de voz e invocar a los métodos del respondedor que ofrecen una respuesta acorde a la consulta realizada. Este método también se encarga de detener Análisis del proyecto 53 la síntesis de voz en el caso de que el reconocimiento haya tenido éxito y, de este modo ofrecer al usuario una respuesta rápida a su consulta. A.3.2. Clase MyASR Es la clase encargada del reconocimiento de la voz. En el constructor se inicializa y configura Loquendo ASR, se definen los directorios donde se guardarán los datos reconocidos, se carga la gramática que utilizará Loquendo ASR para su funcionamiento, y se solicita la apertura del micrófono. aszLanguageList: Atributo que contiene el conjunto de idiomas instalados de Loquendo ASR. oASR: Instancia de Loquendo ASR. oInstance: Instancia de objetos internos de ASR, que permite la asignación de la gramática a utilizar, entre otros aspectos. Con este atributo se tienen acceso a las hipótesis e interpretaciones semánticas obtenidas en el reconocimiento de voz. resetGrammar(): Se encarga de recargar la gramática. Sólo es necesario indicarle el fichero principal de la gramática, ya que Loquendo ASR lo analiza y crea las reglas de reconocimiento con las referencias a los ficheros instanciados en este documento. recognition(): inicia el reconocimiento de Loquendo ASR, quedándose en espera hasta que le es devuelto un listado de hipótesis, es decir, frases que mejor se adaptan a lo que el orador ha dicho. Una vez obtenidas las hipótesis, descarta aquellas que no superan cierto valor de confianza [DAVANPFC], y de las válidas se obtiene sus interpretaciones semánticas, devolviéndolas al método que lo invocó como un listado de palabras. NLPResults(): Dada una hipótesis, se encarga de recorrer su árbol de interpretaciones semánticas, analizando cada una de esas interpretaciones a través del método NLPInterpretation(). Una vez recorridas todas las interpretaciones, devuelve un listado de listados de palabras. NLPInterpretation(): Dada una interpretación, comienza el análisis del árbol de objetos que la componen. El análisis de esos objetos se lleva a cabo en NLPElement(). NLPElement(): Método recursivo que analiza cada nodo que compone el árbol de una interpretación. En el caso de que el nodo sea un nodo final, guarda el tipo y el valor del dato que representa, mientras que si es un nodo intermedio se invoca de forma recursiva para analizarlo y obtener un listado de tipo-valor de cada uno de los nodos finales que cuelgan de dicho nodo intermedio. Modelo de objetos 54 releaseAll(): elimina la instancia del reconocedor de voz y de todos los elementos necesarios para su funcionamiento. A.3.3. Clase MyAudioSource Clase encargada de la configuración del dispositivo de entrada de audio (micrófono) de su apertura, cierre y obtención de datos. En esta clase se definen los valores de codificación del sonido entrante, y el tamaño del buffer donde se irán almacenando los datos que el orador vaya pronunciando y que será leído por Loquendo ASR para su reconocimiento. Start(): Método encargado de activar la tarjeta de sonido, iniciar el buffer de datos de entrada y esperar a que se captura algún sonido para su posterior análisis. Stop(): Método que indica cuando se deja de reconocer el sonido de entrada. Close(): Cierra la conexión con la tarjeta de sonido. GetSampleBuffer(): Se encarga de capturar los datos del buffer de la tarjeta de sonido y los almacena en el buffer de datos de entrada. A.3.4. Clase Respondedor En esta clase se almacenan los datos de consultas anteriores que son necesarios en caso de que el usuario no dé al sistema toda la información que se necesita para ofrecerle una respuesta exacta a su consulta. Es aquí también, donde se obtienen los datos de las Web APIs invisibles al usuario que permiten una geo-localización del ordenador donde se está ejecutando la aplicación. Además en esta clase se inicializan los parsers para analizar los datos devueltos por todas las Web y se dispone de los métodos específicos para cada una de las posibles consultas, que devuelven el texto de respuesta que se sintetizará después e invocan a los métodos de la interfaz para mostrar los datos requeridos. respuestaSaludo(): Método específico para responder en caso de que el usuario haya saludado. respuestaDespedida(): Método específico para el caso en que el usuario se haya despedido de la aplicación. respuestaRepetir(): Método específico que solicita repetir la consulta. Se utiliza cuando el reconocedor de voz no ha obtenido una hipótesis válida. respuestaMusic(): Método específico para una solicitud de elementos musicales. Se encarga de hacer manejar la reproducción de la música, obtener los datos de las Web Análisis del proyecto 55 API de música utilizadas en la aplicación, y permite la apertura de la página web de una canción concreta. respuestaNews(): Método específico para solicitudes de noticias. Analiza qué tipo de noticia solicita el usuario para devolverle la información obtenida de los servicios RSS utilizados. respuestaTime(): Método específico para consultas sobre la hora o la fecha. respuestaWeather(): Método específico para consultas sobre el tiempo atmosférico. Este método se encarga de analizar la falta de datos necesarios para poder realizar las consultas a la Web API especializada en pronósticos atmosféricos. respuestaDBpedia(): Método específico para consultas sobre temas o artículos procedentes de la DBpedia. Este método diferencia cuando se le consulta por un tema o temas para obtener los artículos, de cuando se le solicita leer un artículo o abrirlo. abrirURL(): Método que permite abrir sobre cualquier Sistema Operativo una página web en el buscador. buscarImagenes(): Método que, dado el texto de un artículo obtenido del Sistema de consulta semántica con acceso a la DBpedia, busca referencias a imágenes. obtenerURLImagenes(): Método que, dado el nombre de una imagen, busca su dirección URI en Wikipedia. A.3.5. Clase WebApisXML Contiene los métodos que conectan con las Web APIs y obtienen los datos en formato XML. En el caso de que estos servicios devuelvan un XML sin datos, estos métodos devuelven datos nulos al método que los invocó, para indicar que la información solicitada no se encuentra disponible. getIP(): Método que conecta con la Web API que devuelve la dirección IP visible desde el exterior, en caso de que el sistema no pueda obtener una dirección IP pública. getLocation_of_IP(): Método que, dada una dirección IP, conecta con la Web API que devuelve la localización geográfica de dicha IP. getWeather(): Método sobrecargado, que permite obtener la información meteorológica de un lugar a partir de una dirección IP, o a partir del nombre de una ciudad y su país. getRSS(): Método que conecta con los servicios RSS predefinidos para obtener un XML con las noticias de actualidad. Modelo de objetos 56 getSongsMusic(): Método que, dado un estilo de música, obtiene el listado de canciones más escuchadas en la actualidad. getMusicArtist(): Método que, dado el nombre de un artista, obtiene un listado de canciones relacionadas con él. A.3.6. Clase ParserXML Esta clase es la clase de referencia para todos los parsers implementados, ya que es de ésta de donde extienden sus funcionalidades. Debido a esto, se van a explicar los métodos generales a todos los parsers sin especificar las extensiones, ya que éstas son métodos que permiten obtener datos muy concretos del propio parser. dom: Objeto Document que permite la extracción de datos de un documento XML. runParser(): Método general que inicializa los sistemas de memoria interna concretos de cada parser, invoca al método parseXmlFile() y permite generar gramáticas en tiempo de ejecución. parseXmlFile(): Dado un texto en formato XML, asocia el texto con el objeto dom. parseDocument(): Método que almacena en memoria los datos obtenidos del XML. getTextValue(): Método que permite obtener de un tag del XML, los atributos que lo caracterizan y el dato al que hacen referencia. crearGram(): Método que genera un fichero .gram con formato ABNF, donde se almacenan los datos que podrán ser reconocidos por Loquendo ASR en las siguientes iteraciones. A.3.7. Clase LoquendoTTS Esta clase instancia al sintetizador de voz utilizado, en este caso Loquendo TTS. En el constructor se cargan las voces que se encuentran instaladas y el idioma en que debe trabajar. isSilence(): Indica si Loquendo TTS se encuentra en ese momento sintetizando algún texto. setSilence(): Fuerza a Loquendo TTS a dejar de sintetizar. read(): Este es el método principal de síntesis de voz, ya que es en éste donde se le ordena a Loquendo TTS que sintetice de forma asíncrona un texto dado como entrada, y donde se obtiene la transcripción fonética de dicho texto y el listado de códigos de los visemas que se utilizarán en la sincronización labial con el agente 3D. Análisis del proyecto 57 getPhonetic(): Este método invoca al método phoneticTranscription() de Loquendo TTS con el que se obtiene la transcripción fonética de una frase dada. Ya que la transcripción no incluye los signos de puntuación que determinan la duración de una frase ni las pausas intermedias, en el método getPhonetic() se procesan la frase original y la transcripción y en esta última se insertan los códigos que identifican a los signos de puntuación existentes en la frase original. A.3.8. Clase Visemas Esta clase sirve de enlace entre el sintetizador de voz y el analizador léxico y sintáctico de fonemas. getVisemas(): Dada la cadena con la transcripción fonética de una frase, este método instancia al analizador léxico y lo asocia con la transcripción fonética; e instancia al analizador sintáctico y lo asocia con el analizador léxico anterior. De este modo el resultado que devuelve el analizador sintáctico es el conjunto de códigos de visemas que hacen referencia a cada uno de los símbolos fonéticos de la entrada. A.3.9. Clase Main En esta clase es donde se encuentran todos los métodos relacionados con la creación y modificación de elementos de la interfaz. A continuación se detallan los atributos y métodos más relevantes que permiten la integración de nuevas funcionalidades o extender las ya existentes, o que merecen un momento de interés: temas: contiene un listado con los temas disponibles para mostrar en la pestaña de Alfa III GAVIOTA. herramientas: contiene el listado de herramientas Web API disponibles. estilosMusica: contiene el listado de estilos de música sobre los que el usuario puede solicitar las canciones más escuchadas. crearInterfazGral(): Con este método se inicializan los componentes principales de la interfaz, como el panel que sirve de base para el resto de componentes, el contenedor de pestañas donde van los controles de interacción con el usuario, el panel base donde se integra el agente 3D, el panel base donde se añaden otros paneles que contienen la información estática que se quiere mostrar al usuario, y el panel donde se muestran a las entidades colaboradores de este proyecto. crearPestanaHerramientas(): En este método se inicializan los elementos que se encuentran contenidos en la pestaña de herramientas con acceso a las Web APIs. mostrarCargaCanciones(): Método que sirve para indicar al usuario que el sistema está trabajando en la solicitud de obtención de las canciones. Modelo de objetos 58 stopMP3(): Método que permite detener la reproducción de una canción, y devolver al botón de dicha canción a su estado original de espera. iniciarLoquendo_TTS_ASR(): Instancia un objeto de TTS y otro de MyThreadASR. A.3.10. Clase Agente3D Esta clase corresponde al módulo de generación del agente 3D, y se utiliza para incluirlo en la interfaz y simular el habla del agente. Es una clase desarrollada de forma ajena a este proyecto, de la que se utilizan los siguientes métodos: init(): inicia el proceso de carga de los componentes del agente, y comienza a ejecutar los métodos internos de la clase para simular el movimiento natural y aleatorio del agente, como movimientos de cabeza o párpados, entre otros. getCanvas(): Obtiene el canvas del agente, para así poder introducirlo en la interfaz. emocion(): Método que hace al agente expresar una emoción dada como entrada. spk(): Método que, dándole como entrada los códigos de los visemas que debe interpretar, se encarga de realizar el movimiento labial asociado a esos visemas. callar(): Método que detienen el movimiento labial de simulación del habla. A.4. Modelo dinámico En este apartado se detallan los aspectos de control del sistema que describen las operaciones y el orden en que se llevan a cabo, en respuesta a estímulos externos. Para ello se va a explicar en primer lugar el conjunto de eventos que se transmiten entre los distintos módulos o clases que componen esta aplicación, utilizando para ello dos diagramas de flujo de eventos de dos situaciones posibles; y en segundo lugar se detallará la transición de estados por los que pasará la aplicación desde la formulación de una consulta o solicitud hasta la respuesta devuelta al usuario, utilizando para ello un diagrama de estados. A.4.1. Diagrama de flujo de eventos Debido a la multitud de casos que se pueden dar al interaccionar con la aplicación, se van a mostrar dos situaciones distintas con resultados distintos. El primer caso corresponde al representado en la figura A.3, donde un usuario saluda a la aplicación y ésta le responde, mientras que el segundo caso representado en la figura A.4 corresponde a una solicitud por parte del usuario de un conjunto de artículos con referencias a unos temas elegidos. Análisis del proyecto 59 Usuario saluda a la aplicación Fig. A.3. Diagrama de eventos cuando un usuario saluda. En primer lugar el objeto MyAudioSource indica a MyASR que ya está preparado para recibir datos de audio, por lo que comienza la espera de esos datos de entrada con el método recog(). Cuando el usuario emite el saludo, MyAudioSource lo recoge y lo envía a la instancia de objetos internos de Loquendo ASR (ASRInstance) para su análisis. Una vez terminado envía los resultados a MyASR y éste a MyThreadASR para reconocer qué es lo que el usuario ha dicho. Condicionados por estos resultados, es aquí cuando pueden emitirse dos eventos distintos. Si el resultado devuelto a MyThreadASR es válido, éste enviará un evento a Respondedor para que responda en consecuencia con la petición, en este caso saludo. Respondedor emitirá la orden al TTS para que sintetice una frase de saludo y éste enviará al módulo del agente 3D el conjunto de códigos de visemas para la sincronización labial, y al usuario la síntesis del saludo. Modelo funcional 66 La figura A.12 muestra la especificación del subproceso 3.1 encargado de la conversión de texto a audio. Este subproceso se compone de un subproceso encargado de la síntesis de voz y de su envío al usuario (3.1.1), y de un subproceso que genera los visemas a partir de la interpretación fonética del texto (3.1.2). Datos a devolver (texto a leer) Voz sintética Módulo Agente 3D Usuario 2 Respondedor 3.1.1 Sintetizador de voz 3.1.2 Generador códigos visemas Interpretación fonética del texto Listado de códigos X-SAMPA Fig. A.12. DFD de nivel 3. Especificación del subproceso 3.1: Conversión texto-audio. A.6. Prototipado de pantallas A continuación se van a mostrar algunos de los prototipos de pantallas que se habían planteado para mostrar la información al usuario. Respecto a las solicitudes de artículos de los temas científico-mecánico disponibles, como se puede observar en la figura A.13, en un primer momento se planteó la posibilidad de consultar sobre un único tema, de ahí el sistema de selección unitaria de los temas mostrado en la figura de la izquierda (1). En vista de que el Sistema de consulta semántica permitía búsquedas por varios temas se cambió a un sistema de selección múltiple (2). Alfa III Gaviota Otras herramientasWikipedia Artículo1 Artículo2 Artículo3 Artículo4 Artículo5 (Texto a leer) Tema1 Tema2 Tema3 Tema4 Tema5 Leer Web Leer Web Leer Web Leer Web Leer Web Alfa III Gaviota Otras herramientasWikipedia Artículo1 Artículo2 Artículo3 Artículo4 Artículo5 Tema1 Tema2 Tema3 Tema4 Tema5 Seleccionar tema Leer Web Leer Web Leer Web Leer Web Leer Web Fig. A.13. Prototipos de pantallas para el servicio de consulta de artículos científico-mecánicos. 1 2 3 Análisis del proyecto 67 El Sistema de consulta semántica con acceso a la DBpedia devuelve el texto contenido en los artículos buscados, por ello se planteó la posibilidad de mostrarlo en la interfaz. Con el fin de fomentar la finalidad multimodal de la aplicación, y en vista de que el texto recibido puede contener también referencias a imágenes, se decidió cambiar la interfaz y ofrecer al usuario la información textual mediante síntesis de voz y mostrarle las imágenes obtenidas en la interfaz (3). Respecto a la información obtenida de los servicios Web API utilizados, se van a exponer los prototipos de pantallas planteados para los servicios de tiempo atmosférico y noticias, ya que son éstos los que han sufrido cambios significativos respecto de los prototipos iniciales. Alfa III Gaviota Otras herramientasWikipedia Tiempo atmosférico Ahora Hoy Mañana Pasado El 4º día El 5º día Ciudad Fig. A.14. Prototipo de pantalla para la funcionalidad de tiempo meteorológico. Para el servicio de tiempo atmosférico se planteó desarrollar la interfaz según el prototipo de la figura A.14. Ya que este modelo permitía mantener las proporciones de la interfaz desarrollada para el servicio de consultas a temas científico-mecánicos, se decidió desarrollarlo. Con el fin de conservar las regiones de control y visualización de resultados, se decidió mostrar los resultados en la región donde se exponen las imágenes de los artículos de Wikipedia y para ello se planteó el modelo de la figura A.15-izquierda, donde se muestran los resultados de tres días. En vista de que el servicio Web API utilizado ofrecía la información de cinco días vista y del momento actual, y con el fin de ofrecer más posibilidades de consulta al usuario se planteó el modelo final (figura A.15-derecha) donde se muestra sólo la información del día exacto solicitado con más datos de interés. Fig. A.15. Prototipos para mostrar los datos del tiempo meteorológico. Prototipado de pantallas 68 Respecto al servicio de noticias se plantearon los prototipos de la figura A.16, que mantenían la estructura de diseño de la interfaz con la región de controles en el lado izquierdo. En vista de que los titulares y los textos de las noticias pueden ser muy extensos y el número de noticias puede ser muy alto, se decidió conservar el sistema de selección de noticias (izquierda), y mostrar todas las noticias disponibles en una ventana aparte (figura A.17). Alfa III Gaviota Otras herramientasWikipedia Noticias Generales Economía Ciencia - Tecnología Cultura Deportes Alfa III Gaviota Otras herramientasWikipedia Noticias Texto de noticia Ddadafafafksaflasjfl Titular 1 Ver noticia Texto de noticia Ddadafafafksaflasjfl Titular 2 Ver noticia Texto de noticia Ddadafafafksaflasjfl Titular 3 Ver noticia Texto de noticia Ddadafafafksaflasjfl Titular 4 Ver noticia Fig. A.16. Prototipos de selección de noticias (izquierda) y visualización de titulares (derecha). Noticias – Ciencia y tecnología Fuente: www.www.es Texto de noticia Ddadafafafksaflasjfl Saslfkjasñf Titular 1 Ver noticia Texto de noticia Ddadafafafksaflasjfl Saslfkjasñf Titular 2 Ver noticia Texto de noticia Ddadafafafksaflasjfl Saslfkjasñf Titular 3 Ver noticia Texto de noticia Ddadafafafksaflasjfl Saslfkjasñf Titular 4 Ver noticia Texto de noticia Ddadafafafksaflasjfl Saslfkjasñf Ver noticia Titular 5 Fig. A.17. Prototipo de la ventana de visualización de noticias. 69 Anexo B: Diseño del proyecto En este apartado se detalla la fase de diseño realizada para este proyecto, cuyos objetivos son obtener la estructura modular y los detalles del sistema a partir de la fase de análisis explicada en el anexo A, y obtener un diseño que permita mejorar la reutilización y se pueda probar y entender fácilmente. Para explicar esta fase se ha desarrollado un Diagrama de Estructura de Cuadrados (DEC), que permite determinar qué módulos implementarán los procesos obtenidos en la fase de análisis del proyecto, organizar la estructura de estos módulos y definir las conexiones entre los mismos. En la figura B.1 se puede observar el diagrama de estructura de cuadrados del proyecto donde se muestran los tres procesos definidos en el nivel 1 del Diagrama de Flujo de Datos del análisis. Cuando el módulo de Interfaz de entrada recibe datos del usuario, el tipo y los datos de la consulta son enviados al sistema junto con un flag que indica si la consulta ha sido válida. De esta manera el sistema puede tomar decisiones en base a estos datos recibidos. Sistema Interfaz entrada consulta válida Tipo consulta Generador respuestas Tipo consulta Datos consulta Datos consulta Interfaz salida Datos a mostrar Texto a decir silenciar Datos a mostrar Texto a decir Fig. B.1. DEC del proyecto con los módulos principales. La figura B.2 representa el DEC específico del módulo Interfaz de entrada, donde se pueden ver los módulos de reconocimiento de voz y reconocimiento de dispositivos de entrada convencionales. El módulo de reconocimiento de voz se encuentra conectado con el dispositivo físico (Micrófono) que le envía el flag indicándole que tiene datos disponibles para ser procesados, junto con esos datos. Al mismo tiempo obtiene de la gramática el conjunto de tokens y reglas que le ayudan en el reconocimiento de palabras, y junto con los datos del micrófono se los envía a un módulo predefinido que devuelve al reconocedor de voz los resultados del reconocimiento. Una vez que el Diseño del proyecto 70 reconocedor de voz obtiene estos resultados, devuelve a la Interfaz de entrada la interpretación reconocida. El módulo de reconocimiento de periféricos convencionales se comunica con los dispositivos externos, en este caso el ratón, y con la ayuda del módulo predefinido de eventos de la interfaz WIMP obtiene los elementos de consulta que han sido seleccionados. Interfaz entrada Reconocedor de voz Reconocedor periféricos convencionales Micrófono Gramática ABNF Sistema interno Loquendo ASR Recepción de audio tokensreglas tokens reglas audio Resultado reconocimiento Interpretación reconocida Interfaz WIMP Ratón Consulta (tipo y datos) posición click posición Datos seleccionados audio Fig. B.2. DEC del módulo Interfaz de entrada. Cuando el módulo Interfaz de entrada envía los datos de la consulta al sistema, éste los redirige al Generador de respuestas, que a su vez los redirige al módulo de Extracción de datos para almacenar en memoria los datos útiles para futuras consultas y obtener los datos que el usuario no ha definido en su consulta. Cuando ya se tienen los datos suficientes para atender la solicitud, se le envían al módulo de Obtención de información Web, que se comunica con los Servicios Web externos y les envía los datos de la solicitud como parámetros. Estos servicios externos responden con datos en forma de hipertexto que se redirige al módulo Parser XML, cuya función es comunicarse con el almacén de datos extraídos de las respuestas de los Servicios Web para insertarlos, siempre y cuando los datos no se encuentren ya insertados. Del mismo modo se comunica con la gramática para insertarle los nuevos datos y así ser reconocibles a través del reconocimiento de la voz. Este proceso se encuentra reflejado en la figura B.3. Diseño del proyecto 71 Generador respuestas Extracción datos Tipo consulta Datos consulta Memoria interna de consultas Datos nuevos Datos necesitados Datos solicitados Datos suficientes Obtención información Web Parser XML Datos suficientes Servicio Web (S.C.S. ó Web API) Parámetros de búsqueda XML XML XML Datos obtenidos Memoria interna de datos Datos extraidos Datos anteriores Ya existe Gramática ABNF Datos para reconocer Fig. B.3. DEC del módulo Generador de respuestas. Una vez que el Parser se ha comunicado con la memoria interna de datos y con la gramática, devuelve al Sistema los datos obtenidos que los redirige a la Interfaz de salida para ser mostrados al usuario, como se puede observar en la figura B.4. Llegados a este punto se diferencian los datos que deben ser integrados en la interfaz utilizando el módulo Generador Interfaz-WIMP, de los que deben ser sintetizados a través del módulo Conversión Texto – Voz. En el caso de que el sistema deba detener la síntesis de voz, también se le envía el flag de silencio. Conversión texto – audio Interfaz salida Generador Interfaz WIMP Interfaz WIMP Sintetizador de voz Loquendo TTS Generador códigos visemas Módulo Agente 3D Datos a mostrar Datos a mostrar Componentes nuevos Texto a decir silenciar Frase a sintetizar Lista de fonemas Lista de fonemas Códigos de visemas Códigos de visemas Fig. B.4. DEC del módulo Interfaz salida. Cuando el conversor de texto a audio recibe datos para sintetizar, se comunica con el sintetizador de voz de Loquendo TTS para que los lea. Mientras esto ocurre, el sintetizador devuelve al módulo superior el conjunto de fonemas que representan cada una de las frases que tiene que sintetizar, que son redirigidas al Generador de códigos de visemas para obtener la secuencia de códigos que serán enviados al módulo del Agente 3D para conseguir la sincronización labial del agente. Diseño del proyecto 72 Como se puede observar en la figura B.4, la ejecución de los subprocesos del módulo Conversión texto-audio se encuentra en un bucle condicionado por el flag silenciar enviado desde la interfaz de salida, ya que cuando se reciba se debe detener la síntesis de voz y hacer que el agente 3D se detenga. En la figura B.5 se puede observar el diagrama de estructura de cuadrados completo del proyecto. Conversión texto – audio Sistema Interfaz entrada Reconocedor de voz Reconocedor periféricos convencionales Micrófono Gramática ABNF Sistema interno Loquendo ASR Recepción de audio tokensreglas tokens reglas audio Resultado reconocimiento Interpretación reconocida Interfaz WIMP Ratón Consulta (tipo y datos) posición click posición Datos seleccionados consulta válida Tipo consulta audio Generador respuestas Extracción datos Tipo consulta Datos consulta Tipo consulta Datos consulta Memoria interna de consultas Datos nuevos Datos necesitados Datos solicitados Datos suficientes Obtención información Web Datos consulta Parser XML Datos suficientes Servicio Web (S.C.S. ó Web API) Parámetros de búsqueda XML XML XML Datos obtenidos Memoria interna de datos Datos extraidos Datos anteriores Ya existe Datos obtenidos Interfaz salida Generador Interfaz WIMP Interfaz WIMP Sintetizador de voz Loquendo TTS Generador códigos visemas Módulo Agente 3D Gramática ABNF Datos para reconocer Datos a mostrar Texto a decir Datos a mostrar Datos a mostrar Componentes nuevos silenciar Texto a decir silenciar Frase a sintetizar Lista de fonemas Lista de fonemas Códigos de visemas Códigos de visemas Fig. B.5. Diagrama de Estructura de Cuadrados completo de la fase de diseño del proyecto. 74 75 Anexo C: Reconocedor de voz. Loquendo ASR En este anexo se explica el reconocedor de voz utilizado en el proyecto, cómo se instancia y se configura para comenzar a funcionar, y las clases y métodos que se utilizan para obtener finalmente la semántica de una consulta. Contenido C.1. Instanciación y configuración iniciales .................................................... 76 C.1.1. Configuración de Loquendo ASR ...................................................................... 76 C.1.2. Inicialización ..................................................................................................... 76 C.2. Reconocimiento del audio...................................................................... 77 Para hacer que el sistema pueda reconocer solicitudes de los usuarios a través del habla es necesaria una herramienta de reconocimiento de voz, que interprete las palabras pronunciadas por el orador y devuelva de algún modo el significado semántico de la solicitud. A estas herramientas se las conoce como herramientas de Reconocimiento Automático del Habla (RAH), o en inglés Automatic Speech Recognition (ASR), y permiten la comunicación hablada entre personas y ordenadores. Estas herramientas son capaces de procesar la señal de voz emitida por el usuario, reconocer la información contenida en ésta, convertirla en texto, y además traducirla, es decir, obtener el significado semántico del original. Entre los múltiples reconocedores de voz disponibles en el mercado, para este proyecto se ha utilizado la herramienta de Loquendo ya que era uno de los requisitos previos del proyecto. Loquendo ASR es un software propietario de reconocimiento de voz de última generación para aplicaciones vocales, que ofrece completa independencia de la identidad del hablante y robustez frente al ruido exterior, entre otras muchas características. A continuación se va a proceder a explicar la instanciación y configuración inicial de las clases necesarias para la utilización de este software, el proceso de reconocimiento de la señal de voz del usuario, la actualización de los mecanismos de reconocimiento que permiten extender el conjunto de frases reconocibles, y la forma de ejecución del reconocedor en el proyecto multimodal actual. Sintaxis y semántica en gramáticas ABNF 82  Idioma: La declaración del idioma consiste en el identificador del idioma y seguido opcionalmente del código identificativo del país. Esta declaración indica el idioma principal que se va a utilizar a lo largo del documento, y es requerida por cualquier reconocedor de voz basado en gramáticas. En este caso será el español (es-ES) ya que es el idioma instalado con Loquendo ASR.  Modo: Indica el tipo de entrada que el usuario va a utilizar y por lo que la gramática va a ser utilizada, en esta caso voz (voice). Este atributo indica cómo interpretar los tokens de la gramática, esto es, las palabras pronunciadas en la entrada serán detectados por su parecido con la traducción en audio del token.  Formato de etiqueta: Esta declaración indica el formato en que se encuentran las etiquetas de representación semántica de la gramática. En este caso, como se sigue el estándar SISR [W3CSISR], se utiliza la declaración ’<semantics/1.0>’.  Regla raíz: Indica cuál es la producción que da comienzo al conjunto de reglas definidas en la gramática. #ABNF 1.0 UTF-8; language es-ES; mode voice; tag-format <semantics/1.0>; root $root; Después de definir las características de la gramática en la cabecera, se encuentran el conjunto de producciones o reglas que indican qué es lo que se va a reconocer. Una regla se compone de un elemento que define el nombre de la producción, seguido del carácter ‘=’, seguido de combinaciones de otros tokens o referencias a otras reglas dispuestos por agrupaciones, alternativas, agrupaciones opcionales o combinaciones de éstas. A continuación se detallan cómo se definen la identificación de una regla, las referencias a otras, y el cuerpo de una regla. Identificación de una regla La identificación de una regla se compone del carácter ‘$’ seguido de una cadena de texto que será su identificador. Antes del identificador se puede definir la visibilidad de la regla para que sea accesible sólo desde la gramática en el que se encuentra (private), o accesible desde otras gramáticas (public): public $saludo = ...; private $preguntas = ...; Gramática ABNF 83 Referencia a una regla La referencia a una regla, ya sea de la gramática actual o de una gramática definida en otro documento, se compone del símbolo ‘$’, seguido del nombre de la regla. Para hacer referencias a reglas contenidas en gramáticas externas, es necesario indicar la URI de la gramática, seguido del carácter ‘#’ y del nombre de la regla referida: Referencia local  $rulename Referencia externa  $<gramaticaURI#rulename> En el apartado D.1.3 se puede ver un ejemplo de una gramática ABNF en el que se incluyen referencias locales y referencias a reglas de gramáticas externas. Cuerpo de una regla El cuerpo de una regla está formado por tokens y/o referencias a reglas, dispuestos las siguientes formas:  Secuencia - de tokens: $local = me encuentro en Zaragoza; - de tokens y referencias: $weather = que tiempo va a hacer $lugar  Alternativa Se utiliza el carácter ‘|’ para definir las alternativas en una misma regla. $saludo = buenos días | buenas tardes | buenas noches ;  Agrupaciones Cualquier expresión puede ser agrupada utilizando paréntesis. Éstas tienen mayor precedencia que las secuencias y ofrecen la posibilidad de utilizar una misma regla para tener varias posibilidades de interpretación, pero al menos una de esas posibilidades tiene que estar presente. En el siguiente ejemplo, la regla “saludo” permite distintas interpretaciones: ‘mi nombre es Pepe’, ‘me llamo Pepe’ y ‘soy Pepe’: $saludo = (mi nombre es | me llamo | soy) Pepe;  Agrupación opcional Para definir que una producción pueda tener elementos opcionales se utilizan los corchetes. Con esto se permite que una misma regla pueda Sintaxis y semántica en gramáticas ABNF 84 tener varias posibilidades de interpretación, sin necesidad de que lo que se encuentra entre corchetes se encuentre presente. En el siguiente ejemplo, la regla “preg_hora” permite las interpretaciones ‘que hora es’ y ‘me puede decir que hora es’: $preg_hora = [me puede decir] que hora es; En el lenguaje ABNF, hay disponibles un conjunto de reglas especiales que tienen una interpretación específica para los reconocedores de voz. Estas reglas son sintácticamente idénticas a la referencia a una regla, y su identificación se encuentra bloqueada para que no existan en la gramática otras reglas con los mismos nombres. Estas reglas especiales son: $NULL: Hace que una regla sea automáticamente asociada, es decir, se asocia sin que el usuario haga referencia a esa regla. $VOID: Hace a una regla completamente irreconocible, es decir, la existencia de ésta en cualquier regla hace que esa regla sea invisible para el reconocedor. $GARBAGE: Esta regla es muy útil cuando se quiere reconocer cualquier palabra sin haberse definido en la regla. En el siguiente diagrama se puede ver un caso de uso de esta regla, donde únicamente se reconoce la palabra ‘fricción’, haciendo caso omiso al resto de palabras que lo acompañan: Fig. D.1. Gráfico explicativo del funcionamiento de la regla $GARBAGE. D.1.2. Semántica en gramáticas ABNF Conocer la secuencia de palabras introducidas no suele ser el modo más práctico de manejar la información introducida por el usuario. Lo que se necesita es una representación de la información procesable por el ordenado, es decir, la semántica de la información. En una gramática ABNF la semántica se especifica en las etiquetas o tags. Una tag se encierra entre llaves o en las secuencias de tres caracteres ' { ! { ' y ' } ! } ': Gramática ABNF 85 {tag-content} {!{ tag-content}!} Durante el proceso de interpretación semántica, los valores semánticos pueden ser asignados a las variables asociadas a las reglas de la gramática. Estas variables se denominan Variables de regla. Todas las reglas que componen una gramática tienen una única Variable de regla, pudiendo ser evaluada y asignada, no solo dentro del tag donde se incluye, sino en referencias en otras reglas. La variable de regla se identifica por la palabra OUT, y se puede acceder a propiedades de ésta a través de identificadores de la siguiente manera: out (identifica la Variable de la regla) out.prop (identifica la propiedad prop de la Variable) La variable de regla se inicializa como un objeto vacío antes de ser ejecutada. El diseñador de la gramática puede añadir propiedades a ese objeto, o ignorarlo y asignarle un valor primitivo como números o cadenas, y, dado que la variable se inicializa antes de ser ejecutada, no es necesaria una declaración de variable previa. A continuación se muestran algunos ejemplos que explican qué tipo de objeto se consigue y su valor: // Objeto con la propiedad prop out.prop = "mi propiedad"; // String con el valor "value" out = "value"; // String con el valor "value" out.prop = "mi propiedad"; out = "value"; out = "value"; out.prop = " mi propiedad "; // String con el valor "ab" out.prop1 = "a"; out.prop2 = "b"; out = out.prop1 + out.prop2; // Objeto con la propiedad prop out = "value"; out = new Object(); out.prop = " mi propiedad "; Para acceder a los valores semánticos de las reglas referenciadas dentro de una regla, se utiliza el identificador ‘rules’, seguido del nombre de la regla referenciada (1). Si se desea acceder a alguna de las propiedades de esa regla, se añade el nombre de la propiedad a la referencia de la regla (2), es decir: public $root = $saludo {out.saludo = rules.saludo; (1) out.tipo = rules.saludo.tarde;} (2) Sintaxis y semántica en gramáticas ABNF 86 En el caso de necesitar acceder a gramáticas definidas en ficheros externos, referenciar a los valores semánticos de sus reglas se realiza como si éstas se encontrasen en el mismo fichero gramatical: private $subtema = $GARBAGE $<./mygrammardb.gram#grammardbpedia> $GARBAGE {out.db = 'subtema'; out.gr = rules.grammardbpedia;} ; D.1.3. Ejemplo de gramática ABNF A continuación se muestra un fragmento de la gramática utilizada en este proyecto que puede resultar útil para entender los conceptos definidos en los apartados anteriores de este anexo: #ABNF 1.0 UTF-8; language es-ES; mode voice; tag-format <semantics/1.0>; root $root; public $root = $saludo {out.tipo = 'saludo'; out.saludo = rules.saludo;} | [$saludo] $continuasaludo { out = rules.continuasaludo;} | $despedida {out.tipo = 'despedida'; out.despedida = rules.despedida;} ; public $saludo = (hola | buenas) {out = 'hola'} | buenos dias {out = 'saludoDias'} | buenas tardes {out = 'saludoTardes'} | buenas noches {out = 'saludoNoches'} ; private $despedida = (adios | hasta manana | hasta luego) {out = 'adios'} ; public $continuasaludo = [$amable] $directa { out.tipo = 'directa'; out.directa = rules.directa; } | [$formalduda] $duda { out.tipo = 'duda'; out.duda = rules.duda; } ; private $directa = $time {out.topic = 'time'; out.question = rules.time;} | $weather {out.topic = 'weather'; out.question = rules.weather;} | $debepedia $GARBAGE { out.topic = 'debepedia'; out.question = rules.debepedia; } | $subtema {out.topic = 'subtema'; out.question = rules.subtema;} Gramática ABNF 87 | $news {out.topic = 'noticias'; out.question = rules.news;} | $music {out.topic = 'musica'; out.question = rules.music;} ; private $subtema = $GARBAGE $<./mygrammardb.gram#grammardbpedia> $GARBAGE {out.db = 'subtema'; out.gr = rules.grammardbpedia;} ; private $debepedia = $GARBAGE $<./mygramtdb.gram#dbpedia> $debepedia {out.dbpedia = rules.dbpedia; out.debepedia = rules.debepedia;} | $GARBAGE $<./mygramtdb.gram#dbpedia> ; D.2. Nugram IDE Para realizar las pruebas de la gramática y entender el funcionamiento tanto de la gramática ABNF como de la obtención de la semántica con cada una de las posibles frases, se ha utilizado el plugin de desarrollo Nugram IDE [NUGRAM] para el programa de programación Eclipse [ECLIPSEWEB]. A continuación se explica el proceso de instalación del plugin y el modo de funcionamiento de la herramienta. Para poder utilizar el plugin es necesario tener instalado el programa de desarrollo Eclipse. Una vez obtenido hay que seguir los siguientes pasos para comenzar a utilizar el analizador de gramáticas ABNF: 1. Seleccionar en el menú superior: Help - Install New Software.... 2. Añadir la URL de Nugram indicada en la imagen en la ventana emergente que aparece al pulsar el botón Add…: Nugram IDE 88 3. Seleccionar: Select NuGram IDE Basic Edition. Pulsar el botón Next…. 4. Seguir las instrucciones de instalación y reiniciar Eclipse. 5. Para utilizar las funcionalidades del plugin es necesario cambiar la perspectiva de trabajo. Para ello hay que ir al menú Window – Open perspective – Other… y seleccionar Grammar Development: 6. Será necesario obtener la licencia de trabajo gratuita. Para ello hay que ir a la página de descarga del Nugram IDE Basic Edition [NUGDOWN] y pedir la licencia. Una vez solicitada hay que seleccionar el directorio donde se encuentra el fichero de licencia, para ello seleccionar el menú Preferences… y seleccionar la opción Licensing en Grammar Development: http://nugram.nuecho.com/update-site Gramática ABNF 89 7. A partir de aquí, sólo es necesario crear un nuevo proyecto simple y crear una gramática ABNF en español (es-ES): Una vez seguidos los pasos anteriores aparece una ventana de Eclipse similar a la que se muestra en la figura D.2: Fig. D.2. Interfaz de trabajo de Eclipse con el plugin de Nugram IDE. 1 1 1 2 1 3 1 4 Nugram IDE 90 Esta interfaz se divide en 4 áreas, la zona donde se define la gramática (figura D.2- 1), donde se pueden insertar frases de prueba (figura D.2-2), el área donde se puede observar el árbol sintáctico creado con la frase probada (figura D.2-3), y por último el área donde se obtiene el conjunto de datos semánticos de la frase (figura D.2-4). Las zonas 1 y 2 tienen características especiales que permiten probar frases y dejarlas registradas para, en caso de modificar la gramática, conseguir una batería de pruebas acumulativa. Para ello en la zona 2 se encuentra un botón que permite añadir una frase a la batería de pruebas (figura D.3), mientras que en la zona 1, en la pestaña inferior Coverage, el botón  permite ejecutar el conjunto de pruebas insertadas (figura D.4): Fig. D.3. Detalle de D.2-2. Añadir una frase a la batería de pruebas Fig. D.4. Detalle de la figura D.2-1. Reproducción de la batería de pruebas en la pestaña Coverage. Problemas encontrados en este programa El único problema encontrado en esta herramienta, confirmado por el servicio técnico de Nugram Server, es la interpretación de la regla especial $GARBAGE, ya que en vez de considerarla como un conjunto de tokens hablados indefinidos y que hay que desechar, en este herramienta se considera como una regla $NULL. Es decir, para poder simular por ejemplo la frase “Hola me puedes decir qué artículos tienes sobre la aerodinámica”, donde las palabras “qué artículos tienes sobre la” no se han insertado en la gramática, es necesario quitarlas de la frase, por lo que la frase final a probar será “Hola me puedes decir aerodinámica”. 91 Anexo E: Web APIs. Obtención de la información En este anexo se explica el conjunto de herramientas Web API utilizadas en este proyecto, los parseadores desarrollados para analizar y obtener los datos devueltos por estos servicios web y, en el caso de la funcionalidad musical, el sistema de búsqueda y almacenamiento implementados para mejorar la obtención de resultados. Contenido E.1. Los servicios Web utilizados ................................................................... 91 E.1.1. Pronóstico meteorológico ................................................................................ 91 E.1.2. Servicio de hora y fecha .................................................................................... 94 E.1.3. Servicio de noticias ........................................................................................... 95 E.1.4. Servicio de datos musicales .............................................................................. 96 E.1.5. IP pública y geo-localización ........................................................................... 100 E.2. Parsers XML ......................................................................................... 101 E.1. Los servicios Web utilizados Para este proyecto, se han utilizado cuatro servicios web que permiten obtener información convencional, como la hora, la fecha o la previsión atmosférica inmediata; información más elaborada, como un servicio de noticias y la previsión meteorológica para días y lugares concretos; e incluso multimedia, como un servicio de acceso a compra y escucha previa de canciones. Todos estos servicios son visibles al usuario de la aplicación, aunque también se han utilizado otros servicios como reconocimiento de IP pública y localización geográfica de una IP, que son invisibles al usuario y que permiten obtener información relevante para permitir una comunicación más natural entre el usuario y la aplicación. A continuación se detallan cada uno de estos servicios utilizados: E.1.1. Pronóstico meteorológico Este servicio está habilitado para que el usuario pueda hacer consultas sobre él a través de la interfaz. Permite consultar no sólo el pronóstico para el mismo día, sino que ofrece también la posibilidad de preguntar por el día siguiente o incluso por uno Los servicios Web utilizados 98 - name: el nombre de la canción. - duration: duración en segundos. - url: página web donde se puede comprar la canción. - streamable: este atributo indica si se encuentra disponible un fragmento de la canción para escucha previa. - artist: o name: nombre del cantante/grupo. o mbid: (MusicBrainz Identifier) id único del artista. o url: página web del artista en Last.fm. - image: imagen del disco donde se encuentra la canción. Existen distintos tamaños disponibles, definidos con el atributo size. En vista de que no era posible conseguir un archivo de audio con unos segundos de canción se decidió utilizar otro servicio API que sí que lo ofrecía. Este es Deezer.com. Actualmente la API de Deezer es accesible sólo para usuarios registrados, aunque en su momento sí que se tenía acceso libre a los métodos que ofrecía este servicio. Por esta razón se va a explicar el procedimiento de búsqueda seguido con este servicio. Las búsquedas de datos realizadas sobre la API de Deezer siguen el siguiente esquema: URL base: http://api.deezer.com/2.0/search? Parámetros de búsqueda: - q: datos que se quieren buscar. - output: formato de salida de la información. A continuación se muestra un ejemplo de búsqueda realizada a este servicio: http://api.deezer.com/2.0/search?q=katy+perry&output=xml Cuyo resultado es el siguiente: <?xml version="1.0" encoding="utf-8"?> <root> <data> <track> <id><![CDATA[16580021]]></id> <readable><![CDATA[1]]></readable> <title><![CDATA[Part Of Me]]></title> <link><![CDATA[http://www.deezer.com/music/track/16580021]]></link> <duration><![CDATA[216]]></duration> <preview> <![CDATA[http://cdn-preview- 9.deezer.com/stream/971bf12e3b224f4ef07bb7fb3ca30ba8-0.mp3]]> </preview> <artist> <id><![CDATA[144227]]></id> <name><![CDATA[Katy Perry]]></name> <link><![CDATA[http://www.deezer.com/music/katy-perry]]></link> <picture><![CDATA[http://api.deezer.com/2.0/artist/144227/image]]></picture> </artist> <album> Web APIs. Obtención de la información 99 <id><![CDATA[1549846]]></id> <title><![CDATA[Part Of Me]]></title> <cover><![CDATA[http://api.deezer.com/2.0/album/1549846/image]]></cover> </album> <type><![CDATA[track]]></type> </track> [...] </data> <total><![CDATA[390]]></total> <next> <![CDATA[http://api.deezer.com/2.0/search?q=katyperry&output=xml&index=50]]> </next> </root> Como se puede observar, por cada canción encontrada sí que se obtiene un archivo de audio que permite escuchar un fragmento de la canción a la que hace referencia. Este archivo se encuentra referenciado en la etiqueta <preview>. En este servicio, la metodología de búsqueda desarrollada se basa en realizar una búsqueda por artista en Deezer por cada canción obtenida del Last.fm. De esta búsqueda se obtiene un XML con canciones que tienen alguna referencia con el artista buscado. Uno de los problemas que surgen al consultar varios servicios Web API al mismo tiempo es el límite de consultas por segundos y día que se pueden realizar, ya que estos servicios se protegen ante ataques masivos restringiendo el número de consultas que se pueden hacer desde un mismo ordenador. En este caso, como se hace una búsqueda por artista por cada canción devuelta de Last.fm, el número de consultas que se pueden llegar a hacer sobre Deezer puede ser excesivo. Por esta razón se ha implementado un sistema simple de almacenamiento y consulta que reduce el número de consultas a la API de Deezer, y por lo tanto el tiempo de respuesta al usuario. Este sistema se puede observar en la figura E.2 y consiste en guardar por cada consulta a Deezer, el listado de canciones obtenidas asociadas a un artista, y mantener un listado de artistas de los que ya se ha obtenido información. De esta forma, antes de preguntar a la API por las canciones de un artista, se comprueba si ya se ha consultado anteriormente; en caso afirmativo se busca la canción en el sistema de memoria de canciones interno, en caso negativo se solicita la información a la API. Fig. E.2. Esquema de búsqueda y acceso a datos musicales. sí no Los servicios Web utilizados 100 Con este sistema de búsqueda se consigue una reducción en el tiempo de respuesta de un 68.37%. Fig. E.3. Tiempo de respuesta (en segundos) del servicio de música. Otro detalle a tratar es que en ocasiones el nombre de la canción obtenida de Last.fm, no coincide con el nombre con el que el sistema de Deezer ha guardado la información de la canción. Esto se produce cuando el título contiene texto entre paréntesis. Esto ocasiona que el sistema de almacenamiento interno del proyecto sí que contenga la información de la canción pero no puede encontrarlo por no haber una concordancia directa entre nombres. Para solucionar este inconveniente se realiza la búsqueda considerando el nombre de la canción sin y con paréntesis, y como la búsqueda se realiza sobre la memoria interna del proyecto, el tiempo de respuesta no se ve afectado. Con este sistema la tasa de fallos en la obtención del archivo de audio se reduce en un 6% (ver figura E.4), obteniendo en total una tasa de aciertos de un 90%. Fig. E.4. Reducción de la tasa de fallos con el sistema de búsqueda mejorado. E.1.5. IP pública y geo-localización Para estos dos servicios se ha utilizado el mismo servicio Web [GEOIPWEB]. La consulta y la información obtenida son invisibles al usuario, aunque para el sistema es de gran utilidad ya que permite conseguir datos que el usuario puede no haber dado 0 2000 4000 6000 8000 10000 Tiempo (1º vez) Tiempo (siguientes) 16% 84% Proporción fallos/aciertos Fallos Aciertos 10% 90% Proporción fallos/aciertos mejorado Fallos Aciertos Web APIs. Obtención de la información 101 en una consulta, como cuando el usuario no da información de dónde se encuentra ubicado para darle la previsión meteorológica de ese lugar. Para obtener la información de esta Web API se realiza la petición HTTP de la siguiente manera: URL base: http://geoip.prototypeapp.com/api/locate? Parámetros de búsqueda: - format: formato de los resultados a obtener. - ip: Dirección IP sobre la que obtener la información. A continuación se muestra un ejemplo de búsqueda realizada a este servicio: http://geoip.prototypeapp.com/api/locate?format=xml Cuyo resultado es el siguiente: <?xml version="1.0" encoding="UTF-8" ?> <items> <ip>155.210.155.218</ip> <timestamp>1339406548093</timestamp> <location> <coords> <latitude>41.6333</latitude> <longitude>-0.8833</longitude> </coords> <address> <city>Zaragoza</city> <country>Spain</country> <country_code>ES</country_code> </address> <gmtOffset>1</gmtOffset> <dstOffset>2</dstOffset> </location> </items> Como se puede observar se obtiene del mismo resultado la IP pública del ordenador y la localización geográfica, con una precisión a nivel de ciudad. Esta última viene dada por la longitud y la latitud, y por el nombre de la ciudad, el nombre del país y el código internacional del país. E.2. Parsers XML Para este proyecto se ha considerado que toda la información obtenida de los servicios Web API sea entregada en formato XML. En verdad los datos vienen como una cadena de texto que contiene los elementos necesarios para tratarlo como un archivo XML. Por esta razón, para analizar los resultados obtenidos es necesario crear un analizador (parser) de XML con el que se consiga extraer la información para poder mostrársela después al usuario. Parsers XML 102 Este analizador de texto XML utiliza librerías propias de Java, en concreto las librerías de SAX (Simple API for XML) [SAXWEB], un API totalmente escrito en Java que se encuentra incluido dentro del JRE de Java y que nos permite crear nuestro propio parser de XML. Algunas de las características que tiene SAX son: - Comprueba que el documento está bien formado. - SAX lee secuencialmente de principio a fin, sin cargar todo el documento en memoria. - Eficiencia en cuanto al tiempo y la memoria empleados en el análisis. El hecho de que SAX no introduzca todo el documento en memoria permite que sea el programador el que implemente los métodos necesarios para recorrer el árbol XML y elija qué datos son los que se van a guardar en memoria. Para poder utilizar el parser, es necesario primero crear una instancia de un DocumentBuilder (db) para poder introducirle un InputStream (is) al que se le ha asignado el texto a analizar en formato UTF-8: InputStream is = new ByteArrayInputStream(textoXML.getBytes("UTF-8")); dom = db.parse(is); dom es el objeto instanciado de la clase Document de Java sobre el que se van a realizar las consultas para obtener elementos concretos del XML. En la figura E.5 se muestra un esquema del contenido del objeto dom: Fig. E.5. Esquema del proceso de obtención del objeto DOM. Es en este momento cuando se puede recorrer el árbol de objetos y buscar las etiquetas que contienen los datos que se van a guardar en memoria. Para ello se ha implementado el método parseDocument(), que obtiene del objeto dom el elemento fuente del que cuelgan todos los nodos del árbol que contienen la información del XML. Una vez obtenido este nodo, se debe de obtener una lista de nodos específicos que contienen cada uno un elemento del XML. Para ello se utiliza las siguientes instrucciones: Element docEle = dom.getDocumentElement(); NodeList nl = docEle.getElementsByTagName(cad); Web APIs. Obtención de la información 103 siendo cad el nombre del tag que identifica la zona donde se encuentran los datos de un elemento. En el siguiente caso, cad es la cadena de texto “weather”, que contiene todos los elementos internos que caracterizan una predicción del tiempo: <weather> <date>2012-06-10</date> <tempMaxC>29</tempMaxC> <tempMaxF>84</tempMaxF> <tempMinC>17</tempMinC> <tempMinF>63</tempMinF> [...] <precipMM>1.0</precipMM> </weather> Después de obtener el listado de nodos de elementos, se accede a cada uno de ellos para conseguir la información específica que se desea obtener. Para ello se ha implementado el método getTextValue() al que, dado uno de los elementos y el nombre de un tag interno de ese elemento, devuelve el texto contenido en ese tag. En el caso anterior, para obtener la fecha de la predicción, el método getTextValue() se utilizaría de la siguiente manera: String date = getTextValue(elto,"date"); que asigna a la cadena date el valor “2012-06-10”. En algunos casos como el de la música, existen varios tags que tienen el mismo nombre aunque el contenido es distinto. Estos tags suelen venir acompañados de atributos que los caracterizan y los diferencian de los otros elementos. Para obtener la información contenida de un tag concreto con estas características, se ha sobrecargado el método getTextValue(), añadiéndole dos parámetros más de entrada que hacen referencia al atributo y valor que diferencia a un elemento del resto: <image size="small">http://userserve-ak.last.fm/serve/34s/72573304.png</image> <image size="medium">http://userserve-ak.last.fm/serve/64s/72573304.png</image> <image size="large">http://userserve-ak.last.fm/serve/126/72573304.png</image> String disc_img = getTextValue(elDB,”image”,”size”,”medium”); En este ejemplo la variable disc_img obtiene el texto contenido en el tag image cuyo atributo size sea igual a medium. 104 105 Anexo F: Síntesis de voz En este anexo se van a tratar los dos temas principales de la síntesis de voz, la utilización de la herramienta Loquendo TTS, y la conversión de la fonética de una frase a sintetizar en visemas. Contenido F.1. Loquendo TTS ...................................................................................... 105 F.1.1. Inicialización y configuración .......................................................................... 105 F.1.2. Síntesis de voz ................................................................................................. 107 F.1.3. Detener la síntesis de voz ............................................................................... 107 F.2. Analizador léxico-sintáctico de símbolos fonéticos ............................... 108 Con el fin de ofrecer una aplicación que pueda responder al usuario mediante voz natural, es necesario utilizar algún tipo de herramienta que pueda convertir cualquier cadena de texto a audio, y que además lo haga simulando a un humano. A este tipo de herramientas se les denomina sintetizadores de voz. En este proyecto se ha utilizado el sintetizador de voz Loquendo Text To Speech (Loquendo TTS), una herramienta que ofrece soporte en Java, voz sintética natural en español, permite su utilización en aplicaciones cliente-servidor, ofrece un conjunto de expresiones predefinidas y onomatopeyas que permiten dar emoción y realismo a la aplicación; y permite obtener la transcripción fonética del texto a sintetizar, lo que será de utilidad para la creación de visemas que serán utilizados por el agente 3D para simular una correcta sincronización labial. F.1. Loquendo TTS F.1.1. Inicialización y configuración Para poder utilizar la herramienta Loquendo TTS es necesario crear una sesión de trabajo, disponiendo para ello de la clase TTSSession. Esta instancia servirá para poder crear una instancia de la clase principal de trabajo del sintetizador que contiene todos los métodos necesarios para poder trabajar. Esta clase principal es TTSReader: Loquendo TTS 106 hSession = new TTSSession(); hReader = new TTSReader(hSession); Una vez creada la instancia de la clase principal, es el momento de configurar la salida de audio para síntesis de voz. Para ello la clase TTSReader dispone del método setAudio(), cuyos parámetros son:  audioDestName: Librería destino encargada de la salida del audio. Los valores posibles para este parámetro son:  "LTTS7AudioBoard": redirige la salida a la tarjeta de sonido.  "LTTS7AudioFile": redirige la salida a un fichero de audio, cuyo nombre se define en el parámetro “AudioDeviceName”.  "LTTS7AudioAsf": redirige la salida a un fichero ASF (Advanced Systems Format) exclusivo de Windows.  audioDeviceName: nombre del archivo audio de destino.  sampleRate: Frecuencia de muestreo (en Hz).  Coding: codificación del audio ("linear", "a-law", "u-law").  nChannels: Canales de salida. 1 para mono, 2 para estéreo. En este proyecto, los argumentos elegidos han sido LTTS7AudioBoard para redirigir el audio directamente a la tarjeta de sonido, y los valores (32000Hz, linear, 2) para obtener un audio de alta calidad: hReader.setAudio("LTTS7AudioBoard", null, 32000, "linear", 2); Una vez configurada la salida de audio, hay que definir la voz y el idioma con los que va a funcionar el sintetizador. Para ello se encuentra disponible el método loadPersona() que carga la voz y el idioma definidos como argumentos de entrada: hReader.loadPersona(this.voice, null, null); También es necesario definir la codificación del texto de entrada para el sintetizador. Para ello hay que modificar las directivas definidas para el objeto de la clase TTSReader, en particular la directiva TextEncoding cuyo valor será en este caso UTF-8: hReader.setParam("TextEncoding", "utf-8"); Síntesis de voz 107 F.1.2. Síntesis de voz Una vez realizada la configuración inicial, ya se puede proceder a obtener la fonética del texto que se quiere sintetizar y posteriormente a la síntesis del texto. Para obtener la fonética de una frase sólo es necesario invocar al método phoneticTranscription() de la clase TTSReader, indicando como argumentos de entrada el texto a traducir, y el tamaño máximo en bytes disponible para la conversión: hReader.phoneticTranscription(token_msg,500); Este método devuelve el conjunto de símbolos fonéticos de la frase en formato X- SAMPA, con el inconveniente de no diferenciar las separaciones correspondientes a los signos de puntuación de la frase original, ya que las representa con el carácter ‘#’. Por esta razón se ha creado el método getPhonetic, que analiza la frase original en busca de esos signos de puntuación, e inserta en el lugar adecuado entre los símbolos fonéticos, símbolos predefinidos que marcan dichas pausas. A continuación se muestra un ejemplo donde se muestra el resultado de Loquendo, y el resultado final de la fonética: Frase: Hola. Soy pepe, y me gusta trabajar. Loquendo: "ola#s"oi#p"epe#i#me#M\"ust_da#t_d4_daB_oax"a4_d# Fonética final: "ola#$.#s"oi#p"epe#$,#i#me#M\"ust_da#t_d4_daB_oax"a4_d#$.# Con esta conversión, ya se pueden saber las pausas existentes y se puede mejorar la sincronización labial del agente 3D con la síntesis de voz. F.1.3. Detener la síntesis de voz Para mantener una conversación fluida con el usuario y no hacerle esperar a que el sistema termine de sintetizar una frase, como en el caso de la lectura de un artículo de la Wikipedia donde el texto puede ser muy extenso; se ha creído necesario ofrecer las herramientas oportunas para detener la síntesis de voz. Estas herramientas son los métodos isSilence(), que devuelve un valor booleano indicando si se encuentra realizando la conversión a audio de alguna cadena de texto; y setSilence(), que hace silenciar al sintetizador e indica al agente 3D que debe dejar de hablar: public boolean isSilence(){ return hReader.done(); } public void setSilence(){ try { hReader.stop(); Main.ordenCallar(); // Callar al agente 3D Main.borrarLista(); } catch (TTSException ex) {...} } Analizador léxico-sintáctico de símbolos fonéticos 114 51 b - b_< m p - p\ B - B\ O\ _w 52 u U U\ 53 o y A Q V Y } 1 2 3 - 3\ 6 7 8 9 @ - @\ 54 w x\ H - H\ M W 115 Anexo G: Interfaz WIMP. Integración de nuevas funcionalidades En este anexo se van a explicar los métodos generadores de elementos de la interfaz WIMP, incidiendo en aquellos que se ven afectados en la integración futura de nuevas funcionalidades. Para ello se van a diferenciar los métodos propios de la interfaz general, de los métodos específicos para el tratamiento de la información de cada una de las herramientas de consulta disponibles que deben ser modificados cuando se integren nuevas funcionalidades. Cabe resaltar que los elementos de interfaz utilizados pertenecen a la clase Javax.Swing de Java. Contenido G.1. Interfaz general ................................................................................... 115 G.1.1. Área de control de solicitudes ....................................................................... 116 G.1.2. Área de visualización de información estática ............................................... 118 G.2. Métodos para el tratamiento de la información ................................... 119 Clase MyThreadASR ................................................................................................ 119 Clase Respondedor ................................................................................................. 119 Clase WebApisXML ................................................................................................. 119 Clase ParserXML nueva ........................................................................................... 119 Ficheros de gramática ............................................................................................. 120 G.1. Interfaz general Para la interfaz general se ha dispuesto de los elementos necesarios para que la integración de nuevas funcionalidades no implique modificar la estructura general de la interfaz. Para ello se ha utilizado un panel de pestañas en la zona de control de solicitudes, y un panel “cambiante” para la zona de muestra de datos estáticos incluidos en los resultados devueltos por los servicios utilizados, ya sean imágenes o datos precisos de información. Interfaz general 116 G.1.1. Área de control de solicitudes Fig. G.1. Sección de control de solicitudes. Esta zona se encuentra en la parte izquierda de la interfaz (figura G.1-1). Para esta zona se ha utilizado una instancia de la clase JTabbedPane, que provee de un contenedor sobre el que situar paneles base de cada una de las pestañas que se quieran añadir. El método necesario para añadir estos paneles, y por lo tanto para crear nuevas pestañas es el siguiente: jTabbedPane1.addTab("Título", panel); donde se le introducen como argumentos el título que se quiere mostrar en la pestaña, y el panel base que contendrá todos los elementos Swing para esa pestaña. Uno de los aspectos importantes que se deben de tratar en una interfaz multimodal como es este proyecto, es que el usuario puede solicitar mediante voz, información de una herramienta que no se encuentra completamente visible, es decir, que la pestaña sobre la que se quiere realizar la consulta no se encuentra activa, sino que hay otra que sí que lo está. En este caso se dispone de un método propio de la clase JTabbedPane que permite seleccionar uno de los paneles base que se encuentra contenido en la pestaña que se desea activar. Este método es setSelectedComponent() y recibe como argumento de entrada un objeto Component, en este caso la instancia del panel base de la pestaña a activar: jTabbedPane1.setSelectedComponent(panel_tab_herram); Para poder integrar nuevas funcionalidades a la aplicación, se ha dispuesto de la pestaña “Otras herramientas”, donde se incluye un panel de selección única con el que se selecciona la herramienta sobre la que se quiere hacer la consulta, y un panel base que contiene otros paneles y que permite alternar la visibilidad de cada uno de ellos (figura G.1-2). El panel de selección única consiste en un JComboBox, al que se le 1 1 1 2 Interfaz WIMP. Integración de nuevas funcionalidades 117 pueden añadir nuevos elementos simplemente agregando el texto de la nueva funcionalidad. Para ello se dispone de un vector de Strings donde se encuentran los textos de las consultas disponibles, y otro donde se encuentran las referencias a las imágenes que acompañan a dichos textos: String [] herramientas = new String[] { "Música", "Noticias", "Meteorología", "Hora/Fecha"}; String [] herramientas_img = new String[] { "Musica.png", "Noticias.png", "Tiempo.png", "Fechayhora.png"}; El panel que permite alternar los paneles de control de las funcionalidades disponibles es una instancia de la clase JPanel, al que se le ha asignado una característica de diseño o layout especial que permite a un panel contener otros y alternar la visualización de cada uno de ellos. Este layout se denomina CardLayout. Para poder realizar los cambios en la visualización de los paneles, es necesario poder referenciar al panel que se quiere hacer visible, por esta razón cuando se agrega un panel al panel base, se debe indicar el nombre por el que será conocido internamente. El método que permite añadir paneles alternantes es el método add(), con el panel que se quiere añadir como primer argumento, y como segundo el nombre que se va a utilizar para referenciar a dicho panel en los cambios de visibilidad: panel_card_herramientas.add (panel, texto); Estas adiciones al panel con el layout CardLayout se hacen en el método crearPestanaHerramientas(), siendo éste el único método de los generales que hay que modificar para integrar las nuevas funcionalidades que se deseen añadir a la aplicación. Para realizar los cambios de visibilidad de los paneles se debe invocar al método show() del layout utilizado en el panel base, indicándole el nombre del panel que se quiere mostrar. A continuación se muestra un ejemplo de uso de este método: panel_card_herramientas.add(panel_card_musica,"panel_musica"); CardLayout clher = (CardLayout)(panel_card_herramientas.getLayout()); clher.show(panel_card_herramientas, "panel_musica"); Cuando la interacción es mediante voz, es necesario que tanto el JCombobox como el panel cambiante de control de las funcionalidades incluidas, muestren la opción que se ha solicitado. Por esta razón, se han creado métodos para cada una de estas funcionalidades que, entre otras cosas, permiten activar la pestaña de herramientas, seleccionar el ítem de JComboBox, y hacer visible el panel de control de la funcionalidad seleccionada. Estos métodos son utilizados ya sea para la interacción tradicional con la interfaz, o la interacción mediante voz. public static void mostrarPanelMusica (){ jTabbedPane1.setSelectedComponent(panel_tab_herram); Interfaz general 118 CardLayout cl = (CardLayout)(panel_card_herramientas.getLayout()); cl.show(panel_card_herramientas, "panel_musica"); combo_herramientas.setSelectedIndex(0); [...] } En lo referente al diseño y contenido de cada uno de los paneles propios de la funcionalidad, se deja libertad para introducir los elementos de control que se precisen para obtener la información, siempre y cuando se respete el espacio establecido, o se empleen los elementos necesarios (JScrollPane) que permiten extender el espacio de trabajo sin modificar el tamaño del resto de elementos. G.1.2. Área de visualización de información estática Esta zona de la interfaz se encuentra en el lado derecho (figura G.2), entre el agente 3D y las imágenes de los colaboradores, y es aquí donde se deben mostrar los datos estáticos que se obtengan de los servicios Web, sin elementos de control que permitan interaccionar con el usuario. Fig. G.2. Área de visualización de información estática. Para mostrar la información en esta zona se ha utilizado un panel con el layout CardLayout, de esta forma por cada funcionalidad que se integra, se puede crear un panel que contendrá la información a mostrar al usuario, y este panel se añade al panel base con el layout específico. Los métodos utilizados para cambiar de paneles son los mismos que los especificados en el apartado anterior: panel_fotos.add(panel_fotos_wikipedia,"fotos_wikipedia"); CardLayout cl = (CardLayout)(panel_fotos.getLayout()); cl.show(panel_fotos, "fotos_wikipedia"); El diseño de los paneles de las funcionalidades que se deseen integrar es libre, siempre y cuando se respete el tamaño del área de información, o se utilicen los elementos necesarios para extender el tamaño del mismo sin alterar la estructura general de la interfaz. Interfaz WIMP. Integración de nuevas funcionalidades 119 G.2. Métodos para el tratamiento de la información En el caso de ampliar las funcionalidades sobre las que el usuario pueda solicitar información, será necesario modificar algunas clases existentes para el tratamiento de la información de entrada, e incluso será necesario modificar el fichero de gramática para poder reconocer consultas sobre esas nuevas funcionalidades. Clase MyThreadASR De esta clase el método que sería necesario modificar para añadir el reconocimiento por voz de las consultas a las nuevas funcionalidades, es el método WhatSaid(), que recibe la semántica de la consulta obtenida a través del reconocedor de voz y la analiza para poder llamar a los métodos específicos de la clase Respondedor. Clase Respondedor En esta clase se encuentran los métodos específicos de cada una de las funcionalidades, y la memoria interna que facilita el entendimiento de las consultas recibidas por voz. Para integrar una nueva funcionalidad sólo es necesario añadir el método que se encargue de llamar al método de conexión con el servicio Web de la clase WebApisXML, iniciar el parser para analizar los resultados obtenidos y extraer aquellos que se deseen mostrar al usuario, llamar a los métodos de la interfaz para mostrar la información en las zonas requeridas e invocar al método decir(), con el texto que se desee sintetizar para que se invoquen los métodos necesarios del módulo del agente 3D. Clase WebApisXML Sobre esta clase sólo será necesario introducir el método encargado de llamar al servicio Web añadido con los parámetros de la consulta que se vaya a realizar. Además en el mismo método sería aconsejable introducir una función que compruebe si el resultado obtenido contiene datos válidos, o si se ha recibido un XML con un mensaje de error. Clase ParserXML nueva Debido a que los parseadores de XML utilizados contienen métodos propios de la herramienta a la que dan soporte, sería necesario extender la clase ParserXML e incluir en esa nueva clase los métodos de obtención y consulta de los datos ya analizados. Métodos para el tratamiento de la información 120 Ficheros de gramática Para que el reconocimiento por voz incluya las reglas necesarias para reconocer las posibles consultas de la nueva funcionalidad, será necesario modificar los ficheros de gramáticas. En concreto se recomienda añadir en la gramática principal una referencia a un fichero de gramática nuevo en el que se incluyan las reglas necesarias para el reconocimiento de las nuevas consultas: $<./newgrammar.gram#rootofgrammar> 121 Anexo H: Pruebas realizadas. En este anexo se van a indicar las pruebas realizadas a lo largo del proyecto, utilizadas para comprobar no sólo el correcto funcionamiento de cada uno de los módulos desarrollados, sino la integración de esos módulos con los que ya se han probado anteriormente. Contenido H.1. Pruebas unitarias ................................................................................ 121 Gramática para el reconocimiento de voz .................................................................. 121 Análisis de la fonética .................................................................................................. 122 H.2. Pruebas de integración y del sistema ................................................... 123 H.1. Pruebas unitarias A continuación se explican las pruebas realizadas de forma individual sobre los módulos desarrollados más relevantes. En primer lugar se muestran las pruebas realizadas sobre la gramática utilizada para el reconocimiento de voz, y a continuación las pruebas realizadas sobre el sintetizador de voz, en concreto sobre la obtención de la fonética. Respecto a los módulos internos, las pruebas realizadas se centraron en el correcto funcionamiento de los elementos de la interfaz, en el correcto paso de mensajes entre los módulos, y en obtener la mayor cantidad de información válida para el usuario, como en el caso de la música donde existe información que para la mayoría de elementos sí que se puede obtener. Este último caso se puede ver en el anexo E (apartado E.1.4). Gramática para el reconocimiento de voz Las pruebas realizadas para verificar que la gramática que se estaba desarrollando realmente reconocía las posibles consultas que un usuario puede realizar a la aplicación, se han hecho sobre el programa Nugram IDE explicado en el anexo D. Estas pruebas consisten en introducir en el área marcada en la figura H.1-1 las posibles frases que puede decir el usuario, y cargarlas para poder tenerlas guardadas y realizar así pruebas incrementales de la gramática. Pruebas unitarias 122 Una vez introducido un conjunto significante de frases, en el área marcada en la figura H.1-2 se pueden ejecutar todas las consultas al mismo tiempo y así obtener en primer lugar, el porcentaje de aciertos y fallos producidos en el reconocimiento (figura H.1-3), y en segundo lugar, cuáles son las frases erróneas introducidas (figura H.2). De este modo, se han podido corregir los fallos ocasionados y crear una gramática sólida. El único caso que no se ha podido probar ha sido en frases en las que la regla $GARBAGE se incluye en el reconocimiento. Por esta razón, esta regla se ha sustituido por el token GARBAGE, y cuando se integró con el reconocedor Loquendo ASR, se sustituyó por la regla correcta. Fig. H.1. Interfaz de pruebas de la gramática utilizada en el reconocimiento de voz. Fig. H.2. Detalle de un error en el reconocimiento. Análisis de la fonética Para asegurar el correcto funcionamiento del analizador léxico-sintáctico se ha procedido a analizar varios textos de extensión variable y contenido aleatorio. Estos se han obtenido de un generador de textos aleatorios disponible en internet [LOREMIPSUM]. Una vez obtenidos los textos se ha procedido a analizarlos para observar qué fonemas no se contemplaban en el analizador, y así poder mejorarlo. 1 1 1 3 1 2 Pruebas realizadas 123 Cuando ya se ha conseguido que todos los símbolos sean contemplados, se ha procedido a analizar cuáles son los tiempos de análisis de los elementos fonéticos, para comprobar si este análisis supone aumentar el tiempo de espera para el usuario. En la figura H.3 se muestran los resultados obtenidos de este análisis, donde se puede observar que los tiempos de análisis para textos de unas 600 palabras suponen no más de 180 milisegundos, por lo que se puede concluir que el análisis de los fonemas no influye prácticamente en el tiempo de respuesta al usuario. Fig. H.3. Gráfico de tiempo de respuesta del analizador de fonemas. H.2. Pruebas de integración y del sistema Al seguir una metodología de trabajo Orientada a Objetos, las pruebas más extensas y exhaustivas se han realizado de forma individual sobre cada uno de los módulos que componen la aplicación. Una vez terminadas esas pruebas se han ido integrando cada uno de los módulos hasta que se ha completado el proyecto final. En cada una de las integraciones se realizaban las mismas pruebas que se hicieron sobre cada uno de los módulos individuales, comprobando así que el sistema que se iba formando funcionaba correctamente. 0 20 40 60 80 100 120 140 160 180 200