MAIS: uma ferramenta de percepção para apoiar a edição
concorrente de modelos de análise e projeto
Marco A. de M. Lopes1, Marco A. S. Mangan1,2, Cláudia M. L. Werner1
1 Programa de Engenharia de Sistemas e Computação
COPPE – Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP. 21945-970 – Rio de Janeiro – RJ – Brasil
2Faculdade de Informática – Pontifícia Universidade Católica do Rio Grande do Sul
Porto Alegre – RS – Brasil
{mlopes,mangan,werner}@cos.ufrj.br, mangan@inf.pucrs.br
Abstract. Due to software models inherent complexity, concurrent editing
requires some mechanisms to help developers in change accounting and comprehension. Such mechanisms must also provide information to guide developers on future actions. In this paper, we present the MAIS tool, developed to meet such requirements. Besides change information collection and presentation, the tool also classifies this information according to the developer needs. A developer need is evaluated based on the information relevancy and acknowledge status rated by the developer.
Resumo. Devido à complexidade inerente de modelos de software, a sua
edição concorrente necessita de mecanismos para auxiliar os desenvolvedores a acompanhar e compreender mudanças. Tais mecanismos devem também fornecer informações que possam guiar os desenvolvedores em futuras ações. Neste texto, apresentamos a ferramenta MAIS, desenvolvida levando em consideração essas necessidades. Além da coleta e apresentação de informações de mudança, a ferramenta também as organiza de acordo com sua importância para o desenvolvedor. A importância é avaliada com base na relevância e ciência do desenvolvedor em relação à alteração.
1. Introdução
A atividade de modelagem em um processo de desenvolvimento de software, na maioria das vezes, é realizada por mais de um desenvolvedor. Espera-se que os desenvolvedores alocados a essa tarefa interajam de alguma forma. É possível notar que, atualmente, desenvolvedores pertinentes à equipe de projeto estão dispersos geograficamente, motivados por decisões estratégicas, apoiadas por redução de custos e aumento de produtividade. Assim, é desejável que esta atividade seja apoiada por algum software (groupware), minimizando retrabalho, mantendo consistência e uniformidade dos artefatos produzidos.
Mesmo sendo a atividade de modelagem colaborativa, existem momentos onde os desenvolvedores necessitam trabalhar individualmente. Sendo assim, é interessante que cada desenvolvedor tenha uma cópia do modelo de software compartilhado e, de tempos em tempos, sincronizem estas cópias. Dependendo do tempo em que um desenvolvedor fica sem sincronizar sua cópia, esta pode estar muito divergente das demais, acarretando em um esforço de convergência, culminando em retrabalho.
Um mecanismo para reduzir esse isolamento entre desenvolvedores é a percepção de mudanças entre as cópias do artefato. A informação de mudança deve ser disponibilizada para os desenvolvedores de forma a agilizar a detecção de possíveis conflitos sintáticos e semânticos, permitindo a visualização da evolução das cópias do artefato, tornando possível tomadas de decisões baseadas nas mudanças realizadas.
Este texto apresenta a ferramenta MAIS (Multi-synchronous Awareness InfraStructure), que fornece mecanismos de percepção de mudanças sobre modelos de classes da orientação a objetos, sem a necessidade de desenvolvimento de um novo ambiente ou editor. Além disso, MAIS tem como finalidade potencializar a atividade de modelagem, trabalhando em cima da informação de mudança e inferindo outras mais.
O restante deste texto está organizado da seguinte forma. A Seção 2 apresenta um cenário de uso onde a ferramenta pode ser aplicada. A Seção 3 descreve ferramentas e abordagens relacionadas. A Seção 4 apresenta a ferramenta MAIS. A Seção 5 apresenta a arquitetura da ferramenta. A Seção 6 apresenta a conclusão deste texto.
2. Cenário de Uso
Esta proposta aplica-se a cenários onde os membros de uma equipe de desenvolvimento de software estão dispersos geograficamente. Consideramos que os membros da equipe realizam análise e projeto de sistemas com o uso de editores de diagramas, baseados na linguagem UML. Resolvemos apoiar a percepção sobre modelos por meio de diagramas, pois há uma carência de ferramentas que trabalhem a colaboração neste nível.
A edição de artefatos UML (no contexto desta proposta) é realizada de maneira multi-síncrona (Molli et al, 2002), isto é, cada desenvolvedor possui uma cópia do dado compartilhado, sincronizando-as para obter uma visão unificada deste dado.
Figura 1. Sessões de Trabalho
Para explicar o problema do isolamento, consideremos as sessões de trabalho apresentadas na Figura 1. Supondo que os desenvolvedores D1 e D2 editam, simultaneamente, um modelo de classes M (no intervalo [T1,T2] de tempo). Em um tempo anterior a edição de D1 e D2 (T0), o desenvolvedor D3 modificou M. Quando D1 e D2 ativam o mecanismo de percepção proposto, estes ficam cientes das ações de D3 sobre M. Ao passo que D1 e/ou D2 realizam alterações sobre M, cada um deles percebe quais alterações foram estas; se D3 ativar o mecanismo de percepção proposto tempos depois (T3), este ficará ciente das ações de D1 e D2 sobre M.
3. Abordagens Relacionadas
Existem diversas propostas para apoiar a percepção em edição colaborativa. A ferramenta CO2DE (Meire, Borges, Araújo, 2003) se apresenta como uma implementação de editor gráfico e síncrono de diagramas UML, baseado em uma metáfora de “máscaras”, representando versões. Outro editor colaborativo de artefatos UML é D-UML (Boulila, Dutoit, Bruegge, 2003). Tukan (Schümmer, Schümmer, 2000)
D 3
D 2
D 1
é um ambiente síncrono e distribuído de programação Smalltalk. O ambiente SAMS (Molli et al, 2002) permite a edição colaborativa através de interações síncrona, assíncrona e multi-síncrona. NetEdit (Zaffer et. al, 2001) é um editor colaborativo multi-síncrono de documentos texto acessível pela WEB.
Analisando abordagens que fazem a coleta e distribuição desta informação, sem que esse mecanismo seja uma funcionalidade do editor colaborativo utilizado, temos a ferramenta Palantír (Sarma, Noroozi, Hoek, 2003), que complementa sistemas de gerência de configuração, fornecendo aos desenvolvedores pertencentes à sessão de colaboração informações sobre os espaços de trabalho dos demais. Koblylinski et. al (2002) apresentam uma proposta de sistema de percepção, que permite que colaboradores monitorem atividades de outros sobre artefatos de software.
Em termos de mecanismos de percepção, CO2DE, D-UML e Tukan possuem suporte a interação síncrona, sendo que CO2DE provê também suporte assíncrono para percepção. Palantír, SAMS, NetEdit e a abordagem descrita em (Koblylinski et al., 2002) contemplam mecanismos de percepção em interações multi-síncrona, além do suporte síncrono e assíncrono à percepção. Suportando percepção em modelos UML, temos CO2DE e D-UML.
Tukan utiliza como metáfora ícones usados em boletins meteorológicos;
mudanças com alto impacto são associadas à ícones de tempo instável. Palantír fornece informações sobre severidade de mudanças sobre o artefato compartilhado através de diversas formas gráficas de representação (por exemplo, barra de progresso).
As abordagens pesquisadas não apresentam a funcionalidade de obtenção da informação relativa a um desenvolvedor estar ou não ciente sobre determinada mudança no artefato compartilhado. Esta informação é útil pois evita sobrecarga de informações para o desenvolvedor “ciente”, além de tornar pública a ciência sobre um determinado evento para os demais, que podem tomar decisões baseadas nesse conhecimento.
4. A Ferramenta MAIS
Seguindo a cenário apresentado na Seção 2, um grupo de desenvolvedores de software está trabalhando sobre um mesmo modelo de classe, em cópias locais deste. Sendo assim, necessitam estar cientes sobre o que está sendo (ou o que foi) feito pelos demais, auxiliando-os a tomarem decisões, a fim de tornar as cópias o mais consistente possível.
De posse da informação do que mudou nas áreas de trabalho dos desenvolvedores, é possível agrupá-las e/ou transforma-las para obter características sobre a sessão, que os auxiliam a melhor realizar a tarefa de edição de modelos de classe. Por exemplo, se a informação de mudanças sobre determinada classe do modelo estão agrupadas por desenvolvedor, o volume de alterações sobre esta pode indicar o quanto os desenvolvedores tem conhecimento sobre a classe. Para isto ocorrer, é necessário que a informação de mudança seja coletada de forma mais elementar (grão fino) possível, para que futuras transformações e/ou consolidações possam ser feitas.
A ferramenta MAIS (Multi-synchronous Awareness InfraStructure) contempla as características citadas acima, onde mudanças são registradas em forma de mensagens (eventos) e distribuídas aos desenvolvedores que estão na mesma sessão colaborativa (Figura 2). A ferramenta está inserida no contexto do Projeto OdysseyShare (Odyssey, 2004), baseada na arquitetura cliente-servidor. Os eventos coletados são armazenados em um espaço de tuplas (Carriero, Gelernter, 1989), tendo como implementação
utilizada a especificada por JavaSpaces (JavaSpaces, 2004), visível a todos os desenvolvedores. Quando novos eventos são gerados, os desenvolvedores são notificados e os obtém do espaço de tuplas.
Figura 2. A ferramenta MAIS
Os eventos são coletados do Ambiente onde MAIS está inserido (i.e., Odyssey
Share) e são apresentados aos desenvolvedores em forma de mensagens, descritas
textualmente. Os desenvolvedores visualizam os eventos gerados, quem os gerou, além dos elementos do modelo envolvidos nos eventos. Eventos gerados pelo próprio desenvolvedor são apresentados em uma lista diferente dos gerados pelos demais.
Cada desenvolvedor pode tomar ciência sobre a ocorrência de determinado evento. Isto evita que o desenvolvedor seja alertado sobre a existência de eventos que já tenha tomado ciência em um momento anterior.
5. Descrição da Arquitetura
A ferramenta MAIS foi desenvolvida na linguagem de programação Java, sobre o modelo de programação distribuída baseado em espaço de tuplas, onde objetos são armazenados, retirados e consultados deste espaço (localizado em alguma máquina pertencente à rede de comunicação onde ocorre a colaboração) por diversas estações de trabalho. Cada estação de trabalho, nesse modelo, pode ser notificada quando determinado objeto for armazenado no espaço de tuplas, o que permitiu a implementação do mecanismo de troca de mensagens (eventos) relativas a mudanças sobre a área de trabalho compartilhada (no caso, modelo de classes).
Figura 3. Visão geral da solução
A Figura 3 apresenta os blocos principais da arquitetura da ferramenta MAIS. O módulo MaisClient é responsável por coletar as mudanças realizadas por um desenvolvedor sobre um modelo de classes no Ambiente onde a ferramenta MAIS está inserida, além de organizar e apresentar essa informação. Quando algum desenvolvedor gera mudanças sobre o modelo de classes, é de responsabilidade de MaisClient gerar eventos que indiquem essas mudanças e disponibilizá-los aos demais desenvolvedores, armazenando-os em uma área compartilhada (no caso, espaço de tuplas). Todos os participantes envolvidos (inclusive o que gerou a(s) mudança(s)) são notificados que houve(ram) mudança(s) (eventos) no modelo em questão. Isto é possível porque, quando a ferramenta é iniciada, MaisClient se “registra” para ser notificado quando um
novo evento ocorrer. Esta ação também informa os demais desenvolvedores da existência de um novo desenvolvedor na sessão colaborativa.
Cabe a MaisClient a tarefa de agrupar e ordenar eventos segundo critérios
pré-estabelecidos. Os critérios estabelecidos nesta versão da ferramenta MAIS são: eventos ordenados decrescentemente por momento de criação, eventos agrupados por classe, eventos agrupados por desenvolvedores e eventos ordenados decrescentemente por relevância ao desenvolvedor.
O grau de relevância que um evento possui para um determinado desenvolvedor tenta destacar para este o quão importante um evento é para ele, chamando sua atenção. Na implementacao atual, esta medida de relevância é calculada levando em consideração a quantidade de eventos que um desenvolvedor gerou, relativos ao elemento de modelo envolvido na mudança, sobre o total de eventos gerados por ele. Assim, quando um novo evento sobre este elemento é gerado (por qualquer desenvolvedor), é atribuído a este um grau de relevância, no momento em que cada
MaisClient é notificado sobre este novo evento. Por exemplo, se um desenvolvedor D1
gerou 40 eventos de mudança, sendo que 5 destes relativos à classe C, eventos relativos à classe C tem o grau de relevância igual a 12,5% para este desenvolvedor.
É de responsabilidade de MaisClient obter do desenvolvedor a informação de se este está ciente sobre a ocorrência de determinado evento, além de disponibilizar para os demais desenvolvedores esta informação. O desenvolvedor informa, explicitamente, que tomou ciência da existência de um evento. Essa informação fica disponível no espaço de tuplas, para que o módulo MaisClient a obtenha quando o desenvolvedor voltar a sessão colaborativa (isto é, o desenvolvedor não receberá um evento que ele já está ciente).
O módulo MaisServer atua como uma camada entre MaisClient e o espaço de
tuplas. Foi concebido para ser o único ponto de acesso da aplicação MAIS com o espaço de tuplas, delegando e transformando serviços de maneira que o resto da aplicação desconheça da existência desse espaço. Cada estação cliente possui uma instância de MaisServer, onde é possível registrar-se na sessão colaborativa, armazenar e consultar eventos.
Para representar os eventos gerados por MaisClient, é usada a abstração
MaisEvent, que representa uma ação gerada sobre algum elemento do modelo de
classes, descrito como MaisElement. As ações tratadas pela ferramenta são de criação, remoção e edição de elementos. Já os elementos representados nesta versão da ferramenta MAIS são classe, método e atributo. Em um MaisEvent, está descrito qual desenvolvedor gerou o evento, quando este foi criado, o nome do elemento afetado e quais outros elementos esse evento afeta.
6. Conclusão
Este artigo caracteriza o problema do isolamento entre desenvolvedores que compartilham modelos de análise e projeto baseados na linguagem UML. Na literatura de CSCW, o isolamento pode ser reduzido com o uso de mecanismos de percepção. A ferramenta MAIS realiza o monitoramento de ações nos ambientes de trabalho de cada usuário e divulga essas informações entre os desenvolvedores. As informações são apresentadas considerando também a sua relevância para cada desenvolvedor, minimizando a sobrecarga de informações. Ao monitorar o ambiente da estação de
trabalho, a ferramenta MAIS é capaz de perceber ações que ainda não estão disponíveis no repositório compartilhado. Dessa forma, os desenvolvedores podem anteceder a percepção de possíveis conflitos de edição e tomar ações preventivas. Além disso, a informação de que determinada ação foi percebida por determinado desenvolvedor é disponibilizada para todos os outros, permitindo que novas ações sejam geradas baseadas nessa informação.
Como trabalhos futuros, destacamos o uso das informações coletadas para auxiliar a gerencia do processo de software e para determinar competências entre os membros da equipe. Existe a necessidade de pesquisa sobre uma melhor forma de se calcular relevância de eventos, bem como maneiras de inferir a ciência de um desenvolvedor sobre a ocorrência de mudanças.
Referências
Boulila, N., Dutoit, A.H., Bruegge, B. (2003), "D-Meeting: an Object-Oriented Framework for Supporting Distributed Modelling of Software". In: Int. Workshop on Global Soft. Development, Int. Conf. on Soft. Eng., pp. 34-38, Maio, EUA.
Carriero, N., Gelernter, D. (1989), "Linda in context". In: Communications of the ACM, vol. 32, n. 4, pp. 444-458.
JavaSpaces (2004), em http://java.sun.com/developer/Books/JavaSpaces/ (14/05/2004). Kobylinski, R., Creighton, O., Dutoit, A., Bruegge, B., (2002), “Building awareness in
distributed software enginering: Using issues as context”. In: International Workshop on Distributed Software Development, Int. Conf. on Soft. Eng., Orlando, EUA. Meire, A. P., Borges, M. R. S., Araujo, R. M. (2003), “Supporting Collaborative
Drawing with the Mask Versioning Mechanism”. In: Lecture Notes in Computer Science, Vol.2806,p.p. 208-223, Berlim, Alemanha.
Molli, P., Skaf-Molli, H., Oster, G., et al (2002), “SAMS: Synchronous, Asynchronous, Multi-Synchronous Environments”. In : 7th Int. Conf. on Computer Supported Cooperative Work in Design. CSCWD´2002, pp. 80-84, Rio de Janeiro, Brasil.
Odyssey, 2004, Projeto Odyssey, em http://www.cos.ufrj.br/~odyssey (14/05/2004). Sarma, A., Noroozi, Z., van der Hoek, A. (2003), “Palantír: Raising Awareness among
Configuration Management Workspaces”. In : Proceedings of the 25th International Conference on Software Engineering (ICSE 2003), pp. 444-454, Maio, EUA.
Schümmer, T.; Schümmer, J. (2000), "Support for Distributed Teams in eXtreme Programming". In: Proceedings of eXtreme Programming and Flexible Processes Software Engineering - XP2000, Addison Wesley.
Zaffer, A.,Shaffer, C., Ehrich, R., Perez, M. (2001), “NetEdit: A Collaborative Editor”, TR-01-13, Computer Science, Virginia Tech, EUA.
