gerenciamento de contexto em sistemas colaborativosvvs/cemantika/docs/2006_qualify... ·...
TRANSCRIPT
Gerenciamento de Contexto
em Sistemas Colaborativos
Vaninha Vieira dos Santos
Monografia de Qualificação e
Proposta de Tese de Doutorado
Recife – PE
Maio de 2006
Pós-Graduação em Ciência da Computação
Universidade Federal de Pernambuco
Centro de Informática
Vaninha Vieira dos Santos
Gerenciamento de Contexto em
Sistemas Colaborativos
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Doutor em Ciência da Computação.
Orientadora: Profa. Ana Carolina Salgado
Co-Orientadora: Profa. Patrícia A. C. R. Tedesco
Recife - PE
Maio de 2006
iii
Resumo
Entender o contexto em que ocorre uma determinada interação é fundamental para que os
indivíduos possam responder de maneira apropriada à situação. No trabalho colaborativo,
onde a qualidade do trabalho produzido depende diretamente da interação entre os
indivíduos, conhecer o contexto é ainda mais importante. Uma funcionalidade desejada dos
sistemas computacionais é que eles se adaptem ao contexto corrente do usuário para oferecer
informações e serviços relevantes naquele instante. Em sistemas colaborativos não apenas o
contexto dos indivíduos deve ser considerado, mas também o contexto do grupo, da tarefa
em desenvolvimento, do projeto associado, entre outros. A aplicação de contexto à área de
Trabalho Cooperativo Apoiado por Computador ainda é um tópico em aberto, e necessita de
maiores investigações sobre o que exatamente considerar como contexto e como o mesmo
pode ser usado para melhorar o trabalho em grupo. A criação de sistemas cientes de contexto
não é trivial. Muitas tarefas relacionadas ao gerenciamento da informação contextual devem
ser implementadas. Para reduzir a complexidade inerente ao desenvolvimento desses
sistemas alguns trabalhos propõem mecanismos genéricos de gerenciamento do contexto. No
entanto, poucas pesquisas abordam mecanismos de gerenciamento de contexto em sistemas
colaborativos e, nesses casos, o contexto se confunde com o conceito de percepção. Falta,
também, uma representação formal do contexto voltada para o trabalho colaborativo. Nesse
cenário, este trabalho propõe um framework para gerenciamento de contexto e uma ontologia
para representação das informações contextuais em sistemas colaborativos. O gerenciador de
contextos é responsável por perceber o foco de trabalho corrente do usuário e prover
mecanismos de raciocínio e inferência que permitam identificar qual o contexto
correspondente a esse foco, a partir da manutenção de uma base de conhecimento contextual.
A ontologia propõe o uso de um vocabulário comum, genérico, para os contextos, que
permita a integração de informações contextuais provenientes de fontes diversas de contexto.
Palavras-chave: Contexto, Computação Ciente de Contexto, CSCW, Groupware, Ontologia
iv
Abstract
Understanding the context that surrounds an interaction is fundamental for individuals to
answer in an appropriate way to that situation. In collaborative work, where the quality of
the produced work strongly depends on the interaction between individuals, the knowledge
about the context is more crucial. A functionality desired in computational system is that
they adapt themselves to the users’ context in order to offer relevant information and
services to that user in his/her current situation. In collaborative systems not only users’
context must be considered but also the group context, the task context, the project context,
and so on. The usage of context in Computer Supported Cooperative Work area is still an
open issue. More investigations need to be done in order to identify what exactly to consider
as context and how the context can be used to improve group work. The development of
context-aware systems is not a trivial task. To reduce the complexity inherent in building
those systems, some work propose the use of generic mechanisms for context management.
However, few research propose context management mechanisms for collaborative systems,
and in those cases the concept of context is mixed with the concept of awareness. It, also,
lacks a formal representation of context related to the collaborative work. In this light, this
work proposes a framework for context management in collaborative systems and an
ontology for formal representation of contextual information applied to the collaborative
work. The context manager aims to perceive the user current focus of attention and to
provide reasoning mechanisms that allow the identification of corresponding context, related
to the focus and to a set of contextual knowledge stored in a knowledge base. The ontology
proposes the use of a common, generic, vocabulary for contextual information that enables
the integration of context acquired from diverse context sources.
Keywords: Context, Context-Awareness Computing, CSCW, Groupware, Ontology
v
Sumário
1 Introdução .................................................................................................................. 1
2 Sistemas Colaborativos.............................................................................................. 4 2.1. Trabalho Cooperativo Apoiado por Computador .......................................................... 4 2.2. Requisitos dos Sistemas Colaborativos ......................................................................... 5 2.3. Percepção....................................................................................................................... 8
2.3.1. Classificação e Representação das Informações de Percepção ........................................9 2.3.2. Benefícios em Prover Percepção....................................................................................10 2.3.3. Fatores que Influenciam a Percepção .............................................................................11 2.3.4. Percepção Periférica e Sobrecarga de Informações........................................................12 2.3.5. Mecanismos Genéricos de Percepção ............................................................................13
2.4. Considerações Finais ................................................................................................... 16 3 Contexto Computacional......................................................................................... 18
3.1. Definições de Contexto................................................................................................ 19 3.2. Computação Ciente de Contexto ................................................................................. 20 3.3. Requisitos para Desenvolvimento de Sistemas Cientes de Contexto .......................... 21
3.3.1. Processo para a Construção de Sistemas Cientes de Contexto.......................................21 3.3.2. Identificação dos Elementos de Contexto ......................................................................22 3.3.3. Modelo de Classificação do Contexto............................................................................24 3.3.4. Aquisição do contexto....................................................................................................25 3.3.5. Modelagem e Representação dos Elementos de Contexto .............................................26 3.3.6. Processamento e raciocínio sobre contexto ....................................................................27 3.3.7. Segurança e privacidade.................................................................................................28 3.3.8. Qualidade do Contexto...................................................................................................29 3.3.9. Desempenho do Sistema Ciente de Contexto.................................................................30
3.4. Sistemas de Gerenciamento de Contexto..................................................................... 30 3.5. Considerações Finais ................................................................................................... 31
4 Abordagens para Representação do Contexto...................................................... 32 4.1. Modelo Baseado em Pares de Chave-Valor................................................................. 32 4.2. Modelo Baseado em Linguagens de Marcadores ........................................................ 33 4.3. Modelo Baseado em Representações Gráficas ............................................................ 34 4.4. Modelo Orientado a Objetos........................................................................................ 36 4.5. Modelo baseado em lógica .......................................................................................... 37 4.6. Modelo baseado em Grafos Contextuais ..................................................................... 39 4.7. Modelo baseado em Mapas de Tópicos ....................................................................... 40 4.8. Modelo Baseado em Ontologias .................................................................................. 42
4.8.1. Exemplos de Ontologias de Contexto ............................................................................44 4.9. Considerações Finais ................................................................................................... 45
5 Mecanismos de Gerenciamento de Contexto......................................................... 47
vi
5.1. Categorias de Abordagens para Gerenciamento de Contexto...................................... 47 5.2. Mecanismos para Gerenciamento de Contexto............................................................ 49
5.2.1. SOPHIE..........................................................................................................................49 5.2.2. SOCAM .........................................................................................................................50 5.2.3. CoBrA ............................................................................................................................52 5.2.4. CXMS ............................................................................................................................54 5.2.5. Context Toolkit - CTK ...................................................................................................55 5.2.6. Middleware de Contexto do Gaia...................................................................................56 5.2.7. Framework de Contexto.................................................................................................58 5.2.8. Kernel Semântico de Contexto.......................................................................................59 5.2.9. Framework Conceitual de Contexto para Groupware....................................................61
5.3. Considerações Finais ................................................................................................... 63 6 Colaboração Contextual.......................................................................................... 65
6.1. Sistemas Colaborativos Cientes de Contexto .............................................................. 65 6.2. Percepção x Contexto .................................................................................................. 67 6.3. Identificação dos Elementos de Contexto.................................................................... 67 6.4. Processamento do Contexto......................................................................................... 70 6.5. Outras Questões Associadas a Contexto no Trabalho em Grupo ................................ 71
6.5.1. Contexto Compartilhado ................................................................................................71 6.5.2. Descasamento de Contexto ............................................................................................72 6.5.3. Perda de Contexto ..........................................................................................................73
6.6. Uso de Contexto em Sistemas Colaborativos .............................................................. 73 6.6.1. Mecanismos de Percepção Contextual ...........................................................................73 6.6.2. CO2DE...........................................................................................................................77 6.6.3. ConChat .........................................................................................................................77 6.6.4. Contexto em Sistemas Colaborativos Móveis ................................................................79 6.6.5. Serviços de Recomendação Sensíveis ao Contexto........................................................80
6.7. Considerações Finais ................................................................................................... 81 7 Um Framework para Gerenciamento de Contexto em Sistemas Colaborativos83
7.1. Motivação e Objetivos do trabalho............................................................................. 83 7.2. Conceitos Utilizados .................................................................................................... 84
7.2.1. Agentes Inteligentes .......................................................................................................85 7.2.2. Foco de Atenção.............................................................................................................85 7.2.3. Elementos de Contexto...................................................................................................85
7.3. Framework para Gerenciamento de Contexto Aplicado a Sistemas Colaborativos .... 86 7.3.1. Arquitetura .....................................................................................................................86 7.3.2. Ontologia para Representação de Contexto em Sistemas Colaborativos .......................90
7.4. Metodologia................................................................................................................. 94 7.4.1. Especificação de Cenários Reais de Colaboração ..........................................................94 7.4.2. Modelagem da CoMGroup-Ont .....................................................................................95 7.4.3. Modelagem do Framework CoMGroup.........................................................................95 7.4.4. Implementação de um Protótipo do CoMGroup ............................................................96 7.4.5. Estudo de Caso...............................................................................................................96 7.4.6. Escrita.............................................................................................................................96
7.5. Atividades Realizadas.................................................................................................. 97 7.5.1. Artigos Publicados e Submetidos para Avaliação..........................................................97
7.6. Cronograma de Atividades .......................................................................................... 97 7.7. Contribuições Esperadas.............................................................................................. 98
vii
Lista de Figuras
Figura 2.1 - Esquema geral dos aspectos do trabalho em grupo (Araújo, 2000)......................................................... 6 Figura 2.2 – O modelo 3C de colaboração (Gerosa, 2006) ......................................................................................... 6 Figura 2.3 – Formas de comunicação entre membros de um grupo ............................................................................ 7 Figura 2.4 – Ilustração da percepção sobre ações realizadas em um artefato compartilhado.................................... 9 Figura 2.5 – Visão geral da arquitetura da infra-estrutura NESSIE (Prinz, 1999).................................................... 14 Figura 2.6 - Ciclo Registro-Ocorrência-Notificação do Framework BW (Kirsch-Pinheiro et al., 2002) .................. 15 Figura 2.7 - Processo de gerenciamento das informações de percepção usado em Ariane (Vieira, 2003)................ 16 Figura 3.1 – Tipos de Contexto e suas Dinâmicas (Santoro et al., 2005) .................................................................. 24 Figura 3.2 – Regras de raciocínio de contexto em lógica de primeira ordem (Wang et al., 2004) ............................ 28 Figura 3.3 – Exemplo de geração de contexto de alta ordem usando redes bayesianas (Korpipää et al., 2003) ...... 29 Figura 3.4 – Ontologia de Qualidade de Contexto e Instância de Exemplo (Gu et al., 2004c).................................. 30 Figura 4.1 - Exemplo de uso da representação de contexto por par chave-valor ...................................................... 33 Figura 4.2 - Exemplo de Perfil usando CSCP (Strang e Linnhoff-Popien, 2004) ...................................................... 34 Figura 4.3 – Exemplo de caso de uso genérico para um sistema ciente de contexto (Bauer, 2003) .......................... 35 Figura 4.4 – Modelo CML (Henricksen et al., 2002).................................................................................................. 36 Figura 4.5 – Exemplo de regras de contexto na Teoria da Situação Estendida (Strang e Linnhoff-Popien, 2004) ... 38 Figura 4.6 – Representação de procedimentos e contextos em um grafo contextual (Brézillon, 2003b) ................... 40 Figura 4.7 – Representações Visuais de Mapas de Contexto (Goslar e Schill, 2004) ................................................ 41 Figura 4.8 – Aplicações de Ontologia (Mika e Akkermans, 2005) ............................................................................. 42 Figura 5.1 - Modelo de Contexto (Belotti, 2004)........................................................................................................ 49 Figura 5.2 - Arquitetura do SOPHIE (Belotti, 2004).................................................................................................. 50 Figura 5.3 - Visão parcial da ontologia de alto nível do CONON (Wang et al., 2004) ............................................. 51 Figura 5.4 – Visão Geral da Arquitetura do SOCAM (Gu et al., 2005) ..................................................................... 52 Figura 5.5 – Representação Gráfica da Ontologia CoBrA-Ont (Chen et al., 2003a) ................................................ 53 Figura 5.6 – Visão Geral da Arquitetura do CoBrA (Chen, 2004)............................................................................. 54 Figura 5.7 - Arquitetura do CXMS (Zimmermann et al., 2005a)................................................................................ 55 Figura 5.8 – Hierarquia de Componentes e Arquitetura do CTK (Dey et al., 2001).................................................. 56 Figura 5.9 – Visão geral do middleware de contexto do GAIA (Ranganathan e Campbell, 2003) ............................ 57 Figura 5.10 - Arquitetura do Framework de Contexto (Henricksen e Indulska, 2005) .............................................. 59 Figura 5.11 - Visão Geral da Arquitetura do SCK (Bulcão Neto e Pimentel, 2005) .................................................. 60 Figura 5.12 – Visão geral do modelo de contexto (Bulcão Neto e Pimentel, 2005) ................................................... 61 Figura 5.13 – Framework Conceitual de Contexto para Groupware (Rosa, 2004) ................................................... 62 Figura 5.14 – Diagrama de classes com um modelo conceitual preliminar do contexto (Rosa, 2004)...................... 63 Figura 6.1 – Níveis de contexto em ambientes colaborativos (Brézillon et al., 2004)................................................ 68 Figura 6.2 – Composição do contexto de uma atividade (Rosa, 2004) ...................................................................... 69 Figura 6.3 – Representação de contexto proposta por Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2004) ........... 70 Figura 6.4 – Processamento do contexto no trabalho em grupo (Borges et al., 2004) .............................................. 71 Figura 6.5 – Construção do contexto compartilhado na interação entre dois participantes (Brézillon, 2003a) ....... 72 Figura 6.6 – Exemplos de situações de trabalho onde usuários podem receber informações de percepção relacionadas a um documento (Mark et al., 1997) ............................................................. Erreur ! Signet non défini. Figura 6.7 – Passos para inclusão do contexto de percepção no ENI (Gross e Prinz, 2003) .................................... 76 Figura 6.8 - Arquitetura do ConChat (Ranganathan et al., 2002) ............................................................................. 79 Figura 6.9 – Interface do ConChat (Ranganathan et al., 2002) ................................................................................. 79 Figura 6.10 – Inclusão do contexto ao Modelo 3C no AulaNetM (Filippo et al., 2005) ............................................ 80 Figura 6.11 – Propaganda sensível ao contexto no GMail ........................................................................................ 81 Figura 7.1 – Visão geral da arquitetura do CoMGroup............................................................................................. 87 Figura 7.2 - Visão Geral e Parcial da Hierarquia de Classes da Ontologia de Contexto ......................................... 92 Figura 7.3 – Visão geral dos relacionamentos entre os conceitos ............................................................................. 93 Figura 7.4 – Instância da ontologia de contexto usada no CoWS (Zarate, 2006)...................................................... 94
viii
Lista de Tabelas
Tabela 3.1 - Classificação das informações contextuais (Henricksen, 2003)............................................................. 25 Tabela 4.1 – Atributos (chaves) de Contextos de Percepção (Gross e Prinz, 2003)................................................... 33 Tabela 4.2 – Diagramas da UML e sua finalidade na modelagem do contexto ......................................................... 35 Tabela 4.3 – Resumo das Abordagens de Representação de Contexto....................................................................... 45 Tabela 5.1 – Resumo das Abordagens para Gerenciamento de Contextos................................................................. 64 Tabela 7.1 – Cronograma de Atividades ................................................................................................................... 98
1
CAPÍTULO 1
Introdução
Mudanças nas necessidades de negócios, com tarefas e projetos mais complexos e prazos de execução
menores, vêm demandando alterações na forma de trabalho das organizações, com a substituição do
esforço individual pela utilização de equipes, interagindo colaborativamente. É cada vez mais comum que
as equipes de trabalho sejam formadas por pessoas dispersas geograficamente, ou que, mesmo
fisicamente próximas, tenham uma flexibilidade de horário, trabalhando em turnos distintos. Para que a
realização do trabalho em equipe funcione de maneira eficaz, é necessário que haja cooperação entre os
indivíduos envolvidos, facilidades de comunicação, entendimento dos objetivos e papéis de cada um
dentro do grupo, bem como acompanhamento do que ocorre no âmbito das atividades do grupo.
A área de Trabalho Cooperativo Apoiado por Computador (CSCW – Computer Supported
Cooperative Work) estuda o modo como as pessoas trabalham em equipe e procura descobrir como os
computadores podem auxiliá-las na realização de suas tarefas (Ellis et al., 1991). As pesquisas
desenvolvidas em CSCW deram origem a uma nova categoria de sistemas, chamada “sistemas
colaborativos”, ou “groupware”. Esses sistemas objetivam aumentar o potencial dos grupos, fazendo com
que o produto resultante das interações apresente melhor qualidade do que a soma das contribuições
individuais de cada membro do grupo. Para isso, o groupware deve oferecer recursos que facilitem a
comunicação entre os participantes, a cooperação e compartilhamento de informações e recursos, a
coordenação das atividades colaborativas, a percepção das interações realizadas no contexto do grupo, e
a verificação de interações passadas mantidas em uma memória do grupo.
A percepção refere-se ao entendimento de um indivíduo sobre o que ocorre dentro do grupo que
seja relevante para a realização de suas atividades. A memória do grupo provê um entendimento sobre o
histórico de interações do grupo, como o grupo se comporta, como toma suas decisões e desenvolve seu
trabalho. É importante que os indivíduos compreendam o trabalho dos outros sem muito esforço, e em um
curto espaço de tempo, para otimizar o andamento dos trabalhos.
Contexto pode ser definido como qualquer informação que pode ser utilizada para caracterizar a
situação de uma entidade, onde uma entidade é uma pessoa, lugar ou objeto considerado relevante para a
interação entre um usuário e uma aplicação (Dey, 2001). Sistemas cientes de contexto, ou sensíveis a
contexto, são aquelas que utilizam o contexto do usuário para prover informações e serviços relevantes
para o usuário naquela situação (Dey, 2001).
As pessoas utilizam, diariamente, informações contextuais para tomar decisões, fazer julgamentos
ou interagir com outras pessoas. Entender o contexto em que ocorre uma determinada interação é
fundamental para que os indivíduos possam responder de maneira apropriada à situação. No trabalho
colaborativo, onde a qualidade do trabalho produzido depende diretamente da interação entre os
2
indivíduos, conhecer o contexto é ainda mais importante. O contexto é um instrumento poderoso para
viabilizar a disseminação de informações relevantes, pois considerando a situação atual do usuário, a
informação pode ser filtrada de acordo com o que é mais importante para o usuário naquela situação.
Brézillon argumenta que a informação deve ser adquirida e mantida com o seu contexto associado para
permitir uma melhor compreensão dessa informação, uma vez que ela assume um significado dentro do
seu contexto (Brézillon, 2005).
Em sistemas colaborativos não apenas o contexto dos indivíduos deve ser considerado, mas
também o contexto do grupo, da tarefa em desenvolvimento, do projeto associado, entre outros. A
aplicação de contexto à área de CSCW ainda é um tópico em aberto que necessita maiores investigações
sobre o que exatamente considerar como contexto e como o mesmo pode ser usado para melhorar o
trabalho em grupo. Alguns trabalhos vêm explorando esse tema {Alarcón, 2005 5 /id;Gross, 2003 112
/id;Borges, 2004 31 /id;Kirsch-Pinheiro, 2005 200 /id}. O conhecimento sobre o contexto no qual ocorre
uma determinada interação pode ser útil para apoiar o trabalho colaborativo, através do provimento de
informações e serviços relevantes para aquela situação. Essa adaptabilidade ao contexto é fundamental
para que o apoio ao trabalho em grupo seja efetivo e, com isso, aumente a usabilidade desses sistemas
(Borges et al., 2004).
Conhecer o contexto em que ocorre uma interação, embora pareça simples no mundo real, mostra-
se bastante difícil em sistemas computacionais. Construir sistemas sensíveis a contexto não é uma tarefa
trivial. Inicialmente, é preciso definir o que exatamente considerar como contexto, onde este se aplica e
que informações são necessárias para descrevê-lo. É preciso viabilizar formas de adquirir o contexto do
usuário o mais automático possível, sem que o mesmo tenha que ser questionado insistentemente sobre o
contexto em que se encontra, possivelmente por meio de técnicas de monitoramento. A aquisição
automática exige que mecanismos de raciocínio e inferência sejam implementados, pois nem todo tipo de
contexto pode ser obtido diretamente das variáveis passíveis de monitoramento disponíveis em um
ambiente. Para essa inferência, questões como incerteza devem ser consideradas, bem como um modelo
formal para representação do contexto. O monitoramento traz outras questões como a necessidade do
usuário manter sua segurança e privacidade.
Para reduzir a complexidade inerente ao desenvolvimento desses sistemas alguns trabalhos
propõem mecanismos genéricos para gerenciamento de contexto, que desacoplem do sistema ciente de
contexto tarefas como aquisição, representação, raciocínio e manipulação do contexto. No entanto,
poucas pesquisas abordam mecanismos de gerenciamento de contexto em sistemas colaborativos e, nesses
casos, o contexto se confunde com o conceito de percepção (Dourish e Bellotti, 1992). Falta, também,
uma representação formal do contexto voltada para o trabalho colaborativo que permita o uso de
contextos provenientes de fontes diversas.
Nesse cenário, o objetivo deste trabalho é propor: (1) um framework para gerenciamento de
contexto e (2) uma ontologia para representação das informações contextuais em sistemas colaborativos.
O gerenciador de contextos é responsável por perceber o foco de trabalho corrente do usuário e prover
3
mecanismos de raciocínio e inferência que permitam identificar qual o contexto correspondente a esse
foco, a partir da manutenção de uma base de conhecimento contextual. A ontologia propõe o uso de um
vocabulário comum e genérico para os contextos que permita a utilização de informações contextuais
provenientes de diferentes fontes de contexto.
O restante desta monografia está organizado como segue:
No Capítulo 2 são discutidos os conceitos associados a sistemas colaborativos, com destaque
para o conceito de percepção;
O Capítulo 3 define o que é contexto computacional e descreve os requisitos e desafios para o
desenvolvimento de sistemas cientes de contexto;
O Capítulo 4 discute o problema da representação de contexto e apresenta algumas abordagens
para representá-lo;
O Capítulo 5 aborda mecanismos para gerenciamento de contextos, define as categorias em que
esses mecanismos se inserem, e apresenta algumas abordagens encontradas na literatura;
Os Capítulos 3 a 5 apresentam como o contexto vem sendo estudado nas diversas áreas, com
ênfase na área da Computação Ubíqua, onde os estudos aplicados de contexto estão mais
avançados. Assim, o Capítulo 6 revisa a área de CSCW para identificar como o contexto vem
sendo proposto para uso nos sistemas colaborativos. São discutidas as diferenças e similaridades
entre os conceitos de contexto e percepção, categorias para identificação dos elementos
contextuais nesses sistemas e exemplos do uso do contexto em alguns sistemas colaborativos;
Finalmente, o Capítulo 7 apresenta a proposta desta tese, bem como a motivação para a
pesquisa, o escopo e objetivos do trabalho, a arquitetura do framework proposto, seu modelo de
representação de contexto, baseado em ontologias, a metodologia a ser seguida, as atividades
realizadas, o cronograma das próximas atividades e as contribuições esperadas com o trabalho.
4
CAPÍTULO 2
Sistemas Colaborativos
Grupos são importantes entidades organizacionais. Ao trabalhar em grupo, os indivíduos têm a
oportunidade de obter feedback sobre suas ações, expor-se a diferentes pontos de vista e explorar os
próprios limites de modo a corresponder às responsabilidades assumidas com os colegas (Tedesco, 2001).
Dessa maneira, grupos podem ser mais efetivos, em termos de produção de soluções melhores e mais
rápidas, do que pessoas trabalhando individualmente. Sistemas colaborativos são categorias de aplicações
voltadas para apoiar os grupos na realização dos seus trabalhos, quebrando barreiras de tempo e espaço,
ou seja, com indivíduos distantes geograficamente e com diferentes horários de trabalho.
Este capítulo descreve os conceitos relacionados aos sistemas colaborativos. Inicialmente é
apresentada a área de pesquisa de trabalho cooperativo apoiado por computador, de onde esses sistemas
originam-se. A seguir são descritos requisitos envolvidos na construção de sistemas colaborativos,
segundo o modelo 3C (Comunicação, Coordenação e Cooperação) {Ellis, 1991 95 /id}{Fuks, 2002 298
/id}, sendo detalhado o requisito de percepção, devido à sua relevância para este trabalho.
2.1. TRABALHO COOPERATIVO APOIADO POR COMPUTADOR
A área de Trabalho Cooperativo Apoiado por Computador (CSCW – do inglês Computer Supported
Cooperative Work) estuda como as pessoas interagem para a realização do trabalho cooperativo e como a
tecnologia dos computadores pode auxiliá-las nessa interação (Ellis et al., 1991). CSCW é uma área
multidisciplinar com origens nas ciências sociais, envolvendo disciplinas como Antropologia, Sociologia
e Psicologia, e nas tecnologias de computadores, envolvendo profissionais de áreas como Engenharia de
Software, Banco de Dados, Interação Homem-Máquina, Inteligência Artificial e Redes de Computadores.
Encontrar uma definição precisa de trabalho cooperativo não é fácil. Em (Ramampiaro e Nygard,
1999) é citada uma definição apresentada por Karl Marx que diz que “quando vários trabalhadores
trabalham em conjunto, lado a lado, de acordo com um plano, em um mesmo processo, ou diferentes, mas
conectados, essa forma de trabalho é chamada cooperação”. Outra definição, mais genérica, diz que
cooperação é “um processo de trabalho envolvendo diversas pessoas agindo em conjunto, em um
contexto compartilhado, para realizar tarefas com objetivo comum” (Ramampiaro e Nygard, 1999).
Os termos trabalho cooperativo e trabalho colaborativo são muitas vezes utilizados como
sinônimos. No entanto, existem grupos que fazem distinção entre eles, baseado no grau de divisão das
tarefas. No trabalho cooperativo, os parceiros dividem o trabalho, resolvem sub-tarefas individualmente e
então juntam os resultados parciais em um produto final; enquanto que no trabalho colaborativo, os
participantes do grupo desenvolvem juntos cada sub-tarefa (Dillenbourg et al., 1996). O modelo 3C de
5
colaboração, proposto por Ellis et al. (Ellis et al., 1991), diz que a colaboração é composta por três
atividades inter-relacionadas: cooperação, coordenação e comunicação. Dessa forma, esse modelo vê a
cooperação como uma das atividades que constituem a colaboração.
A interação entre os participantes pode ocorrer, basicamente, de três formas: síncrona, assíncrona e
multi-síncrona. Interação síncrona é aquela em que os participantes trabalham juntos sobre uma
determinada tarefa no mesmo instante de tempo, como ocorre em reuniões. Na interação assíncrona, os
participantes trabalham em diferentes instantes de tempo na tarefa, como ocorre com autores e revisores
na escrita colaborativa, ou em grupos de discussão, onde um participante escreve uma mensagem que
pode levar dias até ser respondida por um outro participante. A interação multi-síncrona, segundo Molli et
al. (Molli et al., 2002), ocorre principalmente no desenvolvimento cooperativo de software, onde cada
membro do grupo tem uma cópia do dado compartilhado e modifica suas cópias em paralelo, as quais são,
posteriormente, reunidas em uma versão única.
As pesquisas desenvolvidas em CSCW deram origem a uma nova categoria de aplicações,
chamadas sistemas colaborativos, ou sistemas de groupware. Essas aplicações objetivam aumentar o
potencial dos grupos, fazendo com que o produto resultante das interações apresente melhor qualidade do
que a soma das contribuições individuais (Araújo, 2000). Além disso, elas auxiliam a manutenção do
conhecimento corporativo através de uma infra-estrutura, conhecida como memória organizacional, ou
memória do grupo, capaz de manter o conhecimento sobre o negócio da organização, através do
armazenamento das interações entre os participantes (Araújo, 2000).
A tecnologia de groupware apóia o trabalho em grupo através da criação de um ambiente virtual
compartilhado onde os membros do grupo podem compartilhar conhecimento, informações e artefatos
diversos (como textos, documentos, objetos de software, descrições) (Alarcón et al., 2005a). Groupware
reflete uma mudança na ênfase em usar o computador para resolver problemas utilizando-o para facilitar a
interação humana (Ellis et al., 1991).
2.2. REQUISITOS DOS SISTEMAS COLABORATIVOS
Os requisitos que devem ser observados por desenvolvedores de sistemas colaborativos envolvem,
basicamente, quatro aspectos principais e inter-relacionados (Figura 2.1): (i) a comunicação entre os
membros do grupo; (ii) a coordenação de suas atividades; (iii) o armazenamento e recuperação do
conhecimento comum através da memória do grupo; e (iv) a percepção do contexto do trabalho do grupo
por seus membros (Araújo, 2000; Borges e Pino, 2000).
Uma outra classificação para os requisitos de sistemas colaborativos é o modelo 3C (Ellis et al.,
1991), apresentado na Figura 2.2. Esse modelo divide a atividade colaborativa em três sub-atividades, co-
relacionadas: comunicação, coordenação e cooperação. A comunicação envolve a troca de mensagens e
a negociação de compromissos. A cooperação é a produção conjunta dos membros do grupo em um
espaço compartilhado. A coordenação permite que pessoas, atividades e recursos sejam gerenciados para
6
lidar com conflitos e evitar a perda de esforços e desmotivações. Mecanismos de percepção permitem que
o indivíduo obtenha feedback de suas ações e feedthrough das ações de seus colegas (Gerosa, 2006).
Figura 2.1 - Esquema geral dos aspectos do trabalho em grupo (Araújo, 2000)
Neste trabalho, são adotadas as definições propostas no modelo 3C, acrescido da noção de memória
do grupo. Devido à relevância para este trabalho, o conceito de percepção será tratado em detalhes na
próxima seção.
2.2.1. Comunicação
O primeiro obstáculo ao trabalho colaborativo virtual é vencer o isolamento e a distância entre os
membros da equipe de trabalho, estabelecendo a comunicação entre as partes envolvidas. Essa
comunicação pode se dar de maneira direta ou indireta, como ilustra a Figura 2.3. A comunicação direta
ocorre por iniciativa dos próprios participantes, por meio de dispositivos como programas de áudio ou
vídeo conferência, correio eletrônico ou programas de mensagem instantânea. Nesse caso, o usuário
contacta diretamente e abre um canal de comunicação com os usuários com quem deseja interagir, e usa a
forma oral ou textual para debater idéias, tirar dúvidas, dividir tarefas ou tomar conhecimento do
andamento das tarefas realizadas pelos outros participantes.
Figura 2.2 – O modelo 3C de colaboração (Gerosa, 2006)
A comunicação indireta ocorre, especialmente, nas interações assíncronas e se caracteriza pela
manipulação de informações existentes nos artefatos compartilhados, como mensagens deixadas por
7
outros participantes relatando suas ações sobre o artefato, ou o histórico de ações realizadas sobre o
artefato. Artefato compartilhado é qualquer tipo de produto, ou partes de um produto, que seja produzido
pelo grupo, tais como objetos de software, documentos textuais, arquivos de áudio, vídeo, imagem,
porções de texto, mensagens textuais, mensagens de áudio, entre outros.
Figura 2.3 – Formas de comunicação entre membros de um grupo
O registro persistente da manipulação dos artefatos compartilhados pelo grupo compõe a memória
do grupo, ou memória organizacional. A memória do grupo permite conhecer o que houve e o que está
acontecendo ao artefato e, conseqüentemente, dentro do grupo. Em (Dourish, 1997), o artefato
compartilhado é visto, essencialmente, como o único espaço compartilhado disponível aos participantes,
representando a informação chave na colaboração assíncrona. Nesse caso, os indivíduos não se
comunicam diretamente uns com os outros, mas através do registro histórico de suas ações (geralmente
realizado de forma automática pelo próprio groupware) ou através de anotações e comentários deixados
pelo usuário anexados aos artefatos compartilhados.
2.2.2. Coordenação
A coordenação refere-se ao acompanhamento da execução do processo de trabalho, à especificação de
como ocorrerão as interações, à definição de regras e prazos, à delegação de responsabilidades, e ao
controle do desenvolvimento das tarefas. A coordenação visa garantir a produtividade e o sucesso dos
objetivos do grupo, mantendo o grupo coeso, os participantes cientes do seu papel perante o grupo e
focados em seus objetivos específicos e no objetivo geral do grupo. Sem uma boa coordenação as chances
de sucesso do grupo são pequenas e há alta probabilidade de desmotivação, desânimo e trabalhos
conflitantes. Exemplos de ferramentas que apóiam o coordenador são ferramentas de workflow, como o
Lotus Notes (IBM, 2006), de gerência de projetos, como o MSProject (Microsoft, 2005), ferramentas
gerenciais sobre a participação dos membros do grupo, como “participômetro”, “contributômetro” e
“impactômetro” apresentadas em (Borges e Pino, 1999), e ferramentas de consultas analíticas, como o
cubo de percepção (Vieira et al., 2004).
2.2.3. Cooperação
A cooperação está diretamente associada à execução conjunta de tarefas por membros do grupo. Para
isso, é necessário um ambiente que permita gerar e manipular artefatos compartilhados, essenciais para o
8
cumprimento dos objetivos das tarefas. Ambientes de cooperação incluem espaços de trabalho
compartilhados (Gutwin e Greenberg, 2002) e ferramentas de co-autoria adequados à tarefa em execução.
Por exemplo, se a tarefa for a escrita cooperativa de um texto, é necessário que o grupo tenha à disposição
um editor de texto cooperativo. Se a tarefa for o desenvolvimento cooperativo de um software, faz-se
necessário um sistema de controle de versões, como o CVS (CVS, 2006).
2.3. PERCEPÇÃO
Mecanismos de apoio à percepção é considerada uma das principais funcionalidades das aplicações
cooperativas e um fator relevante para ampliar a usabilidade dessas aplicações (Gutwin e Greenberg,
2002). Esse tema tem recebido considerável atenção por parte dos pesquisadores das áreas de CSCW e
Interação Humano-Computador (IHC). Sua importância é evidenciada por diversos trabalhos de pesquisa
(Dourish e Bellotti, 1992; Sohlenkamp, 1998; Borges e Pino, 1999; Araújo, 2000; Kirsch-Pinheiro, 2001;
Gutwin e Greenberg, 2002; Redmiles et al., 2002; Kirsch-Pinheiro et al., 2003; Vieira et al., 2004; David,
2004; Gross et al., 2005) e workshops, em importantes conferências, dedicados ao tema (CHI’97,
CSCW’00, CHI’00).
Uma das mais referenciadas definições é a proposta por Dourish e Bellotti, para os quais:
“Percepção é uma compreensão das atividades dos outros, que provê um contexto para
atividades próprias. Esse contexto é utilizado para garantir que as contribuições individuais
sejam relevantes para as atividades do grupo como um todo, e para avaliar as ações
individuais em relação aos objetivos e progresso do grupo” (Dourish e Bellotti, 1992).
Uma outra definição, proposta por Sohlenkamp diz que:
“Percepção é uma compreensão do estado de um sistema, incluindo atividades passadas,
estado atual e opções futuras, e um estado mental de um usuário (abrangendo a
compreensão, o conhecimento, e o “estar atento”), o qual envolve a atividade dos outros e
provê um contexto para atividades próprias” (Sohlenkamp, 1998).
De uma forma geral, pode-se entender percepção como o conhecimento e a compreensão de tudo o
que ocorre dentro e fora de um grupo que sejam relevantes para o desenvolvimento das atividades dos
seus participantes, no desempenho dos seus diferentes papéis. O sistema inclui todo o contexto do grupo,
os artefatos compartilhados, os aspectos sociais e organizacionais do grupo (que pessoas compõem o
grupo, quais são suas atribuições e habilidades) (Vieira, 2003).
Os termos percepção e mecanismos de percepção são, muitas vezes, empregados de forma similar
na literatura, como se fossem o mesmo conceito. Entretanto, deve-se fazer uma diferenciação entre os
dois. O primeiro é um estado mental do usuário, enquanto o segundo corresponde às técnicas empregadas
por um sistema para oferecer informações de percepção que auxiliem os membros do grupo a alcançar
esse estado mental (Sohlenkamp, 1998). Como exemplo dessa diferença, considere a situação onde um
9
usuário entra em uma sala virtual de chat. A informação de percepção é “o usuário X entrou na sala”. Os
mecanismos de percepção são os meios providos pela aplicação para que os membros do grupo recebam
essa informação. A percepção é alcançada quando as demais pessoas presentes na sala recebem,
processam e compreendem essa informação.
2.3.1. Classificação e Representação das Informações de Percepção
Em termos gerais, para compreender totalmente uma interação da qual faz parte, um indivíduo deve
conhecer as pessoas que compõem o seu grupo (percepção social), deve ter uma visão geral das
atividades desenvolvidas pelo grupo, compreendendo onde suas próprias atividades se inserem dentro do
contexto global (percepção de atividades), e deve ser informado sobre mudanças que venham a ocorrer
no espaço de trabalho compartilhado, no decorrer das interações do grupo (percepção do espaço de
trabalho) (Araújo, 2000; Gutwin e Greenberg, 2002).
Uma classificação para as informações de percepção é conhecida como 5W+1H (Gutwin, 1997;
McCaffrey e L., 1998) e identifica seis questões básicas que devem ser respondidas quando se deseja
contextualizar um indivíduo sobre algo que o mesmo não tenha conhecimento. Elas permitem responder
quem (Who) fez o que (What), onde (Where), em que momento (When), por qual motivo (Why) e de que
maneira (How). Esta classificação aparece em diversos trabalhos para representar as informações de
percepção (Tam, 2002; Vieira, 2003). Algumas variações excluem a questão Why ou a questão How da
representação devido à complexidade de sua identificação automática. A Figura 2.4 ilustra o uso dessas
questões para prover percepção a um Usuário A sobre alterações feitas pelo Usuário B em um artefato
compartilhado.
O que aconteceu?O que aconteceu?
Como aconteceu?Como aconteceu?
Quem está aqui?Quem está aqui?
Quando?
Porque?
Onde?
5W + 1H
Quando?
Porque?
Onde?
5W + 1H
Artefato Compartilhado
Usuário A
Usuário B
Artefato Compartilhado
Usuário AUsuário A
Usuário BUsuário B
Figura 2.4 – Ilustração da percepção sobre ações realizadas em um artefato compartilhado
A maioria dos mecanismos de percepção baseia-se nas facilidades do modelo de eventos para
representar as informações de percepção (Fussel et al., 1995; Prinz, 1999; Sohlenkamp et al., 2000;
Kirsch-Pinheiro et al., 2002; Vieira et al., 2004). Eventos são pequenas mensagens estruturadas que
contêm informações sobre mudanças de estado dos artefatos armazenados e que são propagadas pelo
ambiente de modo a prover percepção (Trevor et al., 1993).
10
2.3.2. Benefícios em Prover Percepção
Segundo Gutwin e Greenberg (Gutwin e Greenberg, 2002), a percepção é vista como fator determinante
para o sucesso da utilização dos sistemas colaborativos. Manter os usuários atentos ao que ocorre dentro
do grupo é fundamental para um bom andamento das atividades individuais e para a coordenação do
trabalho como um todo.
A percepção é essencial para o fluxo e a naturalidade do trabalho, auxiliando a diminuir as
sensações de trabalho impessoal e de distância, comuns nos ambientes virtuais (Gerosa et al., 2001).
Através dessas informações, os participantes podem montar o contexto de suas atividades em relação às
dos demais, coordenando-se para que os esforços de comunicação e de trabalho sejam revertidos em
cooperação. Além disso, o coordenador do grupo pode valer-se dessas informações, que lhe fornecerá
uma visão geral do andamento dos trabalhos e o estado de cada atividade, para motivar e organizar as
pessoas dentro do grupo, encorajando a cooperação (Gerosa et al., 2001).
Ao trabalhar sozinho, de forma isolada, um usuário ao retornar para uma tarefa em que estava
trabalhando pode, sem muita dificuldade, buscar em sua memória as mudanças significativas realizadas
em uma sessão anterior, relembrando o que ele alterou nos objetos e o que ainda necessita ser feito. Por
outro lado, ao trabalhar colaborativamente com outras pessoas, o usuário pode encontrar mudanças
realizadas por outras pessoas em artefatos compartilhados em que estava trabalhando anteriormente.
Nesse caso, ele não tem como adivinhar o que foi feito, o que mudou e o que ainda está por fazer. No
entanto, ele necessita dessa informação para compreender as influências dessas mudanças sobre seu
trabalho e como ele deverá agir desse ponto em diante.
Quando decisões e êxitos dependem da integração de diferentes membros de um grupo, torna-se
importante que cada um conheça o progresso do trabalho dos companheiros, como o que falta para o
término de suas atividades ou quais os resultados preliminares. Sem tal contexto, os indivíduos não
possuem meios de medir a qualidade do seu próprio trabalho em relação aos objetivos e progresso do
grupo (Dourish e Bellotti, 1992).
As informações de percepção tornam a colaboração mais eficiente, permitindo aos participantes
evitar a duplicidade de trabalho e reduzir os conflitos. Prover facilidades adequadas para a percepção é
essencial para colaborações suportadas por computador efetivas, uma vez que na falta dessas informações
o usuário é obrigado a supor o que os outros estão fazendo, causando perda de tempo em atividades não
produtivas (Prakash et al., 1999).
A falta de percepção em um grupo gera diversos problemas, como redundância nas tarefas,
inconsistências e contradições, acarretando em um trabalho sem coesão de idéias ou incompleto,
prejudicando seu resultado em termos de qualidade e eficiência, podendo, até, em casos extremos, não
atingir seus objetivos. Além disso, a falta de informações de percepção, principalmente nas interações
assíncronas, pode gerar um estado de solidão e inércia nos membros do grupo, agravado pelo
11
desconhecimento da importância de suas atividades para o grupo, de seus prazos ou do andamento do
trabalho (Kirsch-Pinheiro, 2001).
A percepção é importante, também, para apoiar a coordenação de atividades individuais ou
coletivas, a comunicação informal e indireta e o uso de convenções (Sohlenkamp, 1998). Comunicação
informal é a interação oportunista, espontânea e não planejada entre as pessoas.
2.3.3. Fatores que Influenciam a Percepção
A forma como as informações de percepção devem ser coletadas e apresentadas pode variar de acordo
com alguns critérios, como o modo de interação e o papel desempenhado pelo usuário dentro do grupo.
Modo de interação: síncrono X assíncrono
A percepção é importante tanto nas interações síncronas quanto assíncronas. Entretanto, o tipo de
informação de percepção e os mecanismos correspondentes são diferentes nas duas formas de interação.
Por exemplo, em relação à granularidade das informações tratadas, ao fornecimento dessas informações
aos usuários finais e à durabilidade das mesmas.
Usuários que interagem de forma síncrona estão interessados em eventos que estejam ocorrendo no
espaço de trabalho compartilhado no momento atual e com notificação imediata dos mesmos. Essa
percepção possibilita que os usuários tenham uma mesma visão da área de trabalho (WYSIWIS – What
You See Is What I See) (Gutwin e Greenberg, 2002). Assim, os eventos estão relacionados a ações de
movimentação dos usuários pelo espaço de trabalho, sua disponibilidade para interação, e ações de baixa
granularidade tais como movimentações do mouse e cursor e alterações na posição da barra de rolagem.
As informações de percepção geradas para apoiar esse tipo de interação são efêmeras, necessitando baixa
ou nenhuma persistência. Seu armazenamento é apenas na memória dos participantes da interação ou na
gravação para reprodução posterior.
No modo de trabalho assíncrono, os participantes geralmente são informados sobre interações das
quais os mesmos não tenham participado, em um momento posterior à ocorrência das mesmas. O suporte
à percepção é derivado de uma interpretação resumida de uma seqüência completa de eventos ocorridos
no espaço de tempo (Fussel et al., 1995). As informações geradas devem estar em um nível mais macro,
respondendo a questões do tipo “quem está responsável por uma atividade”, “qual o prazo limite para o
término da mesma”, ou um resumo das últimas ações executadas sobre um determinado artefato. Para
possibilitar notificação posterior, as informações de percepção necessitam de alta persistência, pelo
menos até que todos os indivíduos que tenham interesse nas mesmas tenham sido notificados.
Como os usuários em sistemas colaborativos costumam alternar momentos de interação síncrona e
assíncrona, um mecanismo de percepção efetivo deve se preocupar com as questões de percepção
relativas aos dois modos de interação.
12
Papel desempenhado pelo participante no grupo
Um papel é um conjunto de privilégios e responsabilidades atribuídas a uma pessoa ou, algumas vezes, a
um módulo de um sistema (Ellis et al., 1991). Os participantes em uma equipe de trabalho, normalmente,
possuem atribuições e responsabilidades diferenciadas, e assumem uma determinada posição hierárquica
dentro do grupo. De uma forma geral, analisando-se equipes de trabalho, sem estabelecer um domínio
específico, identificam-se três níveis hierárquicos de papéis que podem ser atribuídos aos usuários:
Nível operacional: composto pelos usuários responsáveis pela execução do trabalho;
Nível tático: formado por coordenadores, cuja responsabilidade é acompanhar, controlar e
gerenciar as atividades executadas pelos operadores, estimular a interação, resolver possíveis
conflitos e garantir que o grupo siga uma metodologia de trabalho;
Nível estratégico: ocupado por pessoas que definem metas e objetivos para o grupo, traçam
processos e estratégias de ação, e identificam boas práticas ou práticas a ser evitadas pelo grupo,
com base em análises sobre o histórico de ações do grupo.
A necessidade de percepção de cada um desses usuários é bastante diferente. Operadores desejam
receber informações relacionadas às suas próprias atividades e a artefatos de seu interesse. Assim,
necessitam saber, por exemplo, o que aconteceu nos artefatos em que estavam trabalhando em períodos
de ausência, e quem modificou ou acessou os artefatos (Kirsch-Pinheiro, 2001).
Por outro lado, os coordenadores não têm interesse em informações muito detalhadas sobre cada
atividade executada por cada participante dentro do grupo. Esses usuários desejam visões de alto nível
dos dados, através de resumos e agregações, de modo a reduzir a sobrecarga de informação e possibilitar
reflexão sobre mudanças nas ações, preferências, comportamento e desempenho do grupo (Borges e Pino,
1999; David e Borges, 2001). Através de uma distribuição gráfica das contribuições dos participantes, o
coordenador pode identificar aqueles que estão trabalhando mais intensamente no processo. Taxas altas
ou baixas de contribuição devem ser analisadas pelo coordenador, de modo a motivar ou inibir novas
contribuições a determinados assuntos.
Já os analistas estratégicos atuam em um nível acima dos demais, numa posição de observador do
que ocorre, em geral, sobre mais de um grupo de trabalho. Nos sistemas colaborativos pode-se alcançar
esse tipo de percepção através de consultas analíticas sobre os dados históricos de interação do grupo,
usando, por exemplo, ferramentas de processamento analítico (OLAP) sobre data warehouses que
contenham informações de percepção, como o cubo de percepção proposto em (Vieira, 2003).
2.3.4. Percepção Periférica e Sobrecarga de Informações
Ser notificado sobre tudo e qualquer coisa que aconteça no contexto do grupo pode provocar problemas
como a sobrecarga de informações ou o desvio constante da atenção do usuário e, conseqüente, perda de
foco. Sistemas colaborativos devem prover mecanismos que permitam que as informações de percepção
sejam passadas aos usuários de forma não perturbadora. Os usuários não devem ter que se focar de
13
maneira explícita na informação apresentada, nem interromper sua atividade atual para ver o que está
acontecendo. Deve ser algo intuitivo, e ao mesmo tempo informativo. Como ocorre com os pilotos de
avião ou motoristas de carro. A tarefa principal de um motorista é guiar o carro, seguindo um
determinado trajeto para chegar a um destino. Durante a realização dessa tarefa, no entanto, ele precisa
ser notificado sobre diversas informações relativas ao seu contexto atual e ao contexto de sua tarefa. Por
exemplo, ele observa placas de trânsito que indicam situações da pista, direções, localidades e distâncias,
e informações do próprio carro como nível do combustível, velocidade e quilometragem percorrida. Em
uma situação específica, como na presença de um radar eletrônico de velocidade, ele recebe a notificação
da presença do radar e o indicativo da velocidade máxima permitida. Imediatamente, ele olha para o
velocímetro e conduz o carro a uma velocidade abaixo da máxima permitida. Percebe-se, nesse exemplo,
que o motorista é submetido a um grande número de informações com a finalidade de auxiliá-lo em sua
tarefa principal: dirigir. Percebe-se, ainda, que essas informações são passadas ao motorista de forma
rápida, fácil e intuitiva, visando desviá-lo minimamente de sua atenção à pista e ao controle do carro: seus
focos principais de atenção. Isso é possível porque essas informações são submetidas à visão periférica do
usuário. O mesmo deve ocorrer nos sistemas colaborativos em relação às informações de percepção. Daí
o termo percepção periférica.
Para alcançar uma percepção periférica efetiva os sistemas devem reforçar padrões e convenções,
oferecendo dicas na interface com o usuário, como uso de cores, tamanho dos objetos ou
aproximação/afastamento de artefatos (Mark et al., 1997). Filtrar informações irrelevantes para o usuário
e garantir a percepção periférica tem uma relação muito direta com o contexto atual do usuário (quem ele
é e o que está fazendo) e com o contexto da tarefa em curso.
2.3.5. Mecanismos Genéricos de Percepção
Uma abordagem promissora em mecanismos de percepção é a de infra-estrutura de percepção genérica e
extensível que inclua mecanismos simples e leves para a geração e apresentação de notificações
configuráveis aos usuários e que possam ser reutilizados por diferentes sistemas colaborativos em
situações diversas (Prinz, 1999). Algumas propostas de mecanismos genéricos de percepção incluem a
infra-estrutura NESSIE (Prinz, 1999), o framework BW (Kirsch-Pinheiro et al., 2002) e o mecanismo
Ariane (Vieira et al., 2004), descritos a seguir.
NESSIE
NESSIE (awareNESS envIronmEnt) (Prinz, 1999) é uma infra-estrutura genérica de percepção,
independente de um sistema colaborativo específico, que inclui mecanismos para geração e apresentação
de notificações configuráveis aos usuários. Uma questão de projeto estabelecida pelos pesquisadores da
NESSIE é que eventos relevantes sobre as atividades do usuário possam ser externalizados de uma
aplicação e promovidos para outras aplicações. Dessa maneira, NESSIE funciona como uma ponte para
diferentes aplicações e configurações.
14
A Figura 2.5 apresenta uma visão geral da arquitetura da NESSIE. As informações relativas à
atividade colaborativa, para fins de percepção, são capturadas por meio da geração de eventos. A
aquisição e geração dos eventos são habilitadas através da implementação de sensores, associados a atores
ou artefatos compartilhados. Os sensores são os responsáveis pela criação dos eventos. Após a criação,
um evento é transmitido para o servidor de percepção, o qual é responsável pela propagação,
transformação e notificação dos eventos. Diferentes sensores podem ser usados para integração a outras
aplicações.
Figura 2.5 – Visão geral da arquitetura da infra-estrutura NESSIE (Prinz, 1999)
NESSIE utiliza o método baseado em perfis de interesse para especificar a informação de
percepção que alguém está interessado. Estudos empíricos mostram que perfis de interesse constituem
uma boa abordagem para a seleção de informações de percepção (Sohlenkamp et al., 2000). A
apresentação da informação é feita através de indicadores configuráveis. Os eventos de atividade são
mapeados a indicadores apropriados.
NESSIE concentra-se no apoio a eventos de ações relevantes que aumentam a percepção social e a
percepção de tarefas relativas à colaboração. Eventos técnicos do tipo movimentação do mouse ou da
barra de rolagem não são tratados. Uma interface CGI/HTTP permite a comunicação entre aplicações e o
servidor NESSIE, de modo que qualquer aplicação possa reportar eventos ou receber notificações do
servidor. A principal desvantagem dessa abordagem é que a aplicação deve dirigir-se explicitamente ao
servidor NESSIE para informar a ocorrência de eventos ou para consumir novos eventos. Desse modo, os
eventos são gerados através de chamadas explícitas da aplicação monitorada ou através de um cliente
NESSIE específico.
BW (Big Watcher)
O BW (Kirsch-Pinheiro et al., 2002) é um framework de apoio à percepção de eventos ocorridos no
passado, voltado para interações assíncronas. BW utiliza percepção baseada em notificação de eventos
executada segundo um ciclo em três fases: registro-ocorrência-notificação (Figura 2.6). Na primeira fase,
o sistema colaborativo registra no framework os tipos de eventos que têm interesse para os propósitos de
15
percepção, passando, para isso, uma instância de exemplo de cada evento desejado para ser usado pelo
BW. Na segunda fase, os usuários interagem com o sistema para execução de suas atividades. O sistema
monitora as atividades de interesse para fins de percepção, gera os eventos correspondentes a cada
atividade monitorada e envia esses eventos para o BW. Na última fase do ciclo, os eventos ocorridos são
repassados do BW para o sistema colaborativo para que as informações de percepção sejam enviadas e
apresentadas aos usuários. Para minimizar a sobrecarga de informação, o BW utiliza filtros baseados em
perfis de interesse.
Figura 2.6 - Ciclo Registro-Ocorrência-Notificação do Framework BW (Kirsch-Pinheiro et al., 2002)
Ariane
Ariane (Vieira et al., 2004) é uma infra-estrutura de apoio à percepção que visa ampliar a oferta de
informações de percepção em sistemas colaborativos a partir do monitoramento do seu processo de
persistência. Para isso, ela utiliza a abordagem de monitoramento baseado em sensores, os quais são
acoplados ao mecanismo de persistência da aplicação. Ariane baseia-se na notificação de eventos para
prover a percepção. Ações ocorridas no ambiente colaborativo são convertidas em mensagens que contêm
as informações de percepção 5W+1H. O processo de gerenciamento das informações de percepção
consiste de quatro etapas: produção, distribuição, consumo e análise de eventos as quais se dividem em
dez atividades, como mostra a Figura 2.7.
A produção dos eventos ocorre com o monitoramento da comunicação entre a aplicação e o banco
de dados e captura de ações executadas pelos usuários (chamados produtores da informação de
percepção). A ação capturada é convertida em um evento no formato 5W+1H e armazenado em um banco
de dados de eventos. A etapa de distribuição consiste na notificação dos eventos gerados a componentes
de percepção previamente registrados. A etapa de consumo é o uso e apresentação da informação de
percepção pela aplicação aos demais usuários do grupo (denominados consumidores da informação de
percepção). Por fim, a etapa de análise implica em preparar os eventos persistidos para uso por
ferramentas de processamento analítico (OLAP - On-Line Analytical Process). Para isso, os eventos
passam pelo processo ETL (Extract-Transform-Load) e são extraídos do BD de eventos, transformados
16
para o modelo multidimensional e carregados em uma estrutura chamada cubo de percepção. Sobre o
cubo de percepção, ferramentas OLAP podem permitir que usuários analistas realizem consultas
analíticas sobre as ações realizadas pelos participantes do grupo e que técnicas de mineração de dados
sejam utilizadas sobre o histórico de eventos.
Figura 2.7 - Processo de gerenciamento das informações de percepção usado em Ariane (Vieira, 2003)
Os sensores, em Ariane, foram implementados como aspectos. Essa abordagem possibilita uma
maior interoperabilidade, permitindo que os sensores possam ser acoplados a diferentes aplicações, de
forma não intrusiva. Aspectos fazem parte do paradigma de desenvolvimento de aplicações chamado
Programação Orientada a Aspectos (AOP – Aspect Oriented Programming) (Kiczales et al., 1997) e
representam as características que atravessam as funcionalidades básicas de um sistema, ou seja, estão
presentes em diversos componentes do sistema.
2.4. CONSIDERAÇÕES FINAIS
Este capítulo apresentou alguns conceitos relacionados a sistemas colaborativos. O objetivo foi definir a
área da computação onde este trabalho se insere e prover uma base para a compreensão dos conceitos
que serão tratados a seguir. Foi apresentado o modelo 3C de colaboração que divide o suporte ao trabalho
colaborativo em três vertentes: comunicação, coordenação e cooperação. A questão da percepção em
groupware foi detalhada com discussão sobre definições, benefícios e desafios envolvidos, e alguns
mecanismos genéricos para tratamento da informação de percepção foram abordados.
A sub-seção que trata sobre percepção utiliza muitas vezes a palavra contexto para indicar sobre o
que a percepção se refere (“contextualizar os usuários”) ou para restringir a informação de percepção
17
(percepção periférica). Percebe-se, assim, uma forte relação entre os conceitos de percepção e contexto,
embora essa relação não seja explícita e não referencie os estudos sobre contexto realizados em outras
áreas, como Inteligência Artificial (Brézillon, 1999a) Computação Ciente de Contexto (Dey e Abowd,
2000) e Interface Humano-Computador (Dourish, 2001).
O próximo capítulo descreve contexto como um conceito computacional considerando os estudos
realizados nessas outras áreas.
18
CAPÍTULO 3
Contexto Computacional
Nas mais diversas situações do dia a dia as pessoas fazem uso do conhecimento do contexto para
delimitar e direcionar ações e comportamentos. As mensagens trocadas para comunicação trazem junto
um contexto associado que apóia a compreensão do seu conteúdo. Contexto ajuda a melhorar a qualidade
da conversação e a compreender certas situações, ações ou eventos. Comumente, a palavra contexto é
usada para restringir a situação da qual se está falando. Por exemplo, ao falar sobre Xuxa, sem conhecer o
contexto da conversa, não se sabe se o assunto em questão é a apresentadora de televisão, o nadador ou
um animal de estimação. Se o contexto considerado é relativo a esportes, provavelmente o assunto é o
Fernando Scherer, o Xuxa, o nadador. Uma ação de “abrir uma janela” pode levar a ambigüidade na
compreensão da mensagem caso não fique claro se a janela em questão trata-se de uma janela física do
mundo real, ou uma janela virtual de um ambiente gráfico de computador.
Contexto é o que está por trás da habilidade de discriminar o que é ou não é importante e permite
que os indivíduos enriqueçam seu conhecimento sobre uma determinada situação através de suas
memórias e experiências relacionadas a essa situação (Belotti et al., 2004a). Dessa forma, o contexto
permite gerenciar a grande quantidade de informação que cerca os indivíduos em um dado instante.
Embora seja um conceito presente e conhecido nas interações entre pessoas, contexto ainda é um
tópico pouco explorado nas interações entre pessoas e computadores. Os sistemas computacionais, em
geral, não levam em consideração o contexto do usuário com quem estão interagindo, e atuam de uma
mesma maneira, pré-programada, sem discriminar as necessidades e restrições correntes do usuário. Por
exemplo, se uma criança e um esportista consultam um mesmo engenho de busca procurando por
informações sobre Xuxa, muito provavelmente receberão o mesmo conjunto de respostas. O
conhecimento do contexto permite que o sistema ofereça serviços e informações relevantes para o
usuário. Se o engenho de busca do exemplo conhecesse o contexto de cada usuário, poderia priorizar
informações sobre Xuxa, o nadador, na consulta feita pelo esportista.
Contexto desempenha um papel importante em qualquer domínio que envolva requisitos como
compreensão, raciocínio, resolução de problemas ou aprendizado (Santoro et al., 2005). Contexto é uma
importante ferramenta para apoiar a comunicação entre pessoas e sistemas computacionais pois ajuda a
diminuir ambigüidades e conflitos, aumenta a expressividade dos diálogos, e possibilita a melhoria dos
serviços e informações oferecidos pela aplicação. Com isso, a tendência é que as aplicações se tornem
mais amigáveis, flexíveis e fáceis de usar.
O reconhecimento da importância do contexto motivou pesquisadores de diversas áreas da
computação, como Inteligência Artificial, Interface Homem-Máquina, Computação Ubíqua, Engenharia
de Software, Banco de Dados e Sistemas Colaborativos, a estudar esse conceito e entender como o
19
mesmo pode ser formalizado e utilizado nos sistemas computacionais. Assim, este capítulo apresenta
contexto como um conceito computacional, discute definições para contexto e para computação ciente de
contexto e aborda alguns requisitos e desafios na construção de sistemas que tratem o contexto dos
usuários.
3.1. DEFINIÇÕES DE CONTEXTO
A definição do que é contexto e o que ele engloba, pensando em sistemas computacionais, ainda não é um
consenso entre os pesquisadores. Existem várias definições para esse conceito, algumas complementares,
outras limitadas à área da computação que buscam apoiar. Bazire e Brézillon (Bazire e Brézillon, 2005)
coletaram um conjunto de aproximadamente 150 definições de contexto, vindas de diferentes domínios e
chegaram a duas conclusões principais desses trabalhos: (1) o contexto atua como um conjunto de
restrições que influenciam o comportamento de um sistema embutido em uma dada tarefa; e (2) a
definição de contexto depende da área de conhecimento à qual pertence.
Uma definição clássica e bastante referenciada é proposta por Dey e Abowd, para os quais:
“Contexto é qualquer informação que caracteriza a situação de uma entidade, onde uma
entidade é uma pessoa, lugar ou objeto considerados relevantes para a interação entre um
usuário e uma aplicação, incluindo o próprio usuário e a aplicação. O contexto é tipicamente
a localização, a identidade, e o estado das pessoas, grupos e objetos físicos e
computacionais” (Dey e Abowd, 2000).
Na área da Inteligência Artificial, Brézillon define contexto como “o que restringe a solução de um
problema, sem entretanto interferir nele explicitamente” (Brézillon, 1999a) ou “uma coleção de condições
relevantes e influências que tornam uma situação única e compreensível” (Brézillon, 1999b).
Gross e Prinz, na área de Sistemas Colaborativos, definem contexto como “as condições (i.e.,
circunstâncias como tempo e localização) inter-relacionadas (i.e., algum tipo de continuidade no sentido
mais amplo) na qual alguma coisa (e.g., um usuário, um grupo ou um artefato) existe (e.g., presença) ou
ocorre (e.g., uma ação executada por um ator)” (Gross e Prinz, 2003).
Rittenbruch, em seu trabalho sobre o uso de contexto para percepção seletiva, define contexto
como “uma descrição complexa de conhecimento compartilhado sobre circunstâncias físicas, sociais,
históricas e outras dentro das quais uma ação ou evento ocorre” (Rittenbruch, 1999; Rittenbruch, 2002).
Alarcón et al. argumentam que a pesquisa sobre contexto concorda em dois aspectos: primeiro, o
contexto é relativo a tudo que cerca alguma coisa, onde essa coisa é uma situação, uma atividade, uma
idéia, porém não a coisa em si. Segundo, o contexto compreende um conjunto de elementos inter-
relacionados que mantém um relacionamento coerente, onde tal relacionamento traz um significado
específico para a coisa, por exemplo uma situação, uma atividade, uma idéia (Alarcón et al., 2005a).
20
Quanto aos elementos que o contexto engloba, Greenberg diz que o contexto deve ser visto como
uma construção dinâmica e deve ser analisado segundo cinco dimensões: tempo, episódios de uso,
interações sociais, objetivos internos e influências locais (Greenberg, 2001). Em algumas situações os
elementos de contexto são estáveis, previsíveis e compreensíveis. Porém, existem situações em que
elementos muito semelhantes caracterizam contextos bem diferentes, como é o caso quando considerada a
dimensão tempo. Dois contextos exatamente iguais, porém que ocorram em instantes diferentes de tempo,
podem não possuir o mesmo significado e devem exigir um tratamento diferenciado.
3.2. COMPUTAÇÃO CIENTE DE CONTEXTO
Os estudos sobre contexto motivaram o surgimento de uma nova comunidade preocupada com o projeto e
desenvolvimento de aplicações e sistemas cientes de contexto (context-aware). Esse termo foi cunhado
pela primeira vez, associado à área de computação móvel, no trabalho de Schilit et al. (Schilit et al., 1994)
e refere-se a sistemas que “utilizam o contexto para fornecer informações e/ou serviços relevantes para o
usuário, onde relevância depende da tarefa do usuário” (Dey e Abowd, 2000). Um ponto crítico nessa
definição é o que exatamente considerar como contexto e como identificar a relevância.
Dentre as funcionalidades que um sistema ciente de contexto deve apoiar estão a apresentação de
serviços e informações relevantes a um usuário, a execução automática de um serviço e a ligação de
contexto a informações para apoiar recuperações posteriores (Morse et al., 2000).
A computação ciente de contexto vem atraindo a atenção de diversos pesquisadores desde que foi
proposta. Diversos sistemas cientes de contexto foram desenvolvidos, principalmente no domínio da
computação ubíqua, onde o uso do contexto é fundamental para garantir os requisitos de computação
disponível no lugar certo e na hora certa. Exemplos desses sistemas incluem: ferramentas de apoio a
ambientes de escritório, como Active Badges (Want et al., 1992) e ParcTab (Schilit e Want, 1995); guias
turísticos, como Travel Mate (Furtado et al., 2005) e GUIDE (Cheverst et al., 2000); guia de participantes
em conferências e eventos, como Conference Assistant (Dey et al., 1999a) e CoBrA (Chen, 2003);
assistentes inteligentes em ambientes hospitalares (Muñoz et al., 2003; Bardram, 2004); e serviços para
dispositivos em casas inteligentes (Wang et al., 2004).
Existe um interesse crescente em aplicar o conceito de contexto a outros domínios, como sistemas
colaborativos. Isso pode ser observado em diversos trabalhos recentes que abordam o assunto {Borges,
2006 32 /id;Brézillon, 2004 43 /id;Santoro, 2005 235 /id;Rosa, 2005 228 /id;Alarcón, 2005 5 /id;Kirsch-
Pinheiro, 2005 200 /id;Gross, 2003 112 /id;Vieira, 2005 268 /id;Vieira, 2005 269 /id}. O conceito de
contexto já aparece há bastante tempo nas pesquisas sobre CSCW, porém sob a forma de outros conceitos
como informações de percepção e memória do grupo (Borges et al., 2004).
A construção de sistemas cientes de contexto ainda é uma tarefa complexa e que consome bastante
tempo. A modelagem, representação e uso de contexto parece ser o desafio dos próximos anos,
especialmente quando considerado problemas muito complexos e grandes bases de conhecimento
21
(Brézillon, 1999b). Diversos são os requisitos e desafios no desenvolvimento desse tipo de aplicação, os
quais serão discutidos na próxima seção.
3.3. REQUISITOS PARA DESENVOLVIMENTO DE SISTEMAS CIENTES DE CONTEXTO
O desenvolvimento de sistemas cientes de contexto apresenta diversos desafios, dentre eles: (i) a
caracterização dos elementos de contexto para uso na aplicação; (ii) a aquisição do contexto a partir de
fontes heterogêneas, tais como sensores físicos, bases de dados, agentes e aplicações; (iii) a representação
de um modelo semântico formal de contexto; (iv) o processamento e interpretação das informações de
contexto adquiridas; (v) a disseminação do contexto a entidades interessadas de forma distribuída e na
hora certa; (vi) o tratamento da qualidade da informação contextual; (vii) o tratamento de questões como
segurança e privacidade; e (viii) o tratamento do desempenho do sistema, uma vez que a inclusão do
contexto demanda um custo computacional extra para a aplicação.
As próximas subseções apresentam um processo para construção de sistemas cientes de contexto
seguido da discussão sobre os requisitos inerentes ao desenvolvimento desses sistemas.
3.3.1. Processo para a Construção de Sistemas Cientes de Contexto
Um processo para a construção de sistemas cientes de contexto foi proposto por Dey e visa facilitar a
compreensão das dificuldades inerentes à construção desses sistemas (Dey, 2000). O processo é composto
por 5 etapas principais, como descrito a seguir:
1. Especificação: visa especificar o problema a ser resolvido e propor uma solução de alto nível
1.1. Especificar que comportamento ciente de contexto deve ser implementado;
1.2. Determinar que elementos de contexto são necessários para que esses comportamentos sejam
executados, utilizando mecanismos existentes de aquisição de contexto.
2. Aquisição: determinar que sensores são necessários para prover o contexto
2.1. Instalar o sensor;
2.2. Compreender que tipo de dado é provido pelo sensor;
2.3. Caso não exista uma interface de programação de aplicações (API), escrever o programa que
permita se comunicar com o protocolo utilizado pelo sensor;
2.4. Se existir a API, aprender a usá-la para se comunicar com o sensor;
2.5. Determinar como consultar o sensor e como ser notificado quando mudanças ocorrerem;
2.6. Armazenar o contexto;
2.7. Interpretar o contexto, se aplicável.
3. Disseminação: prover métodos para apoiar a disseminação do contexto a uma ou mais aplicações,
possivelmente remotas.
4. Recepção: adquirir e trabalhar com o contexto
4.1. Determinar onde estão os sensores relevantes e como se comunicar com eles;
4.2. Requisitar e receber o contexto;
22
4.3. Converter o contexto em uma forma utilizável através de interpretação;
4.4. Analisar a informação para determinar sua utilidade.
5. Ação: verificar se o contexto é útil e executar o comportamento ciente de contexto
5.1. Analisar o contexto, tratando-o como uma variável independente ou combinando-o com outras
informações coletadas;
5.2. Escolher o comportamento ciente de contexto a executar.
Esse processo possui algumas limitações, como: (i) não explora a importância de existir um modelo
de representação global do contexto e a necessidade de converter dados locais adquiridos pelos sensores
para se adequar aos elementos definidos nesse modelo; (ii) é dada pouca ênfase à etapa de interpretação
do contexto que, no entanto, é fundamental para seu tratamento; (iii) considera apenas a aquisição do
contexto por sensores, o que é muito limitante, pois muitas informações contextuais podem ser obtidas de
dados históricos persistidos em modelos da aplicação, ou podem ser providos pelo próprio usuário, por
meio do preenchimento de perfis ou outros formulários.
3.3.2. Identificação dos Elementos de Contexto
Um grande desafio ao desenvolver um sistema ciente de contexto é delimitar as ações dependentes de
contexto nesses sistemas e identificar os elementos contextuais que caracterizam a situação na qual essas
ações são executadas. Estudos mostram que a identificação dos elementos de contexto depende
fortemente do tipo da tarefa e domínio em questão (Öztürk e Aamodt, 1997). Por outro lado, o papel que
o contexto desempenha pode ser generalizado sobre tarefas e domínios específicos.
O contexto é uma construção dinâmica e, embora em algumas situações o contexto seja
relativamente estável e previsível, existem muitas outras onde isso não acontece. Na maioria dos casos é
muito difícil, ou mesmo impossível, para o projetista de uma aplicação ciente de contexto enumerar o
conjunto de estados contextuais que podem existir na aplicação, identificar que informação pode
determinar com precisão um estado contextual desse conjunto, e definir que ações devem ser executadas
em um estado particular (Greenberg, 2001).
Algumas classificações para as informações contextuais foram propostas na literatura com o
propósito de apoiar a identificação dos elementos de contexto. Uma dessas classificações divide as
informações contextuais em: (1) contexto primário, ou básico, ou de baixo nível; e (2) contexto complexo,
ou de alto nível (Wang et al., 2004). A primeira indica elementos contextuais que podem ser percebidos,
automaticamente, por sensores físicos ou lógicos, e a segunda refere-se a informações de contexto
fornecidas pelo próprio usuário ou deduzidas, por motores de inferência, a partir de um conjunto de
informações de contexto de baixo nível.
Exemplos de contextos básicos incluem identidade (de atores ou dispositivos), atividade atual (que
pode ser uma etapa em um processo ou um passo em um workflow), localização (geográfica ou virtual),
tempo (ex. dia, hora, estação do ano), condições ambientais (ex. temperatura, qualidade do ar, luz, som),
disponibilidade de recursos (ex. bateria, largura de banda, tamanho da tela), recursos próximos (ex.
23
dispositivos acessíveis, impressoras, hosts), medidas fisiológicas (ex. pressão sanguínea, batimento
cardíaco, atividade muscular, tom de voz), entre outros.
Contextos complexos podem ser, por exemplo, a situação do indivíduo (ex. se está falando, lendo,
caminhando ou escrevendo), situações sociais (ex. com quem o usuário está, quem são as pessoas
próximas), atividades sociais (ex. se o usuário está em reunião ou ministrando aula), entre outras. Para
identificar, por exemplo, se um usuário está ministrando uma aula, pode ser criada uma regra lógica que
obtenha como contextos básicos a identificação da sala onde ele se encontra, a indicação se existem
outras pessoas na sala, a posição do usuário em relação a essas pessoas e se existe um programa de
apresentação rodando em um micro instalado na sala.
Greenberg indica que o contexto varia em 5 dimensões: período de tempo, episódios de uso
anteriores conhecidos pela pessoa, estado das interações sociais, mudanças nos objetivos internos, e
influências do local onde a pessoa se encontra (Greenberg, 2001).
Uma outra classificação para as informações de contexto separa o contexto em porções estáticas e
dinâmicas (Gauvin et al., 2004). A porção estática inclui os parâmetros externos, gerais e relativamente
fixos, relacionados ao trabalho do usuário. A porção dinâmica é composta por uma memória dinâmica das
ações do usuário, continuamente atualizada quando mudanças, eventos, atividades ou padrões aprendidos
de ações ocorrem durante a execução do trabalho.
Korpipää et al. definiram alguns critérios para a identificação do que escolher como elemento
contextual ao construir uma aplicação ciente de contexto: (i) habilidade para descrever propriedades úteis
do mundo real; (ii) habilidade para inferência de contextos complexos; (iii) facilidade ou viabilidade de
ser medido ou reconhecido, automaticamente, de forma o mais precisa e não ambígua possível (Korpipää
et al., 2003).
Rosa et al. propõem um framework conceitual de contexto para sistemas colaborativos que
classifica as informações de contexto em cinco categorias principais: (i) informações sobre as pessoas e
os grupos; (ii) informações sobre tarefas agendadas; (iii) informações sobre o relacionamento entre
pessoas e tarefas; (iv) informações sobre o ambiente onde ocorre a interação; e (v) informações sobre
tarefas e atividades concluídas (Rosa et al., 2003).
Em colaboração, Brézillon et al. distinguem o contexto do grupo, do projeto e do indivíduo como
elementos contextuais (Borges et al., 2004). Brézillon e Araújo consideram, ainda, o contexto
organizacional, ou seja a empresa onde a equipe trabalha e o mercado onde concorre (Brézillon e Araújo,
2005).
De uma maneira genérica, as informações de contexto referentes a uma ação ou tarefa podem ser
identificadas a partir da resposta às seis perguntas 5W+1H apresentadas na Seção 2.3.1, equivalentes às
informações de percepção em groupware (Vieira, 2003; Brézillon et al., 2004).
24
3.3.3. Modelo de Classificação do Contexto
Brézillon e Pomerol propõem um modelo de classificação segundo o qual o contexto sempre está
relacionado a um foco de atenção, que pode ser, por exemplo, uma tarefa, a solução de um problema ou
uma tomada de decisão (Brézillon e Pomerol, 1999; Brézillon, 1999b). O foco determina o que deve estar
em seu contexto, e o contexto ajuda a restringir o foco. No trabalho colaborativo, todos os membros da
equipe devem possuir um mesmo foco que depende do foco da equipe (Brézillon e Araújo, 2005). O foco
de atenção corresponde a um dado estágio do trabalho onde um subconjunto da informação contextual é
mobilizada, situada, organizada e estruturada para alcançar um resultado relevante e significativo (Gauvin
et al., 2004).
Brézillon e Pomerol dividem o contexto, relativo a uma etapa de uma tarefa, em três partes distintas
(Brézillon e Pomerol, 1999), como mostra a Figura 3.1:
Conhecimento contextual (CK): é o conhecimento relevante para o foco de atenção, que tem
uma forte relação com o foco, porém não é considerado diretamente nele;
Conhecimento externo (EK): é a parte do contexto que não é relevante para o foco de atenção,
porém é compartilhada pelos membros do grupo. O CK em um foco pode se tornar um EK em
um outro foco;
Contexto proceduralizado (PC): refere-se ao aspecto dinâmico do contexto. É a parte do CK que
é invocada, organizada, estruturada e situada de acordo com um dado foco de atenção, e
utilizada para apoiar a tarefa em execução naquele foco. Quando um evento imprevisível ocorre,
a atenção dos atores é focada nesse evento e uma parte do CK é proceduralizada. Quando a
tarefa prossegue para o próximo passo, esse PC passa a fazer parte do CK. À medida que as
tarefas e focos evoluem e mais PCs são produzidos, esses PCs são atribuídos ao CK de cada
indivíduo. Duas pessoas com um mesmo foco poderão construir diferentes PCs, pois elas
possuem diferentes conjuntos de CK e diferentes interpretações do foco (Brézillon e Araújo,
2005).
Conhecimento Externo
Foco
Contexto Proceduralizado
Conhecimento Contextual
Figura 3.1 – Tipos de Contexto e suas Dinâmicas {Brézillon, 1999 38 /id}
25
Brézillon propõe a divisão do contexto em dois diferentes níveis (Brézillon, 2003a). O primeiro é
denominado “in depth first” e define as diferenças nos contextos a depender da sua granularidade, do
mais geral para o mais específico. Assim, por exemplo, o contexto da organização é mais geral, enquanto
o contexto do empregado é mais específico. O outro nível foi denominado “in width first” e considera
contexto como um conjunto heterogêneo de contextos. Esse nível define que cada ator dentro de um dado
escopo possui seu próprio contexto individual. Por exemplo, um projeto de desenvolvimento de software
possui especialistas com diferentes experiências, habilidades e cultura (Santoro et al., 2005).
3.3.4. Aquisição do Contexto
A aquisição do contexto refere-se ao processo de monitorar, capturar e obter informações contextuais,
quer seja de um ambiente físico ou de outras fontes de contexto. Em (Chen, 2003) são apresentadas três
maneiras segundo as quais agentes podem adquirir contexto:
Acesso direto a sensores de contexto de baixo-nível (hardware);
Algum tipo de infra-estrutura que interage com sensores de contexto de baixo nível;
Através de servidores de contexto que mantêm conhecimento contextual sobre o ambiente.
Considerando a maneira como as informações contextuais podem ser obtidas, Gu et al. classificam
o contexto em duas categorias: direto e indireto (Gu et al., 2004c). O primeiro é adquirido explicitamente
por um provedor de contexto, que pode ser o próprio usuário, uma fonte interna (ex. provedor de
localização interna) ou uma fonte externa (ex. serviço de informação do tempo). O contexto indireto é
obtido por meio da interpretação de contextos diretos através de processos de agregação e raciocínio. Por
exemplo, as preferências de horário de trabalho de um grupo podem ser obtidas pela agregação das
preferências individuais de cada membro do grupo.
A Tabela 3.1 mostra uma classificação para as informações de contexto, segundo a qual a
informação pode ser percebida, estática, proveniente de perfil ou derivada (Henricksen, 2003). A tabela
indica, ainda, o nível de persistência de cada categoria de informação, questões que possam afetar sua
qualidade e as fontes de suas imperfeições.
Tabela 3.1 - Classificação das informações contextuais (Henricksen, 2003)
Classe da informação Persistência Questões de qualidade Fontes de imperfeição
Percebida Baixa Pode ser imprecisa, desconhecida ou caduca
Erros na percepção; falhas do sensor ou desconexões da rede; demoras introduzidas pela distribuição e processo de interpretação
Estática Alta Geralmente nenhuma Erro humano
Vinda de Perfil Moderada Tende a caducar Omissão do usuário em atualizar mudanças ocorridas
Derivada Variável Sujeita a erros e imperfeições
Entradas imprecisas; uso de um mecanismo de derivação imaturo ou muito simplificado
26
Informações percebidas são provenientes de sensores físicos ou lógicos. Informações estáticas
descrevem propriedades persistentes informadas pelo próprio usuário, como o tipo de um dispositivo de
computação ou canal de comunicação. Informações provenientes de perfil também são fornecidas pelo
usuário, mas podem ser obtidas automaticamente por aplicações como agenda e calendário. Elas
representam informações mais dinâmicas, como dados pessoais e preferências do usuário, associações
entre usuários e canais de comunicação, e relacionamentos entre pessoas. Informações derivadas são
determinadas pelas propriedades do dado de entrada e dos mecanismos de derivação.
Chen e Kotz apresentam alguns tipos de contexto, relativos ao domínio da computação ubíqua, e
formas de identificá-los (Chen e Kotz, 2000):
Localização: é o tipo de contexto mais estudado e aplicado nos sistemas cientes de contexto
atuais, devido aos requisitos da área de Computação Ubíqua. A localização se altera sempre que
o usuário se move e um serviço de monitoramento de localizações é crítico para algumas
aplicações. A forma mais fácil de obter informações de localização é obrigando que o próprio
usuário as informe, por exemplo, passando um cartão ou deixando uma impressão digital
sempre que entra ou sai de uma sala. O sistema pode, também, observar a que estação de
trabalho o usuário está conectado. Formas automáticas de obter a localização incluem o GPS
(Global Positioning System), para ambientes abertos, e sensores baseados em tecnologias como
raios infra-vermelho ou freqüência de rádio, para ambientes internos, como um edifício;
Tempo: pode ser obtido do relógio do computador. Em geral, as informações de localização são
acompanhadas de informações temporais;
Objetos próximos: a partir do monitoramento da localização de pessoas e outros objetos é
possível identificar quem e o que está próximo de um dado usuário;
Largura de banda: a largura de banda de uma rede pode ser percebida por sensores lógicos,
presentes nas máquinas, que sejam capazes de medir essa variável.
Em sistemas colaborativos, além dos sensores físicos devem ser considerados outros meios de
aquisição do contexto, tais como: sensores lógicos, que monitorem as atividades dos usuários no espaço
virtual compartilhado; a memória do grupo, que provê informação histórica sobre as interações do grupo;
modelos da aplicação, como perfis, modelos do usuário, da tarefa, do grupo, entre outros; e o próprio
usuário, através de interfaces como formulários ou botões, uma vez que nem toda informação pode ser
automaticamente adquirida.
3.3.5. Modelagem e Representação dos Elementos de Contexto
A maioria dos sistemas atuais utiliza modelagens próprias para os contextos, o que torna difícil, quase
impossível, o compartilhamento de informações contextuais entre diferentes sistemas. Com o avanço da
computação ciente de contexto, há um interesse crescente no desenvolvimento de modelos formais de
contexto que facilitem a representação, compartilhamento e interoperabilidade semântica do contexto
(Wang et al., 2004).
27
Existem diversas abordagens de modelos para representação do contexto, como pares de chave-
valor, linguagem de marcação, modelo orientado a objetos, modelo entidade-relacionamento, modelo
baseado em lógica, mapas de tópicos, grafos contextuais e ontologias (Chen e Kotz, 2000; Strang e
Linnhoff-Popien, 2004). Devido à relevância deste tópico para este trabalho, ele é explorado em detalhes
no Capítulo 4.
3.3.6. Processamento e Raciocínio sobre Contexto
Um dos principais problemas na utilização de informações contextuais é como obter contexto realmente
significativo para quem precisa utilizar essa informação, a partir de um conjunto de informações dispersas
e desconexas, obtidas por mecanismos heterogêneos de aquisição. Para isso, funcionalidades de
processamento e raciocínio sobre a informação contextual devem ser disponibilizadas. Questões como
tratamento da incerteza devem ser consideradas, pois como o contexto evolui bastante com o tempo é
difícil inferir com precisão qual é de fato o contexto atual da situação.
Os termos raciocínio e inferência são geralmente utilizados para indicar qualquer processo pelo
qual conclusões são alcançadas (Russell e Norvig, 2003). O projeto e implementação de um mecanismo
para raciocínio de contextos pode variar bastante a depender do tipo do conhecimento contextual
envolvido. Idealmente, o processamento do contexto deve ser implementado separadamente do
comportamento do sistema e não embutido no código da aplicação {Belotti, 2004 23 /id}.
O raciocínio é utilizado para checar a consistência do contexto e para inferir contexto implícito de
alto nível, a partir de contextos explícitos, de baixo nível (Wang et al., 2004). A consistência é necessária
pois, muitas vezes, a informação contextual adquirida automaticamente pode apresentar erros e
ambigüidades. Por exemplo, um sensor de presença pode detectar o celular de um usuário em sua casa e
deduzir que o mesmo está em casa. Porém, um outro sensor de presença baseado em câmeras detecta a
presença do usuário em seu escritório. Essas duas informações são conflitantes e precisam ser resolvidas.
Existem duas diferentes abordagens para inferir contexto de alto nível (Ranganathan e Campbell,
2003). A primeira utiliza regras estáticas, pré-definidas pelos desenvolvedores em lógica de primeira
ordem [ref], lógica de mais alta ordem [ref], lógica descritiva [ref], lógica temporal [ref] ou lógica fuzzy
[ref]. A segunda utiliza técnicas de aprendizagem como redes bayesianas [ref], redes neurais [ref] e
raciocínio baseado em casos [ref].
No raciocínio baseado em regras, cada regra possui uma prioridade associada, de modo que uma
possa ser escolhida caso mais de uma regra seja verdadeira ao mesmo tempo. Esse tipo de raciocínio tem
a desvantagem de exigir uma definição explícita das regras por humanos, além de não ser flexível e não
se adaptar a circunstâncias que mudam frequentemente (Ranganathan e Campbell, 2003). A utilização de
técnicas de aprendizado automático permite que a máquina aprenda um padrão ou uma regra, a partir de
um conjunto de dados de teste, em uma fase chamada de treinamento.
28
O modelo ontológico CONON processa o contexto usando predicados de primeira ordem, e duas
abordagens de raciocínio: baseada em lógica descritiva e baseada em lógica de primeira ordem (Wang et
al., 2004). A estrutura do predicado possui três campos: sujeito, objeto e verbo. Por exemplo, o contexto
de localização física – Wang está localizado em seu quarto – é descrito como (Wang, locatedIn,
Bedroom). A Tabela 3.2 apresenta algumas regras pré-definidas que inferem um contexto de alto nível
(situação do usuário) a partir de informações de baixo nível, em uma casa inteligente. As regras inferem
se o usuário está dormindo, tomando banho, cozinhando, vendo TV ou jantando.
Tabela 3.2 – Regras de raciocínio de contexto em lógica de primeira ordem (Wang et al., 2004)
A Figura 3.2 apresenta a formação de um contexto de alta ordem Outdoors a partir de um conjunto
de contextos atômicos, usando redes bayesianas (Korpipää et al., 2003). Os retângulos brancos
representam elementos atômicos de contexto, as caixas com cor mais clara (com rótulos como Dark e
Normal) representam valores de contexto, e as caixas com cor mais escura (contendo números nos
rótulos) contêm o grau de confiança para aquele contexto. Uma rede bayesiana classifica os valores de
confiança em uma das classes de entrada Indoors e Outdoors, para inferir se o usuário está em um
ambiente aberto ou em um ambiente fechado. Para isso, são analisados aspectos do ambiente que podem
ser medidos por sensores, como a luminosidade, umidade e temperatura.
3.3.7. Segurança e Privacidade
As informações pessoais de um usuário, como sua localização, preferências e perfil, em geral, são as mais
úteis para um sistema ciente de contexto (Chen, 2004). No entanto, o usuário pode temer que essas
informações sejam utilizadas para prejudicá-lo de alguma forma, como uma publicação indevida de
detalhes de suas atividades que deveriam ser mantidos em sigilo. Assim, o tratamento das informações
contextuais traz como desafio questões como segurança e privacidade.
29
Políticas de privacidade podem guiar os sistemas cientes de contexto no trato das informações dos
usuários. Uma política de privacidade consiste de um conjunto de regras que servem para controlar a
execução de ações pelos sistemas. Após o sistema aceitar uma política, ele concorda em reforçar essas
regras quando executar ações. Essas regras podem ser utilizadas para restringir o acesso a informações de
contexto por agentes humanos ou de software (Chen, 2004).
Figura 3.2 – Exemplo de geração de contexto de alta ordem usando redes bayesianas (Korpipää et al., 2003)
3.3.8. Qualidade do Contexto
As informações contextuais possuem uma alta probabilidade de imperfeição ou inconsistência, provocada
por imprecisões na aquisição e manutenção do contexto. Por exemplo, o contexto de localização de um
usuário pode se tornar desatualizado rapidamente quando ele se movimenta por diferentes salas. Sensores
físicos podem causar conflitos de contexto quando, por exemplo, um usuário guarda em sua pasta o
dispositivo que permite identificar sua posição geográfica, e deixa a pasta em uma sala e se locomove
para uma outra sala (Gu et al., 2004c).
Gu et al. definem restrições de qualidade que podem ser associadas aos elementos de contexto,
indicando a qualidade do contexto. Eles construíram uma ontologia extensível para representar os
elementos que indicam parâmetros de qualidade da informação, como mostra a Figura 3.3. Essa ontologia
apresenta alguns tipos de parâmetro, como: precisão (accuracy), que representa a faixa em termos de uma
medida; resolução (resolution), indica o menor elemento perceptível; certeza (certainty), relativa à
probabilidade de descrever o estado de estar correto e atual; tempo de produção (freshness), tempo de
vida médio de uma medida (Gu et al., 2004c).
Cada parâmetro é descrito por uma ou mais métricas de qualidade apropriadas que definem como
medir ou computar a qualidade do contexto em relação ao parâmetro. A métrica contém um valor, um
30
tipo e uma unidade. A Figura 3.3 ilustra o uso desses parâmetros para definir a qualidade do contexto de
localização de uma pessoa. A localização é percebida em termos de coordenadas com uma resolução de
50 metros e uma precisão de 0.79 (79%). Os parâmetros de qualidade do contexto auxiliam a detecção e
resolução de conflitos de contexto. Diferentes tipos de contexto possuem diferentes níveis de confiança,
como por exemplo, o contexto definido pelo usuário é mais confiável do que aquele percebido por um
sensor ou deduzido por uma máquina de inferência (Gu et al., 2004c).
Figura 3.3 – Ontologia de Qualidade de Contexto e Instância de Exemplo (Gu et al., 2004c)
3.3.9. Desempenho do Sistema Ciente de Contexto
Uma questão envolvida no processamento do contexto é o impacto dessa atividade sobre o desempenho
da aplicação. O raciocínio e inferência demandam um esforço extra que pode interferir na execução dos
processos específicos da aplicação. Em um estudo realizado sobre o modelo CONON para avaliar a
viabilidade do raciocínio lógico para o processamento do contexto foi avaliado um protótipo que
implementa dois raciocinadores de contexto: um baseado em lógica descritiva e outro baseado em lógica
de primeira ordem (Wang et al., 2004). Os raciocinadores foram construídos utilizando o Jena2 Semantic
Web Toolkit (Jena, 2006). As conclusões desse estudo indicaram que o desempenho em termos de tempo
de execução do raciocínio baseado em lógica depende de três fatores: o tamanho da informação
contextual, a complexidade das regras de raciocínio e a velocidade de processamento da máquina. Com
isso, o raciocínio de contexto é viável para aplicações não críticas em termos de tempo, porém em
aplicações críticas, como sistemas de navegação ou de segurança, deve ser controlado o tamanho do
conjunto de dados de contexto e a complexidade das regras implementadas (Wang et al., 2004).
3.4. SISTEMAS DE GERENCIAMENTO DE CONTEXTO
Sistemas de gerenciamento de contexto visam prover informações contextuais para apoiar o
desenvolvimento de diferentes aplicações cientes de contexto. Esse gerenciamento envolve a obtenção,
31
interpretação, armazenamento e disseminação da informação contextual, dinamicamente, e em tempo real
(Power, 2003).
Uma dificuldade no desenvolvimento de sistemas de gerenciamento de contexto é identificar, de
forma genérica, o que pode ser considerado como contexto, pois pode ser uma faixa muito ampla de
valores. Pouca informação pode ser de fato descartada ou considerada irrelevante (Power, 2003). Uma
característica importante sobre contexto é o problema da incerteza quanto à relevância da informação. É
difícil prever quais informações são relevantes para uma aplicação ciente de contexto antes da sua
construção. Dessa forma, o sistema de gerenciamento de contexto deve ser genérico o suficiente para lidar
com novas formas de contexto que serão apresentadas durante seu ciclo de vida (Power, 2003).
Alguns sistemas de gerenciamento de contextos conhecidos são o Context Toolkit (Dey et al.,
2001), GAIA (Román et al., 2002), SOCAM (Gu et al., 2004b), CoBrA (Chen et al., 2005), entre outros.
Esses sistemas são discutidos no Capítulo 5.
3.5. CONSIDERAÇÕES FINAIS
Este capítulo apresentou os conceitos relacionados a contexto computacional e as dificuldades e desafios
inerentes à construção de sistemas cientes de contexto. O objetivo foi prover uma base para compreensão
do conceito de contexto e sua aplicação à computação. Para isso, foi discutida a relevância do estudo de
contexto por pesquisadores da computação, foram apresentadas definições sobre contexto e sobre
computação ciente de contexto e foram descritos requisitos e desafios que devem ser considerados por
projetistas e desenvolvedores de aplicações cientes de contexto na construção desses sistemas.
Um requisito importante na construção de um sistema ciente de contexto e, principalmente, para
viabilizar o desenvolvimento de um sistema de gerenciamento de contextos é a existência de um modelo
formal de representação que permita a interoperabilidade e o compartilhamento de contextos entre
diferentes sistemas.
O próximo capítulo discute o problema de representação de contextos e apresenta uma visão geral
das diferentes abordagens encontradas na literatura.
32
CAPÍTULO 4
Abordagens para Representação do Contexto
Um sistema ciente de contexto requer que informações contextuais sejam trocadas e utilizadas por
diferentes entidades, como agentes humanos e de software, dispositivos e serviços, com uma mesma
compreensão semântica. Para isso, um modelo de contexto apropriado deve dar suporte à
interoperabilidade semântica e deve permitir que esquemas comuns sejam compartilhados entre as
diferentes entidades (Gu et al., 2004c).
Os modelos de representação do contexto podem ser formais ou informais (Wang et al., 2004).
Modelos informais são baseados em esquemas proprietários de representação e específicos para um
sistema. Logo, tornam difícil a compreensão do contexto por diferentes sistemas. Os modelos formais
empregam abordagens formais de modelagem para manipulação do contexto, de modo que o mesmo
possa ser utilizado, compreendido e compartilhado por diferentes sistemas.
A maioria dos sistemas cientes de contexto atuais modelam e representam o contexto apenas para
aplicações específicas. Falta a esses modelos formalidade e expressividade. Para aumentar o
compartilhamento das informações contextuais entre sistemas, deve ser utilizado um modelo formal de
representação do contexto que possibilite a estruturação das informações contextuais de forma genérica,
não dependente de uma aplicação específica, e que considere aspectos de interoperabilidade semântica
dos elementos de contexto.
A importância do tópico sobre modelagem e representação de contextos no desenvolvimento de
sistemas cientes de contexto é evidenciada por uma série de conferências científicas recentes direcionadas
especificamente a esse tema (Indulska e de Roure, 2004; Ko et al., 2005; Schulz et al., 2006; Indulska e
Nicklas, 2006; Euzenat et al., 2006; Ghidini et al., 2006).
As próximas seções apresentam algumas das abordagens para representação de contexto existentes
e frequentemente utilizadas pelos sistemas cientes de contexto.
4.1. MODELO BASEADO EM PARES DE CHAVE-VALOR
Essa abordagem de modelagem é a que utiliza a estrutura de dados mais simples para representar a
informação contextual. O contexto é representado através de pares compostos por uma chave, que
identifica o atributo de contexto, e por um valor associado a essa chave, como ilustra o exemplo na Figura
4.1. Nesse exemplo, existem três chaves: data, hora e localização, com os respectivos valores “após 16 de
Abril”, “entre 10 e 12 da manhã” e “sala 35”. Uma ação “chegada de uma pessoa” é associada a esse
contexto. Assim, quando o contexto for a presença de um indivíduo na sala 35, entre as 10 e 12 da manhã,
a partir do dia 16 de abril, o sistema irá executar um som que diga “bom dia”.
33
Figura 4.1 - Exemplo de uso da representação de contexto por par chave-valor
O modelo de chave-valor não considera qualquer tipo de hierarquia entre os atributos e, apesar de
ser um modelo bastante simples de utilizar e manipular, não permite estruturações mais sofisticadas que
habilitem algoritmos eficientes de recuperação de contexto (Strang e Linnhoff-Popien, 2004). Para
identificar o atributo de contexto, o algoritmo de recuperação mais utilizado é o algoritmo de casamento
de nomes (string matching), com um resultado exato de comparação (exact matching) (Strang e Linnhoff-
Popien, 2004).
Mesmo não sendo um modelo muito formal e sofisticado, o modelo de chave-valor ganha no
quesito simplicidade e facilidade de uso, e é um modelo comumente utilizado pelos sistemas operacionais
para armazenar variáveis de ambiente. Em Schilit et al. (Schilit et al., 1994) as informações contextuais
são armazenadas em variáveis de ambiente do sistema operacional. No Context Toolkit (Dey et al., 2001)
o contexto é armazenado sob a forma de pares de chave-valor definidas usando a linguagem de marcações
XML. O sistema de notificações ENI (Event and Notification Infrastructure) utiliza pares de chave-valor
para definir contextos de percepção, como mostra a Tabela 4.1 (Gross e Prinz, 2003). O CXMS (Context
Management System) é um sistema de gerenciamento de contexto que utiliza o modelo chave-valor e
justifica sua escolha pela simplicidade e facilidade de implementação (Zimmermann et al., 2005a).
Tabela 4.1 – Atributos (chaves) de Contextos de Percepção (Gross e Prinz, 2003)
4.2. MODELO BASEADO EM LINGUAGENS DE MARCAÇÃO
O modelo baseado em linguagens de marcação utiliza o padrão XML (eXtensible Markup Language) para
modelagem das informações contextuais. A característica principal de XML é ser uma estrutura de dados
hierárquica que contém rótulos de marcação com atributos e conteúdo. Além disso, por ser um padrão
amplamente reconhecido por diversos sistemas, XML facilita o compartilhamento das informações de
contexto por diferentes aplicações.
34
O modelo de representação baseado em XML tem sido utilizado para a modelagem de perfis. Um
exemplo é o CSCP (Comprehensive Structured Context Profiles) (Held et al., 2002). O CSCP é um
modelo desenvolvido em RDF (Resource Description Framework) que representa o contexto como perfis
de sessão (Figura 4.2). Os nomes dos atributos são interpretados de acordo com sua posição na estrutura
do perfil.
Figura 4.2 - Exemplo de Perfil usando CSCP (Strang e Linnhoff-Popien, 2004)
Uma outra abordagem de representação do contexto baseada em perfis e XML é o CC/PP Context
Extension (Indulska et al., 2003), uma extensão com atributos relacionados a contexto dos vocabulários
CC/PP (Composite Capabilities / Preferences Profile) (W3C, 2004) e UAProf (User Agent Profile)
(Wapforum, 2003). Esses atributos incluem, por exemplo, localização, características da rede, requisitos
da aplicação e informações sobre a sessão.
Essas abordagens procuram definir um vocabulário comum e extensível para representação do
contexto e tentam viabilizar sua utilização por diferentes sistemas. Entretanto, existem diversas
abordagens que utilizam XML para representar contexto, porém de forma proprietária, e limitada a um
pequeno conjunto de aspectos de contexto. Um exemplo é o sistema Cooltown da HP que propõe um
modelo de contexto baseado na Web onde cada objeto (pessoa, lugar ou coisa) possui uma descrição Web
correspondente que pode ser recuperada utilizando uma URL (Kindberg e Barton, 2001).
4.3. MODELO BASEADO EM REPRESENTAÇÕES GRÁFICAS
Gráficos ou diagramas são comumente utilizados para modelagem conceitual de sistemas, a fim de
identificar e especificar as funcionalidades desses sistemas, bem como para estabelecer a estrutura das
informações manipuladas. Por essa razão, alguns pesquisadores argumentam que modelos gráficos de
representação, como a UML e o ORM (Object-Role Modeling) são adequados para representar contextos.
UML (Unified Modeling Language) (OMG, 2006) é uma linguagem muito popular para
modelagem de dados e sistemas. Devido à sua natureza genérica, UML também é apropriada para a
modelagem de contextos (Strang e Linnhoff-Popien, 2004). Uma das extensões para representação de
contextos através da UML foi sugerida por Bauer (Bauer, 2003). Bauer argumenta que a representação do
35
contexto depende de como o contexto será utilizado. Se for utilizado para expressar o estado de uma
entidade pode ser suficiente representar o contexto em um diagrama de classes, porém se o contexto é
utilizado para caracterizar a disseminação de informações dependentes de contexto ou para direcionar as
interações com o usuário, o contexto deve ser representado em diagramas apropriados, como mostra a
Tabela 4.2. A Tabela 4.2 indica os procedimentos e tarefas relacionados ao contexto que podem ser
expressos com os diagramas. A Figura 4.3 apresenta um exemplo de um diagrama de casos de uso, que
mostra a interação entre usuários e o sistema ciente de contexto.
Tabela 4.2 – Diagramas da UML e sua finalidade na modelagem do contexto
Diagrama da UML Finalidade na modelagem do contexto Diagrama de Casos de Uso Modelar os atores envolvidos relacionados ou influenciados pelo contexto e suas
possibilidades de interação Diagrama de Componentes Modelar os sistemas envolvidos que contêm informações relacionadas ao contexto,
como bancos de dados, fontes de contexto, entre outros Diagrama de Classes Representar a informação estrutural do domínio. Modelar como o contexto está
estruturado. Diagrama de Seqüência Modelar cenários de ativação do contexto. O diagrama detalha o fluxo da informação
entre os sistemas envolvidos e exibe a seqüência de disseminação da informação.
Figura 4.3 – Exemplo de caso de uso genérico para um sistema ciente de contexto (Bauer, 2003)
ORM (Object-Role Modeling) (Halpin, 2006) é uma notação gráfica para modelagem conceitual de
sistemas de informação. Em ORM, o conceito básico é o fato. A modelagem de um domínio envolve a
identificação de tipos de fato apropriados e os papéis que tipos de entidade desempenham nesses fatos.
Henricksen et al. propuseram uma extensão à ORM para modelar contextos, denominada CML (Context
Modeling Language) (Henricksen et al., 2002). CML apóia projetistas na especificação dos requisitos de
uma aplicação ciente de contexto e modela o contexto em dois níveis: fatos e situações. A modelagem de
fatos provê construções para definir objetos sobre os quais a informação contextual é requerida e os tipos
de fatos de interesse para o objeto. A modelagem de situações descreve o contexto em um nível mais alto
de abstração, composto pelos tipos de fatos básicos e lógica de predicados.
A Figura 4.4 apresenta um exemplo de representação usando o modelo CML. Em CML, os
contextos são categorizados de acordo com sua persistência e origem, segundo a Tabela 3.1 de
classificação de contextos, apresentada na Seção 3.3.4. Assim, o contexto (ou fato) pode ser estático
36
(static fact type), se permanece inalterado enquanto a entidade que o descreve persistir, ou dinâmico. O
contexto dinâmico pode ser proveniente de perfil (profiled fact type), percebido (sensed fact type) ou
derivado (derived fact type). Um outro indicador de qualidade introduzido por Henricksen é um tipo de
fato histórico para cobrir o aspecto temporal do contexto (temporal fact type). Por fim, outra extensão
feita à ORM são dependências entre fatos (fact dependency), que indica que uma mudança em um fato
conduz a uma mudança automática em um outro fato, representado pela relação dependsOn.
Figura 4.4 – Modelo CML (Henricksen et al., 2002)
4.4. MODELO ORIENTADO A OBJETOS
Essa categoria visa empregar os principais benefícios da abordagem orientada a objetos, tais como
encapsulamento e reusabilidade, para lidar com os problemas de dinâmica do contexto (Strang e
37
Linnhoff-Popien, 2004). Os detalhes do processamento do contexto são encapsulados no nível do objeto
de contexto e o acesso à informação contextual é realizado por meio de interfaces.
Um exemplo de utilização dessa abordagem é o projeto TEA (Technology for Enabling Awareness)
(TecO, 2000), através do conceito de cues, que provêm uma abstração para sensores lógicos e físicos.
Cues são objetos que provêem informação contextual por meio de uma função que recebe como entrada
valores obtidos de sensores lógicos e físicos, e provê uma saída simbólica. Um conjunto de valores
possíveis é definido para cada cue. Diferentes cues podem ser baseados em um mesmo sensor, porém a
saída de cada cue depende de um sensor específico.
Outro exemplo de uso do modelo orientado a objetos é o projeto GUIDE (Cheverst et al., 1999)
que implementa modelos de objetos ativos (Active Object Model). Os objetos gerenciam uma grande
variedade de informações contextuais pessoais e ambientais, e os detalhes das coleções de dados são
encapsuladas e escondidas de outros componentes do sistema.
O modelo proposto por Bouzy e Cazenave (Bouzy e Cazenave, 1997) utiliza orientação a objetos
para representar o conhecimento contextual envolvido no jogo de computador Go (um jogo muito famoso
no Japão, China e Coréia, e que existe há mais de 4000 anos). Nesse modelo, eles destacam os contextos
temporais (se o jogo está no início, meio ou final), o contexto dos objetivos (para identificar bons
movimentos visando atingir algum objetivo), contextos espaciais (ambiente espacial de um grupo de
pedras) e contextos globais (ex. placar do jogo ou natureza da posição da pedra). O modelo orientado a
objetos foi escolhido por suas habilidades de herança e reutilização que permitem simplificar a
representação do conhecimento em sistemas e domínios complexos (Strang e Linnhoff-Popien, 2004).
4.5. MODELO BASEADO EM LÓGICA
A lógica define as condições em que uma expressão ou fato pode ser derivada, através de um processo
conhecido como raciocínio ou inferência, a partir de um conjunto de outras expressões ou fatos (Russell e
Norvig, 2003). Em modelos de contexto baseados em lógica, a informação contextual é representada
como fatos, expressões e regras. A informação contextual é adicionada, atualizada e removida em termos
de fatos ou inferências a partir de regras em um sistema baseado em lógica. Essa abordagem possui um
alto grau de formalismo (Strang e Linnhoff-Popien, 2004).
A primeira formalização do contexto baseada em lógica foi proposta em 1993 por McCarthy
(McCarthy, 1993). Em sua abordagem, McCarthy evita definir exatamente o que é contexto, e tenta
prover uma formalização que viabilize o uso de axiomas simples para fenômenos de senso comum para
representar contextos envolvendo poucas suposições. Assim, o contexto é identificado como a
generalização de uma coleção de suposições. A idéia é que ao escrever um axioma, ele mantenha um
certo contexto, e pode haver um outro contexto, mais geral, onde o axioma falha. Esse modelo é
denominado verdade relativa a um contexto (relativized-truth-within-a-context) e baseia-se no predicado
38
especial ist(c, p). Esse predicado indica que a proposição p é verdadeira no contexto c. A
proposição ist é uma abreviação para is-true (é verdadeiro). Um exemplo para essa relação é:
onde, c0 indica que no contexto das histórias de Sherlock Holmes, a pessoa chamada Holmes é um
detetive. O contexto captura tudo que não é explícito na proposição p mas que é necessário para tornar p
uma sentença significativa.
Giunchiglia utiliza lógica para formalizar o conceito de contexto em uma abordagem denominada
Multi-Context Systems (Giunchiglia, 1993). O foco dessa abordagem é menos na modelagem e mais no
raciocínio sobre contexto. Ele considera o contexto como um subconjunto específico do estado completo
de uma entidade que é usado para raciocinar sobre um dado objetivo.
Uma outra abordagem baseada em lógica foi proposta por Akman e Surav e é denominada Teoria
da Situação Estendida (Akman e Surav apud (Strang e Linnhoff-Popien, 2004)), como uma extensão à
Teoria da Situação, proposta por Barwise e Perry, os quais tentaram cobrir semânticas de linguagem
natural em um sistema de lógica formal (Barwise e Perry apud (Strang e Linnhoff-Popien, 2004)). O
modelo da Teoria da Situação Estendida modela o contexto como tipos de situação comuns. A variedade
de diferentes contextos é tratada sob a forma de regras e pressuposições relacionadas a um ponto de vista
em particular. Eles representam os fatos relativos a um dado contexto com expressões livres de
parâmetros e suportadas pelo tipo de situação correspondentes ao contexto. A Figura 4.5 mostra um
exemplo de como as regras de um contexto são representadas como restrições nessa abordagem.
Figura 4.5 – Exemplo de regras de contexto na Teoria da Situação Estendida (Strang e Linnhoff-Popien,
2004)
Outras propostas incluem: o Modelo do Contexto Percebido (Sensed Context Model) proposto por
Gray e Salber (Gray e Salber apud (Strang e Linnhoff-Popien, 2004)), que utiliza lógica de predicados de
primeira ordem como representação formal de proposições e relações contextuais; e a proposta de Bacon
et al. (Bacon et al. apud (Strang e Linnhoff-Popien, 2004)) que inclui um sistema multimídia em que a
localização é um aspecto do contexto expresso como fatos em um sistema baseado em regras e
implementado em Prolog.
c0: ist(contextof(“Histórias de Sherlock Holmes”), “Holmes é um detetive”)
39
4.6. MODELO BASEADO EM GRAFOS CONTEXTUAIS
Grafos contextuais (contextual graphs) constituem um formalismo baseado em contexto para
representação de procedimentos e práticas em uma organização (Brézillon, 2003b). Inicialmente, esse
formalismo foi desenvolvido para a aplicação SART, para atender o problema de solução de incidentes
em linhas do metrô de Paris (Brézillon et al., 2000). A idéia principal é que a organização estabeleça
procedimentos para a solução do incidente e que o operador da linha de metrô adapte esse procedimento
para resolver o incidente no contexto em que o mesmo ocorre. Esse procedimento contextualizado é
chamado de prática (Brézillon, 2003b). Os procedimentos são gerais e servem para ajudar os operadores
no controle dos processos, enquanto as práticas equivalem à união dos procedimentos com o contexto em
que serão executados, e constituem um conhecimento implícito, baseado na operacionalização dos
procedimentos no dia a dia. Dessa maneira, o volume de práticas acaba sendo muito grande em
comparação ao número de procedimentos, uma vez que para cada contexto diferente o procedimento pode
necessitar ser adaptado em uma nova prática.
Diferentes abordagens foram analisadas para resolver o problema de representação dos
procedimentos e práticas, como regras de produção, árvores de decisão, redes de crenças e raciocínio
baseado em casos. O desafio dessa representação é encontrar respostas para quaisquer que fossem as
circunstâncias em que um incidente ocorresse, e descrever de forma econômica os possíveis contextos em
que uma ação pode ser tomada (Brézillon, 2003b). Foi investigado o uso de árvores de contexto para essa
representação, porém essa abordagem demonstrou vários problemas, dentre eles a existência de muitas
práticas para um mesmo problema, repetição de seqüências de ações, muitas seqüências feitas na mesma
ordem em diferentes ramos, e o fato de duas ações poderem ser feitas em uma ordem diferente, mas
anteriores a uma terceira ação. Com isso, Brézillon e Pomerol investigaram a adaptação das árvores de
contexto para uma estrutura que denominaram grafos contextuais. Essa estrutura identifica seqüências
repetidas e as substitui por macro-ações, une os ramos cujas seqüências são iguais, executa uma
organização temporal dos ramos da árvore (branching temporal) e identifica sub-grafos que aparecem nas
representações de diferentes incidentes. A Figura 4.6 ilustra um exemplo de representação de
procedimentos e contextos em um grafo contextual.
O grafo contextual é um grafo acíclico direcionado com uma única entrada, uma única saída e uma
organização serial-paralela dos nós, conectados por arcos orientados. Mecanismos de agregação e
expansão permitem que os usuários tenham diferentes visões do grafo e transformem uma atividade em
uma ação. Um caminho em um grafo contextual representa uma prática na qual as ações do operador são
entrelaçadas com os elementos contextuais. Duas práticas são diferenciadas uma da outra pelos elementos
contextuais. O elemento temporal de uma ação é representado pela direção do grafo, e pela ordenação das
ações a serem executadas. Entretanto, não é possível representar o tempo em que uma ação deve ser
finalizada, por exemplo, dez minutos antes da execução de uma outra (Brézillon, 2003b).
40
O modelo de representação de grafos contextuais mostra-se muito adequado ao problema de
procedimentos e práticas ou quando há um processo envolvido.
Figura 4.6 – Representação de procedimentos e contextos em um grafo contextual (Brézillon, 2003b)
4.7. MODELO BASEADO EM MAPAS DE TÓPICOS
Um mapa de tópicos permite definir relações entre objetos físicos e lógicos localizados dentro ou fora do
mundo computacional, através da abordagem de redes semânticas. A rede semântica permite organizar os
objetos de uma forma intuitiva que facilita a navegação pelos dados. Essa abordagem é centrada em três
conceitos principais: Tópicos, Associações e Ocorrências (TAO) (ISO e IEC, 2002; Pepper, 2002). Os
objetos do mundo real são representados como tópicos, os quais se interconectam através de associações,
que representam as relações entre as entidades. Ocorrências permitem ligar tópicos aos respectivos
objetos do mundo real. O conceito de escopo define a área semântica no mapa de tópicos, o que permite
associar localidade ao mapa. Assim, tópicos são visíveis apenas dentro do escopo especificado (Goslar e
Schill, 2004).
O mapa de tópicos é um framework para gerenciamento de conjuntos de objetos de informação
interconectados, ou seja, os “assuntos” que são representados como tópicos. Um tópico é criado dentro de
um mapa de tópicos para indicar (ou se referir) a esse assunto. Informações são adicionadas aos tópicos
através da criação de associações entre eles. Por exemplo, o fato de uma pessoa possuir uma página Web
pode ser descrito através da associação hasWebpage entre os tópicos que representam a pessoa e a sua
página web. Não há restrições quanto ao número de associações entre tópicos. Uma vez criado o mapa de
tópicos, podem ser feitas perguntas do tipo “que animais vivem no mar?” ou “sobre quem é essa página
web?” e receber respostas significativas através das associações entre os tópicos (Power, 2003).
Ocorrências são recursos de informações relevantes para um tópico. Por exemplo, um tópico
representando uma pessoa pode possuir ocorrências tais como um retrato, o currículo ou uma descrição
sobre a pessoa. Esses recursos são ligados ao tópico e qualquer referência ao tópico provê,
41
automaticamente, acesso a essas ocorrências. Tipos de ocorrências especificam a quais informações as
ocorrências estão ligadas.
Power (Power, 2003) propõe o uso de mapa de tópicos para integrar dados contextuais localizados
em diferentes bancos de dados contextuais. A idéia é usar o mapa de tópicos para prover acesso aos dados
contextuais de baixo nível, utilizando-o como navegador pelas fontes de dados não estruturadas, e
armazenar o significado do dado contextual no próprio tópico, ao invés de armazená-lo na estrutura do
objeto ao qual o contexto se refere.
Power discute que apenas o mapa de tópicos, tal como definido, não é suficiente para atender à
demanda dos sistemas de gerenciamento de contextos, e propõe extensões com a inclusão de
funcionalidades como: agregação, para reunir dados de contexto de baixo nível e formar contextos de
mais alto nível; privacidade e segurança, através da implementação de mecanismos de controle de acesso
que decidam que informações de contexto devem ser exportadas e visualizadas por quais clientes; e grau
de confiança às associações, útil para prover tempo de expiração à informação contextual que não seja
atualizada ao longo do tempo (Power, 2003).
Mapas de Contexto (Context maps) é uma abordagem proposta em (Goslar e Schill, 2004) para
representação de contexto baseada no conceito de mapas de tópicos, através da extensão de tipos de
associação e tópicos, e da inclusão de código embutido. Essa extensão inclui os conceitos de: tópicos
dinâmicos, que modelam dados voláteis ou dados que mudam muito frequentemente; associações
complexas, que permitem visões mais simples e de alto nível do mapa; associações inteligentes, que
possuem comportamento adaptativo, e podem calcular a validade da associação em tempo de execução ou
modificar tópicos adjacentes; e interpretação e redirecionamento automático de eventos (Figura 4.7).
Figura 4.7 – Representações Visuais de Mapas de Contexto (Goslar e Schill, 2004)
42
Embora esses trabalhos defendam o uso de mapas de tópicos para representação de contexto, não
foram encontrados trabalhos que demonstrem a utilidade desse modelo de representação através do seu
uso em aplicações práticas. Tecnologias para criação e manipulação de mapas de tópicos ainda são
imaturas, e estão em fase inicial.
4.8. MODELO BASEADO EM ONTOLOGIAS
Uma ontologia é uma especificação explícita, formal, de uma conceitualização compartilhada em que
objetos, conceitos, entidades e relacionamentos do mundo real são definidos em uma determinada área de
interesse ou domínio de conhecimento (Gruber, 1993). Um dos grandes interesses na construção e uso de
ontologias é tornar o conhecimento sobre o mundo real processável por máquinas, daí a palavra formal
em sua definição, e a necessidade de utilizar linguagens formais para sua representação. Uma
representação explícita de uma ontologia consiste de um modelo formal de vocabulários (classes e
propriedades) e sua semântica associada (relacionamentos entre as diferentes classes e propriedades), bem
como funções, axiomas e instâncias (Wang et al., 2004).
A Figura 4.8 ilustra as três principais aplicações de ontologias e o nível de formalismo na
especificação do conhecimento exigido em cada uma (Mika e Akkermans, 2005). Na base da pirâmide,
está o suporte à comunicação entre agentes humanos e agentes de software, uma vez que ontologias
representam uma compreensão compartilhada sobre um conjunto de termos e descrições, e descrevem de
forma precisa as propriedades do ambiente e os vários conceitos utilizados no ambiente. Com isso, a
comunicação viabiliza o compartilhamento do conhecimento entre sistemas e entre agentes que atuam
nesses sistemas (Chen et al., 2003b; Wang et al., 2004).
Figura 4.8 – Aplicações de Ontologia (Mika e Akkermans, 2005)
A segunda funcionalidade é o suporte à integração e reuso de conhecimento. Diferentes ontologias
de diferentes domínios podem ser reutilizadas para compor uma ontologia de contexto em larga escala
sem a necessidade de começar do zero (Chen et al., 2003b; Wang et al., 2004). Ontologias podem ser
armazenadas em diferentes locais e podem ser criadas por diferente autores, o que oferece uma grande
extensibilidade e visibilidade do conhecimento (Strang et al., 2003).
A terceira funcionalidade é o suporte ao raciocínio com a produção de novos conhecimentos. Essa
é a funcionalidade que exige mais formalismo na representação do conhecimento, mas por outro lado
43
permite construir os sistemas mais complexos. Mecanismos existentes de raciocínio lógico podem ser
utilizados pelas aplicações para deduzir contextos de alto nível a partir de contextos básicos, e para checar
e resolver inconsistências no conhecimento contextual.
A comunicação indica que (what) tipos de objetos existem no domínio, a integração indica como
(how) esses objetos se relacionam, e o raciocínio indica porque (why) os objetos estão relacionados (Mika
e Akkermans, 2005). O raciocínio é realizado por um motor de inferência que permite: juntar diferentes
fragmentos ontológicos; deduzir conhecimento a partir de axiomas codificados simbolicamente; consultar
instâncias e seus valores; consultar nomes de conceitos e atributos baseados em ontologias conhecidas;
validar a consistência de uma ou mais ontologias; atribuir relacionamentos inter-ontológicos; e completar
as ontologias através do processamento de hierarquia implícita e relacionamentos baseados em regras
existentes (Strang et al., 2003).
O uso de ontologias é muito útil para checar a validade da informação contextual e para facilitar a
especificação do comportamento de aplicações cientes de contexto, uma vez que permite conhecer os
tipos de contexto disponíveis e sua estrutura. A aplicação especifica regras para o comportamento
sensível a contexto utilizando um conjunto particular de conceitos (um vocabulário). Quando a aplicação
se move para um novo espaço, o contexto pode ser diferente. Se a diferença for terminológica, a ontologia
pode permitir que as regras sejam traduzidas e assim funcionem corretamente no novo ambiente
(Ranganathan et al., 2003).
Ranganathan et al. (Ranganathan et al., 2003) apontam algumas das formas em que ontologias são
utilizadas em ambientes pervasivos: (i) verificar se as descrições de diferentes entidades estão
consistentes com os axiomas definidos na ontologia; (ii) permitir a descoberta semântica de entidades;
(iii) permitir que usuários obtenham uma melhor compreensão do ambiente e de como diferentes peças se
relacionam umas com as outras; (iv) permitir e facilitar que ambos agentes humanos e de software
executem buscas em diferentes componentes, interajam com diferentes entidades e especifiquem regras
para comportamentos sensíveis a contexto nessas entidades; (v) permitir que novas entidades (que sigam
diferentes ontologias) possam interagir com o sistema, bem como permitir que diferentes ambientes
pervasivos interajam uns com os outros.
Chen et al. apontam que um problema nos sistemas cientes de contexto atuais é que eles falham no
apoio ao compartilhamento de conhecimento e raciocínio sobre contexto, devido à ausência de
representação explícita de ontologias de contexto (Chen et al., 2003b). Ontologias têm sido usadas para
representação de contexto em diversas áreas, tais como Computação Ubíqua (Chen et al., 2003b;
Christopoulou et al., 2004; Gauvin et al., 2004; Preuveneers et al., 2004; Wang et al., 2004; Bulcão Neto
e Pimentel, 2005) e Sistemas Colaborativos (Vieira et al., 2005c).
A linguagem OWL (Web Ontology Language) (Bechhofer et al., 2004) tem sido comumente
utilizada para representação das ontologias. OWL é um dos padrões definidos para a Web semântica e
permite a definição de ontologias de domínio e compartilhamento de vocabulários. OWL é baseada na
44
linguagem DAML+OIL (DAML, 2006) e compartilha muitas de suas funcionalidades. Dentre elas, o uso
de RDF (Resource Description Framework) como linguagem de modelagem para definir os vocabulários
ontológicos, e o uso de XML como sintaxe para representação das informações (Bechhofer et al., 2004).
OWL é modelada através de uma abordagem orientada a objetos e a estrutura de um domínio é descrita
em termos de classes e propriedades. Do ponto de vista formal, OWL pode ser vista como equivalente à
lógica descritiva (DL), o que permite explorar os mecanismos de raciocínio em DL existentes, incluindo
consistência de classes (Wang et al., 2004).
Chen et al. apontam as seguintes razões para usar OWL na representação de ontologias (Chen et
al., 2003b): (i) possuir maior expressividade em relação a RDF ou RDF-S, permitindo construir mais
conhecimento dentro da ontologia; (ii) ter sido projetada como um padrão do W3C; (iii) ser suportada por
diversos motores de inferência para raciocínio sobre ontologias existentes, como Jena (Jena, 2006) ou
Racer (Racer, 2005).
4.8.1. Exemplos de Ontologias de Contexto
Uma das primeiras abordagens para representação de contexto usando ontologias foi proposta por Öztürk
e Aamodt (Öztürk e Aamodt, 1997). Eles elaboraram uma ontologia de alto nível onde o contexto foi
subdividido em dois conceitos principais: contexto interno, relativo ao agente ou ao raciocinador; e
contexto externo, relativo ao objetivo, à tarefa em curso, e ao ambiente. Sua classificação coloca o agente
como o elemento principal e são utilizados casos ao invés de esquemas para capturar conhecimento
contextual episódico, mantendo episódios únicos como casos. Eles justificam a escolha por ontologias
devido aos recursos de normalização e formalidade.
Dentre as ontologias mais recentes destaca-se a CONON (Wang et al., 2004; Gu et al., 2004c) e a
CoBrA-Ont (Chen et al., 2003a; Chen et al., 2003b), ambas codificadas em OWL. Essas ontologias são
utilizadas, respectivamente, nos mecanismos de gerenciamento de contexto SOCAM e CoBrA, e são
apresentadas no Capítulo 5.
Uma outra abordagem de representação de contexto baseada em ontologias é a linguagem CoOL
(Context Ontology Language), proposta em (Strang et al., 2003). CoOL é uma linguagem para
representação de ontologias de contexto, baseada no modelo Aspect-Scale-Context (ASC), onde os
aspectos representam classificações (ex. distância espacial) e podem possuir várias escalas (ex.
quilômetro ou milhas), que são dimensões individuais dos aspectos, e expressam alguma informação
contextual (ex. 20). A informação contextual é atribuída a um aspecto e escala, e metadados de qualidade
(ex. meanError) são associados à informação através de propriedades de qualidade. Funções de
mapeamento servem para converter a informação contextual de uma escala para outra. O conhecimento
contextual representado em CoOL é processado por raciocinadores lógicos, através de regras lógicas
45
escritas em F-Logic1 (Kifer et al., 1995). O modelo ASC permite não apenas a validação de tipos de
dados, mas também a validação de todo o conteúdo do dado, através da especificação das faixas para a
informação contextual (escalas).
4.9. CONSIDERAÇÕES FINAIS
Este capítulo apresentou algumas abordagens para representação de informações contextuais, que incluem
modelos baseados em pares de chave-valor, linguagens de marcação, extensões de modelos de
representação gráfica, orientação a objetos, lógica, grafos contextuais, mapas de tópicos e ontologias. A
Tabela 4.3 apresenta um resumo das principais características dessas abordagens, bem como os métodos
utilizados em cada uma para processamento e recuperação dos contextos.
Tabela 4.3 – Resumo das Abordagens de Representação de Contexto
Abordagem Vantagens Desvantagens Processamento Modelo Baseado em Pares de Chave-Valor
Modelo simples, de fácil implementação e uso.
Não considera hierarquia. Inadequado para aplicações com estruturas complexas
Busca linear com casamento exato de nomes
Modelo Baseado em Linguagens de Marcação
Baseado no padrão XML. Prevê hierarquia entre os elementos. O esquema de marcação implementa o próprio modelo. Utilização típica em perfis.
Incompletude e ambigüidade na informação contextual deve ser tratada pelo sistema. Inadequado para representar estruturas complexas
Linguagem de consulta baseada em marcação
Modelo Baseado em Representações Gráficas
Ajuda a estruturar o contexto e a modelar o sistema ciente de contexto. Apóia a compreensão do contexto por humanos
Não utilizado para instanciar a informação. Falta formalismos computacionais que permitam a compreensão do contexto por máquinas
Transformação dos modelos para código
Modelo Orientado a Objetos
Usufrui das propriedades de encapsulamento e reusabilidade. Permite estruturar a informação contextual e abstrair tratamento do contexto
A invisibilidade no tratamento do contexto, pelo encapsulamento, dificulta o formalismo do modelo
Algoritmos e compiladores
Modelos Baseados em Lógica
Contextos são definidos como fatos, expressões e regras. Alto grau de formalismo.
Difícil compreensão por humanos. Difícil modelagem da estrutura do contexto
Motor de Inferência
Modelo Baseado em Grafos Contextuais
Adequado para modelar contextos associados a processos
Não permite formalizar a estrutura do contexto
Busca em árvore
Modelo Baseado em Mapas de Tópicos
Facilita a navegação entre os contextos. Facilita modelagem dos contextos por humanos.
Estágio inicial. Tecnologia imatura. Faltam exemplos reais. Baixo formalismo
Navegação por redes semânticas
Modelo Baseado em Ontologias
Contextos modelados como conceitos e fatos. Viabiliza formalização e compartilhamento por humanos e computadores.
Tecnologia de manipulação imatura.
Motor de Inferência. Linguagem de consulta baseada em OWL
Power argumenta que uma questão relevante ao pensar em representação de informações
contextuais é que não é real pensar em um modelo único, padrão e globalizado de representação (Power,
1 F-Logic (ou Frame Logic) provê uma base lógica para linguagens orientadas a objeto e baseadas em quadros (frames) para representação de conhecimento.
46
2003). Ao contrário, os dados do contexto poderão ser obtidos de diferentes formas em fontes diversas e
heterogêneas de contexto. Formalizar todas as possíveis informações contextuais em ambientes restritos e
em situações controladas já é bastante difícil. Em cenários inter-organizacionais ou considerando
diferentes sistemas se torna praticamente impossível (Power, 2003)
Cada abordagem de representação possui vantagens e deficiências. Com isso, não há uma
abordagem que possa ser considerada unanimente a ideal para todos os sistemas cientes de contexto.
Diferentes sistemas impõem diferentes restrições. Em (Strang e Linnhoff-Popien, 2004) os autores
revisam diversas abordagens para modelagem de contexto e concluem que ontologias constituem a
abordagem mais promissora, devido às suas características de permitir o compartilhamento de
conhecimento entre humanos e entre agentes de software, bem como a reutilização de conhecimento entre
aplicações. Além disso, ontologias podem ser utilizadas por motores de inferência para inferir contextos
complexos a partir de contextos de mais baixo nível adquiridos por fontes diversas.
No entanto, existem problemas com o uso de ontologias. Um deles é que nem todo conhecimento
contextual pode ser definido a priori em um modelo estático e formal, como é o caso das práticas do
sistema SART (Brézillon et al., 2000), para as quais os grafos contextuais se mostram ideais. Além disso,
Henricksen et al. (Henricksen et al., 2004) apontam problemas na representação baseada em ontologias,
tais como: os padrões nos quais as ontologias e seus motores de inferência se baseiam são imaturos e
limitados; OWL ainda não provê suporte direto para regras axiomáticas, o que limita os tipos de
raciocínio; ontologias não suportam adequadamente raciocínio sobre informações de contexto imperfeitas
(imprecisas, ambíguas, incompletas), e o processo de criar ou estender ontologias de contexto é complexo
e sujeito a falhas, uma vez que as linguagens de escrita das ontologias não são intuitivas.
A abordagem de mapa de tópicos parece ser bastante interessante, porém ainda está em um estágio
imaturo em termos de definições de padrões e tecnologias. Este trabalho adota ontologias como modelo
de representação das informações contextuais em um framework de gerenciamento de contextos para
ambientes colaborativos. Abordagens para gerenciamento de contexto são revisadas no próximo capítulo.
47
CAPÍTULO 5
Mecanismos de Gerenciamento de Contexto
Nas pesquisas iniciais em computação ciente de contexto o foco era, basicamente, a construção de
aplicações específicas, onde o tratamento do contexto era feito de forma proprietária, localizada, sem
levar em consideração requisitos como modularidade, reusabilidade e interoperabilidade (Riva, 2005). A
maioria das implementações existentes são elaboradas considerando um cenário particular e não provêem
mecanismos de reuso.
Zimmermann et al. utilizam o termo "mecanismos de gerenciamento de contexto" para designar
sistemas que permitem a criação, integração e administração de aplicações cientes de contexto
(Zimmermann et al., 2005a; Zimmermann et al., 2005b). O gerenciamento de contexto considera a
definição de parâmetros de contexto relevantes, a ligação entre esses parâmetros e fontes de informação,
sua utilização para o comportamento adaptativo da aplicação e a definição desse comportamento.
Servidores de contexto ou outros componentes de gerenciamento de contextos armazenam as informações
contextuais e provêem acesso para recuperação, comparação e atualização dessas informações.
A idéia principal dos mecanismos de gerenciamento de contexto é reduzir a complexidade
associada à construção de um sistema ciente de contexto, transferindo da aplicação para uma camada
intermediária as tarefas relativas à manipulação da informação contextual.
Este capítulo discute algumas abordagens para gerenciamento de contexto e revisa mecanismos
presentes na literatura que são relacionados a essas abordagens, identificando os requisitos para
construção de sistemas cientes de contexto contemplados em cada um deles.
5.1. CATEGORIAS DE ABORDAGENS PARA GERENCIAMENTO DE CONTEXTO
Infra-estrutura, framework, toolkit, middleware e engine são os termos comumente utilizados para
designar as diversas abordagens para mecanismos de gerenciamento de contextos. Algumas pesquisas
adotam a abordagem de framework de componentes reutilizáveis para prover uma estrutura, e um toolkit
com modelos básicos que facilitem o desenvolvimento das aplicações cientes de contexto. Pesquisas mais
recentes passaram a utilizar o nome infra-estruturas de contexto para designar os sistemas que apóiam a
construção de sistemas cientes de contexto (Riva, 2005). Para entender a diferença entre essas abordagens
são verificados, a seguir, como esses termos são definidos na literatura.
Uma infra-estrutura é um conjunto de tecnologias bem estabelecido, pervasivo, confiável e
publicamente acessível, que provê uma base para outros sistemas (Hong e Landay, 2001). Uma infra-
estrutura de serviços permite que tecnologias e serviços sejam acessíveis através de uma rede e que
48
aplicações e dispositivos possam utilizá-los através de protocolos e formatos pré-definidos. A Internet é
um exemplo de infra-estrutura (Hong e Landay, 2001).
Framework constitui uma estrutura básica de suporte sobre a qual um outro projeto de software
pode ser organizado e desenvolvido. Pode incluir, tipicamente, programas de apoio, bibliotecas de código,
linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes do
projeto (Wikipedia, 2006b). O framework trata das funcionalidades centrais e provê meios de
customização para adequação a necessidades específicas da aplicação (Hong e Landay, 2001).
Toolkit é um conjunto de widgets, elementos básicos de uma interface gráfica, normalmente
implementados como uma biblioteca de rotinas ou uma plataforma para aplicativos (Wikipedia, 2006c).
Em geral, toolkits são desenvolvidos sobre um framework e provêem componentes reusáveis para
funcionalidades comuns (Hong e Landay, 2001).
Middleware é um software de interface que permite a interação de diferentes aplicações,
geralmente sobre diferentes plataformas de hardware e infra-estrutura, para troca de dados (Wikipedia,
2006a). Ele provê serviços reusáveis que podem ser compostos, configurados e depurados para criar
aplicações em rede de forma rápida e robusta (Blair et al., 2004).
Segundo Ranganathan e Campbell, ambientes de computação ubíqua devem prover um suporte de
middleware para a percepção do contexto (Ranganathan e Campbell, 2003). Eles argumentam que o
middleware pode simplificar as tarefas de criação e manutenção de sistemas cientes de contexto, pois
provêem abstrações uniformes e serviços confiáveis para operações comuns. O middleware facilita
também o desenvolvimento incremental de novos sensores e agentes cientes de contexto no ambiente. Um
middleware, idealmente, deve ser independente de hardware, sistema operacional e linguagem de
programação.
Engine (motor) é um programa que executa uma tarefa de propósito específico para outras
aplicações. O motor pode ser um programa central que coordena toda a operação de um conjunto
coordenado de programas. É também utilizado para descrever um programa de propósito específico que
contém um algoritmo que pode mudar algumas vezes (UBC, 2000). Exemplos são motores de busca,
como Google ou Yahoo, e motores de jogos, usados para formar blocos de construção para outros jogos
(Playstation, 2004).
Apesar das diferentes definições, Hong e Landay afirmam que essas abordagens não são
mutuamente exclusivas e que muitas vezes é importante usar uma combinação de várias delas (Hong e
Landay, 2001). Alguns problemas comuns surgem durante o desenvolvimento e reutilização de
componentes para um sistema de gerenciamento de contextos, tais como a forte dependência de um
domínio, a ausência de interfaces abertas e padronizadas, a ausência de uma representação uniforme dos
perfis e modelos dos usuários e a utilização de fontes de dados diferentes e distribuídas (Zimmermann et
al., 2005b).
49
5.2. MECANISMOS PARA GERENCIAMENTO DE CONTEXTO
As próximas subseções apresentam algumas propostas de mecanismos para gerenciamento de contexto.
Os mecanismos, em geral, são voltados para o domínio da Computação Ubíqua, pois é nesse domínio que
as pesquisas sobre contexto estão mais avançadas em termos de implementações reais.
5.2.1. SOPHIE
SOPHIE (SOcial PHilanthropic Information Environment) é um ambiente de informação reativo e
integrado, que visa rastrear as mudanças constantes que ocorrem em um ambiente e se adaptar a elas, por
exemplo, através da disseminação da informação correta aos vários canais de saída (Belotti, 2004).
SOPHIE é integrado a um motor de contexto (context engine) genérico, com um modelo semântico
de contexto (Belotti et al., 2004a). Esse motor de contexto tem por finalidade gerenciar informações
contextuais e pode ser acoplado a aplicações existentes para aumentar a ciência de contexto dessas
aplicações (Belotti et al., 2004b). O modelo de contexto do SOPHIE tem por objetivo consolidar modelos
existentes em outras abordagens, movendo os conceitos para um nível mais alto de abstração em termos
de descrição semântica do contexto. O modelo baseia-se na extensão ao padrão ORM (Object-Role
Modeling) proposta por Henricksen et al. (Henricksen et al., 2002) e em semânticas bem definidas que
facilitam a reusabilidade e interoperabilidade do contexto em aplicações existentes.
O modelo é centralizado em três conceitos básicos: context (contexto de domínio), providers
(aquisição de contexto) e notifiers (comunicação do contexto). Além desses conceitos, eles introduzem
um sistema de tipos que define a composição do contexto. Os tipos podem ser definidos para três
domínios principais: ApplTypes, que indicam os tipos específicos da aplicação, BaseTypes, que definem
valores primitivos como string, inteiro e booleano, e BulkTypes, que designam conjuntos de valores de
um dado tipo. Os tipos do contexto são definidos como a composição de atributos de um dado tipo
(Belotti et al., 2004a). A Figura 5.1 apresenta os principais elementos desse modelo de contexto.
Figura 5.1 - Modelo de Contexto (Belotti, 2004)
A arquitetura do SOPHIE, e sua integração com o motor de contexto, é ilustrada na Figura 5.2. O
motor de contexto é dividido em quatro abstrações principais relacionadas ao contexto: aquisição (context
sensing), que é a obtenção de informações de produtores de contexto; ampliação (context augmentation),
armazenamento da informação contextual associando-a ao seu assunto; adaptação (contextual
50
adaptation), adapta o comportamento a mudanças no contexto corrente; e descoberta de recursos
(contextual resource discovery), permite descobrir recursos e informações relevantes dependentes do
contexto. As informações contextuais processadas pelo motor são obtidas da camada da aplicação
(application), por meio de informações existentes armazenadas em bases de dados, e da camada de
ambiente (environment) que representa o mundo real, físico (Belotti, 2004).
Figura 5.2 - Arquitetura do SOPHIE (Belotti, 2004)
A aquisição do contexto é baseada em sensores. Para instalar um novo sensor, o desenvolvedor
precisa instanciar um sensor e ligá-lo a um dado contexto. O sensor pode ser executado individualmente e
atualizar o estado do seu contexto ou pode ser de natureza reativa e responder a uma requisição de
atualização do contexto associado (Belotti et al., 2004a). A disseminação do contexto é feita por meio de
notificadores que informam aplicações inscritas como interessadas no contexto sempre que ocorrer um
evento sobre o contexto. Um notificador é associado a um contexto e cada vez que o contexto muda, o
notificador é invocado. O notificador avalia a mudança no contexto e, caso seja desejado, a aplicação
apropriada é notificada (Belotti et al., 2004a).
5.2.2. SOCAM
SOCAM (Service-Oriented Context-Aware Middleware) é um middleware para a construção rápida de
serviços cientes de contexto em ambientes inteligentes (Gu et al., 2005). Para permitir a
interoperabilidade entre aplicações e apoiar o raciocínio sobre contexto, SOCAM utiliza a ontologia
CONON (Context Ontology) (Wang et al., 2004; Gu et al., 2004c). CONON é um modelo semântico de
contexto, serializado em OWL-DL.
Conceitualmente, a CONON é dividida em duas partes distintas (Figura 5.3): uma ontologia de alto
nível (upper ontology) que captura os conceitos genéricos sobre contextos básicos (localização, usuário,
atividade e entidade computacional), e uma coleção de ontologias específicas de domínio, que são
construídas como especializações da ontologia de alto nível para domínios específicos. Estas definem os
51
detalhes dos conceitos genéricos para cada sub-domínio. A separação em domínios facilita o reuso de
conceitos genéricos e provê uma interface flexível para definição de conhecimento específico para a
aplicação (Wang et al., 2004).
Figura 5.3 - Visão parcial da ontologia de alto nível do CONON (Wang et al., 2004)
O middleware SOCAM (Figura 5.4) provê suporte para as seguintes tarefas no gerenciamento de
contexto: aquisição, compartilhamento, raciocínio, armazenamento e disseminação do contexto. A
aquisição do contexto é feita pelos componentes denominados context providers, que abstraem os
contextos a partir de diferentes fontes externas ou internas, e convertem-nos na representação formal da
ontologia CONON. O compartilhamento ocorre através da utilização da CONON, que permite que os
contextos sejam compartilhados e reutilizados pelos vários componentes do SOCAM.
O raciocínio sobre contexto é executado pelos interpretadores de contexto (context interpreters),
que consistem de motores de raciocínio de contexto (context reasoning engines) e de uma base de
conhecimento contextual (context KB). Os motores de raciocínio realizam inferência de contextos, a partir
de regras pré-definidas, resolução de conflitos dos contextos, e manutenção da consistência da base de
conhecimento contextual.
O armazenamento do contexto é efetuado através da manutenção de um banco de dados de
contexto (context database) que persiste as ontologias de contexto e os contextos passados. A base de
conhecimento contextual provê serviços que permitem que os outros componentes possam consultar,
adicionar, remover ou modificar o conhecimento contextual armazenado no banco de dados de contexto.
A disseminação do contexto é realizada pelo serviço de localização de serviços (service locating
service). Esse serviço provê um mecanismo onde os provedores e interpretadores de contexto possam
anunciar suas presenças e os usuários ou aplicações possam localizar e acessar esses serviços.
52
Figura 5.4 – Visão Geral da Arquitetura do SOCAM (Gu et al., 2005)
Para raciocinar sobre a incerteza em relação aos elementos de contexto representados, a SOCAM
utiliza redes bayesianas (Gu et al., 2004a). Esse modelo anexa valores de probabilidade aos predicados de
contexto definidos na CONON. Para isso foi proposta uma extensão à OWL para inclusão de rótulos de
marcação para probabilidades. A escolha pelas redes bayesianas é justificada pela eficiência em lidar com
raciocínio probabilístico e por permitir representar relacionamentos causais entre vários contextos. Entre
as limitações dessa abordagem está a dificuldade em obter dados para treinar a rede bayesiana em certas
circunstâncias, como aplicação de controle de segurança. A lógica fuzzy pode ser utilizada para
representar e raciocinar sobre noções imprecisas de contexto, como "quente", "muito baixo" ou
"confiança".
5.2.3. CoBrA
CoBrA (Context Broker Architecture) é uma arquitetura baseada em agentes cujo objetivo é apoiar
sistemas cientes de contexto em espaços inteligentes, em particular salas de reuniões inteligentes em um
campus universitário. O elemento principal dessa arquitetura é um agente inteligente chamado context
broker que mantém e gerencia um modelo compartilhado do contexto, a ontologia CoBrA-Ont e provê
serviços de proteção de privacidade para os usuários (Chen et al., 2005).
CoBrA-Ont é uma ontologia de contexto desenvolvida em OWL e tem por objetivo auxiliar os
agentes na aquisição, raciocínio e compartihamento do conhecimento contextual, bem como apoiar a
detecção e resolução de conhecimento contextual inconsistente e ambíguo (Chen et al., 2003b). A Figura
5.5 mostra uma representação gráfica dos conceitos ontológicos da CoBrA-Ont, a qual é categorizada em
quatro temas distintos e relacionados: (i) conceitos que definem lugares físicos e suas relações espaciais
associadas; (ii) conceitos que definem agentes (humanos e de software); (iii) conceitos que descrevem o
contexto de localização de um agente em um campus universitário; e (iv) conceitos que descrevem os
contextos de atividade de um agente, incluindo papéis, desejos e intenções associadas em um evento de
apresentação.
53
Figura 5.5 – Representação Gráfica da Ontologia CoBrA-Ont (Chen et al., 2003a)
A arquitetura do CoBrA é ilustrada na Figura 5.6. Os requisitos para gerenciamento de contexto
tratados pelo CoBrA são: (i) aquisição de contexto de fontes heterogêneas, como sensores físicos,
serviços web, bancos de dados, dispositivos e agentes (Context Acquisition Module); (ii) raciocínio sobre
a informação para deduzir conhecimento adicional a partir da informação adquirida, e manter o modelo
de contexto consistente (Context Reasoning Module); (iii) compartilhamento do conhecimento contextual
através do uso de ontologias comuns (RDF/OWL), e padrões de comunicação entre agentes como a
linguagem FIPA-ACL e o protocolo SOAP; (iv) proteção da privacidade dos usuários através de políticas
definidas pelo usuário e de regras de comportamento do broker associadas a essas políticas (Privacy
Management Module) (Chen, 2004).
Para realizar o raciocínio sobre contexto, CoBrA utiliza um número de diferentes sistemas
baseados em regras, como Jena (Jena, 2006), usado para inferência sobre a ontologia OWL, JESS (Java
Expert System Shell) (Jess, 2006), usado para interpretação de contexto utilizando regras específicas do
domínio, e Theorist (Poole et al., 1998), um raciocinador baseado em sentenças Prolog utilizado para
apoiar as inferências lógicas para resolver conhecimento inconsistente (Chen, 2004).
54
Figura 5.6 – Visão Geral da Arquitetura do CoBrA (Chen, 2004)
5.2.4. CXMS
O CXMS (Context Management System) é um framework que oferece um conjunto de ferramentas para
facilitar o desenvolvimento e manutenção de sistemas e serviços cientes de contexto. Para isso, ele
considera as seguintes abstrações principais: (i) aquisição do contexto; (ii) modelagem do contexto; (iii)
definição do comportamento da aplicação; e (iv) apresentação da informação de forma correta
(Zimmermann et al., 2005a; Zimmermann et al., 2005b).
O CXMS é formado pelos seguintes componentes (ver Figura 5.7): o Context Toolkit, o Content
Management System (CMS), o Administrator, uma ferramenta de administração para configuração da
aplicação, e o Mobile Collector, uma ferramenta de edição para a criação de ligações entre os conteúdos e
os parâmetros de contexto.
O Context Toolkit é o elemento responsável pelo gerenciamento do conhecimento contextual e
divide-se em quatro camadas: Sensores, Semântica, Controle e Atuação. A camada dos sensores (Sensor
Layer) é responsável pela aquisição do contexto por meio de uma rede de sensores físicos que reconhece
mudanças no ambiente e recebe todos os eventos de entrada enviados pela aplicação, relacionados à
situação atual do usuário. A camada semântica (Semantic Layer) atende à modelagem do contexto,
fornece a interpretação do contexto enriquecendo semanticamente os dados coletados pela camada dos
sensores, e subdivide-se nas camadas: entidade, define as entidades do domínio e gerencia suas
propriedades; relacionamento entre entidades, modela as dependências entre as entidades; e processo,
observa a evolução dos contextos ao longo do tempo. A camada de controle (Control Layer) é
responsável por definir o comportamento da aplicação e por decidir que ações devem ser disparadas se
condições particulares no modelo forem verdadeiras. Finalmente, a camada de atuação (Actuation Layer)
lida com a apresentação da informação de forma correta. Para isso, são mapeadas as decisões tomadas
55
pela camada de controle para ações do mundo real e são modificados os parâmetros de variáveis do
domínio de acordo com o comportamento do usuário.
Figura 5.7 - Arquitetura do CXMS (Zimmermann et al., 2005a)
A abordagem utilizada no CXMS para representação das informações contextuais é baseada no
modelo de pares de chave-valor, escolhido pela simplicidade e flexibilidade. Cada contexto é uma
enumeração de um ou mais atributos de contexto e cada entidade possui, por definição, um contexto
estático e diversos tipos de contextos dinâmicos. É mantido um histórico para cada tipo de contexto. O
modelo de contexto cobre as quarto dimensões mencionadas em (Gross e Specht, 2001): identidade,
localização, tempo e ambiente. Um contexto sempre representa todas as informações atualizadas e
disponíveis que descrevem a situação atual de um usuário ou grupo de usuários.
5.2.5. Context Toolkit - CTK
O Context Toolkit (CTK) é um dos primeiros e mais referenciados projetos de mecanismo para
gerenciamento de contexto (Dey et al., 1999b; Dey et al., 2001). Seu objetivo é prover uma solução
reutilizável para tratamento do contexto que facilite a implementação e desenvolvimento de aplicações
cientes de contexto interativas, no domínio da computação ubíqua. O CTK compreende um framework
para aplicações cientes de contexto baseado em sensores e provê um número de componentes
reutilizáveis para construção dessas aplicações.
O CTK incorpora vários serviços relacionados ao gerenciamento de contexto, incluindo aquisição
do contexto, acesso a dados de contexto e persistência do contexto. A Figura 5.8 mostra a hierarquia de
componentes do CTK e uma visão geral da sua arquitetura. O componente raiz é o BaseObject, que
subdivide-se em widgets de contexto (widgets), interpretadores de contexto (interpreters) e um servidor
56
para descoberta de recursos (discoverer). Os widgets são compostos por serviços de contexto (services) e
agregadores de contexto (aggregators) (Dey et al., 2001).
Figura 5.8 – Hierarquia de Componentes e Arquitetura do CTK (Dey et al., 2001)
Os widgets de contexto são uma analogia aos widgets de interface gráfica e têm por objetivo apoiar
a aquisição do contexto, através de sensores, e a disseminação dos contextos, por meio dos atuadores. Os
interpretadores ampliam o nível de abstração da informação contextual, para melhor se adequar aos
requisitos da aplicação. Os agregadores combinam os diferentes tipos de informações contextuais
relacionados a uma entidade. Quando widgets, agregadores e interpretadores são instanciados, eles se
registram a um serviço de localização (discoverer) e quando uma aplicação é executada, ela contacta esse
serviço para localizar componentes que sejam relevantes à sua funcionalidade.
O CTK representa o contexto sob a forma de pares de chave-valor definidos usando a linguagem
XML. O principal problema do CTK é a ausência de um modelo formal de contexto e de formas de
controlar uma aplicação ou mudança de parâmetros dinâmicos dentro da aplicação. O CTK não provê um
suporte para raciocínio sobre contextos e inferência de novos contextos de alto nível ou uma estrutura
formal para organizar os diversos tipos de contextos. Além disso, a funcionalidade dos interpretadores
para derivação de contexto é limitada, uma vez que eles são geralmente empregados apenas para
conversões de tipos de dados simples. Como resultado, o suporte a comparações de contexto também é
limitado.
5.2.6. Middleware de Contexto do Gaia
Gaia é uma infra-estrutura para ambientes inteligentes de computação pervasiva cujo principal objetivo é
tornar inteligente espaços físicos como salas, casas e aeroportos e auxiliar pessoas nesses espaços (Román
et al., 2002). Gaia possui um middleware de contexto que permite que aplicações obtenham e utilizem
diferentes tipos de contextos.
O middleware de contexto do Gaia visa prover suporte para as seguintes tarefas de gerenciamento
de contexto: aquisição do contexto a partir de diferentes sensores; disseminação do contexto a diferentes
agentes; inferência de contextos de alto nível a partir de contextos de baixo nível utilizando diferentes
tipos de mecanismos de raciocínio e aprendizagem; facilidades para diferentes atuações dos agentes em
57
diferentes contextos; e (v) interoperabilidade semântica e sintática entre diferentes agentes (Ranganathan
e Campbell, 2003).
A Figura 5.9 mostra uma visão geral da arquitetura do middleware de contexto. A aquisição do
contexto é realizada por provedores de contexto (context providers), os quais, juntamente com
sintetizadores de contexto (context synthesizers), fazem a disseminação da informação contextual a
consumidores de contexto (context consumers). Os sintetizadores são responsáveis, também, pela
inferência dos contextos de alto nível. Os consumidores obtêm diferentes tipos de contextos, raciocinam
sobre o contexto atual e adaptam seu comportamento (atuam) de acordo com o contexto. Um serviço de
busca (context provider lookup service) permite que provedores de contexto anunciem seus contextos e
que agentes encontrem os provedores adequados a suas necessidades. Um serviço de histórico (context
history service) mantém os contextos persistidos em um banco de dados para permitir consulta a
contextos passados.
A interoperabilidade semântica e sintática entre agentes é provida pelo uso de ontologias para
representação do contexto. Um servidor de ontologias (ontology server) mantém as ontologias que
descrevem diferentes tipos de informação contextual, de modo que outros agentes possam obter
descrições dos agentes no ambiente, meta-informações sobre os contextos e definições dos vários termos
utilizados no Gaia.
Figura 5.9 – Visão geral do middleware de contexto do GAIA (Ranganathan e Campbell, 2003)
A representação de contexto no GAIA era feita, inicialmente, com predicados de lógica de primeira
ordem. Posteriormente, em 2003, eles adotaram a abordagem de ontologias, que foi codificada através da
linguagem DAML+OIL (DAML, 2006). Os contextos são representados como predicados e as ontologias
definem o vocabulário e tipos de argumentos que podem ser utilizados nos predicados.
A ontologia de contexto descreve as entidades, que incluem aplicações, serviços, dispositivos,
usuários, fontes de dados, localização, atividades e informações climáticas, suas propriedades e os
58
relacionamentos entre elas, bem como axiomas que restringem as propriedades dessas entidades. As
entidades de contexto são classificadas em sete categorias: (i) contextos físicos (ex. localização e tempo);
(ii) contextos ambientais (ex. clima, níveis de luz e som); (iii) contextos de informação (ex. notas sobre
estoque e placar esportivo); (iv) contextos pessoais (ex. saúde, agenda e atividade); (v) contextos sociais
(ex. atividade do grupo, relacionamentos sociais e quem está na sala com quem); (vi) contextos da
aplicação (ex. email e páginas web visitadas); e (vii) contextos do sistema (ex. tráfego da rede e status da
impressora).
As aplicações cientes de contexto desenvolvidas em Gaia possuem regras que descrevem que ações
devem ser executadas em diferentes contextos. Para escrever essas regras o desenvolvedor deve conhecer
os diferentes tipos de contextos disponíveis bem como as possíveis ações que podem ser executadas pela
aplicação. As ontologias servem para simplificar a tarefa de escrever essas regras. Gaia inclui uma
ferramenta que utiliza a ontologia e auxilia o desenvolvedor na escrita das regras (Ranganathan et al.,
2003).
5.2.7. Framework de Contexto
Henricksen e Indulska (Henricksen e Indulska, 2005) propuseram um framework de contexto que visa
facilitar a construção de aplicações cientes de contexto e prover suporte às tarefas de aquisição,
representação, persistência e disseminação de contextos, e adaptação de aplicações ao contexto. Essas
funcionalidades são baseadas em um modelo de contexto que identifica a diversidade da informação
contextual, sua qualidade, relacionamentos complexos entre dados de contexto e aspectos temporais. O
framework de contexto (Figura 5.10) é organizado em uma hierarquia de seis camadas: (i) camada da
aplicação ciente de contexto; (ii) camada de adaptação; (iii) camada de consulta; (iv) camada de
gerenciamento do contexto; (v) camada de recepção do contexto; e (vi) camada de aquisição do contexto.
A camada de aquisição utiliza sensores para adquirir a informação contextual e processa essa
informação através de interpretadores e agregadores. A camada de recepção provê um mapeamento
bidirecional entre o contexto adquirido e as camadas de gerenciamento, traduzindo os dados de entrada
para o modelo formal definido. A camada de gerenciamento é responsável pela manutenção de um
conjunto de modelos de contexto e suas instanciações, onde a aplicação pode definir seu próprio modelo
de contexto, segundo a abordagem CML (Context Modeling Language) (ver Seção 4.3), ou compartilhar
modelos de aplicações similares. A camada de consulta provê uma interface para que aplicações possam
consultar o sistema de gerenciamento de contexto. A camada de adaptação gerencia repositórios comuns
de definições de situações e preferências e avalia essas definições usando serviços das camadas mais
baixas. A camada da aplicação provê um toolkit de programação com suporte à criação, ativação e
desativação de gatilhos.
59
Figura 5.10 - Arquitetura do Framework de Contexto (Henricksen e Indulska, 2005)
5.2.8. Kernel Semântico de Contexto
O Kernel Semântico de Contexto (Semantic Context Kernel) é uma infra-estrutura de serviços para
gerenciamento de contexto (por simplificação, será denominado SCK) (Bulcão Neto e Pimentel, 2005). O
SCK inclui serviços configuráveis para armazenamento, consulta e inferência sobre contexto, um serviço
de descoberta, além de componentes que apóiam as tarefas de aquisição, disseminação e adaptação ao
contexto e conversão do contexto em um modelo semântico de representação, baseado em ontologias. O
modelo semântico visa prover interoperabilidade semântica e reuso do conhecimento contextual. O
principal objetivo do SCK é prover aos desenvolvedores de aplicações cientes de contexto um conjunto
de serviços que possam ser configurados para atender aos requisitos da aplicação. Os autores apontam a
configurabilidade dos serviços como a principal funcionalidade do Kernel. A arquitetura do SCK é
apresentada na Figura 5.11.
A informação contextual é adquirida de fontes de contexto heterogêneas (context sources) como
aplicações, serviços web e sensores físicos. As informações adquiridas são convertidas em uma
representação semântica comum pelos tradutores de contexto (context transducers) e utilizadas por
consumidores de contexto (context consumers) para adaptar seu comportamento ao contexto atual. Um
serviço de descoberta (discovery service) disponibiliza propagandas de fontes de contexto de modo que
consumidores de contexto possam encontrar as informações que necessitam. O serviço de inferência
60
(context inference service) provê um suporte configurável ao raciocínio de contexto, e permite que
desenvolvedores definam suas regras de inferência. O serviço de consulta (context query service) permite
que consumidores de contexto consultem o contexto por meio de uma linguagem declarativa chamada
RDQL. Finalmente, o serviço de persistência (context persistence service) possibilita o armazenamento
persistente do contexto em uma maneira configurável, de forma que os desenvolvedores das aplicações
possam escolher os tipos de armazenamento e representação do contexto, como bancos de dados
relacionais, arquivos RDF/XML ou arquivos texto em formato N-Triple.
Figura 5.11 - Visão Geral da Arquitetura do SCK (Bulcão Neto e Pimentel, 2005)
A representação do contexto no SCK é feita usando uma ontologia (Figura 5.12) serializada em
OWL. A ontologia divide o contexto em 5 dimensões: identidade dos atores (who), localização (where),
tempo (when), atividade (what) e perfis dos dispositivos (how). A ontologia dos atores usa um conjunto
de ontologias externas como FOAF (Friend of a Friend) (Brickley e Miller, 2006), Dublin Core (Dcmi,
2005) e vCard (Iannella, 2001) para modelar papéis, projetos, contatos, especialidades, documentos e
relacionamentos sociais associados aos atores.
61
Figura 5.12 – Visão geral do modelo de contexto (Bulcão Neto e Pimentel, 2005)
5.2.9. Framework Conceitual de Contexto para Groupware
O framework conceitual de contexto para groupware, proposto por Rosa et al. (Rosa et al., 2003), tem por
objetivo a identificação e classificação dos elementos contextuais mais comuns nas ferramentas de
groupware. É representado através de quadros conceituais e visa prover guias para desenvolvedores de
groupware na inclusão do tratamento do contexto nesses sistemas (Figura 5.13).
62
Figura 5.13 – Framework Conceitual de Contexto para Groupware (Rosa, 2004)
O framework conceitual considera que os elementos relevantes para a composição do contexto de
atividades em grupo estão divididos em sete tipos: contexto do indivíduo, contexto do grupo, contexto da
tarefa, contexto da interação, contexto do planejamento, contexto do ambiente e contexto histórico. Esses
tipos foram alocados em cinco categorias: (i) informações sobre pessoas; (ii) informações sobre as tarefas
a serem realizadas; (iii) informações sobre as relações entre pessoas e tarefas; (iv) informações sobre o
ambiente onde as tarefas são realizadas; e (v) informações sobre as tarefas já realizadas. Cada categoria
procura identificar os aspectos da interação que influenciam a execução de tarefas em grupo. O tipo da
interação (síncrona ou assíncrona) interfere no tipo da informação contextual a ser considerada para uma
das categorias, e por isso essa distinção é feita no contexto da interação.
O framework é uma classificação genérica que visa identificar os elementos contextuais existentes
nas interações ocorridas nos mais diversos tipos de ferramentas de groupware. Classificações mais
específicas poderão ser feitas em domínios particulares, onde novos elementos contextuais podem ser
considerados relevantes. O framework conceitual oferece, assim, um suporte à identificação e
caracterização de contexto em sistemas de groupware. Uma proposta de modelagem conceitual das
informações contextuais, usando o diagrama de classes da UML é ilustrada na Figura 5.14.
63
Figura 5.14 – Diagrama de classes com um modelo conceitual preliminar do contexto (Rosa, 2004)
5.3. CONSIDERAÇÕES FINAIS
Este capítulo discutiu a área de gerenciamento de contextos, definiu as categorias para as diversas
abordagens de gerenciadores de contexto presentes na literatura, e apresentou alguns mecanismos
pertencentes a essas diversas categorias. A Tabela 5.1 exibe um resumo das principais características
desses mecanismos, o modelo de representação utilizado por cada um, as tarefas de gerenciamento que
implementam, e os tipos de informações contextuais que consideram.
Os mecanismos para gerenciamento de contexto encontrados na literatura são, em sua maioria,
voltados para o domínio da computação ubíqua e pervasiva, área em que o estudo e aplicação do contexto
estão mais avançados. Por essa razão, eles seguem um modelo e arquitetura similares. Seus componentes
modulares executam, em geral, as tarefas de: (i) aquisição do contexto; (ii) representação das
informações contextuais; (iii) raciocínio e inferência sobre as informações contextuais capturadas;
(iv) persistência do contexto, mantendo um banco de dados histórico; (v) disseminação do contexto; e
(vi) notificação das aplicações dos contextos adquiridos. Alguns trabalhos se preocupam, também com a
confiança da informação contextual e em como lidar com incertezas, e outros com questões relativas à
privacidade e segurança. Nenhum dos sistemas estudados apresentou soluções para lidar com questões
relacionadas ao desempenho dos sistemas cientes de contexto e otimização do tratamento do contexto.
Na área de sistemas colaborativos foi identificado o framework conceitual de contexto em
groupware (Rosa et al., 2003). A utilização de contexto em sistemas colaborativos, embora seja apontado
por vários pesquisadores como algo bastante relevante, ainda é uma área pouco explorada na literatura.
Os mecanismos encontrados na área de sistemas colaborativos gerenciam informações de percepção, sem
uma relação explícita com o conceito de contexto. O framework conceitual é um primeiro passo rumo à
identificação e caracterização das informações contextuais em sistemas de groupware. Porém, ele não
oferece maiores facilidades no gerenciamento do contexto, uma vez que não provê suporte a tarefas como
64
aquisição, representação formal, processamento e disseminação do contexto. Ele também não indica o
que diferencia o gerenciamento do contexto do grupo em relação ao contexto do indivíduo e não indica
como as aplicações podem utilizar o contexto para tornar a interação em grupo mais efetiva.
Tabela 5.1 – Resumo das Abordagens para Gerenciamento de Contextos
Mecanismo Representação Funcionalidades Informações de contexto Motor do SOPHIE
Gráfico ORM Aquisição, armazenamento, adaptação, disseminação e localização de recursos
Estrutura de tipos genérica. Aplicação define seu contexto
Middleware SOCAM
Ontologia Aquisição, compartilhamento, raciocínio, incerteza, qualidade, armazenamento, disseminação, localização de recursos
Localização física, pessoa, atividade e entidade computacional
Middleware CoBrA
Ontologia Aquisição, compartilhamento, raciocínio, armazenamento, segurança e privacidade
Localização física, agentes, atividade, papéis, intenções
Framework CXMS
Par chave-valor Aquisição, modelagem, armazenamento, definição do comportamento da aplicação, e apresentação da informação
Identidade, localização, tempo e ambiente
Context Toolkit
Par chave-valor Aquisição, agregação, armazenamento, disseminação, adaptação, localização de recursos
Identidade, localização, tempo e atividade
Middleware do Gaia
Ontologia Aquisição, compartilhamento, agregação, raciocínio, armazenamento, disseminação, adaptação, localização de recursos
Aplicações, serviços, dispositivos, usuários, fontes de dados, localização, atividades e informações climáticas
Framework de Contexto
Gráfico CML Aquisição, representação, agregação, armazenamento, disseminação e adaptação
Aplicação define seu contexto
Infra-Estrutura SCK
Ontologia Aquisição, conversão, armazenamento, consulta, inferência, disseminação e adaptação, localização de recursos, configurabilidade
Pessoa, grupo, organização, projeto, contato, papel, habilidades, relacionamentos, atividade, localização, dispositivo, tempo
Framework Conceitual
Quadros e Diagrama UML
Identificação e classificação dos elementos de contexto em groupware
Indivíduo, grupo, tarefa, interação, planejamento, ambiente e histórico
O próximo capítulo fala sobre colaboração contextual e revisa os estudos sobre aplicação de
contexto a sistemas colaborativos.
65
CAPÍTULO 6
Colaboração Contextual
Nos capítulos anteriores foi apresentada uma revisão do cenário de pesquisa atual sobre contexto e
construção de sistemas cientes de contexto. As pesquisas relacionadas a contexto computacional estão
mais avançadas nas áreas de Inteligência Artificial, onde contexto é associado à resolução de problemas, e
Computação Ubíqua, em que contexto é utilizado para ajudar a prover a computação “a qualquer hora e
em qualquer lugar, no lugar certo e na hora certa”.
Este capítulo faz uma revisão dos trabalhos que aplicam contexto à área de CSCW e discute quais
são os desafios apontados para inclusão de contexto em sistemas colaborativos. Para isso, inicialmente, é
apresentada a importância da existência de sistemas colaborativos cientes de contexto. A seguir, são
discutidas as diferenças entre os conceitos de contexto e percepção, uma vez que na literatura de CSCW
esses dois conceitos muitas vezes aparecem juntos, sem uma diferenciação explícita. Em seguida, são
abordadas questões relacionadas à identificação dos elementos de contexto em ambientes colaborativos e
algumas questões específicas do tratamento de contexto em ambientes colaborativos, como contexto
compartilhado, descasamento e perda de contexto. Por fim, é apresentado o uso de contexto na prática em
sistemas colaborativos, com destaque para mecanismos de percepção cientes de contexto.
6.1. SISTEMAS COLABORATIVOS CIENTES DE CONTEXTO
Sistemas colaborativos cientes de contexto são sistemas que utilizam o contexto atual dos usuários, o
contexto do grupo do qual esses usuários fazem parte, o contexto da atividade colaborativa em curso,
entre outros, para responder de forma inteligente às interações entre os usuários, oferecendo serviços e
informações relevantes para o grupo em sua situação corrente.
O uso de contexto em sistemas colaborativos ainda é um tópico em aberto. Poucos trabalhos fazem
referência explícita ao conceito de contexto, tal como ocorre em outras áreas (ex. Computação Ubíqua,
Inteligência Artificial, Interface Humano-Computador). Contexto aparece de forma embutida e,
geralmente, associado a outros conceitos como percepção e memória do grupo (Brézillon et al., 2004).
Borges et al. apontam como causas para esse problema a falta de representação explícita da noção de
contexto e a sua não-associação aos demais elementos dos sistemas colaborativos {Borges, 2006 32 /id}.
No entanto, o contexto é um tema que vem ganhando atenção dos pesquisadores de CSCW, o que é
evidenciado por vários trabalhos recentes, que estudam como o contexto pode ser modelado e gerenciado
em sistemas colaborativos {Borges, 2004 31 /id;Rosa, 2005 228 /id;Kirsch-Pinheiro, 2005 200
/id;Borges, 2006 32 /id;Brézillon, 2005 45 /id;Santoro, 2005 235 /id;Gross, 2003 112 /id;Alarcón, 2005 5
/id}. Esses autores concordam que o conhecimento sobre o contexto no qual ocorre uma determinada
66
interação pode ser útil para apoiar o trabalho colaborativo através do provimento de informações e
serviços relevantes para aquela situação. Essa adaptabilidade ao contexto é fundamental para que o apoio
ao trabalho em grupo seja efetivo e, com isso, aumente a usabilidade desses sistemas (Alarcón et al.,
2005a).
Os sistemas de groupware atuais apresentam muitos casos de sucesso, porém apresentam um
número bem maior de falhas, evidenciadas em problemas de usabilidade desses sistemas. Uma das causas
dos problemas de usabilidade é que o foco principal dos projetistas de groupware ainda está nas
ferramentas e na tecnologia por trás dessas ferramentas. Grudin (Grudin, 1994) identificou 8 desafios para
os desenvolvedores de groupware. Dentre esses, ele destaca a necessidade de levar em consideração não
apenas fatores tecnológicos no projeto, mas também a dinâmica social em que a atividade do grupo
ocorre, como fatores sociais, políticos, econômicos e culturais. As aplicações de groupware, em geral,
não consideram o amplo contexto social em que a interação ocorre, assumindo uma estrutura de papéis
estável e imutável (Alarcón et al., 2005a).
Como destacado em (Brézillon e Araújo, 2005), criar um ambiente de trabalho colaborativo efetivo
é uma questão de facilitar o contato e a comunicação entre os atores, a compreensão mútua e o
compartilhamento do conhecimento. O uso do contexto pode ser bastante útil para viabilizar todas essas
tarefas e, com isso, aumentar a produtividade do grupo, a qualidade do trabalho, e tornar os usuários mais
motivados a interagir. As informações contextuais constituem as condições relacionadas à atividade atual
dos usuários e como as ações dos seus colegas modificam tais condições. Essas informações são providas
aos membros do grupo para que possam compreender como suas ações se enquadram em relação aos
objetivos do grupo (Gutwin e Greenberg, 2002).
A efetividade e a produtividade de um grupo tem forte relação com a compreensão de uma dada
situação em que os usuários estão (Brézillon e Araújo, 2005). Conhecer o contexto que cerca uma
interação é muito útil para os usuários participantes dessa interação, uma vez que facilita o entendimento
dos eventos ocorridos, a comunicação entre os participantes e, consequentemente, a execução do trabalho
da equipe. Além disso, esse conhecimento do contexto ajuda a ampliar a compreensão da interação por
usuários que não participaram da mesma. Usuários que compartilham um contexto possuem mais
facilidades para interpretar dados de uma maneira suficientemente similar para ser útil do que aqueles que
estão em contextos divergentes (Brézillon e Araújo, 2005).
O contexto viabiliza uma compreensão mútua dos eventos ocorridos em uma interação e pode ser
utilizado para apoiar a identificação de convenções dentro do grupo. Convenções para um sistema
colaborativo são regras e padrões estabelecidos dentro do grupo que são comuns e acessíveis a todos os
seus membros e que ajudam os usuários a cooperar de forma mais efetiva (Mark et al., 1997). O contexto
ajuda, também, a estabelecer relações sociais, uma vez que o conhecimento do contexto é uma forma de
estabelecer e reforçar relações de confiança e de reputação entre os membros do grupo (Brézillon e
Araújo, 2005).
67
6.2. PERCEPÇÃO X CONTEXTO
Quando as pessoas trabalham juntas, de forma colaborativa, é crucial que elas percebam e compreendam
as coisas que acontecem ou aconteceram no contexto do seu grupo, e que sejam relevantes para o
acompanhamento e execução de suas atividades (Vieira, 2003). Essa definição evidencia a relação
existente entre percepção e o conhecimento do contexto do grupo. Brézillon et al. argumentam que, no
domínio de sistemas colaborativos, os conceitos de percepção e contexto não devem ser considerados de
forma separada, mas como complementares (Brézillon et al., 2004). No entanto, as semelhanças e
diferenças entre esses conceitos não são totalmente identificadas.
Contexto refere-se ao conjunto de informações que identificam, limitam e caracterizam uma
situação. Essa situação, em groupware, pode ser a interação entre membros do grupo ou entre um
indivíduo e o ambiente colaborativo, para a execução de tarefas necessárias para atingir os objetivos do
grupo. Essas informações incluem características do grupo (ex. objetivo, composição, distribuição de
tarefas), dos indivíduos (ex. quem são, habilidades, conhecimentos técnicos), da interação em curso (ex.
tarefa sendo executada), do ambiente de trabalho (ex. usuários presentes/disponíveis), entre outras.
A percepção representa um estado mental dos usuários (Sohlenkamp, 1998) e implica um
conhecimento e compreensão do que ocorre ou ocorreu no ambiente de trabalho que seja relevante para o
desenvolvimento das atividades dentro do grupo. Mecanismos de percepção indicam ferramentas e
procedimentos que apóiam os usuários do grupo a alcançar esse estado mental.
Como exemplo, considere um cenário onde um usuário se conecta a uma ferramenta de reunião
eletrônica, inserida em um ambiente de aprendizagem colaborativa, onde diversos outros usuários estão
presentes e discutem um tópico associado a uma disciplina. Os usuários presentes, o assunto em
discussão, a disciplina associada ao assunto, o professor que ministra a disciplina, o moderador
responsável pela discussão e o histórico do que já foi discutido são todas informações contextuais
referentes à atividade colaborativa em curso. Quando o usuário entra no ambiente e toma conhecimento
dessas informações, ele está sendo contextualizado sobre o que está acontecendo e ocorreu no ambiente
durante a sua ausência, para que, dessa forma, ele possa se situar dentro da discussão e participar dela,
colaborando com o grupo. Essa contextualização é a percepção, a qual é viabilizada e fornecida por um
ou mais mecanismos de percepção. Por exemplo, um mecanismo de percepção pode ser responsável por
apresentar ao usuário um resumo das atividades ocorridas durante sua ausência, enquanto outro
mecanismo de percepção envia notificações cada vez que um novo usuário se conecta à ferramenta.
6.3. IDENTIFICAÇÃO DOS ELEMENTOS DE CONTEXTO
Uma questão que surge na aplicação de contexto a groupware é identificar onde e como o contexto pode
ser usado e que tipo de informação pode ser considerada como parte do contexto no ambiente
colaborativo. Quando as pessoas trabalham em grupo não apenas o contexto dos indivíduos deve ser
68
considerado, mas também o contexto do grupo (Borges et al., 2004). As informações contextuais podem
ser relativas ao ambiente físico dos membros do grupo ou ao ambiente virtual onde eles interagem, bem
como podem ser relativas às próprias pessoas, ao grupo, ou à memória do grupo (interações históricas).
Brézillon et al. classificam o contexto em três diferentes níveis de granularidade, como mostra a
Figura 6.1: o contexto do grupo (ex. porque e como o grupo foi constituído), o contexto dos vários
indivíduos que compõem o grupo (ex. suas habilidades e origens técnicas) e o contexto do projeto ao qual
o grupo está vinculado (ex. o produto a ser construído pela equipe) (Brézillon et al., 2004).
Figura 6.1 – Níveis de contexto em ambientes colaborativos (Brézillon et al., 2004)
O framework conceitual de contexto em groupware (Rosa et al., 2003), explicado na Seção 0,
agrupa os elementos do contexto em cinco dimensões (ver Figura 6.2): pessoas, tarefas a realizar, relações
entre pessoas e tarefas, ambiente e tarefas já realizadas. As informações sobre as pessoas referem-se ao
contexto do indivíduo e ao contexto do grupo que esses indivíduos fazem parte. O contexto do indivíduo
identifica e caracteriza as pessoas que compõem o grupo através de informações como nome, habilidades,
interesses, formação e experiência, localização geográfica, dados pessoais e horários de trabalho. Esse
tipo de contexto, de uma maneira geral, é atendido, mesmo que de forma incompleta, pela maioria das
ferramentas de groupware existentes (Rosa, 2004). O contexto do grupo inclui informações que
identificam e caracterizam os grupos constituídos, como nome, membros, papéis, habilidades, interesses e
experiências prévias do grupo, estrutura organizacional, horário de trabalho e sede geográfica.
As informações sobre as tarefas a realizar identificam e caracterizam as tarefas a serem realizadas
pelo grupo e surgem quando da definição da tarefa. O contexto da tarefa inclui informações como nome,
descrição, objetivo, prazo, pré-requisitos, tecnologia envolvida, homem/hora necessários, ações a serem
realizadas e restrições. As informações sobre as relações entre pessoas e tarefas visam relacionar as
ações de cada membro do grupo durante as interações com as tarefas a serem realizadas e são
caracterizadas pelo contexto da interação e pelo contexto do planejamento. O contexto da interação é
dependente do tipo da interação: (i) em interações síncronas, é composto por informações detalhadas
sobre as tarefas em andamento, como os participantes presentes na interação, as mensagens trocadas ou as
ações realizadas caracterizadas pelo seu autor; (ii) em interações assíncronas, o que muda é a
granularidade da informação, menos detalhada e mais geral, e inclui as alterações ocorridas desde o
último acesso de um membro, caracterizadas pelos autores, objetivos e datas de realização, bem como a
69
evolução das versões dos artefatos produzidos. O contexto do planejamento representa o plano de ação da
equipe através de informações como papéis dos indivíduos na interação, regras, metas, responsabilidades,
estratégia, procedimentos de coordenação e plano de trabalho, as quais podem ser definidas como produto
das interações, no caso de tarefas realizadas de forma ad hoc, ou, em tarefas programadas, são definidas
quando as tarefas são detalhadas e atribuídas ao grupo.
Figura 6.2 – Composição do contexto de uma atividade (Rosa, 2004)
As informações sobre o ambiente representam o espaço onde ocorrem as interações e onde estão
inseridas as tarefas a serem executadas. Esse contexto é caracterizado por informações como as regras a
serem respeitadas, os padrões de qualidade a serem observados, procedimentos e estratégias
padronizadas, os prazos institucionais, as estruturas organizacionais da instituição, as decisões políticas e
restrições financeiras, a plataforma de hardware e software. Em seu estudo, Rosa não encontrou
ferramentas de groupware que disponibilizassem informações sobre o contexto do ambiente.
As informações sobre as tarefas já realizadas caracterizam as interações passadas, realizadas pelo
próprio grupo ou por outros grupos, e tem por objetivo oferecer subsídios sobre experiências aprendidas
em tarefas já concluídas, e permitir que o grupo entenda de que forma as tarefas já concluídas foram
realizadas, além dos fatores que influenciaram a execução. Essas informações constituem o contexto
histórico e incluem a composição da equipe, a especificação da tarefa, a elaboração do planejamento da
execução e a execução da tarefa. Para isso são descritos o nome da tarefa, seu objetivo, plano de trabalho,
ações realizadas, o autor, objetivo e justificativa de cada ação, a data de realização, versões de artefatos e
outras informações utilizadas na execução da tarefa.
Alarcón et al. identificam, de uma forma geral, que os elementos comuns mínimos para determinar
o contexto de um grupo são pessoas, tarefas ou projetos, e recursos (Alarcón et al., 2005b). Informações
de contexto das pessoas incluem conhecimento da organização dos membros no grupo, papéis e
responsabilidades, localização física ou virtual da pessoa, presença, co-presença, distância entre membros
do grupo, proximidade, visibilidade, disponibilidade, estados emocionais do usuário e ações executadas
pelos outros membros do grupo. O contexto da tarefa inclui conhecimento sobre a estrutura e distribuição
70
das tarefas no projeto, e o estado de execução das tarefas pelos membros do grupo (ex. em execução,
finalizada, a executar). O contexto dos recursos implica em conhecer os recursos disponíveis para o
grupo, sua localização e formas de utilizá-los. Os recursos disponíveis em um grupo podem ser conceitos,
informações (ex. documentos e figuras), artefatos de software, artefatos de trabalho (ex. modelos de
documento), representações de objetos físicos (ex. o endereço IP de uma impressora compartilhada), ou,
ainda, recursos humanos como especialidades, conhecimento, e interesses dos membros do grupo
(Alarcón et al., 2005b).
Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2004) propõem um mecanismo de percepção baseado
em contexto que filtra as informações entregues ao usuário de acordo com uma descrição contextual. O
contexto é representado através de cinco entidades principais: espaço, indica a localização física;
ferramenta, refere-se aos dispositivos físicos e aplicações; tempo, calendário de trabalho do grupo;
comunidade, composição da comunidade incluindo o grupo, os usuários e os papéis; e processo, fluxo de
trabalho executado pelo grupo, incluindo conceitos de atividades e artefatos compartilhados. A partir
desses conceitos principais, foi definida a estrutura de representação de contextos ilustrada na Figura 6.3.
Figura 6.3 – Representação de contexto proposta por Kirsch-Pinheiro et al. (Kirsch-Pinheiro et al., 2004)
6.4. PROCESSAMENTO DO CONTEXTO
Borges et al. propõem um modelo de processamento do conhecimento contextual segundo o qual as
pessoas criam individualmente o conhecimento, o qual é comunicado ao resto do grupo, apresentado em
uma interface gráfica com o usuário e, eventualmente, armazenado (Borges et al., 2004). O modelo
ilustrado na Figura 6.4 se divide em 6 etapas: (1) geração ou construção do conhecimento, ocorre quando
uma pessoa realiza alguma contribuição repassando conhecimento para o grupo; (2) captura, consiste na
obtenção de dados da etapa de geração, como presença e disponibilidade dos indivíduos, movimentação
do mouse ou imagem de uma câmera; (3) percepção, indica o processamento, filtragem e agregação das
informações obtidas dos passos de geração, captura e armazenamento para que sejam fornecidas aos
demais participantes; (4) armazenamento, refere-se à persistência das informações produzidas para
garantir a memória do grupo; (5) visualização, refere-se à exibição da informação para o usuário através
de uma interface gráfica; (6) interpretação, implica na internalização do conhecimento pelos indivíduos
71
do grupo, que ocorre quando uma pessoa assimila em conhecimento a informação visualizada e seu
contexto individual.
Figura 6.4 – Processamento do contexto no trabalho em grupo (Borges et al., 2004)
Tornar o contexto explícito serve para prover o raciocínio, a lógica utilizada no desenvolvimento
do trabalho colaborativo, sendo uma forma de lembrar o modo como uma solução foi desenvolvida, as
alternativas no momento em que a solução foi construída e as restrições existentes (Borges et al., 2004).
6.5. OUTRAS QUESTÕES ASSOCIADAS A CONTEXTO NO TRABALHO EM GRUPO
O uso do contexto em ambientes de trabalho em grupo traz desafios adicionais em relação ao que ocorre
em outros domínios, onde apenas o contexto de um indivíduo é considerado. Dentre esses desafios estão o
contexto compartilhado, o descasamento de contexto e a perda de contexto, descritos a seguir.
6.5.1. Contexto Compartilhado
Na solução conjunta de um problema, os membros do grupo tentam alinhar seus contextos individuais de
modo a torná-los compatíveis com o contexto compartilhado do grupo (Brézillon, 2005). Santoro et al.
definem contexto compartilhado como um espaço de conhecimento compartilhado que é explorado e
utilizado pelos participantes (Santoro et al., 2005).
O estabelecimento de um contexto compartilhado se torna mais difícil proporcionalmente ao
tamanho do grupo. Assim, grupos pequenos, coesos, bem formados e estruturados possuem maior
facilidade na construção de um contexto compartilhado. A natureza de formação do grupo também
influencia a construção do contexto compartilhado. Os grupos podem ser permanentes ou temporários
(Brézillon, 2005). Grupos permanentes seguem uma hierarquia estática dentro da organização, como por
exemplo, os funcionários pertencentes a um departamento. Grupos temporários surgem ou são criados em
virtude de oportunidades ou problemas que atingem a organização, e são desfeitos tão logo o problema
72
seja solucionado (Brézillon, 2005). O contexto compartilhado associado a um grupo permanente
apresenta um conjunto estável de conhecimento contextual. Por outro lado, o contexto compartilhado de
grupos temporários são construídos em tempo de execução, cada vez que um problema ou oportunidade
aparece, a partir do contexto compartilhado da organização e dos grupos permanentes de onde vêm os
membros dos grupos temporários (Brézillon, 2005).
Os membros do grupo podem compartilhar elementos contextuais dos seus contextos individuais
para construir colaborativamente um contexto proceduralizado para a solução de uma tarefa em um
contexto de interação. O compartilhamento do contexto não significa desenvolver uma visão idêntica da
solução para todos os participantes, mas criar visões compatíveis desses participantes sobre uma solução
(Brézillon, 2005). A Figura 6.5 ilustra uma representação do contexto compartilhado gerado a partir dos
conhecimentos individuais de dois participantes em uma interação. O contexto compartilhado é a
interseção dos contextos individuais, é o conhecimento comum aos dois indivíduos necessário para a
resolução do problema ou execução da tarefa. As informações que fazem parte do contexto
proceduralizado na execução colaborativa da tarefa se tornam parte do conhecimento contextual
compartilhado dos indivíduos (Santoro et al., 2005).
Figura 6.5 – Construção do contexto compartilhado na interação entre dois participantes (Brézillon, 2003a)
6.5.2. Descasamento de Contexto
No trabalho em grupo é importante desenvolver um contexto compartilhado robusto e coeso. Uma
compreensão comum desse contexto externo deve ser reforçada entre os membros antes do começo das
interações do grupo e todas as diferenças na compreensão do contexto devem ser identificadas e
reduzidas. Se houverem discrepâncias na compreensão do contexto externo e do contexto compartilhado
que não sejam resolvidas antes do início das atividades, elas provavelmente aparecerão durante a
interação, paralisando-a até que as questões sejam resolvidas. Borges et al. denominaram essas diferenças
na compreensão do contexto por membros de um grupo como descasamento de contexto (context
mismatch) {Borges, 2006 32 /id}. Descasamento de contexto significa, pois, uma falha na construção de
um contexto compartilhado coeso, o que significa que não há interseção entre os contextos individuais.
73
6.5.3. Perda de Contexto
Um tipo de contexto relevante refere-se às atividades executadas durante a tarefa, ou o contexto da tarefa,
que é o contexto relativo aos artefatos pertinentes para sua execução. Durante uma interação, uma perda
de contexto temporária pode ocorrer, resultante da ausência de um indivíduo ou da ambigüidade de
alguma ação. Enquanto o contexto externo é normalmente processado fora da interação monitorada, o
sistema deve prover suporte interno para se recuperar de uma perda de contexto {Borges, 2006 32 /id}.
Mecanismos de percepção podem ser utilizados para lidar com a perda temporária de contexto. No
entanto, os participantes da tarefa devem compartilhar um mesmo contexto geral, ou seja, eles devem
compreender e concordar com o contexto do grupo (ex. papéis), da tarefa (ex. prazos e objetivos) e da
organização (ex. cultura e hierarquia). Por exemplo, não adianta saber que um participante chamado João
contribuiu em uma discussão ou realizou uma ação sobre um artefato compartilhado que causou impacto
na atividade de um outro participante chamado José, se José não sabe quem é João ou qual é o seu papel
dentro da tarefa {Borges, 2006 32 /id}.
6.6. USO DE CONTEXTO EM SISTEMAS COLABORATIVOS
Esta seção apresenta alguns trabalhos que tratam explicitamente do uso de contexto em groupware.
Percebe-se que o uso de contexto aparece fortemente associado a mecanismos de percepção seletiva ou a
groupware móvel. Além desses, contexto é usado para apoiar recomendações em ferramentas de
groupware.
6.6.1. Mecanismos de Percepção Contextual
A percepção contextual utiliza o conceito de contextos para determinar que tipo de informação os
usuários desejam e de que forma eles podem estar atentos, de modo a separar informações de percepção
das informações de “perturbação” (Liechti, 2000). Nesse tipo de percepção deve-se identificar quais são
as pessoas do grupo e que artefatos eles estão interessados, de modo que somente um subconjunto dos
eventos possa ser identificado como crítico e notificado ao usuário.
Como discutido na Seção 2.3.4, um dos desafios no desenvolvimento de mecanismos de percepção
é evitar que os usuários sejam sobrecarregados com um grande volume de informações de percepção, que
desviem sua atenção. A percepção para ser efetiva deve atingir a visão periférica do usuário e as
informações devem ser absorvidas sem um esforço consciente que desvie o foco de atenção da tarefa em
execução. O contexto tem um papel fundamental no apoio à percepção periférica, pois permite que o
mecanismo de percepção conheça a situação atual do usuário. Dessa maneira, o mecanismo pode adaptar
sua funcionalidade filtrando informações irrelevantes nesse contexto ou alterando a forma de exibição das
informações ou, ainda, omitindo informações em um determinado momento em que o usuário não está
disponível para recebê-las, apresentando-as em um momento posterior. Esses mecanismos são
denominados mecanismos de percepção contextual.
74
Os artefatos compartilhados devem se adaptar a situações de trabalho que se modificam
continuamente, através do provimento de informações de percepção com diferentes focos. Uma vez que
qualquer noção de uma situação de trabalho necessariamente é relativa a práticas pessoais de trabalho, o
sistema deve permitir que os usuários adequem individualmente quando, como e onde as informações de
percepção devem ser providas (Mark et al., 1997).
Trabalhos mais atuais como (Gauvin et al., 2004) usam o termo percepção situacional (situational
awareness) para esse tipo de percepção, que usa o contexto do trabalho para prover percepção
personalizada de acordo com uma determinada situação. Nesse trabalho, eles propõem um portal de
conhecimento com percepção situacional que visa prover cada indivíduo com uma área de conhecimento
customizada (denominada portfólio), orientada a missões, que forneça acesso a informações corretas
provenientes de múltiplas fontes no contexto do trabalho. Para isso, eles usam ontologias para prover
integração semântica entre os recursos das diversas fontes.
O contexto em que ocorrem as ações depende fortemente da intenção da pessoa que executou tal
ação. De modo a tornar esse contexto acessível a outras pessoas, ele deve ser explicado ou classificado
pelo próprio executor. Uma abordagem utilizada para explicar o contexto de uma ação visando uma
compreensão mútua desse contexto é chamada mecanismo de percepção informacional (Dourish e
Bellotti, 1992). Nesse modelo, os colegas podem informar uns aos outros sobre suas atividades através de
funcionalidades explícitas, como arquivos de log compartilhados. Porém, prover uma auto-descrição para
cada ação relevante executada implica em um aumento significativo no volume de trabalho o que pode
sobrecarregar o usuário e tornar a tarefa inviável, acarretando no que Grudin classificou como problema
da disparidade entre trabalho e benefício (Grudin, 1994).
No entanto, o usuário deve ter uma participação ativa na explicação das suas intenções e dos
contextos a que suas ações pertencem, uma vez que nem sempre essas intenções podem ser inferidas a
partir das suas ações físicas. Dessa maneira, ferramentas que lidem com a percepção contextualizada
devem apoiar o usuário tanto quanto possível e reduzir a um volume mínimo a quantidade extra de
trabalho necessária para criar a informação contextual.
Em (Rittenbruch, 1999) é introduzido o conceito de mecanismo de percepção seletiva por contexto.
Rittenbruch argumenta que em interações síncronas os membros do grupo têm condições de compreender
o contexto em que está ocorrendo uma dada ação, seja pelos eventos que estão ocorrendo no espaço
compartilhado, ou pela comunicação imediata com os participantes da interação. Porém, em interações
assíncronas, onde pode haver um grande intervalo de tempo entre a ocorrência da ação e a sua
comunicação para um determinado membro do grupo, não é trivial comunicar o contexto em que a ação
se deu. Com isso, em geral, a forma de contextualizar ações ocorridas em interações assíncronas é através
de um modelo de eventos que é atualizado sempre que os usuários executam ações que manipulem
artefatos compartilhados (como documentos de texto, classes em diagramas UML). Uma conseqüência
desse modelo de percepção é que fatalmente o usuário será sobrecarregado com um grande volume de
eventos, muitos dos quais totalmente irrelevantes para sua contextualização.
75
Para resolver esse problema, Rittenbruch propõe a representação de contexto nos sistemas
colaborativos e a associação de informações relevantes para a percepção a esses contextos, através do
Atmosphere. O Atmosphere utiliza contextos pré-definidos, chamados de esferas (spheres), os quais
permitem que usuários ou grupos de usuários configurem previamente o contexto e, ao executar uma
ação, selecionem o contexto apropriado dentro do qual a ação se insere. As esferas podem ser
configuradas conjuntamente e são ordenadas de forma hierárquica. A configuração de uma esfera é
flexível e pode representar contextos organizacionais (como unidades ou departamentos) ou contextos
sociais ou físicos (como tempo ou espaço). Uma esfera contém o conjunto dos artefatos compartilhados,
possíveis sub-esferas e um conjunto do que eles chamam de contextors, que representam o nível de
granularidade mais baixo de uma esfera. Enquanto as esferas representam contextos particulares, os
contextors representam ações (que podem ser relativas a tarefas) dentro desse contexto específico. Ao
executar uma ação, ou um conjunto de ações, sobre um artefato que é representado em uma esfera
particular, o usuário pode escolher um contextor para classificar a ação executada em um nível menor de
granularidade. Em relação a eventos, os contextors e suas esferas superiores podem ser compreendidos
como dicas de eventos.
No sistema POLITeam (Mark et al., 1997) é utilizado o conceito de situações de trabalho para
permitir que usuários especifiquem perfis de percepção, que apóiem o sistema na filtragem seletiva das
informações de percepção. Para isso, um artefato compartilhado, como um documento, define um número
de atividades bem como uma variedade de situações de trabalho (alguns exemplos aparecem na Tabela
6.1) as quais podem ser selecionadas pelo usuário para adequar suas preferências pessoais de percepção à
sua prática individual de trabalho.
Tabela 6.1 - Exemplos de situações de trabalho onde usuários podem receber informações de percepção relacionadas a um documento (Mark et al., 1997)
Essas situações de trabalho são dinâmicas e não devem ser restritas apenas a ações executadas
sobre o artefato alvo em si, mas deve incluir ações sobre artefatos que compartilhem relacionamentos ou
similaridades no domínio da aplicação. Os detalhes sobre preferências de percepção podem ser definidos
usando perfis de percepção, que podem ser anexados a um artefato ou a um conjunto de artefatos. O
sistema realiza a notificação de eventos apenas em situações que casem com um conjunto de perfis aos
quais o usuário estiver inscrito. Por exemplo, o usuário pode configurar a seguinte preferência: “sempre
que eu abrir qualquer documento, eu gostaria de ver o que ocorreu em outros documentos que pertencem
ao mesmo processo” (Mark et al., 1997).
76
A infra-estrutura ENI (Event and Notification Infrastructure) é um ambiente de percepção genérico
e extensível, baseado em eventos (Gross e Prinz, 2003). Avaliações feitas com os usuários do ENI
revelaram que a informação de percepção nem sempre era provida em uma situação de muita utilidade, e
que algumas vezes a informação era reduzida e em outras muito detalhada. A partir desses estudos Gross
e Prinz (Gross e Prinz, 2003) definiram requisitos que os ambientes de percepção devem seguir para
prover suporte à percepção em um grupo: (1) Personalizar e adaptar o tipo da informação de percepção e
sua forma de apresentação à situação atual do usuário, levando em consideração questões como sua tarefa
atual, o tipo da interação (síncrona ou assíncrona), os artefatos e as ferramentas em uso; (2) Prover não
apenas a informação de percepção em si, mas também informações sobre o seu contexto de origem. Para
atender a esses requisitos, o sistema deve conhecer ou deduzir o contexto de origem de um evento e o
contexto atual de trabalho do usuário que será notificado e deve permitir que o usuário especifique em
qual situação ele deseja ser informado sobre os eventos de um contexto específico e em qual formato
específico. A Figura 6.6 apresenta os passos para obtenção desse contexto: os passos 1 e 3 ilustram a
associação de um evento a um contexto, no momento da criação do evento; e o passo 2 ilustra a
associação de usuários a seu contexto de trabalho atual, baseado em suas atividades atuais.
Figura 6.6 – Passos para inclusão do contexto de percepção no ENI (Gross e Prinz, 2003)
Kirsch-Pinheiro et al. propõem um processo de filtragem de eventos que contenham informações
de percepção sensível ao contexto do usuário {Kirsch-Pinheiro, 2005 200 /id} e um modelo de acesso
progressivo às informações de percepção (Kirsch-Pinheiro et al., 2003). A idéia é utilizar o contexto para
possibilitar que os mecanismos de percepção se adaptem às necessidades atuais de cada usuário, provendo
informações de percepção que sejam úteis e essenciais para aquele usuário em relação à tarefa que ele
está executando no momento e o papel que está desempenhando no grupo. O acesso progressivo visa
separar as informações para percepção em níveis de importância, e apresentar aos usuários,
prioritariamente, as informações dos níveis mais altos. Caso o usuário deseje ele pode, progressivamente,
adquirir mais percepção através de consultas aos demais níveis.
77
6.6.2. CO2DE
O CO2DE (Collaborate to Design) é um groupware que permite o desenvolvimento colaborativo por um
grupo de usuários conectados a uma sessão, do diagrama de colaboração especificado pela UML 1.3
(Meire, 2003). O CO2DE possibilita a edição colaborativa síncrona através de uma interface WYSIWIS
(What You See Is What I See), ou seja, todos os participantes possuem uma mesma visão do diagrama e
podem trabalhar simultaneamente em sua criação. Para lidar com possíveis conflitos durante a edição, o
CO2DE permite que diversas versões do diagrama coexistam, através de um conceito denominado
máscaras.
Em experimento realizado por Meire, os participantes apontaram dificuldades enfrentadas pela
ausência de informações do contexto da interação como a identificação da máscara onde os demais
participantes estariam trabalhando dentro da sessão. Outra dificuldade apontada foi relacionada ao
entendimento da tarefa a ser executada, pois o CO2DE não disponibiliza informações do contexto da
tarefa (Meire, 2003). Além disso, o sistema não guarda o contexto em que cada versão foi criada, como
qual foi o conflito ou o raciocínio por trás da criação de uma nova versão {Borges, 2006 32 /id}.
A aplicação de contexto ao CO2DE foi implementada como validação do framework conceitual de
contexto em groupware (Rosa, 2004). Foram implementados na ferramenta os seguintes requisitos de
contexto (Rosa, 2004): (i) Possibilitar cadastro prévio dos usuários com informações que os identifiquem
e caracterizem; (ii) Permitir o login em uma sessão de modelagem somente para usuários previamente
cadastrados; (iii) Permitir, durante a interação, identificar os outros participantes da sessão; (iv) Permitir,
durante a interação, consulta às informações dos outros membros do grupo que participam da sessão de
trabalho; (v) Solicitar que o coordenador do grupo informe o objetivo da tarefa e detalhes sobre sua forma
de execução; (vi) Permitir a criação dos diagramas através da geração de máscaras intermediárias; (vii)
Solicitar informações que permitam identificar e caracterizar cada máscara criada; (viii) Identificar em
que máscara cada participante da interação está trabalhando; (ix) Disponibilizar o objetivo de cada
máscara criada; (x) Permitir a troca de mensagens entre os usuários durante uma interação; e (xi)
Possibilitar a consulta às mensagens já trocadas durante a interação.
Para avaliar o uso do contexto no CO2DE foi realizado um experimento com a ferramenta, dividido
em duas etapas: (1) sem os recursos de contexto (no caso, os recursos de versionamento baseado em
máscaras e de anotações); e (2) com esses recursos habilitados (Rosa et al., 2005). A análise dos
resultados do experimento permitiram que eles identificassem indícios de que a disponibilização de
mecanismos para acesso às informações sobre o contexto da interação ajuda os membros do grupo,
potencializando a cooperação. Constataram, também, que interações síncronas e assíncronas necessitam
de diferentes informações para contextualização (Rosa et al., 2005).
6.6.3. ConChat
Comunicações mediadas por dispositivos perdem muito do contexto que cerca as pessoas que estão
interagindo. “Aumentar a comunicação mediada por dispositivos com informações contextuais enriquece
78
a interação dos usuários” (Ranganathan e Lei, 2003). Os programas de comunicação atuais, como chat ou
mensagens instantâneas, permitem que os usuários indiquem seu estado, como “disponível”, “ocupado”,
“ao telefone”, “em horário de almoço”. O MSN (Microsoft, 2003) permite, ainda, que usuários saibam
que música seus amigos estão ouvindo no momento, através do compartilhamento de informações entre o
MSN e o programa executor de áudio em uso na estação do usuário. Porém, o conjunto de informações
contextuais disponíveis nesses programas ainda é muito limitado.
ConChat é um programa de conversação que enriquece a comunicação eletrônica por meio de
informações contextuais e pela resolução de potenciais conflitos semânticos entre usuários (Ranganathan
et al., 2002). O ConChat permite que os usuários consultem o contexto dos demais usuários através de um
canal de contexto separado do canal de conversação. O contexto pode ajudar o usuário a entender porque
o outro está demorando muito para responder (está ao telefone, conversando com outra pessoa ou
envolvido em uma atividade urgente), e pode ajudar a esclarecer possíveis conflitos semânticos que
tornem as mensagens ambíguas.
As informações contextuais usadas no ConChat são mantidas e gerenciadas através da infra-
estrutura Gaia (ver Seção 5.2.6) e utiliza seu modelo de representação de contexto. As informações
contextuais existentes e tratadas no ConChat são: localização dos usuários, número de outras pessoas na
sala física onde o usuário se encontra, identidade dessas outras pessoas, temperatura, luz e som da sala,
outras aplicações e dispositivos em execução na sala, humor dos usuários (ex. feliz, triste ou empolgado),
estado dos usuários (ex. em almoço ou ao telefone), e atividade na sala (ex. reunião ou apresentação)
(Ranganathan et al., 2002).
A Figura 6.7 apresenta uma visão geral da arquitetura do ConChat. O cenário apresenta dois
usuários A e B cada qual em um ambiente de computação pervasiva. Usuários se registram a um servidor
central, através do qual encontram os usuários com os quais desejam estabelecer a comunicação. Cada
instância do ConChat contacta o motor de contexto e obtém referências de provedores dos contextos do
seu interesse e pode se inscrever para obter informações sobre atualizações desses contextos. Se o
ConChat do usuário B desejar saber informações sobre o usuário A, ele pode enviar uma consulta ao
ConChat de A, o qual irá processar essa consulta e retornar ao ConChat de B os resultados. O ConChat de
B também poderá solicitar ao ConChat de A que seja notificado sempre que ocorrer uma determinada
mudança no contexto de A. Por exemplo, o ConChat de B pode solicitar que seja notificado sempre que
uma outra pessoa entrar na sala onde o ConChat de A está sendo executado. Para diminuir questões
relacionadas à privacidade, os usuários podem configurar quais informações contextuais podem ser
notificadas a outros usuários, através de uma tabela de controle de acessos.
79
Figura 6.7 - Arquitetura do ConChat (Ranganathan et al., 2002)
O ConChat trata alguns conflitos semânticos relacionados à escala, como o uso de diferentes
sistemas de medida; ao tempo, como diferentes fusos horários; a formatos de data e de moeda, diferentes
unidades, além de resolver termos simples como football (que possui diferentes significados para
moradores dos EUA ou da Europa). Todos esses conflitos são dependentes da localização dos usuários
envolvidos. A Figura 6.8 mostra um exemplo de uma interface do ConChat. No campo de mensagem, o
texto (!-8:00 (PST)!) foi inserido pelo ConChat para esclarecer o fuso horário do usuário Amelie.
Figura 6.8 – Interface do ConChat (Ranganathan et al., 2002)
6.6.4. Contexto em Sistemas Colaborativos Móveis
Com a expansão das tecnologias de comunicação e dos dispositivos móveis, e o aumento em seu poder de
processamento, diversas áreas da computação vêm estudando como desenvolver sistemas para esse tipo
de plataforma. Na área de CSCW, trabalhos recentes investigam a criação e adaptação de sistemas de
80
groupware para dispositivos móveis, levando em consideração a necessidade de apoiar membros do
grupo que se deslocam frequentemente (Luff e Heath, 1998; Costa e Antunes, 2002; Filippo et al., 2005;
Alarcón et al., 2005a).
Nesse cenário, surgem alguns novos requisitos para o projetista do groupware, como lidar com
limitações de tamanho da tela, memória disponível, capacidade da bateria, velocidade do processador,
facilidades de entrada. Além disso, é fundamental o tratamento do contexto atual de uso desses
dispositivos, pois ele muda constantemente (Alarcón et al., 2005a).
Alarcón et al. desenvolveram um framework de elementos contextuais para sistemas colaborativos
em cenários móveis, classificado em seis contextos: contexto do cenário físico, contexto social, contexto
computacional, contexto da interação, contexto do suporte tecnológico e contexto da tarefa em andamento
(Alarcón et al., 2005a).
O AulaNetM (Filippo et al., 2005) é uma extensão ao ambiente de aprendizado colaborativo
AulaNet (Fuks et al., 2002) para tornar possível o uso de recursos de mobilidade. Um dos fatores
importantes no desenvolvimento do AulaNetM é o mapeamento das informações de contexto relevantes
para o ambiente de aprendizado (Figura 6.9). O contexto permite aos alunos uma melhor compreensão
dos objetivos do seu estudo, que os auxiliará a decidir suas próximas ações.
Figura 6.9 – Inclusão do contexto ao Modelo 3C no AulaNetM (Filippo et al., 2005)
6.6.5. Serviços de Recomendação Sensíveis ao Contexto
Um exemplo de como contexto pode ser aplicado em um sistema colaborativo é o de
recomendação baseada em análise de conteúdo e contexto. Esse tipo de recomendação foi observada no
sistema de gerenciamento de emails fornecido pela Google, o GMail (Google, 2006). O GMail mantém
uma área de propaganda periférica em seus sistemas, embutida na tela de visualização dos emails. Essas
propagandas são sensíveis ao conteúdo da mensagem de email que o usuário está lendo, como mostra a
Figura 6.10. Percebe-se que o texto fala sobre a elaboração de uma monografia de pós-graduação com
tema na área de data warehouse. Desse modo, as propagandas exibidas (área sponsored links) exibem
sugestões de páginas comerciais relacionadas à elaboração de monografias ou a data warehouse.
81
Figura 6.10 – Propaganda sensível ao contexto no GMail
Em um ambiente de aprendizado colaborativo, por exemplo, o contexto pode viabilizar serviços
como a recomendação de material didático compatível com o nível dos usuários e com os pontos da
discussão onde ocorreram maiores dúvidas. Além disso, o contexto pode apoiar a formação de grupos de
trabalho, sugerindo indivíduos que possuam perfis complementares para compor grupos, levando em
conta o contexto do grupo, da tarefa e dos indivíduos envolvidos. Adicionalmente, ele pode recomendar
grupos de trabalho ou especialistas que possam colaborar com a atividade em curso.
6.7. CONSIDERAÇÕES FINAIS
Inserir contexto em sistemas colaborativos traz os mesmos requisitos e desafios identificados no Capítulo
3 para sistemas cientes de contexto em outras áreas, como Computação Ubíqua. Porém, em sistemas
colaborativos os desafios são ampliados com a necessidade de considerar não apenas contextos dos
indivíduos, mas contextos do grupo, do projeto e da tarefa em que o indivíduo está engajado.
Este capítulo discutiu as questões associadas à inclusão de contexto em sistemas colaborativos.
Para isso foi feita uma diferenciação entre contexto e percepção, foram apresentadas algumas propostas
para identificação do que considerar como contexto em sistemas colaborativos, foram abordadas questões
específicas de contexto associados à área de sistemas colaborativos, como contexto compartilhado,
descasamento e perda de contexto, e foi ilustrado o uso do contexto em algumas ferramentas, relacionadas
à percepção seletiva, groupware móvel e recomendações em groupware.
O uso de contexto em groupware difere bastante do uso de contexto em computação ubíqua, pois
esse tipo de aplicação se baseia muito no uso de sensores físicos para aquisição do contexto, uma vez que
as informações sobre o ambiente físico do usuário são as mais relevantes. Em groupware, pouca
82
informação sobre o ambiente físico do usuário é realmente relevante. Informações sobre o ambiente
virtual em que o usuário está trabalhando e informações sobre a organização do grupo, como os
componentes, divisão de tarefas, prazos, entre outros, são as informações contextuais de interesse. Porém,
não existem padrões para essas informações, como ocorre com as informações do ambiente físico.
As informações contextuais devem, sempre que possível, ser obtidas de forma automática. Porém,
como esse tipo de aquisição pode gerar incertezas é necessário que o usuário também participe validando
as deduções e inferências feitas pelo sistema. Em groupware, devido à natureza da informação e à
ausência de padrões para os dados de contexto, exige-se uma maior participação do usuário na aquisição
do contexto, fornecendo previamente informações que auxiliem o sistema a entender quem é esse usuário,
quais as características do grupo que ele participa, e detalhes sobre suas tarefas associadas. Essa demanda
extra de preenchimento de informações pode desmotivar o usuário a utilizar a ferramenta ou pode levá-lo
a preencher de forma errônea ou incompleta, apenas para “se livrar logo” da tarefa. Os benefícios no uso
do contexto deve ser percebido logo pelo usuário para motivá-lo a continuar alimentando o sistema.
Ainda não há muitos resultados concretos no que diz respeito ao gerenciamento de contexto em
sistemas colaborativos. Pesquisadores indicam que são necessárias experiências práticas do uso do
contexto, para que essa prática enriqueça as discussões teóricas. Esta pesquisa parte desse ponto e tem
como objetivo prover um mecanismo para gerenciamento de contexto que gerenciar informações
contextuais provenientes de ambientes de trabalho colaborativo. A proposta deste trabalho é detalhada no
próximo capítulo.
83
CAPÍTULO 7
Um Framework para Gerenciamento de Contexto em Sistemas Colaborativos
Este capítulo descreve a proposta desta tese para lidar com o problema de gerenciamento de contexto em
sistemas colaborativos. Para isso, são apresentados na Seção 7.1 a motivação para realização deste
trabalho e os objetivos que se deseja alcançar. A Seção 7.2 define alguns conceitos utilizados na proposta.
Na Seção 7.3 é apresentado o framework proposto para gerenciamento de contexto em sistemas
colaborativos, denominado CoMGroup; são detalhados os componentes da sua arquitetura e a ontologia
proposta para representação dos contextos. As seções subseqüentes apresentam, respectivamente, a
metodologia para a continuidade desta pesquisa, as atividades realizadas, o cronograma de
desenvolvimento das atividades futuras e as contribuições esperadas com o trabalho.
7.1. MOTIVAÇÃO E OBJETIVOS DO TRABALHO
A atividade colaborativa exige uma compreensão das ações realizadas pelos integrantes do grupo. Isso é
especialmente verdadeiro em organizações onde as pessoas se dividem em mais de um projeto, com
prazos de execução cada vez menores. Os mecanismos de apoio à percepção desenvolvidos e integrados a
ferramentas de groupware visam apoiar essa compreensão do trabalho do grupo. Porém, os mecanismos
atuais são baseados em eventos ocorridos dentro do grupo e manipulam uma grande quantidade de
informação que cresce exponencialmente à medida que aumenta o tamanho do grupo ou o fluxo de
atividades. As pessoas gastam muito tempo em atividades não diretamente relacionadas às suas tarefas
dentro do grupo, como: ler e responder uma quantidade cada vez maior de emails para notificar os
colegas sobre suas atividades e contextualizar-se sobre as atividades deles; gerenciar versões de
documentos para uniformizar os esforços de trabalho conjunto; ou coordenar suas atividades em relação
aos prazos do grupo e às atividades executadas pelos demais.
Entender o contexto em que ocorre uma determinada interação auxilia o indivíduo a responder de
uma maneira mais apropriada à situação. Uma funcionalidade desejada dos sistemas computacionais, e
que vem atraindo cada vez mais a atenção dos pesquisadores, é dotar esses sistemas com informações de
contexto que permitam que eles se adaptem, alterando seu comportamento, para atender a demandas do
usuário, oferecendo informações e serviços que sejam do seu interesse (Huang, 2002).
O contexto é um instrumento poderoso para viabilizar a disseminação de informações relevantes
pois, considerando o contexto atual do usuário, a informação pode ser filtrada de acordo com o que é mais
importante naquela situação. A informação assim deixa de ser estática e passa a ser dinâmica, uma vez
que o contexto do usuário muda continuamente (Belotti et al., 2004b). O conjunto de funcionalidades do
84
sistema também pode ser ajustado ao contexto do usuário, sendo habilitadas ou destacadas as mais
relevantes. A adaptabilidade ao contexto é fundamental para que o apoio ao trabalho em grupo seja
efetivo e, com isso, aumente a usabilidade dos sistemas colaborativos (Borges et al., 2004).
Para reduzir a complexidade inerente ao desenvolvimento de sistemas cientes de contexto uma
tendência que vem se apresentando na literatura é a criação de mecanismos de gerenciamento de
contextos. Alguns trabalhos vêm sendo realizados para tratar desse problema, através do desenvolvimento
de toolkit (Dey et al., 2001), framework (Rittenbruch, 2002; Rosa et al., 2003), middleware (Ranganathan
e Campbell, 2003; Gu et al., 2004b) ou motor de contexto (Belotti et al., 2004b). Essas soluções
objetivam facilitar o desenvolvimento de sistemas cientes de contexto, provendo modelos e mecanismos
universais para gerenciamento dos contextos e desacoplando da composição do sistema tarefas como
aquisição, representação, processamento e disseminação do contexto (Gauvin et al., 2004).
Poucas pesquisas abordam mecanismos de gerenciamento de contexto voltados para sistemas
colaborativos e, nesses casos, o contexto se confunde com o conceito de percepção (Dourish e Bellotti,
1992), como é o caso dos mecanismos de percepção apresentados na Seção 2.3.5 (Prinz, 1999; Kirsch-
Pinheiro et al., 2002; Vieira et al., 2004). Falta uma representação formal do contexto voltada para
ambientes colaborativos que viabilize a integração de contextos provenientes de fontes diversas e seu uso
por diferentes sistemas. Um mecanismo genérico de gerenciamento de contexto com um modelo formal
de representação viabiliza a obtenção de informações contextuais provenientes de diferentes aplicações
que podem ser confrontadas e analisadas. Essa possibilidade é interessante, pois os usuários costumam
utilizar diferentes aplicações para apoiá-los na execução do trabalho colaborativo.
Dessa forma, o objetivo desta proposta de tese é a definição e desenvolvimento de um framework
para gerenciamento de contexto que apóie o tratamento de informações contextuais em sistemas
colaborativos. A idéia é prover um mecanismo de propósito genérico, configurável, que possa ser
acoplado a diferentes sistemas, e que possua um modelo formal de representação que viabilize a
integração de contextos provenientes de fontes diversas. Devido à complexidade inerente à inclusão de
contexto em sistemas colaborativos e à construção de sistemas gerenciadores de contexto, o foco da
proposta é a resolução de questões ligadas à representação formal das informações contextuais
relacionadas ao trabalho colaborativo, à manipulação e armazenamento dos contextos, e ao raciocínio
sobre informações contextuais existentes para identificação do contexto corrente.
7.2. CONCEITOS UTILIZADOS
Esta seção define alguns dos conceitos usados na descrição desta proposta, uniformizando o entendimento
sobre eles. São descritos, brevemente, agentes inteligentes, e a compreensão sobre foco de atenção e
elementos de contexto utilizados no trabalho.
85
7.2.1. Agentes Inteligentes
Um agente é uma entidade (de software ou hardware) que percebe seu ambiente através de sensores e
age sobre ele através de atuadores para alcançar seus objetivos (Russell e Norvig, 2003). Seu
comportamento inteligente está intimamente ligado à sua capacidade de tomar a melhor decisão para
chegar aos objetivos propostos, raciocinando sobre o conhecimento disponível.
Dentre as propriedades básicas que todo agente possui estão: (i) autonomia, pois o agente exerce
controle sobre suas próprias ações, ou seja, decide quando agir; (ii) reatividade, que indica que o agente
responde a mudanças ocorridas em seu ambiente; (iii) ser guiado por objetivos, ocorre quando o agente
não simplesmente responde ao ambiente, mas age de forma pró-ativa de acordo com um propósito; e
(iv) ser temporariamente contínuo, ou seja, um processo que é executado continuamente (Franklin e
Graesser, 1996; Russell e Norvig, 2003). Um agente pode ser reativo ou guiado por objetivos, porém
pode também apresentar um comportamento híbrido, ou seja, possuir componentes reativos e pró-ativos.
A presença das propriedades citadas é o que diferencia um agente inteligente de um programa comum.
7.2.2. Foco de Atenção
O conceito de contexto utilizado neste trabalho segue o modelo proposto por Brézillon e Pomerol
(Brézillon e Pomerol, 1999), apresentado na Seção 3.3.3, segundo o qual o contexto é dependente de um
foco de atenção e divide-se em três categorias de conhecimento: conhecimento contextual, contexto
externo e contexto proceduralizado.
Neste trabalho, foco de atenção é definido como o conhecimento que permite delimitar a situação
sobre a qual o contexto será considerado. O foco tem relação com o que o usuário está fazendo. No
trabalho colaborativo deve ser considerado, também, o foco compartilhado, ou seja, o que o grupo está
fazendo. O foco pode ser, por exemplo, um passo no processo de execução de uma tarefa ou uma etapa da
solução de um problema (Brézillon e Pomerol, 1999; Brézillon, 1999b). Quando um passo do processo
termina e outro se inicia há uma mudança no foco. O foco também pode mudar com o disparo de um
evento. Por exemplo, quando o usuário solicita, manualmente, a um serviço de recomendação a indicação
de materiais que o auxiliem na discussão de um tópico em um ambiente de aprendizado colaborativo. O
foco anterior era a tarefa em execução, ou seja, a discussão sobre o tópico. Com o disparo da solicitação,
o foco passa a ser a busca por material de aprendizado. O foco viabiliza a identificação dos elementos de
contexto a serem considerados. No exemplo, o contexto contém informações sobre a interação em curso,
como o assunto sendo discutido, o nível do aluno, a disponibilidade de materiais, entre outros, que são
fundamentais para que o sistema de recomendação indique materiais adequados à situação do usuário.
7.2.3. Elementos de Contexto
Neste trabalho considera-se como conhecimento contextual as informações mantidas pelo gerenciador de
contexto em sua base de conhecimento que não são instanciadas e disseminadas pelo gerenciador no foco
corrente.
86
O contexto externo é o conhecimento não existente na base de conhecimento do gerenciador. Por
exemplo, o conhecimento mantido em uma base de conhecimento do domínio da aplicação ou nos
modelos da aplicação.
Já o contexto proceduralizado é a parte do conhecimento contextual que é invocada, organizada,
estruturada e situada de acordo com o foco de atenção, e utilizada para apoiar a tarefa em execução
naquele foco. É a parte do conhecimento contextual relevante para o foco corrente e que, portanto, será o
conhecimento disseminado pelo gerenciador de contexto para a aplicação.
7.3. FRAMEWORK PARA GERENCIAMENTO DE CONTEXTO APLICADO A SISTEMAS
COLABORATIVOS
O gerenciador de contextos realiza tarefas relacionadas ao processamento, raciocínio e persistência dos
contextos, e possui uma representação de contextos associados ao trabalho colaborativo baseada em
ontologias. A ontologia de contexto provê a identificação e um vocabulário comum para o contexto dos
indivíduos e grupos dos quais esses indivíduos fazem parte, bem como às interações entre esses
indivíduos para a realização das atividades colaborativas (Vieira et al., 2005c). A tarefa de raciocínio
possui como tarefas relacionadas: a manutenção de uma base de conhecimento contextual; a identificação
do foco de atenção atual do usuário e do grupo do qual esse usuário faz parte; e, a geração de contextos
proceduralizados (PC) relativos ao foco de atenção, a partir do conhecimento contextual existente na base
de conhecimento. O serviço de persistência é responsável pela manutenção de um repositório com a
história dos contextos e dos contextos proceduralizados produzidos, e em habilitar formas de
disseminação e consulta a esse histórico por groupware e serviços cientes de contexto.
As seções a seguir apresentam a arquitetura do gerenciador de contextos para groupware,
denominado CoMGroup (do inglês, Context Manager for Groupware) e a ontologia de contexto proposta,
denominada CoMGroup-Ont.
7.3.1. Arquitetura
Uma visão geral da arquitetura do CoMGroup é ilustrada na Figura 7.1. O CoMGroup interage com três
categorias de entidades externas: o groupware, para identificação do foco de atenção do usuário e
disseminação dos contextos processados, relativos àquele foco; os serviços cientes de contexto, que não
necessariamente estão embutidos no groupware, mas oferecem serviços que apóiam o trabalho do grupo,
como percepção ou recomendações; e, as fontes externas de contexto, que fornecem elementos
contextuais utilizados pelo gerenciador para construir o contexto. Um módulo de configuração permite
que ajustes sejam feitos ao CoMGroup para atender às particularidades do groupware ou serviço ciente de
contexto, como, por exemplo, extensões à ontologia de contexto.
No CoMGroup são utilizados agentes inteligentes para realização das tarefas de manipulação e
raciocínio sobre o contexto. O CoMGroup implementa quatro agentes: o agente identificador do foco, o
87
agente mapeador do contexto, o agente interpretador do contexto e o agente disseminador do contexto.
Para apoiar a tarefa de raciocínio, o agente interpretador do contexto mantém: uma base de conhecimento
contextual, que armazena os contextos gerenciados; e uma base de conhecimento do contexto
proceduralizado, que armazena o histórico de contextos proceduralizados construídos associados ao foco
de atenção. Um motor de inferência é utilizado pelo agente para processar e raciocinar sobre o
conhecimento mantido nas bases de conhecimento. Os elementos externos e internos do CoMGroup são
detalhados nas próximas subseções.
CoM
Group
Agente Mapeador do Contexto
BC doDomínio
UsuárioUsuário
Agente Identificador do Foco
Agente Disseminador do Contexto
GroupwareGroupware
Sensor Lógico
TradutorTradutor
Sensor LógicoSensor Lógico
TradutorTradutor
Memória do Grupo
TradutorTradutor
Memória do Grupo
TradutorTradutor
Modelo da Aplicação
TradutorTradutor
Modelo da Aplicação
TradutorTradutor
Sensor Físico
TradutorTradutor
Sensor Físico
Sensor Físico
TradutorTradutor
Foco
Contexto Proceduralizado
Elementos de Contexto
Serviço Ciente de Contexto
Serviço Ciente de Contexto
possui
Elementos de Conttexto
Conhecimento Contextual
Conhecimento do Domínio
Foco
Foco
Foco
Elementos de Contexto
Contexto
Contexto
Consulta
Serviço Ciente de Contexto
Serviço Ciente de Contexto
possui
Contexto
Consulta
Módulo de Configuração
Módulo de Configuração
Consulta
Elementos de ContextoElementos
de Contexto
Agente Interpretador do Contexto
BC do Contexto
Proceduralizado
Base de Conhecimento
ContextualMotor de Inferência
Agente Interpretador do Contexto
BC do Contexto
Proceduralizado
Base de Conhecimento
ContextualMotor de InferênciaMotor de Inferência
Figura 7.1 – Visão geral da arquitetura do CoMGroup
Fontes Externas de Contexto
As informações contextuais podem ser obtidas de fontes diversas de forma explícita ou implícita. O modo
explícito é quando o usuário informa diretamente ao sistema o seu contexto atual através de interfaces
específicas como, por exemplo, um formulário ou botões de ação. O modo implícito expõe duas formas
de aquisição do contexto: via coleta ou monitoramento.
88
O monitoramento é realizado por sensores, físicos ou lógicos, que monitoram continuamente o
ambiente físico ou virtual do usuário e capturam informações contextuais desses ambientes. Informações
contextuais do ambiente físico incluem a presença física do usuário e de outras pessoas próximas a ele, a
localização geográfica dessas pessoas, dos dispositivos e dos recursos disponíveis, entre outras.
Informações contextuais do ambiente virtual podem ser a presença virtual do usuário no espaço de
trabalho compartilhado, sua disponibilidade para interação, ações realizadas sobre o espaço de trabalho, a
tarefa em execução, os artefatos compartilhados sendo manipulados, outros usuários com os quais está
interagindo, os aplicativos que estão utilizando, entre outras.
A coleta é relacionada à captura de informações persistentes em bases de dados existentes nos
sistemas. A memória do grupo fornece informações relevantes sobre o histórico de interações do grupo.
Os modelos da aplicação mantêm informações diversas sobre: o indivíduo, como sua identificação e
perfil; o grupo do qual esse indivíduo faz parte, com os seus objetivos e características; as tarefas
definidas para o grupo e seus planos de execução; entre outras.
Cada fonte de contexto é responsável por um determinado tipo de informação contextual e pode
possuir uma representação interna do contexto diferente da utilizada no CoMGroup. Dessa maneira, essas
fontes podem implementar um tradutor que serve para converter seus dados de contexto para serem
utilizados pelo gerenciador de contexto. As fontes de contexto podem ser autônomas e independentes, e
podem ser adicionadas ou removidas do CoMGroup a qualquer momento. A inclusão da fonte de
contexto é gerenciada pelo agente mapeador do contexto.
Uma base de conhecimento do domínio também pode ser utilizada como fonte complementar de
contexto, viabilizando a compreensão das informações disponibilizadas pelas fontes de contexto.
Groupware
A finalidade do CoMGroup é apoiar o tratamento das informações contextuais manipuladas por sistemas
colaborativos. Dessa maneira, ele deve estar conectado a um groupware existente. O groupware deve
entender o funcionamento do CoMGroup e conhecer seus protocolos de comunicação, de modo que seja
possível a interação entre ambos.
Serviços Cientes de Contexto
O CoMGroup não se preocupa, diretamente, com a forma como o groupware irá adaptar-se ao contexto
identificado e processado. De modo a alcançar uma maior modularidade, sugere-se que sejam construídos
serviços, independentes do groupware, adaptativos ao contexto, para apoio ao trabalho do grupo. Esses
serviços podem auxiliar em tarefas como: suporte à percepção seletiva, recomendações e personalizações
do groupware.
Serviços de apoio à percepção são responsáveis por prover informações sobre o contexto atual de
outros membros do grupo, permitindo que os usuários se contextualizem sobre o que ocorre em seu grupo
89
de trabalho, e viabilizando sua auto-coordenação. Essa notificação deve ser feita de uma forma seletiva e
incremental, de modo a não sobrecarregar o usuário com informações que não sejam relevantes ou
perturbá-los com informações excessivas. A prática mostra que é mais eficiente que o usuário seja
notificado de poucas informações, contextualizadas com sua situação atual, do que ser inundado com uma
grande quantidade de informações descontextualizadas.
Serviços de recomendação oferecem aos usuários indicações de informações ou serviços que
possam auxiliá-los em sua tarefa atual, tais como: recomendação de ferramentas para uso em uma
interação, recomendação de materiais de estudo em um ambiente de aprendizagem colaborativa ou
recomendação de especialistas para consultoria, entre outros.
Serviços de personalização ou adaptação buscam tornar o groupware mais próximo do perfil do
usuário que o está utilizando. As adaptações podem ser feitas na aparência das interfaces com o usuário,
produzindo interfaces individualizadas, ou no comportamento do sistema, ajustando informações e
serviços aos interesses e preferências do usuário.
Agente Identificador do Foco
O agente identificador do foco tem por objetivo monitorar o ambiente virtual do usuário e perceber
mudanças em seu foco de atenção, mapeando diferenças em relação ao foco anterior e comunicando essas
informações ao demais agentes do gerenciador de contexto. Uma questão relevante em relação ao foco de
atenção é estabelecer o que irá disparar a instanciação do foco. Segundo Gauvin et al. (Gauvin et al.,
2004), o foco pode ser identificado de duas maneiras: manual ou automática. A forma manual é
conduzida pelo próprio usuário. Para isso, o sistema deve permitir que o usuário indique qual é o seu foco
atual. A forma automática é realizada por um agente de software que monitora o ambiente de trabalho do
usuário e percebe mudanças no foco. Por exemplo, o agente pode perceber que um passo na realização de
uma tarefa foi finalizado e outro terá início.
Agente Interpretador do Contexto
As informações contextuais manipuladas pelo CoMGroup seguem o vocabulário especificado na
ontologia de contexto CoMGroup-Ont proposta em (Vieira et al., 2005c) e detalhada na Seção 7.3.2. O
Agente Interpretador do Contexto mantém duas bases de conhecimento baseadas nessa ontologia. Uma
delas é a Base de Conhecimento Contextual (CKB, do inglês Contextual Knowledge Base), que mantém
as regras e fatos relativos ao conhecimento contextual (CK) manipulado pelo gerenciador. Essa base
mantém um histórico dos contextos e permite inferência de novos fatos, usando regras pré-definidas e um
motor de inferência. A outra é a Base de Conhecimento do Contexto Proceduralizado (PCKB, do inglês
Proceduralized Context Knowledge Base). Essa base mantém o histórico dos contextos proceduralizados
(PCs) produzidos associando-os ao foco em que foram gerados.
Os objetivos do Agente Interpretador do Contexto incluem: manter consistentes a CKB e a PCKB;
gerenciar o raciocínio sobre as informações contextuais mantidas nessas duas bases, inferindo novos
90
contextos a partir de regras lógicas de inferência e de fatos contextuais existentes; gerenciar a construção
do contexto proceduralizado a partir do foco de atenção corrente e do CK existente na CKB; identificar o
conhecimento externo (EK) em relação ao foco que, portanto, não deverá ser considerado pelo
disseminador de contexto; atualizar a PCKB com o foco de atenção e o PC utilizado, de modo a manter
um histórico da construção e uso do PC. Esse histórico servirá como uma base de aprendizado que
possibilite melhorar a inferência do PC em interações futuras. Esse agente utiliza um motor de inferência
para raciocinar sobre os fatos mantidos nas bases de conhecimento, produzindo novos fatos a partir das
regras lógicas pré-definidas. Esse motor também é responsável por checar a consistência da CoMGroup-
Ont, identificando fatos que não estejam de acordo com as especificações descritas na ontologia.
Agente Mapeador do Contexto
Esse agente provê uma interface única de comunicação entre o CoMGroup e as fontes de contexto. Ele
recebe as informações contextuais traduzidas das fontes e envia-as para o agente interpretador do
contexto para que sejam armazenadas como fatos na CKB. Seu funcionamento ocorre em duas direções.
A primeira se dá quando o agente recebe do agente identificador do foco a indicação de que um novo foco
de atenção foi atingido e, portanto, o CoMGroup necessita buscar nas fontes o contexto relativo àquele
foco. Nesse caso, o mapeador do contexto identifica quais fontes de contexto deverão ser consultadas e
solicita informações atualizadas relacionadas ao foco corrente. A segunda direção ocorre quando uma
nova fonte de contexto é incluída ou quando uma fonte de contexto existente deseja comunicar novas
informações contextuais ao CoMGroup, como por exemplo, quando um sensor detecta uma mudança
significativa no contexto do ambiente monitorado.
Agente Disseminador do Contexto
Esse componente é responsável por entregar o PC produzido pelo CoMGroup à aplicação ciente de
contexto (groupware ou serviço). Essa entrega pode ser feita, basicamente, de maneira ativa ou passiva. A
entrega ativa é realizada como resposta a uma consulta enviada pela aplicação ao disseminador,
solicitando diretamente a informação contextual desejada. A entrega passiva ocorre por iniciativa do
CoMGroup. Nesse caso, a aplicação se inscreve ao CoMGroup como interessada em determinados tipos
de informação contextual e sempre que essa informação for modificada o disseminador envia à aplicação
uma mensagem de notificação.
Módulo de Configuração
Esse módulo, externo ao CoMGroup, permite que o desenvolvedor do groupware ou serviço ciente de
contexto regule o funcionamento do gerenciador de contexto, através de parâmetros de configuração.
7.3.2. Ontologia para Representação de Contexto em Sistemas Colaborativos
Um elemento fundamental na proposta de gerenciamento de contexto é a ontologia para representação
dos contextos presentes nos sistemas colaborativos. Foi criada uma versão inicial dessa ontologia,
91
baseada em conceitos construídos a partir de uma revisão da literatura relacionada a contexto e
colaboração (Rosa et al., 2003; Kirsch-Pinheiro et al., 2004; Wang et al., 2004; Chen e Finin, 2004;
Alarcón et al., 2005b). Uma visão geral dos conceitos definidos é ilustrada na Figura 7.2 e uma visão
geral dos relacionamentos entre os conceitos é ilustrada na Figura 7.3. Para uma maior interoperabilidade
da ontologia, o idioma escolhido para sua representação foi o inglês.
A classe Context é a classe principal, raiz da ontologia, a partir da qual todos os elementos de
contexto são representados. Ela se divide em três subclasses: InteractionContext, indica as informações
referentes ao contexto de uma interação que está acontecendo (síncrona) ou que já ocorreu (assíncrona)
durante o trabalho em grupo; OrganizationalContext, representa a informação contextual relativa à
estrutura organizacional do trabalho em grupo e inclui o usuário, o grupo ao qual pertence, o papel
desempenhando na execução de uma tarefa, em um projeto específico; e, PhysicalContext, contém
informações que caracterizam o ambiente físico em que o usuário se encontra.
O contexto da interação (InteractionContext) possui 2 subclasses: SharedArtifactsContext, contém
elementos relativos ao contexto dos artefatos compartilhados utilizados na interação, como classes em um
diagrama de classes colaborativo ou parágrafos em um editor de texto colaborativo; e,
ApplicationContext, indica elementos de contexto referentes à aplicação em uso, ou disponível para uso,
na interação, e inclui o propósito da aplicação (para apoiar a comunicação, coordenação ou cooperação) e
o tipo de interação que suporta (síncrona/assíncrona).
O contexto organizacional (OrganizationalContext) está dividido em 5 subclasses: ProjectContext,
AgentContext, GroupContext, TaskContext e RoleContext. ProjectContext contém elementos que
identificam o contexto do projeto que está sendo conduzido pelos membros do grupo, tais como objetivos
e cronograma. AgentContext, contém informações de contexto sobre os membros do grupo, os quais
podem ser um agente humano (HumanAgentContext) ou um agente de software
(SoftwareAgentContext), pois considera-se que um agente inteligente de software também pode
participar de uma interação apoiando o desenvolvimento do trabalho em grupo. HumanAgentContext
contém informações contextuais que incluem a identificação do usuário, seus interesses, habilidades e
disponibilidade atual (ocupado, ausente, disponível). SoftwareAgentContext possui informações sobre o
objetivo do agente e suas intenções. GroupContext representa informações que caracterizam o grupo,
como objetivo, habilidades e interesses do grupo. TaskContext, identifica elementos do contexto das
tarefas (e subtarefas) que estão sendo, ou já foram, executadas, incluindo o objetivo da tarefa e o prazo
para sua execução. RoleContext, refere-se aos papéis que os membros de um grupo podem desempenhar
na execução de uma tarefa, identificando, por exemplo, se o usuário é um coordenador ou um tutor (em
um ambiente de aprendizado colaborativo).
92
Figura 7.2 - Visão Geral e Parcial da Hierarquia de Classes da Ontologia de Contexto
O contexto físico (PhysicalContext) possui 4 subclasses: DeviceContext, que indica o contexto dos
dispositivos eletrônicos e físicos disponíveis para o usuário, tais como o tipo do dispositivo (PC, PDA,
microfones, webcams); LocationContext, que provê informações sobre o espaço físico e virtual onde o
usuário está localizado e relações como proximidade, distância, presença e ausência; TimeContext, que se
refere ao contexto do momento em que a interação ocorre e contém informações como fuso horário; e
ConditionContext, que informa as condições físicas do ambiente onde o usuário se encontra, como
temperatura, nível de barulho e luminosidade.
De acordo com a especificação OWL, cada conceito possui propriedades de tipo (datatype
properties) que definem seus atributos e propriedades de objeto (object properties) que definem seus
relacionamentos a outros conceitos. Por exemplo, o conceito HumanAgentContext possui propriedades de
tipo como hasName (nome do participante), isAvailable (sua disponibilidade no ambiente) e
hasVisualDisability (que indica se o indivíduo possui alguma deficiência visual), entre outros. A Figura
7.3 apresenta os relacionamentos entres as principais classes da ontologia.
isMemberOf(AgentContext, GroupContext): indica que o agente é membro de um determinado
grupo. Seu relacionamento inverso é o hasMember(GroupContext, AgentContext);
performsRole(AgentContext,RoleContext): determina que o agente desempenha um dado papel
na execução de uma tarefa em um grupo;
93
isLocatedIn(AgentContext,LocationContext): estabelece que o agente está situado em um
determinado contexto de localização, que pode ser geométrico (ex. coordenadas obtidas por
GPS), simbólico (ex. sala 201 do CIn), ou virtual (ex. endereço IP);
hasDeviceContext (HumanAgentContext,DeviceContext): designa o dispositivo de hardware
presente no contexto físico do agente humano;
hasParticipant (InteractionContext, AgentContext/GroupContext): indica quais indivíduos ou
grupos estão participando de uma interação;
isSubTaskOf (TaskContext, TaskContext): enuncia que a tarefa é parte de outra;
executesTask (AgentContext/GroupContext, TaskContext): associa o agente (humano ou
software) ou o grupo, ao contexto da tarefa que está executando;
worksIn (AgentContext/GroupContext, ProjectContext): indica que um grupo ou um indivíduo
trabalha na execução de um projeto;
hastTask (ProjectContext,TaskContext): determina que um projeto é composto de uma ou mais
tarefas;
delegatedTo (TaskContext,RoleContext): associa uma tarefa a um determinado papel.
Figura 7.3 – Visão geral dos relacionamentos entre os conceitos
A ontologia, até o momento, representa uma visão de alto nível dos elementos contextuais
envolvidos no trabalho colaborativo. É necessária uma especialização dessas classes de modo a atender a
propósitos específicos de determinados sistemas. Por exemplo, uma extensão foi feita à ontologia no
94
trabalho de inclusão de contexto ao editor colaborativo CoWS (Zarate, 2006; Vieira et al., 2006),
ilustrado na Figura 7.4. Os conceitos Text e Paragraph foram incluídos como subclasses de
SharedArtifactsContext, pois no CoWS o artefato compartilhado por autores são parágrafos de um texto.
Figura 7.4 – Instância da ontologia de contexto usada no CoWS (Zarate, 2006)
A ontologia foi criada seguindo a metodologia proposta por Noy e McGuiness (Noy e McGuinnes,
2001). A linguagem escolhida para representar a ontologia foi a OWL (Web Ontology Language)
(Bechhofer et al., 2004), pois ela está firmando como um padrão para representação de ontologias para
promover a Web semântica. A ferramenta Protégé (Protégé, 2006) foi utilizada para criação e edição dos
conceitos. O framework Jena (Jena, 2006) foi usado, experimentalmente, associado ao CoWS (Vieira et
al., 2005a) , para testar a implementação de regras de inferência sobre os contextos descritos na ontologia
(Zarate, 2006; Vieira et al., 2006).
7.4. METODOLOGIA
A continuidade deste trabalho de doutorado será executado em seis etapas, descritas a seguir:
7.4.1. Especificação de Cenários Reais de Colaboração
Essa etapa tem por objetivo estudar ambientes reais de trabalho colaborativo para identificar que
informações contextuais estão presentes nesses ambientes, que ferramentas de groupware são utilizadas
pelos usuários para apoiá-los em suas interações, e levantar junto a esses usuários como o conhecimento
do contexto pode ajudá-los em suas tarefas, e como o contexto pode ser usado para tornar as ferramentas
melhores e mais adequadas às suas necessidades.
Foram imaginados dois diferentes ambientes de colaboração a serem investigados nesta etapa. O
primeiro é um ambiente organizacional de desenvolvimento colaborativo de software formado por um
grupo de trabalho de um projeto do C.E.S.A.R., a ser definido. O segundo é o de um ambiente acadêmico,
95
de desenvolvimento colaborativo de artigos científicos, formado por alunos de pós-graduação e
professores de um grupo de pesquisa do CIn-UFPE.
Nesse estudo, deseja-se entender um pouco melhor como as pessoas realmente trabalham, em
diferentes ambientes colaborativos, com diferentes características culturais e pressões de prazo. Serão
utilizadas técnicas de análise qualitativa (e.g. entrevistas, análise da tarefa) para esse estudo. Como
resultado dessa etapa espera-se obter uma descrição formal desses cenários, um levantamento real de
como o contexto pode ser aplicado ao trabalho colaborativo, a identificação dos elementos de contexto
presentes nesses ambientes e as ações ou serviços cientes de contexto que poderiam ser providos por
ferramentas de groupware para apoiar o trabalho das equipes nesses cenários.
7.4.2. Modelagem da CoMGroup-Ont
Essa etapa tem por objetivo a evolução da ontologia CoMGroup-Ont. Esta será construída através do
refinamento e extensão dos conceitos definidos na versão atual da ontologia (descrita na Seção 7.3.2),
adequando-os ao conhecimento obtido nos cenários estudados na etapa anterior. Serão utilizados os dados
levantados nos cenários de colaboração da etapa anterior para instanciar a CoMGroup-Ont e avaliar a
generalidade dos conceitos. A ontologia será disponibilizada em uma página web, para consulta e revisão
por outros pesquisadores da área.
Uma das principais vantagens em utilizar a abordagem de ontologias para representar contexto é a
facilidade de integração com outras pré-existentes. Dessa maneira, deseja-se investigar na literatura
ontologias relacionadas e com conceitos bem estabelecidos que possam ser reutilizados no modelo
proposto, tais como a FOAF (Friend of a Friend) (Brickley e Miller, 2006), uma especificação voltada
para redes sociais que descreve indivíduos, seus interesses e relacionamentos com outras pessoas; a
OpenCyc (OpenCyc, 2006), uma base de conhecimento que mantém a descrição de mais de 47.000
conceitos e mais de 306.000 fatos; e outras ontologias de contexto encontradas na literatura (Preuveneers
et al., 2004; Chen e Finin, 2004; Gu et al., 2004c; Bulcão Neto e Pimentel, 2005).
7.4.3. Modelagem do Framework CoMGroup
Essa etapa objetiva a análise e especificação dos componentes e agentes do CoMGroup. Para isso,
serão realizadas as seguintes tarefas:
Modelar diagramas de casos de uso, tomando como referência os cenários identificados na
Etapa 1, associando o CoMGroup com suas entidades externas;
Criar um processo de geração do contexto proceduralizado a partir do foco de atenção e dos
contextos mantidos na base de conhecimento contextual;
Modelar os agentes Mapeador de Contexto e Disseminador do Contexto;
Modelar o Agente Identificador do Foco, definindo como o foco pode ser identificado e
representado, e como associá-lo ao contexto;
96
Modelar o Agente Interpretador do Contexto, investigando abordagens para raciocinar sobre os
contextos especificados na CoMGroup-Ont;
Modelar o diagrama de colaboração entre os componentes e agentes internos ao CoMGroup;
Especificar os protocolos e interfaces de acesso ao CoMGroup, para interação com os elementos
externos (fontes de contexto, groupware e serviços cientes de contexto).
7.4.4. Implementação de um Protótipo do CoMGroup
Nessa etapa será implementado um protótipo do CoMGroup, seguindo as especificações modeladas
na etapa anterior. Serão implementados os componentes internos do CoMGroup. Como o foco deste
trabalho é a representação e raciocínio sobre os contextos, não está prevista a implementação de
mecanismos de aquisição automática de contextos. Os contextos considerados serão informados
manualmente e mantidos na base de conhecimento contextual, como instâncias da CoMGroup-Ont.
Para viabilizar a avaliação do protótipo do CoMGroup serão implementados dois serviços cientes
de contexto: um serviço de percepção, cuja finalidade é apresentar o contexto em relação ao foco
identificado; e um serviço de recomendação de especialistas, que usará o conhecimento contextual para
adequar suas recomendação à situação atual do usuário. Esses dois serviços fazem parte do projeto de
mestrado de duas alunas do CIn.
7.4.5. Estudo de Caso
O objetivo desta etapa é verificar os resultados obtidos nas etapas anteriores através do
acoplamento do CoMGroup a uma ferramenta de groupware, a ser definida. Deseja-se avaliar se é
possível implementar, de maneira fácil, serviços cientes de contexto a partir do uso do CoMGroup, e se o
uso do contexto facilita e melhora a colaboração entre os usuários. Para isso, as seguintes atividades
devem ser executadas:
a. Identificar a ferramenta de groupware a ser utilizada;
b. Implementar o acoplamento do protótipo do CoMGroup a essa ferrramenta;
c. Definir o estudo de caso, utilizando o framework de avaliação de ferramentas de groupware
definido em (Araújo et al., 2004);
d. Realizar o estudo de caso com um grupo de usuários.
7.4.6. Escrita
Esta etapa será realizada paralela às demais e compreende a escrita da versão final do texto da tese,
e a escrita e submissão de artigos científicos.
97
7.5. ATIVIDADES REALIZADAS
As atividades realizadas para desenvolvimento desta pesquisa e para cumprimento dos requisitos
do programa de doutorado do CIn/UFPE, no período de março de 2004 a abril de 2006 foram:
Cumprimento dos créditos de disciplinas;
Levantamento do estado da arte sobre contexto computacional, e contexto aplicado a sistemas
colaborativos;
Delimitação do escopo do trabalho;
Definição da arquitetura do CoMGroup;
Criação da versão inicial da ontologia de contexto para groupware;
Implementação inicial de regras em lógica de primeira ordem para raciocínio sobre
conhecimento representado na ontologia de contexto utilizando o framework Jena, aplicado ao
CoWS, um groupware para edição colaborativa de textos;
Escrita de artigos científicos sobre a ontologia de contexto e o CoMGroup;
Escrita da monografia de qualificação e proposta de tese.
7.5.1. Artigos Publicados e Submetidos para Avaliação
Vieira, V., Tedesco, P., Salgado, A.C. (2005) Towards an Ontology for Context Representation in
Groupware. In : Proceedings of the CRIWG’2005, pp. 367-375. Porto de Galinhas, PE, Brasil.
Vieira, V., Tedesco, P., Salgado, A.C. (2005) Representação de Contextos em Ambientes Colaborativos
Usando Ontologias. In: Anais do SBIE’05, II Workshop Brasileiro de Tecnologias para Colaboração,
WCSCW’05. Juiz de Fora, MG, Brasil.
Vieira, V., Zarate, D., Tedesco, P., Salgado, A.C. (2006) A Contextual Ontology-Based Reasoning
Mechanism for Groupware. CRIWG’2006, Valladolid, Espanha. Submitted.
Souza, D., Vieira, V., Tedesco, P., Salgado, A.C. (2006) Requirements for Context Management in
Groupware. CRIWG’2006, Valladolid, Espanha. Submitted.
Vieira, V., Tedesco, P., Salgado, A.C., Brézillon, P. (2006) An Ontology-Based Context Manager for
Collaborative Systems. The Knowledge Engineering Review Journal. Em elaboração.
7.6. CRONOGRAMA DE ATIVIDADES
As atividades a serem executadas nesta pesquisa, e no contexto do programa de doutorado da
UFPE, seguem o cronograma apresentado na Tabela 7.1. Está previsto um estágio de 10 meses na
França, sob orientação do Dr. Patrick Brézillon, na Universidade Paris VI, no período de novembro de
2006 a agosto de 2007. Durante esse estágio, deseja-se utilizar a experiência do grupo do Dr. Brézillon
em modelagem e representação de contextos para validar e refinar a modelagem proposta para o
98
CoMGroup e para a CoMGroup-Ont, finalizar a implementação do protótipo e iniciar a especificação do
estudo de caso. Além disso, nesse período está prevista a escrita dos capítulos de revisão da literatura,
especificação da proposta e implementação do protótipo para o texto final da tese, e a escrita de artigos
científicos.
Tabela 7.1 – Cronograma de Atividades
2006 2007 2008ATIVIDADE
05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02
Defesa da qualificação e proposta de tese Especificação de cenários de colaboração Modelagem da CoMGroup-Ont Modelagem do CoMGroup Implementação do protótipo do CoMGroup Especificação do estudo de caso Realização do estudo de caso Refinamento do protótipo Análise dos resultados do estudo de caso Escrita de artigos científicos Escrita do texto da tese Defesa da tese
Doutorado Sanduíche
7.7. CONTRIBUIÇÕES ESPERADAS
O gerenciamento de contextos envolve muitas tarefas, tais como: identificação dos contextos,
aquisição, representação formal, raciocínio, persistência, manipulação, disseminação, uso, apresentação,
qualidade da informação contextual, privacidade e segurança, além de questões de otimização, uma vez
que o tratamento do contexto fatalmente causa um impacto no desempenho da aplicação. Este trabalho
tem por foco os problemas ligados à identificação das informações contextuais em sistemas colaborativos,
à representação formal dos contextos, à persistência e manipulação do conhecimento contextual, e ao
raciocínio sobre as informações de contexto, com a identificação do contexto corrente a partir de um
conjunto de informações contextuais existentes. As demais questões não serão tratadas diretamente neste
trabalho, porém algumas delas (aquisição, disseminação, uso e apresentação) fazem parte dos estudos de
outros alunos do grupo e de um projeto de pesquisa submetido ao CNPq. Questões relacionadas à
qualidade da informação contextual, segurança, privacidade e otimização não estão previstas nesta
pesquisa.
Dessa maneira, as contribuições esperadas para esta tese incluem:
Estudo sobre o tratamento do contexto no domínio de sistemas colaborativos;
99
Definição de um processo de geração de contexto proceduralizado relativo à execução de uma
tarefa colaborativa, a partir do foco de atenção corrente e de um conjunto existente de
conhecimento contextual;
Especificação de um framework para gerenciamento de contextos aplicável a sistemas
colaborativos;
Especificação de uma ontologia para representação formal de contextos associados ao trabalho
em grupo;
Implementação de um protótipo do framework que permita inferir o contexto proceduralizado
correspondente a um dado foco de atenção;
Publicação de artigos científicos em revistas e conferências nacionais e internacionais nas áreas
de CSCW, Modelagem e Raciocínio de Contexto, Computação Ciente de Contexto e
Inteligência Artificial.
100
Referências Bibliográficas
ALARCÓN, R., GUERRERO, L. A., OCHOA, S. F., PINO, J. A., 2005a, "Context in Collaborative Mobile Scenarios". In: Fifth International and Interdisciplinary Conference on Modeling and Using Context (CONTEXT'05), Workshop on Context and Groupware., Paris, France.
ALARCÓN, R., GUERRERO, L. A., PINO, J. A., 2005b, "Groupware Components as Providers of Contextual Information". In: Fifth International and Interdisciplinary Conference on Modeling and Using Context (CONTEXT'05), Paris, France.
ARAÚJO, R. M., 2000, Ampliando a Cultura de Processos de Software - Um Enfoque Baseado em Groupware e Workflow, Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro.
ARAÚJO, R. M., SANTORO, F. M., BORGES, M. R. S., 2004, "A Conceptual Framework for Designing and Conducting Groupware Evaluations", International Journal of Computer Applications in Technology, v. 19, n. 3/4, pp. 139-150.
BARDRAM, J. E., 2004, "Applications of Context-Aware Computing in Hospital Work: Examples and Design Principles". In: Proceedings of the 2004 ACM symposium on Applied Computing, ACM Press, pp. 1574-1579.
BAUER, J., 2003, Identification and Modeling of Contexts for Different Information Scenarios in Air Traffic, Diplomarbeit, Technische Universität Berlin, Fakultät IV - Elektrotechnik und Informatik, Institut für Computergestützte Informationssysteme, Berlin.
BAZIRE, M., BRÉZILLON, P., 2005, "Understanding Context Before Using It". In: 5th International and Interdisciplinary Conference, CONTEXT 2005, v. LNAI 3554, pp. 29-40, Springer Verlag, Paris, France.
BECHHOFER, S., VAN HARMELEN, F., HENDLER, J., HORROCKS, I., MCGUINNESS, D., PATEL-SCHNEIDER, P., STEIN, L., 2004, "Web Ontology Language (OWL) Reference, W3C Recommendation". In: http://www.w3.org/TR/owl-ref/, Access in 05/2006.
BELOTTI, R., 2004, Sophie - Context Modelling and Control, Diploma thesis, Swiss Federal Institute of Technology Zurich.
BELOTTI, R., DECURTINS, C., GROSSNIKLAUS, M., NORRIE, M. C., PALINGINIS, A., 2004b, "Interplay of Content and Context". In: International Conference on Web Engineering (ICWE 2004), Munich, Germany.
BELOTTI, R., DECURTINS, C., GROSSNIKLAUS, M., NORRIE, M. C., PALINGINIS, A., 2004a, "Modelling Context for Information Environments". In: Workshop on Ubiquitous Mobile Information and Collaboration Systems (UMICS), CAiSE 2004, Riga, Latvia.
BLAIR, G., CAMPBELL, A., SCHMIDT, D., 2004, "Middleware Technologies for Future Communication Network - Guest Editorial", IEEE Network, v. 18, n. 1.
BORGES, M. R. S., BRÉZILLON, P., PINO, J. A., POMEROL, J.-C., 2004, "Bringing context to CSCW". In: Proceedings of the Computer Supported Cooperative Work in Design, v. 2, pp. 161-166, IEEE Press.
BORGES, M. R. S., BRÉZILLON, P., PINO, J. A., POMEROL, J.-C., 2005, "Dealing with the Effects of Context Mismatch in Group Work", Submitted for Publication.
BORGES, M. R. S., PINO, J. A., 2000, "Requirements for Shared Memory in CSCW Applications". In: Proceedings of the 10thWorkshop on Information Technologies and Systems, pp. 211-216, Australia.
101
BORGES, M. R. S., PINO, J. A., 1999, "Awareness Mechanisms for Coordination in Asynchronous CSCW". In: 9thWorkshop on Information Technologies and Systems, pp. 69-74, Charlotte, North Carolina.
BOUZY, B., CAZENAVE, T., 1997, "Using the Object Oriented Paradigm to Model Context in Computer Go". In: Proceedings of Context'97, Rio de Janeiro, Brazil.
BRÉZILLON, P., 1999a, "Context in Artificial Intelligence: IA Survey of the Literature", Computer&Artificial Intelligence, v. 18, pp. 321-340.
BRÉZILLON, P., 1999b, "Context in problem solving: A survey", The Knowledge Engineering Review, v. 14, n. 1, pp. 1-34.
BRÉZILLON, P., 2005, "Contextualizations in a Social Network", Revue d'Intelligence Artificielle.Special Issue on "Applying Context Management", v. 19, n. 3, pp. 575-594.
BRÉZILLON, P., 2003a, "Individual and Team Contexts in a Design Process". In: Proceedings of the Hawaii International Conference on System Sciences, Hawaii, USA, IEEE Computer Society Press, CD-R.
BRÉZILLON, P., 2003b, "Representation of Procedures and Practices in Contextual Graphs", The Knowledge Engineering Review, v. 18, n. 2, pp. 147-174.
BRÉZILLON, P., ARAÚJO, R. M., 2005, "Reinforcing Shared Context to Improve Collaborative Work", Revue d'Intelligence Artificielle.Special Issue on "Applying Context Management", v. 19, n. 3, pp. 537-556.
BRÉZILLON, P., BORGES, M. R. S., PINO, J. A., POMEROL, J.-C., 2004, "Context-Awareness in Group Work: Three Case Studies". In: IFIP International Conference on Decision Support Systems (DSS-2004). Decision Support in Uncertain and Complex World., Italia.
BRÉZILLON, P., CAVALCANTI, M., NAVEIRO, R., POMEROL, J.-C., 2000, "SART: An Intelligent Assistant for Subway Control", Pesquisa Operacional, Brazilian Operations Research Society, v. 20, n. 2, pp. 247-268.
BRÉZILLON, P., POMEROL, J.-C., 1999, "Contextual Knowledge Sharing and Cooperation in Intelligent Assistant Systems", Le Travail Humain, PUF, Paris, v. 62, n. 3, pp. 223-246.
BRICKLEY, D., MILLER, L., 2006, "FOAF Vocabulary Specification". In: http://xmlns.com/foaf/0.1/, Access in 03/2006.
BULCÃO NETO, R. F., PIMENTEL, M. G. C., 2005, "Toward a Domain-Independent Semantic Model for Context-Aware Computing". In: Proceedings of the 3rdIW3C2 Latin American Web Congress, IEEE Computer Society, pp. 61-70, Buenos Aires, Argentina.
CHEN, G., KOTZ, D., 2000, A Survey of Context-Aware Mobile Computing Research. Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College.
CHEN, H., 2004, An Intelligent Broker Architecture for Pervasive Context-Aware Systems, PhD Thesis, Faculty of the Graduate School of the University of Maryland.
CHEN, H., 2003, An Intelligent Broker Architecture for Context-Aware Systems, PhD. Dissertation Proposal, University of Maryland Baltimore County.
CHEN, H., FININ, T., 2004, "An Ontology for Context-Aware Pervasive Computing Environments", The Knowledge Engineering Review, v. 18, n. 3, pp. 197-207.
CHEN, H., FININ, T., JOSHI, A., 2003a, "An Ontology for Context-Aware Pervasive Computing Environments". In: Workshop on Ontologies and Distributed Systems, Special Issue in 8th IJCAI, Acapulco, Mexico.
CHEN, H., FININ, T., JOSHI, A., 2003b, "Using OWL in a Pervasive Computing Broker". In: Workshop on Ontologies in Agent Systems, AAMAS-2003, Melbourne, Australia.
CHEN, H., FININ, T., JOSHI, A., PENG, Y., 2005, "UMBC eBiquity Project: Context Broker Architecture (CoBrA)". In:
102
http://ebiquity.umbc.edu/project/html/id/1/?EBS=0a25f6d5d3c8bd4f33fdb719933e0e03, Access in 12/2005.
CHEVERST, K., DAVIES, N., MITCHELL, K., FRIDAY, A., EFSTRATIOU, C., 2000, "Developing a Context-Aware Electronic Tourist Guide: Some Issues and Experiences". In: Proc. of CHI'2000, pp. 17-24, The Hague, The Netherlands.
CHEVERST, K., MITCHELL, K., DAVIES, N., 1999, "Design of an Object Model for a Context Sensitive Tourist GUIDE", Computers and Graphics, v. 23, n. 6, pp. 883-891.
CHRISTOPOULOU, E., GOUMOPOULOS, C., ZAHARAKIS, I., KAMEAS, A., 2004, "An Ontology-based Conceptual Model for Composing Context-Aware Applications". In: Sixth International Conference on Ubiquitous Computing (Ubicomp 2004), Workshop on "Advanced Context Modelling, Reasoning and Management", Nottingham, England.
COSTA, C., ANTUNES, P., 2002, "Handheld CSCW in the Meeting Environment". In: VIII International Workshop in Groupware (CRIWG'2002), v. LNCS 2440, pp. 47-60, La Serena, Chile.
CVS, 2006, "Concurrent Version System - Ximbiot - CVS Wiki". In: http://ximbiot.com/cvs/wiki/index.php?title=Main_Page, Access in 05/2006.
DAML, 2006, "The DARPA Agent Markup Language Homepage". In: http://www.daml.org, Access in 05/2006.
DAVID, J. M. N., 2004, Um Serviço de Percepção para uma Infraestrutura de Desenvolvimento de Groupware, Tese de D.Sc., COPPE, Universidade Federal do Rio de Janeiro.
DAVID, J. M. N., BORGES, M. R. S., 2001, "Selectivity of Awareness Components in Asynchronous CSCW Environments". In: Proc. of 7thInternational Workshop on Groupware (CRIWG'01), pp. 115-124, Darmstadt, Germany.
DCMI, 2005, "Dublin Core Metadata Initiative - DCMI Metadata Terms". In: http://dublincore.org/documents/dcmi-terms/, Access in 03/2006.
DEY, A. K., 2001, "Understanding and Using Context", Personal and Ubiquitous Computing, v. 5, n. 1, pp. 4-7.
DEY, A. K., 2000, Providing Architectural Support for Building Context-Aware Applications, PhD Thesis, Georgia Institute of Technology.
DEY, A. K., ABOWD, G. D., 2000, "Towards a Better Understanding of Context and Context-Awareness". In: Proceedings of the CHI 2000 Workshop on The What, Who, Where, When, and How of Context-Awareness, The Hague, Netherlands.
DEY, A. K., FUTAKAWA, M., SALBER, D., ABOWD, G. D., 1999a, "The Conference Assistant: Combining Context-Awareness with Wearable Computing". In: Proceedings of the 3rd International Symposium on Wearable Computers (ISWC'99), pp. 21-28, IEEE Computer Society Press.
DEY, A. K., SALBER, D., ABOWD, G. D., 2001, "A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications", Human Computer Interaction Journal, v. 16, n. Special Issue on Context-Aware Computing, pp. 97-166.
DEY, A. K., SALBER, D., FUTAKAWA, M., ABOWD, G. D., 1999b, An Architecture to Support Context-Aware Applications. Technical Report, Georgia Institute of Technology.
DILLENBOURG, P., BAKER, M. J., BLAYE, A., O'MALLEY, C., 1996, "The Evolution of Research on Collaborative Learning", Learning in Humans and Machines: Towards an Interdisciplinary Learning Science, Oxford: Pergamon.
DOURISH, P., 2001, "Seeking a Foundation for Context-Aware Computing", Human Computer Interaction, v. 16, n. 2, pp. 229-241.
DOURISH, P., 1997, "Extending Awareness Beyond Synchronous Collaboration". In: Proceedings of the Workshop on Awareness in Collaboration Systems (CHI'97), Atlanta, USA.
103
DOURISH, P., BELLOTTI, V., 1992, "Awareness and Coordination in Shared Workspaces". In: Proc. ACM Conference on Computer Supported Cooperative Work (CSCW'92), pp. 107-114, Toronto, Ontario.
ELLIS, L., GIBBS, S. J., REIN, G. L., 1991, "Groupware: Some Issues and Experiences", Communications of the ACM, v. 34, n. 1, pp. 38-58.
EUZENAT, J., LÉGER, A., MCGUINNES, D. L., 2006, "Second International Workshop on Contexts and Ontologies: Theory, Practice and Applications". In: http://www.c-and-o.net/, Access in 04/2006.
FILIPPO, D., FUKS, H., LUCENA, C. J. P., 2005, "AulaNetM: Extension of the AulaNet Environment to PDAs". In: 5th International and Interdisciplinary Conference on Modeling and Using Context (Context-05), Workshop on Context and Groupware.
FRANKLIN, S., GRAESSER, A., 1996, "Is it an Agent, or just a Program? A Taxonomy for Autonomous Agents". In: Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages, Springer-Verlag.
FUKS, H., GEROSA, M. A., LUCENA, C. J. P., 2002, "The Development and Application of Distance Learning on the Internet", Open Learning - The Journal of Open andDistance Learning, v. 17, n. 1, pp. 23-38.
FURTADO, A., GATIS, I., ANDRADE, G., SOBRAL, L., 2005, "Travel Mate - ImagineCup 2005". In: http://agenciact.mct.gov.br/index.php?action=/content/view&cod_objeto=25706, Access in 03/2006.
FUSSEL, S. R., PANKOKE-BABATZ, U., PRINZ, W., 1995, "Supporting Cooperative Awareness with Local Event Mechanisms: The GroupDesk System". In: Proceedings of the ECSCW'95, pp. 247-262, Stockholm, Sweden.
GAUVIN, M., BOURRY-BRISSET, A. C., AUGER, A., 2004, "Context, Ontology and Portfolio: Key Concepts for a Situational Awareness Knowledge Portal". In: Proceedings of the 37th Hawaii International Conference on System Sciences - Track 4, p. 40111b.
GEROSA, M. A., 2006, Desenvolvimento de Groupware Componentizado com Base no Modelo 3C de Colaboração, Tese de D.Sc., Pontifícia Universidade Católica do Rio de Janeiro.
GEROSA, M. A., FUKS, H., LUCENA, C. J. P., 2001, "Elementos de Percepção como Forma de Facilitar a Colaboração em Cursos via Internet". In: Anais XII Simpósio Brasileiro de Informática na Educação - SBIE, pp. 194-202, Vitória - ES - Brasil.
GHIDINI, C., SERAFINI, L., BOUQUET, P., 2006, "Second International Workshop on Context Reasoning and Representation". In: http://sra.itc.it/events/crr06/, Access in 04/2006.
GIUNCHIGLIA, F., 1993, "Contextual reasoning". In: Proceedings IJCAI Workshop on Using Knowledge in its Context, pp. 39-49, Chambery France.
GOOGLE, 2006, "GMail, the Google Mail". In: http://mail.google.com, Access in 04/2006.
GOSLAR, K., SCHILL, A., 2004, "Modeling Contextual Information Using Active Data Structures". In: Proceedings of the Current Trends in Database Technology - EDBT 2004, Workshops on Pervasive Information Management (PIM), v. LNCS 3268, pp. 325-334.
GREENBERG, S., 2001, "Context as a Dynamic Construct", Human Computer Interaction, v. 16, n. 2-4, pp. 257-268.
GROSS, T., PRINZ, W., 2003, "Awareness in Context: A Light-Weight Approach". In: Proceedings of the Eights European Conference on Computer-Supported Cooperative Work - ECSCW 2003, pp. 295-314, Helsinki, Finland.
GROSS, T., SPECHT, M., 2001, "Awareness in Context-Aware Information Systems". In: Mensch & Computer - 1. Fachuebergreifende Konferenz, pp. 173-182, Bad Honnef, Germany.
GROSS, T., STARY, C., TOTTER, A., 2005, "User-Centered Awareness in Computer-Supported Cooperative Work-Systems: Structured Embedding of Findings from Social Sciences", Human Computer Interaction, v. 18, n. 3, pp. 323-360.
104
GRUBER, T., 1993, "A Translation Approach to Portable Ontologies", Knowledge Acquisition, v. 5, n. 2, pp. 199-220.
GRUDIN, J., 1994, "Groupware and Social Dynamics: Eight Challenges for Developers", Communications of the ACM, v. 37, n. 1, pp. 92-105.
GU, T., PUNG, H. K., ZHANG, D. Q., 2004a, "A Bayesian Approach for Dealing with Uncertain Contexts". In: Proceedings of the Second International Conference on Pervasive Computing (Pervasive 2004), Vienna, Austria.
GU, T., PUNG, H. K., ZHANG, D. Q., 2005, "A Service-Oriented Middleware for Building Context-Aware Services", Elsevier Journal of Network and Computer Applications (JNCA), v. 28, n. 1, pp. 1-18.
GU, T., PUNG, H. K., ZHANG, D. Q., WANG, X. H., 2004b, "A Middleware for Building Context-Aware Mobile Services". In: Proceedings of IEEE Vehicular Technology Conference (VTC 2004), Milan, Italy.
GU, T., WANG, X. H., PUNG, H. K., ZHANG, D. Q., 2004c, "An Ontology-based Context Model in Intelligent Environments". In: Proceedings of Communication Networks and Distributed Systems Modeling and Simulation Conference, San Diego, California, USA.
GUTWIN, C., 1997, Workspace Awareness in Real-Time Distributed Groupware, Ph.D. Thesis, University of Calgary, In: http://www.cs.usask.ca/faculty/gutwin/publications/.
GUTWIN, C., GREENBERG, S., 2002, "A Descriptive Framework of Workspace Awareness for Real-Time Groupware". In: Computer Supported Cooperative Work, v. 11(3-4), pp. 411-446, Special Issue on Awareness in CSCW, Kluwer Academic Press.
HALPIN, T., 2006, "ORM - Object Role Modeling". In: http://www.orm.net/index.html, Access in 05/2006.
HELD, A., BUCHHOLZ, S., SCHILL, A., 2002, "Modeling of Context Information for Pervasive Computing Applications". In: Proceedings of the 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI2002), Orlando, FL, USA.
HENRICKSEN, K., 2003, A Framework for Context-Aware Pervasive Computing Applications, PhD Thesis, School of Information Technology and Electrical Engineering, The University of Queensland.
HENRICKSEN, K., INDULSKA, J., 2005, "Developing Context-Aware Pervasive Computing Applications: Models and Approach", Pervasive and Mobile Computing Journal.
HENRICKSEN, K., INDULSKA, J., RAKOTONIRAINY, A., 2002, "Modeling Context Information in Pervasive Computing Systems". In: Proceedings of 1st International Conference on Pervasive Computing, v. LNCS 2414, pp. 167-180, Springer, Zurich, Switzerland.
HENRICKSEN, K., LIVINGSTONE, S., INDULSKA, J., 2004, "Towards a Hybrid Approach to Context Modelling, Reasoning and Interoperation". In: UbiComp 1st International Workshop on Advanced Context Modelling, Reasoning and Management, pp. 54-61, Nottingham.
HONG, J. I., LANDAY, J. A., 2001, "An Infrastructure Approach to Context-Aware Computing", HCI Journal, v. 1, n. 16, pp. 287-303.
HUANG, Q., 2002, Supporting Context-Aware Computing in Ad Hoc Mobile Environments. Technical Report WUCS-02-36, Washington University, Department of Computer Science and Engineering, St. Louis, Missouri.
IANNELLA, R., 2001, "Representing vCard Objects in RDF/XML". In: http://www.w3.org/TR/vcard-rdf, Access in 03/2006.
IBM, 2006, "Lotus Notes". In: http://www-306.ibm.com/software/lotus/, Access in 03/2006.
INDULSKA, J., DE ROURE, D., 2004, "Proceedings of the First International Workshop on Advanced Context Modelling, Reasoning and Management". In: http://pace.dstc.edu.au/ContextWorkshop2004Program.html, Access in 04/2006.
105
INDULSKA, J., NICKLAS, D., 2006, "CoMoRea'06 - 3rd Workshop on Context Modeling and Reasoning". In: http://nexus.informatik.uni-stuttgart.de/COMOREA/2006/, Access in 04/2006.
INDULSKA, J., ROBINSONA, R., RAKOTONIRAINY, A., HENRICKSEN, K., 2003, "Experiences in Using CC/PP in Context-Aware Systems". In: Proceedings of the 4th International Conference on Mobile Data Management (MDM2003), v. LNCS 2574, pp. 247-261, Melbourne/Australia.
ISO, IEC, 2002, Topic Maps. ISO/IEC 13250, Available at http://y12web2.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf.
JENA, 2006, "Jena - A Semantic Web Framework for Java". In: http://jena.sourceforge.net/, Access in 03/2006.
JESS, 2006, "Jess - The Expert System Shell for the Java Platform". In: http://herzberg.ca.sandia.gov/jess/, Access in 05/2006.
KICZALES, G., LAMPING, J., MENHDHEKAR, A., MAEDA, C., LOPES, C., LOINGTIER, J. M., IRWIN, J., 1997, "Aspect Oriented Programming". In: Proc. European Conference on Object-Oriented Programming (ECOOP'97), v. 1241 of LNCS, pp. 220-242, Springer-Verlag.
KIFER, M., LAUSEN, G., WU, J., 1995, "Logical Foundations of Object-Oriented and Frame-Based Languages", Journal of the ACM, v. 42, n. 4, pp. 741-843.
KINDBERG, T., BARTON, J., 2001, "A Web-based Nomadic Computing System", Computer Networks, v. 35, n. 4, pp. 443-456.
KIRSCH-PINHEIRO, M., 2001, Mecanismo de Suporte à Percepção em Ambientes Cooperativos, Dissertação de M.Sc., PPGC/UFRGS, Porto Alegre, RS, Brasil.
KIRSCH-PINHEIRO, M., GENSEL, J., MARTIN, H., 2004, "Representing Context for an Adaptative Awareness Mechanism". In: Proc. of the X International Workshop on Groupware (CRIWG'2004), v. LNCS 3198, pp. 339-348, San Carlos, Costa Rica, Springer-Verlag.
KIRSCH-PINHEIRO, M., LIMA, J. V., BORGES, M. R. S., 2002, "A Framework for Awareness Support in Groupware Systems". In: Proc. 7thInternational Conference on CSCW in Design (CSCWD'02), pp. 13-18, Rio de Janeiro, Brasil.
KIRSCH-PINHEIRO, M., OLIVER, M. V., GENSEL, J., MARTIN, H., 2005, "Context-Aware Filtering for Collaborative Web Systems: Adapting the Awareness Information to the User's Context". In: ACM Symposium on Applied Computing, pp. 1668-1673, Santa Fe, New Mexico, USA.
KIRSCH-PINHEIRO, M., VILLANOVA-OLIVER, M., GENSEL, J., LIMA, J. V., MARTIN, H., 2003, "Providing a Progressive Access to Awareness Information". In: Proceedings of the 10th International Conference on Cooperative Information Systems, CoopIS'2003, v. LNCS2888, pp. 336-353, Catania, Sicily, Italy.
KO, H., KRÜGER, A., LEE, S., WOO, W., 2005, "First International Workshop on Personalized Context Modeling and Management for UbiComp Applications". In: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-149/, Access in 04/2006.
KORPIPÄÄ, P., MÄNTYJÄRVI, J., KELA, J., KERÄNEN, H., MALM, E., 2003, "Managing Context Information in Mobile Devices", IEEE Pervasive Computing, v. 2, n. 3, pp. 42-51.
LIECHTI, O., 2000, "Awareness and the WWW: an Overview". In: Proc. Workshop on 'Awareness and the WWW' (CSCW '00), v. 21 (3), pp. 3-12, ACM Press, New York, USA.
LUFF, P., HEATH, C., 1998, "Mobility in Collaboration". In: Proc. of the ACM 1998 Conference on Computer Supported Cooperative Work, pp. 305-314, Seattle, WA, US.
MARK, G., FUCHS, L., SOHLENKAMP, M., 1997, "Supporting Groupware Conventions through Contextual Awareness". In: Proceedings of ECSCW'97, pp. 253-268, Lancaster, England, Kluwer Academic Publishers.
MCCAFFREY, L., 1998, Representing Change in Persistent Groupware Environments. Grouplab report. Department of Computer Science, University of Calgary, Alberta, Canada, January.
106
MCCARTHY, J., 1993, "Notes on Formalizing Contexts". In: Proceedings of the Thirteenth International Joint Conference on Artificial Intelligence, pp. 555-560, San Mateo, California.
MEIRE, A. P., 2003, Suporte à Edição Cooperativa de Diagramas Utilizando Versões, Dissertação de Mestrado, Instituto de Matemática e Núcleo de Computação e Eletrônica, Universidade Federal do Rio de Janeiro, Brasil.
MICROSOFT, 2003, "MSN Instant Messenger". In: http://www.msn.com, Access in 04/2006.
MICROSOFT, 2005, "MSProject". In: http://www.msproject.com/, Access in 03/2006.
MIKA, P., AKKERMANS, H., 2005, "Towards a New Synthesis of Ontology Technology and Knowledge Management", The Knowledge Engineering Review, v. 19, n. 4, pp. 317-345.
MOLLI, P., SKAF-MOLLI, H., OSTER, G., JOURDAIN, S., 2002, "SAMS: Synchronous, Asynchronous, Multi-Synchronous Environments". In: Proc. 7thInternational Conference on CSCW in Design (CSCWD'02), pp. 80-84, Rio de Janeiro, Brasil.
MORSE, D. R., ARMSTRONG, S., DEY, A. K., 2000, "The What, Who, Where, When and How of Context-Awareness". In: http://www-static.cc.gatech.edu/fce/contexttoolkit/pubs/CHI2000-workshop.pdf, Access in 03/2006.
MUÑOZ, M. A., GONZALEZ, V. M., RODRÍGUEZ, M., FAVELA, J., 2003, "Supporting Context-Aware Collaboration in a Hospital: An Ethnographic Informed Design". In: Proc. of CRIWG'03, v. LNCS 2806, pp. 330-344, Springer-Verlag Berlin, Heidelberg.
NOY, N. F., MCGUINNES, D. L., 2001, "Ontology Development 101: A Guide to Creating Your First Ontology". In: http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html, Access in 07/2005.
OMG, 2006, "Unified Modeling Language - Resource Page". In: http://www.uml.org/, Access in 05/2006.
OPENCYC, 2006, "OpenCyc". In: http://www.opencyc.org/, Access in 04/2006.
ÖZTÜRK, P., AAMODT, A., 1997, "Towards a Model of Context for Case-Based Diagnostic Problem Solving". In: Proceedings of the interdisciplinary conference on modeling and using context (Context-97), pp. 198-208, Rio de Janeiro, Brasil.
PEPPER, S., 2002, "The TAO of Topic Maps: Finding the Way in the Age of Infoglut". In: http://www.ontopia.net/topicmaps/materials/tao.html.
PLAYSTATION, 2004, "Game Dictionary". In: www.playstationpro2.com/dictionary.html, Access in 03/2006.
POOLE, D., GOEBEL, R., ALELIUNAS, R., 1998, "Theorist". In: http://www.cs.ubc.ca/~poole/theorist.html, Access in 05/2006.
POWER, R., 2003, "Topic Maps for Context Management". In: Proceedings of the 1st International Symposium on Information and Communication Technologies - Workshop on Adaptive Systems for Ubiquitous Computing, pp. 199-204, Dublin, Ireland.
PRAKASH, A., SHIM, H. S., LEE, J. H., 1999, "Data Management Issues and Tradeoffs in CSCW Systems", IEEE Transactions on Knowledge and Data Engineering, v. 11, n. 1, pp. 213-227.
PREUVENEERS, D., DEN BERGH, J. V., WAGELAAR, D., GEORGES, A., RIGOLE, P., CLERCKX, T., BERBERS, Y., CONINX, K., JONCKERS, V., DE BOSSCHERE, K., 2004, "Towards an Extensible Context Ontology for Ambient Intelligence". In: Ambient Intelligence: Second European Symposium, EUSAI 2004, LNCS 3295, pp. 148-159, Eindhoven, The Netherlands.
PRINZ, W., 1999, "NESSIE: An Awareness Environment for Cooperative Settings". In: Proceedings of the Sixth European Conference on Computer Supported Cooperative Work, pp. 391-410, Copenhagen, Denmark.
PROTÉGÉ, 2006, "The Protégé Ontology Editor and Knowledge Acquisition System". In: http://protege.stanford.edu/, Access in 04/2006.
RACER, 2005, "Racer Manager". In: http://www.sts.tu-harburg.de/~r.f.moeller/racer/, Access in 04/2006.
107
RAMAMPIARO, H., NYGARD, M., 1999, "Cooperative Database System: A Constructive Review of Cooperative Transactions Models". In: Proc. International Symposium on Database Applications in Non-Tradicional Environments (DANTE'99), pp. 315-324, IEEE Computer Society Press, Kyoto, Japan.
RANGANATHAN, A., CAMPBELL, R. H., 2003, "A Middleware for Context-Aware Agents in Ubiquitous Computing Environments". In: ACM/IFIP/USENIX International Middleware Conference, Rio de Janeiro, Brasil.
RANGANATHAN, A., CAMPBELL, R. H., RAVI, A., MAHAJAN, A., 2002, "ConChat: A Context-Aware Chat Program", IEEE Pervasive Computing, pp. 52-58.
RANGANATHAN, A., LEI, H., 2003, "Using Context Information to Improve Human Communication", IEEE Computer, v. 36, n. 4, pp. 90-92.
RANGANATHAN, A., MCGRATH, R. E., CAMPBELL, R. H., MICKUNAS, D., 2003, "Ontologies in a Pervasive Computing Environment". In: Workshop on Ontologies and Distributed Systems (part of the 18'th International Joint Conference on Artificial Intelligence (IJCAI 2003), Acapulco, Mexico.
RANGANATHAN, A., MCGRATH, R. E., CAMPBELL, R. H., MICKUNAS, D., 2004, "Use of Ontologies in a Pervasive Computing Environment", The Knowledge Engineering Review, v. 18, n. 3, pp. 209-220.
REDMILES, D. F., KANTOR, M. L., SOUZA, C. R. B., 2002, "Awareness Gauges". In: http://www.isr.uci.edu/projects/cassius/flier.pdf, Access in 05/2006.
RITTENBRUCH, M., 2002, "Atmosphere: A Framework for Context-Awareness", International Journal of Human-Computer Interaction, v. 14, n. 2, pp. 159-180.
RITTENBRUCH, M., 1999, "Atmosphere: Towards Context-Selective Awareness Mechanisms". In: Proc. of the 8th International Conference on Human-Computer Interaction, pp. 332-328.
RIVA, O., 2005, "A Context Infrastructure for the Support of Mobile Context-Aware Services". In: http://www.cs.helsinki.fi/u/kraatika/Courses/f4fMC/WS1/Riva.pdf, Access in 04/2006.
ROMÁN, M., HESS, C. K., CERQUEIRA, R., RANGANATHAN, A., CAMPBELL, R. H., NAHRSTEDT, K., 2002, "Gaia: A middleware infrastructure to enable active spaces", IEEE Pervasive Computing, pp. 74-83.
ROSA, M. G. P., 2004, Inserindo Contexto em Groupware, Dissertação de M.Sc., NCE-IM/UFRJ, Rio de Janeiro, Brasil.
ROSA, M. G. P., BORGES, M. R. S., SANTORO, F. M., 2003, "A Conceptual Framework for Analyzing the Use of Context in Groupware". In: Proc. of CRIWG'03, v. LNCS 2806, pp. 300-313, Springer-Verlag Berlin, Heidelberg.
ROSA, M. G. P., BORGES, M. R. S., SANTORO, F. M., 2005, "Avaliando a Influência do Contexto da Interação no Nível de Cooperação de um Grupo". In: Anais do Simpósio Brasileiro de Informática na Educação (SBIE'05), II Workshop de Ferramentas para Colaboração (WCSCW'05), Juiz de Fora, MG.
RUSSELL, S., NORVIG, P., 2003, Artificial Intelligence – A Modern Approach. 2 ed., New Jersey, Prentice Hall.
SANTORO, F. M., BRÉZILLON, P., ARAÚJO, R. M., 2005, "Context Dynamics in Software Engineering Process", International Journal of Advanced Engineering Informatics, v. Accepted, to appear.
SCHILIT, B., ADAMS, N., WANT, R., 1994, "Context-Aware Computing Applications". In: Proc. of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA.
SCHILIT, B., WANT, R., 1995, "The Xerox ParcTab". In: http://sandbox.parc.com/parctab/, Access in 03/2006.
SCHULZ, S., LEAKE, D. B., ROTH-BERGHOFER, T., 2006, "MRC '06 - Third International Workshop on Modeling and Retrieval of Context". In: http://mrc2006.workshop.hm/, Access in 04/2006.
108
SOHLENKAMP, M., 1998, Supporting Group Awareness in Multi-User Enviroment Through Perceptualization, M.Sc. Dissertation, Fachbereich Mathematik-Informatik der Universität - Gesamthochschule - Paderborn, http://orgwis.gmd.edu/projects/ POLITeam/poliawac/ms-diss/.
SOHLENKAMP, M., PRINZ, W., FUCHS, L., 2000, "POLIAwac: Design and Evaluation of an Awareness Enhanced Groupware Client", AI & Society Journal, v. 14, pp. 31-47.
STRANG, T., LINNHOFF-POPIEN, C., 2004, "A Context Modeling Survey". In: Workshop on Advanced Context Modelling, Reasoning and Management, in 6th International Conference on Ubiquitous Computing, Nottingham/England.
STRANG, T., LINNHOFF-POPIEN, C., FRANK, K., 2003, "CoOL: A Context Ontology Language to enable Contextual Interoperability". In: Proceedings of 4th International Conference on Distributed Applications and Interoperable Systems (DAIS2003)., v. LNCS 2893, pp. 236-247, Paris, France, Springer Verlag.
TAM, J., 2002, Supporting Change Awareness in Visual Workspaces, M.Sc. Dissertation, Department of Computer Science, University of Calgary, Alberta.
TECO, 2000, "TEA - Technology for Enabling Awareness". In: http://www.teco.edu/tea/, Access in 05/2006.
TEDESCO, P., 2001, Mediating Meta-Cognitive Conflicts in Group Planning Situations, PhD Thesis, The University of Leeds, Computer Based Learning Unit and School of Computing.
TREVOR, J., RODDEN, T., BLAIR, G., 1993, "COLA: A Lightweight Activity Model for CSCW". In: Proc. European Computer Supported Cooperative Work (ECSCW'93), pp. 13-17, Milan.
UBC, 2000, "Glossary of Common IT Terms". In: http://www.sauder.ubc.ca/cgs/itm/itm_glossary.html, Access in 03/2006.
VIEIRA, V., 2003, Ariane: Um Mecanismo de Apoio à Percepção em Bases de Dados Compartilhadas, Dissertação de M.Sc., Programa de Engenharia e Sistemas - COPPE - UFRJ, Rio de Janeiro, Brasil.
VIEIRA, V., LUCENA, B., ROCHA, F., 2005a, "CoWS - Collaborative Writing through Shared Spaces". In: http://www.cin.ufpe.br/~vvs/cows, Access in 04/2006a.
VIEIRA, V., MANGAN, M. A. S., WERNER, C. M. L., MATTOSO, M. L. Q., 2004, "Ariane: An Awareness Mechanism for Shared Databases". In: Proceedings of the X International Workshop on Groupware, CRIWG2004, San Carlos, Costa Rica, pp. 92-104.
VIEIRA, V., TEDESCO, P., SALGADO, A. C., 2005b, "Representação de Contextos em Ambientes Colaborativos Usando Ontologia". In: Anais do XVI Simpósio Brasileiro de Informática na Educação, Workshop Brasileiro de Tecnologias para Colaboração.
VIEIRA, V., TEDESCO, P., SALGADO, A. C., 2005c, "Towards an Ontology for Context Representation in Groupware". In: Proceedings of the 11th International Workshop on Groupware (CRIWG'05), pp. 367-375, Porto de Galinhas, Brasil.
VIEIRA, V., ZARATE, D., TEDESCO, P., SALGADO, A. C., 2006, "An Ontology-Based Reasoning Mechanism for Context Management in Groupware". In: Submitted to XII International Workshop on Groupware, CRIWG'2006, Valladolid, Spaña.
W3C, 2004, "Composite Capabilities / Preferences Profile (CC/PP)". In: http://www.w3.org/Mobile/CCPP/, Access in 01/2006.
WANG, X. H., GU, T., ZHANG, D. Q., PUNG, H. K., 2004, "Ontology based context modeling and reasoning using OWL". In: Workshop on Context Modeling and Reasoningat II IEEE International Conference on Pervasive Computing and Communication, Orlando, Florida.
WANT, R., HOPPER, A., FALCAO, V., GIBBONS, J., 1992, "The Active Badge Location System", ACM Transactions on Information Systems, v. 10, n. 1, pp. 91-102.
WAPFORUM, 2003, "User Agent Profile (UAProf)". In: http://www.openmobilealliance.org/release_program/uap_v20.html, Access in 01/2006.
109
WIKIPEDIA, 2006a, "Canal do Transporte". In: http://www.canaldotransporte.com.br/letram.asp, Access in 03/2006a.
WIKIPEDIA, 2006b, "Wikipedia - Framework". In: http://pt.wikipedia.org/wiki/Framework, Access in 03/2006b.
WIKIPEDIA, 2006c, "Wikipedia - Toolkit". In: http://pt.wikipedia.org/wiki/Toolkit, Access in 03/2006c.
ZARATE, D., 2006, Aplicação de contexto ao CoWS uma ferramenta de escrita colaborativa, Trabalho Final de Graduação, Centro de Informática - UFPE, Recife - Brasil.
ZIMMERMANN, A., LORENZ, A., SPECHT, M., 2005a, "Applications of a Context-Management System". In: Proceedings of the CONTEXT-2005555, 569.
ZIMMERMANN, A., SPECHT, M., LORENZ, A., 2005b, "Personalization and Context Management", User Modeling and User-Adapted Interaction, v. 15, n. 3-4, pp. 275-302.