Lições Aprendidas no Processo de Manutenção do Ambiente
WebAPSEE
1Adailton Magalhães Lima, Breno Bernard N. de França, Anderson Costa, Ernani de Oliveira Sales, Carla A. Lima Reis, Rodrigo Quites Reis
Laboratório de Engenharia de Software (LABES) Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Pará (UFPA) - Belém, Pará, Brasil
{adailton,breno,anderson,ernani,clima,quites}@webapsee.com
Abstract. WebAPSEE is an open source software process management tool
which is under development since 2005. This paper presents some lessons learned through the system corrective and evolutive maintenance, mainly related to architectural issues. Finally, a case illustrating the impact of a new feature inclusion is shown.
Resumo. WebAPSEE é um ambiente de gestão de processo de software
baseado em Software Livre em desenvolvimento desde 2005. Este artigo apresenta algumas lições aprendidas na manutenção corretiva e evolutiva, principalmente relacionadas com questões arquiteturais. Por fim é apresentado um caso do impacto de adição de novas funcionalidades.
1. Introdução
Ambientes de desenvolvimento de Software Centrados em Processos (também conhecidos como PSEEs - Process-Centered Software Engineering Environments) [Gimenes 1994] relacionam-se com o problema de como sistemas computadorizados podem ser utilizados no desenvolvimento de software, ou seja, software para ajudar a construir software. Sua finalidade principal é atender a requisitos organizacionais para auxiliar na coordenação das atividades do desenvolvimento de software.
Tais ambientes geralmente envolvem um grande número de componentes integrados para prover serviços aos gerentes e desenvolvedores envolvidos no acesso a tais ambientes. Do ponto de vista de manutenção de software, a componentização dos serviços providos por um PSEE é necessária para manutenção e evolução dos mesmos.
Neste contexto, a proposta inicial do ambiente WebAPSEE surgiu em função da demanda por ferramentas flexíveis no contexto de Software Livre [Lima 2006a] que automatizam a Gerência de Processo de Software. O aumento do número de usuários da ferramenta durante o período entre 2005 e 2006, principalmente na sua utilização pelos parceiros industriais do projeto (como as empresas SERPRO-Belém e Eletronorte), forneceu contribuições no que diz respeito à utilização do ambiente e funcionalidades abrangendo novos aspectos da Gestão do Processo de Software [Lima 2006b].
O ambiente WebAPSEE apresentou, em sua fase inicial (protótipo), problemas na aceitação por seus usuários devido principalmente a problemas de performance e usabilidade. Além disso, acrescentar componentes com novas funcionalidades
1 Trabalho apoiado pelo CNPq (processo 550451/2003-0) e ELETRONORTE (projeto número 50528 do
demandava muito esforço devido ao alto acoplamento de alguns módulos. Diante deste cenário, algumas manutenções foram realizadas no sentido de aumentar a performance, melhorar a usabilidade e extensibilidade do sistema.
Este artigo apresenta as questões tratadas na manutenção e evolução do ambiente a partir das demandas atuais e futuras, assim como as lições aprendidas. Na seção 2 é apresentada uma visão geral do ambiente WebAPSEE. Na seção 3 são apresentadas as principais características dos requisitos que motivam a manutenção atual do ambiente, bem como os modelos que vêm sendo adotados para gerência da evolução do software. Na seção 4 são apresentados aspectos arquiteturais que foram escolhidos para prover a manutenibilidade e evolução do ambiente, enfatizando as funcionalidades de gestão de configuração de artefatos como exemplificação. A seção 5 discute de forma resumida as principais lições aprendidas a partir do relato deste artigo, entretanto, outras lições são apresentadas conforme os problemas são detalhados nas seções 3 e 4. Por fim, na seção 6 são apresentadas as considerações finais deste trabalho.
2. Ambiente WebAPSEE – Visão do Usuário
O ambiente WebAPSEE é um PSEE baseado em tecnologias de distribuição que provê serviços via Internet para seus clientes para definir e acompanhar processos de software. O propósito deste ambiente é flexibilizar a execução do processo dinamicamente [Lima Reis 2003]. Ou seja, em tempo de execução é possível se alterar o processo, por exemplo, incluindo ou excluindo atividades, alterando a alocação de pessoas e recursos, ou as políticas de processo habilitadas.
O WebAPSEE possui duas visões: a do gerente e a do desenvolvedor. A figura 1 mostra a visão do gerente (Manager Console) como parte mais ampla da figura e a visão do desenvolvedor (Task Agenda) na parte inferior direita da imagem.
Figura 1. Interface Gráfica da Versão 1.2 do Ambiente WebAPSEE.
No WebAPSEE o gerente é responsável, juntamente com os engenheiros de processo, pela modelagem e instanciação do processo. Isto é, a ferramenta apóia a
definição do fluxo das tarefas a serem realizadas, assim como: prazos, custos, estimativas e métricas a serem utilizadas, artefatos (artefatos de software) produzidos e consumidos, além das pessoas e grupos envolvidos. O Manager Console oferece, além da modelagem, a visualização para acompanhamento da execução dos processos.
Na visão do usuário-desenvolvedor (denominado agente), o processo é visto como uma Agenda onde são exibidas as tarefas a serem realizadas, os artefatos de software a serem produzidos e os recursos requeridos. O agente fornece, por meio dessa Agenda, o feedback para o gerente sobre o estado de suas atividades.
3. Características da manutenção do projeto
O projeto de manutenção e evolução do ambiente WebAPSEE possui atualmente características peculiares: apesar do produto contar com usuários na academia e indústria, é também um ambiente de experimentação alvo de diversos trabalhos de pesquisa nos tópicos relacionados com as funcionalidades do mesmo. Esta evolução é resultado de um trabalho inicial na definição de uma arquitetura e implementação realizadas no primeiro semestre de 2006 [Lima 2006b].
3.1 Conhecimento de Problemas e Obtenção de Requisitos
Problemas encontrados na versão disponibilizada para usuários acadêmicos e da indústria são continuamente reportados à equipe do projeto. Uma das fontes de identificação de problemas é a própria equipe do projeto durante os testes “pre-release”. Estes são realizadas por membros que não trabalham diretamente na codificação da ferramenta. Problemas reportados por membros da equipe do projeto são, em geral, mais claramente identificados em relação aos reportados por usuários externos. Isto se deve à possibilidade do responsável pelo código estar presente para visualizar o cenário do teste, assim como ter experiência na utilização do mesmo.
Outra fonte identificadora de problemas no ambiente WebAPSEE são os parceiros da indústria. Desta forma, a obtenção do feedback de tais usuários oferece o benefício da utilização da ferramenta em ambientes reais e de forma intensiva, o que nem sempre é alcançado em períodos de testes internos do ambiente.
Além dos problemas identificados ao longo do uso do ambiente WebAPSEE, novos requisitos também fazem parte da manutenção do projeto. Os novos requisitos capturados constituem a evolução do ambiente WebAPSEE, que podem ser classificados em: requisitos anteriores à atual implementação do projeto, ou seja, requisitos que já são conhecidos pelos membros do projeto e somente são adiados por questões de complexidade e prioridade; novos requisitos identificados por pesquisas em andamento e motivados por problemas identificados por membros; novos requisitos coletados por sugestões de parceiros na indústria que utilizam a ferramenta.
3.2 Controle de Evolução
Tanto as demandas de correções de problemas identificados, quanto à implementação das novas funcionalidades são classificadas para definição das prioridades de manutenção do ambiente. As características de complexidade (estimada por um membro do projeto com conhecimento sobre os componentes envolvidos) e prioridade (definida em consenso com as metas do projeto e recursos disponíveis) são adotadas para a classificação e planejamento dos releases do ambiente WebAPSEE, de acordo com o Processo de releases apresentado na Figura 2.
Figura 2. Visão geral do Processo de Liberação Releases do ambiente WebAPSEE. O processo de liberação de releases do ambiente WebAPSEE foi definido com base em processos similares adotados por projetos de software livre apresentados em [Lonchamp 2005], devido ao seu caráter livre e a coordenação principal do projeto ser concentrada em um grupo pequeno de pessoas. Este processo consiste de diversas macro-atividades, dentre elas: atividade decomposta para Definir os Requisitos do
Release, atividades gerenciais para Definir Prazos e refinamento dos sub-processos
para o desenvolvimento de cada nova funcionalidade (Modelagem do Processo), Fase
de Desenvolvimento para novas funcionalidades e bugs, Teste do Pré-Release, Aprovação do Release e atividades de divulgação e implantação do release.
Assim, a liberação do software é gerenciada e documentada (produção de artefatos). Além de manter um histórico das modificações, representando a correção e evolução do software em diversos aspectos.
4. Evoluções na Arquitetura do Ambiente WebAPSEE
Segundo [Herbsleb 2002], a relação entre o grau de acoplamento entre os componentes de um projeto de software aberto pode ajudar ou prejudicar a adesão de novos membros ao projeto. Desta forma, quanto menor a dependência direta de códigos de diversos módulos em um sistema, maior é a facilidade que membros externos e novos possuem para contribuir com projeto.
A figura 3 apresenta uma visão simplificada e em camadas da arquitetura do ambiente WebAPSEE. No topo da arquitetura são representados os principais componentes de interface com os usuários. Nas camadas identificadas como A, B e C estão representados diversos componentes que tratam dos serviços providos pelo
servidor WebAPSEE (camada A), da distribuição dos serviços para os clientes (camada B) e da exibição de dados para interação com aos usuários (camada C).
4.1 Alguns Problemas Identificados
Na primeira versão, ainda com outra proposta arquitetural diferente da atual (figura 3), foram identificados problemas que motivaram modificações no sistema. Nesta versão, não havia definição de interfaces e implementações comuns de comunicação entre camadas cliente e servidora. Tal problema motivou a criação da camada B.
Inicialmente foi utilizado somente o protocolo de distribuição Web Services. A adição de outro protocolo de distribuição provocaria modificações em todos os componentes já dependentes da distribuição via Web Services, o que também motivou a criação da camada B da figura 3.
Problemas de performance identificados no lado cliente (como a Agenda e Manager Console) foram percebidos claramente conforme a quantidade de informações persistentes inseridas no sistema aumentava, representando uma relação com os problemas de escalabilidade da arquitetura. Como uma das causas identificadas, a implementação de alguns componentes na camada cliente foi realizada de maneira inadequada (como, por exemplo, DynamicModelingFacade, na arquitetura atual pertencente à camada A).
A respeito da interface gráfica, foram reportados problemas de usabilidade tanto por membros do projeto quanto por parceiros da indústria, os quais motivaram a refatoração e reconstrução de formulários e botões de acesso às funções do sistema.
Figura 3. Arquitetura da versão 1.2 do ambiente WebAPSEE.
4.2 Descrição da Evolução do Ambiente WebAPSEE
O ambiente WebAPSEE foi e está sendo estendido para fornecer novas funcionalidades conforme novos requisitos que são incorporados ao projeto. Por questões de espaço, a seguir é apresentada somente uma breve descrição da evolução da Gestão de Configuração de artefatos (integração com a ferramenta Subversion) para exemplificar as questões de acoplamento e extensibilidade da arquitetura proposta.
4.2.1 Gestão de Configuração
Um importante serviço adicionado ao WebAPSEE foi a Gestão de Configuração de artefatos, que é vista como uma atividade de garantia de qualidade de software aplicada ao longo de todo um processo de desenvolvimento de software. O provisionamento deste serviço no ambiente WebAPSEE é evidenciado pela inclusão dos componentes ArtifactMngClient (camada B) e ArtifactMngFacade (camada A) e na incorporação de novas funcionalidades na Task Agenda e no Manager Console (camada C).
Atualmente está disponível a integração do WebAPSEE com a ferramenta CVS (Concurrent Versions System) [CVS 2007]. Isto foi obtido através da reutilização de componentes disponibilizados pela ferramenta jCVS (2007). Caso a camada A disponibilizasse serviços diretamente ligados à implementação do sistema de controle de versão, a substituição deste provocaria modificações nas três camadas (camadas A, B e C). A solução atual para gerência de artefatos é extensível à medida que os serviços disponibilizados pela camada A tratam apenas de operações genéricas de acesso a artefatos de software enviados ao mecanismo para persistência dos artefatos. Assim, somente a camada A será modificada para alterar o sistema de controle de versão.
Figura 4. Diagrama de Seqüência UML para o upload de artefatos para o CVS. Na figura 4, é descrita a seqüência (resumida) das passos realizados no ambiente WebAPSEE para o upload de um artefato para um repositório CVS. O evento 1 indica o início do serviço quando o usuário, através da Task Agenda, solicita o upload de um artefato (arquivo selecionado). O evento 2 verifica se o upload pode ser executado, isto é, se a atividade correspondente está ativa. Caso afirmativo, o serviço de upload da interface de gerenciamento de artefatos é requisitado (evento 3). O evento 4 solicita este serviço ao componente do servidor do WebAPSEE que o implementa. Por fim, o servidor do WebAPSEE faz a requisição do serviço import ao servidor CVS (evento 5).
Para a integração do ambiente WebAPSEE com a ferramenta Subversion, primeiramente, o componente Server Component da figura 4 tem a implementação dos serviços retrieveArtifact e performImport da interface ArtifactMngServer (disponibilizada pelo WebAPSEE Server) realizada. Em seguida, é realizada uma prospecção sobre qual tecnologia a ser utilizada (classes próprias e/ou bibliotecas externas) para integração com o sistema externo. Finalmente, são criados os componentes específicos para a conexão com o sistema desejado (Subversion), utilizando a tecnologia escolhida.
4.2.2 Viabilidade para outras extensões
Da mesma forma que os serviços de Gestão de Configuração de artefatos são extensíveis de forma isolada na arquitetura do ambiente WebAPSEE, todos os outros serviços providos pela camada A podem ser substituídos de forma isolada, sem modificação dos componentes de interface com o usuário. Assim, do ponto de vista de manutenção de software, a extensibilidade atual dos serviços providos pelo ambiente WebAPSEE facilita a manutenção corretiva e evolutiva do sistema.
Pode-se citar como exemplo, a migração do framework para persistência de objetos Hibernate, de sua versão 2 para 3. Neste caso, também, apenas os componentes da camada A são modificados.
5. Lições Aprendidas
A arquitetura atual do WebAPSEE foi definida com base no baixo acoplamento entre componentes e serviços. Assim, para amenizar os problemas das versões anteriores, procura-se maior extensibilidade aos componentes existentes e facilidade na adição de novos componentes à arquitetura existente. Alguns padrões de projeto [Gamma 1994] (como Facade, Singleton, AbstractFactory, entre outros) foram aplicados à arquitetura proposta como meio de reutilização de conceitos consolidados pela literatura.
A definição de uma API comum de comunicação para tratar de requisições entre clientes e servidor (camada B), evita que código para realização de chamadas remotas semelhantes seja simplesmente replicado. Além disso, também permite a independência entre aplicações clientes e protocolo de distribuição, fazendo que com que seja possível a substituição de protocolos de distribuição sem modificação nos componentes que dependem da API de comunicação comum. Desta forma, a existência da camada B permite que o código dos componentes definidos na camada C (clientes) possa implementar sua lógica de visualização sem acoplamento direto às invocações remotas necessárias para conexão aos serviços providos pela camada A.
O deslocamento do componente DynamicModelingFacade para o servidor é embasado na quantidade dados persistentes que este componente manipula para realização de certas funcionalidades em sua interface. Este componente é responsável pela modelagem, consistência e alteração dinâmica dos modelos de processo, sendo assim frequentemente utilizado. Certos métodos contidos nesse componente necessitam realizar processamentos complexos e navegar em grandes coleções de dados sobre atividades e tarefas do modelo do WebAPSEE. Assim, conforme cresce o número de informações, maior quantidade de dados é necessária ser recuperada remotamente para processamento. Ou seja, com a modificação deste componente para a camada servidora evita-se a muitas chamadas remotas para a recuperação de dados manipulados por este componente, melhorando a performance do sistema.
Quanto à distribuição, o ambiente atual fornece acesso tanto através de Web Services quanto pelo protocolo fornecido pela Sun em Java – RMI (2007). Com base na arquitetura atual do WebAPSEE e nas afirmações de [Herbsleb 2002], pode-se afirmar que a implementação de novos clientes mantém-se isolada ao uso de serviços providos pela camada B, evitando que desenvolvedores possuam conhecimento sobre aspectos de distribuição do sistema, facilitando assim a extensibilidade do ambiente WebAPSEE.
6. Conclusões
Este artigo descreve a evolução do ambiente WebAPSEE para atender demandas originadas a partir do uso prático da ferramenta pelos usuários e por pesquisas realizadas no contexto do projeto de desenvolvimento do mesmo. Aspectos relacionados com a manutenção corretiva e evolutiva do ambiente são discutidos baseando-se na arquitetura atual de baixo acoplamento entre os componentes existentes. O processo para integração do WebAPSEE com o SubVersion (seção 4.2.1) ilustra a independência entre as camadas definidas na arquitetura do software.
A versão atual do ambiente WebAPSEE descrita neste trabalho, é fruto principalmente das lições aprendidas com o insucesso de versões preliminares. Em tais versões, a inexistência de camadas intermediárias entre serviços e clientes implicou em alto acoplamento entre aspectos de distribuição e visualização de informações pelos usuários. Conforme apresentado, a definição de camadas de software para diminuição do acoplamento permite que componentes sejam estendidos e corrigidos de forma facilitada. Assim, a utilização de boas práticas de modularização definidas em nível arquitetural permite a manutenção corretiva e evolutiva facilitada do WebAPSEE.
Referências
Gamma, E. et. al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
CVS. (2007) “Concurrent Versions System”, http://www.nongnu.org/cvs/, Fevereiro. Gimenes, I. (1994) “O Processo de Engenharia de Software: Ambientes e
Formalismos”. In: XIII JAI, XIV Congresso da SBC, Caxambu-MG.
Herbsleb, James D. et al. “Two Case Studies of Open Source Software Development: Apache and Mozilla”. In: ACM Transactions on Software Engineering and Methodology, Vol. 11, No. 3, Julho, 2002.
jCVS. (2007) “jCVS – Welcome To jCVS.org”, http://www.jcvs.org/, Fevereiro.
Lima Reis, C. A. (2003) “Uma Abordagem Flexível para Execução de Processos de Software Evolutivos”. Tese de Doutorado, Porto Alegre: PPGC-UFRGS.
Lima, A. M. ; França, B. B. N. ; Silva, M. A.; Lima Reis, C. A.; Reis, R. Q. (2006a) “WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software”. VII Workshop de Software Livre . Porto Alegre, abril.
Lima, A. M. Costa, A.; França, B. B. N.; Lima Reis, C. A.; Reis, R. Q. (2006b) “Gerência Flexível de Processos de Software com o Ambiente WebAPSEE”. In: Sessão de Ferramentas do SBES, Outubro.
Lonchamp, J. (2005) “Open Source Software Development Process Modeling”, Software Process Modeling, Springer, pp. 29-64.
