Página principal

El diseño Última modificación: 02/05/2002 Objetivos 3 Introducción 4


Descargar 266.68 Kb.
Página3/5
Fecha de conversión18.07.2016
Tamaño266.68 Kb.
1   2   3   4   5

TAG

Este es otro tipo de formalismo para representar el conocimiento del usuario. TAG (Task Action Grammar) describe el conocimiento del usuario para realizar una determinada tarea en base a una gramática con características [HAR90]. El conocimiento que posee el usuario del tipo "como puedo hacer..." se puede expresar mediante un esquema que engloba a un conjunto de reglas individuales. Un esquema estará formado por una estructura sintáctica definida a partir de un conjunto de características. Las características (features) son atributos que definen la semántica de la tarea. La tareas que tenga estructuras sintácticas diferentes tendrá un esquema diferente. A partir de esta aproximación, se podrá medir la complejidad del interfaz mediante la identificación de características en la acción de tareas y de su agrupamiento en esquemas. El número de esquemas puede dar una orientación de la consistencia del lenguaje de la interfaz; a menos esquemas, el usuario puede inferir el comportamiento esperado del sistema a partir de un conocimiento parcial. Se parte del hecho que la simplificación del esquema es comprensible por el usuario. De este modo, la consistencia ayuda al aprendizaje, ya que podemos inferir nuevas tareas a partir de las conocidas.

Para abordar la especificación de un interfaz mediante TAG se deben seguir los siguientes pasos:


  • Identificar tareas simples que el usuario puede realizar sin resolución de problemas (sin incluir estructuras de control)

  • Describir las tareas simples en un diccionario (como conjuntos de componentes semánticos), reflejando la categorización de las tareas.

  • Definición de reglas de reescritura que trasladan tareas simples en una especificación de acciones, donde los tokens son etiquetados con características semánticas procedentes del diccionario de tareas simples. Las etiquetas permiten la generalización.

Por ejemplo, podemos utilizar TAG para estudiar la consistencia del conjunto de órdenes de un Sistema Operativo (copy, rename, delete). Para ello, partimos de las descripción gramatical de estas tareas, y analizaremos cómo se pueden agrupar en esquemas:

Tareas simples



Copiar fichero nombre_fichero nombre_fichero

Copiar disco nombre_disco nombre_disco

Renombrar fichero nombre_fichero nombre_fichero

Borrar fichero nombre_fichero

Primeramente, deberemos identificar las características que aparecen en estas tareas y sus posibles valores. En este caso, las características corresponden con el tipo de atributo y sus posibles valores. También deberemos tener en cuenta cuando el objeto fuente y destino es el mismo, ya que en tal caso, se produce un cambio en el objeto (y es una característica a tener en cuenta):

Objeto_antiguo [fichero disco, vacio]

Objeto_nuevo [fichero, disco, vacio]

Produce_cambio [si, no]

Una vez obtenidas las características y sus valores, se deberán reescribir las tareas simples mediante estas características, de modo que definan unívocamente su significado:

Copiar fichero [Obj_antiguo=fichero, Obj_nuevo=fichero, cambio= no]

Copiar disco [Obj_antiguo=disco, Obj_nuevo=disco, cambio= no]

Renombrar fich [Obj_antiguo=fichero, Obj_nuevo=fichero, cambio= si]

Borrar fichero [Obj_antiguo=fichero, Obj_nuevo=vacio, cambio= no]

A partir de estas tareas podríamos obtener un único esquema a partir de tres características que lo definen.

Task [obj_ant, obj_nuevo, cambio] :=

Orden[obj_ant, obj_nuevo, cambio]+param1[Obj_ant]+param2[obj_nuevo]

Cada orden vendría dada por un nombre (de la tarea a realizar) y dos parámetros. Los valores para estos argumentos vendrían dados unívocamente por el valor de las características:

tarea[obj_ant=fichero, obj_nuevo=fichero, cambio=si] := "ren"

tarea[obj_ant=fichero, obj_nuevo=fichero, cambio=no] := "copy"

tarea[obj_ant=disco, obj_nuevo=disco, cambio=no] := "diskcopy"

tarea[obj_ant=fichero, obj_nuevo=vacio, cambio=no] := "delete"

param1[obj_ant=vacio] := NULL

param1[obj_ant =fichero] := drive-id + "nombre_fichero"

param1[obj_ant=disco] := drive-id

param2[obj_nuevo=vacio] := NULL

param2[obj_nuevo =fichero] := drive-id + "nombre_fichero"

param2[obj_nuevo=disco] := drive-id

drive-id := NULL | "A:" | " "B:" | "C:" | ...

TAG no realiza predicciones absolutas de rendimiento. Mas bien, se puede utilizar para generar hipótesis que deben ser probadas experimentalmente.

TAG se ha utilizado para medir la consistencia de lenguajes de órdenes (UNIX, MSDOS), aunque también se puede generalizar para acciones de manipulación directa, ubicación de órdenes en menús, etc.


Consistente

Inconsistente

copy src_file target_file

copy src_file target_file

rename src_file target_file

rename target_file in src_file

delete src_file

make src_file deleted

La evaluación de la consistencia del lenguaje del interfaz de usuario puede ser muy sencillo de estimar con TAG. Así por ejemplo, podríamos detectar rápidamente inconsistencias en el lenguaje de órdenes como en este ejemplo, donde las órdenes no poseen la misma estructura. El esquema tiende a ser menos consistente conforme aumenten los esquemas. Como consecuencia, el número total de reglas no es importante, sólo el numero de esquemas.

La consistencia está muy relacionada con la facilidad de aprendizaje. Podríamos estimar que existe una relación directa entre el tiempo de aprendizaje necesario y el número de esquemas que aparecen del lenguaje.

UAN

Las técnicas basadas en gramáticas no resultan adecuadas para la descripción de la interacción en interfaces gráficas de usuario basadas en el paradigma de manipulación directa ya que no permiten describir la realimentación visual (feedback) del sistema. A esto se une la dificultad de especificar tareas basadas en el arrastre de iconos ya que su semántica depende del lugar donde se suelte. En este sentido, UAN (User Action Notation) es una notación centrada en el usuario para descripción de tareas. Su principal característica es la descripción física de las acciones a realizar en el proceso de interacción [HAR95].

Una especificación en UAN se realiza mediante una tabla dividida en 3 columnas describiendo las acciones de usuario, la realimentación de la interfaz y el estado del sistema tras la acción. Las acciones de usuario y la realimentación poseen una notación donde explícitamente se designa la manipulación que se realiza sobre los objetos de la interfaz. Así por ejemplo, las acciones Mv y M^ denotan el efecto de pulsar y soltar el botón del ratón, ~[fichero] representa el movimiento del ratón en el contexto del objeto fichero mientras que fichero > ~ significa que el objeto fichero se está arrastrando. Del mismo modo podemos especificar la respuesta del sistema (feedback) para cada acción tales como la una selección en vídeo inverso de un icono (fichero!), vídeo normal (fichero-!), o un parpadeo (fichero!!). La siguiente descripción especifica la tarea de borrar un fichero mediante técnicas de arrastre.





UAN

Realimentación

Estado

1)

~[fich] Mv

fich!, forall(fich!): fich-!

Selección = fich

2)

~[x,y]*

outline(fich) > ~




3)

~[papelera]

outline(fich) > ~, palelera!




4)

M^

Borrar(fich), papelera!!

Selección = null

Esta especificación nos permite especificar la tarea de arrastrar un fichero a la papelera mediante el proceso que se muestra gráficamente en la Figura 7.



Figura 7 Manipulación directa descrita mediante UAN



ConcurTaskTrees (CTT)

CTT es una notación desarrollada por Fabio Paternò [PAT00] cuyo principal finalidad es la de poder representar las relaciones temporales existentes entre las actividades y usuarios que son necesarios para llevar a cabo en las tareas. En concreto, esta notación es especialmente útil para aplicaciones CSCW (ver capítulo ‘Trabajo cooperativo con ordenador’).

Una de las principales ventajas de esta notación es su facilidad de uso, lo que hace que sea aplicable a proyectos reales con aplicaciones de un tamaño medio–largo y que con llevan especificaciones de cierta complejidad. La notación genera una representación gráfica en forma de árbol de la descomposición jerárquica de las tareas existentes en el sistema. Se permite la utilización de un conjunto de operadores, sacados de la notación de LOTOS, para describir las relaciones temporales entre tareas (secuencialidad, concurrencia, recursión, iteración...)

Podemos reutilizar partes de especificación para la creación de “árboles de tareas concurrentes” e identificarlo como un patrón de tarea. Podemos identificar 4 categorías de tareas en función del actor que la llevará a cabo.





Tareas del usuario. Tareas realizadas completamente por el usuario, son tareas cognitivas o físicas que no interactúan con el sistema. Describen procesos realizados por el usuario usando la información que recibe del entorno (por ejemplo seleccionar dentro de un conjunto de información la que se necesita en un instante determinado para la realización de otra tarea).



Tareas de la aplicación. Tareas realizadas por la aplicación y activadas realizadas por la propia aplicación. Pueden obtener información interna del sistema o producir información hacia el usuario. Como ejemplo podemos ver una tarea que presente los resultados obtenidos de una consulta a una base de datos.




Tareas de interacción. Son tareas que realiza el usuario interactuando con la aplicación por medio de alguna técnica de interacción. Un ejemplo puede ser seleccionar un elemento de una lista desplegable.




Tareas Abstractas . Tareas que requieren acciones complejas y que por ello no es fácil decidir donde se van a realizar exactamente. Son tareas que van a ser descompuestas en un conjunto de nuevas subtareas.

Para la descripción se utilizan además una serie de operadores temporales que facilitan la descripción de las relaciones temporales existentes entre tareas. Estos operadores se han obtenido como una extensión de los operadores existentes en LOTOS [EIJ89]. El uso de estos operadores facilita la descripción de comportamientos complejos. Los operadores temporales que podemos usar son:

T1 ||| T2. Entrelazado (Concurrencia independiente). Las acciones de las dos tareas pueden realizarse en cualquier orden.

T1 |[]| T2. Sincronización (Concurrencia con intercambio de Información). Las dos tareas tiene que sincronizarse en alguna de sus acciones para intercambiar información.

T1 >> T2. Activar (enabling). Cuando termina la T1 se activa la T2. Las dos tareas se realizan deforma secuencial.

T1 []>> T2. Activar con paso de información. Cuando termina T1 genera algún valor que se pasa a T2 antes de ser activada.

T1 [] T2. Elección. Selección alternativa entre dos tareas. Una vez que se esta realizando una de ellas la otra no esta disponible al menos hasta que termine la que esta activa.

T1 [> T2. Desactivación. Cuando se da la primera acción de T2, la tarea T1 se desactiva.

T1 [][> T2. Desactivación con paso de información. Igual que la anterior pero pasando información de una tarea a la otra.

T1*. Iteración. La tarea T1 se realiza de forma repetitiva. Se estará realizando hasta que otra tarea la desactive.

T1(n). Iteración finita. La tarea T1 puede darse n veces. Se utiliza cuando el diseñador conoce cuantas veces tiene que realizarse la tarea.

[T1]. Tarea opcional. No es obligatorio que se realice la tarea. Cuando describimos las subtareas existente en la tarea de rellenar un formulario algunas de las subtareas pueden ser opcionales (las de los campos que sean opcionales).

A la descripción jerárquica de las tareas se le añade la descripción de los objetos que son manipulados por las distintas tareas. Estos objetos pueden clasificarse en dos grupos:



  • Objetos perceptibles. Son objetos gráficos que sirven para presentar información al usuario (ventanas, tablas, gráficos...) o elementos sobre los que el usuario puede interactuar (menús, iconos...).

  • Objetos de aplicación. Elementos que pertenecen al dominio de la aplicación. La información que almacenan estos objetos tiene que ser mapeada a alguno de los otros para poder ser percibida por el usuario.

Cada objeto puede ser manipulado por mas de una tarea. Como ejemplo de especificación utilizando los ConcurTaskTrees podemos ver una parte de una aplicación para acceder a información sobre un museo. En la Figura 8 se muestra el modo de introducir la información por parte del usuario sobre el tipo de artista que está buscando y el sistema le presenta la información asociada a el.

Figura 8 Tarea de acceso a un museo mediante CTT

Se comienza con la tarea “Acceso_Museo_Virtual” que puede ser interrumpida en cualquier momento ([>) por la tarea “Cerrar”. En un siguiente nivel podemos ver la tarea de interacción “Selecc_Tipo_Arte” con la que se describe la selección del tipo de arte sobre el que se requiere información, seguido (>>) por la selección del periodo histórico en el que esta encuadrada la obra del artista. La siguiente tarea a realizar es el acceso a la información del artista para ello se ha obtenido información de las tareas anteriores ( []>> operador activación con paso de información). Algunas de estas tareas se van a descomponer en nuevas tareas de manera jerárquica. Así la tarea “Selecc_adicional” permite seleccionar un artista mediante una lista alfabética o mediante una lista ordenada por periodos históricos.

La descripción de tareas cooperativas consiste en tareas que requieren de la participación de más de un usuario para poder llevarla a cabo. Esta descripción se puede realizar creando un árbol donde aparecerán las tareas cooperativas, que se denotarán con un identificador especial. Por ejemplo, una solicitud de información se podría modelar del siguiente modo:





Figura 9 Tarea cooperativa con CTT

  1. Modelos arquitectónicos

Los modelos arquitectónicos son una alternativa (en algunos casos complementaria) para la representación de sistemas interactivos. En este caso, se pretende obtener un modelo del sistema a desarrollar, centrándose en los aspectos computacionales básicos en los que debe estar basado.

Los primeros modelos que se proponen en este sentido son para describir el sistema interactivo en su conjunto recogiendo sus características esenciales. Si bien los primeros modelos como Seeheim o ARCH se centraban en aspectos funcionales, las últimas propuestas definen una arquitectura modular basada en componentes como MVC o PAC. También podemos encontrar propuestas encaminadas hacia un diseño basado en modelos concretos del sistema con herramientas para su obtención automática como puede ser MOBI–D, HUMANOID, etc. (ver capítulo ‘Herramientas’).

Los aspectos más relevantes de estas propuestas se centran en la modelización de los componentes interactivos (estructura) y mecanismo de interacción (diálogo).

Modelos de componentes interactivos

Los modelos basados en componentes realizan la descripción del sistema como una colección de interadores, elementos básicos que encapsulan interacciones elementales con las que se pueden construir interacciones más complejas.Estos modelos definen las características de los objetos con los que interactúa el usuario (como listas, deslizadores, ventanas, etc.). El modelo conceptual debe reflejar los aspectos relevantes del cualquier componente interactivo (apariencia, eventos, comunicación, etc.). Normalmente esta arquitectura es modular por lo que permite la composición de componentes para crear sistemas más complejos.

Uno de los modelos que más se ha utilizado para la especificación de sistemas interactivos es el denominado interador (de York) [DUK95]. Un interador (interactor) consiste en un estado y un conjunto de acciones que puede percibir e invocar el entorno a través de una interfaz bien definido. Esta definición recoge los elementos esenciales de cualquier elemento interactivo (su estado actual, visualización y eventos para su manipulación. Una parte importante de esta interfaz es la representación gráfica del componente (presentación), que es perceptible por el usuario del sistema. Bajo este modelo, podemos describir elementos interadores abstractos, que posteriormente se plasmará en los lenguajes de especifi­cación.

El concepto de interador ha sido utilizado ampliamente para construir metodologías de diseño de sistema interactivos. La mayor diferencia entre ellas es el lenguaje de especificación utilizado, Z, Lotos, álgebra de procesos, etc.



Figura 10 Modelo de interador de York

Podemos realizar una descripción más detallada de un interador utilizando para ello conceptos que aparecen en los sistemas concurrentes. Así, un interador es un modelo abstracto basado en procesos, canales de comunica­ción y señales de control que definen un componente interactivo con capacidad de representación gráfica y modificación dinámica. Su estructura favorece la interconexión de interadores para realizar modelos de interacción complejos.

En el siguiente esquema se detallan los procesos que definen su funcionalidad, así como las comunicaciones entre los mismos. La idea que se recoge bajo el paradigma del interador es la de representar un componente activo que posee una apariencia gráfica y una medida que representa el valor actual del interador (o estado). Este valor puede modificar la apariencia del interador, así como externamente podemos variar la forma de obtención de la medida. Podemos sincronizar los distintos procesos mediante señales de control.

Un interador se puede describir mediante cuatro procesos. Collection proporciona una descripción de alto nivel de la apariencia gráfica del objeto. Feedback se encarga de producir la apariencia externa del objeto. Measure obtiene un dato de un nivel inferior, y Control, se encarga de generar una nueva medida para el nivel superior. Las entradas y salidas del interador se definen por medio de canales de comunicación: im, oc, od y eo. La sincroniza­ción se realiza mediante dos señales de control: it y ot.





Figura 11 Esquema de un interador

Podemos trasladar el concepto de interador a diferentes lenguajes de especificación. La definición formal de un interador mediante LOTOS [EIJ89, FAC92] es la siguiente:



Specification Interactor [ot, oc, od, eo, im, it] : noexit

Behaviour

Hide me, oc, cf, md, in

((COLLECTION [ot, oc, cf, cm] | [cf]) |

(FEEDBACK [cf, me, eo]) | [cm, me]) |

(MEASURE [im, it, cm, me, md] | [md]) |

(CONTROL [od ,md]))



Where

Process COLLECTION [ot,oc,cf,cm] : noexit :=

oc; COLLECTION [ot, oc, cf, cm]

[] oc; cm; cf; COLLECTION [ot, oc, cf, cm]

endproc

Process FEEDBACK [cf, me, eo] : noexit :=



cf; me; eo; FEEDBACK [cf, me, eo]

[] me; eo; FEEDBACK [cf, me, eo]

endproc

Process MEASURE [im, it, cm, me, md] : noexit :=



cm; me; MEASURE [im, it, cm, me, md]

[] im; me; MEASURE [im, it, cm, me, md]

[] it; md; MEASURE [im, it, cm, me, md]

endproc


Process CONTROL [od, md] : noexit :=

md; od; CONTROL [od, md]

endproc

endspec


En la especificación se describen las distintas sincronizaciones que se deben garantizar sobre los procesos que conforman la estructura del interador. Así, por ejemplo, el proceso feedback se encarga de producir su apariencia gráfica producto de una modificación de la medida (me) o bien de un cambio de apariencia (cf). Podemos asociar a cada canal de comunicación información acerca del tipo de dato que transporta. Por ejemplo el canal de comunicación eo definirá sus datos de tipo gráfico: eo?p : Picture, especificado en ACT ONE. Una de las ventajas que tiene LOTOS (y en general todos los métodos basados en álgebra de procesos) es que explicitan todas las sincronizaciones que aparecen en un sistema interactivo.

Se han desarrollado metodologías para diseñar sistemas interactivos utilizando los interadores en las que se describen las posibles formas de interconectarlos para describir interacciones complejas.

En la siguiente imagen podemos ver como se interconectarían tres interadores para describir parte de un sistema en el que se van a utilizan iconos para representar objetos como ficheros, directorios y unidades de disco. El usuario puede manipular los iconos por medio del ratón y puede modificar el estado de los iconos usando también entradas de un menú.

Se pueden utilizar otros formalismos para la descripción de interadores como por ejemplo la lógica temporal. En [DUK95] se realiza una combinación de un modelo de interador con lógica. Los axiomas se especifican en lógica modal de acciones (MAL), de forma que, junto a los predicados basados en lógica de primer orden, se extiende con un conjunto de operadores modales, que controlan las acciones que se pueden provocar en el sistema. MAL incluye el concepto de agentes (humanos y ordenador) y las responsabilidades mutuas entre ellos. Los operadores usuales son el permiso (per) y la obligación (obl) bajo un paradigma deontológico.


1   2   3   4   5


La base de datos está protegida por derechos de autor ©espanito.com 2016
enviar mensaje