6 Protótipos Desenvolvidos
6.1 Shared Workspaces: Compartilhamento de Área de Trabalho
Os collablets, desenvolvidos para compartilhamento de área de trabalho, implementam mecanismos síncronos de percepção voltados para a coordenação de visualização colaborativa em espaços de trabalho compartilhado (GUTWIN e GREENBERG, 1999). Três collablets (teleapontador, janela em miniatura e bate-papo) foram acoplados ao ambiente de desenvolvimento Odyssey (WERNER et al., 2000), formando a base para a proposta do ambiente colaborativo síncrono do OdysseyShare (WERNER et al., 2002). O ambiente Odyssey visa prover uma infra-estrutura de apoio à reutilização baseada em modelos de domínio. A reutilização de software no ambiente
Odyssey ocorre através dos processos de Engenharia de Domínio, cujo objetivo é
construir artefatos reutilizáveis voltados para problemas de conhecimento específico, e de Engenharia de Aplicação, que tem o objetivo de desenvolver aplicações reutilizando esses artefatos. O Odyssey oferece o conjunto de aplicações sobre as quais se deseja aumentar o potencial para a colaboração. Essas aplicações incluem diversas ferramentas específicas para o desenvolvimento de software, tais como editores gráficos para diversos tipos de diagramas com apoio para rastreabilidade, aplicação de padrões e críticas. No ambiente, estão disponíveis uma máquina de processos (MURTA, 2002) e um repositório de componentes (SOUZA et al., 2001) que apóiam outros aspectos de colaboração.
Dois collablets oferecem informações de percepção do espaço de trabalho e um terceiro apóia a comunicação entre os participantes. O ambiente resultante oferece apoio para a visualização colaborativa de artefatos e para a comunicação direta entre os participantes (Figura 6.1).
Figura 6.1 Collablets no OdysseyShare SDE: bate-papo, teleapontador e janela em miniatura (MANGAN et al., 2002b).
O usuário poderá visualizar sobre a área das janelas de aplicação o indicador do dispositivo apontador remoto e o cursor de edição remoto de um ou mais usuários. Teleapontadores, cursores de edição e outras decorações e sinais sobrepostos são
collablets, ou seja, componentes de software independentes.
O usuário tem a liberdade de selecionar nenhum, um, dois ou três dos
collablets disponíveis. Durante a visualização colaborativa, o usuário percebe um atraso
característico de aplicações distribuídas devido às condições de latência e banda da rede de computadores. Ainda, um ligeiro atraso no processamento é observado, visto que o processador local estará encarregado de parte do trabalho necessário para manter o registro, a interpretação de eventos e a transmissão de mensagens.
A versão inicial do protótipo exigia alterações mínimas no ambiente Odyssey original. Em termos de alterações no código, apenas duas classes (dentre as mais de 600 classes que compõem a aplicação) foram alteradas, com um total de apenas cinco linhas de código incluídas (Figura 6.2). A alteração foi realizada por um programador que não tinha conhecimento prévio do código da aplicação, com base em um processo de
depuração manual da execução da aplicação. Basicamente, as alterações são necessárias para controlar a ativação dos componentes e a integração com os menus da aplicação.
1. Workspace w = new Workspace(); 2. w.setJFrame(this);
3. w.setJScrollPane(sp); 4. w.setup();
5. w.setActive(true);
Figura 6.2 Alterações no OdysseyShare (Classe WinModelagem, linguagem Java).
Os collablets são resultado de um esforço em tornar mecanismos de apoio à colaboração síncrona em componentes de software (MANGAN et al., 2002).
O editor de textos Stylepad é uma outra aplicação que foi alterada com o uso da abordagem apresentada. A alteração de uma segunda aplicação tem como objetivo demonstrar a independência dos collablets em relação ao Odyssey. O Stylepad foi utilizado, também, como protótipo da tese de Begole (1998), com a proposta da Colaboração Transparente Flexível (CTF). Os resultados obtidos na visualização colaborativa são semelhantes na CTF e na ACT. A CTF permite realizar a edição colaborativa síncrona, que foi prevista, mas não implementada na ACT.
Entretanto, a CTF de Begole não pode ser combinada com outra proposta. A CTF substitui objetos da biblioteca Swing por versões colaborativas desses objetos. A ACT utiliza a notificação para acrescentar comportamento aos objetos, sem substituí- los. A vantagem da ACT é que vários mecanismos podem coexistir sobrepostos, sem que a inclusão de um novo collablet remova um collablet existente.
Nas duas aplicações, a coleta é realizada por meio do sistema de janelas. Entretanto, além do desenvolvimento do coletor, é necessário escolher um meio para transferir a informação coletada de uma estação para outra. O sistema de eventos e notificação foi implementado com o uso da tecnologia Jabber (ADAMS, 2002). A função principal desse mecanismo é a realização de comunicação através de mensagens de texto. A possibilidade de extensão desse mecanismo permite a criação de mensagens contendo semântica bem definida, representada por marcações na mensagem.
O formato de representação é adequado para a identificação dos elementos semânticos da mensagem, mas pode não ser adequado ao processamento dos eventos da edição. Principalmente, porque a representação é realizada na linguagem de marcação extensível (Extensible Markup Language - XML) que ocupa um espaço e um tempo adicional para a criação e processamento das mensagens, se comparada com
alternativas, tais como, objetos distribuídos e comunicação via soquetes (sockets). A principal limitação atual desse mecanismo de troca de mensagens é em relação ao processamento eficiente de um alto volume de mensagens. Essa limitação está sendo resolvida com os avanços no processamento de XML. Entretanto, o uso de XML não é adequado para o processamento de informações em formato binário como imagens, som e vídeo. Nesses casos, a comunicação foi implementada através de um canal independente.
A principal vantagem no uso de XML é a facilidade de conversão dessas informações para outros formatos que permitam acesso a sistemas de inferência, mineração de dados, processamento estatístico e visualização de grandes volumes de dados.
No ambiente OdysseyShare, a comunicação é apoiada basicamente por mensagens instantâneas semi-estruturadas. Considera-se interessante o uso associado de áudio e vídeo-conferência. Entretanto, as mensagens de texto oferecem maiores facilidades à busca de informação.
No contexto de troca de mensagens, cada mensagem contém a indicação do remetente, destinatários, conteúdo, ordenação na seqüência de mensagens. O servidor
Jabber realiza o roteamento de mensagens com base nas informações contidas na
mensagem. Um cliente Jabber apresenta as mensagens recebidas e interage com o usuário por meio de uma interface de bate-papo convencional.
A representação em XML permite que a mensagem transporte marcações semânticas adicionais. Por exemplo, uma mensagem pode ser marcada como uma “pergunta” que aguarda uma mensagem específica marcada como “resposta”. Essas marcações facilitam a construção de mecanismos sofisticados de troca de mensagens que operam sobre uma mesma rede de comunicação. Para interpretar as mensagens corretamente, os clientes em cada ponta devem extrair as marcações do corpo da mensagem. As marcações que não são processadas pelos clientes são ignoradas, sem prejuízo para a comunicação. Através dessas marcações, é possível criar grupos de discussão e aninhamento de assuntos.
A tecnologia Jabber é compatível com diversos sistemas de mensagens populares como o MSN Messenger, Yahoo!Messenger e ICQ. A compatibilidade permite a troca de mensagens e a operação por um participante que tenha um cadastro
válido em qualquer desses sistemas. Essa característica contorna um dos principais problemas de um sistema de mensagens que é o estabelecimento de uma massa crítica de usuários. Além disso, os usuários ficam livres para utilizar o sistema de mensagens de sua preferência.
A áudio e video-conferência são realizadas com o uso de componentes de software compatíveis com o protocolo de vídeo-conferência H.323 (ITU, International
Telecommunication Union, 2003). Os clientes utilizados em testes foram o Windows
NetMeeting, CuSeeMe e Gnome Linux GnomeMeeting acionados através de uma
marcação específica enviada através do protocolo Jabber e interpretada pelo cliente
Jabber. Os demais clientes (ICQ, CUSeeMe) devem iniciar a aplicação de vídeo
conferência manualmente. As desvantagens da vídeo-conferência são: (a) o consumo de recursos (capacidade de processamento, banda de rede e espaço para armazenamento) e (b) a distração introduzida pela riqueza das mídias de áudio e vídeo.
Durante a operação do protótipo, percebeu-se a utilidade do uso de marcações especiais para sinalizar o estado do participante durante a sessão, similar aos ícones que demonstram emoções (smiles, emoticons) em programas de bate-papo. As marcações indicam dúvidas, permissão para falar, controle do ambiente, ação em andamento e confirmação de atenção concentrada e outras sinalizações que auxiliam a conduzir a participação durante a sessão. Notou-se, também, a possibilidade de uso de marcação para indicar perguntas, respostas e outros modificadores que facilitem a organização das mensagens.
As mensagens são ordenadas e ficam registradas como parte da memória do grupo. As discussões ficam associadas aos artefatos e outros elementos do contexto colaborativo que envolve as ações de cada usuário. Pode-se utilizar um dos elementos desse contexto para recuperar essas mensagens em um momento posterior. De forma similar, mensagens podem ser colocadas no ambiente como se fossem anotações.
O canal de comunicação com base em mensagem pode ser utilizado como forma de interação entre o apoio à colaboração e ao participante. Espera-se que a inserção de mensagens no contexto da conversa possa ser útil para adicionar informação relevante ao contexto. Considera-se, ainda, possível que os participantes possam utilizar um vocabulário restrito para solicitar informações ao sistema de apoio a colaboração. Por exemplo, a frase “Quem criou o artefato Contrato?” poderia ser usada para
recuperar um dos atributos do artefato durante a colaboração. O uso dessa forma de interação pode ter aceitação variável entre os usuários. Esperamos que a prática do ambiente auxilie a determinar fatores que indiquem a preferência individual para o recebimento de notificação. Apesar da facilidade da implementação e uso de serviços de comunicação com base em mensagens, a sua aplicação deve considerar os problemas que podem ser ocasionados pelas dificuldades de interpretação dos participantes (PIMENTEL et al., 2003).
Informações de percepção básicas como a presença e a disponibilidade de um participante são oferecidas como parte do mecanismo de comunicação. O monitoramento da interface de usuário das aplicações gera informações de percepção mais detalhadas sobre o volume de atividade e o foco do interesse dos demais participantes. Essas informações combinadas permitem determinar quem está presente no ambiente colaborativo e qual a visão que cada um possui sobre o ambiente. O
OdysseyShare captura e apresenta informações sobre o espaço de trabalho dos
participantes usando os eventos da Tabela 6-1.
Tabela 6-1 Eventos básicos da arquitetura de colaboração transparente (modelo de percepção de espaço de trabalho).
EVENTO Parâmetros
MOVE_VIEWPORT Point p1, Point p2
SELECT_VIEW ID
MOVE_POINTER Point p
RESIZE_VIEWPORT Dimension d
RESIZE_VIEW Dimension d
Os eventos são coletados no sistema de janelas do ambiente de execução da plataforma Java, processados e introduzidos de volta ao ambiente através de mecanismos de percepção específicos como o teleapontador e a janela de radar.
Aplicações de compartilhamento de tela, como o Microsoft NetMeeting, são normalmente utilizadas neste tipo de estudo para comparar o desempenho do apoio proposto com um sistema genérico. No nosso caso, problemas técnicos impossibilitaram essa comparação, pois a aplicação implementada em Java não pode ter sua tela
compartilhada, ao menos na versão do NetMeeting disponível na época. A justificativa era de que a plataforma Java possui um sistema de janelas independente do usado pelo ambiente operacional Microsoft Windows. Além disso, o protótipo consegue operar em plataformas heterogêneas (ex. Microsoft Windows e Red Hat Linux). Com isso, a observação se restringe à caracterização do uso dos componentes de compartilhamento de área de trabalho.
As alterações realizadas no ambiente de execução consideram apenas a captura de eventos de interface (Figura 6.3). Os eventos são coletados a partir do sistema de janelas utilizado pela aplicação, o que garante a transparência por parte do programador da aplicação.
Application UI
Component UI
Windowing system run-time
<<remote>>
Component
Model
<<local>>
Component
Model
Component Communication
UI events
Figura 6.3 Versão preliminar da ACT (MANGAN, WERNER, BORGES, 2002).
Com base nessa versão preliminar, foram obtidos protótipos operacionais que oferecem os serviços de comunicação, visualização colaborativa de diagramas e percepção em espaços compartilhados.