4/6/2001 Nueva arquitectura para un servidor vocal telefónico con Reconocimiento Automático de Habla Autor: Javier López García

Javier López García ÍNDICE n Objetivos n Análisis y diseño de sistemas SW n Arquitectura de SERVIVOX: el kernel n Reconocimiento: TIDAISL n Matrices y evaluador de expresiones n Conclusiones n Líneas futuras

Javier López García OBJETIVOS DEL PROYECTO n Diseñar una nueva arquitectura para SERVIVOX que le proporcione mayor modularidad y flexibilidad. n Reestructurar el software de TIDAISL de modo que se puedan integrar los módulos desarrollados en SERVIVOX. n Ampliar y mejorar el LDD. n Generar documentación precisa sobre: –La estructura actual de SERVIVOX. –Los pasos a seguir para ampliarlo con software de TIDAISL.

Javier López García DESARROLLO DE SOFTWARE n Fases: –Análisis (Requisitos,...) –Diseño. –Implementación. –Pruebas. –Mantenimiento. n Estrategias: –Lineal en cascada. –Prototipado-evolutiva. n Metodologías: –Estructurada. –Orientada a objetos.

Javier López García ANÁLISIS Y DISEÑO n Análisis: –Consiste en descomponer un sistema en los elementos que lo integran. –Responde a la pregunta qué es el problema, define el problema con precisión. –Genera un modelo conceptual del sistema. n Diseño: –Se realiza después del análisis. –Responde a la pregunta cómo se resuelve el problema con las herramientas disponibles. –Modifica los modelos generados en el análisis para reflejar decisiones relativas al entorno en que el sistema debe funcionar. –Genera un modelo físico del sistema.

Javier López García ANÁLISIS ORIENTADO A OBJETOS n El análisis y el diseño orientados a objetos utilizan los objetos como elementos básicos para la elaboración de modelos. n Objeto: podemos definir formalmente un objeto como una abstracción de algún objeto en el mundo real que incluye los datos o propiedades (atributos) que describen el objeto real, e incluye las operaciones (métodos) que manipulan estos datos, que son además las únicas autorizadas para hacerlo.

Javier López García ANÁLISIS PROPUESTO n Fase inicial: –Estudio de documentación previa: PFCs. –Reuniones con el cliente: desde gestores a técnicos. n Componentes: –Modelo de requisitos: necesidades de los usuarios. n Ámbito del proyecto. n Diagrama de contexto. n Guiones de casos de uso. –Modelo de objetos: n Arquitectura. n Diagrama de objetos. –Diccionario: define los conceptos utilizados. Se elabora conjuntamente con los modelos anteriores.

Javier López García ÁMBITO DE SERVIVOX – –Un sistema que permita: n n editar, compilar, ejecutar, configurar, depurar, crear, analizar y supervisar aplicaciones multimedia que proporcionen un servicio automático de atención al cliente con síntesis y reconocimiento de habla, con acceso a bases de datos y utilidades de correo electrónico. – –El sistema será también una herramienta para los desarrolladores de aplicaciones. – –Será competencia del sistema: n n proporcionar un lenguaje de descripción de aplicaciones multimedia, junto con las herramientas necesarias para editar, compilar, ejecutar, etc, dichas aplicaciones. – – No será competencia del sistema: n n el reconocimiento y la síntesis del habla, el proporcionar un servidor de mail o un servidor de bases de datos, pero sí definir una interfaz que se comunique con estos sistemas.

SISTEMA SERVIVOX DE APLICACIONES MULTIMEDIA MÓDULO MAGO DE OZ SUPERVISOR PROGRAMADOR OPERADOR(A) TELEFÓNICO MENSAJES PREGRABADOS Interfaz Usuario Sistema DRIVER TELÉFONO DRIVER AUDIO SERVIDOR AGENTES ANIMADOS Interfaz Usuario Servicio DRIVER IMÁGENES RPC MOTOR DE BÚSQUEDA (RENFE) ODBC ( BASES DE DATOS ) MAIL (POP3) Backend PROGRAMAS EXTERNOS EJECUTABLES MÓDULO DE GENERACIÓN DE RESPUESTA MÓDULO DE COMPRENSIÓN NLP MÓDULO DE ACENTOS DLL DE SÍNTESIS LIBRERÍA DE RECONO CIMIENTO Voz PORTABLE, PROFILE, FILEHAND Portable Configura Log

Javier López García ÍNDICE n Objetivos n Análisis y diseño de sistemas SW n Arquitectura de SERVIVOX: el kernel n Reconocimiento: TIDAISL n Matrices n Evaluador de expresiones n Conclusiones n Líneas futuras

Javier López García ARQUITECTURA DEL SERVIVOX (I) n Inspirada en la arquitectura DARPA. n Estructura cliente-servidor: –El kernel controla la secuencia del diálogo (cliente). –Toda la funcionalidad reside en los servidores. n Estructura de subsistemas intercambiables: –Interfaz kernel-servidor normalizada (__funciones). –Reparto normalizado de tareas entre los servidores. n Kernel programable: se define el LDD para la descripción de aplicaciones multimedia. n Log centralizado: seguimiento cronológico de la secuencia de trazas generadas por la aplicación.

Javier López García ARQUITECTURA DEL SERVIVOX (II)

Javier López García EL KERNEL n Núcleo de ejecución del autómata. n Lenguaje de alto nivel especializado en aplicaciones con interfaces vocales y multimedia (LDD). n Principales objetos del kernel: –Autómata y Ejecutar autómata. –Tabla de funciones. –Argumentos y Pila de Subrutinas. –Eventos y Errores. –Variables y Variables iniciales. –Configuración y Log. –Otros: fechasHoras, strings, ficheros, temporiz, matrices.

Javier López García FUNCIONAMIENTO DEL KERNEL AutomataEjecutor Tabla Func. Eventos y errores __Funciones Funciones C Variables Config y Log PilaSub y Argumentos

Javier López García ÍNDICE n Objetivos n Análisis y diseño de sistemas SW n Arquitectura de SERVIVOX: el kernel n Reconocimiento: TIDAISL n Matrices n Evaluador de expresiones n Conclusiones n Líneas futuras

Javier López García TIDAISL n Plataforma donde se prueban los nuevos parametrizadores y reconocedores. n Mains que integran: test bench + recono/param. n Objetivos: –Separar el test bench del recono/param. –Proveer operaciones síncronas en trama. –Crear librerías de procesamiento integrables en SERVIVOX: n paramet: rasta, mfcc. n HMM_SC_DC n lib_comun: configuración, listas...

Javier López García CLASES DE RECONOCIMIENTO (I) n Proponer una nueva arquitectura para las clases de reconocimiento de SERVIVOX. n Reducir la herencia (inclusión). n Desposeerlas de la funcionalidad de reconocimiento: clases meramente interfaz. n Integrar las librerías de TIDAISL disponibles. n Realizar de forma práctica un reconocedor de una etapa: TReconoNuevo.

Javier López García CLASES DE RECONOCIMIENTO (II)

Javier López García ÍNDICE n Objetivos n Análisis y diseño de sistemas SW n Arquitectura de SERVIVOX: el kernel n Reconocimiento: TIDAISL n Matrices n Evaluador de expresiones n Conclusiones n Líneas futuras

Javier López García MATRICES DEL LDD (I) n Dotar al LDD de arrays multidimensionales accesibles por índice y por clave. –Conjunto de pares atributo-valor. –Aplicaciones más legibles. n Diseño a medida para el módulo matrices. n Implementación puramente orientada a objetos. n Programación en C++ haciendo uso de la librería estándar (STL).

Javier López García MATRICES DEL LDD (II)

Javier López García EVALUADOR DE EXPRESIONES n Evaluador de expresiones aritmético-lógicas con variables. n Incorpora: –Operadores lógicos. –Paréntesis. –Las precedencias habituales en C. n Diseño flexible para poder usarse más allá de la mera asignación: clase virtual TgestorVariables. n Ejemplo: n_var2>(1+n_var)/3.1+2*3

Javier López García RESUMEN n Análisis de alto nivel de SERVIVOX orientado a objetos. n Re-diseño del arquitectura y su implementación (prototipado evolutivo). n Rediseño de parte de TIDAISL y de las clases de reconocimiento y parametrización de SERVIVOX. n Funcionalidad añadida al LDD: –Evaluador de expresiones aritmético-lógicas. –Arrays multidimensionales. –Paso de argumentos a subrutinas. –Variables locales.

Javier López García CONCLUSIONES (I) n El análisis orientado a objetos es una herramienta más potente que el análisis estructurado. n El prototipado evolutivo es una estrategia adecuada para desarrollar un sistema: –Es más seguro. –Implica menor coste. –Pero se pueden heredar características del sistema original. n La importancia de un análisis natural: –El sistema es más fácilmente comprensible. –El sistema puede crecer más fácilmente. n Al integrar TIDAISL y SERVIVOX hay que evitar la duplicación del código: usar librerías.

Javier López García CONCLUSIONES (II) n Importancia de una buena documentación: –No sólo documentación de uso (manuales), –sino también documentación interna (desarrolladores). n Comparación con otros proyectos: –GTH: ahora situación análoga a TIDAISL o síntesis. –Empresa: hay más separación entre desarrolladores y pruebas de sistemas y más documentación interna (pero puede no ser de calidad porque se hace por cumplir). n Logros concretos del proyecto: –Desarrollo de aplicaciones (RENFE) facilitado por la ampliación del LDD: variables locales y subrutinas. –Añadir una nueva función de reconocimiento es más fácil. –La incorporación de personal es más sencilla (doc + arq).

Javier López García LÍNEAS FUTURAS n Ejecución distribuida n Re-diseño de otros módulos de reconocimiento (dígitos, preselección y deletreo). n Registrar cambios en el repositorio de TIDAISL. n Incorporación del evaluador a la sintaxis de las asignaciones del LDD. n Re-diseño de algunas aplicaciones existentes empleando variables locales y paso de parámetros. n Eliminación del procesamiento en segundo plano por medio de funciones idle.

Javier López García ¿PREGUNTAS?

LA ARQUITECTURA GALAXY (I) n Consiste en: –Una estructura cliente-servidor. –Reparto normalizado de tareas entre servidores. –Protocolos de comunicación normalizados. –Módulo central (Hub) que canaliza las comunicaciones controlado por un lenguaje de script. n Objetivos: –Favorecer la interoperabilidad de equipos y el plug&play. –Hacer flexible el diálogo, gracias a la configurabilidad del hub.

Javier López García LA ARQUITECTURA GALAXY (II) Servidor de audio Conversión texto-voz Generación del lenguaje Gestor del diálogo Back-end de la aplicación Seguimiento del contexto Parsing del lenguaje Reconocimiento de habla HUB

Javier López García CARACTERÍSTICAS DEL LDD n Instrucciones síncronas: aritméticas, strings, arrays. n Instrucciones especializadas: –Asíncronas: reco, agentes animados,... –Síncronas: mail n Excepciones: –colgado –timeout –fin de intentos –cadena corta n Variables: predefinidas, de usuario, locales. n Instrucciones de control: IF, WHILE, SUBRUTINAS,....

Javier López García Subrutinas y variables locales n Ejemplo de uso: –gosub SINTETIZAR_MENSAJE_LARGO_ARRAY: (n_array_mensaje_largo_dar_timeout, 2;n_result); n Ejemplo de subrutina : –SUBRUTINA SINTETIZAR_MENSAJE_ARRAY: (n_sub_array_mensajes, n_sub_indice_array_mensajes; n_resultado) –DEF_VAR – s_mensaje_aux –FIN_VAR – LEE_ARRAY (n_sub_array_mensajes, n_sub_indice_array_mensajes; s_mensaje_aux); – sintetizar (s_mensaje_aux;); – n_resultado=0;