Introdução de percepção de eventos passados no software Byzance
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 :
22 de Agosto de 2001Sumário
4.A ferramenta cooperativa Byzance
5.Estrutura de comunicação entre BW e Byzance
3.Modificações dentro do Byzance
1 Introdução
Este relatório descreve a introdução de um suporte à percepção de eventos passados (past events awareness) sobre o Byzance, um software cooperativo 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 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 Byzance , como se verá neste relatório, foi uma nova versão do Byzance capaz de armazenar e recuperar a informação 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 cooperativa Byzance: um resumo da estrutura deste software;
·Estrutura de comunicação entre BW e Byzance: esta seção explica como a comunicação entre BW e Byzance 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 Byzance e BW;
·Conclusões: as conclusões deste processo de inclusão de percepção de eventos passados no Byzance
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 Byzance 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].
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 Cooperativa Byzance
A ferramenta Byzance é um editor HTML cooperativo assíncrono. Ela permite que usuários geograficamente distribuídos e conectados através da Internet editem conjuntamente páginas HTML. Seu funcionamento se baseia sobre a fragmentação do documento HTML em diversas partes, que são manipuladas pelos usuários de acordo com os seus papéis como autores deste documento. Esses papéis definem os poderes de cada autor sobre cada fragmento do documento. Por conseqüência, os autores podem trabalhar nos seus fragmentos mesmo se sua conexão à Internet está caída [DEC 98a], [DEC 98b].A fragmentação utilizada pelo Byzance é 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 através de um mecanismo de call back, e também funções para a interface gráfica [DEC 98a], [DEC 98b], [QUI 99a].
Um documento no Thot é 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. Ao utilizar essa estrutura, o sistema Byzance divide seus documentos em fragmentos, que são distribuídas para o site de cada usuário. Essa divisão se dá de acordo com os papéis dos usuários, e por causa disso, somente um usuário do documento poderá modificar um fragmento a cada vez. Essa garantia de um único usuário escrevendo em um fragmento é obtida através de um esquema de cópias “master” e “slave” para cada fragmento. Esse esquema obriga a existência de uma única cópia master, no site do único usuário que pode modificar o fragmento, e muitas cópias slave, nos sites dos outros usuários do documento.
Este poder de modificar (escrever) um fragmento é dado pelos papéis
“manager” e “writer”. O papel “manager” pode ler e
modificar o fragmento, e ainda determinar os papéis dos outros co-autores,
enquanto o papel de “writer” pode apenas ler e modificar o fragmento.
Os outros papéis possíveis são “reader”, aquele que pode ler o
fragmento, e também o papel “null”, que não tem nenhum acesso ao
fragmento, nem de leitura nem de escrita. [DEC 98b], [SAL 98].
Cada co-autor tem um conjunto de papéis potenciais e um conjunto de papéis efetivos sobre cada fragmento do documento. Os papéis potenciais são definidos pelo manager do documento e representam todos os papéis possíveis que o co-autor pode interpretar, enquanto os papéis efetivos são os papéis efetivamente interpretados pelo co-autor. Durante a realização do trabalho cooperativo, os usuários (co-autores) podem mudar seus papéis efetivos de acordo com os seus papéis potenciais. Conseqüentemente, a fragmentação do documento pode ser modificada através de uma divisão ou união (merge) de fragmentos, de forma a adaptar o documento à regra de uma única cópia master de cada fragmento. Através desse mecanismo, vários co-autores podem escrever em fragmentos diferentes de um mesmo documento em um mesmo intervalo de tempo, utilizando o Byzance. [SAL 98]
O Byzance fornece um suporte à notificação, chamado “modo de consciência”. Este suporte permite que seus usuários controlem o ambiente de edição a fim de receber as notificações de modificação dos fragmentos. Esse suporte permite também que cada co-autor receba as notificações relativas às modificações efetuadas por seus colegas sobre os outros fragmentos. Ele foi concebido para facilitar a integração com o processo de edição, para simplificar sua manipulação, para refletir o estado da cooperação e ser eficaz na atualização dos fragmentos. [SAL 98]
Esse sistema de notificação permite aos co-autores regular seu próprio nível de notificação ao escolher entre as atualizações automáticas, abertas ou fechadas. Na primeira opção, as modificações realizadas por um colega em um fragmento são expostas na interface do usuário assim que estiverem disponíveis. Essa escolha não é equivalente à edição síncrona, pois poderá haver um atraso entre as modificações e a sua divulgação para os demais co-autores. No caso de uma atualização aberta, o usuário visualizará as modificações dos fragmentos apenas após requisitá-las voluntariamente. Finalmente, numa atualização fechada, o usuário não deseja ser advertido sobre as modificações em um fragmento, pois ele não deseja considerá-las durante seu trabalho.
Tanto a escolha do sistema de notificação quanto os papéis interpretados pelo usuário são mostrados graficamente através de ícones integrados à interface que são expostos no início de cada fragmento. Qualquer modificação, seja no sistema de notificação, seja no conjunto de papéis, é representada por ícones diferentes cuja transição (entre um ícone e outro) é definida através de um autômato finito. [SAL 98]
Uma conseqüência deste sistema de notificação utilizado pelo Byzance é que não existe um suporte a “past events awareness”. Não é possível saber, por exemplo, se um fragmento foi modificado várias vezes. Apenas é possível conhecer a última modificação sobre o fragmento, não as modificações anteriores. Como o Byzance tem essa 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 Byzance
Este trabalho introduziu no software Byzance 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 Byzance, 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 Byzance e o BW. Este módulo é estruturado em duas partes: um cliente e um servidor de awareness. O cliente trabalha diretamente ligado ao Byzance, 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 Byzance 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 do sistema.
O armazenamento e a leitura das informações neste sistema passa pelas seguintes fases:
- Quando o usuário concluir uma atividade (e por conseqüência, um evento é gerado), o Byzance 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;
- Quando o usuário pede uma notificação das informações de awareness, o Byzance 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.
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 que tem a permissão de escrita sobre o documento (papéis manager ou writer) pede o salvamento do fragmento após tê-lo modificado. É obrigatório que este fragmento tenha sido modificado pelo usuário, caso contrário o evento não será gerado. Por exemplo, se o usuário não modifica o documento e clica sobre a opção “Save Document” do Byzance, não será gerado nenhum evento. Além disso, estes eventos são ligados a cada fragmento, o que significa que cada fragmento do documento terá suas próprias informações de awareness. Quando um novo fragmento é identificado, ele é registrado no Byzance, e quando este fragmento for modificado e registrado, eventos correspondentes serão gerados. No entanto, se dois fragmentos são unidos (isto é possível quando uma tag que define o fragmento é removida), somente os eventos que são ligados ao primeiro destes fragmentos estarão disponíveis.
As informações de awareness sobre um fragmento, ao qual chama-se freqüentemente “o relatório de awareness”, contém o seguinte:
·Um título com o nome do documento e o número que identifica o fragmento;
·Uma seqüência de linhas que mostra as informações precisas sobre o fragmento:
oa data do armazenamento do fragmento;
oa máquina onde ele foi armazenado;
oo nome do usuário que fez o salvamento das informações do fragmento.
Com este primeiro evento, objetivou-se testar a inclusão do suporte à “past events awareness” dentro do Byzance. 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 Byzance 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 Byzance. 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 Byzance. Assim, basta clicar sobre a opção “Awareness” dentro do menu “Cooperation” (o suporte a awareness é uma parte muito importante para que a cooperação tenha sucesso). Como resultado, o sistema mostrará o relatório de awareness de um fragmento ativo em uma janela simples, construída com a biblioteca Thot. Considera-se como fragmento ativo aquele fragmento onde o cursor está posicionado, e o usuário pode facilmente mudar o fragmento ativo apontando para outro fragmento.
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 (read), as funções não bloqueantes, as quais, no caso de falha de comunicação não bloqueiam o processo, permitindo novas tentativas. Por outro lado, utilizou-se funções bloqueantes para enviar as informações (write). Isso significa que o processo irá esperar até que seja obtida uma resposta confirmando a transmissão. Por conseqüência, 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 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 començ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 attributs "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 Byzance
Para incluir o módulo de awareness no Byzance, 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 Byzance são detalhadas abaixo.·Esquema EDITOR.A :Inseriu-se neste esquema a opção "Awareness" no menu "Cooperation", causando a inserção desta mesma opção no aspecto visual do Byzance.
·Arquivo managerSheet.c:adicionou-se neste arquivo a função "AWGetFragmentID", a qual retorna a identificação do fragmento atual.
| int AWGetFragmentID
() { int
fragmentIndex; ... return(aFragId
(fragmentIndex).g_FragId); } |
·Arquivo EDITORactions.c : neste arquivo, inseriu-se a função "AwSaveDoc", a qual mostra o relatório de awareness. A inserção desta função também causou a inserção de algumas bibliotecas ("stdio.h", "base.h" e "document.h").
| /* Telecken: include for I/O file:w
*/ #include
<stdio.h> /* Telecken:
include for get username,url,etc */ #include
"base.h" #include "document.h" ... #ifdef
__STDC__ void AwSaveDoc
(Document document, View view) #else /*
__STDC__*/ void AwSaveDoc
(document, view) Document
document; View
view; #endif /* __STDC__*/ { ... } |
·Arquivo documentOpen.c : neste arquivo, inseriu-se no fim da função "DocumentSave" uma chamada à função "AwSendSaveDoc". Esta chamada ocorre após o salvamento do document e vai acionar o socket de comunicação com o BW.
| #ifdef __STDC__ T_bool
DocumentSave (Document document) #else /*
__STDC__*/ T_bool DocumentSave (document) Document
document; #endif /*
__STDC__*/ { ... if
(newProducedDocumentVersion){ signalModifiedDocToRemoteSites (curDocIndex); AwSendSaveDoc (document); } ... } |
Todos os códigos específicos do lado cliente do módulo de awareness estão limitados a um único arquivo (awareness.h), no diretório "opera/byzance/awareness". Neste arquivo, encontram-se todas 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
|
|
|
|
AwSendSaveDocument
AwCallSaveDoc |
Estas funções buscam as informações importantes do Byzance e as
repassa à função AwExecSaveeDocument.
|
|
AwExecSaveDocument
|
Esta função gera a comunicação TCP/IP entre o cliente e o servidor
quando um evento "Save Document" ocorre.
|
|
AwExecCallSaveDoc
|
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 Byzance, alterando-se o arquivo "makefile" (no diretório "/opera/byzance/byzance"), a fim de introduzir estas modificações e o novo módulo de awarenes. Introduziu-se o diretório "opera/byzance/awareness" na lista de diretórios de bibliotecas, e introduziu-se também uma regra para a compilação do módulo de awareness. Estas modificações estão detalhadas abaixo :
| Arquivo:
opera/byzance/makefile
INCL_DIR = -I.
-Ibyzance ... -Iawareness
-I/home/byzance/opera/Amaya/LINUX-ELF/libwww ... $(OBJ_DIR)/Awareness.o:
awareness/Awareness.c $(CC) $(PROF)
$(FLAGS_CC) $(INCL_DIR) -c awareness/Awareness.c mv Awareness.o
$(OBJ_DIR) $(COMMANDS) ... ALL_OBJ =
$(OBJ_DIR)/AHTBridge.o $(OBJ_DIR)/AHTEvntrg.o \ ... $(OBJ_DIR)/ANNOTnotif.o
$(OBJ_DIR)/ANNOTutils.o $(OBJ_DIR)/Awareness.o ... ANNOT_OBJS =
$(OBJ_DIR)/ANNOTlink.o \ ... $(OBJ_DIR)/Awareness.o
\ $(OBJ_DIR)/ANNOTnotif.o |
Por causa destas modificações introduzidas no Byzance, determinou-se 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 é produzido, o Byzance ativa as funções (por exemplo, a função AwSendSaveDocument), as quais capturam as informações necessárias do Byzance e as repassam para as funções geradoras (por exemplo, a função AwExecSaveDocument). Estas funções geradoras 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 Byzance, neste momento, ativa uma função que captura as informações necessárias a este processo, e as repassa às funções geradoras. 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 "AwSaveDoc".
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, 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 Byzance e o BW na 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) do lado cliente no Byzance, as tratara e passara o resultado para o framework BW. Este mediador foi baseado em uma outra implementação de um mediador (veja em Pinheiro [PIN 01a]), sobre a qual foram feitas as modificações necessárias para a utilizar neste caso. Esta seção descreve estas 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 Byzance.
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 Byzance. Primeiramente, substituiu-se as definições dos eventos da antiga aplicação para a definição do evento teste ("SAVEDOCUMENT") desta aplicação. Também se apagou algumas constantes e modificou-se os valores de algumas outras.
Além disso, modificou-se alguns métodos da classe. Alterou-se 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.
Introduziu-se também novos métodos, os quais são essencialmente destinados ao tratamento da comunicação por sockets com a ferramenta cooperativa Byzance. Estes métodos incluem aqueles que tratam as informações que chegam do cliente, como, por exemplo, os métodos "AwtratarBeginEvent", "AwtratarEndEvent" e "AwtratarGetEvent", os quais tratam os comandos BEGINEVENT, ENDEVENT e GETEVENT, respectivamente. Os novos métodos também incluem aqueles auxiliares, como os métodos "AWBuf" e "AWWriteBuf", que ajudam no tratamento do comando GETEVENT. Os principais métodos incluídos são descritos na tabela 3.
Tabela 3 Os mais importantes métodos introduzidos no
mediador
|
|
|
|
AWtratarBeginEvent
|
Este método recebe a string do socket (comando
BEGINEVENT), a transforma em um objeto BW_Event (evento), e
assinala o início de um evento.
|
|
AWtratarEndEvent
|
Este método recebe a string do socket (comando
ENDEVENT), a transforma em um objeto BW_Event (evento), e
assinala o fim deste evento.
|
|
AWtratarGetEvent
|
Este método recebe a string do socket (comando
GETEVENT), e solicita os eventos passados para o
framework BW.
|
|
AWBuf
|
Este método auxilia o método AwtratarGetEvent, organizando as
informações dos eventos lidos.
|
|
AWWriteBuf
|
Este método auxilia o método AwtratarGetEvent, enviando as
informações dos eventos.
|
Como o mediador atua, no caso do Byzance, como servidor de awareness (ou como o lado servidor deste módulo, como foi chamado aqui), ele deve se disparar sozinho. Por causa disto, incluiu-se o método "main" no mediador, transformando este de uma simples classe em uma aplicação Java. Esta aplicação executará antes mesmo que a ferramenta cooperativa, e não irá parar quando esta ferramenta cessar suas atividades.
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 Byzance envia as informações através do canal de comunicação TCP/IP, estas são recebidas pelo mediador por um de seus fluxos de controle, e elas são tratadas por funções específicas (por exemplo, a função "AwtratarBeginEvent"). Em geral, estas funções específicas dividem a string recebida pelo socket de comunicação, e tratam cada informação individualmente. Este tratamento inclui a transformação destas informações nos objetos esperados pelo framework BW.
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, e para cada evento recuperado, ela manterá, com ajuda das funções auxiliares ("AWBuf" e "AWWriteBuf"), as strings de resposta e as 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 Byzance.
A interface com o usuário é um aspecto muito importante para o bom funcionamento do suporte a awareness. No framework BW, esta interface é definida de forma abstrata pelas interfaces Java "UI_GUIElement" e "UI_GUIEvent".Estas são implementadas pelo próprio mediador, pois a apresentação gráfica não é definida pelo servidor de awareness, o qual conversa com o framework BW. Esta apresentação é definida no lado cliente, junto ao Byzance, à 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 Byzance 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 Byzance. Este demonstrou, também, uma capacidade de expansão, apesar de sua grande complexidade.Esta capacidade de expansão do Byzance poderá permitir melhoramento do suporte a "past events awareness". Poder-se-á, por exemplo, introduzir 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 Byzance 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 "Byzance_AW" (Byzance Awareness & Workflow), poderá ser utilizada para a concepção cooperativa de hiperdocumentos para o ensino à distância.
9 Bibliografia
·[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).
·[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)