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

Niveles de Abstracción de un SI

Núcleo Funcional

Control del Diálogo

Objetos de Interacción

Sistema de Ventanas

Drivers

Control de losdispositivos físicos

Control de losrecursos E/S

Control de losobjetos de interacción

Control del secuen-ciamiento de las acciones del usuario -

Conocimiento del dominio

Incremento en elnivel de abstracción

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

Controldel Diálogo

Componente dePresentació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)

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ónControl delDiálogo

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

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

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

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 inputVista

Controlador

Modelo

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

V

C

V

C

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

Controlador

Modelo

Ejemplo

MVC: Ejemplo Modelo

Circuit

Chip Wire

wireschips

0..* 0..*

MVC: Ejemplo Vistas

GlobalView

LayoutView

ListView

Button

ChipText

WireView

ChipView

View

CompositeView

BasicViewTextItem

0..*0..*

0..*

MVC: Ejemplo Controladores

Controller

ChipController

WireController

LayoutController

TextItemController

ButtonController

ChipTextController

MVC: Ejemplo Configuración de instancias

Circuito

Wire

Chip Chip

GlobalView

LayoutView

ListView

ChipView

ChipView

WireView

ChipText

ChipText

Button

Button

Button

C

C

C

C

CC

C

C

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

Abstracción Presentació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 PC

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 PC

A PC

A PC

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 MVCAbstracción Presentación

Control

Vista

Controlador

Modelo

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 relacionesA P

C

A PC

A PC

A PC

A PC

A PC

A PC

. . . . . . . . . .

Nivel superior:P: presentación globalA: núcleo funcional

C: control global de diálogo

Niveles inferiores: partes básicasP: forma gráfica

A: concepto semánticoC: consistencia, estado local,

intercambio datosNiveles intermedios:Representación de relaciones (composición, consistencia

múltiples vistas), niveles de abstracción

PAC: Ejemplo

A PC

A PC

A PC

A PC

A PC

A PC

A PC

Chip Chip Wire

Lista

Control botones

A PC

A PC

A PC

Botones

Control global

Circuito

Wire

Chip Chip

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

Adaptador del Núcleo Funcional

Núcleo Funcional Toolkit Interacción

Componente de Presentación

OI abstractos

OI reales

Controlador de Diálogo

Agentes PACObjetos de Presentación

Objetos de Interacción

Objetos del Dominio

Objetos del Dominio

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