Análise e Modelagem de Tarefas
Marco A. A. Winckler1, Marcelo Soares Pimenta2
IHC2004 (Tutorial)*
1
2
LIIHS-IRIT (Université Paul Sabatier, Toulouse 3), 118 route de Narbonne,
31062 Toulouse CEDEX 4, France
Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)
Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brasil
[email protected] ,[email protected]
Resumo. O objetivo geral deste tutorial é apresentar aos participantes os
conceitos fundamentais de Análise e Modelagem de Tarefas. Em particular,
pretende-se: i) apresentar fundamentos de Análise de Tarefas e Modelagem de
Tarefas; ii) apresentar alguns modelos de tarefas existentes; pretende-se em
particular demonstrar o uso da notação CTT (Concurrent Task Tree) e do
ambiente CTTE (CTT Environment), um dos ambientes mais difundidos e
utilizados na atualidade para modelagem de tarefas; e iii) discutir os possíveis
usos de modelos de tarefa em algumas etapas do ciclo de desenvolvimento de
uma aplicação interativa. Estudos de casos reais serão preferencialmente
utilizados para exemplificar os conceitos apresentados. Mais do que ter a
pretensão de ser um tutorial exaustivo, nossa intenção é dar uma visão
panorâmica sobre o assunto
PALAVRAS-CHAVE: Interação Homem-Computador, Modelos de Tarefa,
Análise de tarefa, Modelo CTT e Ambiente CTTE, Usos de Modelos de tarefa.
1. Introdução
Hoje há um consenso entre os desenvolvedores de software de que a qualidade do
desempenho do usuário no uso de um sistema interativo está ligada à usabilidade, um
critério de qualidade associado ao componente conhecido como Interface com o
Usuário (IU) deste sistema.
Sistemas computadorizados são projetados para auxiliar as pessoas a executarem
tarefas. Logo, tarefas deveriam ser de interesse central para os desenvolvedores de
software [Johnson, 1992]. De fato, diversos autores da comunidade IHC (Interação
Homem-Computador) convergem para a idéia central de que para projetar sistemas com
maior usabilidade devemos compreender melhor as tarefas executadas pelas pessoas de
modo a aplicar nosso entendimento das tarefas no desenvolvimento de aplicações
[Preece 02, Bodart 94, Diaper 89, Johnson 92].
*
Este material de apoio foi confeccionado como complemento ao material (slides, software, etc) usado
pelos ministrantes durante o tutorial.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
A principal meta dos enfoques de projeto de IHC é aumentar a qualidade da
interface com o usuário produzindo sistemas interativos não só funcionais e confiáveis
mas também usáveis. Os enfoques de projeto baseados em modelos (model-based)
permitem representar várias informações da interface e de seu design em um alto nível
de abstração. Isto permite várias vantagens como acoplamento a um enfoque
metodológico de concepção, rastreabilidade e reuso de modelos, geração de (partes de )
interfaces a partir destes modelos, e melhor reflexão sobre as decisões e exploração de
alternativas do design. Entre os modelos comumente presentes nestes enfoques há
modelos de usuário, diálogo, apresentação, domínio, contexto, plataforma tecnológica e
tarefas para citar apenas alguns. Em particular, o uso de Análise de tarefas e Modelos de
Tarefas visa um melhor entendimento de propriedades das tarefas realizadas pelos
usuários em suas atividades e a aplicação deste entendimento no processo de
construção da interface.
O objetivo geral deste tutorial é apresentar aos participantes os conceitos
fundamentais de Análise e Modelagem de Tarefas. Em particular, pretende-se: i)
apresentar fundamentos de Análise de Tarefas e Modelagem de Tarefas; ii) apresentar
alguns modelos de tarefas existentes; pretende-se em particular demonstrar o uso da
notação CTT (Concurrent Task Tree) e do ambiente CTTE (CTT Environment), um dos
ambientes mais difundidos e utilizados na atualidade para modelagem de tarefas; e iii)
discutir os possíveis usos de modelos de tarefa em algumas etapas do ciclo de
desenvolvimento de uma aplicação interativa. Estudos de casos reais serão
preferencialmente utilizados para exemplificar os conceitos apresentados.
Este tutorial está estruturado da seguinte forma. Após esta introdução, a seção 2
estabelece algumas definições de tarefa, análise de tarefa e modelos de tarefa. As
seções 3 e 4 apresentam respectivamente uma introdução sobre análise de tarefa e
modelagem de tarefas. A seção 5 contém uma descrição mais detalhada da notação CTT
(Concurrent Task Tree) e do ambiente CTTE (CTT Environment) . Na seção 6
discutem-se possíveis usos de modelos de tarefas no ciclo de desenvolvimento de
sistemas interativos.
2. Definições
Inicialmente, é preciso considerar a significação do termo “tarefa” que pode
assumir uma interpretação diferente segundo vários autores [Draper 85] [Benyon 92]
[Storrs 95] [Bodart 94], [Preece 2002]. A existência de várias definições de tarefa
implica na existência de diferentes métodos para Análise de tarefa e de diferentes
modelos de tarefa para representar seus resultados segundo estas diferentes
perspectivas. Neste tutorial adotamos a definição de [Storrs 95], primeiramente por que
ela explicita a importante relação entre ações, objetivos e contextos, mas também por
que ela foi formulada para unificar a terminologia sobre o assunto.
“Uma tarefa é um objetivo associado a um conjunto ordenados de ações que podem satisfazer tal
objetivo nos contextos apropriados” [Storrs 95]1
Assim, embora seja aparentemente similar a conceitos como “função” ou
“processo”, o termo “tarefa” incorpora uma ênfase intencional (relacionada a intenção,
objetivo) da perspectiva do usuário (o quê o usuário quer fazer). Um objetivo pode ser
1
Do original inglês: ‘A task is a goal together with the ordered sets of tasks and actions that would
satisfy it in the appropriate contexts.’
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
definido como um estado (de uma situação ou de um sistema) que o usuário deseja
alcançar. Genericamente, então, o conjunto de ações são os procedimentos que o
usuário deve realizar para alcançar este estado.
A Análise de Tarefa (AT) emergiu da Ergonomia como um método empírico que
permite descrever e analisar como as pessoas realizam suas atividades.
“Análise de Tarefa (AT) é o termo genérico para um conjunto de métodos para descrever as tarefas das
pessoas visando entender melhor os procedimentos para sua realização.[UsabGlossary]
O enfoque básico da AT é descrever a tarefa como tendo um objetivo determinado
e um conjunto de passos envolvidos na sua realização. O nível de detalhe desta
descrição é determinado pelas intenções da AT. A prática usual da Ergonomia adota AT
basicamente para entender as tarefas de um ambiente de trabalho de forma a ter
informações para discutir causas e soluções dos problemas encontrados na sua
realização e possivelmente determinar quais são as necessidades de treinamento. Logo
ficou evidente a possibilidade de usá-la para prover informações para a concepção de
suporte computadorizado a estas tarefas. É com esta intenção que a comunidade IHC se
interessa primordialmente por AT.
Uma melhor compreensão de tarefas pode auxiliar a delimitar um problema
coletando informações de modo sistemático sobre um problema, organizar as
informações coletadas, fazer predições de tempo de execução de tarefas, prevenir erros
(identificando procedimentos difíceis e/ou confusos), auxiliar a identificar as fontes de
problemas e gerar hipóteses para solucioná-los. Esta diversidade de intenções tem
motivado um grande número de métodos e técnicas de análise de tarefa sendo o
denominador comum entre elas a descrição de tarefas em termos de unidades de
atividade identificáveis.
A análise da tarefa em um domínio específico pode produzir uma descrição
explícita de tarefas chamada Modelo da Tarefa. Muitos modelos da tarefa são usados
para representar os resultados da análise de tarefa, cada modelo enfatizando uma
perspectiva.
“Modelo de Tarefa (MT)é uma descrição lógica das atividades a serem executadas para alcançar os
objetivos do usuário.”[Paternó 2001]
Aqui, estamos interessados com a descrição em que objetivos e as atividades para
alcançá-los são explicitamente definidos, para permitir um entendimento mais detalhado
dos passos e dos relacionamentos entre eles. Esta definição explícita do objetivo permite
refletir sobre os procedimentos para que ele possa ser mais eficientemente alcançado.
Muitas vezes, isto permite analisar, criticar e re-elaborar estes procedimentos,
aumentando sua simplicidade, eficácia e usabilidade. Uma boa referência sobre o uso de
modelo de tarefas (MT) no ciclo de desenvolvimento de sistemas interativos é
[Paternó2001].
Geralmente, um MT descreve certos conceitos relacionados de forma a representar
aspectos relevantes das tarefas e dos usuários. Alguns conceitos e relacionamentos são
comuns e presentes em quase todos tipos de MT, enquanto outros são especificamente
propostos e usados em um modelo em particular.
Os conceitos e relacionamentos mais comuns de MT são:
• Decomposição da tarefa, onde uma tarefa é tipicamente descrita de maneira
hierárquica: o nível mais alto contém a tarefa principal sucessivamente dividida em
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
•
subtarefas menores recursivamente até que, nos níveis mais baixos (chamado
também de nível articulatório) são descritas ações físicas que não podem mais ser
decompostas (tais ações são tipicamente associadas com a interação sobre um
dispositivo);
Relacionamentos causais/temporais, que descrevem o fluxo da tarefa, indicando a
ordem em que as subtarefas são executadas, geralmente através de construtores
típicos (seqüência , simultaneidade, entrelaçamento, etc);
Além destes, há outros elementos que descrevem objetos (manipulados pelas
tarefas), papéis e atores (responsáveis pelas tarefas), restrições (p.ex. pré- e póscondições) e propriedades (freqüência de realização, prioridade, etc.) associadas às
tarefas. Mais detalhes sobre todos estes elementos estão presentes em [Welie98], [Balbo
2004] e [Limbourg 2001]. Outros trabalhos envolvem conceitos mais avançados de MT
tais como padrões de tarefas (task patterns) [Breedvelt 97] [Paternó 2001], modelos de
tarefa cooperativos [van der Veer 96] e templates de interação [Paquette 2004].
3. Análise de tarefa
O uso da Análise de tarefas (AT) começou na Ergonomia num esforço de descrever
os comportamentos elementares envolvidos na execução de uma atividade de trabalho.
Desta forma, AT era essencial para a Análise do Trabalho (Work Analysis): a expressão
“conhecer o trabalho para modificá-lo” resume sua motivação. Uma excelente descrição
sobre Análise (Ergonômica) do Trabalho é [Cybis 1996]. Logo surgiram diferentes
métodos de AT, muitos recebendo influência da Psicologia Cognitiva, e que são
distinguidos basicamente pela forma de coletar , classificar e interpretar os dados sobre
a realização de tarefas em situações de trabalho.
AT é um processo interativo e iterativo, com períodos alternados de coleta,
classificação e de interpretação de dados. Várias famílias de métodos de AT existem e
entre as principais estão a Análise Hierárquica de Tarefas – abreviada AHT
(Hierarchical Task Analysis – HTA), e a Análise Cognitiva de tarefas (Cognitive Task
Analysis).
Figura 1 – Exemplo de AHT aplicada à tarefa “preparar chá” (make tea)
AHT é a mais comumente utilizada, decompondo uma tarefa de modo top-down
para formar uma hierarquia de subtarefas que por sua vez podem também ser
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
decompostas sucessivamente. Em geral, sugere-se que a decomposição acabe quando
for atingido um nível baixo de descrição em termos de ações elementares nãodecomponíveis (em IHC, ações elementares são movimentos e cliques de mouse,
pressionamento de teclas, etc). A figura 1 mostra um exemplo de uso de AHT.
Claramente, a família de AHT está orientada a uma visão mais procedural da
realização de uma tarefa de modo que a estrutura hierárquica corresponde a um plano
para realização da tarefa.
A Análise Cognitiva de tarefas por sua vez interessa-se mais por princípios
psicológicos ou cognitivos relacionados à tarefa. Assim, investiga o conhecimento ou
habilidade necessários para a realização da tarefa e por isto se concentra mais na
análise (e possivelmente na predição) da performance do usuário e as razões de sua
variabilidade.
Os resultados da AT nem sempre são documentados, ou seja, nem sempre AT
produz um MT ou uma representação explícita das tarefas analisadas. No entanto, em
IHC a modelagem explícita de tarefas é fundamental para o processo de concepção e
avaliação de sistemas interativos. Há vários autores que defendem o uso de MT mas não
informam como é obtido. Talvez esta seja uma das razões para que a penetração da AT
no mercado seja relativamente reduzida, não só no âmbito nacional mas também
internacionalmente (Diaper 2001).
Embora haja várias formas de realizar Análise de tarefa (AT), o processo pode de
alguma forma ser resumido para fins didáticos em um procedimento genérico.
Basicamente, AT consiste das seguintes etapas (adaptado de [Greenberg 2004]:
1. Inventariar tarefas: descobrir as tarefas que o usuário faz;
Use diferentes técnicas de coleta: o ideal é observar e/ou entrevistar o usuário real
ou seus representantes. Tente identificar objetivos gerais e construir uma lista de tarefas
relacionadas a estes objetivos. Lembre-se que devem ser identificados objetivos
genéricos e não específicos dependentes de uma tecnologia. Por exemplo, no contexto
de um caixa eletrônico, “Identificar usuário” é um objetivo genérico enquanto “Digitar
ID e senha” é um objetivo específico descrito em termos da tecnologia.
2. Selecionar tarefas a serem analisadas e descritas com mais detalhes: tipicamente as
tarefas selecionadas incluem as mais freqüentemente realizadas ou as mais críticas.
3. Descrever as tarefas: decompor e ordenar as tarefas.
Decompor significa detalhar as tarefas (descrevendo-as em termos de subtarefas e
procedimentos, p.ex. se usarmos AHT) e ordenar significa definir o ordenamento causal
e/ou temporal das tarefas (sequencia, entrelaçamento, simultaneidade, etc). Aqui é
construído o modelo de tarefas (MT).
4. Validar as tarefas descritas: uma alternativa simples é apresentar o MT a alguém
não envolvido na AT mas que conheça bem as tarefas para verificar sua
consistência.
4. Modelos de tarefa
De fato, há vários modelos de tarefa (e notações associadas) na literatura, cada um
chamando atenção a um subconjunto de aspectos associados à maneira pela qual as
pessoas fazem suas tarefas. Por exemplo, MAD [Scapin 89], TKS [Johnson 88] e
ATOM [Walsh 89] focam respectivamente na decomposição hierárquica de tarefas, no
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
conhecimento necessário para realizar uma tarefa e às relações atores-objetos-ações
associadas às tarefas. Em geral, uma notação está tipicamente direcionada a
modelar/representar alguma perspectiva sobre a tarefa, entre as quais:
• Modelos de tarefas cognitivas do usuário (também denominados de modelos
cognitivos – “cognitive models”) representam o conhecimento que os usuários
necessitam para a realização de uma tarefa (por exemplo Task Knowledge
Structures - TKS [Johnson 88]);
• Modelos de tarefas interativas (“interactive task model” também denominados
modelos de interação ou modelos de diálogo) descrevem as ações que os
usuário tem que realizar na operação de um sistema para atingir seus objetivos
(por exemplo CLG [Moran 81], TAG [Payne 86], UAN [Siochi 91] [Hartson
90]);
• Modelos de tarefas de usuário (“user tasks”) descrevem como as ações dos
usuários se organizam no decorrer de suas atividades (por exemplo, MAD
[Scapin 89]).
Segundo a classificação de [Brun 95] os modelos genuinamente concebidos para
análise de tarefa são MAD et CLG cuja origem é a Psicologia Cognitiva. Alguns outros
formalismos frequentemente utilizados para modelagem de tarefa podem ser
classificados também como modelos de performance (incluindo GOMS e Keystroke
[Card 83]) ou como modelos de diálogo (incluindo UAN e XUAN [Siochi 91] [Hartson
90]).
Os modelos de performance direcionam-se sobretudo à avaliação da performance
do usuário incorporando técnicas para predizer o tempo de execução de tarefas e taxas
de erros. GOMS [Card 83] e TAG [Payne 86] são exemplos de técnicas avaliativas que
modelam respectivamente a performance e a competência de usuario.
Os modelos de diálogo são uma maneira de representar o diálogo entre o usuário e
o sistema a um nível de abstração baixo. Um exemplo é UAN (User Action Notation).
Os modelos de tarefa são uma maneira adequada de considerar o ponto de vista do
usuário na concepção pois a) representam conceitos relacionados à atividades (de
trabalho ou lazer) que os usuários realizam; e por isto b) permitem que o usuário
compreenda, valide e participa ativamente do processo de análise. Certos trabalhos não
diferenciam entre “tarefas existentes” e “tarefas futuras”, isto é, entre tarefas que o
usuário realiza atualmente e tarefas previstas e que poderão ser realizadas como a
interação com um (novo) sistema. Claramente, estão situadas em diferentes espaços do
processo de concepção do sistema: as primeiras são parte do espaço-problema e as
segundas são parte do espaço solução.
Além dos já citados, há vários outros modelos como TAKD [Diaper 89b] , ETAG
[Tauber 90] , GTA [van der Veer 96] e mesmo trabalhos que estudam a interseção entre
cenários e modelos de tarefas [Diaper 2002]. Entretanto neste trabalho, apresentaremos
um resumo dos modelos de tarefa MAD, UAN, ICO, GOMS e KLM que consideramos
representantes dos diferentes tipos de modelos de tarefa.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
4.1 Método Analítico de Descrição de tarefas2 (MAD)
Método Analítico de Descrição de tarefas (MAD) (Scapin 89, Sebillotte, 1995;
Rodriguez and Scapin, 1997; Scapin and Bastien, 2001) é uma notação e uma
metodologia que visa a descrição de tarefas com o objetivo final de melhor inserir
preocupações ergonômicas na concepção de interfaces com usuários. MAD se baseia na
descrição do objeto-tarefa e na decomposição hierárquica de tarefas em subtarefas com
auxílio de construtores pré-definidos que descrevem relações temporais e lógicas entre
estas diferentes subtarefas. Uma tarefa ou subtarefa é representada como uma árvore
cujos nodos são tarefas, subtarefas ou ações elementares, e assim sucessivamente.
A descrição do objeto-tarefa consiste de um conjunto de propriedades que
caracterizam esta tarefa: um estado inicial, um estado final, pré-condições, póscondições e atributos p.ex. sua prioridade , se a tarefa iterativa ou não, se é opcional ou
obrigatória, se pode ser interrompida ou não.
Construtores em MAD operam sobre os nodos filhos de uma mesma tarefa, o que
às vezes leva à criação de nodos abstratos artificiais para permitir usar algum construtor.
Os principais construtores de MAD são : SEQ – para encadeamento sequencial de
tarefas, PAR para execução paralela entrelaçada de tarefas por um mesmo agente
executor; SIM para execução simultânea de tarefas por agentes executores distintos;
ALT para expressar possibilidade de escolha entre tarefas alternativas; LOOP (ou @)
para tarefas iterativas e OP para tarefas opcionais.
4.2 User Action Notation - UAN
“User Action Notation” (UAN) [Hartson et al. 1990, Siochi 91, Shneiderman 98]
consiste em uma notação orientada a tarefas e ações do usuário para descrever o projeto
de interfaces assíncronas de manipulação direta. UAN é utilizado tipicamente para
descrever como o usuário executa uma tarefa interativa mas não como o sistema é
implementado para interpretar o comportamento do usuário. UAN foi concebida para
servir como uma forma de comunicar a lógica de operação da interface a um projetista
de software visando sua implementação, e claramente não é adequada a comunicação
com usuários finais.
AÇÕES DO
USUÁRIO
~(Lista de
aeroportos destino)
M∨
TAREFA: Selecionar aeroporto destino
FEEDBACK DA INTERFACE
ESTADO DA INTERFACE
Lista de aeroportos destino
aparece
Nome de aeroporto !
~(Item da lista de
aeroportos destino)
M∧
Nome do aeroporto permanece na
no topo da lista
Aeroporto destino é selecionado e o
itinerário do vôo é atualizado
Figura 2 - Exemplo de descrição em UAN, extraído de [Balbo et al. 2004]
Em UAN, uma interface é representada como uma estrutura quase hierárquica de
tarefas assíncronas. No seu mais baixo nível de abstração, UAN é uma notação
orientada a tarefas que descreve ações do usuário, os correspondentes feedbacks da
interface e a informação de estado. Níveis de abstração são usados para esconder estes
2
Do original em francês "Méthode Analytique de Description de tâches".
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
detalhes e representar a interface inteira. Em todos os níveis, ações do usuário e tarefas
são combinadas com relações temporais (como por exemplo, sequenciamento,
paralelismo, intercalação, etc) para descrever o ordenamento entre elas. As descrições
em UAN são apresentadas na forma de tabelas, como é mostrado na figura 2. O sentido
da leitura de uma tabela é de cima para baixo e da esquerda para a direita.
Os símbolos de UAN foram escolhidos, em sua maior parte, com a dupla intenção
de permitir o uso de editores de texto convencionais para escrever descrições de tarefas
e para serem visualmente onomatopéicos. Visando esta segunda característica, por
exemplo, o sinal de til (‘~’) sugere movimento e o sinal de exclamação (‘!’) sugere
atrair a atenção. A tabela 1 resume os símbolos de UAN e seus significados.
Tabela 1 - Símbolos de UAN e seus significados.
Símbolo UAN
(Ação)
~
[X]
~[X]
~[x,y]
~[x, y in A]
~[X in Y]
[X]~
∨
∧
X∨
X∧
X∧∨
X”abc”
X(xyz)
()
*
{}
AB
OR
&
⇔
||
;
!
-!
!!
!-!
n
(!-!)
@x, y
@X
Exibe(X)
Apaga(X)
X>~
X>>~
Contorno(X)
Significado
Move o cursor
Contextodo objeto X, no qual ele é manipulado
Move o cursor para o contexto do objeto X
Move o cursor para uma posição arbitrária (x, y)
Move o cursor para uma posição arbitrária (x, y) dentro do objeto A
Move o objeto X para dentro do objeto Y.
Move o cursor fora do contexto do objeto X.
Pressionar
Liberar
Aperte o botão, chave ou interruptor X.
Libere o botão, chave ou interruptor X.
Clicar botão, chave ou interruptor X
Entrada do literal “abc”, via teclado.
Entrada de valores para as variáveis xyz via o dispositivo X
Mecanismo de agrupamento de tarefas.
Tarefa executada zero ou mais vezes.
A tarefa é opcional (realizada zero ou mais vezes).
Tarefas A e B devem ser executadas na ordem da esquerda para direita ou de cima para baixo (AB).
Escolha de tarefa (útil para mostrar tarefas alternativas).
Tarefas são independentes quanto à ordem de execução
Tarefas X e Y podem ser intercaladas no tempo.
Tarefas podem ser executadas simultaneamente.
A tarefa não precisa necessariamente ser executada
Destaca o objeto
Não destaca o objeto
Destaque especial para o objeto.
Objeto piscando na tela
Objeto piscando na tela n vêzes.
Numa posição específica (x, y)
Na posição onde se encontra o objeto X.
Mostra o objeto X na tela
Apaga o objeto x da tela.
O objeto X é arrastado pelo cursor.
O objeto X muda de tamanho enquanto segue o cursor
Apresenta o contorno do objeto X na tela.
Assim, a descrição da figura 2 pode ser interpretada da seguinte forma: Para o
usuário realizar a tarefa (“selecionar aeroporto destino”) , ele deve mover o cursor para
uma list-box “~(Lista de aeroportos destino)” e pressionar o botão do mouse (“Mv”).
Como resultado desta ação, o sistema faz a lista de opções aparecer (“lista de aeroportos
destino aparece”). A medida que o usuário move o cursor na lista, cada item da lista é
destacado (“Nome do aeroporto !”), e após a liberação do botão do mouse (“M∧”), o
nome do aeroporto escolhido fica no topo da lista exibido como a opção escolhida
(“Nome do aeroporto permanece no topo da lista”). Note que a descrição linha-por-linha
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
associa o feedback da interface a correspondente ação do usuário. Este nível de precisão
é perdido em outros tipos de descrição, quando a ação do usuário e o feedback são
misturados.
4.3 Interactive Cooperative Objects (ICO)
Interactive Cooperative Objects (ICO) [Palanque 93] é um formalismo baseado em
Redes de Petri a Objetos para modelagem do comportamento de um sistema interativo e
que pode servir também para modelar as tarefas interativas entre o usuário e o sistema
[Palanque 1995, Bastide & Palanque 1999, Navarre et al. 2001] . O formalismo
considera que um objeto ICO é composto de:
• Estrutura de dados (atributos);
• Conjunto de operações (serviços internos ou serviços disponíveis como
mensagens);
• Estrutura de controle do objeto (ObCS - Object Control Structure) para modelar
seu comportamento definido através de uma rede de Petri de alto nível;
• Apresentação para descrever sua aparência externa e que está estruturada como
um conjunto de widgets tais como botões, checkboxes, etc.; e
• Função de ativação que, a cada par (widget, ação sobre o widget) associa um
serviço do ICO.
Além disto, o sistema interativo é descrito através de um conjunto de ICOs e de
uma rede de Petri para descrever o comportamento do sistema e as interações entre os
ICOs (WSCS- Whole System Control Structure).
O princípio básico de modelagem ICO é utilizar um protocolo cliente-servidor para
assegurar, para cada ICO, que o conjunto de serviços solicitados aos outros objetos (a
demanda) está inclusa no conjunto de serviços oferecidos por eles (a oferta). Para
avaliar a cooperação com os usuários, cada usuário é considerado como um ICO.
Assim, pode-se assegurar que a demanda do usuário está incluída na oferta do sistema.
Com ICO pode-se verificar se o modelo de concepção do sistema suporta o modelo
de tarefa do usuário. Como os 2 modelos têm uma base (e uma notação) comum pode-se
através de técnicas formais associadas à teoria das redes de Petri:
• Validá-los de maneira isolada, isto é, mostrar que cada ICO é capaz de fornecer
seus serviços; e
• Compará-los e validar sua cooperação.
O uso de formalismos como ICO em IHC tem uma série de vantagens – ver uma
discussão extensa em [Palanque & Paterno 1997] - mas a principal é a possibilidade de
especificar o modelo de tarefa com precisão e rigor, sem ambiguidade e com isto
permitir análise de características do modelo sem uma versão executável do sistema e
sem a participação do usuário, antecipando alguns aspectos da avaliação para as fases
iniciais do ciclo de desenvolvimento de modo a predizer alguns dos aspectos de
usabilidade do sistema.
Evidentemente, estes modelos formais não substituem outras práticas, como testes
com usuários. No entanto, usar modelos formais pode nos habilitar a responder mais
cedo e com menos esforço a certas questões de desenvolvimento de IU.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
4.4 GOMS
O modelo GOMS (acrônimo de Goals, Operators, Methods and Selection rules) foi
desenvolvido como um modelo preditivo do desempenho de um ser humano ao interagir
com um sistema. O modelo GOMS original [Card 83] é o ancestral de uma família de
modelos que variam basicamente em relação à granularidade dos aspectos de
performance do usuário modelados e usados nas predições – incluindo [Grasy et al.
1992, Kieras 1996, John & Kieras 1996, Baumeister et al 2000].
Basicamente, GOMS é um modelo de conhecimento e dos processos cognitivos do
usuário quando interage com sistemas e tem sido usado principalmente para predizer o
desempenho de usuários ao comparar diferentes aplicações e equipamentos e para
ajudar a análise da eficiência de novos sistemas sem a necessidade de envolver usuários.
GOMS pode ser usado no design de (novas) tarefas e por isto a noção de método (o “M”
de GOMS) é tão importante. Um método é uma seqüência de operadores que descreve
a performance de uma tarefa. Operadores (o “O” de GOMS) são ações físicas
(pressionar uma tecla, apontar um item com mouse, “clicar” o mouse, etc) e cognitivas
(decidir qual comando usar, esperar, etc) que o usuário executa. Tarefas são realizadas
para alcançar objetivos (o “G” de GOMS), estados que o usuário quer atingir, e podem
ser decompostas em subtarefas, que correspondem a objetivos intermediários. Quando
vários métodos existem para o mesmo objetivo, uma regra de seleção (o “S” de GOMS),
com base no contexto de uso, é usada para escolher o método apropriado.
GOMS não é freqüentemente usado em avaliação por envolver um conjunto muito
limitado de tarefas de entrada de dados, por não modelar erros adequadamente e não
levar em conta informações contextuais (interrupções nas tarefas, fadiga, etc) que
podem mudar comportamentos e desempenhos previstos.
4.5 KLM
Keystroke Level Model (KLM) faz parte da família GOMS, mas concentra-se em
predições quantitativas do desempenho do usuário [Card 83]. Tarefas podem ser
comparadas em termos de tempo para executá-las ao usar diferentes estratégias
(diferentes métodos na nomenclatura GOMS). Cada método é uma seqüência de
operadores físicos e cognitivos e como cada operador tem um tempo de execução
associado - determinado com base em experimentos prévios e que pode ser consultado
em uma tabela presente em [Preece 2002] -, pode-se predizer o tempo necessário para
realizar uma tarefa.
5. Modelagem de tarefas com ConcurTaskTrees (CTT)
Esta seção apresenta a notação para modelagem de tarefas Concurrent Task Trees ou
resumidamente ConcurTaskTrees (CTT) [Paterno 1997]. Esta notação foi escolhida para
ilustrar aqui o processo de modelagem de tarefas pela sua capacidade de expressão na
modelagem de sistemas interativos e porque é uma notação que vem sendo muito
difundida e utilizada pela comunidade internacional de IHC. Além disto, a existência de
uma ferramenta de edição e de suporte a análise de modelos, chamada CTT
Environment (CTTE) [Mori 2002] (ver seção 5), facilita a criação de modelos de
tarefas. A seguir são apresentados os fundamentos do modelo CTT e os principais
elementos da notação.
5.1 Introdução ao modelo CTT
As principais características de CTT são:
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
• Foco nas atividades: permite que o projetista se concentre nas atividades que os
usuários precisam realizar com a interface sem se preocupar com detalhes de
como a tarefa será implementada pelo sistema;
• Estrutura hierárquica: suporta a representação de vários níveis de abstração pela
decomposição de tarefas complexas em subtarefas menores;
• Representação gráfica: modelos são descritos graficamente na forma de uma
árvore de tarefas;
• Suporte a relacionamentos temporais: um vasto conjunto de operadores é
disponível permitindo definir relacionamentos temporais entre tarefas;
• Alocação de tarefas: permite descrever os agentes que realizam a tarefa (ex.
usuário e/ou aplicação);
• Objetos: permite indicar objetos do domínio do problema que são manipulados
durante a execução da tarefa.
Os elementos da notação CTT são definidos em torno da idéia de que o objetivo do
usuário ao realizar uma tarefa pode ser traduzido como uma modificação do estado do
sistema ou uma consulta a um recurso do sistema. Assim, os modelos criados em CTT
podem ser interpretados como uma representação (de alto nível de abstração) dos
estados possíveis do sistema e do usuário durante a realização de uma tarefa específica.
Segundo esta abordagem, a execução de cada tarefa individual é capaz de modificar a
configuração de estados do sistema.
O comportamento do modelo de tarefas é definido em CTT pela adição de
operadores temporais (tais como escolha, repetição, seqüência, etc.) entre as tarefas. A
existência de tais operadores temporais torna possível a modelagem de tarefas em
sistemas interativos.
5.2 Definição de tarefas e seus atributos
Cada tarefa individual em CTT é descrita através dos seguintes atributos:
• Nome: usado para identificar a tarefa;
• Subtarefa de: indica o nome da tarefa-pai, caso existir;
• Objetos: lista de possíveis objetos do domínio da aplicação que podem estar
associados a tarefa; objetos podem ser do domínio da interface ou do domínio
da aplicação (objetos conceituais);
• Tipo: existem quatro tipos possíveis para uma tarefa de acordo com o agente que
a realiza (usuário, aplicação, interativa, abstrata);
Os atributos nome e subtarefa de são atributos básicos de modelos de tarefas que
permitem respectivamente a identificação individual de cada tarefa e a construção de
uma hierarquia de tarefas onde cada tarefa conhece o seu ancestral imediato. Os demais
atributos são detalhados a seguir.
5.2.1 Objetos
Os objetos são entidades manipuladas durante a realização de tarefas. Sobre estes
objetos são realizadas ações que podem ser cognitivas, lógicas ou físicas.
Objetos podem ser objetos perceptíveis, ou objetos internos. Objetos perceptíveis
são aqueles com os quais o usuário pode interagir usando os sentidos (ex. menus,
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
botões, sinal sonoro, etc.). Objetos internos são entidades conceptuais representadas por
objetos perceptíveis (ex. estado de uma consulta em um banco de dados; o próprio
banco de dados).
Cada objeto pode pertencer a uma ou mais tarefas. Durante o processo de
decomposição de tarefas em subtarefas, objetos definidos no nível mais elevado da
tarefa podem ser manipulados em subtarefas de duas maneiras:
• Por decomposição (um objeto no nível da tarefa é decomposto em 2 ou mais
objetos no nível das subtarefas);
• Por refinamento (o conjunto de ações associadas com um objeto detalhado no
nível das subtarefas).
5.2.2 Tipos de tarefas
CTT identifica quatro tipos de tarefas de acordo com a alocação de tarefas, ou seja,
quem a realiza como segue:
• Usuário: são tarefas cognitivas ou físicas realizadas inteiramente pelo usuário;
por exemplo: identificar o nome de um arquivo numa lista de arquivos de um
diretório;
• Aplicação: são tarefas completamente realizadas pelo sistema sem a intervenção
do usuário. Tais tarefas podem receber informações do sistema e fornecer um
resultado visível ao usuário. Exemplo: compilar um programa e enviar uma
mensagem ao usuários cada vez que um erro é detectado.
• Interativa: são tarefas que o usuário realiza com o sistema; as interações são
ativadas pelo usuário e processadas pelo sistema; Exemplo: editar um diagrama
ou formular uma consulta em um formulário;
• Abstrata: são tarefas que requerem ações complexas e que devem ser
decompostas em um subtarefas. Tarefas abstratas também são usadas para
descrever tarefas que não cabem inteiramente em nenhum das categorias
anteriores.
O tipo das tarefas são representados graficamente na notação CTT. Dois tipos de
representação de tipos de tarefas são possíveis, através de ícones ou de formas
geométrica simples, como mostra a Figura 3.
Figura 3 – Representações possíveis para tipo de tarefas.
Neste trabalho, os exemplos de modelos de tarefas utilizam a representação por
ícones.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
5.3 Relacionamentos temporais
Operados temporais tais como seqüência, escolha e iteração, são fundamentais para
modelar o comportamento de sistemas interativos. Tais operadores são utilizados para
definir o relacionamento de tarefas em um mesmo nível. Os operadores usados em CTT
para descrever tais relacionamentos entre tarefas são definidos como extensões aos
operadores LOTOS [Bolognesi 87]. A lista de operadores temporais disponíveis em
CTT é apresentada na Tabela 2.
Tabela 2 – Operadores temporais entre tarefas.
Operador
Símbolo
Forma3
escolha
[]
T1 [ ] T2
independência de
ordem
|=|
T1 |=| T2
concorrência
independente
|||
T1 ||| T2
concorrência com
troca de informações
|[]|
T1 |[]| T2
desativação
[>
T1 [> T2
suspende/ continua
|>
T1 |> T2
habilitação
habilitação com
passagem de
informação
>>
T1 >> T2
[ ]>>
T1 [ ]>> T2
Descrição
é possível escolher uma tarefa, outras tarefas ficam
indisponíveis até a tarefa escolhida terminar;
ambas as tarefas devem ser realizadas, em qualquer
ordem, mas deve-se esperar a finalização de uma
delas para dar prosseguimento a tarefa seguinte
tarefas podem ser executadas em qualquer ordem
sem nenhuma restrição. Ex. Monitorar uma tela e falar
em um microfone.
as duas tarefas podem ser executadas em paralelo
mas devem se sincronizar para trocar informações
a primeira tarefa é definitivamente desativada quando
a segunda tarefa inicia (ex. Seleção de botões)
este operador da a possibilidade de interromper a
primeira tarefa quando a segunda termina. Este
operador pode ser usado para modelar um tipo de
interrupção
quando a T1 termina a T2 é ativada
quando a T1 termina ela envia valores para a T2
antes que essa seja ativada
Além de operadores relacionais entre tarefas, CTT inclui um conjunto de 3
operadores unários (aplicáveis a uma tarefa individualmente). A representação de um
operador unário é exemplificado na figura 4 pelo operador iteração (*) que é associado
a tarefa Modificar gráfico. A lista completa de operadores unários disponíveis em CTT
é apresentada na Tabela 3.
Tabela 2 - Lista de operadores unários em CTT.
Operador
Símbolo
Forma
iteração
*
T*
opcionalidade
[]
[T]
conexão entre
modelos
↔
T
↔
Descrição
a tarefa é iterativa, a tarefa termina apenas quando for
desativada por outra tarefa
uma tarefa representada entre colchetes ([ ]) é
indicada como opcional
indica que a tarefa sublinhada com o símbolo ↔
pode ser usada em modelo cooperativo onde
participam vários usuários
5.4 O processo de construção de modelos
Um modelo de tarefas CTT é construído em 3 etapas:
1. Decomposição hierárquica de tarefas e subtarefas;
2. Identificação de relações temporais entre tarefas no mesmo nível;
3
Os elementos T1 e T2 representam tarefas.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
3. Identificação de objetos associados a cada tarefa e ações que permitem que os
objetos comuniquem entre si.
5.4.1 Decomposição hierárquica de tarefas e subtarefas
O modelo de tarefas é construído como uma hierarquia de tarefas onde o primeiro
elemento (chamado raiz) corresponde ao nível mais elevado de abstração. O elemento
raiz é então decomposto em sub-tarefas que permitem refinar o modelo. A hierarquia é
representada na forma de uma árvore invertida como mostra a Figura 4. O exemplo
apresentado pela Figura 4 mostra um modelo de tarefas CTT para um programa simples
de edição de gráficos. A tarefa Editar um gráfico é definida como um tarefa composta
de três subtarefas: Abrir arquivo, Modificar gráfico e Salvar arquivo. As tarefas : Abrir
arquivo e Modificar gráfico são ainda decompostas em um outro nível de subtarefas.
Este processo de decomposição de tarefas termina quando o designer decide que o nível
de representação é suficiente para compreender completamente a tarefa.
Figura 4– Modelo CTT para um programa simples de edição de gráficos.
5.4.2 Identificação de relações temporais
As tarefas em CTT se relacionam entre si através de relacionamentos de filiação
(hierarquia entre os diferentes níveis) ou através de relacionamentos temporais entre
tarefas pertencendo a um mesmo nível. Tais relacionamentos são necessários para
definir o comportamento do modelo de tarefas. Considerando o exemplo dado pela
tarefa Editar um gráfico (Figura 4), a ordem de precedência entre estas tarefas é
representada pelo operador >>, como indicado entre as tarefas Mostrar lista de
arquivos, escolher arquivo e Selecionar arquivo; isto significa que a tarefa Escolher
arquivo somente será realizada depois que a tarefa Mostrar lista de arquivos for
concluída.
Para indicar a alternativa entre tarefas CTT emprega o operador [ ] como no
relacionamento entre as tarefas Adicionar nodo, Adicionar vértice, Remover nodo,
Remover vértice e Mover nodo. Isto significa que a tarefa Modificar gráfico pode ser
completada pela realização de qualquer uma destas subtarefas. O operador iteração (*)
associado a tarefa Modificar gráfico é usado para indicar que essa tarefa pode ser
repetida várias vezes. De fato a tarefa Modificar gráfico pode ser completada pela
realização de uma de suas subtarefas (Adicionar nodo, Adicionar vértice, Remover
nodo, Remover vértice ou Mover nodo) ou por qualquer seqüência dessas; por exemplo,
uma modificação de gráfico poderia necessitar a adição de um novo nodo e conexão
deste nodo a um outro nodo do gráfico. Neste caso, o operador iteração (*) é usado para
indicar a repetição da tarefa Modificar gráfico permitindo que diferentes seqüências de
subtarefas sejam formadas para atender os diferentes cenários possíveis para a tarefa.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
5.4.3 Identificação de objetos associados a tarefas
O processo de identificação de objetos e ações associados a tarefas é realizado nível
por nível. Para cada tarefa pode ser associada a lista de objetos manipulados assim
como seus atributos e as ações utilizadas. Geralmente, ações e objetos não são
representados diretamente nas tarefas para evitar que a poluição visual da representação
gráfica do modelo. A ferramenta CTTE, descrita na seção a seguir, auxilia a edição de
objetos e ações associados a tarefas (ver detalhes na seção 5.2).
5.4.4 Solução de problemas de ambigüidade
A simples utilização de operadores temporais durante a construção de modelos de
tarefas com CTT pode levar a algumas ambigüidades. A Figura 5a poderia ser
interpretada de duas maneiras: (T2 [] T3) ||| T4, ou T2 [] (T3 ||| T4). Para resolver esta
ambigüidade pode-se aplicar a prioridade de operadores definida no padrão LOTOS
(escolha > concorrência independente > desativação > habilitação) ou introduzir uma
tarefa que elimine a ambigüidade da expressão. A figura 5b apresenta a segunda solução
optando pela introdução da subtarefa TD.
Figura 5 – Possível problema de ambigüidade entre tarefas (figura a) e sua respectiva
solução gráfica (figura b).
5.4.5 Relacionamento entre tarefas na hierarquia
A utilização de operadores relacionais dentro de um contexto de hierarquia de
tarefas dá uma grande flexibilidade para a especificação de diferentes comportamentos.
Por exemplo, a figura 6 apresenta duas variantes de um tarefa T1 composta de duas
subtarefas T2 e T3 que podem ser realizadas iterativamente em qualquer ordem. No
primeiro caso (figura 6a) o símbolo de iteração está associado a tarefa-pai T1, o que
significa que as subtarefas podem ser realizadas em qualquer ordem mas ambas devem
ser realizadas antes de iniciar a iteração seguinte. No segundo caso (figura 6b), após ter
terminado T2 pode-se repetir várias vezes a tarefa antes de passar a tarefa T3.
Figura 6 - Diferentes maneiras de especificar independência de ordem.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
Um exemplo típico de independência de ordem é a reserva de uma passagem aérea.
O usuário deve informar a chegada e a saída, mas não necessariamente nesta ordem.
Uma vez que uma reserva de vôo foi concluída, é possível realizar uma nova reserva. A
mesma aplicação poderia apresentar concorrência contínua entre duas tarefas
considerando a formulação de uma consulta no banco de dados e a introdução de novos
vôos na base; eles podem ser executadas várias vezes sem nenhum limitação na ordem
de execução.
5.5 Exemplos de especificações em CTT
Esta seção apresenta alguns estudos de caso de modelagem de tarefas usando CTT.
5.5.1 Estudo de caso: terminal de auto atendimento bancário
Atualmente, terminais de auto atendimento são disponíveis para quase todas a operações
bancárias tais como saques, depósitos, transferências, retiradas de cheques, extratos,
aplicações, etc. Contudo, por questões de espaço, nosso estudo de caso sobre terminais
de auto atendimento resume-se à tarefa de saque. A figura 7 apresenta a modelagem da
tarefa saque (denominada no modelo como Retirar dinheiro) usando a notação CTT.
Figura 7 – Modelagem da tarefa Retirar dinheiro em um terminal bancário genérico.
A modelagem de tarefas apresentada na figura 7 descreve uma tarefa de saque
genérica. Esta tarefa, denominada Retirar dinheiro, é composta de quatro subtarefas:
Identificar-se, Indicar montante, Verificar transação, e Terminar. Cada uma dessas
subtarefas ainda é decomposta em um terceiro nível de detalhe. Considera-se que não
existe uma ordem predeterminada para a execução das subtarefas Identificar-se e
Indicar montante (note o operador |=|, independência de ordem, entre elas). De fato, do
ponto de vista do usuário da aplicação, não existe uma seqüência fixa de tarefas, tanto
faz se ele se identifica primeiro e em seguida indica o montante desejado do saque, ou
vice-versa. Com freqüência, é a implementação de tais sistemas que impõem uma
determinada ordem para estas tarefas por questões de segurança e/ou de escolhas de
implementação que não estão de forma alguma relacionados com a realização do
objetivo do usuário. A mesma análise com relação a independência de ordem de
execução de tarefas pode ser observada nas subtarefas Recuperar cartão e Recuperar
dinheiro que estão associadas a tarefa Terminar.
5.5.2 Estudo de caso: Anulação de comandos
Modelos CTT são comumente usados para especificar a atividade de usuários com
uma determinada aplicação. Uma situação bastante comum é a necessidade do usuário
de poder cancelar uma modificação. A Figura 8 mostra uma modelagem CTT genérica
para o cancelamento de um comando em uma aplicação. Após ter realizado a subtarefa
modificar o usuário pode confirmar ou cancelar. Em ambos os casos a tarefa Editar é
iterativa, assim o usuário é capaz de especificar uma nova modificação até que a tarefa
Terminar aplicação seja realizada.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
As figuras 8a e 8b são equivalentes. Observa-se porém uma representação contraída
ou simplificada da tarefa Modificar na figura 8a. A tarefa Modificar é expandida na
figura 8b mostrando toda a decomposição de suas subtarefas. Este recurso gráfico pode
ser usado para controlar o nível de detalhe de um modelo.
Tarefa: modificar
Figura 8 – Cancelamento de um comando.
5.6 Ambiente de suporte a edição e simulação de modelos CTT (CTTE)
A edição e análise de modelos CTT é grandemente facilitada pela ferramenta
CTTE
(CTT
Environment)
que
é
publicamente
disponível
em
http://giove.cnuce.cnr.it/ctte.html. Uma descrição desta ferramenta pode ser encontrada
em (Mori, Paternò, e Santoro, 2002). Aqui nos contentamos em mostrar as principais
facilidade oferecidas por essa ferramenta.
5.6.1 Edição de modelos
Toda a edição de tarefas com CTTE é realizada graficamente. Todo modelo iniciase com uma tarefa abstrata (denominada root) que identifica a base da tarefa. Para criar
subtarefas é necessário selecionar a tarefa-pai. Uma vez que o ponto de inserção na
hierarquia foi selecionada (a tarefa-pai) pode-se selecionar um dos ícones na barra de
ícones (a esquerda da janela); cada vez que o usuário clica em um ícone de tarefa, uma
nova subtarefa é adicionada ao diagrama. A figura 9 apresenta uma visão da ferramenta
ilustrando a edição de um modelo; observa-se que a tarefa principal Editar gráfico é
representada com um retângulo que indica que ela esta atualmente selecionada.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
Figura 9 – CTTE : visão geral da zona de edição de diagramas e barra de ferramentas.
A edição de relacionamentos também é feita da esquerda para direita. Seleciona-se
a tarefa mais a esquerda no mesmo nível hierárquico e, em seguida seleciona-se um
ícone de operador temporal a partir da paleta de operadores (situado logo abaixo dos
ícones de tarefas). O relacionamento é aplicado entre a tarefa atualmente selecionada e a
tarefa imediatamente a direita no mesmo nível. A seleção de um novo ícone de operador
substitui o operador anterior no relacionamento.
5.6.2 Definição de objetos e ações associados a tarefas
Objetos e ações podem ser especificados como associados a uma tarefa através da
opção propriedades da tarefa selecionada. A figura 10 mostra o objeto File system
associado a tarefa Abrir arquivo.
Figura 10 – Definição de objetos e ações de uma tarefa usando CTTE.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
5.6.3 Simulação de modelos e extração de cenários
A simulação de um modelo de tarefas pode ser útil na análise da dinâmica dos
modelos. Com freqüência, é necessário simular a execução de um modelo de tarefas
para determinar se o comportamento especificado representa a realidade modelada.
CTTE inclui uma simulador que permite visualizar graficamente todas as etapas da
execução de um modelo de tarefas CTT. A idéia básica por traz deste simulador é que, a
qualquer momento da simulação, é possível visualizar a lista de tarefas habilitadas.
Apenas tarefas básicas (que não tem filhos) são consideradas.
A figura 11 apresenta a janela do simulador de modelos; tarefas habilitadas são
marcadas como selecionadas no gráfico e elas também aparecem na lista de tarefas que,
de acordo com a ordem e o tipo de operadores definidos estão disponíveis para a
execução. A seleção (por duplo-clique) de uma tarefa habilitada indica o termino da
mesma e transfere o controle para o simulador que atualiza a lista de tarefas e a
representação gráfica com a próxima configuração de tarefas.
Lista de tarefas a serem
executadas
Figura 11 – Simulador de modelos CTT, parte do ambiente CTTE.
A simulação de modelos de tarefas que usam operadores temporais permite a
extração de inúmeros cenários de uso que descrevem a realização de uma tarefa em um
contexto específico. A extração de cenários a partir de um modelo de tarefa é uma
ferramenta útil para a verificação de aplicação e para registrar seqüências de tarefas que
poderão ser utilizadas na escolha de opções de implementação ou na avaliação. Embora
a extração de cenário não seja específica a CTT, o editor CTTE permite que tais
cenários possam ser efetivamente executados graças a uma ferramenta de simulação
integrada ao ambiente. Cada execução de um modelo de tarefas produz um cenário. A
execução do mesmo modelo de tarefa Retirar dinheiro pode produzir cenários
diferentes tais como os apresentados pela figura 12.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
Figura 12 – Cenários extraídos pela execução do modelo de tarefas Retirar dinheiro.
Com base nestes fundamentos vistos até agora, durante o tutorial serão realizados
vários exercícios de modelagem visando consolidar o conhecimento sobre CTT e o
ambiente CTTE.
6. Usos de modelos de tarefa
Uma vez que conhecemos os fundamentos de Análise e Modelagem de Tarefas,
pode-se investigar como podemos usar os modelos criados para auxiliar o processo de
desenvolvimento de sistemas interativos. Esta seção resumirá alguns dos usos possíveis.
O leitor interessado pode obter mais detalhes nas referências apontadas.
6.1 Modelos de tarefa para definição de requisitos
A Engenharia de Software (ES) tem usualmente priorizado sua atenção para os
requisitos funcionais dando pouca ou nenhuma atenção aos requisitos de usabilidade ou
de interação. Assim, a Engenharia de Requisitos de sistema interativos exige, além da
compreensão e modelagem do domínio do problema (já existente nos enfoques
tradicionais da Engenharia de Software) a compreensão do contexto de trabalho em que
o sistema será utilizado. É neste ponto que é importante a Análise e a Modelagem de
Tarefas para investigar e representar os procedimentos de trabalho, os automatismos
desenvolvidos na realização de tarefas, os disfuncionamentos observados, as regras
tácitas (sociais, políticas, comerciais) internas ao contexto organisacional analisado para chegar a um conjunto de requisitos. Estes requisitos podem ser Requisitos
solicitados explicitamente pelo usuário definidos a partir das necessidades identificadas
pela Análise da Tarefa.
Com este conjunto inicial de requisitos definidos, o fio condutor do restante do
processo pode ser o conceito de caso de uso [Jacobson 1992, Booch et al 1999]. Casos
de uso são descrições narrativas do fluxo de eventos no uso de um sistema (ações do
usuário e respostas do sistema a estas ações) e são usualmente utilizados em ES para
modelar requisitos funcionais.
Modelos de tarefa podem ser usados como ponto de partida na construção e no
refinamento de casos de uso, a partir dos objetivos presentes no modelo de tarefas.
Acreditamos que pode-se combinar modelos de tarefas e casos de uso, utilizando casos
de uso essenciais [Constantine & Lockwood 1999]. Casos de uso essenciais são
narrativas estruturadas consistindo de 3 partes: um nome que expressa a intenção final
do usuário, uma descrição passo a passo das intenções do usuário e a correspondente
descrição da responsabilidade do sistema associada a esta ação. Nenhuma descrição (de
usuário ou sistema) é atrelada a uma tecnologia particular (daí o nome “essencial”), o
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
que torna o conceito adequado para discutir requisitos. Um exemplo de caso de uso
essencial para a transação de saque num caixa eletrônico é ilustrado na figura 13
Realizar Saque
Intenção do usuário
Identificar-se
Acionar Operação de Saque
Fornecer Valor para Sacar
Retirar cédulas e recibo
Responsabilidade do Sistema
Verificar Identificação
Fornecer Opções de Operação
Verificar Opção Acionada
Solicitar valor de saque
Verificar se valor é válido
Verificar se há saldo disponível
Processar saque da conta
Disponibilizar cédulas e recibo
Encerrar Operação
Figura 13 – Caso de Uso Essencial para Realizar Saque num caixa eletrônico.
A coluna das intenções do usuário pode totalmente ser construída a partir de um
modelo de tarefas. Note que estes seriam passos que poderíamos sugerir a alguém que
precisasse realizar um saque e não soubesse como proceder. Neste nível de descrição ,
não importam os detalhes operacionais que deverão ser definidos durante o design
(“fornecer valor para sacar” pode ser feita através de seleção em menus exibidos em
uma tela, pressionando teclas especiais com quantias pré-determinadas, digitação em
um campo, etc) mas sim que estas intenções do usuário implicam na definição de
responsabilidades do sistema que deve dar suporte a estas tarefas. Logo, ajudam a
definir requisitos funcionais. Os requisitos não funcionais (incluindo os de usabilidade e
interação) exigem uma definição mais sutil e podem ser estabelecidos também a partir
das informações coletadas na Análise de Tarefas, mas não serão discutidos aqui.
Mais informação sobre o uso de modelos de tarefas para definição de requisitos
para sistemas interativos pode ser encontrada em [Johnson 1992, Wilson & Johnson
1996, SIGCHI Bulletin 1997, Constantine & Lockwood 1999]. Mais informações sobre
requisitos não funcionais encontram-se em [Cysneiros et al. 2001 , Mylopoulos et al.
1992, Chung et al 2000].
6.2 Modelos de tarefa para design de interfaces WIMP
Uma interface com usuário é composta por dois componentes principais: o
componente de apresentação – que indica como a interface exibe informações ao
usuário – e o componente de diálogo que descreve como podem ser ordenadas as
ações que o usuário e o sistema executam.
Além da informação importante sobre os objetivos dos usuários – fundamental para
a determinação dos requisitos do sistema – modelos de tarefa podem ser usados também
no auxílio ao design de interfaces de sistemas interativos, em particular de interfaces de
WIMP, típicas de plataformas desktop como PC e Mac. Neste caso, o objetivo é usar
informações presentes explicitamente nos modelos de tarefa ou deriváveis a partir deles
para identificar, selecionar ou gerar os componentes de apresentação e de diálogo mais
adequados ao suporte das tarefas.
O design da apresentação geralmente inclui 2 atividades, mesmo que nem sempre
sejam executadas separadamente: a) definir quais os elementos (widgets) serão exibidos
numa unidade de apresentação (janela, caixa de diálogo, etc ) a um determinado
momento; e b) definir como estes elementos serão exibidos, ou seja, determinar os
detalhes de apresentação (cor, formato, tamanho, realismo etc).No curso da interação do
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
usuário com o sistema, a apresentação muda para refletir as alterações decorrentes das
ações do usuário e/ou do sistema. A partir do modelo de tarefa , podemos decidir sobre
quais elementos e informações devem estar exibidos ao mesmo tempo. Como esta
decisão depende do contexto de uso e dos usuários alvo, é preferível evitar o
estabelecimento de regras ou mapeamentos rígidos entre o modelo de tarefa e o modelo
de apresentação mas obviamente com base no modelo de tarefa pode-se restringir o
número de alternativas adequadas. Ver mais detalhes sobre design de apresentação com
base em modelos de tarefa em [Eisenstein & Rich 2002], [Bodart 1994], [Johnson et al.
1995] , [Paterno et al. 1998] e [Paterno 1999].
O modelo de diálogo depende diretamente da ordenação descrita no modelo de
tarefa e das restrições causais/temporais entre as subtarefas. Analisando o modelo de
tarefa, pode-se decidir quais ações são possíveis de serem realizadas num determinado
instante e quais não são (o que implica talvez em habilitar/desabilitar seu acionamento),
e em qual ordem o sistema permitirá o encadeamento (sequencial, entrelaçado, etc) da
realização de ações. Ver mais detalhes sobre design de diálogo com base em modelos de
tarefa em [Paterno 1999], [Birnbaum et al 1998] ,[Vanderdonckt & Bodart 1993],
[Wilson & Johnson 1996] e [Paterno 2001].
6.3 Modelos de tarefa para design de interfaces Web
Embora o uso de MT para desenvolvimentode sistemas interativos não seja uma
idéia recente, o uso de MT para design de aplicações web é ainda uma questão aberta.
De fato, tanto a prática de design quanto os enfoques de Web Engineering não prevêem
a integração de MT ao processo de design. Já há alguma preocupação com a usabilidade
ou com a concepção da interação dos websites mas raros são os trabalhos que afirmam
explicitamente usar MTs para isto e mais raros os que indicam como o fazem.
O obstáculo principal é provavelmente o grande número de usuários potenciais e a
consequente grande diversidade de modos de usar e interagir com a aplicação web. Isto
torna muito complexo determinar o conjunto de tarefas a considerar para o design.
De maneira simplificada, as tarefas dos usuários de aplicações web pertencem a 2
categorias principais: tarefas de alto nível e tarefas primitivas.
Tarefas de alto nível geralmente são muito próximas aos objetivos do usuário e
podem ser realizadas de várias formas. Este tipo de tarefa habilita os designers a
entender os aspectos fundamentais da atividade do usuário (como os objetivos, seus
subobjetivos e o ordenamento dos procedimentos para alcançá-los) e são usualmente
independentes da forma de realização.
Tarefas primitivas correspondem a uma atividade do usuário com o sistema. Estas
tarefas são genéricas e podem ser encontradas na maior parte das aplicações web. Um
conjunto inicial de tarefas primitivas é a taxonomia (“taskonomy”4) proposta por [Byrne
et al. 1999], que inclui as seguintes categorias: usar informação de uma página, localizar
algo na página, ir para um página, fornecer informação, configurar navegador e reagir
ao ambiente.
Vários enfoques baseados em modelos (model-based) para sistemas interativos têm
sido propostos nos últimos anos mas o uso de modelos de tarefa para aplicações web é
ainda incipiente [Szwillus & Bomsdorf 2002, Bomsdorf & Szwillus 2003, Szwillus &
Bomsdorf 2003]. Grande parte dos modelos para descrever interfaces web investigados
e propostos na área de Web Engineering concentram-se basicamente na perspectiva
4
O trocadilho do título do artigo é ótimo: taskonomy = taxonomy of tasks, uma taxonomia de tarefas.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
orientada a sistema da aplicação e não contemplam o uso de modelos de tarefa. De fato,
atividades do usuário (user activities) são mais exploradas que modelos de tarefas
[Newman & Landay 2000] e design centrado no usuário (UCD – User Centered Design)
é ainda uma noção pouco usada para Web design, embora haja exceções [De Troyer &
Leune 1998].
6.4 Modelos de tarefa para avaliação de interfaces
Um MT pode ser usado de várias formas em avaliação de interfaces, entre as quais
[Paterno 2001]:
• predizer (ou medir) o desempenho do usuário na realização de tarefas (como em
KLM); O leitor interessado pode achar um bom exemplo de como realizar esta
avaliação preditiva quantitativa no capítulo 14 de [Preece 2002].
• fornecer um modelo de referência para avaliação através de cognitive walkthrough
ou da análise do log de interações do usuário; No primeiro, os avaliadores devem
identificar uma seqüência de tarefas a executar e para cada uma delas devem tentar
responder algumas questões - ver excelente descrição do cognitive walkthrough no
capítulo 13 de [Preece 2002]. No segundo, pode-se analisar desvios na realização da
tarefa com respeito ao inicialmente planejado pelos designers;
• montar cenários ou conjuntos de amostras representativas de tarefas para realização
de avaliações realizadas por usuários (testes com usuários como os ensaios de
interação p.ex.) ou por especialistas (avaliação heurística);
Há alguns trabalhos também relatando o uso de MT para avaliação de interfaces
Web [Winckler et al 2002] e para avaliação automática de interfaces, tais como no
projeto TRIDENT [Bodart et al 1995] e em [Lecerof & Paterno 1998]. No entanto, é
um consenso que há limites sobre o que pode de fato ser avaliado automaticamente
[Farenc et al 1996].
7. Considerações Finais
Neste tutorial destacamos alguns tópicos de AT e MT que consideramos merecer
atenção. Modelos de tarefa devem a nosso ver fazer parte da teoria e da prática de
design de sistemas interativos. Apresentamos alguns conceitos introdutórios, e
fundamentos de técnicas para realizar AT e de alguns modelos existentes para
representar tarefas. Os possíveis usos de MT foram também preliminarmente
discutidos. Nossa ênfase aqui nos fundamentos de CTT e no CTTE permite sua adoção
imediata. Evidentemente há muito material disponível na literatura e na Internet. A lista
de bibliografia aponta apenas alguns que julgamos importantes. Nossa intenção era dar
uma visão panorâmica sobre o assunto mais do que ter a pretensão de ser exaustivo.
Mesmo assim, os autores esperam que este tutorial desperte a curiosidade e estimule
mais e mais pessoas a conhecerem e colocarem em prática estas idéias.
Bibliografia
[Balbo et al. 2004 ] Sandrine Balbo, Nadine Ozkan & Cecile Paris. Choosing the right
task modelling notation: A Taxonomy. In: Diaper, D. and Stanton, N. (Eds.), The
Handbook of Task Analysis for Human-Computer Interaction, Lawrence Erlbaum
Associates, Mahwah, 2004.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Bastide & Palanque 1999] Bastide, R., Palanque, P., A Visual and Formal Glue
between Application and Interaction, International Journal of Visual Language and
Computing, Academic Press, V.10, N. 6, 1999.
[Baumeister et al. 2000] Baumeister L., John B., Byrne M., A Comparison of Tools for
Building GOMS Models, Proceedings CHI’2000, pp.502-509, ACM Press, 2000.
[Benyon 92] Benyon, D. Task Analysis and System Design: the Discipline of Data.
Interacting with Computers, 4(2), 246-59, 1992.
[Benyon 96] Benyon, D.; Palanque, P. Critical Issues in User Interface System
Engineering.(s,l):springer Verlag, 1996. 294p.
[Birnbaum et al. 1998] Birnbaum, L., Bareiss, R., Hinrichs, T., Johnson, C.: Interface
Design Based on Standardized Task Models. In: Proc. of ACM Int. Conf. on
Intelligent User Interfaces IUI’98 (San Francisco, January 1998). ACM Press, New
York (1998) 65–72
[Bodart 94] Bodart, F. et alli. A Model-Based Approach to Presentation: A Continuum
from task Analysis to Prototype. Proc. of International Eurographics Workshop on
Design, Specification and Verification of Interactive Systems, Bocca di Magra (La
Spezia), 8-10 juin 1994.
(Bodart et al 1995) F. Bodart, A.-M. Hennebert, J.-M. Leheureux, I. Provot, B. Sacré, J.
Vanderdonckt, Towards a Systematic Building of Software Architectures: the
TRIDENT methodological guide, in Proc. of 2nd Eurographics Workshop on Design,
Specification, Verification of Interactive Systems DSV-IS'95 (Toulouse, 7-9 juin
1995), Ph. Palanque & R. Bastide (eds.), Springer-Verlag, Vienne, 1995, pp. 262278.
[Bolognesi 87] Bolognesi, T. and Brinksma, E. Introduction to the ISO Especification
Language LOTOS. Computer Networks ISDN Systems 14: 25-59. 1987.
[Bomsdorf & Szwillus 2003] vBomsdorf, Birgit; Szwillus, Gerd: User-Centered
Modeling of Interactive Web Sites, Poster: In: CD-ROM Proceedings of WWW
2003, Budapest, May 2003, 2003
[Booch et al 1999] Booch, G., Rumbaugh, J., Jacobson, I., Unified Modeling Language
Reference Manual, Addison Wesley, 1999.
[Breedvelt 97] Breedvelt, I., Paternò, F. & Severiins, C., Reusable Structures in Task
Models, Proceedings Design, Specification, Verification of Interactive Systems '97,
Granada, June 1997, Springer Verlag, pp.251-265. the Navigational Structure of a
User Interface, In Proceedings of INTERACT 2003, Sept. 2003, Zurich, IOS Press,
pp.455-462.
[Brun 95] Brun, P.; Beaudouin-Lafon, M. A taxonomy and evaluation of formalisms for
the specification of interactive systems. HCI'95, 1995, Huddersfield (UK). People
And Computers X – Proc, Huddersfield (UK): Cambridge University Press, Aug.
p.197-212.
[Byrne et al 1999] Byrne, M.; John, B. E.; Wehrle, N. S.; Crow, D. C. The Tangled
Web We Wove: A Taskonomy of WWW Use. Proc. of CHI99 15-20 May, 1999. P.
544- 551.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Card 83] Card, S.; Moran, T.; Newell, A. The Psychology of Human Computer
Interaction, Lawrence Erlbaum Associates, 1983.
[Chase 94] Chase, J.D. et al. Development and Evaluation of Taxonomical Model of
Behavioral Representation Techniques. In: Human Factor in Computing Systems,
(CHI’94), 1994, Boston, Massachusetts –USA. Anais... Boston, Massachusetts –
USA: Apr. P. 159-165. [Diaper 89] Diaper, D. (ed) Task Analysis for HCI, Ellis
Worwood, Chichester, 1989.
[Chung et al 2000] Chung L,Nixon B,Yu E,Mylopoulos J. Non-functional requirements
in software engineering.Kluwer,Dordrecht,2000
[Constantine & Lockwood 1999] Constantine, L. L., and Lockwood, L. A. D. Software
for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered
Design. Reading, MA: Addison-Wesley, 1999.
[Cybis 1996] Ergonomia de Interfaces Homem-Computador , Apostila do Curso de
Pós-Graduação em Engenharia de Produção da UFSC, 1996. Disponível em
http://www.labiutil.inf.ufsc.br/apostila.htm.
[Cysneiros et al. 2001] Cysneiros, L.M., Leite, J.C.S.P., ., Neto, J.M.S. A Framework
for Integrating Non-Functional Requirements into Conceptual Models. IN:
Requirements Engineering Journal: Vol. 6, N. 2, Pags. 97 -115, (2001), SpringerVerlag London Limited .
[De Troyer & Leune 1998] O.M.F. De Troyer, C.J. Leune WSDM: A User Centered
Design Method for Web Sites. Proceedings of the 7th International World Wide Web
Conference, Elsevier, pp. 85 - 94, 1998.
[Diaper 89a] Diaper, D. Task analysis for human-computer interaction. Chichester,
England: Ellis Horwood, 1989.
[Diaper 89b] Diaper, D. Task Analysis for Knowledge Descriptions (TAKD): The
method and examples. In D. Diaper (Ed.), Task analysis for human-computer
interaction (pp. 108–159). Chichester, England: Ellis Horwood.
[Diaper 2001] Diaper, D. Task Analysis for Knowledge Descriptions (TAKD): a
Requiem for a method. Behaviour and Information Technology 20(3), 199-212,
2001.
[Diaper 2002] Diaper, D. Scenarios and Task Analysis, Interacting with Computers, 14
(2002) 379-395.
[Draper 85] Draper, S.W.; Norman, D. Software Engineering for User Interfaces IEEE
Transactions on Software Engineering, SE-11, 252-58, 1985.
[Eisenstein & Rich 2002] Eisenstein, J. & Rich, C. Agents and GUIS from Task Models,
Proc. of Inteligent User Interfaces IUI 2002, San Francisco, USA.
[Farenc et al. 1996] Christelle FARENC, Véronique LIBERATI, Marie France
BARTHET Automatic Ergonomic Evaluation : What are the Limits ? Proc. of
CADUI'96 2nd International Workshop on Computer-Aided Design of User
Interfaces - Namur, Belgique, 5-7 June 1996.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Gray et al. 1992] Gray, W., John, B., Atwood, M., Project Ernestine: A Validation of
GOMS for Prediction and Explanation of Real-World Task Performance, HumanComputer Interaction, 8, 3, pp. 207-209, 1992.
[Greenberg 2004]. Working Through Task-Centered System Design. In: . In: Diaper, D.
and Stanton, N. (Eds.), The Handbook of Task Analysis for Human-Computer
Interaction, Lawrence Erlbaum Associates, Mahwah, 2004.
[Hartson et al 90] Hartson, R. et alli The User Action Notation: A User-Oriented
Representation for Direct Manipulation Interfaces, ACM Transactions on
Information Systems, V. 8, N. 3, 1990, 181-203.
[Jacobson et al 1992] Jacobson, I. et al. Object Oriented Software Engineering – A UseCase Driven Approach, ACM Press, 1992.
[John & Kieras 1996] John, B., Kieras, D., The GOMS Family of Analysis Techniques:
Comparison and Contrast. ACM Transactions on Computer-Human Interaction,
Vol.3, N.4, pp.320-351, 1996.
[Johnson 88] Johnson, P.; Johnson, H.; Waddington, R. and Shouls,A. Task-Related
Knowledge Structures: Analysis, Modelling and Application. In: D.M.Jones; R.
Winder (eds.). People and Computers: From Research to Implementation, HCI’88,
Cambridge University Press, pp 137-55.
[Johnson 91] Johnson, H.; Johnson, P. Task Knowledge Structure: Psychological basis
and Integration into System Design. Acta Psychologica, 78, 1991, pp 3-26.
[Johnson 92] Johnson, P. Human-Computer Interaction: Psychology, Task Analysis
and Software Engineering, Mc-Graw Hill, Maidenhead, UK, 1992.
[Johnson et al. 1995] Johnson, P., Johnson, H., Wilson, S.: Rapid Prototyping of User
Interfaces Driven by Task Models. In: Carroll, J.M. (ed.). Scenario-based Design:
Envisioning Work and Technology in System Development. John Wiley, New York
(1995) 209–246
[Kieras 1996] Kieras D.E., Guide to GOMS model usability evaluation using NGOMSL,
in The Handbook of Human-Computer Interaction, 2nd edition, North Holland 1996.
[Lecerof & Paterno 1998] Lecerof, A., Paternò, F., Automatic Support for Usability
Evaluation, IEEE Transactions on Software Engineering, October, pp. 863-888,
IEEE Press, 1998.
[Limbourg 2001] Limbourg, Q.; Pribeanu, C.; Vanderdonckt, J. Towards Uniformised
Task Models in a Model Based Approach, in Proc. of 8th International Workshop on
Design, Specification, Verification of Interactive Systems DSV-IS'2001 (Glasgow,
13-15 juin 2001), Ch. Johnson (eds.), Lecture Notes in Computer Science, Vol. 2220,
Springer-Verlag, Berlin, 2001, pp. 164-182.
[Moran 81] Moran, T. The Command Language Grammar : A Representation for the
User Interface of Interactive Computer Systems, International Journal of ManMachine Studies, v. 15, pp. 3-50, 1981.
[Mori 02] Mori, G., Paternò, F. and Santoro, C. CTTE: Support for Developing and
Analyzing Task Models for Interactive System Design. IEEE Transactions on
Software Engineering: 797-813. 2002.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Mylopoulos et al 1992] Mylopoulos J,Chung L,Yu E,Nixon B. Representing and using
non-functional requirements:a process-oriented approach. IEEE Trans Software Eng
1992;18(6):483 –497
[Navarre et al. 2001] Navarre, D.; Palanque, P.; Bastide, R.; Paternó, F.; Santoro, C. A
tool suite for integrating task and system models through scenarios. IN: Proc. of 8th
Eurographics workshop on Design, Specification and Verification of Interactive
Systems, DSV-IS'2001, June 13-15, 2001, Glasgow, Scotland.
[Newman & Landay 2000] Newman, M. W.; Landay, J. A. Sitemaps, storyboards, and
specifications: a sketch of Web site design practice. Proceedings of DIS 2000, ACM
Press New York, NY, USA. Pages: 263 – 274.
[Palanque 95] Palanque, P.; Bastide, R.; SENGES, V. Task model – system model:
towards an unifying formalism. In: International CONFERENCE ON HUMANCOMPUTER INTERACTION, (HCI international 95). Japan. 1995.
[Palanque & Paterno 1997] Philippe Palanque & Fabio Paterno(Eds.) Formal Methods
in Human-Computer Interaction Springer Verlag 1997. ISBN 3-540-76158-6. 376
pages.
[Paquette 2004] Paquette, D.; Schneider, K. A. Interaction templates for construct-ing
user interfaces from task models. In Fourth International Conference on ComputerAided Design of User Interfaces (2004), pp. 223–235.
[Paterno 97] Paterno, Mancini, Meniconi. ConcurTaskTrees: a Diagrammatic Notations
for Specifying Task Models, Proc. of INTERACT 97, pp 362-69, July 97, Sydney,
Chapman&Hall.
[Paterno et al. 1998] Paternò, F., Breedvelt-Shouten, I.M., de Koning, N.M.: Deriving
Presentations from Task Models. In: Proc. of IFIP Workshop on Engineering the
Human-Computer Interaction EHCI’98 (Creete, September 1998). Kluwer
Academics Publisher, Dordrecht (1998)
[Paterno 1999] Model-Based Design and Evaluation of Interactive Application.
Springer Verlag, Berlin, 1999.
[Paternó 2001] Paternó, F. Task models in interactive software systems. In Handbook of
Software Engineering and Knowledge Engineering, S. K. Chang, Ed. World
Scientific Publishing Co., 2001.
[Payne 86] Payne, S.J.; Green, T.R. Task Action Grammar: a Model of the Mental
Representation of Task Languages, Human-Computer Interaction, 2, pp 93-133,
1986.
[Preece 02] Preece, J., Rogers, Y. & Sharp, H. (2002) Interaction Design: Beyond
Human-Computer Interaction. New York, NY: John Wiley & Sons. (519 pages).
[Rodriguez & Scapin 1997] Rodriguez, F. G. and Scapin, D. L. Editing MAD* task
descriptions for specifying user interfaces, at both semantic and presentation levels.
In Proceedings of theEurographics Workshop (DSV-IS'97): Design, Specification,
and Verification of Interactive Systems '97. Granada, Spain. M. D. Harrison, J. C.
Torres (Ed). Springer-Verlag/Wien. 193:208.
[Scapin 89] Scapin, D.; Pierret-Golbreich, C. Towards a Method for Task Description:
MAD. In: Work With Display Units'89, Amsterdam, Elseiver, 1989.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Scapin & Bastien 2001] Scapin, D. and Bastien, C. (2001) Analyse des tâches et aide
ergonomique à laconception: l'approche MAD*. In Interactions Homme-Machine
pour les Systèmesd'Information, Tome 1: Analyse et conception de l'IHM. C. Kolski
(ed.). Hermès.
[Sebillote 95] Sebillotte, S. Methodology guide to task analysis with the goal of
extractingrelevant characteristics for interfaces. Technical report for Esprit project
P6593. INRIA,Rocquencourt (France), 1995.
[Shneiderman 98] Shneiderman, B. Designing the User Interface:Strategies for
Effective Human-Computer Interaction. ed.3. USA:ADDISON-WESLEY, 1998.
639p.
[SIGCHI Bulletin 1997] Human Computer Interaction and Requirements Engineering:
Papers from an Interdisciplinary Workshop, ACM SIGCHI Bulletin, V. 29, N. 1,
January 1997.
[Siochi 91] Siochi, A. ; Hix, D. ; Hartson, H. R. The UAN: a Notation to Support UserCentered Design of direct Manipulation Interface. In: John Karat (Ed). Taking
Software Design Seriously. New York: ACADEMIC PRESS, 1991. Cap. 9, p. 157194.
[Storrs 95] Storrs, G. The Notion of Task un Human-Computer Interaction. In: Proc. of
HCI 95- 10th Annual conference of the British Human-Computer interaction Group,
University of Huddersfield, UK, August-september 1995.
[Szwillus & Bomsdorf 2002] Szwillus, Gerd; Bomsdorf, Birgit: Models for TaskObject-Based Web Site Management, Paper. In: Proceedings of DSV-IS 2002,
Rostock, Juni 2002, 2002
[Szwillus & Bomsdorf 2003] Szwillus, Gerd; Bomsdorf, Birgit: Task-Object Models for
the Development of Interactive Web Sites, Proceedings of HCI International, June
2003, 2003
[Tauber 90] Tauber, M., ETAG: Extended Task Action Grammar—A language for the
Description of the User’s Task Language, Proceedings INTERACT’90, pp.163-174,
Elsevier, 1990.
[van der Veer 96] van der Veer, G., Lenting, B., Bergevoet, B., GTA: Groupware Task
Analysis—Modelling Complexity, Acta Psychologica, 91, pp. 297-322, 1996.
[Vanderdonckt & Bodart 1993] Vanderdonckt, J., Bodart, F.: Encapsulating Knowledge
for Intelligent Interaction Objects Selection. In: Proc. of ACM Conf. on Human
Aspects in Computing Systems InterCHI’93 (Amsterdam, 24-29 April 1993). ACM
Press, New York (1993) 424–429.
[Walsh 89] Walsh, P. Analysis for Task Object Modelling (ATOM). .In: Diaper, D. (ed.)
Task-Analysis for Human-Computer Interaction, Ellis Horwood, 1989.
[Welie 98] van Welie M., van der Veer G.C., Eliëns A., An Ontology for Task World
Models, Proceedings DSV-IS’98, pp.57-70, Springer Verlag, 1998.
[Wilson & Johnson 1996] Wilson, S., & Johnson, P. (1996). Bridging the generation
gap: From work tasks to user interface designs. In: J. Vanderdonckt (Ed.), Computeraided design of user interfaces (pp. 77–94). Namur, Belgium: Presses Universitaires
de Namur.
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
Análise e Modelagem de Tarefas
[Winckler et al. 2002] Winckler Marco, Palanque Philippe, Farenc Christelle, Pimenta
Marcelo. Task-Based Assessment of Web Navigation Design. Proc. of TAMODIA'02
Task Models and Diagrams for User Interface Design 2002, Bucharest, Romania
[UsabGlossary]
Usability
First:
Usability
Glossary
http://www.usabilityfirst.com/glossary/index_terms.txl (Acesso 06/08/2004)
IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.
.