3URMHWRHLPSOHPHQWDomRGRPyGXOR7$26 *UDSK …docs.computacao.ufcg.edu.br/posgraduacao/disserta... ·...

1

Universidade Federal de Campina Grande Centro de Ciências e Tecnologia

Coordenação de Pós-Graduação em Informática ��

3URMHWR�H�LPSOHPHQWDomR�GR�PyGXOR�7$26�*UDSK�GD�IHUUDPHQWD�L7$26�SDUD�DQiOLVH�H�PRGHODJHP�

GD�WDUHID��

)UDQFLVFR�3HWU{QLR�$OHQFDU�GH�0HGHLURV�

Campina Grande - PB Fevereiro de 2003

2

Universidade Federal de Campina Grande Centro de Ciências e Tecnologia

Coordenação de Pós-Graduação em Informática 3URMHWR�H�LPSOHPHQWDomR�GR�PyGXOR�7$26�*UDSK�

GD�IHUUDPHQWD�L7$26�SDUD�DQiOLVH�H�PRGHODJHP�GD�WDUHID�

��

Dissertação submetida à Coordenação de Pós-Graduação em Informática do Centro de Ciências e Tecnologia da Universidade Federal de Campina Grande, Campus I como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (MSc).

��,QVWLWXLomR� Universidade Federal de Campina Grande ÈUHD�GH�&RQFHQWUDomR� Ciência da Computação /LQKD�GH�3HVTXLVD� Engenharia de Software

��

)UDQFLVFR�3HWU{QLR�$OHQFDU�GH�0HGHLURV�Orientador: Bernardo Lula Jr., Dr.

Campina Grande - PB Fevereiro de 2003

3

3URMHWR�H�LPSOHPHQWDomR�GR�PyGXOR�7$26�*UDSK�GD�IHUUDPHQWD�L7$26�SDUD�DQiOLVH�H�PRGHODJHP�GD�WDUHID��

��

)UDQFLVFR�3HWU{QLR�$OHQFDU�GH�0HGHLURV�

Bernardo Lula Jr., Dr., UFCG Orientador

Francilene Procópio Garcia, Dsc., UFCG Componente da Banca

Maria Elizabeth Sucupira Furtado, DsC., UNIFOR Componente da Banca

Maria de Fátima Queiroz Vieira Turnell, Ph.D., UFCG Componente da Banca

Campina Grande, fevereiro de 2003 �

4

��

(VWH�WUDEDOKR�p�GHGLFDGR�D�PLQKD�IDPtOLD��*DEULHO��)iWLPD��

3DWUtFLD��0DQRHO�1HWR�H�*DEULHOD��*DE\��

5

$JUDGHFLPHQWRV��

A Deus, por essa vida maravilhosa.

Aos meus pais, Gabriel e Fátima, pelo esforço constante em favor da minha formação.

Aos meus irmãos, Manoel Neto (Neneto), Patrícia (Teté) e Gabriela (Gaby), pela

cumplicidade, força e amizade.

A toda minha família, pelo apoio recebido.

Ao meu orientador, Bernardo Lula, pelo grande aprendizado durante todo este período

e pelas discussões periódicas na busca de um trabalho bem feito.

Ao amigo e colega de projeto Pedro, por enfrentarmos juntos os dias enfurecidos de

Bernardo e por compartilharmos os momentos de sucesso.

A professora Fátima Turnell, ao professor Eustáquio e ao professor Marconi, pela

colaboração nesse trabalho. Aos professores do DSC que despertaram meu lado acadêmico e

que me forneceram grande conhecimento.

Ao meu professor e amigo Hamurabi, pelos conselhos na vida pessoal e profissional.

Aos meus grandes amigos Alisson, Alexandre, Philip e Claudivan, pelo incentivo nos

momentos de stress e companhia nas horas de alegria.

Aos colegas e amigos de apartamento, Alisson, Eloi, Alex, Heronides (Lula) e Daniel

(BA), por proporcionarem um astral sempre positivo no ambiente de estudo.

A todos meus amigos de Campina Grande e Patos.

A todos os funcionários do DSC, em especial a Aninha,Vera e Zeneide.

A Dona Inês e Dona Maria, pelos almoços e cafezinhos.

A todos que contribuíram diretamente ou indiretamente para que eu alcançasse mais

essa etapa da minha vida.

i

6XPiULR�6XPiULR��L /LVWD�GH�ILJXUDV�� LY

/LVWD�GH�WDEHODV �� Y

/LVWD�GH�GHVFULWRUHV �� YL 5(6802 ��YLL $%675$&7��YLLL

��,QWURGXomR ��

�� ,QGHSHQGrQFLD�GR�GLiORJR ��

�� $QiOLVH�GD�WDUHID��

�� 0HWRGRORJLDV�GH�FRQFHSomR�EDVHDGDV�QD�WDUHID��

�� 7$26�±�7DVN�DQG�$FWLRQ�2ULHQWHG�6\VWHP��

�� 3UREOHPiWLFD ��

�� 2EMHWLYRV�GR�WUDEDOKR ��

��+LSyWHVHV��

��0HWRGRORJLD�GH�WUDEDOKR��

��(VWUXWXUD�GD�GLVVHUWDomR��

��)RUPDOLVPR�7$26�SDUD�DQiOLVH�H�PRGHODJHP�GH�WDUHIDV�QR�FRQWH[WR�GR�SURMHWR�GH�LQWHUIDFHV�GR�XVXiULR ��

��7$26��,QWHOLJrQFLD�$UWLILFLDO ��

��0RGHOR�7$26 �� 2.2.1. Conceitos estáticos..............................................................................................13 2.2.2. Conceitos dinâmicos ...........................................................................................15

��9DOLGDomR�GH�7$26�IDFH�0$'��

��7$26��0RGHODJHP�GD�WDUHID ��

��&RQVLGHUDo}HV�ILQDLV��

��0(',7(�±�8PD�PHWRGRORJLD�EDVHDGD�QD�WDUHID�H�RULHQWDGD�D�PRGHORV�SDUD�FRQFHSomR�GH�LQWHUIDFHV�HUJRQ{PLFDV ��

��'HVFULomR�GH�0(',7(�� 3.1.1. Análise e modelagem da tarefa............................................................................23 3.1.2. Especificação conceitual parcial da interação ......................................................23 3.1.3. Definição dos atributos .......................................................................................24 3.1.4. Geração do protótipo...........................................................................................24

ii

��0RGHOR�0$' �� 3.2.1. Conceitos definidos por MAD*...........................................................................25

��0RGHOR�(',725�� 3.3.1. Agentes do modelo EDITOR ..............................................................................28

��%DVH�GH�UHJUDV�HUJRQ{PLFDV ��

��6XSRUWH�FRPSXWDFLRQDO��)HUUDPHQWDV��


��$QiOLVH�H�PRGHODJHP�GD�WDUHID�³8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV´ ��

��$QiOLVH�H�PRGHODJHP�GD�WDUHID�QD�PHWRGRORJLD�0(',7( ��

��$QiOLVH�H�0RGHODJHP�GD�7DUHID�� 4.2.1. Aquisição de dados sobre a tarefa e sobre o usuário ............................................34 4.2.2. Descrição da tarefa utilizando TAOS ..................................................................35

��$YDOLDomR�GD�PRGHODJHP��


��(VSHFLILFDomR�FRQFHLWXDO�GD�LQWHUDomR ��

��(VSHFLILFDomR�FRQFHLWXDO�GD�LQWHUDomR�QD�PHWRGRORJLD�0(',7(��

��(VSHFLILFDomR�FRQFHLWXDO�SDUFLDO�GD�LQWHUDomR��

��(VSHFLILFDomR�FRQFHLWXDO�FRPSOHWD�GD�LQWHUDomR��

��$YDOLDomR�GD�(VSHFLILFDomR ��

��,QWHJUDomR�GRV�PyGXORV�7$26�*UDSK�H�7$0(��


��3URWyWLSR�GD�LQWHUIDFH��

��3URWyWLSR�GD�LQWHUIDFH�QD�PHWRGRORJLD�0(',7(��

��)UDPHZRUN�-+RW'UDZ�� 6.2.1. Processo de desenvolvimento típico Usando o JHotDraw....................................52

��&ODVVHV�TXH�FRPS}HP�R�VLVWHPD��

��$SUHVHQWDomR�GH�L7$26 ��


��,QVSHomR�GD�XVDELOLGDGH�GR�SURWyWLSR�GD�LQWHUIDFH�GD�IHUUDPHQWD�L7$26 ��

��2�SDGUmR�,62��

��0HWRGRORJLD�XWLOL]DGD�QD�LQVSHomR�GD�XVDELOLGDGH��

��3UREOHPDV�LGHQWLILFDGRV�QR�SURGXWR�D�SDUWLU�GD�LQVSHomR�GH�XVDELOLGDGH��

��7D[DV�GH�DGRomR�FRP�EDVH�QR�SURFHVVR�GH�LQVSHomR��

iii


��&RQFOXVmR��

��'LVFXVVmR�GRV�UHVXOWDGRV��

��&RQWULEXLo}HV ��

��3URSRVWDV�GH�FRQWLQXLGDGH��

5HIHUrQFLDV�%LEOLRJUiILFDV��

�$SrQGLFH��±�)RUPXOiULR�'H3HU8VH ��$SrQGLFH��±�3HUILO�GR�XVXiULR��$SrQGLFH��±�/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62��$SrQGLFH��±�/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62��$SrQGLFH��±�/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62��

�

iv

/LVWD�GH�ILJXUDV�

FIGURA 1. META-MODELO TAOS..........................................................................................12

FIGURA 2. METODOLOGIA MEDITE......................................................................................23

FIGURA 3. CONCEITOS DEFINIDOS POR MAD* .......................................................................25

FIGURA 4. ORGANIZAÇÃO DOS AGENTES DE UM EDITOR .........................................................29

FIGURA 5. ANÁLISE E MODELAGEM DA TAREFA NA METODOLOGIA MEDITE..........................33

FIGURA 6. TAREFA “MODELAR_TAREFAS_UTILIZANDO_ITAOS” ...........................................35

FIGURA 7. TAREFA “EDITAR_AGENTE” .................................................................................36

FIGURA 8. ESPECIFICAÇÃO CONCEITUAL DA INTERAÇÃO NA METODOLOGIA MEDITE.............40

FIGURA 9. ÁRVORE EDITOR PARCIAL DA TAREFA "MODELAR TAREFA" ................................42

FIGURA 11. ÁRVORE EDITOR PARCIAL DA TAREFA "EDITAR AGENTE" ..................................43

FIGURA 12. ÁRVORE EDITOR COMPLETA DA TAREFA "MODELAR TAREFA" ...........................45

FIGURA 13. ÁRVORE EDITOR COMPLETA DA TAREFA "REALIZAR MODELAGEM" ...................46

FIGURA 14. ÁRVORE EDITOR COMPLETA DA TAREFA "EDITAR AGENTE"...............................47

FIGURA 15. PROTÓTIPO DA INTERFACE NA METODOLOGIA MEDITE.......................................50

FIGURA 16. ESTRUTURA EM PACOTES DO FRAMEWORK JHOTDRAW........................................51

FIGURA 17. DIAGRAMA DAS PRINCIPAIS CLASSES DO MÓDULO TAOS-GRAPH DA FERRAMENTA

ITAOS..........................................................................................................................53

FIGURA 18. TELA INICIAL DA FERRAMENTA ITAOS ...............................................................54

FIGURA 19. TELA QUE MOSTRA O MENU FILE ABERTO ............................................................55

FIGURA 20. TELA QUE MOSTRA UM MODELO ABERTO .............................................................55

FIGURA 22. TELA QUE MOSTRA O DESCRITOR DE UMA AÇÃO ABERTO ......................................56

FIGURA 22. TELA QUE MOSTRA O DESCRITOR DE UM AGENTE ABERTO ....................................57

FIGURA 23. JANELA QUE APRESENTA AS AÇÕES DO MODELO ABERTO......................................58

FIGURA 24. FLUXOGRAMA EMPREGADO NA INSPEÇÃO DA USABILIDADE ................................62

v

/LVWD�GH�WDEHODV�TABELA 1. PARTES INTEGRANTES DO PADRÃO ISO 9241........................................................60

TABELA 2 – TAXAS DE ADOÇÃO DO ITAOS ÀS PARTES 14, 16 E 17 DO ISO 9241....................65

vi

/LVWD�GH�GHVFULWRUHV�DESCRITOR 1: CLASSE TAREFA 5�� B�� ..............................................................36

DESCRITOR 2. CLASSE SITUAÇÃO 6�� B,� �� B� � B5�� B0 �� .........................37

DESCRITOR 3. CLASSE SITUAÇÃO 6�� B2 �! �"�#�%$ B� � B5��&�'�� B0 �� %�� ......................37

DESCRITOR 4. CLASSE MÉTODO 0( � ��) B5�� B0 �� ..............................................37

DESCRITOR 5: CLASSE PLANO (� ��*�� B�+ �� B�� ................................................................37

DESCRITOR 6. CLASSE SITUAÇÃO 6�� B,� �� B� � B(� ��*�� B1 �� B$ �� .........................38

DESCRITOR 7. CLASSE SITUAÇÃO 6�� B2 �! �"�#�%$ B� � B(� ��*�� B1 �� B$ �� ,� ......................38

DESCRITOR 8: CLASSE AGENTE 3 �! �-�#�&.�� B� � B,� ��/��0�� ........................................................38

DESCRITOR 9: CLASSE INSTRUMENTO $�1 �2� � �� B� � B0 �� ..............................................38

vii

5(6802�

Esse trabalho apresenta o processo de construção e implementação do módulo TAOS-

Graph da ferramenta iTAOS. iTAOS é uma ferramenta gráfica que implementa o formalismo

TAOS (Task and Action Oriented System) concebida para acompanhar o projetista de

interfaces durante a fase de análise e descrição da tarefa dentro de um processo de

desenvolvimento de interfaces, verificando a completude e consistência da representação.

TAOS-Graph foi desenvolvido utilizando a metodologia MEDITE, uma metodologia guiada

por modelos e baseada na tarefa para construção de interfaces ergonômicas. Os artefatos

gerados ao final de cada etapa do processo de desenvolvimento de TAOS-Graph foram: a

descrição TAOS da tarefa, a especificação conceitual da interação e o código da interface.

Como recomenda a metodologia, foi realizada uma inspeção de conformidade da ferramenta

iTAOS com as partes 14 (Menus), 16 (Manipulação direta) e 17 (Formulários) do padrão ISO

9241.

viii

$%675$&7�

This work presents the process of construction and implementation of the TAOS-

Graph module of the iTAOS tool. iTAOS is a graphical tool that implements the TAOS

formalism (Task and Action Oriented System) and is responsible for accompanying the

interface designer (iTAOS user) during domain task’s description and analysis phases within

the interface development process, verifying the completeness and the consistency of the

representation. TAOS-Graph was developed using the methodology MEDITE, a methodology

guided for models and based in the task for construction of ergonomic interfaces. The

artefacts generated to the end of each stage of the development process of TAOS-Graph had

been: description TAOS of the task, the conceptual specification of the interaction and the

code of the interface. As recommends the methodology, iTAOS was carried through an

inspection of conformity with the parts 14, 16 and 17 of the standard ISO 9241.

1

&DStWXOR��,QWURGXomR�

O campo da interação homem-computador é o estudo do indivíduo (usuário), da

tecnologia computacional (sistema) e do entendimento do trabalho (tarefa) que o indivíduo

tenta realizar utilizando essa tecnologia. No processo de interação usuário-sistema, a interface

é o combinado de software e hardware necessário para viabilizar e facilitar os processos de

comunicação entre o usuário e o sistema computacional utilizado para realizar a tarefa (Souza

at al., 1999).

Para o usuário, o sistema é apenas uma ferramenta e, como tal, exige, para ser

utilizado, um conhecimento e habilidade não somente do domínio da tarefa, mas também do

uso do sistema, envolvendo as funcionalidades e os meios disponíveis para utilizá-lo. Dessa

forma, aprender a usar o sistema torna-se uma tarefa adicional para o usuário, e, portanto,

deve exigir o menor esforço possível. Portanto, é de fundamental importância que o sistema

seja adaptado às características do usuário, às tarefas a serem executadas e ao ambiente de

trabalho, para que o esforço adicional de ter que aprender a usar o sistema seja o menor

possível. É nesse sentido que vem se exigindo, cada vez mais, dos projetistas desses produtos

e sistemas, uma preocupação com a qualidade da interface.

A meta é oferecer aos usuários sistemas com alto grau de usabilidade, ou seja, que

satisfaçam os requisitos de funcionalidade e sejam fáceis de usar, entender e aprender.

�� ,QGHSHQGrQFLD�GR�GLiORJR�Nos dias de hoje, os postos nas equipes que desenvolvem sistemas computacionais são

ocupados, principalmente, por profissionais de informática por formação e esses se

2

empenham, naturalmente, em definir, antes de tudo, as funções lógicas do sistema sem de fato

se preocuparem com o uso deste, ou seja, a interação com o usuário do sistema.

Na realidade, a maioria das metodologias tradicionais de desenvolvimento de software

não se preocupa com a interface do usuário, que passa a ser considerada apenas nas fases

finais do processo, tornando-se assim nada mais que um “ apêndice” do sistema.

As primeiras abordagens de concepção de sistemas interativos tinham uma tendência a

“ misturar” fortemente o código da interface com o código que implementa a funcionalidade

do sistema. A dificuldade de modificação proibia uma abordagem iterativa, praticamente

impedindo de se levar em conta as opiniões de especialistas em comunicação e os resultados

da observação do usuário durante a concepção e o desenvolvimento da interface.

Assim, como no campo de Banco de Dados, com o princípio da independência dos

dados, e como no campo da Inteligência Artificial, com o princípio da independência do

conhecimento, a solução preconizada para uma abordagem iterativa do desenvolvimento da

interface foi a separação modular entre o código da implementação (componente funcional) e

o código da interface (componente interativo). O componente funcional (ou aplicação) define

a funcionalidade do sistema, ou seja, as funções que a aplicação disponibiliza para a

realização de suas tarefas. O componente de interação (ou interface) é o software responsável

pelo diálogo entre o usuário e o sistema. Essa decomposição deve permitir se conceber,

desenvolver e modificar os módulos/componentes independentemente um do outro (Ehrich e

Hartson, 1981; Draper e Norman, 1985; Dodani et al., 1985). O SULQFtSLR�GH�LQGHSHQGrQFLD�GR� GLiORJR, termo consagrado para caracterizar essa decomposição, tem se tornado um

princípio essencial a respeitar no processo de concepção e desenvolvimento de sistemas

interativos, pelas razões já expostas, ou sejam:

L�� A possibilidade de um desenvolvimento independente dos módulos;

LL�� A possibilidade de um processo iterativo de concepção e desenvolvimento;

LLL�� A possibilidade de utilização de profissionais em comunicação (ergonomistas,

artistas gráficos, psicólogos da cognição, lingüistas, etc.);

LY�� A possibilidade de se construir diversas interfaces representando diversas maneiras

de comunicação, com uma mesma aplicação;

3

Y�� A possibilidade de reutilizar toda ou parte de uma interface para outra aplicação;

�� $QiOLVH�GD�WDUHID�A separação modular preconizada pelo princípio da independência do diálogo abriu

caminho para o uso da ergonomia no processo de concepção e desenvolvimento de interfaces

de qualidade.

Em Ergonomia, um princípio fundamental consagrado no projeto de ferramentas é a

necessidade de conhecimento do usuário e do trabalho a ser realizado (Cybis, 1996; Sebillote,

1995). O trabalho é visto segundo dois componentes básicos: a tarefa e a atividade

(Hammouche, 1995):

Tarefa: é descrita por um objetivo (o objetivo do usuário), uma lista de sub-tarefas (os

procedimentos) necessárias para atingir o objetivo, assim como suas restrições estruturais e

temporais. A definição de tarefa é recursiva, visto que uma sub-tarefa é também uma tarefa,

distinguindo-as apenas pelo nível de abstração. A recursividade pára quando a lista de sub-

tarefas só agrupa ações.

Atividade: Um conjunto de ações�HIHWXDGDV�SRU�XP�RX�PDLV�RSHUDGRUHV�KXPDQRV�HP�YLVWD�GH�UHDOL]DU�XP�RX�PDLV�REMHWLYRV. A atividade pode ser vista como a instanciação da

tarefa, ou simplesmente, a tarefa realizada��A análise da tarefa descreve o conjunto de tarefas com o objetivo de entender o

funcionamento cognitivo dos operadores (Sebillote, 1995) e é realizado a partir de entrevistas

dirigidas, observações, experimentos ou outros métodos habituais de pesquisa, buscando

evidenciar as características do processo de realização. O resultado da análise é um

documento (relatório) contendo uma descrição detalhada e hierarquizada do trabalho segundo

o ponto de vista do usuário.

Do ponto de vista da concepção de sistemas, o resultado da análise pode ser aplicado

para apoiar as ações do projetista em pelo menos três momentos: na especificação do sistema

(funcionalidades), no projeto da interface e na elaboração de manuais de treinamento

(Heemann, 1997).

4

No entanto, a utilização efetiva da análise da tarefa no processo de concepção e

desenvolvimento de interfaces não se deu que após a introdução de formalismos apropriados e

que pudessem ser entendidos tanto pelos ergonomistas quanto pelos projetistas de interfaces

e/ou sistemas. Estes formalismos têm surgido como tentativas de integrar a análise e a

descrição da tarefa ao processo de concepção de interfaces (Limbourg, Pribeanu e

Vanderdonckt, 2001), melhorando, com isso, a qualidade das descrições e maximizando a

completude e a coerência (Gamboa e Scapin, 1997).

Diversos formalismos foram propostos com essa finalidade e destacamos os seguintes

pelos seus graus de incidência na literatura a respeito: MAD (Méthode Analytique de

Description) (Scapin e Pierre-Golkbreich, 1989), TKS (Task Knowledge Structure) (Johnson

at al., 1988), ETAG (Tauber, 1988; Tauber, 1990; Haan, Van der Veer e Van Vliet, 1992;

Haan, 2000) e MAD* (Hammouche, 1995, Gamboa, 1998).

O Grupo de Interfaces Homem-Máquina (GIHM) da Universidade Federal de

Campina Grande (UFCG) tem proposto o formalismo TAOS para análise da tarefa no âmbito

da concepção e desenvolvimento de interfaces de sistemas computacionais.

�� 0HWRGRORJLDV�GH�FRQFHSomR�EDVHDGDV�QD�WDUHID�A partir da necessidade de se desenvolver aplicações utilizáveis e acessíveis a um

grande número de usuários, diversas metodologias de concepção e desenvolvimento de

interfaces foram propostas. A maioria dessas metodologias tem como elemento base a

representação da tarefa que o usuário desempenha ou deve desempenhar com a utilização do

sistema correspondente. Elas guiam, a partir da descrição da tarefa, do perfil do usuário e de

princípios ergonômicos, a construção de um protótipo da interface levando em conta os

objetivos do usuário. As metodologias que se baseiam no modelo da tarefa do usuário

constituem um expressivo apoio à concepção de interfaces ergonômicas (Morkopoulos e

Gikas, 1997). Neste contexto, a análise e modelagem da tarefa não têm o objetivo de avaliar,

mas descrever uma tarefa precisamente com o intuito de entender a “ lógica do usuário” .

Dentre as metodologias que se enquadram nesse contexto, citamos: TRIDENT (Bodart

at al, 1994; Bodart at al, 1995), ADEPT (Johnson at al., 1993), ERGO-START (Hammouche,

1995), MACIA (Furtado, 1997), ALACIE (Gamboa, 1998) e MCI (Sousa, 1999).

5

O Grupo de Interfaces Homem-Máquina da UFCG tem proposto a metodologia

MEDITE (Guerrero, 2001; Guerrero e Lula, 2001a; Guerrero e Lula, 2001b; Guerrero e Lula,

2002), orientada a modelos e baseada na tarefa, para a concepção de interfaces ergonômicas.

�� )HUUDPHQWDV�SDUD�DQiOLVH�H�PRGHODJHP�GD�WDUHID�Embora modelagem da tarefa e projeto baseado na tarefa estarem sendo largamente

considerados nos projetos de interfaces homem-computador, sua adoção tem sido limitada

pela carência de ferramentas que suportem o desenvolvimento, a análise interativa e o uso de

modelos da tarefa.

As ferramentas inicialmente desenvolvidas para análise da tarefa de concepção de

interfaces homem-máquina, por exemplo, Adept (Wilson at al., 1993) e IMAD* (Gamboa e

Scapin, 1997) são rudimentares, com características limitadas e usadas somente pelos grupos

de pesquisas que as desenvolveram.

Mais recentemente, algumas ferramentas mais elaboradas, com características mais

interessantes foram desenvolvidas e disponibilizadas na Internet (Euterpe (Van Welie, M. e

Van Der Veer, 1998)).

�� 7$26�±�7DVN�DQG�$FWLRQ�2ULHQWHG�6\VWHP�TAOS é um formalismo de aquisição e representação do conhecimento baseado na

modelagem do domínio e foi desenvolvido por J.H. de Medeiros (Medeiros, 1995; Medeiros e

Rousselot, 1995a, Medeiros e Rousselot, 1995b). TAOS se insere entre os trabalhos teóricos e

experimentais desenvolvidos nesses últimos anos em Inteligência Artificial, no campo da

construção de sistemas baseados em conhecimento (SBC) fundado na modelagem do

domínio. Esses trabalhos têm mostrado as vantagens de metodologias baseadas na construção

de modelos desde a fase de aquisição de conhecimento até a fase de projeto do SBC (Silva,

1999).

Kafure, em (Kafure, 2000), mostra que TAOS tem o mesmo poder descritivo que

MAD para a análise da tarefa no contexto de concepção de interfaces. Assim como MAD,

TAOS permite descrever os objetivos do usuário, a decomposição de tarefas em sub-tarefas,

6

as relações estruturais e temporais entre as sub-tarefas, suas condições de inicialização e de

término, os objetos necessários para sua realização, entre outros.

O modelo de representação proposto pelo formalismo TAOS considera que podem

existir em um domínio dois tipos de entidades ou conceitos: os FRQFHLWRV� HVWiWLFRV, que

conservam suas características durante um intervalo de tempo pré-estabelecido (objetos,

métodos e situações) e os FRQFHLWRV�GLQkPLFRV�(processos, planos e ações), que representam

uma evolução da situação observada num intervalo de tempo. Segundo Medeiros (1995), essa

distinção é importante para a representação do conhecimento uma vez que a natureza das

relações lógicas que existem entre conceitos estáticos (na maioria dos casos, apenas de

generalização/particularização e decomposição) não é a mesma que existe entre os conceitos

dinâmicos (envolve também relações de temporalidade). A representação orientada-objeto dos

conceitos (estáticos e dinâmicos) é um grafo (árvore), cujos nós representam as classes e

instâncias de classes, e cujos arcos representam relações entre as classes ou entre classes e

instâncias.

TAOS foi concebido para ser implantado em dois módulos: módulo TAME (“ 7DVN�DQG� $FWLRQ� 0RGHOLQJ� (QYLURQPHQW” ) e módulo TAOS-Graph. O módulo TAME guia a

construção de um modelo para um domínio. Ele define uma linguagem e uma metodologia

descendente-ascendente de construção do modelo do domínio. O módulo TAOS-Graph

permite a visualização do processo de modelagem. Trata-se de um editor de entidades

estáticas e dinâmicas estruturadas de acordo com os princípios preconizados pelo módulo

TAME. Isso permite modelar o conhecimento do domínio fazendo uma verificação preliminar

desse conhecimento, tanto do ponto de vista da sua completude quanto de sua coerência.

�� 3UREOHPiWLFD�O surgimento de formalismos para análise da tarefa foi um passo importante para

melhorar a qualidade das descrições das tarefas, principalmente do que diz respeito à

colaboração entre ergonomistas e projetistas que passaram a usar uma linguagem formal

comum.

7

Porém, realizar a análise e modelagem de tarefas sem a disponibilidade de uma

ferramenta específica que auxilie o projetista implica em problemas (Gamboa e Scapin,

1997), tais como:

L�� Dificuldade em descrever a estrutura de árvores das tarefas e suas notações formais;

LL�� Dificuldade de verificar a consistência e completude das tarefas modeladas;

LLL�� Impossibilidade de geração automática ou semi-automática do modelo da interação

a partir do modelo da tarefa;

Esses problemas listados são sentidos com uma grande intensidade por projetistas que

analisam e modelam tarefas utilizando os formalismos disponíveis citados anteriormente. Pela

dificuldade em adquirir uma ferramenta de modelagem, a construção e manipulação das

árvores do modelo da tarefa são feitas utilizando lápis e papel ou, no máximo, ferramentas

que desenham e manipulam figuras geométricas básicas, e não os conceitos de tarefas

envolvidos. Por esse motivo, há uma grande dificuldade em verificar a consistência e

completude da tarefa, principalmente pela necessidade de memorização dos atributos, objetos

e termos relacionados com a tarefa que está sendo modelada.

Além disso, a não existência de uma representação digital apropriada da tarefa

implica: (L) na impossibilidade de se ter ferramentas computacionais para auxiliar os

projetistas nos passos seguintes do processo e (LL) em grande dificuldade na utilização de

conhecimentos ergonômicos para a obtenção da representação da interação (modelo da

interação).

�� 2EMHWLYRV�GR�WUDEDOKR�Este trabalho teve como objetivo principal projetar e implementar o módulo TAOS-

Graph e integrá-lo ao módulo TAME gerando a ferramenta LTAOS (Lnterface TAOS) de

suporte a análise e modelagem da tarefa no contexto de concepção e desenvolvimento de

interfaces do usuário. A ferramenta iTAOS deverá: (L) apoiar o projetista de interfaces na

elaboração da representação da tarefa segundo o formalismo e metodologia TAOS, (LL) verificar a consistência e completude da representação e (LLL) viabilizar a construção de outras

8

ferramentas computacionais de suporte à transformação da representação da tarefa na

representação da interação segundo critérios ergonômicos.

Como objetivo periférico, mas não menos importante, contribuir para a promoção e a

consolidação da idéia de que metodologias de concepção e desenvolvimento de interfaces que

levem em conta, desde o inicio do processo, a análise da tarefa e o conhecimento ergonômico

produzem interfaces do usuário com alto grau de usabilidade.

��+LSyWHVHV�As hipóteses que fundamentaram a escolha da metodologia de trabalho aplicada a

construção de nosso objetivo principal foram as seguintes:

L�� É possível projetar e implementar o módulo TAOS-Graph separado do processo de

desenvolvimento do módulo TAME.

LL�� O processo de desenvolvimento a ser utilizado no projeto do módulo TAOS-Graph

deve partir da análise da tarefa “ Utilizar a Ferramenta iTAOS para Analisar e

Modelar Tarefas” de forma a capturar efetivamente o conhecimento sobre o usuário

e sobre o seu processo de realização da tarefa.

LLL�� A metodologia MEDITE possibilita uma construção guiada por modelos do módulo

TAOS-Graph de forma a obedecer aos princípios da ergonomia e aos objetivos do

usuário da ferramenta iTAOS.

��0HWRGRORJLD�GH�WUDEDOKR�A metodologia que adotamos no desenvolvimento deste trabalho consiste nas

seguintes etapas:

L�� Pesquisa bibliográfica sobre formalismos de descrição de tarefas, metodologias de

concepção baseadas na tarefa e ferramentas para análise da tarefa.

LL�� Estudo detalhado sobre TAOS e sobre a metodologia MEDITE (Guerrero, 2001;

Guerrero e Lula, 2001; Guerrero e Lula, 2002a; Guerrero e Lula, 2002b).

LLL�� Levantamento do perfil do usuário.

9

LY�� Análise e modelagem da tarefa “ Analisar e modelar tarefas utilizando o formalismo

TAOS” .

Y�� Produção da especificação conceitual da interação utilizando o modelo EDITOR

(Lula, 1992).�YL�� Construção do protótipo da interface utilizando a linguagem de programação JAVA1.

Essa linguagem foi escolhida devido a sua portabilidade e à experiência por parte dos

projetistas da ferramenta iTAOS.�YLL�� Avaliação dos artefatos projetados. Esta avaliação foi feita interativamente e

iterativamente à medida que o modelo era desenvolvido e ao final através de uma

avaliação baseada na inspeção de padrões (Stewart, 2000).

��(VWUXWXUD�GD�GLVVHUWDomR�O trabalho está organizado em oito capítulos da seguinte forma: O segundo capítulo

apresenta o formalismo TAOS e seu uso para analisar e modelar tarefas no contexto de

interface homem-máquina.

O terceiro capítulo apresenta a metodologia MEDITE, uma metodologia baseada na

tarefa para a concepção de interfaces ergonômicas e utilizada no projeto e implementação do

módulo TAOS-Graph, componente interativo da ferramenta iTAOS.

O quarto capítulo apresenta a análise e modelagem da tarefa “ Modelar tarefa

utilizando a ferramenta iTAOS” . Nesta fase, os dados colhidos junto aos usuários sobre a

tarefa analisada se deu através de técnicas como observações, entrevistas com os usuários e

consultas a manuais.

O quinto capítulo apresenta a utilização de regras ergonômicas da base de regras

formuladas em MEDITE na criação da especificação conceitual da interação a partir do

modelo da tarefa. Algumas das regras foram adaptadas e outras criadas, de forma que fossem

úteis ao projeto.

1 JAVATM é uma tecnologia Sun Microsystems

10

O sexto capítulo apresenta o protótipo da interface implementado com a linguagem de

programação JAVA.

O sétimo capítulo apresenta a avaliação aplicada ao produto final. Trata-se de uma

avaliação baseada em padrões ergonômicos.

No oitavo capítulo, finalmente, discute-se os resultados alcançados, sugestões de

continuidade e trabalhos futuros.

11

&DStWXOR�� )RUPDOLVPR� 7$26� SDUD� DQiOLVH� H�PRGHODJHP�GH�WDUHIDV�QR�FRQWH[WR�GR�SURMHWR�GH�LQWHUIDFHV�GR�XVXiULR�

Neste capítulo descrevemos o formalismo TAOS: o seu surgimento dentro do campo

da Inteligência Artificial, o modelo o qual ele define e sua utilização como formalismo para

análise e modelagem de tarefas no contexto de interfaces homem-máquina.

��7$26��,QWHOLJrQFLD�$UWLILFLDO�A representação e a manipulação do conhecimento é um problema comum encontrado

nos campos da Psicologia, da Ergonomia e da Informática, particularmente da Inteligência

Artificial (IA). Portanto, grande parte do esforço em IA tem se concentrado em buscar ou

aperfeiçoar formalismos para a representação do conhecimento.

TAOS é um formalismo para aquisição e representação do conhecimento baseado na

modelagem do domínio (Kessel, Medeiros e Rousselot, 1995a; Medeiros e Rousselot, 1995b;

Medeiros, 1995; Medeiros, Kafure e Lula, 2000), foi concebido por J. H. de Medeiros e

validado inicialmente no domínio da biologia molecular. TAOS define um modelo teórico e

experimental que se fundamenta no conhecimento que um especialista possui sobre um

determinado assunto. Esse conhecimento é extraído através de técnicas de aquisição do

conhecimento, como entrevistas, questionários, protocolos etc, e representado através de uma

descrição hierárquica formal baseada no conceito de frames (Minsky, 1975).

O problema da análise e modelagem da tarefa do usuário é semelhante ao problema do

desenvolvimento de um sistema baseado em conhecimento (SBC): aquisição/extração do

conhecimento do usuário (especialista), representação do conhecimento (base de

12

conhecimento) e verificação da representação (inferência). Portanto, resolver o problema da

análise e descrição de tarefas significa obter o conhecimento que o usuário tem da tarefa e

representá-la de forma adequada através de um formalismo.

��0RGHOR�7$26�O modelo de representação proposto por TAOS2 considera que os conceitos podem ser

de dois tipos: conceitos estáticos e conceitos dinâmicos. Um conceito é considerado estático

se ele conserva suas características durante um intervalo de tempo pré-estabelecido. Os

conceitos objeto (2EMHFW)�� DJHQWH� �$JHQW�� LQVWUXPHQWR��,QVWUXPHQW�� VLWXDomR� �6LWXDWLRQ��e�PpWRGR� �0HWKRG� são considerados estáticos. Um conceito é considerado dinâmico se ele

representa a evolução de uma situação observada num intervalo de tempo pré-estabelecido.

Os conceitos SURFHVVR��3URFHVV��SODQR��3ODQ��e�DomR��$FWLRQ� são considerados dinâmicos.

)LJXUD��0HWD�PRGHOR�7$26�

2 Os nomes das classes e de seus atributos são apresentados em inglês como definidos no meta-modelo (Figura 1).

13

A figura 1 ilustra a taxonomia dos conceitos definidos por TAOS (Meta-modelo). A

representação gráfica dos conceitos é uma árvore, cujos nós representam as classes e cujos

arcos representam as relações entre as classes.

A distinção entre conceitos estáticos e dinâmicos é importante para a representação do

conhecimento uma vez que a natureza das relações lógicas que existem entre conceitos

estáticos não é a mesma que existe entre conceitos dinâmicos. Enquanto que as relações

existentes entre os conceitos estáticos envolvem quase sempre relações de generalização e

decomposição, as relações entre conceitos dinâmicos envolvem também relações de

temporalidade.

A classe de mais alto nível, denominada &RQFHSW, define a entidade de maior grau de

abstração, possui como atributos QDPH e GHVFULSWLRQ que são do tipo cadeia de caracteres

(String), além de atributos opcionais, tais como : DGGLWLRQDO$WWULEXWHV� que é representado por

uma tupla (nome do atributo, tipo do atributo).

��&RQFHLWRV�HVWiWLFRV�A classe 6WDWLF&RQFHSW é uma sub-classe da classe &RQFHSW. A classe 6WDWLF&RQFHSW se

decompõe em três outras classes: 2EMHFW��0HWKRG�e�6LWXDWLRQ, sendo que a classe 2EMHFW se

decompõe em mais duas, que são 7RRO�e�$JHQW.

A classe 6WDWLF&RQFHSW possui além dos atributos herdados da classe &RQFHSW, o

atributo LQVWDQW2I&UHDWLRQ��que�representa o instante de criação de um determinado conceito

estático.

A classe 2EMHFW possui como novo atributo em relação a sua superclasse 6WDWLF&RQFHSW o atributo &RPSRQHQWV. Este atributo representa a decomposição do objeto em suas partes

constituintes e é representada por uma lista (vetor) de 2EMHFWV.

A classe 7RRO define um tipo de objeto que é utilizado pelos agentes para executar

suas acões (ferramenta). Essa classe, além dos atributos herdados da classe 2EMHFW, possui os

seguintes atributos:

L�� 8WLOLW\ : Ações que podem ser realizadas utilizando a ferramenta (instrumento). É

representado por uma lista (vetor) de ações.

14

LL�� 8VHUV�: Agentes que utilizam a ferramenta para execução de uma ação. É

representado por uma lista (vetor) de agentes.

A classe $JHQW define um tipo de objeto habilitado a executar uma ação. Além dos

atributos herdados da classe 2EMHFW, a classe $JHQW possui os seguintes atributos :

L�� &RPSHWHQFHV : O agente realiza ações que ele conhcece e para as quais ele é

competente. Este atributo é representado por uma lista (vetor) de ações.

LL�� 3DUWQHUV�: O agente pode tomar decisões a partir de informações que ele recebe de

outros agentes. Este atributo é representado por uma lista (vetor) de outros agentes.

A classe 0HWKRG define a estratégia para executar um plano (sub-planos e ações).

Além dos atributos herdados da classe 6WDWLF&RQFHSW, a classe 0HWKRG possui o atributo ERG\.

Este atributo define uma expressão composta ou simples para descrever a decomposição do

plano em sub-planos e ações, segundo a gramática abaixo :

<expression> ::= <opr> (<list-expression>) <list-expression> ::= <action>,<list-expression> <list-expression> ::= <plan>,<list-expression> <list-expression> ::= <expression>,<list-expression> <list-expression> ::= <action>,<simple-expression> <list-expression> ::= <plan>,<simple-expression> <list-expression> ::= <expression>,<simple-expression> <simple-expression> ::= <action>|<plan>|<expression> <opr> :: = SEQ|OR|XOR|AND|SIM|PAR <plan> ::= object of the type 3ODQ 3 <action> ::= object of the type $FWLRQ�

Os operadores SEQ, OR, XOR, AND, SIM, PAR permitem estabelecer relações

temporais (precedência) e/ou lógicas entre os sub-planos e/ou ações que compõem um plano.

Abaixo temos a descrição de cada um dos operadores citados:

L�� OR: indica que pelo menos um dos sub-planos e/ou ações de um plano deve ser

executado.

LL�� XOR: indica que apenas um dos sub-planos e/ou ações de um plano deve ser

executado.

3 Os conceitos dinâmicos (Action, Plan e Process) serão descritos na próxima seção.

15

LLL�� AND: indica que todos os sub-planos e/ou ações de um plano devem ser

executados não importando a ordem de execução das mesmas.

LY�� SEQ: Os sub-planos e/ou ações de um plano devem ser executados em seqüência.

Y�� SIM: indica que os sub-planos e/ou ações de um plano podem ser executados

simultaneamente.

YL�� PAR: indica que os sub-planos e/ou ações de um plano são executados

paralelamente, não necessariamente ao mesmo tempo.

A classe 6LWXDWLRQ define os objetos e as restrições sobre esses objetos antes e depois

da realização de uma ação ou plano e as maneiras de chegar a esse estado. Além dos atributos

herdados da classe 6WDWLF&RQFHSW��a classe Situation possui os atributos 2EMHFWV, 5HVWULFWLRQV e KRZ7R2EWDLQ descritos a seguir :

L�� 2EMHFWV: Objetos do domínio da tarefa que se está modelando. Este atributo é

representado por uma lista (vetor) de objetos.

LL�� 5HVWULFWLRQV: É uma expressão lógica sobre os objetos referenciados na lista de

objetos do atributo 2EMHFWV. LLL�� KRZ7R2EWDLQ: É uma lista de planos ou ações que indicam as diversas maneiras de

se atingir a situação.

��&RQFHLWRV�GLQkPLFRV�A classe '\QDPLF&RQFHSW é sub-classe da classe &RQFHSW e se decompõe em três

outras classes, são elas: 3URFHVV�� $FWLRQ� and� 3ODQ. '\QDPLF&RQFHSW possui além dos

atributos herdados da classe &RQFHSW, os atributos SUH6LWXDWLRQ, SRV6LWXDWLRQ e GXUDWLRQ,

descritos a seguir:

L�� SUH6LWXDWLRQ: Este atributo é do tipo 6LWXDWLRQ e define a situação inicial necessária

a realização de um Plano, Ação ou Processo.

LL�� SRV6LWXDWLRQ��Este atributo é do tipo 6LWXDWLRQ e define a situação final resultante

da realização de um Plano, Ação ou Processo.

16

LLL�� GXUDWLRQ� tempo de duração.

A classe 3URFHVV define um grupo de situações observadas em instantes diferentes

(dispostas em ordem cronológica parcial ou total) e permite registrar a execução de um plano.

A classe 3URFHVV possui os atributos herdados da classe '\QDPLF&RQFHSW e o atributo

VLWXDWLRQV, que é representado por uma lista (vetor) de 6LWXDWLRQs.

A classe 3ODQ define uma tarefa de alto nível ou de nível intermediário. Um plano se

decompõe em sub-planos e ações, podendo ser decomposto em vários níveis de abstração. A

classe 3ODQ possui onze novos atributos, além dos herdados da classe '\QDPLF&RQFHSW. Esses

novos atributos são descritos a seguir:

L�� DFWLRQV: É representado por uma lista (vetor) de $FWLRQs. Essas ações serão

executadas baseado nos operadores definidos na classe 0HWKRG.

LL�� VXE�SODQV: É representado por uma lista (vetor) de 3ODQs. Esses sub-planos serão

executadas baseado nos operadores definidos na classe 0HWKRG.

LLL�� KRZ7R2EWDLQ: Representado por uma lista de 0HWKRGV. Indica como o plano será

executado.

LY�� QXPEHU: número que identifica o plano (sub-plano) na árvore de tarefas em que ela

se encontra.

Y�� RFXUUHQFH: Determina a quantidade de vezes que o plano será executado. Pode

assumir um dos seguintes valores:

• (0,0) – O plano não é executado.

• (0,1) – Executado nenhuma vez ou uma vez.

• (0,n) – Executado zero ou mais vezes.

• (1,1) – Executado uma única vez.

• (1,n) – Executado pelo menos uma vez.

A classe $FWLRQ descreve uma tarefa elementar. Na hierarquia de planos e ações, as

ações seriam as folhas da árvore, isto é, não podem ser mais decompostas. Além dos atributos

herdados da classe '\QDPLF&RQFHSWV, a classe $FWLRQ possui os seguintes atributos:

17

L�� QXPEHU: número que identifica a ação na árvore de tarefas em que ela se encontra.

LL�� RFXUUHQFH: Determina a quantidade de vezes que a ação será executada. Pode

assumir um dos seguintes valores:

• (0,0) – O plano não é executado.

• (0,1) – Executado nenhuma vez ou uma vez.

• (0,n) – Executado zero ou mais vezes.

• (1,1) – Executado uma única vez.

• (1,n) – Executado pelo menos uma vez.

LLL�� DJHQWV: Lista (vetor) de objetos do tipo $JHQW. Agentes que executam a ação.

LY�� WRROV: Lista (vetor) de objetos do tipo 7RRO��Indica as ferramentas utilizadas pelos

agentes para execução da ação.

Y�� VWDWXV: Indica o estado da ação, podendo assumir os valores: em execução,

finalizada, pausada, interrompida ou saltada.

��9DOLGDomR�GH�7$26�IDFH�0$'�O formalismo TAOS, concebido inicialmente para aquisição e representação do

conhecimento no domínio da biologia molecular, foi validado para a análise e modelagem da

tarefa no contexto da concepção de interfaces homem-máquina (Kafure, 2000), sendo capaz

de evidenciar os requisitos exigidos para esta análise, entre os quais:

L�� Os objetivos da tarefa, ou seja, o estado do mundo que se deseja atingir com a

execução da tarefa.

LL�� A decomposição hierárquica da tarefa em sub-tarefas e ações segundo Sebillote

(1998), isto é, a explicitação do plano de ação do usuário para atingir os objetivos a

que se propõe.

LLL�� Os objetos envolvidos, ou seja, informações que são utilizadas e produzidas em

cada etapa da análise.

18

LY�� Os procedimentos utilizados, ou seja, as diferentes maneiras ou estratégias de se

realizar a tarefa.

Y�� As condições necessárias para a realização da tarefa, que dizem respeito às

restrições sobre o estado do mundo que devem ser verificadas para que a tarefa

possa ser iniciada e finalizada.

YL�� As incoerências e incompletude da descrição, ou seja, a construção incremental do

modelo é guiada através de uma metodologia descendente-ascendente, ou seja, deve

ser construída uma hierarquia de tarefas e ações, tendo a tarefa mais geral a ser

executada no topo e as ações que permitem realizar a execução da tarefa nas folhas

da árvore.

��7$26��0RGHODJHP�GD�WDUHID�Hammouche (1995) definiu a nova versão do MAD, um modelo analítico de descrição

de tarefas do usuário orientado à especificação de interface chamado MAD*. Além dos

atributos existentes em MAD, MAD* define novos atributos orientados à especificação da

interface e à simulação de um modelo, que foram agregados ao formalismo TAOS nas classes

$JHQW, 3ODQ�e $FWLRQ.

Na classe $JHQW�foram agregados�os atributos WDVN([SHULHQFH e VLPLODU6\VWHP([SHULHQFH:

L�� WDVN([SHULHQFH�: Experiência que o agente tem acerca da ação que está realizando.

Este atributo, que é do tipo cadeia de caracteres (String), assume o valor alta,

média ou baixa.

LLL�� VLPLODU6\VWHP([SHULHQFH : Experiência com sistemas similares ao que se está

projetanto (descrevendo). Este atributo, que é do tipo cadeia de caracteres (String),

assume o valor alta, média ou baixa.

Nas classes $FWLRQ e 3ODQ foram agregados os seguintes atributos :

L�� SULRULW\��Esse atributo é representado por um inteiro e indica a prioridade da ação.

19

LL�� LQWHUUXSWDELOLW\� Determina se a ação que está sendo executada pode ser

interrompida ou não, e caso possa, como será o reinício da execução dessa ação.

Esse atributo pode assumir um dos três valores descritos abaixo:

• Não Interrompível: A ação não pode ser interrompida.

• Interrompível com reinício a partir do começo – se a ação for interrompida, o

fluxo de sua execução deve ser retomada do início.

• Interrompível com reinício em curso – se a ação for interrompida, seu fluxo de

execução deve ser retomada de onde parou.

LLL�� W\SH: Esse atributo ajuda na especificação das formas de interação. Indica o tipo da

ação e pode assumir um dos seguintes valores: mental, sensório-mental ou verbal.

LY�� PRGDOLW\� Esse atributo também ajuda na especificação das formas de interação.

Pode assumir um dos seguintes valores: automática, manual ou interativa.

Y�� LPSRUWDQFH� Indica a importância da ação e assume um dos seguintes valores: alta,

média ou baixa.

YL�� IUHTXHQFH� Indica a freqüência em que a ação é executada. Pode assumir um dos

seguintes valores: alta, média ou baixa.

Como TAOS foi validado para análise e modelagem da tarefa no contexto de

interfaces homem-máquina, os conceitos 3ODQ e 6XE�SODQ referentes à classe 3ODQ do modelo

TAOS e que são oriundos dos sistemas baseados em conhecimento (SBC), passaram a ser

nomeadas como TDVN� �WDUHIDV� 6XE�7DVN� �VXE�WDUHIDV�, de acordo com a nomenclatura dos

projetistas de interfaces.

��&RQVLGHUDo}HV�ILQDLV�Neste capítulo foi apresentado o formalismo TAOS. Foram descritos sua estrutura e

seus conceitos. TAOS foi concebido para aquisição e representação do conhecimento e

validado para análise e modelagem da tarefa no contexto de interfaces homem-máquina.

A descrição hierárquica da tarefa em sub-tarefas e ações (conceitos dinâmicos)

utilizando o formalismo TAOS é representada graficamente na forma de uma árvore, cujos

20

nodos representam as tarefas, sub-tarefas e ações e os arcos representam as conexões com as

tarefas superiores. Os frames são representados em TAOS por descritores (tabelas) que

descrevem os atributos relativos aos conceitos estáticos. Um extrato de uma descrição TAOS

pode ser encontrado no capítulo 4.

TAOS foi concebido para ser implementado em dois módulos: o módulo TAME e o

módulo TAOS-Graph. O módulo TAME guia a construção de um modelo para um domínio

baseando-se numa metodologia ascendente-descendente. O módulo TAOS-Graph permite a

visualização gráfica do processo de modelagem. Trata-se de um editor de entidades estáticas e

dinâmicas estruturadas de acordo com os princípios preconizados pelo módulo TAME.

O formalismo TAOS vem sendo utilizado como modelo de descrição de tarefas no

âmbito da Universidade Federal de Campina Grande (UFCG). Porém, realizar a análise e

modelagem de tarefas sem a disponibilidade de uma ferramenta específica que auxilie o

projetista implica em problemas (Gamboa e Scapin, 1997), tais como:

L�� Dificuldade em descrever a estrutura de árvores das tarefas e suas notações formais;

LL�� Dificuldade de verificar a consistência e completude das tarefas modeladas;

LLL�� Impossibilidade de geração automática ou semi-automática do modelo da interação

a partir do modelo da tarefa;

Pelas dificuldades citadas acima, foi projetada e implementada a ferramenta iTAOS,

uma ferramenta para análise e modelagem de tarefas segundo o formalismo TAOS. A

ferramenta iTAOS foi concebida seguindo o princípio da independência do diálogo, ou seja, o

módulo TAME (componente funcional) foi projetado independentemente do módulo TAOS-

Graph (componente interativo), seguindo processos distintos. O módulo TAOS-Graph,

resultado desse trabalho, foi desenvolvido utilizando a metodologia MEDITE (Guerrero,

2001), que será apresentada no próximo capítulo.

21

&DStWXOR��0(',7(�±�8PD�PHWRGRORJLD� EDVHDGD�QD�WDUHID�H�RULHQWDGD�D�PRGHORV�SDUD�FRQFHSomR�GH�LQWHUIDFHV�HUJRQ{PLFDV�

MEDITE (Guerrero, 2001, Guerrero e Lula, 2001a, Guerrero e Lula, 2001b, Guerrero

e Lula, 2002) é uma metodologia baseada na tarefa e orientada a modelos que utiliza o

conhecimento ergonômico logo no início do processo de concepção de interfaces de forma a

produzir interfaces que reflitam os objetivos, as características e as necessidades do usuário.

MEDITE (MAD* + EDITOR + ERGONOMIA) guia o projetista, especialmente

aquele que não tem conhecimento sobre Ergonomia, segundo modelos bem definidos durante

todo o processo de concepção de interfaces.

Neste capítulo descrevemos o ciclo de desenvolvimento definido por MEDITE, os

modelos da tarefa, da interface e da arquitetura utilizados na metodologia, a base de regras

ergonômicas proposta inicialmente e o suporte computacional (ferramentas) para cada etapa

do processo de concepção.

��'HVFULomR�GH�0(',7(�A maioria das metodologias tradicionais de desenvolvimento de software não se

preocupa com a interface do usuário, que passa a ser considerada apenas nas fases finais do

processo, tornando-se assim nada mais que um “ apêndice” do sistema. Devido à necessidade

de desenvolver aplicações utilizáveis, acessíveis a um grande número de usuários, foram

surgindo várias metodologias e ferramentas de ajuda à concepção de interfaces para o usuário.

22

As metodologias baseadas na tarefa têm se mostrado um caminho efetivo no apoio à

concepção de interfaces ergonômicas. Partindo da análise e modelagem da tarefa, do perfil do

usuário e de princípios ergonômicos, é possível se construir interfaces que levam em conta os

reais objetivos do usuário.

Entre essas várias metodologias que surgiram podemos citar TRIDENT (Bodart at al,

1994; Bodart at al, 1995), ADEPT (Johnson at al., 1993; Markopoulos, Pycock e Wilson,

1992; Wilson at al., 1993), ERGO-START (Hammouche, 1995), ALACIE (Gamboa, 1998) e

MCI (Sousa, 1999). Essas metodologias, em geral, fazem uso de modelos (modelo da tarefa,

modelo do usuário, modelo da interação, modelo arquitetural), de conhecimento ergonômico e

de ferramentas computacionais para apoiar a concepção da interface.

No entanto, algumas dificuldades e limitações são sentidas na utilização das

metodologias citadas acima, como a dificuldade de escolha e de utilização de regras

ergonômicas em relação às etapas do processo, dificuldades na passagem do modelo da tarefa

para o modelo da interação, dificuldade da aplicação da metodologia na ausência de

ferramentas e dificuldades em modificar o código da interface (Guerrero, 2001).

Com o intuito de minimizar esses problemas e dificuldades no âmbito da UFCG foi

desenvolvida uma metodologia baseada na tarefa e orientada a modelos denominada

MEDITE. Essa metodologia parte da descrição da tarefa. Cada etapa do processo segue um

modelo e o conhecimento ergonômico é integrado de forma a ser usado com facilidade

através de uma base de regras que auxilia o projetista na passagem do modelo da tarefa para o

modelo da interação. Devido a modelos bem definidos para cada artefato gerado, MEDITE

pode ser utilizada independentemente de ferramentas computacionais.

MEDITE define o processo de construção de interfaces ergonômicas em 5 etapas:

análise e modelagem da tarefa, especificação conceitual da interação, refinamento da

especificação conceitual, geração do protótipo e avaliação distribuída em todas as outras

etapas do processo. A Figura 2 ilustra os processos através de círculos e por meio de

retângulos os produtos (artefatos) gerados e as ferramentas conceituais (modelos) utilizadas

em cada etapa do processo.

23

)LJXUD��0HWRGRORJLD�0(',7(�

��$QiOLVH�H�PRGHODJHP�GD�WDUHID�Esta etapa pretende descrever os objetivos dos usuários e os meios utilizados no

processo de realização de uma determinada tarefa. A tarefa deve ser descrita em termos de

objetivos, procedimentos, objetos, decomposição em sub-tarefas, restrições, etc. O modelo

utilizado na descrição da tarefa é o MAD*.

Esta etapa tem como entrada os dados sobre o usuário e sobre o domínio da tarefa. O

produto gerado no final desta etapa é a descrição MAD* da tarefa (árvore MAD* e seus

descritores). A avaliação desta etapa é realizada iterativamente e interativamente com o

usuário, até que o usuário consiga visualizar o fluxo de realização da sua tarefa explícita na

árvore e nos descritores do modelo. A consistência e completude da tarefa devem ser

verificadas pelo projetista, bem como a escolha e modificações das tarefas de acordo com o

sistema a ser desenvolvido.

��(VSHFLILFDomR�FRQFHLWXDO�SDUFLDO�GD�LQWHUDomR�Esta etapa consiste em produzir a especificação conceitual parcial da interação.

Determina a estrutura e o estilo dos aspectos da interação de acordo com o modelo EDITOR

(Lula, 1992). Essa especificação permite uma visão inicial (esboço) da apresentação e do

encadeamento do diálogo da interface em construção.

Esta etapa tem como entrada a descrição MAD* da tarefa gerada na etapa anterior e

utiliza o conhecimento ergonômico armazenado na forma de regras de produção para

24

transformar a descrição MAD* da tarefa na especificação conceitual da interação segundo o

modelo EDITOR.

A avaliação nesta etapa consiste em verificar se a especificação conceitual gerada

através das regras ergonômicas está de acordo com uma primeira apreciação do usuário.

��'HILQLomR�GRV�DWULEXWRV�Esta etapa consiste na definição dos atributos das árvores EDITOR, ou seja, o

complemento e refinamento da especificação gerada na etapa anterior com a definição dos

atributos de $SUHVHQWDomR (localização, formato, tamanho de fonte, etc.), de $EVWUDomR (em

relação ao domínio da aplicação) e de &RQWUROH, definindo o encadeamento do diálogo entre as

janelas da interface.

As entradas desta etapa são a especificação gerada na etapa anterior e a descrição

MAD* da tarefa. O produto gerado é a especificação conceitual completa da interação de

acordo com o modelo EDITOR e com o conhecimento ergonômico para definição dos

atributos.

Nesta etapa, a especificação conceitual completa já permite uma melhor visualização

das janelas da interface que se está projetando, que deve ser levada novamente ao usuário de

forma a validar essa especificação.

��*HUDomR�GR�SURWyWLSR�Esta etapa consiste da codificação da interface a partir da especificação conceitual

completa definida na etapa anterior. Esse código é estruturado de acordo com o modelo de

arquitetura definido no modelo EDITOR.

A avaliação do protótipo deve ser realizada junto ao usuário através de alguma(s)

técnica(s) de avaliação, tais como: testes de usabilidade, inspeção por padrão, avaliação

heurística, conformidade com recomendações, exploração cognitiva ou uma abordagem

híbrida. Dependendo do resultado da avaliação, o projetista deve retornar a etapas anteriores,

baseado no problema que for encontrado.

25

��0RGHOR�0$' �O modelo MAD* é um modelo analítico de descrição de tarefas do usuário orientado à

especificação de interface. Ele descreve e modela as tarefas de forma hierárquica e possui

uma sintaxe gráfica de descrição (Hammouche, 1995). A figura 3 apresenta os quatro

conceitos definidos por MAD*.

0$' �8QLGDGH��7DUHID�

'HFRPSRVLomR�GD�8QLGDGH��7DUHID�

$WULEXWRV�GH�&RQFHSomR�GD�,QWHUIDFH

&RUSR�GD�8QLGDGH��7DUHID�

Corpo Condições de Entrada Condições de Saída

Construtores Temporais (SEQ, PAR, SIM) Construtores Estruturais (ET, OU, ALT)

Restrições de Dialogo Tipo, Modalidade Centralidade Papel do Operador Meios de Interação

)LJXUD��&RQFHLWRV�GHILQLGRV�SRU�0$' �

��&RQFHLWRV�GHILQLGRV�SRU�0$' �Unidade-tarefa

O conceito de unidade-tarefa é definido como uma estrutura de conhecimento que é:

(L) unitário e uniforme, (LL) autônomo, isto é, permite analisar as tarefas individualmente e (LLL) um instrumento de medida da complexidade de uma árvore de tarefas. Este conceito permite

representar tanto tarefas elementares como tarefas compostas.

Em MAD* distinguem-se três níveis de unidade-tarefa: alto, intermediário e baixo.

Uma unidade-tarefa de alto nível descreve um objetivo da tarefa. Uma unidade-tarefa de nível

intermediário representa uma estratégia de procedimentos de execução da tarefa e uma

unidade-tarefa de baixo nível corresponde a uma ação da tarefa.

Uma unidade-tarefa de alto nível pode agrupar diversas unidades tarefas de nível

intermediário, assim como uma unidade tarefa de nível intermediário pode agrupar diversas

unidades tarefas de baixo nível (ações).

26

Corpo da unidade tarefa

O corpo da unidade tarefa trata das condições de entrada e de saída e do corpo da

tarefa. As condições de entrada e de saída possuem como principal atributo SUp�FRQGLo}HV e

SyV�FRQGLo}HV respectivamente. As pré-condições e pós-condições exprimem as restrições

sobre os objetos do estado inicial e final respectivamente.

O corpo da tarefa agrupa grande parte dos atributos MAD*, são eles: nome da tarefa

(tipo alfanumérico), número da tarefa (tipo numérico), objetivo (texto explicando o objetivo

da tarefa), modo da tarefa (facultativa, obrigatória), ator da tarefa (usuário, sistema,

desconhecido), tempo (início da execução, fim da execução e a duração da execução),

prioridade da tarefa, interruptibilidade da tarefa e estado de execução.

Decomposição da unidade tarefa

MAD* define dois tipos de relações de decomposição: estruturais e temporais. As

relações estruturais permitem definir o ordenamento da tarefa e as relações temporais

permitem definir a sincronização das tarefas. Descreveremos a seguir os construtores das

relações estruturais e temporais:

Relações estruturais:

E – executar todas as sub-tarefas.

OU – executar pelo menos uma das sub-tarefas.

ALT – executar somente uma das sub-tarefas.

Relações temporais:

SEQ – executar as tarefas seqüencialmente.

PAR – executar as tarefas paralelamente.

SIM – executar as tarefas ao mesmo tempo.

Atributos orientados à especificação da interface

O quarto conceito de MAD* concerne os atributos que tem por objetivo integrar as

recomendações orientadas à tarefa com aquelas encontradas nas regras ergonômicas,

27

permitindo orientar as primeiras decisões de concepção de uma futura interface. Os atributos

orientados a concepção da interface são adicionados ao nível do corpo ou da decomposição da

unidade-tarefa. São eles:

L�� Restrições do diálogo: permitem refinar o sequenciamento das sub-tarefas de uma

tarefa, notadamente pelas relações E e PAR.

LL�� Tipo e modalidade da tarefa: Os valores que o atributo tipo pode receber são

PHQWDO, VHQVyULR�PRWRU, FRJQLWLYR, YHUEDO etc., enquanto que o atributo modalidade

da tarefa pode assumir os valores PDQXDO, DXWRPiWLFR e LQWHUDWLYR.

LLL�� Papel do operador: Competência e experiência do operador para realizar a tarefa.

Os seguintes atributos o definem:

LY�� Centralidade da tarefa: Este atributo tenta explicitar a maior importância de uma

tarefa em detrimento a outras. Assume o valor LPSRUWDQWH, PHGLDQR ou VHFXQGiULR.

Os dois atributos descritos a seguir o definem:

• Freqüência: {HOHYDGD��PHGLDQD��IUDFD}.

• Entidades importantes: {sub-conjunto dos objetos da tarefa}.

��0RGHOR�(',725�O modelo EDITOR é um modelo multi-agente utilizado como modelo unificado da

arquitetura e de interação na metodologia MEDITE. Ele utiliza o modelo PAC (Coutaz, 1987;

Coutaz, 1990) como modelo de arquitetura e adota o conceito de edição como modelo

conceitual de interação (Smith, Barth e Young, 1987).

EDITOR é um modelo de arquitetura que alia os aspectos remarcáveis do modelo de

Seeheim (Pfaff, 1985) às vantagens de um modelo multi-agente (Coutaz, 1990). Um sistema

interativo é um agente PAC composto, ou seja, se decompõe em agentes intermediários até os

agentes PAC elementares, estruturando a arquitetura de um sistema interativo como uma

hierarquia de agentes PAC. Todo agente PAC possui três facetas:�$SUHVHQWDomR, $EVWUDomR�e

&RQWUROH. As facetas são distribuídas a todos os níveis de abstração.

28

No entanto, o modelo PAC, assim como o modelo de Seeheim, é mais um modelo de

realização que um modelo de concepção, pois não fornece nenhum meio ou indicação de

ajuda à concepção de seus componentes: não veicula um modelo de interação nem explicita as

etapas e/ou as regras que permitam ao projetista identificar os seus componentes a partir da

análise do domínio e/ou da tarefa.

Quanto ao modelo conceitual da interação, o modelo EDITOR adota o conceito de

edição como paradigma central. Pode ser considerado um processo de edição qualquer

seqüência de interações entre um usuário e um sistema, onde o usuário percebe (vê, escuta,

etc.) e controla (modifica, manipula, etc.) o estado da aplicação. Um editor é um componente

de software que suporta este processo por apresentar ao usuário uma visão particular do

estado da aplicação e mecanismos para controlar e modificar esses estados.

O modelo EDITOR une as vantagens arquiteturais do modelo PAC com as vantagens

de um modelo conceitual de interação, permitindo que seus elementos sejam identificados a

partir da descrição da tarefa através de regras claras e objetivas. EDITOR encontra no

paradigma orientado a objeto um modelo computacional adequado para sua representação e

realização.

��$JHQWHV�GR�PRGHOR�(',725�O modelo EDITOR define uma interface (editor) composta por três agentes do tipo

PAC, são eles: (GLWRU, 9LVmR e 2EMHWR�GH�,QWHUDomR, onde cada um deles apresenta as facetas

$SUHVHQWDomR, $EVWUDomR e &RQWUROH� obrigatoriamente, distribuídas a todos os níveis da

hierarquia.

A faceta $SUHVHQWDomR define a forma como o agente é percebido, sendo associado a

um objeto gráfico de uma biblioteca virtual gráfica. A faceta $EVWUDomR define um método

funcional da aplicação associado ao agente. A faceta &RQWUROH define o diálogo entre as

facetas $SUHVHQWDomR e $EVWUDomR� mantendo a coerência entre elas. Vejamos a organização

hierárquica dos agentes de um Editor na Figura 4:

29

sub-janela ...

(GLWRU

janela 9LVmR abstração

405�6#7�8 9#:-;�7#:"< =�8 7�>2?�@�A�9abstração ...

9LVmR

sub-janela405�6*7�8 9,:-;�7#:-< =�8 7�>&?�@�A�9

abstração

apresentação abstração apresentação 405�6*7�8 9,:-;�7#:-< =�8 7�>&?�@�A�9

apresentação abstração

abstração

��

)LJXUD��2UJDQL]DomR�GRV�DJHQWHV�GH�XP�(GLWRU�

Um agente (GLWRU�é um agente PAC composto que define um conjunto de visões sobre

a aplicação (agentes 9LVmR) apresentadas e organizadas em uma janela na tela. Sua faceta

$SUHVHQWDomR� é definida a partir de um objeto TXDGUR de uma biblioteca virtual. A faceta

$EVWUDomR permite designar um objeto da aplicação e definir as modalidades de comunicação

com ele. A faceta &RQWUROH� gerencia os eventos trocados entre a faceta $SUHVHQWDomR e

$EVWUDomR.

Um agente 9LVmR�é um agente PAC composto que define um conjunto de objetos de

interação (agentes 2EMHWRV� GH� ,QWHUDomR) agrupados. Sua faceta $SUHVHQWDomR� p� definida a

partir de um objeto sub-janela ou barra de menu da biblioteca virtual e também pelos eventos

recebidos do usuário. A faceta $EVWUDomR�permite designar um objeto da aplicação e de definir

as modalidades de comunicação com ele. A faceta &RQWUROH� gerencia os eventos trocados

entre a faceta $SUHVHQWDomR e $EVWUDomR, como também entre os 2EMHWRVBGH�,QWHUDomR� Um agente 2EMHWRBGHB,QWHUDomR� define uma forma de visualizar e manipular um

objeto da aplicação a partir de objetos interativos de uma biblioteca virtual. Sua faceta

$SUHVHQWDomR�p�definida a partir de um objeto especifico de uma biblioteca virtual e também

pelos eventos que o objeto de interação pode receber do usuário. A faceta $EVWUDomR�define

um elemento da aplicação e as modalidades de comunicação entre eles. Enfim, a faceta

&RQWUROH� define as modalidades de trocas (de dados e de controle) e de transformação de

formalismo entre os componentes. Os agentes 2EMHWRV� GH� ,QWHUDomR� podem ser simples e

complexos, como visto na Figura 4.

30

Como pudemos observar, uma especificação conceitual da interação segundo o

modelo EDITOR é uma árvore que espelha a composição gráfica da interface a ser gerada,

permitindo uma visualização (esboço) antecipada da sua apresentação.

��%DVH�GH�UHJUDV�HUJRQ{PLFDV�Trataremos nesta seção da base de regras ergonômicas de auxílio à concepção de

interfaces utilizada na metodologia MEDITE. São regras de produção do tipo (SE - ENTÃO)

extraídas de guias de recomendações, normas, padrões e guias de estilos ergonômicos com o

objetivo de auxiliar o projetista durante a passagem da descrição da tarefa para a

especificação da interação.

A base de regras contém dois tipos de regras: (L) regras para a construção da árvore

EDITOR e (LL) regras para definição dos atributos. As regras do tipo (L) relacionam elementos

do modelo da tarefa (MAD*) aos elementos do modelo da interação (EDITOR). Estas regras

são referentes à especificação conceitual inicial da interação, enquanto que as regras do tipo

(LL) definem os atributos das facetas de cada agente: $SUHVHQWDomR (localização, formato, tipo

e tamanho da fonte); $EVWUDomR (em relação ao domínio da aplicação); e &RQWUROH que define

o diálogo.

Exemplo de uma regra do tipo (L): SE a tarefa for de alto nível (MAD* ou TAOS) ENTÃO definir um (GLWRU (EDITOR)

cuja $SUHVHQWDomR�deve ser do tipo -DQHOD��Exemplo de uma regra do tipo (LL):

SE a tarefa for de alto nível� (MAD* ou TAOS) ENTÃO o tamanho, formato e

localização da janela (atributos EDITOR) será o pré-definido pelo tipo de plataforma

utilizado. Ex. Área do Browser, tratando-se de sistemas para Web.

As recomendações ergonômicas estão sujeitas a controvérsias, podendo ser

contraditórias em determinados contextos. Porém, as regras oriundas dessas recomendações

ajudam enormemente aos projetistas, especialmente aqueles (maioria) que não possuem

conhecimento em Ergonomia. A base de regras ergonômicas é uma base de conhecimento e,

portanto pode ser refinada ao longo do tempo e de seu uso.

31

��6XSRUWH�FRPSXWDFLRQDO��)HUUDPHQWDV��A maioria das metodologias baseada na tarefa para o projeto de interfaces do usuário

apresenta dificuldades de utilização quando não há a disponibilidade ou mesmo a existência

de ferramentas que auxiliem a construção das especificações, podendo este fato inviabilizar

sua utilização.

MEDITE possui como uma de suas características a independência de ferramentas

computacionais, ou seja, todo o processo de concepção de uma interface pode ser feito

independente de ferramentas, visto que todas as etapas do processo de concepção produzem

artefatos de acordo com modelos bem definidos.

Existem ferramentas disponíveis que poderiam ser incorporados à metodologia. Na

primeira etapa, a ferramenta MAD*-toolkit poderia ser utilizada para gerar a descrição MAD*

da tarefa. Na segunda, terceira e quarta etapas de MEDITE, onde a especificação da interação,

seu refinamento e a construção do protótipo são realizados respectivamente, a ferramenta

EDITOR OBJETO poderia ser utilizada, especificando a interação da interface através das

árvores EDITOR e realizando a implementação objeto dessas árvores, visto que elas são

representadas por uma estrutura orientada a objetos.

��&RQVLGHUDo}HV�ILQDLV�A metodologia MEDITE vem sendo utilizada na concepção de interfaces homem-

máquina no âmbito da Universidade Federal de Campina Grande. Como dito no capítulo

introdutório, realizar a análise e modelagem de tarefas, primeira etapa de MEDITE, sem a

disponibilidade de uma ferramenta específica que auxilie o projetista implica em problemas,

tais como: dificuldade em descrever a estrutura de árvores da tarefa, dificuldade em verificar a

consistência e completude da tarefa descrita e a impossibilidade de geração automática ou

semi-automática da especificação da interação.

Devido à dificuldade de aquisição de uma ferramenta para descrição de tarefas, como,

por exemplo, MAD*-toolkit, o GIHM trabalhou na geração de uma ferramenta específica para

este propósito. A ferramenta iTAOS, em parte fruto deste trabalho, implementa o formalismo

TAOS para análise e modelagem da tarefa. Devido à sua equivalência com o modelo MAD

32

(Kafure, 2000), acrescentado dos atributos orientados à especificação da interface e à

simulação do modelo de MAD*, podemos substituir MAD* por TAOS como modelo da

tarefa na metodologia MEDITE.

Embora MEDITE pressupunha MAD*, qualquer modelo da tarefa que tenha

equivalência com MAD* pode ser utilizado. O grupo de desenvolvimento de MEDITE é

quem está investindo em iTAOS, o que levará a uma substituição espontânea de MAD* por

TAOS.

Algumas vantagens em relação a outros métodos de concepção de interfaces nos

levaram a adotar MEDITE como processo de concepção do componente interativo (TAOS-

Graph) da ferramenta iTAOS para análise e modelagem de tarefas, entre elas:

• Facilidade em selecionar e aplicar regras ergonômicas por estarem classificadas de

acordo com as etapas do processo;

• Facilidade em passar da descrição da tarefa à especificação da interação por utilizar

um modelo da interação explícito e simples;

• Ser independente de ferramentas, devido ao uso de modelos conceituais bem

definidos;

• A especificação da interação segundo o modelo EDITOR proporciona uma descrição

gráfica clara e intuitiva da interface ao projetista.

Nos próximos quatro capítulos descreveremos a utilização da metodologia MEDITE para

a concepção da interface (TAOS-Graph) da ferramenta iTAOS.

33

&DStWXOR��$QiOLVH�H�PRGHODJHP�GD�WDUHID�³8WLOL]DU�D�IHUUDPHQWD� L7$26� SDUD� DQDOLVDU� H� PRGHODU�WDUHIDV´�

Neste capítulo descrevemos a análise e modelagem da tarefa “8WLOL]DU�D� IHUUDPHQWD�L7$26� SDUD� DQDOLVDU� H� PRGHODU� WDUHIDV” . Trata-se do ponto de partida dos processos de

concepção do módulo da interface (TAOS-Graph) e do módulo funcional (TAME) da

ferramenta iTAOS. A etapa de análise e modelagem da tarefa possui como entrada os dados

sobre o usuário e sobre a tarefa e apresenta como saída a descrição da tarefa segundo o

modelo TAOS.

�� $QiOLVH� H� PRGHODJHP� GD� WDUHID� QD� PHWRGRORJLD�0(',7(�

A análise e modelagem da tarefa correspondem a primeira etapa da metodologia

MEDITE como mostra a figura 5 abaixo:

�)LJXUD��$QiOLVH�H�PRGHODJHP�GD�WDUHID�QD�PHWRGRORJLD�0(',7(�

34

��$QiOLVH�H�0RGHODJHP�GD�7DUHID�

Nesta seção descrevemos o processo de aquisição dos dados sobre a tarefa e sobre o

usuário e posteriormente a descrição dessa tarefa utilizando o formalismo TAOS. A descrição

completa da tarefa “8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV” pode ser

encontrada em Medeiros, Cordeiro e Lula (2002a).

��$TXLVLomR�GH�GDGRV�VREUH�D�WDUHID�H�VREUH�R�XVXiULR�O processo de coleta de dados sobre a tarefa 8WLOL]DU� D� IHUUDPHQWD� L7$26� SDUD�

DQDOLVDU�H�PRGHODU�WDUHIDV e sobre o usuário foi realizado utilizando entrevistas semidirigidas,

a técnica WUDFH�DQDO\VLV e questionários.

A técnica de entrevista semidirigida utiliza o procedimento de perguntas e respostas

(Graesser, 1978), ou “ why and how” (Sebillote, 1991). Baseado nas questões do tipo :K\�DQG�+RZ que iam sendo levantadas e nas respostas dadas e analisadas, foi possível identificar

quais tarefas eram de nível alto ou intermediário (planos) ou de baixo nível (ações),

possibilitando que a tarefa fosse descrita hierarquicamente (Sebillote, 1988).

Em paralelo com as entrevistas realizadas, foi utilizada a técnica WUDFH�DQDO\VLV, que

consiste de um processo de coleta de dados através da observação de usuários realizando a

tarefa e de consultas a documentos. Essa técnica foi utilizada com o intuito de complementar

a descrição da tarefa e para isso foram realizadas consultas a manuais e livros sobre: análise

de tarefas, TAOS e ferramentas para análise de tarefas, permitindo que novos elementos

fossem agregados a descrição e que alguns elementos já levantados fossem checados.

Finalmente, utilizamos o questionário DePerUse (Queiroz, 2001) para obtenção de

dados sobre o usuário da tarefa 8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV (ver Apêndice 1). Este questionário foi aplicado a 22 estudantes de graduação ou pós-

graduação que já analisaram e modelaram tarefas utilizando o formalismo MAD ou o

formalismo TAOS. Do questionário aplicado e das entrevistas semidirigidas realizadas,

traçamos o perfil do usuário (Turnell, 1998) (ver Apêndice 2). O perfil traçado do usuário

35

aborda as seguintes questões: grau de instrução, habilidades para realização da tarefa,

motivações, faixa etária, experiência com a tarefa ou com sistemas similares, etc.

��'HVFULomR�GD�WDUHID�XWLOL]DQGR�7$26�Apresentamos abaixo parte da descrição TAOS da tarefa 8WLOL]DU�D�IHUUDPHQWD�L7$26�

SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV. Esta descrição foi oriunda dos dados sobre a tarefa e sobre o

usuário levantados através das técnicas descritas anteriormente. A descrição completa da

tarefa pode ser encontrada em Medeiros, Cordeiro e Lula (2002a).

Na figura 5 a seguir, apresentamos um trecho da árvore de modelagem que representa

os níveis mais altos da hierarquia, ou seja, os objetivos gerais da tarefa 8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV. Essa descrição TAOS da tarefa expressou fielmente

os dados obtidos das entrevistas, dos questionários e da técnica trace analysis, o que significa

afirmar que o usuário que deseja modelar tarefas utilizando a ferramenta iTAOS tem que

executar pelo menos uma das seguintes sub-tarefas: ativar ambiente de modelagem, realizar a

modelagem da tarefa, verificar o modelo criado, simular o modelo criado, alternar entre os

modelos disponíveis e abertos, solicitar ajuda e desativar ambiente de modelagem, segundo

sua própria vontade, como podemos observar na figura 6.

)LJXUD��7DUHID�³0RGHODUBWDUHIDVBXWLOL]DQGRBL7$26´�Na figura 7 a seguir, apresentamos um trecho da árvore que representa a sub-tarefa

(GLWDU� $JHQWH� O usuário que deseja editar um agente deve executar uma ou mais das

seguintes ações: Editar nome do agente, Editar descrição do agente, Editar competência,

B2C DE0F

B2C GB&C HB2C I

B

B2C JB2C KB2C B

B2C B2C J B2C B&C HB2C B2C KL�M%N O�M�P2Q

RTSVU�W N S0X Y�Z [%\

B2C B2C IB2C B2C B] E+F

^"_2` N ` a M�PbM+c W P�P,M RTW�[ _ M ` d�e EfLhg�M%P,MM [ M%N ` i M�P W-RTSVU�W N M�P _ M�P W cjM i X2k'Z [%\

F W MVN ` a M�P2Q R1SU�W N M%l W�RmX2k'Z [%\n W P ` c ` o M�P2Q RTSU�W N S0X Y�Z [%\

L ` RTp N M�P2Q RS'U�W N S�XqY�Z [�\

e N _ W P [ M%P2Q RSVU�W N S0X Y�Z [%\

L S N ` o�` M�PjQ�Mr p�U MXqY%Z [�\

s"P ` M�P2Q [�S O S QRTSVU�W N S�XqY�Z [�\

t U ` _ M%P2Q RTSVU�W N SXqY%Z [�\

u R g�P ` R ` P2QR1S'U�W N S�XqY�Z [�\

v W o�w M�P2Q RTSVU�W N SX Y�Z k,\

e0_j` O�M�PM R1x ` W�[ _ W-U�WRTSVU�W N MVl%yX&kZ [�\

z W i M _2` O�M�PM RTx ` W�[ _ W-U�WRTSVU�W N M%l%yX2k'Z [%\

36

Editar experiência com a tarefa, Editar experiência com um sistema similar, Editar meios de

interação.

)LJXUD��7DUHID�³(GLWDUB$JHQWH´�Após a apresentação de dois trechos da árvore TAOS da descrição 8WLOL]DU� D�

IHUUDPHQWD� L7$26� SDUD� DQDOLVDU� H�PRGHODU� WDUHIDV, mostraremos os descritores relativos a

tarefa 5HDOL]DUBPRGHODJHP e a ação (GLWDUBQRPHBDJHQWH respectivamente. A escolha dessa

tarefa e dessa ação ocorreu de forma aleatória. Os descritores definem os elementos e

atributos das tarefas e ações da descrição gerada.

Além dos atributos nome, número e ocorrência já encontrados em cada tarefa e em

cada ação na própria árvore TAOS de modelagem, as tarefas e ações possuem atributos,

objetos e procedimentos que são armazenados nos descritores. A seguir mostramos os

descritores relativos a tarefa 5HDOL]DUBPRGHODJHP:

&ODVVH� 7DVN�1DPH� Realizar_modelagem 'HVFULSWLRQ� Realizar a modelagem, criar as árvores e descritores 3UH�VLWXDWLRQ� Situação_Inicial_de_Realizar_Modelagem 3RV�VLWXDWLRQ� Situação_Objetivo_de_Realizar_Modelagem 2FXUUHQFH� (0,n) $FWLRQV� [Salvar_Modelo, Imprimir_Modelo, Fechar_Modelo] 6XE�SODQV� [Criar_um_Novo_Modelo, Editar_Modelo_Existente] +RZ�WR�UHDOL]H� Método_Realizar_Modelagem 3ULRULW\� �� 1 ��2 ��[��3 ,QWHUUXSWLELOLW\� �� Não interrompível

�� Interruptível com reprise no início ��[�� Interruptível com reprise em curso ATRIBUTOS ORIENTADOS A ESPECIFICAÇÃO DA INTERFACE

7\SH�RI�WKH�WDVN� ([) sensório-motor ([) mental �[) verbal ( ) Outro 0RGDOLW\�RI�WKH�WDVN� �� manual �� automático ��[�� interativo ,PSRUWDQFH�RI�WKH�WDVN� �[� importante �� mediana �� secundária )UHTXHQFH�RI�WKH�WDVN� �� elevada ��[�� mediana �� fraca

'HVFULWRU��&ODVVH�7DUHID�5HDOL]DUBPRGHODJHP�

E0FB&C I*C I*C K*C J�C BjI*C J*C GB&C I*C I*C K*C J�C BjI*C J*C HB2C I*C I#C K*C J�C B2I*C J�C JB2C I*C I*C K*C J*C BjI*C J�C KB&C I*C I*C K*C J�C BjI*C J*C IB&C I*C I*C K*C J�C BjI*C J*C B

t U ` _ M�P2Q e l W�[ _ W-X Y�Z [�\

t U ` _ M�P2Q[�S'R1W QM%l W�[ _ WXqY%Z [�\

t U ` _ M�P2QU�W i�o P ` {�| S QM%l W�[ _ WX Y�Z [%\

t U ` _ M�P2Qo SVR g W _2} [ o�` MXqY�Z [�\t U ` _ M%P2QW,~ g W P ` } [ o�` M,Qo S'R Q�M,Q d M%P W c2MX Y�Z [�\

t U ` _ M�P2QW,~ g W P ` } [ o�` M,Qo SVR Q p�R Qi�` i&_ W�R M,Q i*` R ` N MPXqY�Z [�\

t U ` _ M�P2QRTW ` S i Q U�W Qu [ _ W P,M {�| SX Y�Z [%\

B&C I*C I*C K*C J�C BjI*C J

37

&ODVVH� 6LWXDomR�1DPH� Situação_Inicial_de_Realizar_Modelagem 'HVFULSWLRQ� Situação que deve ser satisfeita para o início da realização de uma modelagem

da tarefa 2EMHFWV� [Ambiente_de_Modelagem, Mouse, Teclado, Projetista_de_Interface] 5HVWULFWLRQ� ativado(Ambiente_de_Modelagem), disponível(Mouse), disponível(Teclado),

disponível(Projetista_de_Interface) &RPR�$WLQJLU� Ativar_Ambiente_de_Modelagem

'HVFULWRU��&ODVVH�6LWXDomR�6LWXDomRB,QLFLDOBGHB5HDOL]DUB0RGHODJHP�&ODVVH� 6LWXDomR�1DPH� Situação_Objetivo_de_Realizar_Modelagem 'HVFULSWLRQ� Situação depois da tarefa realizar modelagem 2EMHFWV� Modelo, Mouse, Teclado, Projetista_de_Interface 5HVWULFWLRQ� OR(XOR(criado(Modelo),editado(Modelo)),salvo(Modelo),impresso(Modelo),

Fechado(Modelo)), disponível(Mouse), disponível(Teclado), Disponível(Projetista_de_Interface))

+RW�WR�REWDLQ� Realizar_Modelagem

'HVFULWRU��&ODVVH�6LWXDomR�6LWXDomRB2EMHWLYRBGHB5HDOL]DUB0RGHODJHP�&ODVVH� 0pWRGR�1DPH� Método_Realizar_Modelagem 'HVFULSWLRQ� Estratégia para Modelar modelagem %RG\� OR(XOR(Criar_um_Modelo_Existente, Editar_um_Modelo_Existente),

Salvar_Modelo, Imprimir_Modelo, Fechar_Modelo)

'HVFULWRU��&ODVVH�0pWRGR�0pWRGRB5HDOL]DUB0RGHODJHP�Descritores da ação (GLWDUBQRPHBDJHQWH.

&ODVVH� $omR�1DPH� Editar_nome_agente 'HVFULSWLRQ� Editar o nome de um agente 3UH�VLWXDWLRQ� Situação_Objetivo_de_Selecionar_Link_para_Agente 3RV�VLWXDWLRQ� Situação_Objetivo_de_Editar_Agente 2FXUUHQFH� (0,n) $JHQW� Projetista de interface 7RRO� Ambiente de modelagem 3ULRULW\� ��[�� 1 ��2 ��3 ,QWHUUXSWLELOLW\� �� Não interrompível

�� Interruptível com reprise no início ��[�� Interruptível com reprise em curso

ATRIBUTOS ORIENTADOS A ESPECIFICAÇÃO DA INTERFACE 7\SH�RI�WKH�WDVN� ��[�� sensório-motor �� mental �� verbal 2XWUR� 0RGDOLW\�RI�WKH�WDVN� ��[�� manual �� automático �� interativo ,PSRUWDQFH�RI�WKH�WDVN� ��[�� importante �� mediana �� secundária )UHTXHQFH�RI�WKH�WDVN� ��[�� elevada �� mediana �� fraca

'HVFULWRU��&ODVVH�$omR�(GLWDUBQRPHBDJHQWH� &ODVVH� 6LWXDomR�1DPH� Situação_Inicial_de_Editar_Nome_Agente 'HVFULSWLRQ� Pós situação da ação Selecionar Link para Agente 2EMHFWV� [atributos_agente]

38

5HVWULFWLRQ� Exibido(atributos_agente) +RZ�WR�REWDLQ� -

'HVFULWRU��&ODVVH�6LWXDomR�6LWXDomRB,QLFLDOBGHB(GLWDUB1RPHB$JHQWH� &ODVVH� 6LWXDomR�1DPH� Situação_Objetivo_de_Editar_Nome_Agente 'HVFULSWLRQ� Pré Situação do plano Editar Agente 2EMHFWV� [agente] 5HVWULFWLRQ� Editado(agente) +RZ�WR�REWDLQ� -

'HVFULWRU��&ODVVH�6LWXDomR�6LWXDomRB2EMHWLYRBGHB(GLWDUB1RPHB$JHQWH�

&ODVVH� $JHQWH�1DPH� Projetista_de_Interface 'HVFULSWLRQ� Projetista de interface que modela tarefas &RPSHWHQFH� Todas as ações de plano Modelar tarefas WDVN([SHULHQFH� �� iniciante ��[�� meio �� especialista VLPLODU6\VWHP([SHULHQFH� ��[�� elementar �� médio �� complexo�

'HVFULWRU��&ODVVH�$JHQWH�3URMHWLVWDBGHB,QWHUIDFH�&ODVVH� ,QVWUXPHQWR 1DPH� Ambiente_de_Modelagem 'HVFULSWLRQ� Ambiente utilizado pelo projetista de interface para modelar a tarefa 8VHU� Projetista_de_Interface 8WLOLW\� Todas as ações do plano Modelar tarefas

'HVFULWRU��&ODVVH�,QVWUXPHQWR�$PELHQWHBGHB0RGHODJHP�

��$YDOLDomR�GD�PRGHODJHP�A avaliação da descrição TAOS da tarefa foi realizada junto aos usuários

concomitantemente com a modelagem da tarefa. Por se tratar de um processo interativo e

iterativo, à medida que a coleta dos dados sobre o usuário e sobre a tarefa era realizada, a

árvore e os descritores TAOS da tarefa eram construídos em conjunto com os usuários.

Freqüentemente, os usuários avaliavam a descrição que estava sendo construída e essa

avaliação era então discutida com os projetistas ensejando eventualmente possíveis

modificações.

A avaliação procurou verificar que as árvores e os descritores correspondiam à lógica

de execução da tarefa segundo os usuários. Foi verificada também a consistência das pré e

pós-condições e a completude do modelo, além de remover as tarefas não informatizáveis,

sempre focando na utilização dessa descrição para a concepção da ferramenta iTAOS.

39

��&RQVLGHUDo}HV�ILQDLV�Neste capítulo foi apresentada a descrição TAOS da tarefa 8WLOL]DU� D� IHUUDPHQWD�

L7$26� SDUD� DQDOLVDU� H� PRGHODU� WDUHIDV�� Essa descrição corresponde a primeira etapa da

metodologia MEDITE, que foi utilizada para concepção do módulo interativo (TAOS-Graph)

da ferramenta iTAOS.

A descrição da tarefa 8WLOL]DU� D� IHUUDPHQWD� L7$26�SDUD�DQDOLVDU� H�PRGHODU� WDUHIDV possuiu como entrada dados sobre o usuário e sobre a tarefa obtidos através de técnicas de

coleta de dados como entrevistas semidirigidas e WUDFH�DQDO\VLV�e de questionários. Tratou-se

de um processo interativo e iterativo pelo fato de que os usuários estiveram sempre presentes

disponibilizando informações para que a tarefa fosse descrita segundo o formalismo TAOS. À

medida que a árvore e os descritores TAOS da tarefa eram construídos, o usuário os avaliava.

Essa avaliação foi realizada periodicamente e em paralelo com a modelagem.

A partir do questionário DePerUse aplicado a 22 pessoas, foram obtidas informações

sobre o usuário que ajudou a levantar seu perfil. As informações contidas no perfil do usuário

(Queiroz, 1998), juntamente com as entrevistas semidirigidas e observações, foram

representados nos descritores $JHQWH da descrição TAOS da tarefa. O descritor $JHQWH possui

os seguintes atributos: experiência com a tarefa, experiência com um sistema similar e os

meios de interação para execução a tarefa.

No próximo capítulo apresentaremos o processo de concepção da especificação

completa da interação. A especificação da interação possuiu como entrada a descrição da

tarefa mostrada neste capítulo e utilizou o conhecimento ergonômico armazenado numa base

de regras ergonômicas para transformação das árvores TAOS da tarefa nas árvores EDITOR

da interação.

40

&DStWXOR��(VSHFLILFDomR�FRQFHLWXDO�GD�LQWHUDomR�

Neste capítulo descrevemos o processo de obtenção da especificação conceitual da

interação a partir da descrição da tarefa 8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV. Trata-se do processo de construção das árvores EDITOR, nesta etapa cada agente do

modelo EDITOR ((GLWRU��9LVmR�H�2EMHWRBGHB,QWHUDomR) é definido.

Situaremos inicialmente a especificação conceitual dentro da metodologia MEDITE,

depois descreveremos a especificação conceitual parcial da interação, que consiste da

construção das árvores EDITOR a partir das árvores TAOS da tarefa e posteriormente

apresentaremos a especificação completa da interação, onde os atributos relativos a

$SUHVHQWDomR, $EVWUDomR e &RQWUROH são definidos a anexados as árvores. A especificação

completa da interação pode ser encontrada em Medeiros, Cordeiro e Lula (2002b).

��(VSHFLILFDomR�FRQFHLWXDO�GD� LQWHUDomR�QD�PHWRGRORJLD�0(',7(�

A especificação conceitual da interação corresponde à segunda e à terceira etapa da

metodologia MEDITE como mostra a figura abaixo:

�)LJXUD��(VSHFLILFDomR�FRQFHLWXDO�GD�LQWHUDomR�QD�PHWRGRORJLD�0(',7(�

41

��(VSHFLILFDomR�FRQFHLWXDO�SDUFLDO�GD�LQWHUDomR�Esta etapa teve como entrada a descrição TAOS da tarefa e possuiu como saída à

especificação conceitual parcial da interação, ou seja, as árvores parciais EDITOR. Nesse

momento ocorreu a primeira inserção do conhecimento ergonômico, representado sob a forma

de regras de produção, no processo de transformação das árvores TAOS (descrição da tarefa)

nas árvores EDITOR (especificação da interação).

Descrevemos o processo de construção de algumas árvores EDITOR explorando a

transformação das árvores TAOS nas árvores EDITOR com o auxílio das regras ergonômicas.

Apresentamos a seguir alguns trechos das árvores EDITOR geradas nesta etapa. No texto,

essas árvores EDITOR serão sempre precedidas pela árvore TAOS da tarefa equivalente e das

regras ergonômicas utilizadas para fazer a transformação.

Mostramos, inicialmente, a transformação dos dois primeiros níveis da árvore TAOS

da tarefa 8WLOL]DU� D� IHUUDPHQWD� L7$26� SDUD� DQDOLVDU� H� PRGHODU� WDUHIDV� (ver figura 5)4 na

árvore EDITOR correspondente (especificação conceitual parcial da interação). Partindo da

árvore TAOS e com o auxílio de regras ergonômicas foi construída a árvore EDITOR da

figura 9. As seguintes regras foram utilizadas:

F W l%P,M k%� SE a tarefa for de alto nível (TAOS) ENTÃO definir um �� '� (Modelo Editor) cuja ��*�#�#�,�� ,�%� deve

ser do tipo �%�V�� %� F W l%P,M+� : SE as tarefas forem ligadas pelo construtor OU (TAOS) ENTÃO definir para esse conjunto de tarefas uma � � �*�� (Modelo Editor) cuja ��#�#�#�,�� ,�� deve ser do tipo ��%��*��h��#�� e cada tarefa deve ser um �� V�� %�� ,��,�%� (Modelo Editor) do tipo � � �,�� ,�� dessa

� � �*�� .��F W l%P,M� �y SE a tarefa for de alto nível ou de nível intermediário (MAD*) ENTÃO definir uma Visão (EDITOR)

específica, cuja Apresentação será do tipo Região. O Objeto_de_Interação desta Visão deve ter uma Apresentação do

tipo Caixa de Texto. (Este objeto deve conter texto de orientação, explicando em que estado o usuário se encontra, e

quais os procedimentos que deve tomar naquele estado).

Pelo fato da tarefa 8WLOL]DU�D�IHUUDPHQWD�L7$26�SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV ser de

alto nível, foi definido um editor (GLWRU�0RGHODU� WDUHID cuja faceta $SUHVHQWDomR é do tipo

Janela (Regra 1). Como as sub-tarefas (sub-planos e ações) da tarefa 8WLOL]DU�D� IHUUDPHQWD�L7$26� SDUD� DQDOLVDU� H�PRGHODU� WDUHIDV são ligados por um construtor OU, foi criada uma 4 Na figura 5 foram apresentados três níveis da árvore TAOS da tarefa, porém mostramos a transformação na

árvore EDITOR de somente dois desses níveis.

42

visão )XQFLRQDOLGDGHV cuja faceta ASUHVHQWDomR é do tipo barra de menu e cada sub-tarefa é

um objeto de interação do tipo item-menu (Regra 2). Aplicando a regra 3 acima foi definida

uma visão que expressa a orientação do usuário.

��

�

��

)LJXUD��ÈUYRUH�(',725�SDUFLDO�GD�WDUHID��0RGHODU�WDUHID��Apresentamos, a seguir, o processo de construção da árvore EDITOR correspondente

a descrição TAOS da tarefa 5HDOL]DU�0RGHODJHP, ou seja, o segundo e o terceiro nível da

árvore TAOS apresentada na figura 5. A seguinte regras foi utilizada no processo de

transformação:

5HJUD��SE a centralidade da tarefa for importante e sua frequência elevada�(MAD*) ENTÃO optar por

um diálogo de tipo menu hierárquicos (tipo de menu) (EDITOR).

De acordo com a regra acima, pelo fato da tarefa 5HDOL]DU�PRGHODJHP ser considerada

importante e de freqüência elevada, optamos por utilizar um menu hierárquico com as opções:

Criar um novo modelo, Editar modelo existente, Salvar modelo, Imprimir modelo e Fechar

modelo.

Vejamos na figura 10 a especificação conceitual parcial da interação da tarefa 5HDOL]DU�PRGHODJHP:

... Abstração

Abstração

Abstração

(GLWRU�0RGHODU�WDUHID�

¡�¢&£ C&¤ ¥�¦ CExplicação

Apresentação Região (Panel)

§�¨ © ª*«Explicação

Apresentação Janela do iTAOS

(Frame)

§�¨ © ª�«Funcionalidades

§�¨ © ª*«Orientação

Abstração

Apresentação Barra-menu

(Panel)

¡�¢&£ C&¤ ¥�¦ CVerificar modelo

¡�¢&£ C&¤ ¥�¦ CRealizar

modelagem

¡�¢&£ C&¤ ¥�¦ CSimular modelo

¡�¢&£ C&¤ ¥�¦ CAlternar modelo

¡�¢&£ C&¤ ¥�¦ CSolicitar

ajuda

Abstração

Apresentação Item menu

Abstração

Apresentação Caixa de

texto


Abstração

43

��

)LJXUD��ÈUYRUH�(',725�SDUFLDO�GD�WDUHID��5HDOL]DU�PRGHODJHP��As regras ergonômicas disponíveis na primeira versão da base de regras ergonômicas

não foram suficientes para que fosse realizada a transformação de toda a árvore TAOS da

tarefa nas árvores EDITOR correspondentes. Por esse motivo, algumas regras foram

modificadas e outras criadas baseando-se na nossa experiência com outras ferramentas

equivalentes já existentes. A regra abaixo foi adaptada de uma regra já existente:

5HJUD��SE as tarefas forem ligadas pelo construtor OU e essas tarefas forem do tipo Editar ... (TAOS) ENTÃO

definir para esse conjunto de tarefas uma � � �*�%� (Modelo Editor) cuja ��*�#�#�,�� %�,�� deve ser do tipo ¬��V��0�V� %�,� � e

cada tarefa deve ser um �-� �'�� 0�%� � �� ,��,�� (Modelo Editor) do tipo ®,�� ¯��+��-� �2¯�� dessa � � �#�%� .

��(GLWRU�(GLWDU�DJHQWH

��

)LJXUD��ÈUYRUH�(',725�SDUFLDO�GD�WDUHID��(GLWDU�DJHQWH��

Apresentação Caixa de texto

Abstração Abstração

…

Apresentação Sub-janela do

iTAOS

°�± ²2³�Átributos do

descritor Agente

Abstração

Apresentação Região

(Formulário)

µb¶�·q¸ ± ¹'º »*¼&½�¾�³�Éditar descrição

instrumento

µb¶�· ¸ ± ¹'º »*¼&½�¾�³�Éditar competência

µb¶�· ¸ ± ¹'º »*¼&½�¾�³�Éditar experiência

com a tarefa

µb¶�·q¸ ± ¹'º »*¼&½�¾�³�Éditar experiência com um sistema

equivelente


µb¶,·q¸ ± ¹'º »*¼�½�¾�³�Éditar nome

agente

µb¶�· ¸ ± ¹'º »*¼&½�¾�³�Éditar meios de

interação Abstração

... Apresentação Texto (Label)

Abstração

E x r*y u [ _ yRealizar

modelagem

Apresentação Menu

E x r#y u [ _ yEditar modelo

existente

E x r#y u [ _ yCriar novo

modelo

E x r*y u [ _ ySalvar modelo

E x r*y u [ _ yImprimir modelo

E x r*y u [ _ yFechar modelo

Abstração

44

A figura 11 apresenta a árvore EDITOR correspondente à tarefa (GLWDU�DJHQWH que foi

obtida a partir do trecho da árvore TAOS mostrado no capítulo anterior na figura 6 utilizando

a regra ergonômica acima.

O produto gerado nesta etapa é, portanto, o conjunto de árvores (parciais) EDITOR.

Porém, as árvores ainda não estão completas, falta definir os atributos dessas árvores.

Apresentaremos na próxima seção algumas árvores completas acrescentando os atributos

referentes às facetas $SUHVHQWDomR (localização, formato, tamanho de fonte, etc.), $EVWUDomR�(em relação ao domínio da aplicação) e &RQWUROH��definindo o encadeamento do diálogo entre

as janelas da interface.

��(VSHFLILFDomR�FRQFHLWXDO�FRPSOHWD�GD�LQWHUDomR�Esta etapa teve como entrada a especificação conceitual parcial da interação (árvores

EDITOR parciais) e teve como saída à especificação conceitual completa da interação, ou

seja, as árvores EDITOR completas. Nesta etapa, ocorreu a segunda inserção do

conhecimento ergonômico, representado sob a forma de regras de produção, na definição dos

atributos das facetas $SUHVHQWDomR�(localização, formato, tamanho de fonte, etc.), $EVWUDomR�(com relação ao domínio da aplicação) e &RQWUROH.

Apresentamos ,a seguir, novamente, as três árvores EDITOR apresentadas na seção

anterior acrescidas dos atributos das facetas $SUHVHQWDomR, $EVWUDomR e &RQWUROH. Mostramos

como foram definidos estes atributos através do conhecimento ergonômico representado pelas

regras ergonômicas. Baseado nas regras ergonômicas abaixo, os atributos do (GLWRU�0RGHODU�WDUHID foram definidos:

F W l%P,MÀ¿ � SE a tarefa for de alto nível (TAOS) ENTÃO o tamanho, formato e localização da janela (atributos

EDITOR) será o pré-definido pelo tipo de plataforma utilizado.

F W l%P,MhÁ � SE o número de opções a escolher para concluir ou prosseguir uma determinada tarefa for pequeno (sete ou

menos) (Árvore EDITOR parcial), ENTÃO pode-se optar pela orientação horizontal. (orientação).�F W l%P,MÀÂ � SE a orientação do menu for horizontal (Árvore EDITOR), ENTÃO dispor as opções de escolha da

esquerda para a direita no canto superior esquerdo (atributos EDITOR - alinhamento).

F W l%P,M�Ã � SE o �-� �V�� %� � �� #�*�%�,�� for do tipo Texto (Item-menu) ou Caixa de Texto ENTÃO utilizar sempre a

mesma fonte, de tamanho entre 12 a 20 pontos (atributos EDITOR - tipo / tamanho).

45

��

�)LJXUD��ÈUYRUH�(',725�FRPSOHWD�GD�WDUHID��0RGHODU�WDUHID��

O (GLWRU�0RGHODU�WDUHID possui como $SUHVHQWDomR uma janela com tamanho, formato

e localização pré-definido pela plataforma utilizada, segundo a regra 6. Este editor define duas

visões: a visão )XQFLRQDOLGDGHV e a visão 2ULHQWDomR. Como o número de opções a escolher

na visão )XQFLRQDOLGDGHV é pequeno, foi definida uma barra de menu horizontal. Estas opções

da barra de menu estão dispostas da esquerda para direita e no canto superior esquerdo como

dizem as regras ergonômicas 7 e 8. A $SUHVHQWDomR do objeto de interação ([SOLFDomR é uma

caixa de texto com os atributos definidos segundo a regra ergonômica 9.

Mostramos s seguir um extrato da árvore EDITOR completa que representa o objeto

de interação 5HDOL]DU� PRGHODJHP. A faceta $EVWUDomR dos objetos de interação que

representam os itens de menu do menu Realizar modelagem acessam os métodos do módulo

funcional da ferramenta iTAOS (módulo TAME).

(GLWRU�0RGHODU�WDUHID�

Apresentação

... Abstração

Abstração

Abstração

µb¶,·q¸�Ä ¹'º ¸Explicação

Apresentação Região (Panel)

°�± ²2³�´Explicação

Apresentação Janela do iTAOS

(Frame)

°�± ²j³�´Funcionalidades

°�± ²2³�´Orientação

Abstração

Apresentação Barra-menu

(Panel)

µ�¶�·q¸�Ä ¹'º ¸Verificar modelo

µb¶�· ¸�Ä ¹º ¸Realizar

modelagem

µb¶�· ¸�Ä ¹º ¸Simular modelo

µb¶�·q¸�Ä ¹'º ¸Alternar modelo

µb¶�·q¸�Ä ¹'º ¸Solicitar

ajuda

Abstração


Abstração

Apresentação Caixa de

texto


Abstração

Tamanho: total Orientação: horizontal

Tamanho: 10% Orientação: Horizontal Localização: superior Alinhamento: esquerda

Tam. fonte: 12 Cor: preta Alinhamento: à esquerda

Tamanho: 90% Orientação: horizontalLocalização: inferior Background: branco

46

Extrato da árvore EDITOR completa da tarefa 5HDOL]DU�0RGHODJHP�

)LJXUD��ÈUYRUH�(',725�FRPSOHWD�GD�WDUHID��5HDOL]DU�PRGHODJHP��Apresentamos na figura 14 a árvore EDITOR completa que representa a tarefa Editar

agente. Utilizamos as seguintes regras ergonômicas para definição dos atributos dessa árvore:

Å0Æ�Ç%È,É�Ê%Ê: SE o Objeto_de_Interação for do tipo Texto (Item-menu) ou Caixa de Texto ENTÃO utilizar sempre a

mesma fonte, de tamanho entre 12 a 20 pontos (atributos EDITOR - tipo / tamanho).

Å0Æ�Ç%È,É�Ê,Ë: SE o Objeto_de_ Interação for do tipo Texto (Item-menu) ou Caixa de Texto (Árvore EDITOR parcial)

ENTÃO utilizar cor fonte contrastante com a cor de fundo (atributos EDITOR - formato).

Å0Æ�Ç%È,ÉÌÊ�Í�ÎSE o Objeto_de_Interação for do tipo Caixa de Texto (Árvore EDITOR parcial) ENTÃO o texto deve ser

justificado à esquerda (atributos EDITOR - alinhamento).

��

ÏhÐ'Ñ*Ò'Ó#Ô�ÕjÒRealizar

modelagem

Apresentação Texto (Label)

... Apresentação Texto (Label)

Abstração

Apresentação Menu

ÏhÐ'Ñ*Ò'Ó#Ô�ÕjÒEditar modelo

existente

ÏhÐ'Ñ*Ò'Ó#Ô�ÕjÒCriar novo

modelo

ÏÌÐÑ#ÒÓ,Ô�Õ2ÒSalvar modelo

ÏhÐ'Ñ*Ò'Ó#Ô�ÕjÒImprimir modelo

ÏhÐ'Ñ*Ò'Ó#Ô�Õ2ÒFechar modelo

Abstração

Tam. fonte: 12 Cor: preta Alinhamento: à esquerda

- Faz ligação com o editor Editar Árvore - Substitui a visão Orientação - Cria uma instância de Model e chama getTaskTree e getTAOSFactory do módulo TAME

ÏhÐ'Ñ*Ò'Ó#Ô�Õ2ÒSelecionar

modelo

Apresentação Janela do tipo

Open File

Abstração

- Aparece sobre a visão Orientação Ö Chama loadFromFile da classe Model do módulo TAME

Abstração

47

��

��

)LJXUD��ÈUYRUH�(',725�FRPSOHWD�GD�WDUHID��(GLWDU�DJHQWH��

��$YDOLDomR�GD�(VSHFLILFDomR�A especificação conceitual da interação obtida segundo o descrito anteriormente foi

objeto de uma avaliação realizada em duas etapas, como preconiza a metodologia MEDITE: a

avaliação das árvores EDITOR parciais e a avaliação das árvores EDITOR completas. A

primeira etapa verificou que as regras ergonômicas foram aplicadas corretamente na

construção das árvores EDITOR, enquanto que a segunda etapa verificou que os atributos

definidos estavam também de acordo com as regras ergonômicas definidas na base de regras

ergonômicas. Esta verificação foi realizada através de uma revisão no processo de

transformação das árvores TAOS nas árvores EDITOR aplicando as regras ergonômicas, bem

como na utilização da experiência e do bom senso para verificar que as árvores geradas

apresentavam coerência com os objetivos da concepção.

À medida que as árvores EDITOR eram construídas, já era possível ter uma

visualização da apresentação (esboço das janelas) do sistema, visto que, como já dito no item

Abstração

Abstração

…

Apresentação Sub-janela do

iTAOS

°�± ²j³�Átributos do

descritor Agente

Abstração

Apresentação Região

(Formulário)

µb¶�· ¸ ± ¹'º »*¼&½�¾�³�Éditar descrição

instrumento

µ�¶�·q¸ ± ¹º »*¼�½�¾�³�Éditar competência

µ�¶�·q¸ ± ¹º »*¼�½�¾�³�Éditar experiência

com a tarefa

µb¶�· ¸ ± ¹'º »*¼&½�¾�³�Éditar experiência com um sistema

equivelente


µb¶�·q¸ ± ¹'º »*¼&½�¾�³�Éditar nome

agente

µ�¶�·q¸ ± ¹º »*¼�½�¾�³�Éditar meios de

interação


Abstração

Tam: 25x10 cm Localização: centralizado horizontal e verticalmente

Tam: 100% do total Alinhamento: à esquerda

Tam: 1,5x15 cm Alinhamento: à esquerda Cor da fonte: preta Tam. da fonte: 12

Chama o método setName da classe Agent do módulo TAME

Tam: 1,5x15 cm Alinhamento: à esquerda Cor da fonte: preta Tam. da fonte: 12

Chama o método setSystemExperience da classe Agent do módulo TAME

(GLWRU�(GLWDU�DJHQWH

48

3.3.1, uma árvore EDITOR espelha a composição gráfica da interface a ser gerada. Essa

especificação era então levada ao usuário para apreciação, num processo paralelo de

construção e avaliação da interação do sistema. Ao longo desse processo foram sugeridas

algumas modificações que foram analisadas pelos projetistas e executadas em determinadas

situações.

��,QWHJUDomR�GRV�PyGXORV�7$26�*UDSK�H�7$0(�Como citado anteriormente, os módulos TAME e TAOS-Graph foram desenvolvidos

separadamente, baseando-se no princípio da independência do diálogo. Porém, ao final, estes

módulos tiveram que ser integrados, formando assim a ferramenta iTAOS. Essa integração se

deu através de uma API ($pplication ,nterface 3rogramming) disponibilizada no módulo

TAME, ou seja, no componente funcional.

Não houve a necessidade de que o módulo TAME estivesse finalizado para que o

módulo TAOS-Graph começasse a ser construído. Uma primeira versão funcional do módulo

TAME foi construída e disponibilizada então a API, que foi sendo utilizada para a construção

do TAOS-Graph. O módulo TAOS-Graph evoluiu ao passo que o módulo TAME evoluía.

Os atributos da faceta $EVWUDomR da especificação conceitual da interação definem os

métodos que foram invocados da API disponibilizada no módulo TAME. Alguns desses

métodos foram apresentados nos extratos das árvores EDITOR apresentadas nesse capítulo.

��&RQVLGHUDo}HV�ILQDLV�Neste capítulo foi apresentado o processo de obtenção da especificação da interação da

tarefa 8WLOL]DU� D� IHUUDPHQWD� L7$26� SDUD� DQDOLVDU� H� PRGHODU� WDUHIDV�� Essa especificação

corresponde à segunda e à terceira etapa da metodologia MEDITE, que foi utilizada para

concepção do módulo interativo (TAOS-Graph) da ferramenta iTAOS.

A especificação da interação foi realizada em dois momentos distintos: no primeiro

momento foi realizada a especificação conceitual parcial da interação, que consistiu da

construção das árvores EDITOR a partir da árvore TAOS da tarefa utilizando o conhecimento

ergonômico disponível numa base de regras ergonômicas (GUERRERO, 2001) e num

segundo momento essas árvores EDITOR foram complementadas com os atributos das

49

facetas $SUHVHQWDomR, $EVWUDomR e &RQWUROH��o que correspondeu a especificação completa da

interação.

Logo após uma primeira versão da especificação conceitual da interação, ou seja, após

a construção das árvores parciais EDITOR, começou-se a avaliação da especificação junto ao

usuário, num processo interativo e incremental, ou seja, a especificação da interação era

incrementada a cada interação com os usuários. Essa avaliação se estendeu até que tivéssemos

a versão completa da especificação da interação validada pelo usuário.

No próximo capítulo, descreveremos o processo de construção do protótipo da

interface da ferramenta iTAOS, ou seja, a implementação em JAVA. A construção do

protótipo corresponde a última fase da metodologia MEDITE, que foi utilizada no projeto e

implementação do módulo TAOS Graph de iTAOS.

50

&DStWXOR��3URWyWLSR�GD�LQWHUIDFH��

Neste capítulo, descrevemos o processo de construção do protótipo da interface da

ferramenta iTAOS. Esta etapa possui como entrada a especificação conceitual completa da

interação, ou seja, as árvores EDITOR e possui como saída um protótipo da interface da

ferramenta iTAOS. Trata-se do processo de implementação orientada a objetos da interface

utilizando a linguagem de programação JAVA.

Apresentamos inicialmente onde a construção do protótipo da interface se situa dentro

da metodologia MEDITE. Na construção desse protótipo foi utilizado o framework JHotDraw

(Kaiser, 2001) de apoio a construção de interfaces com o usuário em JAVA, o qual

descrevemos na seção 6.2. Logo após, ilustramos como o framework foi estendido para a

criação da interface da ferramenta iTAOS. Finalmente, apresentamos algumas telas da

interface, comparando-as com as árvores geradas na especificação da interação.

��3URWyWLSR�GD�LQWHUIDFH�QD�PHWRGRORJLD�0(',7(�O protótipo da interface corresponde quarta etapa da metodologia MEDITE como

mostra a figura abaixo:

��

)LJXUD��3URWyWLSR�GD�LQWHUIDFH�QD�PHWRGRORJLD�0(',7(�

51

��)UDPHZRUN�-+RW'UDZ�O framework JHotDraw define um esqueleto básico para a construção de um editor

com diferentes visões, figuras gráficas, ferramentas para manipulação dessas figuras, etc. O

framework pode ser customizado usando herança e combinando componentes. O JHotDraw é

estruturado em pacotes, como mostrado na figura 16 abaixo:

)LJXUD��(VWUXWXUD�HP�SDFRWHV�GR�IUDPHZRUN�-+RW'UDZ�Qualquer aplicação que use o JHotDraw possui uma janela dedicada ao desenho. Essa

janela editor possui uma ou mais janelas internas, cada uma associada a uma visão diferente

('UDZLQJ9LHZ). Cada visão possui uma área que aceita entradas oriundas do usuário

('UDZLQJ). Se algo é mudado no 'UDZLQJ, esta mudança é propagada para a visão

('UDZLQJ9LHZ) que é responsável por atualizar as figuras. O 'UDZLQJ consiste de figuras

()LJXUH), que podem conter outras figuras. Cada figura possui um +DQGOH, que define os

pontos de acesso e determinam como interagir com a figura. Na visão, pode-se selecionar

várias figuras e trabalhar com elas ao mesmo tempo. A janela editor possui uma ferramenta

(7RRO) ativada por vez, que opera no 'UDZLQJ associada à visão ('UDZLQJ9LHZ) sob um

determinado aspecto.

52

��3URFHVVR�GH�GHVHQYROYLPHQWR�WtSLFR�8VDQGR�R�-+RW'UDZ�A lista apresentada a seguir envolve as tarefas envolvidas com o desenvolvimento de

uma aplicação utilizando o JHotDraw:

L�� Criar suas próprias figuras gráficas e símbolos da sua aplicação: Algumas figuras

já estão definidas como $EVWUDFW)LJXUH, &RPSRVLWH)LJXUH e $WWULEXWH)LJXUH. Pode-

se redefinir os métodos nas subclasses para conseguir o comportamento desejado de

cada uma das figuras. Tipicamente, uma figura gráfica deve corresponder aos

objetos usados na aplicação.

LL�� Desenvolver suas próprias ferramentas de criação de figuras e manipulá-las de

acordo com os requisitos da aplicação: JHotDraw oferece algumas classes que

devem ser especializadas como &UHDWLRQ7RRO. &RQQHFWLRQ7RRO, 6HOHFWLRQ7RRO e

7H[W7RRO. Especializar tais classes e redefinir métodos como mouseUp e

nouseDown permite que seja definida a interação com o usuário.

LLL�� Criar a atual interface com o usuário (GUI) e integrá-la a aplicação: JHotDraw

também inclui o esqueleto de uma aplicação básica. Podem ser redefinidos os

métodos da sua aplicação, tais como createMenus, createFileMenu. Uma completa

interface com o usuário é criada quando se instancia a aplicação e chama open().

LY�� Compilar a aplicação usando a JVM (javac): É importante que sejam incorporados

todos os pacotes necessários pelo JHotDraw.

Algumas dessas tarefas envolvem aplicar designs patterns5 (Gamma at al., 2001),

como é o caso de Composite, State, Template method, Factory method, e Strategy.

Embora aprender a usar o JHotDraw ter requerido um esforço razoável, o uso deste

reduziu o tempo de desenvolvimento e melhorou a qualidade do software.

5 Conhecidos como padrões de projeto em português.

53

��&ODVVHV�TXH�FRPS}HP�R�VLVWHPD�Mostraremos algumas classes especializadas do framework JHotDraw para construção

da interface da ferramenta iTAOS. As classes em azul pertencem ao framework JHotDraw e

as classes em amarelo foram criadas:

MDI_DrawApplicat ion

ConnectionFigureArcLine

GraphicalComposit eFigureGraphicTask

LineFigureOperatorFigure

Cust omSelect ionToolDelegat ionSelect ionTool

Creat ionTool

iTAOSCreat ionTool

Connect ionTooliTAOSConnect ionTool

iTAOSCreat ionTaskToo l

St andardDrawing

StandardDrawingView

iTAOSDrawing

iTAOSApplicat ion

creat eInt ernalFrame()creat eSelect ionTool( )creat eTools( )creat eSimulat ionMenu()creat eDrawing()creat edrawingView()creat eEdit Menu()creat eFileMenu( )creat eHelpMenu()creat eInit ialDrawingView()creat eMenus()creat eVerifyMenu()creat eWindowMenu( )loadDrawing( )saveDrawing()main()

iTAOSDrawingView

)LJXUD��'LDJUDPD�GDV�SULQFLSDLV�FODVVHV�GR�PyGXOR�7$26�*UDSK�GD�IHUUDPHQWD�L7$26�

54

Ilustramos as dez principais classes das trinta do módulo interativo TAOS-Graph de

iTAOS. Em todas essas classes há chamadas aos métodos do módulo TAME, especificadas

através da API.

��$SUHVHQWDomR�GH�L7$26�Nesta seção apresentamos algumas telas da interface do iTAOS. A figura 18 se refere

à tela inicial da ferramenta. Segundo o modelo da interação, este tela deve ter duas visões,

sendo a primeira representada por uma barra de menu horizontal.

)LJXUD��7HOD�LQLFLDO�GD�IHUUDPHQWD�L7$26�Posteriormente, apresentamos duas telas, a primeira, na figura 19, mostra o menu

vertical com as opções: Criar um novo modelo, abrir um modelo existente, salvar o modelo,

imprimir o modelo e fechar o modelo, como definido no modelo da interação. A segunda tela,

na figura 20, apresenta um modelo aberto e pronto para ser manipulado diretamente pelo

usuário:

55

)LJXUD��7HOD�TXH�PRVWUD�R�PHQX�)LOH�DEHUWR�

)LJXUD��7HOD�TXH�PRVWUD�XP�PRGHOR�DEHUWR�

56

Na figura 21, apresentaremos o pop-up menu que foi aberto ao se clicar com o botão

direito sobre uma tarefa ou ação. Este pop-up menu foi definido na faceta Abstração do

2EMHWR�GH�LQWHUDomR denominado Árvore da especificação da interação.

)LJXUD��7HOD�TXH�PRVWUD�R�SRS�XS�PHQX�GD�DomR

)LJXUD��7HOD�TXH�PRVWUD�R�GHVFULWRU�GH�XPD�DomR�DEHUWR�

57

Na figura 22, apresentamos a tela com o descritor da ação /LJDU� LPSUHVVRUD aberto.

Esse descritor foi aberto ao clicar no item de menu (GLW� GHVFULSWRU do pop-up menu. Este

descritor, tipo formulário, também foi definido na especificação da interação.

Logo após ao descritor da ação /LJDU� LPSUHVVRUD, apresentamos o descritor de um

agente aberto. Este descritor foi aberto a partir do descritor de uma ação ou a partir do menu

Concepts (Entidades) da barra de menu.

)LJXUD��7HOD�TXH�PRVWUD�R�GHVFULWRU�GH�XP�DJHQWH�DEHUWR�Na figura 23, apresentamos uma tela onde o usuário pode visualizar todas as ações do

modelo aberto e abrir uma delas. Janelas equivalentes a essa existem para todos os conceitos

dinâmicos e estáticos de TAOS.

58

)LJXUD��-DQHOD�TXH�DSUHVHQWD�DV�Do}HV�GR�PRGHOR�DEHUWR�

��&RQVLGHUDo}HV�ILQDLV�Neste capítulo foi apresentado o processo de construção do protótipo da interface da

ferramenta iTAOS, que corresponde a quarta etapa da metodologia MEDITE foi utilizada

para concepção do módulo interativo (TAOS-Graph) da ferramenta iTAOS.

A implementação do protótipo foi realizada utilizando o paradigma orientado a

objetos, visto que os agentes PAC da especificação da interação são representados também

segundo esse paradigma. Utilizamos a linguagem de programação JAVA e o framework

JHotDraw na construção do protótipo da interface.

A validação do protótipo foi realizada segundo o método de inspeção de conformidade

do protótipo da interface da ferramenta iTAOS com as partes 14, 16 e 17 do padrão ISO 9241.

No próximo capítulo apresentamos a metodologia utilizada para realização da inspeção da

usabilidade e os resultados obtidos.

59

&DStWXOR�� ,QVSHomR� GD� XVDELOLGDGH� GR� SURWyWLSR� GD�LQWHUIDFH�GD�IHUUDPHQWD�L7$26�

Apresentamos neste capítulo o processo de inspeção de conformidade do protótipo da

interface da ferramenta iTAOS com as partes 14 (diálogos do tipo menu), 16 (diálogos do tipo

manipulação direta) e 17 (diálogos do tipo formulário) do padrão internacional ISO 9241.

Inicialmente é feita uma breve descrição do padrão ISO 9241, apresentando

posteriormente a metodologia utilizada na inspeção, os problemas identificados a partir da

inspeção de conformidade com as partes 14, 16 e 17 do padrão e finalmente é discutido um

parecer sobre o produto com base nas taxas de adoção das recomendações.

��2�SDGUmR�,62��A preocupação com a ergonomia de terminais cresceu no final da década de 70,

sobretudo no tocante à possível fadiga visual e deterioração da visão dos usuários devido ao

uso prolongado de terminais de vídeo, especialmente aqueles com baixa qualidade de

apresentação visual. (Queiroz, 2001)

O padrão ISO 9241� �,QWHUQDWLRQDO� 2UJDQL]DWLRQ� IRU� 6WDQGDUGL]DWLRQ� é uma norma

internacional que se destina aos profissionais encarregados de garantir um trabalho de

escritório seguro e efetivo com os computadores. As recomendações que constam na ISO

9241 foram definidas por evidência empírica e a partir da revisão da literatura existente na

época, sendo então generalizadas e formuladas em termos de requisitos para o uso de

projetistas e avaliadores de interfaces (Cybis, 2000).

60

Inicialmente, foi decidida a elaboração de um padrão que cobrisse uma gama de

tópicos em ergonomia que o comitê de ergonomia da ISO acreditava precisar de atenção.

Passaram quase sete anos antes da publicação das primeiras partes do padrão ISO 9241

(Stewart, 2000), um padrão de dezessete partes, cada uma tratando de diferentes aspectos do

trabalho em escritórios informatizados, que levou mais de quinze anos para ser concluído. Na

tabela abaixo listamos as dezessete partes que compõem o padrão ISO 9241.

7DEHOD��3DUWHV�LQWHJUDQWHV�GR�SDGUmR�,62��

,62��(UJRQRPLF�UHTXHULPHQWV�IRU�2IILFH�ZRUN�ZLWK�YLVXDO�GLVSOD\�WHUPLQDOV��97'V��

3DUWH� 'HQRPLQDomR�1:1997 General Introduction

2:1992 Guidance on task requirements

3:1992 Visual display requirements

4:1998 Keyboard requirements

5:1998 Workstation layout and postural requirements

6:1999 Environmental requirements

7:1998 Display requirements with reflections

8:1997 Requirements for displayed colours

9:2000 Requirements for non-keyboard input devices

10:1996 Dialogue principles

11:1998 Guidance on usability specification and measures

12:1998 Presentation of information

13:1998 User guidance

14:1997 Menu dialogues

15:1997 Command dialogues

16:1999 Direct manipulation dialogues

17:1998 Form filling dialogues

As nove primeiras partes do padrão ISO 9241 tratam de aspectos relacionados com o

hardware envolvido no processo interativo, enquanto que as outras oito partes são relativas ao

software. As partes 14 a 17 referem-se a estilos de diálogo; por menu, por linguagem de

comandos, por manipulação direta e por preenchimento de campos. As normas fornecem uma

61

estrutura de recomendações referentes à pertinência destes estilos de diálogo, sobre como

realizá-los em seus diferentes aspectos e como avaliá-los.

Descrevemos abaixo as partes 14 (diálogos do tipo menu), 16 (diálogos do tipo

manipulação direta) e 17 (diálogos do tipo formulários) do padrão ISO 9241, que foram

utilizadas na realização da inspeção de conformidade da interface da ferramenta iTAOS:

L�� Diálogos por menu (ISO, 1997): Apresentação de recomendações para o projeto

ergonômico de diálogos via menus, englobando estrutura de menus, navegação,

seleção e execução de opções e apresentação de menus por várias técnicas, e.g.

janelas, painéis, botões, campos.

LL�� Diálogos por manipulação direta (ISO, 1999): Apresentação de recomendações

para o projeto ergonômico de diálogos via manipulação direta, incluindo a

manipulação de objetos e o projeto de metáforas, objetos e atributos.

LLL�� Diálogos por preenchimento de formulários (ISO, 1998): Apresentação de

recomendações para o projeto ergonômico de diálogos via preenchimento de

formulários, cobrindo considerações estruturais, de entrada, saída e navegação.

��0HWRGRORJLD�XWLOL]DGD�QD�LQVSHomR�GD�XVDELOLGDGH�A utilização do padrão internacional ISO 9241 é destinada tanto para projetistas que

desejam analisar a aplicabilidade de recomendações ergonômicas num produto quanto para

avaliadores que desejam verificar a conformidade de um produto específico ao padrão ISO

mediante a adoção ou não das recomendações existentes.

Ao final de cada parte da ISO 9241 há checklists (denominado Anexo A), que

apresentam procedimentos para análise da aplicabilidade e/ou da adoção das recomendações.

A conformidade ao padrão ISO 9241 é definida a partir dos resultados de duas análises, a de

aplicabilidade do(s) quesito(s) do checklist e a da adoção do quesito pelo sistema avaliado. O

resultado final da avaliação deve conter as tarefas (quesitos) avaliadas, as recomendações

aplicáveis e as recomendações adotadas.

Nosso objetivo ao usar as recomendações da ISO foi de avaliar a interface da

ferramenta iTAOS já existente, limitando-se as partes 14, 16 e 17 do padrão internacional ISO

9241. O procedimento utilizado foi o sugerido na norma ISO 9241:

62

�

��

)LJXUD��)OX[RJUDPD�HPSUHJDGR�QD�LQVSHomR�GD�XVDELOLGDGH��

×�ØmÙ�Ú�Û�ÚÜÚÙ�Û�Ý�Þ�ß�à�ÚÛ�á�â�ã�à�á�ä�å�Ú�æ�ç�ãè�é'Ù�á�â�ß�ê�ß�ë�ì�áÜãí�î�ï�ð�ñ�ðòÚ�å�ã�ó�Ú�å�ãÙ�Ú�Û�Úå�á�ó�á�Û�à�ß�ä�Ú�Ûôë�ì�áä�ç�ãöõÚ�Ù�÷�ß�â�Ø�ø�á�÷

è�é'Ù�á�â�ß�ê�ß�ë�ì�áòé�áùÚÛ�á�â�ã�à�á�ä�å�Ú�æ�ç�ãÜê�ã�ßé�Ú�ó�ß�é�ê�á�ß�ó�Ú

ñ�á�â�ß�å�Úòé�ã%ú�Û�áùÚÜÚ�å�ã�æ�ç�ãöáá�éVÙ�á�â�ß�ê�ß�ë�ì�áùãûí�î�ï�ð�ñ�ðá�à�Ù�Û�á�ü�Ú�å�ã

è�éVÙ�á�â�ß�ê�ß�ë�ì�áùãûí�î�ï�ð�ñ�ðÚ�å�ã�ó�Ú�å�ãÙ�Ú�Û�Úöå�á�ó�á�Û�à�ß�ä�Ú�ÛÚ�Ù�÷�ß�â�Ú�ú�ß�÷�ß�å�Ú�å�á

ýÛ�á�â�ã�à�á�ä�å�Ú�æ�ç�ãõùÚ%Ù�÷�ß�â�Ø�ø�á�÷ þ

ÿ�Ú�é�é�á Ù�Ú�Û�ÚÜãÙ�Û�Ý�Þ�ß%à�ãÜß�ó�á�à��ß�é�ó�áùÚ�éÛ�Ú��á�éý é�á�æ�ç�ãöå�Ú�� ôã�ì�� å�ã�� õ

ýÛ�á�â�ã�à�á�ä�å�Ú�æ�ç�ãÚ�Ù�Û�á�é�á�ä�ó�Úmì�à�Úâ�ã�ä�å�ß�æ�ç�ã �� þ

ý â�ã�ä�å�ß�æ�ç�ã��

õùÚ%Ù�÷�ß�â�Ø�ø�á�÷�þ

ñ�Ú�å�ã�éÜé ã�ú�Û�áÜãì�é%ì�Ø�Û�ß�ã�� Ú�éó�Ú�Û�á�ê�Ú�é � Ú�éó�á�â�ä�ã�÷�ã�ü�ß�Ú�é �Ú�à�ú�ß�á�ä�ó�á�é

63

�� 3UREOHPDV� LGHQWLILFDGRV� QR� SURGXWR� D� SDUWLU� GD�LQVSHomR�GH�XVDELOLGDGH�

O $QH[R�$ de cada uma das partes do padrão ISO 9241 apresenta ao final um checklist

sintetizando as recomendações contidas em cada parte do padrão, servindo de auxílio tanto

para projetistas, com respeito à aplicabilidade das recomendações no contexto do projeto,

quanto para avaliadores, num processo de verificação das recomendações num produto final.

Nas listas de inspeção há campos em branco, que devem ser preenchidos conforme a

evolução do processo de inspeção e há também campos não preenchíveis pelo

projetista/avaliador, destacados dos demais pelo preenchimento em cor cinza, o que indica

que não deve ser assinalado, por não se aplicarem ao processo de inspeção ou por não serem

pertinentes ao contexto individual da declaração à qual estão associados.

Os checklists preenchidos referentes às partes 14, 16 e 17 do padrão ISO 9241

encontram-se nos apêndices 3, 4 e 5 respectivamente. Abaixo, apresentaremos os problemas

identificados a partir da inspeção da conformidade da ferramenta iTAOS com o padrão ISO

9241.

3UREOHPDV� LGHQWLILFDGRV�D�SDUWLU�GD� LQVSHomR�GD� FRQIRUPLGDGH�GR�SURGXWR� FRP�D� ,62��'LiORJRV�SRU�PHQX�

Não foram encontrados problemas de conformidade da ferramenta iTAOS com as

recomendações da parte 14 do padrão ISO 9241. Todas as recomendações que são aplicáveis

a ferramenta iTAOS foram adotadas.

3UREOHPDV� LGHQWLILFDGRV�D�SDUWLU�GD� LQVSHomR�GD� FRQIRUPLGDGH�GR�SURGXWR� FRP�D� ,62��'LiORJRV�SRU�PDQLSXODomR�GLUHWD�� Na declaração 6.1.4 (Manipulação direta de saída) recomenda-se que se apropriado

para a tarefa, o resultado da manipulação direta deveria ser apresentado de tal maneira que o

usuário pudesse modificá-lo. Por exemplo, o usuário cria um documento de texto, este

documento possui um nome default “ untitled document” que já aparece selecionado para que

o usuário o modifique. No iTAOS, ao se inserir uma ação na tela, ela aparece com o nome

default “ name of the task” , porém ela não aparece selecionada para que o usuário a modifique.

64

A segunda falha explicitada através da inspeção de conformidade à ISO 9241-16 é

relativa à recomendação 8.2.1 (Rearranjo do conteúdo visualizado de uma janela de acordo

com a seleção do usuário), recomenda-se que o alcance dos objetos selecionados por

manipulação direta possa ir além do tamanho da janela, fazendo com que a janela deslize até

encontrar o objeto desejado. No iTAOS essa recomendação não foi atendida.

3UREOHPDV� LGHQWLILFDGRV�D�SDUWLU�GD� LQVSHomR�GD� FRQIRUPLGDGH�GR�SURGXWR� FRP�D� ,62��'LiORJRV�SRU�SUHHQFKLPHQWR�GH�IRUPXOiULRV� Na declaração 6.1.4 (Manipulação direta de saída) recomenda-se que se os campos são

alfanuméricos e alinhados verticalmente em colunas e se o tamanho do rótulo difere de forma

significativa, os rótulos devem ser justificados a direita e os campos devem ser justificados a

esquerda. No iTAOS, os rótulos e os campos estão alinhados a esquerda, não atendendo à

recomendação.

A segunda falha foi constatada na declaração 5.3.3 (Campos modificáveis versus

campos não modificáveis), que recomenda que os usuários sejam capazes de identificar

facilmente os campos que podem ser modificados dos que não podem (campos só de leitura).

No iTAOS, mesmo os campos que são somente de seleção, estão passíveis de edição, não

condizendo com o que recomenda a declaração 5.3.3.

A declaração 6.4.2 (Identificando e localizando erros) recomenda que se na validação

do campo forem detectados erros e se é apropriado para a tarefa, estes campos devem ser

indicados e o cursor deve ser colocado no lugar onde ocorreu o primeiro erro, para que seja

fácil para o usuário modificá-lo. No iTAOS, o cursor não volta para o campo onde ocorreu o

erro.

A declaração 6.5.2 (Validação de múltiplos campos) recomenda que as dependências

entre campos no formulário, ou entre campos e outros incidentes do mesmo formulário, sejam

validadas, por exemplo: se um campo A não foi preenchido, então o campo B não pode ser

editado. No iTAOS, este tipo de verificação não está sendo checado.

A última falha detectada concerne à recomendação 8.6.4 (Retornando ao formulário

inicial), aplicável a um conjunto de formulários hierárquicos. Deve estar disponível para o

65

usuário um atalho para que ele retorne ao formulário inicial. Este tipo de atalho não está

disponível nos formulários da ferramenta iTAOS.

��7D[DV�GH�DGRomR�FRP�EDVH�QR�SURFHVVR�GH�LQVSHomR�A ,62� recomenda, após a realização da inspeção de conformidade de um

produto a um de seus padrões internacionais ou a algumas de suas partes, que os

resultados da inspeção sejam sumariados a partir da computação de um indicador

denominado WD[D� � GH� � DGRomR ! , definido como a razão percentual do número de

recomendações julgadas satisfatoriamente adotadas pelo produto (i.e., o número de

células assinaladas na coluna 3��da lista de inspeção) pelo número de recomendações

julgadas aplicáveis ao contexto do projeto (i.e., o número de células assinaladas na

coluna 6��da lista de inspeção).

7DEHOD��±�7D[DV�GH�DGRomR�GR�L7$26�jV�SDUWHV��H��GR�,62��

33$$5577((��''22��,,6622�� 33�� 66�� 77$$��1144 62 62 110000,,00

1166 39 41 9955,,11

1177 44 49 8899..77

Além das taxas de adoção do L7$26� � às pDUWHV� � ��,� � �� e� � �� do padrão

internacional ,62��, apresentadas na coluna 7$ (taxa de adoção) da Tabela 2, são

também reportados os números de células assinaladas nas colunas 3��e 6��das listas de

inspeção, apresentados, respectivamente, nas colunas �3 e��6,��conforme recomendado

na sub-seção $��(6XPPDU\��GDWD) de cada parte considerada.

De acordo com a Tabela 2, verifica-se que o modo de interação oferecido pelo

L7$26� �mais conforme (7$� � � ��) às recomendações da ,62 é o que envolve

diálogos via PHQXV, seguido do modo de interação via PDQLSXODomR� �GLUHWD�(7$�� ). Em contrapartida, o modo de interação fundamentado em diálogos via

SUHQFKLPHQWR�GH�IRUPXOiULRV é o que adota o menor número de recomendações da ,62

6 Adoção das recomendações aplicáveis ao contexto do projeto cuja implementação originou o produto inspecionado.

66

aplicáveis aos contextos de uso do universo amostral considerado, apresentando,

portanto, a taxa de adoção mais baixa (7$�� ).

��&RQVLGHUDo}HV�ILQDLV�Apresentamos neste capítulo o processo de inspeção de conformidade do protótipo da

interface da ferramenta iTAOS com as partes 14 (diálogos do tipo menu), 16 (diálogos do tipo

manipulação direta) e 17 (diálogos do tipo formulários) do padrão internacional ISO 9241.

Segundo as recomendações da ISO, algumas foram detectadas falhas nos diálogos com o

usuário.

Como apresentado anteriormente, a metodologia MEDITE utiliza o conhecimento

ergonômico na concepção da interação. Esse conhecimento é estruturado na forma de regras

ergonômicas e aplicado em dois momentos: no primeiro, as regras são utilizadas na

estruturação das telas ou janelas do sistema (esboço inicial), enquanto que no segundo

momento, as regras auxiliam na definição dos atributos da apresentação, abstração e controle

do sistema.

Por se tratar de uma primeira versão da base de regras ergonômicas, existem poucas

regras para definição dos atributos dos diálogos via manipulação direta e preenchimento de

formulários. Por esse motivo, algumas falhas foram observadas na inspeção de conformidade

com as partes 16 e 17 da norma ISO 9241.

As falhas levantadas foram todas corrigidas após a realização da inspeção. Porém, não

foi realizada uma nova inspeção de conformidade com a norma ISO 9241.

67

&DStWXOR��&RQFOXVmR�

Apresentamos nesse trabalho o processo de construção e implementação do módulo

TAOS Graph da ferramenta iTAOS, uma ferramenta de suporte à análise e modelagem da

tarefa. O módulo TAOS Graph refere-se ao componente interativo da ferramenta, ou seja, um

editor de entidades estáticas e dinâmicas estruturadas de acordo com os princípios

preconizados pelo módulo TAME (componente funcional).

O módulo TAOS-Graph foi projetado utilizando a metodologia MEDITE, uma

metodologia baseada na tarefa e orientada a modelos que utiliza o conhecimento ergonômico

na passagem do modelo da tarefa para a especificação conceitual da interação de forma a

produzir interfaces que reflitam os objetivos, as características e as necessidades do usuário.

Inicialmente a tarefa foi descrita utilizando o modelo TAOS, logo após foi feita a

passagem da descrição da tarefa para a especificação conceitual da interação com o auxilio da

base de regras ergonômicas disponível em MEDITE e finalmente foi construído o protótipo

da interface utilizando a linguagem JAVA.

Por se tratar de um processo interativo e incremental, a avaliação de cada etapa da

metodologia adotada foi sendo realizada em paralelo com a descrição dos modelos. Após a

construção do protótipo da interface, foi realizada uma inspeção de conformidade do protótipo

da interface gerada com as partes 14, 16 e 17 do padrão internacional ISO 9241, que

correspondem respectivamente a diálogos via menus, diálogos via manipulação direta e

diálogos via preenchimento de formulários.

Num primeiro momento, realizaríamos um teste de usabilidade da interface da

ferramenta iTAOS, porém tornou-se inviável devido ao tempo que dispúnhamos para

realização de todo o trabalho, ou seja, o projeto, implementação e avaliação do módulo

68

TAOS-Graph do iTAOS. Por esse motivo, optamos por uma avaliação baseada em padrões

(checklists), que é um método de avaliação mais rápido e que possui as seguintes vantagens

segundo Cybis (2000):

L�� Facilidade na identificação de problemas de usabilidade, devido à

especificidade das questões do checklist.

LL�� Aumento da eficácia da avaliação, devido à redução da subjetividade

normalmente associada a processos de avaliação.

LLL�� Devido o conhecimento ergonômico ser inserido dentro do próprio checklist, a

avaliação pode ser realizada por projetistas, não exigindo especialistas em

avaliação de interfaces homem-máquina.

LY�� Redução dos custos de avaliação, pois é um método de avaliação rápido.

Alem da inspeção de conformidade da interface de iTAOS com as partes 14, 16 e 17

da norma ISO 9241, foi realizada uma avaliação heurística do produto iTAOS. Essa avaliação

foi executada por um especialista em design com o objetivo de diagnosticar problemas ou

barreiras que os usuários encontrariam durante a interação com a interface. Essa avaliação

voltou-se para algumas características visuais da interface, como fontes, diagramação, cores e

imagens. No decorrer da avaliação, um conjunto de modificações foi detectado, entre as

quais: a fonte que estava sendo utilizada nos menus e em outros estilos de diálogo, a

diagramação que estava sendo utilizada nas telas de formulários, as imagens utilizadas nos

botões (ícones) e as cores das tarefas e ações do modelo, dando um melhor contraste com o

background da tela. É importante ressaltar que esta avaliação heurística foi realizada antes da

inspeção por padrões

��'LVFXVVmR�GRV�UHVXOWDGRV�Discutiremos as hipóteses consideradas para o desenvolvimento deste trabalho de

acordo com os resultados obtidos:

L�� e� SRVVtYHO� SURMHWDU� H� LPSOHPHQWDU� R� PyGXOR� 7$26�*UDSK� VHSDUDGR� GR�SURFHVVR�GH�GHVHQYROYLPHQWR�GR�PyGXOR�7$0(�

69

Os módulos TAME e TAOS-Graph foram projetados seguindo processos de

desenvolvimento distintos. Isso foi possível por termos assumido D�SULRUL o princípio

da independência do diálogo e pela definição de uma interface de comunicação (API:

Application Programming Interface) robusta que permitisse uma integração adequada

dos módulos D�SRVWHULRUL. Essa API foi definida e disponibilizada no módulo TAME e

seu acesso definido através dos atributos das facetas $EVWUDomR da especificação

EDITOR da interação, conforme Capítulo 5.

LL�� 2�SURFHVVR�GH�GHVHQYROYLPHQWR�D�VHU�XWLOL]DGR�QR�SURMHWR�GR�PyGXOR�7$26�*UDSK� GHYH� SDUWLU� GD� DQiOLVH� GD� WDUHID� ³8WLOL]DU� D� IHUUDPHQWD� L7$26� SDUD�DQDOLVDU�H�PRGHODU�WDUHIDV´�GH�IRUPD�D�FDSWXUDU�HIHWLYDPHQWH�R�FRQKHFLPHQWR�VREUH�R�XVXiULR�H�VREUH�VHX�SURFHVVR�GH�UHDOL]DomR�GD�WDUHID��

O artefato produzido durante a fase de análise e modelagem da tarefa descreve

efetivamente o perfil do usuário, obtido através do questionário DePerUse e

representado através dos atributos da classe Agente (Agent) e o processo de realização

da tarefa obtido através de entrevistas semidirigidas e da técnica trace analysis e

representado através da sua decomposição em sub-tarefas e dos descritores conforme

descrito no capítulo 4.

LLL�� $�PHWRGRORJLD�0(',7(� SRVVLELOLWD� XPD� FRQVWUXomR� JXLDGD� SRU�PRGHORV�GR�PyGXOR�7$26�*UDSK�GH�IRUPD�D�REHGHFHU�DRV�SULQFtSLRV�GD�HUJRQRPLD�H�DRV�REMHWLYRV�GR�XVXiULR�GD�IHUUDPHQWD�L7$26��

Todas as fases de construção do módulo TAOS-Graph tiveram um modelo como

paradigma. Na fase inicial, análise da tarefa, utilizou-se o modelo TAOS de

representação da tarefa no lugar de MAD* como preconizado pela metodologia. Isto

foi feito sem problemas visto que TAOS já havia sido validado em relação a MAD e

estendido para se equiparar a MAD* em termos de atributos orientados a especificação

de interfaces e simulação. A passagem da descrição da tarefa para a especificação da

interação foi realizada tendo como guia o modelo EDITOR, seguindo regras

ergonômicas e preservando os objetivos do usuário declarados na descrição da tarefa.

Nessa fase, a maior dificuldade encontrada foi com respeito à limitação da base de

70

regras de MEDITE que carece de mais regras relativas a diálogos via manipulação

direta e preenchimento de formulários.

Os módulos TAME e TAOS-Graph foram desenvolvidos utilizando metodologias

distintas e atenderam ao princípio da independência do diálogo. Ambas as metodologias

(Processo Unificado e MEDITE) partiram de um mesmo ponto (análise da tarefa) e seguiram

independentemente até chegar a um ponto comum, a integração dos dois módulos formando a

ferramenta iTAOS.

��&RQWULEXLo}HV�A principal contribuição desse trabalho é o módulo TAOS-Graph (módulo interativo),

que juntamente com o módulo TAME formam a ferramenta para análise da tarefa iTAOS. A

ferramenta iTAOS possui características importantes, entre elas:

L�� Adota o conceito de decomposição hierárquica de tarefas, permitindo que os

projetistas considerem vários níveis de abstração e mantenham um relacionamento

entre eles.

LL�� Consideram tarefas concorrentes, através dos operadores SIM e PAR.

LLL�� Habilidade de modelar tarefas cooperativas envolvendo múltiplos usuários, através

da lista de agentes (conceito Agent) das ações (Action).

LY�� Habilidade de modelar tarefas envolvendo as ferramentas (Tools) e/ou objetos

necessários para sua realização.

Y�� A descrição TAOS da tarefa gerada na ferramenta iTAOS (arquivo XML) pode ser

utilizada para geração automática ou semi-automática da especificação da

interação.

YL�� Verificação da consistência da descrição gerada, analisando os objetos da

descrição e a relação das pré e pós condições com os operadores envolvidos na

descrição.

71

YLL�� Verificação da completude da descrição, ou seja, é verificada a falta do

preenchimento de algum atributo (Task, Action, Situation, Agent e Tool).

(Melhorar)

YLLL�� Ambiente multiplataforma, permitindo que projetistas que utilizem diferentes

sistemas operacionais possam usufruir da ferramenta iTAOS.

L[�� Suporte a simulação da descrição da tarefa, através dos atributos prioridade, tempo

de execução e interruptabilidade.

Uma outra contribuição importante diz respeito à adição de uma nova regra a base de

regras ergonômicas da metodologia MEDITE. Duas regras extraídas da experiência do autor

com outras ferramentas foram utilizadas para a construção da especificação conceitual da

interação. A primeira regra diz respeito ao estilo de diálogo Formulários e a segunda a

manipulação direta de um objeto complexo que pode ser dinamicamente criado e/ou alterado.

A primeira se encaixa nas regras para a construção da árvore EDITOR e a segunda na regras

para definição dos atributos das árvores EDITOR.

5HJUD�� SE as sub-tarefas forem ligadas pelo construtor OR (TAOS) e as sub-

tarefas possuírem no atributo Nome a palavra Editar, Escolher ou equivalente,

ENTÃO definir para esse conjunto de tarefas uma Visão (EDITOR) cuja Apresentação

deve ser do tipo Formulário e cada sub-tarefa deve ser um Objeto_de_Interação

(EDITOR) do tipo item-de-formulário dessa Visão.

5HJUD�� Se o objeto de interação (EDITOR) for relacionado com um objeto da tarefa

(TAOS) que pode ser dinamicamente criado ou alterado durante a interação, ENTÃO

os atributos da sua faceta Apresentação devem descrever as ações de manipulação

desse objeto e os atributos de sua faceta Abstração devem descrever os efeitos visuais

e funcionais envolvendo o objeto.

Além das contribuições citadas anteriormente, a construção da ferramenta

iTAOS procura contribuir com a promoção e consolidação da idéia de que metodologias de

concepção e desenvolvimento de interfaces que levam em conta, desde o inicio do processo, a

análise da tarefa e o conhecimento ergonômico produzem interfaces do usuário com um alto

grau de usabilidade.

72

��3URSRVWDV�GH�FRQWLQXLGDGH�Daremos algumas sugestões de trabalhos futuros:

L�� Validação da interface da ferramenta iTAOS pelos usuários. Essa validação vai

ocorrer com o uso da ferramenta no âmbito da Universidade Federal de Campina

Grande e até fora dela por projetistas de interfaces na descrição de suas tarefas, ou

através de um teste de usabilidade.

LL�� Acréscimo de regras à base de regras ergonômicas da metodologia MEDITE. O

conhecimento ergonômico utilizado por MEDITE é limitado, portanto seria de

grande contribuição que novas regras referentes a outros tipos de diálogos fossem

agregados à metodologia.

LLL�� Desenvolvimento de ferramentas específicas para as outras etapas de uma

metodologia para o projeto de interfaces, de forma que tenhamos uma metodologia

totalmente suportada por ferramentas computacionais e que estas ferramentas se

comuniquem.

LY�� Possibilitar que usuários da ferramenta iTAOS possam simular seus modelos.

iTAOS foi projetada e implementada de forma que essa nova funcionalidade

pudesse ser agregada a ferramenta posteriormente.

73

5HIHUrQFLDV�%LEOLRJUiILFDV�BODART, F. et al. $�PRGHO�EDVHG�DSSURDFK�WR�SUHVHQWDWLRQ��D�FRQWLQXXP�IURP�WDVN�DQDO\VLV�

WR� SURWRW\SH. Proceedings of the Eurographics Workshop on Design, Specification and Verification of Interactive Systems, Bocca di Magra: Eurographics Series, 1994.

BODART, F. et al. 7RZDUGV� D� V\VWHPDWLF� EXLOGLQJ� RI� VRIWZDUH� DUFKLWHFWXUH�� WKH�75,'(17�PHWKRGRORJLFDO� JXLGH. In Palanque, P. & Bastide, R. (Eds.), Proceedings of the Eurographics Workshop on Design, Specification and Verification of Interactive Systems DSV-IS’95, Toulouse, France, 1995.

COUTAZ, J. 7KH�&RQVWUXFWLRQ�RI�8VHU� ,QWHUIDFHV�DQG� WKH�2EMHFW�3DUDGLJP, The European Conference on Object Oriented Programming, ECOOP’87, Paris, França, 1987.

COUTAZ, J. Interfaces Homme-Ordinateur – Conception et Réalisation, Bordas, Paris, 1990.

CYBIS, W. A., (UJRQRPLD�H�8VDELOLGDGH�GH�6RIWZDUH�±�$ERUGDJHP�(UJRQ{PLFD�SDUD�,+&. Florianópolis, 1996.

CYBIS, W. A., $ERUGDJHP� HUJRQ{PLFD� SDUD� ,+&, apostila de curso, Laboratório de Utilizabilidade INE/UFSC, Florianópolis, Brasil, 2000.

DODANI at. al., 6HSDUDWLRQ�RI�3RZHUV, Byte, mars 1989.

DRAPER, S. W. e NORMAN, D. A., 6RIWZDUH�HQJLQHHULQJ�IRU�XVHU�LQWHUIDFHV, IEEE Trans. Softw. Eng. SE-11, 1985, 252-258.

EHRICH, R. W. e HARTSON, H. R., DMS - $Q�HQYLURQPHQW� IRU� GLDORJXH�PDQDJHPHQW, Proc. of COMPCON81 (Washington, D.C.), IEEE, New York, septembre 1981, p. 121.

FURTADO, M. E. S., 0LVH�HQ�RHXYUH�GXQH�PpWKRGH�GH�FRQFHSWLRQ�GLQWHUIDFHV�DGDSWDWLYHV�SRXU� GHV� V\VWqPHV� GH� VXSHUYLVLRQ� j� SDUWLU� GH� VSqFLILFDWLRQV� FRQFHSWXDOOHV, PhD thesis, Doctorat de Productique et Informatique à l'Université Aix Marseille III, France, 1997.

GAMMA, E. at al., 'HVLJQ� 3DWWHUQV� ±� (OHPHQWV� RI� 5HXVDEOH� 2EMHFW�2ULHQWHG� 6RIWZDUH, Addison-Wesley, 2001.

74

GAMBOA, F.; SCAPIN, D. L. (GLWLQJ� 0$'� 7DVN� 'HVFULSWLRQV� IRU� 6SHFLI\LQJ� 8VHU�,QWHUIDFHV� DW� %RWK� 6HPDQWLF� DQG� 3UHVHQWDWLRQ� /HYHOV, in Proceedings DVS-IS ’97, 4th International Eurographics Workshop on Design, Specification, and Verification of Interactive Systems, Granada Spain, 1997, Springer Verlag.

GAMBOA, F. R. 6SpFLILFDWLRQ� HW� ,PSOpPHQWDWLRQ� G$/$&,(�� $WHOLHU� /RJLFLHO� G$LGH� j� OD�&RQFHSWLRQ�G,QWHUIDFHV�(UJRQRPLTXHV, Thèse de Doctorat, Paris XI, Octobre, 1998.

GRAESSER, A. C. How to catch a fish: The memory and representation of common procedures. 'LVFRXUVH�3URFHVVHV, 1978, 1, 79-89.

GUERRERO, C.V.S. MEDITE, 8PD�PHWRGRORJLD�RULHQWDGD�D�PRGHORV�SDUD�FRQFHSomR�GH�LQWHUIDFHV� HUJRQ{PLFDV� Dissertação de Mestrado - COPIN, Universidade Federal da Paraíba, Campina Grande, PB, 2001.

GUERRERO, C. V. S.; LULA, B. Jr. 0(',7(��XPD�$ERUGDJHP�%DVHDGD�HP�0RGHORV�SDUD�D�&RQFHSomR� GH� ,QWHUIDFHV� (UJRQ{PLFDV, IX Encuentro Chileno de Computación 2001- Jornadas Chilenas de Computación 2001, Atas (CD-ROM) Seção: Interfaz humano-computador y computación gráfica / Trabalho nº 4 (10 páginas), Punta Arenas - CHILE, novembro de 2001.

GUERRERO, C. V. S.; LULA, B. Jr. 8P�7XWRULDO�QD�:HE��REWHQomR�GR�PRGHOR�GD�LQWHUDomR�D� SDUWLU� GR�PRGHOR�GD� WDUHID� FRP�R� DX[tOLR�GH� UHJUDV� HUJRQ{PLFDV� Relatório Técnico RT- DSC-002/2001 (55 páginas), UFPB/DSC/CCT Campina Grande, PB, outubro de 2001.

GUERRERO, C. V. S.; LULA, B. Jr. 0RGHO�*XLGHG�DQG�7DVN�%DVHG�$SSURDFK�WR�8,�'HVLJQ�&HQWHUHG� LQ� D� 8QLILHG� ,QWHUDFWLRQ� DQG� $UFKLWHFWXUDO� 0RGHO, CADUI'2002 - 4th International Conference on Computer-Aided Design of User Interfaces, p. 107 - 119, Valenciennes, France, May 2002.

HAAN, G. ETAG - $�)RUPDO�0RGHO�RI�&RPSHWHQFH�.QRZOHGJH�IRU�8VHU�,QWHUIDFH�'HVLJQ, Ph.D. Thesis, Vrije Universiteit, Amsterdam, October, 2000.

HAMMOUCHE, H. 'H� OD�PRGpOLVDWLRQ� GHV� WkFKHV� XWLOLVDWHXUV� DX� SURWRW\SH� GH� O¶LQWHUIDFH�KRPPH�PDFKLQH, Thèse de Docteur, Université Paris VI, Décembre, 1995.

HEEMANN, V., &XUVR�GH�(UJRQRPLD�HP�6LVWHPDV�GH�,QIRUPDomR, Universidade Federal da Paraíba, Campina Grande, Julho de 1997.

75

HAAN G.; VAN der VEER G. C. e VAN VLIET J.C., Formal Modelling Techniques in Human-Computer Interaction. Acta Psychologica, 78, nos. 1-3, 26-76, North-Holland, Amsterdam, 1992.

HUDSON, S., JOHN, B., KNUDSEN, K., BYRNE, M., A Tool for Creating Performance Models from Users Interface Demonstrations, Proceedings UIST´99, pp. 93-102.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, Projeto de norma internacional, Menu dialogues - ISO 9241 parte 14, final draft, Genebra, Suíça,1997.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, Projeto de norma internacional, Direct manipulation dialogues - ISO 9241 parte 16, final draft, Genebra, Suíça,1999.

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, Projeto de norma internacional, Form filling dialogues - ISO 9241 parte 17, final draft, Genebra, Suíça,1998.

JOHNSON, P. at al. 7DVN�5HODWHG�.QRZOHGJH�6WUXWXUHV: $QDO\VLV��0RGHOOLQJ�DQG�$SOLFDWLRQ, Queen Mary College, University of London 1988.

JOHNSON, P. at al., J. ADEPT – $GYDQFHG�'HVLJQ�(QYLURQPHQW�IRU�3URWRW\SLQJ�ZLWK�7DVN�0RGHOV, INTERCHI’93 Conference Proceedings, Amsterdam: ACM, 1993.

KAFURE, I. M. 9DOLGDomR�GR�)RUPDOLVPR�7$26�SDUD�D�&RQFHSomR�GH�,QWHUIDFHV�+RPHP�&RPSXWDGRU, Dissertação de Mestrado - COPIN, Universidade Federal da Paraíba, Campina Grande, PB, 2000.

KAISER, W. %HFRPH�D�SURJUDPPLQJ�3LFDVVR�ZLWK�-+RW'UDZ, 2001.

KESSEL, T.; MEDEIROS, H. e ROUSSELOT, F., 6RPH�8VHIXO�(QKDQFHPHQWV�RI�0RGHOLQJ�/DQJXDJHV� WR� EHFRPH� 0RGHOLQJ� /DQJXDJHV, International Workshop “ Modeling Languages for Knowledge-Based Systems” , 01/95, Amsterdam, Pay Bas, 1995.

LIMBOURG, Q.; PRIBEANU, C.; VANDERDONCKT, J., 7RZDUGV�8QLIRUPHG�7DVN�0RGHOV�LQ�D�0RGHO�%DVHG�$SSURDFK, GIST Technical Report, Glasgow, Scotland, June 2001.

LULA, B. Jr. (ODERUDWLRQ� G¶XQ� (QYLURQQHPHQW� GH� *pQpUDWLRQ� ,QWHUDFWLYH� G¶,QWHUIDFHV� j�0DQLSXODWLRQ�'LUHFWHU�SRXU�OH�/DQJXDJH�2%-/2*, Thèse de Docteur, Universidade de

76

Droit d’Economie et des Sciences d’Aix-Marseille III, Faculté des Sciences et Techniques de Saint – Jérôme, França, 1992.

MARKOPOULOS P. e GIKAS S., )RUPDO�6SHFLILFDWLRQ�RI�D��7DVN�0RGHO�DQG�,PSOLFDWLRQV�IRU� ,QWHUIDFH� 'HVLJQ, Cognitive Systems vol 4, pp. 4-3 Queen Mary and Westfield College, University of London, February 1997.

MARKOPOULOS, P.; PYCOCK, J.; WILSON, S., $'(37� �� $� WDVN� EDVHG� GHVLJQ�HQYLURQPHQW, Queen Mary and Westfield College, UK, 1992.

MEDEIROS, F. P. A., CORDEIRO, P. B. e LULA, B. J�, 3URMHWR� L7$26�±�0RGHODJHP�GD�WDUHID� H� )DVH� GH� SODQHMDPHQWR� Relatório Técnico RT- DSC-001/2002, (112 p.), UFPB/DSC/CCT Campina Grande, PB, Brazil, abril, 2002, disponível em www.dsc.ufcg.edu.br/~itaos.

MEDEIROS, F. P. A.; CORDEIRO, P. B. e LULA, B. J�, 3URMHWR� L7$26� ±� )DVH� GH�,PSOHPHQWDomR��3ULPHLUD�,WHUDomR��H�(VSHFLILFDomR�&RQFHLWXDO�GD�,QWHUDomR� Relatório Técnico RT- DSC-003/2002, (47 p.), UFPB/DSC/CCT Campina Grande, PB, Brazil, julho, 2002, disponível em www.dsc.ufcg.edu.br/~itaos.

MEDEIROS, F. P. A., LULA, B. e CORDEIRO, P. B. $�*UDSKLFDO�7RRO� WR� 6XSSRUW�7DVN�'HVFULSWLRQ� XVLQJ� 7$26� )RUPDOLVP� IRU� 8,� 'HVLJQ In: 7th ERCIM Workshop, 2002, Paris. 7th ERCIM Workshop. ERCIM (European Research Consortium for Informatics and Mathematics), 2002. p.45 – 51.

MEDEIROS, F. P. A.; LULA, B., CORDEIRO; P. B. L7$26��D�*UDSKLFDO�7RRO� WR�6XSSRUW�8VHUV�7DVN�'HVFULSWLRQ� LQ�8,�'HVLJQ�&RQWH[W In: V Symposium on Human Factors in Computer Systems, 2002, Fortaleza.V Symposium on Human Factors in Computer Systems. Fortaleza: BNDE, 2002. v.01. p.376 – 379.

MEDEIROS H., /¶8WLOLVDWLRQ� G¶XQ� /DQJXDJH� 7HUPLQRORJLTXH� GDQV� OD� 0RGpOLVDWLRQ� GH�&RQFHSWV�'\QDPLTXHV; Journées 1995, Projet ACNOS, LRPS-BETA-LAG-INRIA, 04-05, Sept 1995, Strasbourg, França, 1995.

MEDEIROS, H.; KAFURE, I. M e LULA, B. Jr�� 7$26�� D� 7DVN�DQG� $FWLRQ� 2ULHQWHG�)UDPHZRUN� IRU� 8VHU¶V� 7DVN� $QDO\VLV� LQ� WKH� &RQWH[W� RI� +XPDQ�&RPSXWHU� ,QWHUIDFHV, Proceeding of SCCC 2000 – XX International Conference oh he Chilean Computer Science Society, november 2000, Santiago, Chile, 2000.

77

MEDEIROS, H. e ROUSSELOT, F., $FTXLVLWLRQ�HW�0RGpOLVWDWLRQ�GH�&RQFHSWV�'\QDPLTXHV��/H�6\VWqPH�7$0(, Rapport ERIC R0102-96, Strasbourg, França, 1995.

MEDEIROS, H. e ROUSSELOT F., 8Q� 2XWLO� '$LGH� j� OD� 0RGpOLVDWLRQ� GH� &RQFHSWV�'\QDPLTXHV�� /H� 6\VWqPH� 7$0(; Journées Acquisition - Validation - Apprentissage, JAVA’ 95, 04/95, Grenoble, França, 1995.

MINSKY, M., $� IUDPHZRUN� IRU� UHSUHVHQWLQJ� NQRZOHGJH. In Winston, P. (Ed.), The Psychology of Computer Vision, chap. 6, pp. 211--277. McGraw-Hill, New York, 1975

PARIS, C.; TARBY,J.; VANDER, L.K., A Flexive Enviroment for Building Task Models. Proceedings of the IHM-HCI 2001, Lille, France.

PFAFF, G. R. 8VHU�,QWHUIDFH�0DQDJHPHQW�6\VWHPV, Eurographics Seminars, Springer-Verlag, 224 pages, 1985.

QUEIROZ, J. E. R., $ERUGDJHP�+tEULGD�SDUD�$YDOLDomR�GD�8VDELOLGDGH�GH�,QWHUIDFHV�FRP�R�8VXiULR, Tese de Doutorado, Coordenação de Pós-Graduação em Engenharia Elétrica - COPELE, UFPB, Campina Grande, junho de 2001.

SMITH R. G.; BARTH, P. S. e YOUNG, R. L., $�VXEVWUDWH� IRU�2EMHFW�2ULHQWHG� ,QWHUIDFH�'HVLJQ, Research Direction in Object-Oriented Programming (Ed. Shriver&Wegner), Computer Systems Serie, MIT Press, 1987.

SCAPIN, D. L e PIERRET-GOLKBREICH, C., 7RZDUGV� D�0HWKRG� IRU� 7DVN� 'HVFULSWLRQ��0$', Unité de Recherche, INRIA, Rocquencourt, France, 1989.

SEBILLOTE, S., +LHUDUFKLFDO�3ODQQLQJ�DV�0HWKRG�IRU�7DVN�$QDOLVLV��WKH�H[DPSOH�RI�RIILFH�WDVN�DQDO\VLV, Behaviour and Information Technology, vol. 7, No. 3, pp. 275-293. INRIA, Rocquencourt, Le Chesnay-Cedex, France,1988.

SEBILLOTE, S., Décrire des tâches selon les objectifs des opérateurs. De l’ interview à la formalisation [Task description model based on the operators’ objectives. From interviews to formalization]. Le travail Humain, 1991, 54, 193-223.

SEBILLOTE, S., 0HWKRGRORJ\�*XLGH�WR�7DVN�$QDO\VLV�ZLWK�WKH�*RDO�RI�([WUDFWLQJ�5HOHYDQW�&KDUDFWHULVWLFV� IRU� +XPDQ�&RPSXWHU� ,QWHUIDFHV, International Journal of Human-Computer Interaction, Le Chesnay Cedex, France, 1995.

78

SILVA, J. C., $TXLVLomR�GH�&RQKHFLPHQWRV� H�0DQXWHQomR�SDUD�XPD�VRFLHGDGH�GH�$JHQWHV�7XWRUHV�$UWLILFLDLV, Dissertação de mestrado, Universidade Federal da Paraíba, COPIN, 1999.

SOUZA, C. S. at al., 3URMHWR�GH�,QWHUIDFHV�GH�8VXiULR��3HUVSHFWLYDV�&RQLWLYDV�H�6HPLyWLFDV� In: XIX CONGRESSO NACIONAL DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 1999, Rio de Janeiro. Anais do XIX Congresso Nacional da Sociedade Brasileira de Computação. Rio de Janeiro: Edições Entrelugar, 1999. v.2. p.425-476.

SOUSA, M. R. F., $YDOLDomR� ,WHUDWLYD� GD� (VSHFLILFDomR� GH� ,QWHUIDFHV� FRP� ÇQIDVH� QD�1DYHJDomR, Tese de Doutorado, Coordenação de Pós-Graduação em Engenharia Elétrica - COPELE, UFPB, Campina Grande, dezembro de 1999.

STEWART, T., Standards Status ISO 9241, 2000.

TAM, R.C.M.; MAULSBY, D.; PUERTA,A., U-TEL: A Tool for Eliciting User Task Models from Domain Experts, Proceedings IUI’ 98, ACM Press, 1998.

TAUBER, M. J., 2Q�0HQWDO�0RGHOV�DQG�WKH�8VHU�,QWHUIDFH. In: van der Veer, G. C., Green, T. R. G., Hoc, J. M. and Murray, D. M. Working with Computers: theory versus outcome. Academic Press, London. Pp. 89-119, 1988.

TAUBER, M. J., (7$*��([WHQGHG�7DVN�$FWLRQ�*UDPPDU��D�ODQJXDJH�IRU�WKH�GHVFULSWLRQ�RI�WKH� XVHUV� WDVN� ODQJXDJH. In: Diaper, D., Gilmore, D., Cockton, G. and Shackle, B. Proceedings Interact'90, pp. 163 - 168. Elseviers, North-Holland, Amsterdam, 1990.

TURNELL,M.F.Q.V., 1RWDV� GH� $XOD� ±� &RQFHLWRV� H� 3URMHWR� GH� ,QWHUIDFHV� 8VXiULR� ±�&RPSXWDGRU, Laboratório de Interfaces Homem – Máquina, DEE – CCT/UFPB, 1998.

VAN WELIE, M., VAN DER VEER, G. C., Eliens A., An Ontology for Task World Models, Proceedings DSV-IS’ 98, pp-57-70, Springer Verlag, 1998.

WILSON, S.; JOHNSON, P.; KELLY, C.; CUNNHINGAM, J.; MARKOPOULOUS, P., %H\RQG�+DFNLQJ��D�0RGHO�%DVHG�$SSURDFK�WR�8VHU�,QWHUIDFH�'HVLJQ. In Proceedings of HCI'93, J. Alty, D. Diaper and S. Guest (eds), Cambridge University Press, 1993.

79

��

��

� � � �� ! � �" � �� # !$ � $ % & � ��

' ( � ) *+ , � -. / �� $ � � 0� � � �� 1 ��

2 ( � ) *+ � � � �" ! � �� $ � 3 �" � �� $ � 4� � � �" ! �

5 ( � ) * � - � 6 )� 7 � - � � 7 . 8 9. - , . ) � 8 9 � 9 � : �� & � ��

; � � � � < / � . 9 = � < �+ � >? $ @A $ � � � �� @B $ CB $ � � � �� C B $ A B $ � � � $ �� $ � � A B $ � � �D E E E E E $F GH I

J � �K 7 � 9 � �� ) � � K � 9 � ) < � 8 � 7 + � L � !M �" $ " � �� N � �� $ � � " !$ �

O ( � ) * 9. � . /K . � < * 8 ) < � K �+ P < � ) � � - < - 9. � � -

) � � K � 9 � ) < � 8 � < - :

�� & � �

Q R = S� � 8 9 � 9. � K � PUT � - � - < - 9. � � -

) � � K � 9 � ) < � 8 � < - :

� �� C� � � � � � � C� � � � � $ > $ � � � � $ � � � � > $ � � �� $ " � 0�V ��

W X � � S� . � �. S Y * 8 ) < � PT � - � - < - 9. � � -

) � � K � 9 � ) < � 8 � < - :

� � $ !� $ � �� " � ��

>Z �V N � ! [ � � V �� $ �\]^ _` a]b c]d e _f ` ] \g ^ g �

� �� > Z �V N � !

[ � � V �� $

>Z �V N � ! � �� $ � $ ��

>Z �V N � !� h � �

� �� >Z �V N � ! � �� $ � $

� $ >i Z �V [ � � � � N ! �� " �

�� j� k� l � �m � � � � l � � � j � �n � � �

��

�o ( � ) * 9. � . /K . � < * 8 ) < � K �+ P < � ) � � � pq rs tu r :

. v w rx , . - ) �. P � � - -� � - . /K . ) 9 � 9 < P � - S� � 8 9 � � �

� . - � � . , . K � < - P = K � � � � < 9. � yz T

�� & � ��

�{ N � �" $ " �Z $ �|

� � R = S� � 8 9 � 9. � K � PUT � - � � pq r s tu r : � �� C� � � � � � � C� � � � � $ > $ � � � $ � � � � > $ � �

� ' X � � S� . � �. S Y * 8 ) < � PUT � - � � pq r s tu r : � � $ !� $ � �� " �

>Z �V N � ! [ � � V �� $

� �� >Z �V N � ! � �� $ � $

� �� >Z �V N � !

>Z �V N � ! � �� $ � $

>Z �V N � !� h �

� �� >Z �V N � ! � �� $ � $

� $ >i Z �V [ � � � � N ! �� " �

} - 9. S� . - 9 < � 8 = � < � 9. � � K � � K 6 - < 9 � , . ) � 7 . 9 � � < 8 �� ~. - S� . K � - - <� < 7 < 9. � , . 7 < 8 . � � -. � K . � � < 7 , . � -� = � < � , . - < - 9. � � - ) � � K � 9 � ) < � 8 � < - . x . � K � � 9 < )� 7 � �x , � pq r s tu r - � �

) � 8 , < � ~. - , . 9. - 9. T p � � � � P � � � 8 � 7 < -. ) � , � � -K . ) 9 � ) � 8 - < , . � � , � x -. 7 . ) < � 8 � 8 , � � � K � � � S� . � � < - � , . S� � � -� � ) � 8 , < � � � , . � -� = � < � . �� 8 . ). 8 , � � - , . � � < - < 8 �� ~. -

- � 7 < ) < 9 � , � -�x S� � 8 , � -. � <� . � 8 . ). - - = � < � T

�� ¡ � � �� ¢£ ¤

80

[ � � V �� $

� 2 ¥� � 7 � P. � - � � , � pq r s tu r S� . PUT � 9 < 7 <� �

� 9� � 7 � . 8 9. :

� 5 X � � � PUT ) � 8 - < , . � � � K � � ). - - � , . < 8 - 9 � 7 �� , �

K � � ,� 9 � :

� �" � 1 ¦ �� 0 1 ¦ �� 0 � �� 1 ¦ �� 0 � �� 1 § �� 0 � � 1 § �� 0 � �" � � � 1 § �� 0

� ; ¨ 8 � 9� �. � � , � K � < 8 ) <K � 7 � 9 < P < , � , . S� . PUT

, . -. 8 P � 7 P. ) � � � �� / © 7 < � , � p q rs tu r +

. - -. 8 ) < � 7 � . 8 9. , . �

e] ` ª«¬ ` g ] a] ` ]^ c _ c¬ \]^ ® _ g e¬ ¯g ° ± _ ¬ \] a¬ g ®g a]

« ®¬ ¬ ® ²f ¬ _`

®f ] ¬ ^ g \]^ ® _ ] g ef ]^ a¬ d g ³] \

� J v � ) � 8 9. / 9 � , . -� � - � 9 < P < , � , . - PUT � 9 < 7 <� � �

p q rs tu r . � �

¯´µ ¶ ·¸¹ º » ´ ¼½ \ ´ ¼½ ¾ ´ ¶

e ¸ ½ ¶ ·¿ º » ´ ¼½ ` ½ ¸À Á º ´ ¶

` ¹ Â´ ¸ ·½ ¿ a Á ¶Ã Á Â ¾ Áµ ¿ ¶ ®½ Ä ¸ Á Ã ¿ ¶

Å ³ ¸ ¿ ¼¹ ¿ º » ´ Æ

c½ ¸ Á Ç Á Ã ¿ º »´ ¼½ \ ´ ¼½ ¾ ´ ¶ ]È Á ¶ ·½µ ·½ ¶

] È ½ Ã ¹ º »´ ¼½ e ¸ ´ É½ ·´ ¶

` ¹ Â´ ¸ ·½ ¿ a Á ¶ Ã Á Â ¾ Áµ ¿ ¶ ®½ Ä ¸ Á Ã ¿ ¶ Å e Ä ¶Ê

Ë ¸ ¿ ¼¹ ¿ º »´ Æ

« · Á ¾ ÁÌ ¿ º »´ ½Í ·½ ¶½ ¶ Î a Á ¶ ¶½ ¸ ·¿ º Ï½ ¶

a½ ¶½µ À ´ ¾À ÁÍ ½µ ·´ ¼ ½ e ¸ ´ ¼¹ ·´ ¶

` ¹ Â´ ¸ ·½ ¿ Ð ´ ¸ ¿ ·´ ¸ Á ¿ ¾ Å ³ ¸ ¿ ¼¹ ¿ º »´ Æ

« ¶´ ½Í ®¸ ¿ Ð ¿ ¾ Ñ ´ ¶ ¼½ ¬ µ Á Ã Á ¿ º » ´ ¯ Á ½µ · Ò Ç Á Ã ¿

®¸ ½ Áµ ¿Í ½µ ·´ ½ Í ^ ÒÀ ½ ¾ ¼ ½ ] È ·½µ ¶ » ´

` ¹ Â ´ ¸ ·½ ¿ Ð ´ ¸ ¿ ·´ ¸ Á ¿ ¾ Å e Ä ¶ Ê Ë ¸ ¿ ¼¹ ¿ º » ´ Æ

� O ¥� � 7 � �� , . � Ó� , � , � pq r s tu r S� . PUT

) � - 9� � � � 9 < 7 <� � � � � < - � �. S Y . 8 9. � . 8 9. :

� $ � $ 0

3 � 0 N� � � M D � � " � !� �" I

3 � 0 N L� �

� �� 0" $ � � !$ � � $ � " ! � �

� ¦ !� � �

� ��

� N � !" � " � �� D 1 �� Ô �Õ � $ � 0Ô 1 $ { I

� Q ¥� � < - � - X � < / � - , . Ö. � � � � . 8 9 � - S� . PUT

) � - 9� � � � 9 < 7 <� � � � � < - � �. S Y . 8 9. � . 8 9. :

� !� $ � � ! � � 4 $ � � �

�� " � ! � � 1 � !� 0 ¦ !� � �

$ � 4� �� " � � � $ N 0� � $ % & �

$ � �� " !$ � � ! � � � � # !$ � % $

$ � � � � � �" !$ � � ! � � 4 $ � � �

�� " � ! � � ! � 0 $ " × !� � �

�� l � � � j� � �Ø � � l � � n � j �� j � �n � ��

��

�� & � �� W ( � ) * 9. � . /K . � < * 8 ) < � K �+ P < � ) � � K � � ,� 9 � -

- < � < 7 � �. - : . v w rx . 8 ). � �. 8 . - 9. K � 8 9 � �

K �. . 8 ) Ù < � . 8 9 � , � S� . - 9 < � 8 = � < � T . Ú Û x

. -K . ) < � < S� . � K � � ,� 9 � . ) � 8 9 < 8� . � K �. . 8 ) Ù < � . 8 9 �

, � S� . - 9 < � 8 = � < � T

� � N � �� 1� � $ % & � |

'o . PT K �. . 8 ) Ù . � � < 9. � � 8 9. � < � �x . -K . ) < � < S� . �

9. � K � , . � - � , � K � � ,� 9 � T

� �� C� � � � � � � C� � � � � $ > $ � � � $ � � � � > $ � �

' � . PUT 9. � . /K . � < * 8 ) < � ) � � � � -. Ü� 8 , � K � � ,� 9 �

- < � < 7 � �x . -K . ) < � < S� .Ý � T

' ' . PT K �. . 8 ) Ù . � � < 9. � � 8 9. � < � �x . -K . ) < � < S� . �

9. � K � , . � - � , � K � � ,� 9 � T

� �� C� � � � � � � C� � � � � $ > $ � � � $ � � � � > $ � �

' 2 . PUT 9. � . /K . � < * 8 ) < � ) � � � � 9. � ). < � � K � � ,� 9 �

- < � < 7 � �x . -K . ) < � < S� .Ý � T

' 5 . PT K �. . 8 ) Ù . � � < 9. � � 8 9. � < � �x . -K . ) < � < S� . �

9. � K � , . � - � , � K � � ,� 9 � T

� �� C� � � � � � � C� � � � � $ > $ � � � $ � � � � > $ � �

81

�$SrQGLFH��±�3HUILO�GR�XVXiULR�Características do usuário, escolhidas pelo projetista, de acordo com a relevância, para o projeto. Levantamento baseado em: " Fatos " Opiniões do usuário " Dados medidos ou observados - Faixa etária: 18 a 60 - Sexo: Masculino ou Feminino - Habilidades necessárias para executar a tarefa:

- Habilidade de percepção: Táctil, Visual. - Habilidades motoras: Precisão, habilidade para manusear o mouse

- Grau de instrução: Segundo grau completo - Freqüência de execução das Tarefas: Uma vez a cada seis meses (por usuário) - Objetivos: Modelar tarefas utilizando uma ferramenta de apoio - Motivações: Facilitar a vida do usuário: Menor trabalho braçal, Verificação de consistência e completude da tarefa. Reduzir erros e Otimizar modelagem.

7 - Função: Projetista de interfaces e sistemas computacionais. Experiente. - Tarefa: Analisar e modelar tarefas. Experiente. - Método: Utilizando uma ferramenta de apoio. O usuário pode ser noviço. - Computador: Necessidade de bom conhecimento. Razoavelmente experiente. - Uso do teclado: Experiente - Uso de mouse Experiente - Uso de dispositivos especiais de interação: Não é necessário

7 Nível de experiência: noviço, experiente, especialista, ...

3$57(��,��&$5$&7(5Ë67,&$6�

3$57(��,,��&21+(&,0(172�&21&(,78$/�

Conhecimento Sintático Nível de experiência

82

- Uso de terminologia específica: Experiência com a terminologia do formalismo TAOS para análise e modelagem de tarefas ou outro formalismo. Experiência com alguma ferramenta de modelagem ou edição (ex: Dreamweaver, Front Page, Rational Rose ou até mesmo Microsoft Word - desenho).

- Aprendizado: Por experiência adquirida para usar a ferramenta; Por tutoriais (livros) ou

aulas para modelar tarefas. - Capacidade de solucionar problemas: Razoável - Capacidade de reter o aprendizado: Alta - Nível de curiosidade: Razoável - Nível de persistência: Alto - Nível de inovação: " Inovador " Conservador " Impulsivo " Reflexivo

3$57(��,��&$5$&7(5Ë67,&$6�

Personalidade:

83

$SrQGLFH��/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62�� /HJHQGD� Recomendação aplicada ou adotada e os métodos usados

$SOLFDELOLGDGH� $GRomR� &RPHQWiULRV��LQFOXLQGR�IRQWHV��

��

5HFRPHQGDo}HV�

� � � � � �� (VWUXWXUD�GH�0HQXV�� ! "# $% ! & � ! " !# � � ')( * ( * +, -. /01 2 , 34 0 56 . 54 20 5 , 2 3

Opções ordenadas em grupos convencionais ou naturais 0 7

')( * ( 8 +, -. /01 2 , 3 9 : / 24 , 3

Ordenadas de forma a evitar ambigüidades e ser facilmente apre(e)dida pela população usuária; níveisminimizados; número de opções maximizadas 0 7

')( * ( ; +, -. /01 2 , 3 ,1 < 2 -1 =1 2 , 3

Se não for possível o agrupamento lógico, as opções devem ser arranjadas em grupos de 4 a 8 opções por nível, .

')( * ( > +0 5 3 2? .1 , @ A . 3 30 <1 . 0 -. BC 0 ? . < 7 34 ,

Se for relevante, deve-se incluir tantas opções e níveis quantos forem possíveis em um único painel de menu. Ver também 8.2.2.

�� D EF � � G � " !# � H ! G� I !� ! " � " " !# � ')( 8 ( * J1 7 C 0 3 9 : / 24 0 3

As opções deverão ser agrupadas por função ou em categorias lógicas, 0 7

')( 8 ( 8 J1 7 C 0 3 ,1 < 2 -1 =1 20 3

Oito ou mais opções deverão ser arranjadas em grupos arbitrários utilizando-se a seguinte equação:

KL =

84

�� M N !O P !# Q & �� H ! G� I !� ! " F � � G � ')( ; ( * +0 5 3 2 3 - R 54 2 ,

As opções devem ser consistentemente posicionadas, na mesma ordem, no grupo de opções. (Ver também 5.2.1), .

')( ; ( 8 S BC 01 - T 54 2 ,

As opções importantes deverão ser listadas em primeiro lugar, . /0 7

')( ; ( ; �1 ? . B 4 0 56 . 54 20 5 , 9

Se for possível manter a ordem convencional, 0 7

')( ; ( > �1 ? . B .U 2 3 -. 5 - .

Se o esquema existente de ordenação for amplamente utilizado, 0 7

')( ; ( ' �1 ? . B ? . 7 30

Se a ordem de uso for conhecida, arranjar segundo tal ordem, 0 7

')( ; ( V �1 .W X R 54 2 , ? . 7 30

Se os grupos forem pequenos (8 ou menos), 0 7

')( ; ( Y �1 ? . B , 9 Z, < [ - 24 ,

Se a freqüência não for conhecida ou os grupos forem grandes

�� 1DYHJDomR�SRU�PHQXV�� \]� � E� G ! Q � � H �# � % ! F �� V ( * ( * ^ _ - 7 90 3

a) Distingüíveis e descritivos, .

b) Compostos por termos relacionáveis, . /0 7 V ( * ( 8 � 3W 7 . B , ? . 5 7 B .1 , @ `0

Estrutura óbvia para o usuário, . /0 7

V ( * ( ; ^ [4 5 24 , 3 /1 = Z 24 , 3

Consistentemente aplicadas e com propósito óbvio para o usuário, . /0 7

V ( * ( > C1 . 3 . 5 -, @ `0 3 2 B 7 9 - T 5 . ,

As relações hierárquicas entre painéis visualizados simultaneamente deverão ser claras para os usuários, .

V ( * ( ' � , C , 3 ? . B . 5 7 3

Deverão representar claramente a estrutura de menus e estarem disponíveis quando requisitados

\]� D a � % ! F �� b G & H � V ( 8 ( * ^ . BC 0 ? . , 4 . 3 30

Se os menus forem acessados de uma estrutura hierárquica, deverão ser apresentados no mais curto

85

intervalo de tempo possível (recomenda-se um valor em torno de 500 ms) .V ( 8 ( 8 4 . 3 30 , 0 3 5 : 3

Os usuários deverão ser capazes de ir de uma parte (nó) a outra sem terem que retornar ao nó inicial comum, .

V ( 8 ( ; c. -0 1 50 , 0 B . 5 7 2 5 24 2 , 9

Simples e consistente, .

V ( 8 ( > 34 . 5 3 `0 ? . 5 _6 . 9

Modo simples e consistente de ascensão de níveis na estrutura de menus.

V ( 8 ( ' +, B 2 5 d0 3 B e 9 - 2 C 90 3

Fornecer alternativas, se tal estratégia se mostrar lógica e fizer sentido.

�� 6HOHomR�H�H[HFXomR�GH�RSo}HV�� f�� g h � H � H ! � ! i !� � Y ( * ( * � [ -0 ? 0 3 , 9 - .1 5 , - 26 0 3

Fornecer métodos alternativos ou habilitar dispositivos de entrada alternativos, se estes forem compatíveis com as limitações do sistema .

Y ( * ( 8 @ A . 3 ? . 3 . 9 . @ `0 . . U . 4 7 @ `0 ? 2 3 30 4 2 , ? , 3

De opções, a menos que o acesso rápido seja importante e/ou os erros sem conseqüências remarcáveis, . /0 7

4 . 3 30 1 =C 2? 0

Se os usuários forem experientes e/ou necessitarem de acesso rápido a opções específicas do menu

a) Mecanismos de atalho – fornecidos para menus intermediários, . /0 7

Y ( * ( ;

b) Seleção e execução combinadas– dotadas de j k lm , . Y ( * ( > c. -0 1 50 , 0 7 3 7 =1 20

Retorno consistente fornecido na opção selecionada, .

Y ( * ( ' � . 3 3 . 9 . @ `0 . ? . 3 Z, n 2 B . 5 -0 ? . 0 C @ A . 3

Fornecer meios para a desseleção de opções, prioritariamente aos mecanismos de execução ou desfazimento oferecidos, .

Y ( * ( V -1 , 30 5 , 1 . 3C 0 3 -,

Se a resposta sofrer um atraso de mais de 3 segundos, deve-se fornecer uma indicação de que o computador está processando a solicitação, .

Y ( * ( Y � . 9 . @ `0 B e 9 - 2 C 9 ,

Se for permitida a seleção múltipla, permitir que todas as escolhas e alterações sejam feitas antes da execução.

86

f�� D o ! Q i � H � i p �# � " h � & Q Y ( 8 ( * � 2 5 2 B 2 n, @ `0 ? . , -, 9 d0 3 . Y ( 8 ( 8 q0 4 , 9 2 n, @ `0 ? . 9 2 5 d , ? . 4 0 B , 5? 0

Em uma posição consistente no painel de menu e ao longo dos diferentes painéis de menu, .

Y ( 8 ( ; �W 7 26 , 9 R 54 2 , ? . B , 2 e 34 7 9 , 3 . B 2 5 e 34 7 9 , 3

As opções deverão ser selecionadas a partir de entradas digitadas pelo usuário em minúsculas, maiúsculas ou combinações de ambas .

� . 3 2 / 5 , ? 01 . 3 , 9 Z, < [ - 24 0 3

As opções deverão ser designadas por uma ou mais letras-chaves (mnemônicos) (Ver também 8.1.11), se

a) A lógica e exclusividade de tais letras forem asseguradas .

Y ( 8 ( >

b) A ordenação seqüencial das opções não for importante .

Y ( 8 ( ' c. /1 , Z =4 2 9 C ,1 , 0 3 ? . 3 2 / 5 , ? 0 1 . 3

Designadores alfabéticos deverão ser gerados a partir de uma regra que seja de fácil aprendizado pelos usuários 0 7

Y ( 8 ( V � . 3 2 / 5 , ? 01 . 3 5 7 B [1 24 0 3

Começando por “1” não por “0” .

Y ( 8 ( Y � 3 -1 7 - 71 , . 3 2 5 -, U . ? 0 3 ? . 3 2 / 5 , ? 0 1 . 3

Consistente entre os designadores.

f�� M o ! Q i �� H ! p �# � � Y ( ; ( * � . 3 2 / 5 , ? 01 . 3

Deverão corresponder aos rótulos das teclas de função .

Y ( ; ( 8 C1 . 3 . 5 -, @ `0 ? . , -1 2 < 7 2 @ A . 3

Se a atribuição-chave não for apresentada continuamente, então apresentá-la quando solicitada, .

Y ( ; ( ; �1 2 . 5 -, @ `0 ? . B . 5 7

Mesma que as das teclas de função, quando um tempo de resposta rápido ao usuário for importante, .

Y ( ; ( > +0 5 3 2 3 - R 54 2 , ? , 3 , -1 2 < 7 2 @ A . 3

Opções consistentemente selecionadas e executadas a partir das mesmas teclas de função.

f�� r N ! i !� � H ! � ! Q i �� H ! " % & " !# � �� H Q � � � � Y ( >)( * �C @ A . 3 . B4 0 9 7 5 , 3

a) As teclas com setas para cima e para baixo movem o cursor para cima e para baixo na estrutura vertical de opções do menu .

87

b) Se o menu for dotado de seleção cíclica ( s tuv u tm j k l), a tecla com seta para baixo move o cursor da última opção para a primeira opção da estrutura vertical de opções do menu, enquanto a tecla com seta para cima move o cursor da primeira opção para a última opção da estrutura vertical de opções do menu .

�C @ A . 3 . B 9 2 5 d , 3

a) As teclas com setas para a esquerda e para a direita movem o cursor para a esquerda e para a direita na coluna de opções do menu na estrutura horizontal de opções do menu .

Y ( >)( 8

b) Se o menu for dotado de seleção cíclica ( s tuv u tm j k l), a tecla com seta para a direita move o cursor da última opção para a primeira opção da estrutura horizontal de opções do menu, enquanto a tecla com seta para a esquerda move o cursor da primeira opção para a última opção da estrutura horizontal de opções do menu .

Y ( >)( ; J1 7 C 0 3 ? . 0 C @ A . 3

Uma tecla diferente das teclas com setas deverá ser usada para mover o cursor entre grupos de opções .

Y ( >)( > ^ . B C 0 ? . 1 . 3C 0 3 -, ? 0 4 71 301

O movimento de resposta do cursor na tela deverá ser tão rápido quanto possível (um valor apropriado é em torno de 200 ms)

f�� E G # � � " !# � w1 . , ? . , C 0 5 -, B . 5 -0

a) Telas sensíveis ao toque – Área extensa o suficiente para minimizar “lapsos” (e.g., as mesmas dimensões do rótulo da opção mais meio caractere em torno do rótulo, ou na faixa de 20 mm x 20 mm a 30 mm x 30 mm, qualquer que seja o valor), 0 7

Y ( ')( *

b) Área não rotulada – Área extensa o suficiente para assegurar que o dispositivo de apontamento não obscureça o (e.g., pelo menos duas vezes a área ativa do dispositivo de seleção ou a área de visualização do apontador, porém não menor do que 4 mm²) .

Y ( ')( 8 - 26 , @ `0 5 `0 2 5 - . 54 20 5 , 9

Minimizada pelos seguintes meios: a) Estabelecimento de uma separação adequada entre

áreas selecionáveis, .

88

b) Inclusão de retorno audível ou visual para o usuário (ver 7.1.2) .

Y ( ')( ; x 30 . W 7 26 , 9 . 5 -. ? 0 - . 4 9 , ? 0

A seleção e execução de opções via teclado deverá ser permitida, alternativamente ao uso de dispositivos de apontamento.

f�� \ y z Y ( V ( * � 2 34 1 2 B 2 5 , @ `0 Z0 5 [ - 24 ,

As palavras utilizadas para a seleção de opções por voz deverão ser foneticamente distintas .

Y ( V ( 8 +0 5 3 2 3 - R 54 2 ,

As opções deverão ser consistentemente aplicadas ao longo dos componentes das tarefas .

Y ( V ( ; c 7 _? 0

Ruído ambiental reduzido.

�� $SUHVHQWDomR�GH�PHQXV�� {]� � E Q !� � � G� I !� ! H &� Q � & " &# �� H ! G� I !� | ( * ( * �C @ A . 34 1 _ - 24 , 3

Continuamente apresentadas .

| ( * ( 8 x 30 Z1 . W X . 5 - .

Opções posicionadas em uma região da tela que não oculte os dados da tarefa . /0 7

| ( * ( ; x 30 0 4 , 3 20 5 , 9

Menus apresentados conforme solicitação do usuário .

| ( * ( > �C @ A . 3 ? 2 3C 0 5 _6 . 2 3

Apresentadas sozinhas, a menos que sejam solicitadas informações concernentes a outras opções 0 7

| ( * ( ' �C @ A . 3 5 `0 ? 2 3C 0 5 _6 . 2 3 4 0 BC 9 . B . 5 -, 5? 0 0 C @ A . 3

? 2 3C 0 5 _6 . 2 3

Apresentadas se puderem se tornar disponíveis em algum outro ponto do diálogo (tais opções deverão ser apresentads com codificação visual apropriada) .

� . 9 . @ `0 }~ �� 1 . , 9 @, ? ,

Em uma das seguintes opções:

a) Opção mais freqüente– se a probabilidade de seleção for conhecida 0 7

b) Primeira opção – no grupo, se a repetição não for importante, 0 7

c) Opção Anterior– a repetição da opção anterior for importante 0 7

| ( * ( V

d) Opção menos destrutiva .

89

^ _ - 7 90 3

a) Primeiro menu – título descritivo curto ou evidenciação do propósito deverá ser evidente por sua posição ou associação . /0 7

b) Menu de nível inferior – em série ou:1) Título como em a) 0 7

| ( * ( Y

2) Evidenciação da dependência de uma opção de nível superior .

| ( * ( | � . 5 7 3 � J1 7 C 0 3 ? . 0 C @ A . 3 B e 9 - 2 C 90 3

Menus/Grupos de opções deverão ser visualmente distintos e usados consistentemente, se possuírem título . /0 7

| ( * ( � � . 9 . @ `0 B e 9 - 2 C 9 ,

Indicações visuais deverão ser fornecidas em uma posição consistente . /0 7

| ( * ( *� � . 3 2 / 5 , ? 0 1 . 3 . U C 9 _4 2 -0 3

Letras maiúsculas e minúsculas não deverão causar confusão (Ver também 7.2.3 e 7.2.4) 0 7

| ( * ( * * � . 3 2 / 5 , ? 0 1 . 3 2 B C 9 _4 2 -0 3

Letras realçadas e seleção e execução combinadas (ver 7.1.3b).

{]� D � � & Q & # � " !# � +0 5 3 2 3 - R 54 2 , ? 0 9 , �0 7 -

a) Menus de comprimento fixo – adotar posicionamento absoluto 0 7

| ( 8 ( *

b) Menus de comprimento variável – adotar posicionamento relativo .

| ( 8 ( 8 ^ _ - 7 90 3

Consistentemente posicionados no topo e centralizados ou alinhados pela esquerda .

| ( 8 ( ; � . 3 2 / 5 , ? 0 1 . 3 . U C 9 _4 2 -0 3

Posicionados à esquerda do nome da opção (separados deste por 2 ou 3 caracteres de espaçamento) .

| ( 8 ( > ^ . 4 9 , 3 , 4 . 9 .1 , ? 0 1 , 3

Códigos posicionados à direita do nome da opção (e preferencialmente alinhados pela direita) .

�C @ A . 3 . B4 0 9 7 5 , 3 | ( 8 ( '

a) Espaçamento – se disponíveis, as opções deverão ser apresentadas em espaço vertical duplo 0 7

90

b) Espaçamento simples – se as opções forem apresentadas em espaço simples, usar letras minúsculas ou minúsculas com a letra inicial maiúscula .

c) Grupos de opções – separados por um espaçamento vertical que seja uma vez e meia a duas vezes igual ao espaçamento vertical das opções existentes em cada grupo .

d) Alinhamento – As opções deverão ser alinhadas pela esquerda (

�� j � � ��

) .

e) Múltiplas colunas de opções - deverão ser separadas por, pelo menos, 3 caracteres de espaçamento .

f) Designadores seqüenciados – designadores numéricos ou alfabéticos deverão ser alinhados seqüencialmente em colunas .

| ( 8 ( V �C @ A . 3 . B 9 2 5 d , 3

Se posicionadas horizontalmente, deverão ser suficientemente separadas para permitir discriminação visual . /0 7

| ( 8 ( Y +01

O mesmo código de cores deverá ser adotado para as opções de um grupo particular de opções (limitando-se a 4 cores) . /0 7

q . -1 , 3

Se forem usados estilos e tamanhos de letras, considerar:

a) Legibilidade – estilos e tamanhos de letras deverão ser legíveis e distingüíveis .

| ( 8 ( |

b) Quantidade – combinações únicas de estilos e tamanhos de letras em um menu não deverão exceder três (não contando maiúsculas/minúsculas) . /0 7

| ( 8 ( � �01 ? , 3 . 9 2 5 d , 3� a) As bordas e linhas deverão ser mantidas simples . b) As bordas e linhas deverão ser suficientemente

separadas das opções de modo a não interferirem com a legibilidade

| ( ; � 3 -1 7 - 71 , . 3 2 5 -, U . ? . 0 C @ A . 3 -. U - 7 , 2 3 | ( ; ( * �0 B . 3 . - _ - 7 90 3 5 `0 , B < _ / 70 3

Nomes de opções e títulos de grupos de opções deverão ser semanticamente distintos .

91

| ( ; ( 8 � , 9 , 61 , 3� 4 d , 6 . 3�

a) Início com palavras-chaves (a menos que seja anti-naturais para o idioma) .

b) Palavras-chaves sugestivas deverão ser usadas, enquanto palavras-chaves inócuas evitadas .

| ( ; ( ; ^ .1 B 2 50 90 / 2 , ? , 3 0 C @ A . 3

Familiar aos usuários .

| ( ; ( > �1 , 3 . , ? 0 ? , 3 0 C @ A . 3

Conciso e consistente .

| ( ; ( ' �C @ A . 3 ? . , @ A . 3

Expressas através de verbos . /0 7

| ( ; ( V �C @ A . 3 ? . 0 <� . -0 3

Expressas através de substantivos (nomes) . /0 7

| ( ; ( Y �C @ A . 3 ? . , @ A . 3 . 0 < � . -0 3

Representadas por sintaxe verbo-nominal .

| ( ; ( | ^1 , 5 3 2 @ `0 C ,1 , 9 2 5 / 7 , / . B ? . 4 0 B , 5? 0 3

Uso de maiúsculas e sintaxe dos nomes das opções devem ser consistentes com a linguagem de comandos .

| ( ; ( � +0 5? 7 @ `0 , 0 7 -1 , 0 C @ `0

Se uma opção conduz a outro menu ao invés de conduzir à execução, fornecer indicações apropriadas 0 7

| ( ; ( *� +0 5? 7 @ `0 , 0 7 -1 0 ? 2 = 90 /0

Se a opção conduz a outro diálogo, fornecer indicações consistentes.

| ( > � 3 -1 7 - 71 , . 3 2 5 -, U . ? . 0 C @ A . 3 /1 = Z 24 , 3 | ( >)( * c : - 7 90 3 ? . _4 0 5 . 3

Caso seja possível ambigüidade de ícones .

| ( >)( 8 /1 7 C , B . 5 -0

Ícones de objetos e de ações posicionados em diferentes grupos de um menu .

| ( >)( ; � 2 34 1 2 B 2 5 , @ `0 6 2 3 7 , 9

Ícones devem ser selecionados para representar opções visualmente distintas e seu significado deverá ser facilmente reconhecido.

| ( ' � 3 -1 7 - 71 , . 3 2 5 -, U . ? . 0 C @ A . 3 , 7? _6 . 2 3 | ( ')( * � e B .1 0 ? . 0 C @ A . 3

O menor possível (3 ou 4) .

| ( ')( 8 � 2 5 -, U .

A sintaxe de opções/designadores preferida .

| ( ')( ; � 2 34 1 2 B 2 5 , @ `0 , 4 e 3 - 24 ,

Opções do menu de voz compreendidas de itens distintos

92

em termos auditivos e traduzidos por palavras únicas suficientemente espaçadas (no tempo), a fim de permitir a discriminação pelo usuário, .| ( ')( > +, C , 4 2? , ? . ? . 1 . C . - 2 @ `0

Deverá ser oferecida.

q . / . 5? , �

�

= Sim (se aplicável)

�

= Não (se não aplicável)

= Análise da Documentação do Sistema �

= Evidência documentada �

= Observação

= Avaliação Analítica �

= Avaliação Empírica � �

= Método Diferente

� = Mensuração

� = Passou (atendeu à recomendação)

�

= Falhou (não atendeu à recomendação)

93

$SrQGLFH��/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62�� /HJHQGD� Recomendação aplicada ou adotada e os métodos usados

5HFRPHQGDo}HV��

$SOLFDELOLGDGH��

$GRomR��

&RPHQWiULRV�(incluindo fontes)

��

��

��

��

��

��

��

��

��

��

� � ��

�

��

� ��

��

��

��

�,QIRUPDomR�*HUDO��

!#" $ " $ �% &' ()% *% +% , -. / ( 01 2 34 () 51 6 5 ( 1 & 57 2 5 2 7 - +89 :; <= > ? : @A

!#" $ " B �1 5 C D ( 7 - & 7 1 4 () E1 4 FG 1% &

!#" $ " H I% 3% 5 -. J1 & 01 31 5 C D ( 7 - &

�� K LM �� NO P Q � R � � ST � � � U � R � � V

V �O Q M U W �X Y � R Q � � � �

!#" B " $ �% 31 ) & J1 & -' 7 (' 7% - 0 - & 01 C 7 1 - & 3 -)% ' 2 + C G 1% &

!#" B " B �% &4 7% 3% ) -. / ( 0 - & 7 1 ' 7 1 &1 ) 5 -. J1 & 01 ( *Z 1 5 ( & 1 F4 () 1 & 01

4 () 57 ( +1 0 - 3 -)% ' 2 + -. / ( 0% 7 1 5 -

!#" B " H ' - 7 [) 4 % - 01 ( *Z 1 5 ( & ) / ( 0% &' ()% *% +% , - 0 ( & 1 F4 () 1 & 01

4 () 57 ( +1

!#" B " \ ' 7 1 &1 ) 5 -. / ( 1 3 &1] 2 ) 0 ( ' + -) ( 01 ( *Z 1 5 ( & 31 ) ( &

% 3' ( 7 5 -) 51 &

!#" B " ! ^1 ' 7 1 &1 ) 5 -. / ( 01 ( *Z 1 5 ( &

�� _ `� � �� O � R � Q O � �� V �X a�

!#" H " $ ' () 5 - 0 ( 7 1 & 01 % ) 0% 4 -. / ( 01 5% ' ( & 01 3 -)% ' 2 + -. / ( 0% 7 1 5 -

!#" H " B ' () 5 - 0 ( 7 1 & 01 % ) 0% 4 -. / ( 01 ) / ( 0% &' ()% *% +% 0 - 01

94

!#" H " H b ) 0% 4 -. J1 & ' - 7 - (' . J1 & & ( +% 4 % 5 - 0 - &

!#" H " \ ^1 5 ( 7 ) ( % 31 0% - 5 ( 1 4 () 5 F) 2 ( 01 % ) D ( 7 3 -. J1 & ' - 7 - ( &

0% D1 7 1 ) 51 & ) FG 1% & 01 3 -)% ' 2 + -. / ( 0% 7 1 5 -

!#" H " ! ' 7 1 &1 ) 5 -. / ( 01 ( *Z 1 5 ( & 7 1 4 1 ) 51 31 ) 51 4 7% - 0 ( & ( 2 - 5% G - 0 ( &

�� c d Q M � Q � Qe � R � � O �� R �

!#" \" $ �% &' ( &% 5% G ( & - + 51 7 ) - 5% G ( &

!#" \" B fg 4 )% 4 - & 1h 2% G - +1 ) 51 & 01 3 -)% ' 2 + -. / ( 0% 7 1 5 - G% - 51 4 + - 0 (

!#" \" H + 51 7 ) i) 4 % - 3 F)% 3 - 1 ) 57 1 0% &' ( &% 5% G ( & 01 1 ) 57 - 0 -

!#" \" \ j ( 5 J1 & 3 k + 5% ' + ( &

��

0DQLSXODomR�GH�REMHWRV�

lm� � n � O Q R � � � X a� o � � � Q

p " $ " $ � -)% ' 2 + -. J1 & 0% 7 1 5 - &] 1 ) g 7% 4 - &

p " $ " B �1h 2 [) 4 % - 01 ( *Z 1 5 ( & 01 3 -)% ' 2 + -. / ( 0% 7 1 5 -

p " $ " H b ) 0% 4 -. / ( q � 2] 1 & 5 / ( - 2 5 ( 3 C 5% 4 - 01 ( *Z 1 5 ( & ( 2 3 -)% ' 2 + -. J1 &

0% 7 1 5 - & 0% &' () FG 1% &

p " $ " \ � -)% ' 2 + -. / ( 0% 7 1 5 - 01 & - F 0 -

p " $ " ! ^1 5 ( 7 ) ( - 1 & 5 - 0 ( & -) 51 7% ( 7 1 & - 3 -)% ' 2 + -. J1 & 0% 7 1 5 - &

p " $ " p � -)% ' 2 + -. / ( 0% 7 1 5 -� 01 - 57% * 2 5 ( &

lm� K LM � O � � V � O � � � � W � X Y �

p " B " $ r% & 2 - +% , -. / ( 0 ( -' () 5 - 31 ) 5 ( 1 &1 +1 . / (

p " B " B ' () 5 - 31 ) 5 ( & ( * 7 1 ( *Z 1 5 ( & 1 1 ) 57 1 ( *Z 1 5 ( &

p " B " H �1 4 -)% & 3 ( & &% 3' +1 & 01 &1 +1 . / (

p " B " \ �1 4 -)% & 3 ( & 3 k + 5% ' + ( & 01 &1 +1 . / (

p " B " ! � -)% ' 2 + -. / ( 0% 7 1 5 - &% 3 2 + 5 i) 1 - 01 G C 7% ( & ( *Z 1 5 ( &

p " B " p s 7 1 - & &1 +1 4 % () C G 1% & ' - 7 - - 3 -)% ' 2 + -. / ( 0% 7 1 5 - 01 ( *Z 1 5 ( &

p " B " t � & 57 2 5 2 7 -. / ( 01 & 5% ) - 0 - u &1 +1 . / ( 01 ( *Z 1 5 ( &

p " B " v 4 1 & & ( - ( *Z 1 5 ( & & 2 ' 1 7 ' ( & 5 ( &

p " B " w � D% 4 % [) 4 % - 0 ( & 31 4 -)% & 3 ( &

p " B " $x y & ( 01 z4 +% h 21 { 0 2 ' + (

p " B " $ $ | () D% ] 2 7 -. / ( 0 ( 2 & 2 C 7% ( ' - 7 - z4 +% h 21 & { 3 k + 5% ' + ( &

95

p " B " $ B �1 +1 . / ( 4 () 5 F) 2 - 01 ( *Z 1 5 ( &

p " B " $ H ^1 0% 7 1 4 % () - 31 ) 5 ( 01 D (4 ( & 01 1 ) 57 - 0 -

l � _ L� � � � �

p " H " $ r% & 2 - +% , -. / ( 0 ( - 7 7 - & 5 (

p " H " B 7 7 - & 5 ( 01 2 3] 7 2 ' ( 01 ( *Z 1 5 ( &

p " H " H � % D1 7 1 ) 4 % -. / ( &1 3 i) 5% 4 - ) ( ' 7 (4 1 & & ( 01 - 7 7 - & 5 (

p " H " \ b ) 51 7 -. J1 & ' 7 g} 01 D% )% 0 - & 1 ) 57 1 ( *Z 1 5 ( &

p " H " ! | () 57 ( +1 0 - & ' ( &% . J1 & 0 ( & ( *Z 1 5 ( & ' 1 + ( 2 & 2 C 7% (

p " H " p 4 1 & & ( - ( *Z 1 5 ( & (4 2 + 5 ( &

p " H " t r% & 2 - +% , -. / ( - 2 5 ( 3 C 5% 4 - 01 ( *Z 1 5 ( & 1 3 Z -) 1 + - &

p " H " v � ( &% 4 % () - 31 ) 5 ( 3 -) 2 - + 01 ( *Z 1 5 ( & 1 3 Z -) 1 + - &

l � c d Q V � O Q � O � V � O � � R � � ST � � �

p " \" $ r% & 2 - +% , -. / ( 0 ( ' 7 (4 1 & & ( 01 0% 31 ) &% () - 31 ) 5 (

p " \" B �1 4 -)% & 3 ( & 01 0% 31 ) &% () - 31 ) 5 (

p " \" H b ) 0% 4 - 0 ( 7 01 0% 31 ) & J1 &

p " \" \ � -)% ' 2 + -. J1 & 0% 7 1 5 - &4 ( 3' +1 31 ) 5 - 7 1 & 01 0% 31 ) &% () - 31 ) 5 (

p " \" ! � -)% ' 2 + -. / ( 01 1 &4 - + -

l � � ` � � �X Y �

p " !#" $ r% & 2 - +% , -. / ( 0 ( ' 7 (4 1 & & ( 01 7 ( 5 -. / (

p " !#" B ^ ( 5 -. / ( 01 ( *Z 1 5 ( &

��

5HFRPHQGDo}HV� DGLFLRQDLV� SDUD� D�PDQLSXODomR�GLUHWD�GH�REMHWRV�GH�WH[WR��~ � � LM � O � � V � O � � � � W� X Y �

t " $ " $ � ( &% 4 % () - 31 ) 5 ( 0 (4 2 7 & ( 7 01 51 6 5 (

t " $ " B �1 +1 4 / ( -4 1 +1 7 - 0 - 01 ( *Z 1 5 ( & 01 51 6 5 (

~ � K d Q V � O Q � O � V � O � � R � ��

t " B " $ � -)% ' 2 + -. / ( 0% 7 1 5 - 01 - 57% * 2 5 ( & 0 ( � ;� ?� � 01 ' C] % ) -

t " B " B��

� -)% ' 2 + -. / ( 0% 7 1 5 - 01 - 57% * 2 5 ( & 0 ( 51 6 5 (��

96

��

5HFRPHQGDo}HV� DGLFLRQDLV� SDUD� D�PDQLSXODomR�GLUHWD GH�MDQHODV��

n � O Q R � � �X a� o � � � Q

v " $ " $ ��

� (G% 31 ) 5 -. / ( 0 ( 4 () 51 k 0 ( 01 2 3 - Z -) 1 + - 1 3 3 k + 5% ' + - &

2 )% 0 - 01 &

�v " $ " B��

� (G% 31 ) 5 -. / ( 0 (4 () 51 k 0 ( 01 2 3 - Z -) 1 + - - ' - 7 5% 7 01 * - 7 7 - &

01 7 ( + -] 1 3�� K LM � O � � V � O � � � � W� X Y �

v " B " $ ��

^1 - 7 7 -) Z ( 0 (4 () 51 k 0 ( G% & 2 - +% , - 0 ( 01 2 3 - Z -) 1 + - 01 -4 ( 7 0 (

4 ( 3 - &1 +1 . / ( 0 ( 2 & 2 C 7% (

v " B " B��

�% )% 3% , -. / ( 0 - 1 ) 57 - 0 - 01 0 - 0 ( & ' 1 + ( 2 & 2 C 7% ( �� _ d Q V � O Q � O � V � O � � R � T � O � W �

v " H " $ ��

� -)% ' 2 + -. / ( 0% 7 1 5 - 0 - & 0% 31 ) & J1 & 01 Z -) 1 + - &��v " H " B� I% 3% 51 & 3 F)% 3 ( 1 3 C 6% 3 ( 0 - & 0% 31 ) & J1 & 01 Z -) 1 + - & �

v " H " H��

� % 31 ) &% () - 31 ) 5 ( 01 - 5 - + E ( &��v " H " \�

�

� -)% ' 2 + -. / ( 01 1 &4 - + -

v " H " !��

� D1% 5 ( & 0 ( 0% 31 ) &% () - 31 ) 5 ( 01 2 3 - Z -) 1 + - & ( * 7 1 &1 2

4 () 51 k 0 (��

5HFRPHQGDo}HV� DGLFLRQDLV� SDUD� D�PDQLSXODomR�GLUHWD�GH�tFRQHV�GH�FRQWUROH�

� � � LM � O � � V � O � � � � W� X Y �

w " $ " $ ��

5% G -. / ( 01 F4 () 1 & 01 4 () 57 ( +1 ��w " $ " B�

�

b ) 0% 4 -. / ( 01 5% ' ( & 01 3 -)% ' 2 + -. / ( 0% 7 1 5 -��w " $ " H�

�

b ) 0% 4 -. / ( 01 5 - 7 1 D - & 0 ( 2 & 2 C 7% (��w " $ " \�

�

b ) 0% 4 -. / ( 01 0% &' ()% *% +% 0 - 01 ��w " $ " !�

�

�1 ' - 7 -. / ( 1 ) 57 1 &1 +1 . / ( 1 - 5% G -. / (��w " $ " p�

�

y & ( -' 7 (' 7% - 0 ( 01 4 () 57 ( +1 &��NOTA Usuários do ISO 9241-16 poderão reproduzir livremente esta lista de verificação, a fim de que ela possa ser utilizada para seu propósito primordial, podendo também publicar posteriormente a lista de verificação

preenchida.

97

I1] 1 ) 0 -

�

= Sim (se aplicável) �


= Análise da documentação do sistema �

= Evidência Documentada �

= Observação


= Avaliação Empírica ��

= Método Diferente

�

= Mensuração �

� Passou (atendeu à recomendação) �


98

$SrQGLFH��/LVWD�GH�YHULILFDomR�GD�DSOLFDELOLGDGH�H�DGRomR�GR�,62��/HJHQGD� Recomendação aplicada ou adotada e os métodos usados��

$SOLFDELOLGDGH� $GRomR� &RPHQWiULRV��LQFOXLQGR�IRQWHV��

��

� � ��

5HFRPHQGDo}HV�

� � � � � �� (VWUXWXUD�GR�SUHHQFKLPHQWR�GH�IRUPXOiULRV�� ! "#$ %& '

Formulários, caixas de diálogos, telas de entrada intituladas para indicar claramente a finalidade.

�� ( )& *+ ,+- ./ 0& 1+ '$ . %

Codificação visual distinta usada para descrever entradas do usuário, defaults e dados de entrada previamente.

�� 2 � 34 '+ * . * 3 .5 6 3 ' 34 # . * . 4 & ,& 67 $ % 8 6+ &

Densidade em geral de 40% (baseada no percentual do total disponível no formulário preenchido).

�� 9 : 4 ' # 6$ / ; 3 '

Instruções providas no display (ou facilmente acessado através de um help) para completar, salvar e transmitir no formulário.

�� < 3 6 . % * . 3 ' # 6$ #$ 6 .

Se o formulário é complexo, vista geral ou apresentação visual da estrutura fornecida

�� = > � ? @A B

99

�� ( � � .5 3 % * 3 & 6+C 3 7 *& *& - $ 7 34 # &

Se usado, a tela de diálogo do preenchimento do formulário deve ser consistente com o layout da origem do papel do documento.

�� ( � ( � 34 D$ 7 *& - $ 7 34 # & * 3 & 6+C 3 7

Campos de entrada agrupados por função, importância, etc. ou otimize a seqüência de entrada do ponto de vista do usuário

�� ( � 2 ) . 7 5 & ' 6 3E $ 3 6+ *& ' 3- . 7 5 & ' & 5 - + & 4 .+ '

Os campos requeridos são posicionados primeiro a menos que tal posicionamento seja inapropriado para a tarefa do usuário

�� ( � 9 %+ 4 D . 7 34 # & * 3- . 7 5 & . % , .4 $ 7 F 6+ - &

Se apropriado para o índice da linguagem, os campos de entrada devem ser alinhados verticalmente em colunas e justificados a esquerda

�� ( � � %+ 4 D . 7 34 # & * 3- . 7 5 & 4 $ 7 F 6+- &

Se os tamanhos dos campos são diferentes, justifique a direita. Se são decimais, alinhe no ponto decimal

�� ( � G H . %& 6 3 ' *& '- . 7 5 & ' 5 3 67 + # + *& '

Informação provida concerne com valores dos campos permitidos

�� ( � I ! . 7 .4 D& ' * 3 6 J #$ %& ' *+ , 3 6 34 # 3 '

Se campos de textos ou alfanuméricos são alinhados verticalmente em colunas e se os tamanhos das letras dos campos diferem significadamente e a tarefa envolve entrada de dados sequenciais, os textos devem ser justificados a direita e os campos a esquerda.

�� ( � K ! . 7 .4 D& * 3 6 J #$ %& ' '+ 7 + % . 6 3 '

Se campos de textos ou alfanuméricos são alinhados verticalmente em colunas e se os tamanhos das letras dos campos não diferem significadamente, ambos os textos e os campos devem ser justificados a esquerda.

�� ( � L � M % # + 5 % . ' + 4 ' # .4 - + . ' * 3$ 7 - . 7 5 &

Se o rótulo (texto) é usado por múltiplas instancias de um campo, o rótulo é localizado acima da coluna ou a direita da linha

100

�� ( � N � M % # + 5 % . ' 5 8C + 4 . '

a) Cada página identificada consistentemente no mesmo local do formulário b) Se o formulário é colunar, rótulos em colunas inseridos novamente.

�� O P � QR @S � � T BA � @S �� 2 � ) . 7 5 & ' * 3 # . 7 .4 D& ,+U &

Se os campos de entrada são de tamanho fixo, os tamanhos são explicitamente mostrados.

�� 2 � ( ) . 7 5 & ' * 3 34 # 6 . * . 6 3E $ 3 6+ *& ' 1 3 6 '$ ' & 5 - + & 4 .+ ' Usuários são facilmente capazes de distinguir entre campos requeridos e opcionais

�� 2 � 2V� ) . 7 5 & ' 7 & *+ ,+ - 8 1 3+ ' 1 3 6 '& ' 4 0& 7 & *+ ,+ - 8 1 3+ '

Usuários são facilmente capazes de distinguir entre campos modificáveis e não modificáveis.

�� 2 � 9 W J #$ %& ' * 3- . 7 5 & ' * 3 '- 6+ # + 1& '

Rótulos de campos claramente e de uma forma não ambígua descrevem dados a serem entrados

�� 2 � � W J #$ %& ' *+ ' # + 4 # & '

Palavras e/ou códigos distintos e consistentes usados para rótulos de campos

�� 2 � G X 4 + * . * 3 ' & $ ' "7 Y& %& '

Símbolos ou unidades apresentadas como um rótulo adicional

�� 2 � I �$ C 3 ' # ; 3 '

Sugestões para formato de entrada de dados (e.g. mm/dd/yy) mostrados dentro de uma campo de entrada ou em rótulos de campos e o uso de abreviações claras para o usuário

�� 2 � K Z 3 # 6 . 7 .+ M '- $ % . 5 . 6 . . 5 6+ 7 3+ 6 . % 3 # 6 . 4 & ' 6 J #$ %& ' *& '

- . 7 5 & '

Rótulos dos campos começam com letra maiúscula, seguida por letras minúsculas até o final do texto.

�� &RQVLGHUDo}HV�GH�HQWUDGD�� [\� � �� G � � �& 1+ 7 34 # & *& - $ 6 '& 6

A ação do usuário requer mover o cursor de um campo de entrada para o próximo minimizado

G � � ( ) . 7 5 & * 3 34 # 6 . * . * 3 # 3U # & + 4 - & 7 5 % 3 # &

Se a entrada não preenche o campo todo, é permitido que o usuário mova diretamente para o próximo campo.

101

H . %& 6 3 ' * 3 , .$ % # '

a) Campo contém valores default onde quer que possível e apropriado para a tarefa, e

G � � 2

b) Campos default de texto editáveis

G � � 9 % # 3 64 .4 *& 34 # 6 3 *+ ' 5 & '+ # + 1& ' * 3 34 # 6 . * .

Se apropriado para a tarefa, deve ser minimizado o trabalho de alternar entre dispositivos de entrada.

G � � � � + ' 5 & '+ # + 1& ' * 3 .5 & 4 # . 7 34 # &

Se um dispositivo de apontamento pode ser usado para entrada num formulário, ele deveria ser usado também para navegação

[\� = ]^ B �� _ � _� B� ` B @ S � � a� ^ A Q b � cd @S G � ( � e$ ' # + ,+ - ./ 0& * . ' 34 # 6 . * . '

O sistema justifica a entrada, não o usuário.

G � ( � ( )& 4 *$ / 0& f 3 6&

Se nenhuma condução é necessária para entrada numérica, o sistema deve provê-las.

G � ( � 2 � M % # + 5 % . ' %+ 4 D . '

Se o campo contém múltiplas linhas de texto (i.e. sentenças ou parágrafos): a) tamanho da área de entrada – o tamanho da área de entrada claramente indicada, e b) auto envolver – capacidade de se auto envolver, e c) editar e navegar – convenções normais.

G � ( � 9 ) . 7 5 & ' 3U - %$ '+ 1& ' 7 $ % #$ . 7 34 # 3

Sugestão visual indica só um dos campos ser usados por vez

G � ( � � W 3C 6 . ' * 3 + 4 # 3 6 * 35 34 * g4 - + .

O uso de complexas regras de interdependências do tipo if/then entre campos de entrada deve ser evitada

G � ( � G h 6 3 . *& - . 7 5 & * 3 34 # 6 . * . * 3 # 3U # &

Campos de texto grandes suficientes para acomodar a maioria das entradas sem rolagem

[\� O ]^ B �� _ � S _ � � S d @ �i � G � 2 � � 5 / ; 3 ' * 3 34 # 6 . * . %+ 7 + # . * . '

Mecanismo provê capacitar o usuário visualizar e selecionar as opções disponíveis

G � 2 � ( �$ C 3 ' # ; 3 ' 1+ '$ .+ ' *+ '- 6+ 7 + 4 . * . '

Sugestões visuais discriminadas usadas para discriminar entre diferentes tipos lógicos de escolhas de entrada na

102

aplicação G � 2 � 2 � 34 $ ' a) Sugestões visuais – uma sugestão visual que um

menu é associado com o campo é provido a menos que a lista de opções é continuamente visível.�

b) Valor do campo – O campo do formulário contém a mais recente seleção do menu como valor corrente.�

Z+ ' # . '

a) Sugestões visuais - Uma sugestão visual fornecida para discriminar selecionada de opções não selecionadas

G � 2 � 9

b) Listas longas – Um mecanismo provê permitir que usuários rapidamente naveguem através da lista.

G � 2 � � j& # ; 3 '

Os botões devem ser usados se os usuários selecionam um pequeno número de opções (2 a 5) e as opções são ativadas imediatamente depois da seleção

G � 2 � G j& # ; 3 ' * 3 3 '- & % D .

a) Conjunto de escolhas – Escolha exclusiva de botões aparecem em conjunto de 2 ou mais escolhas b) Escolha default – Se há um default para o campo, a escolha default deve estar visivelmente selecionada

)& 4 k$ 4 # & ' * 3 3 ' # . *& Y+ 4 8 6+ &

a) Apresentação do grupo – Botões de estado binário devem ser apresentados num grupo.

G � 2 � I

b) Indicação do estado – Quando o formulário é apresentado, botões de estado binário fornecem uma indicação visual de seu estado corrente.

j& # ; 3 ' * 3 ' %+ f .4 # 3 '

a) Escolha inicial – A escolha inicialmente mostrada deve ser a mais apropriada escolha default.

G � 2 � K

b) Modificar valores – Usuários permitidos modificar valores a fim de navegar rapidamente entre escolhas

[� l P @^ B � @ �� G � 9�� )& 6 6 3/ ; 3 ' .4 # 3 ' * 3 5 6& - 3 ' ' . 6

Deve ser permitido ao usuário iniciar a preencher novamente, cancelar entradas, ou mudar alguma entrada antes do formulário ser processado.

103

: * 34 # + ,+ - .4 *& 3 %& - . %+ f .4 *& 3 6 6& '

a) Se a validação indicar que o campo foi preenchido com erros, o cursor é colocado no primeiro campo do erro e ao usuário é permitido facilmente mover através dos campos com erro.

G � 9�� (

b) Se existem dependências entre campos, e se é apropriado para a tarefa, erros potenciais são indicados pelo sistema.

G � 9�� 2 W 3m 34 # 6 . * . * 3 * . *& '

Se o campo contém erros, o usuário não é requerido re-entrar com o dado correto.�

G � 9�� 9 h 6 3 . ' 4 0& *+ ' 5 & 4 " 1 3+ '

Áreas da tela não disponíveis para entrada do usuário, não acessável pelo usuário e visualmente codificado de acordo.

G � 9�� ! 6 .4 ' 7 + ' ' 0& , 8- + %

Transmissão dos campos de entrada realizada pelo significado de uma simples ação explícita.

G � 9�� G )& 4 # 6& % 3 *& $ '$ 8 6+ &

A menos que seja óbvio para o usuário, o formulário deve indicar como realizar as seguintes ações: sinalize a conclusão do formulário e apresente um formulário vazio para a entrada de dados novos; sinalize a conclusão do formulário e apresente a versão previamente terminada do formulário ou uma versão default do formulário; permita a saída do formulário sem mudar nenhuns dados no sistema (opção cancelar)

G � 9�� I � . % 1 3 # 3 7 5 & 6 . 6+ . 7 34 # 3

Se apropriado para a tarefa e as restrições do sistema permitam, uma função para salvar temporariamente deveria ser provida.

[\� � n � � c _ � o p @ _ @ d � QR @ G � �� H . %+ * ./ 0& *& - . 7 5 & '+ 7 5 % 3 '

Se a capacidade do sistema permite, os campos de entrada devem ser checados antes da aceitação.

G � �� ( H . %+ * ./ 0& * 3 7 M % # + 5 %& '- . 7 5 & '

Se dependência entre campos no formulário, ou entre campos com outra incidência no mesmo formulário, validação adicional deve ser checada.

�� )HHGEDFN��5HWRUQR�DR�XVXiULR��

104

I � �- & . 6

Caracteres digitados são ecoados para o usuário assim como foram digitados

I � ( )$ 6 '& 6 3 5 & '+ / 0& *& .5 & 4 # . *& 6

a) A ‘posição do cursor é claramente indicada visualmente, eb) Se o dispositivo de apontar está disponível, a posição do apontador deve estar claramente visível.

I � 2 � 6 6& ' 4 & '- . 7 5 & '

Se o campo contém erros e é apropriado para a tarefa, o feedback do erro deve ser mostrado assim que o usuário complete sua tarefa

I � 9 W 3- & 4 D 3- + 7 34 # & * . # 6 .4 ' 7 + ' ' 0&

O sistema provê um reconhecimento de que a entrada do formulário foi aceita pelo sistema

I � � �$ * .4 / . ' 4 & Y .4 - & * 3 * . *& '

Se o preenchimento do formulário faz mudanças no formulário, um feedback que o banco de dados tem sido atualizado é provido para o usuário.

�� 1DYHJDomR� K � �& '+ / 0& + 4 + - + . % *& - $ 6 '& 6

O cursor é posicionado automaticamente no primeiro campo do formulário que deve ser completado pelo usuário

K � ( �& 1+ 7 34 # & 34 # 6 3- . 7 5 & '

a) O usuário é provido com capacidade para mover o cursor para trás e para frente entre os campos do formulário dentro de um grupo, e se apropriado, mover para campos adjacentes em outros grupos b) Se um acesso rápido para especificar um campo requerido, um método de acesso é provido.

K � 2 W 3 # & 64 & .& - . 7 5 & + 4 + - + . %

Se é apropriado para a tarefa, uma chave ou um comando é provido para permitir que o usuário retorne para o campo inicial no formulário.

K � 9 ! . Y$ % . 6 K � 9�� ) . 7 5 & ' 5 6 3 34 - D+ *& ' 5 . 6- + . % 7 34 # 3

Um tabular manual para mover de um campo para outro.

K � 9�� ( ) . 7 5 & ' 5 6 3 34 - D+ *& '- & 7 5 % 3 # . 7 34 # 3

Auto-skip tabular de um campo para outro provido.

K � 9�� 2 5 6& U + 7 ./ ; 3 ' 7 + ' #$ 6 . * . '

105

As duas aproximações acima num dado não devem ser misturadas num dado preenchimento do formulário.

K � 9�� 9 ) . 7 5 & ' 7 $ % #$ . 7 34 # 3 3U - %$ '+ 1& '

Se campos multuamente exclusivos são presentes no formulário, saltar as opções restantes que não foram escolhidas.

K � 9�� 3/ ; 3 ' *& ,& 67 $ % 8 6+ &

Se o formulário é organizado em grupos (seções) com um determinado significado, usuários são providos com a capacidade de mover de um grupo para outro.

K � 9�� G )+ - %& ' * 3 6 3C + ' # 6& '

Se os dados são organizados em registros seqüenciais e o formulário representa uma visão dos dados de um registro, um mecanismo é provido para circular de um registro para outro, para frente e para trás.

K � 9�� I � + ' 5 & '+ # + 1& ' * 3 .5 & 4 # . 7 34 # & 3 ,& 67 $ % 8 6+ & ' 7 M % # + 5 %& '

Se um dispositivo de apontamento é usado para entrada as tarefas que invocam múltiplos formulários, um mecanismo para navegar entre formulários usando o dispositivo é provido.

K � � �- 6& % %+ 4 C q W& % .C 3 7 r

K � �� W& % .C 3 7 4 $ 7 - . 7 5 &

Se o tamanho máximo dos dados a serem apresentados num campo é maior que o campo, um mecanismo de scrolling é provido.

K � G � 3 % 3/ 0& 4 & ,& 67 $ % 8 6+ & K � G � - 3 ' '& *+ 6 3 # & .& ,& 67 $ % 8 6+ &

O usuário é capaz de endereçar formulários tanto pelo nome do formulário ou pela seleção de um menu.

K � G � ( �& 1+ 7 34 # & 34 # 6 3 ,& 67 $ % 8 6+ & '

Se o formulário pode ser acessado independentemente e se é apropriado para a tarefa, o usuário é capaz de mover de um formulário para outro para frente e para trás numa seqüência pré-definida.

K � G � 2 �& 1+ 7 34 # & 4 $ 7 4 " 1 3 % D+ 3 6 8 6E $ + - &

Se o conjunto de formulários é hierárquico, o usuário deve ser capaz de mover para o próximo nível mais alto e para o nível mais baixo na hierarquia.

K � G � 9 W 3 # & 64 .4 *& 5 . 6 . & ,& 67 $ % 8 6+ & + 4 + - + . %

106

Se o conjunto de formulários é hierárquico, o usuário deve ser capaz de voltar ao formulário inicial de qualquer um formulário na hierarquia.K � G � � �& 67 $ % 8 6+ & ' 4 $ 7 . 7 Y+ 34 # 3 * 3 k .4 3 k . '

Se mais de um formulário pode ser apresentado, somente o último selecionado está ativo e pronto para entradas do usuário.

K � G � G �& 67 $ % 8 6+ & * 3 , .$ % #

Se um formulário é mais provável ser usado, este formulário deve ser o inicial

Z 3C 34 * .s

�

= Sim (se aplicável)

�


= Análise da Documentação do Sistema �

= Evidência documentada �

= Observação


= Avaliação Empírica � �

= Método Diferente

�

= Mensuração �

= Passou (atendeu à recomendação) �


3URMHWRHLPSOHPHQWDomRGRPyGXOR7$26 *UDSK …docs.computacao.ufcg.edu.br/posgraduacao/disserta... ·...

Documents

Transcript of 3URMHWRHLPSOHPHQWDomRGRPyGXOR7$26 *UDSK …docs.computacao.ufcg.edu.br/posgraduacao/disserta... ·...