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

Presentación del tema: "Construcción de Interfaces a Usuario: Control del Diálogo"— Transcripción de la presentación:

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

2 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

3 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

4 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)

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 (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

15 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

16 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

17 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)

18 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

19 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

20 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

21 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

22 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

23

24 Ejemplo

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

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

27 MVC: Ejemplo Controladores WireController ChipController Controller
LayoutController TextItemController ChipTextController ButtonController

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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

40 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

41 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

42 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

43 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.

44 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

45