Embed Size (px)
Citation preview
GILDA DAHIS
Um Modelo Para a Especificação
de Cenários de Interação
Dissertação apresentada ao Departamento de
Informática da PUC-Rio como parte dos requisitos
para obtenção do título de Mestre em Informática.
Orientadoras: Clarisse Sieckenius de Souza
Simone Diniz Junqueira Barbosa
Departamento de Informática
Pontifícia Universidade Católica do Rio de Janeiro
Rio de janeiro, 14 de outubro de 2001.
GILDA DAHIS
Um Modelo Para a Especificação
de Cenários de Interação
Dissertação apresentada ao Departamento de
Informática da PUC-Rio como parte dos requisitos
para obtenção do título de Mestre em Informática.
Orientadoras: Clarisse Sieckenius de Souza
Simone Diniz Junqueira Barbosa
Departamento de Informática
Pontifícia Universidade Católica do Rio de Janeiro
Rio de janeiro, 14 de outubro de 2001.
Dedico este trabalho a todas as pessoas que
sentiram falta da minha atenção durante os anos
de mestrado.
Agradecimentos
Agradeço a D´us por ter me dado forças para persistir até o fim e vencer os percalços
deste longo caminho. Agradeço ao meu amor, Paramahansa, o maior de todos os mensageiros
de boas notícias, pelas revisões, pelo apoio em todos os momentos e sobretudo, por seu amor.
Este trabalho não teria sido concluído sem a sua ajuda. Agradeço a meus pais, a meus irmãos
Goldinha e Julinho, a minha cunhadinha Rose e a meus sobrinhos Gisele, Amanda e Ricardo,
pelo seu eterno amor e pela crença que depositam em mim. Ao meu irmão e a sua família,
agradeço ainda, pela doce acolhida, pertinho da PUC. Agradeço a minhas orientadoras
Clarisse e Simone pela paciência e pela dedicação. Agradeço à Patrícia, ao Bazílio, à Geiza,
ao Anselmo, ao Dadá, à Lene e ao Rodrigo pelos momentos agradáveis que passamos juntos
na PUC. À Patty e ao Baz agradeço em especial, pela impressão, encadernação e distribuição
das cópias desta dissertação. Agradeço a turma *.93 e agregados pela amizade e pelas
manifestações de incentivo e emissões de bons fluídos em todos os momentos. Agradeço a
todos os membros do SERG, pelo incentivo constante, pelas sugestões a este trabalho e
sobretudo por fazerem com que este seja um grupo do qual é gratificante ser membro.
Agradeço especialmente à Cecília por me "emprestar seu tempo" durante um dia inteiro para a
realização de testes e por suas inteligentes sugestões. Agradeço à Raquel, também por ter me
"emprestado" seu tempo, me introduzindo seu trabalho. Agradeço à Milene, à Lúcia, à
Claudia, à Clarissa e ao Elton pelo apoio constante. A estes dois últimos agradeço ainda pelos
empréstimos de materiais importantíssimos para o desenvolvimento deste trabalho. Agradeço
à Rosane da biblioteca do D.I., pelas diversas vezes em que me ajudou a conseguir fontes
bibliográficas utilizadas neste trabalho, sempre com muita boa vontade e dedicação. Agradeço
ao senhor Fernando Anysio Dias, pelo incentivo e pela ajuda em tarefas do dia a dia.
Agradeço à vovó Olga e ao tio Lourenço que sempre estiveram presentes. Agradeço a CAPES
pelo apoio financeiro.
Resumo
Diante da existência de diversas abordagens complementares que visam contribuir
para apoiar o design de interação homem-computador, é oportuno aproveitar o que algumas
delas têm de melhor para tratar questões que não tenham sido muito exploradas. A escassez
de pesquisa sobre modelagem em níveis de abstração situados entre a tarefa e a interface e o
fato de que, apesar do constante surgimento de novas tecnologias, os modelos existentes
privilegiam estilos de interfaces e dispositivos físicos específicos, tornam interessante
investigar a modelagem em um nível de abstração intermediário, que enfoque representações
menos dependentes das tecnologias de implementação. Um nível de abstração que represente
as possíveis conversas travadas entre usuário e sistema, ao qual denominamos nível de
interação, nos parece satisfazer estes requisitos. Acreditamos que a conversa pode
representar a execução de um sistema computacional interativo, independentemente da
tecnologia de implementação da interface, pois, na verdade, esta execução consiste sempre na
troca de informações entre este sistema e o(s) usuário(s). Mediante o reconhecido valor de
cenários como ferramentas de design, apresentamos neste trabalho um modelo para a
especificação de cenários neste nível de abstração pouco explorado. Como a maioria dos
modelos para a especificação de cenários é voltada para seu uso na elicitação de requisitos, a
parte do processo de design que enfoca a comunicação dos usuários/clientes para o designer,
nos concentramos em explorar a utilização de cenários no sentido contrário desta
comunicação. Seguimos a abordagem proposta pela Engenharia Semiótica, que considera a
aplicação como uma mensagem do designer para o usuário, propomos um modelo para a
especificação de cenários de interação como parte do conteúdo desta mensagem.
Abstract
Since there are many complementary approaches that aim to contribute to support
human-computer interaction design, it is worth use the best of some of them to treat questions
less explored. The lack of research about modeling in abstraction levels intermediary between
task and interface levels in addition with the fact that despite of the constant development of
new technologies the existing models privilege specific interface styles and I-O devices make
interesting the investigation of modeling in an abstraction level intermediary between task and
interface, that focus on representations less dependent of implementation technologies. An
abstraction level that represents the possible conversations between user and system, which
we call interaction level, seems to satisfy those requirements. We believe that the
conversation can represent an interactive system execution, independently of the interface
implementation technology, because, in fact, this execution always consists in the information
exchange between this system and its user or group of users. By means of the recognized
value of scenarios as design tools, in this work we present a scenario specification model in
this abstraction level little explored. As the majority of the scenario specification models are
more concerned with the use of scenarios on requirements elicitation activities, the design
process part that focus on user/client to designer communication, we concentrate on exploring
the use of scenarios on the other side of this communication. Following the Semiotic
Engineering approach, which considers that software applications are messages, sent from
designers to users, we propose a model for the specification of scenarios as part of the content
of these messages.
iv
- Sumário -
Lista de Figuras ................................................................................................................................ ix
Lista de Tabelas ................................................................................................................................x
Capítulo 1 – Introdução ...................................................................................................................11.1 Motivações ............................................................................................................................ 11.2 Objetivos .............................................................................................................................. 31.3 A Organização da Dissertação ...............................................................................................4
Capítulo 2 -Trabalhos Relacionados ...............................................................................................62.1 Abordagens Fundamentadas na Psicologia Cognitiva ...........................................................6
2.1.1 CLG .............................................................................................................................82.1.2 TAG ............................................................................................................................ 92.1.3 Modelos da Família GOMS ........................................................................................102.1.4 UAN ............................................................................................................................12
2.2 Abordagens fundamentadas na Engenharia de Software ...................................................... 142.2.1 Cenários de Interação ..................................................................................................152.2.2 Design Patterns ...........................................................................................................19
2.3 Abordagens fundamentadas na Semiótica .............................................................................202.3.1 A Engenharia Semiótica ............................................................................................. 21
Um modelo e um formalismo de apoio à expressão da mensagem do designer ........ 22
Capítulo 3 - Um Modelo para a Especificação de Cenários de Interação ...................................243.1 Interação ................................................................................................................................243.2 Componentes do Modelo Proposto para a Especificação de Cenários de Interação .............24
3.2.1 Representação de cursos típicos ..................................................................................27Tarefa .......................................................................................................................... 28Diálogo ........................................................................................................................29Enunciado de Usuário .................................................................................................29Enunciado de Sistema .................................................................................................29Conceito da Aplicação ................................................................................................ 30Resumo dos componentes propostos para a representação de cursos típicos .............31Tipos de Articulação para Estruturas de Diálogos e de Enunciados .......................... 31Controles de Ocorrência de Diálogos ......................................................................... 33
3.2.2 Representação de cursos de exceção ...........................................................................33Fornecimento de informação inválida realizado pelo usuário .................................... 34Falhas de execução do sistema ................................................................................... 36Falhas da organização .................................................................................................38Resumo dos componentes propostos para representar cursos de exceção ..................38
3.2.3 Representação de cursos alternativos ..........................................................................39O estado da aplicação no momento da interação ........................................................39Possibilidades de escolha disponibilizadas para o usuário, pelo designer ..................46Possibilidade de interrupção e de posterior retomada de passos de tarefas ................47Resumo dos componentes propostos para representar interações alternativas ...........48
3.2.4 Componentes necessários para representar aplicações multi-usuário ..........................49
v
Capítulo 4 - Tipos Semânticos de Tarefas, Diálogos e Enunciados ............................................. 514.1 Tipos Semânticos de Tarefas .................................................................................................51
4.1.1 Tipos Semânticos de Tarefas que Atuam sobre Objetos do Domínio ........................ 52Criação ........................................................................................................................ 52Edição ......................................................................................................................... 52Consulta a Informações ...............................................................................................53Comunicação ...............................................................................................................53Destruição.................................................................................................................... 53
4.1.2 Tipos Semânticos de Tarefas que Atuam sobre Processos ......................................... 53Planejamento ...............................................................................................................53Registro de Atividade ................................................................................................. 53Avaliação .................................................................................................................... 54Desativação .................................................................................................................54Encerramento .............................................................................................................. 54
4.2 Tipos Semânticos de Diálogos .............................................................................................. 544.2.1 Tipos Semânticos de Diálogos onde o Usuário é o Falante Predominante .................55
Diálogos para o Fornecimento de Informação ao Sistema ......................................... 56Diálogos para a Solicitação de Informação ao Sistema ..............................................56Diálogos para a Comunicação de Usuário ..................................................................57
4.2.2 Tipos Semânticos de Diálogos onde o Sistema é o Falante Predominante .................57Apresentação de Informação Referente ao Domínio ..................................................58Confirmação de Operação ...........................................................................................58Ajuda ...........................................................................................................................58Feedback .....................................................................................................................58Comunicação de Sistema ............................................................................................ 59
4.3 Tipos Semânticos de Enunciados ..........................................................................................594.3.1 Tipos Semânticos de Enunciados de Usuário ............................................................. 59
Enunciados para o Fornecimento de Informação ........................................................60Customização .........................................................................................................60Comunicação Interpessoal ..................................................................................... 61Fornecimento de Informação Referente ao Domínio ............................................ 61
Enunciados para Controle da Interação ...................................................................... 61Mudança de Tópico ............................................................................................... 61Controle de Função ................................................................................................62Controle do Diálogo .............................................................................................. 62Controle do Fluxo da Tarefa ..................................................................................63
Enunciados para Solicitação de Informação ...............................................................64Solicitação de Detalhes ..........................................................................................64Solicitação de Ajuda .............................................................................................. 65
Sobreposição de Tipos Semânticos de Enunciados de Usuário ..................................654.3.2 Tipos Semânticos de Enunciados de Sistema ............................................................. 66
Solicitação de Informação ...........................................................................................67Apresentação de Informação Referente ao Domínio ..................................................67Aposto .........................................................................................................................67Informação Contextual ................................................................................................68Ajuda ...........................................................................................................................68Feedback .....................................................................................................................68Parêntese ..................................................................................................................... 69Comunicação de Sistema ............................................................................................ 69
vi
Comunicação de Usuário Remoto .............................................................................. 69Sobreposição de Tipos Semânticos de Enunciados de Sistema ..................................69
4.4 Sugestões para o mapeamento entre os tipos semânticos ..................................................... 704.4.1 Templates sugeridos para especificar tarefas ..............................................................71
Template para a especificação de tarefas do tipo Criação .......................................... 71Explicação ..............................................................................................................71
Template para a especificação de tarefas do tipo Edição ............................................72Explicação ..............................................................................................................72
Template para a especificação de tarefas do tipo Consulta a Informações .................73Explicação ..............................................................................................................73
Template para a especificação de tarefas do tipo Comunicação .................................74Explicação ..............................................................................................................74
Template para a especificação de tarefas do tipo Destruição ou Desativação ............74Explicação ..............................................................................................................75
Template para a especificação de tarefas do tipo Planejamento .................................76Explicação ..............................................................................................................76
Template para a especificação de tarefas do tipo Avaliação .......................................76Explicação ..............................................................................................................77
Template para a especificação de tarefas do tipo Encerramento ................................ 77Explicação ..............................................................................................................78
4.4.2 Templates Sugeridos para Representar Diálogos ........................................................79Template para a especificação de diálogos do tipoFornecimento de Informação Referente ao Domínio ..................................................79
Explicação ..............................................................................................................80Template para a especificação de diálogos do tipo Seleção ....................................... 81
Explicação ..............................................................................................................82Template para a especificação de diálogos do tipo Controle de Função .................... 82
Explicação ..............................................................................................................82Template para a especificação de diálogos do tipo Customização ............................. 83Template para a especificação de diálogos do tipo Solicitação de Informação ..........83Template para a especificação de diálogos do tipoComunicação de Usuário Síncrona .............................................................................83
Explicação ..............................................................................................................84Template para a especificação de diálogos do tipoComunicação de Usuário Assíncrona ......................................................................... 85
Explicação ..............................................................................................................85Template para a especificação de diálogos do tipo Ajuda .......................................... 86
Explicação ..............................................................................................................86Template para a especificação de diálogos do tipo Comunicação de Sistema ........... 87
Explicação ..............................................................................................................87Template para a especificação de diálogos do tipo Feedback .................................... 88Template para a especificação de diálogos do tipoApresentação de Informações Referentes ao Domínio ...............................................88
Explicação ..............................................................................................................88Template para a especificação de diálogos do tipo Confirmação de Operação ..........88
Explicação ..............................................................................................................89
vii
Capítulo 5 - Uma Linguagem para a Especificação de Cenários de Interação .......................... 905.1 Notação Utilizada para a Definição da Sintaxe da LECI ......................................................905.2 Representação de Papéis de Usuário .....................................................................................905.3 Representação de Conceitos da Aplicação ............................................................................915.4 Representação de Enunciados de Usuário .............................................................................92
5.4.1 Representação de Enunciados para Fornecimento Informação .................................. 925.4.2 Representação de Enunciados para Controle da Interação e
Solicitação de Informação ...........................................................................................945.5 Representação de Enunciados de Sistema .............................................................................975.6 Representação de Estruturas de Articulação ......................................................................... 99
5.6.1 Representação de Articulações de Diálogos ................................................................ 1005.6.2 Representação de Articulações de Enunciados ............................................................ 102
5.7 Representação de Diálogos ................................................................................................... 1045.8 Representação de Tarefas ......................................................................................................1075.9 Representação de Interrupções ..............................................................................................1085.10 Representação de Contextos de Interação .............................................................................110
5.10.1Representação de Estruturas de Interação Dependentes de Contexto ........................ 1115.10.2Representação da Exclusividade entre Contextos de Interação ................................. 1135.10.3Representação de Relações entre contextos ............................................................... 115
União ...........................................................................................................................115Interseção .................................................................................................................... 116Subcontexto .................................................................................................................116Complementaridade .................................................................................................... 117
5.10.4Representação de Mudanças no Contexto de Interação Inicial do Diálogo devidas a Enunciados de Usuário ............................................................................................... 118
5.11 Representação de Estratégias para Tratamento de Erros de Usuário ....................................1195.12 Representação de Estratégias para Tratamento de Falhas de Sistema .................................. 1225.13 Reuso de Especificações ....................................................................................................... 124
5.13.1 Reuso de Especificações de Diálogos ........................................................................ 1245.13.2 Reuso de Especificações de Tarefas ...........................................................................126
5.14 Componentes Tecnológicos e Meta-Tecnológicos do Modelo de Interação ........................ 128
Capítulo 6 - Utilização Prática da LECI ....................................................................................... 1306.1 Estudo de Caso 1: Especificação de Cenários de Interação Reais na LECI ......................... 130
Tarefa 1: Criar Reunião .........................................................................................................130Curso Típico ................................................................................................................130Cursos de Exceção ...................................................................................................... 134
Tarefa 2: Editar Reunião ....................................................................................................... 134Curso Típico ................................................................................................................134Cursos de Exceção ...................................................................................................... 135
6.1.1 Especificação Passo a Passo dos Cenários de Interação na LECI .............................. 135Especificação dos Papéis de Usuário ..........................................................................135Especificação dos Conceitos da Aplicação .................................................................136Especificação dos Contextos de Interação ..................................................................136Especificação da Estrutura da Tarefa ..........................................................................137Especificação da Estrutura dos Diálogos ....................................................................139
6.2 Estudo de Caso 2: Utilização da LECI no Apoio à Especificação de AplicaçõesMulti-Tecnologia ...................................................................................................................1446.2.1 O designer pode decidir se quer manter os mesmos subtópicos .................................146
viii
Especificação da interação para Desktop ....................................................................147Especificação da interação para Telefone ...................................................................148
6.2.2 O designer pode decidir se quer manter os mesmos diálogos e contextosde interação ................................................................................................................. 148Especificação da interação para Desktop ....................................................................149Especificação da interação para Telefone ...................................................................149
6.2.3 O designer pode decidir se quer manter a seqüência da interação ............................. 149Especificação da interação para Desktop ....................................................................150Especificação da interação para Telefone ...................................................................151
6.2.4 Conclusões a Partir do Estudo de Caso .......................................................................1526.3 Estudo de Caso 3: Análise Comparativa entre a LECI e a LEMD ....................................... 153
6.3.1 Especificação de Papéis de Usuário e Restrições de Acesso a Funções ...................... 1536.3.2 Especificação de Conceitos da Aplicação ....................................................................1536.3.3 Especificação da Estrutura da Tarefa ...........................................................................1546.3.4 Especificação das Estruturas dos diálogos ...................................................................1556.3.5 Apoio à Especificação de Aplicações Multi-Tecnologia ............................................. 1566.3.6 Conclusões sobre a Análise Comparativa .................................................................... 156
Capítulo 7 - Conclusões ................................................................................................................... 1587.1 Contribuições e Limitações ...................................................................................................158
7.1.1 Modelo para a Especificação de Cenários de Interação ..............................................1587.1.2 Linguagem para a Especificação de Cenários de Interação ........................................159
Inserção de nosso trabalho na classificação realizada em [Rolland et al., 1996]........ 1597.2 Oportunidades para Trabalhos Futuros ................................................................................. 164
7.2.1 Identificação de padrões de design de interação e sua representação na LECI .......... 1647.2.2 Identificação de analogias entre padrões de design de interação dependentes de
tecnologias distintas e sua representação na LECI ..................................................... 1657.2.3 Determinação de Sistemas Expressivos e Regras de Correlação ................................1677.2.4 Incorporação de Controle de Evolução de Cenários ...................................................1687.2.5 Experimentos para avaliação de características da LECI ........................................... 169
Referências ........................................................................................................................................171
ix
- Lista de Figuras -
Figura 2.1: Sumário da notação UAN adaptado de [Griffiths] ........................................................ 13Figura 2.2: Exemplo de representação de uma interface de manipulação direta através da notação
UAN adaptado de [Griffiths] .........................................................................................13Figura 2.3: Cenário de interação descrito em linguagem natural estruturado da forma proposta
por Jacobson et al. em [Jacobson et al., 1992] .............................................................. 19Figura 3.1: Componentes do modelo de interação ...........................................................................27Figura 3.2: Comparação entre os níveis de abstração adotados por Leite [Leite, 1998] e
por este trabalho ............................................................................................................ 28Figura 3.3: Relações entre Contextos de Interação...........................................................................42Figura 3.4: Representação correta e errônea do contexto de interação "RNC não aberto pelo
supervisor, não devido à reclamação de cliente" utilizando a relação decomplementaridade ........................................................................................................46
Figura 3.5: A decomposição da tarefa "Criar proposta de contrato de prestação de serviços"em diálogos ....................................................................................................................48
Figura 4.1: Tipos semânticos de tarefas identificados ..................................................................... 52Figura 4.2: Tipos semânticos de diálogos identificados .................................................................. 55Figura 4.3: Tipos semânticos de enunciados de usuário identificados ............................................ 60Figura 4.4: A hierarquia de tipos semânticos de enunciados de sistema identificados ................... 67Figura 6.1: Capacidade que os dispositivos têm de permitir troca de informação de cada vez .......145Figura 7.1: Algumas operações evolutivas que podem vir a ser representadas utilizando-se
a LECI ........................................................................................................................... 169
x
- Lista de Tabelas -
Tabela 2.1: Questões consideradas nos níveis de abstração representados pelaCommand Language Grammar (CLG) ......................................................................... 8
Tabela 2.2: Classificação apresentada em [Rolland et al., 1996] para abordagensque utilizam cenários de interação ................................................................................ 17
Tabela 2.3: Componentes do meta-modelo para o modelo de usabilidade de Leite ........................ 23Tabela 3.1: Adaptações aos componentes do modelo de usabilidade identificados por Leite para a definição de componentes do modelo de interação ............................................ 31Tabela 3.2: A representação de tipos de articulação definidos em formalismos para a modelagem de tarefas através dos tipos de articulação adotados em nosso modelo ........................ 32Tabela 3.3: Componentes do modelo de interação identificados a partir da análise de fatores
que ocasionam cursos de exceção ................................................................................. 39Tabela 3.4: Componentes do modelo de interação identificados a partir da análise de fatores
que determinam possibilidades de interação alternativas ..............................................49Tabela 4.1: Sobreposições de tipos semânticos de enunciados de usuário identificadas
neste trabalho .................................................................................................................66Tabela 4.2: Sobreposições de tipos semânticos de enunciados de sistema identificadas
neste trabalho .................................................................................................................70Tabela 5.1: Identificadores para a representação de tipos semânticos de enunciados de usuário
para informação de valores de conceitos na LECI ........................................................ 93Tabela 5.2: Identificadores para a representação de controles de ocorrência de diálogos
na LECI ......................................................................................................................... 95Tabela 5.3: Identificadores para a representação de tipos semânticos de enunciados de usuário
para solicitação de informações e controle da interação na LECI .................................96Tabela 5.4: Identificadores para a representação de tipos semânticos de enunciados de sistema
na LECI ......................................................................................................................... 97Tabela 5.5: Identificadores para a representação de tipos de articulação na LECI ..........................100Tabela 5.6: Identificadores para a representação de tipos semânticos de diálogos na LECI ........... 105Tabela 5.7: Identificadores para a representação de tipos semânticos de tarefas na LECI .............. 107Tabela 5.8: Identificadores LECI para tipos de respostas do sistema para tratamento
de erros cometidos pelo usuário .................................................................................... 120Tabela 5.9: Identificadores das formas de encaixe para diálogos de correção na LECI .................. 120Tabela 5.10:Identificadores dos tipos de tratamento de falhas de sistema na LECI .........................122Tabela 7.1: Inserção deste trabalho na classificação apresentada em [Rolland et al., 1996]
para abordagens que utilizam cenários de interação ..................................................... 163
1
Capítulo 1
Introdução
Atualmente, uma interação humano-computador (IHC) de qualidade é considerada um
componente vital de sistemas computacionais bem sucedidos. Entretanto, o design de IHC
não é uma tarefa fácil. Segundo Preece et al., isto pode ser provado por muitos sistemas
computacionais mal projetados [Preece et al., 1993]. Várias abordagens, baseadas nas mais
diversas áreas do conhecimento, visam contribuir para o estabelecimento de métodos e
técnicas que possam apoiar o design de IHC. Neste trabalho, procuramos participar deste
esforço de pesquisa seguindo a Engenharia Semiótica [de Souza, 1993] para propor um
modelo para a especificação de cenários de interação. Na seção 1.1 apresentamos as
motivações deste trabalho, na seção 1.2, seus objetivos e na seção 1.3 sua organização.
1.1 Motivações
Um dos fatores que tornam o design de interação humano-computador uma tarefa
difícil é a inexistência de um método estruturado e preciso para o mapeamento entre as tarefas
que o usuário deverá realizar utilizando a aplicação e uma interface adequada para esta
realização. De fato, a própria natureza do processo de design de sistemas computacionais
dificulta bastante a existência deste tipo de método. O processo de design de sistemas
computacionais (incluindo o design de IHC) pode ser descrito como um processo de
comunicação entre designers e usuários, composto por vários ciclos. Em cada ciclo os
usuários comunicam seus requisitos aos designers e estes comunicam sua solução ao
problema dos usuários sob a forma de aplicação computacional [de Souza, 1993]. Ao interagir
com a aplicação, os usuários percebem novos requisitos1 e os comunicam aos designers,
iniciando um novo ciclo. A natureza cíclica e dinâmica deste processo sugere que o
mapeamento tarefa-interface não pode ser fechado e é isto que dificulta o estabelecimento de
um método preciso para a realização deste mapeamento.
1 Isto pode ser explicado pelo fenômeno da Semiose Ilimitada [Peirce, 1931], que ocorre quando um signo
desencadeia uma seqüência ilimitada de interpretações na mente de quem o interpreta. Uma definição simples
para signo é "algo que representa uma outra coisa para alguém". A Engenharia Semiótica considera que a
interface é um signo para o usuário e que, durante a interação, desencadeia interpretações em sua mente, que o
levam a identificar ou a criar requisitos não percebidos previamente.
2
Apesar da inexistência de métodos precisos para a realização do mapeamento tarefa-
interface, diversas abordagens têm contribuído para apoiar a realização deste mapeamento
(como será visto no capítulo 2). Apesar de estas abordagens pregarem a estruturação do
design em níveis de abstração, desde o nível de tarefa até o de interface, a maioria dos
esforços de pesquisa são voltados para a representação ou da tarefa [UML, 1999],
[Lawrence, 1997] ou da interface [Moran, 1981], [Card, 1983], [Hix, 1993], [Leite, 1998].
Aqueles que privilegiam a interface, muitas vezes, são voltados, principalmente, para
determinados estilos de interface e determinados dispositivos de entrada e saída. Quanto ao
foco de representação, muitas abordagens enfocam apenas o ponto de vista do usuário
[Moran, 1981], [Card et al., 1983] ou o do sistema [Jacob, 1986], [Harel, 1987]. Outras
abordagens para o design de interfaces enfocam ambos os pontos de vista [Nadin, 1988],
[Andersen, 1990], [Hix, 1993], [de Souza, 1993], [Carroll, 1995], [Kotonya, 1998]. Dentre
elas, está a Engenharia Semiótica [de Souza, 1993], que vê o sistema como um "mensageiro"
do ponto de vista do designer, pois considera a aplicação como uma mensagem do designer
para o usuário, expressa através da interface. Enquanto a Engenharia Semiótica se preocupa
com a expressão da mensagem do designer, a Engenharia de Requisitos [Kotonya, 1998] se
preocupa com a expressão dos requisitos dos usuários. Ferramentas bastante utilizadas por
esta abordagem são os cenários [Carroll, 1995]. Carroll define cenário como "uma descrição
narrativa do que as pessoas fazem e experimentam enquanto tentam utilizar sistemas de
computadores e aplicações."2 [Carroll, 1995]. Em [Carroll, 1995] e [Carroll, 2000], indica-se
como cenários podem ser utilizados nas diversas fases do processo de design e apresentam-se
inúmeras vantagens desta utilização. Uma destas vantagens é justamente o fato de que
cenários podem ser usados como língua franca para a comunicação entre usuários e equipes
de designers, beneficiando sobretudo as equipes multi-disciplinares, tão comuns, devido à
própria natureza da atividade de design de IHC.
Diante da existência de diversas abordagens complementares que visam contribuir
para apoiar o design de IHC, é oportuno aproveitar o que algumas delas têm de melhor para
tratar questões que não tenham sido muito exploradas. A escassez de pesquisa sobre
modelagem em níveis de abstração intermediários entre a tarefa e a interface e o fato de que,
apesar do constante surgimento de novas tecnologias, os modelos existentes privilegiam
estilos de interfaces e dispositivos físicos específicos, tornam interessante investigar a
2 Carroll frisa que esta descrição não precisa ser feita de forma textual.
3
modelagem em um nível de abstração intermediário, que enfoque representações menos
dependentes das tecnologias de implementação. O nível de abstração no qual é representada a
conversa travada entre usuário e sistema, ao qual denominamos nível de interação, nos
parece vir ao encontro desta oportunidade. A conversa pode representar a execução de um
sistema computacional interativo, independentemente da tecnologia de implementação da
interface, pois, na verdade, esta execução consiste sempre na troca de informações entre este
sistema e o(s) usuário(s). Mediante o reconhecido valor de cenários como ferramentas de
design, é oportuna a realização de esforços para o estabelecimento de modelos que apóiem a
sua especificação neste nível de abstração pouco estudado. Como a maioria dos modelos para
a especificação de cenários é voltada para seu uso na elicitação de requisitos, a parte do
processo de design que enfoca a comunicação dos usuários para o designer, é interessante
explorar a utilização de cenários no sentido contrário desta comunicação: a expressão da
mensagem do designer para os usuários. Ao enfocar justamente este aspecto do processo de
design, a Engenharia Semiótica pode ser aplicada para a definição de um modelo para a
especificação estruturada de cenários de interação como parte do conteúdo da mensagem do
designer para os usuários. A utilização de um modelo para a especificação estruturada de
cenários de interação em termos de componentes bem definidos poderá conscientizar
designers acerca de informações que devem ser especificadas, evitando que algumas
necessidades de especificação passem despercebidas, o que é comum quando não se segue um
modelo estruturado. A representação de cenários no nível de interação traz vantagens como:
(1) a representação de um conjunto mais abrangente de interfaces, implementáveis em
diversos estilos e tecnologias; (2) o reuso de parte de uma mesma especificação para a
modelagem de interfaces em diferentes ambientes tecnológicos (3) o não comprometimento
precoce com decisões de design de interface; (4) a detecção de problemas de interface mais
cedo no processo de design. Ante ao exposto, acreditamos que o modelo a ser apresentado
neste trabalho traga alguns benefícios relevantes para a tarefa de design de IHC.
1.2 Objetivos
O objetivo deste trabalho é apresentar um modelo para a especificação de cenários de
interação. Seguindo a proposta da Engenharia Semiótica, o modelo propõe a estruturação de
cenários de interação em termos de componentes necessários para sua representação como
parte do conteúdo da mensagem do designer. Utilizamos a comunicação como paradigma e
4
pretendemos apoiar a especificação de cenários que descrevam as conversas que podem ser
travadas entre usuário e sistema (como porta-voz do designer) para que o primeiro realize
tarefas utilizando o segundo como ferramenta. Desta forma, propomos a estruturação de
cenários de interação em três níveis de articulação: tarefa, diálogo e enunciados. Para a
especificação de cenários de interação estruturados de acordo com o modelo proposto,
apresentamos ainda um formalismo. Para auxiliar designers a especificar cenários de
interação consistentes e de maior qualidade, através do formalismo proposto, descrevemos
conjuntos de tipos semânticos de tarefas, diálogos e enunciados e sugerimos mapeamentos
preferenciais entre estes tipos.
Visando obter resultados práticos, definimos o modelo, o formalismo e os conjuntos
de tipos semânticos propostos, considerando nossa experiência no desenvolvimento de um
sistema real, o Qualitas. Este é um sistema de workflow baseado na web desenvolvido pelo
TeCGraf [TECGRAF], laboratório de pesquisa da PUC-Rio, em parceria com a SUSEMA,
Superintendência de Segurança e Meio Ambiente da PETROBRAS. A função do sistema é
auxiliar os funcionários da SUSEMA a prestar seus serviços de acordo com as normas de
qualidade vigentes na organização. O Qualitas foi escolhido por ser uma aplicação de
workflow, que nos permite não apenas analisar as tarefas de um único usuário, mas também
tarefas que envolvem o trabalho em grupo. Assim, esperamos englobar muitos casos com a
análise deste sistema.
1.3 A Organização da Dissertação
No capítulo 2 introduziremos algumas abordagens que contribuem para o design da
interação, fundamentadas na Psicologia Cognitiva, na Engenharia de Software (em especial
cenários) e também na Semiótica, incluindo a Engenharia Semiótica. O capítulo 3 descreverá
o modelo para a especificação de cenários de interação como parte do conteúdo da mensagem
do designer. O capítulo 4 apresentará os conjuntos de tipos semânticos de tarefas, diálogos e
enunciados propostos neste trabalho e nossas sugestões para o mapeamento entre estes tipos
semânticos, elaboradas para auxiliar designers a especificar cenários de interação de maior
qualidade, através do formalismo proposto. O capítulo 5 descreverá a Linguagem para a
Especificação de Cenários de Interação (LECI), proposta com base em nosso modelo. O
capítulo 6 apresentará estudos de caso realizados para ilustrar a utilização prática da LECI na
5
especificação de cenários de interação. O capítulo 7 apresentará as contribuições deste
trabalho para o apoio ao design da interação e as oportunidades para trabalhos futuros.
6
Capítulo 2
Trabalhos Relacionados
Neste capítulo introduzimos trabalhos que visam contribuir para o estabelecimento de
técnicas e métodos para o design de interação humano-computador. A seção 2.1 apresenta
abordagens fundamentadas na Psicologia Cognitiva. A seção 2.2 apresenta abordagens
fundamentadas na Engenharia de Software, em especial, a utilização de cenários. A seção 2.3
apresenta abordagens fundamentadas na Semiótica, em especial a Engenharia Semiótica.
2.1 Abordagens Fundamentadas na Psicologia Cognitiva
A maioria das abordagens para o design de interfaces se baseiam na Psicologia
Cognitiva [Neisser, 1967]. Estas abordagens consideram que os usuários formulam um
modelo mental do sistema, o qual lhes permite mapear suas metas para comandos e funções e
para as ações físicas necessárias para o seu acionamento [Norman, 1986]. Desta forma, estas
abordagens propõem que as propriedades que os modelos de interação devem ter, para que a
interação possa ser desempenhada facilmente, devem ser identificadas com base em modelos
cognitivos que descrevam como funcionam os processos1 e estruturas mentais do usuário.
Assim, têm surgido uma variedade de técnicas, baseadas em modelos cognitivos, para a
análise da tarefa, que é o "processo de investigar um problema, quebrando tarefas que um
usuário potencial de um sistema faz ou faria em seqüências de ações e objetos."
[Preece et al., 1993]. Estas técnicas costumam ser aplicadas para solucionar diversos
problemas relacionados ao design de IHC, dentre os quais destacamos:
1. a previsão/avaliação da facilidade de aprendizado de um sistema,
2. a previsão/avaliação das dificuldades de uso de uma interface,
3. a previsão/avaliação da performance e da complexidade de um sistema,
4. mapeamento das tarefas para a interface e
5. a síntese (criação) de interfaces.
1 Tais como interpretação, aprendizado, recordação e planejamento.
7
As técnicas baseadas na Psicologia Cognitiva resolvem os tipos de problemas
relacionados nos 3 primeiros itens, estimando como os usuários realizarão/realizam tarefas
usando o sistema, em termos de suas operações perceptivas, cognitivas e motoras. A partir
destas estimativas, os designers podem prever:
• o esforço cognitivo requerido para o aprendizado do modelo de interação,
• os esforços cognitivo e físico requeridos para o uso do sistema e
• o tempo gasto na realização das tarefas.
Técnicas de análise de tarefa empregadas para prever ou avaliar a qualidade de
interfaces, costumam ser usadas também como técnicas para o mapeamento de tarefas para
interfaces e para síntese destas. Estas técnicas auxiliam o designer a tomar decisões de design
duas formas:
• através da estimativa da qualidade de designs de interface alternativos para a
comparação entre estes designs;
• através de guidelines [Smith, 1986], que são pequenas regras heurísticas que têm o
propósito de capturar o conhecimento de design e que podem então ser usadas
para ajudar designers na construção de novas interfaces [van Welie et al., 2000].
A estimativa da qualidade de designs de interface alternativos pode até auxiliar na
escolha do melhor destes designs, mas de forma alguma garante que o design escolhido é um
design adequado para a tarefa que está sendo modelada. Quanto à utilização de guidelines
como ferramentas para guiar um bom design de interface, relata-se freqüentemente que esta
utilização apresenta vários problemas [Dix, 1998], [Mahemoff, 1998]. Segundo
[van Welie et al., 2000] alguns destes problemas são:
• guidelines são, freqüentemente, ou muito simplificadas ou muito abstratas;
• guidelines são, usualmente, numerosas e é difícil selecionar as que se aplicam a um
problema de design particular;
• guidelines podem ser difíceis de interpretar;
• guidelines podem ser conflitantes;
8
• a validade e a aplicação de guidelines sempre dependem de um contexto e raras
vezes esse contexto é especificado.
Em resumo, as abordagens baseadas na Psicologia Cognitiva permitem ao designer
identificar as propriedades que boas interfaces devem apresentar, entretanto, não
oferecem meios eficazes para a produção de interfaces com estas propriedades. O design
de uma boa interface, quando apoiado por estas abordagens, ainda permanece muito
dependente do talento do designer. Nas próximas seções introduziremos brevemente alguns
dos formalismos propostos com base em abordagens fundamentadas na Psicologia Cognitiva.
2.1.1 CLG
A CLG, Command Language Grammar [Moran, 1981], é um formalismo antigo
voltado principalmente para a modelagem de interfaces com estilo linguagem de comando.
Este formalismo apresenta uma notação para a representação do design da interface através de
três componentes: o componente conceitual, o componente de comunicação e o componente
físico. Cada um destes componentes é representado em dois níveis de abstração, claramente
distinguíveis entre si, e cada nível representa um refinamento do nível anterior. O componente
conceitual é representado no nível de tarefa e no nível semântico. O componente de
comunicação compreende os níveis sintático e de interação. O componente físico é
representado nos níveis de layout e de dispositivos. Em cada nível de abstração é feita uma
descrição completa do sistema a partir da perspectiva do nível. A tabela 2.1 sumariza as
questões consideradas em cada nível de abstração.
Componente Nível de Abstração Questões ConsideradasComponenteConceitual
Tarefa O que a análise de tarefas diz que os usuáriosdesejarão fazer?
Semântica Que objetos, ações e métodos são necessáriospara a realização de cada sub-tarefa?
Componente deComunicação
Sintaxe Como deveria ser o diálogo e a apresentação deinformações?
Interação Quais deveriam ser as entradas e saídas exatas,utilizando-se um dispositivo de entrada X e umdispositivo de saída Y?
ComponenteFísico
Layout Qual deve ser o layout da interface?
Dispositivos Que dispositivos devem ser usados?Tabela 2.1: Questões consideradas nos níveis de abstração representados pela CommandLanguage Grammar (CLG).
9
Algumas vantagens da CLG são os fatos de que ela permite o design estruturado de
interfaces em níveis de abstração e fornece regras para a realização do mapeamento entre
estes níveis, permitindo a verificação da consistência entre eles. Entretanto, foram realizados
estudos que indicam que o formalismo efetivamente não guia o designer na produção de
designs de qualidade [Sharratt, 1987a], [Sharratt, 1987b]. Sharratt descreve um experimento
no qual a CLG foi usada por alguns alunos de pós-graduação para o design de um sistema
para o controle do horário de transportes (transport timetabling system). O estudo mostrou
uma grande variedade de designs produzidos. Isto parece indicar que a CLG funciona apenas
como notação, não oferecendo grande suporte às decisões de design, pois, apesar de ter sido
usada como ferramenta de suporte ao design, por todos os alunos, estes produziram designs
bastantes distintos. Nestes estudos, Sharratt também nota dificuldades no uso da CLG e
declara que "se estas dificuldades aparecem até mesmo em áreas de design como um sistema
para o controle do horário de transportes, não há muitas razões para supor que a CLG poderia
ajudar substancialmente nas decisões para o design de sistemas complexos.". Em [Firth, 1991]
é apresentado detalhadamente um exemplo de aplicação da CLG para descrição da interface
do utilitário NotePad do Macintosh. Esta especificação revelou falhas no projeto, que não
tinham sido previstas, e resultou numa reestruturação no nível de tarefa.
2.1.2 TAG
A TAG (Task-Action Grammar) [Payne & Green, 1986] é uma meta-linguagem para a
representação do modelo mental que o usuário cria sobre linguagens para a descrição de
tarefas. Assim coma a CLG, ela enfoca a representação de interfaces com estilo linguagem de
comando. A TAG foi criada para atacar o problema de consistência, pois seus idealizadores
acreditam que especificações consistentes implicam em interfaces mais fáceis de aprender e
usar. Reisner, em [Reisner, 1981], propôs uma gramática de ações para descrever duas
versões da interface de um mesmo sistema e mostrou que a versão que tinha uma gramática
mais simples era mais fácil de aprender.
Os pontos fortes da TAG são os fatos de que ela é um formalismo que permite
elaboração de linguagens de comandos a partir de modelos de tarefas [Payne & Green, 1986]
e apresenta uma boa solução para o problema da consistência, possibilitando a representação
de uma gramática que generaliza a sintaxe de um conjunto de comandos. Como pontos fracos
podemos citar que a TAG não permite a representação de saída de informações (output),
10
somente entrada (input), embora a DTAG (Display-based TAG) [Howes, 1990] seja uma
extensão da TAG que já permite a representação de output. Outro ponto fraco é que a TAG
não apresenta uma estrutura de níveis de abstração bem definida, com a CLG. Para fazer face
a isto, a extensão ETAG (Extended Task-Action Grammar) [de Haan, 2000] estrutura a TAG
com os níveis apresentados pela CLG e adiciona alguns refinamentos.
2.1.3 Modelos da Família GOMS
O GOMS [Card et al., 1983] é um modelo que representa as atividades perceptivas,
cognitivas e motoras realizadas pelo usuário durante a interação com sistemas em termos dos
seguintes componentes:
• Metas (Goals): definem estados de desejos a serem realizados e um conjunto de
métodos possíveis para esta realização.
• Operadores (Operators): são ações perceptivas, cognitivas e motoras elementares,
cuja execução é necessária para mudar algum aspecto do estado mental do usuário
ou para afetar o ambiente de execução da tarefa. Os operadores definidos no
modelo GOMS são voltados para a representação de interfaces baseadas em
dispositivos físicos de entrada como o teclado e o mouse e de saída, como o
monitor.
• Métodos (Methods): descrevem um procedimento para se alcançar uma meta. Um
método consiste de um conjunto de operadores;
• Regras de Seleção (Selection Rules): uma regra de seleção funciona como um
controle para seleção quando existem métodos alternativos para o alcance de uma
mesma meta. Essas regras possuem a seguinte forma:
“se <tais condições na situação atual da tarefa são satisfeitas>
então <use o método M>”.
A abordagem GOMS para a modelagem de usuários tem pontos fortes e fracos. Como
ponto forte há o fato de que ela possibilita a previsão dos melhores casos de utilização do
sistema sem ter que treinar usuários para usá-lo e realizar testes de usabilidade com eles.
Além disso, permite a comparação entre designs alternativos e a identificação de problemas
11
de usabilidade. Entretanto Card et al. [Card et al., 1980] admitem várias fraquezas do GOMS,
das quais destacamos:
1. o modelo só pode ser aplicado para usuários experts na aplicação, não servindo
para modelar a interação de iniciantes ou intermediários.
2. Até usuários experts cometem erros ocasionalmente; entretanto, o modelo não
representa erros. Segundo Bodnar, et al. [Bodnar et al., 1996], estudos revelaram
que usuários experts gastam até 25% do seu tempo de uso de um sistema,
cometendo erros ou se recuperando de erros.
3. Diferenças individuais entre usuários não são consideradas no modelo.
4. o modelo não considera o aprendizado do sistema ou a recordação de como usá-lo
após um período de desuso.
5. Direção para a previsão de se usuários vão julgar o sistema útil ou satisfatório ou
se o sistema será globalmente aceito não está incluída no modelo.
6. o modelo não trata o impacto social ou organizacional do sistema ou a influência
deste impacto na produtividade.
7. o modelo não trata funcionalidade, ou seja, que tarefas deveriam ser realizadas
pelo sistema. O modelo considera apenas a usabilidade de uma tarefa em um
sistema.
Além destas fraquezas, há o fato de que o objetivo do GOMS é representar apenas
tarefas seqüenciais que possam ser descritas em termos de uma estrutura hierárquica de metas
e sub-metas. Tarefas que envolvam processamento paralelo ou não tenham hierarquia bem
definida não são boas candidatas para modelagem GOMS. Por exemplo, em uma interface de
manipulação direta, é comum a exploração de possibilidades durante a execução de uma
tarefa e não a elaboração e o prosseguimento de um plano. Segundo [Bodnar et al., 1996] o
GOMS apresenta ainda, deficiências para ser usado na modelagem de sistemas baseados em
novas tecnologias, pois além de poder não existir usuário expert para estes sistemas, os
operadores empregados pelo usuário e o aprendizado durante a interação com estes sistemas
podem ser imprevisíveis. Por fim, alguns pesquisadores fazem críticas também à notação do
GOMS. Kieras comenta que esta notação é difícil de usar [Kieras, 1988] e Bodnar et al.
12
[Bodnar et al., 1996] a declaram restritiva e que o seu uso para a modelagem manual de um
grande conjunto de tarefas consome muito tempo.
Algumas extensões foram feitas, na tentativa de resolver problemas identificados no
GOMS. CMN-GOMS (Card, Moran and Newel GOMS) [Card et al., 1983] é mais específico
que o GOMS, com uma rigorosa hierarquia de metas. NGOMSL (Natural GOMS Language)
[Kieras, 1988] faz previsões de tempo de aprendizado e refina o CMN-GOMS, fornecendo
um formato estruturado para sua especificação em linguagem natural. CPM-GOMS
(Cognitive Perceptual Motor GOMS) [John, 1990] estende o CMN-GOMS para tratar
atividades concorrentes.
2.1.4 UAN
UAN (User Action Notation) [Hix, 1993] é uma notação para a representação de
interfaces de manipulação direta assíncronas, orientada ao mesmo tempo a usuário e a tarefa.
A notação permite a decomposição de tarefas em vários níveis de sub-tarefas até chegar a
ações físicas realizadas para a interação com o sistema. No nível mais baixo, as ações são
representadas em tabelas que as relacionam com os conseqüentes feedback do sistema e
mudanças do estado da interface. Além disso, a UAN permite a representação de relações
temporais entre sub-tarefas, como seqüência, intercalação e concorrência. As descrições do
design produzidas na notação são associadas a cenários (representados por seqüências de
desenhos), diagramas de estado e notas sobre decisões de design. A notação inicial foi
proposta com o objetivo de se representar interfaces de manipulação direta, mas é aberta para
extensões. A figura 2.1 apresenta um sumário da notação original proposta e a figura 2.2
apresenta um exemplo de especificação de interface em UAN. A tabela apresentada descreve
que para selecionar um arquivo arqX, o usuário deve mover o cursor até o ícone que
representa o arquivo, pressionar e liberar o botão do mouse.
13
Figura 2.1: Sumário da notação UAN adaptado de [Griffiths].
Tarefa: selecionar o arquivo arqXAções do Usuário Feedback do Sistema Estado da Interface
~[ícone de arqX.'] Mvícone de arqX.'!¥ ícone de arqX.* ícone de arqX.' :ícone do arq.-!
arquivo selecionado = arqX
M^
Figura 2.2: Exemplo de representação de uma interface de manipulação direta através danotação UAN adaptado de [Griffiths].
UAN é uma das primeiras notações baseadas na Psicologia Cognitiva que foi projetada
com a consciência de que o design da interface deve ser representado também sob o ponto de
vista do comportamento do sistema e não somente sob o ponto de vista do comportamento do
usuário. Além disso, este é um dos primeiros trabalhos a considerar a importância do fato de
que o modelo design é criado pelo designer, conforme mostra a seguinte declaração em
Objetos e AçõesM = mousev = pressionamento (mouse)^ = liberação (mouse)[ objeto ] = contexto físico de objeto, ex. [linha] ponto médio~ = mover o cursorK = informação de um caracter (teclado/voz)K”comando” = representa o comando literal comandoK(variavel) = variavel é uma variávelK(user ID = [A-Z] [A-Z 0-9] +) = uso de expressão regular para restringir a entrada
Feedbackícone de arq. ! = ícone de arq. acende.ícone de arq -! = ícone de arq apaga.ícone da aplicação!! = ícone daaplicação acende de forma diferentedifferently
Mais FormalismoUso de Lógica:¥ = para todo¬ = negação= igual* diferenteícone’ = ícone está selecionadocaixa > ~ = caixa segue o cursoração* = ação é repetida 0 ou mais vezesação+ = ação é repetida 1 ou mais vezesação+N = ação é repetida N vezes
14
[Hix, 1993]: "A UAN foi proposta para ser escrita primeiramente por alguém projetando o
componente de interação e para ser lida por todos desenvolvedores, particularmente por
aqueles que estão projetando e implementando o software de interface de usuário". Em
relação aos formalismos apresentados anteriormente, UAN ainda apresenta a vantagem de ser
um único formalismo capaz de representar tarefas seqüenciais e concorrentes, hierárquicas ou
não e os estilos de linguagem de comando e de manipulação direta.
2.2 Abordagens fundamentadas na Engenharia de Software
As primeiras abordagens para o design de interfaces apresentadas por pesquisadores da
área de Engenharia de Software visavam estabelecer modelos para a representação formal do
comportamento da interface. Estas abordagens [Jacob, 1986], [Harel, 1987], [Harisson, 1994]
propõem a representação formal da interface através de Diagramas de Transição de Estados
(DTE). O uso de DTE para a representação de interfaces foi proposto inicialmente em
[Jacob, 1986]. Entretanto, alguns trabalhos revelaram que certas características da interação
não podiam ser representadas de forma satisfatória por este formalismo [Green, 1986],
[Foley et al., 1990], [Shneiderman, 1992]. Embora os DTEs sejam efetivos para representar
o fluxo de ações de uma interação, eles podem facilmente se tornar grandes e confusos. Esta
confusão geralmente acontece quando cada estado deve apresentar transições para estados de
help, estado inicial ou estados finais. Concorrência também é pobremente representada por
DTEs. Em [Harel, 1987] são propostos os statecharts, que estendem os diagramas de
transição de estados, acrescentando concorrência, comunicação (broadcast) e hierarquia. Há
dois problemas com estas abordagens. Enquanto a maioria das abordagens baseadas na
Psicologia Cognitiva enfocam o comportamento do usuário, deixando um pouco de lado a
representação do comportamento do sistema, as abordagens baseadas em diagramas de estado
fazem exatamente o contrário. Sua formalidade impede a representação de aspectos informais
da interação, como por exemplo os contextos social e organizacional que envolvem o
ambiente onde a aplicação será implantada. Outro problema é que os formalismos
apresentados também funcionam como notações, mesmo quando possibilitam a decomposição
de tarefas, não apresentando regras que indiquem qual a melhor forma de fazê-la.
Mais recentemente, a Engenharia de Software tem apresentado técnicas para o design
de interfaces que consideram aspectos relacionados ao comportamento do usuário e aos
15
contextos de uso. As mais importantes são cenários de interação e Design Patterns (padrões
de design). Nas próximas seções, introduziremos brevemente estas abordagens.
2.2.1 Cenários de Interação
Carroll [Carroll, 1995] descreve "cenário", como "uma descrição narrativa do que as
pessoas fazem e experimentam conforme tentam utilizar sistemas computacionais" e afirma
que estes são "um meio particularmente pertinente para representar, analisar e planejar como
um sistema de computador pode impactar as atividades e experiências de seus usuários".
Cenários possuem um vocabulário que é rico e acessível para todos os participantes no
desenvolvimento de um sistema, incluindo os usuários, além de poder orientar o
desenvolvimento de um software em todas as etapas do projeto. Durante a etapa de análise, os
designers podem criar cenários, em conjunto com os usuários, ou não, para documentar o
trabalho destes antes da implantação do sistema. Durante a etapa de especificação, os
cenários podem ser usados para que os designers descrevam quais são suas idéias para a
futura aplicação. Na etapa de prototipação eles podem ser usados como os protótipos a serem
avaliados pelos usuários. Na etapa de testes do sistema, podem descrever as situações a serem
testadas para a validação do sistema. Os cenários podem ainda ser usados como exemplos e
tutoriais na documentação e treinamento para os usuários e, finalmente, podem descrever
tarefas que os usuários devem executar na aplicação, durante a realização de uma avaliação de
usabilidade. Em [Monteiro et al., 2000] é apresentado um estudo de caso que descreve a
utilização de cenários nas diversas etapas do processo de design de uma aplicação real (o
Qualitas). Além do estudo de caso, o artigo compara este processo de design com processos
anteriormente adotados no laboratório onde o estudo foi realizado (TecGraf), apresentando
vantagens da utilização de cenários. Devido às reconhecidas vantagens da utilização de
cenários ao longo do processo de design, grande esforço de pesquisa vem sendo realizado no
sentido de se estabelecer modelos para a sua especificação. Diversas abordagens têm sido
propostas para a utilização de cenários para o design de aplicações computacionais
[Benner et al., 1992], [Hsia et al. 1994], [Jacobson et al., 1992]. Em [Rolland et al., 1996] é
apresentado um framework para a classificação de abordagens baseadas em cenários. Neste
trabalho propõe-se a classificação deste tipo de abordagem sob quatro perspectivas: forma,
conteúdo, propósito e ciclo de vida. Cada uma destas perspectivas é caracterizada por facetas
que por sua vez são caracterizadas por atributos. A forma se refere ao modo de expressão do
16
cenário. O conteúdo se refere ao tipo de conhecimento expresso no cenário. O propósito se
refere ao papel que o cenário exerce no processo de design. Finalmente, o ciclo de vida se
refere à maneira como os cenários evoluem durante este processo. Para ilustrar o framework
proposto, Rolland et al. o utilizam para classificar 11 abordagens que propõem a utilização de
cenários. A tabela 2.2 apresenta a classificação realizada em [Rolland et al.,1996] 2. Note que
para alguns dos atributos associados ao trabalho de Rengell et al. são apresentados dois
valores, aparentemente conflitantes (eg. tempo de vida = Transiente e Persistente). Isto se
deve ao fato de que esta abordagem propõe a definição de cenários em dois níveis de
abstração: descrições de casos de uso e especificações de casos de uso3. Quando o valor de
um atributo não é o mesmo para os dois níveis, são apresentados dois valores, o primeiro se
refere ao nível de descrição e o segundo ao nível de especificação. Por exemplo, tempo de
vida Transiente e Persistente significa que os cenários do nível de descrição são transientes e
os do nível de especificação são persistentes.
2 Estas tabelas foram traduzidas e adaptadas de [Rolland et al., 1996], entretanto apenas a forma de apresentação
dos dados sofreu adaptações, o conteúdo das tabelas não foi alterado.3 Esta abordagem é uma extensão da abordagem proposta em [Jacobson, 1992].
Tabela 2.2: classificação apresentada em [Rolland et al., 1996] para abordagens queutilizam cenários de interação.
Face
taAt
ribut
o[B
enne
r et
al.,
1992
][G
ough
et
al.,
1995
][H
sia
etal
., 19
94]
[Hol
broo
k,19
90]
[Jac
obso
net
al.,
1992
][K
yng,
1995
][P
otts
et
al.,1
994]
[Reg
nell
etal
., 19
95]
[Rum
baug
het
al.,
199
1][S
calz
o, 1
995]
[Som
é et
al.,
1996
]M
eio
(1)
{T, I
, P}
{T, I
, P}
{T}
{T, I
}{T
}{T
, P}
{T}
{T, I
}{T
, G}
{T, G
}{T
}De
scriç
ãoNo
taçã
o (2
)Q
ualq
uer
IF
II
IS-
FS-
FS-
FS-
FS-
FAn
imaç
ão (3
)Q
ualq
uer
VF
VF
VF
FF
FF
F O R M AAp
rese
ntaç
ãoIn
tera
tivid
ade
Qua
lque
rH
iper
text
oN
enhu
ma
Hip
erte
xto
Nen
hum
aH
iper
text
oH
iper
text
oN
enhu
ma
Nen
hum
aN
enhu
ma
Nen
hum
a
Inst
ânci
a (3
)V
FV
VV
VV
FF
VF
Tipo
(3)
VV
VV
VV
VV
VV
VAb
stra
ção
Mis
ta (3
)V
FF
VF
VV
FF
VF
Inte
rno
ao S
ist.
(3)
VF
FF
FV
VV
FV
VIn
tera
ção
com
Usuá
rio (3
)V
VV
VV
VV
VV
VV
Cont
exto
Org
aniz
acio
nal (
3)V
FF
VF
VV
FF
VF
Cont
exto
Ambi
ente
Org
aniz
acio
nal (
3)V
FF
FF
FF
FF
FF
Posi
ção
(3)
VF
FF
FV
FF
FV
FAr
gum
ento
s (3
)V
FF
VF
VF
FF
VF
Que
stõe
s (3
)V
FF
VF
VF
FF
VF
Argu
men
taçã
o
Deci
sões
(3)
VF
FV
FF
FF
FF
FFu
ncio
nal (
4){E
, F, C
}{E
, F, C
}{C
}{F
, C}
{E,F
,C}
{E,F
,C}
{E,F
,C}
{E, C
, F}
{E,F
,C}
{E,F
,C}
{E, C
}In
tenc
iona
l (5)
{ }{ }
{ }{M
, DM
}{}
(M, R
){}
{M, R
}{ }
{M, R
, O}
{ }
C O N T E Ú D O
Cobe
rtura
Não-
Func
iona
l (6)
{ }{ }
{ }{ }
{}{S
U,S
,P,R
D}
{}{ }
{ }{P
,RT,
RC
,SU
,F,T
E}{R
T}De
scrit
ivo
(3)
VV
VV
VV
VV
VV
VEx
plor
atór
io (3
)V
FF
VF
VF
FF
VF
P R O P Ó S I T O
Pape
lEx
plan
atór
io (3
)V
FF
FF
FF
FF
FF
Tem
pode
Vid
a (3
)?
Pers
iste
nte
Pers
iste
nte
Tran
sien
tePe
rsis
tent
ePe
rsis
tent
ePe
rsis
tent
eTr
ansi
ente
ePe
rsis
tent
eTr
ansi
ente
?Pe
rsis
tent
e
Capt
ura
Reu
sodo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
oR
euso
do z
ero
Inte
graç
ão (3
)?
FF
FF
FV
F e
VV
VV
Refin
amen
to (3
)?
VF
FV
FF
FV
FF
Expa
nsão
(3)
?F
FF
FV
FV
FF
V
C I C V
L I
O D
A
D EO
pera
ções
Dele
ção
(3)
?F
FV
FF
VV
e F
V?
VL
egen
da:
(1) T
: Tex
to, I
: Im
agem
, G: G
ráfic
os, P
: Pro
tótip
o(2
) I: I
nfor
mal
, S-F
: Sem
i-For
mal
, F: F
orm
al(3
) V: v
erda
deiro
, F: F
also
, ?: i
ndet
erm
inad
o
(4) E
: Est
rutu
ra, F
: Fun
ção,
C: C
ompo
rtam
ento
(5) M
: Met
a, D
M: D
ecom
posi
ção
de M
eta,
R: R
espo
nsab
ilidad
es, O
: Opo
rtuni
dade
(6) F
: Fle
xibi
lidad
e, P
: Per
form
ance
, RC
: Res
triçõ
es d
e cu
sto,
RD
: Res
triçõ
es d
e D
esig
n,
RT:
Res
triçõ
es d
e Te
mpo
, S: s
egur
ança
, SU
: Sup
orte
a U
suár
io, T
E: T
rata
men
to d
e Er
ro
17
18
Das abordagens classificadas em [Rolland et al., 1996], destacaremos a abordagem
proposta em [Jacobson et al., 1992], pelo fato de esta ter influenciado nosso trabalho.
Jacobson et al. propõem a descrição de cenários como casos de uso, os quais são estruturas
compostas por atores, normalmente um único curso típico e alguns cursos alternativos. Os
atores são os agentes que executam as tarefas descritas nos cenários. O curso típico descreve
todos os passos necessários para a realização de uma determinada tarefa de forma típica,
desconsiderando situações não típicas ou a ocorrência de problemas. Cada curso alternativo
descreve apenas parte dos passos da mesma tarefa, começando em algum ponto onde podem
ser executados passos alternativos ou onde pode ocorrer algum determinado problema, com o
objetivo de descrever como será a interação no caso deste ocorrer. Como cada curso
alternativo é idêntico ao curso típico até o ponto onde um passo alternativo é executado ou
onde ocorre um problema, são descritas apenas as diferenças. Quando não leva ao
cancelamento da tarefa, após a execução de um conjunto de passos alternativos ou após a
correção de um problema, o curso alternativo volta a ser idêntico ao curso típico. A divisão
em curso típico e cursos alternativos facilita a organização da descrição e permite o reuso das
partes comuns do caso de uso, pois como cada curso alternativo é idêntico ao curso típico até
o momento da variação e muitas vezes retorna a um ponto deste curso, as partes comuns são
descritas uma única vez, no curso típico. Devido às vantagens proporcionadas por este tipo de
especificação, ela foi usada para inspirar a definição de nosso modelo para a especificação de
cenários, como será visto no próximo capítulo.
Para exemplificarmos a descrição narrativa de cenários estruturada da forma proposta
por Jacobson et al., apresentamos na figura 2.3 um cenário de interação para a tarefa
"Registrar um empréstimo de publicações", no contexto de um Sistema Gerenciador de
Biblioteca.
19
Tarefa: Registrar um Empréstimo de Publicações
Atores: Aluno, Atendente da Biblioteca
1. Curso TípicoUm aluno chega a Biblioteca e pesquisa por publicações. Ao encontrar as publicações quesatisfazem suas necessidades, informa ao atendente que deseja pegá-las emprestadas. Oatendente pergunta o nome do aluno e informa este nome ao sistema. O sistema informaque o aluno está habilitado a pegar publicações emprestadas e solicita que o atendenteinforme quais publicações o aluno irá levar. O atendente informa ao sistema o código decada publicação que o aluno deseja alugar. Em seguida, o sistema solicita que o atendentepeça ao aluno para informar sua senha. O aluno informa a senha e o sistema confirma queo registro do empréstimo foi realizado com sucesso, além de apresentar as datas limites dedevolução para cada publicação. O atendente carimba cada publicação com sua respectivadata e as entrega ao aluno.
Cursos Alternativos
1. O aluno não está cadastrado como usuário da bibliotecaNeste caso, o atendente informa ao aluno que deve se cadastrar na secretaria de alunos.
2. O aluno não está habilitado a pegar publicações emprestadasDepois que o atendente informa o nome do aluno ao sistema, este informa que o aluno nãoestá habilitado a pegar publicações emprestadas pois já pegou o máximo número depublicações que lhe é permitido. O atendente informa isto ao aluno e ele decide voltar nodia seguinte e trocar algumas das publicações que está com ele pelas que tentou pegaremprestadas.
3. O aluno informa a senha incorretamenteNeste caso, o sistema permite que ele tente informá-la novamente. Desta vez ele o fazcorretamente e a partir deste ponto o curso volta a ser como o curso típico.
3.1 O aluno erra a senha por 3 vezesApós a terceira vez que o aluno erra a senha, o sistema informa que seus empréstimosficarão bloqueados por 1 dia, por questões de segurança e que, para desfazer o bloqueioele deve contatar a bibliotecária chefe. O aluno decide voltar à biblioteca no dia seguinte.
Figura 2.3: cenário de interação descrito em linguagem natural estruturado da forma propostapor Jacobson et al. em [Jacobson et al., 1992].
2.2.2 Design Patterns
Padrões de design (Design Patterns) são um meio de captura e reuso de experiência de
design. Em outras palavras, padrões de design são abstrações de lições aprendidas. Eles foram
concebidos por Alexander [Alexander et al., 1977], no campo da arquitetura, como meio para
auxiliar designers menos experientes. As idéias de Alexander inspiraram pesquisadores de
20
Engenharia de Software e a abordagem de Design Patterns passou a ser aplicada na
construção de código [Gamma et al., 1995]. O interesse em padrões para o design de
interfaces data de 1994 [Rijken, 1994]. Apesar de vários formatos terem sido sugeridos para a
representação de padrões de design, eles normalmente incluem:
• a descrição do problema,
• uma possível solução,
• exemplos de uso da solução em designs reais,
• razões por que a solução apresentada realmente resolve o problema,
• critérios para se decidir quando usar ou não uma determinada solução,
• relações com outros padrões de design.
Quando uma comunidade concorda sobre uma coleção de padrões, é possível falar de
uma linguagem de padrões. O principal objetivo da pesquisa em design patterns é justamente
o desenvolvimento de linguagens de padrões. Em [Borschers, 2000] é apresentado um modelo
formal para a representação de linguagens de padrões de interação. Para exemplificar este
modelo, é apresentada uma linguagem de padrões para o design de sistemas interativos
projetados para ser utilizados em exposições4 sobre o uso de computadores para o
aprendizado e o trabalho. Neste trabalho, o autor afirma que a linguagem de padrões definida
foi útil para a criação de sistemas do tipo enfocado por ela. Linguagens de padrões enfocando
outros tipos de aplicação também poderiam trazer grandes benefícios a atividade de design de
IHC. Design Patterns se apresenta como uma técnica promissora para o mapeamento de
tarefas para interfaces adequadas, pois ao abstrair a partir de experiência, os padrões têm
relevância e potencial para serem reusados [Trætteberg, 2000].
2.3 Abordagens fundamentadas na Semiótica
As abordagens semióticas revelam uma nova perspectiva e permitem uma nova
interpretação dos modelos computacionais. Elas são bastante promissoras como bases teóricas
para a canalização de fenômenos de IHC pois consideram o design como um processo de
4 do inglês exhibit.
21
comunicação e propõem a utilização da Semiótica5 como fundamentação teórica para sua
realização e para explicações de fenômenos relativos à interação humano-computador. O foco
de interesse é o papel que sistemas de significação e comunicação exercem sobre as
atividades cognitivas do usuário e não estas atividades propriamente ditas [Leite,1998]. Em
[Leite, 1998] analisa-se algumas abordagens fundamentadas na Semiótica, dentre as quais
podemos citar o Paradigma Semiótico [Nadin, 1988] e a Teoria de Semiótica
Computacional [Andersen, 1990]. Leite declara que apesar destas abordagens reconhecerem
que o processo de design de IHC é um processo de comunicação, elas não apresentam
métodos ou ferramentas precisas para o design da interface [Leite, 1998]. A Engenharia
Semiótica vai um pouco mais longe propondo a aplicação da teoria da produção de signo
[Eco, 1976] para o design de interfaces [Leite, 1998] e seguindo esta abordagem, Leite aplica
esta teoria na prática, criando um sistema semiótico para a produção de interfaces em
ambiente GUI e WIMP [Leite, 1998]. A seguir introduziremos brevemente a Engenharia
Semiótica e o trabalho de Leite, as maiores fontes inspiradoras do trabalho apresentado nesta
dissertação.
2.3.1 A Engenharia Semiótica
A Engenharia Semiótica [de Souza, 1993] é uma abordagem para o design de IHC que
considera um sistema computacional interativo como uma mensagem emitida pelo designer
para os usuários e expressa através da interface. O conteúdo desta mensagem é o modelo de
uso6 da aplicação proposto pelo designer. Ao interpretar a expressão da mensagem do
designer (interface), o usuário concebe seu próprio modelo de uso. Para que ele possa
compreender como utilizar a aplicação na realização de suas tarefas, o modelo de uso
concebido pelo usuário deve ser próximo ao proposto pelo designer.
Por considerar o processo de design de interfaces como um processo de produção de
mensagem, a Engenharia Semiótica elege a Semiótica como base teórica, fundamentando-se
nas teorias semióticas propostas por Charles S. Peirce [Peirce, 1931] e Umberto Eco
[Eco, 1976]. A idéia básica é que, se for utilizado no design de interfaces um sistema
semiótico, conhecido tanto pelo designer como pelo usuário, que relacione elementos de
5 A Semiótica é uma disciplina que estuda os signos, sistemas de signos, significação, comunicação e todos os
processos culturais [Eco, 1976].6 Este modelo indica o que o usuário pode fazer com a aplicação e como.
22
interfaces (sistema expressivo) a intenções de comunicação do designer (sistema semântico),
a interpretação do usuário ficará potencializada por estas intenções. Desta forma, o usuário
poderá adquirir um modelo de uso da aplicação compatível com o modelo proposto pelo
designer.
A Engenharia Semiótica se apresenta como abordagem complementar às abordagens
baseadas na Psicologia Cognitiva, apresentadas na seção 2.1. Estas abordagens visam
determinar como funcionam os processos cognitivos do usuário enquanto ele interage com
interfaces de forma a identificar que propriedades devem ter estas interfaces para facilitar
estes processos. Entretanto, estas abordagens não consideram o papel fundamental dos signos
produzidos pelo designer na ocorrência destes processos cognitivos. Assim, apesar de
conseguirem reconhecer interfaces fáceis de aprender e usar, estas abordagens não conseguem
explicar claramente o porquê desta facilidade e conseqüentemente não podem prover um
método estruturado para atingi-la. A Engenharia Semiótica enxerga o design como uma
atividade meta-comunicativa e proporciona uma perspectiva mais pragmática. Sob esta
perspectiva, é possível relacionar o aprendizado à interpretação dos usuários, explicando estes
processos de interpretação através do conceito de signo e utilizar sistemas semióticos, os
instrumentos de apoio a processos comunicativos providos pela Semiótica, como ferramenta
para o design de interfaces. Em outras palavras, a Engenharia Semiótica aplica a teoria
semiótica, visando determinar como o conhecimento que o usuário precisa adquirir, para
utilizar melhor o sistema, pode ser melhor comunicado através da interface de usuário
[Leite, 1998].
Um modelo e um formalismo de apoio à expressão da mensagem do designer
Seguindo a Engenharia Semiótica [de Souza, 1993], Leite define um meta-modelo
para a representação do modelo de uso da aplicação (ao qual chama de modelo de
usabilidade) como conteúdo da mensagem do designer e um sistema semiótico cujo objetivo é
apoiar a elaboração do conteúdo e da expressão desta mensagem. O sistema semântico deste
sistema semiótico é formado pelos componentes do meta-modelo e seu sistema expressivo é
composto por componentes de interfaces estilo WIMP. Leite fornece também as regras de
correlação entre os elementos dos dois sistemas. Com isto, ele estende a proposta original da
Engenharia Semiótica, propondo uma ferramenta prática para o design de IHC baseada no
23
modelo teórico. A tabela 2.3 resume os componentes do meta-modelo para a representação do
modelo de usabilidade identificados por Leite.
Componente Descriçãosigno do domínio abstração das diversas formas que uma informação do domínio
pode ser representada em um sistemafunção aplicada componentes operacionais que operam sobre objetos de
representação de signos do domínio, modificando seus estadosinteração básica operações perceptivas, motoras e cognitivas realizadas pelo
usuário diretamente na interface (fornecimento de caracteres,seleções e acionamentos)
visualização percepção de estados de funções aplicadas e informações sobresignos do domínio, que permitem ao usuário avaliar os efeitos deseus comandos de funções e decidir quais as próximas funções aserem comandadas
comando de função estrutura que articula as interações básicas e/ou visualizações,que podem controlar uma função aplicada e modificar o seuestado
Tabela 2.3: componentes do meta-modelo para o modelo de usabilidade de Leite.
Nosso modelo para a especificação de cenários de interação, também segue a
abordagem da Engenharia Semiótica e desta forma pretende suportar a especificação destes
cenários como parte do objeto da mensagem do designer. O trabalho de Leite foi a principal
fonte inspiradora para a realização nosso trabalho pois também define um modelo para a
comunicação de um modelo como objeto da mensagem do designer que inclui componentes
para a representação de interação. No próximo capítulo descrevermos o modelo para a
especificação de cenários proposto neste trabalho, abordando entre outras coisas a influência
do trabalho de Leite na sua definição.
24
Capítulo 3
Um Modelo para a Especificação deCenários de Interação
Neste capítulo apresentamos um modelo para a especificação de cenários de interação
como parte do conteúdo da mensagem do designer. Na seção 3.1 apresentamos a definição de
"interação" na qual nos baseamos. Na seção 3.2 descrevemos os componentes do modelo para
a especificação de cenários de interação proposto.
3.1 Interação
Na literatura de IHC pesquisada, encontramos definições para a palavra interação em
[Preece et al., 1993] e [Leite, 1998]. No glossário apresentado em [Preece et al., 1993], o
termo é definido como "a troca que ocorre entre usuários e computadores". Em [Leite, 1998] a
interação é definida como "o processo de comunicação que ocorre entre um usuário e uma
aplicação de software". Seguindo o paradigma de comunicação no qual se baseiam estas
definições, propomos a representação da interação sob uma ótica conversacional. Neste
trabalho, consideramos a interação como a conversa travada entre usuário e sistema (como
porta-voz do designer) para que o primeiro realize tarefas utilizando o segundo como
ferramenta. Acreditamos que um modelo que represente a interação desta maneira é
adequado para abstrair interfaces de forma menos dependente da tecnologia de
implementação que um modelo que a represente em termos de ações físicas de usuários.
Enquanto ações físicas muitas vezes são fortemente vinculadas a dispositivos de entrada e
saída (ex.: digitar � teclado, clicar � mouse), a conversa tem grandes chances de
representar a execução de qualquer sistema interativo, pois, na verdade, esta execução
consiste sempre na troca de informações entre o sistema e o(s) usuário(s), independentemente
da tecnologia usada na implementação (ex.: informar � teclado, mouse, voz, monitor
sensível ao toque (touch-screen monitor), etc.).
3.2 Componentes do Modelo Proposto para a Especificação deCenários de Interação
De acordo com nossa concepção de interação, apresentada na seção anterior,
propomos que o conjunto de cenários de interação, integrante do conteúdo da mensagem do
25
designer, deve descrever todos os caminhos conversacionais entre usuário(s) e uma
aplicação definidos pelo designer como meio obrigatório, adicional ou auxiliar para que o(s)
usuário(s) realize(m) tarefas acessando as funções da aplicação. Em outras palavras, este
conjunto de cenários de interação deve indicar como a funcionalidade da aplicação pode e
deve ser acessada pelo(s) usuário(s) através de conversas com a mesma. Para apoiar a
elaboração de cenários com este conteúdo definimos um modelo para a especificação de
cenários de interação cujos componentes são apresentados na figura 3.1. Estes componentes
foram identificados com base em:
• uma análise de quais informações são necessárias para a estruturação de cenários
em cursos típicos e alternativos de interação [Jacobson et al.,1992];
• uma análise de quais informações são necessárias para a especificação de
aplicações multi-usuário e
• uma análise do modelo de interação do Qualitas.
A análise de quais informações são necessárias para a estruturação de cenários em
cursos típicos e alternativos de interação, conforme definidos em [Jacobson et al., 1992] foi
realizada por considerarmos vantajoso suportar este tipo de especificação. A estruturação de
cenários desta forma permite o reuso de especificações de partes de cursos típicos comuns a
cursos alternativos, além de encorajar o designer a modelar situações atípicas as quais devem
ser tratadas pela aplicação. Convém notar que realizamos uma pequena modificação na
nomenclatura proposta em [Jacobson et al., 1992], apresentada no capítulo 2. Jacobson et al.
apresentam um curso típico como uma descrição de todos os passos necessários para a
realização de uma determinada tarefa de forma típica, desconsiderando situações não típicas
ou a ocorrência de problemas. Em seus cursos alternativos, ele inclui tanto as descrições da
interação a partir da execução passos alternativos ao curso típico, como as descrições da
interação a partir da ocorrência de problemas. Entretanto, observe que tanto em cursos típicos
como em cursos alternativos, pode haver interações alternativas no sentido de distintas
possibilidades de interação a partir de um mesmo ponto. Muitas vezes é até difícil ou
impossível precisar qual é o curso típico, pois há casos em que nenhuma interação alternativa
pode ser considerada mais “típica” que outra. Por exemplo, ao modelar a tarefa “criar
reunião” do módulo de organização de reuniões do Qualitas, os designers disponibilizaram
três alternativas para a realização a tarefa: criar a reunião a partir de uma reunião existente,
26
criar a reunião a partir de um template de reuniões ou criar a reunião a partir do zero. A
escolha dentre estas alternativas pode levar a 3 cursos de interação distintos. Todos estes
cursos são componentes do curso típico da tarefa “criar reunião”. Desta forma, achamos
interessante separar variantes aceitáveis do curso típico de cursos que descrevem a ocorrência
de problemas. Assim, passamos a utilizar o termo curso de exceção para nos referir apenas
aos cursos que representam problemas, liberando o termo alternativo para referenciar apenas
possibilidades distintas de interação, que na verdade, podem estar relacionadas tanto a cursos
típicos como a cursos de exceção. Assim, ao apresentarmos os componentes do modelo
proposto, na próxima seção, os dividiremos de acordo com os tipos de descrição de interação
que permitem representar: cursos típicos sem interações alternativas, cursos de exceção
sem interações alternativas e cursos alternativos.
A análise de quais informações são relevantes para a especificação de aplicações
multi-usuário foi realizada para tornar nosso modelo mais abrangente. Embora as mesmas
questões consideradas para o design de aplicações mono-usuário sejam relevantes para o
design de aplicações multi-usuário, este ainda requer a consideração de novas questões que
influenciam a modelagem da interação. Isto será discutido na seção 3.2.4.
A análise do modelo de interação do Qualitas foi feita com o objetivo de adequar
nosso modelo aos requisitos de representação práticos de modelos de interação de sistemas
reais. Apesar de termos nos baseado neste sistema para o desenvolvimento deste trabalho,
para fins didáticos, sempre que possível, utilizaremos um Sistema Gerenciador de
Biblioteca (SGB) quando houver necessidade de fornecer exemplos ao longo deste e dos
próximos dois capítulos. A utilização de um SGB para testar especificações formais foi
proposta inicialmente por Kemmerer em 1981 [Kemmerer, 1981]. Desde então este tipo de
sistema tem sido bastante utilizado para exemplificar e testar modelos e formalismos
apresentados em trabalhos de Engenharia de Software. Em [Wing, 1988] é apresentado um
estudo sobre 12 especificações deste sistema realizadas em formalismos diferentes. SGBs têm
sido referenciados em tantos trabalhos, justamente por terem um domínio simples e conhecido
por seus prováveis leitores. Acreditamos que o mesmo se aplica a esta dissertação. Entretanto,
como o Qualitas é muito mais complexo que um SGB, algumas necessidades detectadas
através da análise do modelo de interação do primeiro não existem para o segundo e desta
forma, não podem ser exemplificadas por ele. Nestes casos, utilizaremos o próprio Qualitas
para fornecer exemplos.
27
Nas próximas seções descreveremos em detalhes os componentes do modelo para a
especificação de cenários proposto.
Notação
Tarefa
Diálogo
Enunciado
Enunciadode Usuário
Enunciadode Sistema
Conceitoda
Aplicação
Conceito doDomínio Original
ConceitoIntroduzido com a
Tecnologia
Contexto deInteração
Determina
Componentes do Modelo de InteraçãoEstratégia
paraTratamentode Erros de
Usuário
Estratégiapara
Tratamentode Falhas
de Sistema
Possui
Possui
Possui
Possui
Interrupção
PermiteOcorre
emPermiteRevisar
Classe Relação de Herança: a classe Bé subclasse da classe A.
Relação deAssociação
A
<nome_classe>
B
A
B
Relação de Composição: objetosda classe A são compostos porobjetos da classe B.
A
B
Papel doUsuário
Determina
Enunciado
Determina
Determina
Determina
Modif ica
Figura 3.1: Componentes do modelo de interação.
3.2.1 Representação de cursos típicos
Para identificar os componentes necessários para a representação de cursos típicos de
interação nos baseamos no meta-modelo para o modelo de usabilidade e no formalismo
propostos por Leite em [Leite,1998]. Escolhemos o trabalho de Leite como base, por duas
razões:(1) ele também define um modelo para a comunicação de um modelo como objeto da
28
mensagem do designer e (2) seu modelo de usabilidade é formado por um modelo de
funcionalidade e por um modelo de interação, incluindo componentes para a representação de
interação.
Ao analisar os componentes do meta-modelo proposto por Leite, os consideramos
suficientes para a representação de cursos típicos de interação. Entretanto, foram realizadas
adaptações para deslocar a abstração adotada por Leite, do nível de ações e visualizações de
usuário para o nível de conversa entre usuário e sistema, adotado neste trabalho (veja a
figura 3.2). A seguir descrevemos os componentes que consideramos necessários para a
representação de cursos típicos de interação, indicando como se derivam do trabalho de Leite.
Após estas descrições apresentamos um resumo das diferenças entre os componentes
propostos no trabalho de Leite e neste trabalho.
Figura 3.2: comparação entre os níveis de abstração adotados por Leite [Leite, 1998] e poreste trabalho.
Tarefa
Leite define que as funções aplicadas são componentes do modelo de usabilidade e
devem ser comunicadas ao usuário através da interface. Contudo, as funções aplicadas só
existem para que o usuário possa realizar tarefas de um domínio particular através da
aplicação. Em geral, ao interagir com uma aplicação o usuário tem maior consciência da
tarefa que deseja realizar do que das funções disponíveis na aplicação. Desta forma, do ponto
de vista de interação, o mais importante é comunicar que tarefas o usuário pode realizar.
Apesar de Leite não explicitar que tarefas são componentes do modelo de usabilidade, o
formalismo que ele propõe para a representação deste modelo permite a especificação de
mensagens de tarefa. Estas mensagens objetivam comunicar ao usuário que estruturas de
comandos são necessárias para que ele consiga executar metas de alto nível, para as quais não
existe uma única função aplicada no sistema. Inspirados nas mensagens de tarefa
Tarefa Interface
Modelo de Cenáriode Interação
Mensagem do Designer
Modelo deUsabilidade
29
identificamos as tarefas que o usuário pode realizar utilizando a aplicação como
componentes do modelo de interação. Estendemos a noção apresentada por Leite propondo
que sejam representadas quaisquer tarefas que o designer pretenda que a aplicação apóie e
não apenas as que não possuem mapeamento direto para funções existentes. Em outras
palavras, em nosso modelo, as tarefas são os componentes do modelo de interação que
representam tudo o que o designer tem consciência1 de que o usuário pode realizar
utilizando a aplicação. Para manter a visão conversacional, caracterizamos a tarefa como
uma articulação de diálogos ao invés de uma articulação de comandos. O componente do
modelo de interação, diálogo, será apresentado no próximo item.
Diálogo
O diálogo é o componente proposto em nosso modelo para representar o componente
comando de função definido por Leite sob a ótica conversacional. Um diálogo é a conversa
ou parte da conversa travada entre usuário e sistema para que o usuário acesse uma
determinada função da aplicação criada para auxiliar a realização da tarefa da qual o diálogo é
componente. Para manter a ótica conversacional, ao invés de articular interações básicas do
usuário e visualizações, como um comando de função, um diálogo é caracterizado por uma
articulação de enunciados de usuário e enunciados de sistema. Estes componentes do
modelo de interação serão descritos nos próximos itens.
Enunciado de Usuário
O enunciado de usuário é o componente proposto em nosso modelo como adaptação
para as interações básicas de usuário definidas por Leite. Um enunciado de usuário
representa algo que o usuário deve ou pode comunicar ao sistema no diálogo em que é
emitido, independentemente da forma como esta comunicação é realizada.
Enunciado de Sistema
O enunciado de sistema é o componente proposto em nosso modelo para adaptar as
visualizações definidas por Leite. Um enunciado de sistema representa algo que o designer
1 Muitas vezes, utilizando a aplicação, o usuário descobre que pode realizar tarefas não premeditadas ou
previstas pelo designer.
30
deseja comunicar ao usuário e o faz através do sistema, independentemente da forma como
esta comunicação é realizada.
Conceito da Aplicação
Leite define signos do domínio como componentes do modelo de usabilidade que se
referem a conceitos do domínio. Ao analisarmos o Qualitas, percebemos que aplicações
podem apresentar tanto signos referentes a conceitos do domínio original como signos que se
referem a conceitos que não existiam neste domínio e que foram incorporados a ele devido à
introdução da tecnologia utilizada na aplicação. Um exemplo deste segundo tipo de conceito é
o conceito "forma de comunicação", que aparece nas interfaces para registro de comunicações
obrigatórias entre funcionários da SUSEMA, durante algumas etapas dos processos de
trabalho realizados através do Qualitas. Nestas interfaces, o usuário deve informar ao sistema
ou o texto de um e-mail para realizar a comunicação através do sistema ou indicar que a
comunicação foi feita de outra forma. Este conceito surgiu devido à introdução da tecnologia.
O usuário precisa informar que a comunicação foi feita, mesmo que não envie e-mail,
somente para que o sistema possa verificar se o serviço foi prestado de acordo com as normas.
Antes da introdução do sistema, isto não era necessário, ou seja, o conceito "forma de
comunicação" não faz parte do domínio original, tendo sido incorporado a este por causa da
tecnologia.
A distinção entre os conceitos do domínio original e conceitos introduzidos é muito
importante para o design pois o tipo de conceito pode fornecer indicações sobre o grau de
conhecimento do usuário sobre este conceito e conseqüentemente sobre a necessidade de
mensagens de help. Para domínios bem conhecidos e razoavelmente estáveis, pode ser mais
necessário fornecer explicações conceitos incorporados devido a introdução de tecnologia do
que fornecer explicações sobre conceitos conhecidos do usuário por fazerem parte do domínio
original.
Desta forma, decidimos distinguir em nosso modelo signos do domínio original e
signos que foram incorporados a este devido a introdução de tecnologia. Inicialmente optamos
por generalizar o componente signo do domínio para signo da aplicação. Mas este termo se
mostrou inadequado, pois qualquer coisa representada na aplicação é um signo da aplicação.
Por exemplo, a forma física como um widget é desenhado e as cores utilizadas na interface
são signos da aplicação mas não são conceitos relevantes para a modelagem da interação. Na
31
verdade o que queremos representar em nosso modelo são conceitos e desta forma decidimos
adotar o termo conceito da aplicação para representar este componente. De acordo com o que
foi exposto, subdividimos inicialmente os conceitos da aplicação em dois tipos: conceitos
existentes no domínio original da aplicação e conceitos incorporados a este domínio devido à
introdução da tecnologia utilizada na implementação da aplicação. Futuramente podem ser
identificados outros tipos de conceito da aplicação relevantes para a modelagem da interação.
Resumo dos componentes propostos para a representação de cursos típicos
A tabela 3.1 resume as adaptações realizadas aos componentes do modelo de
usabilidade identificado por Leite para a definição dos componentes do modelo de interação
necessários para a representação de cursos típicos de cenários de interação.
Componente do Modelo deUsabilidade de Leite
Componente do Modelo para aEspecificação de Cenários Derivado
função da aplicação tarefacomando de função diálogointeração básica (exceto visualização) enunciado de usuáriovisualização (componente e interação básica) enunciado de sistemasigno do domínio conceito da aplicação (inclui conceito
do domínio original e introduzido coma tecnologia)
Tabela 3.1: adaptações aos componentes do modelo de usabilidade identificados por Leitepara a definição de componentes do modelo de interação.
Tipos de Articulação para Estruturas de Diálogos e de Enunciados
Para a representação de tarefas em termos de articulações de diálogos e de diálogos em
termos de articulações de enunciados, propomos praticamente os mesmos tipos de articulação
definidos por Leite para articular comandos de função e interações básicas e/ou visualizações.
Estes tipos são: seqüência, agrupamento, combinação, repetição e seleção. A seqüência
articula elementos de forma seqüencial. O agrupamento articula elementos cuja ordem de
ocorrência pode ser qualquer uma. A combinação articula elementos que devem ocorrer de
maneira dependente um do outro ou de maneira síncrona. A repetição articula elementos que
devem ser repetidos. A seleção articula elementos alternativos, ou seja, indica que o usuário
pode escolher qual destes elementos ocorrerá.
A este conjunto de tipos de articulação definido por Leite, acrescentamos o tipo
seleção múltipla, que deve ser utilizado para articular um grupo de elementos quando o
32
designer permite que o usuário decida pela ocorrência de um ou mais destes elementos. A
necessidade de se incorporar este tipo de articulação foi detectada a partir de um estudo no
qual verificamos se os tipos de articulação definidos por Leite são suficientes para representar
tipos de articulação de atividades definidos em formalismos para a modelagem de tarefas
[UML,1999], [Lawrence, 1997], [Amyot, 1999]. O resultado desta análise foi bastante
satisfatório. Há um único tipo de articulação representável pelos formalismos que não pode
ser representado através dos tipos de articulação definidos por Leite: or-join. Este tipo de
articulação determina que uma atividade só pode ser executada se ao menos uma atividade
dentre um conjunto de atividades determinado tiver sido completada. Analogamente, ao
articular qualquer tipo de elemento, a estrutura or-join representaria que um elemento só pode
ocorrer se ao menos um elemento dentre um conjunto de elementos determinado tiver
ocorrido. Para se representar a seqüência entre o conjunto de elementos, dos quais um ou mais
devem ocorrer e o elemento que depende desta ocorrência podemos utilizar o tipo de
articulação seqüência. A seleção múltipla de alternativas de elementos se faz necessária
justamente para se representar a articulação dos elementos do conjunto. A tabela 3.2 indica
como os tipos de articulação definidos nos formalismos estudados podem ser representados a
partir dos tipos de articulação adotados em nosso modelo.
Tipos de Articulação de Formalismospara a Modelagem de Tarefas
Representação Através de Tipos deArticulação Propostos Neste Trabalho
paralelismo combinaçãoseqüência seqüênciaand_split (depois da execução de umaatividade, uma ou mais atividades têm queser executadas em paralelo)
seqüência entre a primeira atividade executadae o conjunto de atividades que devem serexecutadas em paralelo, articuladas porcombinação
or_split (depois da execução de umaatividade, existe um conjunto dealternativas possíveis de atividades quepodem ser executadas)
seqüência entre a primeira atividade executadae o conjunto de atividades alternativas,articuladas por seleção
and_join (uma atividade só pode serexecutada se todas as atividades de umconjunto de atividades determinadotiverem sido completadas)
seqüência entre um conjunto de atividadesarticuladas por agrupamento e a atividade cujaexecução depende da execução deste conjuntode atividades
or_join (uma atividade só pode serexecutada se ao menos uma atividadedentre um conjunto de atividadesdeterminado tiver sido completada.)
seqüência entre um conjunto de atividadesarticuladas por seleção e a atividade cujaexecução depende da execução de ao menosuma das atividades deste conjunto
Tabela 3.2: A representação de tipos de articulação definidos em formalismos para amodelagem de tarefas através dos tipos de articulação adotados em nosso modelo.
33
Controles de Ocorrência de Diálogos
Apesar de o designer disponibilizar diversos diálogos que o usuário pode travar com o
sistema para realizar tarefas utilizando-o, na maioria das vezes ele permite que estes diálogos
só sejam iniciados quando desejado pelo usuário. Esta possibilidade de escolha é chamada por
Leite de controle de leitura de mensagens2. Neste trabalho chamamos estes controles de
controles sobre a ocorrência de diálogos (mantendo nossa visão conversacional) e fazemos
algumas modificações no conjunto de controles identificados por Leite, que resultam no
seguinte conjunto de controles de ocorrência de diálogos: inicialização, finalização,
interrupção, retomada (após interrupção) e reinicialização do diálogo com ou sem
sugestões do sistema.
Os nomes dos quatro primeiros controles indicam literalmente qual a intenção de
controle do usuário que representam, dispensando maiores explicações. Convém esclarecer
alguns pontos sobre o controle reinicialização. Quando aciona um controle para a
reinicialização do diálogo, o usuário pretende recomeçar a troca de informação com o sistema,
restaurando o estado inicial do diálogo. Ou seja, ele quer responder novamente a todas as
perguntas do sistema, como se o diálogo nem tivesse sido iniciado. Observe que no diálogo
original, o sistema pode ter sugerido o conteúdo para alguns enunciados do usuário (valores
default) e desta forma, a reinicialização do diálogo pode ser feita mantendo-se ou não estas
sugestões.
3.2.2 Representação de cursos de exceção
Conforme mencionado, chamamos de cursos de exceção as descrições de como será a
interação a partir da ocorrência de um problema. A partir de nossa experiência, identificamos
os seguintes fatores como determinantes de cursos de exceção:
1. fornecimento de informação inválida realizado pelo usuário;
2. falhas de execução do sistema e
3. falhas da organização.
2 Nossos diálogos equivalem a comandos de função no modelo de Leite, os quais são representados em seu
formalismo como mensagens de comando.
34
A seguir analisaremos que componentes são necessários para a representação dos cursos
de exceção gerados por cada um destes fatores.
1. Fornecimento de informação inválida realizado pelo usuário
O fornecimento incorreto de informação pelo usuário em cada passo da tarefa
representa um curso de exceção que deve ser previsto pelo designer para que possa ser tratado
pela aplicação. Para representar estes cursos é necessário descrever o que acontece em termos
de interação caso ocorra algum erro de fornecimento de informação. Isto não é possível a
partir dos componentes identificados para a representação de cursos típicos. Para satisfazer
esta necessidade, incorporamos em nosso modelo o componente estratégia para tratamento
de erros de usuário. Esta estratégia se caracteriza por três atributos: o tipo de validação, o
tipo de resposta do sistema e a forma de encaixe do diálogo de correção na interação.
Existem dois tipos de validação:
• pontual: o sistema checa cada informação enunciada pelo usuário, assim que ele
termina de enunciá-la.
• por lote: o sistema checa todas as informações enunciadas pelo usuário em um
mesmo diálogo de uma só vez.
Existem dois tipos de resposta do sistema:
• Correção Interativa: definindo este tipo de tratamento de erro, o designer está
dizendo que a correção será feita interativamente com o auxílio do usuário. Terá
início um diálogo remediador, onde o sistema informará ao usuário os erros
ocorridos e lhe pedirá para reformular seus enunciados inválidos. O usuário pode
abandonar o diálogo a qualquer momento, o que significará que ele está
abandonando a tarefa, pois não é possível continuar uma tarefa sem corrigir erros
detectados pela aplicação.
• Correção Interativa Sugerida: definindo este tipo de tratamento de erro, o
designer está dizendo que o sistema tentará inferir quais são os valores corretos
para as informações inválidas e no diálogo remediador, apresentará estes valores
como sugestão de correção ao usuário.
Definimos as seguintes formas de encaixe para o diálogo de correção:
35
• Inserido: indica que o diálogo original será re-iniciado e enunciados do sistema
que abordam os erros ocorridos serão inseridos dentro dele, solicitando
reformulações dos enunciados inválidos do usuário. O termo inserido pretende ser
uma analogia com o termo insertion sequences (seqüências de inserção)
[Schegloff, 1968] utilizado em análise de discurso. Este termo é apresentado no
contexto da definição do termo adjacency pairs (pares de adjacência). Existem
enunciados que "pedem" certos tipos de enunciados por parte do interlocutor de
quem os emite, por exemplo: pergunta/resposta, saudação/saudação, etc. Estes
tipos de pares de enunciados são chamados de pares adjacentes. Qualquer
seqüência de enunciados ocorrida entre o primeiro e o segundo enunciados que
representem um par adjacente é chamada de seqüência de inserções. Por exemplo:
quando um indivíduo A faz uma pergunta ao indivíduo B, B pode pedir que A
explique melhor o que deseja saber e só depois que A emitir novo enunciado com
explicações, B poderá fechar o par adjacente fornecendo a resposta solicitada pela
pergunta de A. O pedido de explicação de B e a explicação de A formam uma
seqüência de enunciados inserida entre o par adjacente pergunta/resposta. A
analogia com o tipo de tratamento de erro representado consiste no fato de que
enunciados do sistema e reformulações de informação do usuário são inseridos no
diálogo, entre o enunciado de usuário no qual ele solicita a apresentação do
próximo passo da tarefa pelo sistema e seu par adjacente que é justamente esta
apresentação.
• Autônomo: indica que terá início um novo diálogo, o qual será composto apenas
por enunciados do sistema informativos dos erros ocorridos e por correções do
usuário a seus enunciados considerados inválidos pelo sistema. A partir deste
diálogo, o usuário tem a opção de solicitar uma correção estendida, iniciando um
diálogo mais completo, equivalente ao diálogo com encaixe inserido, apresentado
acima. Ou seja, ele é composto por todos os enunciados do diálogo original, pelos
enunciados informativos dos erros ocorridos e por correções do usuário em seus
enunciados originais inválidos.
• Autônomo Contextualizado: indica que terá início um novo diálogo, o qual será
composto por enunciados do sistema informativos dos erros ocorridos, por
correções do usuário em seus enunciados e, quando necessário, por trechos do
36
diálogo original relevantes para a reformulação dos enunciados inválidos. A partir
deste diálogo, o usuário também tem a opção de iniciar uma correção estendida,
iniciando um diálogo mais completo, equivalente ao diálogo com encaixe inserido.
Quando o diálogo encaixado é autônomo, torna-se necessário especificar se ele é
modal ou não e se o diálogo original persiste ou não.
Observe que o designer pode desejar que os erros cometidos pelo usuário em todos os
diálogos de uma mesma tarefa sejam tratados juntos, após o último diálogo que compõe a
tarefa. Neste caso, o tratamento deve ser definido para a tarefa e não para cada diálogo que a
compõe. Uma mesma tarefa ou diálogo pode ter mais de uma estratégia associada, desde que
todas as estratégias associadas a eles estejam relacionadas a contextos de interação distintos.
Existem outras alternativas de especificação a respeito de tratamento de erros que
deliberadamente não são consideradas em nosso modelo. Isto se deve ao fato de
considerarmos desnecessário permitir especificações que acreditamos ser de baixa qualidade.
Exemplos de especificações que foram descartadas são:
• o não tratamento de erro - descartada pois a validação de dados é fundamental,
visto que o fornecimento de informações inválidas pode causar erros de execução
ou inconsistências no banco de dados da aplicação.
• a enunciação das mensagens de erro feita antes e separadamente da reformulação
dos enunciados inválidos do usuário - descartada pois o usuário teria que recordar
quais de seus enunciados devem ser reformulados e por que estão inválidos, o que
dificultaria desnecessariamente a correção dos erros.
• a impossibilidade de o usuário abandonar a tarefa em caso de ocorrência de erro -
descartada por não deixar o controle nas mãos do usuário.
2. Falhas de execução do sistema
Outros cursos de exceção ocorrem devido a outros tipos de erros: as falhas de
sistema. Também não é possível descrever o que acontece em termos de interação caso ocorra
alguma falha de sistema, a partir dos componentes identificados para a representação de
cursos típicos. Para satisfazer esta necessidade, incorporamos em nosso modelo o componente
estratégia para tratamento de falhas de sistema, similarmente ao realizado para a
37
representação de cursos de exceção devido a erros de usuário. A estratégia para tratamento
de falhas de sistema se caracteriza por um único atributo: o tipo de tratamento de falha. A
forma de encaixe do diálogo corretivo na interação não precisa ser definida pois estamos
assumindo que ele será sempre encaixado de forma independente, visto que uma falha de
sistema não tem relação com erros de usuário e não precisa ser inserida ou contextualizada no
diálogo travado anteriormente à falha.
Os tipos de correção de erro definidos para erros de usuários, Correção Interativa e
Correção Interativa Sugerida são válidos para o tratamento de falhas de sistema, mas neste
contexto, sua definição sofre uma pequena variação: os enunciados do sistema visam extrair
informação que "ele julga" (representando o designer) necessária para corrigir a falha e os
enunciados do usuário visam fornecer estas informações requisitadas pelo sistema. Além
destes tipos de tratamento de falhas de sistema, definimos os seguintes:
• Feedback Prestativo: definindo este tipo de tratamento, o designer está dizendo
que, nesta situação de falha, há a possibilidade de o próprio usuário resolver o
problema e o sistema, além de informar a falha ocorrida, irá instruir o usuário
sobre como proceder para corrigi-la. O usuário poderá finalizar o diálogo ou
solicitar mais detalhes ao sistema. Um exemplo de aplicação deste tipo de
tratamento de falha de sistema ocorre quando há falha na tentativa de
armazenamento de um arquivo em um disco cheio. O sistema informa ao usuário
que o problema pode ser resolvido caso ele próprio apague um ou mais arquivos,
liberando espaço em seu disco rígido.
• Feedback Esperançoso: definindo este tipo de tratamento, o designer está dizendo
que nesta situação de falha, nem o usuário nem o sistema podem fazer nada para
solucionar o problema, mas há a esperança de que ela não volte a ocorrer caso o
usuário tente executar a operação interrompida novamente. Desta forma, além de
informar ao usuário a falha ocorrida e permitir que ele solicite detalhes sobre esta
falha, o sistema também permite que o usuário tente refazer a operação, na
esperança de que a falha não se repita. Um exemplo de aplicação deste tipo de
tratamento de falha de sistema ocorre quando há interrupção temporária dos
serviços de rede. O sistema informa este fato ao usuário e permite que ele tente
acessar a rede novamente ou cancele a operação.
38
• Feedback Sumário: definindo este tipo de tratamento, o designer está dizendo que
nesta situação de falha não haverá possibilidade de correção e tudo o que o sistema
poderá fazer é informar ao usuário a falha ocorrida e aguardar que ele finalize o
diálogo ou que solicite detalhes sobre o que o sistema está dizendo.
Analogamente às estratégias para tratamento de erros de usuário, uma estratégia
para tratamento de falha de sistema pode ser associada a uma tarefa, valendo para todos os
diálogos que a compõem, ou pode ser associada a cada um destes diálogos, assim como, uma
mesma tarefa ou diálogo pode ter mais de uma estratégia associada, desde que todas as
estratégias associadas a eles estejam relacionadas a contextos de interação distintos.
3. Falhas da organização
Algumas falhas da organização que utiliza a aplicação podem atrapalhar ou até
impedir totalmente a sua utilização. Um exemplo real ocorrido foi a perda do banco de dados,
devido à falha de determinada organização em seguir o procedimento correto para fazer
backup. O sistema podia funcionar, mas a inexistência de informações que já tinham sido
registradas impedia que funcionasse corretamente, pois se ele fosse utilizado nestas
condições, poderia gerar inconsistências. A solução adotada foi tirar o sistema do ar até que
uma versão estável e a mais atualizada possível do banco de dados fosse recuperada. A
recuperação demorou quase dois meses. Durante este tempo, atividades que haviam sido
iniciadas através do sistema, antes da perda do banco, não puderam prosseguir e atividades
surgidas no período de inatividade da aplicação, tiveram de ser realizadas e registradas
manualmente, sem as verificações de consistência e qualidade possibilitadas pela aplicação. O
problema de falhas da organização é mencionado aqui devido a sua importância, mas não está
no escopo deste trabalho, pois estes tipos de falha não são facilmente previsíveis, requerendo-
se um estudo a parte, baseado em muita experiência, para que possamos categorizá-las. A
categorização de falhas da organização beneficiaria um sistema de help que poderia preparar
os usuários e administradores da aplicação para situações como esta e possivelmente evitá-las.
Resumo dos componentes propostos para representar cursos de exceção
A tabela 3.3 sumariza os componentes propostos para a representação de cursos de
exceção, apresentando os fatores que ocasionam estes cursos e os componentes do modelo de
interação identificados em nosso modelo a partir da análise destes fatores.
39
Fatores que Ocasionam Cursos De Exceção Componentes do Modelo de InteraçãoDerivado
Fornecimento de informação inválidarealizado pelo usuário
estratégias de tratamento de erros deusuário
Falhas de execução do sistema estratégias de tratamento de falhas desistema
Tabela 3.3: Componentes do modelo de interação identificados a partir da análise de fatoresque ocasionam cursos de exceção.
3.2.3 Representação de cursos alternativos
Para identificar informações que são necessárias para a representação de cursos
alternativos de interação, analisamos os seguintes fatores, cujas combinações podem
determiná-las:
1. o estado da aplicação no momento da interação;
2. possibilidades de escolha disponibilizadas para o usuário, pelo designer;
3. possibilidade de interrupção de tarefas antes de sua conclusão e de posterior
retomada.
Convém mencionar, que este conjunto de fatores foi obtido através de observação
informal, não representando o conjunto completo dos fatores que determinam possibilidades
de interação alternativas. A seguir, apresentaremos nossa análise de cada um destes fatores,
identificando se os cursos alternativos determinados por eles podem ou não ser representados
pelos componentes apresentados nas seções anteriores. Quando a representação é possível,
indicamos como é feita e em caso contrário, apresentamos os componentes do modelo de
interação incorporados ao nosso modelo devido à necessidade revelada pela análise do fator.
1. O estado da aplicação no momento da interação
O estado da aplicação no momento da interação pode determinar cursos alternativos de
interação. Isto ocorre pois os principais determinantes deste estado são os enunciados
emitidos pelo usuário e quase sempre há dependência semântica entre os conceitos da
aplicação abordados por estes enunciados e os abordados por enunciados a serem emitidos
posteriormente. Em outras palavras, a semântica de um enunciado de usuário pode restringir
ou determinar a semântica de enunciados posteriores (do usuário e/ou do sistema) que
40
abordem conceitos que dependam do conceito abordado por ele. Desta forma, Dependendo
deste estado, uma mesma tarefa pode ser realizada através de diálogos distintos ou um mesmo
diálogo pode apresentar variações nos enunciados que o compõem.
Utilizemos o Sistema Gerenciador de Biblioteca para ilustrar como diferentes estados
da aplicação podem determinar cursos alternativos. Na interação para a pesquisa por
publicação, o usuário enuncia as condições para filtrar a pesquisa. Dependendo das condições
enunciadas, podem ser encontradas uma ou mais publicações. Assim, a semântica dos
enunciados prévios do usuário, poderia determinar a iniciação de ao menos dois diálogos
alternativos para o curso típico: (1) poderia ser iniciado um diálogo onde o sistema enunciasse
os títulos de várias publicações que satisfizessem as condições fornecidas pelo usuário e
solicitasse que ele indicasse qual delas deve ter informações exibidas em maiores detalhes;
(2) um curso alternativo seria a iniciação de um diálogo onde o sistema enunciasse
diretamente informações detalhadas sobre a única publicação encontrada.
Exemplificaremos agora como a semântica de enunciados prévios do usuário pode
determinar contextos distintos para um mesmo diálogo. Se ao solicitar ao sistema a
apresentação de informações sobre uma publicação, o usuário enuncia que a publicação é um
livro, no diálogo iniciado pelo sistema para a apresentação destes dados, este enuncia
informações como ISBN e editora. Se em seu enunciado o usuário solicita a apresentação de
informação sobre uma tese, o sistema enuncia informações como curso e universidade,
caracterizando um outro contexto do diálogo iniciado para apresentação de informações sobre
publicação.
Observe que enunciados previamente emitidos pelo usuário podem influenciar também
o diálogo no qual são emitidos e não somente os posteriores. Para exemplificar isto,
consideremos a interação para a descrição de uma não conformidade3 no Qualitas. Ao
descrever a não conformidade é necessário também classificar sua natureza em processo,
produto ou sistema. Existem motivos padrão para não conformidades e alguns destes
motivos estão sempre associados à mesma natureza de RNC. Seria interessante que o designer
pudesse especificar que o sistema pode identificar automaticamente a natureza, dependendo
do motivo da não conformidade enunciado pelo usuário. Por exemplo, se o usuário enunciar
3 Uma não conformidade ocorre quando um serviço não é prestado de acordo com o padrão especificado pelas
normas de qualidade vigentes na organização.
41
que o motivo do RNC é "A análise crítica do contrato foi realizada após o prazo estabelecido
na norma.", ao invés da natureza ser também enunciada pelo usuário, o sistema poderia inferir
que ela é de processo e enunciar isto no lugar do usuário impedindo-o de escolher outra
natureza, enquanto mantiver este motivo.
Observe que além de determinar cursos alternativos de interação, o estado da aplicação
determina a disponibilidade de funções da aplicação. Uma mesma função pode ser acessível
em alguns momentos e pode não o ser em outros, para um mesmo usuário. Por exemplo, no
Windows existe a função “colar o objeto que está no clipboard”. Mas, esta função só está
habilitada quando há um objeto no clipboard (estado da aplicação). Desta forma, além de ser
necessário especificar quem pode acessar uma função (veja a seção 3.2.3), é preciso
especificar em que condições isto pode ser feito.
Para representar as condições que caracterizam estados da aplicação em que ocorrem
cursos alternativos de interação, habilitação ou desabilitação de acesso a funções,
incorporamos ao nosso modelo o componente contexto de interação. Contexto, conforme
definido para análise de discurso [Yule, 1983], engloba o conjunto de conhecimentos do
mundo necessários para a inferência de pressuposições implícitas, que influenciam não apenas
a interpretação de uma mensagem, mas também sua geração. Isto é exemplificado pelo fato de
as pessoas usarem anáforas4 ao falarem. Em nosso modelo, analogamente à noção descrita
acima, o contexto de interação tem, como uma de suas funções, a definição dos diálogos a
serem travados entre usuário e sistema. Ele define quais diálogos serão travados (veja o
exemplo de pesquisa por publicação descrito acima), como eles serão travados (veja o
exemplo de apresentação de informações sobre publicação descrito acima) e que
pressuposições podem ser feitas (veja o exemplo da descrição da não conformidade descrito
acima). É através da representação do contexto de interação que o designer determinará o que
usuário e sistema poderão dizer sobre um determinado tópico, em cada uma das situações
onde o tópico é abordado. Os contextos de interação também podem ser utilizados para
representar comportamentos dinâmicos da interação, dependentes de outros fatores, que não a
semântica dos enunciados prévios do usuário, como por exemplo fatores dependentes do
modelo de grupo.
4 Anáfora é uma referência a algo que foi dito anteriormente. Exemplo: "Marcelo encontrou Luciana e pediu a
ela que lhe emprestasse o livro do Norman". "ela" se refere a Luciana, e "lhe" se refere a Marcelo.
42
Ao definirmos contextos de interação, definimos também um conjunto de relações
que pode haver entre contextos. Elas podem ser usadas para definir um contexto de interação
reusando definições de um ou mais contextos já definidos. As relações entre contextos de
interação identificadas neste trabalho são: União, Interseção, Subcontexto e
Complementaridade. Estas relações foram inspiradas na teoria de conjuntos e estão
ilustradas na figura 3.3. A seguir descreveremos cada uma destas relações.
Figura 3.3: Relações entre Contextos de Interação.
União
Esta relação é usada para determinar que um contexto de interação é definido pela
união de N contextos de interação. A figura 3.3a ilustra um contexto de interação A formado
pela união dos contextos de interação B e C. Especificar que um contexto de interação A é a
união dos contextos de interação B e C, significa definir que qualquer situação que se
encontre no contexto de interação B ou C estará também no contexto de interação A e que, se
uma situação está no contexto de interação A, necessariamente está também, em pelo menos
um dos contextos de interação B ou C.
Para exemplificarmos a utilização prática da relação de união na definição de
contextos de interação, consideremos a interação para registro de um empréstimo de
publicação, no Sistema Gerenciador de Biblioteca. Suponhamos que quando o empréstimo é
feito para um professor ou aluno da pós-graduação, o sistema enuncie para o funcionário da
biblioteca que informa este empréstimo, uma mensagem indicando que o usuário tem 20 dias
para devolver a publicação e que em outros contextos, o sistema enuncie que o usuário tem 15
dias para devolvê-la. O primeiro contexto de interação poderia ser definido pela união dos
contextos de interação "o locatário da publicação é professor" e "o locatário da
publicação é aluno de pós-graduação".
CB
A
a) União
CB A
b) Interseção
BA
C
d) Complementaridade
A
B
c) Subcontexto
43
Interseção
Esta relação é usada para determinar que um contexto de interação é formado pela
interseção de N contextos de interação. A figura 3.3b ilustra um contexto de interação A
formado pela interseção entre os contextos de interação B e C. Especificar que o contexto de
interação A é a interseção entre os contextos de interação B e C, significa definir que uma
situação só se encontrará no contexto A se estiver simultaneamente nos contextos de interação
B e C.
Para exemplificarmos a utilização prática da relação de interseção para a definição de
contextos de interação, consideremos novamente a interação para a apresentação de
informação sobre publicação, no Sistema Gerenciador de Biblioteca. Suponhamos que
somente quando o usuário que realiza a consulta é um professor e a publicação está
emprestada para algum aluno seu, o sistema enuncie o nome do aluno que está com a
publicação. Este contexto de interação poderia ser definido pela interseção dos contextos de
interação "o usuário corrente do sistema é professor" e "o locatário da publicação é
aluno do usuário".
Subcontexto
Esta relação é usada para determinar que um contexto de interação é subcontexto de
outro. A figura 3.3c ilustra um contexto de interação A que é subcontexto do contexto de
interação B. Especificar que A é subcontexto de B, significa definir que B engloba todas as
situações definidas por A, mas A só engloba as situações definidas por B que satisfazem a
determinadas restrições.
Para exemplificarmos a utilização prática da relação de subcontexto para a definição
de contextos de interação, consideremos a interação para a abertura de Relatórios de Não
Conformidade (RNC), no Qualitas. Após o diálogo para o fornecimento de informações
sobre o RNC, podem ser iniciados 3 diálogos distintos:
1. se o usuário indicar que houve reclamação de cliente, inicia-se um diálogo no qual
ele fornece informações sobre a reclamação, como o nome do cliente que
reclamou, etc.
44
2. se o usuário não indicar que houve reclamação de cliente:
2.1 se o usuário não for o responsável por supervisionar o RNC é iniciado um
diálogo no qual ele enuncia uma mensagem a ser transmitida para o supervisor
do RNC solicitando que este o ratifique.
2.2 se o usuário for o responsável por supervisionar o RNC, não precisa comunicar
mensagem a si mesmo para pedir a ratificação e assim inicia-se um diálogo
onde o sistema lhe apresenta as informações sobre o RNC, para que ele as
confirme ou revise.
Poderíamos definir o contexto de interação descrito no item 2.2, "RNC aberto pelo
supervisor, não devido a reclamação de cliente", como sendo um subcontexto do contexto
"RNC não devido a reclamação de cliente" associado à restrição de que o RNC foi aberto
pelo supervisor5.
Complementaridade
Esta relação é usada para determinar que um contexto de interação é complementar a
outro, em relação a um contexto de interação do qual ambos são subcontextos. Para facilitar
as próximas explicações, chamaremos este contexto de interação de supercontexto. A figura
3.3d ilustra um contexto de interação A que é complementar a um contexto de interação B em
relação ao supercontexto comum C. Especificar que os contextos de interação A e B são
complementares em relação ao contexto de interação C, significa definir que C é formado pela
união exclusiva dos contextos de interação A e B, ou seja,
1. Se uma situação se encontra no contexto A, ela não está no contexto B e vice-
versa.
2. Se uma situação se encontra em apenas um dos contextos A ou B, ela
necessariamente encontra-se no contexto C.
3. Se uma situação se encontra no contexto C, ela necessariamente se encontra em
um e somente um dos contextos de interação A ou B.
5 Observe que o contexto "RNC aberto pelo supervisor, não devido a reclamação de cliente" também pode
ser representado como a interseção entre os contextos "RNC aberto pelo supervisor" e "RNC não devido à
reclamação de cliente".
45
Quando a relação de complementaridade é usada para a definição de um contexto de
interação, ela também define implicitamente uma relação de subcontexto entre este e o
supercontexto do contexto de interação complementar. A restrição que define esta relação de
subcontexto é a negação das restrições especificadas na relação de subcontexto entre o
contexto complementar e o supercontexto.
Para exemplificarmos a utilização prática da relação de complementaridade para a
definição de contextos de interação, consideremos novamente a interação para a abertura de
Relatórios de Não Conformidade, descrita no item anterior.
Poderíamos definir o contexto de interação descrito no item 2.1, "RNC não aberto
pelo supervisor, não devido a reclamação de cliente", como sendo o complementar do
contexto "RNC aberto pelo supervisor, não devido a reclamação de cliente" em relação
ao supercontexto "RNC não devido a reclamação de cliente". Note que, para este exemplo,
a identificação do supercontexto comum é indispensável, pois se a complementaridade fosse
absoluta, os RNCs abertos pelo supervisor, devidos a reclamação de cliente e os RNCs não
abertos pelo supervisor, devidos à reclamação de cliente seriam erroneamente associados ao
contexto "RNC não aberto pelo supervisor, não devido a reclamação de cliente" (veja a
figura 3.4).
46
Figura 3.4: representação correta e errônea do contexto de interação "RNC não aberto pelosupervisor, não devido à reclamação de cliente" utilizando a relação de complementaridade.
2. Possibilidades de escolha disponibilizadas para o usuário, pelo designer
Para algumas tarefas, os designers disponibilizam alternativas para os usuários, tanto a
nível de diálogos que ele pode iniciar, como a nível de enunciados que ele pode emitir6. Como
exemplo, consideremos novamente um Sistema Gerenciador de Biblioteca. No diálogo inicial
de uma interação para pesquisa por publicações, o designer pode permitir que o usuário
escolha entre iniciar ou não um outro diálogo, no qual ele possa informar restrições adicionais
para sua pesquisa, não abordadas no diálogo inicial. Como exemplo de possibilidade de
escolha dentre enunciados de usuário alternativos, considere a interação para cadastro de
publicação, em um Sistema Gerenciador de Biblioteca. O designer pode permitir que o
usuário, ao informar o assunto associado à publicação, escolha entre selecionar um assunto de
6 Observe que o usuário não pode escolher diretamente quais os enunciados de sistema que serão apresentados.
A escolha direta é feita dinamicamente "pelo próprio sistema", que funciona de forma dependente do contexto da
interação, de acordo com o especificado pelo designer. O usuário pode "escolher" enunciados de sistema de
forma indireta, pois suas ações influenciam o contexto da interação.
b) Representação errônea do contexto "RNC nãoaberto pelo supervisor, não devido à reclamação decliente", como complementar absoluto do contexto"RNC aberto pelo supervisor, não devido àreclamação de cliente".
RNC
RNC aberto pelosupervisor, não devidoà reclamação decliente
RNC nãoaberto peloSupervisor
RNC abertopeloSupervisor
RNC não devido àreclamação de cliente
RNC não aberto pelo supervisor, nãodevido à reclamação de cliente
RNC
RNC aberto pelosupervisor, não devidoà reclamação decliente
RNC nãoaberto peloSupervisor
RNC não aberto pelosupervisor, não devidoà reclamação decliente
RNC abertopeloSupervisor
RNC não devido àreclamação de cliente
RNC devido à reclamação de cliente
a) Representação do contexto "RNC não aberto pelosupervisor, não devido à reclamação de cliente",como complementar do contexto "RNC aberto pelosupervisor, não devido à reclamação de cliente" emrelação ao supercontexto comum "RNC não devido àreclamação de cliente".
47
um conjunto de assuntos pré-definidos ou indicar um novo assunto. As possibilidades de
escolha disponibilizadas para o usuário, pelo designer, podem ser representadas através da
utilização das estruturas seleção e seleção múltipla para articulação de diálogos e enunciados
de usuário.
Convém notar que algumas alternativas disponibilizadas na aplicação para a realização
de uma mesma meta muitas vezes são descobertas pelo usuário a partir do uso da aplicação.
Estas alternativas são possibilitadas por acaso, não tendo sido premeditadas ou previstas pelo
designer.
3. Possibilidade de interrupção e de posterior retomada de passos de tarefas
Para algumas tarefas, o designer pode desejar estabelecer pontos onde elas podem ser
interrompidas e posteriormente retomadas. Por exemplo, considere a tarefa "criar proposta de
contrato de prestação de serviços", no Qualitas. A figura 3.5 ilustra a decomposição desta
tarefa em diálogos. Os diálogos estão representados como retângulos e para aqueles onde a
tarefa pode ser interrompida, a borda é mais grossa. A tarefa é composta pelos seguintes
diálogos: fornecimento de informações sobre o órgão cliente, fornecimento de informações
sobre o contato no cliente, fornecimento de informações sobre o serviço a ser prestado,
elaboração do cronograma para a prestação do serviço e registro da proposta. O usuário pode
interromper a tarefa durante a elaboração do cronograma e durante o registro da proposta, sem
perda das ações realizadas anteriormente a estas etapas. Se ele interromper a tarefa em um
destes diálogos, pode retomá-la posteriormente, podendo retornar a qualquer passo anterior,
exceto o fornecimento de informações sobre o órgão cliente.
A existência de pontos de interrupção em tarefas possibilita cursos alternativos de
interação: o usuário pode executar todos os passos para a realização da tarefa de uma só vez,
ou executar um subconjunto de passos de uma só vez, interrompendo a tarefa antes de
completá-la, para, posteriormente retomá-la no ponto onde parou podendo revisar, ou
não, pontos anteriores. Ele pode, ainda, realizar N interrupções, no mesmo ponto e em
pontos distintos. Na figura 3.5, as setas que apontam para a direita representam o curso de
interação para a execução da tarefa sem interrupções e os caminhos que contém ao menos
uma das setas que apontam para a esquerda representam cursos de execução da tarefa com
interrupções.
48
Figura 3.5: a decomposição da tarefa "Criar proposta de contrato de prestação de serviços"em diálogos.
É importante representar quais passos de uma tarefa podem ser interrompidos e quais
podem ser retomados após uma interrupção, pois deve existir um ato comunicativo para
transmitir estas decisões do designer ao usuário. Ou seja, este tipo de especificação deve ser
mapeado de alguma forma para a interface, como por exemplo, a existência de um marcador
ou mensagem em diálogos que podem ser interrompidos.
Não é possível representar interrupções de tarefas a partir dos componentes
apresentados na seção anterior. Desta forma, incorporamos a nosso modelo o componente
interrupção. Os passos de uma tarefa são representados em nosso modelo pelos diálogos que
a compõem. Desta forma, uma interrupção associa uma tarefa a um dos diálogos que a
compõem, indicando que este é um ponto de interrupção da tarefa. Os pontos de interrupção
são também os pontos de entrada para a continuação da tarefa. Embora a tarefa deva ser
sempre retomada a partir do ponto de interrupção, a interrupção também pode definir quais
pontos da tarefa (diálogos) anteriores a este podem ser revisados, quando o usuário retoma
a tarefa, caso haja.
Resumo dos componentes propostos para representar interações alternativas
A tabela 3.4 sumariza os componentes propostos para a representação de
possibilidades de interação alternativas, apresentando os fatores que as determinam e os
componentes do modelo de interação identificados em nosso modelo a partir da análise destes
fatores.
Forn. de Info.sobre Cliente
Forn. de Info.sobre Contato
Forn. de Info.sobre Serviço
Elaboração doCronograma
Registro daProposta
49
Fatores que Determinam Possibilidades deInteração Alternativas
Componentes do Modelo de InteraçãoDerivado
Estado da aplicação no momento da interação Contextos de interaçãoPossibilidades de escolha disponibilizadaspelo designer para o usuário
Tipos de articulação seleção e seleçãomúltipla
Mudanças dinâmicas no diálogo decorrentesde ações do usuário ao longo da interação
Eventos de diálogo
Tabela 3.4: Componentes do modelo de interação identificados a partir da análise de fatoresque determinam possibilidades de interação alternativas.
3.2.4 Componentes necessários para representar aplicações multi-usuário
Para ser abrangente, nosso modelo precisa considerar não somente aplicações mono-
usuário, mas também aplicações multi-usuário. Embora as mesmas questões consideradas
para o design de aplicações mono-usuário sejam relevantes para o design de aplicações multi-
usuário, este ainda requer a consideração de novas questões. Estas questões dizem respeito a
informações adicionais que precisam ser representadas na fase de modelagem da aplicação
pois influenciam sua funcionalidade e sua interface. São elas: os papéis dos membros e a
hierarquia da organização, os modelos colaborativos e as habilidades comunicativas dos
membros da organização sobre os objetos do domínio [Prates, 1998]. O modelo no qual estas
informações são representadas pode ser chamado de modelo de grupo.
Os componentes do modelo de grupo influenciam a interação em importantes
aspectos: influenciam as restrições de acesso a funções da aplicação, determinando diferentes
visões desta para diferentes tipos de usuários, além de determinar quais são as possibilidades
de comunicação entre usuários. Os papéis e a hierarquia influenciam as restrições de acesso a
funções e diferentes visões da aplicação, pois determinam qual é a distribuição da autoridade
entre o grupo. As informações sobre os objetos do domínio e suas habilidades comunicativas
determinam diferentes visões sobre estes objetos e restrições de acesso a operações
comunicativas sobre eles.
As possibilidades de comunicação entre usuários são muito bem representadas pelo
meta-modelo para a representação do modelo de grupo como parte da mensagem do designer,
definido em [Prates, 1998]. Entretanto, como este modelo não representa funções ou tarefas,
as restrições de acesso a funções não são representadas. Desta forma, criamos mecanismos
somente para representação deste aspecto do modelo de grupo que influencia a interação.
50
As restrições de acesso a funções da aplicação determinam diferentes visões desta para
diferentes tipos de usuários. Estas diferentes visões de interfaces representam quais diálogos
cada tipo de usuário pode iniciar e o que eles e o sistema podem enunciar nestes diálogos. Por
exemplo, em um Sistema Gerenciador de Biblioteca, somente o bibliotecário pode iniciar o
diálogo para o cadastro de publicações, pois é ele quem decidirá como organizá-las. A visão
da aplicação para um atendente, não apresentará diálogos para o cadastro de publicações.
Para representar as restrições de acesso a funções da aplicação decorrentes da estrutura
hierárquica do grupo, incorporamos ao nosso modelo o componente papel de usuário. Este
componente é caracterizado por dois atributos: o conjunto de tarefas que podem ser
executadas por usuários que exerçam o papel representado e o conjunto de papéis definidos
pela organização, superiores a ele. Definido desta forma, o componente permite a
representação de restrições ao acesso a funções da aplicação associadas ao papel do usuário.
As restrições quanto à inicialização de diálogos e ocorrência de enunciados de sistemas
associadas ao papel do usuário podem ser representadas através de contextos de interação, que
sejam caracterizados, entre outras coisas, pelo papel do usuário que está interagindo na
situação representada pelo contexto de interação.
51
Capítulo 4
Tipos Semânticos de Tarefas, Diálogos e Enunciados
Neste capítulo apresentamos os conjuntos de tipos semânticos de tarefas, diálogos e
enunciados propostos neste trabalho com o objetivo de facilitar a conscientização de
designers a respeito de suas intenções de comunicação. Ainda neste capítulo apresentamos
sugestões para o mapeamento entre os tipos semânticos identificados, elaboradas para auxiliar
designers a especificar cenários de interação de consistentes e de qualidade através do
formalismo proposto. Na seção 4.1 apresentamos tipos semânticos de tarefas, na seção 4.2
apresentamos tipos semânticos de diálogos e na seção 4.3 apresentamos tipos semânticos de
enunciados. Na seção 4.4 apresentamos nossas sugestões para a realização do mapeamento
entre os tipos semânticos apresentados.
4.1 Tipos Semânticos de Tarefas
Nesta seção apresentamos um conjunto de tipos semânticos de tarefas identificados
com base em sistemas de workflow baseados na web, desenvolvidos no TecGraf,
principalmente com base no Qualitas. Este é apenas um conjunto inicial e está aberto a
modificações. Foram identificados dois grupos de tipos semânticos de tarefas: tarefas que
atuam sobre objetos do domínio e tarefas que atuam sobre processos. A figura 4.1 ilustra estes
tipos, os quais serão descritos a seguir.
52
Tipos Semânticos de Tarefas
Tarefa que AtuaSobre Objeto do
Domínio
NotaçãoClasse
Relação de Herança: aclasse B é subclasse daclasse A.
A
<nome_classe>
B
Criação
Edição
Consulta aInformações
Destruição EncerramentoAvaliação
Registro deAtividadeComunicação
Tarefa
Desativação
Tarefa que AtuaSobre Processo
Planejamento
Figura 4.1: Tipos semânticos de tarefas identificados.
4.1.1 Tipos Semânticos de Tarefas que Atuam sobre Objetos do Domínio
A seguir apresentamos tipos semânticos de tarefas identificados que atuam sobre
objetos do domínio.
Criação
Este tipo semântico equivale a tarefas de criação de objetos do domínio, como, por
exemplo, a inclusão de uma publicação no cadastro de um Sistema Gerenciador de Biblioteca.
Edição
Este tipo semântico corresponde a tarefas de edição de informações sobre objetos do
domínio já criados, como, por exemplo, a edição de informações sobre uma publicação, em
um Sistema Gerenciador de Biblioteca.
53
Consulta a Informações
Este tipo semântico equivale a tarefas de consulta a informações sobre objetos do
domínio, como, por exemplo, a busca por informações sobre uma publicação, em um Sistema
Gerenciador de Biblioteca.
Comunicação
Este tipo semântico corresponde a tarefas de comunicação de informações referentes a
assuntos do domínio, para outras pessoas, através do sistema. Um exemplo deste tipo de tarefa
em um Sistema Gerenciador de Biblioteca é o envio de uma mensagem para locatários que
estão há mais de uma semana com atraso na devolução de publicações.
Destruição
Este tipo semântico equivale a tarefas de destruição completa de informações sobre
objetos do domínio. Um exemplo deste tipo de tarefa, em um Sistema Gerenciador de
Bibliotecas seria a exclusão do registro de uma publicação do cadastro do sistema.
4.1.2 Tipos Semânticos de Tarefas que Atuam sobre Processos
A seguir apresentamos tipos semânticos de tarefas identificados que atuam sobre
processos.
Planejamento
Este tipo semântico corresponde a tarefas de planejamento de atividades, como, por
exemplo, a elaboração de um plano de ações corretivas para o tratamento de uma não
conformidade na prestação de um serviço, registrada no Qualitas.
Registro de Atividade
Este tipo semântico equivale a tarefas de registro de informações sobre execução de
atividades, como, por exemplo, o registro da execução de uma ação de um plano de ações
corretivas.
54
Avaliação
Este tipo semântico corresponde a tarefas de tomada de decisão sobre o
prosseguimento ou mudança de etapa em um processo de trabalho1, como, por exemplo, a
verificação da eficácia de um plano de ações corretivas, no Qualitas. Após a execução de
todas as ações do plano, seu supervisor deve analisar se as ações remediaram a não
conformidade e, a partir desta análise, decidir se deve ser feito um novo plano de ações ou se
o processo pode ser encerrado.
Desativação
Este tipo semântico equivale a tarefas de desativação de um processo de trabalho, de
forma que informações referentes a ele sejam mantidas. Um exemplo deste tipo de atividade
no Qualitas é o cancelamento de um processo de tratamento de uma não conformidade.
Encerramento
Este tipo semântico corresponde a tarefas de encerramento por vias normais (sem
desativação ou destruição) de um processo de trabalho, como, por exemplo, o encerramento
de um processo de tratamento de uma não conformidade, no qual o supervisor informa suas
conclusões.
4.2 Tipos Semânticos de Diálogos
Nesta seção descrevemos o conjunto de tipos semânticos de diálogos identificado.
Apesar de este conjunto também ter sido elaborado a partir de sistemas de workflow, os tipos
identificados são independentes de domínio e de contexto. Ainda assim, o conjunto é inicial e
não está fechado para modificações. Os tipos semânticos de diálogos identificados estão
classificados em dois grandes grupos: diálogos onde o usuário é o falante predominante e
diálogos onde o falante predominante é o sistema. Nas próximas seções descreveremos os
tipos semânticos de diálogos em termos das intenções do designer ao propor o diálogo e em
termos do efeito que o falante predominante deseja causar sobre o ouvinte. É importante
1 Um processo de trabalho pode ser definido como "um conjunto de um ou mais procedimentos ou atividades
conectadas que, coletivamente, realizam um objetivo de trabalho ou meta de um plano, normalmente no contexto
de uma estrutura organizacional que define papéis e relacionamentos funcionais." [Lawrence, 1997].
55
ressaltar que os participantes do diálogo só podem desejar causar efeitos permitidos pelo
designer e que quando o sistema é o falante predominante, ele é apenas um porta-voz do
designer, ou seja, quem deseja causar efeitos com a "fala do sistema" é o designer e não o
sistema.
A figura 4.2 ilustra uma classificação dos tipos semânticos de diálogos identificados
neste trabalho. A seguir, descreveremos cada um destes tipos.
Tipos Semânticos de Diálogos
Apresentaçãode InformaçãoReferente ao
Domínio
Comunicaçãode SistemaFornecimento
de Informaçãode Controle
Solicitaçãode
Informaçãoao Sistema
Ajuda Feedback
Diálogo
Diálogo onde o Usuário é oFalante Predominante
Diálogo onde o Sistema éFalante Predominante
Seleção
Controlede Função
Customização
Solicitaçãode Ajuda
Solicitação deInformação
Referente aoDomínio
Fornecimentode InformaçãoReferente ao
Domínio
Confirmaçãode Operação
Comunicaçãode Usuário
Comunicaçãode UsuárioSíncrona
Comunicaçãode UsuárioAssíncrona
Notação
Classe Relação de Herança: aclasse B é subclasseda classe A.
A<nome_c lasse
>
B
Fornecimentode Informação
ao Sistema
Figura 4.2: Tipos semânticos de diálogos identificados.
4.2.1 Tipos Semânticos de Diálogos onde o Usuário é o Falante Predominante
Os tipos semânticos de diálogos onde o usuário é o falante predominante estão
classificados em três grupos: diálogos para o fornecimento de informação ao sistema, diálogos
para a solicitação de informação ao sistema e diálogos para a comunicação de usuário.
Apresentaremos a seguir os tipos semânticos pertencentes a cada um destes grupos.
56
Diálogos para o Fornecimento de Informação ao Sistema
Nestes tipos de diálogo o objetivo do designer é permitir que o usuário forneça ao
sistema algum tipo de informação necessária para a realização de suas tarefas. Existem
diálogos para Fornecimento de Informação Referente ao Domínio e diálogos para
Fornecimento de Informação de Controle.
Diálogos para o Fornecimento de Informação Referente ao Domínio são propostos
pelo designer para permitir ao usuário fornecer este tipo de informação, como por exemplo,
um diálogo para o fornecimento de informações sobre uma publicação, em um Sistema
Gerenciador de Biblioteca. Observe que as informações referentes ao domínio podem
compreender tanto os conceitos do domínio original como os introduzidos com a tecnologia.
Ao propor diálogos do tipo Fornecimento de Informação de Controle, o principal
efeito desejado pelo designer é que o usuário forneça informações de controle ao sistema. O
designer deseja comunicar que o usuário tem o controle da aplicação, ou seja, que ele tem
"livre arbítrio". Do ponto de vista do usuário, o efeito desejado, ao acionar estes tipos de
diálogo, é que o sistema obedeça o seu controle. Existem três tipos semânticos de diálogos
para Fornecimento de Informação de Controle: Seleção, Controle de Função e
Customização. Seleção corresponde a diálogos definidos para que o usuário escolha o que
quer fazer, dentre um conjunto de opções fornecidas pelo sistema como, por exemplo, o menu
de opções de um Sistema Gerenciador de Biblioteca. Controle de Função equivale a diálogos
definidos para que o usuário possa controlar a execução de uma função, ao mesmo tempo em
que toma conhecimento do progresso da execução. Um exemplo deste tipo de diálogo seria
um diálogo apresentado durante a realização de um Backup do banco de dados de um Sistema
Gerenciador de Biblioteca para indicar o estado de execução da função e possibilitar seu
cancelamento. Customização corresponde a diálogos estabelecidos para que o usuário possa
ajustar aspectos do sistema conforme suas preferências. Um exemplo deste tipo de diálogo
seria um diálogo para a configuração de impressão.
Diálogos para a Solicitação de Informação ao Sistema
Ao propor diálogos deste tipo, a principal intenção do designer é permitir que o
usuário solicite informações ao sistema. Da mesma forma, a intenção do usuário ao acioná-lo
é que o sistema forneça as informações de que ele necessita. Existem dois tipos semânticos de
57
diálogos classificados como Solicitação de Informação ao Sistema. Solicitação de
Informação Referente ao Domínio (conceitos do domínio original e/ou introduzidos com a
tecnologia) corresponde a diálogos definidos com o propósito de que o usuário solicite
informações desta natureza, como, por exemplo, um diálogo para montagem de consultas ao
banco de dados da aplicação. Solicitação de Ajuda caracteriza diálogos criados para que o
usuário solicite informações de ajuda para saber mais sobre um determinado tópico como, por
exemplo, um diálogo para busca de informação no banco de dados de ajuda.
Diálogos para a Comunicação de Usuário
A principal intenção do designer ao propor estes tipos de diálogo é permitir que o
usuário forneça informações relativas a uma ou mais comunicações que deseja fazer com um
ou mais agentes, através do sistema. O efeito desejado pelo usuário, ao acionar este tipo de
diálogo, é que o sistema envie sua(s) comunicação(ões) ao(s) devido(s) destinatário(s). Se a(s)
comunicação(ões) permitida(s) for(em) síncrona(s), o diálogo é classificado como
Comunicação de Usuário Síncrona. Se for(em) assíncrona(s), ele é classificado como
Comunicação de Usuário Assíncrona.
Para exemplificar, considere que um Sistema Gerenciador de Biblioteca possibilite ao
administrador comunicar-se com usuários que estão há mais de uma semana com atraso na
devolução de publicações. O diálogo proposto para a realização desta comunicação é
classificado como Comunicação de Usuário Assíncrona. Já um diálogo onde dois usuários se
comunicam sincronamente, como por exemplo, através de um chat como o ICQ, pode ser
classificado como Comunicação de Usuário Síncrona.
4.2.2 Tipos Semânticos de Diálogos onde o Sistema é o Falante Predominante
Os diálogos onde o sistema é o falante predominante são quase monólogos do sistema,
mas não podem ser considerados como tal, pois o usuário atua no diálogo, ainda que
minimamente. Eventualmente ele solicita detalhes ou esclarecimentos sobre uma determinada
informação e, ao fim do diálogo, ele sempre toma uma decisão sobre o que fazer depois de
analisar tudo o que foi apresentado pelo sistema, decisão esta que determina o próximo
diálogo a ser travado. A seguir descrevemos os tipos semânticos de diálogos onde o sistema é
o falante predominante.
58
Apresentação de Informação Referente ao Domínio
A principal intenção do designer ao propor um diálogo deste tipo é apresentar, ao
usuário, informações relativas a conceitos do domínio original e/ou introduzidos com a
tecnologia. Podem ser apresentadas informações sobre um único objeto ou sobre um grupo de
objetos. Um exemplo de diálogo para Apresentação de Informação Referente ao Domínio, em
um Sistema Gerenciador de Biblioteca, é um diálogo para apresentação de informações sobre
uma publicação.
Confirmação de Operação
Um diálogo com semântica de Confirmação de Operação é proposto quando o
designer tem a intenção de permitir ao usuário confirmar operações que podem ter
conseqüências importantes para o estado da aplicação, incluindo conseqüências que podem
ser revertidas, como a inclusão ou alteração de informações e conseqüências que não o
podem, como a destruição de informações. Neste tipo de diálogo, além de perguntar, através
do sistema, se o usuário deseja ou não confirmar a operação, o designer deve apresentar
informações referentes a operação (que podem se referir ou não a objetos do domínio) que
auxiliem o usuário a tomar sua decisão. Um exemplo de diálogo com semântica de
Confirmação de Operação em um Sistema Gerenciador de Biblioteca é o diálogo para a
confirmação das informações fornecidas para cadastro de uma publicação, no qual o sistema
apresenta todas as informações fornecidas, de forma que o usuário possa revisá-las e verificar
se deve alterá-las antes de confirmar o término da tarefa.
Ajuda
O designer apresenta diálogos deste tipo quando tem a intenção de eliminar dúvidas
que o usuário possa ter sobre a realização de uma tarefa com utilização da aplicação ou
ensiná-lo a realizá-la desde o início. Qualquer diálogo onde é apresentada informação de
ajuda em qualquer sistema exemplifica este tipo semântico.
Feedback
Estes diálogos são apresentados pelo designer para informar ao usuário sobre o
resultado de suas últimas ações. O efeito desejado pelo designer é que o usuário não fique
59
insatisfeito ou inseguro por não saber se as ordens que deu foram ou estão sendo cumpridas e,
no caso de estarem sendo cumpridas, quanto tempo ainda vão demorar. Um exemplo deste
tipo de diálogo, possível em qualquer aplicação, seria um onde o sistema informasse ao
usuário que as informações que ele forneceu foram armazenadas com sucesso.
Comunicação de Sistema
Estes diálogos são apresentados pelo designer, quando ele tem a intenção de realizar
uma comunicação síncrona do sistema com um ou mais usuários sobre fatos de seu interesse
ou que influenciarão sua utilização do sistema como, por exemplo, o quadro de avisos sobre
tarefas pendentes do Qualitas. O efeito desejado pelo designer é auxiliar o usuário na
realização de suas tarefas.
4.3 Tipos Semânticos de Enunciados
Cada enunciado componente de diálogos pré-estabelecidos pelo designer é
disponibilizado por ele com um determinado propósito. Os enunciados de usuário são a
expressão das intenções de comunicação do usuário permitidas pelo designer. Os enunciados
de sistema representam as intenções de comunicação do próprio designer, tendo o sistema
como porta-voz. Para que a especificação de modelos de interação baseados em nosso meta-
modelo permita que o designer explicite estas intenções de comunicação, identificamos tipos
semânticos de enunciados de usuário e de sistema, independentes de domínio e de contexto.
Os tipos semânticos identificados serão descritos a seguir.
4.3.1 Tipos Semânticos de Enunciados de Usuário
Nesta seção apresentamos os tipos semânticos de enunciados de usuário identificados
neste trabalho. A figura 4.3 ilustra estes tipos. Há dois tipos principais dos quais todos os
demais tipos são subtipos: Fornecimento de Informação, Controle da Interação e
Solicitação de Informação. Descreveremos estes tipos e seus subtipos de enunciados de
usuário nas próximas seções.
60
Reinicializaçãodo Diálogo
Controle daInteração
Tipos Semânticos de Enunciados de Usuário
Fornecimento deInformação Referente
ao Domínio
Customização
Mudança deTópico
Controlede Função
Acionamentode Função
Cancelamentode Função
Interrupçãode Função
Retomada deFunção
Controle doFluxo da
Tarefa
ConfirmaçãoLocal
Solicitaçãode Revisão
ConfirmaçãoParcial
ConfirmaçãoTotal
Controle doDiálogo
Interrupçãodo Diálogo
Retomadado Diálogo
Cancelamentodo Diálogo
Solicitação deExtensão do
Diálogo
Solicitação deInformação
Solicitação deDetalhes
Solicitaçãode Ajuda
ComunicaçãoInterpessoal
ComunicaçãoAssíncrona
ComunicaçãoSíncrona
Solicitação deCancelamento
da Tarefa
Fornecimentode Informação
Enunciadode Usuário
Notação
Classe
Relação de Herança: ac lasse B é subclasse daclasse A.
A
<nome_c lasse>
B
Figura 4.3: Tipos semânticos de enunciados de usuário identificados.
Enunciados para o Fornecimento de Informação
Estes tipos de enunciados objetivam fornecer ao sistema algum tipo de informação
necessária para a realização da tarefa. Seus três subtipos serão apresentados a seguir.
Customização
Este tipo de enunciado é emitido pelo usuário quando ele deseja ajustar aspectos do
sistema conforme suas preferências para a configuração da aplicação. Considerando-se um
61
Sistema Gerenciador de Biblioteca, um exemplo deste tipo de enunciado seria a informação
sobre o número máximo de publicações que devem ser exibidas por diálogo onde são
apresentados resultados de pesquisa por publicações, sem que o usuário tenha que acionar a
exibição das próximas publicações.
Comunicação Interpessoal
Emitindo estes tipos de enunciado, o usuário tem por objetivo se comunicar com
outros usuários através do sistema. Há dois subtipos de enunciados do tipo Comunicação.
Comunicação Síncrona representa comunicações síncronas como, por exemplo, as
mensagens enviadas através de chats como o ICQ. Comunicação Assíncrona representa
comunicações assíncronas como, por exemplo textos de e-mails, os quais são mensagens que
podem vir a ser lidas pelo destinatário muito tempo depois de emitidas.
Fornecimento de Informação Referente ao Domínio
Este tipo semântico representa enunciados emitidos pelo usuário quando ele tem a
intenção de comunicar ao sistema informações referentes ao domínio requisitadas por este em
nome do designer. Estas informações estão sempre associadas a um conceito da aplicação (do
domínio original ou introduzido com a tecnologia) definido. Como exemplos, consideremos
os enunciados nos quais o bibliotecário informa o título de uma publicação ou o código de
barra fixado a ela, ao cadastrá-la em um Sistema Gerenciador de Biblioteca.
Enunciados para Controle da Interação
A intenção que o usuário tem quando emite um enunciado do tipo Controle da
Interação é solicitar o controle de algum aspecto da interação, como o fluxo da tarefa, a
ocorrência dos diálogos, as funções do sistema ou até mesmo a leitura de informações. A
seguir descreveremos os subtipos do tipo Controle da Interação.
Mudança de Tópico
Este enunciado é emitido quando o usuário deseja mudar de tópico e sempre causa a
finalização do diálogo ativo. Um exemplo de enunciado da classe Mudança de Tópico é o
acionamento de uma âncora para uma referência citada por uma publicação. Com esta
62
interação, usuário e sistema passam a "falar" sobre a publicação referenciada, deixando de
falar sobre a publicação que a cita.
Controle de Função
Emitindo estes tipos de enunciado, o usuário tem por objetivo controlar a execução de
uma função. Há quatro tipos de enunciados do tipo Controle de Função. Acionamento de
Função representa enunciados emitidos pelo usuário quando ele tem o objetivo requisitar a
execução de uma função da aplicação. Interrupção de Função representa enunciados
emitidos pelo usuário quando ele tem o objetivo de interromper temporariamente a execução
de uma função. Retomada de Função representa enunciados emitidos pelo usuário quando
ele tem o objetivo de retomar a execução interrompida de uma função. Cancelamento de
Função classifica enunciados emitidos pelo usuário quando ele tem o objetivo de cancelar a
execução de uma função.
Para exemplificar os enunciados do tipo Controle de Função, consideremos a interação
para a realização de Backup do banco de dados de um Sistema Gerenciador de Biblioteca.
Para iniciar o Backup o usuário emite um enunciado de Acionamento de Função. O designer
pode disponibilizar um diálogo, durante a execução da função Backup, que permita ao usuário
interrompê-la (Interrupção de Função) para posteriormente retomá-la (Retomada de
Função) ou cancelá-la (Cancelamento de Função).
Controle do Diálogo
Emitindo estes tipos de enunciado, o usuário tem por objetivo controlar o diálogo
corrente. A identificação destes tipos de enunciados baseia-se nos controles de ocorrência de
diálogo apresentados no capítulo anterior. Há seis subtipos de enunciados do tipo Controle
do Diálogo. Interrupção do Diálogo representa enunciados emitidos pelo usuário quando ele
deseja interromper temporariamente o diálogo corrente. Retomada do Diálogo representa
enunciados emitidos quando o usuário deseja retomar um diálogo interrompido.
Cancelamento do Diálogo representa enunciados cujo objetivo é cancelar o diálogo. Observe
que o cancelamento de um diálogo pode representar a interrupção da tarefa corrente, mas não
o seu cancelamento. Reinicialização do Diálogo representa enunciados cujo objetivo é
reiniciar o diálogo inerente à interação com ou sem sugestões do sistema. Solicitação de
Extensão do Diálogo representa enunciados cujo objetivo é solicitar a extensão do diálogo,
63
ou seja, solicitar alterações dinâmicas no diálogo, como por exemplo, a inclusão de
enunciados.
Para exemplificar estes tipos de enunciados, consideremos um Sistema Gerenciador de
Biblioteca. Em uma interação para a apresentação de resultados de uma pesquisa por
publicações, podem ser apresentadas âncoras para diversos diálogos, cada diálogo associado à
apresentação de informações sobre uma das publicações encontradas pela pesquisa. Ao
interagir com um destes diálogos o usuário pode desejar interrompê-lo temporariamente
(Interrupção do Diálogo) para acionar outro e posteriormente retomá-lo (Retomada do
Diálogo) ou até cancelá-lo (Cancelamento do Diálogo).
Para exemplificar enunciados do tipo Reinicialização do Diálogo, consideremos que
devido à chegada de novos exemplares à biblioteca, um bibliotecário está alterando a
informação sobre a quantidade de exemplares de publicações seguindo um roteiro escrito em
papel. Após alterar a quantidade de exemplares da publicação "A", ele percebe que leu o
número de novos exemplares da publicação "B". Para desfazer sua alteração, ao invés de
subtrair da quantidade de exemplares de "A" a quantidade de novos exemplares de "B", ele
prefere emitir um enunciado do tipo Reinicialização do Diálogo, aceitando as sugestões do
sistema para seus enunciados. Como estas sugestões indicam os valores originais das
informações referentes à publicação "A" antes da alteração, ele obtém a quantidade original
de exemplares de "A".
Para exemplificar enunciados do tipo Solicitação de Extensão do Diálogo, considere
um diálogo para cadastro de informações sobre uma publicação. Neste diálogo o designer
pode sugerir que o usuário informe até 10 palavras-chave, mas pode permitir que ele estenda
o diálogo caso deseje fornecer mais palavras-chave. Ao solicitar esta extensão, o usuário
emite um enunciado com semântica Solicitação de Extensão do Diálogo.
Controle do Fluxo da Tarefa
Emitindo estes tipos de enunciado, o usuário tem por objetivo controlar o fluxo da
tarefa que está executando através da interação com o sistema. Há cinco subtipos de
enunciado do tipo Controle do Fluxo da Tarefa. Solicitação de Revisão representa
enunciados emitidos pelo usuário quando ele deseja revisar passos anteriores da tarefa que
está executando. Confirmação Parcial representa enunciados emitidos pelo usuário quando
64
ele deseja confirmar tudo o que já realizou da tarefa até um determinado instante e prosseguir
para o próximo passo do fluxo da tarefa. Confirmação Local representa enunciados emitidos
pelo usuário quando ele deseja confirmar tudo o que já realizou da tarefa até um determinado
instante sem avançar no seu fluxo. Confirmação Total representa enunciados emitidos pelo
usuário quando ele deseja confirmar a completude da tarefa. Solicitação de Cancelamento
da Tarefa representa enunciados que o usuário emite com a intenção de cancelar a tarefa.
Para exemplificar os enunciados para controle de fluxo de tarefa descritos, considerem
novamente um Sistema Gerenciador de Biblioteca. Em uma interação para cadastro de
publicação, o usuário poderia escolher entre salvar as informações já fornecidas sem
prosseguir (Confirmação Local) ou prosseguindo com a tarefa (Confirmação Parcial) para
uma interação para confirmação das informações fornecidas. Nesta interação o usuário
poderia escolher entre revisar as informações fornecidas (Solicitação de Revisão) ou
confirmá-las (Confirmação Total) concluindo a tarefa. E em qualquer diálogo componente
da tarefa o usuário pode decidir cancelá-la (Solicitação de Cancelamento da Tarefa).
Os enunciados para Controle do Fluxo da Tarefa sempre causam a inicialização de um
novo diálogo, causando a finalização do diálogo ativo, excetuando-se enunciados do tipo
Confirmação Local, que mantêm o mesmo diálogo.
Enunciados para Solicitação de Informação
Os enunciados deste tipo são emitidos pelo usuário quando ele tem a intenção de
solicitar alguma informação ao sistema. Estes tipos de enunciado sempre causam a
inicialização de um novo diálogo, sem finalizar o diálogo ativo (apenas o interrompem
temporariamente). A seguir descreveremos os dois tipos de enunciados para a solicitação de
informação identificados.
Solicitação de Detalhes
Este tipo semântico representa enunciados com os quais o usuário objetiva obter mais
detalhes sobre informação referente a um conceito da aplicação, já apresentada pelo sistema
no diálogo. Por exemplo, considerando-se um Sistema Gerenciador de Biblioteca, podemos
classificar como Solicitação de Detalhes o acionamento de uma âncora para o resumo do
65
conteúdo de uma publicação em um diálogo onde o sistema apresenta informações sobre a
publicação.
Solicitação de Ajuda
Este tipo semântico representa enunciados que objetivam obter informações de ajuda.
Como exemplos, podemos considerar o acionamento de uma âncora para um texto de ajuda,
em qualquer sistema.
Sobreposição de Tipos Semânticos de Enunciados de Usuário
Alguns enunciados de usuário podem ser instâncias de mais de um dos tipos
semânticos apresentados. Para exemplificar isto, consideremos o Qualitas. Uma das
características do domínio deste sistema é que algumas das comunicações referentes à
prestação de serviços enviadas e recebidas pelos funcionários da organização devem ser
guardadas como documentos associados a estes serviços. Desta forma, um enunciado do
usuário onde ele informa ao sistema uma comunicação que deseja fazer a outra pessoa,
através do sistema, instancia, ao mesmo tempo, os tipos semânticos Comunicação de
Usuário Assíncrona e Fornecimento de Informação Referente ao Domínio (neste caso o
objeto é o serviço prestado). A tabela 4.1 apresenta esta e outras possíveis sobreposições de
tipos semânticos de enunciados de usuário identificadas neste trabalho.
66
Tipo Semântico Possíveis SobreposiçõesCustomização Fornecimento de Informação Referente ao
Domínio, Comunicação InterpessoalComunicação Interpessoal Customização, Fornecimento de Informação
Referente ao DomínioFornecimento de Informação Referenteao Domínio
Customização, Comunicação Interpessoal
Solicitação de Detalhes Mudança de Tópico, Interrupção do Diálogo,Cancelamento do Diálogo
Solicitação de Ajuda Mudança de Tópico, Interrupção do DiálogoMudança de Tópico Solicitação de Detalhes, Solicitação de Ajuda,
Interrupção do Diálogo, Cancelamento do Diálogo,Solicitação de Cancelamento da Tarefa, Retomadado Diálogo (outro, que aborda o novo tópico)
Acionamento de Função Confirmação Total, Confirmação Parcial,Cancelamento do Diálogo
Interrupção de Função Interrupção do Diálogo, Cancelamento do Diálogo,Retomada do Diálogo (outro)
Retomada de Função Retomada do DiálogoCancelamento de Função Cancelamento do DiálogoInterrupção do Diálogo Interrupção de Função, Retomada do Diálogo
(outro)Retomada do Diálogo Mudança de Tópico, Retomada de Função,
Interrupção de Função, Interrupção do Diálogo(outro), Cancelamento do Diálogo (outro)
Cancelamento do Diálogo Mudança de Tópico, Acionamento de Função,Cancelamento de Função, Solicitação deCancelamento da Tarefa,Retomada do Diálogo (outro)
Solicitação de Revisão Cancelamento do DiálogoConfirmação Parcial Cancelamento do DiálogoConfirmação Total Cancelamento do DiálogoSolicitação de Cancelamento da Tarefa Mudança de Tópico, Cancelamento do Diálogo
Tabela 4.1: Sobreposições de tipos semânticos de enunciados de usuário identificadas nestetrabalho.
4.3.2 Tipos Semânticos de Enunciados de Sistema
A seguir apresentaremos os tipos semânticos de enunciados que o sistema pode emitir
representando o designer, identificados neste trabalho. A figura 4.4 ilustra estes tipos
semânticos.
67
Enunciadode Sistema
Tipos Semânticos de Enunciados de Sistema
Apresentaçãode InformaçãoReferente ao
DomínioComunicação
de UsuárioRemoto
Parêntese
Comunicaçãode Sistema
AjudaPreventiva
Solicitaçãode
Informação
Aposto
InformaçãoContextual
Ajuda
Feedback
AjudaCorretiva
AjudaExplicativa
Notação
Classe Relação de Herança: ac lasse B é subc lasseda c lasse A.
A<nome_classe
>
B
Comunicaçãode Usuário
RemotoSíncrona
Comunicaçãode Usuário
RemotoAssíncrona
Figura 4.4: a hierarquia de tipos semânticos de enunciados de sistema identificados.
Solicitação de Informação
Enunciados deste tipo objetivam solicitar que o usuário forneça informações. Um
exemplo deste tipo de enunciado em um Sistema Gerenciador de Biblioteca, é a solicitação do
título de uma publicação em um diálogo para o fornecimento de informações sobre este objeto
do domínio.
Apresentação de Informação Referente ao Domínio
Enunciados com esta semântica objetivam apresentar ao usuário informações
associadas a conceitos da aplicação (original ou introduzidos com a tecnologia), como, por
exemplo, o título de uma publicação ou qualquer outra informação associada a ela.
Aposto
Enunciados deste tipo estão sempre associados a outros enunciados de sistema. Eles
funcionam como apostos para estes enunciados, indicando para o usuário o que significa a
informação que eles apresentam. Por exemplo, "ISBN:" é um aposto para "0-201-62769-8",
que é uma apresentação de uma informação (ISBN) referente conceito do domínio (Livro).
68
Informação Contextual
Um enunciado deste tipo objetiva apresentar informações que indiquem o tópico, o
subtópico ou o foco que estão sendo discutidos em um diálogo. Um exemplo de Informação
Contextual é a descrição da tarefa que está sendo executada ou alguma informação que
identifique o objeto específico do domínio que está sendo manipulado durante a tarefa. No
diálogo para cadastro de publicação, em um Sistema Gerenciador de Biblioteca, os
enunciados "Alteração de Publicação", "Human Computer Interaction" e "Jenny Preece et.
al." podem ser usados para contextualizar a tarefa, indicando o tópico (tarefa sendo
executada) e o foco (objeto do domínio manipulado).
Ajuda
Os enunciados do tipo Ajuda têm o propósito de auxiliar o usuário na utilização do
sistema, seja com informações sobre a interface ou sobre o domínio da aplicação. Há três
classes de enunciado do tipo Ajuda. Ajuda Preventiva classifica enunciados que objetivam
evitar que o usuário cometa erros. Eles se caracterizam por serem emitidos para o usuário sem
que ele os solicite. Ajuda Corretiva classifica enunciados que objetivam auxiliar o usuário a
corrigir erros já ocorridos, sendo emitidos sempre que ocorre algum erro para o qual a
correção é de conhecimento do designer. Ajuda Explicativa classifica enunciados que
objetivam eliminar dúvidas que o usuário possa ter sobre a realização de uma tarefa com
utilização da aplicação ou ensiná-lo a realizá-la desde o início. Estes enunciados são emitidos
somente quando solicitados pelo usuário, quando este deseja saber mais sobre como utilizar o
sistema ou sobre o próprio domínio da aplicação.
Feedback
Enunciados com esta semântica têm o propósito de informar ao usuário sobre o
resultado de suas últimas ações ou sobre o andamento de uma tarefa longa executada pelo
sistema, para não deixá-lo sem uma resposta e manter a conversa. Um exemplo de enunciado
do tipo Feedback, em um Sistema Gerenciador de Biblioteca, seria uma mensagem que
indicasse que as informações fornecidas pelo usuário ao cadastrar uma publicação, foram
armazenadas com sucesso.
69
Parêntese
Enunciados deste tipo representam um parêntese no diálogo entre usuário e sistema,
uma informação que tem apenas uma relação indireta com o tópico sendo discutido, como,
por exemplo, um pequeno resumo da biografia de Paramahansa Yogananda em um diálogo
onde o sistema apresenta informações sobre um livro escrito por ele.
Comunicação de Sistema
Enunciados deste tipo objetivam comunicar, sincronamente, ao usuário, fatos de seu
interesse ou que influenciarão a sua utilização do sistema, como por exemplo avisos sobre
tarefas de sua responsabilidade que estejam pendentes. Considerando-se um Sistema
Gerenciador de Biblioteca, um exemplo de comunicação síncrona é uma mensagem
apresentada ao administrador da biblioteca assim que ele entra no sistema, informando que
usuários da biblioteca ele deve notificar por estarem devendo livros há mais de uma semana.
Comunicação de Usuário Remoto
Enunciados deste tipo objetivam comunicar mensagens de usuários remotos enviadas
para o usuário que está interagindo com o sistema, através dele. Esta comunicação também
pode ser síncrona (Comunicação de Usuário Remoto Síncrona) ou assíncrona
(Comunicação de Usuário Remoto Assíncrona). Um exemplo de comunicação síncrona
seria a apresentação de uma mensagem enviada por um usuário remoto através de um chat,
como o ICQ. Um exemplo de comunicação assíncrona seria a apresentação do conteúdo de
um e-mail enviado por um usuário remoto.
Sobreposição de Tipos Semânticos de Enunciados de Sistema
Enunciados de sistema também podem ser instâncias de mais de um tipo semânticos.
Para exemplificar este fato, vamos aproveitar o exemplo apresentado para exemplificar a
sobreposição de tipos semânticos de enunciados de usuário. Um enunciado do sistema que
apresenta uma comunicação recebida por um usuário do Qualitas instancia, ao mesmo tempo,
o tipo semântico Comunicação de Usuário Remoto Assíncrona e Apresentação de
Informação Referente ao Domínio (o objeto é o serviço prestado). A tabela 4.2 apresenta
70
esta e outras possíveis sobreposições de tipos semânticos de enunciados de sistema
identificadas neste trabalho.
Tipo Semântico Possíveis SobreposiçõesApresentação de Informação Referente aoDomínio
Informação Contextual, Comunicação deUsuário Remoto Assíncrona
Aposto Informação ContextualInformação Contextual Aposto, Apresentação de Informação
Referente ao DomínioAjuda Preventiva Comunicação de SistemaAjuda Corretiva Feedback, Comunicação de SistemaFeedback Ajuda Corretiva, Comunicação de SistemaComunicação de Sistema Ajuda Preventiva, Ajuda CorretivaComunicação de Usuário Remoto Assíncrona Apresentação de Informação ao Domínio
Tabela 4.2: Sobreposições de tipos semânticos de enunciados de sistema identificadas nestetrabalho.
4.4 Sugestões para o mapeamento entre os tipos semânticos
Nesta seção, apresentamos sob a forma de templates, nossas sugestões para o
mapeamento entre os tipos semânticos de tarefas, diálogos e enunciados apresentados. Estes
templates funcionam como regras semânticas para o formalismo proposto neste trabalho a ser
descrito no próximo capítulo. Para definir estes templates, utilizamos a seguinte notação:
• As palavras Seqüência, Agrupamento, Seleção Exclusiva, Seleção Múltipla,
Combinação e Repetição indicam o tipo de articulação de uma estrutura de tipos
semânticos de diálogos ou enunciados.
• Os elementos articulados são definidos entre { }, após a palavra que representa o tipo de
articulação.
• A expressão [tipo_semantico] representa que a ocorrência do tipo semântico
tipo_semantico é opcional, ou seja, ele pode ocorrer ou não.
• A expressão (exp1 | exp2 ... | expN) representa que é possível a ocorrência de qualquer
uma das expressões expI.
• A expressão (tipo_semantico1 & tipo_semantico2 ... & tipo_semanticoN) representa que
ocorre um enunciado que instancia ao mesmo todos os tipos semânticos tipo_semanticoI.
• A expressão (tipo_semantico_enunciado_sistema » tipo_semantico_enunciado_usuario)
representa que um enunciado do sistema com semântica tipo_semantico_enunciado_sistema
71
tem potencial para inspirar o usuário a emitir um enunciado com semântica
tipo_semantico_enunciado_usuario, cujo efeito é a inicialização de um outro diálogo.
• A expressão (tipo_semantico)* representa que é possível a ocorrência de 0 ou mais
diálogos/enunciados que instanciem o tipo semântico tipo_semantico.
• A expressão (tipo_semantico)+ representa que é possível a ocorrência de 1 ou mais
diálogos/enunciados que instanciem o tipo semântico tipo_semantico.
4.4.1 Templates sugeridos para especificar tarefas
Nesta seção apresentaremos os templates sugeridos para a especificação dos tipos
semânticos de tarefas identificados através de estruturas de tipos semânticos de diálogos. Para
cada template, forneceremos uma explicação que descreve as motivações para nossas
sugestões.
Template para a especificação de tarefas do tipo Criação
Sugerimos que as tarefas do tipo Criação sejam especificadas de acordo com o
seguinte template:
Seqüência{
(Fornecimento de Informação Referente ao Domínio)+Confirmação de OperaçãoFeedback
}
Explicação
Para criar um objeto do domínio o usuário deve informar seus atributos ao sistema.
Isto é feito através de um ou mais diálogos que têm a semântica Fornecimento de
Informação Referente ao Domínio. Após informar todos os atributos do objeto, o usuário
deve ter a chance de revisar as informações fornecidas a fim de confirmar se estão corretas
antes de finalizar a tarefa. Isto é feito através de um diálogo com semântica Confirmação de
Operação. Finalmente, após o usuário confirmar as informações e solicitar que o sistema as
armazene, o sistema deve apresentar um Feedback informando se o armazenamento foi
realizado ou não com sucesso, o que é feito através de um diálogo com semântica Feedback.
72
Template para a especificação de tarefas do tipo Edição
Sugerimos que as tarefas do tipo Edição sejam especificadas de acordo com o seguinte
template:
seqüência{
(Seleção(Fornecimento de Informação Referente ao Domínio)+Confirmação de OperaçãoFeedback
)|(
Solicitação de Informação Referente ao Domínio(Feedback|([Seleção](Fornecimento de Informação Referente ao Domínio)+Confirmação de OperaçãoFeedback
))
)}
Explicação
Este template é similar ao template sugerido para a representação da tarefa criação. A
diferença é que antes de começar a editar as informações sobre um determinado objeto do
domínio, o usuário deve indicar ao sistema que objeto deseja editar. Isto pode ser feito de
duas maneiras: ou o sistema apresenta ao usuário uma lista com todos os objetos que ele pode
editar, solicitando que ele escolha um, através de um diálogo com semântica Seleção e após
esta escolha inicia-se um diálogo com semântica Fornecimento de Informação Referente ao
Domínio associado ao objeto escolhido; ou o usuário informa ao sistema parâmetros para a
realização da busca pelo objeto que deseja editar, através de um diálogo com semântica de
Solicitação de Informação Referente ao Domínio. Neste caso, há três possibilidades de
interação. Se não for encontrado nenhum objeto o sistema deve informar isto ao usuário
através de um diálogo com semântica Feedback. Se for encontrado um único objeto, o
sistema deve iniciar o diálogo com semântica Fornecimento de Informação Referente ao
Domínio, associado a este objeto. Se for encontrado mais de um objeto, o sistema deve iniciar
um diálogo com semântica Seleção para que o usuário escolha qual destes objetos deseja
73
alterar antes de iniciar o diálogo com semântica Fornecimento de Informação Referente ao
Domínio.
Template para a especificação de tarefas do tipo Consulta a Informações
Sugerimos que as tarefas do tipo Consulta a Informações sejam especificadas de
acordo com o seguinte template:
seqüência{
(SeleçãoApresentação de Informação Referente ao Domínio
)|(
Solicitação de Informação Referente ao Domínio(Feedback|Apresentação de Informação Referente ao Domínio
(Seleção Apresentação de Informação Referente ao Domínio)
|(Apresentação de Informação Referente ao Domínio)+)
)}
Explicação
Para consultar informações sobre um ou mais objetos do domínio, o usuário deve
primeiramente indicar ao sistema quais são estes objetos. Isto pode ser feito de duas maneiras:
ou o sistema apresenta ao usuário uma lista com todos os objetos sobre os quais ele pode
consultar informações, solicitando que ele escolha um, através de um diálogo com semântica
Seleção e após esta escolha apresenta informações sobre o objeto através de um diálogo com
semântica Apresentação de Informação Referente ao Domínio; ou o usuário informa ao
sistema parâmetros para a realização da busca pelos objetos sobre os quais deseja consultar
informações, através de um diálogo com semântica de Solicitação de Informação Referente
ao Domínio. Neste caso, há diversas possibilidades de interação. Se não for encontrado
nenhum objeto, o sistema deve informar isto ao usuário através de um diálogo com semântica
Feedback. Se for encontrado um único objeto, o sistema deve iniciar o diálogo com semântica
Apresentação de Informação Referente ao Domínio, associado a este objeto. Se for
encontrado mais de um objeto, o sistema deve iniciar um diálogo com semântica Seleção para
que o usuário escolha sobre qual destes objetos deseja consultar informações, antes de iniciar
o diálogo com semântica Apresentação de Informação Referente ao Domínio. Outra
74
possibilidade é que o sistema inicie um diálogo com semântica Apresentação de Informação
Referente ao Domínio que apresente informações sobre o primeiro objeto encontrado e que
permita ao usuário iniciar outro diálogo com a mesma semântica, que apresente as
informações referentes ao próximo objeto encontrado e assim sucessivamente.
Template para a especificação de tarefas do tipo Comunicação
Sugerimos que as tarefas do tipo Comunicação sejam especificadas de acordo com o
seguinte template:
seqüência{
(Comunicação InterpessoalFeedback)+
}
Explicação
Para realizar uma comunicação, o usuário deve iniciar um diálogo com semântica
Comunicação Interpessoal (síncrona ou assíncrona). Após finalizar a comunicação, o
sistema deve informar ao usuário se ela foi enviada (no caso de ser assíncrona), ou se foi
encerrada (no caso de ser síncrona) com sucesso. Isto é feito através de um diálogo com
semântica Feedback. Uma tarefa de comunicação pode envolver diversas comunicações e
desta forma, ela pode ser composta por uma ou mais seqüências de diálogos com semânticas
Comunicação Interpessoal e Feedback.
Template para a especificação de tarefas do tipo Destruição ou Desativação
Sugerimos que as tarefas do tipo Destruição ou Desativação sejam especificadas de
acordo com o seguinte template:
75
seqüência{
(SeleçãoConfirmação de OperaçãoFeedback
)|(
Solicitação de Informação Referente ao Domínio(Feedback|(
[Seleção]Confirmação de OperaçãoFeedback
))
)}
Explicação
Para realizar uma tarefa de destruição de objeto ou desativação de processo, o usuário
deve, inicialmente, informar ao sistema qual o objeto que deseja destruir ou o processo que
deseja desativar. Isto pode ser feito de duas maneiras: ou o sistema apresenta ao usuário uma
lista com todos os objetos que ele pode destruir/processos que ele pode desativar, solicitando
que ele escolha um, através de um diálogo com semântica Seleção e após esta escolha
apresenta informações sobre o objeto/processo e solicita a confirmação da operação através de
um diálogo com semântica Confirmação da Operação; ou o usuário informa ao sistema
parâmetros para a realização da busca pelo objeto/processo sobre o qual deseja atuar, através
de um diálogo com semântica de Solicitação de Informação Referente ao Domínio. Neste
caso, há diversas possibilidades de interação. Se não for encontrado nenhum objeto ou
processo o sistema deve informar isto ao usuário através de um diálogo com semântica
Feedback. Se for encontrado um único objeto ou processo, o sistema deve apresentar
informações sobre este objeto ou processo ao usuário e solicitar que ele confirme se realmente
deseja destruir o objeto/desativar o processo. Isto é feito através de um diálogo com semântica
Confirmação de Operação. Se for encontrado mais de um objeto/processo, o sistema deve
iniciar um diálogo com semântica Seleção para que o usuário escolha sobre qual destes
objetos/processos deseja atuar e só depois da escolha do usuário é iniciado um diálogo com
semântica Confirmação da Operação. Por fim, após a confirmação da operação o sistema
deve informar ao usuário se esta foi ou não realizada com sucesso. Isto é feito através de um
diálogo com semântica Feedback.
76
Template para a especificação de tarefas do tipo Planejamento
Sugerimos que as tarefas do tipo Planejamento sejam especificadas de acordo com o
seguinte template:
seqüência{
(Fornecimento de Informação Referente ao Domínio)+Confirmação de Operação(
(Comunicação de UsuárioFeedback)*|Feedback
)}
Explicação
Para realizar uma tarefa com semântica Planejamento o usuário deve inicialmente
elaborar um cronograma de atividades e informá-lo ao sistema. Isto é feito através de um ou
mais diálogos com semântica Fornecimento de Informação Referente ao Domínio. Após
terminar de elaborar o cronograma, o usuário deve ter a chance de revisar as informações
fornecidas a fim de confirmar se estão corretas antes de finalizar a tarefa. Isto é feito através
de um diálogo com semântica Confirmação de Operação. Após confirmar as informações, o
usuário deve comunicar o cronograma aos indivíduos envolvidos ou interessados nas
atividades que o compõem, caso haja. Para isto, devem ser iniciados um ou mais diálogos
com semântica Comunicação de Usuário. Após a solicitação de envio da comunicação feita
pelo usuário, em cada um destes diálogos, o sistema deve informar se a comunicação foi ou
não enviada com sucesso, o que é feito através de um diálogo com semântica Feedback.
Quando não há outras pessoas envolvidas no cronograma, após a confirmação das
informações fornecidas, o sistema deve apenas informar se elas foram ou não armazenadas
com sucesso, através de um diálogo com semântica Feedback. Observe que o sistema pode e
deve apresentar este Feedback, mesmo quando o diálogo iniciado após a confirmação das
informações tem a semântica de Comunicação de Usuário.
Template para a especificação de tarefas do tipo Avaliação
Sugerimos que as tarefas do tipo Avaliação sejam especificadas de acordo com o
seguinte template:
77
seqüência{
(Apresentação de Informação Referente ao Domínio)*(Fornecimento de Informação Referente ao Domínio)+Confirmação de Operação((Comunicação de UsuárioFeedback)*|Feedback
)}
Explicação
Para realizar uma tarefa com semântica Avaliação o usuário pode ou não ter de
consultar informações sobre o domínio necessárias para que ele tome a decisão referente a
tarefa de avaliação, o que deve ser realizado através de um ou mais diálogos do tipo
Apresentação de Informação Referente ao Domínio. Ao realizar a avaliação ele precisa
fornecer informações sobre sua decisão (qual a decisão, justificativas, etc) o que é feito
através de um ou mais diálogos com semântica Fornecimento de Informação Referente ao
Domínio. Após terminar de fornecer estas informações, o usuário deve ter a chance de revisá-
las a fim de confirmar se estão corretas antes de prosseguir com a tarefa. Isto deve ser feito
através de um diálogo com semântica Confirmação de Operação. Após confirmar as
informações, o usuário deve comunicar sua decisão aos interessados, caso haja. Para isto,
devem ser iniciados um ou mais diálogos com semântica Comunicação de Usuário. Após a
solicitação de envio da comunicação feita pelo usuário em cada um destes diálogos, o sistema
deve informar se a comunicação foi ou não enviada com sucesso, o que é feito através de um
diálogo com semântica Feedback. Quando não há outras pessoas interessadas na decisão do
usuário, após a confirmação das informações fornecidas, o sistema deve apenas informar se
elas foram ou não armazenadas com sucesso, através de um diálogo com semântica
Feedback. Observe que o sistema pode e deve apresentar este feedback, mesmo quando o
diálogo iniciado após a confirmação das informações tem a semântica de Comunicação de
Usuário.
Template para a especificação de tarefas do tipo Encerramento
Sugerimos que as tarefas do tipo Encerramento sejam especificadas de acordo com o
seguinte template:
78
seqüência{
(Apresentação de Informação Referente ao Domínio)*(Fornecimento de Informação Referente ao Domínio)+(
(Comunicação de UsuárioFeedback)*|Feedback
)}
Explicação
Para realizar uma tarefa com semântica Encerramento de processo, o usuário deve,
inicialmente, informar ao sistema qual o processo que deseja encerrar. Isto pode ser feito de
duas maneiras: ou o sistema apresenta ao usuário uma lista com todos os processos que ele
pode encerrar, solicitando que ele escolha um, através de um diálogo com semântica Seleção;
ou o usuário informa ao sistema parâmetros para a realização da busca pelo objeto/processo
sobre o qual deseja atuar, através de um diálogo com semântica de Solicitação de
Informação Referente ao Domínio. Neste caso, há diversas possibilidades de interação. Se
não for encontrado nenhum processo o sistema deve informar isto ao usuário através de um
diálogo com semântica Feedback. Se for encontrado mais de um processo, o sistema deve
iniciar um diálogo com semântica Seleção para que o usuário escolha qual destes processos
deseja encerrar. Após a seleção do processo a ser encerrado, o usuário pode ou não precisar
analisar informações para elaborar suas observações referentes ao encerramento do processo.
Quando necessárias, estas informações devem ser apresentadas através de um ou mais
diálogos do tipo Apresentação de Informação Referente ao Domínio. Ao realizar o
encerramento ele precisa informar suas observações, o que é feito através de um ou mais
diálogos com semântica Fornecimento de Informação ao Domínio. Após terminar de
fornecer estas informações, o usuário deve ter a chance de revisá-las a fim de confirmar se
estão corretas antes de prosseguir com a tarefa. Isto é feito através de um diálogo com
semântica Confirmação de Operação. Após confirmar as informações, o usuário deve
comunicar o encerramento aos interessados, caso haja. Para isto, devem ser iniciados um ou
mais diálogos com semântica Comunicação de Usuário. Após a solicitação de envio da
comunicação feita pelo usuário em cada um destes diálogos o sistema deve informar se a
comunicação foi ou não enviada com sucesso, o que é feito através de um diálogo com
semântica Feedback. Quando não há outras pessoas interessadas no encerramento do
processo, após a confirmação das informações fornecidas, o sistema deve apenas informar se
79
elas foram ou não armazenadas com sucesso, através de um diálogo com semântica
Feedback. Observe que o sistema pode e deve apresentar este feedback, mesmo quando o
diálogo iniciado após a confirmação das informações tem a semântica de Comunicação de
Usuário.
4.4.2 Templates Sugeridos para Representar Diálogos
Nesta seção apresentaremos os templates sugeridos para a especificação dos tipos
semânticos de diálogos identificados através de estruturas de tipos semânticos de enunciados
de usuário e de sistema. Para cada template, forneceremos uma explicação que descreve as
motivações para nossas sugestões.
Template para a especificação de diálogos do tipo Fornecimento de InformaçãoReferente ao Domínio
Sugerimos que os diálogos do tipo Fornecimento de Informação Referente ao Domínio
sejam especificados de acordo com o seguinte template:
Combinação{
Seqüência{([Aposto] Informação Contextual)+(Seqüência | Agrupamento){
(Seqüência {
Solicitação de Informação » [Solicitação de Ajuda][Ajuda Preventiva » [Solicitação de Ajuda]]Fornecimento de Informação Referente ao Domínio
})+}Confirmação Parcial
}Seleção{Confirmação LocalInterrupção do Diálogo [& Retomada do Diálogo (outro)]Interrupção da Tarefa[Solicitação de Revisão](Cancelamento do Diálogo | Solicitação de Cancelamento da Tarefa)[Reinicialização do Diálogo]
}}
80
Explicação
A combinação entre a seqüência e a seleção representa que a qualquer momento do
subdiálogo representado pelos enunciados articulados em seqüência, o usuário pode
interrompê-lo ou finalizá-lo ao emitir um dos enunciados alternativos articulados pela seleção.
Desta forma, para facilitar a explicação deste template, a dividiremos em duas partes:
explicaremos primeiramente o subdiálogo articulado em seqüência e posteriormente o
subdiálogo articulado em seleção.
O subdiálogo articulado em seqüência deve ser iniciado com um ou mais enunciados
de sistema com semântica de Informação Contextual, para que o usuário se conscientize do
tópico que está sendo abordado. Para alguns destes enunciados, podem ser especificados
enunciados para explicar seu significado, com semântica de Aposto. Após a apresentação de
informações contextuais inicia-se o subdiálogo onde o sistema solicita e o usuário fornece
informações referentes ao domínio. Estes enunciados de sistema têm a semântica de
Solicitação de Informação Referente ao Domínio e os de usuário têm a semântica de
Fornecimento de Informação Referente ao Domínio. Quando não for trivial a compreensão
de que informação deve ser fornecida, estes enunciados de sistema devem ter o potencial de
inspirar o usuário a solicitar ajuda sobre este fornecimento, através de enunciados com
semântica Solicitação de Ajuda. Eventualmente, o designer pode especificar que o sistema
emita enunciados com semântica de Ajuda Preventiva, numa tentativa de evitar erros no
fornecimento da informação. Estes enunciados também devem ter o potencial de inspirar o
usuário a emitir enunciados com semântica Solicitação de Ajuda. Cada subdiálogo composto
por enunciados de sistema e de usuário referentes a uma mesma informação deve ser
articulado na seguinte seqüência: enunciado de sistema com semântica de solicitação de
informação, enunciado de sistema com semântica de ajuda preventiva (caso haja) e enunciado
de usuário. Antes de apresentar ajuda preventiva relativa a uma informação que deve ser
fornecida, o sistema deve indicar que informação é esta. A eventual ajuda é quase um
detalhamento da identificação da informação e deve sucedê-la imediatamente. Depois de
analisar tudo o que o designer quer comunicar sobre a informação solicitada o usuário pode
emitir seu enunciado para o fornecimento da mesma.
Embora a ordem de ocorrência dos enunciados de cada subdiálogo referente ao
fornecimento de uma determinada informação seja seqüencial, a ordem de ocorrência dos
81
subdiálogos não é necessariamente seqüencial. Ela pode ser aleatória, deixada a cargo da
escolha do usuário. Desta forma, o template indica que estes subdiálogos podem ser
articulados tanto em seqüência como em agrupamento. Após a ocorrência de todos estes
subdiálogos, o usuário pode prosseguir com a tarefa, emitindo um enunciado com semântica
Confirmação Parcial.
Explicaremos agora a segunda parte do template: a articulação de enunciados em
seleção. Alguns enunciados de usuário podem ser emitidos a qualquer momento, e podem
controlar a ocorrência do diálogo corrente e até de outros diálogos. Em diálogos com
semântica para o Fornecimento de Informação Referente ao Domínio, o usuário deve ter a
opção de, a qualquer momento, solicitar o armazenamento das informações já fornecidas no
diálogo (Confirmação Local); re-iniciar o diálogo (Reinicialização do Diálogo); interromper
o diálogo, através de enunciados com semânticas Interrupção do Diálogo, devida ou não a
retomada de outro diálogo, Interrupção da Tarefa ou Solicitação de Revisão, quando é
possível revisar informações fornecidas no diálogo anterior. O usuário deve poder ainda
cancelar o diálogo a qualquer momento, através de enunciados com semântica Cancelamento
do Diálogo ou Solicitação de Cancelamento da Tarefa.
Template para a especificação de diálogos do tipo Seleção
Sugerimos que os diálogos do tipo Seleção sejam especificados de acordo com o
seguinte template:
Combinação {Seqüência{
([Aposto] Informação Contextual)+(Seleção{([Ajuda » [Solicitação de Ajuda]]
Acionamento de Função)+})
|Seleção)}Seleção{
Confirmação LocalInterrupção do Diálogo [& Retomada do Diálogo (outro)]Interrupção da Tarefa[Solicitação de Revisão](Cancelamento do Diálogo|Solicitação de Cancelamento da Tarefa)[Reinicialização do Diálogo]
}}
82
Explicação
A combinação entre a seqüência e a seleção representa que a qualquer momento do
subdiálogo representado pelos enunciados articulados em seqüência, o usuário pode
interrompê-lo ou finalizá-lo ao emitir um dos enunciados alternativos articulados pela seleção,
assim como para o template do diálogo Fornecimento de Informação Referente ao
Domínio. A explicação subdiálogo articulado em seleção é a mesma descrita na explicação
deste template. Desta forma, explicaremos apenas o subdiálogo articulado em seqüência. Os
enunciados de sistema com semântica Aposto e Informação Contextual devem ocorrer neste
subdiálogo nas mesmas circunstâncias e pelos mesmos motivos apresentados na explicação do
template do diálogo Fornecimento de Informação Referente ao Domínio. Pode haver dois
tipos de seleção: seleção de função ou seleção de objeto. Para a seleção de função o usuário
deve emitir um dentre um conjunto de enunciados alternativos com semântica Acionamento
de Função. Eventuais enunciados com semântica Ajuda podem ser emitidos pelo sistema
para auxiliar o usuário a decidir que função deve acionar. Ocasionalmente estes enunciados
podem ter o potencial de inspirar o usuário a emitir um enunciado com semântica Solicitação
de Ajuda com o objetivo de obter mais informações de auxílio. Para a seleção de objeto o
usuário deve emitir um enunciado com semântica Seleção.
Template para a especificação de diálogos do tipo Controle de Função
Sugerimos que os diálogos do tipo Controle de Função sejam especificados de acordo
com o seguinte template:
Seqüência{
(Feedback)+Seleção{(Interrupção de Função | Retomada de Função)Cancelamento de Função
}}
Explicação
Os diálogos com semântica Controle de Função têm o propósito de informar ao
usuário a respeito do progresso da execução de uma função e permitir que ele controle esta
execução. Para informar sobre o progresso da execução da função estes diálogos devem
conter um ou mais enunciados de sistema com semântica Feedback. Para que o usuário possa
83
controlar a execução da função, deve ser permitido que ele emita enunciados com semântica
de Interrupção de Função quando ela estiver sendo executada, de Retomada de Função
quando ela houver sido interrompida ou Cancelamento de Função em qualquer destas
situações.
Template para a especificação de diálogos do tipo Customização
O template para diálogos com semântica Customização é quase idêntico ao template
para diálogos com semântica Fornecimento de Informação Referente ao Domínio. A única
diferença é que os enunciados com semântica Fornecimento de Informação Referente ao
Domínio são substituídos por enunciados com semântica Customização, que deve ser a
semântica das informações fornecidas pelo usuário em diálogos deste tipo.
Template para a especificação de diálogos do tipo Solicitação de Informação
O template para diálogos com semântica Solicitação de Informação é idêntico ao
template para diálogos com semântica Fornecimento de Informação Referente ao Domínio,
também consistindo, basicamente em seqüências de enunciados de sistema e usuários para a
solicitação e o fornecimento de informações referentes ao domínio. A diferença sutil, que não
pode ser representada nos templates, é que enquanto em diálogos com semântica
Fornecimento de Informação Referente ao Domínio as informações fornecidas pelo
usuário são utilizadas para a criação ou edição de atributos de objetos do domínio, em
diálogos com semântica Solicitação de Informação estas informações são utilizadas para a
busca por informações referentes a objetos do domínio ou de ajuda.
Template para a especificação de diálogos do tipo Comunicação de Usuário Síncrona
Sugerimos que os diálogos do tipo Comunicação de Usuário Síncrona sejam
especificados de acordo com o seguinte template:
84
Combinação{
Seqüência{([Aposto] Informação Contextual)+[Ajuda Preventiva] » [Solicitação de Ajuda](Combinação{
Comunicação Síncrona de UsuárioComunicação Síncrona de Usuário Remoto
}|([Comunicação Síncrona de Usuário][Comunicação Síncrona de Usuário Remoto])
)+}Seleção{[Reinicialização do Diálogo]Interrupção do Diálogo [& Retomada do Diálogo (outro)]Cancelamento do Diálogo
}}
Explicação
A combinação entre a seqüência e a seleção representa que a qualquer momento do
subdiálogo representado pelos enunciados articulados em seqüência, o usuário pode
interrompê-lo ou finalizá-lo ao emitir um dos enunciados alternativos articulados pela seleção,
assim como para o template do diálogo Fornecimento de Informação Referente ao
Domínio. A explicação do subdiálogo articulado em seleção é a mesma descrita na explicação
deste template. Desta forma, explicaremos apenas o subdiálogo articulado em seqüência. Os
enunciados de sistema com semântica Aposto e Informação Contextual devem ocorrer neste
subdiálogo nas mesmas circunstâncias e pelos mesmos motivos apresentados na explicação do
template do diálogo Fornecimento de Informação Referente ao Domínio. O enunciado com
semântica Ajuda Preventiva deve informar ao usuário como realizar a comunicação síncrona
através do sistema e eventualmente pode ter o potencial de inspirar o usuário a emitir um
enunciado com semântica Solicitação de Ajuda com o objetivo de obter mais informações
sobre a utilização da interface para comunicação síncrona.
Após estes enunciados inicia-se um subdiálogo formado por enunciados de usuário
com semântica Comunicação Síncrona de Usuário e de sistema com semântica
Comunicação Síncrona de Usuário Remoto. Estes subdiálogo é o diálogo travado entre o
usuário do sistema e um usuário remoto que tem o sistema como porta-voz. Os enunciados
que o compõem podem ocorrer em qualquer ordem, inclusive em paralelo. Os enunciados de
85
usuário e de usuário remoto não são necessariamente emitidos de forma alternada, podendo
ser emitido mais de um enunciado de um mesmo usuário, antes que o outro se pronuncie.
Template para a especificação de diálogos do tipo Comunicação de Usuário Assíncrona
Sugerimos que os diálogos do tipo Comunicação de Usuário Assíncrona sejam
especificados de acordo com o seguinte template:
Combinação{
Seqüência{([Aposto] Informação Contextual)+(Seqüência | Agrupamento){
(Seqüência {
((Solicitação de Informação » [Solicitação de Ajuda][Ajuda Preventiva » [Solicitação de Ajuda]]Fornecimento de Informação Referente ao Domínio)
)|Apresentação de Informação Referente ao Domínio
)+
(Solicitação de Informação » [Solicitação de Ajuda][Ajuda Preventiva » [Solicitação de Ajuda]]Comunicação de Usuário Assíncrona
)|Apresentação de Informação Referente ao Domínio)
})+}Confirmação Parcial
}Seleção{Confirmação LocalInterrupção do Diálogo [& Retomada do Diálogo (outro)]Interrupção da Tarefa[Solicitação de Revisão](Cancelamento do Diálogo | Solicitação de Cancelamento da Tarefa)[Reinicialização do Diálogo]
}}
Explicação
O template para diálogos com semântica Comunicação de Usuário Assíncrona é
bastante similar ao template para diálogos com semântica Fornecimento de Informação
Referente ao Domínio. As diferenças estão ilustradas em negrito. As informações às quais se
86
referem cada seqüência de enunciados de sistema e usuário são relativas aos conceitos
associados à comunicação: remetente, destinatário, assunto. Eventualmente, uma ou mais
destas informações são apresentadas pelo sistema ao invés de serem fornecidas pelo usuário,
através de enunciados com semântica Apresentação de Informação Referente ao Domínio.
Após o fornecimento destas informações o usuário deve informar o conteúdo propriamente
dito da comunicação, através de um enunciado com semântica Comunicação de Usuário
Assíncrona. Eventualmente o sistema também o faz no lugar do usuário, através de um
enunciado com semântica Apresentação de Informação Referente ao Domínio (o conteúdo
padrão de uma comunicação é uma informação referente ao domínio). Finalmente, um único
diálogo com semântica Comunicação Assíncrona pode permitir que o usuário realize mais de
uma comunicação e desta forma, o conjunto de enunciados referente a uma comunicação pode
ser repetido uma ou mais vezes.
Template para a especificação de diálogos do tipo Ajuda
Sugerimos que os diálogos do tipo Ajuda sejam especificados de acordo com o
seguinte template:
Combinação{
Seqüência{([Aposto] Informação Contextual)+Seqüência{(Ajuda Explicativa » [Solicitação de Ajuda])+
}}Seleção{[Confirmação Parcial]Interrupção do Diálogo [& Retomada do Diálogo (outro)]Cancelamento do Diálogo
}}
Explicação
A combinação entre a seqüência e a seleção representa que a qualquer momento do
subdiálogo representado pelos enunciados articulados em seqüência, o usuário pode
interrompê-lo ou finalizá-lo ao emitir um dos enunciados alternativos articulados pela seleção,
assim como para o template do diálogo Fornecimento de Informação Referente ao
Domínio. A explicação do subdiálogo articulado em seleção é a mesma descrita na explicação
87
deste template. Desta forma, explicaremos apenas o subdiálogo articulado em seqüência. Os
enunciados de sistema com semântica Aposto e Informação Contextual devem ocorrer neste
subdiálogo nas mesmas circunstâncias e pelos mesmos motivos apresentados na explicação do
template do diálogo Fornecimento de Informação Referente ao Domínio. O conteúdo
principal deste diálogo são a informações explicativas providas pelo sistema de Help de
acordo com o contexto da solicitação da ajuda. Estas informações são representadas por uma
seqüência de enunciados de sistema com semântica Ajuda Explicativa e, eventualmente,
podem ter o potencial de inspirar o usuário a solicitar mais informações de ajuda através de
enunciados com semântica Solicitação de Ajuda.
Template para a especificação de diálogos do tipo Comunicação de Sistema
Sugerimos que os diálogos do tipo Comunicação de Sistema sejam especificados de
acordo com o seguinte template:
Seqüência{
([Aposto] Informação Contextual)+(Comunicação de Sistema »[Solicitação de Ajuda | Solicitação de Detalhes])+Seleção{Interrupção do Diálogo [& Retomada do Diálogo (outro)]Cancelamento do Diálogo
}}
Explicação
O sistema inicia o diálogo emitindo enunciados com semântica Informação
Contextual e eventualmente, Aposto, nas mesmas circunstâncias e pelos mesmos motivos
apresentados na explicação do template do diálogo Fornecimento de Informação Referente
ao Domínio. O conteúdo principal deste tipo de diálogo é a comunicação do sistema. Esta
comunicação é representada por uma seqüência de enunciados de sistema com semântica
Comunicação de Sistema que, eventualmente, podem ter o potencial de inspirar o usuário a
solicitar informações de ajuda através de enunciados com semântica Solicitação de Ajuda, ou
mais detalhes sobre a comunicação, através de enunciados com semântica Solicitação de
Detalhes. Após tomar conhecimento da comunicação do sistema, o usuário deve decidir se
interrompe o diálogo, retomando ou não algum outro diálogo interrompido ou se cancela o
diálogo.
88
Template para a especificação de diálogos do tipo Feedback
O template sugerido para este diálogo é bastante similar ao template apresentado no
item anterior. A única diferença é que ao invés de emitir enunciados com semântica
Comunicação de Sistema, o sistema emite enunciados com semântica Feedback.
Template para a especificação de diálogos do tipo Apresentação de InformaçõesReferentes ao Domínio
Sugerimos que os diálogos do tipo Apresentação de Informações Referentes ao
Domínio sejam especificados de acordo com o seguinte template:
Seqüência{
([Aposto] Informação Contextual)+(Aposto » [Solicitação de Detalhes]Informação Referente ao Domínio » [Solicitação de Detalhes])+Seleção{Interrupção do Diálogo [& Retomada do Diálogo (outro)]Cancelamento do Diálogo
}}
Explicação
O template sugerido para este diálogo é bastante similar aos templates apresentados
nos dois itens anteriores. As diferenças estão em negrito e são as seguintes: o conteúdo
principal deste tipo de diálogo é apresentação de informações referentes ao domínio. Estas
informações são apresentadas através de pares de enunciados de sistema com semântica
Aposto e Informação Referente ao Domínio. Os Apostos indicam para o usuário o que
significa a informação apresentada pelos enunciados com semântica Informação Referente
ao Domínio. Eventualmente, estes enunciados do sistema podem ter o potencial de inspirar o
usuário a solicitar informações mais detalhes sobre as informações referentes ao domínio
apresentadas, através de enunciados com semântica Solicitação de Detalhes. Após tomar
conhecimento da comunicação do sistema, o usuário deve decidir se interrompe o diálogo,
retomando ou não algum outro diálogo interrompido ou se cancela o diálogo.
Template para a especificação de diálogos do tipo Confirmação de Operação
Sugerimos que os diálogos do tipo Confirmação de Operação sejam especificados de
acordo com o seguinte template:
89
Seqüência{
([Aposto] Informação Contextual)+(Aposto » [Solicitação de Detalhes]Informação Referente ao Domínio » [Solicitação de Detalhes])+Seleção{[Solicitação de Revisão]Confirmação TotalInterrupção do Diálogo [& Retomada do Diálogo (outro)]Cancelamento do Diálogo
}}
Explicação
O template sugerido para este diálogo é bastante similar aos templates apresentados no
item anterior. As diferenças estão em negrito e são as seguintes: além de poder interromper ou
cancelar o diálogo o usuário pode decidir solicitar uma revisão de informações fornecidas em
diálogos anteriores ou confirmar a operação. Uma diferença sutil que não pode ser percebida
no template é o fato de que as informações referentes ao domínio são apresentadas com o
objetivo de auxiliar o usuário a decidir se deve ou não confirmar a operação.
90
Capítulo 5
Uma Linguagem para a Especificaçãode Cenários de Interação
Neste capítulo, apresentamos a Linguagem para a Especificação de Cenários de
Interação (LECI) definida com base no modelo para a especificação de cenários de interação
descrito no capítulo 3. A LECI é uma ferramenta para auxiliar designers a especificar
instâncias de modelos de interação que estão de acordo com nosso meta-modelo. Inicialmente
procuramos adaptar a LEMD, formalismo proposto por Leite [Leite, 1998] para a
especificação do modelo de usabilidade, mas como este se mostrou bastante orientado a ação
e o paradigma adotado por nós vê a interação como conversa, acabamos por criar uma outra
linguagem. Assim como o meta-modelo e os tipos semânticos propostos neste trabalho, a
LECI também foi concebida analisando-se o modelo de interação do Qualitas. Porém,
continuaremos utilizando um Sistema Gerenciador de Biblioteca para exemplificar a sintaxe
da linguagem, sempre que possível, conforme feito nos capítulos anteriores. A seguir
descrevemos a notação utilizada para a definição da sintaxe da LECI e como cada
componente do modelo de interação identificado no capítulo 3 pode ser especificado através
desta sintaxe. Por questões didáticas, apresentamos a sintaxe para a representação dos
componentes em uma ordem diferente da utilizada para a sua descrição no capítulo 3.
5.1 Notação Utilizada para a Definição da Sintaxe da LECI
Será usada a seguinte notação para definir a sintaxe da LECI:
• A expressão <variavel> representa que variavel é uma expressão variável.
• A expressão [expressao] representa que expressao é uma expressão opcional, ou
seja, que nem sempre ocorre.
5.2 Representação de Papéis de Usuário
Um papel de usuário é definido na LECI através de uma sentença com a seguinte
sintaxe:
Role <role_name> [sub-role of <super_roles_set>][may access <tasks_set>]
onde:
91
<role_name> é o identificador do papel.
<super_roles_set> é o conjunto de identificadores de papéis dos quais o papel definido
é uma especialização. Os identificadores devem ser separados por vírgulas. A especificação
de herança entre papéis foi introduzida na linguagem para permitir o reuso de especificações.
Por exemplo, todo o bibliotecário e todo o atendente são funcionários da biblioteca, desta
forma não é necessário definir que são acessíveis para os papéis bibliotecário e atendente, as
tarefas já definidas para o papel funcionário da biblioteca.
<tasks_set> é o conjunto de identificadores de tarefas (veja a seção 5.8) definidas no
modelo de interação que podem ser realizadas por indivíduos que exerçam o papel sendo
definido. Os identificadores devem ser separados por vírgulas. Se o papel estiver sendo
definido como especialização de um ou mais papéis, só é necessário definir as tarefas
específicas do papel, ou seja, as que não foram definidas para os papéis dos quais ele é uma
especialização.
Exemplos:
Os papéis funcionário da biblioteca, bibliotecário e atendente, de um Sistema
Gerenciador de Biblioteca podem ser definidos na LECI através das seguintes sentenças:
Role funcionário da bibliotecamay access cadastrar usuário, registrar empréstimo,
registrar devolução
Role bibliotecário sub-role of funcionário da bibliotecamay access cadastrar publicações
Role atendente sub-role of funcionário da biblioteca
5.3 Representação de Conceitos da Aplicação
Um conceito da aplicação é definido na LECI através de uma sentença com a seguinte
sintaxe:
Concept <concept_name> type <concept_type>
<concept_name> é o nome do conceito definido.
<concept_type> é o tipo de conceito da aplicação: original domain indica que o
conceito é do domínio original e introduced by technology indica que ele é um conceito
surgido devido à introdução da tecnologia.
92
Exemplos:
O conceito "título de uma publicação" é um conceito do domínio original de um
Sistema Gerenciador de Biblioteca. Podemos defini-lo na LECI através da seguinte sentença:
Concept título de publicação type original domain
O conceito "registro de uma comunicação" é um conceito incorporado ao domínio
original do Qualitas devido à introdução da tecnologia. Este conceito só passou a existir
quando foi criado um sistema computacional que precisa ser informado quando ocorre uma
comunicação. Podemos definir este conceito na LECI através da seguinte sentença:
Concept registro comunicacao type introduced by technology
5.4 Representação de Enunciados de Usuário
Como vimos no capítulo anterior, existem três grandes grupos de enunciados de
usuário: enunciados para o fornecimento de informação, enunciados para a solicitação de
informação e enunciados para o controle da interação. Os dois últimos tipos de enunciados
ocasionam mudanças na ocorrência dos diálogos. Além disso, as informações fornecidas por
enunciados do primeiro tipo estão sempre relacionadas a conceitos da aplicação. Devido a
estas diferenças, existem duas sintaxes na LECI para a representação de enunciados de
usuário, uma para enunciados para o fornecimento de informação e outra para enunciados
para a solicitação de informação ou para o controle da interação. Estas sintaxes serão
apresentadas a seguir.
5.4.1 Representação de Enunciados para Fornecimento Informação
Estes tipos de enunciados são representados na LECI através de sentenças com a
seguinte sintaxe:
user [<information_form>] [<obligation_constraints>]:<concept_name> (<semantic_type1> [,<semantic_type2>, ...,
<semantic_typeN>])
onde:
<information_form> indica a forma como o usuário fornece a informação. Informs
indica que ele informa um valor livremente. Chooses indica que ele seleciona um valor de um
conjunto de opções apresentadas pelo sistema. Chooses Multiple é similar a Chooses. A
93
diferença é que o usuário pode selecionar mais de um valor do conjunto apresentado pelo
sistema. Esta forma de informação pode ser especificada com parâmetros, através da seguinte
sintaxe:
Chooses Multiple [at least <minimum_number_of_values>][at most <maximum_number_of_values>]
onde
<minimum_number_of_values> é o número mínimo de valores que devem ser
selecionados, o default é 1;
<maximum_number_of_values> é o número máximo de valores que podem ser
selecionados, o default é o número total de valores disponíveis para seleção;
O valor default para a forma de informação é Informs, ou seja quando uma
informação for fornecida de forma livre, o parâmetro não precisa ser especificado.
<concept_name> é o nome do conceito da aplicação cujo valor é enunciado pelo
usuário.
<semantic_typeI> é o identificador do i-ésimo tipo semântico instanciado pelo
enunciado de usuário. Os tipos semânticos de enunciados de usuário para a informação de
valores de conceitos da aplicação foram descritos no capítulo anterior A tabela 5.1 indica
quais são os identificadores para a representação de cada um destes tipos na LECI.
Tipo Semântico IdentificadorCustomização CustomizationComunicação Síncrona Synchronous CommunicationComunicação Assíncrona Asynchronous CommunicationFornecimento de Informação Referente ao Domínio Domain Information
Tabela 5.1: Identificadores para a representação de tipos semânticos de enunciados deusuário para informação de valores de conceitos na LECI.
<obligation_constraints> indica a restrição quanto à obrigatoriedade do enunciado do
usuário: mandatorily representa que este enunciado é obrigatório e optionally representa que
ele é opcional. Se o parâmetro não for especificado, o valor assumido é mandatorily.
94
Exemplos:
Por exemplo, em um Sistema Gerenciador de Biblioteca, no diálogo para o cadastro de
um usuário da biblioteca, o enunciado onde o responsável pelo cadastro informa o nome do
usuário pode ser representado na LECI através da seguinte sentença:
user: nome do usuário (Domain Information)
Neste mesmo diálogo, o responsável pelo cadastro deve informar o tipo do usuário, se
ele é aluno da graduação, aluno da pós-graduação, aluno professor da graduação ou professor
da pós-graduação. Para definir que o usuário (responsável pelo cadastro) escolherá um ou
mais tipos (ex.: um aluno da pós-graduação pode ser também professor da graduação) a partir
de um conjunto de tipos apresentados pelo sistema, poderíamos ter a seguinte sentença:
user chooses multiple at least 1 at most 2mandatorily: tipo de usuário (Domain Information)
5.4.2 Representação de Enunciados para Controle da Interação e Solicitaçãode Informação
Tanto os enunciados de usuário para Controle da Interação como os para a
Solicitação de Informação, controlam a ocorrência de diálogos (enunciados do último tipo
sempre iniciam um novo diálogo onde o sistema enuncia as informações solicitadas ou
informa ao usuário que não pode fazê-lo). Estes tipos de enunciados são representados na
LECI através de sentenças com a seguinte sintaxe:
<roles_set> <control> of <object>[causing <activation_behavior>](<semantic_type1> [,<semantic_type2>, ..., <semantic_typeN>])
onde:
<roles_set> é o conjunto de identificadores de papéis de usuário que podem controlar
a interação através do enunciado sendo definido. Pode ser um papel definido por uma
sentença Role ou o papel predefinido user que indica que qualquer usuário pode emitir o
enunciado. Os identificadores de papéis devem ser delimitados por vírgulas.
<control> é o identificador do controle de ocorrência de diálogo associado ao
enunciado. Os controles que podem ser exercidos sobre diálogos foram definidos no capítulo
3. A tabela 5.2 indica quais são os identificadores que representam cada um destes controles
na LECI.
95
Controle de Ocorrência de Diálogo IdentificadorInicialização Initialize(s)Finalização Terminate(s)Interrupção Interrupt(s)Retomada Resume(s)Reinicialização mantendo sugestões do sistema Reinitialize(s)Reinicialização sem sugestões do sistema Reinitialize(s) without suggestions
Tabela 5.2: Identificadores para a representação de controles de ocorrência de diálogos naLECI.
<object> é o identificador do diálogo que está sendo controlado pelo enunciado. Pode
assumir os valores this que indica que o enunciado controla a ocorrência do diálogo corrente;
next, que indica que o enunciado controla a ocorrência do próximo diálogo, determinado pela
estrutura da tarefa e pelo contexto de interação corrente ou previous, indicando que quem é
controlado é o diálogo anterior, determinado da mesma forma que o próximo diálogo.
<activation_behavior> indica o comportamento que o diálogo, em cuja interação
ocorre o enunciado, deve ter após este enunciado. Observe que só é relevante especificar este
comportamento se o enunciado controlar a ocorrência de outro diálogo, pois se este estiver
controlando o próprio diálogo onde ele ocorre, o comportamento deste já é definido pelo
controle utilizado. Estão definidos os seguintes tipos de comportamento: interruption, que
indica que o diálogo corrente deve ser temporariamente interrompido; termination que indica
que ele deve ser finalizado e persistence, que indica que ele deve permanecer ativo. Para
enunciados definidos em diálogos persistentes (qualificados com persistent, veja a seção 5.7),
o comportamento é sempre persistence e não precisa ser especificado. Para outros tipos de
diálogo, se a sentença não for especificada, o valor default depende do tipo de controle
enunciado. Quando o enunciado controla a ocorrência de um outro diálogo através dos
controles initialization, resumption, reinitialization e reinitialization without suggestions,
o comportamento default para o diálogo onde ocorre o enunciado é interruption. Para os
controles termination e interruption, o comportamento default é persistence.
<semantic_typeI> é o identificador do i-ésimo tipo semântico instanciado pelo
enunciado de usuário. Os tipos semânticos de enunciados de usuário para a solicitação de
informações e controle da interação foram descritos no capítulo anterior A tabela 5.3 indica
quais são os identificadores para a representação de cada um destes tipos na LECI.
96
Tipo Semântico IdentificadorSolicitação de Detalhes Detailed Information RequestSolicitação de Ajuda Help RequestMudança de Tópico Topic ChangeAcionamento de Função Function ActivationInterrupção de Função Function InterruptionRetomada de Função Function ResumptionCancelamento de Função Function CancellationInterrupção do Diálogo Dialog InterruptionRetomada do Diálogo Dialog ResumptionCancelamento do Diálogo Dialog CancellationRestauração do Diálogo Dialog RestorationReinicialização do Diálogo Dialog ReinitializationSolicitação de Extensão do Diálogo Dialog Extension RequestSolicitação de Revisão Revision RequestConfirmação Local Local ConfirmationConfirmação Parcial Partial ConfirmationConfirmação Total ConfirmationSolicitação de Cancelamento da Tarefa Task Cancellation Request
Tabela 5.3: Identificadores para a representação de tipos semânticos de enunciados deusuário para solicitação de informações e controle da interação na LECI.
Exemplo:
No menu que apresenta as funções disponibilizadas pelo Sistema Gerenciador de
Biblioteca, é necessário especificar que papéis têm acesso a que funções. Para definir que
somente bibliotecários podem cadastrar publicações, somente funcionários podem registrar
empréstimos e devoluções e qualquer usuário do sistema pode pesquisar por publicações,
teríamos as seguintes sentenças LECI no diálogo que representa o menu:
bibliotecário initializes cadastro de publicaçãocausing persistence (Function Activation)
funcionário initializes registro de empréstimocausing persistence (Function Activation)
funcionário initializes registro de devoluçãocausing persistence (Function Activation)
user initializes pesquisa por publicaçãocausing persistence (Function Activation)
97
5.5 Representação de Enunciados de Sistema
Um enunciado de sistema é representado na LECI através de uma sentença com a
seguinte sintaxe:
system: <utterance> (<semantic_type1> [, <semantic_type2> ..., <semantic_typeN>]) [user_alternatives <user_alternatives>] [suggestion <suggestion>]
[affords: <user_request_utterance>]
onde:
<utterance> é a mensagem emitida pelo sistema em seu enunciado.
<semantic_typeI> é o identificador do i-ésimo tipo semântico instanciado pelo
enunciado de sistema. Os tipos semânticos de enunciados de sistema foram descritos no
capítulo anterior. A tabela 5.4 indica quais são os identificadores para a representação de cada
um destes tipos na LECI.
Tipo Semântico IdentificadorSolicitação de Informação Information RequestApresentação de Informação Referente aoDomínio
Domain Information
Aposto AppositionInformação Contextual Contextual InformationAjuda Preventiva Preventive HelpAjuda Corretiva Corrective HelpAjuda Explicativa Explicative HelpFeedback FeedbackParêntese ParenthesisComunicação de Sistema System CommunicationComunicação de Usuário Remoto Síncrona Synchronous Remote User CommunicationComunicação de Usuário RemotoAssíncrona
Asynchronous Remote User Communication
Tabela 5.4: Identificadores para a representação de tipos semânticos de enunciados desistema na LECI.
<user_alternatives> só deve ser especificado quando o enunciado de sistema tem a
semântica de Solicitação de Informação (Information Request) e o enunciado que o usuário
deve emitir em resposta a esta solicitação está restrito a um conjunto fechado de enunciados
alternativos. Este conjunto pode ser determinado em tempo de design, ou determinado em
tempo de execução da aplicação. Um exemplo de conjunto determinado em tempo de design
seria o seguinte conjunto de tipos de publicação existentes em uma biblioteca: livro,
98
periódico, tese de doutorado, dissertação de mestrado e relatório técnico. Um exemplo de
conjunto determinado em tempo de execução da aplicação seria o conjunto de assuntos
abordados pelas publicações armazenadas na biblioteca. Para alguns Sistemas Gerenciadores
de Biblioteca, o designer pode não definir este conjunto em tempo de design, deixando que o
próprio bibliotecário defina os assuntos, ou ainda definir este conjunto de forma aberta,
deixando que o bibliotecário o estenda. Quando o parâmetro <user_alternatives> estiver
representando um conjunto de enunciados de usuário possíveis definido em tempo de design,
ele deve ser especificado com a seguinte sintaxe:
{<alternative1>, <alternative2>, ..., <alternativeN>},
onde <alternativeI> é a I-ésima alternativa. Quando o parâmetro estiver representando
um conjunto determinado em tempo de execução, ele deve ser especificado com um
identificador da semântica comum aos enunciados alternativos que fazem parte deste
conjunto. Em nosso exemplo, o conjunto de assuntos abordados pelas publicações da
biblioteca poderia ser representado pelo termo <assuntos>. Quando o designer define um
conjunto inicial de alternativas e permite ao usuário estender este conjunto, a sintaxe para a
representação do parâmetro <user_alternatives> é:
{<alternative1>, <alternative2>, ..., <alternativeN>}+,
onde <alternativeI> é a I-ésima alternativa predefinida pelo designer.
<suggestion> só deve ser especificado quando o enunciado de sistema tem a semântica
de Solicitação de Informação (Information Request) e o designer deseja apresentar uma
sugestão para o enunciado que o usuário deve emitir em resposta a esta solicitação. Esta
sugestão se apresenta como um default para o enunciado do usuário e representa aquilo que o
designer acredita ser provável que o usuário vá enunciar em determinada situação. Observe
que quando o designer determina um conjunto fechado de alternativas para o enunciado do
usuário, sua sugestão deve pertencer a este conjunto. Quando o usuário pode enunciar ao
mesmo tempo mais de um dos enunciados definidos no conjunto de alternativas, o parâmetro
<suggestion> deve ser especificado com a seguinte sintaxe:
{<alternative1>, <alternative2>, ..., <alternativeN>},
onde <alternativeI> é a I-ésima alternativa sugerida pelo designer.
A extensão opcional affords: <user_request_utterance> só deve ser
especificada quando o enunciado de sistema tem potencial para inspirar o usuário a emitir um
99
enunciado cujo efeito é a inicialização de um outro diálogo. <user_request_utterance> é o
enunciado de usuário para solicitação que pode ser inspirado pelo enunciado do sistema. A
sentença <user_request_utterance> tem quase a mesma sintaxe apresentada na seção 5.4.2.
As únicas restrições são: o controle de ocorrência do diálogo deve ser initialization e as
semânticas de usuário permitidas são Detailed Information Request, Help Request, Topic
Change, Function Activation.
Para exemplificar, consideremos uma interação para o cadastro de uma publicação,
onde um Sistema Gerenciador de Biblioteca solicita que o usuário informe, entre outras
coisas, o tipo, os autores, o assunto e as palavras-chave da publicação. Suponha que o
designer do sistema acredite que na maioria das vezes será cadastrado um livro, ao invés de
outros tipos de publicação e, desta forma, sugira que o usuário enuncie "livro" ao informar o
tipo da publicação. Suponha também que o designer forneça um conjunto inicial de assuntos e
permita ao usuário estender este conjunto, mas que permita que o conjunto de palavras-chave
seja totalmente definido pelo usuário. Suponha ainda que os enunciados do sistema tenham
potencial para inspirar o usuário a emitir um enunciado cujo efeito é a solicitação de
informações de ajuda que indicam como o usuário deve fornecer as informações solicitadas.
Estes enunciados poderiam ser representados na LECI através das seguintes sentenças:
system: <Tipo de Publicação> (Information Request)user_alternatives { livro, periódico, tese de doutorado,dissertação de mestrado e relatório técnico}
suggestion livro affords: user initializes Ajuda Tipo de Publicação (Help Request)
system: <Autores> (Information Request)affords: user initializes Ajuda Autores (Help Request)
system: <Assunto> (Information Request)user_alternatives {Interação Humano Computador, O.O., Redes}+affords: user initializes Ajuda Assunto (Help Request)
system: <Palavras-Chave> (Information Request)user_alternatives <Palavras-Chave>affords: user initializes Ajuda Palavras-Chave (Help Request)
5.6 Representação de Estruturas de Articulação
Como vimos no capítulo 3, as estruturas de diálogos componentes de tarefas e as
estruturas de enunciados componentes de diálogos podem ser articuladas de diversas formas.
A sintaxe para a representação de articulações de diálogos e de enunciados na LECI será
apresentada a seguir.
100
5.6.1 Representação de Articulações de Diálogos
A forma geral para a representação de uma articulação de diálogos é:
<articulation_structure>{
<articulated_elements>} <structured_information_providing_constraints>
<articulation_structure> é o identificador do tipo de articulação na LECI. A tabela 5.5
apresenta os identificadores associados a cada tipo de articulação.
Tipo de Articulação IdentificadorArticulação em seqüência sequenceArticulação em qualquer ordem, dependente da vontade dousuário
group
Articulação de opções alternativas mutuamente-exclusivas, ouseja, somente um dos enunciados/diálogos articulados ocorrerá,de acordo com a escolha do usuário
exclusive choice
Articulação de enunciados/diálogos que ocorrerão, de acordocom a vontade do usuário, ou seja ele pode escolher um ou maisdestes elementos
multiple choice
Articulação de enunciados/diálogos que ocorremsimultaneamente ou que são interdependentes
combination
Articulação de enunciados/diálogos que se repetem repetition
Tabela 5.5: Identificadores para a representação de tipos de articulação na LECI.
<articulated_elements> são os elementos de interação articulados pela estrutura.
Quando a estrutura de articulação definida é uma tarefa, estes elementos são sentenças dialog
(veja seção 5.8) ou articulações destas sentenças. Quando a estrutura definida é um diálogo,
os elementos articulados são enunciados (veja seções 5.4 e 5.5) ou articulações de enunciados.
<structured_information_providing_constraints> informa sobre a obrigatoriedade da
emissão de enunciados de usuário para informação de valor de conceito da aplicação que
ocorrem na estrutura articulada. O parâmetro pode assumir os seguintes valores:
• optionally, que indica que todos enunciados de usuário para informação de valor
de conceito da aplicação presentes na estrutura são opcionais ou
• mandatorily [<comparison_operator> <quantity>
[from {<utterance_id1>, ...,<utterance_idN>}], que indica que um
subconjunto dos enunciados de usuário para informação de valor de conceito da
101
aplicação presentes na estrutura, são obrigatórios. Este subconjunto é determinado
pelos parâmetros <comparison_operator>, <quantity> e <subset>. A não
especificação destes parâmetros indica que todos os enunciados de usuário para
informação de valor de conceito da aplicação presentes na estrutura são
obrigatórios.
<comparison_operator> é o operador de comparação da restrição quanto ao
tamanho do subconjunto de enunciados obrigatórios, o qual pode assumir os
seguintes valores:
• at least: representa que o subconjunto de enunciados obrigatórios tem tamanho
mínimo.
• exactly: representa que o subconjunto de enunciados obrigatórios tem tamanho
fixo.
• at most: representa que o subconjunto de enunciados obrigatórios tem tamanho
máximo.
<quantity> é o número operando da restrição quanto ao tamanho do subconjunto
de enunciados obrigatórios.
<utterance_idI> é o identificador do i-ésimo enunciado do subconjunto de
enunciados possivelmente obrigatórios. Se os componentes tiverem semânticas
e/ou tipos distintos (quando não articulados por repetição), o identificador é o
identificador do conceito da aplicação cujo valor é informado pelo enunciado. Se
os enunciados estiverem articulados por repetição, o identificador é o identificador
do conceito concatenado com o índice da repetição que gera o enunciado.
Exemplo:
Tarefa "Editar Informações Sobre Livro"
A seguir apresentamos trechos da definição LECI da tarefa "Editar Informações Sobre
Livro". Esta tarefa é composta por uma seqüência de diálogos (sequence).
sequence {dialog Edição de Informações Gerais de Publicaçãodialog Edição de Informações Específicas de Livro. . .
}
102
5.6.2 Representação de Articulações de Enunciados
Articulações de enunciados são representadas de forma similar a articulações de
diálogos. Entretanto, ao se definir um diálogo como uma articulação de enunciados de usuário
e de sistema, é importante explicitar-se, além do tipo da articulação, qual a estrutura de
subtópicos do diálogo. Isto pode ajudar o usuário a percorrer as possibilidades de referência e
expressão a cada pedaço da conversa. Desta forma, a LECI provê um mecanismo para a
identificação de subtópicos em uma estrutura de diálogo. A forma geral para a representação
de articulações de enunciados na LECI é:
[<articulation_structure>] subtopic [<subtopic_name>]{
<articulated_elements>} <structured_information_providing_constraints>
onde todos os parâmetros homônimos aos descritos no item 5.6.1 têm a mesma semântica
definida para seus homônimos e o parâmetro adicional <subtopic_name> é o identificador do
subtópico composto pelos enunciados articulados. Este parâmetro é opcional porque pode ser
mais importante identificar que grupos de enunciados fazem parte de um subtópico comum do
que qual é este subtópico. Observe que para articulações de enunciados, a especificação do
tipo de articulação pode ser opcional, fazendo com que a sentença seja usada apenas para
indicar que um subconjunto de enunciados faz parte do mesmo subtópico. Isto foi permitido
para facilitar a representação de um mesmo tipo de articulação para várias estruturas de
subtópico.
Exemplos:
Diálogo para a Solicitação de Impressão de um Arquivo
A seguir apresentamos trechos da definição LECI de um diálogo para a solicitação de
impressão de um arquivo. Este diálogo é composto por uma seqüência (sequence) de
enunciados de usuário e sistema, sendo um dos enunciados do usuário resultante de uma
escolha exclusiva (exclusive choice) obrigatória entre selecionar o nome do arquivo a partir
de um conjunto de nomes enunciados pelo sistema ou informar este nome livremente. Outro
enunciado possível neste diálogo é a solicitação de inicialização de um diálogo para a
configuração da impressora. Este enunciado é dependente (combination) do enunciado através
do qual o usuário informa o tipo de impressora.
103
sequence {. . .subtopic <Nome do Arquivo> {system: <Nome do Arquivo> (Information Request)user_alternatives <nomes de arquivos>
exclusive choice {user chooses: nome do arquivo (Domain Information)user informs: nome do arquivo (Domain Information)
} mandatorily}
combination subtopic <Nome da Impressora> {system: <Nome da Impressora> (Information Request)user_alternatives <nomes de impressoras>
user chooses: nome da impressora (Domain Information)user initializes configuração da impressoracausing persistence (Function Activation)
} . . .}
Diálogo para a Inclusão de Informações sobre Publicação
A seguir apresentamos trechos da definição LECI de um diálogo para a inclusão de
informações sobre uma publicação. Neste diálogo, inicialmente, o sistema solicita que o
usuário informe ao menos uma de 4 palavras-chave e que cada vez que o usuário emite um
enunciado com semântica Repetition Request, aumenta em dois o número de palavras-chave
que podem ser informadas.
sequence subtopic <palavras-chave>{system: <Palavras-Chave> (Information Request)combination {
repetition {user: palavra-chave (Domain Information)
} mandatorily at least 1user requests: reinitialization ofInclusão de Informações sobre Publicaçãocausing persistence ( Dialog Extension Request)
}}
Diálogo para a Inclusão de Informações sobre Usuário da Biblioteca
A seguir apresentamos trechos da definição LECI de um diálogo para a inclusão de
informações sobre um usuário da biblioteca. Neste diálogo, o designer permite que o usuário
do sistema, que realiza a inclusão, informe um conjunto de meios de contato com o usuário da
biblioteca, mas exige que seja informado ao menos o e-mail ou o telefone. As informações
podem ser fornecidas em qualquer ordem (group), mas os enunciados de sistema devem
ocorrer antes dos enunciados de usuário (sequence).
104
group{
system:<Meio de contato> (Information Request)sequence subtopic <e-mail>{
system: <E-mail> (Information Request)user: e-mail (Domain Information)
}sequence subtopic <telefone>{
system: <Telefone> (Information Request)user: telefone (Domain Information)
}sequence subtopic <endereço>{
system: <Endereço> (Information Request)user: endereco (Domain Information)
}} mandatorily at least 1 from {e-mail, telefone}
5.7 Representação de Diálogos
Um diálogo é representado na LECI através de uma sentença com a seguinte sintaxe:
[shared] [persistent] Dialog <dialog_name> ([<semantic_type>])
[operands <dialog_operands>]<utterance_structure>
[<user_errors_handling_sentence>][<system_failures_handling_sentence>]
O identificador opcional shared é especificado quando o diálogo pode ser reusado,
sendo incluído no corpo de outros diálogos, através da sentença include (veja a seção 5.13.1).
O identificador opcional persistent deve ser especificado quando o diálogo for
persistente, ou seja, estiver sempre ativo ao longo de toda a interação com a aplicação, como,
por exemplo, um menu de opções.
<dialog_name> é o nome que identifica o diálogo.
<semantic_type> é o identificador do tipo semântico instanciado pelo diálogo. Os
tipos semânticos de diálogos foram descritos no capítulo anterior. A tabela 5.6 indica quais
são os identificadores para a representação de cada um destes tipos na LECI.
105
Tipo Semântico IdentificadorFornecimento de Informação Referenteao Domínio
Domain Information
Seleção SelectionControle de Função Function ControlCustomização CustomizationSolicitação de Informação Referente aoDomínio
Domain Information Request
Solicitação de Ajuda Help RequestComunicação de Usuário Síncrona Synchronous User CommunicationComunicação de Usuário Assíncrona Asynchronous User CommunicationApresentação de Informação Referente aoDomínio
Domain Information Presentation
Confirmação de Operação Operation ConfirmationAjuda HelpFeedback FeedbackComunicação de Sistema System Communication
Tabela 5.6: Identificadores para a representação de tipos semânticos de diálogos na LECI.
<dialog_operands> é um parâmetro que só deve ser especificado para diálogos que
podem ser reusados como templates (qualificados como shared). Este parâmetro representa
uma lista de operandos (separados por vírgulas) que servem para instanciar o template na
situação em que ele é reusado (veja a seção 5.13.1).
<utterance_structure> é a estrutura de enunciados definida para o diálogo. Ela é
composta por articulações (seção 5.6) de sentenças que representam enunciados de usuário
(seção 5.4) e de sistema (seção 5.5). Estas articulações podem ser recursivas, ou seja, pode
haver articulações de articulações.
<user_errors_handling_sentence> é a sentença que define como os erros cometidos
pelo usuário ao longo do diálogo serão tratados. Esta sentença será apresentada na seção 5.11.
Observe que o designer pode desejar que os erros cometidos pelo usuário em todos os
diálogos de uma mesma tarefa sejam tratados juntos, após o último diálogo que a compõe.
Neste caso, o tratamento deve ser definido para a tarefa e não para cada diálogo que a
compõe. Quando o designer define uma estratégia de tratamento de erros de usuário para um
diálogo e ele é invocado por uma tarefa que também tem uma estratégia de tratamento de
erros de usuário definida, prevalece a estratégia definida pela tarefa e os erros cometidos no
diálogo são tratados junto com os erros cometidos nos outros diálogos da tarefa. Dito isto,
parece não fazer sentido que se especifique uma estratégia para tratamento de erros para um
106
diálogo invocado por uma tarefa que também tem estratégia definida. Mas observe que um
mesmo diálogo pode ser componente de tarefas distintas e para alguma delas pode não ter
sido definida nenhuma estratégia de tratamento de erros de usuário.
<system_failures_handling_sentence> é a sentença que define como as falhas de
sistema ocorridas ao longo do diálogo serão tratadas. Esta sentença será apresentada na seção
5.12. Observe que, para uma determinada tarefa, o designer pode desejar especificar o mesmo
tipo de tratamento de falhas de sistema para mais de um dos diálogos que a compõem. Neste
caso, assim como o tratamento de erros de usuário, o tratamento de falhas de sistema também
pode ser definido para a tarefa, só precisando ser redefinido para diálogos componentes cujos
tratamentos devam ser diferentes do definido para a tarefa.
Exemplo:
A sentença apresentada a seguir representa na LECI o diálogo para a solicitação de
impressão de um arquivo mencionado na seção anterior.
Dialog Solicitação de Impressão de Arquivo (Task Information)sequence{
system: <Para imprimir você deve fornecer os dados, e, em seguida,selecionar o controle da função que você deseja acionar> (Help)subtopic <Nome do Arquivo> {system: <Nome do Arquivo> (Information Request)user_alternatives <nomes de arquivos>
exclusive choice {user chooses: nome do arquivo (Domain Information)user informs: nome do arquivo (Domain Information)
} mandatorily}combination subtopic <Nome da Impressora> {
system: <Nome da Impressora> (Information Request)user_alternatives <nomes de impressoras>
user chooses: nome da impressora (Domain Information)user requests: initialization of configuração da impressoracausing persistence (Function Activation)
}subtopic <Número de Cópias> {
system: <Número de Cópias> (Information Request)suggestion <1>
user: numero_copias (Domain Information)}user requests: initialization of Controle de Impressãocausing persistence (Function Activation)
}
107
5.8 Representação de Tarefas
Uma tarefa é representada na LECI através de uma sentença com a seguinte sintaxe:
[shared] Task <task_name> ([<semantic_type>])[operands <task_operands>]<dialog_structure>[<user_errors_handling_sentence>][<system_failures_handling_sentence>]
O identificador opcional <shared> é especificado quando a tarefa pode ser reusada,
sendo incluída no corpo de outras tarefas, através da sentença include (veja a seção 5.13.2).
<task_name> é o nome que identifica a tarefa.
<semantic_type> é o identificador do tipo semântico instanciado pela tarefa. Os tipos
semânticos de tarefas foram descritos no capítulo anterior. A tabela 5.7 indica quais são os
identificadores para a representação de cada um destes tipos na LECI.
Tipo Semântico IdentificadorCriação CreationEdição EditingConsulta por Informações Information RetrievalComunicação CommunicationDestruição DestructionPlanejamento PlanningRegistro de Atividade Activity RegistrationAvaliação EvaluationDesativação DeactivationEncerramento Termination
Tabela 5.7: Identificadores para a representação de tipos semânticos de tarefas na LECI.
<task_operands> é um parâmetro que só deve ser especificado para tarefas que podem
ser reusadas como templates (qualificadas como shared). Este parâmetro representa uma lista
de operandos (separados por vírgulas) que servem para instanciar o template na situação em
que ele é reusado (veja a seção 5.13.2).
<dialog_structure> é a estrutura de diálogos que compõe a tarefa. Ela é composta por
articulações (seção 5.6) de sentenças dialog que representam a inicialização dos diálogos
componentes da tarefa. Estas articulações podem ser recursivas, ou seja, pode haver
articulações de articulações. As sentenças dialog têm a seguinte sintaxe:
108
dialog <dialog_name> ([<semantic_type>]), onde
<dialog_name> é o nome do diálogo a ser inicializado e <semantic_type> é seu tipo
semântico.
<user_errors_handling_sentence> é a sentença que define como os erros cometidos
pelo usuário ao longo dos diálogos componentes da tarefa serão tratados. Esta sentença será
apresentada na seção 5.11. Conforme mencionado na seção anterior, a estratégia de
tratamento de erros de usuário só deve ser definida para tarefas para as quais o designer
deseje que os erros cometidos pelo usuário em todos os diálogos da tarefa sejam tratados
juntos, após o último diálogo que a compõe.
<system_failures_handling_sentence> é a sentença que define como as falhas de
sistema ocorridas ao longo dos diálogos componentes da tarefa serão tratadas. Esta sentença
será apresentada na seção 5.12. Conforme mencionado na seção anterior, este é o tipo de
tratamento que o designer especifica para a maioria dos diálogos da tarefa, podendo ser
redefinido de forma diferente para um ou mais destes diálogos.
Exemplo:
Para exemplificar a definição de uma tarefa na LECI, apresentamos a seguir uma
sentença que define a tarefa "Editar Informações sobre Livro". Esta tarefa é realizada através
de uma seqüência de diálogos, conforme ilustra a sentença.
Task Editar Informações Sobre Livro (Editing)sequence{
dialog Edição de Informações Gerais de Publicação (Domain Information)
dialog Edição de Informações Específicas de Livro(Domain Information)
dialog Confirmação de Informações Fornecidas(Operation Confirmation)
dialog Feedback de Salvamento de Informações (Feedback)}
5.9 Representação de Interrupções
Para representar uma tarefa que possui pontos de interrupção é necessário dividi-la em
passos de forma que ao menos os passos que podem ser interrompidos e retomados estejam
explícitos para que se possa qualificá-los como tal. Os passos de uma tarefa são representados
na LECI por sentenças que definem inicializações de diálogos (dialog, veja a seção 5.8).
109
Desta forma, introduzimos para esta sentença, a seguinte extensão para a especificação de
interrupções:
[identified by <step_id>] [allows interruption[after resumption, allows revisions at <revisable_steps>]]
<step_id> é o identificador do passo da tarefa representado pelo diálogo cuja
inicialização está sendo representada. A sentença identified by <step_id> é opcional, pois,
por default, o identificador de um passo de tarefa é o próprio identificador do diálogo que é
inicializado no passo. A sentença foi introduzida para tratar casos onde há inicialização de um
mesmo diálogo, em diferentes passos de uma mesma tarefa e desta forma é necessário definir
explicitamente identificadores distintos para cada passo. Note que passos representados dentro
de contextos de interação exclusivos podem ter o mesmo identificador, já que nunca serão
executados em uma mesma situação.
A sentença allows interruption deve ser especificada quando o passo representado
pela inicialização do diálogo pode ser interrompido. A sentença after resumption, allows
revisions at <revisable_steps>, quando especificada, indica quais passos anteriores ao ponto
de interrupção poderão ser revisados a posteriori, quando a tarefa for retomada no ponto de
interrupção. O parâmetro <revisable_steps> é o conjunto de identificadores de passos
anteriores ao passo onde pode ocorrer a interrupção, separados por vírgulas. Observe que
qualquer dos passos articulados por seleção (exclusive choice) ou seleção múltipla (multiple
choice) podem não vir a ser executados. Dentre os passos articulados por seleção, somente
um é executado de cada vez e desta forma, qualquer deles pode não vir a ser executado. Uma
articulação do tipo seleção múltipla permite que o usuário execute até todos os passos
articulados, mas ele também pode decidir deixar de executar um ou mais e desta forma,
qualquer dos passos articulados por seleção múltipla também correm o risco de não ser
executados. Se um passo que pode não vir a ser executado for especificado na lista de passos
revisáveis, assumimos que isto significa que ele é revisável somente se tiver sido executado.
Inicialmente, pensamos em associar um identificador de passo às sentenças que representam
as estruturas de seleção e seleção múltipla. Este identificador representaria os passos
escolhidos dinamicamente pelo usuário. Entretanto, desta forma, só poderíamos definir casos
extremos: ou que todos os passos articulados são revisáveis ou que nenhum o é.
110
Exemplo:
Para exemplificar a especificação de uma tarefa que pode ser interrompida em
determinados pontos, considere a tarefa "Editar Informações Sobre Livro" apresentada no
exemplo anterior. Ela será especificada na LECI, a seguir, considerando-se os seus pontos de
interrupção.
Task Editar Informações Sobre Livro (Editing)sequence{
dialog Edição de Informações Gerais de Publicaçãoallows interruption (Domain Information)
dialog Edição de Informações Específicas de Livroallows interruption after resumption, allows revisions atEdição de Informações Gerais de Publicação
(Domain Information)dialog Confirmação de Informações Fornecidas allows interruption
after resumption, allows revisions atEdição de Informações Gerais de Publicação,Edição de Informações Específicas de Livro
(Operation Confirmation)dialog Feedback de Salvamento de Informações (Feedback)
}
5.10 Representação de Contextos de Interação
Um contexto de interação pode ser definido na LECI através de uma sentença com a
seguinte sintaxe:
Interaction-Context(<context_name>,{[<operands>]},<<condition>>)
<context_name> é o nome que identifica o contexto de interação.
<operands> é uma lista com os conceitos da aplicação que funcionam como
operandos para as condições que verificam se uma determinada situação está no contexto de
interação que está sendo definido.
<condition> é uma expressão lógica que indica as condições necessárias para a que
uma situação esteja no contexto de interação que está sendo definido. Estas condições são
especificadas com base nos conceitos da aplicação especificados na lista de operandos.
Relações entre contextos também podem ser usadas para a montagem destas condições. A
sintaxe para a especificação destas relações será descrita na seção 5.10.3.
111
Exemplos:
Considere uma interação para a apresentação dos resultados de uma pesquisa por
publicações. Podemos dizer que um curso típico ocorre quando a pesquisa encontra uma lista
de publicações e um curso de exceção ocorre quando não é encontrada nenhuma publicação.
Podemos definir o contexto de interação que representa o curso típico na LECI, através da
seguinte sentença:
Interaction-Context(publicacao_encontrada,{número de publicações encontradas},<o número de publicações encontradas é maior ou igual a 1>,{Apresentação dos Resultados de Pesquisa por Publicações})
Para definir na LECI o contexto de interação no qual nenhuma publicação é
encontrada, podemos utilizar a seguinte sentença:
Interaction-Context(publicacoes_nao_encontradas,{número de publicações encontradas},<o número de publicações encontradas é igual a 0>)
5.10.1 Representação de Estruturas de Interação Dependentes de Contexto
O objetivo da representação de contextos de interação na LECI é possibilitar
definições de estruturas de interação (articulações de diálogos e enunciados) que ocorrem
somente em contextos de interação específicos. Para representar estas definições na LECI,
antes da sentença que define a estrutura de interação dependente de contexto, deve ser
declarada a seguinte sentença:
when context is [one of] <contexts_set>, onde
<contexts_set> é o conjunto de identificadores dos contextos de interação onde a
estrutura de interação ocorre, separados por vírgulas. Quando há apenas um contexto de
interação no conjunto, não é necessário especificar o termo one of e quando há mais de um, o
termo dever ser obrigatoriamente especificado. Um contexto de interação pode ser
identificado das seguintes formas:
• pelo identificador de um contexto de interação que tenha sido previamente
definido, através de uma sentença Interaction-Context. Caso tenham sido
definidos operandos para o contexto de interação, os valores a ser associados a
estes devem ser representados junto ao identificador, com a seguinte sintaxe:
<context_identifier> (<operand_value1>, ..., <operand_valueN>),
112
onde <context_identifier> é o identificador do contexto de interação e
<operand_valueI> é o valor que deve ser associado ao I-ésimo operando definido
para o contexto de interação.
Exemplo:
No diálogo onde o sistema apresenta ao usuário os resultados de uma pesquisa por
publicações, ele deve enunciar uma mensagem informando que nenhuma
publicação foi encontrada, somente no contexto de interação em que isto ocorre.
Este enunciado é então dependente deste contexto. Aproveitando a definição do
contexto publicacoes_nao_encontradas na LECI, apresentada na seção anterior,
podemos representar esta dependência através da seguinte sentença:
when context ispublicacoes_nao_encontradas(num. de publicações encontradas){
system: <Não foi encontrada nenhuma publicação> (Feedback)}
• por um contexto de interação anônimo criado apenas para ser associado àquela
estrutura de interação, representado pelo construtor de contextos anônimos
Interaction-Context( {<operands>}, <<condition>> ), onde,
<operands> é uma lista de conceitos da aplicação (separados por vírgulas) que
são operandos utilizados para montar <condition>, que é uma expressão lógica
que indica as condições necessárias para a que uma situação esteja no contexto
anônimo definido. Estas condições são especificadas com base nos conceitos da
aplicação especificados na lista de operandos. Relações entre contextos também
podem ser usadas para a montagem destas condições. A sintaxe para a
especificação destas relações será descrita na seção 5.10.3.
Exemplo:
Caso o contexto de interação publicacoes_nao_encontradas, definido na seção
anterior, seja apenas utilizado em um único diálogo, ele pode ser definido no
próprio diálogo, através da seguinte sentença LECI:
Interaction-Context( {número de publicações encontradas},<o número de publicações encontradas é igual a 0>)
113
5.10.2 Representação da Exclusividade entre Contextos de Interação
Os contextos de interação podem ser independentes ou mutuamente exclusivos. Por
default os contextos de interação são independentes, ou seja, se temos a especificação
especificação de um diálogo na forma
Dialog <dialog_name>Sequence {
when context is <context1><utterance_structure1>
when context is <context2><utterance_structure2>
...when context is <contextN>
<utterance_structureN>}
onde:
<dialog_name> é o nome do diálogo; <contextI> é o identificador do I-ésimo
contexto de interação e <utterance_structureI> é a estrutura de enunciados que devem ocorrer
quando o sistema estiver no I-ésimo contexto de interação, nada impede que quando o diálogo
seja travado, o sistema possa estar ao mesmo tempo em um ou mais dos contextos de
interação context1, context2, ..., contextN. Para representar exclusividade entre contextos de
interação, a LECI disponibiliza a estrutura Exclusive-Contexts que possui a seguinte sintaxe:
Exclusive-Contexts {when context is <context1>
<utterance_structure1>when context is <context2>
<utterance_structure2>...when context is <contextN>
<utterance_structureN>}
onde,
<dialog_name> é o nome da mensagem de comando;
<contextI> é o identificador do I-ésimo contexto de interação e
<utterance_structureI> é a estrutura de enunciados que devem ocorrer somente
quando o sistema estiver no I-ésimo contexto de interação.
114
Exemplo:
O diálogo onde o sistema apresenta informações sobre uma publicação pode ocorrer
em pelo menos cinco contextos de interação mutuamente exclusivos: a publicação é um livro,
a publicação é uma dissertação de mestrado, a publicação é um periódico, a publicação é um
relatório técnico ou a publicação é uma tese de doutorado. Existem informações que
caracterizam qualquer tipo de publicação e que devem ser apresentadas independentemente do
contexto de interação, como por exemplo, o título, os autores, etc. Já outras informações são
específicas de cada tipo de publicação e só devem ser apresentadas em determinados
contextos. A seguir apresentamos trechos da especificação LECI de um diálogo para a
apresentação de informações sobre uma publicação, onde a exclusividade entre contextos é
utilizada para a definir enunciados de sistema que devem ser emitidos de acordo com o tipo
de publicação que está sendo apresentada.
Dialog Apresentação de Informações sobre Publicação(Domain Information)Sequence {
subtopic <título> {system: <Título> (Apposition)system: Título da Publicação (Domain Information Presentation)
}subtopic <Autores> {system: <Autores> (Apposition)system: Autores da Publicação (Domain Information Presentation)
}. . .subtopic <Tipo de Publicação> {system: <Tipo de Publicação> (Apposition)system: Tipo da Publicação (Domain Information Presentation)
}Exclusive-Contexts{when context is publicacao_e_livro {Sequence{subtopic <ISBN> {system: <ISBN> (Apposition)system: ISBN do livro (Domain Information Presentation)
}subtopic <Editora> {system: <Editora> (Apposition)system: editora do livro (Domain Information Presentation)
}subtopic <Edição> {system: <Edição> (Apposition)system: edição do livro (Domain Information Presentation)
}
115
subtopic <Volume> {system: <Volume> (Apposition)system: volume do livro (Domain Information Presentation)
}}
}. . .when context is one-of publicacao_e_dissertacao_mestrado,
publicacao_e_tese_doutorado{Sequence{subtopic <Volume> {system: <Universidade> (Apposition)system: universidade (Domain Information)
}subtopic <Volume> {system: <Curso> (Apposition)system: curso (Domain Information)
}}
}}. . .
}
Convém mencionar que inicialmente pensou-se em utilizar a estrutura if then else para
a representação de contextos de interação mutuamente exclusivos. Entretanto, esta sintaxe foi
substituída por uma estrutura menos procedimental, onde grupos de condições básicas são
representados em um nível mais alto de abstração (contextos de interação). Adotamos esta
sintaxe pois acreditamos que com ela:
1. As especificações serão compreendidas mais facilmente.
2. A linguagem será mais acessível para usuários finais, permitindo que, em trabalhos
futuros, a LECI possa ser usada para end user designing ou end user programming [Myers,
1992].
5.10.3 Representação de Relações entre contextos
As relações entre contextos identificadas em nosso meta-modelo foram apresentadas
no capítulo 3. Nesta seção apresentaremos a sintaxe LECI para a definição de cada uma delas.
União
A união de contextos de interação é definida na LECI através da seguinte sintaxe:
union( <contexts_set> ), onde
116
<contexts_set> é o conjunto de identificadores dos contextos que formam a união,
separados por vírgulas.
Exemplo:
Suponhamos que os contextos de interação "O locatário da publicação é professor." e
"O locatário da publicação é aluno da pós-graduação.", mencionados no capítulo 3, tenham
sido definidos na LECI e identificados, respectivamente por locatario_professor e
locatario_aluno_pos. Para definir o contexto de interação "O locatário da publicação é
professor ou aluno da pós-graduação." poderíamos especificar a seguinte sentença na LECI:
union(locatario_professor, locatario_aluno_pos)
Interseção
A interseção de contextos de interação é definida na LECI através da seguinte sintaxe:
intersection( <contexts_set> ), onde
<contexts_set> é o conjunto de identificadores dos contextos que formam a interseção,
separados por vírgulas.
Exemplo:
Suponhamos que os contextos de interação "O usuário corrente do sistema é
professor." e "O locatário da publicação é aluno do usuário.", mencionados no capítulo 3,
tenham sido definidos na LECI e identificados, respectivamente por usuario_professor e
locatario_aluno_do_usuario. Para definir o contexto de interação "O usuário corrente do
sistema é professor e o locatário da publicação é seu aluno" poderíamos especificar a seguinte
sentença na LECI:
intersection(usuario_professor, locatario_aluno_do_usuario)
Subcontexto
A relação de Subcontexto entre contextos de interação é definida na LECI através da
seguinte sintaxe:
117
subcontext( <basic_context>, <constraints> ), onde
<basic_context> é o identificador do contexto base, do qual o contexto definido pela
relação é subcontexto.
<constraints> é uma expressão lógica que indica que restrições ao contexto base
caracterizam o subcontexto sendo definido. Estas restrições são especificadas com base em
conceitos do domínio e / ou relações entre contextos.
Exemplo:
Suponhamos que o contexto de interação "RNC aberto pelo supervisor", mencionado
no capítulo 3, tenha sido definido na LECI e identificado por RNC_aberto_pelo_supervisor.
Para definir o contexto de interação "RNC aberto pelo supervisor devido a reclamação de
cliente", como subcontexto deste contexto de interação com a restrição adicional de que o
RNC foi aberto devido a reclamação de cliente, poderíamos especificar a seguinte sentença na
LECI:
subcontext(RNC_aberto_pelo_supervisor, há reclamação de cliente)
Complementaridade
A relação de Complementaridade entre contextos de interação é definida na LECI
através da seguinte sintaxe:
complement( <complement_context>, [<super_context>] ), onde
<complement_context> é o identificador do contexto complementar ao contexto
definido pela relação.
<super_context> é o identificador do supercontexto comum aos contextos
complementares, no escopo do qual será definida a relação de complementaridade. Este
parâmetro é opcional. Se não for especificado, a complementaridade é total e não em relação a
algum supercontexto restrito.
Exemplo:
Suponhamos que os contextos de interação "RNC aberto pelo supervisor" e "RNC não
devido a reclamação de cliente", mencionados no capítulo 3, tenham sido definidos na LECI e
identificados, respectivamente por RNC_aberto_pelo_supervisor e
RNC_sem_reclamacao_cliente. Para definir o contexto de interação "RNC não aberto pelo
118
supervisor, não devido a reclamação de cliente." como sendo o complementar do contexto
"RNC aberto pelo supervisor" em relação ao supercontexto "RNC não devido a reclamação de
cliente", poderíamos especificar a seguinte sentença na LECI:
complement(RNC_aberto_pelo_supervisor, RNC_sem_reclamacao_cliente)
5.10.4 Representação de Mudanças no Contexto de Interação Inicial do Diálogodevidas a Enunciados de Usuário
Vimos no capítulo 3 que a semântica de enunciados previamente emitidos pelo usuário
pode influenciar também o diálogo no qual são emitidos e não somente os diálogos
posteriores. A dependência semântica entre enunciados de um mesmo diálogo faz com que
determinados enunciados de usuário modifiquem o contexto de interação inicial deste diálogo.
Para a representação de mudanças no contexto de interação inicial de um diálogo criamos
duas formas especiais de identificação de contextos de interação:
• a palavra Initial, que representa o contexto de interação inicial do diálogo;
• uma sentença na forma:
user utterances: <concept> [<value>],
que representa o contexto de interação resultante da enunciação de value
associado ao conceito <concept>. Quando <value> não é especificado, a sentença
representa o contexto de interação resultante de qualquer enunciação do usuário
que aborde o conceito <concept>.
Estes dois tipos especiais de contexto de interação em conjunto com a cláusula
Exclusive-Contexts permitem representar que enunciados do contexto de interação inicial
do diálogo são afetados devido a um determinado enunciado de usuário, assim como que
enunciados que não seriam emitidos no contexto de interação inicial serão emitidos em
conseqüência deste enunciado.
Exemplos:
Consideremos a interação para a descrição de uma não conformidade no Qualitas,
mencionada no capítulo 3, para exemplificar a representação da interdependência entre
enunciados de um mesmo diálogo na LECI. Conforme mencionamos, em alguns casos, a
natureza de uma não conformidade pode ser inferida de acordo com o motivo da abertura do
119
relatório da não conformidade (RNC). No exemplo do capítulo 3, mencionamos que se o
técnico informar que o motivo do RNC é "A análise crítica do contrato foi realizada após o
prazo estabelecido na norma.", a natureza é de processo e o sistema deve impedir que o
técnico escolha outra natureza, enquanto se mantiver este motivo. A seguir apresentamos
trechos do diálogo para a descrição da não conformidade definido na LECI, ilustrando a
representação desta dependência.
Dialog Descrição da Não Conformidade (Domain Information)Sequence {
. . .
system: <Natureza> (Information Request)user_alternatives {processo, produto, sistema}
Exclusive-Contexts {When context is Initial {
user: natureza do RNC (Domain Information)}when user utterances motivo do RNC as <análise crítica fora do prazo>
{system: processo (Domain Information Presentation)
}. . .
system: <Motivo do RNC> (Information Request)user: motivo do RNC (Domain Information). . .
}
5.11 Representação de Estratégias para Tratamento de Erros deUsuário
Para indicar como será o tratamento de erros de usuário ocorridos durante um diálogo,
ou vários diálogos componentes de uma mesma tarefa, o designer deverá adicionar à sentença
que define, respectivamente, o diálogo, ou a tarefa. uma sentença com a seguinte sintaxe:
has user errors handled byhandle_user_errors(<validation_type1>, <system_response_type1>,<dialog_embedding1>) [when context is [one of] <contexts_set1>...handle_user_errors(<validation_typeN>, <system_response_typeN>,<dialog_embeddingN>) [when context is [one of] <contexts_setN>]
<validation_typeI> identifica, para cada conjunto de contextos de interação
<context_setI>, o tipo de validação a ser executada. immediate identifica uma validação
pontual e batch identifica uma validação por lote.
<system_response_typeI> identifica, para cada conjunto de contextos de interação
<contexts_setI>, o tipo de resposta do sistema para o tratamento de erros cometidos pelo
120
usuário. A tabela 5.8 apresenta os identificadores LECI associados a cada um dos tipos de
resposta de sistema apresentados no capítulo 3.
Tipo de Resposta do Sistema IdentificadorCorreção Interativa interactive correctionCorreção Interativa Sugerida suggested interactive correction
Tabela 5.8: Identificadores LECI para tipos de respostas do sistema para tratamento de erroscometidos pelo usuário.
<dialog_embeddingI> identifica, para cada conjunto de contextos de interação
<context_setI>, a forma como o diálogo remediador será encaixado na interação. A tabela 5.9
apresenta os identificadores LECI associados a cada uma das formas de encaixe de diálogos
apresentadas no capítulo 3.
Forma de Encaixe para Diálogos de Correção IdentificadorInserido insertedAutônomo autonomousAutônomo Contextualizado contextualized autonomous
Tabela 5.9: Identificadores das formas de encaixe para diálogos de correção na LECI.
<contexts_setI> é um conjunto de identificadores dos contextos de interação para
os quais é utilizada a estratégia de tratamento de erros de usuário, definida pela I-ésima
sentença handle_user_errors. As várias formas de se representar um identificador de
contexto são apresentadas na seção 5.10.1. Quando há uma única estratégia de tratamento,
válida para qualquer contexto de interação, não devem ser especificadas sentenças when
context is [one of].
Exemplos:
Tratamento de erros de usuário para um único diálogo
Consideremos o diálogo para a solicitação de impressão de um arquivo definido na
LECI na seção 5.7. Vamos defini-lo novamente, especificando, desta vez, uma estratégia de
tratamento de erros cometidos pelo usuário. A seguir apresentamos a nova definição do
diálogo na LECI, na qual especificamos uma validação em batch, com correção interativa,
onde o diálogo remediador é inserido no diálogo original.
121
Dialog Solicitação de Impressão de Arquivo (Task Information)sequence{
system: <Para imprimir você deve fornecer os dados, e, em seguida,selecionar o controle da função que você deseja acionar> (Help)subtopic <Nome do Arquivo> {system: <Nome do Arquivo> (Information Request)user_alternatives <nomes de arquivos>
exclusive choice {user chooses: nome do arquivo (Domain Information)user informs: nome do arquivo (Domain Information)
} mandatorily}combination subtopic <Nome da Impressora> {
system: <Nome da Impressora> (Information Request)user_alternatives <nomes de impressoras>
user chooses: nome da impressora (Domain Information)user requests: initialization of configuração da impressoracausing persistence (Function Activation)
}subtopic <Número de Cópias> {
system: <Número de Cópias> (Information Request)suggestion <1>
user: numero_copias (Domain Information)}user requests: initialization of Controle de Impressãocausing persistence (Function Activation)
}has user errors handled by
handle_user_errors( batch, interactive correction, inserted )
Tratamento de erros de usuário para todos os diálogos de uma mesma tarefa
Consideremos a tarefa "Editar Informações Sobre Livro" definida na LECI na seção
5.8. Vamos defini-la novamente, especificando, desta vez, um tratamento de erros de usuário
padrão para todos os diálogos que a compõem. A seguir apresentamos a nova definição da
tarefa na LECI, na qual especificamos uma validação em batch, com correção interativa, onde
o diálogo remediador é autônomo contextualizado.
Task Editar Informações Sobre Livro (Editing)sequence{
dialog Edição de Informações Gerais de Publicaçãoallows interruption (Domain Information)
dialog Edição de Informações Específicas de Livroallows interruption after resumption, allows revisions atEdição de Informações Gerais de Publicação
(Domain Information)dialog Confirmação de Informações Fornecidas allows interruption
after resumption, allows revisions atEdição de Informações Gerais de Publicação,Edição de Informações Específicas de Livro
(Operation Confirmation)dialog Feedback de Salvamento de Informações (Feedback)
}
122
has user errors handled byhandle_user_errors( batch, interactive correction,
contextualized autonomous )
5.12 Representação de Estratégias para Tratamento de Falhas deSistema
Para indicar como será o tratamento das falhas do sistema ocorridas durante um
diálogo, ou vários diálogos componentes de uma mesma tarefa, o designer deverá adicionar à
sentença que define, respectivamente, o diálogo, ou a tarefa, uma sentença com a seguinte
sintaxe:
has system failures handled by
handle_system_failures(<system_failures_handling_type1>)
[when context is [one of] <contexts_set1>
...
handle_system_failures(<system_failures_handling_typeN>)
[when context is [one of] <contexts_setN>
onde,
<system_failures_handling_typeI> indica, para cada conjunto de contextos de
interação <system_failures_contextI>, o identificador do tipo de tratamento de erro a ser
executado quando ocorre uma falha do sistema. Estes tipos foram apresentados no capítulo 3.
A tabela 5.10 indica quais os identificadores LECI associado a cada um deles.
Tipo de Tratamento de Falhas de Sistema IdentificadorCorreção Interativa interactive correctionCorreção Interativa Sugerida suggested interactive correctionFeedback Prestativo helpful feedbackFeedback Esperançoso hopeful feedbackFeedback Sumário simple feedback
Tabela 5.10: Identificadores dos tipos de tratamento de falhas de sistema na LECI.
<contexts_setI> é um conjunto de identificadores dos contextos de interação para
os quais é utilizada a estratégia de tratamento falhas de sistema, definida pela I-ésima
sentença handle_system_failures. As várias formas de se representar um identificador de
contexto são apresentadas na seção 5.10.1. Quando há uma única estratégia de tratamento,
válida para qualquer contexto de interação, não devem ser especificadas sentenças when
context is [one of].
123
Exemplos:
Tratamento de falhas de sistema para um único diálogo
Vamos acrescentar agora, ao diálogo para a solicitação de impressão de um arquivo,
redefinido na seção anterior, estratégias para tratamento de falhas de sistema. Nos contextos
onde a falha é "impossibilidade de conexão com a impressora" ou "falta de papel" a estratégia
é feedback esperançoso. Em qualquer outro contexto, a estratégia é feedback sumário. A
redefinição do diálogo é apresentada a seguir.
Dialog Solicitação de Impressão de Arquivo (Task Information)sequence{
system: <Para imprimir você deve fornecer os dados, e, em seguida,selecionar o controle da função que você deseja acionar> (Help)subtopic <Nome do Arquivo> {system: <Nome do Arquivo> (Information Request)user_alternatives <nomes de arquivos>
exclusive choice {user chooses: nome do arquivo (Domain Information)user informs: nome do arquivo (Domain Information)
} mandatorily}combination subtopic <Nome da Impressora> {
system: <Nome da Impressora> (Information Request)user_alternatives <nomes de impressoras>
user chooses: nome da impressora (Domain Information)user requests: initialization of configuração da impressoracausing persistence (Function Activation)
}subtopic <Número de Cópias> {
system: <Número de Cópias> (Information Request)suggestion <1>
user: numero_copias (Domain Information)}user requests: initialization of Controle de Impressãocausing persistence (Function Activation)
}has user errors handled by
handle_user_errors( batch, interactive correction, inserted )
has system failures handled byhandle_system_failures( hopeful feedback ) when context is one of
impressora_nao_conectada, falta_de_papel
handle_system_failures( simple feedback ) when context iscomplement(union(impressora_nao_conectada, falta_de_papel))
Tratamento de falhas de sistema para todos os diálogos de uma mesma tarefa
Vamos acrescentar agora, à tarefa "Editar Informações Sobre Publicação", redefinida
na seção anterior, estratégias para tratamento de falhas de sistema. No contexto onde a falha é
124
"não há espaço em disco para o salvamento da informações" a estratégia é feedback
prestativo. Em qualquer outro contexto, a estratégia é feedback sumário. A redefinição da
tarefa é apresentada a seguir.
Task Editar Informações Sobre Livro (Editing)sequence{
dialog Edição de Informações Gerais de Publicaçãoallows interruption (Domain Information)
dialog Edição de Informações Específicas de Livroallows interruption after resumption, allows revisions atEdição de Informações Gerais de Publicação
(Domain Information)dialog Confirmação de Informações Fornecidas allows interruption
after resumption, allows revisions atEdição de Informações Gerais de Publicação,Edição de Informações Específicas de Livro
(Operation Confirmation)dialog Feedback de Salvamento de Informações (Feedback)
}has user errors handled by
handle_user_errors( batch, interactive correction,contextualized autonomous )
has system failures handled byhandle_system_failures( helpful feedback ) when context is
falta_espaco_em_discohandle_system_failures( simple feedback ) when context is
complement(falta_espaco_em_disco)
5.13 Reuso de Especificações
Em qualquer especificação, muitas definições podem ser válidas para diversas
situações. Para evitar que o designer tenha que especificar várias vezes as mesmas definições,
introduzimos na LECI mecanismos de reuso. Estes mecanismos visam melhorar a
redigibilidade da linguagem e facilitar a manutenção do modelo de interação especificado. A
LECI possibilita os seguintes mecanismos de reuso: herança entre papéis de usuário, relações
entre contextos de interação, reuso de especificações de diálogos e reuso de especificações de
tarefas. A representação de herança entre papéis de usuário e relações entre contextos de
interação foram abordadas, respectivamente, nas seções 5.2 e 5.10.3. Os reusos de
especificações de diálogos tarefas serão descritos a seguir.
5.13.1 Reuso de Especificações de Diálogos
A possibilidade de reuso de especificações de diálogos se faz bastante vantajosa. O
designer pode desejar encaixar um mesmo "subdiálogo" dentro de diálogos distintos ou ainda
125
definir templates de diálogos ou subdiálogos, para instanciá-los através de passagem de
parâmetros.
Um exemplo de reuso de subdiálogo ocorre no Qualitas. Existem diálogos onde o
usuário fornece informações sobre a avaliação de um serviço prestado por ele. Como existem
quatro tipos de serviço, há quatro diálogos distintos para a informação sobre a avaliação de
serviço, cada um correspondendo a um tipo de serviço. Todos estes diálogos incluem um
subdiálogo idêntico que aborda pontos fortes e fracos da prestação do serviço. Outros
exemplos, de mesmos subdiálogos que fazem parte de diálogos distintos, são subdiálogos que
contêm apenas enunciados de sistema. Por exemplo, um mesmo conjunto de mensagens
padrão preventivas de erro, como "* campos obrigatórios.", costuma ser enunciado em
diversos diálogos.
A representação de informações contextuais sobre tarefas exemplifica a utilização de
templates de subdiálogos. Normalmente a apresentação deste tipo de informação segue um
mesmo padrão. Por exemplo, em qualquer diálogo que aborde o tópico publicação, o designer
pode desejar informar ao usuário que este é o tópico, que o subtópico é a tarefa realizada
sobre a publicação (Alteração, Consulta, etc) e que o foco do diálogo é uma determinada
publicação, identificada, por exemplo, por seu título e autores.
O reuso de diálogos é suportado pela LECI através da inclusão de diálogos
compartilhados (qualificados com o identificador shared) na estrutura que define o diálogo
que reusa as especificações compartilhadas. Esta inclusão é representada através da seguinte
sintaxe:
include(<dialog_name> [, {<dialog_operands>}])
<dialog_name> é o identificador do diálogo compartilhado a ser reusado.
<dialog_operands> este parâmetro só deve ser especificado quando o diálogo
compartilhado é um template. Ele representa a lista de operandos necessários para a
instanciação do template (separados por vírgulas).
Exemplos:
A seguir, apresentamos uma sentença LECI que define o template de um subdiálogo
onde o sistema enuncia informações contextuais que devem ser apresentadas ao usuário em
diálogos sobre o tópico publicação. Em seguida apresentamos trechos de dois diálogos, onde
são definidas inclusões deste subdiálogo.
126
shared Dialog contexto_publicacao (Information Presentation)operands { tarefa, título da publicação, autores }Sequence{subtopic {system: <Publicação - > (Contextual Information)system: tarefa (Contextual Information)
}subtopic {system: <Título> (Apposition)system: Título da Publicação (Domain Information)
}subtopic {system: <Autores> (Apposition)system: Autores da Publicação (Domain Information)
}}
Dialog Edição de Informações Específicas de PublicaçãoSequence{
include(contexto_publicacao,{<Alteração>, título da publicação, autores})...
}
Dialog Apresentação de Informações sobre PublicaçãoSequence{
include(contexto_publicacao,{<Consulta>, título da publicação, autores})...
}
5.13.2 Reuso de Especificações de Tarefas
A possibilidade de reuso de especificações de tarefas também é importante, pois
tarefas distintas podem ter passos em comum. Por exemplo, as tarefas "Editar informações
sobre dissertação de mestrado", "Editar informações sobre livro", "Editar informações sobre
periódico", "Editar informações sobre relatório técnico" e "Editar informações sobre tese de
doutorado" são similares, variando apenas o diálogo para a edição das informações
específicas.
O reuso de tarefas é possibilitado na LECI de forma análoga ao reuso de diálogos,
através da inclusão de tarefas compartilhadas (qualificadas com o identificador shared) na
estrutura que define a tarefa que reusa as especificações compartilhadas. Esta inclusão é
representada através da seguinte sintaxe:
include(<task_name> [, {<task_operands>}])
<task_name> é o identificador da tarefa compartilhada a ser reusado.
127
<task_operands> este parâmetro só deve ser especificado quando a tarefa
compartilhada é um template. Ele representa a lista de operandos necessários para a
instanciação do template (separados por vírgulas). Os operandos para templates de tarefa são
identificadores de diálogos.
Exemplos:
Para simplificar as definições das tarefas de edição dos diversos tipos de publicação
mencionadas, poderíamos definir um template para tarefas de edição de publicação, que
recebesse como parâmetro o diálogo para a edição de informações específicas sobre a
publicação. O template e as tarefas que o instanciam poderiam ser definidas na LECI
conforme apresentado a seguir.
shared Task Editar Informações Sobre Livro (Editing)operands dialogo_para_edicao_de_informacoes_especificassequence{
dialog Edição de Informações Gerais de Publicaçãoallows interruption (Domain Information)
dialog dialogo_para_edicao_de_informacoes_especificasallows interruption after resumption, allows revisions atEdição de Informações Gerais de Publicação
(Domain Information)dialog Confirmação de Informações Fornecidas allows interruption
after resumption, allows revisions atEdição de Informações Gerais de Publicação,dialogo_para_edicao_de_informacoes_especificas
(Operation Confirmation)dialog Feedback de Salvamento de Informações (Feedback)
}has user errors handled by
handle_user_errors( batch, interactive correction,contextualized autonomous )
has system failures handled byhandle_system_failures( helpful feedback ) when context is
falta_espaco_em_discohandle_system_failures( simple feedback ) when context is
complement(falta_espaco_em_disco)
Task Editar Informações Sobre Dissertação de Mestrado (Editing)include( Editar Informações Sobre Publicação,
{Edição de Informações Específicas de Dissertação de Mestrado})
Task Editar Informações Sobre Livro (Editing)include( Editar Informações Sobre Publicação,
{Edição de Informações Específicas de Livro} )
Task Editar Informações Sobre Periódico (Editing)include( Editar Informações Sobre Publicação,
{Edição de Informações Específicas de Periódico} )
128
Task Editar Informações Sobre Relatório Técnico (Editing)include( Editar Informações Sobre Publicação,
{Edição de Informações Específicas de Relatório Técnico} )
Task Editar Informações Sobre Tese de Doutorado (Editing)include( Editar Informações Sobre Publicação,
{Edição de Informações Específicas de Tese de Doutorado} )
5.14 Componentes Tecnológicos e Meta-Tecnológicos do Modelode Interação
Acreditamos que os componentes do modelo de interação apresentados no capítulo 3
têm semântica meta-tecnológica, ou seja, podem ser utilizados para construir um discurso
sobre a tecnologia, seja ela qual for. Entretanto, a forma de instanciação destes componentes
pode variar dependendo das limitações e dos recursos das tecnologias para as quais o modelo
de interação será mapeado. Por outro lado, algumas partes do modelo de interação podem ser
comuns a mais de uma tecnologia ou até mesmo a todas para as quais será mapeado. Permitir
que o designer separe em seu modelo de interação o discurso meta-tecnológico de sua
instanciação em uma tecnologia pode trazer as seguintes vantagens:
• pode auxiliar designers a conscientizar-se sobre que partes de seu modelo teriam
que ser modificadas caso a aplicação tenha de ser implementada em uma
tecnologia diferente daquela para a qual tenha sido inicialmente projetada;
• pode facilitar a elaboração de analogias entre os padrões de interação adotados em
tecnologias distintas nas quais o mesmo modelo será implementado.
Desta forma, para permitir que esta separação seja explicitada na LECI, definimos o
seguinte construto:
[Exclusive-Technologies {]when technology is <technology_type1> {
<interaction_structure1>}[. . .when technology is <technology_typeN> {
<interaction_structureN>}
}]
onde:
<technology_typeI> é a descrição do I-ésimo tipo de tecnologia na qual a aplicação
poderá ou deverá ser implementada;
129
<interaction_structureI> é a estrutura de interação específica que só deve existir
quando a aplicação for implementada no I-ésimo tipo de tecnologia especificado e que,
portanto, é componente da mensagem tecnológica do designer.
Exemplo:
Considere um diálogo para a Seleção de uma Publicação, a ser travado para a
realização da tarefa Editar Informações sobre Publicação, em um Sistema Gerenciador de
Biblioteca. Suponha que, ao especificar versões deste diálogo acessíveis via desktop (web) ou
telefone, o designer queira explicitar que partes deste diálogo são comuns aos dois ambientes
e quais são mais adequadas a cada um deles. Suponha, por exemplo, que, assumindo que há
grande possibilidade de o usuário estar procurando editar uma publicação cadastrada
recentemente, o designer decida disponibilizar para os dois ambientes, uma lista com as
últimas N publicações cadastradas e um diálogo para busca pela publicação, caso ela não
esteja na lista. Suponha, entretanto, que ele opte por disponibilizar acessos ao diálogo de
busca, de formas distintas para cada ambiente. Por exemplo, no desktop ele pode incluir este
diálogo dentro do diálogo para a seleção de publicação, aproveitando o espaço disponível e
minimizando o número de diálogos, para evitar espera por carregamento de página. No
telefone ele pode optar por definir que o usuário deve solicitar explicitamente este diálogo
após ouvir as N opções de publicação e ainda permitir que ele solicite a repetição das
informações que caracterizam as N publicações, visto que elas não são persistentes como no
desktop. Para representar estas abstrações através da LECI, faríamos a seguinte especificação
para o diálogo para seleção de publicação:
Dialog Seleção de Publicação (Selection)Sequence subtopic Escolha de Publicação {system:<escolha dentre as N últimas publicações cadastradas oua busque em todo o cadastro> (Information Request)user_alternatives <N últimas publicações cadastradas>
Choice {user chooses: identificador da publicação(Domain Information)
Exclusive-Technologies {when technology is telefone {Choice {user reinitializes this (Dialog Reinitialization)user initializes Busca por Publicação(Function Request)
}}when technology is desktop {
include(Busca por Publicação) }
}}
}
130
Capítulo 6
Utilização Prática da LECI
Neste capítulo apresentamos estudos de caso realizados com o objetivo de ilustrar a
aplicação prática da LECI e as vantagens de se utilizá-la como ferramenta de especificação de
cenários de interação. Na seção 6.1 descrevemos passo a passo como designers devem utilizar
a linguagem para especificar cenários de interação reais. Na seção 6.2 exemplificamos como
a LECI pode apoiar o designer na especificação de aplicações multi-tecnologia. Por fim, na
seção 6.3 utilizamos os cenários apresentados na seção 6.1 para realizar uma análise
comparativa entre a LECI e a LEMD, a qual ilustra nossas motivações para a decisão de criar
uma nova linguagem, ao invés de adaptar a LEMD.
6.1 Estudo de Caso 1: Especificação de Cenários de InteraçãoReais na LECI
Nesta seção descrevemos como designers devem utilizar a LECI para especificar
cenários de interação reais. Os cenários utilizados nesta descrição abordam duas tarefas do
módulo de reuniões do Qualitas: as tarefas “Criar Reunião” e “Editar Reunião”. A tarefa
“Criar Reunião” consiste na iniciação da preparação de uma reunião, através da definição
preliminar de suas características. A tarefa “Editar Reunião” consiste na edição das
características definidas para a reunião, durante sua preparação, por qualquer dos usuários
definidos como seu organizador. A seguir apresentamos os cenários que descrevem estas
tarefas e na próxima seção, apresentaremos passo a passo como especificá-los na LECI.
Tarefa 1: Criar Reunião
Atores: usuário do módulo reuniões e sistema.
Curso Típico
A)- Descrição Geral
O sistema solicita que o usuário informe se deseja criar uma reunião:
• a partir de uma reunião existente,
131
• a partir de um template de reuniões,
• a partir do zero.
Após o usuário escolher a forma de criação, o sistema solicita que ele forneça/atualize
as informações que caracterizam a reunião:
• sua natureza e assunto de forma genérica;
• se a reunião segue alguma norma;
• a pauta da reunião;
• quais são os papéis que serão atribuídos aos participantes da reunião;
• quem são os outros usuários do módulo reuniões, organizadores da reunião, e para
cada um deles (inclusive o criador da reunião), quais são seus papéis na
organização desta reunião;
• quem são os outros participantes, quais são seus papéis;
• quais são as listas de comunicações a serem utilizadas durante a preparação e
divulgação dos resultados da reunião e quem são seus membros;
• o local;
• a data e
• os prazos relativos (em dias) para: definição da pauta, definição da programação,
convocação da reunião, confirmação da presença e definição de representação,
emissão de lembrete, aprovação e divulgação da ata. (Os prazos para a aprovação
e divulgação da ata são contados a partir da data da ocorrência da reunião e os
demais prazos, a partir da data de sua criação).
As informações sobre os papéis, organizadores, participantes e listas de comunicação
são fornecidas pelo usuário através de subdiálogos iniciados a partir do diálogo corrente.
Depois que o usuário termina de informar as características da nova reunião, o sistema lhe
apresenta todas as informações que ele forneceu, solicita que ele as confirme e que indique se
deseja criar um template de reuniões definido por elas.
132
B)- Alternativas Quanto ao Método de Criação da Reunião
B1. O usuário decide criar uma reunião a partir de uma reunião existente
O sistema solicita que ele informe qual reunião servirá de base para a criação da nova
reunião. Para isto, apresenta ao usuário uma lista com as últimas n reuniões, permitindo que
este escolha a reunião desejada dentre a lista ou inicie um diálogo onde pode informar
parâmetros para buscar a reunião em todo o banco de dados.
B1.1. O usuário escolhe uma das n reuniões apresentadas
O sistema apresenta um subconjunto das informações que caracteriza a reunião
escolhida pelo usuário (mesmo conjunto de informações apresentado na descrição geral, com
exceção da data1) e solicita que ele escolha quais destas informações deseja aproveitar para a
criação da nova reunião. Após a escolha do usuário, o curso segue como apresentado na
descrição geral.
B1.2. O usuário decide realizar uma busca pela reunião em todo o Banco de Dados
Neste caso o usuário inicia um diálogo no qual o sistema permite que ele informe os
seguintes parâmetros para a busca: o assunto, a data, a natureza e/ou os participantes da
reunião. O usuário informa os parâmetros que deseja e o sistema realiza a busca.
B1.2.1. É encontrada apenas uma reunião que satisfaz as condições de busca
O sistema apresenta ao usuário o assunto, a data, a natureza e os participantes da
reunião encontrada, para identificá-la. Em seguida, permite que o usuário selecione quais
informações associadas à reunião deseja aproveitar para a criação da nova reunião ou que
inicie uma nova busca. Se o usuário decide iniciar nova busca o curso segue como
apresentado no item B1.2, em caso contrário, o curso segue como apresentado na descrição
geral.
B1.2.2. É encontrada uma lista de reuniões
O sistema apresenta ao usuário a lista de reuniões encontradas e permite que ele
escolha a partir de qual delas deseja criar a nova reunião ou que inicie uma nova busca. Se o
1 A data é a única das informações que caracteriza uma reunião existente que não pode ser aproveitada para a
criação de uma nova.
133
usuário decide iniciar nova busca o curso segue como apresentado no item B1.2, em caso
contrário, o curso segue como apresentado no item B1.2.1.
B1.2.3 Não é encontrada reunião que satisfaça as condições de busca
Neste caso o sistema informa este fato ao usuário e permite que ele inicie uma nova
busca. A partir deste ponto o curso segue como apresentado no item B1.2.
B2. O usuário decide criar uma reunião a partir de um template de reuniões
Neste caso o sistema solicita que o usuário informe qual o template a ser usado como
base para a criação da reunião. O usuário informa o template desejado. O sistema apresenta o
conjunto de informações que caracteriza o template escolhido pelo usuário (mesmo conjunto
de informações apresentado na descrição geral, com exceção da data) e solicita que ele
escolha quais destas informações deseja aproveitar para a criação da nova reunião. Após a
escolha do usuário, o curso segue como apresentado no item D1.
B3. O usuário decide criar uma reunião a partir do zero
Neste caso, não há passos intermediários, o curso segue exatamente como apresentado
no item D1, abaixo.
C)- Alternativas Quanto à Criação de Template
C1. O usuário decide criar um template a partir da reunião criada
No mesmo diálogo em que informa que os dados foram armazenados com sucesso o
sistema também informa que o template foi criado com sucesso. A partir deste ponto o curso
segue como apresentado na descrição geral.
C2. O usuário decide NÃO criar um template a partir da reunião criada
Neste caso o curso segue exatamente como apresentado na descrição geral.
D)- Alternativas Quanto à Confirmação das Informações
D1. O usuário confirma as informações fornecidas
O sistema informa que as informações foram armazenadas com sucesso, apresenta a
mensagem padrão sobre criação de reunião que deve ser enviada aos outros organizadores e
pergunta se ele deseja que ela seja enviada imediatamente ou posteriormente.
134
D1.1 O usuário solicita o envio imediato da mensagem
O sistema a envia, informando ao usuário que este envio foi realizado com sucesso.
D1.2. O usuário decide enviar a mensagem posteriormente
O sistema informa ao usuário que ele poderá enviar a mensagem posteriormente
acessando a opção “Comunicar Criação de Reunião” ou após editar as características da
reunião, acessando a opção “Editar Reunião”.
Cursos de Exceção
O usuário fornece informações incorretamente
O sistema apresenta para o usuário apenas as informações ele forneceu incorretamente
e indica como ele deve corrigi-las.
O sistema falha
O sistema exibe uma mensagem informando o usuário sobre a falha ocorrida e
solicitando que ele tente, se for o caso, invocar novamente a função do sistema que falhou.
Tarefa 2: Editar Reunião
Atores: organizador da reunião e sistema.
Curso Típico
A) - Descrição Geral
O sistema apresenta ao usuário uma lista com todas as reuniões em preparação para as
quais ele foi designado como organizador e solicita que ele informe qual delas deseja editar.
Após o usuário escolher a reunião, o sistema solicita que ele atualize as informações que
caracterizam a reunião. A partir deste ponto este cenário é quase idêntico ao cenário da tarefa
“Criar Reunião”. As únicas diferenças são as seguintes:
• o sistema só pergunta ao usuário se ele deseja criar um template a partir da
reunião, caso isto já não tenha sido feito por ele ou por outro organizador;
135
• a mensagem que o sistema permite que o usuário envie após confirmar as
informações fornecidas para a reunião diz respeito a “alterações realizadas” e não a
“criação de reunião”.
Cursos de Exceção
Há apenas um curso de exceção para esta tarefa que não tenha sido descrito no cenário
da tarefa “Criar Reunião”. Ele será descrito a seguir
O usuário escolhe uma reunião que está sendo editada por outro organizador
Neste caso o sistema lhe informa este fato e quem é o organizador que está editando a
reunião.
6.1.1 Especificação Passo a Passo dos Cenários de Interação na LECI
Para especificar na LECI os cenários de interação apresentados nesta seção, assim
como qualquer outro cenário de interação, são necessários os seguintes passos:
1. especificação dos papéis dos usuários que atuam no cenário,
2. especificação dos conceitos da aplicação referenciados,
3. especificação dos contextos de interação,
4. especificação da estrutura da tarefa em termos de diálogos,
5. especificação das estruturas dos diálogos componentes da tarefa, em termos de
enunciados de usuário e de sistema.
Nas próximas seções ilustraremos a realização de cada um destes passos, utilizando os
cenários apresentados.
Especificação dos Papéis de Usuário
Os papéis de usuário são identificados a partir dos atores mencionados no cenário,
excetuando-se o sistema. Desta forma, a partir dos cenários descritos, podemos identificar os
seguintes papéis: usuário do módulo reuniões e organizador da reunião. Podemos identificar
ainda a seguinte relação de herança entre os papéis: todo o organizador é um usuário do
136
módulo reuniões. Assim, as seguintes sentenças definem estes papéis na LECI, considerando-
se apenas as tarefas descritas:
Role usuário do módulo reuniões may access Criar Reunião
Role organizador da reunião sub-role of usuário do módulo reuniõesmay access Editar Reunião
Especificação dos Conceitos da Aplicação
Os conceitos da aplicação são todas as informações que os cenários descrevem ser
fornecidas pelo usuário ou apresentadas pelo sistema. Desta forma, as seguintes sentenças
definem na LECI todos os conceitos da aplicação referenciados nos cenários apresentados:
Concept identificador da reunião type Original DomainConcept assunto type Original DomainConcept natureza type Original DomainConcept pauta type Original DomainConcept norma type Original DomainConcept organizadores type Original DomainConcept organizador type Original DomainConcept papéis type Original DomainConcept papel do organizador type Original DomainConcept participantes type Original DomainConcept participante type Original DomainConcept obrigatoriedade da presença type Original DomainConcept listas de comunicação type Original DomainConcept local type Original DomainConcept data type Original DomainConcept prazo para a definição da pauta type Original DomainConcept prazo para a definição da programação type Original DomainConcept prazo para a convocação type Original DomainConcept prazo para a confirmação da presença type Original DomainConcept prazo para o lembrete type Original DomainConcept prazo para a aprovação da ata type Original DomainConcept prazo para a divulgação da ata type Original DomainConcept método de criação da reunião type Introduced by TechnologyConcept identificador do template type Introduced by TechnologyConcept informações aproveitáveis type Introduced by TechnologyConcept criar template type Introduced by TechnologyConcept nome da lista de comunicação type Introduced by TechnologyConcept membros da lista de comunicação type Introduced by Technology
Especificação dos Contextos de Interação
Os contextos de interação são identificados através de alternativas de interação. Cada
alternativa de interação representa um contexto de interação. Apresentaremos a seguir as
sentenças que definem na LECI todos os contextos de interação necessários para a
representação das alternativas de interação descritas nos cenários.
137
Interaction-Context(<Criacao_a_partir_de_reuniao_existente>,{método de criação de reunião},<método de criação de reunião = a partir de reunião existente>)
Interaction-Context(<Criacao_a_partir_de_template>,{método de criação de reunião},<método de criação de reunião = a partir de template>)
Interaction-Context(<usuario_realiza_busca>,{})
Interaction-Context(<reuniao_nao_encontrada>,{número de reuniões encontradas},<o número de reuniões encontradas é igual a 0>)
Interaction-Context(<mais_de_uma_reuniao_encontrada>,{número de reuniões encontradas},<o número de reuniões encontradas é maior que 1>)
Interaction-Context(<reuniao_concorrentemente_editada>,{identificador da reunião}, <a reunião identificada poridentificador da reunião está sendo editada por outro usuário>)
Especificação da Estrutura da Tarefa
As tarefas são representadas na LECI em termos de diálogos. Para segmentar a tarefa
em termos de diálogos é necessário analisar em que pontos do cenário ocorrem mudanças de
tópico. As alternativas de interação também têm papel fundamental para a especificação da
estrutura de uma tarefa na LECI. As alternativas de interação indicam em que contextos
ocorrem os diálogos. Alguns diálogos ocorrem em qualquer contexto e outros só em contextos
determinados. Por exemplo, para a tarefa “Criar Reunião”, o diálogo inicial para a seleção do
método de criação de reunião ocorre sempre, enquanto o diálogo para a seleção de um
template de reuniões só ocorre se o usuário desejar criar uma reunião a partir de um template.
Os cursos de exceção também influenciam a especificação das tarefas. Eles indicam
como devem ser especificadas na LECI, as estratégias de tratamento de erros de usuário e de
sistema. De acordo com o que está descrito nos cenários, a estratégia de tratamento de erros
de usuário a ser empregada ao longo dos diálogos componentes da tarefa correção é uma
correção interativa (Interactive Correction) feita em lote (Batch) e no diálogo de correção, o
sistema aborda apenas as informações que foram fornecidas incorretamente (Contextualized
Autonomous). A estratégia de tratamento de falhas de sistema é do tipo Feedback
Esperançoso (Hopeful Feedback).
Por fim, ao especificarmos a estrutura das tarefas convém analisar, também, se é
possível reusar especificações. Por exemplo, as tarefas descritas nos cenários apresentados são
138
compostas por muitos passos comuns: os cenários são praticamente iguais a partir do ponto
onde o usuário fornece/atualiza as informações que caracterizam a reunião. Desta forma
podemos especificar uma única vez as partes comuns a ambas as tarefas e ao especificarmos
suas estruturas, reusar estas especificações utilizando a cláusula include.
Tendo em mente as considerações apresentadas, especificamos na LECI a estrutura de
diálogos das tarefas descritas, através das seguintes sentenças:
Partes Comuns a Ambas as Tarefas
shared Task Informar Atributos da Reunião (Editing)operands tarefa_correnteSequence {
Dialog Edição dos Atributos da Reunião (Domain Information)Dialog Confirmação dos Atributos da Reunião (Operation Confirmation)Dialog Comunicação sobre Reunião (Communication)Exclusive-Contexts {
When Context is mensagem_sera_enviada_imediatamente {Dialog Feedback sobre Envio de Comunicação (Feedback)
}When Context is mensagem_sera_enviada_posteriormente {
Dialog Informação sobre Envio Posterior (Feedback)}
}}
Tarefa Criar Reunião
Task Criar Reunião (Creation)Sequence {
Dialog Seleção do Método de Criação da Reunião (Selection)Exclusive-Contexts {
When context is criacao_a_partir_de_reuniao_existente {Dialog Seleção de Reunião (Selection)When context is usuario_realiza_busca {
Repetition {Dialog Busca por ReuniãoExclusive-Contexts {When context is reuniao_nao_encontrada {
Dialog Feedback sobre Reunião não encontrada (Feedback)}When context is mais_de_uma_reuniao_encontrada {
Dialog Reuniões Encontradas (Selection)}
}}
}Dialog Seleção de Informação Aproveitável (Selection)
}When context is criacao_a_partir_de_template {
Dialog Seleção de Template (Selection)Dialog Seleção de Informação Aproveitável (Selection)
}}
139
include(Informar Atributos da Reunião, {“Criar Reunião”})}has user errors handled by
handle_user_errors( batch, interactive correction,contextualized autonomous )
has system failures handled byhandle_system_failures( hopeful feedback )
Tarefa Editar Reunião
Task Editar Reunião (Creation)Sequence {
Dialog Seleção de Reunião (Selection)include(Informar Atributos da Reunião, {“Editar Reunião”})
}has user errors handled by
handle_user_errors( batch, interactive correction,contextualized autonomous )
has system failures handled byhandle_system_failures( hopeful feedback )
Especificação da Estrutura dos Diálogos
Para a especificação de cada diálogo componente de uma tarefa na LECI, é necessário
identificar quais os enunciados de sistema e de usuário que o compõem. Os enunciados de
sistema são as apresentações de informação realizadas pelo sistema. Os enunciados de usuário
são todas as informações fornecidas por ele e todas as solicitações que ele faz durante a
interação. Para cada enunciado emitido pelo sistema com semântica Solicitação de
Informação, deve haver um enunciado de usuário correspondente, com semântica
Fornecimento de Informação. Desta forma, os enunciados de usuário para fornecimento de
informação podem ser identificados implicitamente no cenário do exemplo, a partir de trechos
que indicam que o sistema solicita o fornecimento de determinada informação, em conjunto
com trechos que indicam que o usuário fornece as informações solicitadas. Com base nestas
considerações, especificamos os diálogos descritos no cenário na LECI através das seguintes
sentenças:
Dialog Seleção do Método de Criação da Reunião (Selection)Sequence subtopic Método de Criação da Reunião {
system: <método de criação da reunião> (Information Request)user_alternatives { <a partir de uma reunião existente>,<a partir de um template de reuniões>, <a partir do zero> }
user: método de criação da reunião (Domain Information)}
Dialog Seleção de Reunião (Selection)Sequence subtopic Escolha de Reunião {
system:<escolha dentre as N últimas reuniões ou a busque em todo o cadastro> (Information Request)user_alternatives <N últimas reuniões>
140
Choice {user chooses: identificador da reunião (Domain Information)user initializes Busca por Reunião (Domain Information Request)
}}
Dialog Busca por Reunião (Information Request)Sequence subtopic parâmetros para a busca {
system: <Informe os parâmetros para a busca> (Contextual Information)subtopic Assunto {system: <assunto> (Information Request)user informs optionally: assunto (Domain Information)
}subtopic Data {system: <data> (Information Request)user informs optionally: data (Domain Information)
}subtopic Natureza {system: <natureza> (Information Request)user informs optionally: natureza (Domain Information)
}subtopic Participantes {system: <participantes> (Information Request)user informs optionally: participantes (Domain Information)
}}
Dialog Reuniões Encontradas (Selection)Sequence subtopic Escolha de Reunião {
system:<escolha dentre as reuniões encontradasou busque novamente> (Information Request)user_alternatives <reuniões encontradas>
Choice {user chooses: identificador da reunião (Domain Information)user initializes Busca por Reunião (Domain Information Request)
}}
Dialog Feedback sobre Reunião não encontrada (Feedback)Sequence {system: <Não foi encontrada nenhuma reunião> (Feedback)user initializes Busca por Reunião (Domain Information Request)
}
Dialog Seleção de Informação Aproveitável (Selection)Sequence {
system: <Informações que deseja aproveitar:> (Information Request)user alternatives: {natureza, assunto, norma, pauta, papéis,organizadores, participantes, listas de comunicação, local, prazo paraa definição da pauta, prazo para a definição da programação, prazopara a convocação, prazo para a confirmação da presença, prazo para olembrete, prazo para a aprovação da ata, prazo para a divulgação daata}
Choice {user chooses multiple: informações aproveitáveis
(Domain Information)user initializes Busca por Reunião (Domain Information Request)
}}
141
Dialog Seleção de Template (Selection)Sequence {
system: <selecione o template> (Information Request)user alternatives <templates>
user: identificador do template (Domain Information)}
Dialog Informação dos Atributos da Reunião (Domain Information)Sequence {
subtopic natureza {system: natureza (Domain Information)system: <natureza> (Information Request)user: natureza (Domain Information)
}subtopic assunto {system: assunto (Domain Information)system: <assunto> (Information Request)user: assunto (Domain Information)
}subtopic norma {system: norma (Domain Information)system: <norma> (Information Request)user informs optionally: norma (Domain Information)
}subtopic pauta {system: pauta> (Domain Information)system: <pauta> (Information Request)user: pauta (Domain Information)
}subtopic papéis {system: <papéis> (Apposition)system: papéis (Domain Information)user initializes: Informação de Papéis (Topic Change)
}subtopic organizadores {system: <organizadores> (Apposition)repetition {
system: organizador (Domain Information)system: papel do organizador (Domain Information)
}user initializes: Informação de Organizadores (Topic Change)
}subtopic participantes {system: <participantes> (Apposition)repetition {
system: participante (Domain Information)system: papel do participante (Domain Information)
}user initializes: Informação de Participantes (Topic Change)
}subtopic listas de comunicação {system: <listas de comunicação> (Apposition)repetition {
system: nome da lista de comunicação (Domain Information)}user initializes: Informação de Listas de Comunicação(Topic Change)
}
142
subtopic local {system: local (Domain Information)system: <local> (Information Request)user: local (Domain Information)
}subtopic data {system: data (Domain Information)system: <data> (Information Request)user: data (Domain Information)
}subtopic prazo para a definição da pauta {system: prazo para a definição da pauta (Domain Information)system: <prazo para a definição da pauta> (Information Request)user: prazo para a definição da pauta (Domain Information)
}subtopic prazo para a definição da programação {system: prazo para a definição da programação (Domain Information)system: <prazo para a definição da programação>(Information Request)user: prazo para a definição da programação (Domain Information)
}subtopic prazo para a convocação {system: prazo para a convocação (Domain Information)system: <prazo para a convocação> (Information Request)user: prazo para a convocação (Domain Information)
}subtopic prazo para a confirmação da presença {system: prazo para a confirmação da presença (Domain Information)system: <prazo para a confirmação da presença> (Information Request)user: prazo para a confirmação da presença (Domain Information)
}subtopic prazo para o lembrete {system: prazo para o lembrete (Domain Information)system: <prazo para o lembrete> (Information Request)user: prazo para o lembrete (Domain Information)
}subtopic prazo para a aprovação da ata {system: prazo para a aprovação da ata (Domain Information)system: <prazo para a aprovação da ata> (Information Request)user: prazo para a aprovação da ata (Domain Information)
}subtopic prazo para a divulgação da ata {system: prazo para a divulgação da ata (Domain Information)system: <prazo para a divulgação da ata> (Information Request)user: prazo para a divulgação da ata (Domain Information)
}}
Dialog Confirmação dos Atributos da Reunião (Operation Confirmation) {Sequence {
subtopic natureza {system: <natureza> (Apposition)system: natureza (Domain Information)
}subtopic assunto {system: <assunto> (Apposition)system: assunto (Domain Information)
}
143
subtopic norma {system: <norma> (Apposition)system: norma (Domain Information)
}subtopic pauta {system: <pauta> (Apposition)system: pauta (Domain Information)
}subtopic papéis {system: <papéis> (Apposition)system: papéis (Domain Information)
}subtopic organizadores {system: <organizadores> (Apposition)repetition {
system: organizador (Domain Information)system: papel do organizador (Domain Information)
}}subtopic participantes {system: <participantes> (Apposition)repetition {
system: participante (Domain Information)system: papel do participante (Domain Information)
}}subtopic listas de comunicação {system: <listas de comunicação> (Apposition)repetition {
system: nome da lista de comunicação (Domain Information)system: membros da lista de comunicação (Domain Information)
}}subtopic local {system: <local> (Apposition)system: local (Domain Information)
}subtopic data {system: <data> (Apposition)system: data (Domain Information)
}subtopic prazo para a definição da pauta {system: <prazo para a definição da pauta> (Apposition)system: prazo para a definição da pauta (Domain Information)
}subtopic prazo para a definição da programação {system: <prazo para a definição da programação>(Apposition)system: prazo para a definição da programação (Domain Information)
}subtopic prazo para a convocação {system: <prazo para a convocação> (Apposition)system: prazo para a convocação (Domain Information)
}subtopic prazo para a confirmação da presença {system: <prazo para a confirmação da presença> (Apposition)system: prazo para a confirmação da presença (Domain Information)
}
144
subtopic prazo para o lembrete {system: <prazo para o lembrete> (Apposition)system: prazo para o lembrete (Domain Information)
}subtopic prazo para a aprovação da ata {system: <prazo para a aprovação da ata> (Apposition)system: prazo para a aprovação da ata (Domain Information)
}subtopic prazo para a divulgação da ata {system: <prazo para a divulgação da ata> (Apposition)system: prazo para a divulgação da ata (Domain Information)
}subtopic criação de template {system: <deseja criar template> (Apposition)
user alternatives: {sim, não} user chooses: <criar template> (Domain Information)
}Choice {user initializes next causing persistence (Confirmation)user initializes previous causing persistence (Revision Request)
}}
Dialog Comunicação sobre Reunião (Communication)Sequence {
system: <as informações foram armazenadas com sucesso> (Feedback)system: <mensagem padrão sobre criação de reunião que deve ser
enviada aos outros organizadores> (Communication)system: <forma de comunicação desta mensagem> (Information Request)user initializes next causing termination (Confirmation)
}
Dialog Feedback sobre Envio de Comunicação (Feedback)Sequence subtopic Confirmação do Envio {
system: <a mensagem foi enviada com sucesso para> (Feedback)system: organizadores (Domain Information)
}
Dialog Informação sobre Envio Posterior (Feedback)operands opção que permite envio posteriorSequence subtopic Confirmação do Envio {system: <para enviar a comunicação posteriormente acesse a opção>
(Feedback)system: opção que permite envio posterior (Feedback)
}
6.2 Estudo de Caso 2: Utilização da LECI no Apoio àEspecificação de Aplicações Multi-Tecnologia
Para avaliar o potencial da LECI como ferramenta de apoio à especificação de
aplicações multi-tecnologia, procuramos especificar na linguagem versões de partes da
interação de aplicações para duas tecnologias distintas: (1) interface acessível via desktop,
baseada na web e (2) interface acessível via telefone comum, baseada em processamento de
voz. A escolha destes tipos de dispositivos deve-se aos seguintes motivos:
145
1. acreditamos que estes possuem capacidades extremamente diferentes de permissão
de troca de informação, no tempo, entre um usuário e uma aplicação
computacional;
2. acreditamos que dispositivos com diferentes capacidades de permitir troca de
informação requerem e/ou possibilitam interfaces com diferentes estruturas de
interação.
A figura 6.1 ilustra nossa crença de que o telefone comum e o desktop são dispositivos
com capacidades extremamente diferentes de permitir troca de informação entre usuário e
sistema. Ela se baseia nas seguintes considerações:
A capacidade de troca de informação permitida por um dispositivo é determinada pela
capacidade dos dispositivos de entrada e saída que o compõem. Quanto mais sofisticados
estes dispositivos, menores as restrições sobre a quantidade de informação que pode ser
trocada. Por exemplo, quanto maior o monitor, mais informação pode ser apresentada de uma
só vez. Se não há monitor, como no caso de um telefone comum, a apresentação de
informação ao usuário só pode se dar via voz, o que só pode ser feito de forma seqüencial,
limitando assim ao mínimo possível a quantidade de informação que pode ser apresentada em
um mesmo instante. Da mesma forma, quanto mais teclas tem um teclado, mais informação
pode ser fornecida pelo usuário de cada vez: em um teclado de um celular, onde cada tecla
pode representar até mesmo 3 ou mais caracteres, o usuário pode ter de pressionar até 3 vezes
a mesma tecla para informar ao sistema um único caracter, enquanto que um teclado padrão
acoplado a um desktop, ele só precisa pressionar uma única tecla para fornecer a mesma
informação.
Telefone Comum Celular Palm-Top Notebook Desktop
- capacidade de permitir troca de informação de cada vez +baixa alta
Figura 6.1: capacidade que os dispositivos têm de permitir troca de informação de cada vez.
Acreditamos que a utilização da LECI pode apoiar o designer na especificação de
aplicações multi-tecnologia pois permite que ele represente, na mesma linguagem, versões de
modelos de interação de uma mesma aplicação para diferentes tecnologias. A visualização de
dois ou mais modelos de interação na mesma linguagem, devidamente semantizada em algum
146
sistema subjacente (no caso da LECI, o modelo proposto para a especificação de cenários de
interação, apresentado no capítulo 3) presta grande apoio à comparação entre eles. A partir
desta visualização, o designer pode analisar mais facilmente quais são as diferenças entre os
modelos. Utilizando a LECI como ferramenta para a modelagem da interação, o designer
pode realizar uma análise da conversa entre usuário e sistema em diferentes ambientes
tecnológicos. Assim, ao invés de comparar, por exemplo, widgets de interfaces acessíveis via
desktop com pressionamentos de tecla e processamento de voz em interfaces acessíveis via
telefone, o designer pode comparar diálogos, tópicos, contextos de interação e todos os
elementos da conversa usuário-sistema que a LECI permite caracterizar para os dois
ambientes.
Visualizando na mesma linguagem de representação, diferentes versões tecnológicas
de modelos de interação de uma mesma aplicação, o designer pode aplicar regras, baseadas
em seu conhecimento e experiência, para decidir que partes destes modelos ele pode e quer
manter invariantes, definindo assim o que é o coração da aplicação, que estará presente em
qualquer ambiente e o que deve ser possibilitado apenas em determinados ambientes. Isto
facilitaria a manutenção da consistência entre versões de uma mesma aplicação para
tecnologias distintas, o que permitiria que usuários que a usem em diferentes ambientes, ao
acessá-la em um destes ambientes, possam importar conhecimentos deste uso para quando a
acessem em outro ambiente.
Exemplificaremos a seguir, algumas das decisões relevantes ao design de aplicações
multi-tecnologia que podem ser tomadas e representadas pelo designer com o apoio da LECI.
6.2.1 O designer pode decidir se quer manter os mesmos subtópicos
Conhecendo as restrições sobre a quantidade de informação que deve ser comunicada
em diferentes ambientes, o designer pode decidir o que comunicar nestes ambientes,
considerando quais subtópicos são essenciais e deverão ser sempre abordados e quais só
serão abordados dependendo da tecnologia. Para exemplificar, imagine que um designer de
um Sistema Gerenciador de Bibliotecas queira especificar, para interfaces acessíveis via
telefone e desktop, um diálogo onde o sistema apresenta informações sobre um livro ao
usuário. São diversas as informações que caracterizam um livro (título, autores, etc), cada
uma representa um subtópico do tópico livro. Conhecendo as restrições sobre a quantidade de
informação que deve ser comunicada em uma aplicação acessível via telefone e a natureza
147
quase irrestrita do desktop, o designer pode determinar que subtópicos considera essenciais e
definir que devem ser abordados nos dois ambientes e ao mesmo tempo aproveitar a
capacidade do desktop para abordar outros subtópicos de interesse, que se abordados via
telefone, tornariam o diálogo denso. Esta análise poderia resultar nas seguintes especificações:
Especificação da interação para Desktop
Dialog Apresentação de Informação sobre Livro(Domain Information Presentaion)
Sequence {subtopic Título {
system: <Título> (Apposition)system: Título (Domain Information)
}subtopic Autores {
system: <Autores> (Apposition)system: Autores (Domain Information)affords: user initializes
Informação Sobre Autores (Information Request)}subtopic Assunto {
system: <Assunto> (Apposition)system: Assunto (Domain Information)affords: user initializes
Publicações sobre Assunto (Information Request)}subtopic Palavras-Chave {
system: <Palavras-Chave> (Apposition)system: Palavras-Chave (Domain Information)affords: user initializes
Publicações associadas a Palavras-Chave (Information Request)}subtopic Resumo {
system: <Resumo> (Apposition)system: Resumo (Domain Information)
}subtopic Ano de Publicação {
system: <Ano de Publicação> (Apposition)system: Ano de Publicação (Domain Information)
}subtopic Edição {
system: <Edição> (Apposition)system: Edição (Domain Information)
}subtopic Editora {
system: <Editora (Apposition)system: Editora (Domain Information)
}}
148
Especificação da interação para Telefone
Dialog Apresentação de Informação sobre Livro(Domain Information Presentaion)
Sequence {subtopic Título {
system: <Título> (Apposition)system: Título (Domain Information)
}subtopic Autores {
system: <Autores> (Apposition)system: Autores (Domain Information)
}subtopic Assunto {
system: <Assunto> (Apposition)system: Assunto (Domain Information)
}subtopic Palavras-Chave {
system: <Palavras-Chave> (Apposition)system: Palavras-Chave (Domain Information)
}}
Neste exemplo foram mantidos invariantes os subtópicos Título, Autores, Assunto e
Palavras-chave. Já os subtópicos Resumo, Edição, Ano de Publicação e Editora, apesar de
serem informações de interesse, não foram considerados essenciais e foram omitidos da
interação com o telefone. Observe que a ordem dos subtópicos invariantes foi mantida,
visando aproximar-se as duas versões tecnológicas.
6.2.2 O designer pode decidir se quer manter os mesmos diálogos econtextos de interação
Considere a tarefa Criar Reunião do Qualitas, descrita na seção 6.1. Ao definir a
interação acessível via desktop, o designer pode disponibilizar os três métodos de criação
mencionados: criação a partir de reunião existente, criação a partir de template de reunião e
criação a partir do zero. Considerando que (1) quando houver muitas reuniões cadastradas,
apresentar as informações que as caracterizem, para que o usuário selecione uma como base,
pode ser extremamente ineficiente via telefone e que (2) o número de templates de reunião
será provavelmente bem menor; o designer pode decidir disponibilizar por telefone apenas a
criação por template ou a criação a partir do zero. Assim, diálogos e contextos de interação
relacionados à seleção de reunião, assim como o contexto de interação que representa que a
nova reunião deve ser criada a partir de uma reunião existente, só seriam necessários para a
interação via desktop. Desta forma, teríamos as seguintes especificações da tarefa na LECI:
149
Especificação da interação para Desktop
Task Criar Reunião (Creation)Sequence {
Dialog Seleção do Método de Criação da Reunião (Selection)Exclusive-Contexts {When context is criacao_a_partir_de_reuniao_existente {
Dialog Seleção de Reunião (Selection)When context is usuario_realiza_busca {Repetition {
Dialog Busca por ReuniãoExclusive-Contexts {When context is reuniao_nao_encontrada {Dialog Feedback sobre Reunião não encontrada (Feedback)
}When context is mais_de_uma_reuniao_encontrada {Dialog Reuniões Encontradas (Selection)
}}
}}Dialog Seleção de Informação Aproveitável (Selection)
}When context is criacao_a_partir_de_template {
Dialog Seleção de Template (Selection)Dialog Seleção de Informação Aproveitável (Selection)
}}include(Informar Atributos da Reunião, {“Criar Reunião”})
}
Especificação da interação para Telefone
Task Criar Reunião (Creation)Sequence {
Dialog Seleção do Método de Criação da Reunião (Selection)When context is criacao_a_partir_de_template {
Dialog Seleção de Template (Selection)Dialog Seleção de Informação Aproveitável (Selection)
}include(Informar Atributos da Reunião, {“Criar Reunião”})
}
Os diálogos e contextos de interação, referenciados na especificação desktop em
sentenças com fundo cinza, são os que não foram mantidos na especificação da interação para
telefone.
6.2.3 O designer pode decidir se quer manter a seqüência da interação
Ainda que um designer decida manter os mesmos subtópicos, diálogos e contextos de
interação em diferentes ambientes, ele pode decidir definir seqüências distintas para a
ocorrência dos diálogos e subtópicos, de acordo com as restrições e facilidades de cada
ambiente. Por exemplo, consideremos a tarefa Editar Reunião, do Qualitas. A realização
150
desta tarefa requer que sistema e usuário conversem sobre diversos atributos da reunião: data,
hora, assunto, participantes, organizadores, listas de comunicação, etc. Alguns destes atributos
são mais complexos que outros e o designer pode optar por definir que sejam abordados em
subdiálogos a parte. Por exemplo, ao informar quem são os organizadores e participantes, o
usuário também deve informar quais são seus papéis, podendo escolher um papel já
cadastrado no sistema ou ainda criar um novo papel, para o qual terá que fornecer a descrição
e etc. Tanto o diálogo principal como os eventuais subdiálogos abordam informações
essenciais a tarefa e devem estar presentes em qualquer ambiente. A interação no telefone é
restrita à seqüência, ainda que sua ordem possa ser determinada por escolhas do usuário. Já o
desktop permite que o diálogo principal e qualquer dos subdiálogos sejam ao menos
percebidos simultaneamente. Assim, um designer poderia optar por definir para o telefone
que primeiro deve ser travado o diálogo principal e depois cada um dos subdiálogos que
abordam os tópicos mais complexos. Para o desktop, o designer poderia definir que a partir do
diálogo principal, o usuário tem a opção de iniciar, a qualquer hora, qualquer dos referidos
subdiálogos e que, o diálogo principal sempre se manterá persistente. As seguintes
especificações representariam estas decisões na LECI:
Especificação da interação para Desktop
Task Editar Reunião (Editing)Sequence {
Dialog Seleção de Reunião (Selection)Dialog Informação dos Atributos da Reunião (Domain Information)Dialog Confirmação dos Atributos da Reunião (Operation Confirmation)Dialog Comunicação sobre Reunião (Communication)Exclusive-Contexts {When Context is mensagem_sera_enviada_imediatamente {
Dialog Feedback sobre Envio de Comunicação (Feedback)}When Context is mensagem_sera_enviada_posteriormente {
Dialog Informação sobre Envio Posterior (Feedback)}
}}
Trecho do diálogo Informação dos Atributos da Reunião
Dialog Informação dos Atributos da Reunião (Domain Information)Sequence {
. . .subtopic papéis {system: <papéis> (Apposition)system: papéis (Domain Information)user initializes: Informação dos Papéis (Topic Change)
}
151
subtopic organizadores {system: <organizadores> (Apposition)repetition {
system: organizador (Domain Information)system: papel do organizador (Domain Information)
}user initializes: Informação dos Organizadores (Topic Change)
}subtopic participantes {system: <participantes> (Apposition)repetition {
system: participante (Domain Information)system: papel do participante (Domain Information)
}user initializes: Informação dos Participantes (Topic Change)
}subtopic listas de comunicação {system: <listas de comunicação> (Apposition)repetition {
system: nome da lista de comunicação (Domain Information)}user initializes: Informação das Listas de Comunicação (Topic Change)
}. . .
}
Especificação da interação para Telefone
Task Editar Reunião (Editing)Sequence {
Dialog Seleção de Reunião (Selection)Dialog Informação dos Atributos da Reunião (Domain Information)Dialog Confirmação dos Atributos da Reunião (Operation Confirmation)Dialog Informação dos Papéis (Domain Information)Dialog Confirmação dos Papéis (Operation Confirmation)Dialog Informação dos Organizadores (Domain Information)Dialog Confirmação dos Organizadores (Operation Confirmation)Dialog Informação dos Participantes (Domain Information)Dialog Confirmação dos Participantes (Operation Confirmation)Dialog Informação das Listas de Comunicação (Domain Information) Dialog Confirmação das Listas de Comunicação (Operation Confirmation)Dialog Comunicação sobre Reunião (Communication)Exclusive-Contexts {When Context is mensagem_sera_enviada_imediatamente {
Dialog Feedback sobre Envio de Comunicação (Feedback)}When Context is mensagem_sera_enviada_posteriormente {
Dialog Informação sobre Envio Posterior (Feedback)}
}}
As sentenças que ilustram diferenças entre as seqüências dos diálogos nas
especificações para os dois ambientes tecnológicos estão sinalizadas com fundo cinza.
Observe que o diálogo Confirmação dos Atributos da Reunião da especificação para o
Desktop equivale à união do diálogo Confirmação dos Atributos da Reunião da
152
especificação para o telefone com os outros diálogos menores desta especificação, que têm
semântica de Confirmação de Operação. Entretanto, estes diálogos não aparecem
consecutivamente ao fim da estrutura da tarefa, de forma a evidenciar esta equivalência. Ao
contrário, optou-se por defini-los sempre após o diálogo com semântica de Fornecimento de
Informação Referente ao Domínio, cujos subtópicos são os mesmos do diálogo de
confirmação.
6.2.4 Conclusões a Partir do Estudo de Caso
Nos exemplos apresentados, a LECI permitiu a representação de versões de parte da
interação de aplicações, para diferentes ambientes tecnológicos, sem perda de expressividade.
O estudo indica que a representação permitida pela LECI pode apoiar o trabalho do designer,
trazendo insights sobre as diferenças entre os tipos de conversa usuário-sistema mais
adequadas à ambientes tecnológicos distintos e conseqüentemente, facilitando a sua tomada
de certas decisões, que uma vez tomadas, também podem ser representadas na LECI. As
decisões são tomadas com base na aplicação de restrições, como por exemplo, restringir que
nos vários ambientes tecnológicos alternativos necessariamente deve-se manter o aspecto X
(X pode ser um conjunto de diálogos, subtópicos, contextos de interação, seqüências, etc). Por
enquanto estas restrições estão somente na cabeça do designer e dependem de seu
conhecimento e experiência de design. Ainda assim, a LECI permite que ele visualize lado a
lado versões tecnológicas de modelos de interação de uma mesma aplicação, na mesma
linguagem, facilitando a aplicação destas restrições. Futuramente, a utilização da LECI poderá
trazer ainda mais apoio à aplicação de restrições para a tomada de decisão do designer. Uma
vez que se tem uma linguagem semi-formal como a LECI, é possível definir-se parsers que
trabalhem com conjuntos de regras. Se for definido, por exemplo, um conjunto de regras que
indiquem padrões de equivalência e/ou similaridade entre ambientes tecnológicos distintos e
entre um mesmo ambiente, estas regras auxiliariam o designer a modelar aplicações para uma
nova tecnologia T2 de forma consistente com um modelo da mesma aplicação previamente
especificado para uma outra tecnologia T1.
A LECI permite a especialização da interação para tipos de tecnologia distintos,
seguindo-se diferentes critérios no que diz respeito ao que será o invariante de uma mesma
aplicação em diferentes ambientes tecnológicos. Ou seja, o objetivo do design de uma mesma
aplicação em diferentes ambientes tecnológicos não é que cada versão seja idêntica às demais.
153
Ao contrário, é imprescindível que o designer esteja atento às diferentes restrições e
oportunidades de cada ambiente. O objetivo é ter ao menos uma parte do modelo invariante, o
que ajudará os usuários a se darem conta, em cada ambiente, de que estão interagindo com
uma aplicação cuja identidade conhecem e a tomarem as decisões certas sobre como agir em
cada ambiente e quando trocar de ambiente porque o atual não é o adequado para o que
querem fazer. Nossa proposta possibilita que o designer eleja o que vai constituir a marca
constante do seu design em qualquer ambiente, e que a partir deste momento, especifique as
diversas versões em conformidade com esta escolha.
6.3 Estudo de Caso 3: Análise Comparativa entre a LECI e a LEMD
Nesta seção realizamos uma análise comparativa entre a LECI e a LEMD, com o
objetivo de ilustrar nossas motivações para a decisão de criar uma nova linguagem, ao invés
de adaptar a LEMD. A análise está estruturada da seguinte maneira: para cada tipo de
informação que deve ser especificada para se representar os cenários de interação descritos na
seção 6.1 analisamos se ela pode ser especificada na LEMD e se mesmo quando isto é
possível, há vantagens em fazê-lo na LECI.
6.3.1 Especificação de Papéis de Usuário e Restrições de Acesso a Funções
Os papéis de usuário e as restrições de acesso a funções identificados a partir do
cenário não poderiam ser representados na LEMD. E nem deveriam poder. A LEMD foi
proposta para a especificação de aplicações mono-usuário e desta forma não está em seu
escopo permitir a especificação de papéis de usuário e das restrições de acesso a funções da
aplicação dependentes destes papéis.
6.3.2 Especificação de Conceitos da Aplicação
Os conceitos da aplicação referenciados nos cenários poderiam ser representados na
LEMD como signos do domínio. A vantagem de se representá-los na LECI é que ela permite
separar conceitos do domínio original de conceitos introduzidos com a tecnologia, como por
exemplo, o conceito método de criação da reunião. Este conceito só existe porque o sistema
permite que o usuário cadastre informações sobre uma reunião e decida se quer ou não obter
automaticamente valores iniciais para elas a partir de dois tipos de fontes.A vantagem de se
separar conceitos do domínio original, dos introduzidos é que isto pode aumentar a
154
consciência do designer sobre os conceitos potencialmente menos conhecidos, auxiliando-o
no planejamento do sistema de help.
6.3.3 Especificação da Estrutura da Tarefa
As estruturas das tarefas descritas nos cenários podem ser representadas na LEMD
através de mensagens de tarefas. Enquanto as tarefas da LECI são estruturadas em termos de
diálogos, as mensagens de tarefa da LEMD são estruturadas em termos de comandos de
função. Embora não haja na LEMD um construto próprio para a representação dos contextos
de interação identificados a partir dos cenários apresentados, é possível representar uma única
tarefa através de diversas mensagens de tarefa (task-message) e utilizar a nomenclatura
destas mensagens para associar cada uma delas a um diferente curso possível para a tarefa.
Por exemplo, a seguir apresentamos 3 mensagens de tarefa que seriam necessárias para
especificar apenas alguns dos cursos possíveis para a tarefa “Criar Reunião”, após a decisão
do usuário de criar a reunião a partir de uma reunião existente. As diferenças entre as
mensagens, que caracterizam os diferentes cursos estão representadas com fundo cinza.
Task-Message Criar Reunião a partir de uma das N últimas Reuniões {Sequence {
Command Seleção do Método de Criação da ReuniãoCommand Seleção de ReuniãoCommand Seleção de Informação Aproveitável Command Informação dos Atributos da Reunião Command Confirmação dos Atributos da Reunião Command Comunicação da Criação da ReuniãoCommand Feedback: Envio de Comunicação sobre Nova Reunião
}}
Task-Message Criar Reunião a partirda única Reunião Encontrada Após Busca {
Sequence {Command Seleção do Método de Criação da ReuniãoCommand Seleção de ReuniãoCommand Busca por ReuniãoCommand Seleção de Informação Aproveitável Command Informação dos Atributos da Reunião Command Confirmação dos Atributos da Reunião Command Comunicação da Criação da ReuniãoCommand Feedback: Envio de Comunicação sobre Nova Reunião
}}
Task Criar Reunião a partir de uma de N Reuniões Encontradas Após Busca {Sequence {
Command Seleção do Método de Criação da ReuniãoCommand Seleção de ReuniãoCommand Busca por Reunião
155
Command Reuniões Encontradas Command Seleção de Informação Aproveitável Command Informação dos Atributos da Reunião Command Confirmação dos Atributos da Reunião Command Comunicação da Criação da ReuniãoCommand Feedback: Envio de Comunicação sobre Nova Reunião
}}
Para representar na LEMD todos os cursos possíveis para a tarefa, seria necessário
especificar ainda muitas outras mensagens de tarefa. Apesar disto, há uma vantagem deste
tipo de especificação em relação a especificação LECI apresentada na seção 6.1: ela permite
visualizar de forma mais clara os passos de cada curso de interação. Convém notar, entretanto,
que este tipo de especificação também pode ser realizado na LECI.
As vantagens de se especificar a tarefa na LECI, através de contextos de interação,
são: maior clareza da estrutura geral da tarefa e o reuso de passos comuns a cursos de
interação distintos. Na especificação LEMD apresentada, os comandos de função Seleção de
Reunião, Seleção de Informação Aproveitável e diversos outros são referenciados em todas
as mensagens de tarefa definidas e o teriam de ser nas outras mensagens necessárias para a
especificação de todos os cursos de interação possíveis para a tarefa. Na LECI, conforme
apresentado na seção 6.1, a estrutura desta tarefa é única e os passos comuns a dois ou mais
cursos de interação são representados uma única vez, facilitando a manutenção da
especificação. Modificações na estrutura da tarefa na LEMD, poderiam acarretar mudanças
na estrutura de diversas mensagens de tarefa enquanto que na LECI, apenas em uma estrutura
de tarefa.
Outra vantagem de se realizar a especificação da estrutura das tarefas descritas na
seção 6.1 na LECI, ao invés de na LEMD, é que a primeira permite não só o reuso de passos
comuns a cursos de interação distintos de uma mesma tarefa, mas também de passos comuns
a tarefas distintas. O reuso dos passos comuns às tarefas “Criar Reunião” e “Editar Reunião”
ilustrado na seção 6.1, não pode ser feito na LEMD. Ao invés disso, é necessário repetir estes
passos na especificação de várias das mensagens de tarefa necessárias para a representação de
cada tarefa.
6.3.4 Especificação das Estruturas dos diálogos
As estruturas dos diálogos componentes das tarefas descritas nos cenários podem ser
representadas na LEMD através de mensagens de comando. Enquanto os diálogos da LECI
156
são estruturados em termos de enunciados de usuário e de sistema, as mensagens de comando
da LEMD são estruturadas em termos de interações básicas de usuário e visualizações. Da
mesma forma que para a especificação de contextos de interação distintos para uma mesma
tarefa na LEMD é necessário especificar mensagens de tarefa distintas, para a especificação
de contextos distintos para um mesmo diálogo é necessária a especificação de mensagens de
comando distintas. Esta forma de especificação apresenta vantagens e desvantagens análogas
às apresentadas pela forma de especificação de tarefas na LEMD em relação à forma de
especificação na LECI: permite visualizar de forma mais clara os enunciados que ocorrem
em cada curso, mas enunciados comuns têm de ser repetidos nas especificações de cursos
distintos, dificultando a manutenção destas especificações.
6.3.5 Apoio à Especificação de Aplicações Multi-Tecnologia
Como vimos no estudo de caso apresentado na seção 6.2, a LECI apóia a especificação
de aplicações multi-tecnologia ao permitir a representação de modelos de interação de uma
mesma aplicação, que abstraem diferentes tecnologias de implementação. A visualização
destas representações pode auxiliar o designer a analisar as diferenças entre as tecnologias e a
tomar decisões com respeito a que partes da interação devem ser comuns a qualquer
tecnologia e que partes são mais adequadas para cada uma delas. Além disso, as cláusulas
Exclusive-Technologies e when technology is permitem que o designer destaque
explicitamente em seu modelo de interação, os componentes dependentes de tecnologia. A
LEMD não permite estes tipos de apoio ao design de aplicações multi-tecnologia e nem há
razão para que ela o faça, pois esta linguagem foi desenvolvida com o objetivo de abstrair
interfaces WIMP e desta forma, auxiliar o designer a especificar aplicações multi-tecnologia
não está em seu escopo.
6.3.6 Conclusões sobre a Análise Comparativa
Pelo fato de a LECI ter surgido a partir de adaptações propostas à LEMD, muitas das
informações representáveis na LECI também podem ser representadas na LEMD e estas
representações são equivalentes. Ambas as linguagens foram definidas seguindo o paradigma
da comunicação usuário sistema, a diferença está na forma como representam está
comunicação. A LEMD foi definida para abstrair interfaces WIMP e desta forma, representa a
comunicação entre usuário e sistema através de visualizações e ações de usuário
157
(Fornecimento de caracteres, Seleção de Informação e Acionamento). A LECI representa esta
comunicação como conversa, composta por enunciados de usuário e de sistema.
Entretanto, a comparação entre a especificação de cenários de interação na LECI e na
LEMD, apresentada neste capítulo, sugere que a LECI apresenta algumas vantagens em
relação a LEMD, para a especificação daquilo que se propõe: cenários de interação abstratos
instanciáveis em diferentes tecnologias. Isto era de se esperar, sendo devido às diferenças de
escopo das duas linguagens. Uma vantagem são os mecanismos que facilitam a manutenção
da especificação em relação a especificações LEMD: os contextos de interação e inclusão de
templates de tarefas e diálogos. Como a LECI foi criada com o objetivo de permitir a
especificação de cenários de interação, diferentemente da LEMD, nos inspiramos na estrutura
de especificação de casos de uso proposta por Jacobson [Jacobson, 1995] e introduzimos estes
mecanismos de reuso na linguagem. Outra vantagem é que a LECI permite a especificação de
papéis de usuário e restrições de acesso a funções dependentes de papéis. Isto se deve ao fato
de que a LECI foi definida a partir do estudo de aplicações multi-usuário e com o objetivo de
suportar a especificação deste tipo de aplicação, ao contrário da LEMD.
Por fim, a grande vantagem da LECI em relação à LEMD, considerando-se os
objetivos a que se propõe, é que enquanto a LEMD foi desenvolvida com o objetivo de apoiar
a especificação de interfaces com a tecnologia específica WIMP, a LECI permite apoiar o
design de aplicações multi-tecnologia.
158
Capítulo 7
Conclusões
Neste capítulo apresentamos as conclusões deste trabalho. Na seção 7.1 apresentamos
suas contribuições e limitações e na seção 7.2, discutimos algumas oportunidades para
trabalhos futuros.
7.1 Contribuições e Limitações
Neste trabalho, procuramos contribuir para o estabelecimento de modelos e
ferramentas de apoio ao design de interação de qualidade. Seguindo a abordagem da
Engenharia Semiótica, nosso objetivo foi definir um modelo que auxiliasse designers a
especificar cenários de interação como parte de sua mensagem para os usuários. Motivados
pelo fato de que, apesar do constante surgimento de novas tecnologias, os modelos existentes
privilegiam tecnologias específicas, procuramos especificar um modelo que permitisse o
aproveitamento de especificações pré-existentes ao se desenvolver uma mesma aplicação para
diferentes ambientes tecnológicos. Nas próximas seções, descreveremos as contribuições
deste trabalho na direção de seus objetivos e também suas limitações.
7.1.1 Modelo para a Especificação de Cenários de Interação
O modelo proposto para a especificação de cenários de interação contribui para apoiar
designers nesta especificação ao identificar que informações devem ser especificadas e como
elas devem ser estruturados. O modelo permite a caracterização da interação como conversa
travada entre usuário e sistema, estruturando a interação em termos de tarefas, diálogos e
enunciados. Acreditamos que a conversa pode caracterizar a execução de um sistema
computacional interativo, independentemente da tecnologia de implementação da interface,
pois, na verdade, esta execução consiste sempre na troca de informações entre este sistema e
o(s) usuário(s). Assim, consideramos que esta proposta tem potencial para permitir o
aproveitamento de especificações pré-existentes, em diferentes ambientes tecnológicos. A
maior contribuição do modelo proposto foi ter servido de base para a definição de uma
linguagem para a especificação de cenários de interação que acreditamos contribuir para o
alcance dos objetivos deste trabalho (veja a próxima seção). O modelo pode ainda ser usado
por outros pesquisadores como base para a definição de outros formalismos.
159
Em linha com os objetivos da Engenharia Semiótica, o modelo suporta a associação de
tipos semânticos a tarefas, diálogos e enunciados, com o objetivo de auxiliar designers a
conscientizar-se sobre suas intenções de comunicação. Para auxiliá-los na expressão destas
intenções, o modelo sugere templates para o mapeamento entre os tipos semânticos.
Entretanto, estes templates não podem ser considerados padrões, tendo sido definidos com
base em “bom senso” e experiência de design. Se fazem necessários estudos experimentais
para avaliar sua qualidade.
Convém mencionar que o modelo não considera aspectos relacionados a evolução de
cenários nem à especificação de aplicações que suportem End User Programming
[Myers, 1992] e tão pouco suporta End User Designing.
7.1.2 Linguagem para a Especificação de Cenários de Interação
Foi definida uma linguagem para a especificação de cenários de interação (LECI) com
base no modelo proposto. Inicialmente, procuramos adaptar a LEMD, formalismo proposto
por Leite [Leite, 1998] para a especificação de modelos de usabilidade. Entretanto, conforme
ilustrado pela análise comparativa entre as duas linguagens, apresentada no capítulo 6, este
formalismo não se mostrou adequado aos objetivos deste trabalho; justamente por ter escopo
bastante diferente do escopo da LECI.
No capítulo 6, apresentamos também um estudo de caso que ilustra a grande
contribuição da LECI: ela pode apoiar o designer na especificação de aplicações multi-
tecnologia, auxiliando-o a tomar decisões com respeito às partes de seu modelo de interação
que devem ser comuns a qualquer tecnologia e às que são mais adequadas para tecnologias
específicas. Além disso, as cláusulas Exclusive-Technologies e when technology is
permitem que o designer destaque explicitamente em seu modelo de interação os
componentes dependentes de tecnologia.
Inserção de nosso trabalho na classificação realizada em [Rolland et al., 1996]
Como o modelo proposto neste trabalho trata de uma abordagem para a especificação
de cenários de interação, convém situá-lo no contexto de outras abordagens que utilizam
cenários. Desta forma, tentaremos classificá-lo utilizando o frameork proposto em
160
[Rolland et al., 1996] para a classificação de abordagens que utilizam cenários, o qual foi
mencionado no capítulo 2.
Por propor a especificação de cenários através da LECI, nosso trabalho tem o meio
classificado como textual e a notação como Semi-Formal (semi pois a especificação dos
contextos de interação é livre), além de não possuir qualquer animação ou interatividade.
A abstração do modelo proposto é a nível de tipo, pois ele só permite especificar tarefas e
atores de forma genérica (ex. “editar publicação” ao invés de “editar o livro Human Computer
Interaction”; “bibliotecário” ao invés de “João”). Quanto ao contexto, representamos somente
os de “Interação com Usuário” e “Organizacional”, através dos componentes contexto de
interação e papel de usuário, respectivamente. O modelo não representa argumentação, pois
propõe a utilização de cenários apenas com papel descritivo. Quanto à cobertura funcional, o
modelo representa estrutura, através da decomposição de tarefas em diálogos e de diálogos
em enunciados e comportamento, através do próprio modelo de interação que permite
representar. Quanto à cobertura intencional, são representadas metas, através de semânticas
de tarefas, diálogos e enunciados e responsabilidades, através do componente papel de
usuário. Quanto à cobertura não-funcional, o modelo representa tratamento de erros, através
dos componentes estratégia de tratamento de erros de usuário e estratégia de tratamento de
falhas de sistema e suporte ao usuário, através de enunciados e diálogos com semântica de
help. Finalmente, quanto ao ciclo de vida, os cenários representáveis em nossa abordagem são
persistentes, pois não há controle de evolução. Das operações consideradas por Rolland et al.,
nosso modelo possibilita o refinamento (o termo é utilizado por ele com o sentido de reuso).
Este é possibilitado, através de herança de papéis, relações entre contextos de interação e
principalmente templates de diálogos e de tarefas.
A inserção de nossa abordagem na classificação de Rolland et al. está ilustrada na
tabela 7.1.1 A tabela mostra que nosso modelo não apresenta as seguintes facilidades
presentes em alguns dos outros modelos relacionados:
• Apresentação de cenários através de gráficos, protótipo, animação e/ou hipertexto;
1 Conforme mencionamos no capítulo 2, o trabalho de Rengell et al. propõe a especificação de cenários em dois níveis de abstração (descrição e especificação). Desta forma,
quando o valor de um atributo não é o mesmo para os dois níveis, são apresentados dois valores. O primeiro se refere ao nível de descrição e o segundo ao nível de
especificação. Por exemplo, tempo de vida “Transiente e Persistente” significa que os cenários do nível de descrição são transientes e os do nível de especificação são
persistentes.
161
• Abstração a nível de Instância;
• Representação do contexto interno do sistema e de alguns aspectos de cobertura
funcional, intencional e não funcional;
• Representação do contexto do ambiente organizacional;
• Exploração e documentação de argumentação e explicação;
• Operações para controle de evolução de cenários.
Outras formas de apresentação de cenários, assim como a abstração a nível de
instância, poderiam ser vantajosas, sobretudo se o modelo proposto for utilizado para design
participativo (Participatory Design) [Muller, 1991], onde os cenários são feitos pelos usuários
ou com o seu auxílio. Entretanto, um certo cuidado deve ser tomado para não se perder a
abstração. Por exemplo, um protótipo deve representar uma conversa entre usuário e sistema,
não uma interface propriamente dita.
A representação do contexto interno do sistema e de alguns dos aspectos de cobertura
funcional (função) e não funcional (performance, restrições de design, de tempo e de custo),
representados em outras abordagens, está totalmente fora dos objetivos deste trabalho. Nossa
meta não é modelar o comportamento interno e funcional do sistema e sim seu
comportamento externo e interativo, que é enxergado pelo usuário.
A representação de aspectos intencionais não tomados em conta (Dependência de
Meta e Oportunidade) pode ser considerada.
A representação do contexto do ambiente organizacional tem extrema importância
durante a fase de análise de requisitos e também quando se deseja utilizar cenários com papel
exploratório e explanatório. Nosso modelo é voltado para a fase de especificação, quando já
se fez uma primeira análise e se quer descrever a semântica da aplicação que deve expressa
através da interface. Entretanto, ao se estender o modelo proposto para permitir a utilização de
cenários com papel exploratório e explanatório, seria de grande utilidade a representação de
informações sobre o ambiente organizacional. Apesar de o estado atual do modelo não
possibilitar documentação de argumentação e explicação, o conjunto de templates poderia ser
estendido, incorporando-se a ele templates alternativos e regras de seleção que seriam uma
forma de permitir esta representação.
162
Por fim, a evolução de cenários é um dos aspectos que mais traria benefícios a
abordagem proposta neste trabalho e desta forma, será discutido em maiores detalhes na seção
7.2.4.
Convém observar, que apesar de não possuir algumas das facilidades presentes em
outros modelos apresentados na tabela, nosso modelo possui características que só estão
presentes em poucos dos outros 11 modelos classificados. Somente nosso modelo e o modelo
proposto por Scalzo apresentam cobertura não funcional de tratamento de erro. Suporte ao
Usuário é representado somente nestes dois modelos e no modelo de Kyng.
Outra importante observação, possível através da análise da tabela, é que o modelo
proposto parece ter muitos pontos em comum com modelos que também utilizam cenários
somente com papel descritivo: nenhum destes modelos representa argumentação, a maioria
deles não representam os contextos internos do sistema e do ambiente organizacional, são
persistentes e suportam poucas operações para controle de evolução de cenários.
Face
taAt
ribut
o[B
enne
r et
al.,
1992
][D
ahis
,20
01]
[Gou
gh e
tal
., 19
95]
[Hsi
a et
al.,
1994
][H
olbr
ook,
1990
][J
acob
son
et a
l.,19
92]
[Kyn
g,19
95]
[Pot
ts e
tal
.,199
4][R
egne
ll et
al.,
1995
][R
umba
ugh
et a
l., 1
991]
[Sca
lzo,
199
5][S
omé
etal
., 19
96]
Mei
o (1
){T
, I, P
}{T
}{T
, I, P
}{T
}{T
, I}
{T}
{T, P
}{T
}{T
, I}
{T, G
}{T
, G}
{T}
Desc
rição
Nota
ção
(2)
Qua
lque
rS-
FI
FI
II
S-F
S-F
S-F
S-F
S-F
Anim
ação
(3)
Qua
lque
rF
VF
VF
VF
FF
FF
F O R M AAp
rese
ntaç
ãoIn
tera
tivid
ade
Qua
lque
rN
enhu
ma
Hip
erte
xto
Nen
hum
aH
iper
text
oN
enhu
ma
Hip
erte
xto
Hip
erte
xto
Nen
hum
aN
enhu
ma
Nen
hum
aN
enhu
ma
Inst
ânci
a (3
)V
FF
VV
VV
VF
FV
FTi
po (3
)V
VV
VV
VV
VV
VV
VAb
stra
ção
Mis
ta (3
)V
FF
FV
FV
VF
FV
FIn
tern
o ao
Sis
t. (3
)V
FF
FF
FV
VV
FV
VIn
tera
ção
com
Usuá
rio (3
)V
VV
VV
VV
VV
VV
V
Cont
exto
Org
aniz
acio
nal (
3)V
VF
FV
FV
VF
FV
FCo
ntex
to
Ambi
ente
Org
aniz
acio
nal (
3)V
FF
FF
FF
FF
FF
F
Posi
ção
(3)
VF
FF
FF
VF
FF
VF
Argu
men
tos
(3)
VF
FF
VF
VF
FF
VF
Que
stõe
s (3
)V
FF
FV
FV
FF
FV
FAr
gum
enta
ção
Deci
sões
(3)
VF
FF
VF
FF
FF
FF
Func
iona
l (4)
{E, F
, C}
{E, C
}{E
, F, C
}{C
}{F
, C}
{E,F
,C}
{E,F
,C}
{E,F
,C}
{E, C
, F}
{E,F
,C}
{E,F
,C}
{E, C
}In
tenc
iona
l (5)
{ }{M
, R}
{ }{ }
{M, D
M}
{}(M
, R)
{}{M
, R}
{ }{M
, R, O
}{ }
C O N T E Ú D O
Cobe
rtura
Não-
Func
iona
l (6)
{ }{T
E, S
U}
{ }{ }
{ }{}
{SU
,S,P
,RD
}{}
{ }{ }
{P,R
T,R
C,S
U,F
,TE}
{RT}
Desc
ritiv
o (3
)V
VV
VV
VV
VV
VV
VEx
plor
atór
io (3
)V
FF
FV
FV
FF
FV
FP R O P Ó S I T O
Pape
lEx
plan
atór
io (3
)V
FF
FF
FF
FF
FF
F
Tem
pode
Vid
a (3
)?
Pers
iste
nte
Pers
iste
nte
Pers
iste
nte
Tran
sien
tePe
rsis
tent
ePe
rsis
tent
ePe
rsis
tent
eTr
ansi
ente
ePe
rsis
tent
eTr
ansi
ente
?Pe
rsis
tent
e
Capt
ura
Reu
sodo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
odo
zer
oR
euso
do z
ero
Inte
graç
ão (3
)?
FF
FF
FF
VF
e V
VV
VRe
finam
ento
(3)
?V
VF
FV
FF
FV
FF
Expa
nsão
(3)
?F
FF
FF
VF
VF
FV
C I C V
L I
O D
A
D EO
pera
ções
Dele
ção
(3)
?F
FF
VF
FV
V e
FV
?V
Leg
enda
:(1
) T: T
exto
, I: I
mag
em, G
: Grá
ficos
, P: P
rotó
tipo
(2) I
: Inf
orm
al, S
-F: S
emi-F
orm
al, F
: For
mal
(3) V
: ver
dade
iro, F
: Fal
so, ?
: ind
eter
min
ado
(4) E
: Est
rutu
ra, F
: Fun
ção,
C: C
ompo
rtam
ento
(5) M
: Met
a, D
M: D
epen
dênc
ia d
e M
eta,
R: R
espo
nsab
ilidad
es, O
: Opo
rtuni
dade
(6) F
: Fle
xibi
lidad
e, P
: Per
form
ance
, RC
: Res
triçõ
es d
e cu
sto,
RD
: Res
triçõ
es d
e D
esig
n,
RT:
Res
triçõ
es d
e Te
mpo
, S: s
egur
ança
, SU
: Sup
orte
a U
suár
io, T
E: T
rata
men
to d
e Er
ro
Tabela 7.1: inserção deste trabalho na classificação apresentada em[Rolland et al., 1996] para abordagens que utilizam cenários de interação.
163
164
7.2 Oportunidades para Trabalhos Futuros
O presente trabalho inspira a realização de alguns trabalhos futuros, dos quais
destacamos:
• Identificação de padrões de design de interação (interaction design patterns)
independentes e dependentes de tecnologia e sua representação na LECI;
• Identificação de analogias entre padrões de design de interação dependentes de
tecnologias distintas e sua representação na LECI;
• Determinação de sistemas expressivos associados às tecnologias existentes e de
regras de correlação entre estes sistemas e os tipos semânticos propostos;
• Incorporação de controle de evolução de cenários ao modelo proposto;
• Realização de experimentos para avaliação de características da LECI.
Nas próximas seções, apresentamos breves discussões sobre cada um deles.
7.2.1 Identificação de padrões de design de interação e sua representação naLECI
Acreditamos que a representação de padrões de design (design patterns) de interação
na LECI traria grandes benefícios para a atividade de design de IHC. Ao abstrair a partir de
experiência, padrões de design têm relevância e potencial para serem reusados. Entretanto,
isoladamente, eles não têm o mesmo valor que se estruturados dentro de uma linguagem de
padrões e por isto o principal objetivo da pesquisa em design patterns é justamente o
desenvolvimento de linguagens de padrões. Desta forma, acreditamos que haveria as
seguintes vantagens em se adaptar a LECI para que ela pudesse ser utilizada para caracterizar
padrões de design de interação:
• seria possível estruturar padrões de design de interação, permitindo-se assim a
representação de linguagens de padrões;
• seria possível representar padrões de design de interação menos dependentes de
tecnologia, em termos de tipos semânticos, ao invés de em termos de componentes
de interface específicos, como feito em vários trabalhos, eg. [Trætteberg, 2000];
165
• seria possível representar analogias entre padrões de design de interação de
tecnologias distintas (isto será discutido na próxima seção).
Para adaptar a LECI para que possa permitir a caracterização de padrões de design de
interação será necessário primeiramente, definir um formato para a representação dos padrões
de design. Alguns formatos são apresentados em [Gamma et al., 1995], [Borschers, 2000].
Após a escolha da estrutura de representação, para cada atributo definido nesta estrutura, será
necessário avaliar se a LECI já permite a representação deste atributo e que extensões seriam
necessárias caso ela não o permita. Para exemplificar, consideremos um conjunto de atributos
normalmente incluídos em diversos formatos definidos para design patterns:
• a descrição do problema,
• uma possível solução,
• exemplos de uso da solução em designs reais,
• razões por que a solução apresentada realmente resolve o problema,
• critérios para se decidir quando usar ou não uma determinada solução,
• relações com outros padrões de design.
Deste conjunto de atributos, acreditamos que a LECI já permite a representação dos
seguintes: uma possível solução para o problema, critérios de decisão e algumas das possíveis
relações com outros padrões de design. Uma possível solução poderia ser representada por
templates de tarefa e de diálogos. Critérios de decisão poderiam ser representados através de
estruturas de interação definidas em contextos de interação exclusivos e as expressões que
descrevem as condições lógicas que caracterizam estes contextos. Por fim, relações de
composição entre tarefas e diálogos padrão poderiam ser representadas através da própria
estrutura de especificação da LECI.
7.2.2 Identificação de analogias entre padrões de design de interaçãodependentes de tecnologias distintas e sua representação na LECI
A identificação de analogias entre estruturas de interação dependentes de tecnologias
distintas pode trazer os seguintes benefícios para o design de aplicações multi-tecnologia:
• facilitaria o mapeamento entre as partes da especificação do modelo de interação
que não possam ser reusadas ao se migrar de uma tecnologia para outra;
166
• facilitaria a manutenção da consistência entre versões de uma mesma aplicação
implementadas em tecnologias distintas, com o objetivo de se permitir que um
usuário que a use em diferentes ambientes, ao acessá-la em um destes ambientes,
possa importar conhecimentos obtidos a partir do uso em outro.
No estado em que se encontra este trabalho, a LECI permite ao menos a representação
de analogias entre estruturas de interação dependentes de tecnologias distintas. A cláusula
Exclusive-Technologies relaciona partes da interação mutuamente exclusivas devido a
dependência tecnológica e desta forma permite ao designer representar as versões análogas
definidas por ele para distintos tipos de tecnologia. Para representar estas analogias como
analogias entre padrões de interação, pode se utilizar templates de diálogos e/ou tarefas. Por
exemplo, a sentença apresentada a seguir teria a seguinte semântica:
para um diálogo ou tarefa genérico (qualificado(a) com shared) denominado
<object_name> e com semântica <semantic_type>, <interaction_structure1>, ...
<interaction_N> são estruturas de interação análogas quando se migra entre as tecnologias
<technology_type1>, ..., <technology_typeN>.
shared dialog | task <object_name> (<semantic_type>) {
[operands <operands>]Exclusive-Technologies {
when technology is <technology_type1> {<interaction_structure1>
}. . .when technology is <technology_typeN> {
<interaction_structureN>}
}
A LECI também permite a representação de estruturas de interação dependentes de
determinada tecnologia que não têm equivalente ou não são necessárias em outras
tecnologias. Basta que não seja especificada a cláusula Exclusive-Technologies.
Entretanto, convém ressaltar que permitir a representação de analogias entre estruturas
de interação dependentes de tecnologias distintas não é suficiente. É preciso garantir a
qualidade destas analogias. Para isto, sugerimos a realização de estudos de caso que
verifiquem se existem analogias entre padrões de design de interação bem sucedidos de
tecnologias distintas. Observe que também se faz necessária uma discussão mais aprofundada
para se avaliar se existem situações onde é impossível transportar uma aplicação de uma
tecnologia para outra, de forma que as versões das interfaces sejam equivalentes.
167
7.2.3 Determinação de Sistemas Expressivos e Regras de Correlação
Conforme mencionado no capítulo 2, a aplicação prática da Engenharia Semiótica ao
design de interfaces baseia se na seguinte idéia: se for utilizado um sistema semiótico,
conhecido tanto pelo designer como pelo usuário, que relacione elementos de interfaces
(sistema expressivo) a intenções de comunicação do designer (sistema semântico), a
interpretação do usuário ficará potencializada por estas intenções. Desta forma, o usuário
poderá adquirir um modelo de uso da aplicação compatível com o modelo proposto pelo
designer. A partir destas considerações, acreditamos que definições de sistemas semióticos
que indiquem regras de correlação entre sistemas expressivos associados a diferentes
tecnologias e os tipos semânticos representáveis na LECI, representam importantes trabalhos
futuros, na direção de aumentar a aplicabilidade da LECI como ferramenta de auxílio à
expressão da mensagem do designer.
É bastante provável que ainda não tenha sido estabelecido um conjunto bem definido
de regras de correlação entre intenções de comunicação dos designers e sistemas expressivos
dos ambientes tecnológicos. Se isto houvesse ocorrido, o seu conhecimento por parte de
designers e usuários faria do design de interfaces uma atividade bem mais simples do que é de
fato. Mesmo sem a consciência de estar usando um sistema semiótico para o design de
interfaces, o designer se beneficiaria deste sistema. Partindo deste pressuposto, de que as
regras ainda não estão totalmente estabelecidas, seria oportuno que pesquisadores definissem
boas regras e que estas regras fossem "ensinadas" aos usuários, estabelecendo-se assim
sistemas semióticos. Para a determinação de boas regras, sugerimos a investigação do uso de
padrões de design de interface como fonte de conhecimento. Design Patterns não só
apresentam soluções para problemas de design mas também argumentação e exemplos para
comprovar que estas soluções são boas, além de critérios para se decidir quando usar ou não
uma determinada solução. Observe que desta vez, nos referimos a design patterns de interface
e não de interação, pois o objetivo será justamente identificar tipos expressivos de ambientes
tecnológicos.
Para analisar se a investigação de padrões de design de interface realmente pode trazer
benefícios para a aplicação prática da Engenharia Semiótica, encorajamos a utilização da
semiótica para explicar porque uma experiência bem sucedida, quando repetida em um
contexto similar, tem grandes chances de ser também bem sucedida. Acreditamos que isto
168
pode estar relacionado ao fato de ter sido repetida um número suficiente de vezes para que sua
relação com o problema que resolve seja bastante conhecida por usuários e designers,
representando assim uma regra de um sistema Semiótico.
7.2.4 Incorporação de Controle de Evolução de Cenários
O processo de design de sistemas computacionais (incluindo o design de IHC) pode
ser descrito como um processo de comunicação entre designers e usuários, composto por
vários ciclos. Em cada ciclo os usuários comunicam seus requisitos aos designers e estes
comunicam sua solução ao problema dos usuários sob a forma de aplicação
computacional [de Souza, 1993]. Devido a Semiose Ilimitada2 [Peirce, 1931], ao interagir
com a aplicação, os usuários percebem novos requisitos e os comunicam aos designers,
iniciando um novo ciclo. A natureza cíclica e dinâmica deste processo faz com que a
especificação da aplicação evolua com o tempo. Desta forma, é interessante que modelos e
linguagens concebidos para a descrição do design em termos de cenários, como os
desenvolvidos neste trabalho, possam suportar a evolução de cenários. Segundo
[Breitman, 1998], os maiores benefícios de se proporcionar o controle da evolução de
cenários seriam: documentação, reuso e criação de design rationale. A evolução de cenários
costuma ser representada através de operações que, ao serem aplicadas a um conjunto inicial
de cenários, geram um novo conjunto de cenários. Em [Breitman, 1998] são identificadas
operações que envolvem um conjunto de cenários e outras que se dão dentro do âmbito de um
mesmo cenário, como, por exemplo, inserção, exclusão ou modificação de partes do cenário.
Acreditamos que a estruturação da LECI, em termos de componentes bem definidos (tarefa,
diálogo e enunciados) facilitará sua adaptação para o suporte a representação da evolução de
cenários através de operações. A figura 7.1 ilustra que poderiam ser representadas operações
relacionando componentes em 3 níveis de abstração e que até mesmo a mudança de tipos
semânticos poderia ser representada. Tendo em vista estas considerações, podemos dizer que
para que a LECI possa suportar a evolução de cenários, será necessário:
1. estabelecer um conjunto de operações de evolução a serem suportadas e os níveis
de abstração em que convém aplicá-las e
2Semiose Ilimitada é o fenômeno que ocorre quando um signo desencadeia uma seqüência ilimitada de
interpretações na mente de quem o interpreta.
169
2. incorporar novos construtos na linguagem capazes de representar as operações a
serem suportadas.
Figura 7.1: algumas operações evolutivas que podem vir a ser representadas utilizando-se aLECI.
7.2.5 Experimentos para avaliação de características da LECI
Alguns experimentos se fazem necessários para avaliar e aumentar a qualidade da
LECI. Por exemplo, os tipos semânticos e os templates apresentados neste trabalho foram
definidos com base em nossa experiência de design, mas representam apenas conjuntos
iniciais, não podendo ser considerados padrões. Além disso, se faz se necessária uma análise
aprofundada sobre que templates e outras combinações de elementos da LECI podem
apresentar dependência tecnológica. Acreditamos que o mapeamento de alguns elementos
caracterizáveis na LECI são mais adequados para interfaces web acessíveis via desktop,
devido ao fato de que, para a definição da linguagem, estudamos somente sistemas com este
tipo de interface. Desktops permitem um maior número de possibilidades de interação que
outros tipos de dispositivos, como palmtops, celulares e telefones, por possibilitarem um
T1 (ST1)
D1 (SD1)
E1 (SE1)
E2 (SE2)
D2 (SD2)
E3 (SE3)
E4 (SE4)
T1 (ST2)
D1 (SD2)
E1 (SE5)
E5 (SE5)
D3 (SD3)
E6 (SE6)
E7 (SE7)
Modificação
Inserção
Modificação
ModificaçãoModificação
Exclusão
Exclusão
T<i> = Tarefa ST<i> = Semântica de TarefaD<i> = Diálogo SD<i> = Semântica de DiálogoE<i> = Enunciado SE<i> = Semântica de Enunciado
Inserção
170
maior fluxo de informação no tempo. Desta forma, alguns elementos da LECI abstraídos a
partir de interfaces acessíveis via desktop podem não ter mapeamento viável ou adequado
para alguns dispositivos distintos. Como o nível de abstração e a independência tecnológica
de uma especificação dependem da capacidade que o designer tem para abstrair, o
conhecimento de potenciais dependências tecnológicas de elementos da LECI, auxiliaria
designers a alcançar um nível de caracterização satisfatoriamente abstrato e a identificar mais
facilmente os componentes tecnológicos de seu modelo, para que possa separá-los
adequadamente, dos meta-tecnológicos.
A análise das potenciais dependências tecnológicas de elementos da LECI poderá ser
feita com mais facilidade ao se representar padrões de interação na linguagem (veja a seção
7.2.1). Da mesma forma, os templates inicialmente propostos poderão ser validados e/ou
substituídos pelos padrões de design comprovados representáveis na LECI.
A realização de mais estudos de caso que apliquem a LECI na especificação de
aplicações multi-tecnologia, como o apresentado no capítulo 6, também traria grandes
benefícios. Também contribuiria para a avaliação e o refinamento dos conjuntos de tipos
semânticos e templates e para a identificação de elementos da LECI que potencializam
dependência tecnológica, assim como lançaria mais luz sobre as formas de apoio que a LECI
presta à especificação de aplicações multi-tecnologia. Convém realizar estudos considerando
outros dispositivos (ex. celular, palm tops) e outros estilos de interação (realidade virtual,
manipulação direta, etc) não considerados neste trabalho.
Por fim, são necessários experimentos com designers com distintos níveis de
experiência em design, para avaliar a usabilidade e a qualidade da LECI como ferramenta
para a especificação de cenários de interação.
171
Referências
[Alexander et al., 1977] Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.;Fiksdahl-King, I. e Angel, S. 1977.A Pattern Language.Oxford University Press, New York.
[Amyot, 1999] Amyot, Daniel. 1999. Use Case Maps - Quick Tutorial -version 1.0. SITE, University of Ottawa.
[Andersen, 1990] Andersen, P. 1990. A Theory of Computer Semiotics.Cambridge University Press, 1990.
[Benner et al., 1992] Benner, K. M.; Feather, S.; Johnson, W. L.; Zorman, L. A.1992.Utilising Scenarios in the Software DevelopmentProcess. IFIP WG 8.1 Working Conference on InformationSystems Development Process, pp. 117-134, Dezembro, 1992.
[Bodnar et al., 1996] Bodnar, Roger; Heagy, Win; Seals, Cheryl. 1996. Curso:Models and Theories of Human-Computer Interactionsministrado em 1996 em Virginia Polytechnic Institute andState University. Disponível em:http://ei.cs.vt.edu/~cs5724/g2/Último acesso em 22/09/2001.
[Borchers, 2000] Borchers, J. O. 2000. A Pattern Approach to InteractionDesign. John Wiley & Sons.
[Breitman, 1998] Breitman, Karin Koogan; Leite, J. C. 1998. SuporteAutomatizado à Gerência da Evolução de Cenários. Anais doWorkshop de Engenharia de Requisitos 1998. Departamentode Informática. PUC-Rio. Outubro,1998. pp. 49-56.
[Card et al., 1980] Card et al., S. K. 1980. Computer text-editing:An information-processing analysis of a routine cognitive skill. CognitivePsychology, Volume 12, 1980, pp. 32 - 74.
[Card et al., 1983] Card, Stuart K.; Moran, Thomas P.; Newell, Allen. 1983. Thepsychology of human-computer interaction. LEA.
[Carroll, 1995] Carroll, John M. Carroll. 1995. Introduction: The ScenarioPerspective on System Development. Em Scenario BasedDesign: Envisioning Work and technology in systemdevelopment. Editado por John M. Carroll. John Wiley &Sons, Inc.
172
[Carroll, 2000] Carroll, John M. Carroll. 2000. Making Use - scenario baseddesign of human-computer interactions. MIT Press.Cambridge, Massachusetts.
[de Haan, 2000] de Haan, Geert. 2000. ETAG - A Formal Model ofCompetence Knowledge for User Interface Design. Tese deDoutorado. Mathematics and Computer Science Department.Vrije Universiteit Amsterdam.
[de Souza ,1993] de Souza, C. S. 1993. "The Semiotic Engineering of UserInterface Languages". International Journal of Man-MachineStudies (1993) 39, 753-773.
[Dix, 1998] Dix, A.; Abowd, G.; Beale, R. and Finlay, J. 1998. Human-Computer Interaction. Prentice Hall.
[Eco, 1976] Eco, U. A Theory of Semiotics. Bloomington, IN. IndianaUniversity Press. 1976.
[Firth, 1991] Firth, Chris; Thomas; Richard C.. 1991. The use of commandlanguage grammar in a design tool. International Journal ofMan-Machine Systems, v. 34, pp. 479-496.
[Foley et al., 1990] Foley, James D.; van Dam, Andries; Feiner, Steven K.;Hughes, Jon F. 1990. Computer Graphics: Principles andPractice. 2a edição. Addison-Wesley.
[Gamma et al., 1995] Gamma, E.; Helm, R.; Johnson, R. e Vlissides, J. 1995.Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley, Reading.
[Gough et al., 1995] Gough, P. A.; Fodemski, F. T.; Higgins, S. A.; Ray, S. J."Scenario - na industrial Case Study and HypermediaEnhancements".1995. Second IEEE International SymposiumOn Requirements Engineering, 1995.
[Green, 1986] Green, Mark. 1986. A survey of three dialogue models. ACMTrans. Graph., v. 5, n. 3, pp. 244-275, Julho 1986.
[Griffiths] Griffiths, Richard. Notas de curso que abordam UAN.Universidade de Brighton. Inglaterra. Disponível em:http://www.it.bton.ac.uk/staff/rng/teaching/notes/UAN.html.último acesso em 04/07/2001.
[Harel, 1987] Harel, D. 1987. Statecharts: a visual formalism for complexsystems. Science of Computer Programming, v. 8, n. 3, pp.231-274, Junho 1987.
173
[Harrison, 1994] Harrison, M.D.; Duke, D. J. 1994. A review of formalismsdescribing interactive behaviour. Technical Report,Department of Computer Science, University of York, 1994.Apresentado no "Research Issues in the Intersection ofSoftware Engineering and Human-Computer Interaction"workshop. ICSE'94. Sorrento.
[Hix, 1993] Hix, Deborah; Harston, H. Rex. 1993. Developing UserInterface - Ensuring Usability Trough Product & Process.
[Holbrook, 1990] Holbrook, C. H. 1990. III, "A Scenario-Based Methodologyfor Conducting Requirement Elicitation", ACM SIGSOFTSoftware Engineering Notes, 15 (1), pp. 95-104,1990.
[Howes, 1990] Howes, A.; Payne, S. J.. 1990. Display-based competence:towards user models for menu-driven interfaces . InternationalJournal of Man-Machine Studies , 33:637--655, 1990.
[Hsia et al., 1994] Hsia, P.; Samuel, J.; Gao, J.; Kung, D.; Toyoshima, Y.; Chen,C. 1994. Formal Approach to Scenario Analysis. IEEESoftware, pp. 33-41.
[Jacob, 1986] Jacob, Robert J. K. 1986. Using formal specifications in thedesign of a human-computer interface. In N. Gehani e A. D.McGettrik, eds., Software Specification Techniques, pp. 209-222. Addison-Wesley, 1986.
[Jacobson et al., 1992] Jacobson, I.; Christerson, M.; Jonsson, P.; Oevergaard, G.1992. "Object Oriented Software Engineering: a Use CaseDriven Approach", Addison-Wesley.
[John, 1990] John, B. E. 1990. Extensions of GOMS analyses to expertperformance requiring perception of dynamic visual andauditory information. Proceedings of ACM CHI'90Conference on Human Factors in Computing Systems, pp.107-115. J. C. Chew and J. Whiteside. New York, ACM Press.
[Kemmerer, 1981] Kemmerer, R. A. Testing Formal Specifications to DetectDesign Errors. IEEE Transactions On Software Engineering.Janeiro de 1981. pp. 32-43.
[Kieras, 1988] Kieras, David E. 1988. Towards a pratical GOMS modelmethodology for user interface design. Em M. Helander, ed.,Handbook of Human Computer Interaction, pp. 135-157.Elsevier.
174
[Kotonya, 1998] Kotonya, G.; Sommerville, I. 1998. RequirementsEngineering: processes and techniques. Chichester. JohnWiley & Sons, Inc.
[Kyng, 1995] Kyng, M. 1995. "Creating Contexts for Design", Em"Scenario Based Design". Editado por John M. Carroll. JohnWiley & Sons, Inc.
[Lawrence, 1997] Workflow Handbook 1997. 1997. Editado por Peter Lawrencee publicado em associação com a Workflow ManagementCoalition. John Wiley & Sons, Inc.
[Leite, 1998] Leite, Jair Cavalcanti; de Souza, C. S. 1998. Modelos eFormalismos para a Engenharia Semiótica de Interfaces deUsuário. Tese de Doutorado. Departamento de Informática.PUC-Rio. Rio de Janeiro.
[Mahemoff, 1998] Mahemoff, M.J. and Johnston, L.J.. 1998. Principles for aUsability-Oriented Pattern Language. Anais da AustralianComputer Human Interaction Conference OZCHI'98Adelaide. IEEE Computer Societey, Los Alamitos, 132-139
[Monteiro et al., 2000] Monteiro, C. C. O.; Barbosa, S. D. J.; de Souza; C. S. 2000.The Role of Designer-Generated Scenarios in DevelopingWeb Applications: A Case Study. Anais do IHC 2000 - IIIWorkshop sobre Fatores Humanos em SistemasComputacionais - Muitas faces em interfaces.
[Moran, 1981] Moran, T. 1981. The command language grammar: arepresentation for the user interface of interactive computersystems. Int. J. Man-Machine Systems, v. 15, n. 1, pp. 3-51,Julho de 1981.
[Muller, 1991] Muller, M. 1991. Participatory Design in Britain and NorthAmerica: “Responding to the Scandinavian Challenge.” Em:S. P. Robertson, G. M. Oslon & J. S. Oslon (eds.), Reachingthrough Technology, CHI´91 Conference Proceedings, NewOrleans, April 28-May 2. New York: ACM Press, pp. 389-392
[Myers, 1992] Myers, B. A. 1992. Languages for Developing UserInterfaces. Jones and Bartlett Publishers, Inc. Boston.
[Nadin, 1988] Nadin, M. 1988. “Interface Design: a semiotic paradigm”.Semiotica 69, 3/4, 269-302, 1988.
[Neisser, 1967] Neisser, U. 1967. Cognitive Psicology. Prentice Hall. MITPress. New York.
175
[Norman, 1986] Norman, D.; Draper, S. 1986. User Centered System Design.Hillsdale, NJ. Lawrence Erlbaum.
[Payne & Green, 1986] Payne, S. & Green. T. 1986. “Task-Action Grammar: a modelof mental representation of task languages. Human-ComputerInteraction, 2(2), 93-133, 1986.
[Peirce, 1931] Peirce, C. S.; 1931.Collected Papers. Harvard UniversityPress.
[Potts et al., 1994] Potts, C.; Takahashi, K.; Anton, A. I. "Inquiry-basedRequirements Analysis". IEEE Software. Março de 1994. pp.21-32.
[Prates, 1998] Prates, R. de O.; de Souza, C. S.. 1998. A EngenhariaSemiótica de Linguagens de Interface Multi-Usuário. Tese deDoutorado. Departamento de Informática. PUC-Rio. Rio deJaneiro.
[Preece et al. , 1993] Preece, J.; Rogers, Y.; Sharp, H.; Benyon, D.; Holland, S.;Carey, T. 1993. Human Computer Interaction. Addison-Wesley.
[Regnell et al., 1995] Regnell, B.; Kimbler, K.; Wesslen, A. 1995. "Improving theUse Case Driven Approach to Requirements Engineering", I.C. S. Press, Eds., Second IEEE International Symposium OnRequirements Engineering, (York, England), pp. 40-47,March 1995.
[Reisner, 1981] Reisner, Phyllis. 1981. Formal grammar and human factorsdesign of an interactive graphics system. IEEE Trans. Soft.Eng., v. SE-7, n. 2, pp.229-240, Março, 1981.
[Rijken, 1994] Rijken, D. 1994. The Timeless Way... the design of meaning.SIGCHI Bulletin. vol. 6, No. 3 (1994) 70-79
[Rolland et al., 1996] Rolland, C.; Ben Achour, C.; Cauvet, C.; Ralyté, J.; Sutcliffe,A.; Maiden, N.A.M.; Jarke, M.; Haumer, P.; Pohl, K.; Dubois,E.; Heymans, P. A Proposal for a Scenario ClassificationFramework (CREWS Report, janeiro de 1996)Disponível em: ftp://sunsite.informatik.rwth-aachen.de/pub/CREWS/CREWS-96-01.pdfúltimo acesso em 22/09/2001.
[Rumbaugh et al., 1991] Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.;Lorensen, W. 1991. "Object-Oriented Modeling and Design",Prentice Hall. 1991.
176
[Scalzo, 1995] Scalzo, Betsy. 1995. UPROAR - User processes reveal objectsand requirements. OOPSLA '95, Workshop on Use Cases,1995.
[Schegloff, 1968] Schegloff, E. 1968. Sequencing in Conversational Openings.American Anthropologist, vol. 70, 1968. pp. 1075-1095.
[Sharratt, 1987a] Sharratt, B. 1987. Internal report: The incorporation of earlyinterface evaluation into Command Language Grammar.Scottish HCI Centre.
[Sharratt, 1987b] Sharratt, B. 1987. Top down interactive systems design: somelessons learned from using Command Language Grammar.Human Computer Interaction - INTERACT '87, 1987. North-Holland. Amsterdam.
[Shneiderman, 1992] Shneiderman, Ben. 1992. Designing the User Interface:Strategies for Effective Human-Computer Interaction 2a
edição. Addison-Wesley.
[Smith, 1986] Smith, S. L.; Mosier, J. N.. 1986. Guidelines for DesigningUser Interface Software. ESD-TR86-278. Bedford. MITRECorporation.
[Somé et al., 1996] Somé, S.; Dssouli, R.; Vaucher, J. 1995. "Toward anAutomation of Requirements Engineering using Scenarios",Journal of Computing and Information, Special issue:ICCI'96, 8th International Conference of Computing andInformation, Waterloo, Canada,2(1) pp. 1110-1132, 1996.
[TECGRAF] Home-Page do TeCGraf, laboratório de pesquisa emTecnologia Em Computação Gráfica da PUC-Rio,www.tecgraf.puc-rio.br/
[Trætteberg, 2000] Trætteberg, Hallvard. 2000 "Model based design patterns".Position paper. CHI 2000.
[UML,1999] OMG Unified Modeling Language Specification - version 1.3.Junho de 1999. Disponível em:http://www.rational.com/uml/index.jtmpl.último acesso em 09/04/2001.
[van Welie et al., 2000] van Welie, M.; van der Veer, G.C.; Eliëns, A.. 2000. Patternsas Tools for User Interface Design. International Workshopon Tools for Working with Guidelines , 7-8 Outubro de 2000,Biarritz, França.
177
[Wing, 1988] Wing, Jeannette M. 1988. A Study of 12 Specifications of theLibrary Problem. IEEE Software. Julho de 1988 pp.66-76.
[Yule, 1983] Yule, George. 1983. Discourse Analysis. CambridgeUniversity Press.
![CENÁRIOS LOGÍSTICOS [ Fabiane Veras ]. DESCRIÇÃO / CONSTRUÇÃO DE CENÁRIOS LOGÍSTICOS](https://img.document.onl/doc/110x75/552fc0fb497959413d8b9541/cenarios-logisticos-fabiane-veras-descricao-construcao-de-cenarios-logisticos.jpg)
