Caso
A partir dos estudos de caso discutidos na Se¸c˜ao 3.4, observou-se a necessidade de evoluir o GREN incorporando a ele alguns requisitos importantes e ´uteis para o dom´ınio de Gest˜ao de Recursos de Neg´ocios, ou seja, tipo enumerado, tipo multivalorado e emiss˜ao de etiquetas. Para isso, um processo de evolu¸c˜ao de frameworks de aplica¸c˜ao foi definido e est´a apresentado no Cap´ıtulo 4. Esse processo foi associado ao ARA para garantir que o framework dispon´ıvel para ser utilizado na reengenharia possa apoiar mais efetivamente a reengenharia de um n´umero maior de sistemas legados que pertencem ao seu dom´ınio.
A partir dos resultados qualitativos e quantitativos observados durante o estudo de caso da Se¸c˜ao 3.5, notou-se a necessidade de uma abordagem de re´uso de teste que pudesse apoiar o engenheiro de software na associa¸c˜ao de requisitos e casos de teste funcional aos padr˜oes
da linguagem de padr˜oes de an´alise GRN e, principalmente, permitir o re´uso desses a fim de diminuir o tempo e o custo envolvidos nas atividades relacionadas a VV&T do ARA. Essa abordagem foi generalizada para ser aplicada a qualquer linguagem de padr˜oes de an´alise no dom´ınio de Sistemas de Informa¸c˜ao e est´a apresentada no Cap´ıtulo 5. Essa abordagem ´e outro recurso fornecido pelo ARA, para aumentar sua efetividade. Al´em disso, observou-se a necessidade de criar uma ferramenta de controle de vers˜ao dos sistemas criados a partir do framework GREN, para permitir instanciar o framework novamente para um mesmo sistema sem perder as altera¸c˜oes realizadas no seu c´odigo fonte em vers˜oes anteriores. Com isso, ´e poss´ıvel que o GREN ap´oie a abordagem iterativa do ARA. Os aspectos funcionais, arquiteturais e de implementa¸c˜ao dessa ferramenta s˜ao apresentados no Cap´ıtulo 6.
3.7
Considera¸c˜oes Finais
Neste cap´ıtulo apresentou-se uma vis˜ao geral do arcabou¸co de reengenharia ´agil, proposto nesta tese, destacando os recursos necess´arios para a sua aplicabilidade, dentre eles, o processo de reengenharia, denominado PARFAIT, tamb´em apresentado neste cap´ıtulo.
Como apresentado, este processo tem como principal seguir as id´eias do arcabou¸co definido, ou seja, fornecer uma vers˜ao do sistema alvo o mais r´apido poss´ıvel, com o apoio computacional de frameworks baseados em linguagem de padr˜oes que pertencem ao mesmo dom´ınio do sistema legado, e evoluir essa vers˜ao durante diversas itera¸c˜oes at´e obter o sistema completo. O planejamento do projeto da reengenharia ´e refeito a cada itera¸c˜ao do processo e avaliam-se os riscos de continuar ou n˜ao o projeto de reengenharia. Al´em disso, PARFAIT conta com a participa¸c˜ao dos usu´arios do sistema legado durante todo o projeto de reengenharia, que validam e refinam os artefatos produzidos. Outro fator importante desse processo ´e que atividades de VV&T s˜ao realizadas durante toda a reengenharia, auxiliando o entendimento do sistema legado, a elicita¸c˜ao e refinamento de requisitos e a valida¸c˜ao do produto final.
PARFAIT utiliza padr˜oes para apoiar o entendimento do sistema legado no n´ıvel funcional e n˜ao arquitetural. A nova arquitetura depende da arquitetura fornecida pelo framework sendo utilizado na reengenharia. Como, em geral, padr˜oes de projeto s˜ao utilizados na implementa¸c˜ao de frameworks, o sistema alvo, gerado a partir dele, possui as vantagens oferecidas por esses padr˜oes como: manutenibibilidade, flexibilidade, facilidade de entendimento, entre outras.
Al´em disso, PARFAIT ´e considerado ´agil pois observou-se que incorpora, de alguma forma, a maioria das pr´aticas de XP e tamb´em as caracter´ısticas ´ageis definidas por Abrahamsson et al. (2002).
Neste cap´ıtulo apresentaram-se tamb´em os trˆes estudos de caso que permitiram observar a viabilidade do processo e a avalia¸c˜ao, adequa¸c˜ao e refinamento de suas atividades. Foi
poss´ıvel tamb´em notar e evidenciar a necessidade de recursos mais apropriados, que poderiam aprimorar a aplica¸c˜ao e facilitar o uso do processo e, conseq¨uentemente, do arcabou¸co de reengenharia definido no in´ıcio deste cap´ıtulo.
PARFAIT foi utilizado apenas com sistemas de pequeno porte, portanto a sua escalabi- lidade para sistemas de maior porte n˜ao est´a consolidada. Estudos de caso espec´ıficos para observar esses aspectos devem ser conduzidos.
Em s´ıntese, pode-se observar que o arcabou¸co proposto, por meio do processo PARFAIT, atende grande parte das necessidades de processos e m´etodos que ap´oiam a reengenharia de software, pois pretende minimizar principalmente custos e esfor¸cos despendidos e alguns dos riscos associados `a reengenharia, discutidos por Rosenberg (1996).
´
E importante esclarecer que os estudos conduzidos neste cap´ıtulo e nos dois cap´ıtulos subseq¨uentes s˜ao limitados `as pessoas envolvidas, ao ambiente onde foram conduzidos e `as condi¸c˜oes impostas (por exemplo, tamanho do sistema legado, restri¸c˜ao de tempo dos participantes dos estudos, uso de apenas um framework, uso de apenas uma linguagem de padr˜oes de an´alise). Por exemplo, com rela¸c˜ao aos estudos de caso de reengenharia que foram aplicados em sistemas de pequeno porte, ou seja, com menos de 100 mil linhas de c´odigo (Sommerville, 2000), o processo PARFAIT comportou-se bem, mas poderia n˜ao ser adequado para sistemas de m´edio porte, ou seja, com at´e 500 mil linhas de c´odigo (Sommerville, 2000)) e tamb´em para sistemas de grande porte e/ou em ambiente industrial.
No pr´oximo cap´ıtulo apresenta-se o processo que trata da evolu¸c˜ao de frameworks de aplica¸c˜ao. Esse processo foi definido e refinado a partir de algumas evolu¸c˜oes do framework GREN. A necessidade de algumas dessas evolu¸c˜oes foram observadas durante a reengenharia com o apoio do PARFAIT, como discutido neste cap´ıtulo. ´E importante ressaltar que esse processo est´a dispon´ıvel no arcabou¸co ARA, apresentado neste cap´ıtulo.
4
PREF: Um Processo de Evolu¸c˜ao de
Frameworks de Aplica¸c˜ao
4.1
Considera¸c˜oes Iniciais
Neste cap´ıtulo apresenta-se o Processo de Evolu¸c˜ao de Frameworks de Aplica¸c˜ao (PREF), que ´e proposto nesta tese e foi associado ao arcabou¸co de reengenharia ´agil ARA, proposto no cap´ıtulo anterior. Esse processo possui diversas atividades similares `as de processos de evolu¸c˜ao de software convencional. No entanto, a sua diferen¸ca est´a no controle sistem´atico da variabilidade de frameworks de aplica¸c˜ao. Variabilidade nesse contexto refere-se `a habilidade do framework ser instanciado no dom´ınio de Sistemas de Informa¸c˜ao e ser evolu´ıdo devido a mudan¸cas no neg´ocio e no mercado, avan¸cos na tecnologia, entre outros. Tal controle de variabilidade objetiva gerenciar a inclus˜ao e altera¸c˜ao de hot spots no framework, aumentando o seu potencial de criar um n´umero maior de sistemas a partir de sua instancia¸c˜ao.
De acordo com Sinnema et al. (2004a), tornar a variabilidade expl´ıcita em fam´ılias de produtos ´e um aspecto importante de gerenciamento de variabilidade ((Clauss, 2001; Deelstra et al., 2005) apud (Sinnema et al., 2004a)). Em geral, em frameworks, esse gerenciamento pode ser alcan¸cado pelo cookbook. Em frameworks baseados em linguagem de padr˜oes, como ´e o caso do framework GREN, esse gerenciamento ´e alcan¸cado, em n´ıvel mais alto de abstra¸c˜ao, pelas variantes dos padr˜oes da linguagem de padr˜oes. No cookbook desse tipo de framework a rastreabilidade da variabilidade ´e explicitada, ou seja, dada uma variante de um determinado
padr˜ao ´e poss´ıvel saber quais classes do framework devem ser instanciadas e quais m´etodos devem ser sobrepostos. PREF n˜ao se preocupa com a modelagem de variabilidade, apenas com a atualiza¸c˜ao da documenta¸c˜ao do framework que a possui.
O processo de evolu¸c˜ao de frameworks foi definido e refinado a partir de algumas evolu¸c˜oes feitas no framework GREN, tanto relacionadas a requisitos funcionais quanto a requisitos n˜ao funcionais. As evolu¸c˜oes relacionadas a requisitos funcionais foram motivadas ap´os o uso do GREN na reengenharia de software, com o apoio do PARFAIT e, conseq¨uentemente, do arcabou¸co ARA, conforme mencionado no Cap´ıtulo 3, e foram conduzidas pela autora desta tese. A necessidade da evolu¸c˜ao relacionada a um requisito n˜ao funcional foi motivada desde a concep¸c˜ao do GREN, no entanto foi somente conduzida posteriormente em um trabalho de mestrado (Silva, 2004b).
Este cap´ıtulo est´a organizado da seguinte forma: na Se¸c˜ao 4.2 apresentam-se as atividades do processo proposto, destacando-se principalmente aquelas relacionadas ao controle de variabilidade do framework. Na Se¸c˜ao 4.3 apresentam-se duas evolu¸c˜oes realizadas no framework GREN com o apoio do processo proposto neste cap´ıtulo. Apesar de n˜ao ter sido coletado dado quantitativo das evolu¸c˜oes conduzidas, observou-se que esse processo ´e efetivo no contexto em que foi aplicado ap´os an´alise qualitativa dos resultados obtidos. Na Se¸c˜ao 4.4 s˜ao apresentadas as conclus˜oes parciais do trabalho, enfocando o processo definido neste cap´ıtulo.