Uma ferramenta para controle de modificação de software : DiSE -ChanCo

Transcrição

1 Uma ferramenta para controle de modificação de software : DiSE -ChanCo Gustavo Yuji Sato, Gislaine Camila Lapasini Leal, Ana Paula Chaves, Elisa Hatsue Moriya Huzita Departamento de Informática Universidade Estadual de Maringá (UEM) Caixa Postal Maringá PR Brasil [gus.sato, cammyleal, chavesana]@gmail.com, emhuzita@din.uem.br Abstract. Software change control goal is to track changes along software development process, both in new features addition and bug fix activities. This paper compare some tools for change control, analyzing requirements for a change control tool. Based on those requirements, a tool for change control was developed. This tools allows to edit in a graphical way, the defined workflow the scripts to be performed as states and transitions associated too. Resumo. O controle de modificações de software tem como finalidade monitorar as alterações realizadas durante o desenvolvimento de software seja para a adição de novas funcionalidades ou para a correção de bugs. Este artigo compara algumas ferramentas de controle de modificação existentes, levantando as características necessárias para uma ferramenta de controle de modificação. Com base nos requisitos identificados, foi desenvolvida uma ferramenta que possibilita a edição de workflows, de forma gráfica, e a associação de scripts a serem executados nos estados e transições. 1. Introdução A gerência de configuração de software é um conjunto de atividades aplicadas para controlar as modificações no software: identificando a parte do produto que será mudada; estabelecendo relação entre eles (modificação e parte do produto); definindo mecanismos para controlar as versões; controlando as modificações e fazendo auditoria; e relatando as modificações realizadas [Pressman, 2001]. Fazendo parte da gerência de configuração está o processo de controle de modificações que, diferentemente do processo de desenvolvimento de software com uma instância em cada projeto, possui diversas instâncias no mesmo projeto. Cada solicitação de modificação dá inicio a uma nova execução do processo de controle de modificações [Murta, 2006]. Inicialmente, os sistemas de controle de modificações tinham seu foco principal em modificações corretivas, mas, com o amadurecimento da área, esses sistemas passaram a ser utilizados para qualquer tipo de modificação [Murta, 2006]. O controle de modificações de software tem como finalidade monitorar as alterações realizadas durante o desenvolvimento de software seja para a adição de novas funcionalidades ou para a correção de bugs. Este artigo apresenta um estudo sobre 1

2 algumas ferramentas de controle de modificação, levanta os requisitos necessários para uma ferramenta de controle de modificações e desenvolve um protótipo de uma ferramenta integrando-a a um ambiente de desenvolvimento distribuído de software, o DiSEN (Distributed Software Engineering Environment). O artigo está organizado em cinco seções, além desta. A Seção 2 aborda o processo de controle de modificações. Na Seção 3, são descritos os trabalhos relacionados. O ambiente DiSEN e a ferramenta desenvolvida são detalhados nas Seções 4 e 5, respectivamente. Por fim, são realizadas algumas considerações. 2. Processo de Controle de Modificações Um processo de modificação se inicia quando uma requisição de modificação é feita e um estudo técnico é realizado para avaliar o impacto sobre as funcionalidades existentes, outros itens de configuração e o custo da modificação. Os resultados desse estudo são apresentados como um relatório de modificação que é avaliado por uma autoridade de controle de modificações, pessoa ou grupo que toma a decisão final sobre o estado e prioridade da modificação. Uma ordem de modificação de engenharia, documento que contém restrições e dados sobre a modificação, como: justificativa da modificação; impacto; prioridade; estimativa de custo e prazos, é gerada para cada modificação a ser desenvolvida [Keyes, 2004]. Ela descreve a modificação a ser feita, as restrições que devem ser seguidas e os critérios de revisão e avaliação. O objeto a ser modificado é copiado (check-out) da base de dados do projeto. Assim que as modificações e as atividades de garantia de qualidade forem realizadas, o objeto é enviado (check-in) à base de dados e os mecanismos de controle de versão são usados para criar a nova versão do software. Diferentemente do processo de desenvolvimento de software, que tem uma instância em cada projeto, o processo de controle de modificações tem diversas instâncias no mesmo projeto. Cada solicitação de modificação dá inicio a uma nova execução do processo de controle de modificações. Dessa forma, algumas instâncias podem ter um ciclo de vida curto, durando pouco mais de uma semana. Por outro lado, solicitações complexas podem ter um ciclo de vida quase tão longo quanto o próprio ciclo de vida do software [Murta, 2006]. O processo de controle de modificações pode ser aplicado tanto na fase de desenvolvimento do software, quanto em sua manutenção. A gerência de configuração durante a manutenção do produto é tão fundamental quanto durante a produção [Hass, 2002]. O desenvolvimento e a manutenção do produto podem estar organizados de diferentes maneiras durante o ciclo de vida do produto. Cada subproduto pode seguir seu próprio processo de desenvolvimento. Um produto de software pode seguir um ciclo de vida iterativo enquanto um hardware pode seguir um modelo cascata. Segundo [Hass, 2002], esses fatores devem ser considerados ao definir o processo de controle de modificação. 3. Trabalhos relacionados Nesta seção, são apresentadas algumas ferramentas de controle de modificação em relação à personalização do processo de modificação. São elas: Bugzilla, Scarab, Jira, Aegis, ClearQuest, Odyssey e Trac. O Bugzilla [Mozilla, 2009] é uma ferramenta utilizada por um grande número de 2

3 projetos opensource (Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office, Eclipse e outros). Entretanto, não possibilita a customização do workflow. Aegis [Miller, 2008] é um sistema de controle de modificações cuja plataforma alvo são sistemas operacionais com o padrão POSIX, como Linux, Unix BeOS. Essa ferramwnta permite que Shell Scripts sejam utilizados para adicionar restrições a seu processo. No entanto, não provê mecanismos para a customização das fases. A ferramenta Scarab [Tigris, 2007] possibilita a customização de seu workflow por meio de um componente. O Jira [Atlassian, 2009] é um sistema de acompanhameto de solicitações que possibilita a customização de workflows através da interface do usuário por meio de: condições que determinam se uma solicitação pode fazer uma transição de estado; validadores que realizam a validação dos dados durante a transição de estados e pós-condições, que são eventos disparados logo após a validação dos dados durante a transição. Trac [Edgewall, 2009] é um projeto para acompanhamento de solicitações desenvolvido em Python, que possibilita a customização do workflow por meio de plugins. ClearQuest [IBM, 2005] é um conjunto ferramentas de automação de workflow desenvolvida pela IBM. Seu workflow é definido por um esquema que descreve o processo de modificação. No esquema são descritos estados, ações do modelo e estrutura de dados usadas para armazenar informações como as requisições de modificações. Odyssey-CCS é um componente para controle de modificação, parte da ferramenta Odyssey-SCM [Murta, 2006], cujo objetivo é a gerência de configuração de software baseado em componentes. A modelagem de processo é realizada por um módulo desktop de modo gráfico por meio da notação SPEM (Software Process Engineering Metamodel), própria para modelagem de processos, e adapta alguns diagramas da UML para a modelagem de processos. As ferramentas descritas acima foram analisadas sob as seguintes perspectivas: interface gráfica, customização de workflow, integração com sistemas de controle de versões, paralelismo entre estados e customização de tarefas automatizadas. A Tabela 1 apresenta a comparação das ferramentas. Interface gráfica Tabela 1. Comparação das ferramentas de controle de modificações. Bugzilla Scarab Jira Aegis ClearQuest Odyssey- CCS Web browser Web browser Web browser Linha de comando Web e Desktop Web e Desktop Trac Web browser Customização de workflow Não Sim Sim Não Sim Sim Sim Integração com sistemas de controle de versões Sim Sim Sim Sim Sim Sim Sim Paralelismo entre estados Não Não Não Não Não Sim Não Customização de tarefas automatizadas Não Sim Sim Sim Sim Não Sim 4. DiSE (Distributed Software Engineering Environment) O DiSEN objetiva prover o suporte necessário para o desenvolvimento distribuído de software, podendo a equipe estar localizada em pontos geográficos distintos e trabalhando de forma colaborativa. A Figura 1 ilustra a arquitetura do DiSEN proposta 3

4 em Pascutti (2002), composta por sete elementos os quais se encontram distribuídos em três camadas: Dinâmica, Aplicação e Infra-estrutura. Figura 1. Arquitetura do DiSEN (Pascutti, 2002). A camada dinâmica é responsável pela inserção, remoção e configuração dos componentes de software e serviços em tempo de execução. A camada de aplicação oferece suporte às metodologias de desenvolvimento de software, o repositório para armazenamento dos artefatos e informações necessários ao ambiente, além dos gerenciadores de objetos, workspaces e agentes. A camada de infra-estrutura é o pilar da arquitetura, provê suporte às tarefas de persistência, nomeação e concorrência. Nela encontramos o canal de comunicação que é o elemento responsável pela troca de informações entre os elementos do DiSEN e pela comunicação com a camada adjacente. 5. DiSE -ChanCo Segundo Pressman (2001), o controle de modificação combina tanto os procedimentos realizados por humanos quanto os automatizados. Por isso, uma ferramenta de controle de modificação deve não apenas possibilitar que a máquina execute algumas ações automatizadas em seu workflow, mas, também, adicionar ações desenvolvidas por terceiros. A WfMC (2009) define workflow como sendo a facilitação ou automação computadorizada de um processo de negócio, em sua totalidade ou uma parte. Ele está relacionado à automação de procedimento durante o qual os documentos, informações ou tarefas são passadas de um participante para outro, de acordo com um conjunto de regras, para se alcançar os objetivos gerais do negócio. Considerando os trabalhos apresentados na seção 3, foi possível identificar os principais requisitos para uma ferramenta de controle de modificação, que são: notificação das novas atividades do desenvolvedor; integração com um sistema de controle de versão e possibilidade de customização do workflow. A ferramenta de controle de modificação, DiSEN-ChanCo (DiSEN Change Control), a qual se encontra integrada ao ambiente DiSEN foi desenvolvida 4

5 considerando as características apresentadas acima. O workflow é definido por um conjunto de estados e um estado inicial. Cada estado possui uma série de scripts a serem executados assim que ele é alcançado (prescripts) e outra série de scripts a serem executados ao término (postscripts). Uma transição é formada por um nome, estado de origem e estado alvo, sendo possível associar um conjunto de scripts a uma transição, como mostra a Figura 2. Figura 2: Diagrama de classes UML do workflow. O editor de workflow, pode ser comparado a uma máquina de estados finitos, com um modelo misto, no qual as ações correspondem aos scripts a serem executados. Sendo possível que essas ações sejam disparadas no início e fim de um estado, além da possibilidade de estar associada a uma transição. É comum que workflows para controle de modificação possuam rotinas em comum. Por exemplo, enviar s notificando o gerente sobre o fim de uma atividade, gerar um relatório ou executar testes automatizados. Alguns workflows apenas possuem uma pequena variação, por exemplo, a construção da aplicação sendo desenvolvida em diferentes linguagens de programação. Em outros casos, há a omissão de uma dessas tarefas ou são realizadas em uma ordem diferente. Se a implementação das tarefas automatizadas de cada um desses workflows ocorresse separadamente, em um único componente, haveria uma repetição de código. O uso de scritps como ações de um transdutor reduz a repetição de código, uma vez que essas ações serão comuns entre os workflows. A Figura 3, apresenta o editor de workflow da ferramenta DiSEN-ChanCO. Na área 1 se encontram as ferramentas para edição do workflow, que são: mover blocos, adicionar estados, adicionar associação, organizar estados (executa algoritmo para distribuição de nodos em um grafo), aumentar zoom, reduzir zoom, excluir transição ou estado selecionado. Os scripts associados à transição ou ao estado são visualizados na área 2. A representação gráfica do workflow é ilustrada nas áreas 3 e 4. 5

6 Figura 3: Interface gráfica do editor de workflows. Ao término da modelagem do workflow, esse é persistido através do serviço de persistência do framework FRADE [Schiavoni, 2007] e poderá ser usado em novas tarefas de modificação de software inseridas no sistema. Entre as transições, é possível especificar scripts que terão acesso aos dados da transição. No início e no fim dos estados, são executados scripts com acesso aos dados do estado e tarefa de modificação. As transições podem ser disparadas pelo responsável pela tarefa de modificação, com exceção das transições com o caractere '$' em seu início, que estarão reservadas para eventos disparados pelo sistema, como envio de artefatos ao repositório. Para isto, o framework FRADE foi estendido para disponibilizar um novo serviço, o Serviço de Eventos de Workflow. Desta forma, é possível disparar um evento de uma determinada tarefa de modificação por meio de outros componentes do ambiente. Por exemplo, na Figura 3, quando uma tarefa que estiver no estado análise, caso o Serviço de eventos receba uma invocação sobre essa tarefa e com a mensagem dsvn_commit (reservada para o sistema de controle de versão do ambiente, indicando que a tarefa análise foi concluída), o workflow passará ao estado projeto. Após a modelagem de um workflow, é possível iniciar uma tarefa para modificação de software através do preenchimento de um formulário. A ferramenta DiSEN-ChanCO permite a definição de um workflow de forma gráfica e ao mesmo tempo a execução de tarefas automatizadas, por meio da execução de scripts. O uso de scripts permite a adição de novas funcionalidades sem que a aplicação seja reiniciada, o que não ocorre utilizando componentes. Além disso, ao invés de desenvolver um componente, com muitas ações programadas, para cada workflow, são desenvolvidos vários scripts que contém a lógica de uma única ação. Esses scripts podem ser re-utilizados em outros workflows com ações semelhantes, como por exemplo, a execução de casos de testes que pode ser comum tanto para workflows de desenvolvimento como na manutenção. Analisando os requisitos utilizados para comparar as ferramentas na seção 3, tem-se que a DiSEN-ChanCo possui interface gráfica desktop, que pode representar uma desvantagem, em relação à interface gráfica via web browser, por não estar acessível em qualquer máquina. No entanto, vale salientar que é possível a utilização da 6

7 tecnologia Java Web Start para que a aplicação seja iniciada sem a necessidade de sua instalação. Como vantagem da aplicação desktop tem-se a possibilidade de armazenar localmente as informações, em casos de estar trabalhando off-line, e quando conectado ao ambiente DiSEN, sincronizar os dados com o servidor. A possibilidade de personalização do workflow se mostrou alta, uma vez que há a possibilidade de adicionar novos estados ao workflow. Esta customização é realizada facilmente, já que ela é feita através de uma interface gráfica intuitiva, na qual blocos representam estados e setas indicam as possíveis transições que podem ser realizadas. A integração com o sistema de controle de versões existente no ambiente DiSEN se deu de forma parcial, uma vez que, a ferramenta possibilita que seja realizada a transição do workflow a partir do commit de um artefato. Ferramentas, como Trac, possibilitam que sejam visualizadas as alterações no código fonte após a realização de uma modificação. No que se refere ao paralelismo entre estados no workflow, das ferramentas pesquisadas, apenas a ferramenta Odyssey-CCS possibilita o paralelismo entre estados do workflow e no DiSEN-ChanCo essa funcionalidade não foi implementada. No que se refere ao paralelismo, com a ferramenta DiSEN-ChanCO é possível realizar tarefas paralelas, por exemplo, o desenvolvimento de duas novas funcionalidades enquanto uma série de bugs são corrigidos, o que não é possível na maioria das ferramentas relacionadas, exceto o Odyssey-CCS. Em relação à personalização de tarefas automatizadas, Bugzilla e Odyssey-CCS não oferecem suporte. Scarab, Jira e Trac oferecem suporte por meio de plugins no qual é necessário alterar arquivos de configuração para que eles sejam incluídos no ambiente. Aegis e ClearQuest trabalham com scripts e funciona de maneira semelhante ao DiSEN-ChanCo. 6.Considerações Finais Os sistemas de controle de modificação que possibilitam a customização de ações, sejam por meio de scripts, plugins ou componentes, exigem o conhecimento de programação. A abordagem usada no desenvolvimento do DiSEN-ChanCo possibilita a execução de scripts. No entanto, pessoas sem conhecimento de programação podem realizar o controle de modificação apenas modelando o workflow graficamente. A visualização do workflow por meio de um transdutor com estados, transições e caminhos alternativos possibilita o seu melhor entendimento. Os pontos fortes do DiSEN-ChanCo são: a notificação das novas atividades ao desenvolvedor; integração com o sistema de controle de versão e a facilidade de customização do workflow. Além disso, a ferramenta contribui para o processo de manutenção pois possibilita o acompanhamento das tarefas de modificação, a análise de erros encontrados, erros resolvidos e novas funcionalidades adicionadas em um período de tempo. Como trabalhos futuros é possível vislumbrar: a definição de políticas de segurança para restringir o acesso de quem inclui novos scripts ao sistema ou mecanismos que limitam o acesso a algumas classes pelos scripts; desenvolvimento de relatórios contendo informações gerenciais, tais como: problemas abertos e finalizados 7

8 em um período de tempo; e, implementar o paralelismo entre estados. Referências Atlassian (2009), Jira User s guide in: Acessado em: março de Edgewall (2009), Trac user and administration guide in: Acessado em: Março de IBM (2005), Rational ClearQuest Introduction in: st.pdf. Acessado em: Março de Hass, A.M.J. (2002), Configuration Management Principles and Practice, 1ª Edição, Addison Wesley, United States of America. Huzita E. H. M. et. Al (2007), Um ambiente de desenvolvimento distribuído de software DiSE in: I Workshop de Desenvolvimento Distribuído de Software, João Pessoa, PB. Miller, P. (2008), Aegis: a Project change supervisor, User guide in: Acessado em: março de 2009 Mozilla (2009), The bugzilla Guide in: Acessado em: março de 2009 Murta (2006), L. G. P, Gerencia de configuração no desenvolvimento baseado em componentes. Dissertação (Doutorado em ciências em engenharia de sistemas de computação) Universidade Federal do Rio de Janeiro, Rio de Janeiro. Pascutti (2002), M.C.D., Uma Proposta de Arquitetura de um Ambiente de Desenvolvimento de Software Distribuído Baseado em Agentes. Dissertação (mestrado em ciência da computação) - Universidade Estadual de Maringá, Maringá- PR. Pressman R. S (2001), Software engineering: a practitioner's aproach, 5th edition, McGraw-Hill Science. Tigris (2007), Scarab developer guide in: Acessado em: março de 2009 Schiavoni, F.L. (2007), FRADE - Framework para infra-estrutura de um Ambiente Distribuído de Desenvovlimento de Software. Dissertação (mestrado em ciência da computação) - Universidade Estadual de Maringá, Maringá-PR. WfMC, acessado em: março de