Reprojeto de Sistemas Legados Baseado em Componentes de Software

Valdirene Fontanette, Vincius C. Garcia, Adriano A. Bossonaro, Angela B. Perez, Antonio F. do Prado Universidade Federal de So Carlos, Departamento de Computao So Carlos, Brazil, CEP 13565-905 {valdirene, vinicius, bossonaro, angela, prado}@dc.ufscar.br Abstract
This work presents a strategy for Component-Based ReDesigning of Legacy Systems, which integrates a software transformation system, a CASE tool and other technologies to reconstruct legacy systems using distributed components. The strategy is accomplished in 4 steps: Organize Legacy Code, Recover Project, Reproject and Reimplement. In the Organize Legacy Code step, the legacy code is organized, using transformations, according to the the ObjectOrientation principles, segmenting it in supposed classes, attributes and methods. The Recover Design step starts from the organized legacy code and also using software transformations, generates its design description in the MDL (Modeling Domain Language) language. The MDL descriptions are imported in a CASE tool, recovering the legacy code design, represented with UML techniques. In the ReDesign step, the Software Engineer redesigns the system with distributed software components. New functional and non-functional requirements can be added in this step. Finally, in the Reimplement step, the system reimplementation is done in an executable language target of the reimplementation. The system final code can be done through the CASE tool or using transformations. Keywords: Software Engineering, Software Reengineering, Reverse Engineering, Object Orientation, Software Transformation, Distributed Components and Reuse.

Resumo
Este artigo apresenta uma estratgia para o Reprojeto de Sistemas Legados Baseado em Componentes de Software, que integra um sistema de transformao, uma ferramenta CASE e outras tecnologias para reconstruir sistemas legados usando componentes distribudos. A estratgia realizada em 4 passos: Organizar Cdigo Legado, Recuperar Projeto, Reprojetar e Reimplementar. No passo Organizar Cdigo Legado, o cdigo legado organizado, usando transformaes, de acordo com os proncpios da Orientao a Objetos, segmentando o cdigo em supostas classes, atributos e mtodos. O passo Recuperar Projeto parte do cdigo legado organizado e tambm usando transformaes de software, gera sua descrio na linguagem MDL (Modeling Domain Language). Estas descries so importadas numa ferramenta CASE, recuperando o projeto do cdigo legado, representado com notao UML. No passo Reprojetar, o Engenheiro de Software reprojeta o sistema usando componentes distribudos. Novos requisitos funcionais e nofuncionais como plataforma, podem ser adicionados neste passo. Finalmente, no passo Reimplementar, faz-se a reimplementao do sistema numa linguagem alvo da reimplementao neste caso, Java. O cdigo final do sistema pode ser gerado pela ferramenta CASE ou usando transformaes. Palavras-Chaves: Engenharia de Software, Reengenharia de Software, Engenharia Reversa, Orientao a Objetos, Transformao de Software, Componentes Distribudos e Reuso.

Introduo

Sistema de software um artefato evolutivo e requer constantes modificaes, seja para corrigir erros, melhorar desempenho, adicionar novos requisitos ou mesmo para adapt-lo para novas plataformas de hardware e software. A dificuldade em atualizar estes softwares para a utilizao de novas tecnologias tem motivado os pesquisadores a investigar solues que diminuam os custos de desenvolvimento, garantam um tempo de vida maior para o sistema e facilitem a sua manuteno[1,2]. O conhecimento adquirido com estes sistemas antigos, denominados sistemas legados, utilizado como base para a evoluo contnua e estruturada do software. O cdigo legado possui lgica de programao, decises de projeto, requisitos de usurio e regras de negcio, que podem ser recuperados, facilitando sua reconstruo, sem perda da semntica. A Reengenharia de Software tambm uma forma de reutilizao que permite obter o entendimento do domnio da aplicao, recuperando as informaes das etapas de anlise e projeto, organizando-as de forma coerente e reutilizvel. Explorando as diferentes tecnologias da Engenharia de Software, pesquisou-se uma Estratgia a para o reprojeto de Sistemas Legados baseado em componentes de software, cujo objetivo recuperar o modelo de anlise de sistemas legados, reconstruindo-os para serem executados em novas plataformas de hardware e software, e incorporar novas tecnologias que surgem. Dentre essas tecnologias est o uso de componentes de software, o que proporciona ao sistema reconstrudo melhor qualidade e capacidade de reuso. A estratgia suporta a manuteno do sistema, inclusive com alterao da sua estrutura original, garantindo sua evoluo atravs do uso de componentes de software. Segundo Sametinger[3], componentes reutilizveis so artefatos autocontidos, claramente identificveis, que descrevem ou realizam uma funo especfica e tm interfaces claras em conformidade com um dado modelo de arquitetura de software, documentao apropriada e um grau de reutilizao definido. Na estratgia, os componentes podem ser utilizados no reprojeto e reimplementao do sistema segundo o mtodo Catalysis[4]. Este artigo est organizado da seguinte maneira: a seo 2 apresenta os principais mecanismos utilizados na estratgia como o sistema de transformao Draco, a ferramenta MVCASE e o mtodo Catalysis, a seo 3 apresenta a estratgia proposta descrevendo cada um de seus passos, a seo 4 apresenta um estudo de caso validando a estratgia, a seo 5 apresenta trabalhos relacionados . Finalmente a seo 6 apresenta as concluses desta pesquisa.

Principais Mecanismos da Estratgia

Dentre os principais mecanismos utilizados para dar suporte estratgia proposta esto: o sistema de transformao Draco, a ferramenta CASE MVCASE[5] e o mtodo de desenvolvimento baseado em componentes Catalysis[3]. Diferentes sistemas de transformao tm sido usados em projetos de engenharia e reengenharia de software destacando-se o IllumaSM[6], Popart[7]. Outro importante sistema de transformao de software que vem sendo utilizado o Draco. Um primeiro prottipo do sistema transformacional Draco foi construdo por Neighbors[2]. Posteriormente, o sistema transformacional Draco foi refinado e reconstrudo na PUC-RJ[8], usando novos domnios e funcionalidades. O Sistema de Transformao (ST) Draco, foi construdo com o objetivo de testar, desenvolver e colocar em prtica o paradigma Draco, criado para implementar as idias de transformao de software orientada a domnios. Com a estratgia proposta por Prado[8] possvel a reconstruo de software pela transformao direta do cdigo fonte de uma linguagem para linguagens de outros domnios. Um domnio no Draco definido atravs de uma Linguagem; esta por sua vez formada por uma Gramtica, um Parser e Prettyprinter, ou unparser, definidos a partir desta gramtica, conforme mostra a Figura 1. Uma Gramtica consiste em smbolos terminais, no-terminais, um smbolo de partida e produes. Um Parser responsvel por analisar os programas da linguagem e gerar a representao interna de uma DAST (Draco Abstract Syntax Tree) no Draco; e o Prettyprinter ou unparser, faz a formatao da DAST, tornando-a novamente textual na linguagem do domnio. Por ltimo, os transformadores, mapeiam estruturas sintticas de uma linguagem para outras estruturas sintticas, que podem estar na mesma linguagem de domnio, chamados transformadores Intradomnio, ou em outra linguagem de um domnio, chamados transformadores Interdomnios. So usados diferentes pontos de controle nas transformaes. Normalmente tem-se o LHS (Left Hand Side) e o RHS (Right Hand Side), que definem os padres de reconhecimento e substituio, respectivamente. 2

O ST Draco dispe ainda de uma Base de Conhecimento (Knowledge Base), que permite armazenar fatos e regras com informaes sobre o cdigo legado, que so consultadas durante as transformaes. Por exemplo, a Base de Conhecimento pode armazenar fatos relacionados com a declarao e utilizao de variveis em um programa. Outro recurso do Draco o Workspace, usado para agrupar ou desagrupar comandos do cdigo legado em blocos, durante a sua organizao segundo os princpios da orientao a objetos. A Base de Conhecimento tambm facilita a execuo de transformaes, que necessitam de informaes capturadas por outras transformaes.

Figura 1- Partes de um Domnio no Draco

Para facilitar o desenvolvimento dos domnios no ST Draco foi construda a ferramenta denominada Draco Domain Editor (DDE) que suporta a edio textual e grfica das gramticas, que do origem aos parsers e unparsers dos domnios, dos transformadores Inter e Intradomnios e de scripts para execuo dos transformadores. O DDE auxilia na utilizao do ST Draco disponibilizando, em um mesmo ambiente, recursos para a edio dos domnios e para aplicao das transformaes. Anteriormente, sem o DDE, o Engenheiro de Software tinha que editar o domnio em outro ambiente diferente do ST Draco. Para que se tenha um melhor entendimento do DDE a Figura 2 mostra a tela para a edio da gramtica de um domnio definido no ST Draco. esquerda (1) tem-se uma estrutura de diretrios onde esto localizados os domnios do ST Draco. Selecionando-se, por exemplo, o domnio Clipper pode-se visualizar sua gramtica na forma textual (2) ou grfica (3). Ainda na ferramenta (2), o Engenheiro de Software pode editar a gramtica, obtendo-se a representao grfica da sua rvore gramatical (3).

Figura 2 Draco Domain Editor (DDE)

A MVCASE[5] uma ferramenta CASE orientada a objetos que suporta a especificao de requisitos do sistema usando a notao UML[9]. Permite a construo de modelos grficos e textuais que representam o sistema em diferentes nveis de abstrao. Os modelos grficos de uma especificao na MVCASE facilitam a comunicao entre os desenvolvedores do sistema e seus usurios. A MVCASE suporta tambm o Desenvolvimento Baseado em Componentes (DBC), utilizando a tecnologia Enterprise Java Beans (EJB)[10] para implementao. O Engenheiro de Software pode construir o Modelo de Componentes Distribudos de um sistema, com base no seu Modelo de Objetos. A MVCASE pode tambm gerar o 3

cdigo Java/EJB dos componentes. Alm do cdigo Java/EJB, a MVCASE gera as descries em XML, que disponibilizam os componentes, em um servidor EJB, para serem reutilizados pelas diferentes aplicaes. A ferramenta MVCASE foi desenvolvida visando suportar a estratgia, atravs da construo de um ambiente integrado aplicao da estratgia. A escolha da MVCase se deve tambm pelo fato de ela ser uma ferramenta desenvolvida em java e portanto multi-plataforma, assim como o ST Draco que foi desenvolvido em C e de livre distribuio. Catalysis[3] um mtodo para DBC que utiliza a notao UML para modelar Sistemas com Componentes Distribudos. Tem como base os princpios: Abstrao, Preciso e Componentes Plug-In. O princpio Abstrao orienta o Engenheiro de Software na busca dos aspectos essenciais do sistema, dispensando detalhes que no so relevantes para o contexto do sistema. O princpio Preciso objetiva descobrir erros e inconsistncias na modelagem, e o princpio Componentes Plug-In visa a reutilizao de componentes para construir outros componentes. O mtodo apresenta modelos precisos e um processo de desenvolvimento completo e sistemtico, que cobre as diferentes fases do ciclo de vida do componente, desde a identificao e anlise dos seus requisitos at seu projeto e implementao. dividido em 3 nveis: Domnio do Problema, que d nfase na identificao dos requisitos do sistema, especificando o que o sistema deve fazer para solucionar o problema, Especificao dos Componentes, onde se define comportamento e responsabilidades dos componentes e Projeto Interno dos Componentes, que d nfase no projeto fsico dos componentes, preocupando-se com seus requisitos no-funcionais, e com suas distribuies fsicas. Foram estudados vrios mtodos[11,12,13] para Desenvolvimento Baseado em Componentes e optamos por Catalysis em razo da clara diviso entre as fases para o desenvolvimento dos componentes e dos princpios que ele se baseia.

ReProjeto de Sistemas Legados Baseado em Componentes de Software

Combinando as tecnologias do sistema de transformao Draco[8], da ferramenta MVCASE[5], as principais tcnicas de Engenharia Reversa[14] e do mtodo DBC Catalysis[3], definiu-se uma estratgia para o Reprojeto de Sistemas Legados Baseado em Componentes de Software, realizada em 4 passos: Organizar Cdigo Legado, Recuperar Projeto, Reprojetar e Reimplementar, conforme mostra a Figura 3.
Domnios no Draco

Tcnicas ER Cdigo Legado

Transformaes para Organizar o Cdigo Legado

Transformaes para Recuperar o Projeto em MDL

Transformaes para reimplementar o projeto numa linguagem executvel

Organizar Cdigo Legado

Informaes Disponvies

Cdigo Legado Organizado ES

Recuperar Projeto

Projeto recuperado do Cdigo Legado

Tcnicas DBCD

Draco

Descries MDL do Projeto Recuperado ES Draco

Reprojetar

Projeto Baseado em ComponentesDistribudos

Linguagem executvel alvo da reimplementao

Reimplementar

MVCASE ES ER KB Engenheiro de Software Engenharia Reversa Base de Conhecimento Novos Requisitos ES MVCASE Descries MDL do Projeto Baseado em Componentes Distribudos ES Draco

Sistema Implementado

Reimplementar

Desenvolvimento Baseado em DBCD Componentes Distribudos MDL Modeling Domain Language ES MVCASE Sistema Implementado

Figura 3 Estratgia de Reengenharia de Sistemas Legados Baseada em Componentes usando Transformaes

3.1 Organizar Cdigo Legado Este passo, Organizar Cdigo Legado, um passo preparatrio para facilitar a transformao de um cdigo procedural para Orientado a Objetos. 4

O Engenheiro de Software com o auxlio do ST Draco e de tcnicas de Engenharia Reversa, organiza o cdigo legado, em classes com seus atributos e mtodos. O cdigo legado, escrito de forma procedural, possui comandos e declaraes que podem ser organizados, sem prejuzo da sua lgica e semntica, de forma a facilitar sua transformao para o paradigma orientado a objetos, que tem a classe como a unidade bsica. Primeiramente rene-se toda a documentao disponvel sobre o sistema legado, principalmente os seus programas fontes. Elabora a relao CHAMA/CHAMADO[14], para determinar a seqncia de programas a serem submetidos s transformaes de organizao do cdigo legado. Esta atividade realizada manualmente pelo Engenheiro de Software. Em seguida, o cdigo legado submetido a um transformador, que contm transformaes desprovidas de padro de substituio (RHS), com objetivo de armazenar na Base de Conhecimento, fatos e regras, com informaes sobre a organizao do cdigo legado. Dentre estas transformaes, destacam-se as utilizadas para: a) b) c) Identificar supostas classes atravs do reconhecimento de comandos de abertura e acesso aos arquivos de dados, estruturas de dados; Identificar supostos atributos, reconhecidos pelos campos dos arquivos de dados, comandos de acesso ao banco de dados, campos de estruturas de dados; Identificar supostas classes de interface. Em sistemas orientados a menus, cada tela de interao d origem a uma suposta classe de interface e os objetos de interface do origem a um suposto atributo da classe de interface; Em sistemas no orientados a menus, cada bloco de comandos do cdigo legado, que no faz referncia a arquivo de dados, definido como um suposto mtodo de uma suposta classe de interface. Esta suposta classe no possui objetos de interface e, portanto, no d origem a nenhum suposto atributo; Identificar supostos mtodos, de uma suposta classe, a partir das unidades de programas que podem ser procedimentos, funes ou blocos de comandos executados pelo disparo de um evento de interface ou pela chamada de outra unidade de programa, respeitando o escopo, dependncia de dados e visibilidade do cdigo legado. Os supostos mtodos so classificados em construtores (c), quando alteram uma estrutura de dados, e observadores (o), quando somente consultam a estrutura de dados. Um suposto mtodo que faz referncia somente um arquivo de dados, relacionado como suposto mtodo da suposta classe identificada para este arquivo. Se o suposto mtodo no consulta nem modifica nenhum arquivo de dados, relacionado com uma suposta classe de interface. Quando um suposto mtodo refere-se a mais de uma suposta classe ele deve ser alocado usando os seguintes critrios[14]:

d)

Se um suposto mtodo for construtor de uma suposta classe e observador de outra (oc), ser alocado na suposta classe que faz referncia como construtor; Se um suposto mtodo for observador de uma suposta classe e construtor de vrias (oc+), ser alocado na primeira suposta classe que faz referncia como construtor; Se um suposto mtodo for observador de mais de uma suposta classe e construtor de apenas uma (o+c), ser alocado na primeira suposta classe que faz referncia como observador; Todas as unidades de programas candidatas a supostos mtodos de uma mesma suposta classe so reunidas em um nico arquivo;
e) Identificar relacionamentos das supostas classes, atravs de variveis e comandos que manipulam dados de um arquivo de dados. verificado se um campo de um arquivo, identificado como chave, tem seus valores consultados e atribudos a uma varivel, e posteriormente o valor dessa varivel armazenado em campos de outro arquivo ou utilizado para fazer busca em registros de outros arquivos. Identificar conexes de mensagens, a partir da interface do sistema, para definir os fluxos de execuo de cada cenrio de uso do sistema. Nos sistemas orientados a menus, parte-se de cada opo do menu para definir os diferentes cenrios de uso do sistema.

f)

A Figura 4 mostra as transformaes IdentifySelect ( direita) e IdentifySupposedClass ( esquerda) usadas para identificar as supostas classes e seus supostos atributos. A primeira transformao IdentifySelect reconhece o comando SELECT do Clipper que define uma rea de dados, usada por arquivos de extenso .dbf. No ponto de controle POST-MATCH cria-se um fato na Base de Conhecimento que relaciona esta rea de dados com uma suposta classe. A transformao IdentifySupposedClass reconhece o comando USE do Clipper que d origem a uma suposta classe. O ponto de controle LHS (1) especifica a regra de produo statements do parser Clipper que reconhece o comando USE, que identifica um arquivo de dados indexado. No ponto de controle POST-MATCH (2), inicialmente localiza o arquivo com extenso .dbf. Em (3) criado o fato SupposedClass na Base de Conhecimento, associando a rea do arquivo com a CurrentClass, que tem o mesmo nome do arquivo. Em (4) so identificados os atributos de cada campo do arquivo .dbf, como nome (AttribName), tipo (AttribType), tamanho (AttribSize) e parte decimal (AttribDec). E criado o fato SupposedAttribute relacionando os com a suposta classe. 5

TRANSFORM IdentifySelect LHS: {{dast clipper.statements SELECT [[NUM express1]] }} POST-MATCH: {{dast txt.decls ... KBAssertIfNew("SupposedClass([[AreaNum]])"); KBWrite(kb); ...

TRANSFORM IdentifySupposedClass LHS: {{dast clipper.statements (1) USE [[iden FileName]] INDEX [[iden* Indexes]] }} POST-MATCH: {{dast txt.decls (2) ... sprintf(File, "%s", expand("[[CurrentClass]].dbf")); Read_Class(File); ... KBAssertIfNew("SupposedClass([[AreaNum]],[[CurrentClass]]") KBWrite(kb); (3) KBAssertIfNew("SupoosedAttribute([[CurrentClass]], (4) [[AttribName]], [[AttribType]],[[AttribSize]], [[AttribDec]])"); KBWrite(kb);

Figura 4 - Transform que identifica as supostas classes e seus supostos atributos

Outras transformaes so usadas para identificar supostas classes de interface, supostos mtodos, relacionamentos entre supostas classes e o fluxo de execuo do cdigo legado. Alm dos fatos sobre supostas classes, supostos atributos e mtodos outros fatos contendo informaes sobre o cdigo legado tambm so armazenados na Base de Conhecimento. Numa segunda etapa, do passo Organizar Cdigo Legado, com base nas informaes coletadas, na Base de Conhecimento, pelo primeiro transformador Intradomnio, aplica-se um segundo transformador Intradomnio, responsvel por segmentar o cdigo legado em supostas classes com seus supostos atributos, mtodos e relacionamentos. Concludo este passo, tem-se o cdigo legado organizado seguindo os princpios de orientao a objetos. 3.2 Recuperar Projeto No segundo passo, Recuperar Projeto, obtm-se o projeto do cdigo legado. Primeiramente, o Engenheiro de Software parte do cdigo legado organizado e, novamente com o auxlio do ST Draco, obtm as especificaes UML do projeto do cdigo legado. As especificaes UML, geradas pelo ST Draco, so armazenadas em descries na linguagem de modelagem MDL (Modeling Domain Language). Os comportamentos dos supostos mtodos, separados em arquivos no passo Organizar Cdigo Legado, e cujos prottipos j foram criados nas respectivas classes, so transformados diretamente para Java. A Base de Conhecimento consultada para a criao das classes, atributos, prottipos dos mtodos e relacionamentos entre as classes. A Figura 5 mostra uma transformao Interdomnios, que cria as classes e gera suas descries na linguagem MDL.
TRANSFORM Program LHS: {{dast clipper.program [[TAG tag]] [[ID ProgName]] [[prog_elements Elements]] }} POST-MATCH: {{dast txt.decls Cont = 1; sprintf (ClassNum, %d, Cont); sprintf (Query, SupposedClass(*x, *y, %s), ClassNum) while (KBSolve (Query)) { sprintf (ClassName, %s, KBRetrieve (*y, 1)); KBAssert (Class([[ClassName]], [[ClassNum]])); KBWrite (RBCD.kb); sprintf (Query,SupposedAttribute(%s, *v, *w, *x, *y, *z, %d),ClassName, Cont); while (KBSolve(Query)) { sprintf (query, SupposedMethod (%s, *y, %d) if (KBSolve (query)) { TEMPLATE (TOperation) TEMPLATE Tclass RHS: {{dast mdl.class_Object (object Class[[STRI NameWithAspas]] quid[[STRI NumWithAspas]] operations(list Operations [[operations* Coper]]) class_attributes(list class_attribute_list [[ClassAttribute* Cattr]]) }} TEMPLATE Tattributes RHS:{{dast mdl.Attribute (object ClassAttribute[[STRI AttribName]] quid [[STRI AttribSize]] type [[STRI AttribType]]) }} TEMPLATE Toperation RHS: {{dast mdl.operations (object Operation [[STRI Nfunction]] quid [[STRI Nid]]) }}

Figura 5 Transform que gera a descrio MDL de uma classe e de seus atributos e mtodos

Em seguida, o Engenheiro de Software, usando a ferramenta MVCase, importa as descries MDL para obter o projeto recuperado do cdigo legado. O projeto recuperado representado pelos Modelos de classes, com seus atributos, mtodos e relacionamentos, e pelos Modelos de Interaes. Os Modelos de Interaes so representados em Diagramas de Seqncia que definem os fluxos de execuo do sistema, com suas conexes de mensagens. 3.3 Reprojetar No terceiro passo, Reprojetar, o Engenheiro de Software com o auxlio da ferramenta MVCASE e de tcnicas DBC 6

Distribudos, faz o reprojeto orientado a componentes distribudos do projeto recuperado do cdigo legado, obtendo um novo projeto baseado em componentes distribudos. Neste passo, adaptamos os mesmos princpios da tcnica de Framework de Modelos, do mtodo Catalysis, que originalmente trabalha com tipos num nvel maior de abstrao, para trabalhar com classes, j que as mesmas foram recuperadas no passo anterior. Obtendo assim, um modelo de classes mais genrico, que pode ser reutilizado. Deste modo, tem-se o reuso no s do cdigo mas tambm de artefatos de alto nvel (modelos). O Reprojeto realizado em 3 passos. no primeiro passo, Definir Domnio do Problema, define-se o domnio do problema. No segundo passo, Especificar Componentes, faz-se a generalizao do Modelo de Classes obtido no passo anterior, Recuperar, em um Framework de Modelos e em seguida o modelo instanciado atravs da Aplicao do Framework e no terceiro passo, Projetar Componentes, faz-se o projeto interno dos componentes, ou seja, como os componentes devem fazer para solucionar o problema. So especificados os requisitos no-funcionais, como a plataforma de hardware e software, a linguagem de implementao e as restries do projeto. As informaes provenientes do passo, anterior, Recuperar, como por exemplo, se uma classe persistente ou de Interface, so utilizadas neste passo. Uma vez projetados os componentes, eles so reutilizados no desenvolvimento de aplicaes. Algumas aplicaes se originam diretamente das classes identificadas como sendo de interface. Algumas aplicaes podem ser criadas, reutilizando os componentes projetados, para adicionar novas funcionalidades ao sistema. 3.4 Reimplementar Finalmente, no quarto passo da estratgia, faz-se a reimplementao do sistema reprojetado. A reimplementao pode ser realizada atravs de transformaes das descries MDL do reprojeto, com o auxlio do sistema de transformao Draco ou atravs da ferramenta MVCASE que gera cdigo automaticamente a partir dos modelos de objetos e componentes do reprojeto. Segue-se a apresentao de um estudo de caso que mostra o uso da estratgia proposta.

Estudo de Caso

Trata-se de um sistema para Oficina Auto-Eltrica e Mecnica que controla os servios executados nos veculos e o estoque das peas utilizadas. O cliente vai at a oficina para solicitar um servio em seu veculo. Um cliente pode ter diversos veculos. O mesmo veculo pode voltar oficina diversas vezes, sendo elaborada, em cada uma delas, uma Ordem de Servio distinta. Essa Ordem de Servio contm dados do cliente, do veculo e dos reparos a serem feitos. Quando o veculo consertado, a Ordem de Servio completada, introduzindo-se as peas utilizadas e a mo-deobra executada. Muitas vezes, o reparo pode exigir peas no existentes no estoque, que so adquiridas fora da oficina mecnica e que tambm participam da Ordem de Servio. O registro dessas peas importante para o gerente da oficina, pois essas so candidatas a serem estocadas no futuro. Esse sistema foi desenvolvido em 1990 e tem cerca de 20.000 linhas de cdigo Clipper. Segue-se uma apresentao de cada passo da estratgia para a reengenharia deste sistema. 4.1 Organizar Cdigo Legado Inicialmente reuniu-se as informaes disponveis sobre o cdigo legado, no caso apenas o cdigo legado, e elaborou-se a relao CHAMA/CHAMADO, para determinar a seqncia de programas a serem submetidos ao primeiro transformador, ClipperToKB, que organiza o cdigo legado em classes com seus atributos e metdos. A Figura 6 mostra direita a Base de Conhecimento (2) aps o reconhecimento da suposta classe Customer atravs dos comandos SELECT e USE, do cdigo legado Customer.prg, e de seu suposto mtodo Method1 (1).

Figura 6 Identificao de uma suposta classe e de seus atributos e mtodos

Aps identificar as supostas classes, seus supostos atributos e mtodos, aplicado um segundo transformador Intradomnio, OrganizeClipper, responsvel por segmentar o cdigo em supostas classes, atributos, mtodos e relacionamentos. A Figura 7 mostra esquerda (1) o programa Customer.prg e direita (2) seu correspondente cdigo organizado. O cdigo permanece na mesma linguagem, porm com classes, atributos e mtodos . No caso, o cdigo foi segmentado nas funes CustomerOpen(), CustomerInit() e CustomerFind().

Figura 7 Segmentao do cdigo legado segundo os princpios da Orientao a Objetos

Da mesma forma procede-se em todo o cdigo legado do sistema, obtendo-se no final deste passo o cdigo segmentado e organizado em supostas classes, atributos, mtodos e relacionamentos. 4.2 Recuperar Projeto Neste passo aplica-se o terceiro transformador, ClipperToMDL, no cdigo legado organizado para gerar as descries MDL, que permitem recuperar o projeto do cdigo legado. A Figura 8 mostra esquerda o cdigo legado Clipper organizado e direita a descrio MDL gerada, correspondente especificao UML. Cada suposta classe, suposto mtodo, e suposto atributo do origem, respectivamente, especificao de uma classe, operao, e atributo em UML, gerando a respectiva descrio em MDL. Por exemplo, a suposta classe identificada como Customer (1) d origem Class Customer. O suposto mtodo identificado como PROCEDURE proc40 (2), d origem Operation proc40, da classe Customer. Os supostos atributos vcRG (3) e vcName (4) do origem aos ClassAttributes vcRG e vcName, respectivamente. No caso pode-se ver ainda que o comportamento de proc40 do Clipper, foi transformado diretamente para Java, que a linguagem alvo da re-implementao. Assim, o prottipo de um mtodo em uma classe descrito em MDL, e seu corpo, descrito diretamente em Java. A gerao de cdigo para reimplementar o sistema em Java, fica mais fcil uma vez que j se tem pronto os cdigos dos mtodos.

Figura 8 - Gerao da descrio MDL de uma classe

Depois de concludas as transformaes de Clipper para MDL, o Engenheiro de Software pode importar as descries MDL na MVCASE para obter o projeto recuperado do cdigo legado, conforme mostra a Figura 9. No 8

caso, as classes Customer, Sale, ServiceOrder e Part foram identificadas como classes persistentes, por serem de banco e AddCustomerScreen como classe de interface.

Figura 9 Modelo de Classes recuperado na MVCASE

4.3 Reprojetar Neste passo o Engenheiro de Software faz o reprojeto do sistema recuperado, usando como base os princpios do mtodo Catalysis para construir o Modelo de Componentes. Assim, a partir do modelo de classes do passo anterior, realizam-se trs atividades para a construo dos componentes. Estas atividades compreendem: Definir Domnio do Problema, Especificar Componentes e Projetar Componentes 4.3.1 Definir Domnio do Problema Neste passo especifica-se os requisitos do sistema, ou seja, o qu os componentes devem fazer para solucionar o problema. Como o sistema fruto do processo de Reengenharia o domnio do problema j foi definido pelo projeto recuperado no passo anterior, Recuperar. 4.3.2 Especificar Componentes Para se obter o reuso no s do cdigo, mas dos modelos em alto nvel, faz-se a generalizao do Modelo de Classes. No caso o Modelo de Classes da Figura 9 foi generalizado obtendo-se o Framework de Modelos da Figura 10. Os smbolos <> identificam quais so as classes genricas e que devem ser associadas com as classes de uma aplicao. A Figura 11 mostra esta associao entre classes do Framework de Modelos Vendas e Servios e as classes, atravs da Aplicao do Framework.

Figura 10 Framework de Modelos

Figura 11 Aplicao do Framework

Em seguida, so identificados os componentes de negcio do domnio. Como os atributos e operaes encapsuladas em classes so recuperados no passo anterior, Recuperar, a tarefa se resume a identificar os componentes a partir das classes e especificar seus servios atravs das Interfaces. 4.3.3 Projetar Componentes Nesse passo feito o projeto interno dos componentes, preocupando-se com outros requisitos no-funcionais, como por exemplo linguagem de programao e distribuio. A Figura 12 mostra o Projeto Interno do Componente Customer, originado da classe Customer, segundo a tecnologia EJB. Conforme identificado no passo anterior, Recuperar, a classe Customer persistente e portanto originou um componente do tipo EntityBean[10]. De maneira similar, a classe AddCustomerServlet foi identificada como sendo de interface, e portanto originou o componente Web AddCustomerServlet, segundo a tecnologia Java/Servlet[15], como mostra a Figura 13. 9

Figura 12 Projeto Interno do Componente Customer

Figura 13 Componente AddCustomerServlet

Uma vez projetados os componentes, pode-se reutiliz-los no desenvolvimento de aplicaes. As classes identificadas como sendo de interface, no passo anterior, originaram algumas aplicaes, como por exemplo a classe AddCustomerScreen, que deu origem ao componente de aplicao AddCustomerServlet. Novas aplicaes podem ser construdas neste passo, adicionando novas funcionalidades ao sistema. A Figura 14 mostra trs componentes de aplicao, AddCustomerServlet, RegisterSaleServlet e AddPartServlet, do tipo Servlet, que reutilizam os componentes Customer, Sale e Part, sendo que o componente de aplicao AddCustomerServlet foi originado de uma classe do sistema legado, e os componentes de aplicao RegisterSaleServlet e AddPartServlet foram construdos neste passo.

Figura 14 Diagrama de Componentes

4.4 Reimplementar A reimplementao pode ser realizada por transformao, usando o ST Draco ou diretamente pelo gerador de cdigo Java da MVCASE. Por exemplo, usando o ST Draco, aplica-se o quarto transformador, Interdomnio, MDLToJava, que transforma as descries MDL em cdigo Java. A Figura 15 mostra esquerda a descrio MDL e direita o correspondente cdigo Java/EJB gerado pelas transformaes. Cada descrio MDL de uma classe ou interface d origem a um arquivo na linguagem Java, no caso CustomerEJB.java, Customer.java e CustomerHome.java. Numa segunda alternativa, pode-se realizar a reimplementao atravs da ferramenta MVCASE que gera o cdigo, conforme mostra a Figura 16. A gerao do cdigo EJB baseia-se no Modelo de classes dos componentes e no Modelo de componentes, especificados no reprojeto.

Figura 15 - Reimplementao usando Trasnformaes

Figura 16 - Cdigo gerado atravs da MVCASE

10

A Figura 17 mostra a arquitetura para execuo do sistema reimplementado. Na camada (1) tm-se as aplicaes Clientes, que podem ser JSPs ou Servlets em um Browser, via http usando um Servidor Web um Frame ou Applet, como aplicao Stand Alone. As aplicaes Clientes acessam, via RMI, os componentes disponveis no servidor J2EE, na camada Regras de Negocio (2). Os servios de Banco de Dados ficam na camada (3), e podem ser acessados pelos componentes, atravs da comunicao do Servidor J2EE com o Servidor de Banco de Dados. Nesta arquitetura os componentes podem ser distribudos, residindo em diferentes computadores.

Figura 17 - Arquitetura do sistema reimplementado

Os resultados das execues so analisados pelo Engenheiro de Software para verificar se atendem aos requisitos do sistema. Estes resultados fornecem um feedback aos passos anteriores, orientando nas correes para validar se a implementao atende aos requisitos especificados para o sistema. A funcionalidade do sistema legado mantida no sistema reimplementado com a vantagem de facilitar a manuteno, uma vez que o cdigo est organizado e encapsulado em componentes. Como as transformaes foram construdas preservando a semntica da linguagem origem na linguagem alvo da implementao, as falhas podem ser do prprio cdigo legado ou das alteraes introduzidas no reprojeto.

Trabalhos Relacionados

Em[16] os autores descrevem uma estratgia de desenvolvimento de sistemas distribudos orientados a objetos, dividido em 3 passos: Especificao do Sistema Distribudo, onde o sistema modelado usando a notao UML, Distribuio dos Objetos, onde definida a arquitetura do sistema distribudo baseado nos servios e frameworks disponveis na plataforma JAMP (Java Architecture for Media Processing) e Implementao do Sistema Distribudo, onde realizada a implementao baseado nas especificaes dos passos anteriores. Esta estratgia difere do nosso trabalho, utilizando frameworks disponveis na plataforma JAMP, onde toda a estratgia suportada. Alm disso, trabalha com objetos, no componentes, diminuindo o reuso no desenvolvimento das aplicaes. Em[17] apresentado uma estratgia para desenvolvimento de sistemas baseados em componentes distribudos, que usa Programao Orientada a Aspectos (AOP) para descrever e implementar as dependncias entre os componentes. Comparado a esta proposta, o nosso trabalho parte da concepo do domnio, obtido pela recuperao do projeto do sistema legado, identificando todos os elementos at a implementao dos componentes de software. Obtendo assim, o reuso no s do cdigo, mas tambm dos modelos de alto nvel de abstrao. A Rational Rose[18] uma ferramenta CASE que oferece uma imensa gama de recursos para suportar o processo de desenvolvimento de software baseado em componentes. Essa ferramenta suporta a especificao usando a notao UML e a gerao do cdigo dessas aplicaes. Comparada a esta ferramenta, a MVCASE se destaca por possuir um repositrio de componentes integrado, permitindo o armazenamento e busca de componentes para o reuso no desenvolvimento das aplicaes. E por ser uma ferramenta acadmica, gratuita.

Concluso

Este artigo apresentou uma estratgia para transformar sistemas legados, orientados a procedimentos, em sistemas orientados a componentes distribudos, atravs do reprojeto usando componentes. O sistema de transformao automatiza grande parte das tarefas da reengenharia, principalmente na organizao do cdigo legado e na gerao das especificaes e do cdigo em uma nova linguagem. Uma das vantagens do uso do sistema de transformao vem da possibilidade de se trabalhar com descries em uma linguagem, contendo descries em outras linguagens, como no caso das especificaes em Catalysis, contendo as mini especificaes dos mtodos, escritas em Java. Outra vantagem vem da capacidade de se trabalhar com linguagens de diferentes domnios de aplicao ou modelagem. A estratgia cobre todo o ciclo da reengenharia de um sistema procedural, destacando-se a recuperao do projeto 11

do cdigo legado permitindo o reprojeto orientado a componentes de software, em uma ferramenta CASE, com reimplementao semi-automtica em uma linguagem orientada a objetos, atravs de uma ferramenta CASE ou atravs de transformaes. O aproveitamento das idias do mtodo de DBC Catalysis proporcionou o reuso no s de cdigo, mas tambm de modelos em alto nvel de abstrao. O uso de componentes proporcionou ao sistema reconstrudo maior qualidade e manutenibilidade. Aps a reconstruo do sistema, os componentes construdos podem ser reutilizados para construir novas aplicaes, adicionar novos requisitos ou modificar funcionalidades j existentes. Outros dois estudos de casos foram realizados aplicando a estratgia em duas empresas. A primeira [19] aplicou a estratgia em um sistema legado (1.500.000 linhas) implementado em Progress4GL, obtendo um novo sistema em Java. A Segunda [20] aplicou a estratgia em um sistema implementado (5.3 milhes de linhas) em DataFlex Procedural, obtendo um sistema em Visual DataFlex. A estratgia proposta d mais um passo na automatizao de grande parte das tarefas do Engenheiro de Software, o que pode contribuir na reduo do tempo e custos de reconstruo de um sistema, atravs do reuso nos diferentes nveis de abstrao, desde os requisitos, anlise e projeto, at a implementao.

Referncias

[1] GAMMA, E. et al. Design Patterns. Elements of Reusable Object-Oriented Software. Ed. Addison-Wesley. USA.1995. [2] NEIGHBORS, J.M. The Draco approach to Constructing Software from Reusable Components. IEEE Transactions on Software Engineering. v.se-10, n.5, pp.564-574, September, 1984.. [3] SAMETINGER, J. Software Engineering with Reusable Components. Springer 1997 [4] DSOUZA, D. and A. Wills, Objects, Components and Frameworks with UMLThe Catalysis Approach, USA: Addison Wesley, 1995. [5] PRADO, A. F., LUCRDIO, D; Ferramenta MVCASE - Estgio Atual: Especificao, Projeto e Construo de Componentes - Sesso de Ferramentas do XV Simpsio Brasileiro de Engenharia de Software - SBES'2001. Rio de Janeiro-RJ, Brasil. 3 5 de Outubro, 2001. [6] Reasoning Systems Incorporated. Refine Users Guide, Reasoning Systems Incorporated, Palo Alto, 1992. [7] WILE, D. Popart: Producer of Parsers and Related Tools System Builders Manual. Technical Report, USC/Information Sciences Institute, 1993. [8] PRADO, A.F. Estratgia de Engenharia de Software Orientada a Domnios. Rio de Janeiro-RJ, 1992. Tese de Doutorado. Pontifcia Universidade Catlica. 333p. [9] BOOCH, G. et al. The Unified Modeling Language User Guide. USA: Addison Wesley, 1999. [10] Enterprise Java Beans technology, Sun Microsystems. URL: http://java.sun.com/products/ejb/index.html, 2001. [11] CHESSMAN, J., Daniels, J., 2000. UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley. USA, 1nd edition. [12] ATKISON, C., et al, 2000. Component-Based Software Engineering: The KobrA Approach. In ICSE2000, 22th International Conference on Software Engineering, 3rd Workshop on Component-Based Software Engineering. ACM Press. [13] JACOBSON, I., et al., 2001. The Unified Software Development Process. Addison-Wesley. USA, 4nd edition. [14] PENTEADO, R.D. Um Mtodo para Engenharia Reversa Orientada a Objetos. So Carlos-SP, 1996. Tese de Doutorado. Universidade de So Paulo. 251p. [15] Java Servlets URL: http://developer.java.sun.com/developer/onlineTraining/Servlets/Fundamentals [16] GUIMARES, M., P., et al..1999. Development of ObjectOriented Distributed Systems (DOODS) using Frameworks of the JAMP platform. In Fisrt Workshop on Web Engineering, in conjunction with 19th International Conference in Software Engineering (ICSE). [17] CLEMENT, P., J., Snchez, F., Prez, M., A., 2002. Modeling with UML Component-based and Aspect Oriented Programming Systems. In WCOP 2002. The 7th Workshop for Component-Oriented Programming. In conjuntion with the 16th European Conference on Oject-Oriented Programming (ECOOP). [18] Rational Rose Tool, 2001. Rational the software development company. Available in 10/07/2001. URL: http://www.rational.com. [19] NOGUEIRA, A. R. ,Transformao de DataFlex Procedural para Visual DataFlex Orientado a Objetos reusando um Framework, So Carlos/SP, 2002, Dissertao de Mestrado. Universidade Federal de So Carlos. [20] NOVAIS, E. R. A.; Reengenharia de Software Orientada a Componentes Distribudos, So Carlos/SP, 2002, Dissertao de Mestrado, Universidade Federal de So Carlos.

12