Reşit Rıza (1865-1935)

Após o término da segunda etapa do estudo de casos, questionários foram aplicados aos grupos G1, G2, G3 e G4 a fim de coletar suas opiniões a respeito do uso do ReJAsp na reengenharia de sistemas legados Java para sistemas em AspectJ. Um dos desenvolvedores de G4 não realizou o experimento, assim são consideradas 14 opiniões. Os resultados completos dos questionários e seus gráficos podem ser encontrados no Apêndice 2.

O questionário é composto de questões de múltipla escolha, variando as alternativas entre 4 e 5 dependendo da questão. O desenvolvedor pode assinalar apenas a alternativa mais adequada ou nenhuma alternativa. Há um espaço reservado, em cada questão, para que o desenvolvedor justifique a escolha da alternativa assinalada ou de nenhuma alternativa.

Quanto à facilidade de uso do ReJAsp 13 desenvolvedores consideraram fácil e somente um difícil. Muito provavelmente, esse desenvolvedor não interpretou corretamente a questão, pois ao justificar sua opinião, colocou que seu conhecimento em POA e em Java era bastante limitado, dificultando a execução do experimento, mas não apontou nenhuma falha de usabilidade no apoio computacional.

Em relação à eficiência da documentação (Guia do Usuário) houve unanimidade de que essa foi muito útil. Quanto à precisão de identificação de indícios, todos acreditam que foi correta na maior parte dos casos. Os desenvolvedores de G1, como comentário, colocaram que as instruções de importação de tipos não deveriam ser consideradas como indícios. Essa consideração não é pertinente dada à forma que o apoio computacional é baseado nas diretrizes de identificação de indícios, Capítulo 3, com todo processo de identificação iniciando-se pela análise de instruções de importação de tipos. A retirada dessa análise permitiria que tipos de mesmo nome, mas

de pacotes diferentes fossem reconhecidos como sendo o mesmo tipo, podendo gerar falsos indícios.

O grupo G3 em seus comentários relatou que indícios foram encontrados em um método abstrato, sendo que não continham indícios na opinião do grupo. Isso pode acontecer com o uso do ReJAsp quando o tipo de retorno ou o tipo de ao menos um parâmetro está relacionado a um interesse transversal. Nesse caso, provavelmente o grupo não estava ciente de que deveria estabelecer um entrecorte dinâmico para que o contexto seja captado na chamada do método e passado para o módulo de aspecto para tratar esse caso. É evidente que o entrecorte deve afetar as classes especializadas que implementam esse método.

Pelos questionários, todos os desenvolvedores relatam que a visualização de indícios foi útil durante a execução do experimento. Os integrantes de G1 e G4 enfatizam que a exibição do código, realçando o trecho com indícios, quando o mesmo é selecionado na árvore de indícios é um ponto forte do apoio computacional. Os membros de G2 acreditam que os indícios de importação de tipos poderiam ser ocultos da árvore de indícios e G3 acrescentou a sugestão de agrupamento de indícios adjacentes no código.

Para a questão relativa à facilidade de uso de assistentes de reestruturação, 10 desenvolvedores consideraram fácil, 2 difícil e 2 não opinaram. É importante ressaltar que os dois desenvolvedores que não opinaram, pertencentes a G3, tiveram o problema ao executar o assistente de reestruturação de código, mas não consultaram este autor.

O assistente de reestruturação foi considerado de difícil uso, por um dos desenvolvedores, devido à quantidade de passos nele existente, pois permite que algum passo seja ignorado ou feito incorretamente. As chances de algum passo ser ignorado são nulas no ReJAsp, pois todas as suas telas são travadas (botão de prosseguir desabilitado), até que informações válidas sejam colocadas pelo desenvolvedor. Além disso, na tela de pré-visualização as alterações a serem realizadas em código são visualizadas e os trechos alterados, tanto do código-base quanto módulo de aspecto, recebem destaque, evitando que informações incorretas sejam inseridas. Se houver qualquer problema há o recurso de usar o botão voltar e refazer algum passo. Uma forma de amenizar a quantidade de passos no assistente é a coleta de informações pelo contexto em que o assistente é acionado, discutido na seção de Trabalhos Futuros, no

próximo Capítulo. Outro desenvolvedor, que avaliou os assistentes de reestruturação de difícil uso, não justificou sua opção.

Os assistentes de reestruturação de código são usados para tratar quantidade limitada de problemas, assim, foi elaborada uma questão para avaliar a freqüência que esses assistentes foram empregados. A utilização dos assistentes na maioria dos casos foi realizada por 10 desenvolvedores,, 2 não opinaram (os mesmos que não opinaram anteriormente), 1 utilizou em metade dos casos e 1 raramente usou. O desenvolvedor que utilizou em metade dos casos, pertencia ao grupo que não conseguiu utilizar os assistentes completamente, e o desenvolvedor que utilizou raramente justificou sua opção devido a sua pouca familiaridade com ReJAsp.

O questionário continha uma pergunta para verificar se os desenvolvedores precisaram utilizar o recurso de gerenciamento de indícios. Como era esperado, a sua utilização não foi constatada na maioria dos casos por ser um recurso avançado do ReJAsp ou por não ter aplicabilidade nos sistemas implementados. Daqueles que utilizaram esse recurso, a maioria considerou de fácil uso, outra parcela avaliou como muito fácil. O único desenvolvedor que apontava esse assistente de difícil uso relatou que não usou essa função, o que é inconsistente.

O tempo de implementação variou não somente devido à complexidade dos sistemas e ao uso ou não do apoio computacional, mas também devido à dificuldade de modificação do sistema. Entretanto, cada desenvolvedor é capaz de notar possíveis economias de tempo geradas com o uso do apoio computacional. Isso foi verificado por 12 dos 14 desenvolvedores. Um desenvolvedor relatou pouca economia e o outro que observou alguma economia. É interessante ressaltar que o desenvolvedor que indicou que o apoio gerou pouca economia de tempo de reengenharia é o pertencente ao grupo que encontrou problemas na implementação do sistema de biblioteca previamente relatado. O desenvolvedor que não notou economia justifica que o tempo gasto com o aprendizado da ferramenta foi praticamente o mesmo tempo economizado na execução do experimento.

5.5. Considerações Finais

O estudo de caso apresentado foi realizado a partir de recursos limitados e disponíveis para este trabalho. Assim, resultados mais conclusivos poderiam ser

inferidos em estudos de caso ideal, utilizando uma quantidade maior de projetos e de grupos de desenvolvimento, bem como, alocação integral, homogeneidade de habilidades, presença deste autor na realização do experimento para controle estrito na coleta de dados.

Um fator que contribuiu para a geração de resultados discrepantes e não conclusivos foi concentração de atividades, um ou dois dias antes do prazo de entrega, para um dos grupos na primeira etapa do estudo de caso e para outro grupo, na segunda etapa do estudo de caso. Nesses casos, a execução do experimento teve baixa prioridade, comprometendo a qualidade da implementação.

Inspecionando os sistemas gerados, são verificadas deficiências dos desenvolvedores ainda com a programação orientada a objetos (POO). Problemas que poderiam ter sido resolvidos com POO não foram aplicados, complicando a solução usando AspectJ. A POA não tem objetivo de substituir completamente a POO e sim complementá-la, adicionando mecanismos para separação de interesses transversais, o que poderia abreviar o trabalho dos grupos.

A desistência de um dos desenvolvedores também afetou os resultados finais, já que houve desbalanceamento desse grupo em relação aos demais. Esse motivo pode justificar os resultados insatisfatórios gerados por eles.

Os resultados evidenciam que a quantidade de LOC dos sistemas implementados de modo manual ou usando ReJAsp é maior que a quantidade de LOC dos legados na maior parte dos casos. Isso se justifica pelo fato que a criação de aspectos requer a especificação de conjuntos de junção, adendos, instruções de declarações estáticas, etc que contribuem para o aumento do código.

O experimento teve como principal objetivo a separação de aspectos de sistemas legados OO para módulos de aspectos em AspectJ. Assim, melhorias adicionais como generalizações de conjuntos de junção, identificação e eliminação de trechos códigos duplicados e outras análises mais apuradas não foram incluídas, devido à restrição de tempo dos experimentos e à preocupação de se manter o enfoque principal do trabalho.

Após a criação de módulos de aspectos, identificação e separação de aspectos provenientes de códigos legados em Java, otimizações dos módulos de aspectos gerados podem ser realizadas utilizando refatorações de aspectos, definidas por Monteiro (2004). Essas otimizações fogem da proposta deste trabalho, mas são pertinentes em trabalhos futuros.

Este trabalho não teve como objetivo final a geração de um produto final de apoio computacional para a reengenharia de interesses transversais, a principal proposta foi a identificação de correções, de melhorias, de aplicabilidade, de usabilidade e da viabilidade do apoio computacional. Mesmo com as limitações encontradas nos estudos de caso realizados, a avaliação do ReJAsp foi realizada com sucesso, pontos fortes e fracos foram identificados e são discutidos no Capítulo 6, bem como os trabalhos futuros.

Considerações Finais

6.1. Introdução

A manutenção de software é uma atividade caracterizada pelo alto custo e esforço do projetista. Porém, é inevitável para qualquer tipo de software, pois os usuários constantemente solicitam modificações de ambiente operacional, a inserção de novas funções, correção de erros, entre outras. Sempre se realiza manutenção seja corretiva, adaptativa, perfectiva ou preventiva (PRESSMAN, 2006).

A Programação Orientada a Objetos (POO) permite que problemas sejam decompostos em objetos com a abstração de comportamentos e de dados em uma simples unidade (KICZALES et al 2007b). Embora a POO tenha obtido grande sucesso na modelagem e implementação de sistemas de software complexos, alguns problemas ainda persistem. Experiências práticas com projetos amplos e complexos mostram que programadores constantemente se deparam com código de difícil manutenção, devido à constante dificuldade na separação de interesses, principalmente os interesses transversais.

Uma importante tecnologia de Programação Pós-Objetos é a Programação Orientada a Aspectos (POA) que provê mecanismos para implementar cada interesse transversal separadamente. Por meio do combinador de aspectos (weaving), o código- base e os módulos que tratam os interesses transversais são combinados para a posterior composição do sistema final. Dentre as linguagens de Orientação a Aspectos (OA), AspectJ (KICZALES et al 1997a) é a mais difundida e utilizada.

Uma forma de manutenção preventiva de sistemas legados OO é pela separação de interesses transversais que se encontram espalhados, gerando um sistema implementado em OA. Nesse sentido, a abordagem Aspecting (RAMOS, 2004) se destaca por apresentar um modo direto e ordenado ao realizar a reengenharia do sistema implementado originalmente em Java para a linguagem AspectJ.

Entretanto, a aplicabilidade da Aspecting é comprometida devido à grande quantidade de diretrizes a serem seguidas. O esforço em sua execução se torna diretamente proporcional ao tamanho do sistema legado e ao número de interesses transversais presentes. Uma maneira de contornar esse problema é via automatização de parte das atividades envolvidas na Aspecting.

Assim, este trabalho apresentou um apoio computacional para Reengenharia de sistemas Java para AspectJ, denominado ReJAsp. Esse apoio envolveu a definição do Modelo de Indícios, uma representação de indícios configurável, atende à de persistência de dados; com a especificação de diretrizes de identificação de indícios e de reestruturação de código, Usa o Modelo de Indícios e estendeu algumas das diretrizes da abordagem Aspecting. A construção de um protótipo do ReJAsp foi realizada como

plug-in do ambiente integrado de desenvolvimento (IDE) Eclipse e sua avaliação foi

realizada por meio de estudos de caso.

A Seção 6.2 discute os resultados obtidos com o experimento realizado; a Seção 6.3 descreve as limitações do apoio computacional. As contribuições deste projeto são listadas na Seção 6.4 e, finalmente a Seção 6.5 apresenta alguns trabalhos que podem dar continuidade a este.