Considerando que o framework GRENJ pode ser amplamente utilizado em novas pes- quisas ou para a instanciação de sistemas de software, a seguir são listados alguns trabalhos que podem ser realizados para mitigar as limitações comentadas anterior- mente ou adicionar mais funcionalidade e qualidade ao framework existente.
CAPÍTULO 7. CONCLUSÕES 102 Implementação da camada de interface gráfica com o usuário: conforme mencio- nado, a camada de interface gráfica com o usuário do framework GREN não passou por reengenharia. O desenvolvimento dessa camada, utilizando as tec- nologias JavaServer Pages1e Servlet2, possibilitaria a instanciação de aplicações voltadas para Web usando o framework GRENJ.
GRENJ-Wizard: A criação de um wizard, semelhante ao GREN-Wizard, poderia ser realizada; possibilitando a instanciação automatizada de aplicações sem que o desenvolvedor tenha conhecimento de detalhes relacionados à implementação do framework GRENJ.
Introdução de Frameworks Transversais: verificar a possibilidade de utilizar fra- meworks ou famílias de frameworks existentes para o tratamento de interes- ses transversais, tais como, persistência e segurança de dados. Um estudo pode ser realizado substituindo o mecanismo de persistência atualmente exis- tente no GRENJ por framework ou família de frameworks, tal como a proposta por Camargo (2006).
Geração de relatórios: os métodos do GRENJ relacionados à produção de relatórios, como por exemplo, lista de clientes inadimplentes, transações pendentes, en- tre outros, retornam, na maioria das vezes, uma lista de objetos que contêm as informações desejadas – uma implementação de java.util.List. No entanto, a exibição dessas informações fica a cargo do desenvolvedor responsável pela implementação da interface gráfica. É possível, por exemplo, exibir tais infor- mações em uma tabela (javax.swing.JTable). A introdução de ferramentas como a biblioteca de código livre JasperReports3 para produção de relatórios em vários formatos, como por exemplo Portable Document Format (PDF), diminuiria o esforço por parte do desenvolvedor e, além disso, aprimoraria a qualidade dos relatórios gerados.
Eliminar as dependências dos testes com a base de dados: os testes criados du- rante o desenvolvimento do GRENJ comunicam-se com o banco de dados a fim de avaliar a inserção, remoção e atualização de tuplas. Essa dependência evita que os testes sejam executados caso o banco de dados ainda não tenha sido con- figurado com as tabelas necessárias. Esse problema poderia ser eliminado por meio da utilização de objetos mock para a simulação da interação com o banco de dados. Dessa forma, a “instalação” dos testes do framework GRENJ seria facilitada, pois eliminaria a necessidade de se configurar o banco de dados com as tabelas avaliadas pelos testes.
1http://java.sun.com/products/jsp/ 2http://java.sun.com/products/servlet/
CAPÍTULO 7. CONCLUSÕES 103 Avaliação da extensibilidade do processo iterativo de reengenharia: aplicar o pro-
cesso iterativo de reengenharia em sistemas de pequeno porte (menos de vinte classes) a fim de aprimorar esse processo. Durante a realização da reengenharia desses sistemas outros padrões de engenharia reversa podem ser introduzidos ao processo. É recomendável que os sistemas submetidos à reengenharia sejam implementados em alguma linguagem dinamicamente tipada como, por exem- plo, Ruby4 e Python5, e que a linguagem selecionada para implementação da solução alvo seja estaticamente tipada, como JavaTMe C++.
Avaliar a substituição do GREN pelo GRENJ no ARA: o Arcabouço de Reengenha- ria Ágil (ARA) (Cagnin, 2005), desenvolvido com o intuito de apoiar a migração de sistemas procedimentais para o paradigma orientado a objetos, utiliza o GREN para alcançar reúso de projeto e código. Pode-se avaliar a substituição do GREN pelo GRENJ nesse contexto.
Produção do “cookbook” do GRENJ: um dos fatores que pode contribuir para faci- litar a instanciação de aplicações usando o GRENJ é a disponibilidade de uma documentação abrangente e adequada. Atualmente, o framework é documen- tado unicamente por meio de tags javadoc (Sun Microsystems, Inc., 2007). A produção de um documento semelhante ao “cookbook” do framework GREN po- deria auxiliar na instanciação de aplicações. Tal “cookbook” documentaria os métodos que precisam ser sobrescritos, mapeamento entre a GRN e o GRENJ, os scripts usados para criação das tabelas necessárias e exemplos detalhados de instanciação.
4http://www.ruby-lang.org/en/ 5http://www.python.org/
Apêndices
A
PÊNDICEA
Breve Introdução ao Framework JUnit
Versão 4.1
A.1 Introdução
Este Apêndice apresenta uma concisa introdução ao framework JUnit versão 4.1, amplamente utilizado pela comunidade de desenvolvedores JavaTM (Stuckert, 2006). O JUnit foi usado para facilitar e automatizar a criação de testes unitários durante o desenvolvimento do framework GRENJ. Assim, esta breve introdução tem a finalidade de facilitar a compreensão, por parte do leitor, dos trechos de código relacionados aos testes apresentados no decorrer deste trabalho. O framework JUnit é um projeto de código aberto (open source) hospedado em http://sourceforge.net/ e mantido sob uma licença de distribuição denominada Common Public License, que pode ser encontrada em http://junit.sourceforge.net/cpl-v10.html.
O JUnit possui várias funcionalidades que facilitam a criação de testes de unidade. As fundamentais como, por exemplo, a criação dos testes e das fixtures terão sua sintaxe exibida e brevemente explicada a seguir. Informações adicionais podem ser encontradas no “cookbook” do JUnit, criado por Kent Beck e Erich Gamma. O “cook- book” está disponível em: http://junit.sourceforge.net/doc/cookbook/cookbook.htm. Detalhes sobre a instalação do framework são omitidos neste Apêndice, no entanto, tal assunto é abordado em: http://junit.sourceforge.net/doc/faq/faq.htm#started_2.
APÊNDICE A. BREVE INTRODUÇÃO AO FRAMEWORK JUNIT VERSÃO 4.1 106