irit - análise e modelagem de tarefasmarco.winckler/publications/2004-ihc... · 2011-07-21 ·...

IHC’2004 – Tutorial, Curitiba, PR. 17-20 Outubro de 2004.

Análise e Modelagem de Tarefas

Marco A. A. Winckler1, Marcelo Soares Pimenta2

IHC2004 (Tutorial)*

1 LIIHS-IRIT (Université Paul Sabatier, Toulouse 3), 118 route de Narbonne, 31062 Toulouse CEDEX 4, France

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

* Este material de apoio foi confeccionado como complemento ao material (slides, software, etc) usado pelos ministrantes durante o tutorial.

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



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



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



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ós- condiçõ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



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ão-decomponí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



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.



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ós-condiçõ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.

TAREFA: Selecionar aeroporto destino AÇÕES DO USUÁRIO

FEEDBACK DA INTERFACE ESTADO DA INTERFACE

~(Lista de aeroportos destino) M∨

Lista de aeroportos destino aparece

~(Item da lista de aeroportos destino)

Nome de aeroporto !

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



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

~ Move o cursor [X] Contextodo objeto X, no qual ele é manipulado ~[X] Move o cursor para o contexto do objeto X ~[x,y] Move o cursor para uma posição arbitrária (x, y) ~[x, y in A] Move o cursor para uma posição arbitrária (x, y) dentro do objeto A ~[X in Y] Move o objeto X para dentro do objeto Y. [X]~ Move o cursor fora do contexto do objeto X. ∨ Pressionar ∧ Liberar X∨ Aperte o botão, chave ou interruptor X. X∧ Libere o botão, chave ou interruptor X. X∧∨ Clicar botão, chave ou interruptor X X”abc” Entrada do literal “abc”, via teclado. X(xyz) 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). A B Tarefas A e B devem ser executadas na ordem da esquerda para direita ou de cima para baixo (AB). OR 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 (!-!)n Objeto piscando na tela n vêzes. @x, y Numa posição específica (x, y) @X Na posição onde se encontra o objeto X. Exibe(X) Mostra o objeto X na tela Apaga(X) Apaga o objeto x da tela. X>~ O objeto X é arrastado pelo cursor. X>>~ O objeto X muda de tamanho enquanto segue o cursor Contorno(X) 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



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.



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:



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



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.



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 Descrição

escolha [ ] T1 [ ] T2 é possível escolher uma tarefa, outras tarefas ficam indisponíveis até a tarefa escolhida terminar;

independência de ordem |=| T1 |=| T2

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

concorrência independente ||| T1 ||| T2

tarefas podem ser executadas em qualquer ordem sem nenhuma restrição. Ex. Monitorar uma tela e falar em um microfone.

concorrência com troca de informações |[]| T1 |[]| T2 as duas tarefas podem ser executadas em paralelo

mas devem se sincronizar para trocar informações

desativação [> T1 [> T2 a primeira tarefa é definitivamente desativada quando a segunda tarefa inicia (ex. Seleção de botões)

suspende/ continua |> T1 |> T2

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

habilitação >> T1 >> T2 quando a T1 termina a T2 é ativada habilitação com passagem de informação

[ ]>> T1 [ ]>> T2 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 Descrição

iteração * T * a tarefa é iterativa, a tarefa termina apenas quando for desativada por outra tarefa

opcionalidade [ ] [ T ] uma tarefa representada entre colchetes ([ ]) é indicada como opcional

conexão entre modelos ↔

T ↔

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.



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.



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.



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.



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.

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 inicia-se 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.

Tarefa: modificar



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.



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.

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.

Lista de tarefas a serem executadas



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



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 Responsabilidade do Sistema Identificar-se Verificar Identificação

Fornecer Opções de Operação Acionar Operação de Saque Verificar Opção Acionada

Solicitar valor de saque Fornecer Valor para Sacar Verificar se valor é válido

Verificar se há saldo disponível Processar saque da conta Disponibilizar cédulas e recibo

Retirar 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



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.



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.



[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. 262-278.

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



[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), Springer-Verlag 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.



[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, Human-Computer 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 Use-Case 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 Man-Machine 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.



[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 HUMAN-COMPUTER 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 Computer-Aided 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.



[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 User-Centered Design of direct Manipulation Interface. In: John Karat (Ed). Taking Software Design Seriously. New York: ACADEMIC PRESS, 1991. Cap. 9, p. 157-194.

[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 Task-Object-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.), Computer-aided design of user interfaces (pp. 77–94). Namur, Belgium: Presses Universitaires de Namur.



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

irit - análise e modelagem de tarefasmarco.winckler/publications/2004-ihc... · 2011-07-21 ·...

Documents