34

Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Embed Size (px)

Citation preview

Page 1: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

O conte�udo do presente relat�orio �e de �unica responsabilidade do(s) autor(es).(The contents of this report are the sole responsibility of the author(s).)Interfaces Homem-Computador:Uma Primeira Introdu�c~aoF�abio Nogueira de [email protected] K.E. [email protected]�orio T�ecnico DCC{94-07Setembro de 1994

Page 2: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador:Uma Primeira Introdu�c~aoF�abio Nogueira de [email protected] Hans K.E. [email protected] Xchart�dcc/imecc/unicampCaixa Postal 606513081-970 Campinas/SP, Brazile-mail: [email protected]: http://www.dcc.unicamp.br/projects/XchartSum�arioUm destaque crescente tem sido dado �as interfaces homem-computador. Neste textos~ao apresentadas evidencias que justi�cam este fato. O conte�udo deste trabalho visaservir de leitura inicial sobre o assunto com enfase em aspectos computacionais. Maisespeci�camente, como o tema relaciona-se com a �area de engenharia de software. Noentanto, s~ao citadas contribui�c~oes de outras �areas para este t�opico multidisciplinar. S~aode�nidos alguns conceitos primordiais, apresentadas t�ecnicas, modelos, ciclo de vida eoutras quest~oes relevantes. Embora o texto seja sucinto, esperamos que a bibliogra�aapresentada indique outras fontes com mais informa�c~oes.1 Introdu�c~ao To users, the interface is the system.Hix and Hartson [34]Os primeiros computadores e softwares foram projetados por engenheiros para seremusados por engenheiros. Estes engenheiros, no entanto, n~ao formam um grupo representa-tivo da atual comunidade de usu�arios de sistemas interativos. O uso de computadores pelasociedade tem crescido continuamente. Em alguns casos s~ao \invis��veis" ao usu�ario como,por exemplo, na alimenta�c~ao eletronica de autom�oveis. Em outros, pessoas n~ao especia-lizadas em computa�c~ao est~ao usando diretamente computadores. Isto torna as interfaceshomem-computador (interfaces, por simplicidade) um elemento relevante na composi�c~ao deum sistema computacional.Antes de apresentar ind��cios para esta relevancia e como ela tem-se re etida no ambienteacademico e comercial, conv�em de�nir o que se entende por interface segundo a enfase destetexto.�Projeto que se concentra no desenvolvimento (especi�ca�c~ao e implementa�c~ao) de interfaces homem-computador. Por curiosidade: a 22a� letra do alfabeto grego (X e �) �e identi�cada em Ingles pela palavraCHI, que coincide com o acronimo de Computer-Human Interface.

Page 3: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

2 F�abio Lucena & Hans LiesenbergInterface: compreende todos os comportamentos do usu�ario e do computadorque s~ao observ�aveis externamente [9]. H�a uma linguagem de entrada, uma desa��da para re etir os resultados e um protocolo de intera�c~ao (veja a Figura 1).Observador externo

SISTEMA INTERATIVOUSUARIO Protocolo

Entrada

Saida

Interface Figura 1: O conceito de interface [9].Este conceito n~ao fornece a perspectiva totalmente apropriada aos nossos mais voltadospara aspectos relacionados com a �area de engenharia de software. Podemos estabelecer umoutro conceito de interfaces com uma de�ni�c~ao fundamentada em software. A de�ni�c~aoseguinte, ilustrada na Figura 2, fornece esta perspectiva.INTERFACE APLICACAO

Sistema InterativoFigura 2: Vis~ao simpli�cada de um sistema interativo.Interface (software): parte do software de um sistema interativo respons�avel portraduzir a�c~oes do usu�ario em ativa�c~oes das funcionalidades do sistema (aplica�c~ao),permitir que os resultados possam ser observados e coordenar esta intera�c~ao.Em outras palavras, a interface �e respons�avel pelo mapeamento das a�c~oes dousu�ario sobre dispositivos de entrada em pedidos de processamento fornecidospela aplica�c~ao, e pela apresenta�c~ao em forma adequada dos resultados produzidos.A Figura 2 mostra um modelo simpli�cado de sistemas interativos. Nesta �gura ocomponente aplica�c~ao �e o elemento respons�avel pela parte funcional (algor��tmica) do sis-

Page 4: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 3tema, ou seja, que transforma dados de entrada em dados de sa��da atrav�es da aplica�c~ao deuma fun�c~ao �a entrada. O componente interface equivale �a de�ni�c~ao fornecida acima. Asepara�c~ao entre estes componentes �e conhecida por independencia de di�alogo.O termo di�alogo geralmente �e empregado com a mesma acep�c~ao de interface. �E comumo uso de di�alogo como a comunica�c~ao existente entre o ser humano e o sistema de com-puta�c~ao, i.e., a troca de s��mbolos e a�c~oes entre o usu�ario e o computador. O termo interfacetamb�em �e comumente empregado como o software de suporte e hardware atrav�es do qualesta troca (di�alogo) ocorre. A acep�c~ao destes termos �e muito pr�oxima, ambos referem-sesomente �as entradas do usu�ario e ao processamento localizado dessas entradas, juntamentecom a apresenta�c~ao dos resultados produzidos pela aplica�c~ao. Por outro lado, excluem ocomponente encarregado da transforma�c~ao da entrada em sa��da. Esta fun�c~ao �e de interessedo componente computacional, denominado aplica�c~ao.A �area de intera�c~ao homem-computador envolve hardware, software, metodologias,t�ecnicas, ferramentas e v�arias �areas do conhecimento humano. Estes itens s~ao comenta-dos sucintamente. A literatura fornecida ao longo do texto pode ser utilizada para obterdetalhes mais espec���cos. Muitas referencias apresentam estes itens como elementos estan-ques, sem a vis~ao imprescind��vel do processo que os coloca em funcionamento durante odesenvolvimento de uma interface (ciclo de vida, m�etodos, t�ecnicas e ferramentas). Ten-tamos, al�em de fornecer uma vis~ao estanque de elementos da intera�c~ao entre homem ecomputador, apresentar a rela�c~ao entre eles e como empreg�a-los.Aconselhamos [34] para um bom entendimento acerca do processo de desenvolvimentode uma interface. Referencias que abrangem v�arios aspectos de interfaces em um s�o livros~ao [13, 31]. Embora este texto apresente informa�c~oes destiladas de diversas referencias,algumas fontes exerceram in uencia signi�cativa no conte�udo aqui apresentado. S~ao elas:[14, 30, 33] e [5]. [30] fornece uma vis~ao geral da �area. [5] enfatiza o desenvolvimento desoftware para interface.O que �e uma interface \amig�avel"?O termo amig�avel (user-friendly) �e comumente atribu��do a interfaces. Abaixo seguem al-gumas caracter��sticas presentes em sistemas onde a interface recebe este adjetivo.� Facilidade de usar e aprender. Embora seja auto-explicativo para os usu�arios, estetermo precisa de um signi�cado mais �util do que simplesmente \f�acil" para projetistas.Do ingles easy-to-learn e easy-to-use. Geralmente s~ao substitu��dos por user-friendlypara caracterizar uma \boa" interface. Habermann [24] sugere uma semantica paraeasy-to-learn e easy-to-use: (1) a interface �e invis��vel (o usu�ario pode concentrar-se nastarefas que necessita realizar); (2) �e previs��vel; (3) �e ex��vel e (4) as pessoas gostamdelas.� Taxa de erro m��nima. Em sistemas cr��ticos (nucleares, controle de tr�a�co a�ereo eoutros) di�cultar a ocorrencia de erros cometidos pelos usu�arios �e imprescind��vel.Conv�em relembrar que erros tamb�em afetam o desempenho dos usu�arios.� Recorda�c~ao r�apida. O usu�ario espor�adico, idealmente, n~ao deve ter que recorrer amanuais quando for usar o sistema.

Page 5: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

4 F�abio Lucena & Hans Liesenberg� Atrativo. Nem sempre o sistema mais poderoso �e preferido pelo usu�ario. O usu�ariopode selecionar um sistema em que seu desempenho �e inferior comparando com umoutro, mas com o qual se sente mais \confort�avel."Organiza�c~ao do TextoA Se�c~ao 4.1 descreve v�arias �areas que contribuem para o desenvolvimento de interfaces. ASe�c~ao 3 descreve atividades a serem realizadas durante o desenvolvimento de interfaces.No ciclo de vida de uma interface nota-se que seus primeiros est�agios sofrem forte in- uencia de outras �areas do conhecimento. A estes primeiros est�agios d�a-se o nome deprojeto. O projeto �e visto na Se�c~ao 4 e a implementa�c~ao na Se�c~ao 5. Considera�c~oes �naiss~ao feitas na Se�c~ao 9.2 Por que interfaces s~ao importantes?Newman e Sproull [56] h�a mais de uma d�ecada j�a descreviam a in uencia das interfacesno sucesso de sistemas interativos. Aprender a us�a-los geralmente implica em investimentorazo�avel de tempo. Uma boa interface torna a intera�c~ao com o sistema mais f�acil deaprender e usar, i.e., amig�avel (user-friendly). Em outras palavras, a interface pode in uirna produtividade do usu�ario, que nem sempre prefere um sistema com mais recursos oue�ciencia do ponto de vista computacional. Um exemplo real �e o coment�ario de Bill Gates,grande acionista da Microsoft, acerca da frusta�c~ao parcial do Word 2.0 [37]: merecemos aculpa por n~ao termos facilitado o seu aprendizado. No tocante aos recursos o produto erafant�astico, mas no que se refere a facilidades dos primeiros passos n~ao nos sa��mos muitobem.Reconhecendo o papel de destaque de uma interface em um sistema interativo, Curtisem [11] destaca v�arios projetos japoneses de longo prazo envolvendo investimentos consi-der�aveis. Todos com a aten�c~ao centralizada no desenvolvimento de interfaces. SegundoCurtis, uma vez atingida certa uniformidade na con�abilidade dos produtos, as interfacess~ao o pr�oximo passo para a distin�c~ao e vantagem comercial, o que justi�ca os investimentosjaponeses. O projeto japones Friend21, por exemplo, tem dura�c~ao estimada em seis anos,envolve, 14 grandes companhias e totaliza um investimento de 120 milh~oes de d�olares. Oprojeto acredita que no s�eculo XXI todas as pessoas estar~ao utilizando os computadores emsuas atividades di�arias [53]. Conforme [41], \gigantes" da computa�c~ao como a IBM, Micro-soft, Digital e Hewlett-Packard (HP) tamb�em tem dado grande enfase para as interfaces.O foco de aten�c~ao atualmente despendido com as interfaces possui uma linha simplesde justi�cativa:Primeiro. O uso de computadores tem crescido continuamente. Preve-se que praticamentetodo ser humano ir�a utilizar computadores no futuro de uma ou de outra forma.Segundo. O mercado temmostrado que, nas vendas entre produtos similares, sobressai o quemelhor permite o acesso do usu�ario �a funcionalidade fornecida pelo sistema. Conv�emressaltar que em alguns casos a funcionalidade e o desempenho n~ao s~ao su�cientes

Page 6: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 5para agradar o usu�ario, que faz op�c~ao por outro sistema com interface atrativa. Ouseja, se um produto deseja ser competitivo, necessariamente sua interface deve serconsiderada de forma s�eria.Conclus~ao. O mercado para sistemas interativos caminha para uma popularidade equiva-lente �a dos televisores atualmente. Acredita-se que a distin�c~ao entre produtos dar-se-�apela interface. Isto torna compreens��vel a crescente quantidade de esfor�cos nesta �area.Ainda mais, estes esfor�cos j�a mostraram que, como veremos ao longo do texto, h�amuito o que fazer pelo desenvolvimento complexo e dif��cil das interfaces.Em [3] �ca evidenciada a importancia e o custo elevado das interfaces, que chegama ser grande parte do c�odigo de um sistema interativo. Em [5, p�ag. v] a�rma-se que ainterface consome at�e 70% dos custos totais do ciclo de vida de um sistema interativo. Em[6] �e relatado que para um sistema especialista poder-se-ia esperar que a maior parte dec�odigo fosse devotada �a base de conhecimento e �a m�aquina de inferencia. Entretanto, abase de conhecimento e a m�aquina de inferencia equivalem a apenas um ter�co do sistema.A interface �e a maior parte do sistema, cerca de 42% do c�odigo. Esta n~ao �e uma situa�c~aoat��pica. Outros sistemas apresentam propor�c~oes similares.Em recente pesquisa sobre dezenas de projetos [54], veri�ca-se que em m�edia 48% doc�odigo de um sistema interativo �e dedicado �a interface. Quanto ao tempo total de desen-volvimento, aquele consumido na interface equivale a 48% do tempo de projeto de todo osistema, 50% de toda a implementa�c~ao e 37% da manuten�c~ao.Ainda conv�em ressaltar que o pre�co de software tem-se tornado cada vez mais signi�ca-tivo com a queda do pre�co de hardware. Uma vez adquirido um sistema (hardware + soft-ware) ainda h�a custos envolvidos com o treinamento e uso di�ario por parte dos usu�arios. Aintera�c~ao com o sistema inclui, muitas vezes, o consumo de tempo desnecess�ario de opera�c~aose realizada de forma inadequada, ou ainda na corre�c~ao de erros freq:uentemente cometidospelos usu�arios. Estes custos devem estar envolvidos em uma an�alise custo/benef��cio no de-senvolvimento de uma interface amig�avel. Conforme [53], economias da ordem de milh~oesde d�olares podem ser realizadas em interfaces onde o usu�ario comete poucos erros, o tempode descri�c~ao das tarefas a serem realizadas �e m��nimo, a distra�c~ao do usu�ario �e reduzida e ostreinamentos s~ao eliminados. Ou seja, a interface interfere economicamente na utiliza�c~aode um sistema.A qualidade da interface tem grande in uencia no sucesso comercial de um software.Os melhores sistemas de hardware e software podem se tornar ine�cazes devido a umainterface impr�opria com o usu�ario [55]. En�m, sistemas interativos com boas interfaces s~aopreferidos �aqueles que apresentam barreiras quanto ao seu uso ou aprendizado. Infelizmenteo desenvolvimento de boas interfaces �e uma atividade que apresenta v�arios desa�os [53].Muito trabalho tem sido realizado visando a constru�c~ao de boas interfaces a baixo custo.Este texto privilegia aspectos computacionais (engenharia de software) de uma interfaceressaltando o seu desenvolvimento.Os itens abaixo enfatizam alguns pontos que motivam trabalhos nesta �area:1. O custo de um sistema computacional n~ao se limita a hardware + software. �E pre-ciso treinar usu�arios. Quanto mais dif��cil de aprender mais oneroso �e o treinamento

Page 7: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

6 F�abio Lucena & Hans Liesenberge quanto mais dif��cil de usar, menor �e o desempenho do usu�ario atrav�es de errosconstantes, lentid~ao de opera�c~ao do sistema e outros.2. Softwares que apresentam di�culdades como as acima citadas tendem a ser rejeitadospelos usu�arios. Comercialmente, o sucesso de vendas de software interativos est�aintimamente relacionado �a facilidade de uso e aprendizado do produto, adjetivos queacompanham praticamente toda propaganda de software hoje em dia.3. Riscos fatais e implica�c~oes em sistemas cr��ticos. Foi parcialmente atribu��do a inter-face homem-computador a inabilidade do ex�ercito americano no combate dos m��sseisExocet iraquianos. A implementa�c~ao errada de uma interface matou v�arias pessoasde doses excessivas de radia�c~ao, parcialmente em decorrencia de erro no c�odigo demanipula�c~ao do cursor no Therac-25. Myers [53] comenta em mais detalhes e citareferencias sobre estes e outros casos.4. O desenvolvimento de interfaces �e um processo caro, dif��cil, demanda tempo e queainda h�a muito a ser empreendido. Ao longo do texto h�a informa�c~oes que tornammais palp�aveis estas caracter��sticas.5. Por �ultimo, todos estes itens tornam-se problemas cujas solu�c~oes s~ao desej�aveis, poiso n�umero de usu�arios de computadores est�a se expandindo e com ele a demanda porsistemas interativos. As vendas, a descri�c~ao adequada e correta de tarefas, e inclusivea seguran�ca de tais sistemas s~ao in uenciados pela interface, que consome 50% dosrecursos de desenvolvimento de um sistema.Conseq:uenciasH�a v�arios indicadores que, n~ao oriundos apenas em ambiente academico, refor�cam o cres-cimento desta �area. Informa�c~oes sobre livros, peri�odicos, grupos de interesse espec���co eoutros s~ao apresentados na Se�c~ao 8.1. Peri�odicos espec���cos ou pertinentes:(a) ACM SIGCHI Bulletin.(b) ACM TOCHI.(c) ACM Interactions.(d) Human-Computer Interactions (jornal).(e) International Journal of Human-Computer Interaction.(f) Interacting with Computers.(g) Behaviour and Information Technology (jornal).(h) International Journal of Man-Machine Studies.2. Conferencias espec���cas ou que apresentam trabalhos desta �area:(a) ACM User Interface Software Technology.

Page 8: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 7(b) ACM SIGCHI { Human Factors in Computing Systems.(c) Human Factors Society (encontro anual).(d) Computer Supported Cooperative Work.(e) IFIP INTERACT.(f) International Conference on Human-Computer Interaction(g) ACM SIGGRAPH(h) British Computer Society HCI: Human-Computer Interaction.(i) Eletronicas:i. netnews: comp.human-factorsii. netnews: comp.cog-engiii. internet: [email protected] (Administra�c~ao: [email protected]).3. A ACM/IEEE incluem a disciplina de intera�c~ao homem-computador na grade curri-cular da gradua�c~ao recomendada por estas entidades.4. Grandes projetos est~ao em desenvolvimento no Jap~ao e outros em empresas como aIBM, Microsoft e HP, essencialmente voltados para o desenvolvimento de interfaces.3 Desenvolvimento de interfacesBecause even the best usability experts cannot design perfectuser interfaces in a single attempt, interface designers should builda usability-engineering life cycle around the concept of iteration.Nielsen [57]Esta se�c~ao fornece v�arios fundamentos necess�arios �a constru�c~ao de interfaces. Primeiros~ao elucidados alguns termos do ambito de engenharia de software. A engenharia de soft-ware estabelece algumas qualidades desej�aveis a serem atingidas por um software (corre�c~ao,con�abilidade, robustez, facilidade de manuten�c~ao e outras) e um conjunto de princ��pios(modularidade, abstra�c~ao e outros) que buscam, quando seguidos, atingir estas qualidades[21]. Para aplicar princ��pios, o engenheiro de software deve estar equipado com t�ecnicasapropriadas. T�ecnicas podem ser agrupadas formando uma metodologia. O objetivo de umametodologia �e permitir o desenvolvimento sistem�atico de uma classe de sistemas atrav�es deuma abordagem ou modelo de solu�c~ao para esta classe de sistemas. Ferramentas, por suavez, s~ao desenvolvidas para dar suporte �a aplica�c~ao de t�ecnicas, m�etodos e metodologias.M�etodos s~ao regras gerais que governam a execu�c~ao de alguma atividade; s~ao abordagenssistem�aticas e disciplinadas. T�ecnicas s~ao atividades mais mecanicas. Engenharia de soft-ware para interfaces pode ser obtida em [15].O desenvolvimento de interfaces �e um processo iterativo, que requer o projeto seguido dealguma forma de avalia�c~ao que realimenta o pr�oprio projeto. Vers~oes de projeto re�nadasa cada teste com os usu�arios podem substancialmente melhorar a intera�c~ao com o sistema[57]. O projeto pode ser in uenciado por padr~oes, guidelines, experiencia com outrossistemas e pelos pr�oprios requisitos do sistema. Esta atividade produz uma especi�ca�c~ao que

Page 9: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

8 F�abio Lucena & Hans Liesenbergpode ser utilizada para a implementa�c~ao ou um modelo formal. O emprego de um modeloformal permite que a interface em desenvolvimento possa ser avaliada sem a necessidade deimplement�a-la. A implementa�c~ao pode envolver a constru�c~ao de todo o sistema, partedo sistema, ou ainda a constru�c~ao de um prot�otipo. A avalia�c~ao pode ser feita sobre umum modelo formal ou sobre a implementa�c~ao do projeto. Note-se que apenas parte doprojeto pode ser implementado para avalia�c~ao. A cita�c~ao no in��cio desta se�c~ao justi�ca anecessidade desta etapa.Uma an�alise de v�arias abordagens para o projeto e implementa�c~ao de interfaces podeser vista em [12]. Quanto ao ciclo de vida da Figura 3, conv�em ressaltar que modelosmais tradicionais como o Waterfall (cascata) n~ao s~ao apropriados. A suposi�c~ao de que asatividades envolvidas ocorrem de forma linear n~ao �e v�alida. Conforme [25], a interface poden~ao estar bem de�nida at�e poucos instantes antes da instala�c~ao de um sistema interativo!Em [28] �e apresentado outro ciclo de vida para o desenvolvimento de interfaces exibido naFigura 4. O relacionamento entre nota�c~oes, ferramentas e abordagens para o projeto deinterfaces e os m�etodos tradicionais para desenvolvimento de sistemas �e comentado em [70].PROJETO

IMPLEMENTACAO

AVALIACAO

GuidelinesExperiencia

Requisitos

Standards

Especificacao

Prototipo / Sistema

ModelosFormais

Stds

GuidelinesReqs

Avaliacao

Figura 3: Ciclo de vida de desenvolvimento de interface [59].4 ProjetoDe�nir projeto (design) n~ao �e uma tarefa simples. Em essencia, projeto �e a descri�c~aode um objeto a partir da qual ele pode ser constru��do. Ou ainda um planejamento deuma constru�c~ao. Note que projeto �e comumente empregado ora como \processo" ora como\produto." No entanto, em ambos os casos referem-se a algo obtido antes do in��cio daconfec�c~ao de um produto. Antes que uma ponte seja constru��da �e necess�ario que um projeto

Page 10: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 9IMPLEMENTACAO

AVALIACAO

PROTOTIPO

ANALISE DE TAREFAS

REQUISITOS

PROJETO CONCEITUALFigura 4: Ciclo de vida estrela [28].correspondente seja realizado e avaliado. Pequenos empreendimentos podem ser realizadossem a descri�c~ao expl��cita de um projeto, ou seja, eles podem ser confeccionados a medidaque s~ao \imaginados." Outros, no entanto, n~ao permitem esta abordagem em decorrenciados custos envolvidos na elimina�c~ao de falhas. Corrigir um erro seria caro, quando n~aoimposs��vel. Por outro lado, corrigir modelos e especi�ca�c~oes �e uma atividade bem menosonerosa do que os seus efeitos correspondentes sobre objetos reais. Por exemplo, com l�apise borracha pode-se reposicionar o bot~ao liga/desliga do controle remoto de uma televis~ao,aumentar ou abaixar a altura de uma ponte, ou ainda corrigir a sua dire�c~ao em alguns graussem grandes di�culdades. No entanto, as conseq:uencias destas mudan�cas sobre tais objetosem constru�c~ao ou j�a acabados s~ao claramente bem mais onerosas.A constru�c~ao de interfaces ainda n~ao possui um padr~ao de desenvolvimento sistem�aticoque possa ser aplicado com sucesso garantido. De�nir uma interface com a qual o usu�ario ir�ainteragir e, paulatinamente, re�nar esta de�ni�c~ao atrav�es da avalia�c~ao de prot�otipos/modelosformais at�e a obten�c~ao de um projeto satisfat�orio �e uma necessidade. S�o ent~ao tem-se in��cioa implementa�c~ao. A implementa�c~ao pode ainda revelar di�culdades que n~ao foram ade-quadamente contempladas no projeto e, neste caso, novamente o projeto �e realimentadocom novos dados, modi�cado e a implementa�c~ao tem prosseguimento. A Figura 3 ilustraesta evolu�c~ao. Note que avalia�c~ao e itera�c~ao s~ao tamb�em caracter��sticas no ciclo de de vidaestrela da Figura 4.O projeto de uma interface �e equivalente a descri�c~ao do look and feel da interface.Look and Feel compreende a aparencia e dinamica de intera�c~ao de uma interface. UmLook and Feel pode ser empregado por diferentes toolkits em diferentes plataformas, for-necendo a mesma aparencia e comportamento para os usu�arios. Uma extensa e did�aticadiscuss~ao sobre projeto �e [4, 43]. Outras referencias recomendadas incluem [7, 18, 71].

Page 11: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

10 F�abio Lucena & Hans LiesenbergProjeto: de�ne o comportamento e a apresenta�c~ao de uma interface. A execu�c~aodo projeto utiliza-se de psicologia, fatores humanos, tecnologia dos dispositivosde entrada e sa��da, tipos de di�alogos, an�alise de tarefas, princ��pios, guidelines,padr~oes, regras, prot�otipos e avalia�c~ao de sistemas existentes. O resultado doprojeto �e a especi�ca�c~ao do projeto, geralmente atrav�es de especi�ca�c~oes formais,prot�otipos ou ainda documentos informais.4.1 Uma atividade multidisciplinarO projeto de uma interface envolve o conhecimento de distintas especialidades. Em geral, noentanto, sistemas s~ao concebidos sem a presen�ca de especialistas pertinentes a estas �areas e,em alguns casos, o conhecimento destas �areas �e aplicado por especialistas em computa�c~ao.Conforme [14], projetos desenvolvidos sem os conhecimentos de v�arias �areas, necess�arios auma interface em particular, fazem uso da capacidade de adapta�c~ao do ser humano paracompensar suas de�ciencias. Em [14] cada uma das �areas abaixo, relevantes para a de�ni�c~aoe o estudo de interfaces, �e comentada em mais detalhes.�Areas de estudo relevantes para a intera�c~ao homem-computador:� Ciencia da Computa�c~ao. Fornece a estrutura tecnol�ogica para facilitar o projeto eimplementa�c~ao de interfaces. Interface �e considerada neste texto da perspectiva destaciencia.� Psicologia. Preocupa-se com o entendimento do comportamento humano, percep�c~ao,cogni�c~ao e outros. A psicologia permite derivar m�etodos para auxiliar o usu�ario hu-mano nas suas atividades. O n�umero m�agico 7 +=� 2 [47] e a raz~ao �aurea s~ao algunsexemplos. Em [19, 20] �e destacada a in uencia positiva de objetos de intera�c~ao queapresentam a raz~ao �aurea.� Ergonomia. Envolve-se com aspectos f��sicos da adapta�c~ao das m�aquinas para usohumano. Por exemplo, formatos de dispositivos f��sicos de intera�c~ao s~ao de interessedesta �area.� Ling:u��stica. A intera�c~ao homem-computador exige uma linguagem. Ling:u��stica �e oestudo da linguagem. A teoria de linguagens formais compartilha formalismos coma ciencia da computa�c~ao que s~ao amplamente utilizados na especi�ca�c~ao formal dedi�alogos. Lex (gerador de analisador l�exico) e Yacc (gerador de analisador sint�atico)s~ao ferramentas do ambiente UNIX utilizadas na implementa�c~ao de interfaces [54].� Sociologia. Neste contexto a sociologia preocupa-se com o impacto dos sistemas inte-rativos na estrutura da sociedade.Groupware applications,1 por exemplo, bene�ciam-se das teorias sociais [16].1Sistemas que d~ao suporte �a grupos de pessoas envolvidas com a realiza�c~ao de uma tarefa comum e quefornecem uma interface para um ambiente compartilhado.

Page 12: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 11� Desenho gr�a�co e tipogra�a. A habilidade est�etica dessas �areas �e importante a medidaque a apresenta�c~ao da interface torna-se \bonita" aos olhos dos usu�arios.N~ao �e esperado que um �unico indiv��duo (projetista) possua conhecimentos em todasestas �areas. Uma alternativa mais real��stica �e ter uma \consciencia" (awareness, n��vel deentendimento) acerca das �areas, combinada com especialistas em uma ou outra �area. Esten��vel de entendimento �e particularmente essencial para os especialistas em computa�c~aoque ter~ao que desenvolver projetos de interfaces. O n��vel de entendimento fornece apenasdiretivas (guidelines) para o projetista e n~ao �e su�ciente para assegurar uma interface dealta qualidade, que requer um projeto mais rigoroso e avalia�c~ao realizados com os m�etodospertinentes a cada �area.Por �m, conv�em ressaltar que o conhecimento dos especialistas em computa�c~ao no pro-jeto de interfaces �e limitado. Em outras palavras, a forma�c~ao b�asica t��pica deste pro�ssionaln~ao contempla todos os conhecimentos necess�arios para o desenvolvimento desta atividade.Seja pelo car�ater multidisciplinar ou ainda pela fal�acia da intui�c~ao egocentrica. Esta fal�aciarefere-se �a ilus~ao de que se conhece o que determina o comportamento e satisfa�c~ao dousu�ario. Conforme [42], mesmo quando um sistema �e obviamente \dif��cil" a intui�c~ao poden~ao revelar as verdadeiras raz~oes. O melhor �e, sempre que poss��vel, permitir que o especi-alista adequado desenvolva a atividade que lhe compete.4.2 Executando o projetoOs projetistas tentam satisfazer os requisitos humanos de uma sistema interativo atrav�es doprojeto da interface, que envolve a aplica�c~ao de conhecimentos de v�arias �areas (veja Se�c~ao4.1). Doravante s~ao comentadas as v�arias entradas, i.e., informa�c~oes que s~ao utilizadasdurante a realiza�c~ao do projeto de uma interface e o resultado do projeto (especi�ca�c~oes).A Figura 3 (p�ag. 8) descreve o uxo de tais informa�c~oes ao longo do desenvolvimento deuma interface.An�alise de tarefasA an�alise de tarefas (veja [14, cap. 5] acerca de um m�etodo para esta an�alise) �e uma impor-tante etapa nos primeiros est�agios de um projeto. Esta an�alise permite obter informa�c~oesque substituem aquelas oriundas da intui�c~ao do projetista acerca de tarefas e como aspessoas executam estas tarefas em um dom��nio particular.PsicologiaInterfaces devem estar em conformidade com as capacidades e limita�c~oes humanas. Istocompreende a forma como os seres humanos processam informa�c~oes, sensa�c~ao, percep�c~ao,aten�c~ao, desempenho, aprendizado e mem�oria.Princ��pios, padr~oes, guidelines e regrasPrinc��pios s~ao metas gerais que podem ser �uteis �a organiza�c~ao de um projeto. Princ��pios, noentanto, n~ao especi�cam m�etodos atrav�es dos quais podem ser obtidos de forma sistem�atica.

Page 13: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

12 F�abio Lucena & Hans LiesenbergGuidelines s~ao regras gerais a serem seguidas durante o projeto. Padr~oes compreendemprinc��pios, regras e guidelines que devem ser seguidos por for�ca de mercado ou \padr~oes"como Windows, IBM CUA e outros.Abaixo seguem alguns princ��pios de projeto geralmente empregados. Embora em [64]seja feita referencia a \regras de ouro" para denominar esta lista, nada assegura que estesprinc��pios conduzir~ao a uma \boa" interface [48, 50]. Russell et al. [61] citam situa�c~oesem que se tem con itos entre eles. Em [14] �e a�rmado que contra-exemplos podem serestabelecidos para cada princ��pio. Em [69] h�a uma extensa lista de diretivas (guidelines)para auxiliar o projetista de uma interface durante a atividade de projeto. Outra referenciasobre este assunto �e [18, p�ags. 391-414].� Consistencia. O di�alogo deve seguir regras simples e n~ao apresentar casos especiaisou exce�c~oes para opera�c~oes similares.� Retroalimenta�c~ao (feedback). A�c~oes do usu�ario devem gerar uma retroalimenta�c~ao.Geralmente isto �e obtido atrav�es de representa�c~oes visuais que re etem, constante-mente, o estado interno do sistema e, por conseguinte, suas altera�c~oes.� Minimizar possibilidades de erro. Deve ser fornecido ao usu�ario somente os comandospass��veis de serem executados no instante da intera�c~ao. Se uma opera�c~ao n~ao podeser disparada ent~ao n~ao deve ser acess��vel.� Fornecer um meio de recupera�c~ao de erros. Entre opera�c~oes desej�aveis em uma inter-face comum podemos citar: refazer um contexto anterior a execu�c~ao de um comando(undo), cancelar, interromper ou substituir um dado fornecido ou comando. Semestas opera�c~oes a di�culdade de corrigir um erro pode ser inaceit�avel, ou inibir aexperimenta�c~ao por parte dos usu�arios.� Tratar adequadamente usu�arios com habilidades diferentes. Alguns sistemas s~ao usa-dos por uma grande variedade de pessoas, desde novatos at�e especialistas. A cada umdestes grupos deve estar dispon��vel um di�alogo apropriado.� Minimizar a necessidade de memoriza�c~ao. Quanto menos mem�oria for exigida melhora aceita�c~ao. Menus e form-�ll s~ao estilos utilizados com esta �nalidade.� Met�aforas. Visam reduzir barreiras da intera�c~ao utilizando a�c~oes, procedimentos econceitos familiares ao usu�ario. Detalhes sobre met�aforas podem ser obtidos em [8].Dispositivos de entrada e sa��daDispositivos de entrada (p.ex., teclado, mouse) e sa��da (p.ex., impressora, tela) conectam os\sentidos" humanos aos canais utilizados pelo computador para comunica�c~ao com o meioexterno. O projetista deve conhecer as tecnologias dispon��veis e quando empreg�a-las.

Page 14: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 13Estilos de intera�c~aoEstilo refere-se �a forma atrav�es da qual ocorre a intera�c~ao com o computador. Em ge-ral, v�arios estilos est~ao presentes em uma mesma interface. Abaixo s~ao comentados v�ariosestilos. Detalhes podem ser obtidos em [18] e [64]. Manipula�c~ao direta �e um dos maisso�sticados e muitas pesquisas tem sido realizadas em busca de t�ecnicas adequadas paraespeci�c�a-lo adequadamente [17, 32, 39]. O projetista deve saber empregar adequadamenteos v�arios estilos de intera�c~ao. Vantagens e desvantagens de v�arios estilos podem ser en-contradas em [14]. Uma abordagem para a implementa�c~ao de uma interface em que v�ariosestilos de intera�c~ao coexistem e o usu�ario pode alternar entre eles durante a \descri�c~ao" deuma mesma tarefa �e apresentada em [40]. Outros estilos de intera�c~ao (p.ex., dataglove) s~aocomentados em [74].� WYSIWYG. Uma interface WYSIWYG (What You See Is What You Get) permite aousu�ario observar na tela o resultado do processamento, ou seja, a sa��da. Por exemplo,um editor de texto WYSIWYG mostra na tela o que ser�a impresso antes que o usu�arioobtenha a impress~ao.� Linguagem de comandos. Meio de intera�c~ao tradicional em que o usu�ario fornece, viateclado, uma seq:uencia de caracteres correspondentes a entrada.� Linguagem natural. Extens~ao do caso anterior onde o usu�ario n~ao est�a limitado a umvocabul�ario ex��guo de palavras e sintaxe r��gida.� Manipula�c~ao direta. Este termo est�a associado a algumas id�eias centrais [63]: (1)visibilidade do objeto de interesse; (2) a�c~oes r�apidas e revers��veis; (3) visualiza�c~aoimediata do resultado, e (4) substitui�c~ao de estilos de intera�c~ao como linguagem decomandos e menus pela manipula�c~ao direta do objeto de interesse. Em outras pala-vras, permite que o usu�ario manipule, geralmente com o uso do mouse, representa�c~oesda realidade.� Demonstracional. Do ingles demonstrational. Estilo no qual o usu�ario pode usarexemplos, fornecidos atrav�es de manipula�c~ao direta, para especi�car opera�c~oes abs-tratas [51]. O sistema usa inferencias para \sugerir" generaliza�c~oes. Por exemplo, emuma interface demonstracional na segunda vez que o usu�ario \arrasta" um arquivocom extens~ao .bak at�e uma lata de lixo, imediatamente o sistema conclui que pro-vavelmente o usu�ario deseja remover todos os arquivos com esta extens~ao. Antes derealizar esta opera�c~ao, no entanto, esta \inferencia" �e con�rmada com o usu�ario.� Iconico. �Icone �e um s��mbolo gr�a�co que apresenta uma rela�c~ao de semelhan�ca ouanalogia com um objeto, propriedade ou a�c~ao. Em interfaces iconicas conceitos s~aoligados a ��cones e acionados atrav�es do mouse.� Menus. Menu �e uma lista de op�c~oes dispostas em uma coluna. Reduz a necessidade dememoriza�c~ao e limita o conjunto de op�c~oes. H�a v�arias formas de apresenta�c~ao de ummenu. Os menus pie (menus circulares), por exemplo, permitem a mesma facilidadede acesso a todos os itens [35], o que n~ao �e poss��vel com os menus tradicionais.

Page 15: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

14 F�abio Lucena & Hans Liesenberg� Form �ll-in. Estilo adequado para a entrada de dados composta por v�arios campos.Pode-se alternar entre campos, identi�cados por r�otulos, e fornecer a entrada emqualquer ordem.Prot�otiposA complexidade das interfaces e o conhecimento ainda insatisfat�orio acerca de como cons-truir interfaces obriga validar decis~oes de projeto. Geralmente isto �e feito atrav�es da cons-tru�c~ao de prot�otipos que re etem de leiaute de tela e sintaxe de comandos. As ferramentasutilizadas para construir prot�otipos n~ao s~ao �uteis, em geral, para a implementa�c~ao. T�ecnicaspara a constru�c~ao r�apida de prot�otipos por projetistas s~ao descritas em [73].O projeto de uma interface, geralmente, dura semanas at�e que algum resultado possaser apresentado ao usu�ario. Uma forma alternativa de construir prot�otipos em pouco tempode projeto �e apresentada em [60]. Nesta abordagem, em vez das tradicionais ferramentaspara confec�c~ao de prot�otipos �e utilizado papel, canetas coloridas e outros materiais t��picosde um escrit�orio. A caracter��stica principal desta abordagem est�a na rapidez em que ousu�ario pode ter contato com um prot�otipo. Tradicionalmente os prot�otipos levam maistempo para serem constru��dos e modi�cados. Usando esta t�ecnica, em pouco tempo podemser desenhados menus, telas, bot~oes e caixas de di�alogo. Todos estes desenhos podem serutilizados durante uma execu�c~ao simulada da interface projetada utilizando estes materiais.As vantagens, neste caso, residem na pouca resistencia a altera�c~oes no projeto e a devidaaten�c~ao dada aos aspectos mais relevantes, em detrimento de cores, formato de letras eoutros que s~ao, pelo pr�oprio processo de confec�c~ao, eliminados.Especi�ca�c~oes de projeto (produto)Em geral o projeto �e documentado atrav�es de uma combina�c~ao de �guras, prot�otipos, des-cri�c~ao em linguagem natural ou mesmo atrav�es de linguagens formais. Por exemplo, anota�c~ao UAN foi desenvolvida especi�camente para esta �nalidade [29]. Outras exemploss~ao [25, 38, 39, 67]. Este t�opico est�a intimamente relacionado aos UIMSs (veja Se�c~ao 5.2),pois estes sistemas, em geral, aceitam especi�ca�c~oes em linguagens que podem ser execu-tadas pelos mesmos e automaticamente geram a interface correspondente. Um tratamentoextenso sobre este assunto pode ser obtido em [52].5 Implementa�c~aoA implementa�c~ao de uma interface �e uma tarefa dif��cil [53, 68]. Entre as di�culdades:1. Projeto iterativo. N~ao h�a \regras de ouro" para o projeto de interfaces. Em con-seq:uencia, o c�odigo �e freq:uentemente modi�cado at�e que resultados satisfat�oriospossam ser obtidos [15]. Logo este c�odigo deve ser escrito de tal forma que possa sermodi�cado facilmente e, se poss��vel, sem afetar outras partes do sistema.

Page 16: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 152. Apresenta�c~ao atrativa. Usar os pacotes gr�a�cos e bibliotecas dispon��veis na confec�c~aode interfaces gr�a�cas n~ao �e uma tarefa trivial. Obter um resultado satisfat�orio podeser um desa�o.3. Entrada ass��ncrona. As interfaces que empregam o estilo de manipula�c~ao s~ao gui-adas pelas a�c~oes dos usu�arios, que podem ocorrer a qualquer momento. Torna-senecess�ario o emprego do controle externo que �e uma estrutura de software diferentedos programas convencionais.No processo de desenvolvimento o programador deve fazer distin�c~ao entre opera�c~oes deinteresse da interface daquelas da aplica�c~ao e determinar a intera�c~ao entre a aplica�c~aoe a interface. Uma decis~ao a ser tomada �e a fonte de controle. Na Figura 5 vemos duasalternativas. Em aplica�c~oes tradicionais o controle reside na aplica�c~ao. Em termosde programa�c~ao, o controle (thread) est�a na aplica�c~ao. Uma alternativa �e colocar ocontrole na interface, como �e o caso de muitas interfaces produzidas com o uso deferramentas. Neste caso a interface transfere o controle para rotinas da aplica�c~ao emresposta �as a�c~oes dos usu�arios na forma de callbacks. Do ponto de vista da interfacea aplica�c~ao �e uma biblioteca de procedimentos que implementa a funcionalidade dosistema. Em termos de programa�c~ao o controle pertence �a interface e �e transferidopara a aplica�c~ao na forma de chamada de fun�c~ao. Quest~oes de controle e comunica�c~aopertinentes ao software da interface s~ao contemplados em [30].Callback

Retorno

APLICACAO INTERFACE

Codigo Codigo

Chamada

Retorno

APLICACAO INTERFACE

Codigo Codigo

(a) (b)Figura 5: Fluxo de controle convencional (a) e existente em ferramentas (b).4. Concorrencia. Fun�c~oes da aplica�c~ao podem consumir grande quantidade de tempopara as suas execu�c~oes. No entanto, a interface n~ao deve esperar por tais execu�c~oes.Ela deve estar \pronta" para atender os pedidos dos usu�arios assim que forem re-quisitados. Em decorrencia, o sistema deve ser organizado em m�ultiplos processos.Isto signi�ca que o programador dever�a tratar problemas de sincroniza�c~ao, exclus~aom�utua e outros.5. E�ciencia. Resposta imediata �as a�c~oes dos usu�arios �e desej�avel em uma interface.Obter esta rea�c~ao imediata requer trabalho adicional do programador em alguns casos.6. Manipula�c~ao de erro. Sistemas interativos n~ao admitem o t�ermino de execu�c~ao emdecorrencia de erro do usu�ario. �E preciso inform�a-lo e, se poss��vel, permitir que o erropossa ser corrigido.

Page 17: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

16 F�abio Lucena & Hans Liesenberg7. Suspens~ao da execu�c~ao, undo e ajuda. Geralmente sistemas interativos permitemque uma atividade seja suspensa em qualquer instante ou ainda, que possa ser \des-feita." H�a ainda necessidade de ajuda ao usu�ario, i.e., help on-line. Estes requisitosacrescentam mais funcionalidade ao c�odigo da interface.H�a uma vasta quantidade de ferramentas utilizadas na constru�c~ao de interfaces. Al-gumas dispon��veis comercialmente, enquanto outras atrav�es de centros de pesquisa. Es-tas ferramentas distinguem-se umas das outras por v�arios motivos: funcionalidade queproveem, facilidade de uso da pr�opria ferramenta, estilos de intera�c~ao empregados (MotifTM,OpenLookTM), portabilidade (veja [2]) da interface gerada e outras [34]. Nesta se�c~ao abor-daremos v�arios tipos de ferramentas para o desenvolvimento de interfaces. Note que exis-tem ferramentas orientadas para a confec�c~ao de prot�otipos, projeto e avalia�c~ao. A im-plementa�c~ao �e apenas uma das atividades do desenvolvimento de interfaces que possuemferramentas de apoio.5.1 ToolkitsToolkit �e uma biblioteca de rotinas usadas por programadores para a implementa�c~ao dedetalhes de baixo n��vel. Em geral, quando se emprega um toolkit na implementa�c~ao deuma interface, o controle reside no componente computacional (ou aplica�c~ao, conformevisto anteriormente). A implementa�c~ao resultante �e um conjunto de widgets. Widget �eum objeto de intera�c~ao com apresenta�c~ao e comportamento bem de�nidos. Implementamelementos t��picos de uma interface como bot~oes, menus e outros. Um toolkit ainda podepossuir ferramenta que facilita o posicionamento destes objetos de intera�c~ao (widgets) natela [58]. A interface desenvolvida com o uso de um toolkit geralmente interage com aaplica�c~ao atrav�es de callbacks. Ou seja, fun�c~oes fornecidas pelo programador para seremexecutadas em pontos espec���cos da intera�c~ao do sistema com o usu�ario, em resposta aalgum evento ocorrido.5.2 UIMSO modelo de Seeheim [22] �e composto por m�odulos que se comunicam entre si (veja Figura6). Cada um dos componentes possui uma fun�c~ao imprescind��vel de um UIMS e, por-tanto, uma descri�c~ao correspondente da interface deve existir para permitir a sua gera�c~aoautom�atica. Trata-se de um modelo l�ogico, n~ao diz como um UIMS deve ser estruturadoou implementado. Cada componente deste modelo tem uma fun�c~ao diferente e requer umat�ecnica de descri�c~ao particular. Note ainda a separa�c~ao desej�avel entre a interface e aaplica�c~ao.UIMS (User Interface Management System): sistema voltado para o de-senvolvimento e execu�c~ao de interfaces entre homem e computador. Ajudamna especi�ca�c~ao, projeto, constru�c~ao de prot�otipos, implementa�c~ao, execu�c~ao,avalia�c~ao, modi�ca�c~ao e manuten�c~ao de interfaces [33].

Page 18: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 17O componente de apresenta�c~ao gerencia a tela (cria�c~ao) e monitora os dispositivos deentrada. Mapeia as a�c~oes do usu�ario sobre os dispositivos de entrada em uma linguagemabstrata e interpreta opera�c~oes abstratas de sa��da produzindo a tela. As entradas do usu�arios~ao tokens produzidos pelo componente de apresenta�c~ao. A seq:uencia em que estes tokenss~ao entregues ao controle de di�alogo guia o di�alogo e produz informa�c~ao para ser enviada�a interface da aplica�c~ao. No sentido contr�ario, o controle de di�alogo recebe informa�c~ao dainterface com a aplica�c~ao, seu estado pode ser modi�cado e provocar comandos abstratosde sa��da que ser~ao interpretados pelo componente de apresenta�c~ao. A interface da aplica�c~aorecebe pedidos do controle de di�alogo que pode realizar mapeamentos antes de entreg�a-los �aaplica�c~ao. Este componente pode responder diretamente aos pedidos do controle de di�alogoquando o pedido n~ao for sintaticamente v�alido, e transformar a sa��da da aplica�c~ao antes detransmiti-la ao controlador de di�alogo.Interface

com aAplicacao

ApresentacaoControle deDialogoFigura 6: Modelo abstrato de um UIMS. Modelo de Seeheim [22]A grosso modo pode-se considerar o componente de apresenta�c~ao como o \n��vel l�exico"do sistema interativo. Um analisador l�exico pode ser utilizado para ocultar os detalhesde como os comandos e parametros podem ser fornecidos (p.ex., um comando pode seroriginado da sele�c~ao de um menu e seu respectivo parametro de um��cone). O controlador dedi�alogo, \n��vel sint�atico", pode ser implementado como um analisador sint�atico, que recebeos tokens pr�e-processados do analisador l�exico e veri�ca a corre�c~ao sint�atica a medida ques~ao obtidos.5.3 Especi�ca�c~ao de di�alogoLinguagens de especi�ca�c~ao de di�alogo podem ser classi�cadas segundo o modelo de controlede di�alogo empregado. Tres modelos s~ao comentados abaixo, juntamente com nota�c~oest��picas de cada modelo. Em [38] �e apresentada uma lista de qualidades desej�aveis emlinguagens de especi�ca�c~ao de di�alogo. Geralmente as nota�c~oes possuem ferramentas deapoio para constru�c~ao e execu�c~ao de descri�c~oes. Conforme [72], diagramas de transi�c~aoe leiautes de tela s~ao inadequados para o usu�ario na ausencia de um interpretador destesdiagramas.Modelos de controle de di�alogoComent�arios exaustivos sobre tres modelos de di�alogos (redes de transi�c~ao, gram�aticas e omodelo de eventos) podem ser obtidos em [23]. Abaixo s~ao descritos os modelos e as nota�c~oest��picas empregadas. Estes modelos podem ser usados como m�etodos para formalmente

Page 19: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

18 F�abio Lucena & Hans Liesenbergespeci�car uma interface, possivelmente para servir de entrada para algum UIMS, queautomaticamente gera o controle da interface.A nota�c~ao mais comum para interfaces �e baseada em redes de transi�c~ao. Diagramasde Transi�c~ao de Estados (DTEs) �e o exemplo mais signi�cativo. Este modelo considerauma interface como uma cole�c~ao de estados ligados por arestas rotuladas com eventos.Estes eventos podem estar associados �as a�c~oes do usu�ario, tempo e resultados (sa��da) daaplica�c~ao. Evento �e a condi�c~ao necess�aria para que ocorra uma transi�c~ao entre estados.Uma caracter��stica positiva dos DTEs �e a sua representa�c~ao gr�a�ca. Statecharts [26] �euma extens~ao dos DTEs empregada na especi�ca�c~ao de sistemas reativos, em particularo controle de di�alogo de uma interface [45]. Statecharts permitem descri�c~oes hier�arquicas,descrever concorrencia, comunica�c~ao e hist�oria.Nota�c~oes baseadas em gram�aticas consideram o di�alogo entre usu�ario e aplica�c~ao comocomo uma linguagem descrita por uma gram�atica. A gram�atica �e especi�cada em BNF(Backus-Naur Form), que �e amplamente empregada na especi�ca�c~ao formal da sintaxe delinguagens de programa�c~ao. A nota�c~ao geralmente �e estendida para permitir que c�odigofornecido seja executado sempre que uma regra �e utilizada.Nota�c~oes baseadas em eventos apresentam facilidades para a descri�c~ao de di�alogos com-plexos, caracter��sticos de manipula�c~ao direta [17, 32]. Neste caso uma interface �e vista comoum conjunto de eventos e tratadores para estes eventos. Eventos podem ser gerados pora�c~oes do usu�ario sobre dispositivos de entrada, por tratadores de eventos ou em decorrenciado resultado das aplica�c~oes.5.4 Independencia de di�alogoO desenvolvimento de sistemas interativos com pouca distin�c~ao entre o software do di�alogoe o da aplica�c~ao conduz a interfaces de baixa qualidade, pois o projeto da interface �e umprocesso c��clico envolvendo avalia�c~ao e corre�c~ao. Isto prossegue at�e a obten�c~ao de umprojeto satisfat�orio. Se n~ao h�a distin�c~ao entre estes elementos, h�a in�umeras di�culdades(resistencias) que di�cultam mudan�cas pois n~ao podemos tratar quest~oes de diferentes inte-resses de forma independente. Isto porque separation of concerns [21], um princ��pio b�asico,e sua conseq:uente realiza�c~ao em m�odulos distintos n~ao s~ao aplicados.Em banco de dados h�a um problema similar: o isolamento desej�avel entre programase dados, de tal forma que mudan�cas em um n~ao afete o outro. A solu�c~ao �e conhecida porindependencia de dados. Uma solu�c~ao an�aloga neste contexto �e chamada de independenciade di�alogo, que �e baseada na de�ni�c~ao de um protocolo de comunica�c~ao entre a interface ea aplica�c~ao. A Figura 7 relaciona estes dois conceitos.A independencia de di�alogo permite separar quest~oes concernentes ao di�alogo de um ladoe a aplica�c~ao de outro. Note que a aplica�c~ao n~ao se interessa na forma como dados de entradaforam obtidos (menus, linguagem de comandos e outros), mas nos dados propriamente ditos.Analogamente, a interface n~ao se interessa pelo processamento dos dados, mas em comoobte-los do usu�ario e exibir os resultados das transforma�c~oes neles realizadas.A grande vantagem desta abordagem �e manter a separa�c~ao entre elementos de prop�ositosdistintos (interface e aplica�c~ao). S~ao v�arios os benef��cios:� Quest~oes que dizem respeito a um componente tem in uencia limitada no outro.

Page 20: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 19INTERFACE APLICACAO BANCO DE DADOS

Independencia dedialogo dados

Independencia deFigura 7: Conceitos an�alogos: independencias de dados e di�alogo.� O desenvolvimento pode ser realizado independentemente, exceto quanto ao protocolode comunica�c~ao entre eles.� Interfaces diferentes para uma mesma aplica�c~ao podem ser desenvolvidas para gruposde usu�arios distintos. Por exemplo, por motivo de l��nguas diferentes, cultura ouexperiencia.Como obter: isolar, em tempo de projeto, quest~oes de di�alogo e de aplica�c~ao[30].Por �m, isto signi�ca que um sistema interativo (Figura 2) �e composto pelo componentede di�alogo atrav�es do qual toda a comunica�c~ao entre o usu�ario e o sistema �e realizada eo componente computacional, parte funcional do sistema que prove toda a semantica dosistema.Em [30, 36] �e comentado em mais detalhes as implica�c~oes desta separa�c~ao.5.5 Sistema de janelaUm marco n��tido na hist�oria das atuais interfaces foi a cria�c~ao do ambiente Smalltalk. Esteambiente permite o uso de v�arias janelas2 sobrepostas.3 As janelas podem ser selecionadase transladadas na tela com o uso do mouse. A primeira vers~ao deste ambiente, conforme[37], foi testada no Alto, um prot�otipo de computador desenvolvido no Xerox PARC (PaloAlto Research Center), um dos computadores mais f�aceis de se usar at�e aquele momento.Conceitos empregados no Alto (desktop, windows, WYSIWYG e outros) foram re�nadose novamente agrupados no XEROX Star em 1981. Usando conceitos apresentados nestasm�aquinas e com pre�co mais acess��vel surge o Apple Macintosh em 1984. Em 1985 �e lan�cadoo Windows | uma tentativa de fornecer aos usu�arios do computador mais difundido, oIBM-PC, facilidades semelhantes �aquelas que os usu�arios dos computadores supracitadospossu��am. O Windows consumiu 110 mil horas de programa�c~ao. Resultado: em dezembrode 1989 j�a haviam sido vendidas 2 milh~oes de c�opias. No �m de 1990 e in��cio de 1991 eram2Janela (window) �e uma �area geralmente retangular da tela. Atrav�es desta �area um programa recebeentradas e emite os resultados do seu processamento. Geralmente os ambientes que permitem o uso dejanelas s~ao multiprogramados (multiprogramming). Neste caso cada janela pode corresponder a um processoexecutado concorrentemente.3Janelas que podem ter uma interse�c~ao n~ao nula, ao inv�es de janelas \azulejadas" (tiled).

Page 21: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

20 F�abio Lucena & Hans Liesenbergvendidas 30 mil c�opias por semana [37]. Grande parte deste sucesso �e atribu��do, sobretudo,�a interface com o usu�ario. Para contrastar com o tempo de desenvolvimento do Windows, ainterface para o Star consumiu 6 anos [10]. Windows NT �e um sistema similar ao Windowsdo ponto de vista de apresenta�c~ao. Por outro lado, acrescenta alguns mecanismos paramelhor utilizar os recursos do equipamento utilizado. Muitas especula�c~oes [75] tem sidofeitas sobre este produto.Estes sucessos tornaram comum os sistemas de janelas. X Window [62] �e muito utilizadoem ambiente UNIX.Sistema de Janela: gerencia recursos t��picos de um ambiente de janela tais comoeventos, cria�c~ao e remo�c~ao de janelas, dispositivos de entrada e sa��da (mouse,teclado, v��deo e outros).Um sistema de janela fornece mecanismos para gerenciar telas usando janelas. As facili-dades fornecidas, no entanto, s~ao de baixo n��vel e requer esfor�co substancial do programadorpara apresentar uma simples janela. O gerenciador de janela (window manager) permiteo controle da tela pelos usu�arios atrav�es da manipula�c~ao de janelas. A interface fornecidapelo gerenciador de janela �e percebida, incorretamente, como todo o sistema de janela. Ogerenciador �e apenas uma das interfaces de um sistema de janela! Uma taxonomia paragerenciadores de janela �e apresentada em [49].H�a v�arios termos associados aos sistemas de janela. Um dos mais importantes refere-seao modelo de imagem empregado.Modelo de Imagem: modelo fornecido por um sistema de janela paraexpressar a sa��da, p.ex., no modelo de pixel (picture X element) atela �e vista como uma matriz de pontos que podem ter suas cores al-teradas. Outros exemplos s~ao GKS (Graphical Kernel System), PHIGS(Programmer's Hierarchical Interface to Graphics), QuickDraw e PostScript.Veja mais detalhes em [5, p�ag. 62].6 Avalia�c~ao The complexity of both humans and computing systems makes theirinteraction less predictable than we would like. Even thebest intentions can result in unusable systems or, more often,in systems with problems.Perlman [59]Avalia�c~ao de projeto geralmente apresenta-se como uma atividade necess�aria no desen-volvimento de sistemas, n~ao exclusivamente de software. No mundo real, a implementa�c~aode um sistema, seguida de sua avalia�c~ao e posterior corre�c~ao de erros �e impratic�avel na

Page 22: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 21grande maioria dos casos. Projetistas geralmente manipulam modelos, que s�o ap�os umm��nimo de \valida�c~ao" s~ao implementados. Esta regra tamb�em �e aplic�avel ao desenvol-vimento de interfaces. O papel da avalia�c~ao �e veri�car (projeto) se realmente o sistemacomporta-se como esperado e atende os requisitos dos usu�arios. No contexto de interfacesh�a alguns ind��cios favor�aveis a realiza�c~ao desta atividade. O \censo comum", por exem-plo, �e algo comumente empregado durante o projeto. No entanto, n~ao pode ser aplicadode forma con��avel e muitos resultados de pesquisas tem contradito este princ��pio. Outroind��cio diz respeito a posi�c~ao do projetista, que em geral assume seu comportamento comorepresentativo, o que �e uma fal�acia. Estes e outros problemas s~ao comentados em [14].A avalia�c~ao pode ser executada durante todo o ciclo de vida do projeto. Ou antes daexistencia de um sistema execut�avel envolvendo apenas os projetistas. No entanto, isto n~aosubstitui o teste com as pessoas para as quais o sistema �e projetado: os usu�arios. Neste�ultimo caso, entretanto, h�a o envolvimento de implementa�c~ao do sistema em alguma forma:desde simula�c~ao, prot�otipos at�e o sistema completamente implementado. Na p�ag. 14, vejaProt�otipos, �e apresentado uma t�ecnica alternativa de avalia�c~ao de projeto com o usu�ario�nal sem a necessidade de c�odigo execut�avel ter sido gerado. Esta avalia�c~ao, no entanto,requer grande habilidade da equipe que a emprega.V�arias t�ecnicas podem ser usadas na avalia�c~ao. Os m�etodos anal��ticos empregam mode-los formais de intera�c~ao. Os m�etodos emp��ricos variam de informais (observa�c~ao do usu�ario)a formais (question�arios, entrevistas e experimentos desenvolvidos formalmente). Abaixos~ao citados alguns m�etodos:� Cen�arios. Fornece indica�c~ao de conceitos a serem capturados na interface.� Manual do usu�ario preliminar. Durante a escrita de detalhes espec���cos pode-se des-cobrir melhores m�etodos de opera�c~ao.� Mock-up. Demonstra a aparencia da interface.� Simula�c~oes pr�evias. Demonstra o comportamento.� Demonstra�c~oes. Mostra um limitado subconjunto da funcionalidade a ser implemen-tada.� Think aloud. Fornece uma id�eia dos pensamentos do usu�ario enquanto est�a operandoum prot�otipo ou vers~ao preliminar do sistema.� Teste formal de prot�otipo. Fornece informa�c~oes acerca de qu~ao bem tarefas podemser realizadas. Usa t�ecnicas de pesquisas em fatores humanos e estat��stica.7 Orienta�c~ao a objetos e interfacesO paradigma de objetos �e freq:uentemente relacionado a v�arios aspectos de interfaces, inclu-sive do ponto de vista metodol�ogico de desenvolvimento [46]. Esta se�c~ao mostra exemplosdeste relacionamento. Conforme [41], o paradigma �e explorado para o desenvolvimento(projeto e implementa�c~ao), apresenta�c~ao e integra�c~ao de interfaces.

Page 23: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

22 F�abio Lucena & Hans Liesenberg1. Projeto e implementa�c~ao. Devido �a quantidade de rotinas e o grande n�umero deparametros que geralmente apresentam, um programador n~ao usa diretamente a in-terface de programa�c~ao de um sistema de janelas. Ele faz uso de uma camada orien-tada a objeto sobre a interface de programa�c~ao. Esta camada equivale a objetos deintera�c~ao. Como exemplos existem MacApp para o Macintosh e Actor paraWindows.Uma descri�c~ao destas duas camadas pode ser vista em [41].A camada orientada a objetos fornece uma hierarquia de classes prede�nidas. Elasreduzem a quantidade de c�odigo a ser gerada pelo programador e fornecem consistencia�a interface. Encapsulam o comportamento e a apresenta�c~ao de elementos comuns comomenus, janelas, e ��cones. O mecanismo de heran�ca pode ser utilizado para herdarcomportamento e estrutura de classes existentes. Os elementos herdados podem serrede�nidos ou estendidos. Mais detalhes de que tipo de facilidades e como podem serusadas s~ao apresentados na descri�c~ao do InterViews em [44].2. Apresenta�c~ao. Nas modernas interfaces o usu�ario geralmente seleciona ou move ��conese objetos sobre a tela. Estes objetos e ��cones s~ao representa�c~oes gr�a�cas de conceitosdo mundo real e, portanto, reagem a mensagens recebidas bem como comunicam-secom outros objetos. Por exemplo, nestes sistemas, arquivos podem ser manipuladoscomo objetos. Para remover um objeto a mensagem remova �e enviada ao objetocorrespondente.3. Integra�c~ao. Este emprego �e mais sutil que os demais. Em vez de diretamente usufruirdo paradigma de objetos, faz uso de conceitos como objeto complexo e identidade deobjeto. An�alogo �a confec�c~ao de um objeto complexo, uma aplica�c~ao complexa podeser obtida pela integra�c~ao de informa�c~ao de um conjunto de aplica�c~oes. O usu�ariopode desenvolver um relat�orio (objeto complexo) em que gr�a�cos foram gerados deresultados obtidos de uma planilha eletronica, que obteve informa�c~oes de um bancode dados. Conv�em notar que os dados n~ao s~ao simplesmente transferidos de umaaplica�c~ao para outra. Uma altera�c~ao em um objeto causa a altera�c~ao do estado doobjeto complexo.8 Onde obter mais informa�c~oesSIGCHI Bulletin da ACM cont�em um variado elenco de informa�c~oes (coment�arios e lan�camentosde livros, projetos, lista de eventos e assim por diante) para os interessados nesta �area.[30, 31] podem ser utilizadas como referencias iniciais. HCI Bibliography Project mant�emuma base de dados com milhares de referencias sobre este assunto. Esta base de dados podeser obtida via ftp anonimo no diret�orio pub/hcibib em archive.cis.ohio-state.edu.O ACM SIGCHI Curricula for Human-Computer Interaction cont�em recomenda�c~oes daACM para a grade curricular de intera�c~ao homem-computador [65].O emprego de m�etodos formais em interfaces homem-computador �e discutido em [1, 27].A proposta de um UIMS �e defendida em [66].O Projeto Xchart encontra-se em andamento no Dept. de Ciencia da Computa�c~ao(IMECC/UNICAMP). Este projeto �e orientada para a constru�c~ao de ferramentas de apoio

Page 24: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 23a implementa�c~ao de interfaces. Na primeira p�agina s~ao fornecidos endere�cos para contatocom o grupo executor do projeto.9 Considera�c~oes �naisEste texto aborda v�arios aspectos do desenvolvimento de interfaces, n~ao s�o do ponto de vistado produto (p.ex., estilos de intera�c~ao) quanto tamb�em do processo (p.ex., ciclo de vida).As informa�c~oes apresentadas s~ao comentadas sucintamente. No entanto, acreditamos que o\todo" sirva de arcabou�co onde mais informa�c~oes podem ser obtidos, conforme as referenciasfornecidas e o interesse do leitor. Neste sentido, buscou-se fornecer uma vis~ao geral da �areaenfatizando aspectos de interesse dos pro�ssionais de computa�c~ao e sugerindo uma estruturapara guiar estes pro�ssionais na vasta bibliogra�a existente.10 AgradecimentosEm particular, gostar��amos de agradecer as valiosas sugest~oes de Osvaldo Severino J�unior.Referencias[1] Gregory D. Abowd. Formal Aspects of Human-Computer Interaction. PhD thesis, Uni-versity of Oxford, University of York { Department of Computer Science | Heslington,York, Y01 5DD, England, June 1991.[2] David M. Andersen and Bruce A. Sherwood. Portability and the GUI. Byte,16(12):221{226, November 1991.[3] Ronald M. Baecker and William A. S. Buxton, editors. Readings in Human-ComputerInteraction { A Muldisciplinary Approach. Morgan Kaufmann Publishers, Inc., 1987.In \Introduction".[4] Lon Bar�eld. The User Interface - Concepts & Design. Addison-Wesley PublishingCompany,Inc., 1993. ISBN 0-201-54441-5.[5] Len Bass and Jo�elle Coutaz. Developing Software for the User Interface. SEI Series inSoftware Engineering. Addison-Wesley Publishing Company, Inc., 1991.[6] Daniel G. Bobrow, Sanjay Mittal, and Mark J. Ste�k. Expert Systems: Perils andPromise. Communications of the ACM, 29(9):880{894, September 1986.[7] Susanne B�dker. Through the Interface: A Human Activity Approach to User InterfaceDesign. Lawrence Erlbaum Associates, Inc., 1991. ISBN 0-8058-0570-2.[8] John M. Carrol, Robert L. Mack, and Wendy A. Kellogg. Interface Metaphors andUser Interface Design. In Martin Helander, editor, Handbook of Human-ComputerInteraction. Elsevier Science - Publishers B.V, 1988.

Page 25: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

24 F�abio Lucena & Hans Liesenberg[9] Uli H. Chi. Formal Speci�cation of User Interfaces: A Comparison and Evaluationof Four Axiomatic Approaches. IEEE Transactions on Software Engineering, SE-11(8):671{685, August 1985.[10] Jo�elle Coutaz. Abstractions for User Interface Design. IEEE Computer, 18(09):21{34,September 1985.[11] Bill Curtis. Japan's Research Focus Shifts to Interfaces. IEEE Software, November1991.[12] J. F. DeSoi and W. M. Lively. Survey and Analysis of Nonprogramming Approachesto Design and Development of Graphical User Interfaces. Information and SoftwareTechnology, 33(6):413{424, July 1991.[13] Alan Dix, Janet Finlay, Gregory Abowd, and Russel Beale. Human-Computer Interac-tion. Prentice-Hall, 1993.[14] Andy Downton, editor. Engineering the Human-Computer Interface. McGraw-Hill,1991. ISBN 0{7-707321-5.[15] Stephen W. Draper and Donald A. Norman. Software Engineering for User Interfaces.IEEE Transactions on Software Engineering, SE-11(3):252{258, March 1985.[16] Clarence Ellis, Simon Gibbs, and Gail Rein. Groupware: Some Issues and Experiences.Communications of the ACM, 34(1):38{58, January 1991.[17] Mark A. Flecchia and R. Daniel Bergeron. Specifying Complex Dialogs in ALGAE. InProceedings of the ACM CHI+GI'87, pages 229{234, April 1987.[18] James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. ComputerGraphics: Principles and Practice. Addison-Wesley Publishing Company, Inc., secondedition, 1990.[19] Jason Gait. An Aspect of Aesthetics in Human-Computer Communications: PrettyWindows. IEEE Transactions on Software Engineering, SE-11(8):714{717, August1985.[20] Jason Gait. Pretty Pane Tiling of Pretty Windows. IEEE Software, pages 9{14,September 1986.[21] Carlos Ghezzi, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Software Engi-neering. Prentice-Hall, Inc., 1991.[22] Mark Green. Report on Dialogue Speci�cation Tools. In G�unther E. Pfa�, editor, UserInterface Management Systems, pages 9{20. Springer-Verlag, 1985.[23] Mark Green. A Survey of Three Dialogue Models. ACM Transactions on Graphics,5(3):244{275, July 1986.

Page 26: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 25[24] Frits Habermann. Giving Real Meaning to 'easy-to-use' Interfaces. IEEE Software,pages 90{91, July 1991.[25] Andrew Harbert, William Lively, and Sallie Sheppard. A Graphical Speci�cation Sys-tem for User-Interface Design. IEEE Software, 7(4):12{20, July 1990.[26] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of ComputerProgramming, 8(3):231{274, June 1987.[27] Michael Harrison and Harold Thimbleby, editors. Formal Methods in Human-ComputerInteraction. Cambridge University Press, 1990.[28] H. Rex Hartson and Deborah Hix. Toward Empirically Derived Methodologies andTools for Human-Computer Interface Development. Int. J. Man-Machine Studies,pages 477{494, 1989.[29] H. Rex Hartson, Antonio C. Siochi, and Deborah Hix. The UAN: A User-OrientedRepresentation for Direct Manipulation Interface Designs. ACM Transactions on In-formation Systems, 8(3):181{203, July 1990.[30] H.R. Hartson and D. Hix. Human-Computer Interface Development: Concepts andSystems for its Management. ACM Computing Surveys, 21(1):5{92, March 1989.[31] Martin Helander, editor. Handbook of Human-Computer Interaction. North-Holland,1988.[32] Ralph D. Hill. Event-Response Systems | A Technique for Specifying Multi-ThreadDialogues. In Proceedings of the ACM CHI+GI'87, pages 241{248, April 1987.[33] Deborah Hix. Generations of User-Interface Management Systems. IEEE Software,pages 77{89, September 1990.[34] Deborah Hix and H. Rex Hartson. Developing User Interfaces: Ensuring UsabilityThrough Product & Process. John Wiles & Sons, Inc., 1993. ISBN 0471-57813-4.[35] Don Hopkins. The Design and Implementation of Pie Menus. Dr. Dobb's Journal,pages 16{26, December 1991.[36] William D. Hurley and John L. Sibert. Modeling User Interface-Application Interacti-ons. IEEE Software, pages 71{77, January 1989.[37] Daniel Ichbiah and Susan Knepper. MICROSOFT. Editora Campus, Rio de Janeiro,1992. Tradu�c~ao do original: The Making of Microsoft.[38] Robert J. K. Jacob. Using Formal Speci�cations in the Design of a Human-ComputerInterface. Communications of the ACM, 26(4):259{264, April 1983.[39] Robert J. K. Jacob. A Speci�cation Language for Direct-Manipulation User Interfaces.ACM Transactions on Graphics, 5(4):283{317, October 1986.

Page 27: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

26 F�abio Lucena & Hans Liesenberg[40] Elieser Kantorowitz and Oded Sudarsky. The Adaptable User Interface. Communica-tions of the ACM, 32(11):1352{1358, November 1989.[41] Setrag Khosha�an and Razmik Abnous. Object Orientation: Concepts, Languages,Databases, User Interfaces, chapter User Interfaces, pages 323{387. John Wiley &Sons, Inc., 1990.[42] Thomas K. Landauer. Research Methods in Human-computer interaction. In M. He-lander, editor, Handbook of Human-Computer Interaction, chapter 42, pages 905{927.Elsevier Science - Publishers B.V, North-Holland, 1988.[43] Brenda Laurel, editor. The Art of Human-Computer Interface Design. Addison-WesleyPublishing Company, Inc., 1990. ISBN 0-201-51797-3.[44] Mark A. Linton, Paul R. Calder, and John M. Vlissides. InterViews: A C++ GraphicalInterface Toolkit. Center for Integrated Systems/Stanford, CA 94305.[45] F�abio N. Lucena and Hans K.E. Liesenberg. Re ections on Using Statecharts to Cap-ture User Interface Behaviour. Proceedings of XIV Int. Conf. of the Chilean CSS,October 1994.[46] Susan E. McDaniel, Gary M. Olson, and Judith S. Olson. Methods in Search of Metho-dology { Combining HCI and Object Orientation. In Human Factors in ComputingSystems CHI'94 Conference Proceedings, pages 145{151, 1994.[47] G. A. Miller. The Magical Number 7, plus or minus 2: Some Limits of our Capacityfor Processing Information. Psychological Review, 1956. Number 63.[48] Rolf Molich and Jakob Nielsen. Improving a Human-Computer Dialogue. Communi-cations of the ACM, 33(3):338{348, March 1990.[49] Brad A. Myers. A Taxonomy of Window Manager User Interfaces. IEEE ComputerGraphics & Applications, pages 65{84, September 1988.[50] Brad A. Myers. Encapsulating Interactive Behaviors. In Human Factors in ComputingSystems, Proceedings SIGCHI'89, pages 319{324, Austin,TX, April 1989.[51] Brad A. Myers. Demonstrational Interfaces: A Step Beyond Direct Manipulation.IEEE Computer, pages 61{73, August 1992.[52] Brad A. Myers, editor. Languages for Developing User Interfaces. J&B, 1992.[53] Brad A. Myers. Challenges of HCI Design and Implementation. Interactions, 1(1):73{83, 1994.[54] Brad A. Myers and Mary Beth Rosson. Survey on User Interface Programming. InCHI'92 Proceedings, pages 195{202, Monterey, California, May 1992.[55] Peter G. Neumann. Flaws in Speci�cation and What to do about Them. ACM SIG-SOFT Engineering Notes, 14(3), May 1989.

Page 28: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Interfaces Homem-Computador: Uma Primeira Introdu�c~ao 27[56] William M. Newman and Robert F. Sproull. Principles of Interactive ComputerGraphics, chapter 28, pages 443{478. McGraw-Hill, Inc., second edition, 1979.[57] Jakob Nielsen. Iterative User-Interface Design. Computer, 26(11):32{41, November1993.[58] Randy Pausch, Matthew Conway, and Robert DeLine. Lessons Learned from SUIT, theSimple User Interface Toolkit. ACM Transactions on Information Systems, 10(4):320{344, October 1992.[59] Gary Perlman. User Interface Development. Technical Report SEI-CM-17-1.1, SoftwareEngineering Institute, Carnegie Mellon University, 1989.[60] Marc Rettig. Prototyping for Tiny Fingers. Communications of the ACM, 37(4):21{27,April 1994.[61] Mattew D. Russell, Howard Xu, and Lingtao Wang. Action Assignable Graphics - AFlexible Human-Computer Interface Design Process. In Human Factors in ComputingSystems CHI'92 Conference Proceedings, pages 71{72, Monterey, California, May 1992.[62] Robert W. Schei er and Jim Gettys. The X Window System. ACM Transactions onGraphics, 5(2):79{109, April 1986.[63] Ben Shneiderman. Direct Manipulation: A Step Beyond Programming Languages.IEEE Computer, 16(8):57{69, August 1983.[64] Ben Shneiderman. Designing the User Interface: Strategies for E�ective Human-Computer Interaction. Addison-Wesley Publishing Company, Inc., 1987.[65] ACM SIGCHI. Curricula for Human-Computer Interaction, 1992. ISBN 0-89791-474-0.[66] Gurminder Singh. Automating the Lexical and Syntactic Desigh of Graphical UserInterfaces. PhD thesis, University of Alberta, Edmonton, Alberta, 1989.[67] Gurminder Singh. VU: Visual User-Interface Design. In The Visual Computer, pages230{241. Springer-Verlag, 1990.[68] H. W. Six and J. Voss. User Interface Development: Problems and Experiences. LectureNotes in Computer Science, 555:306{319, June 1991.[69] Sidney L. Smith and Jane N. Mosier. Guidelines for Designing User Interface Soft-ware. Technical Report ESD-TR-86-278, US Air Force, 1986. Distribution unlimited.Anonymous ftp: archive.cis.ohio-state.edu, pub/hci/Guidelines.[70] R. Summersgill and D. P. Browne. Human Factors: Its Place in System DevelopmentMethods. ACM SIGSOFT Engineering Notes, 14(3):227{234, May 1989.[71] Harold Thimbleby. User Interface Design. ACM Press, 1990. ISBN 0-201-41618-2.

Page 29: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

28 F�abio Lucena & Hans Liesenberg[72] Anthony I. Wasserman, Peter A. Pircher, David T. Shewmake, and Martin L. Kers-ten. Developing Interactive Information Systems with the User Software EngineeringMethodology. IEEE Transactions on Software Engineering, SE-12(2):326{345, Febru-ary 1986.[73] James wilson and Daniel Rosenberg. Rapid Prototyping for User Interface Design.In M. Helander, editor, Handbook of Human-Computer Interaction, chapter 39, pages859{875. Elsevier Science Publishers B.V., 1988.[74] Michael Wilson and Anthony Conway. Enhanced Interaction Styles for User Interfaces.IEEE Computer Graphics & Applications, 11(2):79{90, March 1991.[75] Tom Yager and Ben Smith. Is Unix Dead? Byte, 17(9):134{146, September 1992.

Page 30: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

�Indiceamig�avel, 4an�alise de tarefas, 11aplica�c~ao, 2atrativo, 4avalia�c~ao, 8, 20callback, 16ciclo de vida, 8desenvolvimento, 7di�alogo, 3engenharia de software, 7especi�ca�c~oes de di�alogo, 17estilos, 13f�acil de usar e aprender, 3, 4groupware, 10guidelines, 11implementa�c~ao, 8, 14{20di�culdades, 14independencia de di�alogo, 18independencia de di�alogo, 3informa�c~oes adicionaisonde obter, 22interfaceconceito, 1conseq:uencias da importancia, 6de�ni�c~ao, 2desenvolvimento, 7estilos, 13importancia, 4m�etricas, 5InterViews, 22look and feel, 9modelo de imagem, 20modelo de Seeheim, 17modelo formal, 7modelos de di�alogo, 17

orienta�c~ao a objetos, 21padr~oes, 11portabilidade, 16princ��pios, 11consistencia, 12feedback, 12habilidades distintas, 12met�aforas, 12minimizar erro, 12minimizar mem�oria, 12recuperar erro, 12projeto, 8{14de�ni�c~ao, 9multidisciplinar, 10produto de, 14prot�otipos, 14recorda�c~ao r�apida, 3regras, 11sistema de janela, 19sociologia, 10Star, 19statecharts, 18taxa de erro m��nima, 3toolkits, 16UIMS, 16user-friendly, 3Windows, 19Windows NT, 1929

Page 31: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Relat�orios T�ecnicos { 199292-01 Applications of Finite Automata Representing Large Vocabularies,C. L. Lucchesi, T. Kowaltowski92-02 Point Set Pattern Matching in d-Dimensions, P. J. de Rezende, D. T. Lee92-03 On the Irrelevance of Edge Orientations on the Acyclic Directed Two Dis-joint Paths Problem, C. L. Lucchesi, M. C. M. T. Giglio92-04 A Note on Primitives for the Manipulation of General Subdivisions andthe Computation of Voronoi Diagrams, W. Jacometti92-05 An (l; u)-Transversal Theorem for Bipartite Graphs, C. L. Lucchesi,D. H. Younger92-06 Implementing Integrity Control in Active Databases, C. B. Medeiros,M. J. Andrade92-07 New Experimental Results For Bipartite Matching, J. C. Setubal92-08 Maintaining Integrity Constraints across Versions in a Database, C. B. Me-deiros, G. Jomier, W. Cellary92-09 On Clique-Complete Graphs, C. L. Lucchesi, C. P. Mello, J. L. Szwarc�ter92-10 Examples of Informal but Rigorous Correctness Proofs for Tree TraversingAlgorithms, T. Kowaltowski92-11 Debugging Aids for Statechart-Based Systems, V. G. S. Elias, H. Liesenberg92-12 Browsing and Querying in Object-Oriented Databases, J. L. de Oliveira,R. de O. Anido30

Page 32: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Relat�orios T�ecnicos { 199393-01 Transforming Statecharts into Reactive Systems, Antonio G. Figueiredo Filho,Hans K. E. Liesenberg93-02 The Hierarchical Ring Protocol: An E�cient Scheme for Reading Repli-cated Data, Nabor das C. Mendon�ca, Ricardo de O. Anido93-03 Matching Algorithms for Bipartite Graphs, Herbert A. Baier Saip, Cl�audio L.Lucchesi93-04 A lexBFS Algorithm for Proper Interval Graph Recognition, Celina M. H.de Figueiredo, Jo~ao Meidanis, C�elia P. de Mello93-05 Sistema Gerenciador de Processamento Cooperativo, Ivonne. M. Carrazana,Nelson. C. Machado, C�elio. C. Guimar~aes93-06 Implementa�c~ao de um Banco de Dados Relacional Dotado de uma InterfaceCooperativa, Nascif A. Abousalh Neto, Ariadne M. B. R. Carvalho93-07 Estadogramas no Desenvolvimento de Interfaces, F�abio N. de Lucena, HansK. E. Liesenberg93-08 Introspection and Projection in Reasoning about Other Agents, JacquesWainer93-09 Codi�ca�c~ao de Seq�uencias de Imagens com Quantiza�c~ao Vetorial, CarlosAntonio Reinaldo Costa, Paulo L��cio de Geus93-10 Minimiza�c~ao do Consumo de Energia em um Sistema para Aquisi�c~ao deDados Controlado por Microcomputador, Paulo Cesar Centoducatte, NelsonCastro Machado93-11 An Implementation Structure for RM-OSI/ISO Transaction ProcessingApplication Contexts, Fl�avio Morais de Assis Silva, Edmundo Roberto Mauro Ma-deira93-12 Boole's conditions of possible experience and reasoning under uncertainty,Pierre Hansen, Brigitte Jaumard, Marcus Poggi de Arag~ao93-13 Modelling Geographic Information Systems using an Object Oriented Fra-mework, Fatima Pires, Claudia Bauzer Medeiros, Ardemiris Barros Silva93-14 Managing Time in Object-Oriented Databases, Lincoln M. Oliveira, ClaudiaBauzer Medeiros93-15 Using Extended Hierarchical Quorum Consensus to Control ReplicatedData: from Traditional Voting to Logical Structures, Nabor das Chagas Men-don�ca, Ricardo de Oliveira Anido 31

Page 33: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

93-16 LL { An Object Oriented Library Language Reference Manual, TomaszKowaltowski, Evandro Bacarin93-17 Metodologias para Convers~ao de Esquemas em Sistemas de Bancos deDados Heterogeneos, Ronaldo Lopes de Oliveira, Geovane Cayres Magalh~aes93-18 Rule Application in GIS { a Case Study, Claudia Bauzer Medeiros, GeovaneCayres Magalh~aes93-19 Modelamento, Simula�c~ao e S��ntese com VHDL, Carlos Geraldo Kr�uger e M�arioL�ucio Cortes93-20 Re ections on Using Statecharts to Capture Human-Computer InterfaceBehaviour, F�abio Nogueira de Lucena e Hans Liesenberg93-21 Applications of Finite Automata in Debugging Natural Language Vocabu-laries, Tomasz Kowaltowski, Cl�audio Leonardo Lucchesi e Jorge Stol�93-22 Minimization of Binary Automata, Tomasz Kowaltowski, Cl�audio Leonardo Luc-chesi e Jorge Stol�93-23 Rethinking the dna Fragment Assembly Problem, Jo~ao Meidanis93-24 EGOLib | Uma Biblioteca Orientada a Objetos Gr�a�cos, Eduardo AguiarPatroc��nio, Pedro Jussieu de Rezende93-25 Compreens~ao de Algoritmos atrav�es de Ambientes Dedicados a Anima�c~ao,Rackel Valadares Amorim, Pedro Jussieu de Rezende93-26 GeoLab: An Environment for Development of Algorithms in ComputationalGeometry, Pedro Jussieu de Rezende, Welson R. Jacometti93-27 A Uni�ed Characterization of Chordal, Interval, Indi�erence and OtherClasses of Graphs, Jo~ao Meidanis93-28 Programming Dialogue Control of User Interfaces Using Statecharts, F�abioNogueira de Lucena e Hans Liesenberg93-29 EGOLib { Manual de Referencia, Eduardo Aguiar Patroc��nio e Pedro Jussieu deRezende32

Page 34: Interfaces Homem-Computador: Uma Primeira Introdu cão Relat

Relat�orios T�ecnicos { 199494-01 A Statechart Engine to Support Implementations of Complex Behaviour,F�abio Nogueira de Lucena, Hans K. E. Liesenberg94-02 Incorpora�c~ao do Tempo em um sgbd Orientado a Objetos, Angelo RoncalliAlencar Brayner, Claudia Bauzer Medeiros94-03 O Algoritmo KMP atrav�es de Automatos, Marcus Vin��cius A. Andrade eCl�audio L. Lucchesi94-04 On Edge-Colouring Indi�erence Graphs, Celina M. H. de Figueiredo, Jo~ao Mei-danis, C�elia Picinin de Mello94-05 Using Versions in gis, Claudia Bauzer Medeiros and Genevi�eve Jomier94-06 Times Ass��ncronos: Uma Nova T�ecnica para o Flow Shop Problem, H�elvioPereira Peixoto e Pedro S�ergio de SouzaDepartamento de Ciencia da Computa�c~ao | IMECCCaixa Postal 6065Universidade Estadual de Campinas13081-970 { Campinas { [email protected] 33