interfaces con agentes animadoslorien.die.upm.es/juancho/pfcs/jhp/maquetaci%a2n.doc · web viewel...

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAInformación del proyecto

Información del proyecto

1 Sobre el proyecto

Título: Utilización de agentes animados para interfaces avanzadas de ayuda.

Autor: Jesús Heras Parra.

Tutor: Juan Manuel Montero Martínez.

Departamento: Ingeniería Electrónica de la Escuela Técnica Superior de Ingenieros de Telecomunicación de Madrid (Universidad Politécnica de Madrid).

Grupo: Tecnología del Habla.

2 Sobre el tribunal

Presidente: D. José Manuel Pardo Muñoz. Firma:

Vocal: D. Ricardo de Córdoba Herralde. Firma:

Secretario: D. Juan Manuel Montero Martínez. Firma:

Suplente: D. Javier Macías Guarasa. Firma:

Fecha de lectura:

Calificación:

II

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAInformación del proyecto

3 Resumen

Este Proyecto Fin de Carrera es un estudio sobre las potencialidades de los agentes animados, en la tarea de complementar a las tecnologías del habla, para crear interfaces de usuario atractivas. Como aplicación práctica, se presenta un programa que emplea un personaje animado (basado en la plataforma Microsoft Agent®) capaz de comunicarse con el usuario vía voz y el cual está dotado de movimiento, incluyendo gesticulación, para mejorar su expresividad.

III

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAIndice

Indice

INFORMACIÓN DEL PROYECTO...........................................................................II

1 SOBRE EL PROYECTO.............................................................................................II2 SOBRE EL TRIBUNAL..............................................................................................II3 RESUMEN.............................................................................................................III

INDICE..........................................................................................................................IV

1 INTRODUCCIÓN...................................................................................................2

1.1 PRESENTACIÓN...................................................................................................21.2 PUNTO DE PARTIDA............................................................................................31.3 OBJETIVOS.........................................................................................................41.4 COMPONENTES SOFTWARE................................................................................41.5 ORGANIZACIÓN DEL PROYECTO.........................................................................6

2 INTERFACES CON AGENTES ANIMADOS....................................................8

2.1 NECESIDAD DE INTERFACES DE USUARIO AMIGABLES......................................82.2 DESARROLLO DE LAS INTERFACES DE USUARIO (IU).......................................82.3 INTERFACES DE USUARIO CON PERSONAJES ANIMADOS....................................92.4 ELEMENTOS DE CONVERSACIÓN CARA A CARA CON PERSONAJES ANIMADOS.112.5 DIRECTRICES PARA EL DISEÑO DE LA INTERACCIÓN CON PERSONAJES...........13

2.5.1 Emplear sonido........................................................................................132.5.2 No ser exclusivo.......................................................................................142.5.3 Proporcionar la apropiada realimentación............................................142.5.4 Usar variaciones naturales.....................................................................152.5.5 Interacción social....................................................................................152.5.6 Uso de gestos...........................................................................................162.5.7 Crear una personalidad..........................................................................172.5.8 Aspecto físico...........................................................................................182.5.9 Observar el protocolo apropiado............................................................192.5.10 Usar la alabanza.....................................................................................202.5.11 El personaje y el usuario como miembros del mismo equipo.................212.5.12 Considerar efectos de género..................................................................22

2.6 SONIDO COMO INTERFAZ DE USUARIO............................................................232.6.1 Presentación............................................................................................232.6.2 Reconocimiento del habla.......................................................................23

2.7 ADAPTACIÓN A LAS CARACTERÍSTICAS ESPECIALES DE LAS SUIS.................252.8 SIMULAR POR PARTE DEL SISTEMA UNA CONVERSACIÓN DE LA FORMA MÁS REAL Y NATURAL QUE SEA POSIBLE.............................................................................25

3 CARACTERÍSTICAS DE MICROSOFT AGENT®........................................28

3.1 POTENCIAL DE MICROSOFT AGENT 2.0...........................................................283.2 INSTALACIÓN...................................................................................................303.3 INTERFAZ DE USUARIO DE MICROSOFT AGENT...............................................31

3.3.1 Ventana del personaje.............................................................................313.3.2 Menú contextual de comandos................................................................313.3.3 Icono del personaje en la barra de herramientas...................................32

IV


3.3.4 Ventana de Comandos de Voz.................................................................333.3.5 Globo de Texto........................................................................................333.3.6 Ventana informativa del estado Listening...............................................343.3.7 Ventana de Opciones Avanzadas de Personajes.....................................343.3.8 Ventana de Propiedades del Personaje por Defecto...............................36

3.4 INTERFAZ DE PROGRAMACIÓN DE MICROSOFT AGENT...................................373.4.1 Acceso a los servicios de programación.................................................373.4.2 Modelo de Objetos de Microsoft Agent...................................................403.4.3 Puesta en marcha del Servidor AgentSvr.exe..........................................433.4.4 Servicios de Animación...........................................................................483.4.5 Servicios de Entrada................................................................................533.4.6 Servicios de Salida..................................................................................58

4 PROGRAMACIÓN DEL ANALIZADOR DE ESTILO EN ENTORNO VISUAL C++..................................................................................................................63

4.1 PRESENTACIÓN DEL ENTORNO VISUAL C++....................................................634.1.1 Asistentes.................................................................................................644.1.2 El sistema de ayuda.................................................................................67

4.2 ENTORNO DE DESARROLLO: VISUAL STUDIO..................................................684.3 EL CONCEPTO DE ESPACIO DE TRABAJO DE PROYECTOS (WORKSPACE)........71

4.3.1 Posibilidades de programación...............................................................724.4 CREACIÓN DE LA APLICACIÓN ANALIZADOR DE ESTILO.................................73

4.4.1 Interfaz Gráfica de Usuario: Arquitectura Documento/Vista.................734.4.2 Control ActiveX WebBrowser..................................................................81

5 BIBLIOTECA AGENTES.DLL..........................................................................90

5.1 INTRODUCCIÓN A LAS DLLS:..........................................................................905.1.1 Diferencias entre las bibliotecas de vinculación estática y dinámica... .915.1.2 Ventajas de usar DLLs............................................................................925.1.3 Inconvenientes.........................................................................................925.1.4 Construcción de una DLL.......................................................................93

5.2 CREACIÓN DE LA BIBLIOTECA AGENTES.DLL..................................................955.2.1 Uso del Asistente de Aplicaciones...........................................................955.2.2 Análisis del proyecto generado por el asistente......................................98

5.3 AGREGAR LA BIBLIOTECA AL PROYECTO ESTILOSVC6:................................1015.4 INTERFAZ DE PROGRAMACIÓN (API).............................................................102

Nombre de la función............................................................................................1035.4.1 InicializarAgente...................................................................................1035.4.2 CargarPersonaje...................................................................................1035.4.3 DescargarPersonaje..............................................................................1045.4.4 FijarIdiomaPersonaje...........................................................................1055.4.5 LiberarAgente........................................................................................1055.4.6 MostrarPersonaje..................................................................................1065.4.7 OcultarPersonaje..................................................................................1065.4.8 HablarPersonaje...................................................................................1065.4.9 PensarPersonaje....................................................................................1075.4.10 ReproducirFichero................................................................................1075.4.11 RealizarAccionPersonaje......................................................................1085.4.12 MoverPersonaje....................................................................................1095.4.13 ApuntarPersonaje..................................................................................110

V


5.4.14 HojaPropiedades...................................................................................1105.5 GLOSARIO...................................................................................................111

6 DIÁLOGO INTERACTIVO CON EL AGENTE ANIMADO.......................113

6.1 ANALIZADOR DE ESTILO................................................................................1136.2 GESTIÓN DE DIÁLOGOS EN EL ANALIZADOR DE ESTILO................................1146.3 DISEÑO DE LA INTERFAZ CON EL PERSONAJE................................................1156.4 COMENTAR TABLAS DE RESULTADOS............................................................116

6.4.1 Análisis de datos orientado a objetos....................................................1206.5 COMANDOS DE VOZ DE AGENT.....................................................................128

7 CONCLUSIONES Y LÍNEAS FUTURAS.......................................................130

7.1 CONCLUSIONES..............................................................................................1307.2 LÍNEAS FUTURAS............................................................................................131

A PROGRAMACIÓN BASADA EN COMPONENTES....................................133

A.1 JUSTIFICACIÓN DE ESTE ANEXO.....................................................................133A.2 INTRODUCCIÓN..............................................................................................133A.3 MODELO DE OBJETOS COMPONENTES...........................................................134

A.3.1 Interfaces COM.....................................................................................134A.3.2 ID de interfaz, ID de clase y GUID.......................................................137A.3.3 Implementación de la localización y registro.......................................138A.3.4 DLL alternativos y dominación.............................................................142A.3.5 El Director de Control de Servicio........................................................142A.3.6 Versiones de interfaces..........................................................................143

A.4 AUTOMATIZACIÓN OLE.................................................................................144A.4.1 Comprensión de la interfaz de distribución..........................................144A.4.2 Cómo se utiliza las variantes.................................................................146A.4.3 Eventos..................................................................................................149

A.5 GLOSARIO:..................................................................................................151

B INTERFAZ DE PROGRAMACIÓN DE MICROSOFT AGENT.................153

B.1 IAGENT..........................................................................................................153B.1.1 IAgent::GetCharacter............................................................................154B.1.2 IAgent::Load..........................................................................................154B.1.3 IAgent::Register....................................................................................155B.1.4 IAgent::UnLoad.....................................................................................155B.1.5 IAgent::Unregister................................................................................156

B.2 IAGENTEX......................................................................................................156B.2.1 IAgentEx::ShowDefaultCharacterProperties........................................156B.2.2 IAgentEx::GetVersion...........................................................................157

B.3 IAGENTCHARACTER......................................................................................157B.3.1 IAgentCharacter::GestureAt.................................................................158B.3.2 IAgentCharacter::Hide..........................................................................158B.3.3 IAgentCharacter::Interrupt...................................................................159B.3.4 IAgentCharacter::MoveTo....................................................................159B.3.5 IAgentCharacter::Play..........................................................................160B.3.6 IAgentCharacter::Show.........................................................................160B.3.7 IAgentCharacter::Speak........................................................................161B.3.8 IAgentCharacter::Stop..........................................................................162

VI


B.3.B IAgentCharacter::StopAll......................................................................162B.3.10 IAgentCharacter::Wait..........................................................................162

B.4 IAGENTCHARACTEREX..................................................................................163B.4.1 IAgentCharacterEx::GetLanguageID...................................................163B.4.2 IAgentCharacterEx::GetSRModeID......................................................164B.4.3 IAgentCharacterEx::GetSRStatus.........................................................165B.4.4 IAgentCharacterEx::GetTTSModeID....................................................165B.4.5 IAgentCharacterEx::Listen...................................................................166B.4.6 IAgentCharacterEx::SetLanguageID....................................................166B.4.7 IAgentCharacterEx::SetSRModeID......................................................167B.4.8 IAgentCharacterEx::SetTTSModeID....................................................167B.4.9 IAgentCharacterEx::ShowPopupMenu.................................................167B.4.10 IAgentCharacterEx::Think....................................................................167

B.5 IAGENTNOTIFYSINK......................................................................................168B.5.1 IAgentNotifySink::Click.........................................................................168B.5.2 IAgentNotifySink::Command.................................................................169B.5.3 IAgentNotifySink::DblClick...................................................................170B.5.4 IAgentNotifySink::DragComplete.........................................................170B.5.5 IAgentNotifySink::DragStart.................................................................171B.5.6 IAgentNotifySink::Move........................................................................171B.5.7 IAgentNotifySink::RequestComplete.....................................................172B.5.8 IAgentNotifySink::RequestStart.............................................................172B.5.9 IAgentNotifySink::VisibleState..............................................................173

B.6 IAGENTNOTIFYSINKEX.................................................................................173B.6.1 IAgentNotifySinkEx::ListeningState......................................................174

BIBLIOGRAFÍA.........................................................................................................176

PLANOS.......................................................................................................................179

PLIEGO DE CONDICIONES...................................................................................181

CONDICIONES GENERALES.........................................................................................181CONDICIONES GENERALES A TODOS LOS PROGRAMAS..............................................182CONDICIONES GENERALES DE PRUEBA......................................................................182RECURSOS MATERIALES.............................................................................................182RECURSOS LÓGICOS...................................................................................................182

PRESUPUESTO..........................................................................................................184

1 PRESUPUESTO DE EJECUCIÓN MATERIAL...........................................................1841.1 Relación de salarios..................................................................................1841.2 Relación de obligaciones sociales.............................................................1841.3 Relación de salarios efectivos totales........................................................1851.4 Coste de la mano de obra..........................................................................1851.5 Coste total de materiales...........................................................................1851.6 Importe total del presupuesto de ejecución material................................186

2 IMPORTE DE EJECUCIÓN POR CONTRATA...........................................................1863 HONORARIOS FACULTATIVOS............................................................................1874 Importe total del proyecto.................................................................................187

VII


1


1 INTRODUCCIÓN

1.1 Presentación

Los ordenadores se han introducido en el conjunto de la sociedad hasta llegar a ser herramientas indispensables para la realización de numerosas tareas cotidianas. A lo largo del tiempo han aumentado considerablemente el número de servicios que proporcionan a las personas, llegando a acaparar una cantidad ilimitada de actividades. Los ordenadores se usan con asiduidad dentro del entorno del trabajo, en el hogar, en lugares de ocio, etc.

Sin embargo, dentro del amplio desarrollo experimentado por los ordenadores en la sociedad actual, todavía existen limitaciones que hay que solventar: La comunicación con las aplicaciones informáticas depende sobremanera de dispositivos artificiales como son el ratón o el teclado. Este hecho requiere el aprendizaje y la adaptación del usuario a una interfaz que no se rige por las pautas de la comunicación humana.

En aras de la facilidad de uso y de la humanización de estas aplicaciones se está investigando en medios más naturales e intuitivos de interactuar con las máquinas. Estas interfaces conocidas como multimodales incorporarán funcionalidades de voz, como hablar y escuchar, y serán capaces de transmitir emociones mediante el empleo de expresiones faciales y gestos.

Los Agentes Animados presentan un caso concreto de combinación de diversas modalidades de interacción para la creación de un sistema con interfaz multimodal.

Los Agentes Animados son personajes autónomos (con forma de persona, animal, dibujo animado, etc.) capaces de percibir los actos multimodales del usuario (habla, gestos de las manos, lenguaje corporal, mirada, etc.) y generar respuestas multimodales (habla, mirada, gestos de la cara y manos, movimientos de la cabeza, etc.) adecuadas en tiempo real. Son agentes capaces de actuar como los humanos en conversaciones cara a cara aprovechando las características que proporciona el cuerpo para conseguir un canal de comunicación óptimo y más robusto.

Este Proyecto Fin de Carrera es un estudio sobre las potencialidades de los Agentes Animados, en la tarea de complementar a las tecnologías del habla, para crear interfaces de usuario atractivas. Como aplicación práctica, se presenta un programa que emplea un personaje animado capaz de comunicarse con el usuario vía voz y el cual está dotado de movimiento, incluyendo gesticulación, para mejorar su expresividad. Este personaje será usado como asistente interactivo, para presentar la aplicación y guiar a través de ella. Se integra en la interfaz tradicional de ventanas, menús y controles, completándola y haciéndola más eficaz al ser más natural, instintiva y atractiva.

Para su desarrollo se ha contado con los servicios que proporciona la plataforma Microsoft Agent®. Esta herramienta ayuda a que el incremento de complejidad que supone el incluir un personaje animado en una aplicación no sea inabordable. Entre las facilidades que nos ofrece Microsoft Agent® se encuentran las siguientes:

2


Proporciona ciertos personajes ya creados y listos para ser usados. También ofrece la posibilidad de crear un personaje personalizado con una herramienta de edición.

Gestiona la animación de los mismos.

Ofrece soporte opcional para reconocimiento del habla y para que los personajes puedan responder usando síntesis de voz, audio grabado o mensajes en un bocadillo de texto.

Estos servicios son accesibles desde muchos lenguajes de programación, pero en el caso de este proyecto se accederá a ellos a través de C++, facilitando la integración con el resto del software del Departamento.

1.2 Punto de partida

Para la investigación acerca de la utilización de personajes animados en interfaces de usuario se ha partido de un programa ya existente. Se trata del analizador de estilo para textos en inglés científico/técnico ANESTTE, realizado con anterioridad por Rogelio Vargas Sánchez [Vargas Sanchez, 1996] y completado por Pilar Santamaría [Santamaría, 2001].

El analizador de estilos ANESTTE es un programa que trata de proporcionar una medida objetiva y global del estilo de redacción de un texto de tipo científico/técnico escrito en inglés.

Un indicador del estilo del texto es el empleo, en mayor o menor medida, de ciertos elementos lingüísticos. El programa analiza la aparición en el texto de esos elementos y los convierte en valores numéricos asignados a unas variables. Los valores de esas variables se guardan en un fichero de salida de datos, sin ser mostrados en pantalla.

La versión inicial de Rogelio Vargas calcula, según el valor de las variables y basándose en unas reglas de aceptabilidad, las puntuaciones obtenidas en las diferentes características estilísticas (tipologías) que se analizan (claridad, concisión, variedad, comprensibilidad...) y las muestra en pantalla junto con la valoración final del estilo global del texto.

La revisión del programa de Pilar Santamaría ofrece al usuario la posibilidad de acceder a una ayuda que le permita conocer a fondo la manera de mejorar su estilo. El formato de la ayuda es HTML, de manera que la información está organizada en páginas Web enlazadas unas con otras mediante una amplia red de hipervínculos.

Con la inclusión de la ayuda, el Analizador de Estilo quedó bastante completo pero constituía un candidato excelente para la inclusión de una interfaz de usuario basada en personajes animados interactivos:

Los usuarios potenciales del programa no tienen por qué ser lingüistas por lo que se necesita de una explicación de los resultados enfocada a usuarios no expertos. Esta necesidad podría ser cubierta por un Agente, el cual recalcaría los puntos del análisis cuya corrección ayudase al usuario en mayor grado a mejorar su estilo.

3


Dado la extensa cantidad de información proporcionada en la ayuda, el Agente podría servir de guía a través de ella, haciéndolo de una manera atractiva para convertirla en más amena.

La inclusión de un Agente facilitaría el manejo del programa y se conseguiría llegar a segmento de usuarios más amplio, incluido jóvenes estudiantes de inglés atraídos por el aliciente de interaccionar con personajes animados.

1.3 Objetivos

El principal objetivo propuesto en la realización de este Proyecto de Fin de Carrera es la aplicación de los conocimientos adquiridos sobre los Agentes Animados, para completar la interfaz de usuario del analizador de estilo ANNESTE.

Se incluirá un Agente Animado, como sistema de ayuda y explicación de los resultados obtenidos en el análisis de estilo. El cual se desplazará por la pantalla, concentrando la atención del usuario sobre determinados puntos del análisis (positivos o negativos), así como podrá emitir breves mensajes orales que complementen la información numérica o las extensas páginas HTML de ayuda.

Para ello será necesario familiarizarse con la interfaz de programación de Microsoft Agent y crear una API (Application Programming Interface) en forma de biblioteca de funciones que facilite la incorporación del personaje al programa Analizador de Estilos.

Se pretende reconstruir por completo el analizador, que originalmente fue creado mediante el compilador Borland C++ 4.5, y que ahora se desarrollará en el entorno Microsoft Visual C++ 6. Este cambio de entorno de desarrollo posibilitará el acercamiento a la interfaz de programación de Microsoft Agent, así como la utilización de potentes controles ActiveX para la navegación por las páginas Web de ayuda. Además el cambio conllevará un rediseño de la interfaz gráfica lo que proporcionará al programa un aspecto más actual.

1.4 Componentes Software

Se pretende que el software creado sea reutilizable y pueda ser empleado en otros proyectos de diversa índole que quieran manejar agentes animados. Por lo tanto se ha decidido emplear técnicas orientadas a objetos, que favorecen la reutilización del software al dividirlo en componentes. Además, estas técnicas facilitan el tratamiento de tareas complejas.

Una primera aproximación nos señala los siguientes componentes:

Una interfaz gráfica de usuario (GUI) que gestione toda acción del usuario sobre las ventanas, menús, botones o controles de cualquier tipo que conforman la interfaz del programa. Estará basada en una arquitectura documento/vista de tipo MDI (Multiple Document Interface) para la gestión (edición, archivo y presentación) de los textos que van a ser analizados.

4


El corazón del programa lo forman una serie de ficheros fuente escritos en lenguaje C usando técnicas de programación estructurada. Estos módulos realizan el análisis del texto y permanecen invariables respecto de la versión previa del programa, el analizador de estilo para textos en inglés científico/técnico ANESTTE.

Otro componente, cuyo objetivo es servir como sistema de ayuda y explicación de los resultados obtenidos en el análisis de estilo, controlará el diálogo interactivo entre el usuario y los personajes animados. Estará formado por diversas clases, programadas en C++, que relacionarán entre sí la interfaz del proyecto principal y la biblioteca de los Agentes.

Una biblioteca de funciones a modo de API para el manejo de los personajes. Esta biblioteca será un subconjunto de la interfaz de programación de Microsoft Agent, pero con una interfaz más fácil de usar que facilitará la incorporación de los agentes a cualquier programa. Este componente será creado en forma de biblioteca enlazada dinámicamente (DLL).

Para la navegación por las páginas Web de ayuda se incluirá un control ActiveX que presentará la ayuda en formato HTML sobre un diálogo creado a tal efecto.

Figura 1.1 Diagrama de Componentes del proyecto

Como se ha comentado en los objetivos, la herramienta integradora de todos estos componentes será el entorno de desarrollo integrado (IDE) Microsoft Visual C++ 6. Se ha elegido esta herramienta por ser potente y novedosa y por ser la tecnología Agent también de Microsoft. Aunque la utilización de Microsoft Visual C++ 6 no es obligatorio para poder trabajar con Agent.

5


1.5 Organización del proyecto

Aparte de este capítulo introductorio, el trabajo se divide en seis capítulos más y dos anexos:

El capítulo segundo analiza las características de las interfaces de usuario actuales y evalúa las posibilidades que ofrece incluir un Agente Animado en las nuevas interfaces. También describe cómo ha de diseñarse la interacción con personajes artificiales para crear la ilusión de contexto social en el usuario de la interfaz.

El capítulo 3 describe la herramienta Microsoft Agent: sus potencialidades y su forma de empleo. Incluye un análisis de los fundamentos en los que se basa este componente y una descripción, con ejemplos de código, de la interfaz de programación del Servidor de Microsoft Agent.

Los siguientes capítulos son una disección de la parte práctica del proyecto: La reconstrucción de la aplicación Análisis de Estilo de textos en inglés y la integración en la aplicación de los Agentes Animados.

En el capítulo número 4 se describe detalladamente la herramienta de programación (entorno Microsoft Visual C++ 6.0) destacando las ayudas y los automatismos que presta para el desarrollo de aplicaciones. Tomando el código de la aplicación Analizador de Estilos como ejemplo, se explica cómo se usan las clases de la biblioteca MFC de Windows para la creación de los menús, diálogos y demás componentes, como por ejemplo, el componente encargado de gestionar la navegación a través de las páginas Web de ayuda, el Control ActiveX WebBrowser. En el capítulo quinto se describe la interfaz de programación de la biblioteca de Agentes creada. Esta biblioteca se ha implementado en formato de Biblioteca de Enlace Dinámico o DLL (Dynamic Link Library). En el capítulo se incluye un análisis de este tipo de bibliotecas y de la forma de desarrollarlas mediante Visual C++ 6.

El capítulo séxto describe el módulo de diálogo interactivo Agente/Usuario. Este módulo se ha implementado partiendo de un análisis orientado a objetos y en su descripción se utiliza nomenclatura UML (Unified Modeling Languaje).

El último capítulo incluye las conclusiones y direcciones de trabajo futuras.

Además se incluyen dos Anexos, el A y el B:

El Anexo A es un acercamiento a la programación de componentes basada en COM y en Automatización OLE. Los conceptos explicados aquí son necesarios para comprender cómo funciona Microsoft Agent y serán necesitados para poder seguir con aprovechamiento el capítulo 3.

El Anexo B es una descripción detallada de la interfaz de programación de Microsoft Agent que puede ser usada como referencia de programación.

6

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAInterfaces con Agentes Animados

7


2 Interfaces con Agentes Animados

2.1 Necesidad de Interfaces de Usuario amigables

El crecimiento de los ecosistemas de la información y la computación, está relacionado con un cambio fundamental en la sociedad, caracterizado por la evolución de una industria hasta ahora tradicional de manejo de bienes, hacia la de una industria del conocimiento y de la economía de servicios de información. La producción, distribución y administración de información se han transformado ya en las actividades principales de las sociedades modernas basadas en el manejo del conocimiento.

La necesidad de interactuar con los ordenadores está penetrando en muchos aspectos de nuestra vida cotidiana. Ya sea en bancos, estaciones de tren, hoteles o aeropuertos, se encuentran innumerables puntos de información electrónicos en los que reside gran parte de la información necesaria, o al menos útil, para desplazarse, comerciar o informarse acerca de temas de ocio. Las personas que no están básicamente tecno-alfabetizadas se encuentran hoy en día con serias limitaciones en su acceso a la información, ya sea ésta trivial o fundamental.

Ya a finales de los 60 se decía que en el futuro, no se requeriría de personas orientadas al ordenador, sino de ordenadores orientados a las personas. El tiempo ha demostrado el acierto de esta predicción. En este sentido, la interfaz entre el ser humano y los sistemas informáticos debe ser mejorada continuamente para lograr que el acercamiento a la comunicación con las máquinas no resulte tan traumático para muchos.

La mejora en la comunicación hombre-máquina ha dependido del grado de desarrollo tanto del hardware como de los sistemas operativos. Puede ser de utilidad echar la vista atrás y recordar su evolución [Sabaté]:

2.2 Desarrollo de las Interfaces de Usuario (IU)

En los años 60, los sistemas “más interactivos” utilizaban terminales teletipo, semejantes a una máquina de escribir (TTY), que necesitaban del papel como recurso de visualización. Luego, los diseñadores de interfaces basadas en tubos de rayos catódicos (CRT) basaron sus modelos de presentación gráfica y textual según el mismo modelo. Aquellos kilométricos listados de papel pasaban ahora de forma virtual a estar detrás de un cristal.

La metáfora del teletipo fue la base del conocido MS-DOS, con su línea de comandos basada en texto que aún se padece y que tanto atemoriza a los no iniciados en ese arcaico "C:\>".

En la década de los 60, algunos investigadores como Ivan Sutherland (inventor de la primera interfaz basada en ventanas) y Douglas Engelbart (inventor del ratón), estuvieron ya diseñando sistemas espaciales para pantallas de rayos catódicos que emulaban la complejidad gráfica de los documentos impresos utilizando la capacidad de

8


ajuste dinámico de caracteres que ofrecía el ordenador superando las limitaciones del papel.

La base conceptual de la mayoría de las interfaces gráficas de usuario o GUI (Graphic User Interface) de hoy en día fue desarrollada durante los años 70 en los laboratorios de Xerox Palo Alto Research Center (PARC). Estos conceptos incluyen metáforas gráficas explícitas en pantalla para objetos tales como documentos y programas de ordenador; ventanas múltiples superpuestas para subdividir actividades en la pantalla; y manipulación directa de ventanas, iconos y otros objetos utilizando el ratón de Engelbart como elemento de señalización.

Los ordenadores de entonces, y aún los actuales, han requerido siempre de razonamiento abstracto. La tarea de los investigadores de PARC fue la de crear una interfaz que pudiese explotar además las habilidades manipulativas y visuales del usuario. El objetivo fue diseñar analogías gráficas de objetos familiares del mundo real en la pantalla, para crear la ilusión de que la información digital podía manipularse tan fácilmente en el ordenador, como se hacía con los documentos impresos en un escritorio.

El trabajo sobre interfaces realizado en Xerox PARC a mediados de los 70 ha establecido la mayoría de las convenciones funcionales y visuales de las GUI actuales, y han sido las antecesoras de las GUI de Apple Macintosh, de Microsoft Windows, y de otras como UNIX Motif, NextStep, o Open Look.

De las GUI anteriores, el estándar actual, no de facto pero si de mercado, lo representa Windows y sus aplicaciones. Su interfaz se puede definir como aquella interfaz gráfica en la que el usuario navega a través de menús y ventanas de diálogo con la ayuda del ratón y del teclado.

El hecho de llegar a un cierto estándar ha facilitado a los usuarios habituados al uso de este tipo de interfaces el conocer ciertas partes comunes de todas las aplicaciones, correspondientes a las tareas más frecuentes, teniendo la seguridad de que funcionan igual en otros programas. Por lo tanto: pasado una primera etapa de acercamiento y adaptación a estas interfaces, la interacción del usuario con la máquina no es difícil, aunque tampoco cómoda (por no ser natural), ni poderosa (la interfaz de salida se reduce casi exclusivamente a la pantalla y como interfaces de entrada tan sólo se dispone del teclado y del ratón) y además puede resultar algo fría.

2.3 Interfaces de Usuario con personajes animados

El estudio de la interacción hombre-ordenador o HCI (Human Computer Interface) puede contribuir a generar mejores sistemas y servicios multimedia con interfaces de usuario realmente amigables.

En la actualidad los investigadores en HCI se están dedicando a explorar nuevas metáforas y arquitecturas. Sus investigaciones están descubriendo las numerosas ventajas que presenta la interacción con un sistema multimodal respecto a la interacción de sistemas unimodales.

9


Una definición de interfaz multimodal aparece en [Montoro Manrique, 2000]: Es aquella interfaz que no presenta la limitación de entrada y salida de datos mediante un solo canal. Estos sistemas tratan de implicar varias de las posibles modalidades de comunicación que utilizan las personas. Estas modalidades comprenden habla, reconocimiento de gestos, reconocimiento de la posición de la mirada, del movimiento de los labios, de la expresión facial, de la escritura, etc.

El propósito de utilizar diferentes modos es liberar a las personas del uso de una interfaz rígida, eliminando las barreras de comunicación presentes en la mayoría de los sistemas actuales. El principal objetivo es llegar a una interacción natural entre persona y máquina, esto es, una interacción que se asemeje en la medida de lo posible a la interacción persona-persona.

Además, los sistemas multimodales salvan la dificultad de expresar oralmente información espacial, también eliminan ambigüedades y reducen la tasa de error al poder mostrar la información en diversos modos al mismo tiempo. La información expresada por los distintos modos de comunicación no siempre es redundante sino que en muchas ocasiones cada uno de ellos proporciona información complementaria e incluso puede que imprescindible para la consecución de una tarea específica.

Fomentado por los numerosos beneficios potenciales de este tipo de comunicación multimodal, se ha iniciado recientemente una línea de trabajo basada en el desarrollo de Interfaces de Usuario que permiten la interacción hablada con un agente informático. Para ello, incorporan reconocimiento del habla, comprensión del lenguaje natural, gestión de conversación y apariencia de personaje animado para simular mejor una interacción persona/persona. Como el proyecto REA [Cassel,1999].

Algunas de las motivaciones que han conducido al desarrollo de estas interfaces son:

Los agentes animados con interfaces conversacionales proporcionan un paradigma intuitivo de interacción ya que el usuario no necesita adquirir nuevos conocimientos.

Estas interfaces presentan redundancia y complementariedad en los modos de entrada. Lo que aumenta la fiabilidad de la comunicación entre sistema y usuario.

Los usuarios encuentran estos sistemas más amigables y cooperativos. Los agentes autónomos pueden utilizar esa ventaja para entablar una conversación con los usuarios de forma más natural.

La creación de un agente animado engloba la investigación lingüística, tecnología del habla, ilustración gráfica, etc. Al tratarse de un campo que abarca numerosas disciplinas, el desarrollo de estos sistemas presenta abundantes problemas en la creación de cada componente y en la integración de los mismos.

Una de las principales dificultades consiste en reproducir de forma fidedigna un diálogo cara a cara. Estos diálogos presentan un comportamiento irregular con numerosas excepciones a las reglas. Se ha de prestar atención a cómo sincronizar los labios del agente con lo que dice, a las expresiones faciales utilizadas y a los gestos que realiza.

10


Los desarrolladores necesitaremos de herramientas que nos faciliten el trabajo de integración de los agentes. Una de esas herramientas es Microsoft Agent. De la que se hablará en detalle en un próximo capítulo.

2.4 Elementos de conversación cara a cara con personajes animados

Cuando se diseña interfaces con personajes, la motivación última es conseguir trabajar con computadoras sin teclados, las cuales acepten entradas naturales no entrenadas y respondan en consecuencia. En situaciones tales como esas, se necesitan personajes bien implementados para poder interactuar con ellos usando las múltiples facetas de la conversación natural.

Una conversación cara a cara se caracteriza principalmente por el empleo del lenguaje, pero se emplean, además, otras técnicas o habilidades: los interlocutores emplean gestos con las manos para enfatizar o representar ideas, se dirigen miradas expresivas y utilizan variaciones en el tono o melodía de las palabras o frases articuladas.

El ejemplo de la conversación puede ser considerado como el paradigma de la interacción humana. Es por ello que cuando los diseñadores quieren construir interfaces hombre/máquina recurren a la metáfora de la conversación cara a cara como ideal de esta interacción.

Según [Cassel, 2000], Nickerson, en 1976, fue de los primeros que argumentó acerca de la utilidad de la aplicación de esta metáfora a la interacción hombre/máquina. Expuso una lista de las características que debería poseer una interfaz. Esas características son: poseer elementos de comunicación no verbal, ser capaz de tomar la iniciativa, dar sensación de presencia e incluir reglas de transferencia del control.

Aunque estas reglas se ganaron el reconocimiento por parte de los diseñadores, hasta la fecha no se había intentado llevarlas a la práctica seriamente. Es ahora cuando los diseñadores están trabajando para conseguir interfaces que puedan sostener una conversación. Estas interfaces transmiten emociones y se comportan en función de la demanda del diálogo, de su propia personalidad y de convencionalismos sociales. Además, poseen un cuerpo para usarlo como elemento expresivo y se conocen como agentes conversacionales dotados de cuerpo.

Un camino para reflexionar acerca del problema al que se enfrentan los diseñadores es imaginar que es posible construir un agente conversacional dotado de cuerpo que muestre características tan humanas que pueda sostener una conversación cara a cara con un humano y plantearle serias dudas acerca de su condición humana o artificial. Para que ese agente sea capaz de superar esa prueba (el mismo tipo de prueba a la que sometía Harrison Ford a los replicantes en la película Blade Runner), ¿de qué modelos de conversación humana deberíamos dotarle y qué comportamientos superficiales debería mostrar?

Las conductas que deben mostrar los agentes para conseguir desarrollar una conversación que resulte natural son muy extensas, pero se han de vertebrar alrededor de las siguientes pautas:

11


Emoción : que el agente exprese emociones ayuda a reforzar su mensaje durante una conversación. El perfil emocional de un agente lo determina, en parte, la forma de llevar a cabo sus acciones: El personaje puede exhibir expresiones faciales que denoten emoción y gestos expresivos, por ejemplo, para aconsejar, animar o enfatizar algo al usuario. Aparte de generar respuestas emocionales en los agentes, sería muy útil el reconocimiento de las emociones del usuario. Esto se podría hacer a partir de observar características como su habla, sus gestos y sus expresiones faciales. Con las herramientas PC actuales, implementar algo parecido resulta complejo y excede de los objetivos de este proyecto.

Personalidad : Los Agentes con una personalidad consistente resultan más atractivos y hacen que la información que transmiten sea más amena y fácil de recordar, además, son percibidos por el usuario como más inteligentes y útiles. La personalidad de un Agente ha de ser elegida teniendo en cuenta sus tareas específicas en un contexto dado, pues la personalidad presenta al personaje con sus propias parcelas de conocimiento y perfiles de interés. Para conseguir que el personaje sea un individuo distinguible con un carácter propio, ha de ser dotado de una serie de actitudes que sean consistentes a lo largo de toda la interacción. Estas actitudes se revelan a través de los movimientos, conversaciones e interacciones con el usuario y con otros personajes.

Se deben considerar los objetivos de la conversación: La razón por la que el hablante está comunicando una cosa (es decir, el objetivo que tiene en mente el hablante) y la forma de esta comunicación están muy relacionadas. Las contribuciones a una conversación pueden ser de propuesta y de interacción [Montoro Manrique, 2000]:

- La información de propuesta corresponde al contenido de la conversación. Incluye procesos de habla con sentido y gestos utilizados como complemento al habla o basados en el contenido de la oración (como los gestos para indicar un tamaño).

- La información de interacción corresponde a las señales que regulan el proceso de la conversación. Incluye procesos de habla y comportamientos no verbales que no producen información (como afirmaciones con la cabeza para indicar que se sigue la conversación).

A partir de este análisis se pueden inferir ciertos modelos que son de aplicabilidad directa en los agentes. Así, teniendo en cuenta lo que un personaje quiere expresar, se puede acompañar su discurso con cierta expresión facial o gesto corporal. Como ejemplo, el personaje podría apretar el puño mientras realiza una amenaza, fruncir el ceño cuando no ha entendido algo y solicita una explicación o realizar afirmaciones con la cabeza para indicar que atiende al usuario.

Pautas de conversación: Como puede ser la gestión del turno de palabra, las interrupciones y de la toma de iniciativa. Como los interlocutores no suelen hablar al mismo tiempo, se pueden determinar técnicas para establecer a quién pertenece el turno en cada momento. Para determinar esto, se pueden utilizar factores que incluyan la mirada o la entonación. Las interrupciones producidas por el oyente no

12


se realizan únicamente mediante la voz, sino que también se pueden producir con un gesto para solicitar que se desea el turno.

Aún no se pueden construir agentes con técnicas conversacionales perfectas. Los modelos de emoción, de personalidad, de conversación son todavía rudimentarios. Y el número de conductas conversacionales que pueden ser realizadas en tiempo real usando cuerpos animados es todavía extremadamente limitado. Pero a la vez que se empieza a comprender las habilidades que subyacen en la conversación humana, y se aprecian las conductas que la conforman, se aproxima al día en el que una conversación cara a cara con un agente pueda llegar a ser imaginable.

Mientras llega ese momento los desarrolladores de interfaces con personajes pueden intentar seguir las recomendaciones que se enuncian en el siguiente apartado (pautas adaptadas de [Microsoft Corporation #1, 1998] y [Microsoft Corporation #2, 1998]).

2.5 Directrices para el diseño de la interacción con Personajes

Para diseñar una buena interfaz basada en personajes, antes que nada, es necesario seguir las reglas de diseño de interfaces de usuario en general, y además, tener en cuenta las peculiaridades intrínsecas a este tipo de interfaces:

2.5.1 Emplear sonido

Uno de los elementos fundamentales para constituir un entorno de interacción con personajes es el sonido. Su presencia, no es en sí un requisito necesario, pero sí una parte esencial para la constitución de un entorno de máxima interacción. Como ya ha sido comentado, los humanos consideramos al habla como una forma habitual, espontánea y sencilla para comunicarnos entre nosotros.

Evidentemente, esta vía de comunicación puede ser sustituida por otras en aquellos contextos en que las circunstancias lo requieran. Porque, hablar no es siempre la mejor forma de entrada para solicitar una tarea. Por ejemplo, debido a la alternancia del turno de palabra en el lenguaje natural, esta forma de entrada puede ser en ocasiones más lenta que otras. Además, igual que el teclado, la entrada de voz es una pobre interfaz para apuntar en la pantalla a menos que se proporcione algún tipo de representación mnemotécnica. Por lo tanto, hay que evitar usar el habla como interfaz exclusiva. Se debe proporcionar otros caminos alternativos (ratón, teclado...) para acceder a cualquier funcionalidad básica.

Muchos de esos problemas se solventan si se implementa una interfaz multimodal, donde se complemente la entrada de habla con información visual que ayude a especificar el contexto y las opciones que se admiten.

Para la construcción de un entorno de interacción con personajes en el que se utilice el sonido como interfaz de usuario puede ser necesaria la presencia de ciertos periféricos y sistemas software: Micrófonos, que se utilizan para reconocer la voz y obtener una representación, en

forma de texto, de las palabras pronunciadas por el usuario.

13


Gestores de diálogos, que pueden incluir:

- Analizadores, parsers y gramáticas que identifican el texto reconocido dentro de un diálogo.

- Gestores del flujo de diálogo que hacen posible establecer una conversación coherente con el entorno.

Altavoces para comunicarse con el usuario, lo que puede implicar:

- Generadores de sonido grabado.

- Sintetizadores de voz que permitan generar una voz reconocible por el usuario a partir del texto que se quiere transmitir.

Dada la importancia del sonido en las interfaces con personajes y la complejidad de su tratamiento, el último apartado de este capítulo se dedicará en exclusiva a profundizar en esta cuestión.

2.5.2 No ser exclusivo

Cuando se incluye un personaje interactivo en la interfaz de usuario de una aplicación no ha de hacerse con el ánimo de reemplazar la interfaz primitiva, sino con la intención de mejorarla. Obligar al usuario a tratar en exclusiva con el personaje puede acarrear un serio efecto negativo. Para evitarlo hay que permitir al usuario otras vías alternativas de interacción con la interfaz.

Mantener al usuario con el control es un principio de diseño que debe de cumplirse siempre. Este hecho implica que el usuario ha de poder decidir cuando quiere interactuar con el personaje y cuándo no.

2.5.3 Proporcionar la apropiada realimentación

Una interfaz de usuario que incorpore personajes interactivos puede proporcionar formas más naturales de realimentación. Además crea al usuario la expectativa de que la comunicación se va a realizar conforme a las normas de interacción social.

La localización del personaje en pantalla debe poder ser inferida por el usuario, según el contexto o estado, esto dará idea de una actuación racional del personaje. Así, por ejemplo, el personaje puede desaparecer siempre por la posición de pantalla en la que aparece.

Una realimentación es adecuada dependiendo del momento. Durante una interacción usuario/personaje se pueden distinguir distintos estados:

Cuando no hay interacción usuario/personaje : Durante este estado hay que evitar las distracciones. Esto puede hacerse moviendo al personaje a un punto de stand-by, donde no interfiera con el desarrollo de la acción, por ejemplo, mientras el usuario lee un texto. En esa situación es preferible dotar al personaje de una conducta ociosa (como respirando o mirando alrededor) para mantener la ilusión del contexto social,

14


pero, reduciéndose al mínimo los efectos de sonido y las animaciones. Otra opción a valorar es la posibilidad de esconder al personaje. En este caso hay que dejar claro al usuario por qué se oculta el personaje y qué es lo que puede hacer para volver a verle.

Cuando existe una interacción directa , es decir, el personaje participa en la tarea actual del usuario: En ese momento se debe situar al personaje en el foco de atención.

Cuando se pretende capturar la atención del usuario : Para ello, particularmente sí el personaje está fuera del foco de atención, se puede intentar la translación del personaje, la ejecución de una animación muy activa o de un movimiento o animación dirigiéndose al usuario. En la siguiente figura vemos un ejemplo. Se trata de un fotograma correspondiente a una animación del personaje Merlín en la que simula que golpea con los nudillos en la pantalla del ordenador.

Figura 2.1 Merlín atrayendo la atención del usuario.

2.5.4 Usar variaciones naturales

Una interfaz convencional, con menús y ventanas de diálogo, posee consistencia al ser predecible, causal y repetible.

Por contra, en una interfaz con personajes es necesario variar las respuestas de una forma natural para que el usuario no la considere aburrida, sin interés, ruda o poco inteligente. La comunicación humana raramente repite exactamente. Incluso repitiendo algo en una situación similar, se cambian las palabras, los gestos o las expresiones faciales.

2.5.5 Interacción social

La comunicación humana es fundamentalmente social. Así, la parte más esencial de ésta, el lenguaje, pierde efectividad si no se ve reforzado por unos convencionalismos sociales que vamos aprendiendo por imitación a través de relacionarnos con los demás.

Estos refuerzos pueden ser tanto verbales como no verbales. Aspectos relativos a la voz podrían ser: la entonación o la ordenación de las palabras, y aspectos no verbales: la postura corporal, los ademanes o gesticulación (especialmente con las manos) y las expresiones faciales.

15


La efectividad de este tipo de comunicación es debida a que añadiendo estos refuerzos se define mejor lo que el mensaje quiere transmitir. El comunicador refleja su actitud ante el interlocutor y ante el mensaje, muestra su identidad y expresa emociones. De este modo añade el aspecto subjetivo que personaliza y humaniza la comunicación.

Es una necesidad el emplear refuerzos sustitutivos en los canales de comunicación que por sus limitaciones no ofrecen la posibilidad de incluir los de la comunicación bis a bis. Un ejemplo de esto es el uso generalizado de los llamados smileys o emoticones en los correos electrónicos.

Las interfaces software hasta la fecha han dejado al margen la componente social de la comunicación. Pero ahora se está demostrando que las personas reaccionamos con naturalidad ante estímulos sociales presentados en contextos interactivos. Esta respuesta automática se refuerza ante un personaje animado con ojos y boca. La consciencia del usuario de estar tratando con un personaje artificial no rebaja sus expectativas de percibir en el personaje una conducta socialmente apropiada. Por lo que este aspecto debe ser cuidado al máximo.

2.5.6 Uso de gestos

El objetivo es que los personajes utilicen los mismos recursos de comunicación que las personas. Entre ellos se encuentran los gestos y las expresiones faciales.

Su uso sirve de gran ayuda porque existen ciertas informaciones que sólo se pueden expresar mediante gestos. Además los gestos sirven como complemento a acciones habladas o producen información redundante que ayuda en la mejora del entendimiento. Por lo tanto el uso y análisis de gestos constituyen un factor importante en el desarrollo de agentes animados.

Por ejemplo, los personajes pueden elevar las cejas para indicar que se ha entendido lo que el usuario ha pronunciado, jugar con la mirada mientras habla y utilizar diferentes recursos corporales para incrementar la sensación de naturalidad en la interacción.

Uno de los gestos más empleados por agentes animados es el de apuntar. Se puede combinar este gesto con el desplazamiento del personaje por la pantalla señalando la localización de cierto ítem. Como vemos en la siguiente figura, Genio señala hacia un botón para informar al usuario que debe pulsarlo.

Figura 2.2 Empleo de Gestos: Genio apuntando a un botón

16


2.5.7 Crear una personalidad

Dotar de personalidad a un personaje es importante para que transmita sensación de realismo.

Conviene que la personalidad de cada personaje esté bien definida y sea distintiva. No importa tanto que el personaje sea muy educado o simpático, como que su personalidad resulte atractiva y en general una personalidad débil o ambigua no gusta tanto.

La personalidad que debe ser elegida para un personaje dependerá del rol que haya de interpretar:

Si es dirigir al usuario hacia metas específicas, conviene una personalidad dominante.

Si el propósito del personaje es responder a las peticiones del usuario se debe usar una personalidad más sumisa.

Por otra parte, existen estudios que demuestran que los usuarios prefieren interactuar con personajes cuya personalidad se asemeja a la suya propia. Por lo tanto, otra solución es adaptar la personalidad a la del usuario. Para ello existen dos posibilidades, la primera es permitir que el usuario escoja entre una colección de personajes cada uno con una personalidad distinta, y la segunda es observar el estilo de interacción del usuario y modificar dinámicamente la personalidad del personaje. Aunque esto último es difícil, porque los humanos nos mostramos flexibles en las relaciones y solemos variar nuestra actitud dependiendo del interlocutor.

El programa Microsoft Office ofrece una galería de personajes para que el usuario elija el que mejor le parezca. En la siguiente figura podemos ver una selección a modo de ejemplo.

Figura 2.3 Galería de personajes del programa Microsoft Office

17


¿De qué herramientas se dispone para dotar de personalidad a un personaje?

La primera impresión que causa es importante. La postura, gestos, apariencia, elección de las palabras y estilo son rasgos sociales a través de los cuales se prejuzga una personalidad. El nombre de un personaje, como se presenta a sí mismo, como habla, como se mueve, y como responde a la acción del usuario contribuye a establecer una personalidad básica.

Pero, para crear una personalidad, no es necesario dotar al personaje de inteligencia artificial o crear animaciones de alta calidad. Los profesionales de la animación lo saben y llevan años usando los más sencillos rasgos de la comunicación social para dotar de ricas personalidades a objetos inanimados. Por ejemplo, los dibujantes de la Disney fueron capaces desde sus comienzos de dibujar simples sacos de harina que expresaban emociones.

Así pues, la estrategia a seguir es incidir sobre el aspecto psicológico. Si el personaje hace aseveraciones, se muestra seguro y desencadena acciones por su cuenta, habremos creado una personalidad dominante. Mientras que, una personalidad más sumisa puede caracterizarse mediante la articulación de frases interrogativas y por preferir la sugerencia a la orden. Además, las personalidades dominantes llevan el peso o la iniciativa en la interacción con el usuario.

El engreimiento suele ser mirado con escepticismo y antipatía por parte del usuario. Por lo tanto, se debe evitar la autoalabanza, a menos que sea una parte humorística de la personalidad que queremos que el personaje proyecte. Sí hemos de resaltar la pericia del personaje, una buena idea es hacerlo de manera indirecta desde otra fuente, como por ejemplo usando otro personaje o mediante una explicación descriptiva.

2.5.8 Aspecto físico

Como se ha comentado, el aspecto físico es importante porque contribuye a definir la personalidad del personaje.

Las formas de los personajes dependen del tipo de uso al que vayan a estar destinados en cada proyecto: Si se piensa que el uso de personajes con forma humanoide puede incrementar las expectativas de los usuarios más allá de lo que el agente puede ofrecer, es mejor usar personajes con forma de animal, objeto animado, etc. Por otra parte, si se usan personajes humanoides, se puede conseguir que los usuarios sitúen las expectativas al nivel que lo harían con los humanos y que por lo tanto disminuya su dificultad para interaccionar con el ordenador, que siempre resulta un interlocutor extraño.

18


Figura 2.4 Cyber: personaje humanoide creado por Randy Casson

2.5.9 Observar el protocolo apropiado

Los humanos aprendemos normas sociales de protocolo, y las usamos para relacionamos.

Nuestro personaje también ha de someterse a esas normas, en cuanto que, debemos simular una comunicación lo más humanizada posible. El usuario espera una reciprocidad en su interacción y si esto no ocurriera, podría juzgar la conducta del personaje como incompetente u ofensiva.

En situaciones formales o novedosas, la cortesía es esperada. Sólo después de haber alcanzado una cierta familiaridad en la relación se permite una relación no tan formal. Por lo tanto, ante la duda, la regla es ser cortés.

Por ejemplo, consideremos el protocolo apropiado para empezar y terminar una interacción social. Se puede mostrar la disponibilidad para entablar una conversación mirando al interlocutor potencial o aproximándose a la persona. El inicio de la misma suele corresponder con un intercambio verbal estereotipado. Para concluir la conversación se puede producir una frase de agradecimiento seguida de señales visuales.

Este modelo es de aplicación directa en una interfaz con personajes. Así, siempre debe evitarse que el personaje aparezca en pantalla o desaparezca sin la oportuna explicación. El personaje puede saludar al iniciar una conversación y llegado el momento de despedirse, avisar de la intención de partir antes de hacerlo sin más. Las siguientes figuras nos muestran un ejemplo práctico. En la primera viñeta, podemos ver como Peedy da la bienvenida al usuario al comienzo, por ejemplo, de una visita guiada, y en las otras viñetas vemos como advierte al usuario de su partida y se despide.

19


Figura 2.5 Peedy dando la bienvenida Figura 2.6 Peedy se despide

Durante una conversación, los integrantes de la misma se sitúan enfrente uno del otro mientras hablan. Darse la vuelta en ese momento, sin ningún motivo, indica desinterés y suele ser considerado como descortés.

La cortesía, o la ausencia de ella, se demuestra bien en la forma que tenemos de responder a una pregunta. En efecto, no basta sólo con encontrar la respuesta oportuna, sino que debemos cuidar la entonación, la expresión facial y las demás conductas no verbales para no resultar ofensivos.

Otra conducta que puede ser percibida como descortés es la falta de modestia. Por lo tanto, a menos que estemos tratando de implementar un estilo de personalidad descortés deberemos tratar de evitar que nuestro personaje presuma de sus prestaciones.

2.5.10 Usar la alabanza

Debido a que los personajes crean un contexto social, hay que prestar un cuidado especial con el empleo de la crítica y la alabanza.

A la gente le suele agradar una actitud adulatoria. Pero, aunque los humanos respondemos bien ante las alabanzas (incluso siendo inmerecidas), los límites de su administración en interfaces software no están bien definidos.

La alabanza es especialmente efectiva en situaciones donde los usuarios no confían demasiado en su preparación para la realización de una tarea. Pero, la mayoría de las interfaces software se esfuerzan en evitar evaluar a los usuarios, aunque está demostrado que la alabanza es más efectiva que la ausencia de evaluación.

¿Por qué es interesante usar la alabanza? Porque, tradicionalmente, muchas interfaces han sido diseñadas tan neutras que los usuarios las perciben como críticas: raramente reciben realimentación positiva cuando las cosas están operando normalmente, pero sí mensajes de error cuando van mal. Un ejemplo que puede ser visto en la siguiente figura, es el típico mensaje de error de aplicación de una interfaz Windows.

20


Figura 2.7 Mensaje de error de Windows: realimentación negativa

Por lo tanto, de vez en cuando resulta beneficioso lanzar mensajes de ánimo, como puede verse en la siguiente figura, donde el personaje resalta los buenos resultados obtenidos por el usuario.

Figura 2.8 Mensaje de alabanza de Peedy: realimentación positiva

En relación a la crítica, ésta debería ser usada con mucha moderación. Incluso aunque se crea que la crítica es oportuna, hay que tener cuidado, pues la condición humana del usuario es reacia a admitir los errores y las críticas suelen ser redirigidas hacia la fuente de donde parten.

2.5.11 El personaje y el usuario como miembros del mismo equipo

Un factor importante a la hora de diseñar una IU con personajes es decidir qué tipo de relación usuario/personaje se quiere implementar. Como esta relación es de tipo social se debe estudiar las dinámicas sociales que pueden presentarse en la interacción.

Así, puede ser de utilidad presentar al personaje como miembro del mismo equipo que el usuario. Ya que, cuando un equipo es creado, la dinámica del grupo tiene un poderoso efecto sobre sus miembros. Para empezar, la gente en un grupo o equipo tiene una tendencia mayor a identificarse con sus compañeros que con gente de afuera. Y además, los miembros de un equipo tienen más voluntad para cooperar y modificar sus actitudes y conductas.

Crear un sentimiento de equipo se consigue mediante dos factores: identificación e interdependencia:

Se puede crear identificación mediante la utilización de un nombre de equipo, color, símbolo o cualquier otro identificador que usuario y personaje compartan. Por ejemplo,

21


dar la posibilidad al usuario de elegir un nombre de equipo o emplear un icono que podría aparecer con el personaje. La identificación con el personaje puede también conseguirse mediante comentarios del personaje. Por ejemplo, el personaje podría presentarse a sí mismo como un compañero del usuario y comentar que forman un equipo.

Lograr interdependencia puede resultar más duro y requerir más tiempo para ser implementado. Aún así, es importante considerarla pues la interdependencia parece tener un impacto social más fuerte que la identidad de equipo. Crear un sentimiento de interdependencia involucra el demostrar continuamente la utilidad y la fiabilidad del personaje para el usuario. Para ello, sería importante poder responder afirmativamente a dos preguntas en relación al personaje: ¿proporciona valor añadido al usuario? y, ¿opera de manera fiable y predecible?.

Para generar el sentimiento de equipo del que hablábamos anteriormente, es necesario presentar al personaje como un compañero del usuario, pero, en determinados escenarios, puede ser de mayor utilidad presentar al personaje como un sirviente o como un experto. La solución para alcanzar ambos objetivos (interdependencia y dinámica de grupo), puede ser un término medio: crear un sentimiento de igualdad entre usuario y personaje donde el usuario sea dependiente del personaje pero sin un sentido de inferioridad.

Esto podría ser tan simple como que el personaje se catalogara a sí mismo como un compañero de equipo o un colega, mejor que como un mago o experto. O utilizando expresiones apropiadas cuando se solicita información al usuario. Por ejemplo, el personaje podría decir "Trabajemos juntos para resolver esta cuestión...".

2.5.12 Considerar efectos de género

Las respuestas sociales se ven afectadas por el género. Así, existe un estereotipo que considera que los hombres tienen una mayor facilidad o inclinación para tratar con temas técnicos mientras que las mujeres tienen una mayor habilidad para las relaciones interpersonales. El anterior ejemplo no va encaminado a fomentar o perpetuar los estereotipos, sólo a advertir de su existencia, para así poder evaluar su efecto en la interacción con el personaje.

Las connotaciones de género de un personaje no sólo son propiciadas por su nombre o su apariencia. Incluso un personaje de género neutro, como por ejemplo Clipo (el ayudante de Microsoft Office al que podemos ver en la figura de abajo), puede percibirse como masculino o femenino dependiendo de las características de su voz o sus movimientos.

Figura 2.10 Clipo, el ayudante de Office no tiene un género definido

22


2.6 Sonido como Interfaz de Usuario

2.6.1 Presentación

Uno de los principales atractivos de las aplicaciones que incluyen personajes es la posibilidad de que estos hablen. Este atractivo es aún mayor si se consigue centrar la capacidad de interactuar con el usuario en el empleo del sonido.

Una interfaz basada en Agentes Animados se puede catalogar dentro del apartado de las Interfaces habladas de usuario o SUI (Spoken User Interfaces), que consisten en interfaces de usuario con las que se interactúa mediante comandos fijos de voz o mediante diálogos y de las que se obtiene una contrapartida también de forma audible.

Este tipo de interfaces fueron concebidas como sustituto de las Interfaces gráficas de usuario (GUI), pero poco a poco se fueron adaptando a situaciones específicas donde ofrecían ventajas concretas sobre los entornos visuales. Estas interfaces son de gran utilidad en entornos telefónicos, sistemas de navegación por Internet, sistemas en los que las manos y los ojos están ocupados (por ejemplo asistentes para la conducción) o como en el caso de los Agentes Animados para la creación de entornos con interacción de modo natural.

2.6.2 Reconocimiento del habla

Las interfaces de usuario controladas mediante la voz necesitan obtener una representación en texto de las palabras pronunciadas por el usuario, esto es, necesitan incluir reconocimiento del habla.

Microsoft Agent facilita la posibilidad de trabajar con un motor de reconocimiento de voz pues proporciona la interfaz de programación para controlarlo.

Sin embargo, la entrada de habla presenta muchas dificultades. Los motores de habla actuales operan sin partes sustanciales del repertorio de la comunicación hablada humana, tales como gestos, entonación, y expresiones faciales. Como el habla natural es por lo general ilimitada, es fácil para el hablante exceder el vocabulario real, o la gramática, del motor de reconocimiento.

Se puede tratar de restringir las posibilidades de error si el sistema se centra en reconocer comandos de voz, como el motor de reconocimiento que Microsoft Agent soporta.

Aún así no se estará libre de equivocaciones, porque el reconocimiento de habla debe a menudo tratar con grandes variaciones en el entorno del hablante. Por ejemplo, el ruido de fondo, la calidad del micrófono o su localización pueden afectar a la calidad de la entrada. Igualmente, las diferentes pronunciaciones de los hablantes o incluso variaciones en el mismo hablante, como por ejemplo cuando está resfriado, hacen que sea difícil convertir los datos acústicos en representaciones comprensibles. Finalmente, las máquinas de habla deben tratar con palabras o frases de similar sonido dentro de un lenguaje.

23


El éxito en el uso de la entrada de voz no sólo es debido a la calidad de la tecnología. Incluso el reconocimiento humano, el cual excede cualquier tecnología de reconocimiento, falla a algunas veces. Para tratar de paliarlo, en la comunicación humana se usan estrategias que mejoran la probabilidad de éxito y que proporcionan recuperación frente a errores cuando algo va mal. El ejemplo de la comunicación humana llevado al ámbito del reconocimiento de voz por sistemas artificiales, demuestra que la efectividad de la entrada de voz también depende de la calidad de la interfaz de usuario que la presenta.

Así, para conseguir que la interacción resulte lo más natural y adecuada posible la interfaz ha de manejar correctamente los errores producidos por los reconocedores del habla: Los errores de borrado (cuando el reconocedor no puede determinar qué se ha

pronunciado) se pueden solventar reconduciendo al usuario en la conversación de modo que repita la frase con otras palabras o intente hablar de forma más clara para el reconocedor.

Los errores de sustitución (en los que se reconoce una expresión distinta a la pronunciada) pueden producir fallos inesperados en el comportamiento del sistema. Este tipo de errores hace que pueda resultar necesario asegurarse de que se ha comprendido correctamente lo dicho por el usuario. Como la continua comprobación de este tipo de errores supone una considerable carga dentro de la conversación, lo mejor es que se realice solamente en momentos críticos o en los casos en los que se piense que la entrada no se corresponde con lo esperado.

Los Agentes Microsoft facilitan al desarrollador la mejor y las dos siguientes mejores alternativas devueltas por la máquina de reconocimiento de habla. Además, indican el porcentaje de confianza de todas las posibilidades. Esta información puede usarse para tratar de inferir qué es lo que se ha dicho. Por ejemplo, si las puntuaciones de confianza de la mejor y de la primera alternativa son cercanas, esto indicaría que el motor de habla tiene dificultad en discernir entre una de ellas. En tal caso, se puede pedir al usuario que repita para intentar mejorar el reconocimiento. Sin embargo, si la mejor y la siguiente alternativa devuelven el mismo comando, eso reforzaría la indicación de un reconocimiento correcto.

Los errores de inserción (cuando el ruido produce una frase) se pueden tratar con algunos de los métodos anteriores, o incluso desconectando el micrófono o el reconocedor en determinados momentos de la conversación. Muchos sistemas optan por una interfaz click-to-speak (en los que el micrófono o el reconocedor no están operativos hasta que el usuario los activa explícitamente) en contraposición con una interfaz de estilo open-microphone (donde el micrófono y el reconocedor funcionan continuamente). Con el método click-to-speak se consigue descartar hasta un 12,4 % de palabras ininteligibles respecto a un sistema open-microphone, aunque se restringe considerablemente la libertad de interacción con el sistema [Montoro Manrique, 2000].

El motor de reconocimiento de Microsoft Agent es de tipo click-to-speak.

24


2.7 Adaptación a las características especiales de las SUIs

El vocabulario usado en sistemas con interfaces de usuario tradicionales (por ejemplo GUIs) no se puede transferir correctamente a las SUIs. Para estos nuevos casos resulta más conveniente utilizar frases que cumplan las convenciones establecidas dentro de las conversaciones. Sin embargo, para conseguir una alta capacidad de reconocimiento el sistema debe intentar conducir al usuario a respuestas que se encuentren dentro de sus capacidades. Esto implica que se deban utilizar oraciones para el sistema concreto que se está desarrollando.

Los escenarios de entrada de voz a través de personajes que definen claramente el contexto tienen más éxito. El contexto ayuda a clarificar y dirigir las elecciones del usuario (que aprende el rango de la gramática en cada momento) y favorece el reconocimiento de habla al limitarse la gramática activa en cada contexto.

Microsoft Agent incluye construcciones que incrementan el éxito de la entrada de voz mediante la clarificación de la gramática el sistema. Por ejemplo, la ventana de comandos mostrada cuando el usuario dice Abrir Ventana de Comandos de Voz sirve como guía visual de la gramática activa de la máquina de habla.

Puede permitirse que el usuario solicite el contexto mediante un comando, como podría ser Ayuda o ¿Dónde estoy?, a lo cual la interfaz debería responder clarificando el contexto actual, como, por ejemplo, la última acción que la aplicación llevó a cabo.

El modo de organización y presentación de la información puede presentar complicaciones dentro de un entorno conversacional. El flujo de información en una SUI puede resultar confuso para el usuario. Si el diálogo implica subdiálogos puede ser difícil determinar en qué punto se encuentra la conversación, si ya se ha retornado a un estado anterior o si las respuestas corresponden al diálogo en que se suponía estar.

Dado que el habla es un método no persistente de transmisión de la información (lo que puede provocar una carencia de retención por parte del usuario) las oraciones que transmite el sistema han de ser breves, concisas e informativas. Se ha de evitar utilizar palabras que no sean necesarias o que resulten extrañas o repetitivas. Aplicando el principio de que el sistema debe proporcionar la menor cantidad de información posible, aunque nunca menos de la necesaria.

Microsoft Agent trata de paliar el efecto de la no persistencia mediante la duplicación de la información hablada en el globo de texto, pero éste también es un modo no persistente.

2.8 Simular por parte del sistema una conversación de la forma más real y natural que sea posible

Uno de los principales desafíos de este tipo de aplicaciones consiste en poder simular el papel de hablante o de oyente de forma suficientemente convincente como para producir una comunicación satisfactoria con el usuario.

25


En ese sentido, la comunicación es algo más que el reconocimiento de palabras. El proceso de diálogo implica mostrar señales que indiquen a quién corresponde el turno de palabra o que se ha comprendido el mensaje del interlocutor. Los personajes pueden mejorar las interfaces conversacionales mediante señales como inclinaciones de cabeza, asentimientos, o movimientos que indican que el motor de habla está en estado de escucha y que algo está siendo reconocido. Por ejemplo, Microsoft Agent tiene animaciones ligadas al estado de Escuchando cuando el usuario presiona la tecla que indica que quiere decirle algo al personaje.

Otro elemento importante en toda conversación es la entonación. Actualmente se está trabajando en conseguir herramientas de síntesis con unos niveles de entonación similares a los humanos, en los que la voz no suene metálica y sea lo más natural posible.

Las pausas que se realizan en las conversaciones constituyen otro de los factores que se deben tener en cuenta dentro de los diálogos. Se ha de procurar que las pausas generadas por los retrasos en el proceso de reconocimiento sean lo suficientemente cortas para que sean percibidas como naturales. Los silencios se han de evitar siempre que su presencia no corresponda a la situación esperada dentro de una conversación.

Por último, no todos los sistemas permiten interrumpir al sintetizador mientras está pronunciando una oración, lo que puede repercutir en una falta de naturalidad en el diálogo. Microsoft Agent interrumpe la salida de audio cuando detecta entrada de voz por el micrófono, aunque presenta el globo de texto. El sintetizador también debería poder aumentar o disminuir la velocidad de su discurso para simular, en mayor medida, el habla humana. Agent puede ajustar programáticamente la velocidad o el pitch de la voz del sintetizador.

26

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDACaracterísticas de Microsoft Agent®

27


3 Características de Microsoft Agent®

3.1 Potencial de Microsoft Agent 2.0

Si se busca un sistema avanzado de ayuda basado en personajes, Microsoft Agent, es una opción a tener en cuenta porque es una poderosa herramienta para animar y humanizar interfaces de usuario.

Microsoft Agent versión 2.0 proporciona un juego de servicios software programables que pueden usarse para complementar una interfaz de usuario clásica al facilitar la integración de personajes animados interactivos. Gestiona la animación de los mismos e incluye soporte para tecnologías complementarias como entrada y salida de habla, entre otras. Esto favorece y ensancha la comunicación que fluye entre un usuario y sus aplicaciones y permite desarrollar una interfaz de usuario conversacional con un ancho de banda contenido.

Esta tecnología proporciona valor añadido al ser incluida como un componente de una página web o de una aplicación convencional diseñada para plataformas Windows. La siguiente figura es un ejemplo de aplicación animada con personajes:

Figura 3.1 Aplicación animada con personajes

Algunas de las características de Microsoft Agent son:

Se integra como un componente extra manteniendo una estructura orientada a objetos.

El acceso a esta tecnología se realiza desde una interfaz de programación que puede ser codificada desde cualquier lenguaje que soporte COM, tal como C++ o Visual

28


Basic. También incluye un control ActiveX que facilita la programación desde lenguajes tipo script como VBScript o JScript.

Gracias al conversor texto a voz que permite incorporar, no es necesario transmitir la voz natural a través de la línea de comunicación, y se puede disponer de aplicaciones que hablen con un gran ahorro de ancho de banda. Aunque también es posible reproducir un fichero de audio grabado o sacar los mensajes por pantalla en un bocadillo de texto.

Integra reconocimiento de habla, que puede ser usado para que la interfaz responda a comandos o para facilitar la entrada de datos.

Está disponible en la red para descargarlo gratuitamente y puede ser empleado por los desarrolladores en sus aplicaciones sin coste de derechos de autor.

¿Respecto a qué referencias o antecedentes se puede comparar a Microsoft Agent?

Por un lado puede recordar a Microsoft Bob, el cual fue un rotundo fracaso de mercado, pero ambos se diferencian en tres importantes cuestiones:

Microsoft Bob era una aplicación dirigida a nuevos usuarios de PC´s. Consistía en una guía interactiva para una serie de programas. Por contra, Microsoft Agent no es una aplicación, sino una tecnología que se integra con las aplicaciones.

Con Bob los personajes aparecían en una interfaz que enmascaraba la interfaz Windows. Microsoft Agent, sin embargo, se integra sin costuras en las aplicaciones ya existentes y en la interfaz del sistema operativo. Los personajes de Agent aparecen en sus propias ventanas no rectangulares, cuya forma es la silueta de la animación que se esté ejecutando, y pueden aparecer en cualquier lugar de la interfaz convencional.

Además, al contrario que en Bob, los personajes de Agent pueden ser ocultados en cualquier momento a voluntad del usuario, puesto que no ha de ser el sustituto de la interfaz sino un complemento que intenta mejorarla.

Por otro lado, al hablar de Microsoft Agent, se puede pensar que es algo similar al Asistente de Microsoft Office (Clipo por ejemplo). Pero, en realidad, Microsoft Agent es la herramienta para crear ese tipo de aplicaciones.

¿Para qué pueden ser usados los personajes proporcionados por Microsoft Agent?

No están pensados para ningún tipo especifico de aplicación. Los personajes son como actores a los que los desarrolladores les escriben un guión convirtiéndolos en una herramienta determinada. Por ejemplo, los siguientes son sólo unos pocos de los muchos roles que los desarrolladores pueden escribir para un personaje:

Puede ser un anfitrión que saluda a los usuarios la primera vez que encienden el ordenador o instalan una aplicación.

29


Puede ser un guía turístico y hacer una breve explicación acerca de lo que se encuentra disponible en un sitio web o de las capacidades de una aplicación.

Puede ser un tutor que muestra cómo puede llevarse a cabo una tarea paso a paso.

Puede actuar como un agente de ventas, o dirigir al usuario a través de una serie de preguntas hasta la toma de una decisión.

Puede entregar mensajes como recordatorios, avisos, alertas, o cosas similares.

Puede actuar como asistente personal que busque información en Internet y la lea en voz alta.

Puede ser divertido, manteniendo la atención de los niños para enseñarles o entretenerles, por ejemplo, leyéndoles cuentos.

En la siguiente figura podemos ver algunos de los personajes suministrados por Microsoft. De izquierda a derecha podemos ver a Robby el Robot, Peedy el Loro, Genie y Merlin.

Figura 3.2 Galería de personajes de Microsoft

Si no se quieren usar estos personajes, se puede crear un personaje propio y compilar sus animaciones usando el Editor de Personajes de Microsoft Agent.

3.2 Instalación

Para poder acceder a la interfaz del servidor de Microsoft Agent, éste debe estar previamente instalado sobre el sistema. Si se quiere utilizar Microsoft Agent como parte de otras aplicaciones, se debe adquirir una licencia de distribución. El acuerdo de licencia está disponible en la página web:http://www.Microsoft.com/sitebuilder/workshop/imedia/Agent/licensing.asp

El motor de Microsoft Agent, los personajes de Microsoft, los motores de habla, alguna herramienta complementaria, como el editor de personajes, la documentación completa del API, y código de ejemplo pueden ser encontrados en el sitio web de Microsoft Agent en: http://www.microsoft.com/msagent/.

Cuando el fichero de instalación se ejecuta, Agent se instala automáticamente en el sistema. Por lo que, este fichero ejecutable, puede ser incluido como parte del programa de instalación de la aplicación que incorpore Agent como componente.

30

http://www.microsoft.com/msagent/

http://www.microsoft.com/sitebuilder/workshop/imedia/agent/licensing.asp).


El fichero de instalación de Microsoft Agent no se instalará sobre Microsoft Windows 2000, porque esa versión del sistema operativo ya incluye su propia versión de Agent.

Para instalar correctamente Agent sobre un sistema, se debe asegurar que el sistema tiene una versión reciente de la librería de tiempo de ejecución de Microsoft Visual C++ (Msvcrt.dll), la herramienta de registro de Microsoft (Regsvr.dll), y las DLLs COM. La manera más fácil de asegurar que los componentes necesarios están en un sistema es requerir que Microsoft Internet Explorer versión 3.02 o posterior esté instalado. De forma alternativa, se pueden instalar los primeros dos componentes al instalar Microsoft Visual C++ y el componente que resta, las DLLs COM, puede ser instalado como parte de la actualización de Microsoft DCOM, disponible en la página web de Microsoft.

Igualmente, los personajes de Microsoft en formato ACS, están disponibles para distribución en la página web de Microsoft Agent.

Como los componentes de Microsoft Agent están diseñados como componentes de sistema operativo, Agent no puede ser desinstalado. Igualmente, cuando Agent está ya instalado como parte del sistema operativo, el fichero de auto instalación no instalará nada.

3.3 Interfaz de Usuario de Microsoft Agent

Microsoft Agent proporciona varios componentes de interfaz para facilitar a los usuarios acceder e interactuar con los personajes, conocer su estado y cambiar parámetros globales que afectan a todos los personajes. Este apartado describe los elementos básicos de la interfaz de usuario de Microsoft Agent [Microsoft #3, 1998].

3.3.1 Ventana del personaje

Microsoft Agent muestra los personajes animados en sus propias ventanas, las cuales siempre aparecen superpuestas a las demás ventanas. La translación de los personajes en pantalla lo realizan las aplicaciones mediante el método MoveTo del API de Agent. Pero, además, un usuario puede mover la ventana de un personaje arrastrándolo mientras presiona el botón izquierdo del ratón. Las imágenes del personaje se mueven siguiendo al puntero del ratón.

3.3.2 Menú contextual de comandos

Cuando el usuario clica con el botón derecho sobre un personaje, aparece un Menú Contextual emergente como el de la siguiente figura:

31


Figura 3.3 Menú Contextual de comandos

Los comandos se muestran en el menú según el siguiente formato:

Abrir | Cerrar Ventana de Comandos de VozOcultar_______________________________________OtrosComandosPropiosDeLaAplicación

El comando Abrir|Cerrar ventana Comandos de voz controla la aparición de la ventana de comandos de voz del personaje que esté activo en ese momento. Si los servicios de reconocimiento de habla están deshabitados, este comando está deshabitado. Si los servicios de reconocimiento de habla no están instalados, este comando no aparece.

El comando Ocultar ejecuta la animación asignada al estado Hiding (escondiéndose) del personaje y esconde al personaje.

Los comandos propios, OtrosComandosPropiosDeLaAplicación, que la aplicación quiera incluir en este menú, se sitúan detrás del comando Ocultar separados por una línea de división. Por ejemplo, puede verse en la figura anterior como la aplicación correspondiente ha incluido el comando Advanced Character Properties como una de las entradas.

3.3.3 Icono del personaje en la barra de herramientas

Si un personaje ha sido creado para incluir un icono, el icono aparecerá en el área de notificación de la barra de herramientas cuando el servidor de Microsoft Agent está en ejecución y el personaje es cargado.

Figura 3.4 Iconos de Merlín y Genio en la barra de herramientas

Pasando el puntero del ratón sobre el icono se muestra un pequeño cuadrado con el nombre del personaje (en el lenguaje del sistema). Así lo muestra la siguiente figura:

Figura 3.5 Ventana con el nombre del personaje

32


Haciendo click sobre el icono se muestra al personaje. La acción asociada con el doble click sobre el icono depende de la aplicación que esté controlando al personaje en ese momento.

Al hacer click con el botón derecho sobre el icono se muestra el Menú Contextual del personaje. Cuando el personaje es visible, este menú muestra los mismos comandos que aquéllos mostrados al hacer click con el botón derecho sobre el personaje. Si el personaje está escondido, sólo son mostrados los comandos Abrir|Cerrar Ventana de Comandos de Voz y Mostrar.

3.3.4 Ventana de Comandos de Voz

Si un motor de habla compatible está instalado, Microsoft Agent proporciona una ventana especial llamada Ventana de Comandos de Voz que muestra los comandos que están disponibles para reconocimiento de voz. La Ventana de Comandos de Voz sirve como recordatorio visual de lo que puede ser dicho como entrada (estos comandos no pueden ser seleccionados con el ratón).

Figura 3.6 Ventana de Comandos de Voz

La ventana aparece cuando un usuario selecciona el comando Abrir Ventana de Comandos de Voz, bien por decir el comando o haciendo click con el botón derecho sobre el personaje y eligiendo ese comando desde el menú contextual del personaje. Sin embargo, si el usuario deshabilita la entrada de voz, la Ventana de Comandos de Voz no estará accesible.

La Ventana de Comandos de Voz muestra los posibles comandos en forma de árbol. Si la aplicación proporciona comandos de voz, estos aparecen expandidos al comienzo de la ventana. La ventana también incluye los comandos de voz globales proporcionados por Microsoft Agent. Si la aplicación no tiene comandos de voz, sólo aparecen los comandos de voz globales. El usuario puede trasladar la Ventana de Comandos de Voz. Microsoft Agent recuerda la última posición de la ventana y la vuelve a mostrar en esa posición si el usuario reabre la ventana.

3.3.5 Globo de Texto

Para completar la salida de audio hablada, la interfaz de Microsoft Agent proporciona una salida a través de un Globo de Texto, similar al típico bocadillo de texto de los cómics. Las palabras aparecen en el bocadillo mientras van siendo pronunciadas por el

33


personaje. El bocadillo desaparece cuando la salida de habla termina. La Ventana de Opciones Avanzadas de los personajes proporciona opciones para deshabitar este tipo de salida así como para controlar los atributos relativos a su aspecto. El Globo de Texto tiene el aspecto que muestra la siguiente figura:

Figura 3.7 Globo de Texto

3.3.6 Ventana informativa del estado Listening

Si el reconocimiento de habla está habilitado, el usuario puede presionar la tecla click-to-speak (presionar para hablar) para forzar a que el personaje esté atento a la entrada de voz (estado Listening) y así poder comenzar la entrada de voz. En ese momento, aparece una ventana especial que muestra información contextual relativa al estado actual de la entrada de voz. Si un motor de reconocimiento compatible no ha sido instalado o no ha sido habilitado, esta ventana no aparecerá.

Las siguientes son tres ventanas informativas del estado Listening que muestran tres posibles mensajes a modo de ejemplo:

Figura 3.8 Ventanas con mensajes durante el estado Listening

3.3.7 Ventana de Opciones Avanzadas de Personajes

Microsoft Agent mantiene ciertas opciones globales que regulan la interacción con todos los personajes. La Ventana de Opciones Avanzadas de los personajes muestra estas opciones y sus configuraciones actuales. Aunque es mostrada por la aplicación a través del API del Agente, sus opciones sólo son configurables por el usuario. La ventana se divide en tres páginas:

3.3.7.1 Página de salidaEsta página incluye las propiedades que controlan la salida de voz del personaje. Por ejemplo, el usuario puede determinar si quiere mostrar salida a través del Globo de Texto y cómo ha de ser esa salida, si se quiere reproducir salida de voz o si se prefiere mantenerla inhibida, puede indicar si se han de reproducir los efectos de sonido de las animaciones del personaje o puede ajustar la velocidad a la que hablan los personajes.

34


Figura 3.9 Página de propiedades de salida

3.3.7.2 Página de la entrada de vozEl usuario puede ajustar las opciones de la entrada de habla en esta página de propiedades. El usuario puede deshabilitar la entrada de habla, fijar la tecla de comienzo del estado de escucha, elegir si quiere mostrar la ventana de información del estado de escucha, y elegir si se ha de ejecutar una señal MIDI indicando que la entrada de habla está disponible.

Figura 3.10 Página de propiedades de la entrada de voz

3.3.7.3 Página del CopyrightEsta página muestra el copyright e información de la versión de Microsoft Agent.

35


Figura 3.11 Página del Copyright

3.3.8 Ventana de Propiedades del Personaje por Defecto

Las aplicaciones pueden cargar un personaje concreto o no especificar personaje y así cargar el Personaje por Defecto. La figura del personaje por defecto ha sido ideada por Microsoft para convertirla en el asistente centralizado de Windows, que será compartido por las diferentes aplicaciones. Este personaje es accesible desde cualquier aplicación, pero es únicamente seleccionable por el usuario a través de su Ventana de Propiedades. De este modo, las aplicaciones pueden conocer el personaje favorito del usuario. El acceso a esta ventana se realiza a través del API del Agente.

Figura 3.12 Ventana de Propiedades del Personaje por Defecto

36


3.4 Interfaz de programación de Microsoft Agent

La interfaz de programación de aplicación (API) de Microsoft Agent [Microsoft #4, 1998] proporciona servicios de programación entre los que destacan: la habilidad de cargar un personaje, ejecutar una animación, hablar usando un sintetizador de voz, o un fichero de audio (sincronizando la salida automáticamente con el movimiento de los labios del personaje) y aceptar entrada de voz del usuario.

Microsoft Agent ha sido creado como un Servidor de Automatización OLE1. La Automatización OLE consiste en que un programa, el cliente, puede invocar métodos almacenados en otro programa, el servidor, que se ejecuta de forma invisible, de tal modo que el usuario no es consciente de ninguna interacción. La Automatización OLE es una implementación específica de la arquitectura Modelo de Objetos Componentes (COM). La convención COM facilita la integración de componentes, pues regula las interfaces y la forma de interactuar de los componentes, en este caso, cliente y servidor.

De esta manera, Microsoft Agent posibilita que múltiples aplicaciones, llamadas clientes o aplicaciones de cliente, hospeden y accedan a sus animaciones y a sus servicios de entrada y salida a un mismo tiempo. Un cliente puede ser cualquier aplicación que conecte con las interfaces COM del servidor de Microsoft Agent, AgentSvr.exe.

Como cualquier servidor COM, AgentSvr.exe sólo arranca cuando una aplicación cliente usa las interfaces COM y pide conectarse a él. Continúa ejecutándose hasta que todos los clientes cierran sus conexiones. Cuando no queda ningún cliente, el servidor se cierra automáticamente.

3.4.1 Acceso a los servicios de programación

Como Microsoft Agent ha sido creado como Servidor de Automatización OLE, dispone de una interfaz dual para que se acceda a sus servicios:

Por un lado, se puede integrar en una aplicación como un control ActiveX (OLE) y usar un controlador de automatización para acceder a los servicios.

Por otro lado, se puede llamar directamente a la interfaz COM de Microsoft Agent.

Los siguientes subapartados explican con más detalle las diferencias entre ambos métodos de acceso y el porqué de la elección del segundo método en este Proyecto Fin de Carrera:

3.4.1.1 Control ActiveXUsar Microsoft Agent como un control ActiveX se puede hacer desde cualquier lenguaje de programación que sea capaz de implementar un controlador de distribución,

1 Para seguir este capítulo con facilidad y aprovechamiento es necesario poseer conocimientos sobre la arquitectura COM y la Automatización OLE. El Anexo A de este PFC (Anexo A - Programación Basada en Componentes: COM y Automatización OLE) pretende ser un acercamiento a estas arquitecturas software.

37


como por ejemplo C++, Visual Basic, o lenguajes tipo script como VBScript. Como los controles ActiveX están pensados para su uso en Internet, Microsoft Agent puede ser controlado a través de scripts que se incluyan en páginas Web si localmente está instalado la tecnología Agent y si el navegador soporta la interfaz ActiveX.

Incluir Microsoft Agent como control ActiveX en una aplicación creada con Visual C++ 6 es tan fácil como seguir los siguientes pasos:

1. Con el proyecto al que se quiera añadir el control abierto en el compilador Visual C++ 6, hay que seleccionar la opción Add To Project de entre las opciones del menú Project y después seleccionar Components and Controls en el subsiguiente menú. Como muestra la siguiente figura:

Figura 3.13 Opción añadir a un proyecto Componentes y Controles

2. Seleccionar la opción Registered ActiveX Controls en la lista del cuadro de diálogo de la siguiente figura:

Figura 3.14 Carpetas de Componentes y Controles.

3. Buscar el control adecuado, Microsoft Agent Control 2.0, en la galería de controles y pulsar el botón Insert.

38


Figura 3.15 Galería de Componentes y Controles

4. Al pulsar Insert aparece el diálogo de la siguiente figura que nos facilita el nombre de las clases que van a ser creadas y nos posibilita el poder cambiar el nombre de las clases (controles) o el de los ficheros en el que son incluidas sus implementaciones.

Figura 3.16 Diálogo de confirmación de nombre de las clases

Tras esta última operación, Visual C++ construye los esqueletos de las clases2, que en su conjunto dan acceso a toda la funcionalidad de Agent. Gracias a este controlador de distribución es posible acceder a los servicios de Microsoft Agent empleando métodos que tienen exactamente el mismo aspecto que una versión local del objeto de automatización. Estos esqueletos de clases admiten los parámetros correctos, y los

2 Valga el siguiente código como ejemplo de una de esas clases:

CAgentCtlCharacters CAgentCtlEx::GetCharacters(){

LPDISPATCH pDispatch;InvokeHelper(0x3, DISPATCH_PROPERTYGET, VT_DISPATCH,

(void*)&pDispatch, NULL);

return CAgentCtlCharacters(pDispatch);}

39


transforman en un array de VARIANT3 para después llamar a la función Invoke con el objetivo de llamar al verdadero objeto de Automatización OLE: el servidor de automatización AgentSrv.exe.

3.4.1.2 Acceso directo a la Interfaz COM Hacer una llamada a un método o un acceso a una propiedad a través de una interfaz de distribución es un proceso que supone gran cantidad de sobrecarga, lo cual repercute en aumento del tiempo de ejecución respecto a la misma funcionalidad obtenida a través de una interfaz de tabla de funciones virtuales, vtable. Por esta razón, la Automatización OLE también permite a un cliente realizar vinculación mediante una vtable y llamar a las funciones de la interfaz de manera eficiente.

En este PFC se ha optado por esta segunda opción, es decir, por acceder al objeto Agent directamente a través de su interfaz COM. Esta decisión se debe a diversos motivos:

La eficiencia es muy importante en las aplicaciones a las que va destinado: aplicaciones de tiempo real que gestionan animaciones y voz y que, por lo tanto, necesitan un gran ancho de banda. Como acaba de ser comentado, esta opción es más eficiente.

No se necesita control ActiveX puesto que la aplicación no ha sido desarrollada en un lenguaje tipo script sino en C++. El escribir la aplicación en C++ redunda en una mayor facilidad y eficacia en la interacción con la interfaz COM, pues se aprovecha el hecho de que la forma de implementar las tablas de las funciones virtuales, vtable, en COM y C++ sea similar.

3.4.2 Modelo de Objetos de Microsoft Agent

El Modelo de Objetos Microsoft Agent consiste en los objetos de la siguiente lista:

Request (Solicitud de Petición)

Agent (Agente)

Characters (Colección de Personajes)

Character (Personaje)

Commands (Colección de comandos)

Command (Comando)

Balloon (Globo de Texto)

AnimationNames (Colección de Animaciones)

SpeechInput (Entrada de voz)

3 Este tipo de datos es utilizado por OLE para facilitar la compatibilidad entre diferentes lenguajes de programación. Estos tipos especiales como VARIANT o BSTR son analizados con detalle en el Anexo A.

40


AudioOutput (Salida de audio)

CommandsWindow (Ventana de Comandos)

PropertySheet (Ventana de Opciones Avanzadas de Personajes)

En el apartado 3.3, Interfaz de Usuario de Microsoft Agent, ya fueron presentados una gran parte de estos objetos por lo que es fácil imaginar su función específica. A lo largo de los siguientes apartados se analizarán los objetos restantes dando una visión más cercana de cada uno de ellos.

Estos objetos están organizados según la jerarquía que muestra la siguiente figura adaptada de [Microsoft #4, 1998]:

Figura 3.17 Jerarquía de objetos del Objeto Agent.

La línea de puntos indica que pueden existir múltiples objetos de ese tipo instanciados al mismo tiempo.

En la figura se puede apreciar como el objeto principal es el objeto Agent y como el resto de objetos dependen de él, salvo el objeto Request.

El objeto Request no está implementado dentro del objeto Agent, pero es parte integrante del servidor AgentSrv.exe. En concreto se encarga de lanzar los eventos que produce el servidor ante una acción del usuario o para sincronizar las animaciones. Más adelante el proceso de captación de eventos será explicado en detalle.

41


También es de destacar que alguno de esos objetos sean colecciones. El término colección define en general a un grupo de objetos donde, a diferencia de un array, no existen posiciones ordenadas. Las Colecciones de Automatización OLE son colecciones de objetos que cumplen el estándar de interfaz OLE. Son implementadas por pseudo objetos que controlan el acceso a los objetos que agrupan.

Microsoft Agent, siguiendo la norma COM, define unas interfaces que permiten a las aplicaciones acceder a los servicios que implementan los diferentes objetos que lo constituyen. A través de estas interfaces una aplicación puede controlar las animaciones de un personaje, los eventos de entrada de un usuario o especificar la salida de audio.

Figura 3.18 Jerarquía de Objetos, con sus respectivas Interfaces de programación.

El diagrama de la anterior figura muestra la relación entre el Modelo de Objetos y las interfaces de programación. En él se puede observar como la casi totalidad de los

42


objetos del servidor son programables a través de las interfaces que tienden a las aplicaciones clientes.

La excepción la constituye el objeto Request que, como ya ha sido dicho, gestiona el mecanismo de generación de eventos y por lo tanto necesita de una implementación especial, así como de la colaboración de otro objeto, AgentNotifySink, que se instancia en el cliente y sirve para recoger y manejar los eventos. Por simplicidad en el diagrama, se ha prescindido de las interfaces extendidas4 (por ejemplo se incluye la interfaz básica IAgent y no la interfaz extendida IAgentEx).

En los siguientes apartados se explica en detalle los mecanismos de acceso a las interfaces para programar los objetos así como la gestión de eventos.

3.4.3 Puesta en marcha del Servidor AgentSvr.exe

Cuando un cliente desea usar los servicios del objeto Agent, debe pedir a COM que localice el servidor de la clase del objeto, AgentSvr.exe. En ese momento, COM pide al servidor que cree el objeto y devuelve al cliente un puntero a la interfaz inicial del objeto. A través del puntero, el cliente puede llamar a los métodos del objeto o puede solicitar punteros a interfaces adicionales mediante la función miembro IUnknown::QueryInterface.

3.4.3.1 Conexión al Servidor: Implementación de la localización y registroCOM proporciona una API de creación genérica, CoCreateInstance, la cual instancia un objeto, conocido su CLSID. Así, para crear un ejemplar del objeto Agent y recibir un puntero a su interfaz, IAgentEx, se debe codificar lo siguiente:

IAgentEx *pAgentEx=NULL;hRes = CoCreateInstance(CLSID_AgentServer, NULL, CLSCTX_SERVER, IID_IAgentEx, (LPVOID *)&pAgentEx);

Entre los parámetros pasados por el cliente en la función CoCreateInstance, destacan el identificador de clase (CLSID) del servidor (CLSID_AgentServer) y el identificador de interfaz (IID) de la interfaz inicial (IID_IAgentEx).

Si la función tiene éxito, se creará un nuevo objeto Agent y a la salida, la variable puntero pasada por referencia en el último argumento, pAgentEx, recibirá el puntero a la interfaz IAgentEx del nuevo objeto COM. Pero para llegar a ese punto, hay un complejo camino que la biblioteca COM se encarga de gestionar. La siguiente figura, adaptada de [Williams, 1994] para el caso particular de Microsoft Agent, trata de representarlo:

4 Las interfaces del servidor de Microsoft Agent a menudo incluyen interfaces extendidas que incluyen un sufijo "Ex". Estas interfaces son versiones mejoradas que derivan de las versiones no extendidas y por lo tanto incluyen toda su funcionalidad.

43


Figura 3.19 Localización y activación de un objeto

En el diagrama se puede seguir el proceso a través de los números colocados en cinco momentos clave:

1. La aplicación cliente llama a CoCreateInstance para instanciar el objeto Agent y obtener un puntero a su interfaz a través del cual pueda comenzar a usar los servicios del objeto.

2. La biblioteca COM busca en el Registro de Windows a través del CLSID. Toda la información relativa al objeto que las bibliotecas COM necesitan, está concentrado bajo una entrada en el registro de Windows: HKEY_CLASSES_ROOT\CLSID\ CLSID_AgentServer. La siguiente figura muestra el editor del registro expandido para mostrar la entrada correspondiente al CLSID del objeto Agent.

Figura 3.20 CLSID del objeto Agent

Una de esas entradas (LocalServer32 al ser el servidor Agent un servidor local o fuera de proceso) nos indica la localización en el sistema del gestor de proceso, el ejecutable AgentSvr.exe. En la siguiente figura puede verse en detalle como el path donde reside el servidor, C:\ARCHIVOS DE PROGRAMA\MICROSOFT AGENT\AGENTSRV.EXE, está registrado en la entrada LocalServer32.

44


Figura 3.21 Localización del gestor de proceso: el servidor AgentSvr.exe

3. Una vez que COM ha localizado al servidor, llama a la función CreateProcess (del API de Win32) para lanzarlo. El servidor, en ese momento, inicializa COM en su propio espacio de proceso. Cuando esto ocurre, COM en el proceso del servidor conecta con COM en el proceso del cliente.

4. CoCreateInstance devuelve a la aplicación un puntero a la interfaz del Objeto. Como el objeto está en un proceso diferente al del cliente, COM automáticamente organiza el puntero mediante una técnica denominada dominación (marshalling).

5. Finalmente, a través del puntero a la interfaz se pueden usar los servicios del objeto o conseguir punteros a las demás interfaces. Por ejemplo, como muestra la Figura 3.19, el método Load.

3.4.3.2 Cargando el personaje y los datos de animaciónUna vez que se tiene el puntero a la interfaz IAgentEx, se puede usar el método Load para cargar un personaje y acceder a su interfaz IAgentCharacterEx. Hay tres diferentes posibilidades para especificar la ruta de directorios de un personaje concreto al método Load. La primera es compatible con Microsoft Agent 1.5, donde la ruta especificada es la ruta completa más el nombre del fichero del personaje. La segunda posibilidad es especificar únicamente el nombre de fichero, en cuyo caso, Agent mira en su directorio de personajes. La última posibilidad es pasarle a la función un parámetro vacío, para que se cargue el personaje por defecto.

// Crea un Variant para almacenar el nombre de fichero del// personaje que se quiere cargar.

const LPWSTR kpwszCharacter = L"merlin.acs";

VariantInit(&vPath);

vPath.vt = VT_BSTR; vPath.bstrVal = SysAllocString(kpwszCharacter);

// Carga el personaje hRes = pAgentEx->Load(vPath, &lCharID, &lRequestID);

// Obtención de su interfaz IAgentCharacterEx hRes = pAgentEx->GetCharacterEx(lCharID, &pCharacterEx);

Ahora se puede usar esta interfaz para acceder a los métodos del personaje:

// Muestra el personaje. El primer parámetro le pide a Microsoft

45


// Agent que muestre el personaje ejecutando una animación. hRes = pCharacterEx->Show(FALSE, &lRequestID);

// Hace hablar al personaje. bszSpeak = SysAllocString(L"Hello World!");

hRes = pCharacterEx->Speak(bszSpeak, NULL, &lRequestID);

SysFreeString(bszSpeak);

Cuando los servicios de Microsoft Agent no se necesiten, como por ejemplo cuando la aplicación que los usa se va a cerrar, hay que liberar sus interfaces. La liberación de la interfaz del personaje no descarga el personaje. Hay que llamar al método Unload para descargarlo antes de liberar la interfaz IAgentEx.

// Limpiezaif (pCharacterEx){ // Libera la interfaz del personaje pCharacterEx->Release();

// descarga el personaje. pAgentEx->Unload(lCharID);} // Libera AgentpAgentEx->Release();

VariantClear(&vPath);

3.4.3.3 Crear un recolector de eventos (Notification Sink)El servidor AgentSvr.exe puede estar atento a la ocurrencia de ciertos acontecimientos, para cuando sucedan generar notificaciones de eventos al cliente. Para acceder a las notificaciones de los eventos que ocurran por Microsoft Agent, se debe crear un recolector de eventos (Notification Sink).

Este recolector consiste en una interfaz de distribución, IAgentNotifySink, a la que el servidor llama cuando lanza un evento. La interfaz proporciona funciones que recogen los eventos pero no los tratan, al ser funciones vacías. Por lo tanto, la aplicación cliente tiene que implementar el código de las funciones correspondientes a los eventos que quiera manejar.

Para poner en marcha el recolector se ha de crear un objeto AgentNotifySink y registrar la interfaz en el servidor, para que éste tenga un punto de entrada (el puntero a la interfaz, pIAgentNotifySink). Como muestra el siguiente código:

// Crea un notification sinkpSinkEx = new AgentNotifySinkEx;

pSinkEx->AddRef();

// Y lo registra con Microsoft AgenthRes = pAgentEx->Register((IUnknown *)pIAgentNotifySink, &lNotifySinkID);

46


Cada vez que el Servidor detecta una acción del usuario merecedora de evento, o ocurre algún acontecimiento en la cola de animaciones de personajes, se crea un objeto Request, el cual generará el evento apropiado. Este objeto conoce cuál es la función de la interfaz IAgentNotifySink que recoge la información sobre ese evento, por lo que llama a la función IAgentNotifySink::Invoke() con el identificador de la función recolectora (ID_REQUEST_COMPLETE por ejemplo) y los parámetros apropiados (en el caso de RequestComplete, el identificador de petición de ejecución de una animación y un parámetro de estado). La siguiente figura lo muestra de forma gráfica:

Figura 3.22 Los Objetos Request acceden al objeto AgentNotifySink a través de un puntero a su Interfaz para comunicarle los eventos.

La interfaz de distribución habrá implementado la función que maneje ese evento (IAgentNotifySink::RequestComplete) y gestionará la información aportada por el servidor de la forma que el programador de la aplicación cliente considere oportuna.

Por ejemplo, si una aplicación quiere sincronizarse con la finalización de una animación puede generar el siguiente código:

// Animación con la que hay que sincronizarse. // g_lDone recibe el identificador de petición de ejecuciónpCharacter->GestureAt(150, 100, &g_lDone);

// Comienza un bucle de mensases que continuará hasta // recibir un mensaje WM_QUIT. while (GetMessage(&msg, NULL, 0, 0) > 0)

DispatchMessage(&msg);

El encargado de mandar el mensaje WM_QUIT, para que el programa pueda continuar con el resto de código será la función recolectora del evento, RequestComplete. Para ello implementará un código que chequee que los identificadores de las animaciones que vayan llegando de la cola de animaciones coincidan con el propio de la función por la que se espera (g_lDone que será pasada al contexto de la interfaz de distribución como variable externa), momento en el cual enviará el mensaje WM_QUIT a la aplicación para que continúe. Como muestra el siguiente código:

extern long g_lDone;

STDMETHODIMP AgentNotifySink::RequestComplete ( long dwRequestID,

47


long hrStatus ) {

// Compara los identificadores de animaciones completadas con la // variable g_lDone que alberga el identificador de la animación // por la que se espera y manda un mensaje.

if (dwRequestID == g_lDone)PostQuitMessage(0);

return NOERROR;}

Hay que recordar desregistrarse antes de cerrar la aplicación o de liberar las interfaces de Microsoft Agent.

pAgentEx->Unregister(lNotifySinkID);

pSinkEx->Release();

3.4.4 Servicios de Animación

Los servicios de animación de Microsoft Agent manejan la animación y la translación de la imagen de un personaje dentro de su propia ventana sobre la pantalla.

Cuando un cliente lo solicita, el servidor carga y ejecuta el fichero de animación del personaje. Una animación se define como una secuencia de fotogramas, compuesta de una o más imágenes y datos de efectos de sonido. El servidor dibuja la imagen, en una ventana cuyo marco se ajusta a la silueta de la imagen. De esta manera se permite que el personaje aparezca en cualquier lugar de la pantalla independientemente de la ventana de la aplicación cliente. Está técnica de animación, destaca no sólo por su flexibilidad para mostrar al personaje, sino también porque crea la ilusión de que el personaje está operando dentro del entorno del usuario.

Se pueden definir personajes propios para usar con Microsoft Agent. Para crear las imágenes de las animaciones, cualquier herramienta de edición gráfica que pueda salvar en formato de mapa de bits de Windows (.bmp) puede ser empleada. Después, para ensamblar y compilar en forma de animación las imágenes de un personaje, se debe emplear el Editor de Personajes de Microsoft Agent. Esta herramienta permite definir las animaciones y las propiedades por defecto para el personaje, salvando el resultado en formato compatible con Microsoft Agent.

3.4.4.1 Cargar un personajePara poder animar un personaje, primero ha de ser cargado. Para ello se llama al método Load. El formato de fichero único (.acs) se usa cuando los datos del personaje y sus animaciones están almacenados localmente. Otros formatos de fichero (.acf, .aca) se deben usar para descargar animaciones individuales desde un servidor HTTP.

Aunque ya se anticipó anteriormente (en la puesta en marcha), a continuación se muestra el código necesario para cargar un personaje:

VARIANT vPath;

48


static const LPWSTR kpwzChar = L"\\Win95_32\\Msagent\\Chars\\Genie.acs";

// Prepara la cadena de texto con el PathvPath.vt = VT_BSTR;vPath.bstrVal = SysAllocString(kpwzChar);

// Intenta cargar a GeniohRes = pAgentEx->Load(vPath, &lCharID, &lRequestID);

Una aplicación de un cliente puede cargar únicamente una instancia del mismo personaje. Cualquier intento de cargar un mismo personaje más de una vez fallará. Sin embargo, una aplicación puede tener múltiples instancias del mismo personaje, si el personaje es cargado en conexiones separadas a Microsoft Agent.

3.4.4.2 Cargar el Personaje por DefectoComo ya ha sido comentado en el apartado de interfaz de usuario, el personaje por defecto puede ser elegido por el usuario a través de la hoja de propiedades, que incluye Microsoft Agent, conocida como la Ventana de Propiedades del Personaje por Defecto. Se puede llamar a esta ventana desde una aplicación mediante el método ShowDefaultCharacterProperties, pero sólo el usuario, mediante interacción directa, es capaz de cambiar su configuración.

//Muestra la Ventana de Propiedades del Personaje cargado por Defecto.//Permite recorrer la galería de personajes instalados en el sistema//y fijar el personaje que se quiera cargar por defecto.hRes = pAgentEx->ShowDefaultCharacterProperties(10,10,0);

La selección de un personaje por defecto, está limitada a aquellos que incluyan un juego mínimo de animaciones estándar. El objetivo de esta restricción es tener un nivel de consistencia entre personajes.

Como el personaje por defecto está pensado para propósito general y su uso puede ser compartido por otras aplicaciones al mismo tiempo, es conveniente evitar cargarlo cuando se quiera un personaje exclusivo para la aplicación.

Para cargar el personaje por defecto, se llama al método Load sin especificar un nombre de fichero o ruta de acceso. Como muestra el siguiente código

// Prepara una cadena vacíaVariantInit(&vPath); vPath.vt = VT_EMPTY;

// Intenta Cargar el personaje por DefectohRes = pAgentEx->Load(vPath, &lCharID, &lRequestID);

Si el usuario no ha seleccionado un personaje como personaje por defecto, Microsoft Agent selecciona el primer personaje que soporte el juego de animaciones estándar. Si no hay ninguno disponible, el método fallará, señalando la causa en la variable de retorno. El servidor notifica a los clientes que han cargado el personaje por defecto cuando un usuario lo cambia, pasándole el GUID del nuevo personaje. El servidor

49


automáticamente descarga el primero y recarga el nuevo personaje. Las colas de todo cliente que tuviera cargado el personaje por defecto son paradas y purgadas. Sin embargo, las colas de los clientes que hubieran cargado el personaje explícitamente usando el nombre de fichero del personaje no se ven afectadas.

3.4.4.3 Animando un personajeUna vez que el personaje es cargado, se pueden usar los métodos de animación de personajes. Típicamente, el primero en usarse es el método Show. El cual hace visible el marco del personaje y ejecuta la animación del estado Showing asignada al personaje, si el primer parámetro es FALSE.

// Muestra el personaje ejecutando una animaciónhRes = pCharacterEx->Show(FALSE, &lRequestID);

Para ejecutar una animación, una vez que el marco del personaje es visible, se puede usar el método Play especificándole el nombre de una animación. La forma de usarlo es la siguiente:

BSTR bszAnimation; // Prepara el nombre de la animación de saludobszAnimation = SysAllocString(L"Greet");

// Ejecuta la animación correspondientepCharacterEx->Play(bszAnimation,&lRequestID);

// Libera la cadena de textoSysFreeString(bszAnimation);

Los nombres de las animaciones son específicos para cada personaje y son asignados durante la definición de éste. Cuando una animación se ejecuta, la forma de la ventana cambia para igualar la imagen en el marco. Esto resulta en una imagen gráfica trasladable, o sprite, mostrada superpuesta a todas las demás ventanas.

El método Speak permite programar al personaje para que hable, sincronizando la salida con el movimiento de los labios. Se darán detalles al respecto en la sección de servicios de salida de este capítulo.

Con MoveTo se traslada al personaje a una nueva posición. Cuando se llama a este método, Microsoft Agent automáticamente ejecuta la animación apropiada según la localización relativa del personaje en la pantalla respecto a la posición donde ha de ir.

// Cambia el personaje de localización en la pantallapCharacterEx->MoveTo(500, 500, 10, &lRequestID);

La siguiente figura corresponde con un fotograma de la animación resultante de la ejecución del método MoveTo:

50


Figura 3.23 Merlín ejecutando una animación de transición cuando se le pide con el método MoveTo que ocupe una nueva posición en la pantalla.

Igualmente, cuando se llama a GestureAt, el personaje señala hacia la posición de pantalla que le pasa como parámetro basándose en la localización del personaje.

// Fuerza a que el personaje señale hacia la dirección marcada por // las coordenadas (100,100)m_pCharacter->GestureAt(100,100, &lRequestID);

Para ocultar el personaje, hay que llamar al método Hide. Antes de ocultarse el personaje, pasa automáticamente, como transición, por el estado Hiding si el primer parámetro de la función está fijado a FALSE.

// Esconde el personajepCharacterEx->Hide(FALSE,&lRequestID);

Microsoft Agent procesa todas las llamadas a animaciones, o peticiones, de forma asíncrona. Esto permite al código de la aplicación continuar manejando otros eventos mientras la petición va siendo procesada. Las nuevas peticiones se colocan al final de una cola, tras las peticiones previas que restan por ejecutarse. Llamadas a posteriores funciones pueden ejecutarse antes de que termine una animación. Por ejemplo una función que vaya tras una llamada a los métodos Play o MoveTo se ejecutará antes de que la animación termine.

Para sincronizar las animaciones con la ejecución del código, se puede crear un objeto referencia a la petición de animación, y así se puede saber cuándo comienza o finaliza la animación, monitorizando los eventos Request que el servidor usa para avisar a sus clientes.

Si, por ejemplo se quiere que aparezca una ventana cuando el personaje termina una animación, esa ventana podría ser lanzada desde una subrutina que espera por el evento RequestComplete que corresponda con el identificador de la petición en cuestión. Un ejemplo práctico puede verse en el apartado 3.4.3.3 (Crear un recolector de eventos (Notification Sink)).

Cuando un personaje está escondido, el servidor no ejecuta las animaciones que se le solicitan; sin embargo, las encola y procesa las peticiones de animación (como si fueran ejecutadas las animaciones) y devuelve el estado de la petición. Estando escondido, el personaje nunca tiene la entrada activa. Sin embargo, si el usuario dice el nombre del personaje (cuando la entrada de voz está habilitada) el servidor muestra el personaje de forma automática.

51


Cuando existe un único personaje, cada petición de animación se ejecuta al terminar de ejecutarse la petición previa; Es decir, se ejecutan secuencialmente. Cuando la aplicación cliente carga múltiples personajes al mismo tiempo, los servicios de animación de Microsoft Agent permiten animar los personajes independientemente o usar los métodos Wait, Interrupt, o Stop para sincronizar las animaciones de los personajes.

Por ejemplo, si se tienen dos personajes, y se quiere que la petición de animación de un personaje espere hasta que la animación del otro personaje termine, hay que llamar al método Wait con el identificador de la petición de la animación del personaje. El siguiente ejemplo ilustra este caso:

// Genio habla a MerlínbszSpeak = SysAllocString(L"¡Hola Merlin!");

pGenie->Speak(bszSpeak, NULL, &lWaitID);

SysFreeString(bszSpeak);

// Hace que Merlin espere a que Genio termine de hablarpMerlin->Wait(lWaitID, &lRequestID);

// Merlín contesta a GeniobszSpeak = SysAllocString(L"¿Qué tal Genio?");

pMerlin->Speak(bszSpeak, NULL, &g_lDone);SysFreeString(bszSpeak);

Microsoft Agent ejecuta algunas animaciones de forma automática. Por ejemplo si el estado de un personaje no ha cambiado durante varios segundos, el Agente comienza a ejecutar las animaciones de estado ocioso (Idling) asignadas al personaje. O cuando está habilitada la entrada de voz, el Agente ejecuta la animación Listening y luego, cuando se detecta nivel de audio en el micrófono, el estado Hearing. Estas animaciones manejadas por el servidor son llamadas estados, y son definidos cuando un personaje es creado.

Por ejemplo, en la figura podemos ver la animación del estado Hearing.

Figura 3.24 Estado Hearing.

52


3.4.5 Servicios de Entrada

La aplicación cliente proporciona la primera capa de la interfaz que interacciona con un personaje. Así, se puede programar un personaje para que responda a cualquier forma de entrada, desde apretar un botón o introducir algo por el teclado. Pero además, Microsoft Agent proporciona eventos, para que se pueda programar lo que debe ocurrir, cuando el usuario, hace click o doble click o arrastra al personaje.

3.4.5.1 Cliente con entrada activaComo muchas aplicaciones cliente pueden compartir el mismo personaje y como múltiples clientes pueden usar diferentes personajes al mismo tiempo, el servidor designa un cliente como el de entrada activa y proporciona entrada de ratón y de voz sólo a la aplicación de ese cliente. Así, se mantiene el correcto manejo de la entrada de usuario, para que el cliente apropiado responda a la entrada.

Cuando el servidor procesa el método Show de un personaje, el cliente de ese personaje pasa a tener la entrada activa. A partir de entonces, es la interacción del usuario (hacer click sobre el personaje, decir el nombre de un personaje...) lo que determina cuál es la aplicación cliente que pasa a tener la entrada activa.

Cuando un personaje es ocultado, su cliente deja de ser el de entrada activa. El servidor automáticamente pasa a considerar como cliente activo a alguno de los restantes personajes con entrada activa. Cuando todos los personajes son ocultados, ningún cliente tiene entrada activa. Sin embargo, si en esta situación, la tecla Listening es presionada el reconocimiento sigue funcionando para el último personaje que fue cliente activo.

Se puede fijar que un cliente esté activo o no activo usando el método Activate. Se puede programar de tal manera que sólo al activar la ventana de aplicación, se le dé entrada activa al personaje mediante el método Activate, para evitar interferir con otros clientes del personaje. Por ejemplo, si el usuario hace click en tu ventana de aplicación, activando tu aplicación, puedes llamar al método Activate para recibir y procesar entrada de voz y ratón dirigido al personaje.

3.4.5.2 Soporte para Menú ContextualMicrosoft Agent incluye un Menú Contextual emergente para cada personaje. El servidor añade automáticamente al menú comandos para abrir la Ventana de Comandos de Voz y para esconder al personaje, así como los nombres de otros comandos de otros clientes del personaje para permitir a los usuarios conmutar entre clientes. El servidor automáticamente añade un separador en el menú entre sus propias entradas y aquellas definidas por el cliente.

El servidor muestra este menú automáticamente cuando un usuario clica el botón derecho de ratón sobre el personaje. A parte de los comandos que incluye el Servidor por defecto, se pueden añadir comandos al menú para una determinada aplicación cliente mediante la definición de una colección de comandos (Commands).

53


Para acceder a la colección de comandos hay que obtener un puntero a la interfaz IAgentCommands llamando a la función del API de COM QueryInterface través del un puntero a IAgentCharacter, interfaz de la que depende.

IAgentCommands *pCommands;pCharacter->QueryInterface(IID_IAgentCommands, (LPVOID *)&pCommands);

Una vez obtenida la interfaz se pueden añadir comandos propios a través de la función IAgentCommands::Add de la siguiente manera:

BSTR bszCommand;long lComentarTablaID;bszCommand = SysAllocString(L"Comentar Tabla");

pCommands->Add(bszCommand, bszCommand, TRUE, TRUE, &lComentarTablaID);SysFreeString(bszCommand);

El primer, segundo y tercer parámetro se corresponden con las propiedades Caption, Voice y Visible, respectivamente, del comando en la colección que se define. Siendo Caption el texto que aparece en el menú cuando la propiedad Visible está fijada a True. La propiedad Voice la utiliza el servidor para llamar a este comando desde la ventana de comandos de voz. Se puede usar la propiedad Enabled (cuarto parámetro) para mostrar el comando en el menú como deshabilitado. La definición de la tecla de acceso rápido para el texto del menú se hace incluyendo el símbolo & antes del carácter de texto que se quiera en el texto de Caption.

El efecto del código anterior es el que refleja la siguiente figura:

Figura 3.25 Menú Contextual de Comandos

El servidor manda un evento AgentNotifySink::Command con el identificador de comando (almacenado en la variable lComentarTablaID) cuando el usuario selecciona ese comando del menú mediante el ratón, el teclado o la ventana de comandos de voz. Es entonces en el recolector de eventos (en Notify.cpp) dónde se debe enlazar el comando con la funcionalidad que se le quiera dar. Por ejemplo:

extern long lComentarTablaID;

AgentNotifySink::Command(long dwCommandID, IUnknown * punkUserInput) {

if (dwCommandID == lComentarTablaID)ComentarTabla();

return NOERROR;}

54


Para quitar comandos del menú, se usa el método Remove. Los cambios en el menú sólo entran en funcionamiento cuando el menú se vuelve a dibujar, no mientras se está mostrando.

Si se prefiere proporcionar el servicio de menú emergente más personalizado, se puede usar la propiedad AutoPopupMenu para deshabilitar la aparición automática del menú gestionada por el servidor al clicar con el botón derecho.

//Cuando el parámetro es TRUE, pinchando con botón derecho del ratón //sobre el personaje, en la pantalla o en la barra de tareas, se //muestra el menú emergente. Cuando es FALSE se inhabilita tal acción.

hRes = pCharacterEx->SetAutoPopupMenu(FALSE);

Se puede usar la notificación del evento Click para crear una conducta propia de manejo de menú.

Cuando el usuario selecciona un comando del Menú Emergente o de la Ventana de Comandos de Voz, el servidor lanza el evento Command del cliente asociado y devuelve los parámetros de la entrada usando el objeto UserInput.

El servidor también proporciona el mismo menú contextual desde el icono del personaje en la barra de tareas. Cuando el personaje es visible y se hace click sobre él con el botón derecho, se muestra el mismo menú, que si se clica sobre el personaje con el botón derecho del ratón. Si está oculto, sólo aparecen en el menú los comandos suministrados por el servidor.

3.4.5.3 Soporte para entrada de hablaPara complementar la entrada mediante ratón y teclado, Microsoft Agent incluye soporte directo para entrada de voz.

Aunque los servicios de Microsoft Agent incluyen el soporte para entrada de habla, un motor de reconocimiento de habla aislada, tipo Comando y Control (Command and Control), debe ser instalado en el sistema para poder acceder a los servicios de entrada de habla de Agent y conseguir que los personajes soportados por Agent sean capaces de recibir comandos de voz.

El motor de reconocimiento funciona mediante el método click-to-speak (presionar para hablar). El usuario puede comenzar la entrada de habla tras presionar y mantener sostenida la tecla Listening (ajustable desde las Ventana de Opciones Avanzadas de Personajes). En este modo Listening, si el motor de habla recibe el comienzo de la entrada de habla, mantiene el canal de audio abierto hasta que detecta el fin de la articulación de la voz. Sin embargo, cuando no recibe entrada no se bloquea la salida de audio. Esto posibilita que el usuario lance diversos comandos de voz mientras presiona la tecla, y el personaje puede responder cuando el usuario no esté hablando.

El modo Listening expira una vez que usuario deja de presionar la tecla Listening. El usuario puede ajustar el tiempo de expiración para este modo usando las Opciones

55


Avanzadas de Personajes. Desde el código de la aplicación de cliente no se puede fijar este tiempo de expiración.

Si el personaje intenta hablar mientras el usuario lo está haciendo, la salida audible del personaje fallará, aunque el texto puede ser mostrado en el globo de texto. Si el personaje está usando el canal de audio mientras la tecla Listening es presionada, el servidor automáticamente devuelve control al usuario después de procesar el texto en el método Speak. Una señal MIDI opcional es lanzada para indicar al usuario que puede comenzar a hablar. Esto facilita al usuario el conocer cuándo es su turno de entrada, incluso si la aplicación que maneja el personaje no proporciona correctamente pausas lógicas en su salida.

Se puede usar también el método Listen para iniciar la entrada de habla. Llamando a este método comienza a funcionar el reconocimiento de habla por un periodo de tiempo predefinido. Si no hay entrada durante ese intervalo, Microsoft Agent desactiva el reconocimiento automáticamente y libera el canal de audio. Esto evita bloquear la entrada o la salida del dispositivo de audio y minimiza la carga que supone al procesador tener el motor de reconocimiento en funcionamiento. También se puede usar el método Listen para apagar la entrada de habla. Sin embargo, hay que tener cuidado porque al no funcionar la máquina de reconocimiento de habla de manera asíncrona, el efecto puede no ser inmediato. Como resultado es posible recibir un evento Command incluso después de que el código llamó a Listen para desactivar la entrada de voz.

Para soportar entrada de voz hay que definir una gramática, el conjunto de palabras que se quieren usar para que el motor de reconocimiento equipare lo que ha capturado con lo que tiene definido para cada comando (Command) de la colección de comandos.

Tanto si un usuario presiona la tecla Listening o si la aplicación cliente llama al método Listen para iniciar la entrada de voz, el motor de reconocimiento intenta casar lo que ha capturado con la gramática de los comandos que han sido definidos, y devuelve la información al servidor. Entonces el servidor notifica a la aplicación de cliente usando el evento Command (IAgentNotifySink::Command), que indica el identificador del comando con mayor probabilidad. Mediante esta función se obtiene el objeto UserInput que incluye el identificador del comando que más probabilidad tiene de haber sido el que el usuario ha pronunciado y la de las dos alternativas siguientes (si las hay), una puntuación de confianza y el texto del vocablo entendido y el de cada una de las alternativas.

Cuando se entra en el modo Listening, el servidor automáticamente ejecuta la animación que el personaje tiene asignada para este estado. Luego, cuando detecta señal en el micrófono, ejecuta la animación del estado de escucha (estado Hearing). El servidor mantendrá al personaje en estado de atención hasta que de detecte el fin de la entrada de micrófono. Esto proporciona la realimentación social apropiada indicándole al usuario que está siendo escuchado.

Si el usuario deshabilita la entrada de voz en la ventana de Opciones Avanzadas de Personajes, la tecla del estado de escucha permanecerá deshabilitada también. Igualmente llamar al método Listen cuando la entrada de voz está deshabitada provoca que el método falle.

56


3.4.5.4 Elección del motor de habla El fijar el identificador (ID) de lenguaje para un personaje determina su lenguaje por defecto para entrada de habla. Microsoft Agent requiere que para ese lenguaje se tenga un motor de habla instalado que cumpla con el estándar SAPI. Si la aplicación de un cliente no especifica una preferencia de lenguaje, el Agente intentará encontrar un motor de reconocimiento de habla que iguale el identificador del lenguaje por defecto del usuario. Si no hubiera motor disponible que igualara este lenguaje, el habla queda deshabilitada para ese personaje.

Se puede requerir también un motor de reconocimiento de habla especificando su identificador de modo (usando la propiedad SRModeID del personaje). Sin embargo, si el identificador de lenguaje para ese identificador de modo no es igual a la configuración del lenguaje del cliente, la llamada fallará. El motor de reconocimiento del habla permanecerá como el último motor satisfactoriamente fijado por el cliente, o si no fue ninguno, el motor que iguale al actual identificador del lenguaje del sistema. Si esto último tampoco es satisfactorio, la entrada de habla no estará disponible para ese cliente.

Microsoft Agent carga automáticamente un motor de reconocimiento del habla cuando la entrada de habla es iniciada al presionar la tecla Listening o cuando el cliente con entrada activa llama al método Listen. Sin embargo, un motor puede ser cargado también cuando se fija o se pregunta por el identificador de modo, fijando o preguntando por las propiedades de la Ventana de Comandos de Voz, preguntado por su estado (SRStatus), o cuando el habla está habilitada y el usuario muestra la página de Entrada de Habla de las Opciones Avanzadas de Personajes. Sin embargo, sólo se mantienen cargados los motores de habla que estén siendo usados por los clientes.

3.4.5.5 Eventos de entrada de hablaAdemás de la notificación de los eventos de comando, el agente también notifica al cliente con entrada activa cuando el servidor enciende o apaga el modo de escucha (estado Listening), usando los métodos ListenStart y ListenComplete (IAgentNotifySinkEx::ListeningState). Sin embargo, si el usuario presiona la tecla del modo de escucha y no hay motor reconocimiento de habla disponible para el personaje cliente con entrada activa, el servidor no genera un evento ListenStart.

3.4.5.6 Ventana de Comandos de VozLa Ventana de Comandos de Voz muestra los comandos de voz activos disponibles para el personaje. La ventana aparece cuando el comando Abrir Ventana de Comandos es elegido en el Menú Emergente o la propiedad visible del objeto ComandsWindow es fijada a True.

IAgentCommandsWindow *pCmdWin;

// Solicita la interfaz IAgentPropertySheet pAgentEx->QueryInterface(IID_IAgentCommandsWindow, (LPVOID *)&pCmdWin);

// Muestra la Ventana de Propiedades AvanzadaspCmdWin->SetVisible(TRUE);

57


Si el motor de habla no ha sido cargado todavía, preguntar por esta propiedad provocará que Microsoft Agent intente inicializar el motor. Si el usuario deshabilita el habla, la ventana aún se muestra; sin embargo, incluirá un mensaje de texto que informe al usuario que el habla está actualmente deshabitada.

3.4.5.7 Ventana de Opciones Avanzadas de PersonajesLa ventana de Opciones Avanzadas de Personajes se emplea para que los usuarios configuren las características comunes para la interacción con todos los personajes. Por ejemplo, los usuarios pueden deshabilitar la entrada de voz o cambiar los parámetros de entrada. Pueden también configurar la salida a través del globo de texto. Estos cambios están por encima de cualquier cambio fijado por una aplicación cliente o fijados como parte de la definición de un personaje. Una aplicación no puede cambiar o deshabilitar estas opciones, porque se aplican a las preferencias de usuario generales para la operación con todos los personajes. Sin embargo, el servidor notificará a cada aplicación activa, mediante el evento AgentNotifySink::DefaultCharacterChange, los cambios realizados por el usuario.

Para mostrar o cerrar la ventana hay que obtener un puntero a la interfaz IAgentPropertySheet, solicitándola a QueryInterface, y luego usar el puntero para llamar al método SetVisible con el parámetro a TRUE o FALSE, para mostrarla o ocultarla respectivamente. Como muestra el siguiente código:

IAgentPropertySheet *pPropSheet;

// Solicita la interfaz IAgentPropertySheet pAgentEx->QueryInterface(IID_IAgentPropertySheet, (LPVOID *)&pPropSheet);

// Muestra la Ventana de Propiedades AvanzadaspPropSheet->SetVisible(TRUE);

3.4.6 Servicios de Salida

Además de soportar las animaciones de un personaje, Microsoft Agent soporta salida de audio para el personaje. Esto incluye salida de voz y efectos de sonido. Para la salida de voz, el servidor automáticamente sincroniza las imágenes del movimiento de la boca con la salida. Se puede elegir entre sintetizar texto a voz (TTS), utilizar un sonido grabado o solamente salida mediante texto escrito en el globo de texto.

3.4.6.1 Soporte para síntesis de vozIgualmente, si se quiere usar los servicios de habla de Microsoft Agent para que un personaje tenga salida de voz sintética, se debe instalar un motor texto a voz (TTS) compatible. Como los servicios de habla de Microsoft Agent están basados en el API de habla de Microsoft (Microsoft Speech API, SAPI), se deben usar motores que sean compatibles con dichas interfaces de habla.

Si usa síntesis de voz, el personaje tiene la habilidad de decir casi cualquier cosa, lo cual ofrece una mayor flexibilidad. Por otra parte, con audio grabado se puede dar al

58


personaje una voz especifica que lo haga único. Para especificar la salida, hay que pasar el texto como parámetro al método Speak.

Para habilitar la salida de texto a voz, hay que usar el método Speak. Microsoft Agent intentará automáticamente cargar el primer motor que iguale el identificador del lenguaje del personaje. Si la definición del personaje incluye un identificador de modo de un motor TTS específico, el motor está disponible, y además, iguala el identificador del lenguaje del personaje, Agent cargará el motor para ese personaje. Si no, Agent cargará el primer motor TTS que la interfaz de habla reconozca como válido para ese idioma. Se puede usar IAgentCharacterEx::SetTTSModeID para cargar un motor específico.

//GUID Correspondiente a una TTS conocidaswprintf(bszAux,L"%hs","{2CE326E0-A935-11d1-B17B-0020AFED142E}"); pCharacterEx->SetTTSModeID( bszModeID );

3.4.6.2 Soporte para salida de audio grabadoMicrosoft Agent permite usar ficheros de audio simulando la salida de voz de un personaje. Para ello, se deben grabar previamente los ficheros de audio para poder reproducirlos durante el desarrollo de la aplicación mediante el método Speak. Cuando se usa un fichero de sonido como salida de voz del personaje, hay que especificar la localización del fichero en el parámetro bszURL, mientras que el parámetro bszText especifica las palabras que aparecerán en el globo de texto del personaje. Como muestra el código siguiente

BSTR bszText, bszURL;

//Prepara el texto que se mostrará en el globo de textobszText = SysAllocString(L"¡Bienvenido!, mi nombre es Birdie");

//Prepara el path del fichero de audiobszURL = SysAllocString(L"C:\\Win95_32\\media\\Bienvenida.wav");

//Reproduce el fichero WAVhRes = pCharacterEx->Speak(bszText,bszURL,&lRequestID);

//libera las cadenas de caracteresSysFreeString(bszText);SysFreeString(bszURL);

Los servicios de animación de Microsoft Agent soportan automáticamente sincronización entre el sonido y el movimiento de labios. Si queremos una sincronización mejorada, que incluya información sobre fonemas y pausas entre palabras, hay que usar un formato de fichero de sonido especial que Microsoft Agent es capaz de entender. Este formato se puede generar con una herramienta de Edición de Sonido con Información Lingüística de Microsoft.

3.4.6.3 Soporte para Globo de TextoCuando usamos el método Speak, la voz de salida puede aparecer también como salida de texto dentro de un globo, similar al típico bocadillo de los cómics. Esto puede ser

59


empleado como algo que complementa o como una alternativa a la salida de voz si ésta no está disponible.

El método Think no produce salida de voz y el globo que encierra el texto tiene misma forma que se emplea en los cómics cuando el personaje está pensando.

BSTR bszAnimation, bszSpeak; // Prepara el nombre de la animaciónbszAnimation = SysAllocString(L"Think");

// Ejecuta una animación correspondiente a un estado reflexivo (esto no // es necesario para que el formato del globo sea el de pensamiento)pCharacterEx->Play(bszAnimation,&lRequestID);

// Prepara el texto del globobszSpeak = SysAllocString(L"¿Dónde he dejado las llaves?");

// Muestra el globo pCharacterEx->Think(bszSpeak, &lRequestID);

// Libera las cadenas de textoSysFreeString(bszAnimation);SysFreeString(bszSpeak);

La siguiente figura muestra el resultado que produce el anterior código:

Figura 3.26 Método Think aplicado al personaje Merlín

Los Globos de Texto soportan tan sólo comunicaciones desde el personaje, no entradas del usuario. Por lo tanto el Globo de Texto no soporta controles de entrada. Sin embargo, se puede proporcionar entrada para el usuario a través de interfaces desde tu propio lenguaje de programación o desde otros servicios de entrada proporcionados por Microsoft Agent, tales como el menú emergente.

Cuando se define un personaje, se puede especificar si se quiere incluir soporte para Globo de Texto. Sin embargo, si se usa un personaje que incluya soporte para Globo de Texto, no se puede deshabilitar el soporte.

60


Se puede acceder a la interfaz del Globo de Texto para modificar sus características de presentación y personalizarlas. El siguiente código de ejemplo modifica el tamaño y el tipo de font:

BSTR bszFontName, bszSpeak;

//Solicita la interfaz del Globo de TextopCharacterEx->QueryInterface(IID_IAgentBalloonEx, (LPVOID *)&pBalloonEx);

//Fija el tamaño del font a 12 puntospBalloonEx->SetFontSize(12);

//Prepara el nombre del nuevo fontbszFontName = SysAllocString(L"Terminator Two");

//Fija el nuevo fontpBalloonEx->SetFontName(bszFontName); //libera la cadena de caracteresSysFreeString(bszFontName);

// Prepara el texto bzSpeak = SysAllocString(L"Hasta la vista Baby!");pCharacterEx->Speak(bszSpeak, NULL, &lRequestID);

//libera la cadena de caracteresSysFreeString(bszSpeak);

La siguiente figura muestra el resultado de los cambios que produce el anterior código en el Globo de Texto:

Figura 3.27 Globo de Texto con tipo de font Terminator 2 y tamaño de fuente 12

3.4.6.4 Efectos de Sonido de las AnimacionesMicrosoft Agent permite incluir efectos de sonido como parte de la animación de un personaje. Usando el Editor de Personajes de Microsoft Agent, se puede especificar el nombre de fichero de un fichero de sonido estándar de Windows (.wav) que haya que incluir sobre un fotograma de una determinada animación.

Los efectos de sonido y la voz no pueden superponerse, así, la salida de voz no comienza hasta que el efecto de sonido haya terminado. Por lo tanto hay que evitar sonidos largos, o en bucle, como parte de una animación.

61

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAProgramación del Analizador de Estilo en entorno Visual C++

62


4 Programación del Analizador de Estilo en entorno Visual C++

La herramienta integradora de todos los componentes empleados en la realización de este Proyecto Fin de Carrera es el entorno de desarrollo integrado (IDE) Microsoft Visual C++ 6. Este capítulo describe sus potencialidades y la forma de trabajar con él, usando como caso práctico la programación de alguno de los componentes del Analizador de Estilo.

4.1 Presentación del entorno Visual C++

Microsoft Visual C++ 6.0 es un completo entorno de desarrollo orientado a la creación de aplicaciones para entorno Windows5. Al ser un entorno integrado, Visual C++ incluye, entre otras, las siguientes herramientas de desarrollo:

Editor de texto.

Compilador/Enlazador.

Depurador.

Visor de datos y dependencias (Browser).

Si desde el punto de vista del usuario Windows es un sistema amigable, desde el punto de vista del desarrollador no lo es tanto. El SDK (Software Developer Kit) de Windows es un complejo conjunto de funciones que añade además numerosas definiciones de tipos de datos [Rivilla Lozano, 1997]. Para solucionar este problema, Visual C++ incluye la librería de clases MFC (Microsoft Foundation Classes) que permite crear y gestionar de manera intuitiva componentes típicos de Windows. Realmente la MFC es una implementación que utiliza el API encapsulando todas las estructuras y llamadas a funciones en objetos fáciles de utilizar.

Visual C++ no es únicamente una biblioteca de clases, sino todo un entorno de trabajo. Este entorno nos permite crear aplicaciones basadas en los elementos habituales de Windows (recursos), con todas las características que se esperan de ellas: ventanas, menús, cuadros combinados, barras de herramientas, etc. La Figura 4.1 muestra los nombres de algunos de estos elementos en una ventana correspondiente a la aplicación EstilosVC6.

5 Windows es un entorno multitarea basado en ventanas, que representan programas, y que permite ejecución concurrente.

63


Figura 4.1 Controles que aparecen en la aplicación EstilosVC6

El entorno se encarga en muchas ocasiones de escribir el código que hace uso de esas clases, de este modo se simplifica la programación y se reducen los errores de programación.

4.1.1 Asistentes

La creación de aplicaciones mediante Visual C++ se facilita al poder emplear distintos asistentes (Wizards en inglés), que ofrecen su ayuda a lo largo de todo el proceso de programación.

En un primer momento se puede hacer uso del asistente AppWizard, que ayuda a construir un esqueleto de programa genérico, adaptado a nuestras necesidades. Sólo hay que ir especificando a AppWizard las funcionalidades específicas que necesitemos y Visual C++ generará una completa colección de ficheros fuente y ficheros de recursos basados en clases de la librería MFC, que constituirán una aplicación Windows plenamente funcional.

Más tarde ClassWizard permitirá añadir al esqueleto anterior las funciones asociadas a los distintos controles. ClassWizard ayuda a modificar el mapa inicial de mensajes de una aplicación. Las funciones así añadidas tendrán dos facetas:

64


Por una parte, permitirán a la aplicación responder a los mensajes generados por el usuario en los aspectos relacionados con la interfaz de usuario, esto es, en el sentido visible de la aplicación.

Por otra parte, ClassWizard permite insertar las funciones que llevan a cabo las tareas específicas de la aplicación, más allá de los aspectos de la interfaz: ClassWizard facilita al programador el realizar ciertas tareas rutinarias tales como crear nuevas clases, definir manejadores de mensajes, sobrescribir funciones virtuales y reunir datos acerca de los controles de un recurso nuevo e incluirlos dentro de una clase. También facilita el añadir propiedades, métodos y eventos a una clase.

El código generado mediante cualquiera de las dos herramientas anteriores presenta una complejidad añadida a la natural de cualquier programa; junto con el código C/C++ y el de la MFC aparecen líneas (generalmente entre comentarios) que son totalmente necesarias para el funcionamiento del ClassWizard. Modificar cualquiera de esas líneas dará muchos problemas a la hora de utilizar ClassWizard para modificar el código.

El WizardBar se sitúa en el entorno de Visual C++ como una barra de herramientas común. Muestra dentro de un control de lista desplegable todos los miembros de una clase. Basta con seleccionar la clase dentro de otro control de lista donde aparecen todas las clases del proyecto. Una vez seleccionado un miembro de una clase, podemos acceder a un menú que nos ofrece posibilidades como definir manejadores de mensajes, sobrescribir funciones virtuales y navegar por los ficheros (.cpp y .h) del proyecto, situándonos en la declaración o implementación de variables y funciones de la clase que hayamos seleccionado.

Figura 4.2 WizardBar nos muestra todos los miembros de la clase CAnalizaVarDlg

65


Figura 4.3 Menú desplegable con todas las acciones posibles

El editor de recursos es otra aplicación fundamental, integrada en Visual C++, que permite modificar recursos ya existentes, quizá creados por los asistentes mencionados anteriormente, así como añadir recursos propios a la aplicación. Estos recursos añadidos por el desarrollador se incorporan al proyecto simplemente, de manera gráfica: basta colocarlos en las posiciones deseadas, y especificar después el comportamiento que se espera de cada elemento. Evidentemente, los recursos añadidos no serán tenidos en cuenta por la aplicación hasta que insertemos mediante ClassWizard el tratamiento adecuado para responder a los mensajes asociados a estos recursos.

La posibilidad de finalización automática de una sentencia sirve de gran ayuda en el proceso de edición de un programa. Cuando se construye una expresión en que se alude a un miembro de una clase, basta escribir las primeras letras para que aparezca una lista de los posibles miembros. Si se trata de una función, al pulsar el paréntesis de apertura (“( “) se completa automáticamente el nombre de la función, y se muestra otra lista de posibles parámetros de la función, empleando para ello el sistema de la ayuda emergente. La figura 4.4 muestra un ejemplo en el que el usuario va a hacer uso de un objeto declarado anteriormente; en cuanto el usuario pulsa un punto (“.”), o una flecha (“->”) si es un acceso a través de puntero, aparece la lista con todas las variables y funciones miembro, correspondientes a ese tipo de dato.

Figura 4.4 Sistema de finalización automática de sentencias

66


Esta posibilidad se extiende también a las funciones y clases creadas por el usuario. Como ejemplo, supongamos que se declara una función cuyo prototipo es:

HRESULT CargarPersonaje ( IAgentEx *pAgentEx, char *Filename, long *plCharacterID, int *handlePersonaje, long *lRequestID );

La figura 4.5 muestra lo que sucede cuando el usuario efectúa una llamada a esta función: aparece la lista de parámetros formales que consta en el prototipo.

Figura 4.5 Otro aspecto del sistema de finalización automática de sentencias

Y según se ha indicado, si se escribe el nombre de un ejemplar o puntero de una clase creada por el usuario, el resultado será también una lista de miembros en cuanto se haga uso del operador de acceso a miembros.

4.1.2 El sistema de ayuda

El sistema de ayuda de Visual C++ 6, la biblioteca MSDN, está basado en un sistema de hipertextos escrito en HTML, sobre los que se puede navegar.

Figura 4.6 La ventana del sistema de ayuda

67


La documentación es bastante extensa (consta de 2 CD-ROM) y su instalación completa ocupa 400MB de espacio en el disco duro. Existe la posibilidad de hacer una instalación básica que requiere muy poco espacio en disco, pero tiene el inconveniente de tener permanentemente ocupada la lectora de CD-ROM para hacer uso del sistema de ayuda.

Una vez instalado se puede solicitar ayuda pulsando el botón que se ve en la figura 4.7 y que se encuentra en la barra de herramientas Estándar.

Figura 4.7 El botón de ayuda

Al sistema de ayuda también se accede de manera automática, pues existe una búsqueda sensible al contexto que permite obtener información sobre cualquier palabra sin más que situar sobre ella el puntero del ratón y pulsar la tecla F1.

4.2 Entorno de desarrollo: Visual Studio

El entorno de desarrollo integrado (IDE) de Visual C++, Visual Studio, se organiza en cuatro áreas distintas: menús y barras herramientas, ventana del espacio de trabajo, editor de código y ventana de depuración y búsqueda. La Figura 4.8 muestra estas áreas.

El menú permite acceder a diferentes opciones para todo el proyecto, con las que se puede controlar desde el comportamiento de compilador hasta el de las fuentes del editor de código. Todas las barras de herramientas se pueden anclar a cualquiera de los cuatro lados de la ventana principal del IDE; además, pueden flotar en cualquier lado del escritorio.

La ventana de depuración muestra información importante durante el proceso de creación del proyecto (mensajes de error que se den al compilar o linkar) y mientras éste se ejecuta en modo depuración. Además, ofrece los resultados de la búsqueda de cadenas de texto en ficheros.

La ventana del espacio de trabajo muestra los distintos aspectos de los diferentes proyectos que puede contener un espacio de trabajo, mediante la conmutación entre las solapas de la vista de clases (ClassView), la vista de archivos (FileView) y la de recursos (ResouceView) de cada proyecto. Aparte del trabajo en el editor de código, la gran mayoría de la interacción con un proyecto se quedará dentro de la ventana de vista del espacio de trabajo, ya sea empleando la vista de archivos o de clases.

68


Figura 4.8 Las cuatro áreas de Visual Studio

Todos los archivos incluidos en cada proyecto se muestran en formato de árbol jerárquico en la vista de archivos. Para editar un archivo, simplemente hay que hacer un doble clic en él dentro de la ventana del espacio de trabajo y se cargará en el editor de código. La vista de archivos abre todo el proyecto en el editor y lo muestra de principio a fin. Editar múltiples archivos es también fácil, pues cada archivo se carga en su propia ventana de edición, que se pueden organizar en mosaico usando el menú Window (ventana). De esta manera se puede cortar y pegar entre ventanas o mostrarlas una junto a otra para comparar línea a línea.

69


Figura 4.9 Vista de archivos

La vista de clase ordena el proyecto de acuerdo a sus clases. Combina los archivos de clase .h y .cpp en una entidad de clase lógica única y se muestra en un formato de árbol jerárquico. Este agrupamiento lógico de clases facilita la programación, sobre todo en proyectos largos con muchas clases. Al hacer doble clic en un nombre de clase se muestra el código de ésta en el editor. Al expandir un nodo del árbol de clases se muestra la lista de funciones, variables y las funciones de manipulación de mensajes.

Al pulsar dos veces en cualquier clase, función miembro o variable que se encuentre dentro del proyecto se abre el archivo de código fuente relevante de la ventana el editor, con el cursor ya situado en la línea que representa ese objeto.

Figura 4.10 Vista de clases

El significado de los distintos iconos que aparecen junto a las variables y funciones de cada clase se muestran en la siguiente figura:

70


Figura 4.11 Los iconos de la vista de clases muestran detalles adicionales

La solapa vista de recursos, muestra un listado de los recursos de los que hace uso la aplicación, a la vez que permite visualizar y modificar los recursos existentes o crear otros nuevos con mucha comodidad. De este modo se pueden diseñar diálogos, iconos, barras de herramientas, menús y aceleradores de teclado personalizados. Pulsando dos veces con el ratón sobre cualquier recurso de la vista, se abre un programa editor gráfico de recursos. La forma de trabajar con el editor de recursos se verá en próximos apartados cuando se hable de la creación de los controles propios del Analizador de Estilos.

Figura 4.12 Vista de recursos con un diálogo abierto en el editor

4.3 El concepto de Espacio de trabajo de Proyectos (Workspace)

En Visual C++ la construcción de cualquier tipo de programa se inscribe dentro del concepto de espacio de trabajo de proyectos (workspace). Un espacio de trabajo es un contenedor para el desarrollo de proyectos.

71


Cuando se crea un proyecto nuevo, se crea, al mismo tiempo, un espacio de trabajo que permite albergar, si es necesario, nuevos proyectos, incluyendo proyectos dependientes o nuevas configuraciones a un proyecto existente. Para guardar información relativa a los proyectos que se incluyen en un espacio de trabajo, Visual C++ crea y mantiene un fichero de extensión .dsw .

También se crean otros ficheros asociados, incluyendo un fichero de proyecto (.dsp) por cada proyecto incluido, que contiene información para construir el proyecto, y un fichero de opciones del espacio de trabajo (.opt). Este último fichero almacena configuraciones como aquellas que se especifican en el diálogo Configuraciones de Proyecto (Project Settings) que aparece al seleccionar la opción Settings en el menú Project, y el aspecto visual del espacio de trabajo.

Un proyecto define los pasos a seguir para alcanzar la construcción de un objetivo (un programa, una DLL, etc.), en realidad es un concepto análogo a lo que se conoce como makefile (archivo de creación) en otros entornos típicos de desarrollo en C.

Desde el punto de vista funcional, el proyecto contiene referencias a cada uno de los ficheros fuentes (C/C++, con extensiones .c y .cpp respectivamente), objetos, librerías o ficheros de recursos (extensión .rc) que se deben utilizar para construir el objetivo final del proyecto.

En definitiva, para crear cualquier programa con Visual C++ se debe comenzar creando un proyecto para él, codificando y añadiendo los módulos necesarios a dicho proyecto, y definiendo los recursos asociados.

4.3.1 Posibilidades de programación

Cuando se crea un nuevo proyecto (desde la opción New del menú File aparece un diálogo que nos permite especificar que se cree un nuevo workspace), lo primero que solicita el sistema es determinar el tipo de objetivo que se persigue con este proyecto. Existen muchas posibilidades, que se reflejan en la tabla de la siguiente figura:

Figura 4.13 Tipos de proyecto

72


Las opciones que más destacan son las siguientes:

MFC AppWizard (exe): Aplicación ejecutable basada en la MFC.

MFC AppWizard (dll): Librería de enlace dinámico basada en la MFC.

Win 32 Application: Aplicación ejecutable estándar para Windows basada en el SDK.

Win 32 Console application: Aplicación ejecutable modelo DOS.

Win 32 Dynamic-Link Library: Librería de enlace dinámico basada en el SDK.

Win 32 Static Library: Librería estática .lib.

4.4 Creación de la aplicación Analizador de Estilo

Como forma de analizar de forma práctica las posibilidades de programación que ofrece el entorno de desarrollo Microsoft Visual C++ 6, los siguientes apartados explican en detalle el proceso de creación de la interfaz gráfica de usuario y del componente de navegación del programa Analizador de Estilo.

4.4.1 Interfaz Gráfica de Usuario: Arquitectura Documento/Vista

La popularidad de las aplicaciones para Windows proviene del concepto de interfaz de usuario consistente. Una aplicación típica de Windows posee una barra de título en la parte superior, seguida por un menú desplegable y una o más filas de iconos de barras de herramientas que sirven como atajos. Por debajo de las barras de herramientas hay una zona principal de visualización, y por último una barra de estado que ocupa la parte inferior. Aunque se consideren muchos tipos distintos de aplicaciones, habrá unas mismas opciones de menú y unos mismos iconos en la barra de herramientas, que mantienen un mismo significado. Esto facilita la adaptación del usuario a nuevos programas que cumplan con este estándar.

Para un programador de Visual C++, ajustarse al aspecto familiar de Windows no supone esfuerzo alguno. La biblioteca MFC ofrece una gran cantidad de apoyo para generar inicialmente una aplicación empleando AppWizard, aplicación que contendrá un menú, una barra de herramientas, una barra de estado y otros componentes; además permitirá fácilmente personalizar estos componentes. Las clases creadas cooperan entre sí para formar una estructura interrelacionada que suele conocerse con el nombre de arquitectura Documento/Vista.

4.4.1.1 Arquitectura Documento/VistaEl concepto fundamental de la arquitectura Documento/Vista consiste en separar los datos requeridos en sí de la presentación de lo que los datos significan para el usuario.

73


Esto se logra reteniendo los datos en una clase (la clase Document) y presentando la información al usuario a través de otra clase (la clase View); de aquí proviene el término Documento/Vista.

Normalmente, el documento está relacionado directamente con un archivo de disco. El objeto documento suele representar un archivo que ha abierto la aplicación, mientras que la ventana de la vista proporciona una presentación visual de los datos del documento y acepta la interacción del usuario. La relación entre los documentos y las vistas es una relación de uno a varios, es decir, un documento puede tener muchas vistas, pero se puede asociar una vista con un único documento.

La solución de la biblioteca MFC ofrece mucho más que un entorno organizativo. También abarca muchas características de la interfaz de usuario y métodos para cargar y almacenar información en archivos.

El asistente de creación de aplicaciones posibilita la creación de dos tipos de aplicaciones documento/vista: SDI (interfaz de un solo documento) y MDI (interfaz de múltiples documentos).

La diferencia entre las aplicaciones de un solo documento y las de múltiples documentos queda bastante clara a la vista de sus nombres. Las aplicaciones SDI sólo permiten abrir un documento cada vez. Las aplicaciones MDI permiten abrir uno o más documentos simultáneamente; cada uno de ellos tendrá una ventana de vista diferente para su interfaz de usuario.

El Analizador de Estilo va a ser diseñado siguiendo una interfaz de múltiples documentos para que los usuarios puedan tener, si lo desean, varias ventanas de edición abiertas. El tipo base de vista elegida será RichEdit. Una vista RichEdit permite presentar una interfaz de edición de texto en formato de texto enriquecido. La vista tiene capacidades OLE, lo cual significa que se podrían incrustar imágenes, segmentos de vídeo y registros de sonido en el texto.

4.4.1.2 Generación de un proyecto MDI mediante AppWizardLa generación de un proyecto MDI es simplemente una cuestión de seleccionar las opciones correctas en AppWizard:

1. Para crear un nuevo proyecto hay que seleccionar la opción New desde el menú File:

Figura 4.14 Opción nuevo proyecto

74


2. A continuación en la solapa Projects del cuadro de diálogo New project, hay que seleccionar MFC AppWizard(exe), escribir un nombre para el proyecto (EstilosVC6 en este caso) y después pulsar Aceptar.

Figura 4.15 Selección del tipo de proyecto

3. En el cuadro de diálogo del paso 1 de MFC AppWizard, se selecciona el botón de radio Multiple Documents. Una vez que se marca Document/View Architecture Support?, se pulsa Next para continuar.

Figura 4.16 Paso 1 de 6

4. En el cuadro de diálogo del paso 2, hay que seleccionar el botón de radio None. Las opciones de este paso admiten distintos tipos de soporte para bases de datos que no se necesitan para nuestro proyecto. Se pulsa Next para continuar.

75



5. En el cuadro de diálogo del paso 3, hay que seleccionar Container frente a la pregunta What compound document support would you like to include? Esto añade soporte para contenedores OLE al proyecto, lo cual es necesario porque la vista RichEdit que se quiere utilizar funciona como un contenedor OLE. Hay que marcar la opción ActiveX Controls y pulsar Next para continuar.


6. En el cuadro de diálogo del paso 4, se marcan las opciones siguientes: Docking Toolbar, Initial Status Bar, Printing and Print Preview y 3D Controls. Se selecciona el botón de radio normal como estilo de la barra de herramientas. Además, se pulsará el botón Advanced para fijar ciertas opciones avanzadas. Las opciones elegidas para el proyecto EstilosVC6 son:

- Extensión .rtf como extensión propia para los documentos de la aplicación,

- EstilosVC6 como el nombre que aparecerá en el marco de la aplicación

76


- Archivos Estilo (*.rtf) como el nombre del filtro que aparecerá en el control de lista desplegable en el cuadro de diálogo Abrir (Archivos Estilo (*.rtf))

- Estilo como nombre inicial para los ficheros creados desde el menú Nuevo, etc.

Una vez cerrado este cuadro de diálogo se pulsa Next para continuar.


7. En el cuadro de diálogo del paso 5 hay que seleccionar MFC Standard como estilo del proyecto. Se selecciona Yes para generar comentarios en los archivos fuente. Se recomienda emplear las MFC como DLL y no como LIB en cuanto al tamaño y modularidad del programa, pero para ello hay que asegurarse de distribuir la DLL junto con el programa para que funcione correctamente. Por lo tanto, se selecciona As a Shared DLL como forma de emplear la biblioteca MFC y se pulsa Next.


77


8. El cuadro de diálogo del paso 6 permite modificar el nombre de las clases MFC que se van a generar, además de especificar los ficheros en los que se implementan y la clase base de la que derivan. Los nombres generados por AppWizard suelen ser bastantes significativos. En cuanto a las clases bases lo único que hay que modificar es hacer derivar la clase de vista, CEstilosCV6View, para que sea de tipo CRichEditView. Para continuar se pulsa Finish.


9. El cuadro de diálogo New Project Information aparecerá según se muestra en la Figura 4.22. Este cuadro de diálogo incluye información útil respecto a las clases generadas y a los nombres de los archivos fuente. También se puede comprobar la lista de características.

Figura 4.22 Información con las características del nuevo proyecto

Una vez pulsado OK, debería crearse el nuevo proyecto, quedando abierto en el Developer Studio.

78


4.4.1.3 Análisis del resultadoEl aspecto que toma la vista de clases puede verse en la siguiente figura:

Figura 4.23 Vista de clases del nuevo proyecto creado

Como se puede observar, el nombre por defecto de las clases generadas tiene mucho que ver con el nombre que se le haya dado al proyecto. De esta manera, si al proyecto se le da el nombre de EstilosVC6, se obtienen los siguientes nombres de clases:

4.4.1.3.1 CEstilosVC6App Definida en EstilosVC6.h e implementada en EstilosVC6.cpp. CEstilosVC6App deriva de la clase CWinApp.

Una característica de la programación basada en MFC es que el código carece de programa principal (punto inicial de ejecución como la función main de C/C++ para DOS, UNIX, etc.), la ejecución comienza con la creación de un objeto de una clase propia de la aplicación derivada de CWinApp. Este objeto es global o estático (es decir, existe durante todo el programa) y representa a la aplicación Windows. En este caso derivará de CEstilosVC6App.

En realidad, es la MFC la que provee una función principal estándar WinMain que utilizarán todos los programas. Los pasos básicos que sigue son tres: inicialización del programa, entrada en el bucle de mensajes y finalización del programa

Por lo tanto, CEstilosWinApp gestiona la inicialización de la aplicación y lanza la ventana marco de la aplicación. Siendo la clase base CWinApp la encargada de mantener la asociación entre las clases de documento, vista y marco. Además recibe los mensajes de Windows y los distribuye a la ventana blanco correspondiente.

4.4.1.3.2 CAboutDlgRepresenta el típico diálogo de Acerca de… y ha sido generada automáticamente por AppWizard. Esta clase (rompiendo la norma habitual de la MFC) aparece definida e implementada dentro de los mismos ficheros que la clase aplicación (ficheros EstilosVC6.h y EstilosVC6.cpp). Como norma se ha de evitar este tipo de construcción.

79


Las siguientes clases implementan la interfaz Documento/Vista tipo MDI:

4.4.1.3.3 CEstilosVC6Doc Definida en EstilosVC6doc.h e implementada en EstilosVC6doc.cpp.

CEstilosVC6Doc es un contenedor para los datos del documento y tiene la responsabilidad de serializar los datos desde y hasta el sistema de almacenamiento persistente. Al ser una interfaz de múltiples documentos pueden coexistir muchos ejemplares de la clase documento. La creación de un objeto documento siempre creará una nueva ventana de vista, la asociará al documento y creará una nueva ventana marco que contenga la vista.

Cómo puede haber varios ejemplares documento, el entorno MDI introduce el concepto de documento activo. Un documento se activará cuando el usuario interactúa con cualquiera de las vistas que tenga asociado ese documento.

4.4.1.3.4 CEstilosVC6ViewDefinida en EstilosVC6view.h e implementada en EstilosVC6View.cpp.

La clase de CEstilosVC6View tiene la responsabilidad de generar la representación visual de los datos del documento para el usuario y de capacitar al usuario para interactuar con los datos. En el programa EstilosCV6, la vista permitirá editar un texto en formato enriquecido. Cada vista puede estar interconectada con un único ejemplar de documento, pero un documento puede estar interconectado con múltiples objetos de vista. La clase de vista, accede a los datos que necesita a través de funciones miembro públicas de la clase del documento.

4.4.1.3.5 CMainFrameDefinida en mainfrm.h e implementada en mainfrm.cpp.

El papel de la clase CMainFrame es proporcionar una ventana para que la utilice la aplicación. Deriva de CMDIFrameWnd, que crea una ventana marco distinta para la aplicación (que suele denominarse ventana marco principal) y una para cada ventana de vista. La ventana marco principal contiene las barras de herramientas y la barra de estado y desempeña las funciones de gestión de ventanas.

4.4.1.3.6 CChildFrameDefinida en childfrm.h e implementada en childfrm.cpp).

La ventana de vista está almacenada en su propia ventana marco y la clase CChildFrame se encarga de proporcionarla. Deriva de CMDIChildWnd.

80


4.4.2 Control ActiveX WebBrowser

La versión anterior del programa Analizador de Estilo mostraba las páginas web de ayuda mediante el programa Internet Explorer. Esto conllevaba la necesidad de tener que instalar este navegador en el sistema para poder ver la ayuda. Con la idea de liberar de esta limitación a los usuarios, se ha incluido en EstilosVC6 un sistema propio de navegación. El sistema utiliza un control ActiveX, llamado WebBrowser (Explorador del web), como clase base para la navegación y un diálogo no modal para la visualización de las páginas web.

4.4.2.1 Creación del componente navegador

Visual C++ permite insertar la interfaz de distribución del componente navegador a través de una clase que incluye los métodos para manejar el control ActiveX en el que se basa. Esta clase está contenida en dos ficheros: uno fuente y otro de cabecera. En el fichero de cabecera se define la clase. El fichero fuente es el controlador de distribución, que implementa los métodos de la clase para que tengan exactamente el mismo aspecto que una versión local del objeto de automatización. Estos métodos admiten los parámetros correctos, y los transforman en un array de VARIANT para después llamar al verdadero Control ActiveX a través de la función Invoke().

Los pasos que se han seguido para insertar la clase de manejo del control de navegación al proyecto EstilosVC6 y poder utilizarla son los siguientes:

1. Se selecciona del menú Project, la opción Add To Project y luego, en el submenú, la opción Components and Controls.

Figura 4.24 Opción Añadir a Proyecto Componentes y Controles

2. Del cuadro de diálogo Components and Controls, se selecciona Registered ActiveX Controls.

81


Figura 4.25 Selección de la carpeta Controles ActiveX Registrados

3. En la lista, hay que seleccionar Explorador del Web de Microsoft y responder afirmativamente cuando se pregunte si se desea insertar este componente.

Figura 4.26 Selección del Componente Explorador del Web de Microsoft

El archivo que contiene el código del control se muestra en el cuadro Path to Control de la parte inferior de la ventana. El código del control ActiveX se encuentra en esa .DLL (C:\Windows\system\shdocvw.dll), así que hay que distribuir la aplicación con ese archivo asociado y registrarlo en la máquina de destino. Según [Bates, 1999], los controles se pueden registrar mediante la aplicación regsvr32.exe desde el menú Inicio a través de la opción Ejecutar o bien desde una línea de órdenes como ésta: Regsvr32 C:\Windows\system\shdocvw.dll.

82


4. Se accede a un cuadro de diálogo en el que se aparecerá el nombre predeterminado de la clase y de sus archivos. Se pueden modificar o aceptarlos. Una vez que se hace pulsa el botón OK, se creará la clase. Después se cierra el cuadro de diálogo.

Figura 4.27 Elección del nombre de la clase y sus archivos

5. Ahora hay que crear un una ventana, un diálogo, desde dónde usar el control ActiveX CNavegador. Para ello, desde el editor de recursos, se crea un cuadro de diálogo sin ningún botón. Si la opción System Menu (en la pestaña Styles de las propiedades del diálogo) esta seleccionada, el usuario podrá cerrar el diálogo en el momento en que estime oportuno. El tamaño del diálogo marcará el tamaño de visualización de las páginas web, por lo que se fija a un tamaño apropiado. Para definir este diálogo se fija el identificador (ID), IDD_NAVEGADOR_DLG, y como Caption, el texto que aparecerá en el título del diálogo, GUÍA DE ESTILO DEL INGLÉS CIENTÍFICO-TÉCNICO.

6. Desde el AppWizard se crea una nueva clase, CNavegadorDlg, para el diálogo.

Figura 4.28 Creación una nueva clase para el recurso recién creado IDD_NAVEGADOR_DLG.

83


7. El objetivo es utilizar el control CNavegador desde la clase CNavegadorDlg. Para ello, lo primero es incluir en el archivo recién creado, NavegadorDlg.h, el fichero de cabecera del control:

#include "CNavegador.h"

8. Podría añadirse directamente con el ClassWizard una variable (control) de tipo CNavegador en la clase recién creada, CNavegadorDlg; Pero Visual C++ permite añadir el control de forma gráfica y así poder fijar alguna de sus propiedades desde el editor de recursos, como el tamaño de visualización, por ejemplo. Para ello, cuando se pulsa sobre el diálogo con el botón derecho del ratón, aparece un menú contextual en el que hay que seleccionar la opción Insert ActiveX Control. Entre la lista de controles se selecciona, una vez más, Explorador del Web de Microsoft y se pulsa OK. Sobre el diálogo ha aparecido un control con el icono del programa Internet Explorer. Desde el menú contextual Properties se puede modificar su identificador por defecto para darle un nombre más descriptivo, por ejemplo, IDC_CTRL_NAVEGADOR. El área de visualización de las páginas web corresponderá con el tamaño que se le dé en el editor de recursos, por lo que conviene extenderlo a todo el área del diálogo para aumentar el área de visualización. El aspecto que toma es el de la siguiente figura:

Figura 4.29 Diálogo CNavegadorDlg con el Control ActiveX ocupando toda su extensión.

9. En el ClassWizard, se selecciona Add Variable sobre el identificador del control, IDC_CTRL_NAVEGADOR, y se añade a la clase CNavegador una variable miembro, m_CtrlNavegador, que manejará el control:

84


Figura 4.30 Resultado tras añadir la variable m_CtrlNavegador al control.

10. Se quiere que el diálogo que muestra las páginas web sea no modal para que se pueda acceder a otras funcionalidades del programa (editar un texto, analizarlo...) a la vez que se tiene abierto la ventana de navegación. Por lo que se modifica el código del constructor de la siguiente manera:

CNavegadorDlg::CNavegadorDlg(CWnd* pParent ) :CDialog(CNavegadorDlg::IDD, pParent){

//Crear Ventana no modalif(Create(CNavegadorDlg::IDD, pParent)){

ShowWindow(SW_SHOW);}

}

11. Además, se decide crear un constructor de la clase diálogo privado, que permita instanciar un único objeto de esta clase en cada momento. De este modo se consigue tener una única ventana de visualización de páginas web aunque se soliciten ejemplares de clase diálogo desde distintos puntos del código. Para ello, se modifica la clase CNavegadorDlg como muestra el siguiente código.

//CNavegadorDlg.h///////////////////////////////////////////////////////////

class CNavegadorDlg : public CDialog{ // Constructor públicopublic:

static CNavegadorDlg* getInstance(CWnd* pParent)

// Constructor estándar privadoprivate:

CNavegadorDlg(CWnd* pParent);

// Única instancia de la clase CNavegadorDlg. // Variable global a la que se accede mediante el puntero // que proporciona getInstance.

85


static CNavegadorDlg* instance;};

//CNavegadorDlg.cpp///////////////////////////////////////////////////////////

//Inicialización de instance.CNavegadorDlg* CNavegadorDlg::instance = 0;

//Implementación del constructor privadoCNavegadorDlg::CNavegadorDlg(CWnd* pParent)

: CDialog(CNavegadorDlg::IDD, pParent){

//Crear Ventana no modalif(Create(CNavegadorDlg::IDD, pParent)){

ShowWindow(SW_SHOW);}

} //Implementación del constructor públicostatic CNavegadorDlg* getInstance(CWnd* pParent){

if( !instance)instance = new CNavegadorDlg(pParent);

return instance;}

//Borra y destruye el diálogo cuando el usuario lo cierravoid CNavegadorDlg::OnClose() {

CDialog::OnClose();

delete instance;instance=NULL;

}

Ahora sólo resta crear el código que haga uso del control de navegación web que acaba de crearse.

4.4.2.2 Forma de empleo del componente navegador

Por ejemplo, uno de los puntos de la aplicación EstilosVC6 desde dónde se quiere lanzar la navegación es la opción Guía de Estilos del menú Ayuda. A continuación se enumeran los pasos seguidos para añadir esta opción de menú que abre el diálogo navegador:

12. Desde el editor de recursos se abre el recurso menú en cuestión, IDR_ESTILOTYPE, y dentro de la opción Ayuda, se ha de presionar dos veces con el ratón sobre la opción de menú que muestra el cuadrado vacío. Se ha abierto el diálogo Menú Item Properties que permite añadir una opción de menú nueva. Si se rellena el campo Caption con el texto &Guía de Estilo el menú tendrá el aspecto que muestra la siguiente figura:

86


Figura 4.31 Opción Guía de Estilo insertada en el menú.

13. Ahora hay que indicar a la aplicación la función que debe ejecutarse en respuesta al mensaje generado por Windows cuando el usuario selecciona esta opción. Este mensaje se llama WM_COMMAND, y la clase encargada de responder al mensaje es la vista de documento donde se encuentre el menú, CEstilosVC6View. Para añadir la función, la forma más fácil es desde el ClassWizard: Se selecciona el identificador de la opción del menú ID_AYUDA_GUIA_DE_ESTILOS y el mensaje COMMAND y se pulsa Add Function con lo que aparece un diálogo con un control de edición para editar el nombre de la función, como muestra la siguiente figura.

Figura 4.32 Añade en la clase CEstilosVC6View el manejador de selección de la opción de menú.

14. Ahora se puede pulsar Edit Code para dotar de funcionalidad al menú. Por ejemplo, el siguiente código instancia un objeto de la clase del diálogo CNavegadorDlg para, a través de su variable (control) miembro m_CtrNavegador, poder llamar a métodos con funcionalidades de navegación. En este caso se usa Navigate, que muestra la página HTML que se le pase como primer parámetro, ya sea un URL o un fichero local:

#include NavegadorDlg.h

(...)

87


void CEstilosVC6View::OnAyudaGuiaDeEstilos() {

CNavegadorDlg *pNavegadorDlg;pNavegadorDlg = CNavegadorDlg::getInstance(NULL);pNavegadorDlg->m_CtrlNavegador.Navigate("D:\\ayuda\\indice1.html",

NULL,NULL,NULL,NULL);}

Siendo el resultado el de la siguiente figura:

Figura 4.33 Diálogo mostrando las páginas de ayuda

15. Una vez abierto el diálogo por la página deseada, se puede navegar a través de los hipervínculos como si se tratase de un navegador comercial cualquiera. Para completar este navegador personalizado, se podría incluir un menú (o unos botones) con las funcionalidades Anterior y Siguiente que al ser pulsados llamasen a los métodos del control de navegación GoBack y GoForward respectivamente, para retroceder o avanzar en la visualización de páginas.

void CNavegadorDlg::OnSiguiente() {

m_CtrlNavegador.GoForward();}

void CNavegadorDlg::OnAnterior() {

m_CtrlNavegador.GoBack();}

Para completar este análisis de Visual C++ 6 y del programa Analizador de Estilo los dos siguientes capítulos se dedicarán a describir el proceso de creación de una DLL (que albergará una pequeña interfaz de programación de los Agentes) y a analizar el diálogo interactivo del usuario con los Agentes.

88


89

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDABiblioteca Agentes.dll

5 Biblioteca Agentes.dll

La biblioteca6 de manejo de los Agentes se va a crear en formato de biblioteca de enlace dinámico o DLL7 (dynamic-link library). Al construirse como módulo completamente independiente al programa Analizador de Estilos, podrá ser reutilizada por cualquier otra aplicación, que quiera incluir control sobre los Agentes de Microsoft.

En los primeros apartados de este capítulo se hace un acercamiento al concepto de biblioteca en entorno Windows y se describen las ventajas y desventajas de las bibliotecas de vinculación dinámica respecto a las estáticas. Para ello se plasman de forma sintética los conceptos extraídos de [Sarma, 1996] y [Leinecker, 1999] y de la ayuda a la programación de la MSDN.

Finalmente, se detalla el modo de creación de una DLL en el entorno de desarrollo Microsoft Visual C++ 6, tomando como ejemplo la creación de la biblioteca Agentes.dll, al tiempo que se analiza sus funciones y su forma de utilización.

5.1 Introducción a las DLLs:

Las bibliotecas de enlace dinámico se establecen sobre el concepto de comunicación cliente-servidor. Las funciones y los datos se guardan en la DLL, el servidor, y son exportados para ser usados por uno o varios clientes. Estos clientes pueden ser aplicaciones u otras DLL.

Las siguientes definiciones de aplicación y DLL pueden esclarecer sus funcionalidades:

Una aplicación escrita para el sistema operativo Windows, es un fichero ejecutable que generalmente crea una o más ventanas y usa un bucle de mensajes para recibir la entrada del usuario.

Por su parte, las DLLs no son directamente ejecutables y tampoco reciben mensajes. Las bibliotecas son ficheros independientes que contienen funciones y datos que pueden ser llamados por otros programas u otras DLL para realizar una cierta funcionalidad.

El proceso de creación de una DLL es muy similar al de creación de un ejecutable. Las funciones de biblioteca se compilan dentro de un archivo .OBJ (módulo), y un vinculador o enlazador (linker) crea la salida final binaria mediante el vínculo de diferentes módulos. Sin embargo, en el caso de una DLL, un parámetro especial del vinculador (/DLL) se usa para decirle al vinculador que se está creando una DLL en

6 En este Proyecto Fin de Carrera y en concreto en este capítulo se ha hecho el esfuerzo de utilizar el término biblioteca en lugar del término librería, más empleado por los programadores pero que no deja de ser una mala traducción del termino inglés library.

7 Se utiliza el acrónimo DLL en inglés por ser un término ampliamente aceptado que discrimina un tipo específico de biblioteca.

90


lugar de un EXE. De esa manera, el cargador de Windows, reconoce el archivo como DLL, y no como una aplicación.

5.1.1 Diferencias entre las bibliotecas de vinculación estática y dinámica

Bibliotecas estáticas:

En una biblioteca estática, las funciones y datos se precompilan dentro de un archivo binario, normalmente con la extensión .lib. Por lo tanto, los ficheros .lib son básicamente colecciones de ficheros objeto. El vinculador copia entonces estas funciones y datos de la biblioteca y los combina con los otros módulos de la aplicación para crear el ejecutable final (un archivo .exe). El vinculador es responsable de algo denominado fijación (mapping). Fijación es el proceso en el que llamadas de otros módulos en el ejecutable son mapeadas hacia funciones en la biblioteca.

Cuando una aplicación se vincula a una biblioteca estática, todas las llamadas a funciones de la biblioteca se resuelven en tiempo de compilación, por lo que el proceso se llama vinculación estática (static linking). Debido a que todo lo que necesita la aplicación de la biblioteca se copia en el ejecutable, la biblioteca (.lib) no tiene porqué ser distribuida con el ejecutable.

Bibliotecas dinámicas:

Por su parte, la vinculación dinámica proporciona un mecanismo para vincular bibliotecas a aplicaciones durante el tiempo de ejecución. Estas bibliotecas se llaman de vinculación dinámica para enfatizar el hecho de que son vinculadas a una aplicación cuando ésta es cargada y ejecutada, no durante la creación del ejecutable. Este mecanismo de vinculación puede ser realizado explícitamente, por las aplicaciones, o implícitamente, por el sistema operativo.

La vinculación dinámica implícita es realizada en tiempo de carga por el sistema operativo. Cuando el sistema operativo carga una aplicación o DLL, primero carga en memoria cualquier DLL dependiente (es decir, cualquier DLL que vaya a ser usada por la aplicación o DLL que se está cargando). Después, el sistema operativo resuelve las referencias a funciones en la DLL para que puedan ser llamadas por la aplicación, y cuando ya no se necesita, se descarga la DLL.

La vinculación dinámica explícita es realizada en tiempo de ejecución por la aplicación o DLL mediante llamadas al sistema operativo para cargar y descargar la DLL de memoria. Se usará este tipo de vinculación si se quiere cargar la DLL únicamente cuando se necesite llamar a las funciones de la DLL. Mientras que sus funciones no se usen, se puede descargar la DLL de memoria, ahorrando espacio. Las funciones necesarias para cargar y descargar la DLL son respectivamente LoadLibrary y FreeLibrary.

Ambos mecanismos de vinculación no son excluyentes y un programa puede usar la misma DLL mediante uno u otro método.

91


Las funciones y datos de una DLL no se copian dentro de la aplicación cliente. En su lugar, se crean dos archivos: una biblioteca de importación y la propia DLL. La biblioteca de importación contiene los nombres y localizaciones de las funciones exportadas por la DLL. Una aplicación que quiera usar las funciones exportadas por una DLL dada, ha de vincularse con la biblioteca de importación8. Por su parte, la DLL es un fichero ejecutable independiente (de extensión .dll) donde residen las funciones y datos reales. Como la DLL tiene las funciones y datos necesarios para sus clientes, debe distribuirse también con la aplicación que la use.

5.1.2 Ventajas de usar DLLs

Las DLLs son compiladas y vinculadas independientemente de las aplicaciones que las usan, por lo tanto pueden ser actualizadas sin requerir que las aplicaciones tengan que volver a compilarse.

Si varias aplicaciones trabajan juntas como un sistema y todas comparten DLLs, la funcionalidad del sistema entero se puede ver mejorada al reemplazar una DLL con una versión actualizada.

Las DLLs pueden reducir memoria y espacio en disco al compartir una única copia de código común y recursos entre múltiples aplicaciones. La cantidad de memoria y espacio de disco ahorrado se incrementa con el número de aplicaciones que usen la DLL. Si varias aplicaciones usan la misma biblioteca de vinculación estática, existen copias idénticas de la misma biblioteca en disco. Si esas aplicaciones corrieran simultáneamente, entonces habría varias copias idénticas en memoria. Estas copias son redundantes y suponen una pérdida de espacio. Si se usara una DLL en lugar de bibliotecas de vinculación estática, sólo habría una única copia del código y de los recursos, sin importar cuántas aplicaciones diferentes las usen.

5.1.3 Inconvenientes

La primera desventaja de usar DLLs frente a bibliotecas de vinculación estática es que son más difíciles de desarrollar.

Algunas veces, usar DLLs puede, contrariamente a lo dicho antes, incrementar la memoria y espacio de disco necesitado por una aplicación, especialmente si es una única aplicación la que usa la DLL. Esto ocurre cuando la DLL y la aplicación comparten llamadas a mismas funciones de una biblioteca de vinculación estática, como en el caso de funciones de la biblioteca de tiempo de ejecución de C. Si la DLL y la aplicación tienen vinculadas a ellas la misma biblioteca estática, habrá dos copias de las funciones en memoria y en disco, lo cual no es eficiente. Para evitar este problema la distribución de las llamadas a función y las propias funciones debe ser estudiada para evitar en la medida de lo posible esta duplicación.

8 Realmente, este caso sólo se da cuando la aplicación está implícitamente vinculando la DLL. Con vinculación explícita las aplicaciones deben hacer una llamada a función para cargar explícitamente la DLL.

92


5.1.4 Construcción de una DLL

Se puede construir una DLL usando el atributo dllexport o usando un fichero extra llamado de definición de módulo o también fichero de cliente (fichero con extensión .def). A continuación se discutirán ambos métodos.

5.1.4.1 Usando un fichero .def

Como ya ha sido comentado, la DLL puede ser implementada usando un fichero de definición de módulo, con extensión .def. Este fichero se debe incluir entre los ficheros de la aplicación cliente de la DLL a la hora de ser construida, para que las funciones y variables que la DLL exporte, se busquen en el código de la DLL y no en el de la aplicación. El siguiente código de ejemplo representa el fichero de cabecera de una DLL que exporta una variable y dos funciones mediante el empleo de un fichero .def, el cual también se incluye:

Figura 5.1 Exportación mediante fichero de definición .def

La declaración LIBRARY debe ser la primera declaración del fichero de definición. El nombre especificado en la declaración LIBRARY identifica a la biblioteca como la biblioteca de importación de una DLL.

La sección EXPORTS enumera todas las definiciones exportadas.

5.1.4.2 Usando __declspec(dllimport) y __declspec(dllimport)

La edición de Visual C++ de 32 bits usa __declspec(dllimport) y __declspec(dllexport) para reemplazar la palabra clave __export que era usada anteriormente en las ediciones de Visual C++ de 16 bits. El propósito de ambos mecanismos de exportación es el mismo: generar los nombres exportados automáticamente y situarlos en un fichero .lib. Este fichero puede ser usado

93


directamente como una biblioteca de importación para que una aplicación que lo incluya quede vinculada con la DLL.

Por lo tanto, __declspec(dllexport) puede sustituir a la sección EXPORTS de un fichero .def. Proporcionando una forma fácil de exportar funciones desde un fichero ejecutable o DLL, sin necesidad de usar un fichero de definición de módulo.

Aún así, hay directivas de exportación que sólo pueden ser usadas si se incluyen en un fichero de definición de módulo, por lo que a veces es necesario un uso combinado de __declspec(dllexport) y del fichero .def para aprovechar al máximo las posibilidades de programación de una DLL.

Sintaxis:

Debido a que son atributos y no palabras clave, dllexport y dllimport deben ser usadas en conjunción con la palabre clave __declspec. La sintaxis para usar __declspec es la siguiente:

__declspec(atributo) declaración de variable

Por ejemplo la siguiente declaración exporta un entero:

__declspec(dllexport) int Sum;

A su vez, para que este dato pueda ser importado directamente por la aplicación, se necesita que la definición que incluya el fichero de cabecera de la aplicación sea:

__declspec(dllimport) int Sum;

Usar __declspec(dllimport) para llamadas a función:

Una vez que se ha exportado una función mediante cualquiera de los dos métodos reseñados anteriormente, no es necesario usar __declspec(dllimport) para que el código compile correctamente. Pero hacerlo permite al compilador generar mejor código. Se genera mejor código porque el compilador conoce con seguridad si una función está en una DLL o no, y así puede producir código menos largo y más rápido.

Evidentemente, no debe usarse __declspec(dllimport) para las funciones locales a la DLL. Usar __declspec(dllimport) y __declspec(dllexport) para datos:

Cuando se importan datos desde una DLL, se accede a ellos a través de la tabla de direcciones de importación. Mientras que, dentro de la DLL no se tiene ese nivel extra de indirección. Esto significa que para acceder desde fuera a los datos exportados por la DLL, hay que hacerlo a través de punteros. Como queda reflejado en el siguiente ejemplo:

94


Figura 5.2 Acceso a datos usando exportación mediante .def

Para liberar al programador de esta delicada tarea, que puede ser fuente de errores de programación, en el fichero de cabecera de la aplicación se puede marcar el dato como __declspec(dllimport). Haciéndolo así, el compilador automáticamente genera el código de indirección; y no hay que preocuparse de usar la variable como puntero desde fuera de la DLL.

Para facilitar aún más las cosas y olvidarse del fichero de definición de módulo, se puede usar la siguiente declaración en el fichero de cabecera de la DLL:

__declspec(dllexport) ULONG ulDataInDLL;

para exportar la variable automáticamente desde la DLL.

5.2 Creación de la biblioteca Agentes.dll

Para la creación de la biblioteca de los Agentes se va a crear un proyecto nuevo (de nombre Agentes.dsp). Este proyecto se incluirá dentro del espacio de trabajo (workspace) donde se encuentra el proyecto EstilosVC6. El objetivo es disponer en un mismo espacio de trabajo de los dos proyectos y así poder saltar de uno a otro a voluntad y sin esfuerzo, facilitando el desarrollo.

5.2.1 Uso del Asistente de Aplicaciones

Una vez abierto el espacio de trabajo AnalizadorEstilos.wsp en el Visual Studio, se han de realizar los siguientes pasos guiados por el asistente de aplicaciones:

16. Seleccionar la opción New del menú File, como se muestra en la siguiente figura:

95


Figura 5.3 Opción New del menú file

17. Seleccionar el tipo de aplicación que se quiere construir: una biblioteca DLL. Para ello, en el cuadro de diálogo que se ve en la siguiente figura se seleccionará la opción Win32 Dynamic-Link Library.

Figura 5.4 Selección del tipo de proyecto

Además hay que rellenar algunos campos obligatorios como el nombre del proyecto (en este caso Agentes) y la localización donde será creado (la estructura lógica es incluirlo dentro del directorio AnalizadorEstilo).

También se activará el botón de radio Add to current workspace para que el proyecto se añada al espacio de trabajo y se seleccionará el cuadro de marcar Dependency of EstilosVC6 en el control de lista desplegable, si se quiere que se reconstruya el proyecto Agentes cada vez que se construya el proyecto del que se le hace depender (EstilosVC6). Esta operación se puede realizar o deshacer a posteriori desde el Visual Studio con la opción Dependencies... del menú Project.

18. Al pulsar el botón OK aparece el cuadro de diálogo de la siguiente figura. En él se puede elegir entre tres opciones, que se diferencian en la cantidad de código que el asistente va a generar automáticamente:

- La primera opción An empty DLL project crea un proyecto vacío, sin ningún fichero fuente ni de cabecera, lo cual no sirve de gran ayuda.

96


- La segunda opción A simple DLL project crea, al menos, un fichero fuente con la función de entrada de la DLL.

- La última opción A DLL that exports some symbols es la más interesante, pues crea tanto un fichero fuente como otro de cabecera donde se muestra la manera de exportar funciones, variables e incluso clases de una manera cómoda. Más adelante se expondrá en detalle en qué consiste el método de exportación.

Por lo tanto se marca el botón de radio correspondiente a la última opción.

Figura 5.5 Selección de la cantidad de código automático que generará el asistente

19. Al pulsar el botón Finish se muestra un cuadro de información con las características del proyecto que va a ser generado, el tipo de aplicación, el nombre de los ficheros y la localización donde será creado.

Figura 5.6 Información con las características del nuevo proyecto

97


Sí no se está conforme con las características, se puede volver atrás para cambiar alguna opción o para abandonar el asistente. Sí se pulsa el botón OK el proyecto será generado.

5.2.2 Análisis del proyecto generado por el asistente

En la siguiente figura puede verse el aspecto que tiene el panel de trabajo después de añadir el proyecto Agentes:

Figura 5.7 Panel del espacio de trabajo

Se puede apreciar en la solapa File View como ahora cuelga una entrada más del espacio de trabajo AnalizadorEstilo. El nombre de esta nueva entrada es Agentes Files y se corresponde con el proyecto Agentes que acaba de ser creado. Incluye dos ficheros fuente y dos de cabecera, con código generado automáticamente. Estos ficheros son:

Agentes.dsp: contiene información a nivel de proyecto.

StdAfx.cpp y StadAfx.h: Estos ficheros se utilizan para construir un fichero de cabecera precompilado (.PCH) y un fichero de tipos precompilado StdAfx.obj.

Agentes.h: Contiene la declaración de los elementos a exportar. A continuación se muestra el código que se ha generado:

98


Figura 5.8 Código de ejemplo: Agentes.h

Con espíritu didáctico, el asistente ha incluido la definición de una función (fnAgentes), una clase (CAgentes) y una variable (nAgentes) a modo de ejemplo de exportación. Todos ellas a pesar de estar declarados en la DLL, son accesibles desde cualquier proyecto que haga uso de la DLL; gracias al siguiente mecanismo de exportación (ya anticipado en la primera parte del capítulo):

Se declara un símbolo, AGENTES_EXPORTS, que sólo debe estar definido en el proyecto de la DLL9 y no en ningún proyecto que incluya la biblioteca. También se declara una macro, AGENTES_API, que será sustituida por __declspec(dllexport) o por __declspec(dllimport) dependiendo de si AGENTES_EXPORTS está definido o no en las definiciones del preprocesador. De esta manera al incluir AGENTES_API en la declaración de las funciones, variables o clases como modificador de tipo se indica al proyecto que incluya el fichero de cabecera Agentes.h, que estos elementos están siendo importados desde una DLL, mientras que para el proyecto que genera la DLL estos elementos son de exportación. Sustituyéndose AGENTES_API por una directiva u otra dependiendo de si se trata de la DLL o de la aplicación que la usa, puede usarse el mismo fichero de cabecera en ambas.

Agentes.cpp: En este fichero se declara la función DllMain, el punto de entrada de la DLL. Además se declaran la función fnAgentes, la variable nAgentes y el constructor de la clase CAgentes, como vemos en el código:

9 El Asistente se encarga de incluirlo de forma automática en las definiciones del preprocesador.

99


Figura 5.9 Código de ejemplo: Agentes.cpp

El punto de entrada de una DLL es la función DllMain.

Esta función realiza la inicialización y terminación de la DLL. El compilador busca esta función en el código de la DLL, si no lo encuentra usa la función que la biblioteca de tiempo ejecución de C/C++ proporciona por defecto.

La entrada de la función toma tres parámetros, un manejador (handle) de módulo, la razón de la llamada (con cuatro motivos de llamada posibles) y un parámetro reservado. Devuelve TRUE para indicar éxito.

El parámetro hModule contiene el manejador de la instancia de la DLL. Este parámetro puede ser salvado en una variable global para poder usarlo en las llamadas de carga de recursos.

El parámetro fdwreason indica la razón por la que el sistema operativo está llamando a DllMain. Las cuatro razones son:

- Cada vez que una DLL es cargada por un nuevo proceso, DllMain es llamada con DLL_PROCESS_ATTACH.

- Si en ese mismo proceso, un hilo de ejecución llama a LoadLibrary sobre esa DLL, entonces DllMain es llamado con DLL_THREAD_ATTACH.

- Si el hilo llama a FreeLibrary, se llamará a DllMain con DLL_THREAD_DETACH.

100


- Y finalmente, cuando una aplicación libera la DLL, DllMain es llamado con DLL_PROCESS_DETACH.

El parámetro lpReserved está reservado y normalmente es pasado como NULL.

5.3 Agregar la biblioteca al proyecto EstilosVC6:

Para vincular implícitamente una DLL, el programa ejecutable debe tener los siguientes elementos proporcionados por el proveedor de la biblioteca:

Un fichero de cabecera que contenga las declaraciones de las funciones y/o clases exportadas.

Una biblioteca de importación (.lib) para enlazar con ella. Esta biblioteca es normalmente generada por el compilador.

La propia DLL.

Así, para que la aplicación EstilosVC6.exe pueda hacer uso de la biblioteca Agentes.dll, ha de hacerse lo siguiente:

Desde una perspectiva de codificación, las llamadas a las funciones exportadas son como cualquier otra llamada a función. Por lo tanto, los ficheros fuente de la aplicación que incluyan llamadas a funciones exportadas por la DLL, deben incluir el fichero de cabecera que contenga las definiciones de las funciones (o clases C++) exportadas. El nombre de este fichero es Agentes.h.

Además en la construcción del fichero ejecutable EstilosVC6, se debe enlazar con la biblioteca de importación Agentes.lib. Esta biblioteca de importación es una biblioteca de enlazado estático que contiene únicamente el código necesario para identificar e invocar las funciones de la DLL. La biblioteca se genera automáticamente durante la construcción de la DLL.

Para incluir la biblioteca de importación al proyecto, hay que hacer lo siguiente:

1. Seleccionar Settings en el menú Project y acceder al cuadro diálogo Project Settings.

2. Seleccionar la ficha Link.

3. Fijar el cuadro combinado Category a General.

4. En el cuadro de texto Object/Library modules, entrar el nombre de archivo de la biblioteca, con su localización.

La siguiente figura muestra el cuadro de diálogo Project Settings con Agentes.lib como biblioteca de importación incluida.

101


Figura 5.10 Incluir la biblioteca Agentes.dll

El sistema operativo ha de ser capaz de localizar el fichero Agentes.dll cuando cargue el ejecutable que la usa. Para localizar la DLL, el sistema operativo busca en los siguientes directorios: el directorio actual, el directorio del programa ejecutable, el directorio de sistema de Windows, el directorio de Windows y todos los directorios especificados en la variable de entorno path.

5.4 Interfaz de Programación (API)

Este apartado presenta y describe las funciones que incluye la librería Agentes.dll. Para entenderlas en mayor grado pueden ser de utilidad los anexos de este PFC:

Para obtener información sobre las funciones de la Interfaz de Programación de Microsoft Agent, el Anexo B: Interfaz del Servidor Agent puede servir de referencia.

Para obtener información sobre la Interfaz de Programación básica, la arquitectura y los tipos de datos de COM y OLE, se puede consultar el Anexo A: Programación Basada en componentes: COM y Automatización OLE

.En el análisis de las funciones se ha diseñado un formato, que da a cada apartado del análisis (Descripción, Parámetros, Valores de Retorno...) una tipografía diferente para favorecer la claridad. No incluye los nombres de los apartados por no resultar repetitivo.

El formato es el siguiente:

102


Nombre de la funciónPrototipo de la función

Breve descripción de la funcionalidad

• Valores de retorno

Parámetros

Descripción de los parámetros

Descripción más detallada de la funcionalidad y detalles de la implementación.

A continuación, siguiendo el anterior formato, se analizan las 14 funciones que conforman la Interfaz de Programación:

5.4.1 InicializarAgente IagentEx* InicializarAgente ( void )

Crea un nuevo objeto Agent y obtiene el puntero a su interfaz IAgentEx.

• Retorna el puntero a la interfaz principal del objeto Agent: IAgentEx.

Inicializa COM y lanza el servidor AgentSvr.exe que crea un nuevo objeto Agent. La función retorna el puntero a la interfaz (IAgentEx) del nuevo objeto.

5.4.2 CargarPersonaje HRESULT CargarPersonaje ( IAgentEx *pAgentEx, char *Filename, long *plCharacterID, int *pihandlePersonaje, long *lRequestID )

Carga un personaje y lo mete en el array de personajes.

• Devuelve S_OK para indicar que la operación ha tenido éxito.

pAgentEx

Puntero a la interfaz principal del objeto Agent.

Filename

Path con la localización absoluta del fichero de personaje (fichero de extensión .acs) que se quiere cargar. Si se pasa como parámetro una cadena de caracteres vacía, se cargará el personaje por defecto.

plCharacterID

Puntero que recibe el identificador del personaje.

103


handlePersonaje

Puntero que recibe la posición del personaje cargado en el array de personajes cargados.

lRequestID

Puntero que recibe el identificador de la petición de ejecución del método IAgentEx::Load.

Llama a IAgent::Load para cargar de la colección de personajes aquel personaje cuyo nombre de fichero y path es pasado como parámetro. Para ello, lo primero que hace la función es adaptar el formato del parámetro Filename, tipo cadena de caracteres, a formato VARIANT10, que es el tipo de dato que admite el método IAgent::Load.

Una vez cargado el personaje, se llama a la función IAgentCharacter::GetCharacterEx para obtener el puntero a la interfaz IAgentCharacter.

El puntero obtenido se introduce en la siguiente posición libre (si la hubiere) del array de personajes (10 elementos máximo), donde se almacenan los punteros a las interfaces de los personajes actualmente cargados por la librería.

Este método, y algún otro método de esta librería, incluyen un identificador de petición de ejecución, lRequestID. Cuando la operación correspondiente a ese identificador sea cursada (inmediatamente, o con cierto retraso si hubiera otras animaciones en al cola), el servidor lanza un evento que puede ser capturado. De esta manera, se puede seguir el progreso de las animaciones de la cola del personaje y sincronizar el código del resto de la aplicación con el estado de animación actual del personaje.

5.4.3 DescargarPersonaje Void DescargarPersonaje ( IagentEx *pAgentEx, int handlePersonaje, long lCharID )

Descarga un personaje y lo elimina del array de personajes.


pAgentEx


handlePersonaje

Posición que ocupa el personaje (que hay que descargar) en el array de personajes cargados.

lCharID

10 El tipo VARIANT es un tipo utilizado en OLE y será explicado en el Anexo A: Programación Basada en Componentes: COM y Automoción OLE.

104


Identificador del personaje.

Libera la interfaz del personaje, descarga al personaje y deja libre la posición que ocupaba en el array de personajes.

5.4.4 FijarIdiomaPersonaje HRESULT FijarIdiomaPersonaje (int handlePersonaje,

const unsigned long lLANG_ID, const unsigned long lSUBLANG_ID )

Fija el idioma del personaje.


handlePersonaje

Posición que ocupa el personaje al que hay que fijar el idioma en el array de personajes cargados.

lLANG_ID

Identificador principal del idioma personaje. Por ejemplo: LANG_SPANISH o LANG_ENGLISH.

lSUBLANG_ID

Identificador secundario del idioma personaje. Por ejemplo: SUBLANG_SPANISH o SUBLANG_ENGLISH_US.

Fijando el idioma del personaje, la DLL de idiomas de Agent buscará en el sistema un conversor texto a voz (TTS) y un reconocedor de voz que se ajusten a ese idioma.

Esta función llama a la función IAgentCharacterEx::SetLanguageID con los identificadores del idioma que indiquen los parámetros lLANG_ID y lSUBLANG_ID, advirtiendo a Agent que cargue, para este personaje, los motores de voz correspondientes a ese idioma.

5.4.5 LiberarAgentevoid LiberarAgente ( IAgentEx *pAgentEx )

Libera la interfaz del personaje y desconecta COM.

• Sin parámetro de retorno.

pAgentEx


Llama a dos funciones del API de COM: la primera Release, que libera el puntero a la interfaz IAgent, destruyéndose el objeto Agent, y la segunda CoUninitialize que desconecta COM.

105


5.4.6 MostrarPersonajeHRESULT MostrarPersonaje ( int handlePersonaje, long *lRequestID )

Muestra en la pantalla al personaje.


handlePersonaje

Posición que ocupa el personaje que hay que mostrar en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Show.

Llama al método IAgentCharacterEx::Show para mostrar al personaje en pantalla.

5.4.7 OcultarPersonajeHRESULT OcultarPersonaje ( int handlePersonaje, long *lRequestID )

Oculta el personaje.


handlePersonaje

Posición que ocupa el personaje que hay que ocultar en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Hide.

Llama al método IAgentCharacterEx::Hide para ocultar al personaje de la pantalla.

5.4.8 HablarPersonajeHRESULT HablarPersonaje (char *Texto,int handlePersonaje, long *lRequestID )

El personaje pronuncia en voz alta un texto mientras mueve la boca. Simultáneamente se muestra lo que va diciendo en un globo de texto.


Texto

Texto que debe pronunciar el personaje.

106


handlePersonaje

Posición que ocupa el personaje al que se le pide pronunciar el texto en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Speak.

Transforma el parámetro Texto de cadena de caracteres a tipo BSTR11 y se lo pasa al método IAgentCharacterEx::Speak.

5.4.9 PensarPersonajeHRESULT PensarPersonaje (char *Texto, int handlePersonaje, Long *lRequestID )

Presenta un globo de texto con los pensamientos del personaje.


Texto

Texto que aparecerá en el globo de texto como pensamiento del personaje.

handlePersonaje

Posición que ocupa el personaje al que se le pide mostrar el globo de texto, que indique que está pensando, en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Think.

Transforma el parámetro Texto de cadena de caracteres a tipo BSTR y se lo pasa al método IAgentCharacterEx::Think, el cual muestra el texto especificado en un globo de texto especial, similar al que se usa en los cómics para indicar que el personaje está pensando y no hablando.

5.4.10 ReproducirFicheroHRESULT ReproducirFichero ( char *Path, int handlePersonaje, Long *lRequestID )

Reproduce un fichero de sonido mientras el personaje mueve la boca.


Path

11 El tipo BSTR es un tipo utilizado en OLE y será explicado en el Anexo A: Programación Basada en Componentes: COM y Automoción OLE.

107


Localización absoluta del fichero de audio (fichero de extensión .wav) que se quiere ejecutar.

handlePersonaje

Posición que ocupa el personaje al que se le pide ejecutar el fichero de audio en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Speak.

Transforma el parámetro Path de cadena de caracteres a tipo BSTR y se lo pasa al método IAgentCharacterEx::Speak, el cual localiza el fichero de audio y lo reproduce, mientras el personaje mueve los labios.

Este método está pensado para salida hablada del personaje teniendo los mensajes pregrabados en ficheros. Esto reduce la flexibilidad pero permite dotar al personaje de una voz no sintética y personalizada.

5.4.11 RealizarAccionPersonajeHRESULT RealizarAccionPersonaje ( char *Accion, int handlePersonaje, Long *lRequestID )

El personaje ejecuta la animación especificada.


Accion

El nombre de la animación.

handlePersonaje

Posición que ocupa el personaje al que se le pide ejecutar la animación en el array de personajes cargados.

lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::Play.

Transforma el parámetro Accion de cadena de caracteres a tipo BSTR y se lo pasa al método IAgentCharacterEx::Play, el cual ejecuta la animación correspondiente.

La siguiente tabla muestra, a modo de ejemplo, todas las animaciones con las que cuenta específicamente el personaje Genio, ya que cada personaje puede tener animaciones propias.

Lista de animaciones del Personaje GenioAcknowledge Hide Read

108


Alert Idle ReadContinued

Announce LookDown ReadReturn

Blink LookDownBlink Reading

Confused LookDownReturn RestPose

Congratulate LookLeft Sad

Congratulate_2 LookLeftBlink Search

Decline LookLeftReturn Searching

DoMagic1 LookRight Show

DoMagic2 LookRightBlink StartListening

DontRecognize LookRightReturn StopListening

Explain LookUp Suggest

GestureDown LookUpBlink Surprised

GestureLeft LookUpReturn Think

GestureRight MoveDown Thinking

GestureUp MoveLeft Uncertain

GetAttention MoveRight Wave

GetAttentionContinued MoveUp Write

GetAttentionReturn Pleased WriteContinued

Greet Process WriteReturn

Hearing Processing Writing

5.4.12 MoverPersonajeHRESULT MoverPersonaje ( int posX, int posY, int handlePersonaje, long *lRequestID)

Traslada el personaje a las coordenadas especificadas.


posX

La coordenada x de la ventana en pixeles, relativa al origen de la pantalla (esquina superior izquierda).

posY

La coordenada y de la ventana en pixeles, relativa al origen de la pantalla (esquina superior izquierda).

handlePersonaje


lRequestID

109


Identificador de la petición de ejecución del método IAgentCharacterEx::MoveTo.

Llama al método IAgentCharacterEx::MoveTo, el cual ejecuta la animación asociada al estado Moving mientras mueve el marco del personaje a la localización especificada. La localización de un personaje está basada en la posición de la esquina superior izquierda del marco de su animación, por lo que en la nueva posición, las coordenadas de esa esquina serán (posX, posY).

5.4.13 ApuntarPersonajeHRESULT ApuntarPersonaje ( int posX, int posY, int handlePersonaje, long *lRequestID )

El personaje señala a la posición especificada.


posX


posY


handlePersonaje


lRequestID

Identificador de la petición de ejecución del método IAgentCharacterEx::GestureAt.

Llama al método IAgentCharacterEx::GestureAt, el cual ejecuta la animación asociada al estado Gesturing. En este estado, el personaje señala al punto de la pantalla especificado, teniendo en cuenta la propia localización del personaje respecto al punto en que señala.

5.4.14 HojaPropiedadesVoid HojaPropiedades ( IAgentEx *pAgentEx, bool bVisible )

Muestra en pantalla la Ventana de Opciones Avanzadas de Personajes.


IAgentEx

Posición que ocupa el personaje que hay que mostrar en el array de personajes cargados.

110


bVisible


Utiliza el puntero pAgentEx para, a través de la función del API de COM QueryInterface, obtener un puntero a la interfaz del objeto AgentPropertySheet (IAgentPropertySheet). Una vez obtenida dicha interfaz, usa el método IAgentPropertySheet::SetVisible para hacer visible la Ventana de Opciones Avanzadas de Personajes.

5.5 GLOSARIO

Biblioteca de enlazado dinámico: una biblioteca compilada de código objeto o recursos que se puede enlazar con un programa ejecutable durante la ejecución, normalmente en forma de un archivo .DLL.

Biblioteca de enlazado estático: una biblioteca de código objeto compilado que se puede enlazar con un ejecutable en el momento de la compilación, normalmente en forma de un archivo de biblioteca .lib.

Biblioteca importada: una biblioteca de enlazado estático que contiene únicamente el código necesario para identificar e invocar funciones de una DLL, que normalmente será generada por el compilador.

__declspec(dllexport): atributo que modifica la definición de una variable o función para hacerla directamente exportada por una DLL.

__declspec(dllimport): atributo que modifica la definición de una variable o función para alertar al compilador de que es importada desde una DLL.

111

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDADiálogo interactivo con el Agente Animado

112


6 Diálogo interactivo con el Agente Animado

6.1 Analizador de Estilo

El Analizador de Estilo (EstilosVC6.exe) es un programa que trata de proporcionar una medida objetiva y global del estilo de redacción de un texto de tipo científico/técnico escrito en inglés.

Un indicador del estilo del texto es el empleo, en mayor o menor medida, de ciertos elementos lingüísticos. El programa analiza la aparición en el texto de esos elementos y los convierte en valores numéricos asignados a unas variables. Los valores de esas variables se guardan en un fichero de salida de datos, sin ser mostrados en pantalla.

El programa calcula, según el valor de las variables y basándose en unas reglas de aceptabilidad, las puntuaciones obtenidas en las diferentes características estilísticas (tipologías) que se analizan (claridad, concisión, variedad, comprensibilidad...) y las muestra en pantalla junto con la valoración final del estilo global del texto.

Los usuarios potenciales del programa no tienen por qué ser lingüistas por lo que se necesita de una explicación de los resultados enfocada a usuarios no expertos. Para realizar este cometido se ha incluido un Agente Animado que recalca los puntos del análisis cuya corrección pueda ayudar al usuario en mayor grado a mejorar su estilo.

También se ofrece al usuario la posibilidad de acceder a una ayuda que le permita conocer a fondo la manera de mejorar su estilo. El formato de la ayuda es HTML, de manera que la información está organizada en páginas Web enlazadas unas con otras mediante una amplia red de hipervínculos. Dado la extensa cantidad de información proporcionada en la ayuda, el Agente puede servir de guía a través de ella, haciéndolo de una manera atractiva para convertirla en más amena.

Se ha pretendido que la inclusión del Agente Animado facilite el manejo del programa y se consiga llegar a segmento de usuarios más amplio, incluyendo jóvenes estudiantes de inglés atraídos por el aliciente de interaccionar con personajes animados.

La siguiente figura corresponde a un diagrama de secuencia del programa. En él se puede apreciar cómo, partiendo del cuadro de diálogo que muestra los resultados del análisis, se puede lanzar el Agente para que comente los resultados o para que abra el navegador con la información de ayuda.

113


Figura 6.1 Diagrama de secuencia del programa Analizar de Estilo

6.2 Gestión de diálogos en el Analizador de Estilo

En la tarea de mejora del programa Analizador de Estilo, los mayores esfuerzos de desarrollo se han empleado en la tarea de reconstrucción de la interfaz de usuario y en la descripción mediante un Agente de los resultados obtenidos tras el análisis. Para lo cual ha sido necesario centrarse en la integración de los Agentes en la interfaz de usuario: desplazamiento por la pantalla, gestión de las animaciones de los personajes al señalar botones, o al abrir cuadros de diálogo, etc.

Con el objetivo de demostrar las potencialidades de la utilización de los Agentes para la interacción hablada con el usuario, parte del esfuerzo de desarrollo se ha dedicado a la gestión del diálogo interactivo hablado usuario/Agente.

Dada la enorme cantidad de trabajo que supondría la gestión de diálogos necesaria para incluir interacción hablada como forma de acceso a todas las funcionalidades de la aplicación, con sus múltiples opciones, ésta se ha reducido al ámbito de la descripción de los resultados del análisis del texto.

Al restringir el contexto, se facilita el manejo y comprensión de lo dicho por el usuario y el sistema puede proporcionar una respuesta correcta y distinta para cada uno de los sencillos escenarios previstos. De este modo, el usuario y el sistema pueden entablar una conversación coherente, favorecidos porque la iniciativa recae en manos del sistema y porque el nivel de profundidad de los diálogos es reducido.

114


Realmente, el sistema no es siempre el que ha de tomar la iniciativa en el turno de la palabra: También el usuario puede comenzar un diálogo, mediante la articulación de un comando de voz (el usuario sabe en cada momento qué puede decir consultando la ventana de comandos de voz activos), por lo que el sistema puede catalogarse como de Iniciativa Mixta (usuario/sistema).

6.3 Diseño de la interfaz con el personaje

Parece que los usuarios avanzados de informática tienen una mala predisposición al enfrentarse con un Agente. Por ejemplo, no siempre la aparición inesperada del asistente animado de Word es bien recibida por los usuarios del programa y en muchas ocasiones, aún necesitando ayuda, terminan por cerrarlo y lo que es más, desactivándolo.

¿Qué puede motivar este comportamiento? En gran medida, las deficiencias en el diseño de la interfaz de usuario que integra al Agente:

Al final y al cabo, la forma de interacción con el Agente se limita al empleo del mismo teclado o ratón con los que hay que comunicase con un asistente basado en cuadros de diálogo (considerados por los usuarios de mucha más utilidad), con lo que no se percibe ningún valor añadido que justifique su empleo. Si se descarta como beneficio el ver una animación graciosa, para la que no siempre se tiene tiempo.

En ese mismo ejemplo, la reticencia a la interacción con el Agente no sólo es debida a la desconfianza sobre su utilidad, sino también a un mal diseño en la toma de la iniciativa por parte del sistema, que en un alto porcentaje de las ocasiones resulta inoportuno. Del mismo modo, el hecho de que siempre repita el consabido "Parece que está escribiendo una carta...", no dice mucho en favor suyo y provoca que el usuario la pueda considerar monótona o poco inteligente.

En este proyecto se ha tratado de diseñar una interfaz de usuario que no adolezca de esos mismos defectos, para lo cual se han tenido en cuenta una serie de estrategias de diseño:

Un primer punto es la utilización de entrada de voz para el manejo del Agente, como valor añadido que ayude a vencer la resistencia de algunos usuarios a la interacción por medios tradicionales (ratón y teclado) con un Agente. Aún así, se han creado caminos alternativos de control de la interfaz, manteniendo la regla de diseño de no ser exclusivo, es decir, de no obligar al usuario a que para alcanzar una funcionalidad de la aplicación tenga que utilizar la interfaz hablada con el Agente.

Del mismo modo, los desplazamientos por pantalla del Agente señalando los puntos claves del análisis también proporcionan información de valor añadido, a la vez que refuerzan la componente social de su comunicación mediante el empleo de gestos.

Otro aspecto que se ha cuidado en la interfaz es mantener al usuario con el control. Siendo el usuario el que lanza (o para) al Agente, para que realice una tarea dada, en el momento en el que él decide.

115


Se ha tratado de dotar de variabilidad a los comentarios de los personajes: Proponiendo diferentes comentarios ante situaciones análogas, para que Agent los tome, de forma aleatoria, a la hora de expresarse.

Agent se encarga de generar la apropiada realimentación (necesaria en una comunicación basada en las normas sociales como la que se trata de implementar) al ejecutar animaciones asociadas a un estado de escucha o al advertir al usuario de que su comando de voz no ha sido entendido.

Para tratar de humanizar los personajes dotándoles de personalidad, se han diseñado dos tipos de conducta: una sumisa y otra más rebelde. Los rasgos de la personalidad se muestran, por ejemplo, en detalles como las diferencias en el tipo de comentarios que hacen al ser arrastrados por el usuario con el ratón, o al ser cliclados. La siguiente figura es un ejemplo:

Figura 6.2 Genio es sumiso y Merlín más rebelde.

6.4 Comentar Tablas de Resultados

El aspecto del programa durante la edición de un texto es el que muestra la siguiente figura:

116


Figura 6.3 Edición de un texto en la aplicación EstilosVC6.exe

Una vez que tenemos el texto editado, mediante éste u otro programa de edición, se puede proceder a su análisis desde la opción Procesar del menú Análisis,

Figura 6.4 Opción Procesar un texto para proceder a su análisis

Al terminar el análisis del texto, el programa ha calculado las puntuaciones obtenidas en las diferentes características estilísticas (tipologías) analizadas (estilo directo, claridad, concisión, convicción y variedad) y las muestra en pantalla, organizadas en un cuadro de diálogo, junto con la valoración final del estilo global del texto.

117


Figura 6.5 Tabla de resultados

El usuario, a la vista de unos resultados, tiene la posibilidad de pulsar el botón Lanzar Agente para que un personaje le sirva de guía a través de ellos.

Los objetivos principales que se marca el personaje cuando analiza los resultados son: informar, explicar y destacar aquellos resultados que ayuden al usuario a mejorar su estilo. Para ello realizará tres tipos de comentarios:

Comentará la media de ponderar los resultados en las diferentes categorías.

Alabará aquellas categorías que destaquen por haber alcanzado una buena puntuación (o aquellas que estén por encima de la media).

Y por último, comentará aquellas otras categorías en las que los resultados no hayan sido satisfactorios y en las cuales es conveniente mejorar.

El personaje se desplazará por la ventana y señalará allí donde quiera que el usuario concentre su atención. Como puede verse en la siguiente figura:

118


Figura 6.6 El personaje centra la atención del usuario

Así mismo, el personaje interactuará con el usuario y le hará preguntas acerca de los pasos a seguir. Como por ejemplo, preguntar si se quieren detalles acerca del peor resultado, o del siguiente peor, etc. En virtud de las respuestas el personaje será capaz de desplazarse hasta un botón y simular que lo pulsa, con lo que se abrirá una ventana de ayuda o un nuevo cuadro de dialogo.

El personaje se desplazará, a medida que vaya profundizando en detalles acerca de las categorías, por los cuadros de diálogo de los resultados. Por lo que, la explicación puede verse como la navegación a través de un árbol de datos interdependientes, en el que el camino elegido depende de los resultados y/o de la negociación con el usuario.

119


Figura 6.7 Solicitud de apertura de las páginas web de ayuda

6.4.1 Análisis de datos orientado a objetos

Se pretende que el módulo software creado sea reutilizable y pueda ser empleado para comentar tablas de resultados de muy diversa índole, por lo cual (y teniendo en cuenta las ventajas que representa este tipo de análisis) se ha hecho un análisis del problema orientado a objetos.

6.4.1.1 Definición del problemaEn la siguiente definición del problema se han subrayado los sustantivos que son candidatos a constituir clases:

El personaje realizará tres tipos de comentarios acerca de los resultados expuestos en un cuadro:

Comentará la media de ponderar los resultados en las diferentes categorías.

Destacará, mediante comentarios al efecto, aquellas categorías que destaquen por haber alcanzado una buena puntuación o aquellas que estén por encima de la media.

Y por último, comentará aquellas otras categorías en las que los resultados no hayan sido satisfactorios, están fuera del rango conveniente, y en las cuales es conveniente mejorar.

120


El personaje se desplazará por la ventana y señalará allí donde quiera que el usuario concentre su atención. Interactuará con el usuario y le hará preguntas acerca de los pasos a seguir. Como por ejemplo, preguntar si se quieren detalles acerca del peor resultado, o del siguiente peor, etc. En virtud de las respuestas el personaje será capaz de desplazarse hasta un botón y simular que lo pulsa, con lo que se abrirá una ventana de ayuda o un nuevo cuadro de dialogo.

6.4.1.2 Diagrama de casos de uso

Figura 6.8 Diagrama de casos de uso

6.4.1.3 Clases Resultantes

6.4.1.3.1 CIndiceLa información necesaria para que el personaje pueda realizar sus comentarios no se reduce a los datos de los resultados del análisis, también se necesita otro tipo de información relacionada, como por ejemplo, el texto de la categoría a la que pertenece o las coordenadas relativas dentro de la ventana para que el personaje se dirija a una posición concreta, etc.

Esa información necesaria para comentar cualquier tipo de resultado se almacenará en una clase llamada CIndice. En la siguiente figura, se puede ver las funciones miembro y los atributos de la clase:

121


Figura 6.9 Clase CIndice

A parte de las funciones de acceso a los atributos, destacan las siguientes variables, pensadas para albergar información necesaria de cara a su análisis:

bCheck (BOOL): Valor booleano que puede indicar si la categoría está dentro o fuera del rango recomendado.

iIdentificador (int): Identificador de un objeto (botón, elemento de menú...) hacia el cual queramos que se desplace el personaje.

iMensajeWnd (int): Para encaminar el desarrollo de la aplicación el personaje pregunta al usuario sobre el siguiente paso a seguir. En esta variable se puede pasar el valor de un mensaje que lanzado sirva para abrir un cuadro de diálogo, una ayuda o similar. Para que puedan ser recibidos estos mensajes la clase de diálogo a la que pertenezca el cuadro mostrado, debe tener el mapa de mensajes oportuno.

iValor (int): El valor cuantitativo del análisis.

tcTexto (*char): String que contendrá el texto de la categoría.

xRangoOK (_RANGO_OK): Valores considerados recomendables dentro de una tipología.

Figura 6.10 Estructura _RANGO_OK

122


6.4.1.3.2 CTablaIndicesCada tabla que haya que comentar será un objeto de la clase CTablaIndices y estará formado por un compendio de resultados e información relacionada (índices u objetos de la clase CIndice). El número de elementos de que consta la tabla de índices es variable y depende del tipo de tabla, por lo que en el constructor de CTablaIndices hay que asignar dinámicamente el número de elementos.

Figura 6.11 Clase CTablaIndices

Entre sus funciones miembro, destacan aquellas pensadas para reordenar los elementos de la tabla, de forma que se puedan generar subtablas de elementos que cumplan ciertos requisitos (los mejores resultados por ejemplo).

La clase CTablaIndices consta de los siguientes atributos:

hHandleVentana (HWND): Manejador (handle) de ventana (handle).

iNumeroIndices (int): número de elementos de la tabla.

pxIndice (*CIndice): puntero a un objeto de tipo CIndice. Necesario para gestionar de forma dinámica en numero de objetos CIndice de los que consta cada tabla.

6.4.1.3.3 CTablaRangos y CRangoLos datos resultantes del análisis son números que cumplen una relación de orden por lo que pueden ser valorados mediante el cotejo con el rango de aceptación que marcan las reglas. Estos rangos de aceptación se organizan en otra clase a que se ha llamado CRango, que a su vez se agrupan por tablas de resultados mediante la clase CTablaRangos.

123


Figura 6.12 Clase CRango

Figura 6.13 Clase CTablaRangos

El concepto de objetivo de mejora es corresponde a un nivel que el Agente propone alcanzar al usuario, para lo que se sugiere mejorar en ciertas categorías. Es un valor dinámico, que varía según los resultados obtenidos por el usuario, así si el resultado del análisis indica un nivel principiante el objetivo de mejora será bajo y si el nivel es bueno, el objetivo de mejora será alto.

6.4.1.3.4 CDescriptoraTablasCualquier tabla que se necesite analizar, cuyos datos se organicen según la estructura de datos que marca CTablaIndices, puede ser pasada como parámetro a las funciones del módulo analizador, constituido por la clase CDescriptoraTablas. Los comentarios variarán según los resultados se adecuen a las reglas marcadas por la clase CTablaRangos.

Para llevar a cabo la interpretación de la tabla y realizar comentarios sobre los resultados esta clase incluye funciones miembro que realizan, entre otras, las siguientes tareas:

Crear subtablas con los “n” elementos más positivos y los “n” elementos más negativos para centrar los comentarios sobre las tipologías a los que pertenezcan.

Localizar la posición de un control a partir de su identificador, para poder situar al personaje sobre él.

Preguntar o sugerir al usuario el siguiente paso a realizar y enviar mensaje que abra cierto recurso.

Generar los comentarios que el personaje articulará según el contexto.

- sprintf (“Aunque en la tipología %s sus resultados son excelentes, en las tipologías %s y %s se podría mejorar”, tcTipo1, tcTipo2, tcTipo3);

124


- sprintf (“En %s ha obtenido un %f, lo cual está fuera del rango recomendado %d-%d”,tcTipo1, fResul, iRangoInf, iRangoSup);

Figura 6.14 Clase CDescriptoraTablas particularizada para el cuadro Tipologias

6.4.1.3.5 CPersonajeSingletonPara llevar a cabo la tarea descriptiva de una tabla, la clase CDescriptoraTablas tiene que controlar a los personajes. Para ello, la clase CDescriptoraTablas contiene dos punteros a objetos de la clase CPersonajeSingleton, que proporcionan punteros a objetos personaje (IAgentEx).

El acceso a la librería de Agentes (Agentes.dll) a lo largo del programa (no sólo en la clase CDescriptoraTablas) siempre se realiza a través de esta clase CPersonajeSingleton. La necesidad del uso de esta clase viene motivada por el hecho de no querer tener múltiples instancias de los personajes a lo largo del programa. De

125


este modo, la clase CPersonajeSingleton ha sido diseñada siguiendo un modelo Singleton y devuelve la misma instancia de un personaje una vez creado la primera vez.

El siguiente código corresponde a la definición de la clase y en él se puede ver el contructor público de la misma:

class CPersonajeSingleton{public:

static CPersonajeSingleton* getInstance(int iPersonaje){

if (iPersonaje == MERLIN){

if(!instance1)instance1 = new CPersonajeSingleton(MERLIN);

return instance1;}else //if (iPersonaje == GENIE){

if(!instance2)instance2 = new CPersonajeSingleton(GENIE);

return instance2;}

}

private:CPersonajeSingleton(int iPersonaje);

static CPersonajeSingleton* instance1;static CPersonajeSingleton* instance2;

}

El constructor privado utilizará la librería Agentes.dll para cargar el personaje únicamente la primera vez que es llamado.

126


6.4.1.4 Diagrama de clases

Figura 6.15 Diagrama de clases

127


6.4.1.5 Diagrama de objetos

Figura 6.16 Diagrama de Objetos

6.5 Comandos de Voz de Agent

La comunicación hablada con Agent se realiza a través de comandos de voz. Cuando se crean comandos de voz con Microsoft Agent, se puede editar el texto que aparece en la ventana de comandos de voz así como las palabras que el motor debería usar para igualar este comando.

Para la aplicación Analizador de Estilo se han creado (a través del API de Agent) comandos de voz simples que lanzan ciertas funcionalidades de la interfaz de usuario, como por ejemplo, el comando Comentar Tabla y también otro tipo de comandos que servirán para que el usuario dé una respuesta de tipo binario (Si o No) o de tipo cuantitativo (1,2,3..) ante las preguntas del personaje.

A estos comandos hay que sumar los que Agent incorpora a la ventana de comandos de voz de forma automática y que controlan la aparición del personaje o la conmutación de la entrada de voz entre personajes. A través de la ventana de comandos de voz, el usuario sabe en cada momento que comandos están activos.

128

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAConclusiones y líneas futuras

129


7 Conclusiones y líneas futuras

7.1 Conclusiones

Dado el peso específico que tiene Agent en este PFC y al hecho de que el empleo de la Programación basada en componentes supone una novedad para el Departamento y en particular para el GTH, se ha realizado un importante análisis descriptivo de los fundamentos de la tecnología COM y la Automatización OLE, necesarios para comprender y sacar el máximo rendimiento a la tecnología Microsoft Agent (Servidor de Automatización OLE).

Tanto el análisis de los rudimentos de la tecnología base, como la disección de la interfaz de programación de Agent, supone un excelente punto de partida para alguien que quiera continuar con la línea iniciada por este PFC: la investigación sobre interfaces de usuario basadas en personajes y su desarrollo mediante la herramienta Microsoft Agent.

Se ha creado una biblioteca de funciones de manejo de los Agentes en formato DLL (Agentes.dll), la cual constituye un API de más fácil utilización que las funciones de la interfaz directa de Microsoft Agent. La facilidad de uso se debe a que agrupa varios procesos de la interfaz de Agent en una única función, o a que aísla al programador de requerimientos COM, como, por ejemplo, el paso de parámetros en formato VARIANT.

La aplicación Analizador de Estilo, desarrollada en este PFC, usa la biblioteca Agentes.dll como interfaz de control de los Agentes. Además, una primera versión de la biblioteca fue aprovechada por Javier Martínez Salas para la inclusión de personajes animados en la interfaz de la aplicación de su PFC [Martínez Salas, 2000].

Al igual que la Programación basada en componentes, la utilización en este PFC del entorno de desarrollo integrado Microsoft Visual C++ 6 representa una novedad.. Dado lo cual, se ha intentado describir esta herramienta de desarrollo con espíritu didáctico, enfatizando en la parte práctica de la generación de aplicaciones y DLLs, o la inclusión de controles ActiveX a un proyecto.

Se ha reconstruido la interfaz gráfica del programa Analizador de Estilo lo que le ha proporcionado un aspecto más actual. También se ha aprovechado para dotarlo de mayores funcionalidades como, por ejemplo, una arquitectura documento/vista basada en la vista CRichEditView. Al incluir esta arquitectura, los textos a analizar pueden ser editados en el mismo programa en formato de texto enriquecido.

Se ha completado la interfaz de usuario del programa Analizador de Estilo, con la inclusión de un agente animado que explica los resultados, recalcando los más importantes y ofreciendo consejos para mejorar en puntos concretos el estilo del usuario. Este módulo de diálogo interactivo puede ser exportado, sin mucho esfuerzo, a otras aplicaciones en las que se necesite que un agente animado comente los resultados expuestos en una tabla.

130


La aplicación directa de la investigación desarrollada sobre COM y OLE también alcanza a otro aspecto práctico del proyecto: Se ha incluido un control ActiveX (tecnología OLE para Internet), llamado WebBrowser (Explorador del web), que ha dotado a la aplicación Analizador de Estilo de un sistema propio de navegación a través de las páginas web de ayuda.

7.2 Líneas futuras

En este proyecto, los mayores esfuerzos de desarrollo con los Agentes se han empleado en la tarea de integración en la interfaz de usuario: desplazamiento por la pantalla, gestión de las animaciones de los personajes al señalar botones, menús, o al abrir cuadros de diálogo, etc.

Aunque una parte de ese esfuerzo se ha dedicado a la gestión de la interacción hablada con el usuario, una línea de desarrollo a seguir sería la inclusión de un gestor de diálogo que diera más protagonismo a la interacción hablada como forma de acceso a las funcionalidades de la aplicación.

Ese gestor de diálogo interactivo se podría llevar a la práctica aprovechando las herramientas y los conocimientos ofrecidos por este proyecto y el background del Grupo de Tratamiento del Habla. El objetivo final de este tipo de interfaces sería que el Agente entendiese, en la medida de lo posible, a un usuario mediante el empleo de lenguaje natural.

En todo sistema que utiliza el habla hay que enfrentarse a la limitación que supone la tasa de reconocimiento. Para paliar esa limitación sería conveniente insertar mecanismos de control frente a fallos de reconocimiento. Agent ofrece las herramientas al dar porcentajes de probabilidad de acierto en el reconocimiento de los comando de voz.

Otra línea de desarrollo sería la creación de un motor de reconocimiento propio del GTH para no tener que depender de reconocedores comerciales. Este reconocedor sería de tipo Command and Control y la condición para que pudiera ser usado por Agent es que cumpliera con la interfaz SAPI de Microsoft.

Un buen diseño del comportamiento de los Agentes (siguiendo las pautas del Capítulo 1) es fundamental en una aplicación basada en personajes. Sería conveniente efectuar una evaluación del programa para comprobar el impacto y facilidad de manejo entre posibles futuros usuarios. Probando la interfaz con usuarios finales se podría dotar al Agente de una conducta más adecuada al gusto que esa muestra de usuarios marcase.

La situación que se pretende evitar con este tipo de análisis es una similar a aquella en la que el asistente de Office comenta: "Veo que está usted escribiendo una carta...", que tantas veces se produce en el peor momento durante la edición de un documento en Word, y que tanto irrita al usuario avezado en el uso del programa. Es el mismo usuario el que termina por desactivar al asistente, cansado de su mal funcionamiento y habiéndole cogido antipatía.

131


Mejorar el programa Analizador de Estilo dotando de nuevas funcionalidades al Agente. El cual podría, por ejemplo, buscar un texto en las páginas HTML de ayuda, o leer en voz alta y en inglés (cargando, al efecto, una TTS para lengua inglesa) un texto que el usuario acaba de escribir y del que tiene dudas acerca de su pronunciación.

Ampliación de las funciones de la biblioteca Agentes.dll. Por ejemplo, con funciones que manejen de forma automática la inserción de comandos de voz al vocabulario del Agente o la inserción de comandos al menú emergente del personaje; O funciones que gestionen la interacción entre dos personajes basándose, por ejemplo, en los métodos IAgentCharacter::Wait o IAgentCharacter::Interrrupt de la interfaz de Microsoft Agent.

Creación de un agente personalizado mediante el Editor Personajes de Microsoft. Tarea esta destinada a un ingeniero cualificado para las artes gráficas o a un artista con conocimientos técnicos.

132

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAProgramación basada en componentes: COM y Automatización OLE

8 Programación basada en componentes

8.1 Justificación de este Anexo

En este anexo se hace un análisis descriptivo de los fundamentos de la tecnología COM y la Automatización OLE, necesarios para comprender y sacar el máximo rendimiento a la tecnología Microsoft Agent (Servidor de Automatización OLE).

La aplicación directa de los conocimientos expuestos en este capítulo no se limita a la posibilidad de la programación avanzada de Agent, sino que también alcanza a otros aspectos de la programación de aplicaciones. Por ejemplo, en este mismo PFC se incluye un control ActiveX, llamado WebBrowser (Explorador del web), que dota a la aplicación Analizador de Estilos de un sistema propio de navegación a través de páginas web.

El análisis de estas tecnologías ha sido necesario dado el alto peso específico que supone Agent en este PFC. El esfuerzo descriptivo de esas mismas tecnologías, que se hace en este anexo, viene motivado por la novedad del empleo de la Programación basada en componentes en el Departamento y en particular en el GTH. Los conceptos aquí descritos pueden ayudar a que los lectores de este PFC obtengan un mejor aprovechamiento del mismo.

La información que se expone en este capítulo es un compendio de la bibliografía analizada al respecto de COM y OLE (principalmente de [Bates, 1999] y [Williams, 1994], aunque también de [Freeman, 1995] y [Goswell,1995]). No trata de abarcar todos los aspectos de estas tecnologías, sino que está enfocada a aclarar los rudimentos de los componentes utilizados en este PFC que se basan en esas tecnologías.

Se incluye un glosario de términos al final del capítulo.

8.2 Introducción

Debido a la creciente complejidad del desarrollo de software en entornos sofisticados como el de Windows, con sus muchas interfaces de programación de aplicaciones (API) y habida cuenta de la necesidad de estándares, de velocidad en el desarrollo y de la computación distribuida, se ha producido la aparición de una tecnología que se denomina Programación basada en componentes.

Los componentes son pequeñas entidades de software (algo así como ejemplares de una clase) que llevan a cabo tareas concretas a través de interfaces bien definidas. A diferencia de los ejemplares de una clase, no tienen fuertes lealtades para con un cierto ejemplar de programa o para con una determinada máquina. Se pueden escribir en muchos lenguajes y siguen comunicándose perfectamente a través de sus interfaces con programas y componentes implementados en otros lenguajes.

133


8.3 Modelo de Objetos Componentes

Microsoft ha hecho evolucionar esta tecnología hasta su estado actual, que se denomina Modelo de Objetos Componentes (COM). También pueden verse otros términos como Enlazado e Incrustación de Objetos (OLE) y Controles ActiveX (componentes para Internet). Pero hay que tener en cuenta que éstas son tan sólo implementaciones específicas de programación COM.

COM es un sistema independiente de lenguaje y de plataforma, distribuido y orientado a objetos para crear componentes software binarios que pueden interactuar entre sí empleando un protocolo común acordado.

Para comprender COM (y por lo tanto las tecnologías basadas en COM), es crucial tener en mente que no es un lenguaje orientado a objetos, sino un estándar. COM tampoco especifica cómo debe estar estructurada una aplicación. Lenguaje, estructura, e implementación son dejados en las manos del programador de la aplicación. COM especifica un modelo de objetos y requerimientos de programación que posibilitan que los objetos COM (también llamados componentes COM, o a algunas veces simplemente objetos) puedan interactuar con otros objetos. Estos objetos pueden estar dentro de un único proceso, en diferentes procesos o incluso en máquinas remotas. Pueden haber sido escritos en otros lenguajes, y pueden ser estructuralmente muy distintos. Esto es por lo que COM es referido como un estándar binario (un estándar que se aplica después de que un programa haya sido trasladado a código máquina binario).

El único requerimiento de lenguaje de COM es que el código sea generado en un lenguaje que pueda crear estructuras de punteros y, implícita o explícitamente, llamadas a función a través de punteros. Los lenguajes orientados a objetos como C++ proporcionan mecanismos de programación que simplifican la implementación de objetos COM, pero lenguajes como C también pueden usar y crear objetos COM.

Además al especificar el estándar de objeto binario básico, COM define ciertas interfaces básicas que proporcionan funciones comunes a todas las tecnologías basadas en COM. También proporciona un pequeño número de funciones API que todos los componentes requieren. COM ha expandido su ámbito para definir cómo han de trabajar los objetos sobre un entorno distribuido, y ha añadido características de seguridad para asegurar la integridad del sistema y del componente.

8.3.1 Interfaces COM

El aspecto más importante de los objetos COM son las interfaces; los objetos en sí son tan sólo implementaciones de caja negra con una funcionalidad específica. Sin embargo, para que sea posible utilizar esta funcionalidad, todos los programas clientes deben disponer de un contrato bien definido para pasar parámetros y obtener resultados. Este contrato entre los objetos y el programa cliente se denomina su interfaz.

En general, un objeto software está constituido por un conjunto de datos y las funciones que manipulan esos datos. En los objetos COM el acceso a sus datos se consigue exclusivamente a través de uno o más juegos de funciones relacionadas. Estas

134


colecciones de funciones, o métodos, constituyen la interfaz. Además, COM requiere que el único camino para conseguir acceder a los métodos de una interfaz sea a través de un puntero a la interfaz.

Todo objeto COM posee al menos una interfaz, pero suelen tener muchas, cada una de las cuales posee su propio conjunto de funciones. En la siguiente figura (adaptada de [Williams, 1994]) puede verse la representación de un objeto COM con tres interfaces.

Figura A.1 Interfaces de un Objeto COM

Es posible escribir un objeto COM en cualquier lenguaje que pueda admitir estas interfaces. Algunos lenguajes resultan más adecuados que otros. Por ejemplo, Java funciona muy bien porque todo objeto de Java puede poseer múltiples interfaces y por tanto encaja de forma natural con cualquier objeto COM. Los objetos COM ponen el código real por detrás de estas interfaces, así que un programa que llama a una función a través de una interfaz, hallará una implementación, dentro del objeto COM, que lleva a cabo la tarea definida por esa función.

La estructura de la interfaz COM estándar es exactamente la misma que la estructura de la tabla de las funciones virtuales de Visual C++. Esto significa que se puede utilizar el mecanismo de la tabla de funciones virtuales para definir e implementar interfaces COM.

Normalmente se utilizarán las funciones virtuales como una forma de reemplazar a una función de la clase base en una clase derivada (mediante el prefijo virtual en la declaración de la función en la clase base). Al hacer esto, se declara una tabla de funciones virtuales asociadas a esa clase, una vtable12.

La siguiente figura (adaptada de [Williams, 1994]) explica de forma gráfica el concepto de vtable:

12 Todo objeto de C++ en memoria posee una tabla de funciones virtuales asociadas (aunque algunas puedan no tener entradas y ser por tanto de longitud nula). Cada entrada de la tabla contiene un puntero del código que implementa una función virtual. Cuando se invoca a una de las funciones virtuales del objeto, la tabla asociada proporciona la dirección correcta, o bien de la función de la clase base o bien de la función de la clase derivada.

135


Figura A.2 Diagrama de una vtable

Es posible declarar una clase de C++ que únicamente contenga funciones virtuales puras. Esto es lo que se denomina una clase base abstracta. No es posible crear un ejemplar de estas clases abstractas, pero se pueden emplear para crear una interfaz COM compatible con C++ y pueden tener un aspecto similar al siguiente.

Class IUnknown{public:virtual HRESULT QueryInterface ( REFIID riid, LPVOID FAR* ppvObj )=0;virtual ULONG AddRef()=0;virtual ULONG Release()=0;}

Microsoft proporciona estas definiciones de C++ para todos los objetos COM que ofrece, aun cuando puede verse que las funciones están arropadas en una macro que se extiende para hacer lo mismo:

STDMETHOD (QueryInterface)(THIS_REFIID riid, LPVOID FAR* ppvObj) PURE;STDMETHOD_(ULONG, AddRef) (THIS) PURE;STDMETHOD_(ULONG, Release) (THIS) PURE;

Todo objeto, tiene que implementar la interfaz IUnknown que consta de estos tres métodos (o funciones) y toda interfaz debe implementar estas tres funciones antes que sus propias funciones personalizadas. El papel de estas funciones es como sigue:

AddRef(): Cuando un cliente obtiene un puntero de una interfaz, se incrementa un contador interno de referencia que representa el número de referencias de cliente que están activas en ese momento.

Release(): Cuando un cliente libera un puntero, se decrementa la referencia interna, hasta que ésta alcanza el valor cero cuando se destruye el objeto (normalmente por sí mismo).

QueryInterface(): Un cliente que posea un puntero de una interfaz de un objeto COM puede solicitar un puntero a otra interfaz de ese objeto, pasando el ID (el parámetro riid en el ejemplo precedente) de la interfaz requerida. Si existe esa interfaz, se invoca a AddRef() aplicada a un puntero de la interfaz solicitada y se proporciona la interfaz en el objeto ppvObj. El ID de la interfaz solicitada (riid) se explica detalladamente más adelante.

136


Dado que se tiene la garantía de que toda interfaz va a implementar estas funciones comunes, se puede escribir un programa que pida un ejemplar de un objeto COM (lo cual hará que se invoque automáticamente a AddRef() sin hacerlo el programador). Recorra las interfaces del objeto empleando QueryInterface(), y cuando haya terminado, llame a Release() para cada puntero de interfaz que haya obtenido, permitiendo así el objeto se destruya a sí mismo (excepto, por supuesto, sí hay algo más que lo esté utilizando). Estas mismas funciones son válidas universalmente en todos los objetos COM.

Si se incrementa un objeto COM es preciso proporcionar el código que mantendrá este contador y que devuelve un puntero de la interfaz solicitada, o bien NULL si no existiera esa interfaz.

Una interfaz que únicamente admitiese estas tres funciones sería prácticamente inútil, así que normalmente las funciones más sofisticadas heredan esta definición como base y definen después funciones más específicas para formar una interfaz personalizada y de utilidad.

8.3.2 ID de interfaz, ID de clase y GUID

Como se ha visto antes, la función QueryInterface() proporcionará un puntero de otra interfaz que viva en un determinado objeto COM cuando se le pase el ID de la interfaz que se necesita. Cada interfaz posee su propio ID exclusivo, denominado IID, del mismo modo que cada clase de COM posee su CLSID. Estos ID son números de 128 bits de longitud, de los cuales se garantiza que son únicos para toda interfaz y todo objeto COM de cualquier lugar del mundo. Se denominan ID globalmente exclusivos (GUID).

Cuando se escribe a un nuevo objeto COM o se escribe una nueva interfaz, se puede emplear un programa llamado guidgen.exe para generar estos números globalmente exclusivos. Este programa aparece en el directorio ...Visual Studio\VC98\tools\bin\. Un GUID típico tiene este aspecto cuando adopta el formato registro:

{F0B7A1A1-9847-11cf-8F20-00805F2CD064}

Por su parte, en código C++, ese mismo número podría definirse de la siguiente forma:

#define GUID_DEFINEDtypedef struct _GUID{ unsigned long Data1; unsigned short Data2; unsigned short Data3; unsigned char Data4[8];} GUID;#endif /* GUID_DEFINED */

#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ EXTERN_C const GUID name \

137


= { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }

// {F0B7A1A1-9847-11cf-8F20-00805F2CD064}DEFINE_GUID(ID_Example, 0xf0b7a1a1, 0x9847, 0x11cf, 0x8f,

0x20, 0x0, 0x80, 0x5f, 0x2c, 0xd0, 0x64);

La capacidad para recordar números de 128 bits no es demasiado corriente, así que se asocia unos apodos legibles a las interfaces y a las clases. Por ejemplo, la interfaz IUnknown se conoce con el nombre de IID_IUnknown y la macro DEFINE_GUID puede utilizarse para asociar estos nombres al número de 128 bits con objeto de producir una estructura estática que se le puede pasar a QueryInterface() como ID de la interfaz.

Por ejemplo, el código siguiente hará que, teniendo acceso al objeto Agent a través del puntero pAgentEx a su interfaz IAgentEx, se pueda llamar a QueryInterface() y se obtenga el puntero pPropSheet a la interfaz IID_IAgentPropertySheet:

IAgentPropertySheet *pPropSheet =NULL;pAgentEx->QueryInterface( IID_IAgentPropertySheet, (LPVOID*)&pPropSheet);

Las clases COM tienen un prefijo similar, CLSID. Por ejemplo, el objeto Agent que implementa la interfaz IID_IAgentEx adopta el nombre CLSID_AgentServer.

Sin embargo, entre bastidores, el ID de la clase y de la interfaz son realmente GUID y se pueden obtener los números reales en el archivo AgtSvr_i.c, declarados en la forma:

typedef struct _IID{ unsigned long x; unsigned short s1; unsigned short s2; unsigned char c[8];} IID;

typedef IID CLSID;const CLSID CLSID_AgentServer = {0xD45FD2FC,0x5C6E,0x11D1, {0x9E,0xC1,0x00,0xC0,0x4F,0xD7,0x08,0x1F}};

8.3.3 Implementación de la localización y registro

Cuando un cliente desea usar un objeto, siempre comienza pidiendo a COM que localice el servidor de la clase del objeto, pide al servidor que cree un objeto, y devuelve al cliente un puntero a la interfaz inicial. A través de ese punto, el cliente puede obtener punteros a interfaces adicionales desde el mismo objeto a través de la función miembro IUnknown::QueryInterface.

Para alguna de sus propias clases nativas, OLE proporciona APIs creadas específicamente para acortar el proceso de inicialización. Pero para todos los componentes personalizados (aquéllos no implementados por el mismo OLE), COM proporciona una API de creación genérica, CoCreateInstance, la cual instancia un objeto, conocido su CLSID:

138


HRESULT CoCreateInstance (REFCLSID rclsid, DWORD dwClsCtx, void *pvReserved, REFIID riid, void** ppvClsObj);

El cliente pasa un CLSID, algunas banderas (flags), y el identificador de interfaz (IID) de la interfaz inicial. A la salida, la variable puntero pasada por referencia en el último argumento recibe el puntero a la interfaz. Internamente, COM se ocupa de enlazar el CLSID con el servidor correspondiente, cargando al servidor en memoria, y pidiéndole al servidor que cree el objeto y devuelva un puntero a la interfaz. Si el objeto está en un proceso diferente al del cliente, COM automáticamente organiza el puntero mediante una técnica denominada dominación que será vista en el siguiente apartado (A.1.4 DLL alternativos y dominación).

El detalle de los parámetros que se pasan a la función CoCreateInstance es el siguiente:

El primer parámetro es el CLSID del objeto que quiere ser cargado. COM lo busca en el registro en la siguiente ruta: HKEY_CLASSES_ROOT\CLSID\{<CLSID-GUID>}.

El segundo parámetro dwClsCtx da más información sobre contexto de activación del objeto.

Normalmente será preciso pasar un valor NULL como tercer parámetro pvReserved, que sólo se utiliza en una técnica COM avanzada denominada agregación.

El cuarto parámetro, riid, es una referencia de un GUID para la interfaz que se requiere en el nuevo objeto COM.

El último parámetro, ppvClsObj, es un puntero del puntero de interfaz de nuestro cliente, que recibirá un puntero de la interfaz especificada en el nuevo objeto.

Los primeros dos parámetros son usados por el Director de Control de Servicio o SCM (del inglés Service Control Manager"), para localizar la implementación del objeto. El parámetro dwClsCtx permite al cliente indicar la preferencia de cargar el objeto en proceso o fuera del proceso. Este parámetro es una máscara de bits que soporta los siguientes valores:

enum CLSCTX { CLSCTX_INPROC_SERVER = 1, CLSCTX_INPROC_HANDLER = 2, CLSCTX_LOCAL_SERVER = 4};

#define CLSCTX_ALL CLSCTX_INPROC_SERVER | CLSCTX_INPROC_HANDLER | CLSCTX_LOCAL_SERVER

#define CLSCTX_SERVER CLSCTX_INPROC_SERVER |

139


CLSCTX_LOCAL_SERVER

Basándose en los bits fijados en dwClsCtx, el SCM consulta las claves apropiadas en el registro de Windows y carga la implementación apropiada.

Cuando se crea un ejemplar de un objeto COM, arranca un proceso servidor de ejecución que lo mantiene. El proceso servidor puede ser nuestro propio programa cliente, una DLL asociada, un ejecutable (.exe) situado en la máquina local, o un programa de una máquina remota. Todos estos casos se denominan contextos y se muestran en la siguiente tabla (tomada de [Bates, 1999]):

Contexto Indicador asociado Descripción

Servidor en proceso

CLSCTX_INPROC_SERVER El código se ejecuta en el mismo proceso que el programa cliente que hace la llamada.

Servidor local CLSCTX_LOCAL_SERVER El código se ejecuta en otro programa EXE, en un proceso diferente de la misma máquina que el programa.

Servicio remoto

CLSCTX_REMOTE_SERVER El código se ejecuta en una máquina completamente distinta de aquella en que reside el programa que hace la llamada.

Tabla A.1 Distintos contextos para ejecutar un código COM.

Toda la información relativa al objeto que las bibliotecas COM necesitan está concentrado bajo una entrada en el registro de Windows: HKEY_CLASSES_ROOT\CLSID. Cada objeto tiene una clave que es llamada con la representación en forma de cadena de caracteres que es su CLSID. Bajo esta clave, Las bibliotecas, buscan la información que necesitan para crear el objeto. Existe una clave de entrada para cada uno de los distintos tipos de servidor registrado (bien sea InprocServer32, LocalServer32 o RemoteServer32). Junto a estas claves se puede ver el nombre de archivo del DLL o EXE que contiene el código necesario para crear y gestionar el objeto COM.

Como ya ha sido anticipado, existen tres tipos de servidores:

Servidor en proceso: Servidores implementados como DLLs Win32. Dado el CLSID del objeto, la biblioteca COM busca en la ruta HKEY_CLASSES_ROOT\CLSID la apropiada clave GUID del objeto. Una vez encontrada, para obtener el nombre de la DLL y la ruta del directorio donde se encuentra instalada, mira el valor de la sub-clave InprocServer32. Finalmente, COM llama a la función LoadLibrary, para cargar la DLL en memoria.

Servidor local: Servidores implementados como programas ejecutables (.EXE) y por lo tanto fuera de proceso. Se utiliza la clave LocalServer32 en lugar de InprocServer32. Para ello, COM llama a la función CreateProcess (del API de Win32) para lanzar el .exe; el cual, en ese momento, inicializa COM en su propio espacio de proceso. Cuando esto ocurre, COM en el proceso del servidor conecta con COM en el proceso del cliente.

140


Servidor remoto (aquel que corre en otra máquina): Las entradas del registro incluyen también el nombre de la máquina. Cuando COM activa un servidor de este tipo, se comunica con un proceso residente, el SCM, que corre en la otra máquina. Entonces, el SCM carga o lanza al servidor sobre la máquina servidora y envía un puntero de retorno a la interfaz a la máquina cliente.

[HKEY_CLASSES_ROOT\APPID\{<appid-guid>}] "RemoteServerName"="<DNS name>"

El resultado neto en cualquiera de los tres casos anteriores, es que el cliente tiene un puntero a una interfaz a través de la cual puede comenzar a usar los servicios del objeto.

Resumiendo, el proceso básico de instanciación de un objeto a través de la llamada a la función CoCreateInstance se muestra esquematizado en la siguiente figura (adaptada de [Brockschmidt, 1994]:

Figura A.3 Localización y activación de un objeto

En la figura se muestran las acciones necesarias para que una aplicación cliente pueda usar un objeto COM y como se desencadenan estas acciones a partir de la llamada a CoCreateInstance: 1. La aplicación cliente llama a CoCreateInstance para instanciar un Objeto COM.

2. La biblioteca COM busca en el Registro de Windows a través del CLSID.

3. Tras localizar la implementación del objeto, se lanza el servidor.

4. CoCreateInstance devuelve a la aplicación un puntero a la interfaz del Objeto.

5. A través del puntero a la interfaz se pueden usar los servicios del objeto.

141


8.3.4 DLL alternativos y dominación

Cuando el programa cliente obtiene un puntero de la interfaz del objeto COM, no le importa dónde está situado el objeto real. Sin embargo, si el objeto COM está ejecutándose fuera de nuestro proceso cliente, el puntero no puede señalar directamente la vtable de funciones de la interfaz; en lugar de hacer esto, se crea un segmento vacío en nuestro espacio de proceso que a los ojos del cliente adopta el aspecto de un puntero de interfaz local. Cuando se llama a una función a través de ese puntero de interfaz, se emplea, entre bastidores, una técnica denominada dominación (marshalling) para enlazar nuestro cliente con el objeto COM a través de otra DLL denominada alternativo (proxy).

Ambas interfaces se registran también en el Registro de Windows dentro de HKEY_CLASSES_ROOT\Interface, identificándolas mediante su GUID. Éstas definen claves tales como ProxyStubClsid32, que contiene el CLSID que identifica la situación del DLL alternativo que puede dominar las funciones de la interfaz. Como puede verse en la siguiente figura:

Figura A.4 Claves para localizar el DLL alternativo (proxy) de una interfaz

El DLL alternativo tiene la responsabilidad de reunir los parámetros en forma independiente de la máquina para su transmisión. Quizá utilice llamadas a procedimiento remoto (RPC) para llamar a una función de un objeto COM remoto. Los DLL alternativos se pueden generar automáticamente escribiendo definiciones en el Lenguaje de Definición de Interfaz y pasándolas por el compilador IDL de Microsoft (MIDL). El compilador producirá unas RPC y un código de dominación adecuado para su inclusión en un DLL alternativo.

8.3.5 El Director de Control de Servicio

El Director de Control de Servicio o SCM (del inglés Service Control Manager) se ocupa de que cuando una solicitud de cliente sea hecha, el servidor apropiado esté conectado y preparado para recibir la petición. El SCM mantiene una base de datos con información de clases basada en el registro de Windows a la que el cliente accede a través de la biblioteca COM.

Esta es la base de los servicios de localización de implementaciones, como se muestra en la Figura A.5:

142


Figura A.5 COM delega la responsabilidad de cargar y lanzar los servidores al SCM.

Esta figura (adaptada de [Brockschmidt, 1996]) muestra como la biblioteca COM utiliza al SCM para lanzar, cargar y conectar remotamente (si es necesario) con el servidor COM. Para ello, cuando un cliente hace la solicitud de creación de un objeto dando su CLSID, la biblioteca COM contacta con el SCM local (sobre el mismo ordenador) y pide que el apropiado servidor sea localizado o lanzado, y una factoría de clases sea devuelta a la biblioteca COM. Después de eso, la biblioteca COM, o el cliente, puede pedir a la factoría de clases que cree el objeto.

8.3.6 Versiones de interfaces

El viejo problema de mantener unas versiones correctas del software se resuelve mediante una sencilla regla. Una vez publicado el objeto COM para que lo use todo el mundo, es preciso dejar intactas sus interfaces en futuras versiones. Esto significa que las versiones nuevas del objeto COM deberán implementar interfaces adicionales, manteniendo inalteradas las originales. Los viejos programas clientes que sólo saben utilizar la interfaz del viejo estilo, se limitarán a solicitar esa interfaz, mientras que los programas clientes que conozcan las nuevas características podrán solicitar la nueva versión de la interfaz.

La técnica estándar de denominación para estas nuevas interfaces consiste en añadir un número de versión después de la interfaz. Aunque las interfaces del servidor de Microsoft Agent que incluyen interfaces extendidas lo hacen añadiendo un sufijo "Ex". Estas interfaces derivan de las versiones no extendidas y por lo tanto incluyen toda su funcionalidad.

143


Por ejemplo, la interfaz original de IAgent ha sido ampliada (a partir de Microsoft Agent 2.0) con nuevas funciones que sólo son implementadas a través de IAgentEx. Ahora, los programas clientes antiguos pueden seguir solicitando IAgent y los nuevos solicitar la interfaz IAgentEx, que es más sofisticada pero que sigue incluyendo los métodos tradicionales. Si se solicita una interfaz IAgentEx a un servidor Agent 1.5 (no actualizado), se tomará un valor NULL como puntero de interfaz procedente de la llamada a CoCreateInstance y se proporcionará el código S_FALSE.

Dado que sólo importa la definición de la interfaz, los objetos COM son libres de utilizar el mismo código de implementación para implementar funciones que sigan siendo iguales en las versiones nuevas y viejas de las interfaces.

8.4 Automatización OLE

El Enlazado e Incrustación de objetos (OLE) era un término destinado inicialmente a describir la capacidad de insertar objetos de distintos tipos en documentos de otro tipo, tal como insertar hojas de cálculo de Excel en documentos de Word.

Los documentos que admiten estas operaciones de enlazado e incrustación se denominan documentos compuestos. Si se pulsa el menú Insert de algunas aplicaciones se verán las opciones comunes del menú Object. Las aplicaciones que admiten esta opción, almacenan estos documentos compuestos y permiten insertar objetos procedentes de una lista de servidores OLE registrados.

Los objetos insertados pueden ser o bien incrustados, lo cual significa que se guardarán en el documento, o bien enlazados, lo cual significa que se inserta una referencia del archivo (lo que se denomina Moniker) en el documento. Estas dos operaciones han dado lugar al término OLE original.

Sin embargo, el término se ha extendido hasta incluir las opciones OLE para arrastrar y soltar, así como la Automatización OLE, qué consiste en que un programa puede invocar métodos almacenados en otro programa que se ejecuta de forma invisible, de tal modo que el usuario no es consciente de ninguna interacción.

8.4.1 Comprensión de la interfaz de distribución

Las capacidades de automatización surgen de una definición principal de interfaz COM, llamada interfaz de distribución, IDispatch. Un objeto COM que ofrezca una interfaz de distribución contendrá una tabla de métodos con nombres (funciones), sucesos (funciones que registran llamadas retroactivas del cliente frente a notificaciones específicas) y propiedades (funciones que obtienen o establecen una determinada variable del objeto COM). Los programas clientes pueden acceder dinámicamente a este tipo de información (lo cual se denomina enlazado tardío) mientras se están ejecutando para obtener detalles relativos al objeto de automatización.

La interfaz de distribución extiende a IUnknown (interfaz de todo objeto COM) con estas cuatro funciones:

144


interface IDispatch : IUnknown{

HRESULT GetTypeInfoCount(unsigned int *pctinfo);

HRESULT GetTypeInfo(unsigned int itinfo, LCID lcid ITypeInfo **pptinfo);

HRESULT GetIDsOfNames(REFIID riid, OLECHAR **rgszNames, unsigned int cNames, LCID lcid, DISPID *rgdispid);

HRESULT Invoke(DISPID dispID, REFIID riid, LCID lcid, unsigned short wFlags, DISPPARAMS *pDispParams, VARIANT *pVarResult, EXCEPINFO *pExcepInfo, unsigned int *puArgErr);};

GetTypeInfoCount(): Permite al programa cliente saber si está disponible la información de tipos.

GetTypeInfo(): Recupera la información de tipos.

GetIDsOfNames(): Proporciona un conjunto de posiciones de array (denominadas ID de distribución) que corresponden a los nombres de los métodos, sucesos o propiedades solicitados.

Invoke(): Invoca a una de las funciones contenidas en el array de distribución cuando se le pasa el ID de distribución con un cierto número de parámetros VARIANT13 y proporciona un resultado VARIANT al retornar.

Esta interfaz de distribución se utiliza mucho en OLE, especialmente en cosas tales como controles ActiveX, documentos OLE y guiones de Visual Basic. Este sistema de búsqueda de funciones a partir de una tabla interna durante la ejecución, resulta muchísimo más lento que llamar directamente a los métodos de una interfaz, pero ofrece una cierta flexibilidad. Se pueden producir bibliotecas completas de esta información de tipos en forma de archivos .tlb; estas bibliotecas permiten a Visual C++ construir rápidamente esqueletos de clases (que se denominan controladores de distribución) a los que es posible invocar empleando métodos que tienen exactamente el mismo aspecto que una versión local del objeto de automatización. Estos esqueletos de clases admiten los parámetros correctos, y los transforman en un array de VARIANT para después llamar a la función Invoke() con objeto de llamar al verdadero objeto de Automatización OLE.

La siguiente figura expone de forma gráfica el mecanismo de una interfaz de distribución. Ha sido adaptada de [Brockschmidt, 1996] para el caso del Control ActiveX de navegación empleado en el Analizador de Estilos:

13 La estructura VARIANT se explicará en la sección siguiente.

145


Figura A.6 El acceso a un método o propiedad en una interfaz de Distribución se realiza pasando el dispID apropiado a través de IDispatch::Invoke.

En la figura se muestra cómo mediante un puntero a la interfaz de distribución, pCtrlNavegador, se acaba llamando a las funciones que implementa el control (por ejemplo, CNavegador::Navigate). Estas funciones se organizan localmente en el cliente mediante una tabla de distribución (controlador de distribución). Las llamadas a esas funciones locales provocan una llamada a Invoke que conecta con la verdadera implementación de las funciones dentro del control. Que una única función (Invoke) sea capaz de llamar a cualquiera de las funciones de esa tabla, se consigue mediante la discriminación que ofrecen los ID de distribución (DISPID) pasados a la propia función Invoke (por ejemplo, en la figura, el DISPID 0 corresponde con la función Navigate).

Como se ha comentado, hacer una llamada a un método o un acceso a una propiedad a través de IDispatch::Invoke es un proceso que supone gran cantidad de sobrecarga, lo cual repercute en aumento del tiempo de ejecución respecto a la misma funcionalidad obtenida a través de una interfaz vtable. Por esta razón, Automatización OLE define lo que se llama una interfaz dual, consistente en una interfaz vtable personalizada que deriva de IDispatch. La interfaz dual permite a un cliente que pueda realizar vinculación mediante una vtable, llamar a funciones en la interfaz de manera eficiente sin perder compatibilidad con los controladores de automatización que únicamente pueden llamar a miembros IDispatch. Una interfaz dual tiene el beneficio añadido de que Automatización OLE proporciona para ambas interfaces el mismo gestor de memoria y así como un número limitado de tipos compatibles con OLE.

8.4.2 Cómo se utiliza las variantes

Dado que la función Invoke() se invoca desde múltiples funciones diferentes de Automatización OLE, esta función tiene que disponer de una forma de pasar diferentes tipos de parámetros a las diferentes funciones que invoca. Esto se hace pasándole una estructura DISPPARAMS que apunta a un array de estructuras VARIANT. Una estructura VARIANT se limita a almacenar una unión de C++ formada por muchos tipos de datos distintos, que pueden ser dominados por OLE. También contiene un índice de tipo de variante (VARTYPE) denominado vt que indica el tipo que se está empleando.

146


typedef struct tagVARIANT VARIANT;typedef struct tagVARIANT VARIANTARG;

typedef struct tagVARIANT { VARTYPE vt; //Identifica el tipo unsigned short wReserved1; unsigned short wReserved2; unsigned short wReserved3; union { //Campos pasados por valor short iVal; long lVal; float fltVal; double dblVal; VARIANT_BOOL bool; SCODE scode; CY cyVal; DATE date; BSTR bstrVal; IUnknown FAR * punkVal; IDispatch FAR* pdispVal; SAFEARRAY FAR* parray;

//Campos pasados por referencia short FAR* piVal; long FAR* plVal; float FAR* pfltVal; double FAR* pdblVal; VARIANT_BOOL FAR* pbool; SCODE FAR* pscode; CY FAR* pcyVal; DATE FAR* pdate; BSTR FAR* pbstrVal; IUnknown FAR* FAR* ppunkVal; IDispatch FAR* FAR* ppdispVal; VARIANT FAR* pvarVal; void FAR* byref; }; };

La siguiente tabla muestra algunos de los muchos tipos de datos que pueden contener la estructura VARIANT junto con el tipo de variante (vt) asociado. VARIANT también puede contener punteros de los distintos objetos, lo cual se indica anteponiendo una p al nombre (tal como plVal) y agregando el valor de indicador VT_BYREF al indicador de tipo (tal como VT_I4|VT_BYREF).

147


Tipo de Datos Nombre Identificador de tipo Descripción

unsigned char bVal VT_UI1 Un valor de un byte sin signo

short iVal VT_I2 Un valor de dos bytes con signo

long lVal VT_I4 Un valor de cuatro bytes con signo

float fltVal VT_R4 Un valor de cuatro bytes en coma flotante

double dblVal VT_R8 Un valor de ocho bytes en coma flotante

BOOL boolVal VT_BOOL Un valor TRUE o FALSE de cuatro bytes

SCODE scode VT_ERROR El valor de un código de error COM

DATE date VT_DATE El valor de una fecha en coma flotante compatible con ColeDateTime.

BSTR bstrVal VT_BSTR El valor de una cadena compatible con Visual Basic que puede ser convertida desde y hacia el tipo CString

IUnknow punkVal VT_UNKNOW Un puntero de una interfaz IUnknow

IDispatch pdispVal VT_DISPATCH Un puntero de una interfaz IDispatch

Tabla A.2 Resumen de los tipos de datos más importantes de un VARIANT

Una clase importante de objetos de automatización es la llamada colección (collection), la cual es un agrupamiento de otros objetos. Las colecciones implementan métodos específicos y propiedades para navegar por los elementos que las constituyen, incluyendo la interfaz IEnumVARIANT, que enumera esos elementos.

Otro de los tipos más usados en Automatización OLE, aunque es el tipo de cadena de Visual Basic, es BSTR (Basic string). Un BSTR es un OLECHAR*, un puntero que señala a una cadena Unicode. La clave char que precede a OLECHAR indica la longitud de BSTR. Su valor se configura a través de la API SysAllocString. Para liberar BSTR, se tiene que utilizar la API SysFreeString.

Figura A.7 Tipo de cadena BSTR

Los tipos datos que se almacenan en VARIANT son independientes de lenguaje y serán comprendidos por cualquier lenguaje compatible con OLE. OLE proporciona servicios para convertir, si es posible, VARIANT de un tipo en otro tipo compatible.

Para traducir entre BSTR y un objeto CString de MFC, se pueden utilizar las funciones de CString denominadas AllocSysString() y SetSysString(), que reservan un nuevo BSTR y dan valor a un BSTR ya existente a partir del contenido de la CString, respectivamente. La traducción inversa puede realizarse empleando las refundiciones de

148


tipo definidas por (char*) y (const char*) para traducir la BSTR a una cadena con terminación nula.

Los tipos variantes no se emplean únicamente en la interfaz de distribución; pueden aparecer en múltiples lugares de OLE como formas útiles de almacenar y transferir distintos tipos de datos.

8.4.3 Eventos

Los conceptos explicados en este apartado son necesarios para entender cómo el servidor Agent notifica de sus propios eventos o de eventos del usuario a la aplicación cliente.

Como ya se ha comentado, un cliente de Automatización puede controlar un servidor de Automatización programáticamente a través de la llamada interfaz de distribución (dispatch). Pero además, el servidor puede estar atento a la ocurrencia de ciertos acontecimientos y generar notificaciones de eventos al cliente cuando sucedan.

Un evento de un servidor de Automatización es un método que está definido en el Servidor, en la interfaz de distribución de un objeto fuente de eventos, pero que está implementado en una interfaz de distribución del Cliente y que actúa a modo de recolector de eventos [Rogerson, 1994].

El objeto fuente de eventos define una interfaz de distribución como su lista de eventos. Se puede pensar que los eventos son los métodos de esa interfaz de distribución mediante los cuales el servidor puede informar al cliente de lo que le ocurre. Pero en Automatización, un evento es más bien un método que es llamado por un objeto del Servidor, más que un método implementado por ese objeto, ya que es realmente el cliente el que implementa esa interfaz para dar un tratamiento personalizado a los eventos lanzados por el servidor. El Servidor por si mismo no implementa ningún evento en su propia interfaz IDispatch.

La forma de lanzar los eventos es llamando a esos mismos métodos que se ejecutarán en el contexto de la aplicación. Para ello, cuando un servidor quiere disparar un evento, invoca a la función IDispatch::Invoke con el ID de distribución correspondiente al evento y los parámetros apropiados.

El cliente debe implementar puntos de entrada para los eventos. Los puntos de entrada consisten en interfaces que implementan el juego completo de eventos del Servidor sin tener en cuenta si el propio cliente realizará alguna acción sobre estos eventos. Proporcionando todos los puntos de entrada se consigue que el Servidor nunca tenga que preocuparse sobre si debe lanzar un evento: Él sólo los lanza y deja que el contenedor los ignore. Por defecto, el cliente los ignora, pues no hará nada con estos eventos a menos que le sean útiles y haya sido especialmente programado para tratarlos de alguna manera. La desventaja de este mecanismo es que incluso si únicamente se quiere manejar una clase de eventos, se ha de implementar la interfaz entera de la que es parte.

149


Resumiendo:

El servidor define los eventos y los describe en su librería de tipos.

El contenedor implementa un manejador de los eventos a través de una interfaz de distribución.

La fuente dispara los eventos llamando a los métodos de esa interfaz.

La siguiente figura representa un ejemplo en el que puede analizarse el mecanismo de generación y manejo de eventos en un servidor de Automatización:

Figura A.8 Fuente y recolector de eventos

En la figura puede verse la actividad normal de un Servidor de Automatización, un objeto (en la figura etiquetado como Objeto Normal) tiende una interfaz (IObjetoNormal) al cliente, que éste aprovecha para acceder a sus métodos. Pero además, puede verse cómo funciona la gestión de eventos: El cliente implementa la interfaz de distribución IRecolectorEventos para manejar los eventos generados por el servidor. Para ello crea un objeto Recolector de Eventos y registra la interfaz en el servidor para que éste tenga un punto de entrada (el puntero a la interfaz, pIRecolectorEventos). Cuando el Servidor detecta un evento, como por ejemplo que el usuario haya clicado el ratón, crea el objeto Fuente de Eventos. Este objeto conoce cuál es la función de la interfaz IRecolectorEventos que recoge la información sobre ese evento, por lo que llama a la función IRecolectorEventos::Invoke() con el identificador de la función (ID_CLICK) y los parámetros apropiados (por ejemplo, las coordenadas en pantalla del punto clicado). La interfaz de distribución habrá implementado la función que maneje ese evento y gestionará la información aportada por el servidor de la forma que considere oportuna.

150


8.5 GLOSARIO:

ActiveX: La tecnología ActiveX es una implementación específica de OLE orientada a controles para Internet.

Automatización OLE: La Automatización OLE consiste en que un programa, el cliente, puede invocar métodos almacenados en otro programa, el servidor, que se ejecuta de forma invisible, de tal modo que el usuario no es consciente de ninguna interacción. La Automatización OLE es una implementación específica de la arquitectura de Modelo de Objetos Componentes (COM).

Controlador de Distribución (o de Automatización): Mecanismo por el cual el cliente de un control OLE invoca métodos que tienen exactamente el mismo aspecto que una versión local del objeto de automatización, pero que realmente sólo se encargan de redirigir las llamadas al verdadero objeto de Automatización OLE a través de la función Invoke().

Enlazado e incrustación de objetos, OLE (Object Linking and embedding): La capacidad de un programa para visualizar y utilizar capacidades de otro programa dentro de sus ventanas. Por ejemplo, se puede visualizar una hoja de cálculo en un documento de un procesador de textos sin que el procesador de textos sepa nada acerca del objeto visualizado; el código para visualizar y mantener el objeto pertenece íntegramente a la hoja de cálculo.

Lenguaje de definición de interfaces de Microsoft, MIDL: lenguaje que específica definiciones de interfaces COM y de clases COM para construir el código de llamadas a procedimientos remotos (RPC) y el paso de parámetros de forma bien definida y compatible entre distintas aplicaciones.

Modelo de Objetos Componentes, COM: Es un modelo de programación que extiende los conceptos de la orientación a objetos más allá del ámbito de un solo programa. Los distintos programas pueden comunicarse y emplear objetos mediante interfaces bien definidas, sin necesidad de saber donde están ubicados esos objetos. Los objetos pueden ejecutar localmente o en otra máquina a través de una red.

Modelo de Objetos Componentes Distribuidos, DCOM: Extiende COM para soportar comunicaciones entre objetos localizados en diferentes ordenadores, red de área local (LAN), red de área extensa (WAN), o incluso Internet.

VARIANT: Estructura que almacena una unión de C++ formada por muchos tipos de datos distintos. Contiene un índice denominado vt que indica el tipo que se está empleando. Es utilizado por la función Invoke() para poder pasar parámetros de cualquier tipo, y por muchas otras funciones de OLE.

vtable: tabla de funciones virtuales que crea el compilador para toda definición de clase. Se utiliza en COM para definir la implementación específica de una interfaz.

151

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAInterfaz de programación de Microsoft Agent

152


9 Interfaz de programación de Microsoft Agent

Microsoft Agent define unas interfaces que permiten a las aplicaciones acceder a sus servicios. Las interfaces consisten en colecciones de funciones, o métodos, a través de los cuales una aplicación puede controlar las animaciones de un personaje, los eventos de entrada de un usuario o especificar la salida de audio, entre otras.

Este anexo se puede considerar como una referencia de consulta de la interfaz de programación del servidor Agent [Microsoft #4, 1998]. Las funciones están organizadas por interfaces.

En el análisis de las funciones se ha diseñado un formato, que da a cada apartado del análisis (Descripción, Parámetros, Valores de Retorno...) una tipografía diferente para favorecer la claridad. No incluye los nombres de los apartados por no resultar repetitivo. El formato es el siguiente:

Nombre de la funciónPrototipo de la función

Breve descripción de la funcionalidad

• Valores de retorno

Parámetros

Descripción de los parámetros

Descripción más detallada de la funcionalidad (sólo sí es necesario).

Al comienzo de la descripción de cada interfaz, una tabla resume las funciones que esta guía incluye relacionadas con la misma, incluyendo una breve descripción de su funcionalidad.

Las interfaces que a continuación serán descritas son IAgent, IAgentEx, IAgentCharacter, IAgentCharacterEx, IAgentNotifySink y IAgentNotifySinkEx.

9.1 IAgent

IAgent define la interfaz que permite a las aplicaciones cargar los personajes, recibir eventos, y chequear el estado actual del servidor de Microsoft Agent. Estas funciones son también accesibles desde IAgentEx.

Métodos IAgent Descripción

Load Carga el fichero de datos de un personaje.

Unload Descarga el fichero de datos de un personaje.

Register Registra un recolector de eventos (notification sink) de cliente.

Unregister Desregistra un recolector de eventos (notification sink) de cliente.

153


GetCharacter Devuelve la interfaz IAgentCharacter del personaje cargado.

9.1.1 IAgent::GetCharacterHRESULT GetCharacter( long dwCharID )

Obtiene el interfaz IAgentCharacter del personaje cargado.


DwCharID


9.1.2 IAgent::LoadHRESULT Load ( VARIANT vLoadKey, long * pdwCharID, long * pdwReqID )

Carga un personaje en la colección de personajes (colección Characters).


vLoadKey

VARIANT que debe ser rellenado con una de las siguientes posibilidades:

filespec Localización del fichero de definición del personaje especificado.

URL Dirección HTTP del fichero de definición de personaje.

pdwCharID

Dirección de la variable que recibe el identificador de personaje.

pdwReqID

Puntero a una variable que recibe el identificador de la petición de ejecución del método de carga.

Se pueden cargar personajes del subdirectorio de Microsoft Agent, especificando la ruta de directorios relativa. Esta ruta relativa se completa anteponiendo la dirección del directorio de personajes de Agent (localizado en el directorio %windows%\msagent)

No se puede cargar el mismo personaje (un personaje que tenga el mismo GUID) más de una vez en una única conexión. Sin embargo, se puede realizar otra conexión (usando CoCreateInstance) y cargar el mismo personaje.

El proveedor de datos de Microsoft Agent permite cargar datos de personajes almacenados en ficheros de extensión .ACS, en los cuales los datos del personaje y los datos de las animaciones están juntos. Existe otra manera de cargar que necesita de dos formatos de fichero, el de extensión .ACF que contiene los datos del personaje y .ACA que contiene los datos de las animaciones. Generalmente, hay que usar el fichero .ACS para cargar un personaje que esté almacenado en un disco duro o red local y el acceso se

154


hace usando un protocolo de ficheros convencional. Y hay que usar los ficheros .ACF y .ACA cuando se quiera cargar los ficheros de animación individualmente desde un sitio remoto. Aquí el acceso se realiza a través del protocolo HTTP.

Cuando se usan ficheros .ACS, el uso del método Load proporciona acceso a las animaciones del personaje. Una vez cargado, se puede usar el método Play para animar el personaje.

En el caso de usar ficheros .ACF, hay que usar además el método Prepare para cargar los datos de animación. El método Load no soporta descarga de ficheros .ACS usando HTTP.

Al cargar un personaje, éste no se muestra de forma automática. Hay que usar el método Show para hacer visible al personaje.

9.1.3 IAgent::RegisterHRESULT Register( IUnknown * punkNotifySink, long * pdwSinkID )

Registra el recolector de eventos (notification sink) para la aplicación cliente.


punkNotifySink

Puntero a variable de tipo IUnknown que sirve de interfaz para el recolector de eventos.

pdwSinkID

Puntero al identificador del recolector de eventos. El cual será usado para desregistrar el recolector.

Es necesario registrar el recolector de eventos (notify sink o event sink) para recibir los eventos desde el servidor de Microsoft Agent.

9.1.4 IAgent::UnLoadHRESULT UnLoad ( long * dwCharID )

Descarga los datos del personaje especificado de la colección de personajes (colección Characters).


dwCharID

Identificador de personaje.

Cuando no se necesita más al personaje, se usa este método para liberar la memoria utilizada para almacenar la información del personaje. Después, si se quiere acceder al personaje de nuevo, hay que volver a usar el método Load.

155


9.1.5 IAgent::UnregisterHRESULT Unregister( long dwSinkID )

Elimina el registro del recolector de notificaciones.


dwSinkID

Identificador del recolector de notificaciones.

Hay que usar este método cuando no se necesiten los servicios de Microsoft Agent por más tiempo; como por ejemplo, cuando la aplicación se cierra.

9.2 IAgentEx

IAgentEx deriva de la interfaz IAgent. Incluye todos los métodos de IAgent y proporciona acceso a funciones adicionales.

Métodos IagentEx Descripción

ShowDefaultCharacterProperties Muestra las propiedades del personaje por defecto.

GetVersion Devuelve el número de versión del servidor de Microsoft Agent.

9.2.1 IAgentEx::ShowDefaultCharacterPropertiesHRESULT ShowDefaultCharacterProperties( short x, short y, long bUseDefault )

Muestra en la ventana de propiedades del personaje por defecto.


x


y


bUseDefault

Bandera de posición por defecto. Si este parámetro es True, Microsoft Agent muestra la ventana de hoja de propiedades del personaje por defecto en la localización en la que apareció por última vez.

156


9.2.2 IAgentEx::GetVersion HRESULT GetVersion( short * psMajor, short * psMinor )

Devuelve el número de versión del servidor de Microsoft Agent.


psMajor

Dirección de la variable que recibe la versión más reciente.

psMinor

Dirección de la variable que recibe la versión más antigua.

9.3 IAgentCharacter

IAgentCharacter define una interfaz que permite a las aplicaciones preguntar por las propiedades del personaje y ejecutar animaciones. Estas funciones están también disponibles a través de IAgentCharacterEx.

Algunos métodos incluyen un identificador de petición de ejecución. Se puede capturar el evento que indica que la operación correspondiente a ese identificador ha sido cursada. De esta manera, se puede seguir el progreso de las animaciones de la cola del personaje y sincronizar el código del resto de la aplicación con el estado de animación actual del personaje.

Métodos IagentCharacter____ Descripcción________________________________________

Play Ejecuta una animación específica.

Stop Detiene una animación del personaje.

StopAll Detiene todas las animaciones del personaje.

Wait Detiene la ejecución de la cola de animaciones.

Interrupt Interrumpe la animación de un personaje

Show Muestra al personaje y ejecuta la animación del estado Showing.

Hide Ejecuta la animación del estado Hiding mientras esconde el marco del personaje.

Speak Produce salida de audio provocando el efecto de ser el personaje el que está hablando.

MoveTo Mueve el personaje a la posición especificada.

GestureAt Provoca que el personaje señale a la posición especificada.

157


9.3.1 IAgentCharacter::GestureAtHRESULT GestureAt( short x, short y, long * pdwReqID )

Ejecuta la animación asociada al estado Gesturing. En este estado el personaje señala al punto de la pantalla especificado, teniendo en cuenta la propia localización del personaje respecto al punto en que señala.

• Devuelve S_OK para indicar que la operación ha tenido éxito. El parámetro de salida, pdwReqID, contiene el identificador de la petición

x


y


pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método GestureAt.

El servidor determina la animación apropiada, basándose en la propia posición actual del personaje, para señalar a la localización especificada.

9.3.2 IAgentCharacter::HideHRESULT Hide( long bFast, long * pdwReqID )

Esconde el personaje.

• Devuelve S_OK para indicar que la operación ha tenido éxito. El parámetro de salida, pdwReqID, contiene el identificador de la petición.

bFast

Bandera de la animación del estado Hiding. Si este parámetro es True, la animación Hiding no se ejecuta antes de que el marco del personaje se esconda; si es False, la animación se ejecuta.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Hide.

El servidor encola la animación asociada con el método Hide en la cola del personaje. Esto permite usar este método para ocultar el personaje después de una secuencia de animaciones. Se puede esconder el personaje inmediatamente si se usa el método Stop antes de llamar al método Hide.

Los personajes escondidos no pueden acceder al canal de audio.

158


9.3.3 IAgentCharacter::InterruptHRESULT Interrupt( long dwReqID, long * pdwReqID )

Interrumpe la animación especificada que había sido requerida anteriormente por otro personaje.


dwReqID

Identificador de la petición que se quiere interrumpir.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Interrupt.

Si se cargan varios personajes, se puede usar este método para sincronizar las animaciones entre ellos. Por ejemplo, si otro personaje está en una animación tipo bucle, este método parará esa animación, para que pueda comenzar la siguiente animación de la cola del personaje interrumpido.

Interrupt detiene la animación solicitada, pero no purga la cola de animaciones del personaje. Hace comenzar la siguiente animación de la cola. Para parar y purgar la cola del personaje, hay que usar el método Stop.

No se puede usar este método para que un personaje se interrumpa a sí mismo, porque el servidor de Microsoft Agent encola el método Interrupt en la cola de animaciones del personaje. Por lo tanto, únicamente se puede usar Interrupt para parar la animación de otro personaje que haya sido cargado.

9.3.4 IAgentCharacter::MoveToHRESULT MoveTo( short x, short y, long lSpeed, long * pdwReqID )

Ejecuta la animación del estado asociado Moving mientras mueve el marco del personaje a la localización especificada.


x

La coordenada x de la nueva posición en pixeles, relativa al origen de la pantalla (esquina superior izquierda). La localización de un personaje está basada en la posición de la esquina superior izquierda del marco de su animación.

y

La coordenada y de la nueva posición en pixeles, relativa al origen de la pantalla (esquina superior izquierda).

lSpeed

159


Este parámetro especifica, en milisegundos, la rapidez del movimiento del marco del personaje. El valor recomendado es 1000. Si se especifica cero (0), el marco se mueve sin ejecutar ninguna animación.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método MoveTo.

9.3.5 IAgentCharacter::PlayHRESULT Play( BSTR bszAnimation, long * pdwReqID )

Ejecuta la animación especificada.


bszAnimation

El nombre de la animación.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Play.

El nombre de las animaciones se define cuando el personaje es compilado con el Editor de Personajes de Microsoft. Antes de ejecutar la animación especificada, el servidor intenta ejecutar la animación Return14 correspondiente a la animación previa (si esa animación tiene una animación Return asignada).

9.3.6 IAgentCharacter::ShowHRESULT Show( long bFast, long * pdwReqID )

Muestra en pantalla al personaje.


bFast

Bandera de la animación del estado Showing. Si este parámetro es True, la animación del estado Showing se ejecuta después de hacer visible al personaje; si es False, la animación no se ejecuta.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Show.

9.3.7 IAgentCharacter::SpeakHRESULT Speak( BSTR bszText, BSTR bszURL, long * pdwReqID )

14 La animación Return está pensada para dar continuidad al movimiento del personaje. Consiste en regresar a la posición de reposo desde una animación específica.

160


Pronuncia en voz alta un texto o ejecuta un fichero de sonido.


bszText

El texto que el personaje ha de pronunciar.

bszURL

La ruta de directorios de un fichero de sonido que contiene la salida hablada. Puede ser un fichero de sonido estándar (.wav) o un fichero de sonido con información lingüística (.lwv).

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Speak.

Para usar este método con un personaje configurado para hablar usando un motor texto a voz (TTS), sólo hay que proporcionar el parámetro bszText. En este parámetro, se puede usar una barra vertical (|) entre caracteres para designar cadenas de texto alternativas. Así, cuando el servidor procese el método, elegirá aleatoriamente un texto u otro.

Si se quiere usar un fichero de sonido como salida de voz del personaje, hay que especificar la localización del fichero en el parámetro bszURL. En este caso, el parámetro bszText especifica las palabras que aparecerán en el globo de texto del personaje. Si el fichero de sonido del parámetro bszURL tiene información lingüística (formato de fichero .LWV), y no se especifica texto, el parámetro bszText utiliza el texto almacenado en el fichero.

El método Speak usa la última animación ejecutada para determinar qué animación se ejecuta mientras habla. Por ejemplo, si se precede al comando Speak con un IAgentCharacter::Play “GestureRight”, el servidor ejecutará GestureRight y luego la animación del estado GestureRight mientras habla. Si la última animación ejecutada no posee animación compatible con el habla, entonces Microsoft Agent ejecuta la animación asignada al estado Speaking.

Si se llama a Speak y, el canal de audio está ocupado, la salida de audio del personaje no podra ser oída, pero el texto será mostrado en el globo de texto.

Hay que fijar el identificador de lenguaje de un personaje (usando IAgentCharacterEx::SetLanguageID) antes de usar el método Speak para asegurar que el texto apropiado se muestra en el globo de texto.

9.3.8 IAgentCharacter::StopHRESULT Stop( long dwReqID )

161


Detiene la animación especificada por el parámetro y la elimina de la cola de animaciones del personaje.


dwReqID

Identificador de la petición que se quiere detener.

9.3.9 IAgentCharacter::StopAll HRESULT Stop( long lType )

Detiene todas las peticiones de animación y las elimina de la cola de animaciones del personaje.

lType

Indica los tipos de peticiones que han de ser detenidas (y eliminadas de la cola del personaje). Los valores admitidos se muestran en la siguiente tabla:

STOP_TYPE_ALL = 0xFFFFFFFF; Detiene todas las y peticiones de animación.

STOP_TYPE_PLAY = 0x01; Detiene todas las peticiones Play.

STOP_TYPE_MOVE = 0x02; Detiene todas las peticiones Move.

STOP_TYPE_SPEAK = 0x04; Detiene todas las peticiones Speak.

STOP_TYPE_PREPARE = 0x08; Detiene todas las peticiones Prepare.

STOP_TYPE_NONQUEUEDPREPARE=0x10 Detiene todas las peticiones Prepare no encoladas.

STOP_TYPE_VISIBLE = 0x20 Detiene todas las peticiones Hide o Show.

9.3.10 IAgentCharacter::WaitHRESULT Wait( long dwReqID, long * pdwReqID )

Retiene la cola de animaciones de un personaje en la animación especificada hasta que otra petición de otro personaje termina.


dwReqID

Identificador de la petición por la que hay que esperar.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Wait.

162


Cuando existe un único personaje, cada petición de animación se ejecuta al terminar de ejecutarse la petición previa; Es decir, se ejecutan secuencialmente. Cuando se quiere secuenciar la interacción entre varios personajes hay que usar el método Wait.

Si se tienen dos personajes, y se quiere que la petición de animación de un personaje espere hasta que la animación del otro personaje termine, hay que llamar al método Wait con el identificador de la petición de la animación del personaje.

9.4 IAgentCharacterEx

IAgentCharacterEx deriva de la interfaz IAgentCharacter. Incluye todos los métodos de IAgentCharacter y proporciona acceso a las siguientes funciones adicionales:

Métodos IAgentCharacterEx Descripción

ShowPopupMenu Muestra el menú emergente del personaje.

Listen Pone al personaje estado de escucha.

SetLanguageID Fija el identificador del idioma del personaje.

GetLanguageID Devuelve el identificador del idioma del personaje

GetTTSModeID Devuelve el identificador de modo del conversor TTS del personaje.

SetTTSModeID Fija el identificador de modo del conversor TTS del personaje.

GetSRModeID Devuelve el identificador de modo del motor de reconocimiento de habla del personaje.

SetSRModeID Fija el motor de reconocimiento de habla.

Think Muestra el texto especificado en un globo de texto cuya forma indica pensamiento.

GetSRStatus Devuelve las condiciones necesarias para soportar entrada de voz.

9.4.1 IAgentCharacterEx::GetLanguageIDHRESULT GetLanguageID( long * plangID )

Obtiene el identificador del idioma fijado para el personaje.


plangID

Dirección de la variable que recibe el identificador del idioma fijado para el personaje.

Una variable tipo long integer especifica el identificador de idioma del personaje. El identificador del idioma (LANGID) para un personaje es una constante de 16 bit definido por Windows, que consiste en un identificador de idioma principal y un identificador de idioma secundario. Los siguientes ejemplos son valores para algunos idiomas:

163


Español 0x0C0A

Inglés (Británico) 0x0809

Inglés (EEUU) 0x0409

Francés 0x040C

Si no se fija el identificador de idioma para un personaje, el lenguaje del personaje será el del actual lenguaje del sistema.

El identificador del idioma determina el idioma para la salida del conversor TTS, el texto del globo de texto, los comandos en el menú emergente del personaje, y el motor de reconocimiento del habla. Para saber si hay disponible un motor de reconocimiento del habla compatible para el idioma del personaje, hay que usar el método IAgentCharacterEx::GetSRModeID.

9.4.2 IAgentCharacterEx::GetSRModeIDHRESULT GetSRModeID( BSTR * pbszModeID )

Obtiene el identificador de modo del motor de reconocimiento del habla fijado para el personaje.


pbszModeID

Dirección de la variable tipo BSTR que recibe el identificador de modo del motor de reconocimiento del habla del personaje.

Este método devuelve el motor fijado para la entrada de habla de un personaje. Si no se fija el indicador de modo del motor de reconocimiento de habla para un personaje, el servidor devuelve el primer motor que iguale el idioma del personaje. Si no hay disponible un motor de reconocimiento del habla que iguale el idioma del personaje, el servidor devolverá una cadena de texto vacía.

Cuando la entrada de habla esté habilitada (en la ventana de Opciones Avanzadas del Personaje), al preguntar por esta propiedad, el motor asociado será cargado (si es que no lo estaba ya), y los servicios de habla comienzan. Es decir, la tecla del estado de escucha está disponible y la ventana emergente del estado de escucha se muestra.

Microsoft Agent requiere que el motor de habla esté basado en el interfaz de habla de Microsoft (Microsoft Speech API). Cualquier motor que soporte ese interfaz puede ser instalado y usado con Agent.

164


9.4.3 IAgentCharacterEx::GetSRStatusHRESULT GetSRStatus( long * plStatus )

Obtiene el estado de las condiciones necesarias para soportar entrada de habla.


plStatus

Dirección de la variable que recibe uno de los siguientes valores indicativos del estado de la entrada de habla:

LISTEN_STATUS_CANLISTEN = 0 Entrada de habla disponible.

LISTEN_STATUS_NOAUDIO = 1 No hay dispositivo de entrada de audio instalado en el sistema.

LISTEN_STATUS_NOTTOPMOST = 2Otro cliente tiene la entrada activa para este personaje.

LISTEN_STATUS_CANTOPENAUDIO = 3 La entrada de audio o el canal de salida están actualmente ocupados, otra aplicación está usando audio.

LISTEN_STATUS_COULDNTINITIALIZESPEECH = 4 Un error no especificado ha ocurrido en el proceso de inicialización del subsistema de reconocimiento de habla.

LISTEN_STATUS_SPEECHDISABLED = 5; El usuario ha deshabilitado la entrada de habla en la Ventana de Opciones Avanzadas de Personajes.

LISTEN_STATUS_ERROR = 6; Un error no especificado ha ocurrido durante la comprobación del estado del audio.

Esta función permite conocer si, con las condiciones actuales, se soporta reconocimiento de entrada de habla, incluyendo estado del dispositivo de audio. Si la aplicación usa el método IAgentCharacterEx::Listen, se puede usar esta función previamente para conocer lo que puede ocurrir. Al llamar a este método también se carga el motor de habla, si todavía no había sido cargado.

9.4.4 IAgentCharacterEx::GetTTSModeIDHRESULT GetTTSModeID( BSTR * pbszModeID )

Obtiene el identificador de modo del conversor TTS fijado para el personaje.


pbszModeID

Dirección de la variable tipo BSTR que recibe el identificador de modo del conversor TTS.

165


Este método devuelve el identificador de modo del conversor texto a voz (TTS) para la salida hablada de un personaje. El identificador de modo de un conversor es una cadena de texto, el GUID, que identifica unívocamente al suministrador del conversor.

Si no se ha fijado el identificador de modo del conversor TTS para el personaje, el servidor devuelve el primer conversor que iguale el idioma del personaje.

9.4.5 IAgentCharacterEx::ListenHRESULT Listen( long bListen )

Conecta o desconecta el modo de escucha (entrada de reconocimiento del habla).


bListen

Bandera del modo de escucha. Si este parámetro es True, el modo de escucha se inicia; si es False, el modo de escucha se termina.

Llamando a este método con True se habilita el modo de escucha (da comienzo el reconocimiento de habla) durante un periodo de tiempo fijo.

Cuando se llama este método, el servidor lanza el evento IAgentNotifySinkEx::ListeningState.

Este método no llama automáticamente a IAgentCharacter::StopAll y ejecuta un estado de animación de escucha como ocurre cuando el usuario presiona la tecla del estado de escucha. Esto posibilita usar el evento IAgentNotifySinkEx::ListeningState para determinar si se quiere parar la animación actual y ejecutar una animación apropiada al modo de escucha. Sin embargo, una vez que se detecta entrada de micrófono, el servidor automáticamente llama al método IAgentCharacter::StopAll y ejecuta la animación del estado de escucha (Hearing).

9.4.6 IAgentCharacterEx::SetLanguageID HRESULT SetLanguageID( long langID )

Fija el identificador del idioma del personaje.


langID

Identificador del idioma fijado para el personaje.

Si no se fija el identificador de idioma para un personaje, y está instalada la DLL de idiomas de Agent, el identificador del idioma del personaje será el del sistema; de otro modo, el idioma del personaje será el inglés americano.

166


9.4.7 IAgentCharacterEx::SetSRModeIDHRESULT SetSRModeID( BSTR bszModeID )

Fija el identificador de modo del motor de reconocimiento de habla de un personaje.


bszModeID

Identificador de modo del motor de reconocimiento de habla de un personaje.

Este método fija el motor de entrada de habla para un personaje. El identificador de modo de un motor de reconocimiento de habla es una cadena de texto, el GUID, que identifica unívocamente al suministrador del conversor.

9.4.8 IAgentCharacterEx::SetTTSModeIDHRESULT SetTTSModeID( BSTR bszModeID )

Fija el identificador de modo del motor texto a voz (TTS) para un personaje.


bszModeID

Identificador de modo del motor de reconocimiento de habla de un personaje.

9.4.9 IAgentCharacterEx::ShowPopupMenuHRESULT ShowPopupMenu( short x, short y )

Muestra el menú emergente del personaje.


x

La coordenada x del menú emergente en pixeles, relativa al origen de la pantalla (esquina superior izquierda).

y

La coordenada x del menú emergente en pixeles, relativa al origen de la pantalla (esquina superior izquierda).

9.4.10 IAgentCharacterEx::ThinkHRESULT Think( BSTR bszText, long * pdwReqID )

Muestra el texto especificado en un globo de texto especial similar al que se usa en los cómics para indicar que el personaje está pensando y no hablando.


167


bszText

El texto que aparecerá en el globo de texto.

pdwReqID

Dirección de la variable que recibe el identificador de la petición de ejecución del método Think.

Igual que el método Speak, el método Think muestra texto en un globo de texto. Pero los globos de texto de ambos métodos son diferentes y además el método Think no produce salida de audio.

9.5 IAgentNotifySink

IAgentNotifySink notifica a sus clientes a través de eventos cuándo ocurren ciertos cambios de estado. Sus funciones están también disponibles a través de la interfaz IAgentNotifySinkEx.

IAgentNotifySink Description

Command Ocurre cuando el servidor procesa un comando definido por el cliente.

VisibleState Ocurre cuando el estado Visible cambia.

Click Ocurre cuando se hace clic sobre un personaje.

DblClick Ocurre cuando se hace doble clic sobre un personaje.

DragStart Ocurre cuando un usuario comienza arrastrar a un personaje.

DragComplete Ocurre cuando un usuario termina de arrastrar a un personaje.

RequestStart Ocurre cuando el servidor comienza a procesar cierta petición (Request).

RequestComplete Ocurre cuando el servidor termina de procesar cierta petición (Request).

Idle Ocurre cuando el servidor manda comenzar o terminar el estado ocioso.

Move Ocurre cuando un personaje ha sido movido.

9.5.1 IAgentNotifySink::ClickHRESULT Click( long dwCharID, short fwKeys, long x, long y )

Notifica a una aplicación cliente cuándo el usuario hace clic sobre el personaje o sobre el icono del personaje en la barra de tareas.

• No devuelve ningún valor.

dwCharID

Identificador del personaje clicado.

fwKeys

168


Parámetro que indica el botón del ratón y estado de alguna tecla modificadora. Este parámetro de salida puede ser una combinación de los siguientes valores:

0x0001 Botón izquierdo

0x0010 Botón del medio

0x0002 Botón derecho

0x0004 Tecla mayúsculas (Shift) presionada

0x0008 Tecla control presionada

0x0020 Tecla Alt presionada

0x1000 Evento ocurrido sobre el icono de la barra de tareas

x


y


Este evento es enviado al cliente con entrada activa del personaje. Si el personaje estaba oculto, es automáticamente mostrado.

9.5.2 IAgentNotifySink::CommandHRESULT Command( long dwCommandID, Iunknown * punkUserInput )

Notifica a la aplicación cliente que un comando de usuario (Command) ha sido seleccionado por el usuario.


dwCommandID

Identificador de la mejor alternativa de comando encontrada.

punkUserInput

Dirección de la interfaz IUnknown para el objeto IAgentUserInput.

Es necesario usar QueryInterface para obtener la interfaz IAgentUserInput.

El servidor notifica al cliente con entrada activa cuándo un usuario elige un comando mediante la voz o seleccionándolo del menú emergente de comandos. El evento ocurre incluso cuando el usuario selecciona uno de los comandos del servidor. En este caso el servidor devuelve un identificador de comando nulo, la puntuación de confianza y el texto de voz devuelto por el motor de habla para esa entrada.

169


9.5.3 IAgentNotifySink::DblClickHRESULT DblClick( long dwCharID, short fwKeys, long x, long y )

Notifica a la aplicación de cliente cuando un usuario hace doble click sobre un personaje.


dwCharID

Identificador del personaje que ha sido doblemente clicado.

fwKeys

Parámetro que indica el botón del ratón y el estado de las teclas modificadoras durante la generación del evento. Los valores posibles son los mismos que en el evento Click.

x


y


9.5.4 IAgentNotifySink::DragCompleteHRESULT DragComplete( long dwCharID, short fwKeys, long x, long y )

Notifica a una aplicación de cliente cuando el usuario termina de arrastrar a un personaje.


dwCharID

Identificador del personaje arrastrado.

fwKeys


x


y


170


9.5.5 IAgentNotifySink::DragStart HRESULT DragStart( long dwCharID, short fwKeys, long x, long y )

Notifica a una aplicación cliente cuando el usuario comienza a arrastrar con el ratón a un personaje.


dwCharID

Identificador del personaje arrastrado.

fwKeys


x


y


9.5.6 IAgentNotifySink::MoveHRESULT Move( long dwCharID, long x, long y, long dwCause )

Notifica a una aplicación de cliente cuando el personaje es movido.


dwCharID

Identificador del personaje que ha sido movido.

fwKeys


x


y


dwCause

171


Causa del movimiento de personaje. El parámetro puede tomar uno de los siguientes valores:

NeverMoved = 0 El personaje no ha sido movido.

UserMoved = 1 El usuario ha arrastrado al personaje.

ProgramMoved = 2 La aplicación cliente movió al personaje.

OtherProgramMoved = 3 Otra aplicación movió el personaje.

SystemMoved = 4 El servidor movió al personaje para mantenerlo en pantalla después de un cambio de resolución de pantalla.

9.5.7 IAgentNotifySink::RequestCompleteHRESULT RequestComplete( long dwRequestID, long hrStatus )

Notifica a una aplicación de cliente cuando una solicitud de animación ha sido completada.


dwRequestID

Identificador de la petición que ha sido completada.

hrStatus

Código de estado. Este parámetro devuelve el código de estado de la petición.

A través del identificador de petición proporcionado por este evento, es posible rastrear cuándo un método encolado se completa. Por ejemplo, los siguientes métodos de la interfaz IAgentCharacter: GestureAt, Hide, Interrupt, MoveTo, Prepare, Play, Show, Speak...

9.5.8 IAgentNotifySink::RequestStartHRESULT RequestStart( long dwRequestID )

Notifica a una aplicación de cliente cuando una petición de animación ha comenzado.


dwRequestID

Identificador de la petición que comienza.

A través del identificador de petición proporcionado por este evento, es posible rastrear cuándo un método encolado comienza a ejecutarse. Por ejemplo los siguientes métodos de la interfaz IAgentCharacter: GestureAt, Hide, Interrupt, MoveTo, Prepare, Play, Show, Speak...

172


9.5.9 IAgentNotifySink::VisibleStateHRESULT VisibleState( long dwCharID, long bVisible, long dwCause )

Notifica a una aplicación cliente cuándo el estado de visibilidad de un personaje cambia.


dwCharID

Identificador del personaje cuyo estado de visibilidad ha cambiado.

bVisible

Bandera de visibilidad. Este valor booleano es igual a True cuando un personaje se hace visible y False cuando el personaje se oculta.

dwCause

Causa del cambio en el estado de visibilidad del personaje. Este parámetro puede tomar uno de los siguientes valores:

NeverShown = 0 El personaje no ha sido nunca mostrado.

UserHid = 1 El usuario ha escondido al personaje desde el icono de la barra de tareas o mediante entrada de voz.

UserShowed = 2 El usuario ha mostrado el personaje.

ProgramHid = 3 El creación cliente ha escondido al personaje.

ProgramShowed = 4 La aplicación ha mostrado al personaje.

OtherProgramHid = 5 Otra aplicación ha escondido al personaje.

OtherProgramShowed = 6 Otra aplicación ha mostrado al personaje.

UserHidViaCharacterMenu = 7 El usuario ha escondido al personaje desde el menú emergente.

UserHidViaTaskbarIcon = UserHid El usuario ha escondido al personaje desde el icono de la barra de tareas o mediante entrada de voz.

9.6 IAgentNotifySinkEx

IAgentNotifySinkEx se deriva de la interfaz IagentNotifySink. Incluye todos los métodos de IAgentNotifySink y proporciona acceso a la siguiente función:

Método IagentNotifySinkEx Descripción

ListeningState Ocurre cuando el estado de escucha del personaje cambia.

173


9.6.1 IAgentNotifySinkEx::ListeningStateHRESULT ListeningState( long dwCharacterID, long bListening, long dwCause )

Notifica a una aplicación de cliente que el modo de escucha ha cambiado.


dwCharacterID

El personaje cuyo modo de escucha ha cambiado.

bListening

Estado del modo de escucha. True indica que el modo de escucha ha comenzado; False, que el modo de escucha ha terminado.

dwCause

Motivo del evento, puede ser uno de los siguientes valores:

LSCOMPLETE_CAUSE_PROGRAMDISABLED = 1 El modo de escucha fue apagado por código del programa.

LSCOMPLETE_CAUSE_PROGRAMTIMEDOUT = 2 TimeOut del modo de escucha encendido por programa.

LSCOMPLETE_CAUSE_USERTIMEDOUT = 3 TimeOut del modo de escucha encendido por Listening Key.

LSCOMPLETE_CAUSE_USERRELEASEDKEY = 4 El modo de escucha fue apagado porque el usuario soltó la Listening key.

LSCOMPLETE_CAUSE_USERUTTERANCEENDED = 5 El modo de escucha fue apagado porque el usuario terminó de hablar.

LSCOMPLETE_CAUSE_CLIENTDEACTIVATED= 6 El modo de escucha fue apagado porque el cliente con entrada activa fue desactivado.

LSCOMPLETE_CAUSE_DEFAULTCHARCHANGE = 7 El modo de escucha fue apagado porque el personaje por defecto ha sido cambiado.

LSCOMPLETE_CAUSE_USERDISABLED = 8 El modo de escucha fue apagado porque el usuario deshabilitó la entrada de habla.

Este evento es enviado a todos los clientes cuando el modo de escucha comienza después de que el usuario presiona la tecla de escucha o cuando su tiempo de era termina, o cuando el cliente con entrada activa llama al método IAgentCharacterEx::Listen.

El evento devuelve valores a los clientes a actualmente tienen este personaje cargado. Todos los otros clientes reciben un carácter NULL.

174

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDABibliografía

175


Bibliografía

Los siguientes libros, artículos, Proyectos Fin de Carrera y Tesis Doctoral han sido utilizados como documentación de consulta y/o referencia en la realización de este PFC. Han sido ordenados por orden alfabético y sus datos se exponen siguiendo el formato recomendado por el IEEE:

176


177

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAPlanos

Planos

Los listados de los programas no se incluyen en esta memoria para evitar un posible uso ilegal de los mismos que pudiera atentar contra el derecho de la propiedad intelectual. No obstante, éstos podrán ser consultados solicitándolos en la biblioteca del Departamento de Ingeniería Electrónica (DIE) de la ETSI de Telecomunicación de la Universidad Politécnica de Madrid, siempre y cuando los fines sean puramente académicos y nunca comerciales.

178

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAPlanos

179

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAPliego de Condiciones

Pliego de condiciones

Condiciones generales

La obra será realizada bajo la dirección técnica de un Ingeniero de Telecomunicación y el número de programadores necesarios.

La ejecución material de la obra se llevará a cabo por el procedimiento de contratación directa. El contratista tiene derecho a obtener, a su costa, copias del pliego de condiciones y del presupuesto. El ingeniero, si el contratista lo solicita, autorizará estas copias con su firma, después de confrontarlas.

Se abonará al contratista la obra que realmente se ejecute, de acuerdo con el proyecto que sirve de base para la contrata.

Todas las modificaciones ordenadas por el ingeniero-director de las obras, con arreglo a sus facultades, o autorizadas por la superioridad, serán realizadas siempre que se ajusten a los conceptos de los pliegos de condiciones y su importe no exceda la cifra total de los presupuestos aprobados.

El contratista, o el organismo correspondiente, quedan obligados a abonar al ingeniero autor del proyecto y director de obra, así como a sus ayudantes, el importe de sus respectivos honorarios facultativos por dirección técnica y administración, con arreglo a las tarifas y honorarios vigentes.

Tanto en las certificaciones de obra como en la liquidación final, se abonarán las obras realizadas por el contratista a los precios de ejecución material que figuran en el presupuesto, por cada unidad de obra.

En el caso excepcional en el que se ejecute algún trabajo no consignado en la contrata, siendo admisible a juicio del ingeniero-director de las obras, se pondrá en conocimiento del organismo correspondiente, proponiendo a la vez la variación de precios estimada por el ingeniero. Cuando se juzgue necesario ejecutar obras que no figuren en el presupuesto de la contrata, se evaluará su importe a los precios asignados a ésta u otras obras análogas.

Si el contratista introduce en el proyecto, con autorización del ingeniero-director de la obra, alguna mejora en su elaboración, no tendrá derecho sino a lo que le correspondería si hubiese efectuado la obra estrictamente contratada.

El ingeniero redactor del proyecto se reserva el derecho de percibir todo ingreso que en concepto de derechos de autor pudiera derivarse de una posterior comercialización, reservándose además el derecho de introducir cuantas modificaciones crea convenientes.

180


Condiciones generales a todos los programas

Estarán realizados en lenguajes estándar.

Se entregarán tres copias de los listados para cada programa o subrutina.

Los programas y subrutinas deberán ir documentados, indicando brevemente su función, entradas y salidas, y cualquier otra información de interés.

Se entregará, junto con los programas, un manual de uso e instalación.

Condiciones generales de prueba

Los programas y subrutinas que se entreguen deberán funcionar sobre un ordenador PC o compatible con microprocesador Pentium III 500 MHz o superior y con, al menos, 128 MBytes de RAM. Se ejecutarán bajo sistema operativo Windows 2000 NT Professional o superior, en entorno local.

Solamente se aceptarán los programas si funcionan correctamente en todas sus partes, rechazándose en caso contrario. Si, por causas debidas al contratista, los programas no funcionaran bajo las condiciones expuestas anteriormente, la empresa contratante se reservará el derecho de rescindir el contrato.

Recursos materiales

Ordenador PC compatible, Pentium III 500 MHz, 128 MBytes de memoria RAM y 2 Gbytes de disco duro.

Tarjeta de sonido Sound Blaster.

Micrófono y altavoces.

Tarjeta de red Ethernet.

Recursos lógicos

Sistema operativo Windows 2000 NT Professional.

Compilador Microsoft Visual C++ 6.

Plataforma de agentes animados Microsoft Agent 2.0.

Office 2000.

181


182

UTILIZACIÓN DE AGENTES ANIMADOS PARA INTERFACES AVANZADAS DE AYUDAPresupuesto

Presupuesto

1 Presupuesto de ejecución material

En la ejecución de este proyecto han participado las siguientes personas:

Un Ingeniero Superior de Telecomunicación, encargado del desarrollo y redacción del proyecto, así como de la obtención e interpretación de los resultados.

Un mecanógrafo, encargado de la escritura del proyecto en un procesador de textos, elaboración de gráficos, etc.

1.1 Relación de salarios

Partimos del sueldo base mensual de cada una de las personas que han intervenido en el proyecto para calcular el sueldo base diario respectivo. A éste habrá que añadir las obligaciones sociales.

Sueldo base mensual

Sueldo base diario Gratificación Sueldo total

diario

Ingeniero Superior de Telecomunicación 1.334,59 44,49 6,07 50,56

Mecanógrafo 632,49 21,08 5,67 26,76

Tabla P-1: Sueldos de las personas que han intervenido en el proyecto (todas las cantidades en euros).

1.2 Relación de obligaciones sociales

CONCEPTO

Vacaciones anuales retribuidas 8,33%

Indemnización por despido 1,60%

Seguro de accidentes 7,00%

Subsidio familiar 2,90%

Subsidio de vejez 1,80%

Abono días festivos 12,00%

Días de enfermedad 0,75%

183


Plus de cargas sociales 4,25%

Otros conceptos 15,00%

TOTAL 53,63%

Tabla P-2: Obligaciones sociales.

1.3 Relación de salarios efectivos totales

Sueldo diario Obligaciones sociales Total/día

Ingeniero Superior de Telecomunicación 50,56 27,11 77,67

Mecanógrafo 26,76 14,35 41,1

Tabla P-3: Salarios efectivos totales (todas las cantidades en euros).

1.4 Coste de la mano de obra

Para calcular el coste de la mano de obra basta con aplicar el número de días trabajado por cada persona por el salario respectivo.

Días Salario(€)/día Total (€)

Ingeniero Superior de Telecomunicación 330 77,67 25.630,7

Mecanógrafo 40 41,1 1.644,13

TOTAL COSTE DE MANO DE OBRA 27.274,83

Tabla P-4: Coste de la mano de obra.

1.5 Coste total de materiales

Para la ejecución de este proyecto se han empleado un ordenador personal tipo PC basado en el microprocesador Pentium III y una impresora Láser HP LaserJet 2100 Series PCL 6-1, para la elaboración de toda la documentación necesaria. También se incluyen los gastos de material fungible y de oficina.

184


Los costes referentes a los materiales utilizados se reflejan en la tabla P-5, y son los siguientes:

Precio (€) Uso (meses) Amortización (años) Total (€)

1 ordenador personal para diseño 1.502,53 12 5 300,51

Compilador Microsoft Visual C++ 420,71 12 5 84.14

Impresora Láser HP LaserJet 2100 780,71 1 5 13,01

Placa de red Ethernet 120,2 - - 120,2

Material fungible y de oficina 120,2 - - 120,2

TOTAL GASTO DE MATERIAL 638,06

Tabla P-5: Coste de materiales.

1.6 Importe total del presupuesto de ejecución material

El presupuesto de ejecución material se calcula basándose en los costes de mano de obra y los costes materiales.

CONCEPTO IMPORTE (€)

COSTE TOTAL DE MATERIALES 638,06

COSTE TOTAL DE MANO DE OBRA 27.274,83

TOTAL PRESUPUESTO DE EJECUCIÓN MATERIAL 27.912,89

Tabla P-6: Presupuesto de ejecución material.

2 Importe de ejecución por contrata

Al importe de ejecución material hay que añadirle los siguientes conceptos:

CONCEPTO IMPORTE (€)

GASTOS GENERALES Y FINANCIEROS (22%) 6.140,83

BENEFICIO INDUSTRIAL (6%) 1.674,77

TOTAL G.G. Y B.I. 7.815,6

185


Resultando:

IMPORTE DE EJECUCIÓN POR CONTRATA 35.728,49

Tabla P-7: Importe de ejecución por contrata.

3 Honorarios facultativos

Este proyecto se encuadra dentro del grupo XII: Aplicaciones de la Electrónica y Aparatos de Telecomunicación. Si se aplican las tarifas correspondientes sobre el importe del presupuesto de ejecución material:

Hasta 30.050,61 (Coef. 1,0 sobre 7%) 2.103,54

Hasta 60.101,21 (Coef. 0,9 sobre 7%) 359,16

TOTAL HONORARIOS FACULTATIVOS (€) 2.462,7

Tabla P-8: Honorarios facultativos (todas las cantidades en €).

Los honorarios que hay que aplicar son los correspondientes tanto por redacción del proyecto como por dirección, por lo que el total de honorarios es:

Honorarios de Ingeniero por redacción 2.462,7

Honorarios de Ingeniero por dirección 2.462,7

TOTAL HONORARIOS 4.925,4

Tabla P-9: Honorarios totales (todas las cantidades en €).

4 Importe total del proyecto

El Importe Total del Proyecto es la suma del Importe de Ejecución por Contrata, los Honorarios de Redacción y los Honorarios de Dirección, al cual habrá que aplicar el 16% de IVA.

EJECUCIÓN POR CONTRATA 35.728,49

HONORARIOS 4.925,4

IMPORTE 40.653,89

IVA (16%) 6.504,62

IMPORTE TOTAL 47.158,51

Tabla P-10: Importe total del proyecto (todas las cantidades en €).

186


El importe total del presente proyecto asciende a la cantidad de CUARENTA Y SIETE MIL CIENTO CINCUENTA Y OCHO euros CON CINCUENTA Y UN céntimos.

EL INGENIERO AUTOR DEL PROYECTO

Fdo.: Jesús Heras Parra.MADRID, OCTUBRE DE 2002

187