The impact of policy context

Com o decorrer do tempo, a reengenharia tem se tornado o principal meio para se realizar manutenc¸˜oes e evoluc¸˜oes em sistemas legados (Bianchi et al., 2001). Isso se deve ao fato do processo de reengenharia preservar ao m´aximo o conhecimento embutido no sistema. Dessa forma, tornando poss´ıveis diversos tipos de alterac¸˜oes de maneira confi´avel, r´apida e, muitas vezes, mais f´aceis. Al´em de possuir um custo de manutenc¸˜ao relativamente aceit´avel (Bennett, 1995).

Contudo, estudos realizados pelo Standish Group International (2010), Sneed (2005, 2008) e Demeyer (2005) estimam que cerca de metade dos projetos de reengenharia falham. Essa alta quantidade de falhas, segundo Sneed (2005), se deve a dois principais motivos: (i) a dificul- dade em automatizar os processos, o que aumenta os custos; e (ii) a falta de padronizac¸˜ao e formalismos, portanto, dificilmente uma tarefa realizada em um projeto poder´a ser reutilizada em outros. Sneed (2005) afirma que, devido essa falta de padronizac¸˜ao, o desenvolvimento de ferramentas que automatizam o processo de reengenharia se torna invi´avel. Consequentemente, as organizac¸˜oes se sentem forc¸adas a optar por soluc¸˜oes ad hocs, essas por sua vez imaturas, por´em, de menor custo. Soluc¸˜oes tais quais tem suas pr´oprias ferramentas, algoritmos e meta- modelos de representac¸˜ao que dificultam a troca de conhecimento.

Com tais problemas em mente, em 2003, o Object Management Group (OMG) iniciou esforc¸os no sentido de padronizar os tradicionais processos de reengenharia de software. Por meio da Architecture-Driven Modernization Task Force (ADMTF) a OMG propˆos ent˜ao a

Architecture-Driven Modernization(ADM). Segundo a OMG os principais objetivos da ADM

s˜ao (Omg, 2009): (i) melhorar os tradicionais processos de modernizac¸˜ao de software; (ii) conso- lidar melhores pr´aticas de modernizac¸˜ao, a fim de permitir que este processo seja bem-sucedido; (iii) tornar aplicac¸˜oes existentes mais ´ageis; (iv) permitir a revitalizac¸˜ao de aplicac¸˜oes j´a existen- tes; e (v) alavancar o uso de padr˜oes de modelagem e a iniciativa do Model-Driven Archtecture (MDA) e do Model-Driven Development (MDD).

Um dos principais pilares da ADM est´a no uso de modelos, ou seja, a ADM ´e uma aborda- gem baseada em modelos e metamodelos, o que pode diminuir o n´ıvel de complexidade, uma vez que o n´ıvel de abstrac¸˜ao ´e mais alto (Omg, 2016b). Portanto, a ideia foi unir os conceitos da MDA/MDD, como o PSM (Platform Specific Model), o PIM (Platform Independent Model) e o CIM (Computational Independent Model) e da Engenharia Reversa com alguns metamo- delos padr˜oes. Esses metamodelos criados s˜ao: o ASTM (Abstract Syntax Tree Metamodel); o SMM (Software Metrics Metamodel); o ADMPR (ADM Pattern Recognition Specification);

o ADMVS (ADM Visualization Specification); o ADMRS (ADM Refactoring Specification); o ADMTM (ADM Transformation Metamodel) e o KDM (Knowledge Discovery Metamodel). At´e o presente momento, os metamodelos j´a disponibilizados s˜ao o SMM, o ASTM e o KDM, enquanto os demais, ainda encontram-se em elaborac¸˜ao. A Tabela 2.1 mostra a situac¸˜ao atual dos metamodelos da ADM.

Tabela 2.1: Situac¸˜ao atual dos metamodelos da ADM. Fonte: www.omg.org/spec/category/software-modernization

Metamodelo Situac¸˜ao Vers˜ao Ano

ADMPR em Desenvolvimento ADMRS em Desenvolvimento ADMVS em Desenvolvimento ASTM Dispon´ıvel 1.0 2011 KDM Dispon´ıvel 1.4 2016 SMM Dispon´ıvel 1.1.1 2016 ADMTM em Desenvolvimento

O processo de modernizac¸˜ao da ADM ´e baseado na recuperac¸˜ao de c´odigo fonte, transformac¸˜ao de modelos e gerac¸˜ao de c´odigo fonte. Sendo assim, dividido em dois dom´ınios, que por usa vez s˜ao divididos em perspectivas arquiteturais. Os dom´ınios s˜ao: (i) Dom´ınio de Neg´ocio que ´e di- vidido em apenas uma perspectiva, a perspectiva de neg´ocios; e (ii) Dom´ınio de Tecnologia que ´e dividido em duas perspectivas, a perspectiva de aplicac¸˜ao e de t´ecnica. A perspectiva t´ecnica do dom´ınio de tecnologia ´e comumente utilizada e motivada pelo risco de obsolescˆencia, custos e mudanc¸as f´ısicas (Ulrich; Khusidman, 2007). Esse tipo de modernizac¸˜ao pode ser exemplificado por mudanc¸as de plataformas, troca de linguagem, etc..

Geralmente, essa modernizac¸˜ao ´e realizada diretamente em c´odigo fonte ou com modelos PSMs. J´a a perspectiva de aplicac¸˜ao do dom´ınio de tecnologia ´e comumente utilizada quando se ocorre alterac¸˜oes de forma que o sistema precise ser reimplementado ou ter alguma mudanc¸a pesada em sua arquitetura como um todo. Geralmente, essa modernizac¸˜ao ´e realizada com o aux´ılio de modelos PIMs. Por fim, o dom´ınio de neg´ocio e sua perspectiva envolve a soluc¸˜ao mais abrangente que transcende os modelos de aplicac¸˜ao e t´ecnico para modelos arquiteturais de neg´ocio. Essa perspectiva ´e comumente relacionada ao conceito do CIM, que apresenta o sistema de um ponto de vista mais abstrato poss´ıvel (Truyen, 2006).

´

E importante ressaltar que esse processo ´e frequentemente retratado por meio do Modelo de Reengenharia Horseshoe (Ferradura) e do paradigma de evoluc¸˜ao incremental proposto por

Kazman, Woods e Carri`ere (1998). A Figura 2.3 mostra o processo de modernizac¸˜ao proposto pela ADM baseado no modelo Horseshoe.

Figura 2.3: Processo Horseshoe de Modernizac¸˜ao proposto pela ADM. Fonte: Adaptado de OMG (2009)

Como a maioria dos processos de reengenharia, o objetivo ´e resolver os problemas existen- tes no sistema legado obtendo-se posteriormente, uma nova vers˜ao modernizada. Para tanto, o ciclo comec¸a com a engenharia reversa do sistema legado transformando-o em uma instˆancia do metamodelo ASTM (PSM). Posteriormente, essa instˆancia ´e transformada em uma instˆancia do KDM (PIM). Com base nessa instˆancia, aplicam-se algoritmos de minerac¸˜ao e de an´alise com o objetivo de identificar os problemas existentes no sistema legado. Em seguida, a etapa de refatorac¸˜ao e otimizac¸˜ao ´e conduzida e uma nova instˆancia do metamodelo KDM livre dos problemas identificados ´e gerada. Uma tecnologia comumente empregada nessa etapa ´e o ATL (Atlas Transformation Language), que ´e uma linguagem de transformac¸˜ao de modelos. Ap´os a obtenc¸˜ao de um KDM modernizado, prossegue-se no ciclo da engenharia avante, gerando-se novamente uma instˆancia do ASTM e posteriormente o c´odigo fonte do sistema antes legado e, agora modernizado.