Post on 22-May-2020
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��������������������������������������������������������������������������
�����&RQVLGHUDo}HV�ILQDLV����������������������������������������������������������������������������������������������������
���$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���������������������������������������������������������������������������������������������
�����&RQVLGHUDo}HV�ILQDLV����������������������������������������������������������������������������������������������������
���(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(������������������������������������������������������������
�����&RQVLGHUDo}HV�ILQDLV����������������������������������������������������������������������������������������������������
���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 �����������������������������������������������������������������������������������������������
�����&RQVLGHUDo}HV�ILQDLV����������������������������������������������������������������������������������������������������
���,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
�����&RQVLGHUDo}HV�ILQDLV����������������������������������������������������������������������������������������������������
���&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
Apresentação Item menu
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³�´Atributos do
descritor Agente
Abstração
Apresentação Região
(Formulário)
µb¶�·q¸ ± ¹'º »*¼&½�¾�³�´Editar descrição
instrumento
µb¶�· ¸ ± ¹'º »*¼&½�¾�³�´Editar competência
µb¶�· ¸ ± ¹'º »*¼&½�¾�³�´Editar experiência
com a tarefa
µb¶�·q¸ ± ¹'º »*¼&½�¾�³�´Editar experiência com um sistema
equivelente
Apresentação Caixa de texto
µb¶,·q¸ ± ¹'º »*¼�½�¾�³�´Editar nome
agente
µb¶�· ¸ ± ¹'º »*¼&½�¾�³�´Editar 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
Apresentação Item menu
Abstração
Apresentação Caixa de
texto
Apresentação Item menu
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³�´Atributos do
descritor Agente
Abstração
Apresentação Região
(Formulário)
µb¶�· ¸ ± ¹'º »*¼&½�¾�³�´Editar descrição
instrumento
µ�¶�·q¸ ± ¹º »*¼�½�¾�³�´Editar competência
µ�¶�·q¸ ± ¹º »*¼�½�¾�³�´Editar experiência
com a tarefa
µb¶�· ¸ ± ¹'º »*¼&½�¾�³�´Editar experiência com um sistema
equivelente
Apresentação Caixa de texto
µb¶�·q¸ ± ¹'º »*¼&½�¾�³�´Editar nome
agente
µ�¶�·q¸ ± ¹º »*¼�½�¾�³�´Editar meios de
interação
Apresentação Caixa de texto
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) �
= 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)
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)
�
= 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)