Especificação de Componentes de Software em Sistemas Colaborativos

Transcrição

1 Especificação de Componentes de Software em Sistemas Colaborativos Marco A.S. Mangan 1,2, Claudia M.L. Werner 1, Marcos R.S.Borges 3 (mangan@inf.pucrs.br, werner@cos.ufrj.br, mborges@nce.ufrj.br) Programa de Engenharia de Sistemas e Computação COPPE/UFRJ 1 Faculdade de Informática PUCRS 2 Depto. de Ciências da Computação/IM e Núcleo de Computação Eletrônica UFRJ 3 Abstract Computer Supported Cooperative Work has emerged as an application domain defining collaborative systems, their services and applications. As the need for collaboration support within other domains increases, it is necessary to provide means for the systematic reuse of collaborative service components to extend legacy systems or to facilitate the design of new systems. In this work, we present a software component specification composed of collaborative domain features, component architecture, and finally a description of relevant component features. This specification contributes to organize information required for component cataloguing and adoption. Therefore, we demonstrate how collaborative services can be decoupled from a collaborative system promoting reuse of services design and implementation. Palavras-chave: Desenvolvimento com Base em Componentes, Reutilização, Especificação de Componentes, Domínio de Aplicação, Sistemas Colaborativos, Groupware, CSCW. 1 Introdução Pessoas trabalham melhor quando se associam em grupos. Nas últimas décadas, a área de Trabalho Cooperativo Apoiado por Computador (Computer Supported Cooperative Work - CSCW) [1] tem estudado as relações entre o apoio de programas de computador criados para apoiar o trabalho de grupos (sistemas colaborativos ou groupware) e a organização de trabalho em um grupo ou entre grupos de usuários. CSCW é considerado um domínio de aplicação pelos especialistas da área devido a complexidade das relações que foram encontradas e pela diversidade de famílias de groupware existentes [1]. Um groupware típico oferece diversos serviços de colaboração adaptados para uma tarefa específica ou perfil de usuários. Tais serviços aparecem de forma recorrente entre os sistemas, sendo possível identificar características comuns em quantidade suficiente para justificar a sua reutilização. Neste contexto, a aplicação de técnicas de desenvolvimento baseado em componentes (DBC) é fundamental para facilitar a reutilização sistemática de decisões de projeto, arquitetura e implementação desses serviços. Neste trabalho, apresentamos uma especificação de componentes que contribui para a identificação de serviços recorrentes em editores colaborativos. A especificação é realizada considerando uma divisão entre Engenharia de Domínio (processo de desenvolvimento para reutilização) e Engenharia de Aplicação (processo de desenvolvimento com reutilização), seguindo a proposta de Werner e Braga [8]. CSCW é caracterizado como um domínio de aplicação secundário (co-domínio) que aparece associado, na Engenharia de Aplicação, com um domínio principal tal como ensino, finanças ou mesmo desenvolvimento de software. A especificação apresentada contempla dois serviços clássicos de visualização colaborativa: o teleapontador e a visão de radar. As informações do domínio de CSCW utilizadas na especificação dos componentes são, em sua maioria, provenientes dos trabalhos sobre percepção e do levantamento de serviços de CSCW de Greenberg et al. [3]. A arquitetura dos componentes adota a colaboração transparente proposta por Begole et al. [2].

2 A descrição dos componentes é realizada através da classificação de características proposta por Yacoub et al. [4]. A definição dos termos relacionados com componentes tem por base a proposta de nomenclatura de Griss [6]. Os componentes podem ser implementados de diversas formas com diferentes tecnologias. Uma implementação dos componentes na plataforma Java é parte integrante do ambiente para desenvolvimento cooperativo de componentes denominado OdysseyShare [9]. A implementação não é tratada em detalhes neste artigo. O restante deste artigo está organizado da seguinte forma. Primeiro, os serviços teleapontador e visão de radar são brevemente descritos no contexto de CSCW (Seção 2). O processo de engenharia de domínio é apresentado, destacando o modelo de domínio criado (Seção 3), a arquitetura dos componentes (Seção 4) e a caracterização dos componentes (Seção 5). Finalmente, a Seção 6 apresenta as conclusões deste artigo. 2 Serviços em CSCW Em uma sessão de edição colaborativa em tempo real, componentes de percepção transferem informação sobre o espaço de trabalho local aos demais participantes, aumentando sua percepção das ações dos outros usuários (Figura 1). Essa informação auxilia aos participantes coordenar suas atividades sobre o documento. Figura 1 - Teleapontadores e visão de radar sobre um diagrama de classes da UML no ambiente OdysseyShare [9]. A visão de radar (radar view) é um serviço de percepção comum em editores gráficos e textuais que auxilia a determinar a posição corrente de edição em um documento grande. Por exemplo, programas como Acrobat Reader, Aladdin Ghost View e Microsoft PowerPoint implementam esse serviço. No contexto de groupware, a visão de radar exibe informações sobre o posicionamento tanto do usuário local como dos demais usuários do grupo. O teleapontador (telepointer) apresenta a posição do cursor do mouse, ou de outro dispositivo de indicação, de cada usuário no grupo. Teleapontadores são populares em teleconferências, mas são vistos raramente fora do contexto de groupware. A identificação dos componentes parte da premissa que é possível realizar alguns dos serviços de colaboração isolando o código dos componentes do restante do código da aplicação. Cada componente realiza uma separação de interesses (concerns), uma segmentação vertical que realiza completamente o serviço. Essa segmentação acarreta a

3 definição de uma interface de usuário (visual component) que determina um contrato de especificação com o usuário, que inclui aspectos como documentação (end-user help), internacionalização e estilo de interface. Existem diversas variações do componente de visão de radar (como janelas em miniatura, olhos-de-peixe e janela sobreposta) e do componente teleapontador (como múltiplos cursores, cursores semânticos e cursores compartilhados) [3]. As variações apresentam refinamentos sobre um mesmo componente básico. No caso do radar, os refinamentos incluem manipulações gráficas sofisticadas na apresentação da informação ao usuário e, no caso do teleapontador, os refinamentos exploram informações mais precisas sobre a semântica dos objetos apontados pelo mouse ou um controle de concorrência mais flexível. A implementação atual adota janelas em miniatura e cursores múltiplos, pois servem como base para as demais variações. 3 Engenharia de Domínio em CSCW Segundo o processo de Engenharia de Domínio proposto por Werner e Braga [8], o domínio de aplicação sendo considerado deve ser representado através de um modelo de domínio. A representação desse modelo utiliza características (features) conceituais e funcionais que podem ser utilizadas como índice ou como forma de concentrar as discussões nesta ou naquela característica. Esse modelo é representado através de uma notação gráfica que forma um grafo de conceitos ou um hipertexto manipulado através de um editor que permita a navegação entre as referências como por exemplo, o editor de modelo de domínios disponível no Odyssey SDE [7]. Em sua representação on-line, características podem estar associadas a outros elementos do modelo de domínio, aplicações modeladas e outros documentos, formando um hipertexto. Os serviços de colaboração são descritos em detalhes suficientes na literatura para que um engenheiro de software inicie a descrição do domínio. A ajuda de um especialista de domínio teria sido útil, mas nem sempre um especialista esteve à disposição. De qualquer forma, observa-se que o modelo de domínio não elimina a necessidade da consulta à literatura. Foram adotadas duas formas de descrição do domínio de aplicação neste trabalho. Primeiro, a descrição do vocabulário corrente entre os autores estudados. Essa primeira forma facilita a comunicação com os especialistas, na identificação de requisitos e na introdução de questões típicas de CSCW como dinâmica de grupo, cognição e aspectos sociais da interação - reduzindo a importância de termos relacionados com a implementação dos sistemas. Por exemplo, a decisão da adoção em ambos componentes considera se os participantes de uma sessão de trabalho estão (a) operando em tempo real, (b) executam a mesma tarefa e (c) compartilham a mesma visão sobre a área de trabalho. A segunda forma, auxilia na enumeração e no entendimento das relações entre os serviços. Por exemplo, alguns serviços são mais indicados para esta ou aquela tarefa e outros são utilizados em conjunto. Durante a análise de diversos sistemas, observamos que o serviço teleapontador e o serviço de visão em radar aparecem associados na maioria dos sistemas em que ocorrem. Seu uso combinado é proposital, pois oferece um efeito positivo sobre os usuários do sistema colaborativo [3]. 4 Arquitetura dos componentes A arquitetura dos componentes é descrita em camadas (Figura 2). A primeira camada controla a apresentação de dados e captura a operação do usuário sobre a interface da aplicação. A camada intermediária armazena o estado de cada componente, que são resultantes dos eventos capturados. A camada inferior permite a distribuição de eventos através da rede, comunicando componentes em execução em diferentes estações de trabalho.

4 O modelo de componentes armazena dados coletados através dos eventos monitorados na interface de usuário. A camada de comunicação é responsável pela criação das sessões de trabalho e pela sincronização entre os dados no modelo de componentes local e suas cópias remotas. Em cada cópia remota, a interface de usuário dos componentes apresenta esses dados para o usuário. Dessa forma, os dados podem ser percebidos por todos os usuários. Windowing system run-time Application UI Component UI UI events <<local>> Component Model <<remote>> Component Model Component Communication Figura 2 Visão geral da arquitetura para colaboração transparente. O sistema de janelas (windowing system) é responsável pelo compartilhamento dos recursos do ambiente gráfico oferecido por uma plataforma. Modernos sistemas de janelas são frameworks que facilitam a criação de interface de usuário. Exemplos são: o X Windows, adotado em diversas plataformas, o Java Foundation Classes e os sistemas do Microsoft Windows e do MacOS que são incorporados no próprio sistema operacional. Todos os eventos de uma interface de usuário são manipulados pelo sistema de janelas. Tipicamente, uma aplicação monitora esses eventos e executa ações correspondentes. Na arquitetura apresentada, o componente monitora eventos de outras aplicações (movimento do mouse e da barra de rolagem) e envia esses eventos através da rede para apresentação na interface de um usuário remoto. Essa dependência com os sistemas de janelas não é um problema, visto que a maioria dos sistemas de janelas oferece funções similares. As interfaces externas do componente são definidas pelo sistema de janelas adotado, sendo suficientes para a captura desses eventos. A utilização do sistema de janelas como fonte de dados e controle evita que sejam necessárias maiores alterações na aplicação. As aplicações passam a trabalhar de forma integrada sobre a rede de computadores, criando um espaço de trabalho compartilhado entre diversos usuários [2]. Dessa forma, a adoção do componente tem um pequeno impacto no restante da aplicação, critério que pode ser decisivo na escolha do componente. 5 Caracterização dos componentes Do ponto de vista de catalogação e adoção, a classificação de características de componentes sugerida por Yacoub et al. [4] apresenta uma alternativa à descrição de interfaces dos componentes. 5.1 Descrição informal O contexto do componente como solução de um problema considera: idade (age), a especificação resume uma experiência madura na edição colaborativa, pois descreve diversos sistemas existentes. Por outro lado, a implementação disponível no OdysseyShare ainda não foi testada em outra aplicação concreta, o que revela uma baixa maturidade da

5 implementação. Origem (source), os componentes são resultado de um trabalho de pesquisa acadêmica. Desempenho, confiabilidade e correção da implementação encontram-se em níveis aceitáveis para uma prova de conceito. Nível de reutilização (level of reuse), a realização da descrição permite a reutilização em diversos níveis, principalmente, da especificação e, em menor escala, da implementação. Contexto (context), os componentes são apropriados para tarefas de edição ou visualização colaborativa em tempo real de documentos on-line, ou qualquer forma de texto ou diagrama que possa ser representado em uma interface de usuário, incluindo a própria interface. Intenção (intent), aumentar a disponibilidade de informações de percepção sobre a posição de edição atual e posicionamento do mouse entre os participantes de uma sessão de edição ou visualização. Componentes relacionados (related component), não existem componentes similares conhecidos. Entretanto, existem editores colaborativos que apresentam serviços similares. 5.2 Descrição Externa A descrição da relação do componente em relação a outros sistemas considera: interoperabilidade (interoperability), ambos operam em conjunto com a infra-estrutura de execução oferecida pelo sistema de janelas. Os eventos consumidos ou gerados pelos componentes podem ser compartilhados com outras aplicações com o uso de ouvintes (listeners). Portabilidade (portability), a arquitetura depende dos serviços de um sistema de janelas orientado a eventos no qual os componentes apresentam papéis ativos e passivos. Alguns componentes devem ser reescritos para diferentes plataformas. Papel (role). O papel ativo inclui a apresentação de dados para o usuário da aplicação e o envio de dados para os pares remotos. O papel passivo inclui a coleta de informações sobre o movimento do mouse e da posição da janela de edição local. Fase da integração (integration phase), a especificação do componente permite a adoção na fase inicial do projeto da aplicação, durante a decisão da adoção de serviços colaborativos e do planejamento da integração com interface da aplicação existente. A implementação integra-se durante a fase de desenvolvimento com a programação da conexão dos componentes com as janelas, as barras de rolagem e o controle do mouse da aplicação. Posteriormente, durante a execução, a implementação integra-se com o sistema de janelas e com a camada de comunicação através da rede de computadores. Framework de integração e tecnologia (integration framework and technology), o sistema de janelas é o framework de integração. A tecnologia utilizada tem como base características da programação orientada a eventos e da programação orientada a objetos. Características nãofuncionais (nonfunctional features), a autenticação de usuário e o acesso à rede de computadores exigem que a política de segurança da aplicação seja adaptada, para permitir a comunicação entre os componentes. Os componentes estão sujeitos a falhas devido ao ambiente de rede. 5.3 Descrição Interna A descrição interna do componente identifica: natureza e granularidade (nature and granularity), o componente apresenta uma especificação com base em serviços recorrentes em um dado domínio, implementando um serviço de percepção. Esse serviço atende parte dos requisitos de uma aplicação de edição ou visualização colaborativa. Encapsulamento (encapsulation - decision hiding), a descrição dos componentes oferece uma forma de implementar serviços de percepção de maneira que a adoção do componente acarrete o mínimo de impacto no projeto do restante da aplicação. Essa separação de interesses permite que a equipe de aplicação se concentre nos demais requisitos do sistema. Aspecto de estrutura e de comportamento (structural and behavioral aspects), a implementação é composta por um conjunto de classes. O estado do componente é determinado pelos eventos

6 monitorados sendo replicado através da rede suas outras instâncias. Acesso ao código fonte (accessibility of source code), o código fonte e o componente pronto para reutilização encontram-se disponíveis, para parceiros cadastrados, através da página do projeto [7]. 6 Conclusão Neste trabalho, apresentamos uma especificação de componentes que identifica serviços recorrentes no domínio de aplicação de CSCW. A separação entre o serviço e o sistema colaborativo é obtida através de uma arquitetura que adota o sistema de janelas da aplicação como fonte de eventos de manipulação de interface. Essa obtenção indireta dos dados necessários para a realização dos serviços é a peça-chave para a reutilização do serviço através dos componentes de software. Além disso, a adoção dos componentes tem o menor impacto possível tanto sobre aplicações existentes quanto sobre aplicações sendo projetadas. A especificação dos componentes é complementada através de características de componente que favorecem a comunicação de decisões de projeto, a catalogação e a recuperação dos componentes descritos. A descrição interna dos componentes é o nível de detalhes mais próximo da implementação disponível. De uma maneira geral, a especificação seria suficiente para apoiar a decisão sobre a adoção de um componente particular em uma aplicação. A especificação foi realizada segundo uma abordagem de DBC particular. A inovação neste aspecto está na identificação de CSCW como um co-domínio de aplicação. Esse codomínio oferece informações importantes tanto para o entendimento do contexto do uso de apoio ao trabalho colaborativo quanto na seleção de componentes e sistemas para reutilização. A descrição de serviços de colaboração através de componentes é uma atividade em andamento e ainda são necessários aprimoramentos e a descrição de outros serviços. Entretanto, a especificação apresentada demonstra o potencial da reutilização através de componentes na área de CSCW, que apresenta soluções ainda pouco difundidas para problemas que estão se tornando cada vez mais presentes no projeto de aplicações. Agradecimentos Os autores desejam agradecer o apoio financeiro do CNPq e da CAPES a este trabalho. Referências Bibliográficas [1] C.A. Ellis, S.J. Gibbs, G. Rein. Groupware: some issues and experiences, Communications of the ACM, v. 34, n. 1, p [2] J.Begole, M.B. Rosson, C.A. Shaffer. Flexible Collaboration Transparency: Supporting Worker Independence in Replicated Application-Sharing Systems, ACM Transactions on Computer- Human Interaction, v. 6, n. 2, p [3] C. Gutwin, S. Greenberg The effects of workspace awareness support on the usability of realtime distributed groupware, ACM Transactions on Computer-Human Interaction, v. 6, n.3, p [4] S. Yacoub, H. Ammar, A. Mili. Characterizing a Software Component. In: Proc. of Int. Workshop on Component-Based Software Engineering, 2, Los Angeles, USA, [5] Odyssey SDE homepage, Disponível em [6] M. Griss. Implementing Product-Line Features with Component Reuse. In: Proc. of Int. Conference on Software Reuse, 6,Vienna, Austria, [7] C.M.L. Werner, R.M.M. Braga et al. "Infra-estrutura Odyssey: estágio atual", Simpósio Brasileiro de Engenharia de Software, 14, Caderno de Ferramentas, João Pessoa, [8] C.M.L. Werner, R.M.M. Braga. "Desenvolvimento Baseado em Componentes", Simpósio Brasileiro de Engenharia de Software, 14, Minicursos, João Pessoa, [9] OdysseyShare homepage, Disponível em