Resumen.- Versión abreviada y precisa del proyecto que se...

Proyecto Anexo técnico 20071291 Saúl De La O Torres. ESCOM 2007

1Uso de Agentes Inteligentes para la Comunicación Hombre Maquina, mediante el empleo de Procesamiento de Lenguaje Natural con metodología Orientada a Objetos.

El lenguaje escrito es un medio ejemplar para interactuar, que proporciona las ventajas propias de la naturaleza humana, y que muestra la capacidad de ofrecer una interacción humano-computadora refinada. Sin embargo en la medida en que este medio proporciona ventajas, surgen retos que implican una colección de esfuerzos desarrollados por un conjunto de gente que en su diaria actividad investigadora intenta proporcionar soluciones para esta clase de retos.

Resumen.- Versión abreviada y precisa del proyecto que se reporta como concluido. Se describe el análisis, el diseño y la implementación del gestor de diálogo para una interfaz conversacional para el proceso de reservación de habitaciones a un hotel, utilizando herramientas para el análisis de lenguaje natural para el idioma español. Se utiliza Java para implementar tanto el gestor como el servidor Web (API JSP/Servlet) sobre el que funciona el programa y el análisis de lenguaje natural se realiza con ayuda de una adaptación del Phoenix Parser de la Universidad de Colorado. Se muestra una visita virtual de cierta parte del hotel mediante el IPX Image Viewer. Introducción.- Debe establecer claramente el propósito del trabajo, incluyendo las hipótesis propuestas, los problemas abordados, un bosquejo del trabajo y su importancia en un contexto más amplio de investigación. Debe ser explícito y comprensible para quienes no son especialistas en el tema. La demanda de un acceso inmediato, continuo y libre a la supercarretera de la información es cada día mayor; así mismo la necesidad de obtener interfaces que de una manera eficiente y confiable puedan proporcionar los medios suficientes para lograr esto; hace preciso el fijar una meta en la cual se contempla la formación de una nueva generación de interfaces computacionales que soporten una interacción más compleja, pero sin que estas pierdan los toques atractivos y de la simplicidad en su uso que las caracterizan.

Métodos y materiales.- Hacer una descripción del diseño de experimentos o del procedimiento teórico-metodológico utilizado en la investigación, estableciendo claramente las premisas, supuestos del diseño, justificar la selección del método. Los métodos deben identificarse y describirse con suficiente detalle para que sea posible: a) obtener los mismos resultados por otro investigador experimentado, b) para evaluar la confiabilidad y validez de los métodos usados y de los resultados reportados Describirlos en un orden lógico donde se puede identificar fácilmente como se relacionan con el diseño experimental en su caso. Este documento se estructura en nueve secciones, dentro de los cuales se exponen los objetivos, la base teórica, de diseño y la implementación del sistema. En la seccion 1 se presenta el contexto en el que surgen las interfaces conversacionales, su estructura general, la forma en que operan, los retos presentes y futuros. Además se da una introducción teórica sobre lo que concierne a la iniciativa mixta, como un intento de obtener características básicas de la forma de planeación estratégica para solución de



problemas, y de las cuales estas pueden ser implementadas en modelos computacionales. En la sección 2 se presentan los objetivos generales del trabajo y un esquema general del proceso de reservación parte del cual se desea automatizar mediante una interfaz en lenguaje escrito. Los conceptos involucrados para el desarrollo del trabajo y el funcionamiento de las herramientas utilizadas se mencionan de forma introductoria en la sección 3. Los conceptos abarcan áreas de conocimiento que se adquirieron a lo largo de la carrera y se explican con más detalles en las referencias proporcionadas La sección 4 muestra las herramientas que se utilizaron para la creación del sistema. Se mencionan sus componentes, funciones y la manera en que se utilizaron para llevar a cabo el proyecto. La sección 5 presenta un panorama general del funcionamiento de la parte central del trabajo “Análisis del lenguaje natural”. El fundamento del trabajo se encuentra en investigaciones hechas en la Universidad de Colorado, el Instituto Tecnológico de Massachussets y la Universidad de Carnegie-Mellon, donde se originaron los primeros sistemas conversacionales e interfaces de lenguaje escrito. El análisis y diseño del sistema se explican en la sección 6, donde también se muestran los diagramas de UML sobre los que se basa el programa. La interfaz de usuario del programa también aparece en esta sección.

Sección 1. 1. Contexto El hombre siempre ha querido lograr una comunicación directa con las computadoras, es decir de forma más natural, así como se comunica con otros hombres. El término Sistemas Conversacionales implica un sistema interactivo de diálogo que opera en un dominio restringido; el sistema toma un papel activo en un diálogo para negociar con el usuario el cumplimiento de cierto objetivo. Las interfaces conversacionales son una tecnología relativamente nueva. Teniendo su primera aparición a finales de la década de los 80, surgen como resultado de los esfuerzos financiados por gobiernos en ambos lados del Atlántico, por una parte Estados Unidos lanza su programa en Sistemas de Lenguaje Hablado a través de la organización DARPA (Defense Advanced Research Projects Agency), y por la otra en Europa el programa Esprit SUNDIAL (Speech UNderstanding and DIALog). Los dos programas se desarrollaron en paralelo en cada continente, y generalmente involucraban el acceso a una base de datos para la planeación de viajes. Estos sistemas a la fecha han alcanzado capacidades de operación en tiempo real, y de instalación en cualquier estación de trabajo o PC, sin agregar hardware adicional 1.1 Interfaces Conversacionales


3

El termino interfaz conversacional por lo general implica un sistema interactivo el cual opera en un dominio restringido. Un aspecto que diferencia a este tipo de interfaces, es el grado en el cual los sistemas toman un rol activo en la conversación. Los sistemas que tienen un diálogo dirigido por la máquina tenderán a preguntar al usuario series de preguntas, los sistemas de respuestas interactivos podrán interactuar con el usuario de una forma más natural. Las interacciones concretas generadas por un sistema pueden generar respuestas cortas por parte del usuario, lo cual generará porcentajes de éxito más altos. Muchos sistemas desarrollados han utilizado esta estrategia. Este marco puede ser mejorado permitiendo a los usuarios experimentados especificar varias restricciones en una sola intervención. Estos sistemas permiten a los usuarios interactuar con un equipo de cómputo para recobrar información, conducir transacciones, o para desarrollar otras tareas en la solución de problemas. La arquitectura de este tipo de interfaces varía significativamente, de acuerdo a las capacidades ofrecidas por la misma, desde aquellas que sólo obedecen a comandos específicos, hasta aquellas que permiten un diálogo continuo y fluido. 1.2 Arquitectura general de las interfaces conversacionales

Generador de lenguaje

Uso de Agentes Inteligentes para la Comunicación Hombre Maquina, mediante el empleo de Procesamiento de Lenguaje Natural con metodología Orientada a Objetos.

Figura 1. Módulos generales de un sistema conversacional

La arquitectura general de una interfaz conversacional tiene los siguientes elementos:

a) Entrada del sistema: La entrada del sistema que puede ser por lenguaje hablado o lenguaje escrito. Para este trabajo se considera que la entrada del sistema es mediante lenguaje escrito introducido desde teclado.

b) Módulo de entendimiento de lenguaje natural: El cual se encarga de obtener una representación significativa de lo obtenido en la entrada.

c) Manejador de diálogo. Se encarga de controlar la interacción con el usuario. d) Generador de lenguaje. Va a formar oraciones, para representar o pedir

información y que estas puedan ser entendidas por el usuario.

Manejador de diálogo

Contexto de diálogo

Entendimiento de lenguaje natural

Frames semánticos

Base de datos

Entrada del sistema

Salida del sistema



e) Salida del sistema. Un mecanismo para transmitir la información obtenida al usuario. Se puede utilizar un sintetizador de voz (TTS, Text to Speech System), pero también pueden incluirse texto, pantallas o cualquier otro medio gráfico de visualización.

Por lenguaje natural entendemos el conjunto de interacciones que las personas intercambian con otras para conseguir un objetivo, compartir o expresar información. 1.3 Operación de los sistemas conversacionales La manera en que opera una interfaz conversacional se puede describir brevemente de la siguiente manera: La entrada de información es procesada, analizada verificada por el módulo de entendimiento para obtener una representación significativa de lo que el usuario ha expresado. El manejador de diálogo trata de incorporar de acuerdo al contexto de la conversación la información que recientemente ha ingresado al sistema, lo que puede resultar en salida de información en forma de texto, tablas o gráficas. Cuando el proceso de incorporación es insuficiente o ambiguo, el sistema puede hacer preguntas al usuario formuladas por el módulo generador de lenguaje y coordinado por el manejador de diálogo para resolver las ambigüedades presentadas en la entrada. Si la salida del sistema lo permite (existe un sintetizador de voz o TTS) las respuestas y preguntas al usuario son en lenguaje hablado, de otra manera se pueden transmitir resultados en lenguaje escrito. Las entradas del sistema para este trabajo serian mediante teclado y las salidas serían en forma de texto, tablas o graficas. A lo largo del proceso, la información del diálogo se mantiene y retroalimenta a los elementos de entendimiento del lenguaje para que las oraciones puedan ser entendidas propiamente de acuerdo al contexto en que aparecen. 1.4 Clasificación de los sistemas conversacionales Se clasifican de acuerdo a los recursos que se utilizan para la comunicación entre el usuario y la máquina: solo lenguaje hablado, lenguaje escrito, imágenes, tablas, etc. Siguiendo esta clasificación, los sistemas pueden ser unimodales o multimodales. 1.4.1 Sistemas unimodales En estos la computadora es capaz de entender la entrada hablada de la persona y generar una salida hablada para el usuario. Estos sistemas son sistemas de entrada – salida unimodales, esto es, que utilizan información representada como habla y nada más en su comunicación con el usuario, por ejemplo los sistemas que funcionan por medio de la línea telefónica, en donde el usuario sólo puede dar información a la computadora de manera hablada, y el sistema sólo le puede dato información al usuario por la línea telefónica. Estos sistemas pueden ser subdivididos en sistemas que toman en cuenta entrada hablada continua y aquellos que requieren palabras aisladas, sistemas independientes del usuario, y aquellos que requieren cierto entrenamiento para cada usuario. 1.4.2 Sistemas multimodales



Los sistemas interactivos multimodales son sistemas que tienen algunos dispositivos de apoyo como una pantalla para presentar tablas o pantallas para presentar el texto que es la respuesta de la máquina. El sistema también tiene formas de comunicarse con el usuario, no se restringe solo a salida hablada o escrita, también el usuario puede apoyarse con el teclado, el ratón o algún otro dispositivo. El presente trabajo de tesis se basa en un sistema multimodal que opera por medio de la Web, donde el usuario se comunica por medio de entradas por teclado y el sistema responde con texto, imágenes y tablas

Sección 2. 2 Proceso de reservación En las secciones anteriores se han mencionado diferentes sistemas conversacionales que proporcionan ayuda en un dominio restringido. Para el presente trabajo son de interés:

• El Danish Dialogue System que fue desarrollado para automatizar la reservación de boletos de avión,

• El sistema CU Communicator de la Universidad de Colorado que proporciona información acerca de hoteles y,

• El WebGalaxy de la Instituto Tecnológico de Massachussets que es un sistema conversacional que opera sobre un navegador Web y que el usuario puede manejar el sistema a través de entradas de teclado.

Para proponer una nueva interfaz conversacional tomaremos diferentes características de los sistemas anteriores. Del Danish Dialogue System tomaremos la tarea: la reservación de servicios; del CU Communicator tomaremos el dominio de aplicación: hoteles y el concepto de diseño del sistema: agentes; y del WebGalaxy tomaremos los medios para establecer la comunicación hombre-máquina: la Web, las entradas por medio de teclado y las salidas del sistema por medio de texto, tablas e imágenes. Una característica significativa del sistema que se propone, y que la hace diferente de los sistemas existentes, es que el idioma de la interfaz es el español. El cambio de idioma provoca que el sistema tenga que manejar representaciones de conocimiento diferentes, lo que lo hace totalmente novedoso. Por otra parte la investigación acerca de las interfaces conversacionales y su implantación no es tan amplia en México, por lo que el presente trabajo aporta fundamentos teóricos y prácticos de los sistemas conversacionales. El sistema a desarrollar será de Iniciativa Mixta Limitada con el fin de que la interfaz proporcione flexibilidad en la comunicación con el usuario. 2.1 Objetivos del trabajo Los objetivos del presente trabajo son crear:



1. Desarrollar un Agente que basado en las características de un hotel dialogue con el usuario para realizar el servicio de reservación de habitaciones por Internet y ofrecer una visita virtual a una de las habitaciones del hotel.

2. Crear un sitio Web que incorpore los servicios del agente. Se ha elegido la tarea de reservación en el dominio hotelero porque:

• La mayoría de las interfaces conversacionales son sistemas de ayuda en un dominio restringido como el de reservaciones de hotel.

• La tarea y el dominio no han sido abordados de manera conjunta por ninguno de los sistemas presentados, pero a la vez proporcionan elementos como bases teóricas, de diseño e implementación para realizarlo.

Con respecto a la parte de la visita virtual, existen herramientas que permiten realizarla. En el sección 3 y 4 se hablará de cómo funcionan estas herramientas y cuál se eligió para realizar la visita virtual. Dado que el proceso de reservación es un término amplio, el siguiente apartado delimitará que se quiere decir con “servicio de reservación” en el objetivo. Así mismo se especificarán las características del hotel que el sistema manejará. 2.2 Consideraciones generales del proceso de reservación Para este trabajo el proceso de reservación se entiende como la aplicación de un conjunto de preguntas para obtener información acerca de:

• El número y tipo de habitaciones de hotel. • El número de adultos y menores que van a ocupar las habitaciones del hotel. • Los datos generales de cliente que reserva. • La forma de pago del cliente.

Lo anterior también implica proporcionar información al cliente acerca del hotel y la reservación que esta realizando. 2.2.1 Restricciones

• Hotel: Se eligió el hotel “Aeropuerto Plaza” de la cadena de hoteles Fiesta Americana.

[Aeplaza]

La elección de este hotel se debe a que la página Web de este hotel proporciona amplias descripciones en español acerca de las instalaciones, los servicios y sus precios, lo que se puede incorporar perfectamente a la base de datos del sistema que se va a realizar. En [Aeplaza] se encuentra una lista de las características y descripciones de instalaciones y servicios de hotel.

Cabe mencionar que los métodos de administración del hotel (incluida los métodos de administración de reservaciones) no están disponibles al público en general.



• Información proporcionada: El sistema a realizar será capaz de dar información acerca del hotel y en un momento dado si el cliente así lo solicita, llevar a cabo el proceso de reservación. Para ver una lista completa de las consultas que el sistema puede procesar, remítase al capitulo 7.

• Restricciones del proceso de reservación: El proceso de reservación es

individual y no maneja reservaciones grupales. El sistema maneja las siguientes características de una reservación individual:

o El cliente puede elegir un solo tipo de habitación en cada reservación de entre las diferentes opciones que ofrezca el hotel.

o Número de habitaciones limitado para reservar. La cantidad exacta depende de las políticas de cada hotel, pero usualmente es menos de 13.

o Número de adultos y menores limitado al número y tipo de habitaciones a reservar.

o Cuando se haga una observación acerca de alguna característica especial de la reservación como habitaciones en zona de no fumadores o en planta alta, estas aplicarán de forma global a toda la reservación.

o Es necesario solicitar tarjeta de crédito para asegurar que las reservaciones se llevarán a cabo, de lo contrario se pueden presentar problemas por bloquear habitaciones para clientes que reservaron y nunca llegaron, debido a que la mayoría de los hoteles rehúsan a pagar por una reservación cuando el huésped nunca se presenta.

o Si existe el número de habitaciones y el tipo que el cliente desea, al registrar su pago con tarjeta de crédito, las habitaciones quedan automáticamente reservadas (bloqueadas).

o La validación de la tarjeta de crédito queda fuera de los alcances de este proyecto.

2.2.2 Preguntas del proceso de reservación De acuerdo con la Lic. Alicia Arenas profesora de la Escuela Panamericana de Hotelería una reservación vía telefónica se realiza de la siguiente manera:

1. Contestar con la fraseología del hotel. 2. Preguntar las fechas de llegada 3. Preguntar el tipo de habitaciones

a. Se necesita verificar la disponibilidad de las habitaciones solicitadas b. Indicar tarifa de la habitación solicitada

4. Preguntar el número de personas que van a ocupar las habitaciones: adultos y menores.

5. Preguntar la fecha de salida (o número de noches) 6. Preguntar datos del cliente que hace la reservación 7. Preguntar forma de pago:

a. Tarjeta de crédito: i. Nombre del titular

ii. Numero de la tarjeta iii. Fecha de vencimiento

b. Deposito: Proporcionar al cliente el: i. Banco

ii. Numero de cuenta



iii. Razón social 8. Confirmar datos (Nombre del cliente, fecha de entrada y fecha de salida,

número de adultos y menores, número y tipo de habitaciones y la tarifa. 9. Preguntar por “remarks” o solicitudes adicionales. 10. Indicar políticas del hotel (llegada y cancelación) 11. Proporcionar el número de confirmación 12. Despedir la reservación con la fraseología del hotel

Algunas observaciones hechas son:

• La fraseología del hotel no es la misma para todos los hoteles. • Existe un sistema computacional que dirige las preguntas que la persona a cargo

de la reservación debe hacer, dependiente de cada hotel. • Se busca que el tiempo promedio del proceso (aplicación y respuesta) es de 3

minutos. Con respecto a la fraseología del hotel, se deben tener en cuenta que quien hace la reservación no sólo ha tomado una reservación sino que ha realizado una función de venta; por lo tanto, la manera de tomar la reservación es importante. Las siguientes son ciertas técnicas clave en el manejo de una llamada de la reservación.

• Quién hace la reservación nunca debe decir “estamos llenos”, “tenemos todo vendido” o “ya no tenemos nada”. En lugar de ellos deben utilizarse las frases “tenemos cupo lleno” o “no hay disponibilidad”.

• Nunca debe utilizarse la frase “tiene que” al solicitar el depósito. En lugar de ello debe decir que el hotel exige un depósito.

• Si se pregunta por qué no hay disponibilidad, nunca debe darse la impresión de que el hotel tiene cupo lleno a causa de algún grupo. No es deseable dejar la impresión con un huésped prospecto de que el hotel no deja lugar a huéspedes regulares. En lugar de ello debe indicarse sólo que no hay disponibilidad a causa de una gran demanda.

• En lo que concierne a tarifas, políticas y procedimientos, las explicaciones deben ser claras pero breves.

2.3 Esquema general del proceso de reservación Teniendo en cuenta el contexto y la teoría de los sistemas conversacionales que se mencionan en el capitulo 1, es necesario adaptar el orden de las preguntas que se hacen vía telefónica para realizar el proceso de reservación, si se desea desarrollar un sistema conversacional basado en un navegador Web. Las adaptaciones son las siguientes: Las partes del proceso de reservación que se realizan por medio del proceso de diálogo son:

1. Contestar con la fraseología del hotel. 2. Obtener la fecha de llegada 3. Obtener el tipo de habitaciones

a. Verificar la disponibilidad de las habitaciones solicitadas 4. Obtener el numero de habitaciones



a. Verificar la disponibilidad y validez del número de habitaciones solicitadas

5. Indicar tarifa de la habitación solicitada 6. Preguntar el número de personas que van a ocupar las habitaciones: adultos y

menores. a. Verificar que el número de personas sea valido para el número y tipo de

habitaciones solicitado 7. Obtener la fecha de salida (o número de noches) 8. Confirmar datos (Nombre del cliente, fecha de entrada y fecha de salida,

número de adultos y menores, número y tipo de habitaciones y la tarifa. 9. Preguntar por “remarks” o solicitudes adicionales.

a. Verificar que los remarks existen 10. Indicar políticas del hotel (llegada y cancelación)

El orden en que se presentan las preguntas es el orden en el que se harán. Dadas las restricciones que se han hecho al proceso de reservación, las siguientes partes se realizarán llenando formularios comunes a cualquier proceso de negocio en la Web:

11. Preguntar datos del cliente que hace la reservación 12. Preguntar tarjeta de crédito:

i. Nombre del titular ii. Numero de la tarjeta

iii. Fecha de vencimiento 13. Proporcionar el número de confirmación

Al final del proceso de reservación, entonces el sistema despedirá al cliente con la fraseología del hotel. Las razones para dividir así el proceso, son las siguientes:

• Se puede recolectar vocabulario necesario para los pasos 1-9 que se muestran, mientras que los nombres de las personas, direcciones, y cualquier otro dato personal no presentan patrones que un número relativamente pequeño de reglas gramaticales, permita procesar.

• Cuando se intercambian datos personales, como número de tarjeta de crédito, siempre es más seguro hacerlo a través de las prestaciones de HTML como los campos de password que ocultan los caracteres que se teclean y los envían cifrados a través de la red.

Posteriormente en la sección 6 se detallará más el proceso de reservación elegido.

Sección 3. 3 Base teórica del sistema



Las herramientas utilizadas para este trabajo y la programación que se realizó involucran los siguientes fundamentos teóricos. 3.1 Agentes 3.1.1 Definición

"Existen dos nociones de agente: una débil y otra fuerte Definición débil:...un sistema computacional hardware o software que goza de las siguientes propiedades:

• Autonomía: los agentes operan sin una directa intervención de humanos u otros, y tienen cierto grado de control sobre sus acciones y su estado interno;

• Habilidad social: los agentes interactúan con otros agentes (y posiblemente con humanos) vía algún tipo de lenguaje de comunicación entre agentes;

• Reactividad: los agentes perciben su ambiente, (que puede ser el mundo físico, un usuario vía una interfaz gráfica, una colección de otros agentes, la INTERNET, o tal vez todos estos combinados), y responden de una manera oportuna a cambios que ocurren en él;

• Pro-actividad: los agentes no actúan simplemente en respuesta a su ambiente, son capaces de exhibir comportamiento oportunista, dirigido por objetivos, tomando iniciativas cuando sea apropiado.

Definición fuerte: un agente, además de las características anteriores tiene una o más de las siguientes características:

• Nociones mentales: un agente tiene creencias, deseos e intenciones. • Racionalidad: un agente realiza acciones a fin de lograr objetivos. • Veracidad: un agente no es capaz de comunicar información falsa de propósito. • Adaptabilidad o aprendizaje".

3.2 Representación del conocimiento A continuación se verán las formas en que se representa el conocimiento en el sistema conversacional a construir. Es difícil definir la palabra conocimiento, pero algunas palabras que lo pueden sustituir son: datos, hechos e información. Para los sistemas inteligentes la forma en que se representa el conocimiento es importante por dos razones:

• El sistema se analiza, diseña e implementa en base a la representación elegida • La forma en que un sistema inteligente representa el conocimiento afecta su

desarrollo, eficiencia, velocidad y mantenimiento. 3.2.1 Marcos y ranuras Un marco (frame) es una colección de atributos, normalmente llamados ranuras (slots), con valores asociados (rellenos), que describe alguna entidad del mundo. A veces el marco describe una entidad en un sentido absoluto, y otras veces representa la entidad desde un punto de vista particular. Fueron introducidos por primera vez en la propuesta de un sistema de visión por Marvin Minsky en 1975. Un marco único, tomado



independientemente, no suele ser útil. En lugar de eso se construyen sistemas de marcos a partir de colecciones de marcos conectados unos con otros en virtud del hecho de que el valor de un atributo de un marco puede ser a su vez otro marco, reglas, imágenes, comentarios, preguntas a los usuarios, hipótesis relacionadas con una situación u otros marcos. Los marcos han sido propuestos como un método para comprender la visión, el lenguaje natural y otras áreas. Proporcionan una estructura conveniente para representar objetos que son comunes a una situación dada, como los estereotipos. Un marco es análogo a la estructura de registro en un lenguaje de alto nivel como en C las estructuras. Un marco es básicamente un grupo de ranuras y rellenos que definen un objeto estereotípico. La utilidad de los marcos recae en los sistemas jerárquicos de marcos y en la herencia que permiten construir sistemas de representación del conocimiento muy versátil. En particular los sistemas basados en marcos son muy útiles para representar el conocimiento causal porque su información está organizada en causas y efectos. Los rellenos pueden ser valores, como una propiedad en la ranura del nombre, o un rango de valores, como en la ranura de tipos. Las ranuras también pueden contener procedimientos adjuntos llamados anexos de procedimiento. Por lo general son de tres tipos:

• Los de si-es-necesario que son procedimientos que se ejecutarán cuando se necesita un valor de relleno pero no hay ninguno presente o el valor predeterminado no es adecuado.

• El tipo si-se-agrega se ejecuta cuando se agrega un valor de una ranura. • El tipo si-se-elimina se ejecuta cada vez que se elimina un valor de una ranura.

Este tipo de procedimientos se ejecuta cuando un valor es obsoleto. Los sistemas de marcos están diseñados para que los marcos más genéricos se encuentren en la parte superior de la jerarquía. Se supone que los marcos pueden personalizarse al modificar los casos predeterminados y crear marcos mas específicos. Los marcos tratan de modelar objetos del mundo real utilizando conocimiento genérico ara la mayor parte de los atributos de un objeto, y el conocimiento especifico para casos especiales. Los marcos también pueden clasificarse por sus aplicaciones:

• Marcos situacionales: Contienen conocimiento sobre lo que se espera en una situación determinada

• Marcos de acción: contiene ranuras que especifican las acciones que se realizarán en una situación determinada. Es decir, los rellenos son procedimientos ara realizar algunas acciones, como eliminar una parte defectuosa de un cinturón de seguridad. Un marco de acción representa conocimiento del procedimiento.

• La combinación de marcos de situación y de acción puede utilizarse para describir relaciones de causa efecto en la forma de Marcos de Conocimiento Causal.

3.2.1.1 Conclusión


12

Nombre del ma que se refieren a: Tipo de habitación Número de habitaciones Número de adultos Número de menores

abitaciones

Lista de observaciones para la reservación llegada

Fecha de salida

3.2.2 3.2.2.1

Una gramática es una 4-tupla (VN, VT, S, Φ) donde:

VN: es un conjunto de símbol bolos no terminales. VT: es un conjunto de símbolos llamados símbolos terminales. S: es un símbolo especial de la gramática llamado símbolo inicial de la gramática. Φ⊆((VN∪VT)*VN(VN∪VT)*)x((VN)∪VT)*).

Para representar un concepto de diálogo los sistemas conversacionales utilizan marcos de conocimiento causal. Los conceptos de diálogo se asocian con marcos. La parte situacional del marco tiene ranuras o conceptos de diálogo que contienen la siguiente información:

• Nombre de la ranura • Palabras clave: Conjunto de frases o palabras que se asocian a la ocurrencia del

concepto en una interacción del usuario. • Pregunta al usuario: En el apartado 3.1 de este documento, se hace referencia a

la característica de pro-actividad de los agentes inteligentes y este es un ejemplo. Cuando el agente necesita conocer información acerca del concepto en cuestión, el agente tiene que proponer esta pregunta al usuario.

• Valor del concepto: Es el valor asociado al concepto que se ha extraído de la intervención.

• Confirmación: Para anunciar al usuario del sistema que el valor asociado al concepto de la conversación ha sido bien entendido, es necesario confirmarlo a través de esta intervención.

• Plantilla de SQL: Cuando en un momento dado, el agente puede realizar una transacción a la base de datos con el valor del concepto.

La parte de acción del marco incluiría las restricciones que se especifican como se agregan y/o eliminan los rellenos de las ranuras; esto es, anexos de procedimientos: si-es-necesario, si-se-agrega y/o si-se-elimina. Más adelante, en el sección 5 y 6, se detallará el comportamiento de estos procedimientos. Cabe mencionar que los principales marcos de la aplicación serán:

rco Ranuras H

Fecha deFechas

Tabla 1: Marcos o frames del sistema

Gramáticas

Definición de Gramática

os llamados sím



13

A los elementos que contiene Φ se les llama reglas gramaticales, reglas de derivación o reglas de sustitución. Cada gramática define el lenguaje formal de todas las sentencias que están formadas exclusivamente por los símbolos terminales a los que se puede llegar mediante derivación a partir del símbolo inicial. Una gramática comienza un símbolo inicial y la aplicación sucesiva de reglas resulta en un lenguaje formal. Ejemplo: Gramática que construye el conjunto de los números reales Reglas de producción:

→ → + | - | ε → | → | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Con esta gramática llegamos al lenguaje formal {0, 1 ,... , 9, 34, 7834, ... } 3.2.2.2 Clasificación de las Gramáticas de Chomsky Esta clasificación consiste en ir poniendo restricciones sobre as reglas gramaticales (Φ). Dentro de esta clasificación se observan cuatro tipos.

Tabla 2 : Tabla con los tipos de gramáticas existentes

Gramáticas sin Restricciones (Tipo 0) En estas no se tienen restricciones a la izquierda ni a la derecha de la producción. Su potencia es la de una máquina de Turing, y sus reglas son del tipo. α = β, donde ( )+Σ∪∈ Vα y donde ( )*Σ∪∈ Vβ . Los conjuntos V y Σ son disjuntos. Una gramática sin restricciones, es una cuatreña de la forma (V, Σ, P, S), donde V es un conjunto de variables o no terminales, Σ (es un conjunto finito de símbolos terminales, P es un conjunto finito de reglas, y S es un elemento de V llamado el símbolo inicial o axioma de la gramática.




Ejemplo:

Dada la gramática G5 = ({S, A}, {a, b}, S, P) donde P = {(S → abAS), (abA → baab),

(S→a), (A → b)}. Determinar el lenguaje que genera.

Solución: Se generan sentencias del lenguaje aplicando las reglas hasta que se pueda ver

la forma general del lenguaje.

S → abAS → babas → baaba

S → a

S → abAS → abbS → abba

S → abAS → abAabAS → … → (abA)n S → (abb)na

S → abAS → abAabAS → … → (abA)nS → (baab)na

S → abAS → abAabAS → abbbaaba

S → abAS → abAabAS → baababba

S → abAS → abAabAS → abAabAabAS → baababbbaaba

L(G5) = {cadenas que contienen abb y baab intercambiándose y reproduciéndose cualquier número de veces, y terminando siempre con el símbolo a} Se puede observar que la forma de expresar este lenguaje no es simple, y surge la necesidad de tener una herramienta que permita describir los lenguajes de otra forma. Gramáticas sensibles al contexto (Tipo 1) Contiene reglas que se ajustan a:

βΑγ = βδγ

Este tipo de producciones, implica que las sustituciones sólo pueden efectuarse en cierto contexto (el símbolo 'A' se podrá sustituir por ' δ ' si y sólo si, está precedido por ' β', y le sigue ' γ '), esto es, son gramáticas sensibles al contexto, por tanto, pueden hacer que un sintagma sea sistemáticamente igual a otro. Obsérvese en el cuadro número 2.2 lo complejo de las reglas necesarias. La complejidad de su análisis es exponencial con la longitud de la cadena de entrada (lo cual es inaceptable con fines de reconocimiento).

Este tipo de gramáticas son las de menor éxito en toda la jerarquía. Ejemplo. La gramática G = (VN, VT, S, P) donde VN ={, }.

VT={0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; S= y las reglas de producción siguientes son

del tipo 1.


15

::=

::=

::=0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Gramáticas independientes del contexto (Tipo 2) Describen los llamados lenguajes de contexto libre, es decir, en ellos se pueden insertar proposiciones dentro de proposiciones, independientemente del contexto de la oración. De acuerdo con Chomsky, una gramática y su lenguaje correspondiente son independientes del contexto, si y sólo si pueden definirse con un conjunto de producciones independientes del contexto. Las gramáticas de contexto libre (o independientes del contexto), son muy importantes en la teoría de los lenguajes de programación, ya que los lenguajes que definen, tienen en general, una estructura muy sencilla. Las técnicas de análisis sintáctico, suelen basarse en gramáticas de contexto libre.

El formato de las producciones según Chomsky será:

α = A

donde α es una cadena, vacía o no, de símbolos terminales o no terminales. Equivale en cuanto a potencia descriptiva, al autómata con pila o Pushdown, y nos permite describir adecuadamente las relaciones intra e inter-sintagmáticas de la lengua natural:

• Concordancia sujeto-verbo. • Concordancia sujeto-atributo. • Inserción de proposiciones en posibles centrales.

La representación gráfica de un análisis de contexto libre es el típico árbol sintáctico, con los símbolos no terminales en los nodos intermedios, y los símbolos terminales en los nodos finales. Como en la figura siguiente

Tabla 3 : Tabla con un árbol de análisis sintáctico



16

Gramáticas Regulares (Tipo 3) Es el descriptivamente más débil. Sus reglas poseen el siguiente formato:

A = aB

donde B puede existir o no. Equivalen en cuanto a poder descriptivo, a los autómatas finitos deterministas y no deterministas. Dado un lenguaje regular, que es aquel que es posible caracterizar usando una gramática de tipo 3, siempre será posible hallar su autómata equivalente.

Cada símbolo no terminal es un estado, cada regla A = aB, una rama que conecta los estados A

y B por medio del símbolo terminal a, y cada regla A = a, nos dice que A se une al estado final

del símbolo a.

Ejemplo:

La gramática G = ({a, b}, {A, S}, S, P) donde P son las producciones que se muestran a

continuación es de tipo 3.

S → aS

S → aA

A → bA

A → b

JERARQUÍA DE LAS GRAMÁTICAS

TIPO 0 TIPO 1

TI

TIPO 2

Figura 2 : Jerarquía de las gramáticas según Chomsky



17

3 Herramientas utilizadas A continuación se presenta una descripción de las herramientas que se utilizaron para realizar el sistema: 3.1 Phoenix Semantic Parser El parser Phoenix está disponible como código libre en el sitio Web [communicator]. 3.1.2 Introducción La herramienta del Parser fue diseñada para el desarrollo de interfaces robustas de lenguaje natural para aplicaciones, especialmente para aquellas de lenguaje hablado. Debido a que el habla espontánea esta a menudo mal formada, y porque el reconocedor puede generar errores, es necesario que el parser sea robusto a los errores de reconocimiento, en su gramática y a la fluidez del habla. Este parser esta diseñado para permitir un análisis confiable de este tipo de entradas. 3.1.3 Teoría de la operación del Parser El parser Phoenix mapea una entrada a una secuencia de marcos semánticos. Un marco de Phoenix es un conjunto de ranuras que tienen nombre, donde las ranuras representan piezas de información relacionadas. La figura 1 muestra un ejemplo de un marco para la solicitud de información de vuelos. Cada ranura tiene asociada una gramática libre de contexto que especifica los patrones de orden de las cadenas de palabras que corresponden a dicho ranura. Las gramáticas son compiladas en Redes de Transición Recursiva (RTNs). Un ejemplo de un marco ya analizado se muestra en la figura 2. Cuando un análisis esta completo, cada ranura contiene un árbol semántico para cada cadena de palabras que son las que lo hacen crecer. La raíz de dicho árbol es el nombre de la ranura.

Figura 3: Ejemplo de un análisis del parser Phoenix



18

Figura 4: Ejemplo de una salida de análisis

El proceso de análisis se muestra en la figura siguiente. El algoritmo de búsqueda es muy similar al proceso de correspondencia para la producción de grafos de palabras. Las gramáticas para los ranura, son relacionadas de nuevo a una cadena de palabras para producir un grafo de palabras. El conjunto de marcos activos define un conjunto de ranuras activos. Cada ranura apunta a la raíz de una Red de Transición Recursiva saciada a él. Estas redes son relacionadas de nuevo a la secuencia de palabras de entrada por un algoritmo de análisis semántico de características Mapa, top-down, y Redes de Transición Recursiva.



19

Figura 5: Ejemplo del proceso de análisis léxico – sintáctico

3.1.4 Escribir gramáticas y marcos semánticos El parser requiere de dos archivos de entrada un archivo de marcos y otro de gramáticas. 3.1.4.1 El archivo de marcos




Este archivo especifica todos los marcos que serán usados por el parser. Un marco representa algún tipo básico de acción u objeto para la aplicación. Las ranuras en un marco representan información que es relevante para la acción u objeto. La sintaxis para la definición de un marco es:

# comment FRAME: nombre del marco NETS: las redes a nivel raíz que se utilizaran en el análisis

[nombre red] [nombre red] [nombre red]

; Ejemplo de un marco para una consulta de reservación de hotel podría ser:

FRAME: Hotel NETS:

[Busqueda_Hotel] [Nombrehotel] [Duracion_hotel] [Localización] [Tipo_habitación] [Fecha_llegada] [Quiero]

; 3.1.4.2 El archivo de gramáticas Los nombres de los archivos de gramáticas tienen la extensión “.gra”. Estos archivos tienen la definición de las gramáticas para cada red. Las definiciones son reglas libres de contexto que especifican los patrones de ordenamiento de las palabras. La sintaxis de una gramática para un token es:

# comentario opcional [nombre_token]

(patrón a) (patrón b)

NT (regla de reescritura para NT)

; El nombre del token está encerrado en corchetes. Después de este sigue un conjunto de patrones de reescritura, uno por línea, cada uno encerrado por paréntesis, con un espacio en blanco al inicio de cada línea. Después de los patrones de reescritura básicos siguen las reglas no-terminales de reescritura, las cuales tienen el mismo formato. La notación usada para la especificación de los patrones es:



• Cadenas de letras minúsculas son terminales. • Cadenas de letras mayúsculas son no terminales. • Los nombres encerrados entre [] son llamadas a otras redes. • Expresiones regulares

* dato indica 0 o 1 repeticiones de ese dato + indica 1 o mas repeticiones +* indica 0 o mas repeticiones (equivalente a la estrella Kleene)

• #include lee el archivo que contiene las reglas de reescritura no-terminales.

Un ejemplo de reglas gramáticas para los tokens [petición_reservacion] y [deseo] son:

[peticion_reservacion] (*[deseo] *UN HOTEL)

UN

(una) (un) (unas)

HOTEL (hotel) (motel) (habitación) (habitaciones) (lugar para quedarme)

;

[deseo] (*YO DESEO)

I

(yo) (nosotros)

DESEO

(queremos) (quiero) (deseo) (deseamos) (quisiera)

; El análisis de una oración como:

“quisiera una habitacion“ Sería así:

[peticion_hotel]([deseo]( quisiera) una habitación))



Sección 4. 4 Análisis del lenguaje natural 4.1 Proceso de creación de la gramática 4.1.2 Inferencia Gramatical y Programación Dirigida por Sintaxis En los años 60s se había comenzado a desarrollar un conjunto de métodos y técnicas orientadas a la obtención de gramáticas a partir de ejemplos de oraciones de este lenguaje. A este conjunto de herramientas se les englobo con el nombre de Inferencia Gramatical. A partir de un conjunto de ejemplos de un lenguaje se puede encontrar la gramática que describe el lenguaje y a partir de la gramática se puede construir un compilador o interprete capaz de reconocer las oraciones del lenguaje. La Programación dirigida por Sintaxis es el proceso de desarrollar sistemas a partir de ejemplos del lenguaje con el que se quiere dar órdenes al sistema.

Para la obtención de la gramática que define al lenguaje, se utiliza la inferencia gramatical consiste en encontrar una gramática a partir de un conjunto de ejemplos del

lenguaje que se quiere representar. Dicho de otra forma, la Inferencia Gramatical trabaja con la estructura de las oraciones del lenguaje buscando encontrar una estructura

general o regla sintáctica a partir de estructuras particulares u oraciones canónicas

4.1.3 Pasos para obtener la gramática del Lenguaje Primero se tiene que encontrar ejemplos del lenguaje a partir del cuál se desea obtener, la gramática. Después se siguen los siguientes pasos:

• Detección de las unidades léxicas del lenguaje. Se analizan las oraciones de ejemplo recopiladas para detectar los componentes que representen la estructura de la oración y darles un nombre. Este nombre puede tener un significado semántico diferente para cada aplicación.

• Obtención de una Gramática Generativa Canónica

Se hace mediante la sustitución de cada una de las unidades léxicas en las oraciones por un símbolo que indica su tipo de unidad léxica e introduciendo un axioma que genera las oraciones.

Una vez definido el vocabulario y con la lista de ejemplos de oraciones del lenguaje se obtiene una Gramática Canónica sustituyendo cada unidad léxica en las oraciones de ejemplo por su tipo de unidad léxica e integrando todas las oraciones resultantes en una gramática.



4.1.4 Ejemplo Con la ayuda de la notación vista para el Phoenix parser (sección 4, sección 4.2.3), se mostrará como puede aplicarse la inferencia gramatical para la obtención de la gramática Sean algunos ejemplos de frases para el dominio elegido: “Deseo una reservar una habitación” “Quisiera unos cuartos” “unas habitaciones” Aplicando el primer paso, se tienen los siguientes componentes: DESEO

(deseo) (quisiera)

ART (una) (unos) HABITACION (reservar una habitación) (cuartos) Aplicando el segundo paso se introduce un axioma que genere las oraciones del lenguaje.

[Reservac_reservacion] (*DESEO *ART HABITACION)

4.2 Análisis léxico y sintáctico del lenguaje Se utiliza el parser Phoenix, para mapear la interacción con el usuario en una secuencia de marcos semánticos. Un marco construido por el sistema Phoenix es un conjunto de ranuras con nombre, donde dichas ranuras representan partes relacionadas de información. Cada ranura tiene asociado una Gramática Libre de Contexto (CFG), que especifica el patrón de orden de las palabras que pueden contener las ranuras o slots. Las gramáticas son compiladas en Redes de Transición Recursiva, que son cotejadas con la entrada del usuario para llenar las ranuras. Cada ranura llenado contiene un árbol semántico con el nombre de la ranura como raíz El resultado que Phoenix proporciona al manejador de diálogo es una representación extraída del análisis, que es mapeada directamente a frames conceptuales de la tarea o conceptos de diálogo. Por ejemplo:

“Deseo reservar dos habitaciones para el jueves”

Lo que produciría el proceso de análisis seria:



Reservación: [Acción].reservar Reservación: [Habitaciones].[Numero].dos Reservación: [Fecha].[Dia].jueves 4.3 Análisis semántico del lenguaje El análisis semántico del lenguaje lo lleva a cabo el manejador de diálogo (ver sección 1, sección 1.2). El manejador del diálogo está organizado como un sistema de producción, normalmente éste se encuentra en un estado inactivo esperando por un evento de entrada. Cuando se recibe la entrada, se toman un conjunto de acciones, se regresan los resultados al usuario, y entonces regresa a su estado inactivo. El manejador del diálogo es el responsable de varias funciones

• Recibir análisis del módulo de Análisis (módulo de Procesamiento de Lenguaje Natural)

• Resolución de elipsis (elipsis es la omisión de una o varias palabras en una oración)

• Aclaración • Actualización del contexto • Preguntar por información • Información a la salida para el usuario • Generar consultas a la base de datos

La estructura de datos básica para la representación de información de un dominio son los marcos. Un marco tiene un nombre y un conjunto de ranuras. Cada ranura es un concepto jerárquico de dialogo con el nombre de ranura como la raíz como se muestra en al figura. La información se extrae del análisis y se almacena directamente en los marcos o conceptos de diálogo por el manejador del diálogo. En el mejor caso, la estructura conceptual en estos marcos es la misma que la producida por el analizador, si es así, el manejador del diálogo extrae el marco de información del analizador directamente.

Habitación: [Habitación]. [Tipo] [Número] [Personas]. [Adultos] [Menores]

Ejemplo 1: Estructura de un marco del sistema Hay una tabla en la base de datos del sistema de donde los marcos obtienen la información de las ranuras que necesitan:


25

Figura 6: Tabla con los conceptos de diálogo del sistema (ranuras o slots)

• La clave corresponde con el nombre de una ranura • El comentario es meramente informativo • Prompt: es una plantilla para realizar preguntas. • Confirmación es una plantilla para generar las confirmaciones de información

del usuario. 4.3.2 Recibir el análisis El módulo de manejo del manejo del diálogo recibe el análisis del módulo de Procesamiento de lenguaje natural. Estos análisis son secuencias de extracciones del analizador. El manejador del diálogo debe extraer la información del analizador y almacenarla en sus propios marcos. Este proceso toma varios pasos:

1. Mapear a la forma canónica 2. Resolución de elipsis 3. Ejecutar funciones del contexto 4. Incorporar los marcos en el contexto

4.3.3 Mapeando a la forma canónica Con frecuencia, la forma en que los usuarios especifican información no es la misma forma en que el sistema la necesita para usarla. Algunos ejemplos son las fechas y horas. El usuario puede decir “Mañana”, pero el sistema necesita un número de mes y número de día. Los formatos preestablecidos de utilizar números de mes y no nombres de meses, es lo que se llama forma canónica. Por ejemplo, de la entrada hablada:

Reservación: [Fecha].[Relativo].MAÑANA Se necesita obtener:

Reservación: [Fecha].[Dia]. 1 Reservación: [Fecha].[Mes]. 5

El sistema provee una lista de funciones canónicas que se encargan de transformar la información obtenida en la forma canónica que utiliza el sistema. Esta lista asocia un nombre de token como [Fecha] con una función para poner el árbol en forma canónica. La función reemplaza la entrada con una versión canónica. Por ejemplo, la función para [Fecha] tomaría la cadena [Fecha].[Relativo].MAÑANA y la reemplazaría por :

[Fecha].[Dia]. 1 [Fecha].[Mes]. 5.




Cuando el manejador del diálogo recibe un análisis, éste ejecuta un procedimiento llamado extractValues() para obtener la información del análisis en marcos. El método extractValues() busca en el análisis por algún nombre de token que estén en la tabla de funciones canónicas. Cuando encuentra un token en la tabla, ejecuta las transformaciones adecuadas. 4.3.4 Resolución de elipsis La entrada analizada puede ser mal especificada desde el punto de vista del mapeo de la entrada a un marco. Esto significa que el token inicial en la cadena analizada no es una ranura dentro de un marco en el archivo de tareas, pero aparece solo como una pequeña parte de una ranura. Un ejemplo es cuando un usuario dice simplemente cuatro, el análisis arrojaría el siguiente resultado: Reservación :[Numero].dos. El marco tiene los siguientes conceptos de diálogo:

• [Habitaciones].[Numero] • [Personas].[Numero],

El sistema necesita saber el numero es un número de habitaciones o un número de personas. El manejador del diálogo intenta resolver este token “elíptico” en claves completamente especificadas, empezando por el nombre de la ranura. En este ejemplo, el sistema transforma [Numero].dos a [Habitaciones].[Numero].2, suponiendo que el concepto más reciente del que se ha hablado son las habitaciones. 4.3.5 Funciones de Contexto Los eventos en el análisis de entrada pueden necesitar tomar otras acciones en el contexto, además de solo obtener sus valores extraídos. Por ejemplo, en el token de entrada [Terminar] hace que el sistema termine la instancia que atiende al usuario que dio esa intervención. El token de entrada [Reset] hace que el sistema vuelva a reiniciar al estado inicial del sistema. En un mecanismo como las funciones canónicas, las acciones de contexto son especificadas en una lista y asociadas con un token. Cuando el token es extraído del análisis, la función asociada se ejecuta. 4.3.6 Incorporar contexto Hay dos listas globales de objetos, Context y Extract. Extract es la nueva lista de conceptos de diálogo que se han encontrado en la última interacción con el usuario. El contexto es un conjunto de marcos que contienen información que fue creada previamente por interacciones en la sesión. La nueva información se integra en el contexto llenando ranuras en los marcos existentes.



Una vez que se han aplicado las funciones canónicas, la clave se ha transformado en una clave completa, y las funciones de contexto se han ejecutado, los valores analizados se extraen a una secuencia de marcos analizados que se ponen en la lista de Extract. Cuando todas las líneas del análisis se han extraído, la lista de Extract se integra con la lista de Context. 4.3.7 El conmutador de acciones Después de que la información se extrajo y se incorporó al contexto, el método switchNextAction() (conmutador de acciones) es llamado para determinar la próxima acción del sistema. Aquí se examina el contexto y toma una acción basada en un orden de prioridades previamente especificado. La toma de decisiones de que acción tomar en seguida se rige por un protocolo que se conforma de 9 prioridades:

1. Se verifica si se han concluido todas las transacciones y/o confirmaciones y si es así, se termina el diálogo.

2. Si existe una petición de terminar, reiniciar el manejador del diálogo, éste es terminado o reiniciado

3. Si existe una petición de que se repita la ultima intervención del usuario, ésta es enviada a la salida.

4. Si hay preguntas, aclaraciones pendientes por realizar estas se mandan a la salida.

5. Verificar si consultas para realizar a la base de datos pendientes para presentarle al usuario

6. Si los valores de las ranuras de los marcos no están completas (faltan puntos por conocer para completar el diálogo), completarlo preguntando por la información que falte.

7. Confirmar los marcos para verificar que la información este completa. 8. Crear la consulta o transacción final a la base de datos, y realizarla con lo que se

completa el objetivo de la tarea de la interfaz. 9. Como ultima opción (es decir, no se pudo cumplir nada de lo anterior)

despedirse del usuario y terminar. La lógica del conmutador de acciones no es muy específica de una tarea. Hace transacciones con eventos de dialogo en general, de alto nivel, no necesita cambiarse mucho de una aplicación a otra. 4.3.8 Mandar peticiones al usuario. El manejador del dialogo manda diferentes tipos de salidas a los usuarios:

• Pregunta por información • Da información al usuario • Mensajes de error

Las intervenciones del manejador del diálogo con la fraseología del hotel. El conjunto de intervenciones que la máquina hace al usuario se almacena en la base de datos.


28

4.3.9 Generar preguntas Cualquier ranura de los marcos puede tener una plantilla de preguntas asociado con el. La plantilla es usada para generar una pregunta para la información especificada por la ranura. Cuando el sistema necesita un fragmento de información, llena el plantilla de preguntas asociado del contexto y lo manda a la salida del usuario. Las plantillas de preguntas se especifican en la tabla de ranuras presentada. Para decidir por que plantilla se preguntará, el manejador del diálogo pone un marco en foco y ejecuta el método completeFrame() para completar cualquier parte de información faltante en el marco. completeFrame() devuelve la plantilla de pregunta al primer spot que encuentre vacío. Si el manejador del diálogo está por preguntar por una ranura, y una parte del marco ya esta llena, entonces pregunta por otra pequeña parte de información en el mismo. Esta característica se aplica en situaciones como la que se describe abajo. La estrategia del manejador del diálogo es preguntar por las ranuras más generales primero y preguntar más específicamente por la información que le falte. 4.3.10 Generación de consultas a la base de datos El manejador de diálogo, puede realizar consultas a la base de datos de manera transparente. Hay ciertas intervenciones del usuario que el manejador no puede integrar al contexto, todas estas intervenciones son tratadas como consultas. Las consultas del usuario se asocian con claves especiales que sirven como llave primaria de una tabla en la base de datos.

Figura 7: Tabla de consultas del sistema

Supongamos que la interacción del usuario es: “¿Dónde está ubicado el hotel?” Así por ejemplo, la “consulta” tiene un preámbulo a la respuesta que se almacena en la tabla RESULTADO. Por ejemplo: “El hotel esta ubicado en”. Si el resultado de la consulta se puede colocar dentro de la misma conversación, entonces habrá un registro asociado en la tabla URESULTADO. Por ejemplo, utilizando la Figura anterior: “el centro de la ciudad de México”




Cuando se desee asociar una pagina Web con contenido independiente de la base de datos el campo texto de la tabla PRESULTADO, contendrá una página que se mostrará en la interfaz de usuario del sistema sobre el navegador del usuario. Por ejemplo, utilizando la Figura anterior, podría aparecer un mapa con la localización del hotel. Si además el resultado tiene asociado una consulta, el campo texto de la tabla CRESULTADO tendrá una sentencia SQL que de acuerdo con el valor del campo PANTALLA se podrá integrar a la respuesta dentro de la conversación o dentro de una página con título igual al campo con el mismo nombre, asociada a la respuesta.

Sección 5. 5 Análisis y diseño del sistema A continuación se muestra un análisis detallado de la funcionalidad que debe tener el sistema conversacional presentado, quiénes son las personas que deben interactuar con él, de qué manera, qué datos o información fluye en el sistema y los resultados que debe arrojar el sistema según la intervención expresada, etc. 5.1 Análisis 5.1.1 Actores del sistema.

Nombre: Cliente Participa en casos de uso: Reservar, Cancelar por sistema, Solicitar información, Registrar usuario, Registrar pago, Realizar visita virtual. Descripción Un cliente es una persona física (a diferencia de una persona moral) que se comunica a un hotel para realizar una reservación, cancelarla o cambiarla. Es la persona a nombre de la cuál se realiza la reservación.

Nombre: Administración del hotel Participa en casos de uso: Cerrar categorías, Generar reservaciones diarias. Descripción Un hotel o la administración del hotel tienen un sistema de administración del hotel. Este pudiera ser computarizado por lo que el departamento de reservaciones tendría que hacer interfaz con él. En otro caso la comunicación se realiza por medio del personal de la administración del hotel y el departamento de reservaciones. La administración del hotel necesita datos acerca de la estimación de ocupación esperada, permitiendo de esta manera a los que llevan la administración planear sus necesidades personales y controlar sus gastos de nómina.

Un pronóstico adecuado por el departamento de reservaciones puede tener una gran



influencia sobre la eficiencia total de la operación y la rentabilidad de los departamentos afectados por la estimación. 5.1.2 Casos de uso del sistema

Nombre Registrar usuario Paquete Interfaz de usuario Relaciones Ninguna Actor participante Llamado por Cliente Condición inicial Haber iniciado el caso de uso Reservar Flujo de eventos

1. El usuario solicita por escrito al sistema su registro. 2. El registro consiste en escribir su nombre, apellidos, dirección,teléfono, e-mail, un nick de usuario y un password en un formularionormal en el sitio Web del hotel. El sistema almacena está información en la base de datos. Se proporciona un número de socioy una clave para posteriores ingresos a la página del sistema. 3. Si el usuario ya esta registrado, entonces, deberá proporcionar sunúmero de socio y su clave. 3. Si la tupla socio-clave es inválida, la interfaz de usuario indicará la causa del error. De otra manera se despliega una pantalla con losdatos recién ingresados a manera de confirmación.

Condición de salida El cliente se identificado o se ha registrado en la base de datos del sistema.

Notas Los datos que el cliente debe registrar son:

• Nombre • Apellido paterno, materno. • Dirección • Teléfono • E-mail • Nick • Password

Requerimientos especiales.

Para registrarse todos los requerimientos anteriores deben serllenados.

Nombre Registrar pago Paquete Interfaz de usuario



Relaciones Ninguna Actor participante Llamado por Cliente Condición inicial Haber iniciado el caso de uso Reservar Flujo de eventos

1. Cuando el proceso de reservación está por terminar, el sistema muestra al usuario un formulario con los campos necesarios para elpago de la reservación, a saber:

• Tarjeta, clave, vencimiento 2. También se proporciona al usuario la comodidad de especificar siva a llegar por avión y si es así, el número de vuelo por el que va a llegar, para que el servicio de transporte del hotel lo recoja 3. Si la reservación es exitosa y si el cliente así lo solicita la información de la reservación se envía a su correo, ejecutándose elcaso de uso Solicitar envío de correo electrónico 4. El sistema se despide del usuario con la fraseología del hotel

Condición de salida Los recursos necesarios para realizar el proceso de reservación seliberan

Notas Los datos que el cliente debe registrar para este caso son:

• Nombre de la tarjeta • Número de tarjeta • Vencimiento de la tarjeta • Línea por la que llega (Opcional) • Número de vuelo (Opcional) • Confirmación de que desea la información en su email.


Para registrar el pago y que la reservación sea exitosa, los requerimientos de pago deben ser llenados

Nombre Reservar Paquete Interfaz con usuario Relaciones Ninguno Actor participante Llamado por Cliente Información

La interfaz para el proceso de reservación a la que llamaremos gestorde la reservación dirige la lógica y el dialogo con el que se negociacon el usuario.

Condición inicial Ninguna Flujo de eventos



1. El gestor de la reservación recibe de la interfaz de usuario, lasintervenciones del usuario. 2. Los conceptos mencionados en el sección dos de este documento son tratados en el orden establecido para registrar la reservación. 3. El diálogo termina cuando se han recopilado los datos necesariospara dar de alta la reservación y el cliente los ha confirmado alsistema. 4. Si el usuario no se ha registrado, entonces se solicita su registro através de la ejecución del caso de uso Registrar usuario 5. Si la reservación ha sido exitosa; es decir, el cliente ha aceptadolos términos de la reservación, entonces se ejecuta el caso de usoRegistrar pago.

Condición de salida Si la reservación se lleva a cabo, se actualiza la base de datos delsistema y se proporciona al usuario un número de reservación.

Notas Los conceptos de diálogo y el proceso de reservación completo selista en el sección 2 de este documento.


El proceso de reservación es concurrente porque pueden existirmuchos usuarios realizándolo al mismo tiempo, por lo que el accesoa la base de datos debe estar sincronizado

Nombre Consultar Paquete Interfaz con usuario Relaciones Ninguna Actor participante Llamado por el cliente. Condición inicial Haber iniciado una instancia de alguno de los casos de uso:

Reservar. Flujo de eventos

1. El cliente realiza una intervención en el diálogo que se está llevando a cabo consultando por información. La solicitud deinformación se da en base a una pregunta implícita del usuario ocuando las intervenciones no puedan se incorporadas al contexto delproceso de reservación 2. El sistema hace la consulta pertinente a la base de datos. 3. Los resultados de la consulta pueden venir en forma de una páginaWeb o incorporadas dentro de una intervención del sistema



Condición de salida La información solicitada en la consulta es mostrada al usuario Notas El tipo de consultas que el sistema puede responder se mencionan en

el capitulo 7 del presente documento. Requerimientos especiales.

Ninguno

Nombre Cancelar por sistema Paquete Interfaz con usuario Relaciones Ninguno Actor participante Llamado por Cliente Condición inicial Haber finalizado una instancia del caso de uso: Reservar. Flujo de eventos

1. El cliente solicita de manera escrita la cancelación de sureservación. 2. El sistema presenta una página Web donde se solicita el númerode reservación a cancelar. 3. Si el número de reservación es válido, el sistema da de baja lareservación, desbloqueando el número de habitaciones que se hanreservado. 4. Se anuncian al cliente las políticas de cancelación para queconozca en caso de que existan, las sanciones a las que se hace acreedor por cancelar.

Condición de salida Borrar los registros correspondientes a la reservación que se cancela,y realizar las acciones correspondientes a las políticas del hotel encaso de cancelación.

Notas Ninguno Requerimientos especiales.

Ninguno

Nombre Realizar visita virtual Paquete Interfaz con usuario Relaciones Ninguna Actor participante Llamado por Cliente Condición inicial Haber iniciado una instancia de alguno de los casos de uso:

Reservar. Flujo de eventos

1. El cliente solicita al sistema una visita virtual a uno de los cuartosde hotel. 2. Se muestra una pantalla al cliente con las imágenes de la visita



virtual. El cliente manipulará con el mouse estas imágenes a suconveniencia para visualizar el cuarto de hotel.

Condición de salida Las imágenes de la visita virtual una vez mostradas permanecerán enla pantalla del usuario.

Notas Ninguno Requerimientos especiales.

Ninguno.

Nombre Solicitar envío de correo electrónico Paquete Interfaz con usuario Relaciones Ninguna Actor participante Llamado por Cliente Condición inicial Haber iniciado una instancia el caso de uso: Registrar pago Flujo de eventos

1. El cliente puede solicitar el envío del proceso de reservaciónconcluido. 2. El sistema recopila la información necesaria y la envía al correoproporcionado durante el registro del cliente.

Condición de salida La información se ha enviado al usuario en un correo electrónico Notas Ninguno. Requerimientos especiales.

Enviar la información inmediatamente cuando así lo desee el usuario.

Nombre Administrar categorías Paquete Configuración de administrador Relaciones Ninguna Actor participante Llamado por Hotel Condición inicial Ninguna Antecedentes

Día a día el hotel debe analizar el número de reservaciones que tiene a la mano o en proyecto, y tomar una determinación en cuanto acerrar o no las reservaciones en ciertos niveles de tarifas. La decisiónsobre los niveles de tarifas aceptables, se hace como resultado de laacumulación de reservaciones. Por tanto, a medida que se acumulalas reservaciones para una fecha en particular, un hotel cerrará (ya noaceptará) las reservaciones empezando por la categoría mínima,después seguirá con la normal, la superior y tal vez aceptaráfinalmente sólo las reservaciones para suites. El estado de lasreservaciones de un hotel puede, por tanto, clasificarse como sigue: - Tarifa mínima (habitaciones superior y superior doble): Se aceptan todas las reservaciones. - Tarifa máxima (habitación Junior king suite, Junior king doble):



Se aceptan reservaciones sólo de tarifa máxima para arriba. - Suite únicamente. (Habitación de lujo king). - Cierre de llegadas: Ya no se aceptan reservaciones para llegadas en una fecha específica. - Reservaciones después de un límite nulas: no se aceptan reservaciones cuando la permanencia del huésped se prolongaráhasta después de una fecha específica. Habrá una interfaz de usuario que guiará a la administración delhotel para abrir o cerrar categorías de habitaciones

Flujo de eventos 1. El hotel realiza la selección de cuales categorías de habitación hayque cerrar, a través de un formulario que liste las categorías o tiposde habitación. 2. Se realiza las modificaciones pertinentes a la base de datos.

Condición de salida Las categorías o clases de habitación que la administración del hotelo el hotel desea cerrar son marcadas como no elegibles para serapartadas en próximas reservaciones, por lo que el sistema impedirácualquier intento de los usuarios por reservar habitaciones que fueron cerradas

Notas Ninguna. Requerimientos especiales.

Los cambios realizados a la base de datos en cuanto a lashabitaciones, se aplicarán inmediatamente.

Nombre Generar informe de reservaciones diarias Paquete Configuración de administrador Relaciones Ninguna Actor participante Llamado de información Hotel Condición inicial Ninguna Flujo de eventos

1. Cada día el gestor de archivo debe informar de las reservacionescuyo registro se realizará dicho día. 2. El sistema, a través de una interfaz de usuario desplegará la listade reservaciones formateada en la interfaz del gestor del archivo queel Hotel podrá imprimir

Condición de salida Las reservaciones para la fecha actual se mostrarán en pantalla unaocasión en el día para que el Hotel pueda imprimirlas

Notas La información de salida será una tabla con las siguientes columnas:Nombre del huésped, tarifa, fecha de llegada y permanencia en elhotel.


Ninguna


36

5.2 Diseño UML Los diagramas de diseño del sistema conversacional propuesto se realizaron con UML y la herramienta CASE Rational Rose. 5.2.1 Diagrama de casos de uso El diagrama de casos de uso se divide en dos paquetes:

Interfaz con usuario

Configuración de administrador

Figura 8: Paquetes de casos de uso del sistema

Para el paquete de la interfaz de usuario:

Reservar

Consultar Registrar usuario

Registrar pago

Solicitar envio de correo electrónico

Realizar visita virtual

Cancelar

Cliente

Figura 9: Diagrama de casos de uso del paquete de Interfaz con usuario

Para el paquete de configuración de administrador

Administrar categorías Generar informe de reservaciones diariasAdministración del hotel

Figura 10: Diagrama de casos de uso del paquete de Configuración de administrador



37

El caso de uso Reservar, tiene el siguiente diagrama de estados:

Esperando interacción con el usuarioentry : Reinicializar contador de espera

Buscando inf ormaciónentry : Buscando parámetros consultaexit: Almacenar última consulta

Entendiendo interacciónentry : Ejecutar análisisexit: Av isar agente

Ejecutando orden

Integrando al contextoentry : Guardar estados anteriores

Consulta entendida

Orden entendida

Interacción contextual entendida

orden ejecutadaResultados mostrados

Generando Interv enciónentry : Buscando inf ormación f altante

Interv ención mostrada

Inicializando agenteentry : Inicializar módulo de LN

Presentar bienv enida

Interv ención del sistema generada

Terminando procesoentry : Asignando cliente y pagoexit: Generando resumen reserv ación

Contexto completo

Interacción del usuario

Tiempo de espera agotado

Figura 11: Diagrama de estados del caso de uso Reservar

El caso de uso Registrar usuario tiene el siguiente diagrama de estados:



38

Captura de datos para accesoentry: Recibe datos del usuarioexit: Mandar datos a validar

Datos incompletos

Validando datos

Datos completos

Insertar datos en la base de datosentry: Validar datos con la tabla de clientes

Datos incorrectos

Solicitud de validación

Usuario válido / no válido

Usuario reconocidoentry: Enviar datos del cliente al manejador de diálogo

Usuario válido

Figura 12: Diagrama de estados del caso de uso Registrar usuario

El caso de uso Registrar pago tiene asociado el siguiente diagrama de estados:

Captura de datos del pagoentry: Recibir datos de la tarjeta de créditoexit: Mandar datos a validar

Datos incompletos

Validando datos

Datos no correctos

Insertar datos en la base de datosentry: Validar datos con las tablas de tarjeta

Solicitud de validación

Datos válidos

Desplegando información de la reservaciónentry: Datos de la reservación

Datos de reservación y pago válidos y aceptados

Figura 13: Diagrama de estados del caso de uso Registrar pago



39

5.2.2 Diagrama de clases Los paquetes de clases del sistema.

Database

Knowledge

Business

Site

Figura 14: Paquetes de clases del sistema

El paquete Database está compuesto de clases que permiten el acceso concurrente y sincronizado a la base de datos:

ManagerConnectionPool1..1 0..*da servicio1..1 0..*

Figura 15: Clases principales del paquete de clases Database

El paquete Business está compuesto por las siguientes clases:

Aerolinea

Cliente

(from Interfaz con usuario)

RemarkHabitacionTarjeta Reservacion ReservaciónRemark

Mensaje

Start Terminar

BusinessObject

RepeatErrorBookingConcluded

Resultado

Figura 16: Diagrama de clases del paquete Business



40

La clase BusinessObject encapsula métodos de acceso a la base de datos y las clases que se derivan de ella, implementan la semántica propia de las tablas de la base de datos. La clase Mensaje, se utiliza para el intercambio de objetos amanera mensajes entre los diversos componentes de la aplicación. La clase Resultado se utiliza como un medio de comunicar los resultados de las intervenciones con la aplicación. El paquete Knowledge, encapsula clases para el manejo del conocimiento, heurística necesaria para llevar a cabo una reservación y la clase que representa el agente a cargo del proceso de reservación: HotelManager.

FrameHabitaciónFrameFecha

ParsedDateFrame

ParsedGearFrame

ParsedNumberFrame

ParsedQueryFrame

ParsedRoomFrame

ParsedSenteceFrame

Slotvalor : Object

ParsedFrame

transform()checkEvents()

Knowledge.Frame

completeFrames()confirmFrames()mergeContext()

1..*

1..1

1..*

1..1

tiene

1..* 1..11..* 1..1

utiliza

HotelManager

receive()extractValues()switchNextAction()

2

1

2

1maneja

EventHandler implementa

AllParses

getPhoenixInput()

1..1

1..1

1..1

1..1usa

Phoenix

usa

Figura 17: Diagrama de clases del paquete Knowledge

Las clases que se extienden de ParsedFrame, implementan el análisis semántico de los marcos semánticos que provienen del proceso de entendimiento en el Phoenix parser. Las clases que se extienden de Frame, implementan el conocimiento, creencias e intenciones que el agente maneja. Las dos clases derivadas son FrameFecha y FrameHabitación y son las dos únicas clases que representan el conocimiento, por ello la cardinalidad que se muestra en la relación de HotelManager a Knowledge.Frame es 1:2. Las clases que se extienden de Frame, almacenan su conocimiento en ranuras que son objetos del tipo Slot, donde se almacenan realmente los conceptos de diálogo, las plantillas de preguntas, confirmaciones y SQL necesarias para dar al agente las características que tiene.



41

La clase AllParses tiene el método getPhoenixInput a través del cual, obtiene la entrada del parser Phoenix que funciona como un servidor al que el sistema se conecta. Para fines de representación, el servidor Phoenix se muestra como una interfaz de la que la implementación de getPhoenixInput depende. La clase HotelManager es la clase cuyas instancias poseen las características de agente mencionadas en el capitulo 4, implementa la interfaz EventHandler, a través de la cual se recibe las intervenciones del cliente. Un diagrama de secuencia explicará el comportamiento del sistema:

unCliente : ClienteUI

unaInstancia : ServidorAtención

unAgenteDeServicio : Hotel

parsesDePhoenix : AllParses

framesSemánticos : ParsedFrame

conocimientoDelSistema : Frame

: Phoenix

doGet( )

receive(Object)

extractValues( )

getPhoenixInput( )

transform( )

checkEvents(EventHandler)

EventHandler es una interfaz implementada por la clase HotelManager

mergeContext( )

receive( )

showUser( )

doParseInput( )

swi tchNextAction( )

Figura 18: Diagrama de secuencia que muestra la ejecución del sistema

La explicación es la siguiente: El unCliente se comunica con el servidor de atención al cliente que es un servlet. El servlet guarda la sesión del cliente y cuando recibe un mensaje de entrada, instancia un objeto de la clase HotelManager unAgenteDeServicio. A este objeto se le pasan las intervenciones o mensajes del usuario. unAgenteDeServicio tiene un objeto de la clase AllParses que se comunica directamente con el servidor de entendimiento de lenguaje natural. El servidor regresa de acuerdo a la entrada del usuario, un conjunto de frames semánticos, que son transformados a conceptos de diálogo por medio de los métodos, transform y checkEvent. Las transformaciones hechas se comunican con unAgenteDeServicio a través de la interfaz EventHandler. Cuando el proceso de transformación termina, la instancia de HotelManager, utiliza su cono

Resumen.- Versión abreviada y precisa del proyecto que se...

Documents

Transcript of Resumen.- Versión abreviada y precisa del proyecto que se...