Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Control del Diálogo.

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

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

2 Construcción de Interfaces a Usuario - ©1999 Contenidos 4 Controlador del Diálogo –Funciones / Características 4 Diálogos en un SI 4 Organización del Software –Principio de Independencia del Diálogo –Modelos en capas Seeheim Arch, Arch/Slinky –Modelos multiagentes MVC PAC –Modelos mixtos PAC/Amodeus 4 Otros servicios a proveer

3 Construcción de Interfaces a Usuario - ©1999 Niveles de Abstracción de un SI Núcleo FuncionalControl del DiálogoObjetos de InteracciónSistema de VentanasDrivers Control de los dispositivos físicos Control de los recursos E/S Control de los objetos de interacción Control del secuen- ciamiento de las acciones del usuario - Conocimiento del dominio Incremento en el nivel de abstracción

4 Construcción de Interfaces a Usuario - ©1999 Controlador del Diálogo 4 Nivel intermedio entre núcleo funcional y los OI 4 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

5 Construcción de Interfaces a Usuario - ©1999 Controlador de Diálogo 4 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 Funcional Protocolo de Comuni- cación con la Compo- nente de Presentación Controlador del Diálogo Sistema Interactivo Componente Interactiva (Interfaz)

6 Construcción de Interfaces a Usuario - ©1999 Controlador de Diálogo 4 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

7 Construcción de Interfaces a Usuario - ©1999 Controlador de Diálogo 4 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

8 Construcción de Interfaces a Usuario - ©1999 Diálogos en un Sistema Interactivo Sistema Interactivo Núcleo Funcional Controlador de Diálogo Componente Presentación Núcleo Funcional Controlador de Diálogo

9 Construcción de Interfaces a Usuario - ©1999 Diálogo Operador - Sistema Interactivo 4 Puede ser conducido por el usuario o por el sistema 4 Cantidades de inputs válidos en un instante dado –1 solo input disponible: el operador es conducido desde una subtarea a otra  Más sencillo de implementar  Puede producir una descomposición de la tarea no natural –Más de 1 input disponible: el operador puede modificar su plan de acción, realizando una de varias tareas posibles  Es posible iniciar varias subtareas y efectuarlas en forma paralela.  El paralelismo puede requerir multiples threads de diálogo en el NF

10 Construcción de Interfaces a Usuario - ©1999 Diálogo entre componentes de un S.I. 4 Control interno: efectuado por el NF –El diálogo está determinado por la funcionalidad de la aplicación –El CD es visto como un servidor de presentaciones 4 Control externo: mantenido en el CD –La interacción es conducida por los eventos del operador –El NF es visto como un servidor semántico –En general, ambos modelos sugieren una secuencialización de la interacción No adecuado para manipulación directa con alto feedback semántico –Las expresiones de input suelen ser tratadas en paralelo con una expresión de output (ej. rubberbanding o dragging)

11 Construcción de Interfaces a Usuario - ©1999 Diálogo entre componentes de un S.I. 4 Control mixto: en algunas situaciones, el control es administrado por el NF y por el CD en otras. –En general, es el más apropiado –Permite que el NF y el CD sean participantes similares en la interacción –Permite el cambio de la localización del control, de acuerdo a la interacción ej. Ambientes para visualización de simulaciones –La descripción de la simulación es conducida por el operador (CD) –La ejecución de la simulación es conducida por el NF

12 Construcción de Interfaces a Usuario - ©1999 Diálogo dentro de la Componente de Presentación 4 Provisión de múltiples OI, disponibles en forma simultánea y manipulables en cualquier orden –Debe ser posible “intercalar” OI. Trabajar sobre un OI, luego manipular otros OI y finalmente volver al OI original –La componente de presentación debe permitir la expresión de las facilidades de multiprocesamiento (‘multithread’) provistas por el NF

13 Construcción de Interfaces a Usuario - ©1999 Protocolo entre el CD y el NF 4 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 intercambip Sincrónica Asincrónica

14 Construcción de Interfaces a Usuario - ©1999 Organización del software 4 Principales formas de organización: –Organización en capas o niveles Utilizada en los primeros SI –Descentralización: “sistemas multiagentes” 4 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 otros....

15 Construcción de Interfaces a Usuario - ©1999 Principio de Separación del Diálogo 4 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

16 Construcción de Interfaces a Usuario - ©1999 Modelo de Seeheim 4 Resultado del 1er. Workshop sobre Herramientas para Software de Interfaces (Seeheim, Alemania, 1-3/11/83) 4 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ónControl del Diálogo

17 Construcción de Interfaces a Usuario - ©1999 Modelo de Seeheim 4 Componente de Presentacion –Presentación externa de la interfaz –Genera las imágenes –Recibe los eventos de input (‘tokens’) –Procesamiento léxico 4 Control del diálogo –Procesamiento sintáctico de los ‘tokens’ –Debe mantener un estado 4 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

18 Construcción de Interfaces a Usuario - ©1999 Modelo de Seeheim 4 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

19 Construcción de Interfaces a Usuario - ©1999 Modelo Arch 4 Evolución del modelo de Seeheim –Desarrollado en un workshop integrado por desarrolladores de interfaces 4 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

20 Construcción de Interfaces a Usuario - ©1999 Modelo Arch 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 Entidades del dominio visibles y manipulables por el operador Secuenciamiento tareas, consistencia entre múltiples vistas, correspondencia entre formalismos del NF y la IU OI independientes del toolkit utilizado Correspondencia entre OI virtuales y reales ‘Semantic enhancement’, implementación protocolo NF- CD

21 Construcción de Interfaces a Usuario - ©1999 Modelo Arch/Slinky 4 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 4 Modelo Arch/Slinky –Las distintas funcionalidades de cada componente pueden “desplazarse”a otras componentes –Pueden comprimirse componentes ej. FileSelectionBox, rutina provista por muchos toolkits

22 Construcción de Interfaces a Usuario - ©1999 Modelos Multiagentes 4 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 4 Algunas arquitecturas multiagentes: Modelos: MVC, PAC, ALV, CNUCE Toolkits: Interviews, Aïda

23 Construcción de Interfaces a Usuario - ©1999 Modelos Multiagentes 4 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)

24 Construcción de Interfaces a Usuario - ©1999 Modelos Multiagentes 4 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

25 Construcción de Interfaces a Usuario - ©1999 MVC (Model-View-Controller) 4 Desarrollado por Smalltalk (1980) 4 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

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

27 Construcción de Interfaces a Usuario - ©1999 MVC (Model-View-Controller) 4 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 Modelo V C V C V C

28 Construcción de Interfaces a Usuario - ©1999 MVC (Model-View-Controller) 4 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 Controlador Modelo

29 Construcción de Interfaces a Usuario - ©1999 Ejemplo

30 Construcción de Interfaces a Usuario - ©1999 MVC: Ejemplo 4 Modelo CircuitChipWire wires chips 0..*

31 Construcción de Interfaces a Usuario - ©1999 MVC: Ejemplo 4 Vistas GlobalViewLayoutViewListViewButtonChipText WireView ChipViewViewCompositeViewBasicViewTextItem 0..*

32 Construcción de Interfaces a Usuario - ©1999 MVC: Ejemplo 4 Controladores ControllerChipControllerWireControllerLayoutControllerTextItemControllerButtonControllerChipTextController

33 Construcción de Interfaces a Usuario - ©1999 MVC: Ejemplo 4 Configuración de instancias CircuitoWireChip GlobalViewLayoutViewListViewChipView WireViewChipText Button C C C C C C C C C

34 Construcción de Interfaces a Usuario - ©1999 MVC (Model-View-Controller) 4 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

35 Construcción de Interfaces a Usuario - ©1999 Model-View 4 Motivado por las dificultades en separar las vistas y controladores en MVC –Andrew, InterViews 4 Objetivo principal: soportar múltiples vistas de los mismos datos –Requiere solamente cambiar las vistas, para ver los datos diferentemente

36 Construcción de Interfaces a Usuario - ©1999 PAC (Presentation-Abstraction- Control) 4 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 Abstracción Presentación Control

37 Construcción de Interfaces a Usuario - ©1999 PAC 4 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

38 Construcción de Interfaces a Usuario - ©1999 PAC 4 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

39 Construcción de Interfaces a Usuario - ©1999 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 Controlador Modelo

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

41 Construcción de Interfaces a Usuario - ©1999 PAC: Ejemplo A P C A P C A P C A P C A P C A P C A P C Chip Wire Lista Control botones A P C A P C A P C Botones Control global Circuito Wire Chip

42 Construcción de Interfaces a Usuario - ©1999 Inconvenientes modelos multiagentes 4 Dificultades para diseñar la estructura de agentes 4 Problemas para obtener portabilidad –Es dificil localizar todos los lugares donde son necesarias modificaciones 4 No existen muchos frameworks disponibles comercialmente –A excepción de MVC

43 Construcción de Interfaces a Usuario - ©1999 Modelos mixtos 4 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

44 Construcción de Interfaces a Usuario - ©1999 PAC/Amodeus 4 Adopta los mismos componentes del modelo Arch 4 El controlador de diálogo es descompuesto en un conjunto de agentes PAC –El estado de la interacción es distribuido entre estos agentes

45 Construcción de Interfaces a Usuario - ©1999 PAC-Amodeus Adaptador del Núcleo Funcional Toolkit Interacción Componente de Presentación OI abstractos OI reales Controlador de Diálogo Agentes PAC Objetos de Presentación Objetos de Interacción Objetos del Dominio Objetos del Dominio

46 Construcción de Interfaces a Usuario - ©1999 Heurísticas 4 El diseño de una jerarquía de agentes no es sencillo 4 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 4 En general, estas reglas se derivan de la experiencia adquirida en el desarrollo de aplicaciones

47 Construcción de Interfaces a Usuario - ©1999 Otros servicios provistos 4 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

48 Construcción de Interfaces a Usuario - ©1999 Otros servicios provistos 4 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.

49 Construcción de Interfaces a Usuario - ©1999 Otros servicios provistos 4 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

50 Construcción de Interfaces a Usuario - ©1999