Anais do IHC'2001 - Departamento de Informática e Estatística - UFSC

250
Anais do IHC’2001 - IV Workshop sobre Fatores Humanos em Sistemas Computacionais
cada nova extensão inserida no software. Sem esta atualização não será possível manter a
função metalingüística atuando de forma satisfatória, pois ela falhará quando for necessário
acessar informações sobre estas extensões.
É interessante observar que os requisitos até agora levantados vão ao encontro
direto da proposta de Adler e Winograd [ADLER ’92] refletindo o problema da aquisição de
conhecimento do software por parte dos usuários finais para a realização de suas tarefas,
sejam elas normais ou de extensão. Porém, nenhum deles garante que as extensões ao
software produzidas por estes usuários não venham a invalidar o conhecimento já
adquirido. A fim de evitar a perda deste conhecimento é indispensável que as extensões
somente possam adicionar, reorganizar ou personalizar a UIL dentro de uma faixa de tipos
possíveis de modificações antecipadas pelo designer, de forma a não corromper seu design
original. Devido a esta limitação nos tipos de extensões e ao fato de que estas extensões
ocorrerão sobre a UIL, a tarefa de realização de extensões em EUP será equivalente à
geração de tokens de tipos interativos realizados ou potenciais que deverão ser
intrínsecos à concepção da mensagem original do designer para o usuário [DE SOUZA ’01].
Esta visão está de acordo com o mecanismo de programação por demonstração
[CYPHER ’93], no qual os tipos interativos são usados para inferir extensões pretendidas e
somente tokens específicos da UIL do software, que pertençam a estes tipos, podem ser
gerados pelos mecanismos de EUP. Estas observações procuram deixar claro o fato de que
extensão é estritamente diferente de programação, pois na primeira pressupõe-se a
existência de algo a ser estendido enquanto na segunda pode-se partir “do nada”. Isto
implica que um usuário no papel de designer não poderá introduzir novos elementos que
não tenham relação com o modelo de usabilidade original do software.
Contudo, não basta garantir a exclusão de elementos estranhos ao modelo de
usabilidade do software para evitar a perda de conhecimento com a criação de extensões, é
preciso também que as extensões construídas pelo usuário respeitem o Ciclo de Interação
Mínimo necessário à criação de diálogos completos na UIL. No modelo conceitual aqui
proposto, este ciclo mínimo é composto por três passos que podem ser descritos como [DE
SOUZA ’01]:
software diz alguma coisa para o usuário — isto é, a mensagem do designer,
descrevendo as funcionalidades disponíveis, é passada ao usuário através da UIL;
usuário diz alguma coisa ao software — isto é, o usuário define a ação que quer
executar para realizar parcialmente, ou totalmente, sua tarefa; e
software responde ao usuário — isto é, o software apresenta o resultado da
efetivação de sua funcionalidade.
É interessante observar que este ciclo diferencia-se do ciclo de interação dos
modelos da tarefa de EUP tradicionais devido àqueles, geralmente, considerarem somente
os dois últimos passos descritos acima. Desta forma, aqueles modelos não levam em conta
o fato de que o designer comunica ao usuário, através da interface, a estrutura de
funcionamento do software e que uma falha nesta comunicação resultará na sua baixa
usabilidade, como nos mostra Prates et al. em [PRATES ’00]. Assim, para garantir que o
Ciclo de Interação Mínimo seja respeitado, é necessário que a EUPL tenha uma noção
de texto que seja sintaticamente distinta, ou uma construção de mais alta ordem que aquela
equivalente às instruções, bloco ou programa executável, de tal forma que se possa associar
uma interpretação pragmaticamente válida (na UIL) às construções de texto (na EUPL).