Reengenharia de software: o que, por qu e como e

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

Departamento de Informtica - UNICENTRO a 85010-990 Guarapuava, PR (Recebido em 3 de maio de 2000)

Resumo: Este artigo tem como objetivo fornecer um embasamento sobre o processo de
manuteno de software, mais especicamente sobre reengenharia e engenharia reversa, ca sendo destinado basicamente para apoio didtico a essa parte da Engenharia de Software. a Devido a isso, so apresentadas as denies - o o que so essas modalidades de manuteno, a co a ca os casos em que se aplicam o por que utiliz-las e a forma de adot-las o como a a realiz-las. a ca Palavras-chave: Manuteno de software, reengenharia de software, engenharia reversa

Abstract: This paper aims to provide a basement about software maintenance process,
specially on reengineering and reverse engineering. It was developed regarding pedagogical use for Software Engineering classes. The concepts presented were organized to answer three basic points: what are the maintenance categories, why use them and how to implement them.

Key words: Software maintenance, software reengeneering, reverse engineering.

Introduo ca

Segundo Osborne e Chikofsky (1990), a variedade de problemas que envolve manutenc ao de software cresce constantemente, sendo que as soluoes no acompanham essa c a evoluao. Esses problemas so resultantes de cdigo fonte e documentaao mal c a o c elaborados, alm da falta de compreenso do sistema. e a A partir do momento em que um sistema comea a ser utilizado, ele entra em c um estado cont nuo de mudana. Mesmo que tenha sido constru aplicando as c do melhores tcnicas de projeto e codicaao existentes, os sistemas vo se tornando e c a obsoletos em vista das novas tecnologias que so disponibilizadas. a

34

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

Alm das correoes de erros, as mudanas mais comuns que os sistemas sofrem so e c c a migraoes para novas plataformas, ajustes para mudanas de tecnologia de hardware c c ou sistema operacional e extenses em sua funcionalidade para atender os usurios. o a Em geral, essas mudanas so realizadas sem que haja preocupaao com a arquitec a c tura geral do sistema, produzindo estruturas mal projetadas, documentaao desatuac lizada, lgica e codicaao ruins, sendo esses os focos que dicultam a manutenao o c c em um sistema (OSBORNE e CHIKOFSKY, 1990). Quando o sistema no fcil de ser mantido sendo, porm, de grande utilidade, a e a e ele deve ser reconstru do. Partindo-se do sistema existente (via cdigo-fonte, intero face ou ambiente), so abstra a das as suas funcionalidades e so constru a dos o modelo de anlise e o projeto do software. Esse processo denominado reengenharia de a e software. Considerando-se que o material sobre essa rea da engenharia de software a e escasso, principalmente para ns didticos, este artigo compila os principais artigos a do tema em questo. Descreve-se o que a reengenharia de software (O que), a sua a e importncia (Por qu) e a forma de realiz-la (Como), alm de situ-la no processo de a e a e a manutenao de software. Trata-se, portanto, de uma reviso que tem como objetivo c a constituir um material de apoio ao ensino dos contedos da disciplina Engenharia u de Software, mais especicamente Manutenao de Software. c

O que reengenharia de software e

Para abordar adequadamente as tcnicas de manutenao de software, deve-se primeie c ramente considerar trs conceitos dependentes: a existncia de um processo de dee e senvolvimento de software, a presena de um sistema a ser analisado e a identicaao c c de n veis de abstraao1 (OSBORNE e CHIKOFSKY, 1990). c Qualquer que seja o processo de desenvolvimento de software, espera-se que haja interaao entre seus estgios e, talvez, recurso. Em um processo de desenvolvimento c a a de software, os estgios iniciais envolvem conceitos mais gerais, independentes da a implementaao, enquanto os estgios nais enfatizam os detalhes de implementaao. c a c O aumento de detalhes durante o processo de desenvolvimento conceitua os n veis de abstrao. Estgios iniciais do sistema planejam e denem requisitos de alto ca a n quando comparados com a prpria implementaao. vel o c Essa comparaao importante para deixar claro que n de abstraao e grau c e vel c de abstraao so grandezas distintas. Enquanto o n de abstraao um conceito c a vel c e que diferencia os estgios conceituais do projeto, o grau de abstrao intr a ca e nseco a cada estgio. A evoluao atravs das fases do processo de desenvolvimento de softa c e ware envolve transioes dos n c veis mais altos de abstraao nos estgios iniciais, para c a n veis mais baixos nos estgios posteriores. As informaoes podem ser representadas a c em qualquer estgio do desenvolvimento, seja de forma detalhada (baixo grau de a abstraao), seja de forma mais sucinta ou global (alto grau de abstraao). c c
Abstrao denida como a habilidade de se ignorar os aspectos de assuntos no relevantes ca e a para o propsito em questo, tornando poss uma concentrao maior nos assuntos principais. o a vel ca
1

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

35

Para que as tcnicas de manutenao de software (especicamente engenharia e c reversa e reengenharia) sejam descritas de forma simplicada, sero tomadas como a base apenas trs fases do processo de desenvolvimento de software, com n e veis de abstraao bem diferenciados, conforme a Figura 1: c Requisitos: especicaao do problema a ser resolvido, incluindo objetivos, c restrioes e regras de negociaao; c c Projeto: especicaao da soluao; c c Implementaao: codicaao, teste e adaptaao ao sistema operacional. c c c A tcnica tradicional, que avana progressivamente pelas fases do processo de e c desenvolvimento de software, denominada engenharia progressiva. A execuao e c dessa tcnica consiste em partir de projetos independentes da implementaao, que e c possuem altos n veis de abstraao, indo em direao ` implementaao f c c a c sica do sistema. Em outras palavras, engenharia progressiva segue a seqncia de desenvolviue mento estabelecida no projeto, visando ` obtenao do sistema implementado a c (OSBORNE e CHIKOFSKY, 1990).

Figura 1: Relacionamentos no Ciclo de Desenvolvimento de Software (CHIKOFSKY e CROSS, 1990)

Na Figura 1, com exceo da engenharia progressiva, as demais transioes entre ca c as fases de desenvolvimento so tecnologias utilizadas na manutenao de software a c (CHIKOFSKY e CROSS, 1990), sendo assim denidas: Redocumentaao: como uma sub-rea da engenharia reversa, a criaao ou c a e c reviso de uma representaao semanticamente equivalente, dentro do mesmo n a c vel

36

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

relativo de abstraao, sendo que as formas resultantes de representaao so consic c a deradas como vises alternativas, utilizadas para uma melhor compreenso humana o a do sistema analisado; Recuperaao de projeto: uma sub-rea da engenharia reversa na qual o coc e a nhecimento do dom da aplicaao, informaoes externas e deduao so adicionadas nio c c c a a `s observaoes referentes ao programa, para se extrairem abstraoes signicativas de c c mais alto n vel, alm daquelas obtidas atravs da observaao direta do sistema; e e c Reestruturaao: a transformaao de uma forma de representaao, para c e c c outra no mesmo n de abstraao relativo, preservando o comportamento externo vel c do sistema (funcionalidade e semntica). Geralmente usada como uma forma de a manutenao preventiva, a reestruturaao aplicada em sistemas que tenham sido c c e desenvolvidos de forma desestruturada, resultando uma representaao que preserva c as caracter sticas do sistema, porm de forma mais bem estruturada; e Engenharia reversa: o processo de analisar um sistema com a nalidade de e criar sua representaao de uma forma diferente ou em um n mais alto de abstraao c vel c do que o cdigo fonte. Essa tecnologia descrita detalhadamente na seao 2.1; o e c Reengenharia: a reconstruao de algo do mundo real, tendo como propsito a e c o busca por melhorias que permitam produzir algo de qualidade melhor ou comparvel a ao produto inicial. A reengenharia detalhada na seao 2.2. e c No processo de manutenao, quando se trata de reconstruir um software (ou c seja, realizar sua reengenharia), necessrio, portanto, que se proceda ` engenharia e a a reversa do sistema em questo, a m de obter os modelos de anlise baseados no a a software existente. Esses modelos, com as devidas correoes/alteraoes, sero o c c a ponto de partida para a engenharia progressiva. O padro IEEE P1219/D14 (apud SAGE, 1995) para manutenao de software dea c ne a reengenharia como um subconjunto da engenharia de software, composta por engenharia reversa e engenharia progressiva.

2.1

Engenharia reversa

O processo inverso a engenharia progressiva, caracterizado pelas atividades retro` ativas do ciclo de vida, que partem de um baixo n de abstraao para um alto vel c n de abstraao, conhecido como engenharia reversa (CHIKOFSKY e CROSS, vel c e 1990). O termo engenharia reversa originou-se da anlise de hardware (CHIKOFSKY a e CROSS, 1990; REKOFF, 1985), que extra o projeto a partir do produto nal. Em a geral, aplicada para melhorar um produto ou para analisar um produto concorrente e ou de um adversrio (principalmente em situaao militar ou de segurana nacional). a c c Aplicando o conceito inicial de engenharia reversa a sistemas de software, muitas das tcnicas utilizadas em hardware servem para obter uma compreenso bsica do e a a sistema e sua estrutura. Entretanto, enquanto o objetivo bsico para hardware a duplicar o sistema, os objetivos mais freqentes para software so obter uma e u a compreenso suciente em n de projeto para auxiliar a manutenao, fortalecer o a vel c crescimento do sistema, e substituir o suporte.

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a 2.1.1 Denies co

37

Para Pressman, a engenharia reversa de software um processo de recuperaao de e c projeto, consistindo em analisar um programa, na tentativa de criar uma representaao do mesmo, em um n de abstraao mais alto que o cdigo-fonte (PRESSc vel c o MAN, 1995). Segundo Benedusi, pode-se denir engenharia reversa como uma coleao de teoc rias, metodologias, e tcnicas capazes de suportar a extrao e abstraao de ine ca c formaoes de um software existente, produzindo documentos consistentes, quer seja c a partir somente do cdigo fonte, ou atravs da adiao de conhecimento e experincia o e c e que no podem ser automaticamente reconstru a dos a partir do cdigo (BENEDUSI o et al., 1992 apud RAMAMOORTHY et al., 1996; CHIKOFSKY e CROSS, 1990). Para Samuelson, engenharia reversa geralmente entendida como a aao de e c criar um conjunto de especicaoes funcionais para um sistema, por algum que no c e a foi o projetista original, baseado na anlise de um sistema existente e suas partes a componentes (SAMUELSON, 1990 apud REKOFF, 1985). Segundo Waters e Chikofsky, o processo de anlise de um sistema para idena ticar os componentes de um software e seus inter-relacionamentos, e para criar uma representaao do software em outra forma, provavelmente num n c vel mais alto de abstraao que o cdigo fonte, constitui a engenharia reversa (WATERS e c o CHIKOFSKY, 1994). 2.1.2 Vises de software o

A partir da engenharia reversa e com base nos diferentes n veis e graus de abstraao, c o software pode ser visualizado de diferentes maneiras (HARANDI e NING, 1990): Viso em n a vel implementacional: abstrai caracter sticas da linguagem de programaao e caracter c sticas espec cas da implementaao; c Viso em n a vel estrutural: abstrai detalhes da linguagem de programaao c para revelar sua estrutura a partir de diferentes perspectivas. O resultado uma e representaao expl c cita das dependncias entre os componentes do sistema; e Viso em n funcional: abstrai a funao de um componente, isto , o que a vel c e o componente faz. Essa viso relaciona partes do programa `s suas funoes, procua a c rando revelar as relaoes lgicas entre elas (diferentemente das relaoes sintticas ou c o c a das estruturais); Viso em n de dom a vel nio: abstrai o contexto em que o sistema est operando, a ou seja, o porqu do sistema a ser desenvolvido. e E relevante ressaltar que uma forma de representaao extra do cdigo pode c da o diferir de uma representaao similar que foi desenvolvida no processo de engenharia c progressiva. A forma extra ir reetir a idiossincrasia da representaao do cdigo da a c o muito mais do que a representaao original, que reete a compreenso do problema c a pelo analista ou projetista. A Figura 2 mostra a correspondncia entre as categorias de visualizaao do softe c ware e as diferentes atividades do ciclo de desenvolvimento de software.

38

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

Figura 2: Visualizaoes de Software no Ciclo de Desenvolvimento (COSTA, 1997) c

Muitas vezes necessrio acrescentar as informaoes contidas no cdigo, outras e a ` c o informaoes provenientes de conhecimentos e experincias humanas, para se obter c e vises diferenciadas do software. Conforme o escopo das informaoes usadas, que o c resultaro em um n de entendimento obtido do sistema, pode-se formular uma a vel categorizaao dos mtodos de engenharia reversa. c e 2.1.3 Categorias

De acordo com o n vel de entendimento obtido do sistema e o escopo das informaoes usadas, duas categorias de engenharia reversa so denidas: visualizao c a ca de cdigo (OMAN, 1990) e entendimento de programa (CHIKOFSKY e CROSS, o 1990). Visualizao de cdigo ca o Tambm denominada redocumentao, a visualizaao de cdigo a criaao e ca c o e c ou reviso de representaoes semanticamente equivalentes num mesmo n de absa c vel traao (CHIKOFSKY e CROSS, 1990). O processo de visualizaao de cdigo cria as c c o representaoes a partir de informaoes obtidas apenas da anlise do cdigo fonte, c c a o embora a apresentaao dessas informaoes possa se diversicar. As formas das rec c presentaoes so consideradas vises alternativas, cujo objetivo melhorar a comc a o e preenso do sistema global. a A forma mais simples e mais antiga de engenharia reversa a visualizaao de e c cdigo. A intenao recuperar a documentaao que j existiu, ou que deveria o c e c a ter existido, sobre o sistema. A nfase, de fato, a criaao de vises adicionais, e e c o especialmente vises grcas, que no foram criadas durante o processo original de o a a engenharia progressiva. A visualizaao de cdigo no transcende a viso em n estrutural e no atribui c o a a vel a signicados ao sistema analisado. Recuperaoes mais ambiciosas tais como a funao, c c

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

39

os propsitos ou a essncia do sistema exigem um n de entendimento maior e so o e vel a denidas como entendimento de programa. Entendimento de programa Nesta categoria de engenharia reversa, tambm denominada recuperao de e ca projeto, o conhecimento do dom nio das informaoes externas e as deduoes so c c a adicionadas `s observaoes feitas sobre o sistema atravs do exame do mesmo, de a c e modo a obter informaoes com n mais alto de abstraao [CHIKOFSKY e CROSS, c vel c 1990). c Segundo Biggersta (1989), o entendimento de programa recria abstraoes do projeto a partir de uma combinaao de cdigo, documentaao existente do projeto c o c (se dispon vel), experincias pessoais e conhecimentos gerais sobre o problema e o e dom nio de aplicaao. Sintetizando, deve produzir todas as informaoes necessrias c c a para se entender completamente o que, como, e por que o sistema faz. Entendimento de programa distingue-se de visualizaao de cdigo porque objec o tiva entender o sistema, em vez de simplesmente fornecer vises alternativas para o auxiliar o usurio a entender o sistema. Esse entendimento vai alm do conhecia e mento em n implementacional e estrutural, buscando obter o conhecimento em vel n funcional e at mesmo em n de dom (ambiente de operaao do sistema). vel e vel nio c Um completo entendimento de programa busca reconstruir no somente a funao a c do sistema, mas tambm o processo pelo qual o sistema foi desenvolvido. Rugaber e et al. (1990) enfatizam a importncia da recuperaao de decises de projeto tomadas a c o durante o desenvolvimento original para uma completa estrutura de entendimento. A categoria de entendimento de programa a forma mais cr e tica de engenharia reversa, porque tenta aproximar-se do racioc humano na busca do entendimento. nio A Figura 3 apresenta a amplitude de alcance das categorias de engenharia reversa, relacionadas com o escopo das informaoes utilizadas (cdigo fonte ou base de c o conhecimento) e o n de visualizaao pretendida (implementacional, estrutural, vel c funcional e de dom nio).

Figura 3: Categorias da engenharia reversa e suas vises o

40

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

2.2

Reengenharia

O termo reengenharia est relacionado com a reconstruao de algo do mundo a c real, e independentemente de sua aplicaao, o seu principal propsito a busca c o e por melhorias que permitam produzir algo de qualidade melhor ou, pelo menos, de qualidade comparvel ao produto inicial. a 2.2.1 Denies co

Sendo a reengenharia de sistemas de software o foco deste artigo, a seguir so ina clu das denioes de diversos autores para que um n de compreenso mais amplo c vel a seja obtido. Para Chikofsky e Cross (1990), IEEE CS-TCSE (1997) e GT-REG (1998), a reengenharia, conhecida tambm como renovaao ou reconstruao, o exame e alteraao e c c e c de um sistema de software, para reconstitu em uma nova forma, e a subseqente -lo u implementaao dessa nova forma. Um processo de reengenharia geralmente inclui c alguma forma de engenharia reversa, seguida por uma forma de engenharia progressiva ou reestruturaao. c Para Warden (1992), a reengenharia tem como principal objetivo melhorar um sistema de alguma maneira, atravs de alteraoes signicantes que proporcionem e c melhoria, porm, sem alterar suas funoes. A extraao automtica da descriao de e c c a c uma aplicaao e sua implementaao em outra linguagem no considerada, segundo c c a e o autor, reengenharia, e sim traduao de cdigo. Do mesmo modo que Chikofsky, c o Warden considera que a reengenharia pode ser dividida em duas fases principais: a Engenharia Reversa e a Engenharia Progressiva; e cada uma destas fases pode ser dividida em uma srie de atividades. e Premerlani e Blaha (1994) citam que o objetivo da reengenharia reutilizar aue tomaticamente os esforos de desenvolvimento passados, objetivando reduzir custos c de manutenao e melhoria na exibilidade do software. c Segundo Pressman (1995), a reengenharia, tambm chamada de recuperaao ou e c renovaao, recupera informaoes de projeto de um software existente e usa essas c c informaoes para alterar ou reconstituir o sistema, preservando as funoes existentes, c c ao mesmo tempo em que adiciona novas funoes ao software, num esforo para c c melhorar sua qualidade global. Para Sommerville (1995), a reengenharia de software descrita como a reorgae nizaao e modicaao de sistemas de software existentes, parcial ou totalmente, para c c torn-los mais manuten a veis. Das diversas denioes elencadas, percebe-se que existe clara distinao entre o c c desenvolvimento de um novo software e reengenharia de software. A distinao est c a relacionada ao ponto de partida de cada um dos processos. O desenvolvimento de um novo software (denido como engenharia progressiva por Chikofsky e Cross (1990)) inicia-se com uma especicaao escrita do software que ser constru c a do, enquanto que a reengenharia inicia-se tomando como base um sistema j desenvolvido. a Nota-se, tambm, que existe distinao entre os objetivos da reengenharia e os e c da engenharia reversa. O objetivo da engenharia reversa derivar o projeto ou e

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

41

especicaao de um sistema, partindo-se de seu cdigo fonte (SOMMERVILLE, 1995). c o O objetivo da reengenharia produzir um sistema novo com maior facilidade de e manutenao e a engenharia reversa usada como parte do processo de reengenharia, c e pois fornece o entendimento do sistema a ser reconstru do. 2.2.2 Categorias

Sage (1995) indica diversas categorias de melhorias relacionadas a reengenharia, entre ` elas: Reengenharia de processos administrativos: direcionada para alteraoes e c potenciais em todos os negcios ou processos organizacionais; o Reengenharia de processos produtivos: consiste em modicar qualquer ciclo de processos padro, que esteja em uso em uma dada organizaao, a m de melhor a c acomodar as tecnologias novas e emergentes, bem como os requisitos dos clientes para um produto ou sistema; Reengenharia de sistemas de software ou produtos: o exame, estudo, captura e e modicaao de mecanismos internos ou funcionalidade de um sistema existente ou c produto, visando reconstitu em uma nova forma e com novas caracter -lo sticas, freqentemente para tomar vantagem das novas e emergentes tecnologias, mas sem u grandes alteraoes na funcionalidade e propsito inerentes ao sistema. c o Quando se efetua a reengenharia de processos administrativos, provavelmente ser necessrio efetuar reengenharia de software, visto que existe uma dependncia a a e impl cita entre os processos administrativos e o software (SOMMERVILLE, 1995).

Por que realizar a reengenharia

A tendncia de reengenharia dos processos das empresas so inuenciados por fatores e a tais como a necessidade de melhoria da qualidade dos servios e produtos oferecic dos, a compresso das margens de lucro, a reduao do ciclo de vida dos produtos, a c a diminuiao da interferncia dos governos e dos subs c e dios, a exploso tecnolgica, a o o rpido crescimento do conhecimento humano, a maturidade dos mercados de cona sumo e a globalizaao da economia. c Outros fatores so relacionados com a complexidade das atividades empresariais, a tais como a busca por produtividade; a exibilidade frente as constantes mudanas; ` c a concentraao no ramo de negcio; os relacionamentos com clientes, com o meio c o ambiente e com os governos; o apoio de consultores; a parceirizaao; a gesto e c a a remuneraao dos recursos humanos por resultados. Todos esses pontos inuenc ciam diretamente na reengenharia dos softwares existentes em empresas (HAMMER e CHAMPY, 1994). Alm disso, todos os sistemas tm um tempo de vida limitado, sendo que cada e e alteraao efetuada pode degenerar a sua estrutura, fazendo com que as manutenoes c c se tornem cada vez mais dif ceis e dispendiosas. Isso ocorre principalmente em software legado (JACOBSON e LINDSTROM, 1991).

42

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

3.1

Reengenharia de software legado

Um software legado pode ser informalmente denido como aquele que executa tarefas uteis para a organizaao, mas que foi desenvolvido utilizando-se tcnicas atualmente c e consideradas obsoletas (WARD e BENNETT, 1995). A quantidade de cdigo em o sistemas legados imensa. Em 1990, estimava-se (ULRICH, 1993) que existiam 120 e bilhes de linhas de cdigo fonte de sistemas desse tipo, a maioria em COBOL ou o o FORTRAN, linguagens com facilidades limitadas de estruturaao de programas e c dados. A migraao e/ou alteraao desse tipo de software gera desaos tcnicos c c e (por exemplo: vericar efeitos colaterais de uma alteraao) e no-tcnicos (por ex.: c a e estimar o custo de alteraao) a todos os envolvidos com manutenao de software. c c Existe um grande dilema na deciso sobre o futuro de software legado. Ao mesmo a tempo em que ele traz incorporado o acmulo de anos de experincia e renamento, u e traz tambm todos os v e cios e defeitos vigentes na poca de seu desenvolvimento, e mesmo que naquela poca, o que hoje chamado de v e e cio e defeito, fosse a melhor indicaao para o desenvolvimento de software (BENNETT, 1995). Por exemplo, c o tamanho do programa, que devido ` limitaao imposta pelo custo do hardware, a c tinha que ser reduzido, atualmente no crucial (devido ao barateamento dos coma e ponentes de hardware). Houve ainda a poca em que se prezava a ecincia, em e e detrimento da clareza e estruturaao do programa. Adicione-se a isso as sucessivas c manutenoes e conseqentes degeneraoes sofridas pelo software. Sabe-se hoje que c u c todos esses fatores esto diretamente relacionados com a diculdade de entendimento a de qualquer software legado. Muitos programas legados so cr a ticos para os negcios das organizaoes que os o c possuem. Eles tm embutidas informaoes dos negcios e procedimentos, que poe c o dem no estar documentados. O risco de remover e reescrever tais programas a e grande, pois muita informaao teria que ser redescoberta por tentativa e erro. Conc seqentemente, as organizaoes, de um modo geral, no aposentam seus sistemas u c a legados, preferindo mant-los em operaao, com adaptaoes `s novas necessidades. e c c a As diculdades devem ser enfrentadas, pois qualquer software que no evoluir cona tinuamente (sofrer manutenoes) tornar-se- menos util no mundo real (LEHMAN, c a 1980). Segundo Bennett (1991), os maiores problemas em manter software legado so: a Desestruturaao e diculdade de entendimento do cdigo, muitas vezes porque c o o software foi desenvolvido antes da introduao dos mtodos de programaao estruc e c turada; Programadores que no participaram do desenvolvimento de um produto de a software sentem diculdade em entender e mapear a funcionalidade para o cdigo o fonte; Documentaao desatualizada, no auxiliando em nada a equipe de manutenao; c a c Diculdade de predizer as conseqncias de efeitos colaterais; ue Diculdade de administrar mltiplas alteraoes concorrentes. u c A complexidade e tamanho dos programas legados tm inuncia direta no custo e e de manutenao dos mesmos (RAMAMOORTH e TSAI, 1996). Pesquisas revelam que c

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

43

mais de 50% do custo de um produto de software est relacionado com as atividades a de manutenao, havendo casos de este percentual chegar at a 85% (LAYZELL et c e al., 1995). Em alguns negcios, estima-se que 80% de todos os gastos com software so cono a sumidos pelas manutenoes e evoluoes dos sistemas (YOURDON, 1990). O nmero c c u de sistemas que precisa ser modicado est aumentando gradualmente. Existe la de a espera para pedidos de manutenao. Isto signica que, algumas vezes, imposs c e vel para as organizaoes investirem em novos sistemas para melhorar a ecincia orgac e nizacional. O problema de manutenao de sistemas legados complexo porque, geralmente, c e esses sistemas no so simples programas, desenvolvidos e mantidos. Muitos deles a a so compostos de outros diferentes programas que, de alguma forma, compartilham a dados. Tambm ocorre que esses programas foram desenvolvidos por diferentes e pessoas ao longo dos anos, as quais no esto mais na organizaao. Muitas vezes foi a a c usado um sistema de administraao de bases de dados que pode estar obsoleto, ou c depende de arquivos armazenados separadamente. No caso de arquivos separados, cada um tem seu prprio formato e, freqentemente, as mesmas informaoes so o u c a duplicadas e representadas em diferentes formas e em diferentes arquivos. Essa duplicaao usualmente acontece porque as informaoes so fortemente integradas c c a com as estruturas de dados dos programas. Com o objetivo de minimizar os problemas gerados por manutenoes dif c ceis e, algumas vezes, degenerativas da estrutura do sistema, muitas organizaoes esto c a optando por refazer seus sistemas. A idia bsica dessa reconstruao ou reengee a c nharia que as informaoes de projeto e especicaao sejam extra e c c das do cdigo o fonte, reformuladas e reconstru das, resultando um software mais fcil de ser mantido a (BENNETT, 1991). Aplicando-se a reengenharia de software, o sistema pode ser redocumentado ou reestruturado, os programas podem ser traduzidos para uma linguagem de programaao mais moderna e implementados em uma plataforma distribu bem como c da, seus dados podem ser migrados para uma base de dados diferente. A reengenharia de software objetiva fazer sistemas ex veis, fceis de modicar, frente `s constantes a a mudanas das necessidades dos usurios. c a O campo da reengenharia est crescendo rapidamente em resposta a necessidade a ` cr tica que existe na indstria de software por tecnologia que suporte a manutenao u c de sistemas legados e o desenvolvimento evolutivo de novos sistemas. Existe uma rme e crescente demanda para migrar programas legados de mainframes monoprocessados, para estaoes multiprocessadas, distribu c das e ligadas em rede, visando acompanhar os avanos das tcnicas de programaao tais como: interfaces grcas c e c a para o usurio, comunicaao interprogramas, desenvolvimento orientado a objetos, a c reusabilidade, etc. (RUGABER e WILLS, 1996; SNEED e NYARY, 1995). Tambm o e desenvolvimento de novos projetos de software devero se deparar, cada vez mais, a com processos de reengenharia (COLEMAN et al., 1994).

44

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

3.2

Migrao do paradigma procedimental para o de orientao a ca ca objetos

Atualmente, a fase de transiao que a comunidade de informtica est enfrentando c a a para migrar software das plataformas centralizadas (mainframes) para ambientes de processamento distribu em arquitetura cliente/servidor, mostra a importncia do a da reengenharia, o que implica, muitas vezes, o mover de uma arquitetura orientada a aao (paradigma procedimental) para uma arquitetura orientada a objetos c (paradigma de orientaao a objetos) (SNEED, 1992; MITTRA, 1995). c c Para Newcomb e Kotik (1995), a programaao orientada a objetos tem muitas vantagens sobre a programaao procedimental, pois possibilita construir sistemas c altamente ex veis, adaptveis e extens a veis; possui uma coleao rica de mecanismos c composicionais para formaao de classes, instanciaao de objetos, propriedades de c c herana, polimorsmo e ocultamento de informaoes, que esto presentes em linc c a guagens de programaao orientadas a objetos, as quais provem apoio para criar c e sistemas que exibem um alto grau de reuso e facilidade de manutenao. c Gall e Klosch (1995) citam vrios motivos para migraao do paradigma procedia c mental para o paradigma de orientaao a objetos: c Em programas procedimentais, muito dif prever efeitos colaterais, pois e cil freqentemente os relacionamentos no so vis u a a veis; Manutenoes sucessivas requerem um conhecimento detalhado dos compoc nentes do sistema, como foram criados e modicados e seus inter-relacionamentos; A reusabilidade de software tambm seriamente afetada pela estrutura e e prpria dos programas procedimentais; o A orientaao a objetos oferece algumas caracter c sticas uteis, tais como meios de abstraao bem denidos, conceito de encapsulamento e comportamentos que c efetivamente apiam o processo de manutenao de software; o c A identicaao de objetos nos programas procedimentais, exibindo explicitac mente suas dependncias, ajuda a entender o projeto do sistema, evita a degradaao e c do projeto original durante as manutenoes e facilita o processo de reuso. c

Como realizar a reengenharia

O processo de reengenharia de software constitu de duas fases distintas. Na e do primeira, o software objeto de reconstruao desmontado, visando seu entendic e mento. Na segunda, o software reconstru e do, na forma desejada, a partir do produto da primeira fase, sendo inclu dos os ajustes que se zerem necessrios. a O processo de Reengenharia pode ser traduzido como (JACOBSON e LINDSTROM, 1991): Reengenharia = Engenharia Reversa + Engenharia Progressiva onde pode ser de dois tipos:

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

45

Alteraes parciais de funcionalidade (Alteram parcialmente o objetivo co principal do sistema): ocorrem devido a mudanas nos negcios, ou necessidade do c o usurio; a Alteraes de implementao (Alteram a forma de implementaao do co ca c sistema): ocorrem devido a alteraoes no ambiente de operaao do software e ou c c linguagem de implementaao (protocolos, sistema operacional, portabilidade, linc guagens, etc.). Existem alguns pontos que devem ser considerados para um processo de reengenharia (WARDEN, 1992): Deve ser executado somente se existir um argumento aceitvel de custo/benef a cio; Implica melhoria atravs de reprojeto; e Deve remover projetos ruins, mas reconhecer e manter projetos bons e simples, mesmo que eles sejam desestruturados; A Engenharia Reversa dirigida por tipos de problemas, os quais necessitam e ser identicados; Os problemas so identicados e expressos como violaoes as tcnicas de a c ` e projeto estruturado e regras de programaao, ou outras que o usurio pode denir; c a Ferramentas devem ser adequadas aos processos de reengenharia, e no os a processos adequados `s ferramentas. a

4.1

O processo de reengenharia

Jacobson e Lindstrm (1991) declaram que, para executar um processo de reengeo nharia de um sistema, necessrio: e a Realizar a engenharia reversa: identicar como os componentes do sistema se relacionam uns aos outros e ento criar uma descriao mais abstrata do a c sistema. Um exemplo de identicaao de relacionamentos entre componentes pode c ser a identicaao de dependncias entre os arquivos e as funoes, entre as funoes c e c c e as descrioes da base de dados, etc. Um exemplo da criaao de uma descriao c c c mais abstrata do sistema pode ser um diagrama de uxo de dados para as funoes c e o modelo entidade-relacionamento para as descrioes da base de dados. Com esse c primeiro passo, obtm-se um modelo abstrato, que mostra a funcionalidade do sise tema (propsito para o qual o sistema foi construido) e um nmero de mapeamentos o u entre os diferentes n veis de abstraao. Os mapeamentos compreendem as decises c o de projeto que ocorrem quando se transforma uma representaao abstrata em uma c representaao concreta; c Decidir sobre alteraes na funcionalidade: as alteraoes de funcionaco c lidade so as alteraoes nos requisitos que o usurio determina que sejam implea c a mentadas no sistema. Esse passo executado utilizando-se as abstraoes de mais e c alto n vel, obtidas no passo anterior. Sem o modelo abstrato, necessrio decidir e a questes de alto n utilizando-se comandos de baixo n (por exemplo, um coo vel vel mando de alto n tal como Altere a associaao entre as entidades X e Y deveria vel c ser traduzido para um outro de baixo n vel, tal como Adicione uma tabela que contenha as referncias entre X e Y); e

46

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

Reprojetar o sistema: parte-se das abstraoes de alto n c vel, obtidas nos passos anteriores, para uma representaao mais concreta, ou seja, executa-se a enc genharia progressiva reimplementando o sistema. Neste processo, deve-se levar em consideraao as alteraoes de tcnicas de implementaao. Se apenas parte do sistema c c e c for alterado, devem-se considerar questes sobre a integraao/comunicaao entre as o c c partes velhas e novas do sistema. Gall e Klosch (1995) relatam um processo para se encontrar objetos em programas procedimentais. Esse processo de identicaao de objetos baseado nas informaoes c e c derivadas do cdigo fonte, integradas com conhecimento espec o co do sistema e do dom nio da aplicaao, os quais resultam em representaoes das semnticas das c c a aplicaoes em objetos. A identicaao de objetos inicia-se com a geraao de docuc c c mentos de projeto de baixo n vel, como diagramas estruturados e diagramas de uxo de dados, sendo estes a base para o processo de identicaao dos objetos. c Sneed e Nyry (1995) descrevem uma abordagem para extrair automaticamente a documentaao de projeto, orientada a objetos a partir de programas escritos em c COBOL para mainframe; mapas ou painis para comunicaao com o usurio; bases e c a de dados armazenados e cartes de controle de execuao do programa. o c c c Yeh et al. (1995) abordam a recuperaao de representaoes arquiteturais de software, partindo do cdigo fonte. A experincia inclui desenvolvimento, impleo e mentaao e teste de uma abordagem interativa para recuperaao de tipos abstratos c c de dados (TADs) e instncias de objetos extra a dos de programas escritos em linguagens convencionais como C. Newcomb e Kotik (1995) descrevem uma ferramenta de reengenharia para transformar automaticamente um sistema procedimental em sistema orientado a objetos sem alteraao de funcionalidade. O processo de transformaao em forma orientada c c a objetos localiza dados e procedimentos redundantes, duplicados e similares, e os abstrai em classes e mtodos. e Segundo Ramamoorthy e Tsai (1996), os mtodos de engenharia reversa exise tentes at o momento no recuperam de modo automtico todas as vises do softe a a o ware. Isso acontece basicamente porque a fase de implementaao - caracterizada c principalmente por programas fonte e descriao de arquivos - no contm todas as c a e informaoes essenciais para o processo de engenharia reversa, as quais so providas c a pela fase de anlise, sendo necessria a intervenao humana para extrair boas reprea a c sentaoes de projetos de software, principalmente em n c veis mais altos de abstraao c (TANGORRA e CHIAROLLA, 1995).

4.2

Ferramentas de aux ` reengenharia lio a

Existem ferramentas com a nalidade de auxiliar a execuao da reengenharia. A c maioria das ferramentas so utilizadas na etapa de engenharia reversa do sistema a a ser reconstru do. a Segundo Pressman (1995), as ferramentas baseadas em engenharia reversa esto ainda engatinhando, cando claro que as pesquisas na area de entendimento de cdigo so muito importantes e muitas outras pesquisas ainda acontecero. o a a

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

47

As ferramentas devem ser adequadas aos processos de reengenharia, e no os a processos adequados as ferramentas. As ferramentas de suporte dispon ` veis para auxiliar a reengenharia tm inuncia sobre os custos de reengenharia. e e Existem muitas ferramentas de reengenharia com aplicabilidade em sistemas de software. O Quadro 1 apresenta vrias dessas ferramentas, mostrando de onde a provm as informaoes de entrada e o que cada uma delas produz como resultado. e c

Quadro 1: Escopo das informaoes utilizadas por ferramentas de reengenharia, as c respectivas vises e outras sa o das produzidas.

O escopo das informaoes que cada ferramenta utiliza so provenientes: c a do cdigo fonte do software: cada ferramenta trabalha com cdigo em detero o minada linguagem (pr-denida); e da base de conhecimento do sistema: constitu por documentaao existente, da c informaoes de usurios ou projetistas do software e bibliotecas de componentes, c a entre outras.

48

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

Em relaao aos resultados produzidos, quando apenas o cdigo fonte utilizado c o e como entrada, as vises fornecidas so, em geral, em n implementacional e eso a vel trutural. Para se obter vises mais abstratas (funcional e de dom o nio), bem como outras sa das, necessrio utilizar como entrada, alm do cdigo fonte, bases de e a e o conhecimento sobre o sistema.

Consideraes nais co

Este artigo no aborda exaustivamente todo o contedo relacionado ` reengenharia a u a de software. Sendo destinado ao apoio pedaggico, o enfoque maior est nas denioes o a c o que a reengenharia e outros termos relacionados a manutenao de software e c e na aplicabilidade dessa atividade por que realizar a reengenharia de um software. O como, ou seja, a forma de realizar a reengenharia em um software depende de muitos fatores, relacionados, por exemplo, com a forma de trabalho da empresa, a origem do software em questo e com o desenvolvimento de tecnologias para apoiar a essa atividade. Algumas ferramentas dispon veis foram inclu das, com o intuito de fornecer uma viso geral de como executar a reengenharia de um software. a A importncia da reengenharia est em possibilitar que todo conhecimento agrea a gado ao software legado no seja perdido, o que aconteceria se a opao fosse pelo a c desenvolvimento de um novo software. O processo de extraao do conhecimento de um software legado realizado pela c e engenharia reversa, que fornece vises mais abstratas do que o cdigo do sistema e/ou o o alguma outra documentaao possivelmente existente. Com essas vises poss c o e vel compreender o software e o sistema em que est inserido, possibilitando a produao a c de modelos de anlise que serviro a reengenharia. a a ` Da reengenharia de um software resulta uma nova verso, que agrega toda a a informaao do software legado, as inovaoes tecnolgicas e novas funcionalidades c c o desejadas. Dessa forma, a reengenharia de software no trata apenas de moderniza a lo, mas tambm adapt-lo de acordo com as novas necessidades do processo em que e a est inserido. a

Referncias e
BENEDUSI, P.; CIMITILE, A.; CARLINI, U. Reverse Engineering Processes, Design

Document Production, and Structure Charts. Journal Systems and Software, v. 19, 1992, p. 225-245.
BENNETT, K. H. Automated Support of Software Maintenance. Information and

Software Technology, v. 33, n.1, 1991, p. 74-85.

BENNETT, K. H. Legacy Systems: coping with success. IEEE Software, v. 12, n. 1,

1995, p. 19-23.
BIGGERSTAFF, T. J. Design Recovery for Maintenance and Reuse. IEEE Computer,

v. 22, n. 7, 1989, p. 36-49.

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

49

CANFORA, G.; CIMITILE, A.; MUNRO, M. RE2: Reverse-engineering and Reuse Re-

engineering. Journal of Software Maintenance: Research and Practice, v. 6, n. 2, 1994, p. 53-72.

CHIKOFSKY, E. J. e CROSS II, J. H. Reverse Engineering and Design Recovery:

A Taxonomy. IEEE Software, v. 7, n. 1, 1990, p. 13-17.

CHIN, D. N.; QUILICI, A. DECODE: A Co-operative Program Understanding

Environment. Journal of Software Maintenance: Research and Practice, v. 8, n. 1, 1996, p. 3-33.

COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H.; HAYES, F. e JEREMAES, P. Object-Oriented Development: THE FUSION METHOD.

Englewood Clis, New Jersey: Prentice Hall, 1994.

COSTA, R. M. Aplicaao do Mtodo de Engenharia Reversa FUSION-RE/I na c e

Recuperaao da Funcionalidade da Ferramenta de Teste PROTEUM. So Carlos: c a ICMSC-USP, 1997. Dissertaao (mestrado). c
GALL, H. e KLOSCH, R. Finding Objects in Procedural Programs: An alternative

Approach. In: Proceedings of Second Working Conference on Reverse Engineering. Monterey, EUA: 1995, p. 208-216.
GT-REG (Georgia Techs - Reverse Engineering Group). Glossary of Reengineering

Terms. Georgia, http://www.cc.gatech.edu/reverse/glossary.html, 1998.

HAMMER, M.; CHAMPY, J. Reengenharia: revolucionando a empresa em funao c

dos clientes, da concorrncia e das grandes mudanas da gerncia. Rio de e c e Janeiro: Campus, 1994. HARANDI, M. T.; NING, J. Q. Knowledge-Based Program Analysis. IEEE Software v. 7, n. 1, 1990, p. 74-81.
IEEE CS-TCSE (IEEE Computer Society - Technical Council on Software Engineer-

ing). Reengineering & Reverse Engineering Terminology. Washington, http://www.tcse.org/revengr/taxonomy.html, 1997.

JACOBSON, I.; LINDSTROM, F. Re-egineering of old systems to an object-oriented

architeture. SIGPLAN Notices, v. 26, n. 11, 1991, p. 340-350.

KRAMER, C.; PRECHELT, L. Design Recovery by Automated Search for Structural

Design Patterns in Object-Oriented Software. In: Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p. 208-215.
LAYZELL, P. J.; FREEMAN, M. J.; BENEDUSI, P. Improving Reverse-engineering

through the Use of Multiple Knowledge Sources. Journal of Software Maintenance: Research and Practice, v. 7, n. 4, 1995, p. 279-299.
LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution. Proc.

IEEE, 1980, p. 1060-1076.

MITTRA, Sitansu S. A Road Map for Migrating Legacy Systems to Client/Server.

Journal of Software Maintenance: Research and Practice, v. 8, n. 2, 1995, p. 117-130.

50

Revista Cincias Exatas e Naturais, Ano 1, no . 2, Jan/Jun 2000 e

MORRIS, P.; FILMAN, R. Mandrake: A Tool for Reverse-Engineering IBM Assem-

bly Code. In: Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p. 57-66.
NEWCOMB, P. e KOTIK G. Reengineering Procedural Into Object-Oriented Systems.

In: Proceedings of Second Conference on Reverse Engineering, Toronto, Canada, 1995, p. 237-249.
OMAN, P.W. Maintenance Tools. IEEE Software, v. 7, n. 3, 1990, p. 59-65. OSBORNE, W.M.; CHIKOFSKY, E.J. Fitting Pieces to the Maintenance Puzzle. IEEE

Software, v. 7, n. 1, 1990, p. 11-12.

PREMERLANI, W. J. e BLAHA, M. R. An Approach for Reverse Engineering of Re-

lational Databases. Communications of the ACM, v. 37, n. 5, 1994, p. 42-49.

PRESSMAN, R. S. Engenharia de Software. So Paulo: Makron Books, 1995. a RAMAMOORTHY, C. V.; TSAI, W. Advances in Software Engineering. IEEE

Computer, v. 29, n. 10, 1996, p. 47-58.

REKOFF Jr., M. G. On Reverse Engineering. IEEE Transaction on Systems. Man,

and Cybernetics, v. 15, n. 2, maro/abril, 1985. c

RUGABER, S. e WILLS, L. M. Creating a Research Infrastructure for Reengineering.

In: Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p. 98-102. RUGABER, S. et al. Recognizing Design Decision in Programs. IEEE Software, v. 7, n. 1, 1990, p. 46-54.
SAGE, A.P. Systems Engineering and Systems Management for Reengineering.

Journal Systems and Software, v. 30, n. 1, 1995, p. 3-25.

SAMUELSON, P. Reverse-Engineering Someone Elses Software: Is It Legal? IEEE

Software, v.1, n. 1, 1990, p. 90-96.

SNEED, H. M. e NYARY, E. Extracting Object-Oriented Specication from Procedu-

rally Oriented Programs. In: Proceedings of Second Conference on Reverse Engineering. Toronto, Canada, 1995, p. 217-226.
SNEED, H. M. Object-Oriented COBOL Recycling. In: Proceedings of Third Working

Conference on Reverse Engineering. Monterey, EUA, 1996, p. 169-178.

SNEED, H. M. Migration of Procedurally Oriented COBOL Programs in an Object-

Oriented Architeture. In: Proceedings of Conference on Software Maintenance, Orlando, EUA, 1992, p. 105-116.
SOMMERVILLE, I. Software Engineering (International Computer Science Series).

5a Ediao. Reading: Addison-Wesley, 1995. c

TANGORRA, F.; CHIAROLLA, D. A methodology for reverse engineering hierarchical

databases. Information and Software Technology, v. 37, n. 4, 1995, p. 225-231.

Ana Elisa Tozetto Piekarski e Marcos Antonio Quinia a

TONELLA, P. et al. Augmenting Pattern-Based Architetural Recovery with Flow

51

Analisys: Mosaic - A Case Study. In: Proceedings of Third Working Conference on Reverse Engineering, Monterey, EUA, 1996, p. 198-208. ULRICH, W. M. Re-engineering: Dening an integrated migration framework. In: Software Reengineering (R. S. Arnold, ed.). Los Altos, California: IEEEE Computer Society Press, 1993, p. 108-118. WARD, M. P.; BENNETT, K. H. Formal Methods for Legacy Systems. Journal of Software Maintenance: Research and Practice, v. 7, n. 3, 1995, p. 203-219. WARDEN, R. Re-engineering - A Pratical Methodology With Commercial Applications. In: Applied Information Tecnology 12 (Software Reuse and Reverse Engineering in Practice). (P. A. V. Hall, ed.) - Chapman@Hall, 1992. WATERS, R. C.; CHIKOFSKY, E. J. Reverse Engineering: Progress Along Many Dimensions. Communications of the ACM, v. 37, n. 5, 1994, p. 23-24. WONG, K. et al. Structural Redocumentation: A Case Study. IEEE Software, v. 12, n. 1, 1995, p. 46-54. YEH, A. S.; HARRIS, D. R. e REUBENSTEIN, H. B. Recovering Abstract Data Types and Object Instances from a Conventional Procedural Language. In: Proceedings of Second Conference on Reverse Engineering. Toronto, Canada, 1995, p. 227-236. YOURDON, E. Anlise Estruturada Moderna. Rio de Janeiro: Editora Campus, a 1990.