Construccin de Interfaces a Usuario: Control del Dilogo

1
Construcción de Interfaces a Usuario Control del
Diálogo
2
Niveles de Abstracción de un SI
Incremento en el nivel de abstracción
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)

5
Controlador de Diálogo

• Responsabilidades
• Mantener correspondencia entre los objetos
  semánticos y los OIs
• Relaciones 11, 1N o N1
• 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

11
Modelo de Seeheim

• Componente de Presentacion
• 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
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
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 desplazarsea 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

Modelo
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
(No Transcript)
24
Ejemplo
25
MVC Ejemplo

• Modelo

wires
chips
0..
0..
26
MVC Ejemplo

• Vistas

0..
0..
0..
WireView
27
MVC Ejemplo

• Controladores

28
MVC Ejemplo

• Configuración de instancias

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

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

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

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

36
PAC Ejemplo
Control global
Control botones
Lista
Botones
Wire
Chip
Chip
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
Objetos de Presentación
Objetos del Dominio
Objetos de Interacción
Objetos del Dominio
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
  recastingde 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
(No Transcript)