Introdução de percepção de eventos passados no software Amaya

Projeto CEMT - Relatório

Autores :

Tiago Telecken (telecken@inf.ufrgs.br)

Cassiano Bergmann Maciel (cbm@inf.ufrgs.br)

Tharso de Bittencourt Borges (tharso@aton.inf.ufrgs.br)

Manuele Kirsch Pinheiro (manuele@inf.ufrgs.br / Manuele.Kirsch_Pinheiro@inrialpes.fr)

Data :

20 de Agosto de 2001

Sumário

1.Introdução
2.Percepção de eventos passados
3.Framework BW

4.A ferramenta Amaya

5.Estrutura de comunicação entre BW e Amaya

6.Evento de teste

7.Implementação

1.Características gerais

2.Protocolo de comunicação

3.Modificações dentro do Amaya

4.Modificações dentro do BW

8.Conclusões

9.Bibliografia

1 Introdução

Este relatório descreve a introdução de um suporte à percepção de eventos passados (past events awareness) sobre o Amaya, um software de edição de documentos desenvolvido pelo Projeto Opéra junto ao INRIA (Institut National de Recherche en Info matique t en Automatique - France)[OPE 99]. Este suporte consiste de um framework chamado BW, criado com a finalidade de fornecer um suporte flexível a este tipo de percepção. Este framework foi desenvolvido por M. K.Pinheiro junto à PPGC/UFRGS (Programa de Pós-Graduação em Computação / Universidade Federal do Rio Grande do Sul - Brasil) [PIN 01a]. O resultado da introdução deste framework no software Amaya , como se verá neste relatório, foi uma nova versão do Amaya capaz de armazenar e recuperarinformações de awareness.
Este relatório está organizado nas seguintes partes:
·Percepção de eventos passados: uma pequena exposição sobre o que se conhece por "past events awareness" ou percepção de eventos passados;

·Framework BW: uma exposição sobre o funcionamento e a estrutura deste framework;

·A ferramenta Amaya: um resumo da estrutura deste software;

·Estrutura de comunicação entre BW e Amaya: esta seção explica como a comunicação entre BW e Amaya funciona;

·Evento de teste: esta seção expõe o evento de teste escolhido para se fornecer awareness neste primeiro protótipo;

·Implementação: aqui são fornecidos detalhes sobre a implementação deste teste. Estes detalhes incluem informações sobre as características gerais, o protocolo de comunicação e sobre as modificações realizadas nos códigos do Amaya e BW;

·Conclusões: as conclusões deste processo de inclusão de percepção de eventos passados no Amaya

2 Percepção de eventos passados

Um conceito muito simples de "awareness" (percepção) é o seguinte: fornecer o contexto das atividades individuais através da compreensão das atividades realizadas pelos demais [ARA 97]. De uma forma mais completa, pode-se afirmar que awareness é o conhecimento sobre as atividades do grupo, o conhecimento sobre o que foi produzido em um momento passado, o que está sendo produzido agora e o que se poderá produzir, além do conhecimento sobre o próprio trabalho e sobre o próprio grupo [PIN 01b].
De fato, estar atento aos colegas e às atividades por eles realizadas desempenha um papel muito importante para um trabalho fluido e natural [GUT 99]. Por conseqüência, awareness torna-se crucial para a cooperação, pois perceber, reconhecer e compreender as atividades realizadas por outras pessoas é um requisito básico para a interação humana e para a comunicação em geral [SOH 99].
Pinheiro et al. [PIN 01b] analisaram vários mecanismos de suporte à awareness e identificaram características importantes para este suporte. Estas características são organizadas em 6 questões (o que, quando, onde, quem, como e quanto), cada uma identificando aspectos cruciais para o fornecimento de awareness em ferramentas cooperativas. Dentre estas questões a questão "quando" é a que mais interessa aqui. Esta questão se refere a quando são gerados os eventos que produzem as informações de awareness. Considera-se que as informações de awareness são geradas por eventos, os quais ocorrem durante o trabalho em grupo, e além disso, o momento em que ocorrem os eventos determina sua importância para a percepção do usuário. Pode-se dividir os eventos em quatro momentos possíveis: no passado (estes são eventos que começaram e terminaram em um intervalo passado, e cujos resultados podem não ser mais válidos), em um passado contínuo (para os eventos que começaram no passado, mas que não foram concluídos ou cujos resultados ainda são futuro), no presente (os eventos que estão sendo realizados agora), ou no futuro (representando as opções futuros para o grupo).

Chama-se de "past events awareness" este suporte a eventos passados, e é a introdução deste tipo de suporte no software Amaya que é descrita neste documento.

3 Framework BW

Apesar da sua importância para que o trabalho cooperativo seja bem coordenado e estruturado, o suporte a “past events awareness” é muito limitado na maioria das ferramentas cooperativas disponíveis [PIN 01a]. Como conseqüência, situações como a ausência de um membro do grupo por algum tempo não são tratadas. Como estas situações são muito freqüentes durante o trabalho em grupo, tratá-las é uma condição muito importante para o bom funcionamento de um groupware. Dessa forma, há a necessidade de fornecer um contexto das atividades realizadas para aqueles membros que continuam trabalhando e também para aqueles que retornam ao trabalho após um período de ausência.
Dentro deste objetivo de fornecer um mecanismo flexível para o suporte a “past events awareness” que o framework BW foi criado. O BW (Big Watcher) é um framework para fornecer esse suporte. Ele foi concebido de uma maneira flexível, de forma a poder ser incluído em diversas ferramentas cooperativas [PIN 01a].
O BW foi organizado em quatro pacotes (ver Figura 1). Três (chamadas control, storage e Interface) são independentes trocam informações que são descritas no quarto pacote (chamado kernel). Essas informações são essencialmente relativas aos eventos, os quais representam as atividades que foram concluídas por qualquer membro (qualquer membro que interprete um papel específico) de um grupo. Essas atividades são registradas no BW pela ferramenta cooperativa que o utiliza, objetivando fornecer o contexto do trabalho aos seus usuários. Além disso, a própria ferramenta cooperativa pode criar classes específicas a partir das classes propostas pelo BW. Como conseqüência, o framework BW pode ser incluído em praticamente qualquer ferramenta de cooperação assíncrona que necessite um mecanismo de suporte a “past events awareness” [PIN 01a], [PIN 01c].

Frame1

O framework BW foi implementado em Java (JDK 1.1.x) e sua implementação seguiu a mesma divisão em pacotes (conforme a Figura 1). No pacote kernel encontra-se todas descrições dos eventos e de outras informações utilizadas pelo BW, como por exemplo, os grupos, seus membros e papéis. Em adição, o pacote control é responsável pela gestão de informações, incluindo o tratamento dos eventos que são reportados e também o tratamento das informações para o usuário. Finalmente, os pacotes interface e storage são responsáveis, respectivamente, pela interface com o usuário e pelo armazenamento das informações.

Todo o funcionamento do framework BW é organizado em três etapas: inicialmente, a ferramenta cooperativa registra os eventos junto ao framework BW. Cada tipo de evento registrado no BW corresponde a um único tipo de atividade possível na ferramenta cooperativa. Este processo permitirá ao usuário escolher sobre quais atividades serão fornecidas as informações de awareness. Após, ao passo que as atividades são finalizadas (completadas) dentro das ferramentas cooperativas, os eventos correspondentes a essas atividades são gerados e enviados para o framework. Esta segunda etapa se repete durante a realização do trabalho cooperativo. A terceira etapa compreende a própria notificação das informações de awareness para o usuário. Essa notificação é feita através da interface entre o framework e o usuário, que utiliza as funções descritas no pacote interface e deve também estar bem integrada à própria interface da ferramenta de cooperação.

4 A ferramenta Amaya

O Amaya é um browser e editor de documentos que permite a publicação destes documentos na web estes documentos podem ser do tipo texto, HTML, XHTML, folhas do estilo do CSS, expressões de MathML, e desenhos de SVG. Sua interface é do tipo "WYSIWYG "(a aparência do documento durante a edição é semelhante a aparência do documento final).
Seu funcionamento se baseia sobre a fragmentação do documento em diversas partes (elements), a fragmentação utilizada pelo Amaya é resultado do trabalho da API Thot. O Thot é utilizado para o desenvolvimento de aplicações que manipulam documentos estruturados. Ele fornece um conjunto de funções que manipulam a estrutura lógica e o conteúdo dos documentos. Além disso, o Thot permite às aplicações incluírem funções extras (funções lógicas e para interface gráfica) através de um mecanismo de call back e linguagens de alto nível. [DEC 98a], [DEC 98b], [QUI 99a].
Um documento no Thot, e conseqüente mente no amaya é representado por sua estrutura lógica, essencialmente hierárquica, que se chama “árvore abstrata”. Sobre essa estrutura são adicionadas relações suplementares, resultando também um hipertexto. Essa estrutura segue algumas regras, uma espécie de formato de documento, que ajuda (ou obriga) seus usuários a produzirem documentos daquele tipo.

Analisando os recursos de edição colaborativa do amaya foram encontrados poucos recursos dentre eles umsistema de anotação colaborativa baseada em RDF (Resource Description Framework), XPointer e Xlink que permite que várias pessoas possam anexar anotações, comentários à um documento, bastando para isto ter acesso a internet e ao servidor de anotações do documento.[KOI01].

Apesar do amaya proporcionar um certo tipo de percepção através das anotações e da visualização de como o documento esta a cada momento não foi encontrado no mesmo um sistema de awareness de eventos passados; devido a tal limitação , decidiu-se introduzir nele um módulo de “past events awareness”, utilizando o framework BW, que já foi comentado anteriormente.

5 Estrutura de comunicação entre o BW e o Amaya

Este trabalho adicionou no software Amaya um módulo para o fornecimento de suporte a “past events awareness”. Este módulo foi concebido para a manipulação dos diversos tipos de eventos gerados pelo Amaya, com o objetivo de fornecer um suporte para a notificação destas atividades já concluídas. Este suporte é fornecido pelo framework BW.
O módulo de suporte à notificação de eventos passados é o único responsável por toda a comunicação necessária entre o Amaya e o BW. Este módulo é estruturado em duas partes: um cliente e um servidor de awareness. O cliente trabalha diretamente ligado ao Amaya, de forma a passar para o servidor as descrições dos eventos, e que este servidor repasse-as para o BW. A arquitetura utilizada para a comunicação entre essas duas partes, cliente e servidor, é descrita na Figura 2.

Figura 2 Arquitetura utilizada

Essa arquitetura de comunicação foi escolhida pois o Amaya e o BW foram construídos com linguagens de programação diferentes, e essa arquitetura se mostrou a mais simples para fazer a integração dos sistemas. O Byzance é um software escrito em C com uma base de dados (base de dados fornecida pela biblioteca Thot), enquanto o framework BW foi escrito em Java. Além disso, nesta implementação foi utilizada uma base de dados centralizada (fornecida pelo software PostgreSQL), criada anteriormente para uma outra utilização do framework BW. Dessa forma, foi escolhida essa opção de modelo cliente-servidor, utilizando TCP/IP, para ser inserida na arquitetura atual do Amaya que ainda conta com um servidor central de anotações.

O armazenamento e a leitura das informações neste sistema passa pelas seguintes fases:

1.Quando o usuário concluir uma atividade (e por conseqüência, um evento é gerado), o Amaya irá realizar seus procedimentos habituais, e após, ele irá enviar as informações de awareness para o cliente TCP/IP dentro do módulo de awareness (Awareness Module). Este cliente, que foi escrito na linguagem C, vai tratar e enviar essas informações para o lado servidor do módulo. Este servidor, escrito em Java, localiza-se na mesma máquina do cliente e inclui o framework BW. Ele repassa ao BW as informações recebidas, que são então estocadas pelo BW através de uma base de dados PostgreSQL remota;

2.Quando o usuário pede uma notificação das informações de awareness, o Amaya passa as informações desta requisição para o lado cliente do módulo de awareness. Este cliente repassa essa requisição para o lado servidor do módulo, que, utilizando o framework BW, lê as informações de awareness da base de dados. Estas informações lidas são então repassadas ao cliente TCP/IP, que mostra as informações para o usuário.

Depois da definição da arquitetura, escolheu-se um evento para verificar a primeira implementação deste sistema. Esta escolha está descrita abaixo.

6 O evento de teste

Foi escolhido para o primeiro teste o evento “Save Document”. Este evento representa a atividade de salvamento do documento. Essa atividade é muito importante, pois ela indica que os fragmentos editados pelo usuário estão salvos de forma estável.
Um evento “Save Document” é criado quando um usuário pede o salvamento do documento após tê-lo modificado. É obrigatório que este documento tenha sido modificado pelo usuário, caso contrário o evento não será gerado.
As informações de awareness sobre um documento, ao qual chama-se freqüentemente “o relatório de awareness”, contém os seguintes itens:

·Um título com o nome do documento;

·Uma seqüência de linhas que mostra as seguintes informações de cada evento "Save Document" ocorrido:

§a data de quando o documento foi salvo;

§a url onde o documento foi armazenado;

§o nome do usuário que salvou o documento.

Com este primeiro evento, objetivou-se testar a inclusão do suporte à “past events awareness” dentro do Amaya. Existem ainda diversos outros eventos interessantes que podem ser incluídos após a validação deste teste. Por exemplo, é possível, com esse suporte, mostrar quais usuários já visualizaram a última versão de um fragmento, ou ainda mostrar quantas versões de um fragmento foram geradas desde a última visualização por parte de um usuário, etc.

7 A implementação

7.1 Características Gerais

A implementação do suporte a awareness no Amaya seguiu a arquitetura discutida na seção 5 deste relatório. Esta implementação foi limitada, neste primeiro momento, a um único evento, conforme discutido na última seção deste documento. Nesta seção, serão expostos detalhes mais precisos desta implementação, começando pela interface e pela comunicação utilizada.
Para apresentar as informações de awareness aos usuários, foi concebida uma pequena interface dedicada a essa tarefa, observando as sugestões disponibilizadas por Pinheiro [PIN 01a]. Uma das sugestões de Pinheiro é a integração da interface de suporte a awareness na própria interface da ferramenta cooperativa, com o objetivo de não confundir o usuário. Seguindo essa sugestão foi criada uma extensão da interface completamente integrada à interface do Amaya. O usuário, para ler o relatório de awareness de um fragmento, deve utilizar os menus, exatamente como para as outras funções do Amaya. Assim, basta clicar sobre a opção “Awareness” dentro do menu “Cooperation” (Que foi adicionado no amaya neste projeto). Como resultado, o sistema mostrará o relatório de awareness de um documento ativo em uma janela simples, construída com a biblioteca Thot. Considera-se como documento ativo aquele documento onde o cursor está posicionado.
Para ter as informações de awareness, essas devem ser transmitidas entre o lado cliente e o lado servidor do módulo de awareness. A comunicação entre os dois lados, cliente e servidor, é realizada através de sockets TCP/IP, utilizando streams para o fluxo de informações. Essas informações são compostas de strings, que respeitam um protocolo fixo, que será discutido em detalhes mais adiante. Nessas strings existem caracteres que delimitam os blocos de informações e que são definidos neste mesmo protocolo. Graças a esses caracteres, os blocos de informações são facilmente compreendidos e registrados.

O primeiro passo dessa comunicação é a criação, e posterior identificação, do socket. Esse processo utiliza as funções padrão das bibliotecas C/UNIX (write, para enviar as informações, e read, para sua leitura). Quando o socket for criado com sucesso, pode-se requisitar uma conexão com o servidor, utilizando-se uma porta anteriormente definida (onde o servidor espera as conexões dos clientes). Quando o servidor aceita essa conexão, está definido um caminho para o fluxo de informações, e a comunicação em dois sentidos (cliente - servidor e servidor - cliente) é estabelecida. Por conseqüência, pode-se utilizar o mesmo socket para enviar e receber as informações.

Utilizou-se, para receber as informações a função "read", as quais, no caso de falha de comunicação bloqueiam o processo, não permitindo o uso do Amaya até que exista uma resposta do servidor . Por outro lado, utilizou-se funções não bloqueantes para enviar as informações (write). Isso significa que o processo somente com a função "write" não irá esperar até que seja obtida uma resposta confirmando a transmissão, por isto é utilizada uma chamada (read) logo após o envio de dados para o servidor, que por ser bloqueante espera o envio de uma resposta por este. Deste modo, garante-se que as informações serão transmitidas corretamente. Ao utilizar-se funções bloqueantes corre-se o risco de impedir o trabalho do usuário, se o tempo de espera for muito longo. Entretanto, como o servidor e o cliente são locais à mesma máquina, os tempos de espera não serão longos.

Já do lado do servidor do módulo de awareness, quando este recebe as informações do cliente, sua primeira atitude é transformar o conjunto de bytes recebidos em objetos “evento”, que serão manipulados e armazenados pelo BW.

A escolha dessas duas estratégias, comunicação TCP e streams, dá uma melhor confiabilidade na entrega das informações, pois facilita a detecção de erros e perdas de pacotes durante a comunicação. Além disso, essas estratégias suportam a entrega seqüencial dos pacotes. É fácil imaginar os possíveis problemas causados pela entrega fora de ordem. Nesses casos, poderia-se obter informações incompletas ou mesmo perder dados essenciais ao bom funcionamento do serviço.

7.2 O protocolo de comunicação

Para realizar a comunicação descrita na seção acima, propôs-se um protocolo simples. A lista completa dos comandos deste protocolo está exposta na Tabela 1.
Tabela 1 Comandos do protocolo
Comando
Funcionalidade
BEGIN
Inicia todas as transmissões
BEGINEVENT
Indica o início de um evento
ENDEVENT
Indica o fim do último evento reportados
CANCELEVENT
Anula o último evento que iniciou
NEWUSER
Adiciona um novo usuário ao grupo ou muda as informações de um usuário
SETUSERPROFILE
Muda o conjunto de profiles do usuário. Esses profiles são uma estrutura do BW que informa quais são os eventos que interessam ao usuário.
GETEVENTS
Requisita os eventos, que foram produzidos em um intervalo de tempo passado, e que interessam ao usuário.
BYE
Finaliza as transmissões
OK
Resposta do servidor a um comando bem sucedido
NOK
Resposta do servidor a um comando mal sucedido
Todos esses comandos seguem uma sintaxe similar, exceto o comando BYE. Essa sintaxe é a seguinte:
COMANDO informações

As informações que são enviadas dependem do comando, e têm sua própria sintaxe geral (exceto no caso das informações do comando SETUSERPROFILE):

< atributo1= "valor" & atributo2= "valor" & atributo3= "valor" & ... & atributoN="valor" >

Estes atributos são os mesmos que foram definidos nas classes “BW_Member”, “BW_Event”, “BW_Profile” e “BW_AwarenessProfile” do framework BW. Essas classes descrevem, respectivamente, os usuários, os eventos, os profiles gerais e os profiles dos usuários. A sintaxe completa destes comandos está representada abaixo.
 
Comando :
BEGIN < type="4" & login="login" & name="nom" & machine="nom de la machine" >
informações :

O comando BEGIN passa as informações básicas sobre o usuário ativo. 

resposta do servidor: 

OK - Se tudo foi bem. 

NOK - Se houveram problemas servidor. 

comando :
BEGINEVENT < type="n" & name="nom du evento" & description="description du evento" & details="détails sur l'evento" >
informações :

O comando BEGINEVENT passa as informações sobre o evento que começa. Os atributos "description" e "details" podem ser vazios (exemplo : details=""). 

resposta do servidor : 

OK - Se tudo foi bem. 

NOK - Se houveram problemas no servidor. 

comando :
ENDEVENT < type="n" & name="nom du evento" & description="description du evento" & details="détails sur l'evento" >
informações :

O comando ENDEVENT passa algumas informações sobre o evento que termina. Os atributos "description" e "details" podem ser vazios (exemplo : details=""). 

resposta do servidor : 

OK - Se tudo foi bem. 

NOK - Se houveram problemas no servidor. 

comando :
CANCELEVENT < type="n" & name="nom du evento" & description="description du evento" & details="détails sur l'evento" >
informações :

O comando CANCELEVENT passa as informações sobre o evento que foi anulado. Os atributos "description" e "details" podem ser vazios (exemplo : details=""). 

resposta do servidor : 

OK - Se tudo foi bem. 

NOK - Se houveram problemas no servidor. 

comando :
NEWUSER < type="4" & login="login" & name="nom de l'usuário" & homepage="page web personnelle de l'usuário" & mail="courrier électronique de l'usuário" & machine="nom de la machine utilisée par l'usuário" & paper1="première rôle de l'usuário" & paper2="deuxième rôle de l'usuário" & ... & paperN="rôle N de l'usuário"> 
informações :

O comando NEWUSER passa as informações sobre um usuário. Os atributos "homepage", "mail" e "name" podem ser vazios (exemplo : homepage=""). 

observação :

O número "4" é uma sugestão de um identificador único para o tipo de informação "usuário". 

resposta do servidor : 

OK - Se tudo foi bem. 

NOK - Se houveram problemas no servidor. 

comando :
SETUSERPROFILE < type="n" & membertype="identification du type de l'usuário" & memberlogin="login de l'usuário" & membermachine="nom de la machine utilisée par l'usuário" & event1="type=n; name=nom" & ... & eventN="type=n; name=nom" & interval="jour:moins:an:heur:minute; jour:moins:an:heur:minute">
informações :

O comando SETUSERPROFILE passa algumas informações sobre um usuário e as informações sobre seu profile. Existe uma pequena diferença na estrutura do atributo "eventX". Este atributo inclui o tipo de evento e o nome do evento, ambos separados por um ";" e sem as aspas. No atributo "interval", as informações iniciais e finais de data e hora do evento são também separadas por um ";", sendo que as informações individuais dentro destas (dia, mês, ano, hora e minuto) são separados por ":" cada um. 

resposta do servidor : 

OK - Se tudo foi bem. 

NOK - Se houveram problemas no servidor. 

comando :
GETEVENTS < type="n" & login="login de l'usuário" & machine="nom de la machine utilisée par l'usuário" > 
informações :

O comando GETEVENTS passa algumas informações sobre um usuário, o qual deseja receber as informações de awareness de seu interesse. 

resposta do servidor : 

A resposta do servidor será os eventos passados, que acordam com os profiles do usuário. Esta resposta tem a seguinte sintaxe: 

<details="détails sur l'evento" & type="n" & objid="n" & name="nom de l'evento" & description="description de l'evento" & interval="jour:moins:an:heure:minute; jour:moins:an:heure:minute" & memberlogin="login de l'usuário" & membername="nom de l'usuário" & memberhomepage="URL" & membermail="courrier elétronique " & membermachine="maquina" >

<details="détails sur l'evento" & type="n" & objid="n" & name="nom de l'evento" & description="description de l'evento" & interval="jour:moins:an:heure:minute; jour:moins:an:heure:minute" & memberlogin="login de l'usuário" & membername="nom de l'usuário" & memberhomepage="URL" & membermail="courrier elétronique " & membermachine="maquina" >

...

<details="détails sur l'evento" & type="n" & objid="n" & name="nom de l'evento" & description="description de l'evento" & interval="jour:moins:an:heure:minute; jour:moins:an:heure:minute" & memberlogin="login de l'usuário" & membername="nom de l'usuário" & memberhomepage="URL" & membermail="courrier elétronique " & membermachine="maquina" >
comando :
BYE 
informações :

O comando BYE termina as transmissões entre cliente e servidor

7.3 Modificações no Amaya

Para incluir o módulo de awareness no Amaya, alterou-se algumas partes de seu código. As partes alteradas não representam uma grande porção do código total, um resultado muito positivo, especialmente para o framework BW, que objetiva a flexibilidade. Estas modificações realizadas no Amaya são detalhadas abaixo.
·No arquivo/esquema EDITOR.A :Inseriu-se neste esquema o menu "Cooperation"e a opção "Awareness"neste menu, causando a inserção desta opção na Interface visual do Amaya.
·Arquivo EDITORactions.c : no final deste arquivo, inseriu-se a função "AwSaveDoc", que captura o nome do atual documento e visão e os repassa para as funções que irão gerar o relatório de awareness. Também foi inserida a função "AwMountWindow" que montará a janela com o relatório de awareness.

·Arquivo HTMLsave.c: neste arquivo, inseriu-se no fim da função "SaveDocument" uma chamada à função "AwCoordDoc". Esta chamada ocorre após o salvamento do documento e vai acionar o socket de comunicação com o BW.

Os demais códigos específicos do lado cliente do módulo de awareness estão limitados a um único arquivo (awareness.c), no diretório "opera/byzance/awareness". Neste arquivo, encontram-se as funções para o tratamento do protocolo e de outras funções de comunicação. As funções mais importantes são descritas na tabela 2.

Tabela 2 Funções do lado cliente do módulo de awareness
 
Função
Descrição
AwCoordDoc 
AwCoordApp
Estas funções recebem as informações importantes do Amaya e as repassa às funções que irão gerenciar o tratamento dos eventos.
AwExecOnSaveDoc
Esta função gerencia a comunicação TCP/IP entre o cliente e o servidor quando um evento "Save Document" ocorre.
AwExecReportSaveDoc
Função que gerencia a comunicação entre o cliente e o servidor quando um usuário solicita seu relatório de awareness.
MountBegin
Esta função cria a string para o comando BEGIN do protocolo.
MountBeginEvent
Esta função cria a string para o comando BEGINEVENT do protocolo.
MountEndEvent
Esta função cria a string para o comando ENDEVENT do protocolo.
MountGetEvent
Esta função cria a string para o comando GETEVENT do protocolo.
TreatResp
Esta função trata da resposta enviada pelo servidor.
AwSendString
Esta função envia as strings do protocolo do cliente até o servidor.

Finalmente, também se alterou o procedimento de compilação do Amaya:

-Foram criados os arquivos awareness/makefile.in e awareness/makefile.awareness com as instruções de compilação do novo módulo.

-Alterações no arquivo amaya/makefile.in para que o arquivo awareness/awareness.c seja compilado e adicionado no binário do programa amaya.

Com base nestas modificações foram introduzidos dois novos fluxos de informação para as funções de awareness. O primeiro ocorre no momento da criação de um evento. Quando um evento monitorado ocorre, o Amaya ativa as funções de coordenação(AwCoordDoc ou AwCoordApp), as quais recebem as informações necessárias do Amaya e as repassam para as funções gerenciadoras (por exemplo, a função AwExecOnSaveDoc). Estas funções gerenciadoras controlam o envio destas informações capturadas do cliente para o servidor, onde se encontra o framework BW. Este controle incluiu a criação das strings do protocolo (funções MountBeginEvent, MountEndEvent, etc.) e o envio ou a recepção destas strings.

O segundo fluxo ocorre quando um usuário solicita as informações de awareness. O Amaya, neste momento, ativa uma função de coordenação que recebe as informações necessárias a este processo, e as repassa às funções gerenciadoras. Estas funções, por sua vez, solicitam a criação da string do protocolo para o comando GETEVENT (função MountGetEvent), e o envio deste comando. Quando servidor recebe este comando, ele passa o pedido ao framework BW, o qual o trata, lendo informações de awareness interessantes para o usuário. Estas informações serão enviadas do servidor para o cliente, o qual as tratará e mostrará ao usuário, utilizando a função " AwExecReportSaveDoc ".

7.4 Modificações no BW

O framework BW foi projetado para se adaptar à ferramental cooperativa onde ele esta integrado, sem causar grandes modificações nos fontes da ferramenta. A fim de manter esta independência, o BW trabalha com a idéia de um mediador, este é um intermediário entre a ferramenta cooperativa e o framework BW. Dessa forma, a implementação do BW fica escondida da ferramenta à qual ele forneceu suporte a percepção, e a própria ferramenta não precisa de muitas modificações.
Construiu-se, neste trabalho, este mediador entre o Amaya e o BW em linguagem Java. Este mediador representa o lado servidor do módulo de awarenes, o qual receberá as informações (os eventos, as informações sobre o usuário, etc) do lado cliente, que esta no Amaya, as tratará e passará o resultado para o framework BW. Este mediador foi baseado em uma outra implementação de um mediador (ver em Pinheiro [PIN 01a]). Esta seção descreve as modificações realizadas sobre esta implementação utilizada como base para a construção do lado servidor do módulo de awareness.
A primeira modificação realizada na implementação base foi na classe responsável pelo preenchimento inicial da base de dados, e não no mediador propriamente dito. Este preenchimento inclui na base as informações básicas para o bom funcionamento do BW, como o registro do evento de teste, e os papéis, o usuário e grupo modelos. Estas informações da implementação anterior foram adaptadas para o caso do Amaya.

Após estas modificações para o correto preenchimento da base de dados, remodelou-se o mediador existente da aplicação anterior para as necessidades do Amaya. Primeiramente, substituiu-se as definições dos eventos da antiga aplicação para a definição do evento teste ("SAVEDOCUMENT") desta aplicação.

Para a interação com o Amaya, o mediador foi dividido em duas classes : uma, que trata da conexão com o cliente e desmembra a string recebida deste em uma hashtable, e a segunda, o mediador por si próprio, com métodos para transformar os dados da hashtable num objeto BW_Event e comunicar-se com o BW.

A primeira classe, chamada de BWComm, é composta de três métodos : o método “main”, que inicializa o BW e seta o objeto mediador, e inicia o ciclo de espera por conexões; o método “run”, que é disparado cada vez que o servidor recebe uma mensagem do cliente (assim, cada mensagem é tratada por uma thread exclusiva). Este método recebe a mensagem via sockets e dispara o terceiro método, “MessageParser”. Este terceiro método desmembra a string enviada pelo cliente numa hashtable, e envia esta como parâmetro para o método tratador do mediador.

No mediador, alguns métodos da classe foram modificados. Foram alterados os métodos "makePrototypes" e"getPrototypes", que objetivam a criação e a captura, respectivamente, dos protótipos dos eventos, a fim de tratar corretamente os atributos do evento teste. Alterou-se também o método "_start", que faz a inicialização do mediador, para tornar esta inicialização bem adaptada ao caso do Byzance; o método “fillEvent, que preenche os campos ainda em branco do evento recem gerado; o método readDefaults, que lê as informações de grupo e papel default do sistema.

Foram acrescentados também novos métodos, os quais são destinados ao tratamento da mensagem recebida pelo clienteAmaya. Estes métodos transformam a mensagem recebida através da hashtable de forma que seja compatível com o BW, e então ativa os métodos necessários para a continuidade do tratamento. Os principais métodos incluídos são descritos na tabela 3.

Tabela 3 Os mais importantes métodos introduzidos no mediador
 
Métodos
Descrição
AWtreatBegin
Este método é ativado no início da conexão, verificando se o usuário já está cadastrado.
AWtreatBeginEvent
Este método recebe a hashtable , a transforma em um objeto BW_Event (evento), e assinala o início de um evento.
AWtreatEndEvent
Este método recebe a hashtable, a transforma em um objeto BW_Event (evento), e assinala o fim deste evento.
AWtreatCancelEvent
Este método recebe a hashtable, a transforma em um objeto BW_Event (evento), e assinala o cancelamento deste evento.
AWtreatGetEvent
Este método recebe a a hashtable, e solicita os eventos passados para o framework BW.
AwtreatBye
Este método é usado no final da conexão, a fim de deslogar o usuário do BW.

Como o mediador atua, no caso do Amaya, como servidor de awareness (ou como o lado servidor deste módulo), ele deve estar inicializado quando o cliente começar a executar. Por causa disto, a classe BWComm deve ser “executada” a partir de seu método “main”.

Uma conseqüência deste comportamento é a possibilidade de ter vários eventos ocorrendo ao mesmo tempo. Por causa disto, introduziu-se a idéia de multi-threading, a fim de tratar cada requisição em um novo fluxo de controle específico, deixando o fluxo principal (servidor) mais disponível para as outras requisições.

Logo, quando o lado cliente do módulo de awareness no Amaya envia as informações através do canal de comunicação TCP/IP, estas são recebidas pelo BWComm por um de seus fluxos de controle, e elas são tratadas pela função “MessageParser

De forma similar, quando um pedido de relatório de awareness (comando GETEVENT) chega, o fluxo de controle que o recebe chamará a função de tratamento ("AwtratarGetEvent"). Esta função solicitará ao framework BW os eventos passados, montará a string de resposta e a enviará para o cliente. Quando todos estes eventos são recebidos pelo lado cliente do módulo de awareness, o cliente os apresenta ao usuário em uma janela de interface similar à interface utilizada no Amaya.

A interface com o usuário é definida no lado cliente, junto ao Amaya, à fim de bem integrar-se a este.

8 Conclusões

Encontrou-se alguns resultados interessantes durante a realização deste traballho. Os primeiros resultados encontrados foram a capacidade de expansão do Amaya e a flexibilidade do framework BW. Este framework provou sua flexibilidade (uma entre seus principais objetivos), aceitando a integração com a ferramenta complexa como o Amaya. Este demonstrou, também, uma capacidade de expansão, apesar de sua grande complexidade.
Esta capacidade de expansão do Amaya poderá permitir melhoramento do suporte a "past events awareness". Poder-se-á, por exemplo, introduzir o monitoramento de outros eventos mais interessantes, ou melhorar a interface de apresentação das informações de awareness.
Por fim, esta capacidade demonstra que há a possibilidade de construir uma nova versão do Amaya com um suporte a awareness mais efetivo, mas, principalmente, uma nova versão com uma estrutura de workflow. Esta nova versão, que poderá se chamar "AWA" (Amaya, Workflow & Awareness), e ser utilizada para a concepção cooperativa de hiperdocumentos para o ensino à distância.

9 Bibliografia

·[ARA 97] Araújo, R.M.; Dias, M.S.; Borges, M.R.S. Suporte por Computador ao Desenvolvimento Cooperativo de Software: Classificação e Propostas. In: XI Simpósio Brasileiro de Engenharia de Software. Anais. Fortaleza, CE, outubro, 1997. P. 299-314
·[DEC  98a] DECOUCHANT, Dominique; SALCEDO, Manuel Romero; QUINT, Vincent. Structured Cooperative Authoring on the World-Wide Web. Disponible: <http://www.w3.org/pub/Conferences/WWW/Papers/91/>. (set.1998).
·[DEC  98b]DECOUCHANT, Dominique; SALCEDO, Manuel Romero; SERRANO, M. Principes de Conception d'une Application d'Édition Coopérative de Documents sur Internet. Disponible: <ftp://ftp.inrialpes.fr/pub/opera/publications/IHM97.ps.Z> (set.1998).

·[GUT 99] Gutwin, C.; Greenberg, S. A framework of awareness for small groups in shared-workspace groupware. Techinical Report 99-1, Departament of Computer Science, University of Saskatchewan, Canadá. Disponible: <http://www.cpcs.ucalgary.ca/grouplab/papers/1999/99-AwarenessTheory/html/theory-tr99-1.html> (set., 1999).

·[KOI01] KOIVUNEN, Marja. Annotea Project . Disponible < http://www.w3.org/2001/Annotea/> (jun., 2001)

·[OPE  99] Opera Group. Byzance. Disponble: <http://www.inrialpes.fr/opera/Byzance.fr.html> (jun.1999).

·[PIN  01a] Pinheiro, Manuele Kirsch. Mecanismo de suporte à percepção em ambientes cooperativos. Dissertação de mestrado. Porto Alegre, Brasil : PPGC/UFRGS, 2001. Disponible: <http://www.inf.ufrgs.br/~manuele/teseFinalPDF.zip> (jun.,2001).

·[PIN  01b]Pinheiro, Manuele Kirsch; Lima, José Valdeni; Borges, Marcos R.S. Awareness em Sistemas de Groupware. In IV Jornadas Iberoamericanas de Ingenieria de Requisitos y Ambientes de Software. Memorias. Santo Domingo,. Costa Rica : CIT, 2001.

·[PIN  01c] Pinheiro, Manuele Kirsch; Lima, José Valdeni. An Adaptable Framework for Past Events Awareness Support. Disponible: <http://www.inf.ufrgs.br/~manuele/ArtBW.zip> (jun.,2001).

·[QUI  99a]QUINT, Vincent;VATTON, Irène. Thot Tool Kit API. Disponble: <http://www.inrialpes.fr/Thot/Doc/APIman.html> (fev.1999).

·[SAL  98] SALCEDO, Manuel Romero. Alliance sur l'Internet: support pour l'édition coopérative des documents struturés sur um réseau à grande distance. Grenouble, France: INPG, 1998.

·[SOH 99]Sohlenkamp, M. Supporting group awareness in multi-user enviroment through perceptualization. Dissertation. Fachbereich Mathematik-Informatik der Universität - Gesamthochschule - Paderborn. Fevereiro, 1998. Disponible: <http://orgwis.gmd.edu/projects/POLITeam/ poliawac/ms-diss/> (jul., 1999)