Trabalhos Relacionados

transparência de Begole (1998), pela adoção de interpretação de eventos proposta por Li e Li (2002). A interpretação de eventos permite obter uma descrição do significado dos eventos compartilhados. Na proposta de Li e Li, o significado dos eventos é utilizado para promover o compartilhamento de aplicações heterogêneas. Na ACT, a interpretação é utilizada para promover serviços de coordenação e colaboração assíncronas. Com isso, pretende-se oferecer um espectro mais amplo de apoio adequado para as necessidades do desenvolvimento de software globalizado, onde os participantes precisam trabalhar em diferentes modos de colaboração.

A proposta de collablets permite que a ACT seja ampliada através da programação de novos mecanismos. Li e Li propõem o treinamento na interpretação de eventos. A arquitetura de implementação da ACT adota o uso de sensores nas estações clientes. Nesse sentido, a implementação é similar a usada no Palantír (SARMA et al., 2003). Porém, a interpretação dos eventos e dos objetos não é reproduzida dentro de um servidor. Na ACT, toda a interpretação é realizada nas estações de trabalho, o que facilita a interpretação de novos eventos e objetos sem a necessidade de interferir na implementação da ACT.

Neste trabalho, o apoio se destina aos usuários cuja principal tarefa colaborativa é o compartilhamento de editores gráficos. Os visualizadores considerados são aplicações capazes de apresentar diagramas bi-dimensionais, onde o conhecimento necessário para o entendimento do software está semi-formalizado. Diagramas são o principal instrumento de comunicação entre desenvolvedores e a maior parte das discussões de alto-nível, que envolvem criatividade e incerteza, ocorrem sobre esse tipo de representação.

Além disso, o conhecimento proveniente de diversas fontes é explicitado nos diagramas, o que pode levar a uma maior necessidade de colaboração nesse tipo de documento. Outros tipos de documento podem ser compartilhados, bastando para tanto que se estude o mapeamento das informações de seu visualizador para o modelo da ACT. Cada classificador da UML (classe, pacote, estado, caso de uso) é mapeado como um “objeto” nos modelos da ACT, as propriedades da UML são mapeadas para “propriedades” da ACT e os relacionamentos são mapeados para “relações”. A UML oferece um modelo mais detalhado que o da ACT. Mantendo o modelo da ACT genérico podemos definir diversos outros mapeamentos. Por exemplo, o modelo da

ACT pode ser usado para representar informações como “Marcos criou a classe 'Fornecedor'”, com base em um mapeamento dos elementos da UML, mas também pode afirmar que “Antônio apagou o arquivo Y” com base em outro modelo que considere um modelo de sistema de arquivos.

O modelo de percepção de Rodden descreve um grafo onde os nodos representam objetos e as arestas representam relações entre os objetos. Existe uma função r(o1, o2) que determina a correlação c entre dois objetos, onde c varia entre 0, para objetos não relacionados, até 1, para objetos fortemente relacionados (RODDEN, 1996). O modelo de Rodden é muito utilizado como base para outros modelos de percepção. A função r no modelo de Rodden pode ser comparada as análises de impacto de mudanças exploradas no Palantír (SARMA et al., 2003). No caso da ACT, a função r pode ser definida de diversas maneiras. Ou seja, uma mesma coleção de objetos e eventos pode gerar interpretações diferentes. O modelo da ACT oferece a oportunidade de definir uma relação r com base em diversos critérios. Por exemplo, podemos utilizar o conceito de relação para determinar uma função r1 que considera a estrutura estática de classes definidas através de relações ou propriedade da ACT e uma função r2 que calcule o (inverso) do número de operações realizadas no ambiente entre a última operação sobre o objeto o1 e a subseqüente operação sobre o objeto o2. A definição de

r1 seria adequada para avaliar o impacto sobre alterações em um diagrama. A definição

de r2 poderia ser utilizada para avaliar a correlação entre as definições de dois objetos. A ocorrência de operações conjuntas freqüentes sobre um grupo de objetos pode revelar uma dependência semântica que não é evidente pela estrutura estática das classes.

A plataforma de agentes CUMBIA (MORENO et al., 2003) explora a possibilidade da utilização de informações coletadas na área de trabalho de computadores pessoais como forma de promover colaborações oportunísticas. A coleta das informações ainda não está totalmente definida na CUMBIA, mas a abordagem de gestão de conhecimento a partir da coleta de informações das aplicações guarda alguma semelhança com a proposta do histórico da ACT.

Algumas características descritas na ACT podem ser encontradas em outros sistemas. Sistemas que avaliam a usabilidade de interfaces também utilizam coletas de eventos de interface (YVORY e HEARST, 2001). A interpretação de eventos de entrada em eventos de aplicação é uma técnica utilizada para reduzir o espaço necessário para

registrar a operação da aplicação por parte de um usuário. Sistemas de colaboração com base em comunicação, como o Babble (ERICKSON e KELLOG, 2000), baseiam a coordenação nas áreas compartilhadas em protocolos sociais. Sistemas de recomendação podem utilizar informações sobre o histórico do usuário para encontrar preferências e indicar outros objetos similares (CLAYPOOL et al., 2001). Ambientes colaborativos voltados para o ensino, como o AgentSheets (REPENNING et al., 2001) adotam a possibilidade de configuração por parte do usuário sem a necessidade de um programador. Os ambientes evoluem com a adição de novos componentes de aprendizado, mediante programação. Percepção com base em memória de eventos é explorada em sistemas como o POLITeam (MARK e BORDETSKY, 1998). As informações são coletadas durante o uso das aplicações com o monitoramento combinado de eventos ocorridos nos dispositivos de entrada (teclado e mouse) e no ambiente de execução das aplicações. O monitoramento das ações de um usuário para a captura de seu processo de trabalho é uma prática proveniente de repositórios ativos (YE e FISCHER, 2000).

A proposta da arquitetura Clover (LAURILAU e NIGAY, 2002) é fundamentada em três conceitos: comunicação, coordenação e produção (communication, coordination e production). O conceito de produção se refere à área compartilhada, onde estão os objetos criados (produzidos) pelos usuários. Laurillau e Nigay advogam que uma arquitetura de groupware deve buscar o equilíbrio entre esses três conceitos. A Clover é uma arquitetura conceitual, a ACT pode ser caracterizada como uma arquitetura de implementação coerente com os conceitos da Clover.

As facilidades de extensão da ACT são similares as do framework ANTS (LÓPEZ e SKARMETA, 2003). Serviços de percepção, modelo de componentes e a integração com middleware existente são três das características do ANTS que se assemelham a esta proposta. Entretanto, as extensões no ANTS se referem ao apoio à colaboração. O ANTS oferece uma biblioteca para a programação de aplicações colaborativas. Por outro lado, a similaridade da ACT com o ANTS poderia indicar que a implementação da ACT poderia ser realizada, em parte, com o uso deste framework. Com isso, seria possível concentrar o desenvolvimento da interpretação de eventos. Este ponto ainda está para ser investigado. Outra arquitetura similar ao ACT é a WWG (MARQUÈS e NAVARRO, 2001). A WWG é aplicada na construção de ambientes de

ensino e oferece mecanismos de percepção assíncronos. A difusão de eventos da WWG é muito similar a da ACT. A infra-estrutura da WWG baseia-se na extensão WebDAV (WEBDAV, 2003).

5.8 Conclusão

Os elementos da ACT apresentam responsabilidades que favorecem a implementação de edição colaborativa, mecanismos de informação de percepção e obtenção de perfil de usuário. A ACT descreve uma família de ambientes colaborativos similares e uma mesma implementação com base na ACT poderia ser adaptada para uma mesma implementação pode atender a diversos cenários concretos. Como princípio, a ACT é não intrusiva, tanto na aplicação legada, quanto no modo de trabalho do usuário da aplicação. Entretanto, a aplicação da ACT é restrita a colaboração que evolui a partir do modelo individual de trabalho e que depende de baixa coordenação implementada pelo ambiente, ou seja, na mediação. Mecanismos de coordenação mais eficientes podem ser implementados através de protocolos sociais ou de extensões colaborativas que atuem sobre os históricos antes que os eventos sejam difundidos.

A ACT ainda descreve papéis e distribui responsabilidades para diversos perfis de desenvolvedores. Através dos papéis a programação de mecanismos de colaboração pode ocorrer em paralelo com a evolução das aplicações. A integração das aplicações e a configuração dos ambientes colaborativos são distribuídas entre os próprios usuários do ambiente.

Na ACT, o custo da obtenção de eventos é único, ou seja, a coleta por um mecanismo de um evento de entrada requer o mesmo esforço que o da coleta de uma ação semântica por parte do usuário. Com isso, espera-se incentivar a criação de novos mecanismos de colaboração. A programação de novos mecanismos requer o aprendizado de uma API reduzida e da lista de eventos catalogada no ambiente.

Por fim, o histórico da ACT facilita a avaliação das possibilidades de apoio à colaboração, antes da construção de um groupware através da obtenção de métricas sobre a geração dos eventos (baseline). Após a introdução do apoio à colaboração, é possível continuar monitorando o trabalho e verificar o impacto das alterações. Esse potencial para a observação do trabalho individual e em grupo pode levar a um