Análise e Modelagem de Tarefas

Transcrição

1 Marco A. A. Winckler 1, Marcelo Soares Pimenta 2 IHC2004 (Tutorial) * 1 LIIHS-IRIT (Université Paul Sabatier, Toulouse 3), 118 route de Narbonne, Toulouse CEDEX 4, France 2 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brasil winckler@irit.fr,mpimenta@inf.ufrgs.br 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.

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

3 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

4 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

5 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

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

7 4.1 Método Analítico de Descrição de tarefas 2 (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 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 ~(Item da lista de aeroportos destino) M TAREFA: Selecionar aeroporto destino FEEDBACK DA INTERFACE ESTADO DA INTERFACE Lista de aeroportos destino aparece Nome de aeroporto! 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".

8 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 y Numa posição específica (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

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

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

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

12 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) 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.

13 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 Forma 3 Descrição escolha [ ] T1 [ ] T2 é possível escolher uma tarefa, outras tarefas ficam indisponíveis até a tarefa escolhida terminar; ambas as tarefas devem ser realizadas, em qualquer independência de = T1 = T2 ordem, mas deve-se esperar a finalização de uma ordem delas para dar prosseguimento a tarefa seguinte tarefas podem ser executadas em qualquer ordem concorrência T1 T2 sem nenhuma restrição. Ex. Monitorar uma tela e falar independente em um microfone. concorrência com as duas tarefas podem ser executadas em paralelo [] T1 [] T2 troca de informações 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 T indica que a tarefa sublinhada com o símbolo pode ser usada em modelo cooperativo onde modelos 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.

14 3. Identificação de objetos associados a cada tarefa e ações que permitem que os objetos comuniquem entre si 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 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.

15 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) 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) 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.

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

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

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

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

20 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