A principal contribui¸c˜ao deste trabalho ´e a defini¸c˜ao de um arcabou¸co de reengenharia ´agil baseado em framework cuja constru¸c˜ao tenha sido baseada em linguagem de padr˜oes, que proporciona re´uso em diversos n´ıveis de abstra¸c˜ao, como ilustrado na Figura 7.1. Para permitir o uso desse arcabou¸co definiu-se um processo ´agil de reengenharia tamb´em baseado em framework (Se¸c˜ao 3.3 do Cap´ıtulo 3), que seguiu as principais id´eias de tal arcabou¸co.
O entendimento e a elabora¸c˜ao da documenta¸c˜ao orientada a objetos do sistema legado podem ser reutilizados a partir da linguagem de padr˜oes de an´alise, usada na constru¸c˜ao do framework de aplica¸c˜ao. Isso porque a linguagem de padr˜oes fornece conhecimento do dom´ınio ao qual o sistema legado pertence e tamb´em solu¸c˜oes de an´alise (por exemplo, na forma de diagrama de classes) de problemas recorrentes que s˜ao encontrados em tal dom´ınio. Os recursos de teste agregados aos padr˜oes da linguagem de padr˜oes de an´alise com o apoio da abordagem ARTe, definida nesta tese, colaboram para o re´uso no n´ıvel de teste, desde o in´ıcio da reengenharia, possibilitando a “reengenharia guiada por teste”. A implementa¸c˜ao e o projeto do sistema alvo s˜ao reutilizados a partir do framework utilizado. As adapta¸c˜oes feitas em cada vers˜ao “intermedi´aria” do sistema alvo s˜ao incorporadas em sua subseq¨uente vers˜ao com o apoio da ferramenta de controle de vers˜ao GREN-WizardVersionControl , colaborando
para o re´uso no n´ıvel de manuten¸c˜ao. Assim, o re´uso na reengenharia em diversos n´ıveis pode contribuir com a redu¸c˜ao de custos e esfor¸cos associados.
ANÁLISE (entendimento do sistema legado e elaboração da documentação OO) PROJETO E IMPLEMENTAÇÃO TESTE Passos para definir recursos de teste R T R T R T C T R T ETAPA 1 Diretrizes para reutilizar recursos de teste C T C T C T C T C T C T C T C T C T C T C T C T C T C T C T C T ETAPA 2 C T C T C T xxxxxx xxxxxx xxxxxx Padrão 1 Padrão 2 Padrão 3 Padrão 4
Níveis de Reúso Representação Abordagens de Reúso
LINGUAGENS DE PADRÕES DE ANÁLISE FRAMEWORKS BASEADOS EM LINGUAGEM DE PADRÕES ABORDAGEM DE REUSO DE TESTE ARTe Classe1 Classe2 Classe3 Classe4 MANUTENÇÃO PERFECTIVA FERRAMENTA DE CONTROLE DE VERSÃO GREN- WIZARDVERSION CONTROL Framework MySQL xxxxxxxxx Código fonte adaptado manualmente Sistema v1 Sistema v2
Figura 7.1: Formas de re´uso do PARFAIT
As pr´aticas de m´etodos ´ageis embutidas nas atividades do PARFAIT colaboram para que o sistema alvo possa ser entregue dentro do prazo e custos previamente estimados. Al´em disso, notou-se que esse processo pretende minimizar alguns dos riscos associados `a reengenharia, discutidos por Rosenberg (1996), como justificado na Se¸c˜ao 3.3 do Cap´ıtulo 3. Dessa forma, PARFAIT e, conseq¨uentemente, o arcabou¸co ARA, preenche diversas carˆencias levantadas na Se¸c˜ao 1.1 do Cap´ıtulo 1, ou seja: 1) de processos e abordagens de reengenharia com apoio computacional efetivo na reengenharia e com atividades VV&T associadas, 2) de abordagens de teste que associam recursos de teste a padr˜oes, 3) do uso
de padr˜oes de an´alise para apoiar o entendimento do sistema legado, 4) de processos de reengenharia que utilizam frameworks de aplica¸c˜ao e 5) de processos de reengenharia que utilizam pr´aticas ´ageis.
Salienta-se que o arcabou¸co ARA pode ser adaptado para apoiar tamb´em o desenvol- vimento de software. Resumidamente, o documento de requisitos ´e elaborado a partir de entrevistas com os usu´arios do sistema. O diagrama de classes ´e criado com o apoio dos padr˜oes da linguagem de padr˜oes de an´alise, a partir dos requisitos definidos. Os casos de teste do sistema s˜ao reutilizados daqueles agregados aos padr˜oes da linguagem de padr˜oes, colaborando para o desenvolvimento guiado por teste (test-driven development (Beck, 2002)). Como na reengenharia, o projeto e a implementa¸c˜ao do novo sistema s˜ao obtidos a partir da instancia¸c˜ao do framework. Requisitos e regras do neg´ocio, espec´ıficos do sistema, s˜ao implementados manualmente no c´odigo fonte do sistema. Ressalta-se que todo o desenvolvimento pode ser feito de maneira iterativa e incremental, sendo que os clientes e/ou usu´arios do sistema priorizam os requisitos que devem ser considerados em cada itera¸c˜ao do processo e tamb´em participam de todo o desenvolvimento do software, validando os artefatos produzidos. Em geral, os requisitos que tˆem mais valor de neg´ocio s˜ao implementados nas primeiras vers˜oes do novo sistema, a fim de diminuir os riscos associados no desenvolvimento. Diferentemente do PARFAIT no contexto de reengenharia, a implanta¸c˜ao do novo sistema pode ser feita gradativamente, at´e atingir todo o sistema. A migra¸c˜ao dos dados de vers˜oes anteriores do novo sistema para uma nova vers˜ao ´e apoiada pela ferramenta GREN-WizardVersionControl .
O desenvolvimento da ferramenta GREN-WizardVersionControl permitiu que o fra- mework GREN atendesse `as caracter´ısticas iterativa e incremental do ARA. Essa ferramenta pode ser tamb´em utilizada no desenvolvimento de sistemas com o apoio de processos que possuem tais caracter´ısticas. Apesar da ferramenta GREN-WizardVersionControl ser espec´ıfica a um ´unico framework, a sua estrutura geral pode ser utilizada como base pela comunidade ´agil quando o interesse ´e utilizar frameworks para apoiar o desenvolvimento ´agil. Outra contribui¸c˜ao desta tese ´e a defini¸c˜ao do processo de evolu¸c˜ao de frameworks de aplica¸c˜ao PREF. Apesar do processo PREF ter alguns passos que s˜ao similares a qualquer outro processo de manuten¸c˜ao de software convencional, fornece contribui¸c˜ao relacionada ao controle de variabilidade de framework. Isso preenche outra carˆencia, identificada na Subse¸c˜ao 2.4.1 do Cap´ıtulo 2, ou seja, ausˆencia de processos de evolu¸c˜ao espec´ıficos para frameworks de aplica¸c˜ao. O processo ´e utilizado por engenheiros de dom´ınio, quando decide-se evoluir o framework; e por engenheiros de aplica¸c˜ao, quando decide-se evoluir apenas os sistemas gerados a partir da instancia¸c˜ao do framework. O controle de variabilidade ´e apoiado por um Hist´orico de Requisitos, que cont´em requisitos funcionais e n˜ao funcionais “n˜ao atendidos”, “sendo atendidos” ou “atendidos” pelo framework. Esse Hist´orico de Requisitos ´e utilizado pelo engenheiro de dom´ınio para apoiar a decis˜ao de evoluir ou n˜ao o
framework e tamb´em indica a vers˜ao do framework em que um determinado requisito, n˜ao considerado durante o desenvolvimento do framework, pode ser encontrado.
O pacote de experimenta¸c˜ao, apesar de ter sido apresentado parcialmente no Apˆendice A, tamb´em ´e outra contribui¸c˜ao da tese, pois cont´em toda a instrumenta¸c˜ao necess´aria (ou seja, documentos e material de apoio ao treinamento, e formul´arios para coleta de dados) para apoiar os interessados que desejam conduzir tal experimento, tanto no meio industrial quanto no meio acadˆemico. Isso preenche outra carˆencia levantada na Se¸c˜ao 1.1 do Cap´ıtulo 1, que est´a relacionada `a ausˆencia de pacotes de experimenta¸c˜ao dispon´ıveis no contexto de reengenharia de software. Al´em disso, o pacote definido cont´em diversas li¸c˜oes aprendidas durante a opera¸c˜ao parcial de um estudo de caso conduzido para validar tal pacote. Esse estudo de caso contribuiu para o refinamento de alguns itens da defini¸c˜ao e do planejamento do pacote.