PRE/OO UM PROCESSO DE REENGENHARIA ORIENTADA A OBJETOS

Transcrição

1 UNIVERSIDADE FEDERAL DE SÃO CARLOS CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO PRE/OO UM PROCESSO DE REENGENHARIA ORIENTADA A OBJETOS COM ÊNFASE NA GARANTIA DA QUALIDADE *,=(//(6$1'5,1,/(026 Diertação apreentada ao Programa de Pó-Graduação em Ciência da Computação do Departamento de Computação da Univeridade Federal de São Carlo, como parte do requiito para obtenção do título de Metre em Ciência da Computação Orientadora: Prof.ª Dr.ª Roângela Aparecida Delloo Penteado 6mR&DUORV

2 )LFKDFDWDORJUiILFDHODERUDGDSHOR'H37GD %LEOLRWHFD&RPXQLWiULDGD8)6&DU L557pr Lemo, Gizelle Sandrini. PRE/OO Um proceo de reengenharia orientada a objeto com ênfae na garantia da qualidade / Gizelle Sandrini Lemo São Carlo : UFSCar, p. Diertação (Metrado) Univeridade Federal de São Carlo, Engenharia de oftware. 2. Reengenharia orientada a objeto. 3. Qualidade de proceo. I. Título. CDD: (20ª)

3 Dedica tória 'HGLFRHVWHWUDEDOKR DRVPHXVSDLV DRPHXPDULGR0iULR3UDGRHDRPHXILOKR0iULR/HPRV

4 Agra decim en to À Profª. Drª. Roângela A. D. Penteado pela paciência, ugetõe e orientação indipenávei. Ao meu marido Mário Prado pelo companheirimo e carinho, pela dedicação junto ao noo filho durante ee período, pela ugetõe e ajuda que muito contribuíram para a concluão dee trabalho. Ao meu filho Mário Lemo pela paciência e compreenão e por aceitar a vária negativa quanto à diponibilidade de atenção. Ao meu pai Ernani e Aparecida pelo incentivo e auxílio memo à ditância. Ao meu irmão Amanda e Marco pelo apoio e carinho. À querida amiga Angelita Segovia por me eninar a trabalhar empre com eriedade e confiança e por me ouvir no momento difícei. À colega Regiane Marucci e Débora Diniz pela amizade e ajuda durante o curo. Ao Edon Recchia e à Maria Ângela pela experiência, pelo conelho e pelo material fornecido para utilização em meu trabalho. Ao amigo da Aociação Luz e Caridade pela força tranmitida, eencial em meu equilíbrio. Ao querido Metre Jeu e à Deu, Pai Maior.

5 Re u m o Ete trabalho apreenta um proceo, denominado PRE/OO (Proceo de Reengenharia Orientada a Objeto), que via conduzir a reengenharia de itema legado procedimentai para itema orientado a objeto. O proceo é epecificado na forma de ete FOXVWHUV, compoto por vinte padrõe, que atendem à eguinte etapa: planejamento do proceo, engenharia revera e engenharia avante endo doi FOXVWHUV epecialmente criado para a garantia de qualidade, aplicando-e um dele durante todo o proceo. O PRE/OO foi compoto com bae na evolução do Fuion/RE utilizando a UML para modelagem do diagrama gerado. O proceo é realizado de forma evolutiva, permitindo o retorno a etapa anteriore. Algun do padrõe de engenharia revera foram elaborado com bae na FaPRE/OO, uma família de padrõe de reengenharia orientada a objeto. O FOXVWHUVde garantia da qualidade foram elaborado a partir de KPA do nível 2 de maturidade do SW-CMM. O trabalho concentra-e na aplicação da reengenharia em itema deenvolvido no ambiente Delphi, que não e beneficiam da vantagen do paradigma da orientação a objeto, inerente à linguagem 2EMHFW 3DVFDO. O ambiente de programação em quetão é um do mai utilizado por emprea e profiionai, para a implementação de itema informatizado. Entretanto, por ua flexibilidade e facilidade de aprendizado, divero programadore em experiência nee paradigma e, muita veze, acotumado à programação procedimental em linguagen como &OLSSHU ou COBOL, ub-utilizam a capacidade do ambiente e implementam aplicaçõe em o uo de eu conceito. Como reultado ão gerado itema complexo, mal documentado e de difícil expanão e manutenção. Um etudo de cao é apreentado em que um itema legado, implementado em caracterítica orientada a objeto, foi ubmetido ao PRE/OO para exemplificar eu uo. Como reultado obteve-e a verão re-implementada do itema que utiliza plenamente o conceito da orientação a objeto e toda a documentação do memo.

6 $EVWUDFW Thi work preent a proce, called PRE/OO (Object Oriented Reengineering Proce) which aim to help the reengineering proce from procedural legacy ytem to object oriented ytem. The proce i pecified in the form of even cluter compoed of twenty pattern including the following phae: proce planning, revere engineering and forward engineering. Two cluter were ued for quality aurance applied during the proce. The PRE/OO i baed on the Fuion/RE evolution and ue the UML for modeling the ytem diagram. The entire proce i built in an evolutive context, where the oftware engineer can return at any time to earlier proce tep. Some revere engineering pattern were created baed on the FaPRE/OO (an object oriented reengineering pattern family). The quality aurance cluter were created baed on the econd level KPA in the SW-CMM. The work focu on the application of reengineering proce for ytem developed in the Delphi environment which were projected/developed without uing the concept of the Object Orientation Paradigm, inherent in the Object Pacal language. Although the Delphi programming environment i largely ued by companie and profeional developer not all of them are able to ue thi feature and capabilitie to a full extent becaue they either lack the proper knowledge for uing OOP or they are till uing old programming technique (e.g. from Cobol or Clipper). The final reult are normally complex ytem, with very few documentation and difficult maintenance and expanion. A cae tudy i preented uing a legacy ytem, that did not ue the OOP concept in it development. Thi ytem wa ubmitted to the PRE/OO proce. The reult wa one new verion of the ytem that complie with the OOP concept and it repective documentation.

7 Su m á rio &$3Ì78/2,1752'8d CONSIDERAÇÕES INICIAIS CONTEXTUALIZAÇÃO E OBJETIVOS DA PESQUISA MOTIVAÇÃO DA MONOGRAFIA ORGANIZAÇÃO DA DISSERTAÇÃO...4 &$3Ì78/25(9,6 2%,%/,2*5É),&$ 2.1. CONSIDERAÇÕES INICIAIS ENGENHARIA REVERSA MÉTODO FUSION/RE REENGENHARIA SEGMENTAÇÃO MANUTENÇÃO PADRÕES PARA REALIZAÇÃO DE REENGENHARIA QUALIDADE NO PROCESSO DE SOFTWARE pWRGRVGH0HOKRULDGD4XDOLGDGH 0RGHORVGH0DWXULGDGH 2.9. UML (UNIFIED MODELING LANGUAGE) O AMBIENTE DE PROGRAMAÇÃO DELPHI CONSIDERAÇÕES FINAIS...39 &$3Ì78/22352&(662'(5((1*(1+$5,$25,(17$'$$2%-( CONSIDERAÇÕES INICIAIS O PROCESSO DE REENGENHARIA ORIENTADA A OBJETOS (PRE/OO) PADRÕES DE MELHORIA DA QUALIDADE DO PRE/OO PADRÕES DE ENGENHARIA REVERSA DO PRE/OO PADRÕES DE ENGENHARIA AVANTE DO PRE/OO CONSIDERAÇÕES FINAIS...98 &$3Ì78/2(678'2'(&$62$5((1*(1+$5,$'(8062)7:$5('(/3+, 4.1. CONSIDERAÇÕES INICIAIS DESCRIÇÃO DO SOFTWARE LEGADO PREPARAÇÃO E PLANEJAMENTO DO PROCESSO DE REENGENHARIA COM O PRE/OO REALIZAÇÃO DA ETAPA DE ENGENHARIA REVERSA DO PRE/OO REALIZAÇÃO DA ETAPA DE ENGENHARIA AVANTE DO PRE/OO CONSIDERAÇÕES FINAIS...136

8 &$3Ì78/280$(67,0$7,9$'2&8672;%(1()Ì&,23$5$2352&(662'( 5((1*(1+$5,$25,(17$'$$2%-( CONSIDERAÇÕES INICIAIS CUSTOS X BENEFÍCIOS DO PLANEJAMENTO DO PROCESSO DE REENGENHARIA ORIENTADA A OBJETOS CUSTOS X BENEFÍCIOS DA ENGENHARIA REVERSA CUSTOS X BENEFÍCIOS DA ENGENHARIA AVANTE CONSIDERAÇÕES FINAIS &$3Ì78/2&21&/86 (6(3(563(&7,9$6)8785$ CONCLUSÕES CONTRIBUIÇÕES DESTE TRABALHO SUGESTÕES PARA TRABALHOS FUTUROS ()(5È1&,$6%,%/,2*5É),&$6

9 Li ta de Figu ra FIGURA 2.2.1: NÍVEL E GRAU DE ABSTRAÇÃO NO CICLO DE VIDA DO SOFTWARE (CHIKOFSKY, 1990)...6 FIGURA 2.3.1: ESQUEMA DO MÉTODO FUSION/RE (PENTEADO., 1998A)...10 FIGURA 2.7.1: AGRUPAMENTO DOS QUATRO DA LINGUAGEM DE PADRÕES DE DEMEYER.(2000B)...15 FIGURA 2.7.2: & DA FAMÍLIA DE PADRÕES DE REENGENHARIA OO DE RECCHIA (2002A)...16 FIGURA 2.8.1: ABORDAGEM IDEAL (GREMBA, 1997)...21 FIGURA 2.8.2: CICLO PDCA (CAMPOS, 1992)...22 FIGURA 2.8.3: NÍVEIS DE MATURIDADE DO SW-CMM (PAULK., 1993A)...27 FIGURA 2.8.4: ESTRUTURA DAS KPAS DO SW-CMM (FIORINI., 1998)...36 FIGURA 2.9.1: FORMAÇÃO DA UML. ADAPTADA DE (PRADO, 2001)...37 FIGURA 3.1.1: ORIGENS DO PRE/OO...41 FIGURA 3.2.1: VISÃO GERAL DOS & DE PADRÕES DO PRE/OO...43 FIGURA 3.3.1: EXEMPLO DE DOCUMENTAÇÃO DO LEVANTAMENTO DE ATIVIDADES...49 FIGURA 3.3.2: EXEMPLO DE DOCUMENTAÇÃO DO PLANO PARA REALIZAÇÃO DA REENGENHARIA...53 FIGURA 3.3.3: EXEMPLO DE DOCUMENTAÇÃO DA INSPEÇÃO DE ACOMPANHAMENTO DO PROCESSO...56 FIGURA 3.3.4: LISTA DE CONTROLE DE CONFIGURAÇÃO REFERENTE AO SISTEMA DE CONTROLE DE LOCAÇÕES DE VÍDEOS...61 FIGURA 3.3.5: PRIMEIRA % DE PROJETO REFERENTE AO SISTEMA DE CONTROLE DE LOCAÇÕES DE VÍDEOS...61 FIGURA 3.4.1: VISÃO PARCIAL DA LISTA DE PROCEDIMENTOS E FUNÇÕES PARA O SISTEMA DE LOCAÇÕES DE VÍDEOS...65 FIGURA 3.4.2: VISÃO PARCIAL DA LISTA "CHAMA/CHAMADO POR" DO SISTEMA DE LOCAÇÕES DE VÍDEOS 68 FIGURA 3.4.3: TRECHO DE SQL DO ARQUIVO DE DADOS CLIENTE E LISTA DE TABELAS E CHAVES CORRESPONDENTE...71 FIGURA 3.4.4: MER REFERENTE AO SISTEMA DE LOCAÇÕES DE VÍDEOS...71 FIGURA 3.4.5: INSPEÇÃO DE GARANTIA DA QUALIDADE REALIZADA NO MER...72 FIGURA 3.4.6: CÓDIGO-FONTE DO PROCEDIMENTO DE LOCAÇÃO DE UM VÍDEO...74 FIGURA 3.4.7: EXEMPLO DE UM TRECHO DA LISTA DE ANOMALIAS DO SISTEMA DE LOCAÇÕES DE VÍDEOS 74 FIGURA 3.4.8: VISÃO PARCIAL DO DIAGRAMA DE PSEUDO-CLASSES DO SISTEMA DE LOCAÇÕES DE VÍDEOS...76 FIGURA 3.4.9: TELA CORRESPONDENTE AO CADASTRO DE CLIENTES DO SISTEMA DE LOCAÇÕES DE VÍDEOS...77 FIGURA : DIAGRAMA DE USE CASES DO MASA RELATIVO A INTERFACE DA FIGURA FIGURA : DESCRIÇÃO DO CLIENTESBTNPRINTLOCACOESCLICK...79 FIGURA : VISÃO PARCIAL DO DIAGRAMA DE CLASSES DO SISTEMA DE LOCAÇÕES DE VÍDEOS...83 FIGURA : VISÃO PARCIAL DA LISTA DE MAPEAMENTO MASA X MAS DO SISTEMA DE LOCAÇÕES DE VÍDEOS...83 FIGURA : VISÃO PARCIAL DA LISTA DE CORRESPONDÊNCIA DE MÉTODOS ANÔMALOS...84

10 FIGURA : VISÃO PARCIAL DO DIAGRAMA DE 8 & APÓS ABSTRAÇÃO NO MAS...86 FIGURA : VISÃO PARCIAL DA LISTA DE MAPEAMENTO DE 8 &...86 FIGURA : DESCRIÇÃO DO ATUALIZAR...87 FIGURA 3.5.1: VISUALIZAÇÃO PARCIAL DO DIAGRAMA DE CLASSES DE PROJETO...90 FIGURA 3.5.2: DIAGRAMA DE SEQÜÊNCIA RELATIVO AO ATUALIZAR...91 FIGURA 3.5.3: VISÃO PARCIAL DA DECLARAÇÃO DA CLASSE CLIENTE...93 FIGURA 3.5.4: IMPLEMENTAÇÃO DOS MÉTODOS DA CLASSE CLIENTE...93 FIGURA 3.5.5: DECLARAÇÃO DA CLASSE DE ACESSO AOS DADOS DERIVADA DA CLASSE CLIENTE...95 FIGURA 3.5.6: COMPONENTES DE ACESSO DIRETO A DADOS QUE ORIGINARAM A INTERFACE DO SOFTWARE LEGADO...97 FIGURA 3.5.7: INTERFACE DE CLIENTES DO SISTEMA DE LOCAÇÕES DE VÍDEO APÓS A REENGENHARIA OO...97 FIGURA 4.4.1: COMPOSIÇÃO DE PARTE DA LISTA DE PROCEDIMENTOS E FUNÇÕES FIGURA 4.4.2: COMPOSIÇÃO DE PARTE DA LISTA "CHAMA/CHAMADO POR" FIGURA 4.4.3: COMPOSIÇÃO DA LISTA DE TABELAS E CHAVES FIGURA 4.4.4: MODELO ENTIDADE-RELACIONAMENTO DO ESTUDO DE CASO FIGURA 4.4.5: COMPOSIÇÃO DA LISTA DE ANOMALIAS FIGURA 4.4.6: APRESENTAÇÃO DOS RELACIONAMENTOS NO DIAGRAMA DE PSEUDO-CLASSES FIGURA 4.4.7: COMPOSIÇÃO DAS PSEUDO-CLASSES FIGURA 4.4.8: VISUALIZAÇÃO PARCIAL DO DIAGRAMA DE 8 & PARA O ATOR CLIENTE FIGURA 4.4.9: ORIGEM DO CREDBTNPGCLICK FIGURA : DESCRIÇÃO DO CREDBTNPGCLICK FIGURA : VISUALIZAÇÃO PARCIAL DA VERSÃO 1.0 DA LISTA DE MAPEAMENTO MASA X MAS FIGURA : EXEMPLO DE UM PROCEDIMENTO SEM ANOMALIAS QUE FOI CONVERTIDO EM DOIS MÉTODOS FIGURA : EXEMPLO DE PROCEDIMENTOS SEM ANOMALIAS QUE NÃO FORAM CONVERTIDOS EM MÉTODOS FIGURA : DIAGRAMA DE CLASSES APÓS A ABSTRAÇÃO DO MASA FIGURA : COMPOSIÇÃO DA LISTA DE CORRESPONDÊNCIA DE MÉTODOS ANÔMALOS FIGURA : 8 INSERIRCOR DO MAS FIGURA : VISUALIZAÇÃO DA DESCRIÇÃO DO INSERIRCOR FIGURA 4.5.1: VISUALIZAÇÃO PARCIAL DO DIAGRAMA DE CLASSES DE PROJETO FIGURA 4.5.2: DIAGRAMA DE SEQÜÊNCIA DO INSERIRCOR FIGURA 4.5.3: DOCUMENTAÇÃO ELABORADA NA INTERFACE DA CLASSE "COR" FIGURA 4.5.4: VISUALIZAÇÃO PARCIAL DA DOCUMENTAÇÃO DOS MÉTODOS DA CLASSE "COR" FIGURA 4.5.5: VISUALIZAÇÃO PARCIAL DA INTERFACE DA CLASSE "DBCOR" FIGURA 4.5.6: VISUALIZAÇÃO PARCIAL DA IMPLEMENTAÇÃO DA CLASSE "DBCOR" FIGURA 4.5.7: INTERFACE LEGADA REFERENTE À TELA DE CORES FIGURA 4.5.8: INTERFACE RE-IMPLEMENTADA REFERENTE À TELA DE CORES FIGURA 5.4.1: CÓDIGO-FONTE LEGADO QUE PROVÊ A INSERÇÃO DE NOVAS QUANTIDADES EM ESTOQUE142

11 FIGURA 5.4.2: CORRESPONDÊNCIA ENTRE AS OPERAÇÕES DO SOFTWARE LEGADO E OS MÉTODOS/EVENTOS ORIGINADOS APÓS A REENGENHARIA FIGURA 5.4.3: CÓDIGO-FONTE OO QUE PROVÊ A INSERÇÃO DE NOVAS QUANTIDADES EM ESTOQUE FIGURA 5.4.4: CÓDIGO-FONTE LEGADO COM REPETIÇÃO DA FUNCIONALIDADE DE LOCALIZAR UM CLIENTE FIGURA 5.4.5: ABAS DO AMBIENTE DELPHI COM COMPONENTES DE ACESSO DIRETO AOS DADOS FIGURA 5.4.6: VISUALIZAÇÃO PARCIAL DA INTERFACE DA CLASSE "DBCLIENTE" FIGURA 5.4.7: INTERFACE ORIENTADA A OBJETOS...146

12 Li ta de Qu a dro QUADRO 2.8.1: DOCUMENTOS QUE COMPÕEM O PROJETO SPICE (CORTÊS, 2001)...24 QUADRO 2.8.2: NÍVEIS DE CAPACIDADE ATRIBUTOS DE PROCESSOS DO SPICE (ROUT, 1998)...26 QUADRO 2.8.3: RESULTADO DAS MODIFICAÇÕES NOS DOCUMENTOS DO SPICE (CORTÊS, 2001)...26 QUADRO 2.8.4: CARACTERÍSTICAS DOS NÍVEIS DE MATURIDADE DO SW-CMM (FIORINI., 1998) 28 QUADRO 2.9.1: DIAGRAMA DEFINIDOS PELA UML...37 QUADRO 3.3.1: MODELO PARA A DOCUMENTAÇÃO DO LEVANTAMENTO DE ATIVIDADES...48 QUADRO 3.3.2: MODELO PARA A DOCUMENTAÇÃO DO PLANO DE REENGENHARIA...50 QUADRO 3.3.3: MODELO PROPOSTO PARA O REGISTRO DAS INSPEÇÕES DE ACOMPANHAMENTO DO PROCESSO...55 QUADRO 3.3.4: MODELO PROPOSTO PARA A DOCUMENTAÇÃO DAS INSPEÇÕES DE GARANTIA DA QUALIDADE...57 QUADRO 3.3.5: MODELO PROPOSTO PARA O CONTROLE DE CONFIGURAÇÃO...59 QUADRO 3.3.6: MODELO PROPOSTO PARA A DOCUMENTAÇÃO DAS DO PROJETO...60 QUADRO 3.4.1: MODELO PARA MONTAGEM DA LISTA DE PROCEDIMENTOS E FUNÇÕES...65 QUADRO 3.4.2: FORMATO DA LISTA CHAMA/CHAMADO POR. ADAPTADO DE (PENTEADO, 1996A)...67 QUADRO 3.4.3: MODELO PARA DOCUMENTAÇÃO DAS TABELAS DE DADOS...70 QUADRO 3.4.4: CRITÉRIOS PARA CLASSIFICAÇÃO DAS ANOMALIAS EM PROCEDIMENTOS E FUNÇÕES...73 QUADRO 3.4.5: MODELO PARA CONSTRUÇÃO DA LISTA DE ANOMALIAS...73 QUADRO 3.4.6: MODELO DA LISTA DE MAPEAMENTO MASA X MAS...81 QUADRO 3.4.7: MODELO PARA A LISTA DE CORRESPONDÊNCIA DE MÉTODOS ANÔMALOS...82 QUADRO 3.4.8: MODELO PARA DOCUMENTAÇÃO DA LISTA DE MAPEAMENTO DOS 8 &...85 QUADRO 4.3.1: LEVANTAMENTO DE ATIVIDADES DO SOFTWARE LEGADO QUADRO 4.3.2: PLANO PARA REALIZAÇÃO DA REENGENHARIA QUADRO 4.4.1: DOCUMENTO DE INSPEÇÃO DE GARANTIA DA QUALIDADE DA LISTA DE PROCEDIMENTOS E FUNÇÕES QUADRO 4.4.2: VISUALIZAÇÃO PARCIAL DA VERSÃO 1.1 DA LISTA "CHAMA/CHAMADO POR" QUADRO 4.4.4: LISTA DE CONTROLE DE CONFIGURAÇÃO REFERENTE AO PASSO DE REVITALIZAÇÃO DA ARQUITETURA QUADRO 4.4.5: PRIMEIRA ESTABELECIDA DURANTE A REALIZAÇÃO DO ESTUDO DE CASO QUADRO 4.4.6: DOCUMENTO DE INSPEÇÃO DE ACOMPANHAMENTO DO PROCESSO QUADRO 4.4.7: INSPEÇÃO DE ACOMPANHAMENTO DE PROCESSO REALIZADA APÓS O TÉRMINO DO MASA QUADRO 4.4.8: SEGUNDA DO ESTUDO DE CASO QUADRO 4.4.9: VISUALIZAÇÃO PARCIAL DA LISTA DE MAPEAMENTO DE 8 & QUADRO : DOCUMENTO RELATIVO À TERCEIRA INSPEÇÃO DE ACOMPANHAMENTO DO PROCESSO 129 QUADRO : TERCEIRA % DE PROJETO...130

13 Li ta de Abrevia tu ra e Sigla IDEAL Initiating, Diagnoing, Etablihing, Acting, Learning IEC International Engineering Conortium IS International Standard ISO International Organization of Standardization KPA Key Proce Area PDCA Plan, Do, Check, Act SEI Software Engineering Intitute SPICE Software Proce Improvement and Capability determination SQL Structured Query Language SW-CMM Capability Maturity Model for Software UML Unified Modeling Language

14 1 Ca pítu lo 1. In trodu çã o &RQVLGHUDo}HV,QLFLDLV Muita organizaçõe têm enfrentado problema com o uo e a manutenção de itema de oftware contruído para erem executado em uma variedade de tipo de hardware e programado em linguagen oboleta. Com o paar do tempo, a tarefa de realizar a manutenção torna-e mai complexa e mai cara e, ainda, ee itema tornam-e cada vez mai deorganizado devido à inúmera tentativa de adaptaçõe e incluõe de nova funcionalidade (TILLEY, 1998). Há ainda muito oftware nea ituação devido à rápida evolução da ferramenta, tecnologia e método coneguida pela indútria de computadore e emprea de tecnologia da informação (OLSEM, 1998). Sendo aim, a organizaçõe têm trê alternativa: manter o oftware legado com a ituação já decrita de deorganização e cuto cada vez maiore, redeenvolver o oftware ou realizar a reengenharia tanto para aumentar ua manutenibilidade quanto para implementa-lo em um paradigma mai atual com ou em mudança de linguagem. No cao de manter um oftware legado, apena efetuando-e a manutençõe para que o memo continue operando, muito problema podem er citado: a alocação de peoal para ea tarefa que, egundo PRESSMAN (2000), pode chegar a mai de 60% do eforço de uma organização, além da falta de ua documentação, comum nee cao e que torna ainda mai crítica a ituação. A opção pelo redeenvolvimento de um oftware legado também tem problema aociado. O fato de que oftware têm a regra de negócio embutida, que podem não etar documentada e a poibilidade da peoa que a dominam não etarem mai na emprea, faz com que o eu completo redeenvolvimento não eja confiável (QUINAIA, 1999). Além dio, outro problema dea opção é o cuto do redeenvolvimento global do oftware, geralmente muito alto, conumindo tempo e recuro que, na maioria da veze, a emprea não dipõem (OLSEM, 1998). A engenharia revera e/ou reengenharia ão a forma que muita organizaçõe etão bucando para manter/refazer eu oftware, livrando-e da manutençõe

15 Ca pítu lo 1. In trodu çã o 2 difícei e da degeneração de ua etrutura. Por ee motivo, é importante que o reultado dee proceo eja confiável. Na última década, o fator qualidade com relação ao proceo de deenvolvimento de oftware foi batante etudado tendo ido elaborado vário modelo de melhoria e amadurecimento do memo, o que elevou ua capacitação para a geração de oftware. Aim, no proceo de reengenharia a garantia da qualidade também foi encarada como mai uma etapa do proceo. Segundo CORTÊS (2001), a definição de um proceo completo de oftware deve incluir atividade de controle de projeto, garantia da qualidade, gerenciamento de configuração, além de ferramenta e método de engenharia de oftware. Ea diertação pretende etudar e aplicar ee apecto a um proceo de reengenharia de forma a torná-lo completo. A definição de padrõe de reengenharia têm ido abordada por divero autore atualmente, pela neceidade da exitência de diretrize mai conitente para guiar na realização do proceo. &RQWH[WXDOL]DomRH2EMHWLYRVGD3HVTXLVD Ee trabalho tem por objetivo definir e documentar um proceo para realização da reengenharia de itema legado implementado em Delphi em caracterítica orientada a objeto. Apó a reengenharia o itema mantém a linguagem 2EMHFWPacal utilizando, porém, o recuro orientado a objeto preente no ambiente Delphi. O proceo etá organizado na forma de padrõe, relacionado à etapa de engenharia revera e engenharia avante e, ainda, à qualidade de proceo. Dea forma, o itema apó ua reengenharia reflete a mema funcionalidade do legado, tendo ido aplicada a prática de qualidade de proceo. O método Fuion/RE (PENTEADO, 1996a) (PENTEADO HW DO., 1996b) foi elaborado para a realização da engenharia revera orientada a objeto em oftware originalmente deenvolvido de acordo com o paradigma procedimental. Mai tarde, alguma extenõe viando a realização de reengenharia foram a ele incorporada (PENTEADO HWDO., 1998a), em que muito detalhe foem fornecido o que dificultou o proceo por parte do engenheiro de oftware meno experiente.

16 Ca pítu lo 1. In trodu çã o 3 Como primeiro pao da reengenharia, de acordo com o Fuion/RE, é feita a engenharia revera, que identifica o componente do oftware legado e o repreenta em um nível mai alto de abtração, para fin de re-documentação ou de recuperação do projeto (CHIKOFSKY, 1990). Apó a obtenção dee modelo, em nível de análie, pode er aplicada a engenharia avante com mudança de paradigma de procedimental para orientado a objeto, preervando a funcionalidade do oftware e a linguagem de programação (PENTEADO HWDO., 1999). Com a aplicação do Fuion/RE em itema legado implementado em diferente linguagen procedimentai notou-e que o modelo de proceo utilizado, eqüencial linear, não é o mai apropriado. Como o retorno a fae anteriore é neceário para que e obtenha completamente o modelo orientado a objeto em nível de análie, o modelo de proceo evolutivo torna-e mai adequado. Entende-e por proceo evolutivo, aquele atravé do qual é poível retornar a pao já realizado de acordo com a neceidade de refinamento de produto, interagindo com outro produto já elaborado. Aim, ete trabalho faz a adequação do pao do Fuion/RE ao modelo evolutivo e utiliza o digrama UML (8QLILHG0RGHOLQJ/DQJXDJH) (QUATRANI, 1998) ao invé do diagrama Fuion (COLEMAN HW DO., 1994). A engenharia avante também é incorporada ao proceo global realizado de acordo com o modelo evolutivo gerando uma evolução do Fuion/RE. A qualidade de proceo, comentada anteriormente, é deafio também no proceo de reengenharia. Dea forma, a aplicação de modelo de melhoria da qualidade, originalmente utilizado no proceo de deenvolvimento de oftware, em apoio ao proceo de reengenharia é também utilizada nete trabalho, com o objetivo de tornar o proceo de reengenharia orientada a objeto mai eficiente e maduro. Optou-e por decrever ee proceo utilizando-e padrõe, pelo fato de tornarem o aprendizado, pelo engenheiro de oftware, mai fácil dado eu formato padronizado, decrito em eçõe pré-definida e já utilizado em trabalho de vário autore. Dea forma, ete trabalho propõe um Proceo de Reengenharia Orientada a Objeto, denominado PRE/OO, com toda a caracterítica acima decrita eperando auxiliar engenheiro de oftware a realizar a reengenharia de itema legado, obtendo ua completa re-etruturação, de forma facilitada.

17 Ca pítu lo 1. In trodu çã o 4 Vale realtar que a egmentação de um oftware legado, reengenharia em que é preervada a linguagem de implementação, omente com adaptaçõe de caracterítica orientada a objeto, também pode er realizada pelo PRE/OO. Um itema exemplo, implementado em Delphi, é utilizado para motrar a egmentação aplicando-e o PRE/OO. 0RWLYDomRGD0RQRJUDILD O deenvolvimento de oftware comerciai para pequena emprea, utilizando linguagen como &OLSSHU e Pacal, tem ido realizado pela autora dete trabalho dede o término de ua graduação. A neceidade de migrar oftware implementado nea linguagen para ambiente com caracterítica orientada a objeto, de forma facilitada, foi um do motivo para a realização dete trabalho. Aliado a io, o interee em que ee deenvolvimento e migraçõe para outro ambiente e linguagen foem feito com qualidade e com o uo adequado de ferramenta foi evidenciado. Dea forma, o tema de pequia aqui apreentado foi propoto, uma vez que há um conjunto de itema que pode ervir para a aplicação e avaliação do PRE/OO. 2UJDQL]DomRGD'LVVHUWDomR Eta diertação etá organizada da eguinte forma: no Capítulo 2 encontra-e o levantamento bibliográfico elaborado a repeito do aunto relevante para a execução dete trabalho. No Capítulo é decrito o proceo de reengenharia orientada a objeto (PRE/OO), por meio de FOXVWHUV de padrõe; no Capítulo 4 um etudo de cao deenvolvido em Delphi em coniderar o apecto orientado a objeto é utilizado para exemplificar a aplicação do PRE/OO. No Capítulo 5 apreentam-e conideraçõe quanto à etimativa de cuto e eforço obervada quando da aplicação do PRE/OO e no Capítulo 6 ão tecido comentário finai obre o trabalho realizado e indicado trabalho futuro que podem dar continuidade a ete.

18 5 Ca pítu lo 2. Revi ã o Bibliográ fica &RQVLGHUDo}HV,QLFLDLV Nete capítulo ão relatado o aunto pertinente à pequia realizada encontrado em publicaçõe epecializada e que e relacionam diretamente a ete trabalho. O proceo de engenharia revera, egmentação e reengenharia, bem como o Fuion/RE ão decrito por formarem a bae do trabalho. A manutenção de oftware é etudada para verificar como o proceo de reengenharia pode auxiliá-la. Padrõe de reengenharia ão pequiado por organizarem e facilitarem a tranferência de conhecimento obre o proceo. A qualidade no proceo de oftware é abordada para adaptá-la ao proceo de reengenharia e da UML ão uado diagrama para a documentação de modelo elaborado na reengenharia. Na Seção 2.2 é apreentado o proceo de engenharia revera. Na Seção 2.3 é decrito o método de engenharia revera Fuion/RE; na Seção 2.4 é apreentado o proceo de reengenharia; na Seção 2.5 a egmentação é vita juntamente com algun etudo de cao deenvolvido em trabalho anteriore; na Seção 2.6 é dicutida a manutenção de oftware e o papel da engenharia revera e da reengenharia viando o aumento de manutenibilidade; na Seção 2.7 ão motrado algun trabalho obre padrõe de reengenharia; na Seção 2.8 é feita breve introdução ao ambiente de deenvolvimento Delphi; na Seção 2.9 aborda-e a qualidade no proceo de oftware. A Seção 2.10 apreenta o conceito da UML com o objetivo de ambientar o leitor ao diagrama gerado em cada uma de ua fae e, finalmente, a Seção 2.11 apreenta a conideraçõe finai. (QJHQKDULD5HYHUVD O termo engenharia revera teve ua origem na análie do hardware, em que a prática de extração de projeto de produto concluído é comum, endo aplicada para a melhoria dee produto e análie de produto de competidore (CHIKOFSKY, 1990). Nee contexto a engenharia revera pode er definida como o proceo de

19 Ca pítu lo 2. Revi ã o Bibliográ fica 6 deenvolvimento de um conjunto de epecificaçõe para um itema de hardware complexo atravé do exame ordenado do componente do itema (REKOFF, 1985). Enquanto que para o hardware o objetivo tradicional da engenharia revera é duplicar o itema, para o oftware ee proceo é mai freqüentemente utilizado para e obter um uficiente entendimento do memo no nível de deenvolvimento. Portanto, define-e engenharia revera para um oftware como o proceo de análie para identificar eu componente e inter-relacionamento e criar repreentaçõe do memo em outra forma ou num nível mai alto de abtração (CHIKOFSKY, 1990). Abtração pode er definida como a tarefa de utilizar apena aunto relevante ao propóito em quetão (OXFORD, 1986). Doi conceito podem er derivado, como decrito a eguir e ilutrado na Figura º Nível de Abtração: acontece entre a fae do ciclo de vida do oftware. Quanto mai próximo e etiver da implementação, menor é o nível de abtração e quanto mai próximo da fae de epecificação de requiito, maior o nível de abtração; º Grau de Abtração: acontece dentro de uma mema etapa do ciclo de vida do oftware. Se a informaçõe forem pouco detalhada, o grau de abtração é alto. Se a informaçõe forem batante detalhada, é baixo o grau de abtração (CHIKOFSKY, 1990).!#"%$ "$ &%'%() *+,-+/.0!%21 ;A1 +0B 1!/1 ;2C;%D 7 EF! +/G > H I JK0C JL M%&NNOP Segundo CHIKOFSKY (1990), há dua categoria de engenharia revera: a redocumentação e a recuperação de projeto. A redocumentação, também chamada de viualização de código, é utilizada na criação de repreentaçõe a partir de informaçõe obtida apena da análie do código fonte, com o objetivo de recuperar a documentação

20 Ca pítu lo 2. Revi ã o Bibliográ fica 7 do oftware. A recuperação de projeto, também chamada de entendimento de programa, utiliza além do exame do código, o conhecimento do domínio da informaçõe relativo ao oftware e a deduçõe, com o objetivo de obter-e informaçõe com um nível mai alto de abtração. O entendimento de programa é uma forma mai crítica de engenharia revera, poi tenta aproximar-e do raciocínio humano na buca de entendimento (QUINAIA, 1999). No último dez ano, a pequia a repeito da engenharia revera produziram método para análie de código, incluindo decompoição de oftware, análie da dependência etática e dinâmica, uo de métrica, além da exploração e viualização do oftware (redocumentação). Entretanto, o código do oftware não contém toda a informaçõe neceária endo que o conhecimento obre ua arquitetura e obre o domínio da aplicação, além da retriçõe implícita que, geralmente, ó exitem na mente de quem contruiu e utilizou o oftware (WONG HWDO., 2000). Com a engenharia revera é poível abtrair informaçõe a partir do código exitente e também do conhecimento e experiência do uuário, produzindo documento conitente com o código fonte, melhorando o deenvolvimento ubeqüente, facilitando a manutenção e a reengenharia. Entretanto, reprojetar e documentar um itema já exitente é tarefa bem mai difícil do que realizar um novo projeto (PENTEADO HWDO., 1996b). Para que a quetõe técnica relativa ao proceo de engenharia revera ejam tratada de forma mai efetiva, o proceo deve tornar-e maduro, capaz de er repetido, e paível de evolução de modo que cada vez mai pao poam er executado por ferramenta automatizada (WONG HWDO., 2000). 0pWRGR)XVLRQ5( O Fuion/RE foi criado a partir do método Fuion (COLEMAN HWDO., 1994) com o objetivo de recuperar o projeto de oftware legado procedimentai em uma forma orientada a objeto. Para a realização do proceo de engenharia revera a partir dee método não há neceidade de e ter a documentação do oftware legado, poi é poível recuperar o projeto atravé do código fonte do oftware.

21 Ca pítu lo 2. Revi ã o Bibliográ fica 8 O método foi inicialmente deenvolvido conitindo de quatro pao que correpondem à fae de engenharia revera (PENTEADO, 1996a) e, poteriormente, mai doi pao correpondente à egmentação foram adicionado (PENTEADO HWDO., 1998a) formando o ei pao reumido a eguir: 1. Revitalização da arquitetura do oftware legado: é recuperada a documentação báica do oftware, baeada na documentação diponível a repeito do memo. Ee proceo pode er conduzido de forma manual ou com o auxílio de ferramenta de extração. Como reultado dee pao tem-e uma lita de todo o procedimento, com ua decrição e hierarquia de chamada (Lita Chama/Chamado por ); 2. Recuperação do Modelo de Análie do Sitema Atual (MASA): a partir da bae de dado e do código é criado um peudo modelo orientado a objeto do oftware legado. Ee modelo pode er entendido como uma abtração orientada a objeto preliminar, memo a implementação real tendo ido feita de acordo com o paradigma procedimental. A etrutura de dado (eu relacionamento e cardinalidade) ão recuperada e modelada como endo peudo-clae de objeto e o procedimento do código legado ão a bae para a derivação do método. Muito do procedimento podem conter anomalia, ou eja, um memo procedimento pode tratar com vária etrutura de dado. Há uma claificação para o procedimento: º (o) obervador, o procedimento ou a função que omente conulta a etrutura de dado, º (c) contrutor, o procedimento ou a função que altera a etrutura de dado ou altera e conulta a etrutura de dado, º (i) implementação, o procedimento ou a função que trata apena de apecto de implementação, em alterar ou conultar nenhuma etrutura de dado; O inal de + aociado ao ímbolo (o) ou (c), indica que o procedimento oberva e/ou conulta dua ou mai etrutura de dado. Dee modo, a poívei claificaçõe para o procedimento anômalo podem er (o), (c), (oc), (o+c), (oc+), (o+c+) ou (i); Apó a claificação do procedimento, ão criado: º Modelo de Ciclo de Vida: retrata, atravé de expreõe regulare, o comportamento global do itema, º Modelo de Operação: decreve detalhadamente cada operação do oftware de forma textual,

22 Ca pítu lo 2. Revi ã o Bibliográ fica 9 º Modelo de Objeto: repreenta o conceito exitente no domínio do problema e ua relaçõe; 3. Criação do Modelo de Análie do Sitema (MAS): o diagrama criado no pao anterior ão abtraído, a peudo-clae do MASA ão generalizada e a anomalia do procedimento ão eliminada, tranformando um procedimento anômalo em quanto método forem neceário; 4. Mapeamento do MAS para o MASA: ão mapeado a clae, atributo e procedimento do MAS para o elemento correpondente no MASA, documentando-e incluive a poívei incluõe/excluõe. Ee pao é muito importante para futura manutençõe e poível reuo do oftware; 5. Elaboração do Projeto Avante: via a elaboração do modelo da fae de projeto para que a engenharia avante eja feita mudando-e o paradigma de procedimental para orientado a objeto, mantendo-e ou não a linguagem procedimental em uo. O diagrama gerado nee pao ão: º Grafo de Interação de Objeto: motra quai objeto participam da execução de uma operação e a eqüência de troca de menagen entre ele, endo contruído com bae no Modelo de Operaçõe, º Grafo de Viibilidade: etabelecem a forma de comunicação entre a clae, epecificando a interface para troca de menagen do itema, º Decriçõe de Clae: complementam o Modelo de Objeto do itema, epecificando quai o atributo de cada clae e ua interface externa, º Grafo de Herança: definem a epecializaçõe exitente entre a clae complementando a Decriçõe de Clae; 6. Segmentação do Sitema: o procedimento com anomalia ão tranformado em método. O código é examinado, dividido em método e ão inerido comentário motrando a correpondência entre ele. Ee pao é elaborado com bae no diagrama do projeto avante do oftware. Geralmente, apó a aplicação do método Fuion/RE, percebe-e um aumento no número de método em relação ao procedimento do oftware legado, porém ee ão empre menore e organizado de forma a aumentar a poibilidade de reuo e melhorar a manutenibilidade do oftware. Como já foi citado, a egmentação não altera a linguagem de programação, ma o oftware gerado apó o proceo pode, de maneira

23 Ca pítu lo 2. Revi ã o Bibliográ fica 10 muito mai imple, er tranformado para uma linguagem orientada a objeto (PENTEADO HWDO., 1998a). A Figura motra o pao do método Fuion/RE apó a incluão do pao 5 e 6 referente ao proceo de engenharia avante.!#"%$ Q$ &%'%R6%S+%T2!#1;?U0V7W; 1;X6 ;<Y ZR=GW[R(\R3 ]K_^`%ab $ M%&NNc!P

24 Ca pítu lo 2. Revi ã o Bibliográ fica 11 5HHQJHQKDULD A reengenharia, egundo CHICOFSKI (1990), envolve baicamente dua etapa: alguma forma de engenharia revera (para e alcançar um nível mai alto de abtração) e a engenharia avante ou reetruturação. Ee proceo é indicado para o oftware que ainda têm alta utilidade, ma difícil manutenção, endo feito utilizando-e método que proporcionam maior qualidade ao oftware. Atualmente, o uo da orientação a objeto tem motrado uma boa perpectiva, tanto para o deenvolvimento do oftware quanto para ua poterior manutenção. De acordo com JACOBSON (1991), a reengenharia pode er categorizada egundo o cenário no quai ocorrem a tranformação de oftware procedimentai para oftware orientado a objeto: º 5HHQJHQKDULD FRPSOHWD GD WpFQLFD GH LPSOHPHQWDomR VHP DOWHUDomR GH IXQFLRQDOLGDGH, em que o cenário é compoto da eguinte etapa: Preparação do modelo de análie, com bae no oftware a er recontruído; Mapeamento de cada objeto de análie para a implementação do oftware antigo; Reprojeto do oftware utilizando-e metodologia orientada a objeto; º5HHQJHQKDULD SDUFLDO VHP DOWHUDomR GD IXQFLRQDOLGDGH, em que o cenário é parcialmente alterado, de modo que o oftware pareça er totalmente orientado a objeto. Conite da etapa: Identificação da parte do oftware que erão re-implementada uando-e a orientação a objeto; Preparação de um modelo de análie da parte elecionada anteriormente; Mapeamento de cada objeto modelado a partir da antiga implementação do oftware; Execução do pao anteriore até a interface entre a parte mantida e remodelada do oftware e tornarem aceitávei; Execução em paralelo: - Projeto do novo oftware e de ua interface com o antigo oftware, - Modificaçõe no oftware antigo e adição da interface com o novo oftware; Integração e tete da parte mantida e re-implementada do oftware; º5HHQJHQKDULD FRP DOWHUDomR GD IXQFLRQDOLGDGH. Ee cenário é de um proceo normal da engenharia avante, no qual ão adicionada nova funcionalidade ao

25 Ca pítu lo 2. Revi ã o Bibliográ fica 12 oftware e o memo é re-implementado com o uo de uma técnica orientada a objeto. A principai etapa dete cenário ão: Alteração no modelo de análie de acordo com o requiito incorporado ao oftware; Reprojeto do oftware. Segundo SOMMERVILLE (1995), a categorização da reengenharia e dá de acordo com a abrangência que ee proceo irá ter com relação ao oftware: º &RQYHUVmRGRSURJUDPDIRQWH: é a forma mai imple de reengenharia, na qual o código fonte ecrito em uma linguagem é traduzido para outra linguagem; º 5HHVWUXWXUDomR GR SURJUDPD: aplicável quando a etrutura do oftware etá corrompida dificultando eu entendimento. Por exemplo: exitência de funçõe duplicada ou nunca chamada. 6HJPHQWDomR Segmentação é o proceo de reengenharia com mudança da orientação de procedimental para orientação a objeto, preervando-e a funcionalidade do oftware e a linguagem de programação. Aim, é realizada a adaptação do código-fonte, de acordo com o recuro diponívei na linguagem, de forma a implementá-lo com caracterítica orientada a objeto (PENTEADO HWDO., 1999). A egmentação, como vito anteriormente, pode er conduzida eguindo-e o Fuion/RE, endo o último pao dee método. Ee pao foi ubdividido em quatro parte, executada gradualmente e ao fim de cada uma ão realizado tete funcionai com o objetivo de garantir a preervação da funcionalidade do oftware (PENTEADO HW DO., 1999). A eguir a egmentação é reumidamente decrita: 1. São criada a clae de acordo com o Modelo de Objeto obtido na terceira fae do Fuion/RE (Obtenção do MAS). O método em anomalia ão diretamente inerido na clae correpondente. O método anômalo têm ecolhida a clae que melhor o repreentam e, então, é feita a inerção. Além dio, ão inerida referência a ee procedimento na clae que ee método alteram e/ou obervam; 2. É feita a quebra do método anômalo em vário endo que cada um paa a alterar ou obervar apena uma clae, à qual é poteriormente aociado;

26 Ca pítu lo 2. Revi ã o Bibliográ fica São criado o módulo que contêm a decriçõe da clae e o protótipo de método aociado a ela. Daí ão criado o módulo que contêm a implementação de cada clae; 4. São criada a clae dependente do tipo de implementação uada, como: pilha, lita ou árvore. O proceo de egmentação varia de acordo com a linguagem procedimental utilizada, em relação ao modo de implementação de ua etrutura de dado e do recuro computacionai a erem utilizado com o objetivo de tornar o código peudoorientado a objeto. A eguir, ão citado doi trabalho que motram o proceo de egmentação e o reultado obtido em itema reai (PENTEADO HW DO., 1998a) (PENTEADO HWDO., 1998b). O primeiro itema, com linha de código em &OLSSHU para controle de oficina mecânica e elétrica, pouia como documentação apena a Lita Chama/Chamado Por e a decrição da tabela relacionai. Nee etudo verificou-e que alguma caracterítica do &OLSSHU dificultaram a imulação da orientação a objeto como a falta de uma etrutura de dado que pudee ubtituir o conceito de clae. Foi, então, realizada a imulação do conceito de clae com a inerção de todo o método pertencente a uma clae no memo arquivo fíico. A última fae dee etudo foi a tranformação do código egmentado em &OLSSHU para a linguagem Java com a ferramenta Draco-Puc. O egundo trabalho, foi a egmentação do ambiente StatSim, um itema com linha de código implementado em C e ;YLHZ que permite a edição e a imulação de VWDWHFKDUWV. O proceo foi realizado coniderando o modelo orientado a objeto obtido durante a engenharia revera. 0DQXWHQomR A manutenção de oftware é uma da fae mai problemática de eu ciclo de vida, caracterizando-e por um alto cuto e baixa velocidade de implementação. Porém, é uma atividade inevitável, principalmente tratando-e de oftware útei, para o quai o uuário contantemente olicitam mudança e agregaçõe de nova funcionalidade (BENNET HWDO, 2000).

27 Ca pítu lo 2. Revi ã o Bibliográ fica 14 Segundo PRESSMAN (2000), pode-e claificar a manutenção de oftware em quatro categoria principai: º 0DQXWHQomR&RUUHWLYDalteração de um oftware de forma a corrigir eu defeito e aim garantir a continuidade de ua operação; º 0DQXWHQomR $GDSWDWLYD adição ou modificação de funcionalidade um oftware para adaptá-lo à mudança ocorrida em eu ambiente; º 0DQXWHQomR (YROXWLYD incluão de nova funcionalidade ao oftware além da originai a pedido do uuário; º 0DQXWHQomR 3UHYHQWLYD mudança do oftware para tornar ua manutenção mai fácil (aumento da manutenibilidade). Entre o principai fatore da dificuldade de entendimento de um oftware encontram-e a parcial ou completa inexitência de documentação e/ou ua deatualização. Dee modo, oberva-e que a manutenibilidade de oftware etá fortemente relacionada com a diponibilidade de documentação atualizada obre o memo (COSTA, 1996). A engenharia revera e, poteriormente, a egmentação podem er utilizada com grande proveito no entendimento e na re-documentação de oftware, de forma a melhorar ua manutenibilidade, endo uma forma de manutenção preventiva. 3DGU}HVSDUD5HDOL]DomRGH5HHQJHQKDULD Segundo DEMEYER HWDO. (1999, 2000a e 2000b), o itema legado não etão limitado ao paradigma procedimental e a linguagen como COBOL. Atualmente encontram-e itema legado orientado a objeto implementado em C++, 6PDOOWDON ou Java. Originalmente, a orientação a objeto prometeu a contrução de itema mai flexívei e de fácil evolução. Porém, notou-e que ee itema legado preciam paar pelo proceo de reengenharia com o objetivo de atifazerem novo requiito, tornarem-e mai flexívei ou, implemente, eguir o projetoorientado a objeto. Dea forma, o autore criaram uma linguagem de padrõe, a qual pode er utilizada não omente no proceo de engenharia revera, como também durante a reengenharia de itema como alternativa de prover a reetruturação de itema orientado a objeto. O padrõe apreentam o eguinte formato: 1RPH,,QWXLWR, &RQWH[WR, 3UREOHPD, 6ROXomR, ([HPSORV, $YDOLDomR, -XVWLILFDWLYD, 3DGU}HV 5HODFLRQDGRV, 8VRV

28 Ca pítu lo 2. Revi ã o Bibliográ fica 15 &RQKHFLGRV e &RQWH[WR 5HVXOWDQWH, o quai foram agrupado em quatro FOXVWHUV, como motra a Figura Cada FOXVWHU contém padrõe tratando uma ituação imilar da engenharia revera e ão o eguinte: ¾ 3ULPHLUR&RQWDWRO padrõe dee FOXVWHU decrevem o procedimento a erem tomado pelo engenheiro de oftware no primeiro contato com o itema legado; ¾ (QWHQGLPHQWR,QLFLDO O padrõe dee FOXVWHU decrevem como o engenheiro de oftware pode obter o entendimento inicial do oftware, documentado principalmente na forma de diagrama de clae; ¾ &DSWXUD GH GHWDOKHV GR PRGHOR O padrõe dee FOXVWHU decrevem como o engenheiro de oftware pode obter o entendimento detalhado de um particular componente do oftware; ¾ 3UHSDUDomRGDUHHQJHQKDULDComo a engenharia revera precede a reengenharia, ete FOXVWHU inclui algun padrõe que auxiliam na preparação do pao ubeqüente da engenharia avante.!#"%$ d$ &%'38e!%T2+ <7W;?1;%6/S!78W;?fb gh ` ^ijh21!2, <%! +Tk1 +Ae!1Wl ] RU#R LRZm^`%ab $ G "OOO%5%P RECCHIA HW DO (2002b) criou a FaPRE/OO, uma família de padrõe para a reengenharia orientada a objeto de itema legado procedimentai. Ea família é

29 Ca pítu lo 2. Revi ã o Bibliográ fica 16 formada por quatro FOXVWHUV cada um agrupando o padrõe relacionado a ituaçõe imilare da engenharia revera (3 FOXVWHUV) e da engenharia avante (1 FOXVWHU), decrito a eguir e ilutrado na Figura !#"%$ d$ "' nb gh ` ^ijh21!a!ta),!#1 +2[!1 l Z++ <% + <o! j!/k Kp1 +2Z R> > H I 3qG "OO"!%P º &OXVWHU: Modelar o Dado do Legado: agrupa padrõe que extraem informaçõe a partir do dado e do código fonte do itema legado, de forma a conduzir a açõe do engenheiro de oftware durante o primeiro contato com o itema; º &OXVWHU Modelar a Funcionalidade do Sitema: agrupa padrõe para obter a funcionalidade do itema legado, criando modelo que repreentam a Regra de Negócio da Emprea e capacitando o engenheiro de oftware a obter um entendimento detalhado do componente do itema, aprofundando aim, ua compreenão obre ete; º &OXVWHUModelar o Sitema Orientado a Objeto: agrupa padrõe para e obter o Diagrama de Clae e o Diagrama de Seqüência do itema, atravé da interação do produto obtido pelo padrõe do FOXVWHUV anteriore. O reultado de ua

30 Ca pítu lo 2. Revi ã o Bibliográ fica 17 aplicação é o MAS (Modelo de Analie do Sitema), modelo orientado a objeto que erve como bae ao proceo de reengenharia; º &OXVWHU Gerar o Sitema Orientado a Objeto: agrupa o padrõe de engenharia avante, reponávei pela re-implementação do oftware legado a partir do modelo orientado a objeto gerado com a aplicação do padrõe. Segundo DUCASSE HWDO. (1998, 1999), quando um importante oftware legado não pode mai evoluir naturalmente para atifazer a mudança no requiito ele, freqüentemente, é ubmetido ao proceo de reengenharia. O autore explicam que padrõe de reengenharia apreentam nova oluçõe para uma olução legada recorrente que já não é apropriada e decrevem como realizar a migração da olução legada à nova olução. Citam, também, que padrõe de reengenharia codificam e regitram o conhecimento obre como modificar oftware legado: ajudam a diagnoticar problema e identificar o ponto fraco que dificultam o deenvolvimento adicional do itema, além de ajudar a encontrar oluçõe mai apropriada ao novo requiito. O formato de propoto para o padrõe de reengenharia é ilutrado a eguir: º 1RPHGR3DGUmR Utiliza-e uma pequena entença contendo um verbo que enfatiza o tipo de tranformação de reengenharia; º,QWXLWR Uma decrição do proceo, juntamente com o reultado e por que o memo é deejável; º $SOLFDELOLGDGH Indica quando o padrão é aplicável ou não. Eta eção inclui: uma lita de intoma: experiência na ocorrência de reuo, manutenção ou mudança no itema, uma lita de meta da reengenharia: qualidade aperfeiçoada por meio da aplicação do padrão, uma lita de padrõe relacionado; º 0RWLYDomR Apreenta um exemplo concreto, o qual tem por objetivo familiarizar o leitor para que ete entenda melhor a apreentação mai abtrata do problema que egue na eçõe Etrutura e Proceo. O exemplo deve explicar claramente a etrutura do itema de legado exitente, a etrutura do itema apó ubmetido ao proceo de reengenharia e a relação entre o doi, além de decrever eu etado ante e depoi da aplicação do padrão;

31 Ca pítu lo 2. Revi ã o Bibliográ fica 18 º (VWUXWXUD Decreve a etrutura do itema ante e depoi da reengenharia. São identificado o Participante e a Colaboraçõe. Nea eção também ão dicutida a vantagen e devantagen da etrutura alvo em comparação à etrutura inicial; º 3URFHVVR Eta eção é ubdividida em trê parte: Detecção, Receita e Dificuldade. Sabe-e que o código, freqüentemente, indica ao engenheiro de oftware onde etá o problema e o proceo de reengenharia deve ter como objetivo evitar que o código reultante da reengenharia não obtrua o deenvolvimento adicional. Porém, há cao em que pode er intereante decobrir automaticamente onde podem er aplicado padrõe diferente. A eção Detecção decreve método e ferramenta para decobrir quando o código etá ofrendo com problema realmente ério em que o proceo ecolhido pode ajudar a aliviar ou a reolver ete problema. A eção Receita diz como realizar a reengenharia e ua poívei variante. A eção Dificuldade dicute ituaçõe em que a reengenharia é impoível ou ua aplicação é comprometida por outro problema exitente; º 'LVFXVVmR Neta eção, é avaliada a relação entre o cuto e o benefício da aplicação do padrão. A olução legada é comentada para motrar por que tal olução era boa num dado período de tempo ma, inuficiente ou inadequada para o problema atual. Dicute-e qual o cuto para detectar ete problema, ua magnitude e o benefício da aplicação do padrão. Eta dicuão deve ajudar o engenheiro de oftware a decidir e a aplicação do padrão é ou não viável nete cao epecífico; º 4XHVW}HV (VSHFtILFDV GD /LQJXDJHP Lita o que, epecificamente, deve er olucionado para cada linguagem, verificando-e quai a dificuldade e facilidade encontrada em cada uma. POOLEY HWDO. (1998) apreentam a idéia de padrõe de reengenharia de oftware, adaptada a partir de padrõe de projeto, como forma de identificar procedimento bem ucedido de projeto de reengenharia e a partir dele, criar padrõe diponívei para uo em novo projeto. Segundo o autore, a vantagem da utilização de padrõe de reengenharia em auxílio à aplicação de metodologia, vem do fato de que em etudo conduzido atualmente, no quai buca-e deenvolver metodologia de reengenharia, a obtenção de reultado têm ido extremamente dificultada pelo fato deta terem que er uficientemente genérica. Padrõe de reengenharia ão propoto como maneira de codificação e dieminação de boa prática reengenharia de oftware facilitando a compreenão e a utilização da metodologia exitente.

32 Ca pítu lo 2. Revi ã o Bibliográ fica 19 Segundo STEVENS HW DO. (1998), nem todo o itema legado ão grande oftware deenvolvido em COBOL. Há muito itema moderno originalmente bem contruído de forma orientada a objeto ou baeado em componente, porém de difícil manutenção pelo fato de ua etrutura ter e tornado obcura por modificaçõe de vário ano. Nee cao, a reengenharia pode er uma olução atrativa como forma de reetruturação, ma a dificuldade em encontrar epecialita para a realização dee proceo, dificulta a adoção dea olução. Segundo o autore, o deenvolvimento de novo materiai e técnica poderia minimizar ee problema. Como contribuição, criaram padrõe de reengenharia, que podem er utilizado como um modo de tranferir conhecimento dada a pouca quantidade de bibliografia nea área, em comparação com a diponívei obre o deenvolvimento de itema. O padrõe funcionam como unidade auxiliare na tranferência de conhecimento, por erem pequeno e epecífico a ponto da comunidade de epecialita poder validá-lo efetivamente. O formato adotado pelo autore para decrição do padrõe propoto foi: 1RPH &RQWH[WR 3UREOHPD 6ROXomR H &RQVHT rqfldv. O tamanho reduzido de cada padrão torna poível ua utilização em complemento à metodologia adotada, porém não eliminam a neceidade do uo da mema, ma influenciam e ão influenciado por ela. O padrõe de reengenharia apreentado têm por objetivo comum o aumento da facilidade da implementação dee proceo, dada a forma padronizada e bem documentada do FOXVWHUV que o decrevem. Dee modo, prevê-e a melhor aplicabilidade por parte do engenheiro de oftware e, coneqüentemente, maior qualidade do produto gerado, ou eja, do oftware orientado a objeto reultante. 4XDOLGDGHQR3URFHVVRGH6RIWZDUH O proceo de oftware pode er definido como o conjunto de ferramenta, método e prática que ão utilizado para deenvolver e manter o oftware e produto aociado (FIORINI HWDO., 1998). E é ob um proceo bem definido que a etabilidade no deenvolvimento do oftware pode er intituída. A capacitação em deenvolvimento de oftware preupõe a exitência de um proceo de oftware definido no qual é aplicado um modelo de melhoria de proceo. O proceo definido tem documentação que detalha o que é feito, quando, por quem, o que é utilizado e o que é produzido. A maturidade do proceo indica até que ponto um proceo é definido e implementado, utilizando para io apecto como métrica para verificação do controle e da eficácia.