Download Modelos: MVC, PAC

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
Conocimiento
del dominio
Control del secuenciamiento de las
acciones del usuario
Control de los
objetos de
interacción
Control de los
recursos E/S Control de los
dispositivos físicos
Incremento en el
nivel 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)
Protocolo de Comunicación con el Núcleo
Funcional
Núcleo
Funcional
Protocolo de Comunicación con la Componente de Presentación
Control
del Diálogo
Controlador del Diálogo
Componente Interactiva (Interfaz)
Sistema Interactivo
Componente de
Presentación
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
Control del
Diálogo
Presentación
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
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
Entidades del dominio visibles
y manipulables por el operador
Secuenciamiento tareas, consistencia
entre múltiples vistas, correspondencia
entre formalismos del NF y la IU
Diálogo
Objetos del dominio
Aplicación Virtual
(Adaptador dominio)
OI independientes del
toolkit utilizado
Objetos de Presentación
Toolkit Virtual
(Adaptador presentación)
Objetos de
Interacción
Objetos del dominio
Interfaz con
la Aplicación
‘Semantic enhancement’,
implementación protocolo NF- CD
Presentación
(Toolkit Real)
Correspondencia entre
OI virtuales y reales
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” (‘domainknowledge 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


Cada thread de la actividad del operador puede tener
asociado distintos agentes


Apto para groupware
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


Vistas


Semántica de la aplicación
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
Modelo
C
V
C
MVC (Model-View-Controller)

Ciclo de interacción estandar:





El operador manipula un dispositivo de input
El controlador notifica al modelo
El modelo actualiza su estado
El modelo propaga el cambio a sus vistas dependientes
Las vistas actualizan la pantalla
 Las vistas pueden consultar al modelo por información adicional
1.
2.
3.
4.
5.
Vista
Modelo
Controlador
Ejemplo
MVC: Ejemplo

Modelo
chips
Circuit
wires
0..*
Chip
0..*
Wire
MVC: Ejemplo

Button
Vistas
BasicView
TextItem
ChipView
View
WireView
ListView
CompositeView
LayoutView
GlobalView
ChipText
0..*
0..*
0..*
MVC: Ejemplo

Controladores
WireController
ChipController
Controller
LayoutController
TextItemController
ButtonController
ChipTextController
MVC: Ejemplo

Configuración de instancias
C
C
ChipView
LayoutView
GlobalView
C
WireView
ChipView
C
Circuito
ChipText
C
ChipText
C
ListView
Chip
Chip
Button
C
Button
C
Wire
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-AbstractionControl)

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
A P
 3.3. Si la Abstracción no lo puede tratar, lo envía al
C
Control del agente padre
P
A
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
A P
sus agentes hijos
C
P
A
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-AbstractionControl)

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
A
P: presentación global
A: núcleo funcional
C: control global de diálogo
C
P
A
P
A
C
C
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
P
A
P
A
C
P
A
C
P
A
C
PAC: Ejemplo
Circuito
P
A
Control
global
C
Control
botones
P
A
C
Chip
Chip
Wire
P
A
C
P
A
P
A
C
Botones
P
A
C
P
A
C
C
Lista
P
A
C
Chip
P
A
P
A
C
C
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
Objetos del Dominio
Adaptador del
Núcleo Funcional
Objetos de Presentación
Agentes PAC
Componente de
Presentación
OI abstractos
Objetos del
Dominio
Núcleo Funcional
Objetos de
Interacción
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