Construcción de Interfaces a Usuario: Control del Diálogo

Niveles de Abstracción de un SI Núcleo Funcional Control del Diálogo Incremento en el nivel de abstracción Objetos de Interacción Sistema de Ventanas Drivers Conocimiento del dominio Control del secuen- ciamiento de las acciones del usuario - Control de los objetos de interacción Control de los recursos E/S Control de los dispositivos físicos

Controlador del Diálogo Nivel intermedio entre núcleo funcional y los OI Provee: Estructura arquitectónica, posibilitando un desarrollo incremental Reglas de correspondencia y transformaciones entre el núcleo funcional y los OIs Control del comportamiento dinámico de una interfaz

Controlador de Diálogo Esencialmente, es el núcleo central de la interfaz Administra las relaciones entre el núcleo funcional y la presentación (compuesta por OIs) Núcleo Funcional Control del Diálogo Componente de Presentación Protocolo de Comuni- cación con el Núcleo cación con la Compo- nente de Presentación Controlador del Diálogo Sistema Interactivo Componente Interactiva (Interfaz)

Controlador de Diálogo Responsabilidades Mantener correspondencia entre los objetos semánticos y los OIs Relaciones 1:1, 1:N o N:1 Mantener las relaciones entre distintos OIs Mantener una representación dinámica del estado del diálogo entre el núcleo funcional y la presentación Definir protocolos de comunicación: Controlador de Diálogo (CD) - Núcleo Funcional (NF) Adecuado a la forma en que está modelado el NF Controlador de Diálogo (CD) - Presentación (P) Adecuado a la forma de la Presentación Suelen ser dependientes de un toolkit particular

Controlador de Diálogo Características Suele administrar las dependencias del estilo y formas utilizadas en la presentación ( “medio” de la presentación) El NF es independiente del medio utilizado Los OI son dependientes del medio utilizado Pueden requerirse múltiples interacciones del operador para generar un único comando al NF El CD debe recolectar los componentes del comando, y enviarlo al NF cuando el comando está completo Debe mantener la consistencia entre distintas vistas de un mismo concepto semántico

Protocolo entre el CD y el NF Consideraciones en el diseño del protocolo: Nivel de abstracción de los datos transferidos Datos en niveles léxicos (ej. Pixels) o semánticos (ej. Registros) El nivel de abstracción debiera ser definido por el NF Componente que contendrá los datos a intercambiar Datos contenidos en el NF, el CD o compartidos entre ambos Estrategia temporal del intercambio Sincrónica Asincrónica

Organización del software Principales formas de organización: Organización en capas o niveles Utilizada en los primeros SI Descentralización: “sistemas multiagentes” Modelos arquitectónicos Determinan la forma de organizar el software de una aplicación Objetivo: identificar las componentes en las que deben estar localizadas las distintas partes de la funcionalidad Permite diseñar en términos de modularización, reusabilidad, extensibilidad, etc. Algunos modelos arquitectónicos de HCI: Seeheim MVC PAC Arch PAC/Amodeus

Principio de Separación del Diálogo Las decisiones de diseño que afecten solamente a la interfaz deben estar aisladas de aquellas que afecten solamente la estructura de la funcionalidad del sistema

Modelo de Seeheim Resultado del 1er. Workshop sobre Herramientas para Software de Interfaces (Seeheim, Alemania, 1-3/11/83) Los distintos niveles de un SI son tratados como capas físicas Nivel de presentación: agrupa el sistema de ventanas y los OI Nivel de control del diálogo Interfaz con la aplicación Interfaz con la aplicación Presentación Control del Diálogo

Modelo de Seeheim Componente de Presentacion Control del diálogo Presentación externa de la interfaz Genera las imágenes Recibe los eventos de input (‘tokens’) Procesamiento léxico Control del diálogo Procesamiento sintáctico de los ‘tokens’ Debe mantener un estado Interfaz con la aplicación Define la interfaz entre la componente interactiva y el resto del software Provee el feedback semántico para el chequeo de la validez de los inputs

Modelo de Seeheim Basado en un enfoque lingüístico Aspectos semánticos  Núcleo Funcional Aspectos sintácticos  Control del diálogo Aspectos léxicos  Presentación Nociones bien comprendidas por los ingenieros de sistemas Enfoque similar al diseño de compiladores Se intentaba utilizar las ideas sobre la generación automática de compiladores para generar interfaces automáticamente Solamente adecuado para un tratamiento secuencial de las expresiones de input (al igual que los compiladores) No adecuado para interactividad Modelo adecuado para enseñar y/o describir el diseño de IU Utilizado como base para los siguientes modelos Pobre feedback semántico Dependencias entre el diálogo y las otras componentes

Modelo Arch Evolución del modelo de Seeheim Desarrollado en un workshop integrado por desarrolladores de interfaces Intenta solucionar los problemas de dependencias entre componentes del modelo de Seeheim En Seeheim, el reemplazo de un toolkit por otro puede requerir la re-escritura de todo el diálogo Igualmente, existen dependencias entre la aplicación y el diálogo Se proveen dos adaptadores para amortiguar tales dependencias: Adaptador de Presentación o Toolkit Virtual Adaptador del Dominio o Aplicación Virtual Proveen reusabilidad, modificabilidad, portabilidad Absorben los efectos de los cambios en sus vecinos

(Adaptador presentación) Modelo Arch Secuenciamiento tareas, consistencia entre múltiples vistas, correspondencia entre formalismos del NF y la IU Entidades del dominio visibles y manipulables por el operador Interfaz con la Aplicación Aplicación Virtual (Adaptador dominio) Diálogo Toolkit Virtual (Adaptador presentación) Presentación (Toolkit Real) Objetos del dominio Objetos de Presentación Objetos de Interacción OI independientes del toolkit utilizado Correspondencia entre OI virtuales y reales ‘Semantic enhancement’, implementación protocolo NF- CD

Modelo Arch/Slinky La introducción de nuevas capas puede producir mermas en el rendimiento de la aplicación Portabilidad, Modificabilidad vs. Eficiencia “Delegación de conocimiento del dominio” (‘domain-knowledge delegation’) Incluir conocimiento del NF en la IU Reduce tráfico de datos entre componentes Adecuado para aplicaciones distribuidas Modelo Arch/Slinky Las distintas funcionalidades de cada componente pueden “desplazarse”a otras componentes Pueden comprimirse componentes ej. FileSelectionBox, rutina provista por muchos toolkits

Modelos Multiagentes El SI es estructurado como una colección de entidades o agentes especializados que producen y reaccionan ante eventos Los aspectos de presentación, control del diálogo y semántica de la aplicación son separados dentro de cada agente Los distintos modelos difieren en la forma en que es realizada esta separación Cada agente puede encargarse de una parte de la funcionalidad de la interacción, en un nivel de abstracción dado Los agentes reaccionan a determinados fenómenos externos (estímulos), produciendo nuevos estímulos Algunas arquitecturas multiagentes: Modelos: MVC, PAC, ALV, CNUCE Toolkits: Interviews, Aïda

Modelos Multiagentes Agente: sistema completo de procesamiento de información Incluye: Receptores y transmisores de eventos Un estado interno Procesamiento cíclico: Recepción de un evento de input Actualización de su estado interno Puede producir otros eventos Pueden comunicarse directamente con otros agentes (incluyendo al operador)

Modelos Multiagentes Beneficios: Los agentes definen la unidad de modularidad, paralelismo y distribución Puede modificarse el comportamiento de un agente sin afectar al resto del sistema Pueden ejecutarse los agentes en distintos procesadores Apto para groupware Cada thread de la actividad del operador puede tener asociado distintos agentes Un thread demasiado complejo puede ser representado por múltiples agentes cooperantes Fácilmente implementados en términos de lenguajes OO

MVC (Model-View-Controller) Desarrollado por Smalltalk (1980) Idea general: separar la presentación (‘View’), el manejo de las acciones del usuario (‘Controller’) y la semántica de la aplicación (‘Model’) Objetivos: Reutilizar vistas y controladores existentes con distintos modelos Proveer distintas vistas de un mismo modelo Las vistas están altamente relacionadas con los controladores

MVC (Model-View-Controller) Modelo Semántica de la aplicación Vistas Aspectos gráficos Disposición espacial, subvistas, OI compuestos Controlador Interfaz entre los modelos y vistas con los dispositivos de input Vista Modelo Controlador

MVC (Model-View-Controller) Cada par Vista-Controlador tiene un Modelo; un Modelo puede tener varios pares asociados Las vistas y controladores conocen explícitamente a su modelo, pero los modelos no conocen sus vistas Los cambios en los modelos son propagados a sus objetos dependientes (ej. vistas) utilizando un protocolo estandar V C V C Modelo V C

MVC (Model-View-Controller) Ciclo de interacción estandar: 1. El operador manipula un dispositivo de input 2. El controlador notifica al modelo 3. El modelo actualiza su estado 4. El modelo propaga el cambio a sus vistas dependientes 5. Las vistas actualizan la pantalla Las vistas pueden consultar al modelo por información adicional Vista Modelo Controlador

Ejemplo

MVC: Ejemplo Modelo Circuit chips wires 0..* 0..* Chip Wire

MVC: Ejemplo Vistas 0..* 0..* 0..* Button TextItem ChipText BasicView ChipView 0..* View WireView 0..* ListView CompositeView LayoutView GlobalView

MVC: Ejemplo Controladores WireController ChipController Controller LayoutController TextItemController ChipTextController ButtonController

MVC: Ejemplo Configuración de instancias C C ChipView C LayoutView WireView GlobalView ChipView C Circuito ChipText C ListView ChipText Chip Chip C Button Wire C Button C Button C

MVC (Model-View-Controller) Inconvenientes: Las vistas y controladores están altamente relacionados Pueden existir complejidades con: Controladores con sub-controladores Modelos con sub-modelos Vistas con sub-vistas Control entre distintas vistas incluido en el modelo

Model-View Motivado por las dificultades en separar las vistas y controladores en MVC Andrew, InterViews Objetivo principal: soportar múltiples vistas de los mismos datos Requiere solamente cambiar las vistas, para ver los datos diferentemente

PAC (Presentation-Abstraction-Control) Cada agente define 3 aspectos o “facetas”: Presentación: comportamiento perceptible Abstracción: semántica (Núcleo Funcional) Control: Vincula una abstracción con una presentación Controla el comportamiento de la abstracción y la presentación Mantiene un estado local Permite implementar diálogo multithread Administra las relaciones con otros agentes Presentación Abstracción Control

PAC Ciclo de interacción estandar 1. La Presentación recibe un evento del usuario 2. Informa al Control del evento recibido 3. El Control trata el evento recibido 3.1. Si es un feedback léxico, el Control actualiza la Presentación 3.2. Si la Abstracción puede tratar el mensaje, se lo envía para su procesamiento 3.3. Si la Abstracción no lo puede tratar, lo envía al Control del agente padre A P C A P C

PAC Ciclo de interacción estandar 1. El Control recibe un evento de su control padre 2. El Control trata el evento recibido 3.1. Si corresponde, actualiza la Presentación (enviandole un mensaje) 3.2. Si corresponde, propaga el evento a los controles de sus agentes hijos A P C A P C A P C A P C

Diferencias MVC - PAC El modelo de MVC se corresponde con la abstracción PAC La vista y el controlador de MVC se corresponden con la presentación de PAC El control de PAC no tiene correspondencia directa en MVC Abstracción Presentación Control Vista Modelo Controlador

PAC (Presentation-Abstraction-Control) Un SI es estructurado recursivamente como una jerarquía de agentes La jerarquía puede ser utilizada para definir niveles de refinamiento o relaciones Nivel superior: P: presentación global A: núcleo funcional C: control global de diálogo A P C . . . . . . . . . . Niveles intermedios: Representación de relaciones (composición, consistencia múltiples vistas), niveles de abstracción Niveles inferiores: partes básicas P: forma gráfica A: concepto semántico C: consistencia, estado local, intercambio datos

PAC: Ejemplo A P C A P C A P C A P C A P C A P C A P C A P C A P C A P Circuito Wire Chip A P C Control global Control botones A P C A P C A P C A P C A P C A P C Lista Botones A P C A P C A P C Chip Chip Wire

Inconvenientes modelos multiagentes Dificultades para diseñar la estructura de agentes Problemas para obtener portabilidad Es dificil localizar todos los lugares donde son necesarias modificaciones No existen muchos frameworks disponibles comercialmente A excepción de MVC

Modelos mixtos Intentan combinar las ventajas provistas por los modelos basados en capas y los modelos multiagentes Portabilidad de los sistemas basados en capas Extensibilidad de los sistemas multiagentes PAC/Amodeus

PAC/Amodeus Adopta los mismos componentes del modelo Arch El controlador de diálogo es descompuesto en un conjunto de agentes PAC El estado de la interacción es distribuido entre estos agentes

PAC-Amodeus Controlador de Diálogo Agentes PAC Objetos del Dominio Objetos de Presentación Adaptador del Núcleo Funcional Componente de Presentación OI abstractos Objetos del Dominio Objetos de Interacción Núcleo Funcional Toolkit Interacción OI reales

Heurísticas El diseño de una jerarquía de agentes no es sencillo Los implementadores de modelos arquitectónicos suelen proveer un conjunto de heurísticas ej. PAC/Amodeus Modelar una ventana principal como un agente Utilizar un agente para mantener consistencia visual entre múltiples vistas Modelar la paleta de un editor como un agente Modelar el espacio de trabajo de un editor como un agente Modelar un concepto complejo como un agente Introducir un agente para sintetizar acciones distribuidas sobre múltiples agentes Introducir un agente para mantener una relación semántica entre conceptos incluidos en distintas ventanas En general, estas reglas se derivan de la experiencia adquirida en el desarrollo de aplicaciones

Otros servicios provistos Undo / Redo Necesitan mantener una historia de la interacción El ‘undo’ de una acción semántica es posible si el NF provee servicios para ello El ‘undo’ de una acción sintáctica es posible si los OI proveen servicios para ello. La semántica de ‘undo’/’redo’ depende del tamaño máximo de la pila conteniendo la historia

Otros servicios provistos Cut, Copy & Paste Pueden corresponder: A un único SI A varias instancias de un mismo SI A distintos SI Los sistemas de ventanas suelen definir un formato para la transferencia de datos entre aplicaciones Estos datos deben ser convertidos por la aplicación generadora e interpretados por la aplicación recipiente Deben proveerse mecanismos de cheueo y ‘recasting’de datos.

Otros servicios provistos Ayudas Estas facilidades pueden estar disponibles local o globalmente Ayudas dinámicas Requieren un modelo del funcionamiento del SI y del operador Requiere acceder al estado del SI Ayudas estáticas Mas sencillas de implementar Generalmente, no necesitan cálculos