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.

33 Ca pítu lo 2. Revi ã o Bibliográ fica 20 Nete entido, a capacitação em deenvolvimento de oftware reflete o grau de intitucionalização de uma infra-etrutura e da cultura relacionada ao método, prática e procedimento do deenvolvimento de oftware. Reflete, ainda, a qualidade do proceo, poi e abe que a qualidade do produto de oftware depende diretamente da qualidade do proceo de deenvolvimento a ele aociado. PFLEEGER (1998) define qualidade a partir de como eta é percebida em diferente perpectiva: º 9LVmR 7UDQVFHQGHQWDO trata da qualidade como um conceito abtrato, que dificilmente pode er fixado com precião. Qualidade repreenta uma caracterítica, propriedade ou etado que torna um produto ou erviço aceitável; º 9LVmRFRP%DVHQR9DORU agrega qualidade ao valor que o cliente eteja dipoto a pagar pelo produto, nee cao, quanto maior o preço do produto, maior é ua qualidade; º 9LVmR GR 8VXiULR concentra-e no uuário, tendo ee como fonte de toda a avaliação da qualidade de um produto, a qualidade de um produto etá condicionada à vontade de eu conumidor; º 9LVmR &HQWUDGD QR 3URFHVVR GH )DEULFDomR fixa-e no eforço realizado em produzir um item de acordo com ua epecificaçõe báica, determinada durante o projeto. Aim, e o proceo de fabricação não pode deenvolver um produto conforme ua epecificaçõe, a qualidade etará comprometida logo no primeiro eforço para produzi-lo. FUGGETTA (2000) diz que o eforço neceário para apoiar atividade de melhoria de proceo podem er claificado como modelo de maturidade ou etratégia de melhoria: º (VWUDWpJLD GH PHOKRULD define o pao pelo quai a melhoria pode er obtida. Epecifica como avaliar um proceo, iniciar açõe corretiva e, também, promover iniciativa para a implementação de nova melhoria. Um exemplo citado é o IDEAL; º 0RGHOR GH PDWXULGDGH define o perfil ideal de um proceo, ou eja, o conjunto mínimo de exigência que um proceo deveria atifazer para etar qualificado dentro de um etado epecífico. Como um exemplo de modelo de maturidade cita o SW-CMM do 6RIWZDUH(QJLQHHULQJ,QVWLWXWH.

34 Ca pítu lo 2. Revi ã o Bibliográ fica 21 Na eçõe eguinte ão apreentado método de melhoria e etratégia de maturidade conforme cita FUGGETTA (2000), o quai foram etudado para verificação da poibilidade de incluão no PRE/OO. (VWUDWpJLDVGH0HOKRULDGD4XDOLGDGH,'($/,QLWLDWLQJ'LDJQRVLQJ(VWDEOLVKLQJ$FWLQJ/HDUQLQJ O IDEAL provê uma forma útil em pao eqüenciai para o etabelecimento de programa de melhoria bem ucedido. Seguindo ua fae, atividade e princípio, o eforço de melhoria ão beneficiado em muito (GREMBA, 1997) (McFEELEY, 1996). O IDEAL conite de cinco fae, viualizada na Figura e decrita a eguir:, Inicialização: atravé de etímulo, é etabelecida uma infra-etrutura viando a melhoria do proceo; ' Diagnótico: é gerado um diagnótico documentado da prática atuai e documentação para melhorá-la; ( Etabelecimento: ão etabelecida e documentada a etratégia e a prioridade, ão identificado o proceo e o recuro neceário e é elaborado um plano de ação para a melhoria do proceo; $ Ação: é realizada a melhoria de acordo com o planejado. São definido proceo e mediçõe, o quai ão planejado e executado; / Aprendizagem: ão documentada e analiada a liçõe aprendida e é revita a propota organizacional.!#"%$ c$ &%'%R678!7 V!2I ]R3r2G.0Z RU/3 M%&NNdP

35 Ca pítu lo 2. Revi ã o Bibliográ fica 22 3'&$3ODQ'R&KHFN$FWLRQ O PDCA é uma etratégia para a reolução de problema agindo no auxílio do encontro de oluçõe atravé de um proceo etruturado e ordenado, em que cada pao depende da execução do anterior (FAESARELLA HWDO., 1998) (McMANUS, 1996). O ciclo PDCA também pode er utilizado como auxiliar no gerenciamento da qualidade e na verificação da aplicação do conceito e prática da qualidade dentro de um determinado contexto (CORTÊS, 2001). Ete ciclo é compoto por quatro fae, a quai ão decrita a eguir e ilutrada na Figura 2.8.2: 3 Planejar: conite em etabelecer meta obre o reultado do proceo, a maneira e método para atingi-la; ' Executar: trata de realizar a tarefa de acordo com o plano e coleta de dado para a verificação do proceo; &Verificar: via comparar o reultado alcançado com a meta planejada; $ Agir: objetiva atuar de forma a corrigir o devio obervado e prevenir futura ocorrência. FAESARELLA HWDO. (1998) citam o uo do PDCA na manutenção e melhoria do proceo. Em proceo não repetitivo, ele pode er uado em melhoria do nível de deempenho, em que o plano conta de uma meta e um método que decreve o procedimento neceário para atingi-la.!#"%$ c$ ;X[]>3qG > 3U/[KtCM&NN"P

36 Ca pítu lo 2. Revi ã o Bibliográ fica 23 0RGHORVGH0DWXULGDGH Com o preupoto de que o deenvolvimento de um oftware deve orientar-e pelo princípio que regem a técnica e prática de deenvolvimento de um produto, HUMPHREY (1987a) ugere que a capacitação na produção de oftware buque: º proceo bem definido; º evolução do proceo; º controle etatítico. Segundo ROCHA HW DO (2001), para que o proceo de oftware eja realizado corretamente, deve apreentar: º procedimento e método que decrevam claramente a ligação entre a tarefa; º ferramenta e equipamento para facilitar e automatizar o trabalho; º peoa treinada para poderem realizar a atividade. A partir da neceidade de melhoria do proceo de oftware foram definido vário modelo e norma, entre ele podem er citado a norma internacional NBR ISO/IEC (Tecnologia da Informação Proceo de Ciclo de Vida do Software), o SPICE 6RIWZDUH 3URFHVV,PSURYHPHQW DQG&DSDELOLO\ G(WHUPLQDWLRQ H o SW-CMM &DSDELOLW\ 0DWXULW\ 0RGHO IRU 6RIWZDUH elaborado pelo SEI 6RIWZDUH (QJLQHHULQJ,QVWLWXWH A eçõe eguinte detalham o modelo e norma etudado para verificação do qual eria adaptado ao proceo de reengenharia, o que reultou da ecolha e uo do SW- CMM.,62,(& Eta norma tem como objetivo principal auxiliar eu uuário a definir eu papéi na produção de oftware, atravé de proceo bem definido e de um melhor entendimento da atividade a erem realizada (ISO, 1995). A ISO divide o proceo relacionado ao ciclo de vida do oftware em trê clae de acordo com ua natureza: 3URFHVVRV )XQGDPHQWDLV proceo báico realizado dede a contratação do fornecedor para a elaboração do oftware até ua manutenção durante o ciclo de vida: º Proceo de Aquiição; º Proceo de Fornecimento;

37 Ca pítu lo 2. Revi ã o Bibliográ fica 24 º Proceo de Deenvolvimento; º Proceo de Operação; º Proceo de Manutenção; 3URFHVVRV GH $SRLR proceo que auxiliam e contribuem para a qualidade do projeto de oftware: º Proceo de Documentação; º Proceo de Gerência de Configuração; º Proceo de Garantia da Qualidade; º Proceo de Verificação; º Proceo de Validação; º Proceo de Revião Conjunta; º Proceo de Auditoria; º Proceo de Reolução de Problema; 3URFHVVRV 2UJDQL]DFLRQDLV proceo empregado geralmente fora do domínio do projeto, ma que contribuem para a melhoria da organização: º Proceo de Gerência; º Proceo de Infra-Etrutura; º Proceo de Melhoria; º Proceo de Treinamento. 63,&( O SPICE 6RIWZDUH3URFHVV,PSURYHPHQWDQG&DSDELOLW\G(WHUPLQDWLRQfoi lançado com o objetivo de gerar norma para a avaliação de proceo, viando a melhoria ua contínua e a determinação de ua capacitação (ROCHA HWDO., 2001) (ROUT, 2000). O documento do projeto SPICE foram organizado em um conjunto de nove parte em forma de um relatório técnico ISO, endo apena a parte 2 e 3 normativa e a demai apena informativa, como motra o Quadro u0vwxywz?{ }% ~ z %v 2ƒ% Wz% 2 vƒ/ z Xˆ ƒ% kzxˆywzš ƒ WzA Œ Ž = Ž 0 { %~ 3DUWH 1 2 'HVFULomR (Informativa) Contém o ponto de entrada do documento. Decreve a organização geral do SPICE. (Normativa) Decreve o modelo de dua dimenõe, proceo e ua capacidade.

38 Ca pítu lo 2. Revi ã o Bibliográ fica 25 (Normativa) Decreve o requiito para a realização de uma avaliação de forma 3 que o reultado ejam repetívei. (Informativa) Fornece orientaçõe para a realização de avaliaçõe em vário 4 contexto. (Informativa) Ilutra um modelo de referência detalhado para a realização de 5 avaliaçõe. 6 (Informativa) Decreve o requiito para a qualificação de avaliadore. (Informativa) Apreenta orientaçõe no uo do modelo como guia na melhoria de 7 proceo. (Informativa) Apreenta orientaçõe no uo do modelo como guia em avaliaçõe 8 da capacidade de um fornecedor em potencial. 9 (Informativa) Vocabulário. O modelo herdou da ISO a arquitetura do proceo e do ciclo de vida do oftware e do SW-CMM o conceito de nívei de maturidade de proceo, definindo dua dimenõe: 1. 'LPHQVmR GH 3URFHVVR correponde à definição de um conjunto de proceo fundamentai para a boa prática da engenharia de oftware, endo ee dividido em cinco categoria de acordo com o tipo de atividade que cobre: º Cliente (CUS): tem impacto direto obre o cliente; º Engenharia (ENG): epecifica, implementa, ou mantém um itema ou produto de oftware; º Gerência (MAN): etabelece o projeto, a coordenação e o gerenciamento do recuro; º Suporte (SUP): capacita e uporta a execução de outro proceo; º Organização (ORG): etabelece a meta de negócio da organização e o proceo de deenvolvimento, além de avaliar o recuro que irão ajudar a organização a alcançar ua meta. 2. 'LPHQVmRGH&DSDFLGDGHcorreponde à definição de um modelo de medição com bae na identificação de um conjunto de atributo que permite determinar a capacidade do proceo, ee modelo etabelece a ecala em ei nívei (0 a 5) que provêem a definiçõe da capacidade a ele relacionada e o caminho para a melhoria de qualquer proceo. Cada nível poui atributo que definem a caracterítica do proceo, o quai etão decrito no Quadro

39 Ca pítu lo 2. Revi ã o Bibliográ fica 26 u0vwxywz?{ }% { šƒ /x ƒ/žw ˆw % x wx ƒ#œ 8y8 v Wz% 2x ƒ2œywz ƒ %z% /xza Œ Ž X W 0ž %~ŸŸ} 1tYHO 'HVFULomR $WULEXWRV 3URFHVVR,QFRPSOHWR O proceo não etá implementado, ou falha para alcançar eu reultado. Nenhum atributo 3URFHVVR ([HFXWDGR O proceo é implementado e alcança eu reultado. Execução de Proceo 3URFHVVR *HUHQFLDGR O proceo é executado de forma gerenciada (planejado, acompanhado, verificado e ajutado) baeado em objetivo definido. Gerenciamento de Performance Gerenciamento de Produto de Trabalho 3URFHVVR (VWDEHOHFLGR O proceo é executado uando diretrize definida baeada no princípio de engenharia de oftware e é capaz de alcançar eu reultado. Definição de Proceo Recuro de Proceo 3URFHVVR 3UHYLVtYHO O proceo é executado de forma conitente, dentro do limite definido para alcançar eu reultado. Medida de Proceo Controle de Proceo 3URFHVVR 2WLPL]DGR O proceo muda dinamicamente e adapta-e para atifazer efetivamente a meta de negócio projetada. Mudança de Proceo Melhoria Contínua Em 1998, foi lançado um documento (SPICE, 1998) que atenuava conideravelmente o choque com o modelo da qualidade já exitente A principai mudança ão em relação ao volume de documento, reduzido para cinco parte, como motra o Quadro u0vwxywz?{ }% ƒ v wxzax w 2 Azx 8 w ƒ A %z% /xz %v% 2ƒ Wz% /xz2 Œ Ž = Ž 0 { %~ 3DUWHV 'HVFULomR 2ULJHP 1 Conceito e vocabulário Antiga parte 1 e 9 2 Requiito para a realização de avaliaçõe Antiga parte 2 e 3 3 Guia para a realização de avaliaçõe Antiga parte 4 e 6 4 Guia para a utilização do reultado de avaliaçõe Antiga parte 7 e 8 5 Modelo-exemplo para avaliaçõe Antiga parte 5 6:&00 Em 1987, o SEI lançou uma breve decrição de ua etrutura de maturidade de proceo (HUMPHREY, 1987a) e apó quatro ano de experiência, evoluiu ea etrutura para o &DSDELOLW\0DWXULW\0RGHOIRU6RIWZDUH (PAULK HWDO., 1991). A evolução dee modelo baeou-e no conhecimento adquirido da avaliaçõe de proceo de

40 Ca pítu lo 2. Revi ã o Bibliográ fica 27 oftware e extenivo IHHGEDFN da organizaçõe e de órgão governamentai norteamericano que o utilizaram em nível de tete (FIORINI HWDO., 1998). A verão 1.0 de agoto de 1991 foi uada e reviada e em fevereiro de 1993 foi lançada a verão 1.1 do SW-CMM, atualmente em uo (PAULK HWDO., 1993a) (PAULK HW DO., 1993b). A partir daí, o modelo tornou-e uma bae para o programa de melhoria, por ua poição de primeiro modelo de avaliação e capacitação definido, endo uado por deenvolvedore de outro modelo de melhoria (ROUT, 1998). O SW-CMM foi deenvolvido em uma etrutura de etágio de maturidade, nívei de melhoria crecente, viando alcançar um proceo de oftware maduro. Cada nível compreende um conjunto de meta de proceo que, quando atifeita, etabilizam um importante componente do proceo de oftware. Ea etrutura etá baeada no princípio de gerência de proceo do TQM 7RWDO 4XDOLW\ 0DQDJHPHQW (DoD, 1988), que tratam da aplicação de método quantitativo e recuro humano para melhorar: º o material e o erviço fornecido a uma organização; º todo o proceo dentro de uma organização; º o grau de conhecimento da neceidade do cliente, agora e no futuro (HUMPHREY, 1987b). A Figura motra a etrutura do nívei de maturidade do SW-CMM e o Quadro 2.8.4, a caracterítica de cada nível. vy w#{% } % šƒ /x ƒ2 Fw 8vy8 x wx ƒ#xz2 q Ž # Œœ ž ª«q % %~ŸŸw

41 Ca pítu lo 2. Revi ã o Bibliográ fica 28 u0vwxywz?{ }% Žw y w ƒ yw j w 2xz% A šƒ /x ƒ2 Fw 8vy8 x wx ƒ#xz2 q Ž # _ 0 % ~ŸŸ} 1tYHO 6:&00,QLFLDO 5HSHWLWLYR 'HILQLGR *HUHQFLDGR 2WLPL]DGR &DUDFWHUtVWLFDV O proceo de deenvolvimento de oftware é uma caixa preta, de forma que omente a entrada e o produto finai podem er vito com clareza. Como a equenciação da atividade é fracamente definida, há grande dificuldade no etabelecimento do etado da atividade e do progreo do projeto. A capacitação do proceo nee nível é impreviível, poi o memo ou não etá explicitamente definido ou é contantemente alterado com o decorrer do trabalho. O cronograma, orçamento, funcionalidade e qualidade do produto ão geralmente impreviívei. O proceo paa a ter um nível báico de controle, aindo de uma única caixa preta para uma eqüência de caixa preta, que aeguram a viibilidade em determinado ponto do proceo chamado marco de acompanhamento de progreo. Ee marco permitem verificar e o projeto etá eguindo como planejado. O planejamento de novo projeto é baeado em experiência adquirida com projeto imilare já realizado e documentado. A capacitação do proceo é melhorada projeto a projeto, atravé do etabelecimento de diciplina báica de gerência de proceo. A organização interna da tarefa é definida e viível, não endo mai coniderada como caixa preta. O envolvido conhecem ua reponabilidade e papéi. Dado a repeito de modificaçõe no projeto podem er obtido de forma rápida e egura. O proceo etabelecido ão uado e alterado quando apropriado, para ajudar a equipe de deenvolvimento a deempenhar mai efetivamente ua atividade. Na padronização do proceo de oftware ão uada prática eficaze de engenharia de oftware. O proceo de oftware definido é intrumentado e controlado quantitativamente. São medida a qualidade e a produtividade para atividade importante do proceo de oftware, abrangendo todo o projeto. É mantido um controle obre ee reultado de forma a verificar a variância em eu deempenho, para que e poa garantir que o projeto etejam empre dentro de limite aceitávei. Vito que o proceo é etável e medido, e ocorrer algum evento ineperado, a coneqüência poderão er identificada e abordada minimizando eu impacto. Tenta-e, de maneira contínua e controlada, identificar, avaliar e elaborar nova forma de deenvolvimento para o proceo de oftware, de forma a melhorar a qualidade e a produtividade. O proceo ão avaliado viando prevenir defeito recorrente e a liçõe aprendida ão dieminada pela equipe. A capacitação nee nível, pode er caracterizada como endo de melhoria contínua, poi há empre um eforço para e melhorar a capacidade do proceo.

42 Ca pítu lo 2. Revi ã o Bibliográ fica 29 Com exceção do Nível 1, cada nível de maturidade é compoto por KPA.H\ 3URFHVV$UHDV. Ea área-chave contituem a primeira divião itemática dentro do nívei de maturidade, decrevendo a meta que devem er atingida e a quetõe que devem er tratada para que e alcance ea meta e, com io, o nível de maturidade pretendido. A eguir ão decrita a KPA que devem er implementada para o alcance do nível 2 de maturidade (PAULK HWDO., 1993b): ¾ *HUHQFLDPHQWR GH 5HTXLVLWRV Tem por finalidade definir de forma clara o requiito alocado ao oftware e controlar ua evolução, de modo que empre que o requiito forem alterado, o plano, o produto de trabalho e a atividade afetada ejam ajutada para e manterem conitente. De acordo com (PAULK HWDO., 1993b) o requiito não e referem omente à funcionalidade deejada para o oftware, ma também à quetõe não funcionai, endo definido para o oftware o UHTXLVLWRVIXQFLRQDLV, que epecificam a funçõe que o oftware deve er capaz de executar e o UHTXLVLWRV QmRIXQFLRQDLV, acordo, retriçõe e/ou condiçõe contratuai que afetam e determinam a atividade do oftware. Para o Gerenciamento de Requiito ão definida dua meta: º Meta 1:controlar e documentar o requiito alocado e de forma a etabelecer uma EDVHOLQH para uo gerencial; º Meta 2: manter o plano, produto de trabalho e atividade de forma conitente com o requiito alocado. De forma a documentar ea KPA, ugere-e a criação do Documento de Requiito Alocado em que ão documentado o requiito do oftware. ¾ 3ODQHMDPHQWRGR3URMHWRGH6RIWZDUHEnvolve o deenvolvimento um plano para deempenhar o trabalho, no qual ão decrito, entre outro apecto, a reponabilidade e compromio, a etimativa para o tamanho do produto de trabalho e o recuro neceário para todo o projeto. Para o Planejamento do Projeto de Software ão definida trê meta: º Meta 1: documentar a etimativa a erem uada no planejamento do projeto; º Meta 2: planejar e documentar a atividade e o compromio do projeto; º Meta 3: obter a concordância de todo o envolvido no projeto com relação ao compromio aumido. ¾ $FRPSDQKDPHQWR H 6XSHUYLVmR GR 3URMHWR GH 6RIWZDUH Eta KPA tem por finalidade verificar o progreo do projeto, comparando o reultado obtido com o

43 Ca pítu lo 2. Revi ã o Bibliográ fica 30 que foi documentado no Plano do Projeto (criado na KPA Planejamento do Projeto), com relação à etimativa, ao compromio e à atividade planejada. Deve-e documentar toda a diferença encontrada, para poterior análie e acompanhamento até ua reolução. Foram definida trê meta para ea KPA: º Meta 1: acompanhar e confrontar o reultado da execução do projeto com o Plano do Projeto; º Meta 2: realizar açõe corretiva empre que o reultado reai e deviarem do que foi planejado; º Meta 3: combinar a alteraçõe em compromio aumido entre todo o envolvido. O SEI não epecificou padrõe para documentação dea KPA, ma é neceária a criação de um Relatório de Acompanhamento para cada inpeção do progreo do projeto. Em cao erem realizada açõe corretiva, um documento deve er criado citando o fato que gerou a ação corretiva, o conteúdo da ação corretiva, o reponável por ua execução e a data de implementação da ação corretiva. ¾ *DUDQWLD GD 4XDOLGDGH GH 6RIWZDUH Via fornecer uma vião da eficácia do proceo que etão endo utilizado no projeto e do produto que etão endo gerado, o que envolve reviar e auditar o produto de oftware e a atividade para aegurar que etão em conformidade com a epecificaçõe e plano aprovado. São quatro a meta da KPA Garantia da Qualidade: º Meta 1: planejar a atividade de Garantia da Qualidade; º Meta 2: verificar a conformidade da atividade e do produto de trabalho gerado com o procedimento e requiito alocado; º Meta 3: informar ao envolvido no projeto com relação à atividade e reultado da Garantia da Qualidade de Software; º Meta 4: notificar ao gerente toda a não-conformidade que não poam er reolvida no âmbito do projeto de oftware. Como na KPA Acompanhamento e Supervião do Projeto de Software, qualquer devio verificado na atividade e produto de oftware deve er documentado e tratado pela equipe de deenvolvimento de oftware de forma que voltem a refletir o que foi planejado. A documentação dee devio, contendo a açõe corretiva a erem implementada, o reponávei pela açõe corretiva e o cronograma para a realização da mema deve er gerada.

44 Ca pítu lo 2. Revi ã o Bibliográ fica 31 ¾ *HUHQFLDPHQWRGH&RQILJXUDomRO propóito dea KPA é controlar a alteraçõe e manter a integridade do produto de oftware gerado ao longo do ciclo de vida do projeto. Devem er elecionado o produto de oftware que erão gerenciado, ou eja, a configuração do oftware num dado momento. O produto de oftware ob a gerência de configuração ão denominado iten de configuração. Todo o iten de configuração ão gerenciado e controlado, io implica que exite uma rígida diciplina com relação à alteraçõe feita nee iten, de forma a manter conhecida a diferença entre cada uma de ua verõe, o que motivou tai alteraçõe e o reponávei pela mema. À medida que o oftware é deenvolvido, ão etabelecida EDVHOLQHV para o iten de configuração, que ervem de bae para deenvolvimento e alteraçõe futura. Cada EDVHOLQH é formalmente etabelecida e documentada. O proceo de deenvolvimento de oftware egue então de EDVHOLQH em EDVHOLQH, acumulando iten de configuração novo ou revito. A meta para o Gerenciamento de Configuração ão: º Meta 1: planejar a atividade de Gerenciamento de Configuração; º Meta 2: identificar, controlar e diponibilizar produto de oftware elecionado; º Meta 3: controlar a alteraçõe no produto de oftware identificado; º Meta 4: informar a peoa afetada a repeito da ituação e conteúdo da EDVHOLQHV do oftware. A alteraçõe no iten de configuração devem er formalizada. Para io, devem exitir Relatório de Alteraçõe entregue ao reponável pelo Controle de Configuração apó a alteraçõe erem realizada. ¾ *HUHQFLDPHQWR GH 6XE&RQWUDWRV GH 6RIWZDUH O objetivo dea KPA é elecionar ub-contrato com emprea qualificada e gerenciá-la de forma eficaz. Envolve elecionar tai emprea, etabelecer o compromio e acompanhar e reviar a performance e o reultado do ub-contrato. São quatro a meta do Gerenciamento de Configuração: º Meta 1: a emprea contratante deve elecionar ub-contratada de oftware qualificada; º Meta 2: a emprea contratante e ub-contratada devem aceitar o compromio aumido para amba; º Meta 3: a emprea contratante e ub-contratada devem manter comunicação;

45 Ca pítu lo 2. Revi ã o Bibliográ fica 32 º Meta 4: a emprea contratante deve acompanhar o deempenho da ubcontratada, comparando-o com o compromio aumido. Para ea KPA, o documento bae é o Contrato de Software, que contempla o termo e a condiçõe de trabalho de amba a emprea, o requiito para o produto de oftware a erem deenvolvido, a condiçõe na quai ocorrerão a inpeçõe do produto, além do procedimento e critério de avaliação a erem utilizado na verificação do deempenho da emprea ub-contratada. A KPA relativa ao alcance do Nívei de Maturidade 3 a 5 não foram decrita detalhadamente pelo fato de, nete trabalho, terem ido utilizada apena a KPA para alcance do Nível 2. A eguir ão apreentada reumidamente a meta para o atingimento da KPA do Nível 3: ¾ 'HILQLomRGR3URFHVVRGD2UJDQL]DomREnvolve deenvolver e manter o proceo de oftware padrão da organização, aim como o recuro relacionado ao proceo, como decriçõe de ciclo de vida de oftware, diretrize e critério para adaptação do proceo, o banco de dado de proceo de oftware da organização e uma biblioteca de documentação relacionada ao proceo de oftware. Foram elaborada dua meta para a Definição do Proceo da Organização: º Meta 1: deenvolver e manter um proceo de oftware padrão; º Meta 2: coletar, reviar e tornar diponívei toda a informaçõe relacionada ao uo do proceo de oftware padrão no projeto de oftware. ¾ )RFRQR3URFHVVRGD2UJDQL]DomRO proceo padrão deenvolvido, ou eja, do proceo operacional báico da organização, (ver KPA Definição do Proceo da Organização) é alvo de melhoria e adaptaçõe de forma a moldá-lo de acordo com a particularidade do projeto em que o memo é aplicado. Io envolve entender o proceo atual, e a partir daí avaliá-lo, deenvolve-lo e melhorá-lo. São meta dea KPA: º Meta 1: coordenar a atividade de melhoria no proceo de oftware atual; º Meta 2: identificar o ponto fraco e forte no proceo de oftware atual; º Meta 3: planejar a atividade de melhoria do proceo de oftware a nível organizacional. ¾ 3URJUDPD GH 7UHLQDPHQWR Caracteriza-e pelo correto treinamento da peoa envolvida na execução do proceo. A neceidade de treinamento ão identificada e, em eguida, exprea em plano, o quai ão executado e o

46 Ca pítu lo 2. Revi ã o Bibliográ fica 33 dado dee treinamento armazenado. A meta para o Programa de Treinamento ão: º Meta 1: planejar a atividade de treinamento; º Meta 2: prover treinamento para o deenvolvimento da habilidade e conhecimento neceário para realizar o proceo; º Meta 3: a peoa relacionada ao proceo recebem o treinamento neceário executar eu papéi. ¾ *HUHQFLDPHQWR GH 6RIWZDUH,QWHJUDGR O objetivo dea KPA é, a partir do proceo de oftware padrão e do recuro definido na KPA Definição do Proceo da Organização, deenvolver um proceo de oftware definido para cada projeto viando abranger a caracterítica epecífica de cada projeto. A meta do Gerenciamento de Software Integrado ão: º Meta 1: garantir que o proceo de oftware definido correponda a uma adaptação do proceo de oftware padrão; º Meta 2: planejar e gerenciar o projeto de acordo com o proceo de oftware definido. ¾ (QJHQKDULDGH3URGXWRVGH6RIWZDUHEnvolve integrar técnica de engenharia de oftware ao Proceo de Software Definido para o Projeto para gerar, de maneira eficaz e eficiente, produto de oftware correto e conitente. A meta da Engenharia de Produto de Software ão: º Meta1: definir, integrar e executar de forma conitente a tarefa de engenharia de oftware ao produzir o oftware; º Meta 2: manter a conitência do produto de trabalho que compõem o oftware. ¾ &RRUGHQDomR,QWHU*UXSRVEnvolve a interação do grupo de deenvolvimento do oftware com o demai grupo envolvido no projeto, de forma a garantir que o memo atifaça a meta propota e acordada entre todo. Foram definida trê meta para a Coordenação Inter-Grupo: º Meta 1: obter a concordância de todo o envolvido quanto ao requiito do cliente; º Meta 2: obter a concordância de todo o envolvido com relação ao compromio aumido entre o grupo; º Meta 3: identificar, acompanhar e reolver quetõe entre o grupo.

47 Ca pítu lo 2. Revi ã o Bibliográ fica 34 ¾ 5HYLV}HV A reviõe ão propota com a finalidade de remover, de forma eficiente, o defeito do produto de trabalho, ainda no etágio iniciai de ua criação. Ea reviõe podem ocorrer na forma de ZDONWKURXJV ou reviõe progreiva URXQGURELQ. São meta da reviõe: º Meta 1: planejar a reviõe; º Meta2identificar e remover o defeito no produto de trabalho. A eguir ão apreentada reumidamente a meta para o atingimento da KPA do Nível 4: ¾ *HUHQFLDPHQWR 4XDQWLWDWLYR GR 3URFHVVR Via controlar quantitativamente o deempenho do proceo, etabelecendo meta de deempenho para o Proceo de Software Definido, a quai ão verificada atravé da aplicação e análie de métrica. Em cao de não-alcance da meta definida, devem er etabelecido ajute para o proceo. A meta para o Gerenciamento Quantitativo do Proceo ão: º Meta 1: planejar a atividade de gerenciamento quantitativo do proceo; º Meta 2: controlar quantitativamente o deempenho do Proceo de Software Definido para o Projeto; º Meta 3: conhecer, em termo quantitativo, a capacitação do proceo de oftware padrão da organização. ¾ *HUHQFLDPHQWR GD 4XDOLGDGH GH 6RIWZDUH Tem como objetivo deenvolver um entendimento quantitativo da qualidade do produto de oftware e alcançar meta epecífica de qualidade. Envolve ainda definir meta de qualidade para produto de oftware, definir plano para alcançar ea meta e monitorar e ajutar o plano de oftware, produto de trabalho, atividade e meta de qualidade de modo que etejam capacitado a atifazer o plano etabelecido. A meta para o Gerenciamento da Qualidade de Software ão: º Meta 1: planejar a atividade de Gerenciamento da Qualidade de Software; º Meta 2: definir meta menurávei e prioridade para a qualidade do produto de oftware; º Meta 3: gerenciar e quantificar o progreo real do proceo para atingir a meta da qualidade para o produto de oftware.

48 Ca pítu lo 2. Revi ã o Bibliográ fica 35 A eguir ão apreentada reumidamente a meta para o atingimento da KPA do Nível 5: ¾ 3UHYHQomR GH 'HIHLWRV Via identificar a caua de defeito e prevenir ua recorrência, reduzindo o volume de defeito no produto de oftware. Envolve analiar o defeito encontrado no produto gerado e implementar açõe epecífica para que ua ocorrência poa er prevenida em futuro trabalho. Há trê meta definida para a Prevenção de Defeito: º Meta 1: planejar a atividade de prevenção de defeito; º Meta 2: bucar e identificar a caua comun de defeito; º Meta 3: priorizar e eliminar itematicamente a caua comun de defeito. ¾ *HUHQFLDPHQWR GD (YROXomR GRV 3URFHVVRV Tem por objetivo melhorar continuamente o proceo de oftware utilizado, aumentando a produtividade e diminuindo o tempo para o deenvolvimento do produto. Envolve a definição de meta de melhoria do proceo e a identificação, avaliação e implementação de melhoria no proceo de oftware. Há trê meta para o Gerenciamento da Evolução do Proceo: º Meta 1: planejar a melhoria contínua do proceo; º Meta 2: aegurar a ampla participação de todo na atividade de melhoria do proceo de oftware da organização; º Meta 3: melhorar continuamente o proceo de oftware padrão da organização e o proceo de oftware definido para o projeto. ¾ *HUHQFLDPHQWR GD (YROXomR GD 7HFQRORJLD Seu propóito é identificar nova tecnologia (ferramenta, método, proceo) e acompanhar eu uo de maneira regular. Sua meta ão a eguinte: º Meta 1: planejar a incorporação de mudança tecnológica; º Meta 2: avaliar nova tecnologia para determinar eu efeito na qualidade e na produtividade; º Meta 3: tranferir nova tecnologia apropriada para a prática de rotina da organização. Toda a KPA do SW-CMM ão organizada em Caracterítica Comun que tratam o fatore neceário para ua efetiva implementação e intitucionalização, dividindo-e de acordo com o eguinte tipo:

49 Ca pítu lo 2. Revi ã o Bibliográ fica 36 º &RPSURPLVVRVDGHVHPSHQKDUaçõe tomada pela organização para garantir que o proceo erá etabelecido e duradouro; º +DELOLWDo}HV D GHVHPSHQKDU pré-condiçõe que devem exitir na organização de forma a prover a implementação de maneira efetiva; º $WLYLGDGHVUHDOL]DGDV atividade neceária para implementar uma KPA; º 0HGLo}HV H DQiOLVHV mediçõe utilizada para determinar o etado de implementação do proceo; º 9HULILFDomR GD LPSOHPHQWDomR açõe realizada no entido de aegurar que a atividade ão implementada de acordo com o proceo etabelecido. Cada &DUDFWHUtVWLFD &RPXP contém um número de 3UiWLFDV &KDYH, que decrevem a infra-etrutura organizacional requerida ou a atividade a erem executada, para a intanciação da KPA. A Figura ilutra ea organização. O 1tYHLV GH 0DWXULGDGH ão organizado conforme Figura (página 27) e a ÈUHDV &KDYHGH3URFHVVR(KPA) decrita a partir da página 29. vy w#{% } % 8y8v 8vy w#x w?«œœ 2xzA ± Ž # _ 0 % ~ŸŸ}

50 Ca pítu lo 2. Revi ã o Bibliográ fica 37 80/8QLILHG0RGHOLQJ/DQJXDJH A UML foi elaborada para epecificar, contruir, viualizar e documentar itema de oftware. Surgiu da evolução de vário método, ilutrado na Figura 2.9.1, endo ua notação a união da intaxe de: Diagrama de BOOCH (1991), Fuion de COLEMAN HWDO. (1994), 6WDWHFKDUWVde HAREL (1987), OMT 2EMHFW0RGHOLQJ7HFKQLTXH de RUMBAUGH HWDO. (1991), OOSE 2EMHFW2ULHQWHG6RIWZDUH(QJLQHHULQJ de JACOBSON HWDO (1992). vy w#{% Ÿ ~% zyw 2w ²zAx waž #ª -œx w ˆ wx w/x ƒ/ WŒ œ F { %~ A ecolha de quai modelo e diagrama devem er criado têm influência obre como um problema é atacado e como a correpondente olução é modelada. A chave para melhor exprear o problema é a abtração, o foco no detalhe relevante enquanto outro ão ignorado, porque: º Todo itema complexo é melhor abordado atravé de pequeno conjunto de viõe independente de um diagrama, uma vião única não é uficiente; º Cada diagrama pode er expreo em diferente grau de abtração; º O melhore diagrama etão conectado à realidade (OMG, 1999). A UML define nove diagrama deenvolvido ao longo da fae decrita acima, o quai ão reumidamente decrito pelo Quadro u0vwxywz?{ Ÿ% ~ w y w 2w/x ƒ 8 xz%?ˆƒ% waž #ª 'LDJUDPDV Diagrama de Atividade 'HVFULomR Motra o fluxo entre a atividade do itema e como a mema ão realizada na interação entre o itema e o uuário.

51 Ca pítu lo 2. Revi ã o Bibliográ fica 38 Diagrama de Clae Diagrama de Colaboração Diagrama de Componente Motra o conjunto de clae do itema e o relacionamento entre ela. Repreenta a interação entre intância de clae, objeto ou entidade atravé de uma eqüência de menagen que implementam uma operação ou uma tranação. Motra a organização e a dependência entre o componente do oftware, incluindo componente do código fonte, componente do código binário e componente executávei. Um módulo do oftware é repreentado como um tipo de componente. Diagrama de Motra o etado do objeto de uma clae, o evento que cauam a Etado tranição de uma clae para outra e a açõe que reultam de uma tranição de etado. Diagrama de Motra a conexõe fíica entre o proceadore, o dipoitivo e a Implementação alocação do proceo ao proceadore, endo um proceador um componente do hardware capaz de executar programa. Diagrama de Objeto Diagrama de Seqüência Diagrama de 8VH&DVHV Modela intância de iten contido em diagrama de clae, motrando um conjunto de objeto e eu relacionamento em determinado ponto no tempo, provendo a viualização de apecto etático de itema. Motra uma interação organizada em uma eqüência de tempo entre o objeto participante de uma operação e ua troca de menagen. Repreenta graficamente algun ou todo o atore, o XVHFDVHV e ua interaçõe, endo utilizado para epecificar ou caracterizar a funcionalidade e o comportamento do oftware. 2$PELHQWHGH3URJUDPDomR'HOSKL O ambiente Delphi foi uma da primeira ferramenta a er elaborada para o deenvolvimento de oftware viuai para o itema operacional :LQGRZV. Ante de ua criação, o deenvolvimento dee tipo de oftware era muito trabalhoo vito que o programadore tinham que e preocupar com o que o PRXVH etava fazendo, em que parte do menu o uuário etaria, e o clique do PRXVH era imple ou duplo, o que exigia centena de linha de código em C, por exemplo, para uma imple tarefa (CORNELL, 1995). O ambiente de deenvolvimento Delphi utiliza o 2EMHFW Pacal como linguagem para a implementação de oftware. Apó ua criação foram originado outro ambiente emelhante, como o C++ %XLOGHU com C++ como linguagem (SCHILDT, 2001), o J %XLOGHU com Java como linguagem (FORD, 1999), entre outro. O Delphi continua competindo igualmente com ea ferramenta e, com o lançamento do.\ol[ (SONNINO,

52 Ca pítu lo 2. Revi ã o Bibliográ fica ) (verão do ambiente Delphi para o itema operacional Linux), a quetão da portabilidade, caracterítica que favorecia a linguagem Java na ecolha durante o projeto do oftware, tornou-e deciiva para a afirmação do Delphi como um do ambiente predominante para o deenvolvimento de oftware (INPRISE, 1999). Podem er citada vária caracterítica que fazem do ambiente Delphi um do mai utilizado atualmente, entre ela: º O oftware deenvolvido com o Delphi têm praticamente a mema velocidade do oftware deenvolvido em C ou C++; º Com o Delphi podem er contruída DLL '\QDPLF/LQN/LEUDULHV º Podem er contruído objeto reutilizávei eguindo o paradigma da orientação a objeto (INPRISE, 1999). O ambiente Delphi, organiza o código-fonte do oftware em deenvolvimento da eguinte forma: º Arquivo ".pa": contém o código fonte implementado com a linguagem 2EMHFW3DVFDO. Cada XQLWDelphi etá aociada a um arquivo dee tipo; º Arquivo ".dfm": "Delphi ForM", contém a decriçõe do controle do )RUP(interface do aplicativo) com ua repectiva propriedade; º Arquivo ".dpr": "Delphi PRoject", arquivo principal do projeto, com a lita de XQLWV uada e a inicialização da aplicação; º Arquivo ".dof": "Delphi Option File", arquivo com a opçõe do projeto. Exemplo: diretiva, diretório e opçõe de compilação; º Arquivo ".re": "RESource", recuro do projeto. Exemplo: ícone e ELWPDSV utilizado. &RQVLGHUDo}HV)LQDLV Não exite na literatura um proceo único, definido e documentado para a condução da reengenharia orientada a objeto. Dea forma, a partir do trabalho de DEMEYER HWDO(2000a, 2000b) e RECCHIA (2002a), obervou-e que padrõe podem er elaborado para direcionar o engenheiro de oftware na condução dee proceo por tratar-e de uma forma útil e didática de decrever eu pao e atividade.

53 Ca pítu lo 2. Revi ã o Bibliográ fica 40 Outro apecto relevante verificado na literatura foi a importância da engenharia revera dentro do proceo de reengenharia para o aumento da manutenibilidade de itema legado, pelo fato de e gerar toda a ua documentação, muita veze inexitente ou deatualizada. Com a recuperação da documentação de itema legado atravé da engenharia revera, pode-e obter ganho ignificativo de entendimento do oftware auxiliando-e na etapa de manutenção. Em eguida, com o proceo de engenharia avante é poível prover a ua implementação em plataforma, ambiente e/ou paradigma mai moderno. A qualidade de proceo atualmente batante referenciada em e tratando do proceo de deenvolvimento de oftware, foi também coniderada pelo fato da importância de garantir que tanto o proceo como o produto gerado com a aplicação do proceo de reengenharia tenham qualidade, ou eja, contemplem todo o requiito exitente no oftware legado. Utilizando a UML, o engenheiro de oftware é capaz de prover o modelo de análie e projeto do oftware durante ua reengenharia. Pelo fato de haver vária ferramenta de modelagem UML, a documentação gerada a partir dela pode facilmente er detalhada, expandida ou melhorada.

54 41 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto &RQVLGHUDo}HV,QLFLDLV Ete capítulo apreenta o Proceo de Reengenharia Orientada a Objeto (PRE/OO). Ee proceo conite da evolução do método Fuion/RE (PENTEADO, 1996a) endo utilizada a UML (OMG, 1999) para repreentar o modelo orientado a objeto. Além dio, é apreentada a mudança na forma de condução do proceo de eqüencial linear para evolutivo. Outro apecto coniderado é a melhoria da qualidade tomando por bae a KPA do Nível 2 de maturidade do SW-CMM (PAULK HWDO, 1993a). O proceo propoto, por meio de padrõe, via auxiliar o engenheiro de oftware na plena realização da reengenharia orientada a objeto. Para io, a Família de Padrõe para Reengenharia Orientada a Objeto propota por RECCHIA (2002a) é adaptada para itema implementado em Delphi em a utilização do paradigma orientado a objeto, que erão convertido para Delphi orientado a objeto. A Figura ilutra a origen do PRE/OO. ³ µ #¹%º»º»%¼½0 8 µ ¾ À/ÁÂXÃÄ Å Æ ½ ½

55 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 42 Ete Capítulo apreenta na Seção 3.2 a vião geral do PRE/OO; a Seção 3.3 contém o FOXVWHUV de padrõe relacionado à melhoria da qualidade do PRE/OO. A Seção 3.4 decreve o padrõe que correpondem ao trê primeiro pao do PRE/OO, o quai compõem a engenharia revera e a Seção 3.5, o FOXVWHUV de padrõe relacionado à engenharia avante. A Seção 3.6 apreenta a conideraçõe finai. 23URFHVVRGH5HHQJHQKDULD2ULHQWDGDD2EMHWRV35(22 A experiência adquirida com a utilização do Fuion/RE (PENTEADO 1996a) em algun itema norteou a ua evolução para o PRE/OO, como ilutra a Figura Ea evolução e fez neceária poi a aplicação do método nem empre pode er feita de forma eqüencial, como ilutrado Figura (página 10), apreentada no Capítulo 2. O uo do Fuion/RE vem ocorrendo de forma evolutiva devido à neceidade do retorno, alguma veze, ao pao anteriore para tornar eu reultado mai completo. Porém, ente-e a neceidade de que um proceo de reengenharia eja planejado e avaliado. Dea forma, o PRE/OO foi criado aproveitando no FOXVWHUV2, 3 e 4, técnica do Fuion/RE. A Figura ilutra o proceo de reengenharia orientada a objeto denominado PRE/OO, o qual é organizado em ete FOXVWHUV de padrõe. Algun padrõe foram adaptado a partir da Família de Padrõe para Reengenharia Orientada a Objeto, propota por RECCHIA (2002a), para a obtenção do modelo de análie orientado a objeto, comprovando que o modelo evolutivo é o mai adequado. O FOXVWHUV de padrõe do PRE/OO dividem-e em: º padrõe para a realização da reengenharia orientada a objeto (FOXVWHUV3 a 7); º padrõe para a melhoria da qualidade da reengenharia (FOXVWHUV1 e 2). O FOXVWHUV 3 a 5, reponávei pela engenharia revera, foram elaborado com bae no pao 1 a 3 do Fuion/RE, repectivamente. Porém, cada um dee pao pode er realizado de forma evolutiva, como indicam a eta em torno da elipe, diferentemente do Fuion/RE, eqüencial linear. O pao foram influenciado, também, pela FaPRE/OO de RECCHIA HWDO. (2002b).

56 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 43 O FOXVWHUV 6 e 7 dizem repeito ao proceo de engenharia avante, tendo ido elaborado com bae na extenão do Fuion/RE (PENTEADO HW DO., 1999) e no proceo evolutivo. ³ µ #¹%º Ǻ»%¼È ÀÉÂ?Êt¾ %ËÁÂ%ÀXÌ ÍÎ ÏjÎ Á ¾2à Á Ð ¾À2Á ÂXÃÄ ÅÆ ½ ½

57 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 44 O FOXVWHUV 1 e 2 implementam a melhoria da qualidade no proceo de reengenharia baeado na KPA do Nível 2 de maturidade do SW-CMM. O FOXVWHU 1, trata da preparação e do planejamento, endo realizado anteriormente ao inicio do proceo de reengenharia. O FOXVWHU 2 trata do acompanhamento da aplicação do FOXVWHUV3 a 7. O pao a eguir decrevem a utilização do PRE/OO: º o engenheiro de oftware inicia o PRE/OO preparando e planejando o proceo de reengenharia orientada a objeto, ou eja, aplicando o FOXVWHU 1 apreentado na Figura Aim como acontece com o deenvolvimento de oftware, o proceo de reengenharia que conta de dua grande etapa: a engenharia revera e a engenharia avante, deve er preparado e planejado; º concluído ee planejamento, o engenheiro de oftware inicia a revitalização da arquitetura do oftware legado, com a aplicação do FOXVWHU 3 da Figura Pode-e permanecer nee pao enquanto o reultado neceitarem de refinamento, como indicam a eta em torno da elipe em que encontra-e o FOXVWHU; º obtido reultado atifatório, ou eja, tendo a informaçõe obtida refletido a funcionalidade do itema inicia-e a elaboração do Modelo de Análie do Sitema Atual (MASA), aplicando-e o padrõe FOXVWHU 4 da Figura Ee pao depende de reultado do pao anterior e por ee motivo recomenda-e que eja iniciado apó a obtenção do produto do FOXVWHU 3, em ua primeira aplicação. O memo acontece com o Modelo de Análie do Sitema, obtido a partir da aplicação do FOXVWHU 5 da Figura 3.2.1, em relação ao MASA. O reultado do MASA ão utilizado e devem repreentar de forma clara a implementação atual do itema. Portanto, um eboço do MAS pode er elaborado apó a aplicação do doi grupo de padrõe anteriormente citado. Jutifica-e a adoção do modelo evolutivo, poi podem er neceária mai epecializaçõe no produto obtido anteriormente; º apó o término da verão preliminar do MAS ou memo durante ua elaboração, pode-e retornar ao pao anteriore quanta veze forem neceária de forma a elaborar como produto final o modelo orientado a objeto do oftware; º a partir da obtenção do MAS, inicia-e a elaboração do projeto avante do itema com a aplicação do padrõe do FOXVWHU 6 da Figura 3.2.1; º em eguida, é realizada a re-implementação do itema legado (aplicação do FOXVWHU 7 da Figura 3.2.1), que acontece com bae no modelo de projeto e na demai informaçõe neceária, a quai podem er obtida a partir do pao anteriore;

58 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 45 º a aplicação do padrõe que compõem o FOXVWHUV3 a 7, é intercalada pela aplicação do padrõe do FOXVWHU 2, atravé de inpeçõe e controle que tratam da manutenção da qualidade do proceo de reengenharia. O proceo pode er reiniciado a partir de qualquer um do FOXVWHUV 3 a 7 e, cada padrão, aplicado quanta veze for neceário. Na medida em que o proceo evolui, reinicia-e a partir de FOXVWHUV poteriore do PRE/OO, porém a volta ao anteriore pode er neceária também para anar dúvida. O PRE/OO foi deenvolvido para que engenheiro de oftware poam realizar a reengenharia orientada a objeto de oftware Delphi em documentação e/ou deenvolvido de forma não orientada a objeto. Aim, ee itema podem ter ua documentação recuperada e paam a refletir a forma orientada a objeto, mai etruturada e com maior capacidade de reuo de eu módulo. Realta-e que o PRE/OO pode er coniderado um proceo genérico no que diz repeito à realização da reengenharia em oftware legado. Porém, podem er neceária alguma adaptaçõe, para a condução da reengenharia orientada a objeto em oftware legado deenvolvido em outra linguagen procedimentai. Optou-e pela incluão de padrõe relacionado à melhoria da qualidade no proceo de reengenharia pelo fato de etudo terem comprovado que a qualidade do proceo conduz à qualidade do produto reultante (PAULK HWDO., 1993a). A partir dea premia, a KPA do Nível 2 do SW-CMM erviram de bae para compor o doi grupo de padrõe de melhoria da qualidade do PRE/OO (FOXVWHUV 1 e 2 da Figura 3.2.1). O proceo de reengenharia é decrito nete trabalho ob a forma de FOXVWHUV de padrõe eguindo o formato propoto na Linguagem de Padrõe de Engenharia Revera e Reengenharia (DEMEYER HW DO., 1999, 2000a) e também utilizada na Família de Padrõe para Reengenharia Orientada a Objeto (RECCHIA, 2002a). Cada padrão conta do eguinte iten: 1~PHUR 1RPH,QWXLWR 3UREOHPD &RQWH[WR,QIOXrQFLDV 6ROXomR $YDOLDomR -XVWLILFDWLYD ([HPSOR 8VRV &RQKHFLGRV 3DGU}HV 5HODFLRQDGRV e 3URGXWRV 2EWLGRV O iten $YDOLDomR e -XVWLILFDWLYDnão ão comentado na decriçõe do padrõe pelo fato de envolverem o uo dee por outro engenheiro de oftware.

59 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 46 3DGU}HVGH0HOKRULDGD4XDOLGDGHGR35(22 Segundo FIORINI HW DO. (1998), determinar o requiito em relação ao proceo de oftware é, em última análie, entender exatamente o quê deve er feito e o quê e epera receber como reultado. Adotando-e um paralelo para o proceo de reengenharia, há a neceidade da determinação da atividade e produto de trabalho a erem criado. O conjunto do produto de trabalho, quaiquer reultado imple ou compoto deenvolvido ao longo do proceo, compõe o requiito do proceo de reengenharia. A diferença entre um projeto e outro no que diz repeito à complexidade do oftware legado, ao domínio da aplicação e à fonte de dado auxiliare diponívei, tornam neceário o levantamento do requiito. Já, a partir da determinação da informaçõe obre o quê deve er feito, egue a determinação de como o proceo de reengenharia erá realizado, viando a elaboração do planejamento do projeto. Portanto, ante do inicio da reengenharia orientada a objeto, propriamente dita, o oftware deve ter eu ecopo contextualizado, a fonte de dado auxiliare e a ferramenta diponívei preparada, o planejamento do proceo realizado e o produto de trabalho definido. A partir dea neceidade, originou-e o FOXVWHU 1 3UHSDUDUH3ODQHMDUR3URFHVVRGH5HHQJHQKDULD, compoto pelo padrõe: º Padrão 1: Preparar o Proceo de Reengenharia, º Padrão 2: Planejar o Proceo de Reengenharia. A bae para a contrução dee FOXVWHU de padrõe foram a KPA 1 e 2 do Nível 2 de maturidade do SW-CMM, repectivamente. Houve a neceidade da criação de outro FOXVWHU de padrõe relacionado à qualidade do proceo (FOXVWHU 2), aplicado durante a realização da reengenharia orientada a objeto, o que levou à utilização e à adaptação da demai KPA do SW- CMM Nível 2, originando o trê padrõe que o compõem. A única KPA do Nível 2 de maturidade não utilizada foi o Gerenciamento de Sub-Contratado. O FOXVWHU 2 0HOKRUDU D 4XDOLGDGH GR 3URFHVVR GH 5HHQJHQKDULD agrupa o eguinte padrõe relacionado à melhoria da qualidade do PRE/OO: º Padrão 3: Acompanhar o Progreo do Proceo de Reengenharia, º Padrão 4: Realizar Inpeção de Garantia da Qualidade,

60 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 47 º Padrão 5: Controlar a Configuração. O padrão 3, Acompanhar o Progreo do Proceo de Reengenharia, via o acompanhamento do projeto, complementando o planejamento feito anteriormente, de forma a mantê-lo empre atualizado. A KPA Acompanhamento e Supervião de Projeto erviu de bae para a elaboração dee padrão. O padrão 4, Realizar Inpeção de Garantia da Qualidade via a realização de inpeçõe de garantia da qualidade no produto elaborado durante o proceo, endo inpirado na KPA Garantia da Qualidade. Segundo ROCHA HW DO. (2001), a inpeçõe ão atividade voltada para a garantia da qualidade que podem er aplicada ao longo de todo o proceo para a revião de um variado conjunto de produto de trabalho, com a vantagem de poderem er aplicada aim que o produto é elaborado. Completando-e a utilização da KPA do Nível 2 de maturidade do SW-CMM, foi criado o padrão 5, Controlar a Configuração, o qual é aplicado ao longo do proceo de reengenharia, eguindo o que recomenda a KPA Gerenciamento de Configuração em relação ao controle de verõe e o gerenciamento de EDVHOLQHV. A eguir ão detalhado o padrõe que compõem o FOXVWHUV1 e 2, que tratam da melhoria da qualidade do PRE/OO: &OXVWHU3UHSDUDUH3ODQHMDUR3URFHVVRGH5HHQJHQKDULD 1RPHPreparar o Proceo de Reengenharia,QWXLWRObter quai atividade erão realizada durante o proceo de reengenharia e quai produto erão elaborado. 3UREOHPDDefinir a atividade e o produto de trabalho reultante da aplicação do PRE/OO. &RQWH[WR A lita com o produto de trabalho que erão elaborado pode er obtida analiando-e o recuro diponívei. Já a atividade que devem er eguida para a obtenção dee produto dependem diretamente do que precia er elaborado e da análie do proceo decrito na eçõe eguinte (PRE/OO). 6ROXomR Elaborar um documento denominado Levantamento de Atividade, contendo a informaçõe contante do Quadro

61 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 48 Ñ Á WÂ?¹º ¹%º»¼%Ò0ÂÁ ¾%Ë ÂXÓ # #ÁÂÔ %Õ2¾ Ö ÉÂAÁÂXØ¾Ù Ö %Õ2¾% ÖWÂ?Á ¾4ÚÖ8 Ù Á Á ¾À LEVANTAMENTO DE ATIVIDADES 3URMHWR Û%ÛÜÝÞ#ß#àÝFá%â Ýäãjßå Ý æ%æ 'DWDGH&ULDomRGR'RFXPHQWR Û%Ûàíå í4ëîâ ï íð-êý æ%æ 9HUVmRGR'RFXPHQWR Û%Ûçèßâ éêý#àý4àýëìþ#ßü%å Ý æ%æ Åñ %Õ2¾#Á 4ò Ö8 É Û%Û4àßé-ëîâ ï ð-êý4àý0éýó å ôíâ ß0õ ßöíàÝ æ%æ Ö ¾ À?ø ÀÓ %ù Ù¾% À Û%Û4ó ÝÜ%å ßé0àß4àíàÝéFàï éèá ÝÜú çèßï éæ%æ à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%âa 4ò¾ ¾ÕþÅË ü%â Á Â%À Û%Û4àßé-ëîâ ï ð-êý4àýé á%â Ýàìå ÝéFí0éßâ ßÞÿößâ íàýé/æ%æ ÚÖä Ù Á Á ¾À/ #ò¾ ¾Õ ľ Ë Á À Û%Û4àßé-ëîâ ï ð-êý4àýé á íàâ ßé0àÝ ±í0éßâ ßÞ 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Û%ÛÜÝÞ#ß æ%æ í-á%õ ï ë-íàýé0àß4ó Ýâ Þ#í#í4ößâ íâýé á%â Ýàìå Ýé Üßë-ßéîéâ ï Ýé#æ%æ A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.1: º Projeto: contém o nome do oftware legado que erá ubmetido à reengenharia orientada a objeto; º Verão do Documento: conta do número adotado para diferenciar a modificaçõe realizada no documento durante a evolução do proceo de reengenharia e documentada no controle de configuração, cao realizada. O número de cada modificação deve obedecer ao formato propoto: 1.0 primeira verão do documento, 1.1 egunda verão do documento e aim uceivamente; ou a um formato ecolhido pelo engenheiro de oftware; º Data da Criação do Documento: data da criação da verão citada do documento. Como ee e outro campo erão utilizado em todo o modelo propoto, deve-e adotar o eguinte formato dd/mm/aaaa; º Reponável pela Criação do Documento: nome da peoa reponável pela criação da verão correpondente ao documento; º Exame da Situação: deve conter a contextualização do oftware em relação ao domínio em que etá inerido, contendo a decrição detalhada de ua funcionalidade para uo poterior como fonte de auxílio ao eu entendimento; º Iten Diponívei: contém a fonte de informaçõe diponívei para utilização durante o proceo de reengenharia. Em geral, conite de: código-fonte, arquivo de dado e programa executável;

62 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 49 º Produto de Trabalho a Serem Elaborado: compoto de produto que contém reultado imple ou compoto deenvolvido ao longo da reengenharia. O conteúdo dee campo varia conforme o Iten Diponívei; º Atividade a Serem Realizada: decrição de quai padrõe ão neceário à compoição do produto de trabalho acima citado. Dependendo do produto já diponívei, algun padrõe podem er omitido. ([HPSOR Supondo que um itema legado para controle de locaçõe de vídeo foe ubmetido ao proceo de reengenharia orientada a objeto, apó a aplicação do padrão, eria produzido o documento da Figura Nota-e que há apena algun iten diponívei para auxiliar a realização do proceo. Dentro dee conjunto citado, o iten código-fonte, arquivo de dado e programa executável (ou interface legada) formam a mínima quantidade de informação neceária para a realização da reengenharia com o PRE/OO. O PRE/OO foi elaborado baeando-e na exitência omente do iten acima citado. Porém, fonte auxiliare de informação, como o Manual do Uuário preente no exemplo, podem er útei na compoição de produto e, em algun cao, dipenar a aplicação de determinado padrõe. ³ µ #¹%º ¹º»%¼%Åñ¾ÕXÓ Ë ÂAÁ ¾/Á ÂÔ% Õ2¾% Ö ÉÂ?Á Â=Ø¾Ù Ö Õ2¾ ÖWÂAÁ ¾#ÚÖ8 Ù Á Á ¾À

63 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 50 $YDOLDomR... -XVWLILFDWLYD... 3DGUmR5HODFLRQDGRA aplicação dee padrão reulta na entrada para o padrão 2: Planejar o Proceo de Reengenharia. 3URGXWR2EWLGRDocumento Levantamento de Atividade. 1RPH Planejar o Proceo de Reengenharia,QWXLWRPlanejar a atividade de reengenharia definida com a aplicação do padrão Preparar Proceo de Reengenharia. 3UREOHPD Etimar o tempo, recuro e iten de configuração relacionado ao projeto de reengenharia do oftware legado. &RQWH[WRPlanejar a atividade, a partir do Documento Levantamento de Atividade obtido com a aplicação do padrão Preparar Proceo de Reengenharia.,QIOXrQFLDV É difícil etimar tempo para a realização do proceo de reengenharia e do pao no quai ee e ubdivide, Ea dificuldade pode er minimizada com a adoção de métrica de tamanho e/ou com o auxílio da experiência do engenheiro de oftware. 6ROXomR Elaborar um documento denominado Plano para Realização da Reengenharia contendo a informaçõe contante do Quadro 3.3.2, o qual deve er preenchido coniderando-e cada um do pao do proceo de reengenharia. Aim, ee plano etará completo omente quando todo o pao forem etimado. Ñ Á WÂ?¹º ¹%º Ç ¼%Ò0ÂÁ ¾%Ë ÂXÓ # #ÁÂÔ %Õ2¾ Ö ÉÂAÁÂXÃË %ÂAÁ ¾Aľ¾ %µ ¾ ý 8 PLANO PARA REALIZAÇÃO DA REENGENHARIA 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDFULDomR!! 9HUVmRGR'RFXPHQWR 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR YHUVmRGRGRFXPHQWR!! QRPH!! 'DGRV*HUDLVGR3URFHVVRGH5HHQJHQKDULD û ¾%ÕXÓ%Â=ø ÀÓ %ù Ù¾%ËÓ /ÂXà ÂÔ¾ÀÀ% Û%Û#å ßÞFá Ý jàï í á ßé-éÝí æ%æ Û%Ûîá ßé-éÝíéæ%æ Û%Ûàï íéæ%æ Û%Ûå Ýå íõå ßÞFá ÝFá%â Ýäãjßå Ý æ%æ ø Ö À?ÅÀÖ8 Õ2 Á À?Ó 2 Ô% Â2¾2³ %Ë ÉÂAÁÂXà WÂÔ¾ÀÀ%ÂAÁ ¾Aľ¾ %µ ¾% ý 8 Û%Ûàíå í4ï Üï ëîï íõ-ßéå ï Þ#íàí æ%æ Û%Ûàíå í#ó ï Üíõßéå ï Þ#íàí æ%æ Ö ¾ À2Á ¾  8 µ É Û%Ûõ ï éå í#àß0ï å ßÜé0àß4ë-ÝÜó ï ö%ìâ íð-êý æ%æ

64 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 51 ÀÓ¾ Ð ¾À Á ¾4Ú ÔÂÕXÓ ý Õ2¾ ÖWÂA¾4ò Ó¾ Ù ÀÉÂAÁÂXà  ¾ÖW Û%Ûëîâ ÝÜÝöâ íþ#í#àíéfï Üéèá ßð ßé_àß#íë-ÝÞFá íüíþ#ßü%å Ý æ%æ ÀÓ¾ Ð ¾À Á ¾#Êt Ö8 #Á Ñ Ë Á% Á ¾ Û%Ûëîâ ÝÜÝöâ íþ#í#àíéfï Üéèá ßð ßé0àß4öíâ íü%å ï í#àíìíõ ï àíàß æ%æ 3DVVR±5HYLWDOL]DomRGD$UTXLWHWXUDGR6RIWZDUH/HJDGRFOXVWHU à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%â Û%Ûõ ï éå í/àýé á%â Ýàìå Ýé4àß2å â ííõ ÝíçèßÜàÝ4á íâ í/ë-íàí4á%â Ýàìå Ý2àßéëîâ ï å Ý%å ßÞFá Ý2ßéå ï Þ#íàÝ4á íâ í2àßéßü%çèýõ ç ï Þ#ßÜ%å Ý íõ çèýqàßmë-ýü%å â Ýõ ßmàßmë-ÝÜó ï ö%ìâ íð-êýmßqï Üéèá ßð-êÝqàßqöíâ íü%å ï íqàíìíõ ï àíàß ßÞ ìßqéß!íéßï í éìíqë-ýüéå âwìð-êý â ßëìâ éýéfë-ýþfáìå íëîï ÝÜíï é0àï éèá ÝÜ%ú çèßï é"%â ßéèá ÝÜéçèßõèá Ýâ éìí4ßõ íýâ íð-êý æ%æ û ¾%ÕXÓ%Â$#¾Ô¾ÀÀ% 8 ÂXÓ &  %Ô%Ë ÀÉÂAÁÂXà ÀÀ% Û%ÛéÝÞ#í#àÝé0å ßÞFá ÝéFöíéå Ýétá íâ í#í4ßõ íýâ íð-êý#àß4ë-íàí á%â Ýàìå Ý#àß#å â ííõ Ý('Fï Üéèá ßð ßéæ%æ 3DVVR±5HFXSHUDomRGR0RGHORGH$QiOLVHGR6LVWHPD$WXDOFOXVWHU à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%â Û%Û) ) )%æ%æ û ¾%ÕXÓ%Â$#¾Ô¾ÀÀ% 8 ÂXÓ &  %Ô%Ë ÀÉÂAÁÂXà ÀÀ% Û%Û ) ) ) æ%æ 3DVVR±2EWHQomRGR0RGHORGH$QiOLVHGR6LVWHPDFOXVWHU à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%â Û%Û) ) )%æ%æ û ¾%ÕXÓ%Â$#¾Ô¾ÀÀ% 8 ÂXÓ &  %Ô%Ë ÀÉÂAÁÂXà ÀÀ% Û%Û ) ) ) æ%æ à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%â Û%Û) ) )%æ%æ û ¾%ÕXÓ%Â$#¾Ô¾ÀÀ% 8 ÂXÓ &  %Ô%Ë ÀÉÂAÁÂXà ÀÀ% Û%Û ) ) ) æ%æ 3DVVR±(ODERUDomRGR3URMHWR$YDQWHFOXVWHU à WÂÁ ÖWÂ%À/Á ¾4û ü Ë ý%â Û%Û) ) )%æ%æ û ¾%ÕXÓ%Â$#¾Ô¾ÀÀ% 8 ÂXÓ &  %Ô%Ë ÀÉÂAÁÂXà ÀÀ% Û%Û ) ) ) æ%æ 3DVVR±5HLPSOHPHQWDomRGR6RIWZDUHFOXVWHU A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.2: º O campo Projeto, Verão do Documento, Data da Criação do Documento e Reponável pela Criação do Documento têm a mema informaçõe apreentada no modelo Levantamento de Atividade, Quadro 3.3.1, decrito no padrão anterior; º Tempo Diponível para o Proceo: refere-e ao tempo diponível que a equipe deignada dipõe para a realização do proceo de reengenharia. Deve er definido pelo engenheiro de oftware que conduz o proceo, endo expreo em dia e hora;

65 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 52 º Data Etimada para Inicio e Finalização do Proceo de Reengenharia: ea data ão obtida atravé do omatório do tempo neceário para realização de cada pao do proceo de reengenharia, etimado pelo engenheiro de oftware; º Iten de Configuração: contém o produto de trabalho deenvolvido durante o proceo de reengenharia, para o quai é importante que eja realizado o controle de alteraçõe; º Inpeçõe de Acompanhamento e Supervião do Projeto: lita quanta, quando e por quem erão realizada a inpeçõe de acompanhamento de projeto. Sugeree a realização de uma inpeção de acompanhamento de projeto ao final de cada pao do proceo de reengenharia; º Inpeçõe de Garantia da Qualidade: lita quanta erão, no total, a inpeçõe realizada no produto de trabalho; º Produto de Trabalho: para cada pao do proceo de reengenharia, devem er epecificado quai o produto de trabalho devem elaborado, por quem, a etimativa de tempo e qual a ferramenta de auxílio erá uada para ua elaboração, além de informaçõe obre a neceidade de controle de configuração; º Tempo Neceário para a Concluão do Pao: é o tempo obtido a partir do omatório da etimativa de tempo para a elaboração de cada um do produto de trabalho produzido nee determinado pao. No modelo do Quadro 3.3.2, o planejamento do pao 2, 3, 4 e 5, deve er realizado da mema forma indicada para o pao 1, Revitalização da Arquitetura do Software Legado. Quando do término do preenchimento dee documento tem-e o planejamento inicial para o proceo de reengenharia. ([HPSOR A Figura ilutra o Plano para Realização da Reengenharia para o exemplo do itema de controle de locaçõe de vídeo. Nee cao, etão documentado o planejamento global do proceo e o detalhamento do planejamento do pao 1 Revitalização da Arquitetura. Porém, numa ituação real, todo o pao devem er planejado.

66 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 53 ³ µ #¹%º ¹º Ǽ%Åñ¾ÕXÓ Ë ÂAÁ ¾AøÂÔ% Õ/¾ Ö ÉÂAÁÂXÃË %ÂXÓ Aľ Ë ÉÂ?Á 2ľ¾ %µ ¾ ý j $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão deve er aplicado, neceariamente, apó o padrão 1, Preparar o Proceo Reengenharia, pelo fato de que ua aída é utilizada aqui como entrada. Apó o planejamento do proceo, deve er iniciado o proceo de reengenharia efetivamente. O padrão 3, Acompanhar o Progreo do Proceo de

67 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 54 Reengenharia, que conta do FOXVWHU2, etá fortemente relacionado, poi a partir dele realiza-e o replanejamento do proceo. 3URGXWR2EWLGRPlano Para Realização da Reengenharia. &OXVWHU0HOKRUDUD4XDOLGDGHGR3URFHVVRGH5HHQJHQKDULD 1RPH Acompanhar o Progreo do Proceo de Reengenharia,QWXLWRManter empre atualizado o planejamento do proceo de reengenharia. 3UREOHPDContornar o poívei devio que o projeto de reengenharia do oftware legado poa vir a ofrer a partir da etimativa realizada durante o eu planejamento. &RQWH[WRA inpeção de acompanhamento do proceo é a verificação do progreo do projeto de reengenharia de um oftware legado com relação ao que foi planejado. Cao, durante a inpeção de acompanhamento do proceo, conclua-e que o deenvolvimento do proceo eteja defaado em relação ao que foi planejado, açõe corretiva devem er tomada. Tai açõe incluem a correção do Plano para Realização da Reengenharia, de modo que ee reflita a execução real, ou o replanejamento do pao retante. Ee padrão é aplicado com bae no Plano para Realização da Reengenharia elaborado no padrão Planejar o Proceo de Reengenharia e no andamento real do proceo.,qioxrqfld É difícil definir o que deve er coniderado como devio no Plano, vito o apecto ubjetivo a er definido pelo engenheiro de oftware e, ainda, qual atitude deve er tomada em cao de verificação de um devio. 6ROXomR Elaborar um documento denominado Inpeção de Acompanhamento do Proceo contendo a informaçõe contante do Quadro Para cada um do pao do proceo de reengenharia (FOXVWHUV3 a 7) deve-e realizar e documentar a inpeção de acompanhamento do progreo do projeto, bem como o ajute feito no Plano para Realização da Reengenharia, cao neceário. Cao eja neceária a criação de uma nova verão do Plano para Realização da Reengenharia, deve-e realizar o controle de configuração.

68 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 55 Ñ Á WÂ?¹º ¹%º ¹ ¼%Ò0ÂÁ ¾%Ë ÂXÓ WÂÓÂ%ÀÖWÂ=Ó #ÂX ¾µ ÀÖ8 WÂAÁ ÀA ÀÓ¾ Ð ¾À/Á ¾# ÔÂÕ?Ó ý Õ2¾ ÖWÂAÁÂXÓ WÂÔ¾ÀÀ% à W ¾ÖW Û%ÛÜÝÞ#ß#àÝFá%â Ýäãjßå Ý æ%æ à ÀÀ%Â?Á ÂXÃÄ ÅÆ ½ ½ Û%Û á íéîéý#àý *pæ%æ INSPEÇÃO DE ACOMPANHAMENTO DE PROCESSO ÀÓ¾ ÉÂ$#º + Û%ÛÜ,Þ#ßâ Ý àíkï Üéèá ßð-êÝAéß-ßÜëîï íõ#àìâ íü%å ß å ÝàÝ Ý á%â Ýäãjßå Ý æ%æ ø Ö /Á ¾& 8 ÉÂAÁÂXøÂÔ% %Õ2¾ ÖW Û%Ûàíå í4ëîâ ï íð-êý æ%æ ľÀÓ% À%Ù¾ ËÓ¾%Ë 2 ÀÓ¾ ÉÂAÁ ¾ Ú ÔÂÕXÓ ý %Õ2¾ ÖW Û%ÛÜÝÞ#ß æ%æ Ö ï ç ï å ï ï ï ¾ À/Ú Ë À ÁÂ%À Û%Ûëîâ ÝÜÝöâ íþ#í#àß#íå àíàß#ß4ï ßÜéFí0éßâ ßÞ ßßÜößÜíâ íaæ%æ ë-ýüéå âwìú àýé0àß4íë-ýâ àý4ë-ýþ àßé-ëîâ ð-êý4üý õ íüýfá íâ í ßíõ.îíð-êÝ#àí ľÀ Ë Ö ÁÂ%À2½FüÖ8 ÁÂ%À Û%Ûàßéëîâ ï ð-êý#àßå íõ íàí#àýìß4ó Ýïç ßâ ï ó ï ë-íàý4ßþÿâ ßõ íð-êý#íý õ íüý á íâ í ßíõ ï.îíð-êý#àí ßßÜößÜíâ ï íaæ%æ Ú Ð ¾À/  8 ¾Ö8 Ù À0#¾Ô¾ÀÀ% 8 À Û%Ûõ ï éå í#àß#íð ßé ë-ýâ â ßå ï çèíé éìößâ ï àíéæ%æ Ö ¾ À/Ú Ë À ÁÂ%À Û%Û) ) )%æ%æ ľÀ Ë Ö ÁÂ%À2½FüÖ8 ÁÂ%À Û%Û) ) )%æ%æ Ú Ð ¾À/  8 ¾Ö8 Ù À0#¾Ô¾ÀÀ% 8 À Û%Û) ) )%æ%æ Ö ¾ À/Ú Ë À ÁÂ%À Û%Û) ) )%æ%æ ľÀ Ë Ö ÁÂ%À2½FüÖ8 ÁÂ%À Û%Û) ) )%æ%æ Ú Ð ¾À/  8 ¾Ö8 Ù À0#¾Ô¾ÀÀ% 8 À Û%Û) ) )%æ%æ A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.3: º Realta-e, novamente, que o campo Projeto e Data da Criação do Documento ão preenchido como no documento anteriore; º Reponável pela Inpeção de Acompanhamento: com o nome da peoa ou do integrante da equipe que realizou a inpeção de acompanhamento e upervião de projeto; º Pao do PRE/OO: decreve em qual pao do proceo de reengenharia que foi realizada a revião de acompanhamento de projeto, ou eja, durante a aplicação de qual cluter de padrõe. Por exemplo: Revitalização da Arquitetura do Software Legado, MASA, Projeto Avante, etc.; º Inpeção N.º: contém o número eqüencial, com doi dígito, para identificação da inpeçõe de acompanhamento de projeto;

69 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 56 º Iten Analiado: decreve o apecto do Plano para Realização da Reengenharia que foram ubmetido à inpeção. Podem er dividido em ubeçõe em que ão analiado diferente apecto relacionado ao proceo; º Reultado Obtido: deve contar a comparação entre a etimativa e o reultado reai alcançado em termo de tempo gato e produto de trabalho elaborado; º Açõe Corretiva Neceária: decreve quai a açõe corretiva foram utilizada para correção ou adaptação do Plano para Realização da Reengenharia, no cao de devio em relação ao planejado. ([HPSORCao, no exemplo do itema de controle de locaçõe de vídeo, durante a inpeção de acompanhamento tivee ido verificada a ocorrência de um devio no deenvolvimento real do projeto em relação à etimativa documentada no Plano para Realização da Reengenharia, o engenheiro de oftware deveria avaliar a amplitude do devio, levando em conideração em qual pao do proceo de reengenharia ocorreu, optando por: Replanejar o pao ubeqüente, conforme ituação real, documentando ee replanejamento numa nova verão do Plano para Realização da Reengenharia e documentando o reultado da inpeção; Continuar o proceo de reengenharia, repaando o atrao para a atividade retante e documentando o reultado da inpeção, de forma atenta para evitar nova ocorrência do devio. O exemplo da documentação da inpeção de acompanhamento do projeto em que ocorre um pequeno devio é ilutrado pela Figura ³ µ #¹%º ¹º ¹¼%Åñ¾ÕXÓ Ë ÂAÁ ¾/Á ÂÔ% Õ2¾% Ö ÉÂ?Á 2 À Ó¾ ÉÂ?Á ¾4 ÔÂÕXÓ ý Õ2¾ ÖWÂAÁÂXÓ WÂÔ¾ÀÀ%Â

70 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 57 $YDOLDomR... -XVWLILFDWLYD... 3DGUmR 5HODFLRQDGR Ee padrão deve er aplicado apó durante proceo de reengenharia, preferencialmente apó o fim de cada um do pao (FOXVWHUV 3 a 7) que compõem o PRE/OO. 3URGXWR2EWLGRDocumento de Inpeção do Acompanhamento do Proceo. 1RPH Realizar Inpeção de Garantia da Qualidade,QWXLWR Garantir a qualidade do produto gerado durante o proceo de reengenharia. 3UREOHPD Decobrir o erro em produto de trabalho em relação ao que foi planejado, à epecificaçõe e/ou padrõe propoto. &RQWH[WR Cada produto de trabalho gerado ao longo do proceo de reengenharia deve er alvo da inpeção propota com ee padrão.,qioxrqfld O engenheiro de oftware pode decidir obre a realização da inpeçõe apena em produto crítico, de acordo com o porte do oftware ubmetido ao proceo de reengenharia orientada a objeto. 6ROXomR Elaborar um documento contendo a informaçõe contante do Quadro de forma a garantir a qualidade do produto de trabalho gerado durante o proceo, verificando e tai produto refletem o que foi olicitado e e eguem o padrõe propoto. Ñ Á WÂ?¹º ¹%º 1¼%Ò0ÂÁ ¾%Ë ÂXÓ WÂÓÂ%ÀÖWÂ=Ó 4 /Á ÂÔ% %Õ2¾ Ö ÉÂ?Á ÀA ÀÓ¾ Ð ¾À2Á ¾#µ Öj /Á 2 %Ë Á Á ¾ INSPEÇÃO DE GARANTIA DA QUALIDADE 3URMHWR QRPHGRSURMHWR!!,WHP $OYR GD,QVSHomR GH *DUDQWLD GD 4XDOLGDGH QRPHHYHUVmRGRLWHP!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDFULDomR!! 5HVSRQViYHO SHOD,QVSHomR GH *DUDQWLD GD 4XDOLGDGH QRPH!!,QVSHomR1ž Q~PHURGDLQVSHomRVHT HQFLDOGXUDQWHWRGR RSURMHWR!! ÚÀÓ¾ÔÖWÂ%À2Ú Ë À ÁÂ%À Û%Û4àßé-ëîâ ï ð-êý4àß#å ÝàÝé0Ýé0íéèá ßëå ÝéFíÜíõ ï éíàýé"%ó Ýâ Þ#í#àß#íÜõ ï éß4ß0é-ï å ìíð-êý4ë-ýþÿâ ßõ íð-êý4íý#àßéßäãjíàýaæ%æ ø ¾ ¾ % À?Å %Ô Ö8 Á À Û%Û4àï ó ßâ ßÜð-íéæ%æ Ú Ð ¾À/  8 ¾Ö8 Ù À0#¾Ô¾ÀÀ% 8 À Û%Ûõ ï éå í#àß#íð ßé ë-ýâ â ßå ï çèíé éìößâ ï àíéæ%æ

71 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 58 A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.4: º Projeto e Data da Criação do Documento ão preenchido como no documento anteriore; º Item Alvo da Inpeção de Garantia da Qualidade: contém o nome e a verão do produto de trabalho inpecionado; º Reponável pela Inpeção de Garantia da Qualidade: contém o nome da peoa ou do integrante da equipe reponável pela realização da inpeção; º Inpeção N.º: contém um número eqüencial, com doi dígito, para identificação de cada inpeção de garantia da qualidade; º Apecto Analiado: decreve todo o apecto analiado no produto de trabalho, a forma de análie e a ituação em relação ao deejado; º Diferença Encontrada: relata a diferença entre o apecto analiado e o reultado eperado; º Açõe Corretiva Neceária: decreve a propota para corrigir a diferença encontrada. ([HPSOR A inpeção de garantia da qualidade é realizada durante todo o proceo de reengenharia. Por ee motivo, um exemplo de ua realização encontra-e ilutrado junto ao exemplo da aplicação do padrão 8, Modelar Dado do Software Legado, pela Figura 3.4.5, a qual contém a inpeção realizada no MER. $YDOLDomR... -XVWLILFDWLYD... 3DGUmR 5HODFLRQDGR Relaciona-e com o FOXVWHUV 3 a 7 do PRE/OO, de forma a inpecionar cada aída produzida a partir da aplicação do padrõe que compõem tai FOXVWHUV. 3URGXWR2EWLGRDocumento de Inpeção de Garantia da Qualidade. 1RPHControlar a Configuração,QWXLWREtabelecer e manter a integridade do produto de trabalho elaborado ao longo do proceo de reengenharia. 3UREOHPD Controlar a alteraçõe realizada no vário produto de trabalho de forma a não permitir a ocorrência de inconitência.

72 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 59 &RQWH[WR A condução do proceo de reengenharia de forma evolutiva torna indipenável a implementação dee padrão, como forma de controlar mudança e verõe do produto de trabalho contruído, fator que torna-e ainda mai crítico no cao do proceo er conduzido por mai de uma peoa.,qioxrqfldv A aplicação do padrão pode er dificultada por não er realizada de forma automatizada; O uo de ferramenta própria para o Controle de Configuração e a criação de %DVHOLQHV como, por exemplo, o MS 6RXUFH 6DIH pode er uma opção a ee padrão. 6ROXomR 1. Definir o iten de configuração, ou eja, o produto de trabalho que terão ua verõe controlada; 2. Documentar toda a alteraçõe realizada no iten de configuração, decrevendo a ua origem, quando e por quem foi feita a alteração (no cao de mai de uma peoa etar aociada ao proceo) e em que verão do item reultou, de acordo com o modelo propoto no Quadro 3.3.5; 3. Etabelecer uma EDVHOLQH 3 ao final de cada pao do proceo de reengenharia para que e poa ter um maior controle do projeto em termo de gerenciamento de configuração, ou eja, um conjunto de produto de trabalho inpecionado que ervem de bae para a continuação do projeto e que ó podem er alterado mediante controle documentado. A documentação para o gerenciamento da EDVHOLQHV como ua decrição, o iten que a compõem, ua data de criação e demai dado encontram-e ilutrado no modelo do Quadro :9<;0=> =>?A@B6;8ACD ;FE9<;:E;GH<;$E7A9 7;(I;:JHK9<;LD C&8ACI;:JMKN O:59 7PQ; LISTA DE CONTROLE DE CONFIGURAÇÃO 3URMHWR QRPHGRSURMHWR!! 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR QRPHGRUHVSRQViYHO!! 3DVVRGR35(22 QRPHGRSDVVR!! 'DWDGH&ULDomR Û%Ûàíå í#àí4ëîâ ï íð-êý4àý àýëìþ#ßü%å Ý æ%æ 1RPHGRV 'RFXPHQWR Û%Û R ÝÞ#ß æ%æ 9HUVmR Û%ÛLS%ßâ éêý#àý T ÝëìÞ#ßÜ%å Ý æ%æ 2ULJHP Û%Û/Uâ ï íàý#ífá íâwå ï âàßaæ%æ 1 %DVHOLQHV ão linha de referência etabelecida durante o proceo, caracterizada pela entrega de um ou mai iten de configuração, aceito apó inpeção técnica (FIORINI HW DO, 1998).

73 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 60 A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.5: º Projeto, Reponável pelo Controle de Configuração e Pao do PRE/OO ão preenchido como no documento anteriore; º Data de Criação: relata a data (dd/mm/aaaa) de criação da verão do item de configuração; º Nome do Documento: refere-e ao nome dado ao produto de trabalho que é alvo do controle de configuração; º Verão: contém a verão do item de configuração criada apó a realização da alteraçõe; º Origem: epecifica a partir de qual proceo ou inpeção foi originada a verão dee item de configuração :9<;0=> => VA@B6;8ACD ;FE9<;:E;GH<;$E7A9 7 7&8A;I5W/CAJH 7PQ;08A7GXYZA[\ ] ^:[Z/8A;FE9<;_ CH<; %$6(/,1( DE PROJETO 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGD%DVHOLQH GDWDFULDomR!! 3DVVRGR35(22 SDVVRHPTXHIRLHVWDEHOHFLGDDEDVHOLQH!! 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR QRPH!! ` ï ï a H ` CGI9KN PQ; Û%Û4àßé-ëîâ ð-êý4àí íéßõ ÜßAæ%æ CAJG/8ACb ;:JMKN OL59 7PQ; cdca9 GQ; 7H 7&8AC&be9KN 7PQ; Û%Û0ï å ßÜé0àß4ë-ÝÜó ï ö%ìâ íð-êýìß ó Ýâ Þ#íÞ í íéßõ ï ÜßAæ%æ Û%Û/çèßâ éêý4ï Üéèá ßëîï ÝÜíàí2æ%æ Û%Û4àíå í#àý0ï å ßÞ æ%æ A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.3.6: º Projeto, Pao do PRE/OO e Reponável pelo Controle de Configuração devem er preenchido como no documento anteriore; º Data de Criação da %DVHOLQH: relata a data (dd/mm/aaaa) em que o iten de configuração elaborado ao longo do pao do PRE/OO foram reunido e formaram a EDVHOLQH; º Decrição: contém a explicação obre o conteúdo da EDVHOLQHcriada; º Iten de Configuração: lita o nome de cada item de configuração que compõe a EDVHOLQH; º Verão: lita a verão do item de configuração que compõe a EDVHOLQH;

74 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 61 º Data de Criação: relata a data da criação da verão decrita do item de configuração. ([HPSOR O controle de configuração do itema de locaçõe de vídeo é exemplificado atravé da Lita de Controle de Configuração (Figura 3.3.4) correpondente à Revitalização da Arquitetura e da primeira EDVHOLQH criada para o projeto, apó a realização da revitalização da arquitetura do oftware legado (Figura 3.3.5). f N O:59 7=> => g:@hn GH 78AC&b ;LJHK9<;:D C8AC&b ;LJMKN OL59 7PQ;$9 CM CA9 CAJH C7;&GN GH CW/7&8ACI;:JHK9<;LD C&8AC/D ;I7PiACG/8AC6jk 8AC;G f N O:59 7=> =>?@l 9mN W/CAN 9 7&noYZA[\ ] ^:[68AC/l 9<;_ CH<;$9 CM CA9 CAJH C7;&GN GH CW/7&8ACI;:JHK9<;LD C&8AC/D ;I7PiACG/8AC6jk 8AC;G $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVRelaciona-e com todo o padrõe do FOXVWHUV 3 a 7, de forma a controlar a alteraçõe em todo o iten de configuração gerado a partir de ua aplicação. 3URGXWRV 2EWLGRV Documento: Lita de Controle de Configuração e %DVHOLQH do Projeto. A eção eguinte apreenta o padrõe para a realização do proceo de engenharia revera de itema legado implementado em Delphi em caracterítica orientada a objeto, contido no FOXVWHUV3 a 5.

75 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 62 3DGU}HVGH(QJHQKDULD5HYHUVDGR35(22 A engenharia revera é a primeira etapa de qualquer proceo de reengenharia. No PRE/OO ela é compota por trê pao, cada um dando origem a um FOXVWHU de padrõe: º &OXVWHU 3 5HYLWDOL]DU $UTXLWHWXUD GR 6RIWZDUH /HJDGR. Reúne o padrõe relacionado à obtenção do entendimento da etrutura do oftware legado, bem como da extração da regra de negócio embutida no código-fonte. É formado pelo eguinte padrõe: Padrão 6: Elaborar Lita de Procedimento e Funçõe; Padrão 7: Elaborar Lita de "Chama/Chamado Por". O padrão 6, Elaborar Lita de Procedimento e Funçõe tem por objetivo facilitar a identificação do procedimento e funçõe alvo da reengenharia, ou eja, apena aquele proveniente da implementação legada. Ea identificação, em a utilização do padrão, pode er dificultada pela forma idêntica como ão utilizado o procedimento e funçõe proveniente de biblioteca diponívei no ambiente Delphi. O padrão 7, Elaborar Lita de "Chama/Chamado Por" foi adaptado do método Fuion/RE, endo mantido com o objetivo de prover um entendimento detalhado, por parte do engenheiro de oftware, obre o oftware legado e, ainda, permitir a decoberta de regra de negócio implícita ao código-fonte. º &OXVWHU 4 (ODERUDU 0RGHOR GH $QiOLVH GR 6LVWHPD $WXDO. Reúne o padrõe reponávei pela documentação da funcionalidade do oftware legado: Padrão 8: Modelar Dado do Software Legado; Padrão 9: Criar Lita de Anomalia; Padrão 10: Criar Vião OO do Dado; Padrão 11: Criar Diagrama de 8VH&DVHVdo MASA; Padrão 12: Decrever 8VH&DVHVdo MASA. Nee pao do PRE/OO ão gerado o modelo de análie, epecificado em UML (OMG, 1999), que compõem o oftware em ua implementação procedimental. Como o proceo via a elaboração de produto com qualidade, o uo de ferramenta computacionai é fortemente encorajado, pelo fato dea facilitarem a

76 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 63 documentação, diminuindo a poibilidade de erro. Para ete trabalho, a ferramenta de apoio utilizada foi a 5DWLRQDO5RVH(RATIONAL, 2001). O padrão 8, Modelar Dado do Software Legado foi adaptado reunindo o trê primeiro padrõe definido no FOXVWHU Modelar o Dado do Legado de RECCHIA (2002), devido à caracterítica do ambiente Delphi. O padrão 9, Criar Lita de Anomalia foi adaptado do Fuion/RE (PENTEADO, 1996a), para claificação do procedimento e funçõe exitente no código-fonte. O procedimento e funçõe que conultam e/ou obervam mai de uma etrutura de dado ão coniderado anômalo e o que conultam apena uma etrutura de dado ão diretamente tranformado em método. O padrão 10, Criar Vião OO do Dado propoto com bae no FOXVWHU Modelar o Dado do Legado de RECCHIA (2002) e no Fuion/RE, tem por objetivo criar a vião orientada a objeto a partir da modelagem procedimental do oftware legado. O padrõe 11 e 12, Criar Diagrama de Ue Cae do MASA e Decrever 8VH &DVHVdo MASA, repectivamente, ão propoto nete trabalho com bae no Modelo de Operaçõe utilizado no Fuion/RE. º &OXVWHU 5 (ODERUDU 0RGHOR GH $QiOLVH GR 6LVWHPD. Reúne o padrõe que permitem ao engenheiro de oftware prover a vião orientada a objeto do oftware legado: Padrão 13: Abtrair Diagrama de Peudo-Clae, Padrão 14: Criar Diagrama de 8VH&DVHV do MAS, Padrão 15: Decrever 8VH&DVHV do MAS. O padrõe que compõem ee FOXVWHU, utilizam o modelo obtido no MASA (FOXVWHU 4), criando a partir dele a abtraçõe para que omente caracterítica orientada a objeto ejam coniderada. Dea forma, o reultado é a elaboração de um modelo orientado a objeto do oftware legado procedimental. A eguir é decrito cada um do padrõe do PRE/OO para a realização do proceo de engenharia revera: &OXVWHU5HYLWDOL]DU$UTXLWHWXUDGR6RIWZDUH/HJDGR 1RPH Elaborar Lita de Procedimento e Funçõe

77 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 64,QWXLWR Identificar todo o procedimento e funçõe, definido pelo programador, que erão tranformado pelo proceo de reengenharia. 3UREOHPD Detacar, a partir do código-fonte, omente o procedimento e funçõe definido pelo programador, ignorando o procedimento e funçõe declarada em biblioteca ou API ($SSOLFDWLRQ3URJUDPPDEOH,QWHUIDFHV) fornecida pelo fabricante do ambiente de deenvolvimento Delphi. &RQWH[WR Conidera-e apena o procedimento e a funçõe definido pelo programador para realizar a engenharia revera. A bae para a análie do procedimento e funçõe é o código-fonte toda a XQLWV do oftware legado; No Delphi, grande parte do código-fonte é executado direta ou indiretamente em repota a evento. Um evento é um tipo epecial de propriedade que repreenta uma ocorrência em tempo de execução, geralmente uma ação do uuário (como o FOLFNdo PRXVHobre um botão), Pode-e localizar o evento clicando-e obre a aba (YHQWVdo 2EMHFW,QVSHFWRU.,QIOXrQFLDV A ilegibilidade do nome utilizado para decrever o procedimento e funçõe pode dificultar o proceo; A aplicação do padrão é facilitada pelo fato do protótipo do procedimento e funçõe erem decrito na eção,qwhuidfh da XQLWV 6ROXomR 1. Identificar o protótipo (cabeçalho) de todo o procedimento e funçõe preente no código da XQLWV do oftware legado e documentá-lo conforme modelo propoto no Quadro 3.4.1; 2. Claificar cada procedimento ou função de acordo com o critério a eguir: º Ev Evento: procedimento originado em repota à evento diparado pelo itema. Ee tipo de procedimento encontra-e declarado acima da palavra reervada SXEOLFna interface da XQLW, º Pr 3ULYDWH: procedimento ou funçõe viívei apena internamente à XQLW em que etão declarado. Procedimento e funçõe privado encontram-e declarado abaixo da palavra reervada SULYDWHna interface da XQLW, º Pb 3XEOLF: procedimento ou funçõe viívei a outra XQLWV, além daquela em que e encontram declarado. Procedimento e funçõe público ão declarado abaixo da palavra reervada SXEOLF na interface da XQLW.

78 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto :9<;0=> g> p@b6;8acd ;FE7A9 7&W(;:JH 7OACWq8A7/hN GH 7&8AC/l 9 ;IC8:N W/CAJH<;GC f 5JPiACG LISTA DE PROCEDIMENTOS E FUNÇÕES 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGHFULDomRGDOLVWD!! \ t y t t ] x ] 9HUVmRGR'RFXPHQWR 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR YHUVmRGDOLVWD!! rtlu vz v(w vx z{y *[ QRPH!! }{v~$[z vz& *v [ ~$[^:y vz(v u& :u ^:ƒ [Z \ YZZ] Yƒ v ˆ Š Œ Ž Ž ˆ Š Œ Š š A oœž Ÿ Ÿ A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.1: º Projeto, Verão do Documento, Data da Criação do Documento e Reponável pela Criação do Documento: devem er preenchido como citado no Quadro do padrõe da Seção anterior; º Módulo do Software: deve conter todo o arquivo com extenão ".pa" que compõem o oftware legado; º Nome do Procedimento e Funçõe: lita todo o procedimento e funçõe que ão extraído a partir do código-fonte; º Claificação: lita a viibilidade do procedimento ou função em relação ao módulo em que etá declarado e ao oftware. Utiliza a nomenclatura Ev, Pb ou Pv conforme decrito no Pao 2 da olução. O trê último campo do Quadro devem er repetido até que e egotem todo o procedimento e funçõe que compõem um módulo e todo o módulo que compõem o oftware legado. ([HPSOR Para o itema de locaçõe de vídeo, a vião parcial da Lita de Procedimento e Funçõe é ilutrada pela Figura 3.4.1, na qual podem er obervado o procedimento e funçõe documentado a partir da XQLWCliente.pa. f N O:59 7=> ga> p@c N GQ;FE7A9<IN 7AD8A7/hN GH 78AC/l 9<;IC8LN W/CAJH<;GC f 5JPiACG(E7A9 7;/GN GH CW/7&8AC/D ;I7PiACG/8AC6jk 8AC;G $YDOLDomR... -XVWLILFDWLYD...

79 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 66 3DGUmR 5HODFLRQDGR Ee padrão inicia o proceo de reengenharia, endo aplicado apó a aplicação do FOXVWHU 1, Preparar e Planejar o Proceo de Reengenharia. Apó a aplicação do padrão, deve-e: realizar a inpeção de garantia da qualidade da Lita de Procedimento e Funçõe: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; realizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 7, Elaborar Lita "Chama/Chamado Por". 3URGXWR2EWLGRLita de Procedimento e Funçõe. 1RPH Elaborar Lita "Chama/Chamado Por",QWXLWR Obter entendimento da funcionalidade implementada em cada procedimento e função do oftware legado. 3UREOHPD Extrair, de cada procedimento e função elencado na Lita de Procedimento e Funçõe, a funcionalidade, o procedimento e a funçõe que ão por ele chamado e por quai outro procedimento e funçõe ele é chamado. &RQWH[WR O código-fonte do oftware legado contém muita regra de negócio e detalhe de implementação importante para o entendimento da funcionalidade que podem paar depercebido pelo engenheiro de oftware que etá conduzindo a engenharia revera.,qioxrqfldv Um ponto negativo que o engenheiro de oftware pode encontrar para a aplicação dee padrão é o tempo que ete conome; Por e tratar do etudo e documentação do código, trabalho minucioo, o engenheiro de oftware pode optar por não aplicá-lo ou aplicá-lo apena na XQLWV mai importante do oftware legado; Apó a aplicação dee padrão, o entendimento há cerca do oftware aumenta conideravelmente. 6ROXomRPreencher a Lita Chama/Chamado Por para cada procedimento e função que conte da Lita de Procedimento e Funçõe, declarada no Quadro

80 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto :9<;0=> g> A@ f ;:9<W/7H<;08A7/hAN GH 7( "b{ 7W/7 be 7W/78;FE;:9 > o8a7aeh 78;08AC& l ª: L `d«p V7 LISTA CHAMA/CHAMADO POR 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGHFULDomRGDOLVWD!! 0yGXORGR6RIWZDUH GHVFULomR UHVXPLGD GD IXQFLRQDOLGDGH GD XQLW!! 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR QRPH!! 9HUVmRGR'RFXPHQWR YHUVmRGDOLVWD!! l 9<;IC8:N W/CAJH<; f 5AJPQ; Š Œ Œ Š š Œ Ž š 6 Ž Š Œ Œ 6Ž " Œ Œ A ± ²"³{ µ "¹ º" ±»*¼ ½¾ be 7W/7 6 Š Œ ŽÀ Œ Š Ž Á Š Œ Ž be 7W/78;FlL;:9 6 Š Œ ŽÀ Œ Š Ž6 Á Š Š( A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.2: º Projeto, Verão do Documento, Data da Criação do Documento e Reponável pela Criação do Documento devem er preenchido como no padrõe da eçõe anteriore; º Módulo do Software: contém o arquivo com extenão ".PAS", o qual teve eu código-fonte utilizado na compoição da lita. Elabora-e uma Lita "Chama/Chamado Por" para o arquivo com extenão ".PAS" que compõe o oftware; º Procedimento/Função: contém o nome do procedimento ou função com decrição ucinta de ua funcionalidade, que é obtida a partir do entendimento do código implementado no corpo do procedimento ou função, encontrado na eção LPSOHPHQWDWLRQ da XQLWem que ee e encontra declarado; º Chama: lita o procedimento chamado por outro procedimento e funçõe da Lita de Procedimento e Funçõe, exitente no código do procedimento ou função analiado; º Chamado Por: lita o procedimento ou funçõe que ão chamado pelo procedimento litado no item Chama. De acordo com a claificação, podem ocorrer trê ituaçõe: Cao o procedimento ou função apreente a claificação Pb (3XEOLF), procedimento e funçõe de outra XQLWVpodem chamá-lo (coniderar apena aquele que contem da Lita de Procedimento e Funçõe), endo a coluna &KDPDGR 3RU completada omente quando todo o procedimento ou funçõe foram claificada, ou eja, quando o proceo de revitalização da demai XQLWV for concluído;

81 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 68 Cao o procedimento ou função apreente a claificação Pv (3ULYDWH), apena procedimento e funçõe da XQLW em que ee e encontra podem chamá-lo (coniderar apena aquela que contam da Lita de Procedimento e Funçõe), portanto a coluna &KDPDGR 3RU erá completada ao término da revitalização da XQLWem que ee e encontra; Cao o procedimento tenha a claificação Ev, a coluna &KDPDGR 3RU erá vazia, pelo fato de e tratar de um evento, o qual omente é diparado por algum agente externo ao oftware e nunca por outro procedimento/funçõe. ([HPSOR Para o itema de locaçõe de vídeo, a vião parcial da Lita Chama/Chamado Por é ilutrada pela Figura em que contam o procedimento e funçõe da XQLW Cliente.pa, a decrição de cada um, por quem ee procedimento ão chamado e quai cada um dele chamam. f N O:59 7=> N GQ;FE7A9<IN 7AD8A7/hN GH 7Ã"be 7W/7 be 7W/78;Fl:;L9<Ãe8;/GAN GH CW/78AC/D ;I7PiACG&8AC jk 8AC;G $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó ter ido aplicado o padrão 6, Elaborar Lita de Procedimento e Funçõe, poi a aída dele é utilizada como entrada para ete padrão. Apó a aplicação dee padrão, deve-e:

82 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 69 realizar a inpeção de garantia da qualidade da Lita "Chama/Chamado Por": utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; inpecionar o andamento do proceo em relação ao Plano para Realização da Reengenharia: utilizar o padrão 3, Acompanhar o Progreo do Proceo de Reengenharia; continuar o proceo de engenharia revera: utilizar o padrão 8, Modelar Dado do Software Legado. 3URGXWR2EWLGRLita "Chama/Chamado Por". &OXVWHU (ODERUDU0RGHORGH$QiOLVHGR6LVWHPD$WXDO 1RPHModelar Dado do Software Legado,QWXLWR Contruir o Modelo Entidade Relacionamento (MER) correpondente à implementação atual do dado do oftware legado. 3UREOHPD Interpretar e abtrair o dado do oftware legado documentado ob a forma de VFULSWV SQL (6WUXFWXUHG4XHU\/DQJXDJH) preente no arquivo de dado do oftware legado.,qioxrqfldv É neceário que o engenheiro de oftware poua conhecimento báico obre SQL; A cardinalidade entre a entidade repreentada no MER nem empre ão triviai e, muita veze, ó ão obtida a partir de invetigação detalhada da regra de negócio embutida no código ou percebida atravé da execução do oftware legado. 6ROXomR 1. Montar o Quadro A partir do arquivo de dado do oftware legado, ecrito ob a forma de VFULSWV SQL. A coluna Tabela de Dado do Quadro 3.4.3, deverá er preenchida a partir da identificação do nome de cada tabela de dado aociado à cláuula CREATE TABLE do VFULSWV; 2. Identificar, abaixo de cada cláuula CREATE TABLE o nome e tipo do campo relacionado à tabela de dado identificada no pao anterior. Ee campo deverão er inerido na coluna Campo de Dado do Quadro 3.4.3; 3. Identificar a cláuula PRIMARY KEY no VFULSWV SQL do arquivo de dado. Cada cláuula dee tipo correponde à chave primária da tabela de dado

83 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 70 identificada no Pao 1 da olução. Cada chave primária identificada, deve ter eu nome inerido na coluna Chave Primária do Quadro 3.4.3; 4. Identificar a chave etrangeira, ou eja, a Chave Primária de Tabela de Dado declarada como campo em outra tabela, e ineri-la na coluna Chave Etrangeira do Quadro :9<;0=> g> =A@B6;8ACD ;FE7A9 7&8A;I5AW&CJH 7PQ;08A7G H 7AÄCAD 7G&8AC&8A78;G LISTA DE TABELAS E CHAVES 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGDFULDomRGRGRFXPHQWR!! 9HUVmRGR'RFXPHQWR 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR YHUVmRGRGRFXPHQWR!! QRPH!! Å YX:[\ Y t [ ÆoY t vz Y~/Ç vz t [ ÆoY t vz ÈYAÉ[ K] ~0Ê m] Y ÈYAÉ[Z/Ë:ZAy KY^Ì:[] KYZ Š Œ Š A 6 Š Œ Š A  ΠŠ Œ & A 6 Š Ž6Œ Ž Š A Ž Ž Œ Œ Á œ" Á œ" ŠÍ ŠÏ ŠÍ A A A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.3: º Projeto, Verão do Documento, Data da Criação do Documento e Reponável pela Criação do Documento ão preenchido como no padrõe anteriore; º Tabela de Dado: contém a informaçõe obtida com a realização do pao 1 da Solução; º Campo de Dado: contém a informaçõe obtida realizando-e o pao 2 da Solução; º Chave Primária: contém o() campo() que identifica(m) unicamente cada regitro da Tabela de Dado, conforme intruçõe do pao 3 da Solução; º Chave Etrangeira: campo() da Tabela de Dado que compõe(m) a Chave Primária de outra() Tabela() de Dado, o que pode er verificado atravé da análie do campo Chave Primária da Lita de Tabela e Chave; 5. Contruir o MER. A partir da informaçõe contante da Lita de Tabela e Chave. Cada Tabela de Dado dá origem a uma entidade do MER, cada Chave Etrangeira identifica o relacionamento entre a divera Tabela de Dado repreentada. A cardinalidade entre a entidade devem er obtida atravé da regra de negócio, extraída do código-fonte com a execução do oftware legado e/ou de entrevita com uuário. ([HPSOR A eguir é ilutrado o exemplo da aplicação do padrão no itema de locaçõe de vídeo. A Figura ilutra o VFULSW SQL preente no arquivo de dado

84 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 71 "Cliente" do oftware legado, relativo a Tabela de Dado Cliente, o qual originou parte da Lita de Tabela e Chave apreentada. O MER conta da Figura Verifica-e, no detaque D da Figura a cláuula CREATE TABLE, identificando o nome da Tabela de Dado. O detaque Eda Figura ilutra do campo de dado CodCliente e Nome, pertencente a tabela de dado "Cliente". O detaque F da Figura ilutra a chave primária da tabela de dado "Cliente", compota unicamente pelo campo de dado CodCliente. A Figura ilutra a inpeção de garantia da qualidade realizada no MER. f N O:59 7=> ga> =@ª:9 CI ;08AC6ZA K] Ç yðd46h&8;/7a9<ñ:5an j;(8ac8a78;g/b{d N CAJH C C(hAN GH 7&8AC ªA7AÄCAD 7G&C&be 7jCG/I;:9K9 CGE;:J8ACAJH C f N O:59 7=> ga> g:@b Ò9 CM CA9 CAJH C7;&GN GH CW/7&8AC/D ;I7PiACG&8AC jk 8AC;G

85 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 72 f N O:59 7=> ga>?@ a JGAECPQ;08ACÓÀ7A9 7AJHKN 78A74657AD N 8A78AC/9 C7AD N Ô78A7/J;0B Ò A inpeção de garantia da qualidade realizada no exemplo (Figura 3.4.5) verificou a falta da repreentação da cardinalidade do MER, apecto corrigido para o poterior lançamento de nova verão do produto de trabalho. $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVApó a aplicação do padrão, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade do MER: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; proeguir com a engenharia revera: utilizar o padrão 9, Criar Lita de Anomalia. 3URGXWRV2EWLGRVLita de Tabela e Chave e Modelo Entidade-Relacionamento. 1RPH Criar Lita de Anomalia,QWXLWR Obter, a partir do código-fonte, toda a anomalia relacionada ao procedimento que compõem a tabela de dado identificada. 3UREOHPD Regitrar e claificar o procedimento e funçõe que obervam e/ou conultam mai de uma entidade.,qioxrqfldv Para a aplicação do padrão, todo o código-fonte deve er percorrido; Permite a poterior divião do procedimento e funçõe de forma a eliminar a anomalia e permitir a migração para o paradigma orientado a objeto. 6ROXomR Criar uma lita com o procedimento e funçõe da Lita de Procedimento e Funçõe e a claificação de cada um quanto a anomalia em relação à tabela

86 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 73 de dado, obedecendo ao critério apreentado no Quadro O modelo para a elaboração da Lita de Anomalia é ilutrado pelo Quadro :9<;0=> g> gl@be9mn H ÕA9KN ;G(E7A9 7&ID 7GGN MKN I7PQ;(8A7G&7AJ;LW/7D N 7GCWÖE9<;IC8LN W/CAJH<;G&C6MK5JPiACG &ODVVLILFDomR 6LJQLILFDGR &ULWpULR o Obervador Procedimento ou função que oberva a tabela de dado c Contrutor Procedimento ou função que altera a tabela de dado I de Implementação Procedimento ou função relacionado(a) à implementação + - Aociado ao ímbolo (o) ou (c), indica que o procedimento ou a função oberva e/ou altera dua ou mai tabela de dado 6ØÙÚ:Û<Ü0ÝÞ ßÞ àaáâ6üúaãä ÜFåÙAÛ Ù&æÜLçèéKÛKØêëÜ(ÚAÙ(ìAí èé Ù&ÚAã î{çülï/ùaä í Ùè LISTA DE ANOMALIAS 3URMHWR QRPHGRSURMHWR!! 9HUVmRGR'RFXPHQWR YHUVmRGRGRFXPHQWR!! 0yGXORVGR 3URFHGLPHQWRRX 6RIWZDUH ˆ Š Œ & ŠÏ Ž Í Œ Š ðm š A )XQomR ˆ Š Œ Œ Š š ( 'DWDGH&ULDomRGR'RFXPHQWR GDWDGDFULDomR!! 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR QRPHGRFULDGRUGRGRFXPHQWR!! &ULWpULRGH$FHVVR &ODVVLILFDomR 7DEHODVGH'DGRV ñ Ž6 Ž mœ" Œ Ž ðm Ž Œ ŽÀ A Œ Š š / jv7dehodv ò Œ Š ó Œ ôõ öõ öa GD$QRPDOLD øk L *øk *øk Aù øm ù øk L Aù *øk L ù øk Aù ù øo & ø A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.5: º Projeto, Verão do Documento, Reponável pela Criação do Documento, Data da Criação do Documento devem er preenchido conforme modelo apreentado no padrõe anteriore; º Módulo do Software: contém cada arquivo com extenão ".pa" que compõe o oftware legado; º Procedimento ou Função: deve conter todo o procedimento e a funçõe que compõem a Lita de Procedimento e Funçõe; º Tabela de Dado: decreve o nome da tabela de dado obervada e/ou alterada dentro do procedimento ou função declarado na coluna anterior; º Critério de Aceo à() Tabela(): claificação de acordo com o tipo de aceo que o procedimento ou função faz a cada Tabela de Dado; º Claificação da anomalia: cao o procedimento/função eja anômalo, ou eja, altere e/ou oberve mai de uma Tabela de Dado imultaneamente, o tipo final de ua anomalia deve er trancrito, obedecendo o critério Quadro ([HPSORA Figura ilutra parte do proceo de criação da Lita de Anomalia para o itema de controle de locaçõe de vídeo, a qual motra o procedimento

87 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 74 AlugarBtnClick alterando dado na tabela de dado "Cliente" e adicionando um regitro na tabela de dado "Locacoe". A Lita de Anomalia reultante da análie dee código e de algun outro trecho, é ilutrada pela Figura ú í û:øû ÙÝÞ ßAÞ üáý þúlí ûüÿ <Ü:çé ãúüfåû<üæãúlí ï/ãçé<ü0úaã/ä ÜæÙêëÜ0ÚAã/Øï ÚAãÜ ú í û:øû ÙÝÞ ßAÞ á ãïfåaä Ü(ÚAã(Øï ékû ãæ Ü0ÚAÙ/ìAí èé Ù&ÚAãî{çÜLï/ÙAä í Ùè&ÚÜ&èí èé ãï/ùúaã/ä ÜæÙêAãè&ÚAã ÚAãÜè $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrõe 6 e 8, Elaborar Lita de Procedimento e Funçõe e Modelar Dado do Software Legado, pelo fato da aída dete erem utilizada aqui como entrada. De forma a proeguir a reengenharia, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade da Lita de Anomalia: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 10, Criar Vião OO do Dado. 3URGXWR2EWLGRLita de Anomalia.

88 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 75 1RPHCriar Vião OO do Dado,QWXLWR Obter a vião orientada a objeto do dado a partir do itema legado procedimental. 3UREOHPD Tranformar o modelo de dado contruído de forma procedimental em uma vião orientada a objeto.,qioxrqfldv Pode-e utilizar a ferramenta 5DWLRQDO 5RVH para modelar o diagrama elaborado com a aplicação dee padrão; O engenheiro de oftware tem conhecimento do conceito da UML, para gerar modelo orientado a objeto a partir do MER. 6ROXomR 1. Coniderar cada entidade do MER como uma peudo-clae; 2. Tranportar o Campo de Dado decrito na Lita de Tabela e Chave para o Diagrama de Peudo-Clae, que etá endo gerado, como atributo da peudo-clae coniderada; 3. Analiar a Lita de Anomalia e, cada procedimento e função que tenha ido claificado como oc, c+, o+, o+c+, oc+ ou o+c, deve er coniderado como método, no Diagrama de Peudo-Clae, de toda a peudo-clae com a quai e relaciona (a quai modifica e/ou conulta); 4. Verificar a cardinalidade entre a entidade do Modelo Entidade- Relacionamento: º Para relacionamento binário (entre dua entidade) e com cardinalidade igual a 0..1, 1..1, 0..N ou 1..N, deve-e tranpor a cardinalidade para o Diagrama de Peudo-Clae da mema forma que eta e encontra no MER. Deve-e verificar também, o tipo do relacionamento, de forma a repreentá-lo como aociação ou agregação (todo-parte), de acordo com a funcionalidade que repreenta. O relacionamento de agregação podem er percebido na ituaçõe em que uma peudo-clae faz o papel, dentro do contexto do oftware, de parte de outra peudo-clae. O relacionamento que não forem dea forma, devem er mapeado como aociação; º Para relacionamento ternário (entre trê entidade) e com cardinalidade N..N, deve-e verificar, no MER, e o reultado dee relacionamento pode er repreentado como um OLQNDWULEXWRda peudo-clae envolvida. ([HPSOR A eguir, na Figura é repreentado o Diagrama de Peudo-Clae do itema de locaçõe de vídeo, no qual pode er verificado que o relacionamento

89 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 76 (1..N) entre a entidade "Vídeo" e "Claificacoe" do MER (Figura página 71) foi tranformado no relacionamento todo-parte entre a peudo-clae "Video" e "Claificacoe". ú í û:øû ÙÝÞ ßAÞ á í èëüfåùaû<æí ÙAäÚÜ í Ùû:Û Ùï/ÙÚAãèãAØÚÜÿ ýeä Ùèèãè&ÚÜ&èí èé ãï/ùúaã/ä ÜæÙêAãè&ÚAã ÚAãÜè $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrõe 8 e 9, Modelar Dado do Software Legado e Elaborar Lita de Anomalia, pelo fato que a aída dele ão utilizada como entrada para ua aplicação. Continuando o proceo de engenharia revera, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de Peudo-Clae: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 11, Criar Diagrama de 8VH&DVHVdo MASA. 3URGXWR2EWLGRDiagrama de Peudo-Clae. 1RPHCriar Diagrama de 8VH&DVHVdo MASA,QWXLWR Modelar a funcionalidade e o comportamento do oftware legado 3UREOHPD Mapear o comportamento do oftware legado, de forma a completar o proceo de engenharia revera. 6ROXomR Modelar o agente externo que interagem com o itema (atore) e o evento (XVHFDVHV) promovido por ele:

90 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto Verificar, atravé de cada interface com o uuário, preente no oftware legado, quem dipara a interaçõe com o ambiente externo. Ea interaçõe podem ocorrer por meio de botõe, menu, caixa de texto ou grade (JULGV). O reponável pelo diparo do evento deve er coniderado como ator do XVHFDVH; 2. Verificar quai a interaçõe ocorrem em cada interface. Cada interação origina um XVHFDVH 3. Nomear o XVHFDVH: º Cao o evento que origina o XVH FDVH eja tratado pelo ambiente Delphi atravé de componente, não há código-fonte mapeado com o conteúdo do ue cae. Nee cao, o nome do ue cae deve refletir ua funcionalidade; º Cao o evento que origina o XVH FDVH eja tratado pelo programa, deve-e obter, atravé do código-fonte, o nome do procedimento que trata o evento decrito, o qual deve contar da Lita de Procedimento e Funçõe. O nome do XVHFDVHdeve er o nome do procedimento ([HPSORA eguir, é ilutrada a tela de cadatro de cliente do itema de locaçõe de vídeo (Figura 3.4.9) e o Diagrama de 8VH &DVHV obtido atravé dela (Figura ). Nee cao, verificou-e a exitência de apena um XVH FDVH tratado pelo programa: ClienteBtnPrintLocacoeClick, pelo fato de apena o botão "ClienteBtnPrintLocacoe" levar a um procedimento (de memo nome do XVH FDVH). O demai XVH FDVHV do exemplo ão tratado por componente de aceo direto à tabela de dado não gerando procedimento implementado pelo programador. ú í û:øû ÙÝÞ ßAÞ áaãaä Ù&æÜ:ÛKÛ ãèåülçúaãaçé ãùü0æùúaùèékû<ü(úaã&æä í ãaçé ãè&úü&èí èé ãï/ùúaã/ä ÜæÙêAãè&ÚAã ÚAãÜè

91 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 78 ú í û:øû ÙÝÞ ßAÞ á í Ùû:Û Ùï/ÙÚAã èã&ýoùèãè/úaüfâ6î î Û ãaä ÙéKí Ü(Ù/í çé ãaû Ùæã&ÚAÙ ú í ûløû Ù&ÝÞ ßÞ $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrão 6, Elaborar Lita Procedimento e Funçõe, pelo fato de ua aída er utilizada aqui como entrada. Apó a aplicação dee padrão, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de 8VH &DVHV do MASA: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 12, Decrever o 8VH&DVHVdo MASA. 3URGXWR2EWLGRDiagrama de 8VH&DVHVdo MASA. 1RPHDecrever o 8VH&DVHVdo MASA,QWXLWRDetalhar a documentação do XVHFDVHVdo oftware legado. 3UREOHPDDocumentar o curo normal e o curo alternativo de execução do XVH FDVHV.,QIOXrQFLDV A elaboração da decriçõe de cada XVHFDVH pode variar em função de fatore epecífico a cada oftware legado, como o conhecimento do engenheiro de oftware a repeito do domínio da aplicação, ua experiência em Delphi e o tempo diponível para a aplicação do padrão; Apena o XVH FDVHV tratado pelo programa devem ter ua decriçõe elaborada.

92 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 79 6ROXomR O código-fonte da XQLWV e o Diagrama de 8VH&DVH formam a bae para a elaboração da decriçõe do XVHFDVHV Para cada XVHFDVH deve er obtida a decrição correpondente, eguindo a forma: 1. Etudar e documentar o código do procedimento reponável pela execução do XVHFDVH, extraindo a eqüência da operaçõe; 2. Verificar e documentar toda a ocorrência de curo alternativo no código, com o objetivo de mapear toda a ramificaçõe decorrente do curo normal. ([HPSORPara o XVHFDVH repreentado por ClienteBtnPrintLocacoeClick do itema exemplo utilizado no padrõe anteriore, foi extraída a decrição ilutrada pela Figura ú í û:øû ÙÝÞ ßAÞ á ãèæûkí êëü(úü! #"$! #% &!' ( )+*(-,.+*)0/!1 ')+* (-, % &!'!4 6 $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrão 11, Criar Diagrama de 8VH&DVHVdo MASA, pelo fato da aída dete er utilizada aqui como entrada. Continuando o proceo de reengenharia, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade na Decriçõe do 8VH &DVHV do MASA: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; inpecionar o andamento do proceo em relação ao Plano para Realização da Reengenharia: utilizar o padrão 3, Acompanhar o Progreo do Proceo de Reengenharia; continuar o proceo de engenharia revera: utilizar o padrão 13, Abtrair Diagrama de Peudo-Clae.

93 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 80 3URGXWR2EWLGRDecriçõe do 8VH&DVHVdo MASA. &OXVWHU(ODERUDU0RGHORGH$QiOLVHGR6LVWHPD 1RPHAbtrair Diagrama de Peudo-Clae,QWXLWRCriar a vião orientada a objeto do oftware legado. 3UREOHPD Eliminar a anomalia preente no Diagrama de Peudo Clae elaborado no MASA.,QIOXrQFLDV A análie do relacionamento modelado é, em muito cao, ubjetiva. Portanto, o conhecimento do engenheiro de oftware obre orientação a objeto é indipenável; No MAS, o procedimento e funçõe anômalo do MASA ão mapeado num número variável de método aociado à clae modificada e/ou conultada, cabendo ao engenheiro de oftware, a decião obre a modularização da funcionalidade implícita a ee procedimento e funçõe. 6ROXomR 1. Alterar o nome da clae, cao neceário, para mnemônico mai ignificativo; 2. Verificar a repreentatividade do nome de cada atributo da clae e ua utilidade no oftware legado; 3. Mapear a alteraçõe realizada no pao 1 e 2 da Solução elaborando uma lita de acordo com modelo ilutrado pelo Quadro 3.4.6; 4. Verificar o nome do procedimento e funçõe em anomalia, ou eja, claificado como (o) ou (c). Ee procedimento e funçõe devem ter o nome verificado quanto à repreentatividade e, ainda, o código-fonte analiado quanto a poibilidade de erem "quebrado" em um ou mai método, de forma a facilitar o reuo; 5. Mapear a alteraçõe realizada no método em anomalia na lita parcialmente preenchida no pao 3 da Solução (Quadro 3.4.6); 6. Tranformar o método anômalo em quanto método forem neceário de forma a dividido-lo na clae que obervam/contróem. Por exemplo, no cao de um procedimento (oc) declarado na clae A e B, deve originar SHORPHQRV doi método, um obervador na clae A e um contrutor na clae B. Outro método podem urgir, com o objetivo de reutilizar código e torná-lo mai

94 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 81 etruturado, ou ainda, pode-e fazer uo do método já exitente (criado a partir da aplicação do Pao 4 da olução), cao tenham a mema funcionalidade; 7. Documentar a tranformaçõe realizada no método anômalo, conforme modelo ilutrado pelo Quadro 3.4.7; 8. Identificar a funcionalidade do oftware legado tratada por meio de funçõe e procedimento de componente Delphi de aceo direto à Tabela de Dado; 9. Tranformar ea funcionalidade em quanto método forem neceário para prover eu encapulamento na clae definida. Ee novo método deverão contar apena da coluna MAS da Lita elaborada a partir do modelo do Quadro 3.4.6; 10. Verificar e, cao neceário, ubtituir o tipo de relacionamento entre a clae (aociação, agregação e herança). Para io, deve-e identificar a repreentatividade de cada relacionamento junto ao domínio da aplicação e com relação à regra da orientação a objeto quanto ao tipo de relacionamento exitente; 11. Alterar o nome do relacionamento, cao neceário, com o objetivo de melhorar a repreentatividade do memo. 6ØÙÚ:Û<Ü0ÝÞ ßÞ üaáâ6üúaãä Ü(ÚAÙ/ìí èé Ù&ÚAã&â ÙAåãÙï/ãAçé<Ü0â6îdî7 0â6î LISTA DE MAPEAMENTO MASA X MAS 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGHFULDomRGDOLVWD!! 9HUVmRGR'RFXPHQWR YHUVmRGDOLVWD!! 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR QRPHGRUHVSRQViYHOSHODFULDomRGDOLVWD!! 0$6$3VHXGR&ODVVHV 0$6&ODVVHV 1RPH << nome da peudo-clae>> << nome da clae correpondente>> $WULEXWRV 0RGLILFDGRV << nome originai do atributo >> << novo nome do atributo >> 0pWRGRV VHP $QRPDOLDV << nome originai do método em anomalia >> << novo nome do método >> 1RYRV 0pWRGRV - << nome do novo método criado para encapular a funcionalidade anteriormente tratada pelo componente de aceo a dado >> A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.6: º Projeto, Verão do Documento, Reponável pela Criação do Documento, Data da Criação do Documento ão preenchido como citado no padrõe anteriore;

95 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 82 º Coluna MASA (Peudo-Clae): contém a documentação do iten preente no código legado, ante da aplicação do padrão: º Nome: nome da peudo-clae, º Atributo Modificado: nome do atributo ante de ua alteração no MAS, º Método em Anomalia: nome do método claificado como (o) ou (c) ante de ua alteração no MAS; º Coluna MAS (Clae): contém o nome da modificaçõe e excluõe realizada na clae, atributo e método em anomalia. Nea coluna ão preenchido: º Nome: nome da clae, º Atributo Modificado: nome do atributo apó ua alteração no MAS, º Método em Anomalia: nome do método claificado como (o) ou (c) apó ua alteração no MAS, º Novo Método: método criado no MAS, a partir da divião da funcionalidade de método em anomalia, para a melhoria da modularização e aumento do reuo do código. 6ØÙÚ:Û<Ü0ÝÞ ßÞ Aáâ6ÜÚAãä ÜFåÙAÛ ÙÙ/ìí èé ÙÚAã&ý Ü:ÛKÛ ãèåü:çú!8çæí ÙÚAã/â:9é<ÜAÚÜè&î{ç ;Lï/ÙAä Üè LISTA DE CORRESPONDÊNCIA DE MÉTODOS ANÔMALOS 3URMHWR QRPHGRSURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGHFULDomRGDOLVWD!! 9HUVmRGR'RFXPHQWR 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR YHUVmRGDOLVWD!! QRPHGRUHVSRQViYHOSHODFULDomRGDOLVWD!! 0$6$ 0$6 0yGXORGR 6RIWZDUH EGFH I J IK FAB#ILNM OICI I> H BAB F> SL#F J BT T 0pWRGR $Q{PDOR < <UVBL#I#AB BABT T &ODVVLI &ODVVHV 0pWRGRV < <P J FCQCQ? D WAF F> BL#F J? F!T T < <P J FCXCI#AB#Y[Z]\^ILNB BAB#I> H F_ CI!T T < <UVBL#IC`H ICO IC T T A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.7: º Projeto, Verão do Documento, Reponável pela Criação do Documento e Data da Criação do Documento ão preenchido como citado no padrõe anteriore; º Módulo do Software: lita a XQLW do oftware legado que contém o método anômalo; º Método Anômalo: contém o nome do método com anomalia; º Claif.: decreve a claificação de acordo com o tipo da anomalia do método: oc, c+, o+, o+c+, oc+ ou o+c;

96 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 83 º Clae: contém o nome da clae a que erão aociado o método apó a eliminação da anomalia; º Método: contém o nome do método reultante da eliminação da anomalia. ([HPSORConiderando o exemplo do itema de controle de locaçõe de vídeo, foi gerado o Diagrama de Clae, ilutrado pela Figura Verifica-e que o relacionamento foram abtraído em relação ao Diagrama de Peudo-Clae, criando-e o link-atributo entre a clae "Cliente" e "Video". Também podem er viualizado trecho da Lita de Mapeamento MASA x MAS (Figura ) e da Lita de Correpondência do Método Anômalo (Figura ). Verifica-e, que houve o reuo do método ObterCodCliente, criado apó a abtração no MAS, pela Figura e , ainalada por D. ú í û:øû ÙÝÞ ßAÞ aá í èëüfåùaû<æí ÙAäÚÜ í Ùû:Û Ùï/ÙÚAã&ýeä Ùèèãè&ÚÜ&èí èé ãï/ùúaã/ä ÜæÙêAãè&ÚAã ÚAãÜè ú í û:øû ÙÝÞ ßAÞ Ýá í èëüfåùaû<æí ÙAäÚAÙ/ìí èé ÙÚAã/â6ÙåãÙï/ãAçé<Ü0â6î îb 0â6î!ÚÜ/èí èé ãï/ù&úaã/ä ÜæÙêAãè&ÚAã ÚAãÜè

97 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 84 ú í û:øû ÙÝÞ ßAÞ ß:á í èëüfåùaû<æí ÙAäÚAÙ/ìí èé ÙÚAã&ý Ü:ÛKÛ ãèåü:çú!8açæí Ù&ÚAã&â:9é<ÜAÚÜè&î{ç ;Lï/ÙAä Üè $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrão 10, Criar Vião OO do Dado, pelo fato de ua aída er utilizada aqui como entrada. Continuando o proceo de engenharia revera, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de Clae: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 14, Criar Diagrama de 8VH&DVHV do MAS. 3URGXWRV 2EWLGRV Diagrama de Clae, Lita de Mapeamento MASA x MAS e Lita de Correpondência de Método Anômalo. 1RPHCriar Diagrama de 8VH&DVHV do MAS,QWXLWRCompletar vião orientada a objeto do oftware legado. 3UREOHPDRefletir, no Diagrama de 8VH&DVHVdo MASA, a modificaçõe feita no Diagrama de Clae, com a eliminação da anomalia, a reetruturação do método exitente e a criação de novo método,qioxrqfldv O engenheiro de oftware deve analiar cada XVH FDVH para definir a eqüência da realização da operaçõe em alterar a funcionalidade repreentada ma de forma a refletir o método criado no MAS; O engenheiro de oftware deve verificar a neceidade da criação de novo XVH FDVHVa partir da divião da funcionalidade do método anômalo. 6ROXomR

98 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto Subtituir, no Diagrama de 8VH &DVHV do MASA, o nome do XVH FDVHV pelo nome que o método em anomalia paaram a utilizar no MAS. Ee nome ão viualizado na Lita de Mapeamento MASA x MAS; 2. Subtituir, no Diagrama de 8VH &DVHV do MASA, o nome do XVH FDVHV pelo nome que o método criado a partir da eliminação da anomalia paaram a utilizar no MAS. Ee nome ão viualizado na Lita de Correpondência de Método Anômalo; 3. Re-epecificar o Diagrama de 8VH &DVHV do MASA, mantendo o atore e atualizando o fluxo de entrada e aída do XVH FDVHV para que reflitam a alteraçõe neceária; 4. Elaborar a Lita de Mapeamento do 8VH &DVHV para documentar a modificaçõe efetuada no Diagrama de 8VH &DVHV do MASA. Um modelo propoto para ea lita encontra-e ilutrado no Quadro ØÙÚ:Û<Ü0ÝÞ ßÞ Aáâ6ÜÚAãä ÜFåÙAÛ Ù&ÚAÜæØAï&ãçé ÙêëÜ0ÚAÙ/ìAí èé Ù&ÚAã/â ÙAåãÙï/ãAçé<Ü(ÚÜèc-!d+$!Q LISTA DE MAPEAMENTO DE 86(&$6(6 3URMHWR SURMHWR!! 'DWDGH&ULDomRGR'RFXPHQWR GDWDGHFULDomR!! 9HUVmRGR'RFXPHQWR 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR YHUVmR!! QRPH!! 0$6$ 0$6 8VH&DVHV 8VH&DVHV &ODVVHV < <:> BL#I#ABeOCIPQFCI> B Y[Z]\!ZfT T < <:> BL#I#ABeOCIPQFCI> B#YfZg\T T < <FCXCBPh? BAB!T T A eguir é detalhado o conteúdo de cada um do campo que compõem o Quadro 3.4.8: º Projeto, Verão do Documento, Data da Criação do Documento e Reponável pela Criação do Documento ão preenchido como no padrõe anteriore; º 8VH&DVHV (MASA): contém o nome do XVHFDVHVdecrito no Diagrama de 8VH&DVHVelaborado no MASA; º 8VH&DVHV (MAS): contém o nome do XVHFDVHV apó a abtração realizada no MAS; º Clae: lita a clae a que pertence o método que trata o XVHFDVH. ([HPSOR Para o itema de controle de locaçõe de vídeo, o XVH FDVH ClienteBtnPrintLocacoeClick foi abtraído, para o XVH FDVH ImprimirRelatorioDeLocacoe. No MASA, ClienteBtnPrintLocacoeClick é um procedimento anômalo que obervava a peudo-clae "Cliente" e "Locacoe".

99 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 86 No MAS, ee procedimento anômalo foi quebrado no procedimento ImprimirRelatorioDeLocacoe que chama o método: ObterCodCliente (da clae Cliente), ObterLocacao (da clae Locacao). A Figura ilutra o Diagrama de 8VH&DVH reultante apó a abtração realizada e a Figura , a vião parcial da Lita de Mapeamento do 8VH&DVHV, em que nota-e que o XVHFDVHcontinua endo tratado por um evento. Porém, ee evento não tem aceo à nenhuma clae, chamando o método da clae "Cliente" e "Locacao", como decrito no padrão anterior: ú í û:øû ÙÝÞ ßAÞ àá í èëüfåùaû<æí ÙAäÚÜ í Ùû:Û Ùï/ÙÚAãic-!d+$!Q&ÙAåþè&Ù!jèéKÛ ÙêëÜFçÜ0â6î ú í û:øû ÙÝÞ ßAÞ üá í èëüfåùaû<æí ÙAäÚAÙ/ìí èé ÙÚAã/â6ÙåãÙï/ãAçé<Ü(ÚAãc-!d+$!Q $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrõe 11 e 13, Criar Diagrama 8VH&DVHV do MASA e Abtrair Diagrama de Peudo-Clae, poi ua aída ão utilizada aqui como entrada. Continuando o proceo de engenharia revera, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de 8VH&DVHVdo MAS: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia revera: utilizar o padrão 15, Decrever 8VH &DVHV do MAS. 3URGXWRV2EWLGRV Diagrama de 8VH&DVHV do MAS e Lita de Mapeamento do 8VH&DVHV.

100 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 87 1RPHDecrever 8VH&DVHVdo MAS,QWXLWR Re-epecificar a decriçõe do XVH FDVHV alterado durante a abtração do modelo elaborado. 3UREOHPD Atualizar a decriçõe do XVH FDVHV modificado apó a abtração do Diagrama de 8VH&DVHV do MASA. 6ROXomR 1. Obter, na Lita de Mapeamento de 8VH &DVHV, o nome do método que originam o XVHFDVHV do MAS e que tenham ofrido modificaçõe, além da troca do nome para melhoria da repreentatividade; 2. Re-epecificar a decriçõe do XVH FDVHV, para cada método encontrado no pao anterior, de forma que reflitam a modificaçõe neceária com relação à funcionalidade e aceo a clae; 3. Decrever o XVH FDVHV que, no MASA, eram tratado por componente do ambiente Delphi e que no MAS paaram a er tratado por método da clae. ([HPSOR O XVH FDVH ClienteBtnPrintLocacoeClick foi abtraído no MAS reultando no XVH FDVH ImprimirRelatorioDeLocacoe. Porém, ua funcionalidade continua endo a mema de forma que ua decrição não foi alterada. O XVHFDVH Atualizar, realizado no oftware legado por um componente do Delphi para aceo à tabela de dado, paou a er realizado, no MAS, pelo método Atualizar da clae "Cliente", endo neceária a elaboração de ua decrição. ú í û:øû ÙÝÞ ßAÞ á ãèæûkí êëü(úü! #"$!6î ékøùaä í kùaû $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV 5HODFLRQDGRV Ee padrão omente pode er aplicado apó a aplicação do padrõe 11 e 13, Criar Diagrama 8VH&DVHVdo MASA e Abtrair Diagrama de

101 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 88 Peudo-Clae, pelo fato de ua aída erem utilizada aqui como entrada. Continuando o proceo de reengenharia, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade na Decriçõe do 8VH &DVHV do MAS: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; inpecionar o andamento do proceo em relação ao Plano para Realização da Reengenharia: utilizar o padrão 3, Acompanhar o Progreo do Proceo de Reengenharia; iniciar o proceo de engenharia avante: utilizar o padrão 16, Elaborar Diagrama de Clae de Projeto. 3URGXWR2EWLGRDecriçõe do 8VH&DVHVdo MAS. PRE/OO. A eção eguinte decreve o padrõe para a condução da engenharia avante no 3DGU}HVGH(QJHQKDULD$YDQWHGR35(22 A engenharia avante é a egunda etapa do proceo de reengenharia com o PRE/OO, endo dividida em doi pao: elaborar o projeto avante e realizar a reimplementação do oftware. Cada pao foi documentado na forma de um FOXVWHU de padrõe: º &OXVWHU 6 (ODERUDUR3URMHWR$YDQWH. Contém o padrõe relacionado à obtenção modelo de projeto orientado a objeto correpondente ao oftware legado: Padrão 16: Elaborar Diagrama de Clae de Projeto; Padrão 17: Contruir Diagrama de Seqüência. O padrão 16, Elaborar Diagrama de Clae de Projeto, reflete o projeto da clae de forma a eparar a lógica do negócio da lógica de armazenamento do oftware, viando aumentar a modularidade, a manutenibilidade e melhorar o entendimento do itema. O padrão 17, Contruir Diagrama de Seqüência, foi criado com o objetivo de documentar o fluxo da operaçõe realizada pelo oftware. Ee padrão foi adaptado a partir do Grafo de Interação de Objeto do Fuion/RE e do padrão de memo nome preente no FOXVWHUModelar o Sitema Orientado a Objeto da FaPRE/OO RECCHIA HW DO(2002).

102 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 89 º &OXVWHU7 5HLPSOHPHQWDUR6RIWZDUH. Reúne o padrõe reponávei mudança da implementação do oftware Delphi procedimental para orientado a objeto: Padrão 18: Implementar a Clae, Padrão 19: Implementar a Lógica de Armazenamento, Padrão 20: Implementar a Lógica de Apreentação. O padrõe Implementar a Clae, Implementar a Lógica de Armazenamento e Implementar a Lógica de Apreentação foram propoto como forma de conduzir o engenheiro de oftware no proceo de re-implementação de oftware Delphi contruído em a adoção do paradigma orientado a objeto. A eguir ão decrito o padrõe de engenharia avante do PRE/OO, o quai foram agrupado no FOXVWHUV6 e 7: &OXVWHU(ODERUDUR3URMHWR$YDQWH 1RPHElaborar Diagrama de Clae de Projeto,QWXLWR Modularizar a funcionalidade do oftware, de forma a epara-la do aceo ao dado. 3UREOHPD Criar, numa nova intância do Diagrama de Clae, com menor nível de abtração, de forma a viualizar a modularizaçõe neceária à eparação da lógica de negócio da lógica de armazenamento do oftware.,qioxrqfld Separar o aceo ao dado do apecto funcionai, bem como da interface do oftware é difícil para um programador em experiência em programação orientada a objeto. 6ROXomR 1. Derivar cada clae contante do Diagrama de Clae elaborado com a aplicação do padrão 13, Abtrair Diagrama de Peudo-Clae; 2. Criar um método para cada funcionalidade preente em relação a manipulação e ao aceo ao dado da() tabela() com a quai cada clae e relaciona; 3. Cao neceário, criar atributo que facilitem a manipulação do dado; 4. Criar um Diagrama de Clae de Projeto para documentação da clae definida no Pao 1 a 3 da Solução. ([HPSORPara a clae Cliente, do exemplo da locadora de vídeo, foi derivada a clae DBCliente, como forma de modularizar o aceo à tabela de dado Cliente. O Diagrama de Clae de Projeto parcialmente concluído, é apreentado na Figura

103 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto Nota-e que a clae DBCliente não contém atributo, io ocorre poi toda a lógica do negócio já foi decrita na clae Cliente. l m n-o p q#r t u vwvm x o q!y m zq { }^~ q!p m q!y } Vm q n-p q ƒqe! # gy qxx x! p }ˆ } $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVEe padrão utiliza como entrada, a aída da aplicação do padrão 13, Abtrair Diagrama de Peudo-Clae. Continuando a engenharia avante, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de Clae de Projeto: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia avante: utilizar o padrão 17, Contruir Diagrama de Seqüência. 3URGXWRV2EWLGRVDiagrama de Clae de Projeto. 1RPHContruir Diagrama de Seqüência,QWXLWRDocumentar a lógica de negócio do itema legado. 3UREOHPDDecrever a lógica de negócio do itema legado para facilitar ua futura re-implementação.,qioxrqfldv Repreentar a iteração do método obtido no padrão 16, Elaborar Diagrama de Clae de Projeto, pode er uma tarefa complexa; Método já definido a partir da Decriçõe de 8VH&DVHV, viabilizam a olução dee problema. 6ROXomR Contruir um Diagrama de Seqüência, a partir de cada Decrição de 8VH &DVH, obtida a partir da aplicação do padrõe 12 e 15, Decrever 8VH &DVHVdo

104 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 91 MASA e Decrever 8VH &DVHV do MAS, repectivamente. Devem er coniderado o método diponívei na clae para a contrução do diagrama. ([HPSOR A decrição do XVH FDVH Atualizar, que provê a atualização do dado cadatrai de um cliente pelo itema de controle de locaçõe de vídeo originou o Diagrama de Seqüência ilutrado pela Figura l m n-o p q#r t Š v Vm q n-p q ƒq#! Œ- Ž! m qp!y q m }q}!"$! o q!y m zq!p $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVEe padrão utiliza como entrada, a aída da aplicação do padrõe 12, 15 e 16, Decrever 8VH&DVHVdo MASA, Decrever 8VH&DVHVdo MAS e Elaborar Diagrama de Clae de Projeto. Continuando a engenharia avante, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no Diagrama de Seqüência: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; inpecionar o andamento do proceo em relação ao Plano para Realização da Reengenharia: utilizar o padrão 3, Acompanhar o Progreo do Proceo de Reengenharia; continuar o proceo de engenharia avante: utilizar o padrão 18, Implementar a Clae. 3URGXWRV2EWLGRVDiagrama de Seqüência do Sitema.

105 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 92 &OXVWHU5HLPSOHPHQWDUR6RIWZDUH 1RPH Implementar a Clae,QWXLWRDefinir formalmente a lógica de negócio do itema, previamente modelada, a partir da aplicação do padrõe anteriore. 3UREOHPD Definir o atributo, tratando o encapulamento do memo, implementar o método de aceo a ee atributo, de forma a tratar a lógica de negócio de cada objeto. &RQWH[WR A clae referente à lógica de negócio do itema decrita no Diagrama de Clae de Projeto reultante da aplicação do padrão 16, Elaborar Diagrama de Clae de Projeto formam a bae para a aplicação dee padrão.,qioxrqfldv O uceo da aplicação dee padrão, depende, em grande parte, da qualidade da modelagem previamente elaborada, ou eja, da correta expreão da lógica de negócio no produto de trabalho criado com a aplicação do padrõe anteriore; O engenheiro de oftware tem facilidade na expreão de lógica de negócio por meio de diagrama. 6ROXomRPara cada clae relacionada a lógica de negócio preente no Diagrama de Clae de Projeto, deve-e: 1. Criar a etrutura da clae com a eçõe detinada ao atributo e método público, protegido e/ou privado; 2. Criar o código-fonte correpondente ao atributo imple e ao atributo originado de relacionamento com outra clae, verificando ua viibilidade (em qual eção erão declarado) e tipo; 3. Criar o código-fonte para o método que tratam da funcionalidade do objeto. Para io, deve-e verificar a Lita de Mapeamento MASA x MAS e a Lita de Correpondência de Método Anômalo, no entido de bucar a origem do código-fonte legado que deverá er re-implementado em cada método. ([HPSORA clae Cliente, obtida a partir da abtração do oftware legado, tem o código-fonte referente à ua declaração ilutrado pela Figura (pao 1 e 2 da Solução). Já, a implementação de eu método conta da Figura (pao 3 da Solução).

106 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 93 l m n-o p q#r t r vwvm x }~ q!p m q!y!q#! y q!p q { }!qe y qxx e gy m! l m n-o p q#r t -v ƒ~!y ƒ q { }i } xƒ }! } xe!qe y qxx # gy m $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRV A aída da aplicação do padrão 16, Elaborar Diagrama de Clae de Projeto, formam a bae para a aplicação dee padrão, o qual é aplicado em conjunto com o demai padrõe do FOXVWHU, de forma a completar,

107 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 94 imultaneamente, a interface, o aceo a dado e a funcionalidade previta no oftware. Em conjunto com a aplicação do padrõe, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no código fonte da clae implementada: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração. 3URGXWR2EWLGRCódigo-fonte da clae relativa à lógica de negócio do oftware. 1RPH Implementar a Lógica de Armazenamento,QWXLWRDefinir a lógica de armazenamento do oftware. 3UREOHPDImplementar o objeto reponávei pelo encapulamento do método de aceo ao dado. &RQWH[WRA clae que provêem a interface com o banco de dado, documentada no Diagrama de Clae de Projeto contruído a partir da aplicação do padrão 16, Elaborar Diagrama de Clae de Projeto, ão utilizada como entrada.,qioxrqfldv A orientação a objeto permite que o código-fonte eja totalmente organizado, de forma que a hierarquia do objeto é definida atravé de vário nívei de abtração; Para aplicaçõe multi-uuário, ee padrão deve contemplar a implementação, no método, da manutenção da integridade do dado, apecto já diponível em banco de dado como 2UDFOHe 0LFURVRIW64/6HUYHU 6ROXomR Para cada clae relacionada a lógica de armazenamento do dado, preente no Diagrama de Clae de Projeto, deve-e: 1. Criar a etrutura da clae, com a eçõe detinada ao atributo e método público, protegido e/ou privado; 2. Criar o código-fonte correpondente ao atributo imple e ao atributo originado de relacionamento com outra clae, verificando ua viibilidade (em qual eção erão declarado) e tipo; 3. Criar o código-fonte para o método que tratam do aceo ao dado do objeto. Para io, deve-e verificar a Lita de Mapeamento MASA x MAS e a Lita de Correpondência de Método Anômalo, no entido de bucar a origem do código-fonte legado que deverá er re-implementado em cada método. ([HPSOR A clae DBCliente, derivada da clae Cliente, é reponável pelo aceo à tabela de dado Cliente, como ilutra a Figura

108 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 95 l m n-o p q#r t t v y q!p q { }!qe y qxx #! #q xx }q } xe!q } xe!!p m q!q#!qe y qxx h gy m! $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVEe padrão relaciona-e com o padrõe 16 e 18, Elaborar Diagrama de Clae de Projeto e Implementar a Clae, pelo fato de ua aída er utilizada aqui como entrada. Continuando o proceo de engenharia avante, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no código-fonte da clae relativa à lógica de armazenamento e manipulação de dado do oftware: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração; continuar o proceo de engenharia avante: utilizar o padrão 6, Implementar a Lógica de Apreentação. 3URGXWRV2EWLGRVCódigo-fonte da clae relativa à lógica de armazenamento e manipulação de dado. 1RPH Implementar a Lógica de Apreentação,QWXLWRRedefinir a interface do oftware em a utilização de componente de aceo direto ao banco de dado.

109 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 96 3UREOHPD Implementar a interface do oftware e a ligação ao método da clae anteriormente criada. &RQWH[WR No oftware Delphi, implementado em a utilização do paradigma orientado a objeto, ão normalmente utilizado, para apreentar o dado na interface, componente que manipulam diretamente o banco de dado, em a interferência de procedimento ou funçõe definido pelo programador. Já, no paradigma orientado a objeto, ão criado evento que utilizam o método definido na clae implementada com a aplicação do padrõe 18 e 19, Implementar a Clae e Implementar a Lógica de Armazenamento do Software, de forma a prover a apreentação do dado.,qioxrqfldv O componente de manipulação de dado preente no ambiente Delphi facilitam a implementação. Porém, ete omente podem er utilizado no cao de aceo direto ao dado, o que fere o conceito de encapulamento do paradigma orientado a objeto; Há componente gráfico (campo de edição e JULGV) que apreentam dado fornecido pelo programador, podendo er utilizado para motrar a aída de método da clae por ete definida; A codificação da interface orientada a objeto no ambiente Delphi é, em primeira intância, mai complicada que a programação procedimental, pelo fato do aceo ao dado ter que er completamente implementado pelo programador de forma apena a trocar informaçõe com a interface. Porém, uma vez codificada a interface báica, eta podem er reutilizada, bem como a clae de auxílio à apreentação do dado. 6ROXomR 1. Definir a interface do oftware de forma a prover todo o recuro diponívei no legado utilizando omente componente imple de apreentação de dado; 2. Implementar, a partir de evento, o aceo ao método da clae codificada durante a aplicação do padrõe 18 e 19. ([HPSOR A interface de cadatro de cliente do oftware legado foi totalmente deenvolvida utilizando-e componente de aceo direto ao dado, diponívei no conjunto 'DWD &RQWUROV como ilutra a Figura A interface contruída com componente que apena apreentam dado obtido pelo programador, no cao provindo da clae "DBCliente" e "DBLocacao" é ilutrada na.figura

110 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 97 l m n-o p q#r t š v V} ƒ~ }- x! #q xx } -m p }q#!q } xeœ-o #}-p m n-m q!p q ƒ qm!p œ q e }x } œ :q!p y n!q!} l m n-o p q#r t ž v!p œ q #! e y m! x!}x!m x ƒq#! y } q {Ÿ! x! :! }q!~ xeqp n!! q!p m qe [ $YDOLDomR... -XVWLILFDWLYD... 3DGU}HV5HODFLRQDGRVO padrõe 17,18 e 19, Contruir Diagrama de Seqüência, Implementar a Clae e Implementar a Lógica de Armazenamento ão complementare a ee padrão pelo fato de ua aída erem utilizada aqui como

111 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 98 entrada. Complementando o proceo de engenharia avante, o engenheiro de oftware deve: realizar a inpeção de garantia da qualidade no código-fonte referente à lógica de apreentação do oftware: utilizar o padrão 4, Realizar Inpeção de Garantia da Qualidade; atualizar o controle de configuração: utilizar o padrão 5, Controlar a Configuração. 3URGXWRV2EWLGRV Interface e código-fonte referente à lógica de apreentação do oftware. Terminada a aplicação do FOXVWHUV, o engenheiro de oftware pode refinar o produto obtido, aplicando novamente todo ou algun padrõe na ordem em que coniderar melhor. &RQVLGHUDo}HV)LQDLV A não exitência de um proceo que conduzie pao a pao a realização da reengenharia orientada a objeto a partir de itema legado deenvolvido em a utilização dee paradigma aumentava o eforço e o tempo gato pelo engenheiro de oftware nea tarefa. Dee modo, o PRE/OO foi elaborado viando auxiliar engenheiro de oftware na realização do proceo de reengenharia de itema legado não orientado a objeto. Havendo, também, a preocupação com a qualidade do proceo de reengenharia, foi realizada a adaptação da KPA do Nível 2 de maturidade do SW-CMM. Com o PRE/OO a bae para a engenharia revera e para a engenharia avante etabelecida pelo método Fuion/RE continuam a mema. O objetivo do PRE/OO é evoluir o método anterior para que o reultado do proceo reengenharia poam er melhorado ainda mai, com a garantia da qualidade do proceo em todo o eu pao e vito que grande parte do eforço de documentação pode er auxiliado pelo uo da ferramenta o 5DWLRQDO 5RVH (RATIONAL, 2001), já batante utilizada na prática profiional, fornecendo maior confiabilidade ao reultado alcançado. O planejamento propoto no PRE/OO capacita uma emprea a prover o mínimo de viibilidade com relação à neceidade que erão gerada ao longo do proceo de reengenharia orientada a objeto de itema procedimentai. Dea forma, vário projeto podem er conduzido imultaneamente, levando a maior e melhor aproveitamento do recuro (humano, hardware e oftware) diponívei na emprea. O

112 Ca pítu lo 3. O Proce o de Reen gen h a ria Orien ta da a Objeto 99 planejamento que é vital para o deenvolvimento de oftware não etava explicitamente incluído em proceo de reengenharia, endo uma da contribuiçõe dete trabalho. Optou-e por definir inpeçõe como forma de atender a KPA Garantia da Qualidade pelo fato dea poderem er realizada a qualquer momento durante a aplicação do padrõe. A forma de decrição do proceo por meio de padrõe facilita o aprendizado pelo engenheiro de oftware, bem como a aplicação de parte iolada do proceo quanta veze e fizerem neceária para prover refinamento de forma a gerar um produto final com qualidade. Realta-e que o padrõe exitente na FaPRE/OO foram intanciado para oftware implementado em Delphi, comprovando aim que o proceo de reengenharia apreentado pode er utilizado independente da linguagem de programação do oftware legado. Ao completar o proceo de reengenharia de um oftware legado com a utilização do PRE/OO, é gerada toda a ua documentação, muita veze inexitente ou deatualizada devido à manutençõe freqüente. Outro apecto importante é a organização propota pelo PRE/OO quanto à forma de implementação orientada a objeto apreentada pelo padrõe do FOXVWHU 7, Re-implementar o Software, que coniderou a arquitetura mai atuai de implementação exitente, como a multicamada, com eu apecto modular de divião da lógica de negócio, armazenamento e interface. Ea forma de implementação pode er adotada, independentemente do tamanho do oftware legado, facilitando o reuo da clae durante a expanõe ou em novo oftware. A interface contruída a partir do aceo ao método definido não difere, no apecto gerai de apreentação, da exitente no oftware legado, o que facilita a utilização pelo uuário acotumado com ela. Porém, podem er feita modificaçõe durante a re-definição da mema, de forma a melhorar a uabilidade ou a pedido do uuário como, por exemplo: definição de tecla de atalho à funcionalidade, modificação em menagen de erro e de confirmação apreentada pelo oftware ou poicionamento de componente na interface.

113 10 0 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i &RQVLGHUDo}HV,QLFLDLV Ete capítulo apreenta um etudo de cao para a aplicação do PRE/OO. Nele, um oftware legado procedimental implementado em Delphi em caracterítica orientada a objeto é ubmetido ao proceo de reengenharia, utilizando a caracterítica orientada a objeto preente no 2EMHFW3DVFDO. Na Seção 4.2 é apreentado o oftware legado alvo do etudo de cao. A Seção 4.3 decreve a preparação e o planejamento da reengenharia com a aplicação do padrõe do primeiro cluter referente à melhoria da qualidade do PRE/OO. Na Seção 4.4 a etapa de engenharia revera do oftware legado do PRE/OO é apreentada e na Seção 4.5 é motrada a aplicação da engenharia avante do PRE/OO. A conideraçõe finai encontram-e na Seção 4.6. 'HVFULomRGR6RIWZDUH/HJDGR O oftware &21752/(*/2%$/ para Loja poui cerca de linha de código Delphi e foi deenvolvido há quatro ano por um programador com experiência na linguagen procedimentai Pacal, &OLSSHU e C. Apear do ambiente Delphi (INPRISE, 1999) ter 2EMHFW Pacal como linguagem de programação, que permite uma implementação totalmente de acordo com o paradigma orientado a objeto, o itema foi deenvolvido eguindo a forma procedimental. O oftware legado tem como funcionalidade principal a getão do etoque e do crediário de pequena emprea do etor de comércio de vetuário. Um reumo de ua funcionalidade é decrito a eguir:

114 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 1 º Caixa: o caixa diário é controlado, endo ua movimentação proveniente da entrada de pagamento de parcela de crediário e de venda efetuada. Um relatório pode er gerado com toda a movimentação diária do memo, cao olicitado pelo gerente; º Cliente: permite a incluão, a atualização de dado e a excluão de cliente cadatrado, além de conter funçõe de buca e de impreão de relatório com informaçõe pertinente, como por exemplo, a ficha cadatral completa de um determinado cliente; º Crediário: ão coniderada como crediário a venda de mercadoria ao cliente cadatrado, financiada pela emprea em até cinco parcela. Em cao de venda com pagamento em crediário, o valor da parcela é calculado automaticamente pelo oftware, bem como o juro em cao de atrao no pagamento; º Etoque: a mercadoria comercializada pela emprea ão cadatrada em etoque e cada uma recebe um código que erve como identificador. Cada mercadoria tem eu preço médio controlado, proveniente do cuto de cada lote de mercadoria ob a quantidade total diponível. A freqüência de aída e entrada de mercadoria também pode er acompanhada por meio de relatório. O etoque é dividido por core e por grupo de mercadoria; º Fechamento: o fechamento de venda, troca e comiõe do vendedore é emitido a cada final de mê, em forma de divero relatório, para que e poa controlar o cuto e lucro com relação a ea operaçõe; º Troca: a mercadoria vendida pela emprea podem er trocada por outra, endo que o oftware controla a entrada e a aída de etoque quando ea operação ocorre, além do débito ou crédito decorrente; º Venda: a cada venda realizada, o oftware emite a nota fical correpondente, gerencia a aída de etoque, a inerção do regitro do novo crediário (cao a venda não eja paga à vita) e faz o cálculo da comião do vendedor; º Vendedore: ão cadatrado e identificado por código emitido pelo oftware, têm regitrado eu crédito e débito para com a emprea, além da comião ganha durante o mê, a qual é calculada pelo oftware durante cada venda efetuada pelo vendedor a partir de porcentagem de ganho individual contante de eu cadatro. A eção eguinte inicia o proceo de reengenharia orientada a objeto utilizando o PRE/OO para o itema legado tomado como etudo de cao.

115 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 2 O FOXVWHVe o padrõe apreentado no Capítulo 3 não ão repetido aqui. Para cada FOXVWHU é apreentado o eu nome. Para o padrõe apreenta-e o 1~PHURe o 1RPHcorrepondente ao exitente no Capítulo 3. A 6ROXomR e o 3URGXWRV2EWLGRV referem-e à aplicação do PRE/OO ao itema legado &21752/(*/2%$/. A Figura correponde à reapreentação da Figura 3.2.1, com o objetivo de facilitar a viualização do FOXVWHUVe repectivo padrõe pelo leitor. l m n-o p q: Š u vwvm x }n!!p q!y } x! ª! ~ q -p Ÿ! x }i «V [ l!m n-o p q#r Š u

116 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i UHSDUDomRH3ODQHMDPHQWRGR3URFHVVRGH5HHQJHQKDULDFRPR 35(22 &OXVWHU3UHSDUDUH3ODQHMDUR3URFHVVRGH5HHQJHQKDULD O proceo de reengenharia orientada a objeto do oftware legado &21752/(*/2%$/ iniciou-e com a aplicação do FOXVWHU 1, de forma a prover a contextualização do projeto em quetão, ou eja, o entendimento do projeto em eu domínio de aplicação eguido pelo planejamento da atividade contida no PRE/OO. 3UHSDUDUR3URFHVVRGH5HHQJHQKDULD 6ROXomR A preparação do proceo de reengenharia para o oftware legado, &21752/(*/2%$/, teve inicio com a definição do limite do projeto, o entendimento de eu ecopo, a determinação do produto de trabalho a erem elaborado e da atividade a erem realizada, ou eja, do padrõe neceário para a obtenção do produto deejado; A partir da execução do itema e do conhecimento de eu contexto pelo engenheiro de oftware, definiu-e e documentou-e o ecopo do oftware legado no primeiro documento gerado a repeito do projeto, o qual encontra-e ilutrado no Quadro Poderiam er realizada entrevita com uuário e/ou utilizar-e outro produto exitente, como manuai de operação, de forma a enriquecer a informaçõe diponívei; Em eguida reuniu-e o demai produto diponívei a repeito do oftware, no cao, apena o código-fonte e o arquivo de dado. Com ea informaçõe foi poível definir quai o produto de trabalho deveriam er gerado e, a partir da decrição do PRE/OO (Capítulo 3 dee trabalho), o padrõe a erem aplicado para a elaboração de tai produto. 3URGXWR2EWLGR ± o q -p }! r u v ² q! q ƒ! }! m m!q! x } } œ :q!p ² n!q!} LEVANTAMENTO DE ATIVIDADES 3URMHWR ControleGlobal 'DWDGH&ULDomRGR'RFXPHQWR 21/11/2001 9HUVmRGR'RFXPHQWR 1.0 ³ q ƒ #!q Vm o q { } 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Gizelle Lemo O oftware em quetão foi deenvolvido para prover a gerência da eguinte área de uma emprea de pequeno porte reponável pela comercialização de artigo para vetuário: º etoque: cadatro, entrada e aída de mercadoria, cálculo do preço de venda médio e do ganho com relação a cada mercadoria cadatrada; poibilidade de aociação de mercadoria a grupo; impreão de vário relatório e de etiqueta com código de barra para cada mercadoria;

117 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 4 º venda e troca efetuada: cálculo de vário tipo de plano de pagamento (à vita ou em crediário), movimentação do etoque com relação à entrada e aída de mercadoria, cálculo da comião do vendedore e do valor de impoto; impreão de nota ficai; º cliente cadatrado: confecção e impreão de mala direta, poibilidade de diferenciação de cliente em epeciai e com retriçõe de crédito; º crediário: controle de pagamento de parcela, controle de parcela em atrao, a vencer; impreão de relatório periódico de atraado; º fechamento menal: controle de cuto e lucro com relação à venda, aída de etoque e pagamento ao vendedore; º caixa diário da emprea: fechamento diário e controle da entrada e aída do caixa, controle da origem da cada movimentação (venda, troco, retirada de caixa). Cada uma da funcionalidade citada foi deenvolvida em um módulo independente e o dado ão armazenado em tabela do banco de dado relacional MySQL.! xi Vm x ~ }- m x º Decrição de toda a tabela de dado ( QµX ¹ SQL contante de arquivo de dado); º Código-fonte completo; º Programa executável. p } -o } xe! º-p q!» q!y }q!p ƒ¼ +y q!» }-p q!} x m No proceo de reengenharia, ter-e-á a elaboração do oftware orientado a objeto, endo gerado, durante todo o proceo, o eguinte produto: º Lita de Procedimento e Funçõe; º Decriçõe do ½+ ¾ À ¾ ; º Lita Chama/Chamado Por ; º Lita de Correpondência de Método Anômalo; º Lita de Anomalia; º Lita de Mapeamento MASA x MAS; º Modelo Entidade-Relacionamento; º Lita de Mapeamento do ½- ¾ À Q¾ ; º Lita de Tabela e Chave; º Diagrama de Clae de Projeto; º Diagrama de Peudo-Clae; º Diagrama de Seqüência; º Diagrama de Clae MAS; º Código-fonte Orientado a Objeto. º Diagrama de ½- ¾ À ¾ (MASA e MAS); Ám m!q! xeq#!p ƒâ«q!y zq!qx Dada a neceidade da elaboração de todo o produto de trabalho que compõem o PRE/OO, erão aplicado o 15 padrõe que compõem o cluter 3 a 7. A partir da elaboração do documento Levantamento de Atividade eguiu-e a determinação de como a reengenharia orientada a objeto do oftware legado eria realizada. Para io, foi aplicado o padrão 2. 3ODQHMDUR3URFHVVRGH5HHQJHQKDULD 6ROXomR O planejamento do proceo foi realizado de forma a dipor a atividade documentada, a partir da aplicação do padrão 1, de acordo com o tempo diponível para a realização do PRE/OO (280 hora), como ilutrado pelo campo Tempo Diponível para o Proceo, do Quadro Aim, realizou-e a divião do tempo entre o FOXVWHUV de padrõe a erem aplicado, coniderando-e o divero produto de trabalho a erem elaborado; Ea ditribuição do tempo diponível entre o divero padrõe a erem aplicado foi feita manualmente, em a utilização de métrica de eforço, coniderando o número e a complexidade do produto obtido com a aplicação de cada padrão. A complexidade de cada produto foi etimada empiricamente, ou

118 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 5 eja, a partir de experiência anteriore do engenheiro de oftware na elaboração do produto; Informaçõe obre a equipe reponável pela realização do PRE/OO, bem como o papel de cada integrante, foram omitida pelo fato do proceo ter ido realizado apena por um engenheiro de oftware; Em eguida foram definido o iten de configuração controlado durante o PRE/OO, além do próprio Plano para Realização da Reengenharia. Outro dado documentado foram a inpeçõe de garantia da qualidade e de inpeção, com o objetivo de garantir ua realização e, eperada, garantia da qualidade. 3URGXWR2EWLGR ± o q -p }! r Š!v y q }~ q!p q«q!y m zq{ }!q«! n!! q!p m q p }ˆ } ControleGlobal w!p x }i!}^ } o ƒ! } PLANO PARA REALIZAÇÃO DA REENGENHARIA q qe! e gp m q { } } } o ƒ! } 21/11/2001 «x ~ }- x Ã!y ~ y qe gp m q { }i!}^ } o ƒ! } 1.0 Gizelle Lemo q } xäf!p q!m xe } p } xx }i! «! n!! q!p m q º! ƒ~ }^ Vm x ~ }- y~ q!p qe} p } xx } 70 dia. 4 hora de trabalho/dia. Total: 280 hora q q x m ƒq!q~ q!p ql m q!y m zq { } } p } xx }i! «! n!! q!p m q v 22/02/2002! x! # V}- œ m n0o p q { } ± m º Lita de Procedimento e Funçõe; º Lita Chama/Chamado Por ; º Lita de Anomalia; º Modelo Entidade-Relacionamento; º Lita de Tabela e Chave; º Diagrama de Peudo-Clae; º Diagrama de Clae MAS; º Diagrama de ½- ¾ À ¾ (MASA e MAS); x ~ {Ÿ! x! #Äfq!p q! m q#!q o q!y q! º Decriçõe do ½+ ¾ À ¾ ; º Lita de Correpondência para Método Anômalo; º Lita de Mapeamento MASA x MAS; º Lita de Mapeamento do ½+ ¾ À ¾ ; º Diagrama de Seqüência; º Diagrama de Clae de Projeto; º Código-fonte Orientado a Objeto. A inpeçõe de garantia da qualidade para prover a conformidade do produto de trabalho elaborado devem er realizada ao fim da elaboração de cada produto de trabalho, em cada uma da volta a erem dada durante o proceo, que ocorre de forma evolutiva. x ~ {Ÿ! x! }0ƒ~ q! q ƒ! } Go ~!p m x } } p }ˆ } Uma inpeção de acompanhamento do proceo de reengenharia comparando o reultado obtido com o dado etimado deve er realizada ao final de cada um do µhå Æ ¹ ¾ 3 a 6. Iten a erem inpecionado: º Produto de trabalho a erem elaborado º Tempo gato na concluão do pao º Inpeçõe de garantia da qualidade realizada e reultado obtido 0qxx }^u[ç«m q!y m zq { }!q p Œ-o m o p qe! ªr p } -o } xe! º-p q!» q!y } º Lita de Procedimento e Funçõe º 1 dia para concluão (3 h de trabalho) º Alvo de inpeção de garantia da qualidade (0,5 h de trabalho) º Recuro computacional neceário: editor de texto º Lita de Chama/Chamado por º 6 dia para concluão (24 h de trabalho) º Alvo de inpeção de garantia da qualidade (5,5 h de trabalho); º Recuro computacional neceário: editor de texto. º! ƒ~ }^È xx Ã!p m }~ q!p qe V}0 y ox } } 0qxx } º 7 dia ou 27 h de trabalho revitalização da arquitetura º 2 dia ou 6 h de trabalho inpeçõe para garantia da qualidade º 1 dia ou 1 h de trabalho inpeção de acompanhamento r xe}-oé 0m de projeto qx ao término da realização dee pao º Tempo total reultante (etimado): 27h + 6h + 1h =

119 ò õ è ð Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 6 ÊVË!ÌÍ!Î ÏÐ!ÍÑ ÒÓ Ô Í ÕÖ!ÍÓ Inpeçõe de Garantia da Qualidade: 2 Inpeçõe de Acompanhamento e Supervião: 1 0ØÓÓ ÏiÙ:ÚÛ Í Ü Ý Ô Í!Î Ø ÕÞ ÏÐ ÏißÏ!Ð!Í!à ÏÐ!Í#á]Ò â!à ã Ó ÍeÐ ÏäGã Óå Í ÌØáå Ý Ø!àæ! ª+ç è Î Ï Ð-Ýå Ï ÓeÐ!Íé-Î Ø!ê Ø!à ë Ï º Lita de Tabela e Chave º 1 dia para concluão (4 h de trabalho); º Alvo de inpeção de garantia da qualidade (0,5 h de trabalho); º Recuro computacional neceário: editor de texto; º Modelo Entidade-Relacionamento º 1 dia para concluão (3 h de trabalho); º Alvo de inpeção de garantia da qualidade (0,5 h de trabalho); º Recuro computacional neceário: editor de texto; º Lita de Anomalia º 2 dia para concluão (7 h de trabalho); º Alvo de inpeção de garantia da qualidade (0,5 h de trabalho); º Recuro computacional neceário: editor de texto; º Diagrama de Peudo-Clae º 3 dia para concluão (10 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ); º Diagrama de ½- ¾ À ¾ do MASA º 3 dia para concluão (11 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ); º Decriçõe de ½- ¾ À ¾ do MASA º 4 dia para concluão (15 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ). é!í ÌÔ Ï^Ê Í ÜÍÓÓ â!î ã ÏÔ Ø!Î ØeïVÏ0Ò Ü à ÝÓ Þ ÏÐ Ï 0ØÓÓ Ï º 13 dia ou 50 h de trabalho recuperação do MASA º 2 dia ou 4,5 h de trabalho inpeçõe para garantia da qualidade º 1 dia ou 1 h de trabalho inpeção de acompanhamento ëóï0ýiòxçeð-ã de projeto ao ØÓ término da realização dee pao Tempo total reultante (etimado): 50 h + 4,5 h + 1 h = ðð ñ ð ÊVË!ÌÍ!Î ÏÐ!ÍÑ ÒÓ Ô Í ÕÖ!ÍÓ Inpeçõe de Acompanhamento e Supervião: 1 Inpeçõe de Garantia da Qualidade: 6 0ØÓÓ Ïió:Úeô:êå Í!Ò ÕÞ ÏÐ Ïiß:Ï Ð!Í!à ÏiÐ!Íá]Ò â!à ã Ó ÍeÐ ÏäVã Óå Í ÌØ#æ! ª Î Ï Ð-Ýå Ï ÓeÐ!Íé-Î Ø!ê Ø!à ë Ï º Diagrama de Clae º 3 dia para concluão (10 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ); º Lita de Mapeamento MASA x MAS º 2 dia para concluão (8 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: editor de texto; º Lita de Correpondência de Método Anômalo º 3 dia para concluão (10 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: editor de texto; º Diagrama de ½- ¾ À ¾ do MAS º 3 dia para concluão (10 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ); º Decriçõe do ½+ ¾ À ¾ do MAS º 4 dia para concluão (15 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ) º Lita de Mapeamento do ½- ¾ À Q¾ º 1 dia para concluão (2 hora de trabalho); º Alvo de Inpeção de garantia da qualidade (0,5 h de trabalho); º Recuro computacional neceário: editor de texto. é!í ÌÔ Ï^Ê Í ÜÍÓÓ â!î ã ÏÔ Ø!Î ØeïVÏ0Ò Ü à ÝÓ Þ ÏÐ Ï 0ØÓÓ Ï º 14 dia ou 55 h de trabalho obtenção do MAS º 2 dia ou 5,5 h de trabalho inpeçõe para garantia da qualidade º 1 dia ou 1 h de trabalho inpeção de acompanhamento ëóï0ýiò de projeto Ð-ã ao ØÓ término da realização dee pao Tempo total reultante (etimado): 55 h + 5,5 h + 1h = õ ñ ð ÊVË!ÌÍ!Î ÏÐ!ÍÑ ÒÓ Ô Í ÕÖ!ÍÓ Inpeçõe de Acompanhamento e Supervião: 1 Inpeçõe de Garantia da Qualidade: 6

120 ð Ù õ õ è õ Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 7 Î Ï Ð-Ýå Ï ÓeÐ!Íé-Î Ø!ê Ø!à ë Ï 0ØÓÓ Ïç#Úö+à Ø!ê Ï-Î Ø ÕÞ ÏÐ Ï Î Ï Íå Ïáø Ø!Òå Íeæ! ª º Diagrama de Clae de Projeto º 2 dia para concluão (8 h de trabalho); º Alvo de inpeção de garantia da qualidade (0,5 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ); º Diagrama de Seqüência º 4 dia para concluão (15 h de trabalho); º Alvo de inpeção de garantia da qualidade (1 h de trabalho); º Recuro computacional neceário: ferramenta gráfica (ìvà ¹ íî ÀÅìVí ¾ ). é!í ÌÔ Ï^Ê Í ÜÍÓÓ â!î ã ÏÔ Ø!Î ØeïVÏ0Ò Ü à ÝÓ Þ ÏÐ Ï 0ØÓÓ Ï º 6 dia ou 23 h de trabalho obtenção do MAS º 1 dia ou 1,5 h de trabalho inpeçõe para garantia da qualidade º 1 dia ou 1 h de trabalho inpeção de acompanhamento de projeto ao término da realização dee pao Tempo total reultante (etimado): 23 h + 1,5 h + 1h = Ù ëóï0ý Ð-ã ØÓ ð ñ ð ÊVË!ÌÍ!Î ÏÐ!ÍÑ ÒÓ Ô Í ÕÖ!ÍÓ Inpeçõe de Acompanhamento e Supervião: 1 Inpeçõe de Garantia da Qualidade: 2 0ØÓÓ Ï ÚÛ Í ù ã ÌÔ à Í ÌÍ!Òå Ø ÕÞ ÏÐ ÏäÏ ú å û:ø!î Íeæ Ü à ÝÓå Í!Î-üè Î Ï Ð-Ýå Ï ÓeÐ!Íé-Î Ø!ê Ø!à ë Ï º Código-fonte da clae referente a lógica de negócio º 5 dia para concluão (20 h de trabalho); º Alvo de inpeção de garantia da qualidade (2 h de trabalho); º Recuro computacional neceário: ambiente Delphi; º Código-fonte da clae referente ao aceo ao dado º 5 dia para concluão (20 h de trabalho); º Alvo de inpeção de garantia da qualidade (2 h de trabalho); º Recuro computacional neceário: ambiente Delphi e banco de dado MySQL; º Código-fonte referente à lógica de apreentação do oftware e interface relacionada º 8 dia para concluão (30 h de trabalho); º Alvo de inpeção de garantia da qualidade (2 h de trabalho); º Recuro computacional neceário: ambiente Delphi. é!í ÌÔ Ï^Ê Í ÜÍÓÓ â!î ã ÏÔ Ø!Î ØeïVÏ0Ò Ü à ÝÓ Þ ÏÐ Ï 0ØÓÓ Ï º 18 dia ou 70 h de trabalho obtenção do MAS º 2 dia ou 6 h de trabalho inpeçõe para garantia da qualidade Tempo total reultante (etimado): 70 h + 6 h = ü ëóï0ýiòýð-ã ØÓ õ ÊVË!ÌÍ!Î ÏÐ!ÍÑ ÒÓ Ô Í ÕÖ!ÍÓ Inpeçõe de Acompanhamento e Supervião: 0 Inpeçõe de Garantia da Qualidade: 3 é Ï å Ø!à ã þø ÕÖ!ÍÓ Î Íø ã Ó Þ ÏÐ!Í#é!Í ÌÔ Ïé Ï å Ø!àØä Í!Î0ÿfØÓå Ïiæ ÍÓå ã ÌØå ã ø Ø è º Pao 1: Revitalização da Arquitetura: 34 h ou 9 dia º Pao 2: Contrução do MASA: 55,5 h ou 14 dia º Pao 3: Obtenção do MAS: 61,5 h ou 16 dia º Pao 4: Elaboração do Projeto Avante: 25,5 h ou 6 dia º Pao 5: Re-implementação do Software: 76 h ou 19 dia Tempo total reultante (etimado): Ù ë Ï-Î ØÓeÏ-Ý çð0ã ØÓ ð ñ ð Apó a aplicação do FOXVWHU 1, no qual foram realizado a preparação e o planejamento da reengenharia, teve inicio a engenharia revera, primeira etapa do PRE/OO. A eção eguinte ilutra como foram aplicado o padrõe do FOXVWHUV3 a 5, o quai compõem ea etapa. O FOXVWHU 2, referente à melhoria da qualidade da reengenharia é utilizado durante todo o proceo e portanto, não erá apreentado ioladamente. 5HDOL]DomRGD(WDSDGH(QJHQKDULD5HYHUVDGR35(22 &OXVWHU5HYLWDOL]DUD$UTXLWHWXUDGR6RIWZDUH/HJDGR

121 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 10 8 O primeiro pao da engenharia revera egundo o PRE/OO foi iniciado na data previta, 22/11/2001, com a aplicação do padrão 6, Elaborar Lita de Procedimento e Funçõe. Apó a elaboração e inpeção da Lita de Procedimento e Funçõe, foi iniciada a contrução da Lita "Chama/Chamado Por", com a aplicação do padrão 7, Elaborar Lita "Chama/Chamado Por", a partir da XQLWV CaixaDM.pa e Caixa.pa a quai pouem junta cerca de 500 linha de código e 16 procedimento. A Lita Chama/Chamado Por foi parcialmente elaborada durante a primeira volta no ciclo evolutivo, endo completada no decorrer da etapa de engenharia revera com a identificação, em outra XQLWV, do ponto de chamada do procedimento e funçõe identificada. (ODERUDU/LVWDGH3URFHGLPHQWRVH)XQo}HV 6ROXomR A viualização parcial da Lita de Procedimento e Funçõe compota a partir de um trecho do código-fonte legado é ilutrada na Figura e o documento correpondente à ua Inpeção de Garantia da Qualidade, no Quadro 4.4.1; O código-fonte apreentado à direita da Figura motra procedimento da XQLW Main.pa claificado como evento (Ev) e outro como privado (Pv). Verifica-e que, no exemplo, nenhum procedimento ou função foi declarado na eção SXEOLF da XQLW Main. Ea claificação foi realizada para o demai procedimento e funçõe do oftware ditribuído na 31 XQLWV retante, num total de 340 procedimento e funçõe documentado na verão 1.1 da Lita de Procedimento e Funçõe, obtida apó a inpeção; Como forma de facilitar ua poterior localização, um número eqüencial único foi atribuído a cada procedimento e função documentado na Lita de Procedimento e Funçõe, viualizado, na Figura 4.4.1, na coluna à equerda do nome de cada procedimento; A inpeção de garantia da qualidade da Lita de Procedimento e Funçõe foi realizada manualmente verificando e toda a XQLWVhaviam ido percorrida, e todo o nome de procedimento e funçõe haviam ido trancrito de forma correta e a claificação fornecida etava de acordo com a área da XQLW em que o procedimento ou função encontrava-e declarado.

122 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWR2EWLGR ã -Ý Î Ø:ç ç ò ïvï ÌÔ Ï Ó!ã ÕÞ ÏiÐ!ÍÔ Ø!Î å Í#Ð!Ø!ã Óå ØeÐ!Í Î Ï ÜÍ Ð0ã ÌÍ!Òå Ï ÓeÍ Ý Ò ÕÖ!ÍÓ Ý Ø Ð-Î Ïç ç ò Ï Ü Ý!ÌÍ Òå ÏiÐ!Íã ÒÓ Ô Í ÕÞ ÏÐ!Í!Ø!Î Ø!Òå ã ØeÐ!Ø-Ý Ø à ã Ð!ØÐ!ÍeÐ!Ø ã Óå Ø#Ð!Í Î Ï ÜÍ Ð0ã ÌÍ Òå Ï ÓeÍ Ý Ò ÕÖ!ÍÓ Î Ï Íå Ï ControleGlobal Ñ å Í Ì á]à ø ÏiÐ!ØÑ ÒÓ Ô Í ÕÞ ÏÐ!ÍeÿfØ!Î Ø!Òå ã ØeÐ!Ø Ý Ø à ã Ð!ØÐ!Í Lita de Procedimento e Funçõe Verão 1.0 Ñ ÒÓ Ô Í ÕÞ ÏÐ!ÍeÿfØ!Î Ø!Òå ã ØeÐ!Ø Ý Ø à ã Ð!ØÐ!ÍÊ 1 áó0ô Í Üå Ï ÓágÒ Ø!à ã Ó Ø Ð Ï Ó INSPEÇÃO DE GARANTIA DA QUALIDADE Øå ØeÐ!ÍeïgÎ ã Ø ÕÞ ÏÐ ÏÏ Ü Ý ÌÍ!Òå Ï 22/11/2001 Û ÍÓ Ô Ï-ÒÓ âø Í!à Ô Í à ØÑ ÒÓ Ô Í ÕÞ Ï Gizelle Lemo ú 1. Nome do módulo 2. Nome do procedimento e funçõe 3. Claificação da procedimento e funçõe 4. Comparação entre o número de procedimento e funçõe no código e na lita analiada Vã Í!Î Í!Ò ÕØÓiö Ò ÜÏ-Òå Î Ø Ð!ØÓ 1. Nome do módulo: OK 2. Nome da procedimento e funçõe º Nome do Procedimento 180 Ajuta Ø!à Orcamento º Nome do Procedimento 203 OrcTroca 0Ø!Í ManagerGetNextPage 3. Claificação da procedimento e funçõe º Claificação do Procedimento 5 Diplay Hint: Ev para Pv º Comparação entre o número de procedimento e funçõe no código e na lita analiada: OK ávõ Ö!ÍÓïVÏ-Î Î Íå ã ø ØÓ º Criação da Verão 1.1 da Lita de Procedimento e Funçõe com a correçõe neceária

123 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 0 (ODERUDU/LVWD&KDPD&KDPDGR3RU 6ROXomR A numeração eqüencial elaborada durante a aplicação do padrão 6 foi mantida na Lita "Chama/Chamado Por" como forma de facilitar o mapeamento, podendo er viualizada na coluna à equerda do nome e decrição do procedimento, na Figura 4.4.2; A compoição da Lita "Chama/Chamado Por" foi realizada em mai de uma etapa. Primeiro, foram documentada a decriçõe do procedimento e funçõe e a coluna &KDPD. A coluna &KDPDGR3RUde cada procedimento e função foi completada ao longo do proceo de revitalização da arquitetura; De forma a exemplificar ua compoição, o trecho de código fonte acima da Lita "Chama/Chamado Por" na Figura correponde à chamada ao procedimento PegaProximoIdx dentro do código-fonte do procedimento MovimentoCaixa TableAfterInert da XQLW CaixaDM.pa; O trecho de código-fonte abaixo da Lita "Chama/Chamado Por" ilutra o procedimento MovimentoCaixaAfterInert que não chama nenhum procedimento ou função; Na que correpondente à parte da Verão 1.0 da Lita "Chama/Chamado Por", a coluna &KDPDGR 3RU referente ao procedimento InerirValorNoCaixa encontra-e em branco, tendo ido preenchida apena na egunda etapa da revitalização da arquitetura (Quadro 4.4.2); O procedimento e funçõe referente à demai XQLWV do oftware legado foram claificado na Lita "Chama/Chamado Por" da mema forma anteriormente apreentada, endo criada verõe quando neceário conforme a modificaçõe e inerçõe de chamada exitente no código-fonte legado; Todo o controle de configuração foi realizado aplicando-e o padrão 5, Controlar a Configuração. Dea forma, foi iniciada a documentação da Lita de Controle de Configuração, como ilutra o Quadro 4.4.3, propiciando ao engenheiro de oftware o controle de alteraçõe da divera verõe neceária de cada produto de trabalho gerado; Ao final da elaboração da Lita "Chama/Chamado Por" foi realizada a inpeção de garantia da qualidade para melhoria da mema, com a aplicação do padrão 4, Realizar Inpeção de Garantia da Qualidade. Nea inpeção foram verificado, a partir da claificação de cada procedimento e função decrito (Ev, Pv ou Pb), a coluna Chama do procedimento ou função e, em eguida, a coluna Chamado Por;

124 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 1 Ao final da revitalização da arquitetura foi originada a primeira EDVHOLQH do projeto (Quadro 4.4.4), com o produto elaborado e inpecionado durante a condução do pao. A eguir, foi realizada a Inpeção de Acompanhamento do Proceo, com o objetivo de verificar e o Plano para Realização da Reengenharia etava endo cumprido de forma efetiva. O Quadro ilutra o documento criado apó a inpeção. 3URGXWR2EWLGR ã -Ý Î Ø:ç ç Ù ïvï ÌÔ Ï Ó!ã ÕÞ ÏiÐ!ÍÔ Ø!Î å Í#Ð!Ø!ã Óå Øhïgë Ø ÌØ ïgë Ø ÌØ Ð!Ï -Ï-Î

125 1 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 2 Ý Ø Ð-Î Ïç ç Ù 3URMHWR ControleGlobal ã Ó!Ý Ø!à ã þø ÕÞ ÏÔ Ø!Î Ü ã Ø àð!ø 0yGXOR CaixaDM.pa: reponável pelo proceamento da entrada e aída de valore no Caixa 9HUVmRGR'RFXPHQWR 1.1 Î Ï ÜÍ Ð-ã ÌÍ!Òå Ï Í!Î Ó Þ Ïò ò Ð!Ø ã Óå Øhïgë Ø ÌØ ïgë Ø ÌØ Ð Ï -Ï-Î LISTA "CHAMA/CHAMADO POR" 'DWDGH&ULDomRGR'RFXPHQWR 28/11/2001 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Gizelle Lemo CaixaTableAfterInert Inicializa um regitro de caixa para inerção na tabela. 69 ïgë Ø ÌØ ïgë Ø ÌØ Ð Ï 0Ï-Î Î Ï ÜÍ Ð-ã ÌÍ!Òå Ï InerirValorNoCaixa Inere novo regitro de movimentação no caixa. ïgë Ø ÌØ ïgë Ø ÌØ Ð Ï 0Ï-Î Movimenta (74) PegaProximoIdx (164) IdxDataModule.pa Î Ï ÜÍ Ð-ã ÌÍ!Òå Ï MovimentoCaixaTableAfterEdit Atualiza valor no caixa. 76 ïgë Ø ÌØ ïgë Ø ÌØ Ð Ï 0Ï-Î CredBtnConfPgClick (112) Crediario.pa ExcluirPagtoCaixa (118) Crediario.pa ProceaTrocaDifAv (207) OrcTroca.pa ProceaTrocaDifUnica (208) OrcTroca.pa ProceaTrocaDif2X (209) OrcTroca.pa ProceaTrocaAltP (210) OrcTroca.pa InerirEntradaNoCaixa (232) OrcVenda.pa ProceaVendaAv (256) OrcVenda.pa ExcluirPagtoCaixa (323) RelVenda.pa Ý Ø Ð-Î Ïç ç ó ã Óå Ø#Ð!ÍeïVÏ-Òå Î Ï0à ÍeÐ ÍeïVÏ-Òú ã -Ý Î Ø ÕÞ ÏÎ Íú Í!Î Í!Òå Í#Ø ÏÔ ØÓÓ ÏÐ!ÍÛ Íø ã å Ø!à ã þø ÕÞ ÏiÐ!Øá]Î-Ý ã å Íå Ý Î Ø LISTA DE CONTROLE DE CONFIGURAÇÃO 3URMHWR ControleGlobal 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR Gizelle Lemo & % + 3DVVRGR35(22 Revitalização da Arquitetura ª"! #$ % % '^ ( % )% '^ *- ª $ %,Vª"! -.' 22/11/2001 Lita de Procedimento e Funçõe 1.0 Revitalização da Arquitetura 22/11/2001 Lita de Procedimento e Funçõe 1.1 Inpeção de Garantia da Qualidade: Nº 1 23/11/2001 Lita "Chama/Chamado Por" 1.0 Revitalização da Arquitetura 28/11/2001 Lita "Chama/Chamado Por" 1.1 Revitalização da Arquitetura 03/12/2001 Lita "Chama/Chamado Por" 1.2 Inpeção de Garantia da Qualidade: Nº 2 Ý Ø Ð-Î Ïç ç ç/ Î ã ÌÍ ã Î Ø0!! *- ÍÓå Ø!ê Í!à Í Ü ã Ð!ØeÐ-Ý!Î Ø!Òå Í#ØÎ ÍØ à ã þø ÕÞ ÏÐ ÏÍÓå Ý Ð ÏÐ!ÍeÜØÓ Ï %$6(/,1( DE PROJETO 3URMHWR ControleGlobal 'DWDGH&ULDomRGD%DVHOLQH 03/12/2001 3DVVRGR35(22 Revitalização ÍÓ Ü Î ã ÕÞ Ï da Arquitetura 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR Gizelle Lemo À ¾Å î ¾ 1, contendo o conjunto do iten de configuração aprovado apó a inpeçõe de garantia da qualidade, o quai decrevem a revitalização da arquitetura do oftware legado. Ñ å Í!ÒÓÐ!Í#ïVÏ-Òú ã 0Ý Î Ø ÕÞ Ï Í!Î Ó Þ Ï Øå ØeÐ!ÍeïgÎ ã Ø ÕÞ Ï Lita de Procedimento e Funçõe /11/2001 Lita "Chama/Chamado Por" /12/2001

126 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 3 Ý Ø Ð-Î Ïç ç ð 3URMHWR ControleGlobal Ï Ü Ý!ÌÍ Òå ÏiÐ!ÍÑ ÒÓ Ô Í ÕÞ ÏÐ!Í#áGÜÏ0ÌÔ Ø!Ò ë Ø ÌÍ!Òå ÏÐ Ï Î Ï ÜÍÓÓ Ï INSPEÇÃO DE ACOMPANHAMENTO DO PROCESSO 'DWDGD&ULDomRGR'RFXPHQWR 03/12/2001 3DVVRGR35(22 Revitalização da Arquitetura 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Gizelle Lemo,QVSHomRGH$FRPSDQKDPHQWR1ž1 Ñ å Í!ÒÓeá]Ò Ø!à ã Ó Ø Ð Ï Ó å 1. Produto de Trabalho Elaborado 2. Tempo Gato na Elaboração do Produto de Trabalho 3. Inpeçõe de Garantia da Qualidade Realizada 4. Tempo Gato para Concluão do Pao Û ÍÓ Ý à Ø Ð Ï Óô êå ã Ð Ï Ó 1. Todo o produto de trabalho que compõem a revitalização da arquitetura foram gerado 2. O tempo gato para a elaboração do produto de trabalho condiz com o etimado no Plano 3. Foram realizada toda a inpeçõe de garantia da qualidade neceária 4. O tempo gato na inpeçõe de garantia da qualidade condiz com o etimado no Plano ávõ Ö!ÍÓïVÏ-Î Î Íå ã ø ØÓ - &OXVWHU(ODERUDU0RGHORGH$QiOLVHGR6LVWHPD$WXDO O egundo pao do PRE/OO, conduzido a partir da aplicação do padrõe do FOXVWHU 4, trata da contrução do Modelo de Análie do Sitema Atual (MASA) e foi realizado apó a concluão da Lita Chama/Chamado por com o objetivo de prover uma vião peudo-orientada a objeto do oftware legado. 0RGHODU'DGRVGR6RIWZDUH/HJDGR 6ROXomR A aplicação dee padrão baeou-e no arquivo de dado contendo o VFULSWV SQL da etrutura da tabela de dado utilizada pelo oftware; Apó a análie da cláuula contida em cada um dee arquivo, foi contruída a Lita de Tabela e Chave, como ilutra a Figura Nela, viualiza-e, no primeiro quadro, o arquivo de dado com o VFULSWSQL referente à tabela de dado "Caixa". A partir dee arquivo, foram extraído o nome, o atributo e a chave primária da tabela de dado. O procedimento foi adotado para o VFULSWSQL com a informaçõe referente à tabela de dado "MovimentoCaixa"; A compoição dea lita foi realizada em dua etapa: Obteve-e, a partir de cada arquivo, o nome, atributo e chave() primária() da tabela de dado e montou-e, repectivamente, a coluna Tabela de Dado, Campo de Dado e Chave Primária da Lita de Tabela e Chave; Percorreu-e a coluna Campo de Dado para cada tabela documentada de forma a verificar e algum de eu atributo coincidia com a chave-primária de

127 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 4 outra tabela. Em cao afirmativo, ee atributo foi trancrito para a coluna Chave Etrangeira; Com bae na Lita de Tabela e Chave foi elaborado o Modelo Entidade- Relacionamento para o etudo de cao. Cada tabela de dado originou uma entidade e toda a ocorrência de chave etrangeira originaram relacionamento no MER, como motra a Figura Apó a compoição do MER, foram aplicado o padrõe 4 e 5, Realizar Inpeção para Garantia da Qualidade e Controlar a Configuração, de forma a controlar a qualidade do proceo de reengenharia; A cardinalidade do MER foram obtida atravé da análie, por parte do engenheiro de oftware, do oftware legado e de ua execução. O tipo de relacionamento entre a entidade foram obtido atravé do exame da interface, obervando-e o contexto do relacionamento. 3URGXWRV2EWLGRV ã -Ý Î Ø:ç ç ó ïvï ÌÔ Ï Ó!ã ÕÞ ÏiÐ!Ø!ã Óå ØeÐ!Í#é!Ø!ê Í!à ØÓ#Íeïgë Øø ÍÓ

128 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 5 ã -Ý Î Ø:ç ç ç2 ßÏ!Ð!Í!à Ïö+Òå ã Ð!Ø Ð!Í ù Û Í!à Ø Ü ã Ï-Ò Ø ÌÍ!Òå ÏÐ ÏÍÓå Ý Ð ÏÐ!ÍeÜØÓ Ï &ULDU/LVWDGH$QRPDOLDV 6ROXomR A aplicação do padrão 9, deu origem à Lita de Anomalia, que tem por objetivo mapear o aceo à tabela de dado realizado no procedimento e funçõe decrito na Lita de Procedimento e Funçõe, anteriormente criada. A Figura ilutra ua compoição, em que e pode notar que o procedimento

129 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 6 MovimentoCaixaTableAfterInert modifica o valor de um regitro da tabela de dado "MovimentoCaixa" e, por ee motivo, é claificado como (c). Além dio, pode-e verificar o procedimento MovimentoCaixaTabelaAfterPot que oberva o conteúdo da tabela de dado "Caixa" e "Movimento Caixa", endo claificado como (o+); Apó a claificação de toda a anomalia relativa ao aceo a dado do procedimento e funçõe legado, foram realizada a inpeção para garantia da qualidade e o controle de configuração neceário (aplicação do padrõe 4 e 5). Na inpeção foram obervado, para cada procedimento e função, e o número e o critério de aceo à etrutura de dado etavam correto. Outro item obervado foi a claificação reultante da combinação do divero aceo à etrutura de dado. 3URGXWR2EWLGR ã -Ý Î Ø:ç ç ð ïvï ÌÔ Ï Ó!ã ÕÞ ÏiÐ!Ø!ã Óå ØeÐ!Í#á]Ò Ï0ÌØ!à ã ØÓ

130 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 7 A eguir, foi aplicado o padrão 10, Criar Vião OO do Dado. Para io, foram utilizado o produto obtido com a aplicação do padrõe anteriore dee FOXVWHU (padrõe 8 e 9). &ULDU9LVmR22GRV'DGRV 6ROXomR O objetivo da aplicação dee padrão é obter uma primeira vião orientada a objeto do oftware procedimental, com a criação do Diagrama de Peudo- Clae. A partir do MER e da Lita de Tabela e Chave, foram criada a peudo-clae e eu atributo, como ilutra o detaque Dda Figura O "método" de cada peudo-clae foram originado a partir da Lita de Anomalia, como ilutra o detaque Eda Figura 4.4.7; Nota-e, no detaque E da Figura 4.4.7, que vário "método" ão comun a mai de uma peudo-clae. Io acontece porque ele têm operaçõe de modificação e/ou obervação à peudo-clae envolvida, ou eja, ão anômalo. O "método" que ó ocorrem em uma peudo-clae apena conultando ou modificando eu dado, não pouem anomalia; O relacionamento entre a peudo-clae foram obtido a partir do exame do relacionamento entre a entidade do MER, endo ilutrado no Diagrama de Peudo-Clae (Figura 4.4.6). A ecolha do tipo de relacionamento (aociação, agregação ou herança) foi realizada com bae no contexto em que cada peudoclae etava inerida. Por exemplo, a entidade "Produto", "Etoque" e "Cor", aociam-e pelo relacionamento "TEM", indicando que "Etoque" ID] SDUWH de "Produto" e "Cor" ID] SDUWH de "Etoque", ugerindo doi relacionamento por agregação 2 ; A verificação e a agregação acontece por valor ou por referência foi feita analiando a ocorrência de dependência direta da peudo-clae à outra a quem etá agregada. No cao da peudo-clae "Cor", viualizada na Figura 4.4.6, não há dependência direta de "Etoque", poi o regitro de cada cor permanece gravado memo em haver etoque cadatrado, indicando uma agregação por referência. Já, o regitro de etoque depende diretamente de haver produto cadatrado, indicando uma agregação por valor; 2 Maiore informaçõe obre tipo de relacionamento entre clae podem er encontrada em (LIBERTY, 1998).

131 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 8 A aociaçõe refletem relacionamento imple entre dua clae de memo nível. Durante a condução do etudo de cao, apó a claificação da agregaçõe, o demai relacionamento foram claificado como aociaçõe. 3URGXWRV2EWLGRV 0..* Comiao 6 4"@ 6 4:@ 0..* Credito 1 Empreg 1 5 4:;9= C B ; :;9= C B ; 1 0..* 1 A ;"B :78:4 ; Grupo 6 4:@ 1 1..* Produto "798:4 ; "@ Orcam 6 4"@ 1..* 1..* ProdOrcam 0..* Etoque 0..* Venda 0..* Troca 6 4"@ 0..1 ProdutoTroca 0..* * * 1..* 6 4:@ D"5 C E:C 7"; "798:4 ; Cor Cliente D95 C E"C 7:; 0..* 0..* A ;9B 6 4"@ 6 5 ;9<";"= >";? v iv e, naceu Crediario 0..1 D95 C E"C 7:; 1..* 0..1 ProdutoVenda 1 Cidade Caixa 1 6 4:@ D95 C E:C 7"; ã -Ý Î Ø:ç ç õ * MovimentoCaixa 0..1 D95 C E:C 7:; á]ô Î ÍÓ Í!Òå Ø ÕÞ ÏiÐ Ï ÓiÎ Í!à Ø Ü ã Ï0Ò Ø ÌÍ!Òå Ï ÓÒ ÏVã Ø -Î Ø ÌØ#Ð!Í Ó Í!Ý Ð Ï ù ïgà ØÓÓ ÍÓ

132 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 11 9 F G H2I J KML N L N O PQR ST R U G VWRYX KÜ TUZ I X R [ \ ] KUUZU Apó a finalização do Diagrama de Peudo-Clae foi feita a inpeção para a garantia da qualidade (padrão 4). Na inpeção foram verificado o eguinte apecto: a ditribuição do método na divera peudo-clae, a repreentatividade e a cardinalidade e o tipo do relacionamento. Não foram contatada nãoconformidade durante a inpeção, por ee motivo iniciou-e a aplicação do padrão 11, Criar Diagrama de 8VH &DVHV do MASA, com a elaboração do Diagrama de 8VH &DVHV do MASA. &ULDU'LDJUDPDVGH8VH&DVHVGR0$6$ 6ROXomR A bae para a compoição do Diagrama de 8VH &DVHV foram a interface exitente e o código-fonte do oftware legado. Aim, cada interface do oftware legado gerou um ou mai XVHFDVHV. Um do Diagrama de 8VH&DVHVgerado é ilutrado pela Figura 4.4.8, no qual percebe-e o detaque no XVH FDVH CredBtnPgClick; O nome do XVHFDVHVforam mantido de acordo com a implementação, endo modificado apena no MAS, fato confirmado a partir da Figura 4.4.9, em que viualiza-e o FOLFNno botão CredBtnPg originando o XVHFDVHCredBtnPgClick.

133 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWRV2EWLGRV CredBtnPgClick _:n f p a o"uf"i ^._:`:a bc_/^.d e:`:a f:d a _.g Cliente / Parcela OrcTrocaBtnPgAv h f"i _:d ~d "fkq2ekw:n _ SolicitarOrcamentoTroca l.d _:`m"n _:o h f:i _"dkj)l.fbfkd li f:w_o x.a oyc_:wz {e9a o l.d _"`m"n _:o li fkw_ ~d "fkq2ekw:n _ SolicitarOrcamentoVenda Cliente W izbtnconfirmavendaclick p _:d q2fko x a oy}_w:a { e:a o p _:d qrf h f"i _:d p _:d qrf:olf:bkn _ p _"d qrf lf:bn _ tou:_9i v:a `kf _:n f p a o"uf"i OrcamBtnConfFPgClick OrcTrocaBtnFPagtoClick OrcamBtnConfPgAvClic F G H2I J KML N L N P G U IK ] G ƒkvwr TK J\G kk ]X R G KH2J KS KX Z 2 ˆ rš ˆ. YTK J KR K R2J/QŒ] G Z Z F G H2I J KML N L N Ž P MJ"G H Z S X R ˆ Š ˆ( r /š œ žÿ Terminada a elaboração do Diagrama de 8VH &DVHV foram feita ua repectiva decriçõe. 'HVFUHYHU8VH&DVHVGR0$6$ 6ROXomR A aplicação dee padrão baeou-e no ecopo do oftware, na interface diponívei e na execução do oftware legado. Vale alientar que outra fonte de informação podem er utilizada para compor tai decriçõe como, por exemplo,

134 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 1 entrevita com uuário, cao haja ea poibilidade. A decrição do XVHFDVH CredBtnPgClick, referenciado pela Figura 4.4.8, conta da Figura Ea decrição foi compota a partir da execução do oftware legado e da viualização do código-fonte. Nela, pode er viualizada a origem do curo alternativo, executado quando entra-e com um número de crediário não cadatrado no itema; A inpeçõe de garantia da qualidade para o diagrama e decriçõe gerado, foram efetuada, aplicando-e o padrão 4. Nela, obervou-e e todo o curo alternativo haviam ido documentado e e o final de cada decrição de XVH FDVHcorrepondia à realizada; Ao fim do MASA foi realizada a inpeção de acompanhamento de proceo, aplicando-e o padrão 3. Na inpeção de acompanhamento foi detectado um pequeno atrao em relação ao tempo etimado para a concluão do MASA. Porém, ee atrao não excedeu o tempo diponível para a reengenharia (70 dia), o que dipenou a tomada de açõe corretiva. No cao da ocorrência de devio coniderávei, o engenheiro de oftware reponável pelo planejamento do proceo deve optar por reditribuir a atividade em aumentar o tempo retante para o proceo ou redimenionar o prazo limite para o final do projeto, conforme o atrao ocorrido e mover toda a atividade retante de acordo com ee atrao. O regitro da inpeção de acompanhamento do proceo encontrae ilutrado no Quadro 4.4.6; Apó a realização da inpeção de acompanhamento de projeto para a contrução do MASA, foi etabelecida a egunda EDVHOLQH, com a aplicação do padrão 5. A EDVHOLQH encontra-e ilutrada no Quadro URGXWR2EWLGR F G H2I J KML N L N P ZU \ J"G VWR X R ˆ Š ˆ r /š œ žÿ

135 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 2 IKX2JR L N L N P U TZVWR X Z(K\R/STK KS Z R X Z T J R \ZUU R J ZK ] G ƒkx KK T U R J9SYG R X RY Mª «ª INSPEÇÃO DE ACOMPANHAMENTO DO PROCESSO 3URMHWR ControleGlobal 3DVVRGR35(22 Contrução do MASA 'DWDGD&ULDomRGR'RFXPHQWR 27/12/2001 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Gizelle Lemo,QVSHomRGH$FRPSDQKDPHQWR1ž2 Z Uª) K ] G UKX R U 1. Produto de Trabalho Elaborado 2. Tempo Gato na Elaboração do Produto de Trabalho 3. Inpeçõe de Garantia da Qualidade Realizada 4. Tempo Gato para Concluão do Pao ZU I ] KX R U "G X R U 1. Todo o produto de trabalho que compõem a contrução do MASA foram gerado 2. O tempo gato para a elaboração do produto de trabalho etá ligeiramente em atrao em relação ao tempo etimado no Plano (1 dia de atrao ao final do MASA) 3. Foram realizada toda a inpeçõe de garantia da qualidade neceária 4. O tempo gato na inpeçõe de garantia da qualidade condiz com o etimado no Plano ªV ZU QR2J"J Z "G ±KU Item 2 Na inpeção de acompanhamento foi detectado um pequeno atrao em relação ao tempo etimado para a concluão do pao. Porém, o atrao não excede o tempo diponível para o proceo de reengenharia (70 dia). Ação neceária: correção do Plano e lançamento de nova verão. IKX2JR L N L N O P«ZH2I X K(² Š ˆ³ µ2ˆ(x R ZU "I X R X Z\KU R %$6(/,1( DE PROJETO 3URMHWR ControleGlobal 'DWDGH&ULDomRGD%DVHOLQH 27/12/2001 3DVVRGR35(22 Contrução ZU \ J"G VWR do MASA 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR Gizelle Lemo ¹º ¼¹ 2 conjunto do iten de configuração aprovado apó a inpeçõe de garantia da qualidade e que decrevem o modelo de análie do itema atual do oftware legado. Z U X ZQR2 ½"G H/I J KVWR Z J UWR K KX ZQŒJ"G KVWR ¾ ¾ Lita de Tabela e Chave /12/2001 Modelo Entidade-Relacionamento /12/2001 Lita de Anomalia /12/2001 Diagrama de Peudo-Clae ¹ ¹ /12/2001 Diagrama de ¹ ¹ do MASA /12/2001 Decriçõe do do MASA /12/2001 A eção eguinte aborda a abtração do Modelo de Análie do Sitema Atual, a partir do produto obtido com a aplicação do padrõe do FOXVWHUV 2 e 3, para a obtenção do Modelo de Análie do Sitema (MAS). &OXVWHU(ODERUDUR0RGHORGH$QiOLVHGR6LVWHPD $EVWUDLU'LDJUDPDGH3VHXGR&ODVVHV 6ROXomR O terceiro pao do PRE/OO, a obtenção do Modelo de Análie do Sitema (MAS), iniciado com a aplicação do padrão 13, analiou o contexto e o nome de toda a peudo-clae do Diagrama de Peudo-Clae (Figura 4.4.6), de forma a verificar a repreentatividade de cada uma com relação ao contexto

136 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 3 oftware. Dea forma, a peudo-clae "Caixa" foi eliminada por conter apena a omatória do regitro da peudo-clae "MovimentoCaixa". A demai peudo-clae tiveram eu nome melhorado; O atributo da peudo-clae também foram verificado. Toda a modificaçõe realizada foram documentada na Lita de Mapeamento MASA x MAS, parcialmente viualizada pela Figura , em que nota-e a excluão da peudo-clae "Caixa" do modelo que incorpora o conceito de orientação a objeto. Já, a peudo-clae "Cliente" foi ubtituída pela clae "Cliente" no MAS e teve o nome de cinco de eu atributo ubtituído. A clae "Troca", do MAS, poui doi atributo a meno que a peudo-clae "Troca" que a originou, pelo fato de ter-e notado que ete não etavam endo utilizado pelo oftware; A partir da Lita de Anomalia foram verificado o procedimento e funçõe com claificação (o) e (c). Ee procedimento e funçõ, condireado não anômalo, tiveram ua funcionalidade analiada, no entido de verificar e eta não poderia er ditribuída em mai de um método. Apó a análie, cada método foi aociado à clae que obervava ou modificava. A Figura motra o exemplo do procedimento SavePoition que oberva a peudo-clae Cliente e foi convertido no método ObterCodCliente e SalvarPoicaoTabela como forma de aumentar o reuo, já que apreenta dua funcionalidade ditinta; Dada a forma de implementação do oftware utilizado no etudo de cao, algun procedimento de abertura e fechamento do componente de aceo à tabela de dado não tiveram mai utilidade pelo fato dee componente não erem mai utilizado na re-implementação do oftware. Nee cao, ee procedimento foram eliminado ou tiveram ua claificação modificada; O detaque D da Figura ilutra o exemplo de um procedimento que foi eliminado por conter apena a abertura do componente de aceo ao dado da tabela Cidade. O detaque E da Figura refere-e ao procedimento que fecha o componente de aceo ao dado da tabela Cidade e libera a memória alocada pela interface (IRUP) de Cidade. Ee procedimento foi mantido, porém com a claificação (i), referindo-e omente à forma de implementação utilizada, pelo fato de ter ido eliminada a parte do código-fonte de fechamento do componente Cidade; A última etapa de abtração do Diagrama de Peudo-Clae é a divião do procedimento e funçõe anômalo, de forma a eliminar ua anomalia e tranformá-lo em método. Eta divião foi conduzida no etudo de cao,

137 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 4 analiando-e a funcionalidade de cada procedimento e função. No cao da funcionalidade preente (ou parte dela) já haver ido documentada na forma de método (durante a aociação do método em anomalia), ee foi aproveitado apena endo novamente referenciado. Por exemplo, cao algum método anômalo tivee que obter o código do cliente como parte de ua funcionalidade, não preciaria er novamente definido, podendo utilizar o método ObterCodCliente, anteriormente definido. Cao contrário, um novo método foi criado para prover a funcionalidade; A Figura ilutra a compoição da Lita de Correpondência de Método Anômalo e, abaixo, o código-fonte referente ao procedimento anômalo Inerir Crediario dividido no método AtualizarDataUltimaCompra (clae "Cliente") e Create (clae "Crediario"). Verifica-e, ainda, que procedimento de abertura e fechamento de componente de aceo direto à tabela de dado foram eliminado de divero módulo do oftware. Outro fato que pode er notado foi que algun método puderam er reutilizado, como o método ObterCodCliente da clae "Cliente; A eguir, foi elaborado o Diagrama de Clae referente ao Modelo de Análie do Sitema (MAS). O relacionamento entre a peudo-clae do MASA foram analiado em função de ua repreentatividade com relação ao domínio da aplicação e quanto a poibilidade de haver melhor exploração do conceito diponívei na orientação a objeto, como a herança e o OLQNDWULEXWR A Figura ilutra o relacionamento entre a clae do MAS. Vária modificaçõe foram realizada em relação à Figura 4.4.6, que apreenta o relacionamento entre a peudo-clae. Um exemplo é a incluão do relacionamento de herança entre a clae "Orcamento" e "Venda"/"Troca", que não exitem no Diagrama de Peudo-Clae, io ocorreu pelo fato de repreentarem melhor dea forma o contexto em que etão inerida no oftware. A clae "Cliente" paou a aociar-e diretamente à clae "Venda" e "Troca", fato que não ocorria no MASA e que também pode er comprovado analiando-e o ecopo do oftware, pelo fato do cliente er reponável pela realização da operaçõe de venda e troca.

138 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWRV2EWLGRV F G H2I J KML N L N P G U IK ] G ƒkvwrtk J\ G K ]X K(±Z J UWRN (X K À G U KX Z MK TZKS Z RY Mª «ªÂÁY Mª «F G H2I J KML N L Nà P Ä ÁZST ] R X Z I SÅT JR \ZX/G S Z R UZS K R/S K ] G KUÆ2IZ(½R/G\R2 ±Z J "G X R ZSÇX R2G U S R X R U

139 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 6 F G H2I J KML N L NÈ P Ä ÁZST ] R X Z T J R \ZX2G S Z R UUZSÉK R S K ] G KU Æ2IZ WR½R2J KSÇ\R/ ±Z J "G X R UZ SÇS R X R U F G H2I J KML N L NL2P G KH2J KS KX ZQŒ] KUUZUK T UK(K U "J KVWRYX R Mª «ª

140 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 7 F G H2I J KML N L NÊ PQR ST R U G VWRYX K À G U KX ZQR2J"J ZU T R2 X Ë \ G KX Z M R X R Uª) Ì/S K ] R U Continuando a elaboração do Modelo de Análie do Sitema, o próximo padrão aplicado foi Criar Diagrama de 8VH&DVHdo MAS. &ULDU'LDJUDPDVGH8VH&DVHVGR0$6 6ROXomR A partir do Diagrama de 8VH&DVHVdo MASA e do Diagrama de Clae, o XVH FDVHV foram abtraído, originando o Diagrama de 8VH &DVHV do MAS. Algun XVH FDVHV tiveram eu nome atualizado, acompanhando a

141 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 8 modificaçõe realizada no Diagrama de Clae. O XVH FDVH CaixaBtnFechaClick, foi tranformado para FecharCaixaDiario, nome do evento que chama o método da clae neceária de forma a prover o pagamento de uma parcela de crediário, quando olicitado por um cliente, como er vito na linha marcada por D do Quadro 4.4.8; A Figura ilutra o XVH FDVH InerirCor reponável pela inerção de uma nova cor na tabela de dado de core. Ee XVHFDVHé tratado, no MASA, por um componente de aceo direto à tabela de dado "Cor". No MAS, o XVH FDVH paou a er tratado pelo evento InerirCor, o qual acea o método "Create" da clae "Cor"; Todo o XVH FDVHV abtraído do MASA foram inerido na Lita de Mapeamento do 8VH &DVHV, de forma a regitrar a modificaçõe realizada para o MAS. O Quadro ilutra parcialmente a lita elaborada para o etudo de cao. O detaque Eilutra a documentação do XVHFDVHInerirCor. 3URGXWRV2EWLGRV F G H2I J KML N L N P 2 ˆ Š ˆ Í rî Ï ÅX RY Mª «IKX2JR L N L N P )G U IK ] G ƒkvwrtk J\ G K ]X K À G U KX ZS K TZKS Z R X ZY 2 ˆ rš ˆ. LISTA DE MAPEAMENTO DE 86(&$6(6 3URMHWR ControleGlobal 'DWDGH&ULDomRGR'RFXPHQWR 14/01/2002 Ð KÑ Ð Ñ 9HUVmRGR'RFXPHQWR 1.0 5HVSRQViYHOSHOD&ULDomRGR'RFXPHQWR Gizelle Lemo 0$6$ 0$6 8VH&DVH 8VH&DVH &ODVVLI &ODVVH AbrirCaixa AbrirCaixa Evento - BucaBtnLocateClick Localizar Método Cliente CaixaBtnFechaClick FecharCaixaDiario Evento CredBtnPgClick PagarCrediario Método CrediarioVenda/Troca InerirCor InerirCor Evento

142 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 12 9 'HVFUHYHU8VH&DVHVGR0$6 6ROXomR Ee padrão foi aplicado de forma a completar o Modelo de Análie do Software, finalizando a engenharia revera, primeira etapa do PRE/OO. A decriçõe do XVHFDVHV elaborada no MASA foram analiada e, cao neceário, modificada para refletir a alteraçõe realizada no MAS. O XVHFDVHV do MASA tratado por componente de aceo direto ao dado tiveram ua decriçõe elaborada. A Figura ilutra a decrição realizada para o XVHFDVHInerirCor. Ao final da obtenção do Modelo de Análie do Sitema, foi realizada a inpeção de acompanhamento do proceo de reengenharia (Quadro 4.4.9) e, em eguida, lançada a terceira EDVHOLQH do etudo de cao (Quadro ), compota pelo produto gerado e inpecionado nee pao. 3URGXWR2EWLGR F G H2I J KML N L NO P G U IK ] G ƒkvwr X KX ZU \ J"G VWR X R ˆ Š ˆÍ rî Ï IKX2JR L N L N Ž P R \ I S Z R J Z ] K "G ± R ÒM Z J\Z G J K G U TZVWR X Z(K\R/SYTK KS Z R X RT JR \ZUU R 3URMHWR ControleGlobal INSPEÇÃO DE ACOMPANHAMENTO DE PROCESSO 'DWDGH&ULDomRGR'RFXPHQWR 18/01/2002 3DVVRGR35(22 Obtenção do MAS,QVSHomRGH$FRPSDQKDPHQWR1ž03 Z Uª) K ] G UKX R U 5HVSRQViYHOSHOD,QVSHomRGH $FRPSDQKDPHQWR Gizelle Lemo Etimativa de tempo etabelecida para o terceiro pao do PRE/OO Obtenção do MAS. Produto de Trabalho a Serem Elaborado: º Diagrama de Clae, Lita de Mapeamento MASA x MAS e Lita de Correpondência de Método Anômalo, ¹ ¹ ¹ ¹ ¹ ¹ º Diagrama de ¾, Decriçõe de ¾ e Lita de Mapeamento de ¾. ZU I ] KX R U "G X R U Foi recuperado o atrao relacionado ao pao anterior, contrução do MASA, de forma que o cronograma etá endo mantido conforme documentado no Plano. Todo o produto de trabalho foram elaborado e inpecionado. ªV ZU QR2J"J Z "G ±KUYÓ Z\ZUUÔ J"G KU -

143 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 13 0 IKX2JR L N L N PÕ Z J\Z G J KÖŠ ˆ³ µ2ˆmx Z JRØ Z R %$6(/,1( DE PROJETO 3URMHWR ControleGlobal 'DWDGH&ULDomRGD%DVHOLQH 22/01/2002 3DVVRGR35(22 5HVSRQViYHOSHOR&RQWUROHGH&RQILJXUDomR Obtenção do MAS Gizelle Lemo ZU \ J"G VWR ¹º» ¼¹ 3, contendo o conjunto do iten de configuração aprovado apó a inpeçõe de garantia da qualidade, o quai decrevem o modelo de análie do itema. Z U X ZQR2 ½"G H/I J KVWR Z J UWR K KX ZQŒJ"G KVWR ¾ ¾ ¾ Diagrama de Clae /01/2002 Lita de Mapeamento MASA x MAS /01/2002 Lita de Correpondência ¹ ¹ de Método Anômalo /01/2002 Diagrama de ¹ ¹ /01/2002 Decriçõe de ¹ ¹ /01/2002 Lita de Mapeamento de /01/2002 5HDOL]DomRGD(WDSDGH(QJHQKDULD$YDQWHGR35(22 &OXVWHU(ODERUDUR3URMHWR$YDQWH (ODERUDU'LDJUDPDGH&ODVVHVGH3URMHWR 6ROXomR Iniciando a engenharia avante, egunda etapa do PRE/OO, ee padrão foi aplicado como forma de diminuir o nível de abtração do Diagrama de Clae gerado no MAS e auxiliar na futura implementação orientada a objeto do oftware; Cada uma da clae preente no Diagrama de Clae foi analiada de forma a eparar o método que tratam a lógica de negócio da lógica de armazenamento do oftware. Apó a análie houve a derivação da clae de forma que o método que tratavam o dado foram movido da uper-clae para a ub-clae. O atributo originai foram mantido na uper-clae; Ea forma de projeto, em que a lógica de negócio, armazenamento e apreentação ão eparada, como ilutrado parcialmente pela Figura 4.5.1, provê uma maior organização e entendimento do oftware. A clae "DBCor" contém o método de aceo à tabela de dado de core, enquanto que a clae "Cor" provê a lógica de negócio pertinente à core no contexto do oftware; Finalizado o Diagrama de Clae de Projeto, ete paou pela inpeção para garantia da qualidade, em que foram reviada toda a derivaçõe elaborada e o método de cada clae.

144 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWR2EWLGR Ù Ú Û2Ü Ý ÞMß à áà â ãäú å ÜÞ æ Ú çþèéê ëþ ÝìÚ Þ æí êîú ÞÛ2Ý Þï Þí ðñœæ Þååðå í ð ò Ýêó ðôê &RQVWUXLU'LDJUDPDVGH6HT rqfld 6ROXomR Utilizando como bae o XVHFDVHV definido durante a engenharia revera e o método preente na clae obtida com a aplicação do padrão anterior iniciou-e a contrução do Diagrama de Seqüência. Um exemplo pode er viualizado na Figura 4.5.2, que motra o Diagrama de Seqüência relacionado ao XVH FDVH InerirCor. No diagrama nota-e o uo do método da clae "Cor" e "DBCor". Para io, foram utilizada a decrição do XVH FDVH, compota com a aplicação do padrão 15, a qual contém a decrição da operaçõe e o Diagrama de Clae de Projeto, que contém o método de cada clae; Apó a elaboração do Diagrama de Seqüência, foram aplicado o padrõe do FOXVWHU 2, de forma a garantir a qualidade do produto gerado e verificar a realização da etimativa documentada no Plano para Realização da Reengenharia. A inpeção para garantia da qualidade verificou e todo o ue cae tiveram eu repectivo Diagrama de Seqüência elaborado e e a eqüência da operaçõe foi corretamente decrita. A inpeção de acompanhamento de projeto verificou a etimativa documentada no Plano para Realização da Reengenharia e notou um atrao de doi dia (8 hora) com relação ao término do projeto avante, ee atrao foi repaado para a atividade futura. Foi lançada a quarta EDVHOLQH do projeto, com a verõe etávei do Diagrama de Clae de Projeto e do Diagrama de Seqüência.

145 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWR2EWLGR Ù Ú Û2Ü Ý ÞMß à áà õ ã îú ÞÛ2Ý Þï Þí ð(ö ð 2øù ú ì Ú Þí ê ˆ( Š ˆ Í rî Ï &OXVWHU5HLPSOHPHQWDUR6RIWZDUH,PSOHPHQWDUDV&ODVVHV 6ROXomR A re-implementação do oftware foi iniciada com a aplicação do padrão 18, Implementar a Clae, o qual baeia-e diretamente na clae referente à lógica de negócio do oftware decrita no Diagrama de Clae de Projeto elaborado durante o projeto avante do oftware; Cada uma da clae foi implementada e inpecionada, de forma a não conter erro de implementação, o quai poderiam afetar o deempenho e o reultado apreentado pelo oftware. Um apecto importante a er coniderado é a documentação do código-fonte de cada clae, compota por: º um comentário acima do nome da clae informando ua finalidade, autor, verão, data (dd/mm/aaaa) da última compilação e clae relacionada (Figura 4.5.3); º comentário apó cada atributo informando o limite e condiçõe epeciai a erem verificada na entrada (Figura 4.5.3); º comentário acima da implementação de cada método informando o tipo e a finalidade de cada parâmetro, a finalidade do retorno (para funçõe) e a funcionalidade que o método provê (Figura 4.5.4).

146 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i URGXWR2EWLGR Ù Ú Û2Ü Ý ÞMß à áà û ã î ê ì Ü ï ð úô Þèéê ð æ Þ ü ê2ý Þí Þ úþ Ú úô ð Ý ý Þìðí Þì æ Þååðþ ñê2ýþ Ù Ú Û2Ü Ý ÞMß à áà ß2ãäÚ å ÜÞ æ Ú çþèéê ëþ ÝìÚ Þ æí Þí ê ì Ü ï ð úô ÞèéêYí ê å ï ÿôê í ê åí Þìæ Þååðþ ñê/ýþ,psohphqwdud/yjlfdgh$upd]hqdphqwr 6ROXomR A aplicação dee padrão foi realizada da mema forma que o padrão 18, Implementar a Clae, porém relacionando-e com a clae do Diagrama de Clae de Projeto referente à lógica de armazenamento do dado da tabela fíica exitente, a quai compõem o banco de dado MySQL utilizado no

147 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 13 4 etudo de cao. A Figura ilutra a interface da clae "DBCor" e a Figura 4.5.6, ua implementação. 3URGXWR2EWLGR Ù Ú Û2Ü Ý ÞMß à áà á ãäú å ÜÞ æ Ú çþèéê ëþ ÝìÚ Þ æí Þ Ú úô ð Ý ý Þìðí Þìæ Þååðþ.î ñê2ýþ Ù Ú Û2Ü Ý ÞMß à áà ãäú å ÜÞ æ Ú çþèéê ëþ ÝìÚ Þ æí Þ Ú ïyë æ ðï ð úô Þèéê í Þì æ Þååðþ.î ñê2ýþ

148 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 13 5,PSOHPHQWDUD/yJLFDGH$SUHVHQWDomR 6ROXomR A partir da aplicação dee padrão foram elaborada a interface do oftware e o evento que tratam da lógica de apreentação do dado. A Figura e a Figura ilutram como foram compota, repectivamente, a interface legada e orientada a objeto referente à manipulação de core. A primeira, utilizando componente de aceo direto ao dado e a egunda, componente de edição de texto imple, obtido indiretamente, ou eja, atravé do método; Apó a definição de toda a interface foi realizada a inpeção de garantia da qualidade no oftware orientado a objeto, de forma a verificar e ete continha toda a funcionalidade preente no oftware legado. Io foi feito executandoe amba a verõe e verificando e cada funcionalidade etava preente na dua; Ea inpeção final conumiu cerca de quatro hora ao invé do tempo etimado no Plano para Realização da Reengenharia (uma hora). Porém, a reengenharia não etava atraada, o que não reultou em prejuízo para o proceo; Apó o término da inpeção, foi lançada a última EDVHOLQH do projeto, aplicando-e o padrão 5, contendo a verõe inpecionada do código-fonte e do programa executável. 3URGXWR2EWLGR Ù Ú Û2Ü Ý ÞMß à áà ã úô ð Ý ý Þìð æ ðû Þí Þ Ý ðý ð Ý ð úô ð (ô ð æ Þí ðñê/ý ðå

149 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 13 6 Ù Ú Û2Ü Ý ÞMß à áà ã úô ð Ý ý Þìð Ý ð Ú ïyë æ ð ïð úô Þí Þ Ý ðý ð Ý ð úô ð Mô ð æ Þí ðìê2ý ðå &RQVLGHUDo}HV)LQDLV Nee capítulo foi apreentado um exemplo da aplicação de cada padrão durante a realização do PRE/OO para o itema &21752/(*/2%$/. A documentação completa do etudo de cao encontra-e em LEMOS HWDO (2002). A preparação e o planejamento prévio do proceo habilitaram, durante ua aplicação, o acompanhamento por meio de inpeçõe, o que manteve ua condução empre de acordo em termo de alocação de tempo, recuro e peoal. Ante da utilização de cada padrão do FOXVWHUV3 a 7, o Plano para Realização da Reengenharia foi reviado e o tempo e o recuro etimado para a elaboração do produto de trabalho recuperado para a aplicação do padrão de forma organizada. O tempo etimado foi utilizado como guia, endo redimenionado de acordo com a neceidade e, cao neceário, reportado durante a inpeçõe de acompanhamento do proceo. A aplicação do FOXVWHU 2, Melhorar o Proceo de Engenharia Revera, relacionado à qualidade do proceo deve er contínua, ou eja, realizada ao longo da aplicação de todo o padrõe que compõem o FOXVWHUV 3 a 7, e ainda, apó o encerramento do PRE/OO (em futura manutençõe ou evoluçõe do oftware) de forma que o produto de trabalho e a documentação da qualidade como, por exemplo, a Lita de Controle de Configuração, não e tornem deatualizado.

150 Ca pítu lo 4. E tu do de Ca o: A Reen gen h a ria de u m Softwa re Delph i 13 7 O controle de configuração permitiu, a qualquer momento, durante o proceo o retorno à verõe mai atualizada do produto de trabalho e a realização de alteraçõe de forma controlada. Já, o etabelecimento de EDVHOLQHV poibilitou que conjunto de produto de trabalho correto e inpecionado foem utilizado, quando neceário, durante a aplicação do padrõe poteriore pelo engenheiro de oftware. A forma evolutiva de condução do PRE/OO poibilitou a volta a produto de trabalho deenvolvido ao longo do etudo de cao. Dea forma, obtêm-e reultado mai refinado do que na condução de um proceo de reengenharia de forma eqüencial linear. Outro fator eencial na qualidade do oftware orientado a objeto reultante do proceo foi a aplicação da inpeçõe de garantia da qualidade, verificando e o produto de trabalho haviam ido elaborado de forma correta. A decrição do PRE/OO em forma de padrõe, adaptada da FaPRE/OO (RECCHIA HW DO. 2002b), facilitou ua realização dada a modularidade e organização da informaçõe neceária, apecto relevante em vita de ua extenão. Ea divião facilitou, ainda, a utilização individual de padrõe, durante a volta do proceo evolutivo, detalhando-e produto epecífico por ele gerado. A implementação do oftware encapulando-e a lógica de negócio, de armazenamento e de manipulação do dado em clae epecífica tornou a utilização da funcionalidade por ela provida mai fácil dada a interface criada para cada clae. A partir dea forma de implementação, o engenheiro de oftware pode reutilizar o método diponívei, auxiliado pela documentação, em haver neceidade de conhecer eu detalhe de implementação. Outra vantagem derivada do encapulamento é a facilidade de manutenção er realizada em apena um ponto do código-fonte, o que, no oftware legado devido à repetição de código leva a um eforço e tempo gato maiore durante cada manutenção.

151 13 8 Ca pítu lo 5. Um a E tim a tiva do Cu to x Ben efício pa ra o Proce o de Reen gen h a ria Orien ta da a Objeto &RQVLGHUDo}HV,QLFLDLV Ete capítulo expõe algun ponto que foram obervado durante a condução do PRE/OO, provendo etimativa de benefício que podem er etendido ao demai cao de aplicação do proceo de reengenharia orientada a objeto. A Seção 5.2 motra o cuto x benefício quando e aplica o cluter de planejamento do PRE/OO; a Seção 5.3 aborda o cuto x benefício na realização do cluter referente à engenharia revera e a Seção 5.4 apreenta conideraçõe referente a engenharia avante utilizando o ambiente de deenvolvimento Delphi e o conceito de orientação a objeto. A Seção 5.5 traz a conideraçõe finai. &XVWRV [ %HQHItFLRV GR 3ODQHMDPHQWR GR 3URFHVVR GH 5HHQJHQKDULD2ULHQWDGDD2EMHWRV A preparação e o planejamento do PRE/OO foram propoto para que o engenheiro de oftware, ao utilizá-lo, obtivee mai ubídio para controlar a execução da atividade pela equipe envolvida habilitando-o há tomar deciõe mai apropriada coniderando o dado etimado no Plano para Realização da Reengenharia. Durante a realização do proceo, epecialmente ao término de cada pao da reengenharia (finalização da aplicação de cada um do FOXVWHUV3 a 7), foram propota inpeçõe como forma de prover ao engenheiro de oftware ponto epecífico para a realização de comparaçõe com a etimativa documentada. Ee ponto epecífico podem er coniderado como marco de acompanhamento do proceo, em que o engenheiro, com bae em ua habilidade e/ou experiência no gerenciamento de projeto

152 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 13 9 e na informaçõe etimada e reai, manipula e converge o proceo de forma que reultado atifatório relativo ao gerenciamento poam er alcançado. A limitação impota pelo PRE/OO é a neceidade de habilidade e/ou experiência do engenheiro de oftware durante a compoição da etimativa, dividindo o tempo diponível entre a divera atividade a erem realizada para a reengenharia do oftware. Ea habilidade faz-e neceária, também, quando o engenheiro de oftware, durante a inpeçõe de acompanhamento, deve comparar o reultado e tomar deciõe relativa ao proceo como: adiar atividade, redimenionar o tempo diponível para a aplicação de um ou mai FOXVWHUV, etc. Porém, atualmente, a emprea de oftware não trabalham em etimativa quando realizam deenvolvimento novo itema o que, naturalmente, deve e etender para a reengenharia de itema legado. É viível a neceidade da criação de nova métrica ou adaptação de métrica exitente para compor etimativa além da bae unicamente empírica da experiência do engenheiro, principalmente em cao que ua experiência com o proceo ou com o ecopo do oftware ejam pequena. A adoção de ferramenta de planejamento como o 063URMHFW para compor o cronograma de atividade pode facilitar o trabalho do engenheiro de oftware. Durante a condução do etudo de cao toda a etimativa baearam-e no conhecimento do engenheiro de oftware obre o PRE/OO e obre o oftware legado. Nenhuma métrica para geração de etimativa ou ferramenta para compoição do cronograma foi utilizada. O reultado obtido foram coniderado atifatório, uma vez que a reengenharia pôde er realizada dentro do prazo etabelecido e gerando um produto melhor que o legado em termo de documentação e manutenção futura. Ma, acredita-e que ee reultado podem variar batante em cada oftware legado a er ubmetido ao PRE/OO, em função do apecto citado. &XVWRV[%HQHItFLRVGD(QJHQKDULD5HYHUVD A engenharia revera, dividida no PRE/OO em trê FOXVWHUVnumerado de 3 a 5, (Figura página 43) apreentou, durante a realização do etudo de cao, alguma variaçõe decrita a eguir: º A aplicação do FOXVWHU 3, Revitalizar a Arquitetura do Software, tendo como auxílio o editor de texto do MS Office, foi a etapa mai repetitiva, por er neceária percorrer vária veze todo o código-fonte em buca do procedimento e funçõe e de eu

153 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 0 ponto de chamada. A exitência de uma ferramenta, baeada na análie intática do código-fonte legado, capaz de extrair o procedimento e funçõe para a montagem da lita, diminuiria o trabalho do engenheiro de oftware e a ocorrência de poívei erro. Io tornaria a aplicação do padrõe 6 e 7 mai rápida, retando ao engenheiro de oftware a compoição da decriçõe do procedimento e funçõe apó a geração automática da Lita de Procedimento e Funçõe e da Lita "Chama/Chamado Por". Porém, não houve dificuldade em e aplicar tai padrõe manualmente, fato que contribuiu para um melhor conhecimento da etrutura da XQLWVe da arquitetura do itema ao longo do proceo, por parte do engenheiro de oftware. A aplicação dee FOXVWHU foi indipenável, poi compô a documentação da arquitetura do oftware, a qual foi utilizada em todo o FOXVWHUVpoteriore, como forma de obtenção de informaçõe obre o procedimento e funçõe exitente; º A aplicação do FOXVWHU4, Elaborar Modelo de Análie do Sitema Atual, foi facilitada pelo uo da ferramenta 5DWLRQDO 5RVH. O padrõe 8 e 9 foram realizado manualmente havendo, em relação à aplicação do padrão 9, Criar Lita de Anomalia a mema dificuldade citada no item anterior, pelo fato da neceidade do engenheiro de oftware percorrer o código-fonte em buca do aceo à etrutura de dado anteriormente identificada. Ee FOXVWHU, reponável pelo eboço da primeira vião orientada a objeto do oftware, foi aplicado em dificuldade, fato auxiliado por não ter ido tomada nenhuma decião ubjetiva por parte do engenheiro de oftware, tratando apena da repreentação de informaçõe já exitente no oftware legado de outra forma; º A aplicação do FOXVWHU 5, Elaborar Modelo de Análie do Sitema, contou com o auxílio da ferramenta 5DWLRQDO5RVH,para o deenho do diagrama. Porém, dado o fator ubjetivo implícito na tomada de deciõe contida no trê padrõe que o compõem como, por exemplo, a definição do tipo de relacionamento entre a clae do MAS com bae no contexto do itema, tornaram o produto reultante de ua aplicação dependente do nível de conhecimento do paradigma orientado a objeto e do contexto do objeto dentro do ecopo do oftware. A etapa de engenharia revera do PRE/OO poibilitou a recuperação de toda a documentação do oftware, inexitente no cao do itema legado utilizado. Aim, em cao de expanão/manutenção da funcionalidade do itema, o diagrama e lita gerado facilitam e complementam ua realização diminuindo o cuto e o tempo neceário para o eu entendimento.

154 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 1 Além do auxílio na etapa de manutenção de itema, a engenharia revera é um pré-requiito indipenável para a etapa de engenharia avante, pelo fato do modelo de projeto gerado com a aplicação do FOXVWHU 4 utilizarem, como bae, vário produto obtido com a aplicação do FOXVWHUV3 a 5. &XVWRV[%HQHItFLRVGD(QJHQKDULD$YDQWH Durante a aplicação do padrõe do FOXVWHU 6, Elaborar Projeto Avante, foram verificada a mema particularidade da aplicação do cluter 5, em que foi utilizado o 5DWLRQDO 5RVH facilitando o deenho do diagrama que compõem a documentação do itema. Porém, foi dificultada pelo caráter ubjetivo da tomada de alguma deciõe, principalmente quanto à aociação do método à clae referente à lógica de negócio e à lógica de armazenamento e manipulação de dado. A aplicação do padrõe do FOXVWHU 7, Re-implementar o Software, foi batante auxiliada pelo diagrama elaborado com o padrõe do FOXVWHU anterior. Porém, foi muito relevante o conhecimento, por parte do engenheiro de oftware, da programação orientada a objeto, no entido de utilizar corretamente o apecto diponívei na linguagem 2EMHFW 3DVFDO como, por exemplo, a obrecarga de método (e também o apeto não diponívei nea linguagem como, por exemplo, a herança múltipla) de forma a elaborar a implementação mai organizada e tranparente poível para futura manutençõe. Pode-e dizer que a qualidade do produto gerado com a aplicação do PRE/OO, em termo de fidelidade de repreentação da informaçõe originai do oftware legado e da correta aplicação do conceito da orientação a objeto utilizado na compoição da documentação (MAS e Projeto Avante) e na re-implementação (código-fonte orientado a objeto implementado em 2EMHFW 3DVFDO), é inveramente proporcional ao eforço que erá gato em futura manutençõe/evoluçõe do itema apó ua reengenharia. Um exemplo da melhoria da manutenibilidade é apreentado a eguir. A Figura ilutra o código legado referente ao procedimento ProdEtoqueBtnPotClick que inere nova quantidade de um produto no etoque. Oberva-e que um único procedimento é reponável direto por divera operaçõe, como detalhado a eguir: O itema, primeiro, verifica e há regitro dee produto em etoque (detaque D) e em cao afirmativo, lança uma exceção (detaque E). Cao contrário, inere o

155 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 2 produto em etoque (detaque F), atualiza a interface (detaque G), obtém o cuto unitário (detaque H), calcula o preço médio de cuto de acordo com a quantidade inerida (detaque I) e atualiza o componente da interface para que econdam o componente de inerção em etoque (detaque J). Ee conjunto de operaçõe tratada apena por um procedimento, em nenhum comentário ou documentação, torna a manutenção difícil e, ainda, poibilita a inerção de novo EXJV no oftware dada à falta de referência obre o outro procedimento dependente dee. Ù Ú Û2Ü Ý Þá à ß à â ãñ í/ú Û ê ýê2úô ð æ ðû Þí ê /Üð ë Ý ê ùþ Ú úåð Ýèéê í ð ú ê Þå /ÜÞ úô"ú í Þí ðåðï ðåôê 2Üð No pao de re-implementação ee procedimento teve ua operaçõe foram dividida em método da clae "DBEtoque" e em outro evento de interface,

156 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 3 chamado pelo evento GravarQuantidadeEmNovoEtoque como ilutra a Figura A Figura apreenta o código-fonte re-implementado. Nota-e a modularização do código, ou eja, a divião do código em pequeno trecho tratado por divero método, além da inerção de comentário, o que torna a manutenção dea funcionalidade batante facilitada. Como a linguagem de implementação legada é a mema utilizada no proceo de reengenharia oberva-e a redução no número de linha de código. Ù Ú Û2Ü Ý Þá à ß à õ ãñê2ý"ý ðå ë ê/ú í ù ú ì Ú Þ(ð úô"ý ðþåê2ëð Ý Þè ðåí êå ê ý ô MÞ Ý ð æ ðû Þí ê ðê å ï ÿôê í ê å ðð úôê åê2ý9ú Û2Ú úþí ê åþ ë åþ Ý ðð ú Û ð úþ Ý"Ú Þ Ù Ú Û2Ü Ý Þá à ß à û ãñ í/ú Û ê ýê2úô ð 2Üð ë Ýê ùþ Ú úåð Ýèéê í ð ú ê Þå /ÜÞ úô"ú í Þí ðåðï ðåôê /Üð A organização do código-fonte é uma da caracterítica marcante em todo o oftware re-implementado, com maior número de procedimento e funçõe (método), reultando numa maior viibilidade da funcionalidade provida. Ea organização obtida com a aplicação do FOXVWHUV 6 e 7 do PRE/OO melhora o entendimento por parte do engenheiro de oftware, auxiliado ainda, pela documentação diponível obtida na etapa

157 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 4 de engenharia revera (FOXVWHUV 3 a 5). Com ea vantagen a manutenibilidade do oftware é aumentada. Outro exemplo motra como o encapulamento, provido com a reengenharia orientada a objeto, pode facilitar o reuo de código durante futura do oftware reimplementado. O oftware procedimental implementado em Delphi utiliza, como citado anteriormente, componente que fazem aceo direto à tabela de dado do oftware. O uo dee tipo de componente, ilutrado pela Figura 5.4.5, facilita a implementação, poi obtém-e diretamente qualquer informação da tabela de dado. Porém, ea facilidade aliada à falta de documentação reulta, muita veze, em duplicação do código, como ilutrado pelo detaque D, E e F da Figura Ù Ú Û2Ü Ý Þá à ß à ß2ãñ í/ú Û ê ýê2úô ð æ ðû Þí ê ìê ïåý ð ëðô"ú èéê í Þ(ý"Ü ú ì Ú ê/úþ æ Ú í Þí ðí ð æ ê ìþ æ Ú çþ ÝrÜ ïçì æ Ú ð úô ð

158 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 5 Ù Ú Û2Ü Ý Þá à ß à á ã)üþå í ê Þ ïü Ú ð úô ð î ð æ ë Úìê ïçìê ïëê2úð úô ðå í ð(þìðåå êyí/ú Ý ðôê Þê å í Þí ê å A duplicação da funcionalidade para localizar um cliente foi, na engenharia revera, reconhecida e eliminada com a criação do método Locate. Na engenharia avante, o método foi implementado utilizando-e obrecarga de funçõe de forma a permitir ua utilização a partir do código e do nome do cliente, como ilutra o detaque da Figura Ù Ú Û2Ü Ý Þá à ß à ãäú å ÜÞ æ Ú çþèéê ëþ ÝìÚ Þ æí Þ Ú úô ð Ý ý Þìðí Þìæ Þååðþ.î ñœæ Ú ð úô ðþ A implementação por meio de método provendo o encapulamento da funcionalidade requer ao engenheiro de oftware, em cao de neceidade de reuo para evolução do itema, apena a conulta à interface da clae deejada para utilizar eu método, não endo neceário percorrer todo o código de forma a aber e uma determinada funcionalidade já foi implementada. Porém, é de extrema importância haver a documentação da funcionalidade diponívei em cada clae de forma a informar ao engenheiro de oftware e tal método realiza o eperado. Um outro ponto a er detacado é quanto a diferença verificada comparando-e à interface orientada a objeto em relação à exitente na implementação legada. O principal ponto obervado nee apecto, durante a realização do etudo de cao, foi a forma de montagem da interface.

159 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 6 A contrução da interface eguindo o paradigma orientado a objeto envolve um trabalho maior por parte do engenheiro de oftware, poi ete tem que "encaminhar" o valore obtido atravé do método até a interface, como ilutra o exemplo da Figura Ù Ú Û2Ü Ý Þá à ß à ã úô ð Ý ý Þìðê2Ý"Ú ð úô Þí Þ(Þê/ü.ó ðôê å A interface legada, contruída com bae no componente de aceo direto ao dado coneguem, atravé dele, apreentar diretamente ao uuário o dado da tabela, como ilutra a Figura Para compoição dee tipo de interface não é neceária a implementação de código-fonte para aceo ao dado, batando configurar a propriedade do componente. Apear dea diferença, a dua forma de compoição reultam em interface praticamente idêntica, o que facilita a adaptação do uuário ao itema re-implementado.

160 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 7 Ù Ú Û2Ü Ý Þá à ß à ã úô ð Ý ý Þìðìê ïëê åô ÞÞ ëþ Ý ô"ú Ý/í ðìê ïë ê/úð úô ðå í ð(þìðåå êyí/ú Ý ðôê Þí Þí ê å &RQVLGHUDo}HV)LQDLV De acordo com o apecto apreentado nee capítulo conclui-e que o PRE/OO pode er uma opção concreta em comparação com o total redeenvolvimento de um oftware legado deenvolvido em Delphi em a utilização da caracterítica orientada a objeto diponívei no ambiente. A preparação e o planejamento do proceo de reengenharia orientada a objeto obtido a partir da aplicação do FOXVWHU 1 poibilitam ao engenheiro de oftware um maior controle do produto a erem gerado ao longo do proceo, bem como do tempo e recuro gato para a ua elaboração, a partir da aplicação do padrõe que

161 Ca pítu lo 5. Um a E tim a tiva de Cu to x Ben efício p a ra a Reen gen h a ria OO 14 8 compõem o FOXVWHUV3 a 7. Porém, o etudo de métrica poívei de erem aplicada é uma ugetão para aumentar a fidelidade da etimativa. A aplicação do padrõe do FOXVWHU 3 utilizou um maior eforço pelo fato dete erem realizado manualmente. O padrõe do FOXVWHUV 5 e 6 exigiram a tomada de deciõe ubjetiva, pelo engenheiro de oftware, em relação à modelagem orientada a objeto. Durante a aplicação do padrõe do FOXVWHU 7, foi neceário conhecer o apecto de orientação a objeto preente ou não na linguagem 2EMHFW3DVFDO. O padrõe do FOXVWHU 2, aplicado ao longo do PRE/OO, poibilitaram o acompanhamento da atividade etimada no Plano para Realização da Reengenharia e do produto de trabalho gerado durante ea atividade contribuindo para a organização do proceo e a validação do produto. Outro fator que contribuiu para ea organização foi a realização do controle de configuração, permitindo ao engenheiro de oftware controlar a verõe do iten de configuração e etabelecer EDVHOLQHVpara documentação do iten inpecionado. Verificou-e que a incluão dee padrõe na reengenharia não tornou o proceo burocrático, além de auxiliar na correção de erro cometido durante a elaboração do produto e na organização da atividade.

162 14 9 Ca pítu lo 6. Con clu õe e Per pectiva Fu tu ra Ete capítulo apreenta a concluõe do trabalho na Seção 6.1 e ua contribuiçõe na Seção 6.2; na Seção 6.3 ão apreentada a ugetõe de pequia que podem er realizada em continuidade a ete. &RQFOXV}HV Devido à grande quantidade de itema de oftware oboleto que realizam tarefa útei à emprea ma deenvolvido com técnica, atualmente, coniderada oboleta, há a neceidade de definir e documentar um proceo de reengenharia de maneira a torná-lo uma opção conitente para eu completo redeenvolvimento ou para facilitar a manutençõe que tornam-e cada vez mai cara. Ea diertação propô um proceo de reengenharia orientada a objeto (PRE/OO) definido na forma de vinte padrõe, ditribuído em ete FOXVWHUVcompondo a engenharia revera, a engenharia avante e a qualidade global do proceo. Como forma de exemplificar a utilização do PRE/OO, foi conduzida a reengenharia de um oftware legado procedimental deenvolvido utilizando-e o ambiente Delphi em a preocupação em coniderar o recuro orientado a objeto nele exitente. A neceidade da criação de um proceo de reengenharia orientada a objeto que cuidae do apecto de garantia da qualidade foi percebida pela falta de referência ao aunto na literatura epecializada bem como pela falta de informaçõe de engenheiro de oftware para a condução dee proceo. Dea forma, coniderando-e o materiai diponívei relacionado ao deenvolvimento de proceo de oftware que cuidam da melhoria de qualidade optoue por utilizar a KPA do nível 2 de maturidade do SW-CMM para a realização do proceo de reengenharia orientada a objeto. A utilização dea KPA foi poível uma vez que tratam de apecto báico de proceo em geral como a definição de requiito, o planejamento do proceo, a gerência de configuração e a inpeçõe, preocupaçõe exitente também na reengenharia. Com io pretende-e que o

163 Ca pítu lo 6. Con clu õe e Per pectiva Fu tu ra 15 0 proceo de reengenharia orientada a objeto, PRE/OO, eja realizado com qualidade proporcionando que o reultado final também eja atifatório. A elaboração do PRE/OO utilizou a diretrize do método Fuion/RE, que foi utilizado em divero proceo de engenharia revera, a ferramenta 5DWLRQDO5RVHpara documentação do diagrama orientado a objeto produzido ao longo do proceo, o ambiente de deenvolvimento Delphi com o recuro da linguagem 2EMHFW 3DVFDO de forma que o engenheiro de oftware não tenha gato de aprendizado com uma nova linguagem de programação. Sua ecrita ocorreu na forma de padrõe para facilitar o entendimento por parte de outro engenheiro de oftware que venham a utilizar ee proceo. Acredita-e que a utilização de padrõe relacionado à melhoria da qualidade favoreça a geração de um produto com a mema funcionalidade que a do itema legado e que em todo o ponto do proceo poam er acompanhado o eforço com ele gato. Durante a elaboração dee proceo um etudo de cao foi conduzido a fim de que a maioria da ituaçõe foem tetada. O oftware utilizado no etudo de cao utilizado foi deenvolvido há cinco ano pela autora dee trabalho, utilizando o ambiente Delphi em aproveitar o recuro da orientação a objeto por ele oferecido. O proceo de reengenharia conduzido de forma evolutiva permite acuidade do produto elaborado em relação ao proceo eqüencial linear, pelo fato do ganho de eclarecer a funcionalidade exitente no legado em divero pao, garantir maior conitência ao proceo. O padrõe do PRE/OO não preciam er utilizado de forma eqüencial. Dependendo do conhecimento do engenheiro de oftware em relação ao oftware legado e à orientação a objeto, o padrõe podem er utilizado de forma que melhor lhe forneça documentação útil tanto para manutenção do itema como para ua reengenharia completa. 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, que foram aplicado nee proceo de reengenharia para torná-lo mai completo. A eguir ão apreentada a contribuiçõe dete trabalho.

164 Ca pítu lo 6. Con clu õe e Per pectiva Fu tu ra 15 1 &RQWULEXLo}HVGHVWH7UDEDOKR A contribuição principal dete trabalho foi prover a definição de um proceo de reengenharia orientada a objeto totalmente documentado na forma de padrõe, a partir do quai, o engenheiro de oftware torna-e capaz de realizá-la em itema procedimentai implementado em Delphi em levar em conideração caracterítica orientada a objeto. Ee itema ão tranformado de modo a adquirir ea caracterítica utilizando-e, para io, a linguagem de programação original. Outra contribuiçõe que derivam deta diertação ão: º a preocupação com a qualidade de proceo na reengenharia e, coneqüentemente, no produto de trabalho dela reultante, decrita na forma de doi FOXVWHUV de padrõe. A partir dee apecto, paa-e a tratar a reengenharia com o memo cuidado já decrito em relação ao proceo de deenvolvimento de oftware; º o detalhamento do pao para a obtenção do modelo de análie do itema, poibilitando a realização apena de ua engenharia revera, independente da neceidade da re-implementação do itema. A engenharia revera, realizada no intuito de prover a re-documentação de itema, pode er feita individualmente, a partir da aplicação do FOXVWHUV de padrõe 3, 4 e 5 do PRE/OO, acompanhado pelo FOXVWHUV1 e 2 relacionado à qualidade de proceo; º a verificação do proceo evolutivo como endo melhor opção à condução da reengenharia em relação ao proceo eqüencial linear, de forma a prover reultado mai refinado devido à facilidade de retorno a padrõe previamente aplicado; º a evolução de um proceo já validado, o Fuion/RE, utilizando a UML, como meio de facilitar a documentação do diagrama gerado dada a exitência de vária ferramenta de apoio, como o 5DWLRQDO5RVH, utilizado nee trabalho; º a poibilidade da utilização do PRE/OO, apó alguma adaptaçõe, em itema implementado em outra linguagen procedimentai; º o uo do padrõe do FOXVWHU Modelar o Dado do Legado da FaPRE/OO intanciado para Delphi. 6XJHVW}HVSDUD7UDEDOKRV)XWXURV O proceo de reengenharia teve parte do padrõe aplicado, auxiliado apena pelo editor de texto, como no cao do padrõe 6 e 7 do FOXVWHU 3 relacionado à revitalização da arquitetura. Ee fato reultou em baixa eficiência, o que tende a tornar-

165 Ca pítu lo 6. Con clu õe e Per pectiva Fu tu ra 15 2 e crítico quanto maior for o itema a paar pelo proceo. Aim, uma poibilidade de pequia é a elaboração de uma ferramenta para extração do procedimento e funçõe do oftware legado. Além dee, outro padrõe podem er automatizado como, por exemplo, o padrão 8, Modelar Dado do Software Legado, de forma a obter o Modelo Entidade Relacionamento e a Lita de Tabela e Chave a partir do VFULSWVSQL preente no arquivo de dado do oftware legado. A atividade de melhoria da qualidade podem er revita e adaptada a cada cao, complementando-e o FOXVWHUV1 e 7, com outra diretrize de forma a prover um proceo de reengenharia cada vez mai efetivo. Propõe-e, ainda, um modelo de capacitação para o proceo de reengenharia, independente da forma de condução do memo, derivando-e modelo já validado como o SW-CMM. Outra ugetão de pequia é a derivação e o detalhamento do PRE/OO para itema deenvolvido em outro ambiente, como o 9LVXDO %DVLF, aumentando o número de cao em que o proceo pode er utilizado.

166 15 3 Referên cia Bibliográ fica BENNET, K. H.; RAJLICH, V. T. 6RIWZDUH 0DLQWHQDQFH DQG(YROXWLRQ D 5RDGPDS. In Anthony Finkeltein, ed. The Future of Software Engineering. Limerick, Ireland. ACM Pre, Página BOOCH, G. 2EMHFW2ULHQWHG'HVLJQZLWK$SSOLFDWLRQV Benjamin Cumming, CA CAMPOS, V. F. 74&&RQWUROHGD4XDOLGDGH7RWDO Fundação Chritiano Ottoni, UFMG Belo Horizonte CHIKOFSKY, J. E.; CROSS, J. H. 5HYHUVH (QJLQHHULQJ DQG 'HVLJQ 5HFRYHU\ $ 7D[RQRP\. IEEE Software. Volume 7, número 1, página COLEMAN, D.; ARNOLD, P.; BODOFF, S.; DOLLIN, C.; GILCHRIST, H. and HAYES, F. 2EMHFW2ULHQWHG 'HYHORSPHQW 7KH )XVLRQ 0HWKRG. Prentice Hall. ISBN CORNELL, G.; STRAIN, T. 'HOSKL1XWV %ROWVIRU([SHULHQFHG3URJUDPPHUVMakron Book. ISBN CORTÊS, M. L.; CHIOSSI, T. C. S. 0RGHORVGH4XDOLGDGHGH6RIWZDUH. Série Título em Engenharia de Software. Editora da Unicamp. Intituto de Computação COSTA, R. J.; SANCHES, R. )HUUDPHQWDV GH (QJHQKDULD 5HYHUVD QR $SRLR j 4XDOLGDGHGH6RIWZDUH. Relatório Técnico n 45, ICMC-USP São Carlo DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. $ 3DWWHUQ /DQJXDJH IRU 5HYHUVH (QJLQHHULQJ. Proceeding of the 4 th European 5 th European Conference on Pattern Language of Programming and Computing. Paul Dyon (Ed.) Univeritätverlag Kontanz GmbH, Kontanz, Germany. July DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. $ 3DWWHUQ /DQJXDJH IRU 5HYHUVH (QJLQHHULQJ. Proceeding of the 5 th European Conference on Pattern Language of Programming and Computing. Andrea Rüping (Ed.)

167 Referên cia Bibliográ fica 15 4 DEMEYER, S.; DUCASSE, S.; NIERSTRASZ, O. 7LH &RGH DQG 4XHVWLRQV D 5HHQJLQHHULQJ 3DWWHUQ. Proceeding of the 5 th European Conference on Pattern Language of Programming and Computing. Andrea Rüping (Ed.). Página b. DoD. 7RWDO4XDOLW\0DQDJHPHQW0DVWHU3ODQ. Department of Defene USA DUCASSE, S.; RICHNER, N.; NEBBE, R7ZR5HHQJLQHUULQJ3DWWHUQV(OLPLQDWLQJ7\SH &KHFNLQJ In Proceeding of 4 th European Conference on Pattern Language of Programming and Computing. Paul Dyon (Ed.). UVK Univeritätverlag Kontanz GmbH, Kontanz, Germany. July DUCASSE, S.; RICHNER, N.; NEBBE, R 7\SH &KHFNLQJ (OLPLQDWLRQ 7ZR 2EMHFW 2ULHQWHG 5HHQJLQHHULQJ 3DWWHUQV In Proceeding of 6 th Working Conference on Revere Engineering). IEEE Computer Society Pre, página FAESARELLA, I. S.; CARPINETTI, L. C. R.; SACOMANO, J. B. *HVWmRGD4XDOLGDGH &RQFHLWRVH)HUUDPHQWDV. USP São Carlo FIORINI, S.T.; STAA, A.; BAPTISTA, R. M. (QJHQKDULD GH 6RIWZDUH FRP &00. Ed. Braport, Rio de Janeiro FORD, N. -%XLOGHU8QOHDVKHGSam Publihing. 1ª Edição FUGGETTA, A. 6RIWZDUH3URFHVV$5RDGPDS. In Anthony Finkeltein, ed. The Future of Software Engineering. Limerick, Ireland. ACM Pre, Página GREMBA, J.; MYERS, C. 7KH,'($/ 0RGHO $ 3UDFWLFDO *XLGH IRU,PSURYHPHQW. Software Engineering Intitute HAREL, D. 6WDWHFKDUWV $9LVXDO)RUPDOLVPWR&RPSOH[6\VWHPV. Science of Computer Programming. Volume 8, página HUMPHREY, W. S. &KDUDFWHUL]LQJ WKH 6RIWZDUH 3URFHVV $ 0DWXULW\ )UDPHZRUN, Software Engineering Intitute. CMU/SEI-87-TR a. HUMPHREY, W. S.; SWEET, W. L. $ 0HWKRGIRU $VVHVVLQJ WKH 6RIWZDUH(QJLQHHULQJ &DSDELOLW\ RI &RQWUDFWRU. Software Engineering Intitute, CMU/SEI-87-TR b.

168 Referên cia Bibliográ fica 15 5 IEEE 6WDQGDUG*ORVVDU\RI 6RIWZDUH(QJLQHHULQJ 7HUPLQRORJ\, Standard IEEE Pre, INPRISE CORPORATION. %RUODQG'HOSKL±'HYHORSHU V*XLGH ISO. NBR ISO/IEC 12207: HFQRORJLDGD,QIRUPDomR±SURFHVVRVGHFLFORGHYLGD GHVRIWZDUH. Aociação Braileira de Norma Técnica, JACOBSON, I.; CHRISTERSON, M.; JONSSON, P.; OVERGAARD, G. 2EMHFW2ULHQWHG 6RIWZDUH(QJLQHHULQJ. Adion-Weley, ReadingS, MASS JACOBSON, I.; LINDSTRÖM, F. 5HHQJLQHHULQJRI2OG6\VWHPVWRDQ2EMHFW2ULHQWHG $UFKLWHFWXUHSIGPLAN Notice. Volume 26, número 11, página LEMOS, G. S.; PENTEADO, R. A. D. 5HHQJHQKDULD GR 6RIWZDUH &RQWUROH*OREDO SDUD /RMDV Documento de Trabalho n 1. Departamento de Computação, Univeridade Federal de São Carlo. Fevereiro LIBERTY, J. %HJJLQLQJ2EMHFW2ULHQWHG$QDOLV\VDQG'HVLJQ with C++. Wrox Pre Ltd McFEELEY, B.,'($/ $ 8VHU V *XLGH IRU 6RIWZDUH 3URFHVV,PSURYHPHQW Software Engineering Intitute. CMU/SEI-96-HB McMANUS, J. I.; SCHULMEYER, G.G +DQGERRN RI 6RIWZDUH 4XDOLW\ $VVXUDQFH International Thomon Computer Pre. 2ª Edição OLSEM, M. R. $Q,QFUHPHQWDO$SSURDFKWR6RIWZDUH6\VWHPV5HHQJLQHHULQJSoftware Maintenance: Reearch and Practice. Volume 10, página OMG. 8QLILHG 0RGHOLQJ /DQJXDJH 6SHFLILFDWLRQ. Object Management Group. Verão 1.3. Junho OXFORD UNIVERSITY PRESS. 'LFWLRQDU\RI&RPSXWLQJ PAULK, M. C.; WEBER, C. V.; WISE, C.; WITHEY, J..H\ 3UDFWLFHV RI WKH &DSDELOLW\ 0DWXULW\ 0RGHO 9HUVLRQ Software Engineering Intitute, CMU/SEI-91-TR

169 Referên cia Bibliográ fica 15 6 PAULK, M. C.; CURTIS, B.; CHRISSIS, M. B.; WEBER, C. V. &DSDELOLW\0DWXULW\0RGHO IRU 6RIWZDUH 9HUVLRQ Software Engineering Intitute, CMU/SEI-93-TR a. PAULK, M.C.; WEBER, C. V; GARCIA, S.; CHRISSIS, M. B.; BUSH, M..H\3UDFWLFHVRI WKH &DSDELOLW\ 0DWXULW\ 0RGHO 9HUVLRQ Software Engineering Intitute, CMU/SEI-93-TR b. PENTEADO, R. A. D. 8P0pWRGRSDUD(QJHQKDULD5HYHUVD2ULHQWDGDD2EMHWRV. Tee (Doutorado em Fíica Computacional). Intituto de Fíica de São Carlo, Univeridade de São Paulo São Carlo/SP. 1996a. PENTEADO, R. A. D.; BRAGA, R. T. V.; MASIERO, P. C.,PSURYLQJ WKH 4XDOLW\ RI /HJDF\&RGHE\5HYHUVH(QJLQHHULQJ IV International Conference on Information Sytem Analyi and Synthei. Orlando, Flórida. Página b. PENTEADO, R. A. D.; GERMANO, F. ; MASIERO, P. C. $Q2YHUDOO3URFHVV%DVHGRQ )XVLRQ WR 5HYHUVH (QJLQHHU /HJDF\ &RGH III Working Conference on Revere Engineering IEEE. Monterey, California. Página b. PENTEADO, R. A. D.; MASIERO, P. C.; BRAGA, R. T. V.; PRADO, A. F. 5HHQJLQHHULQJ RI /HJDF\ 6\VWHPV %DVHG RQ 7UDQVIRUPDWLRQV 8VLQJ WKH 2EMHFW 2ULHQWHG 3DUDGLJP V Working Conference on Revere Engineering IEEE. Honolulu, Hawaii. Página PENTEADO, R. A. D.; MASIERO, P. C.; CAGNIN, M. I. $Q([SHULPHQWRI/HJDF\&RGH 6HJPHQWDWLRQ WR,PSURYH 0DLQWDLQDELOLW\. III European Conference on Software Maintenance and Reengineering IEEE. Amterdã, Holanda. Página PFLEEGER, S. L.. 6RIWZDUH(QJLQHHULQJ±7KHRU\DQG3UDFWLFH. Prentice Hall Inc., New Jerey, POOLEY, R.; STEVENS, P. 6RIWZDUH 5HHQJLQHHULQJ 3DWWHUQV. 1º SEBPC Legacy Sytem Workhop. Grey College, Univerity of Durham, February PRADO, A. F. 'HVHQYROYLPHQWRGH6RIWZDUH2ULHQWDGRD2EMHWRV Apotila. - Aceado em 01/04/01.

170 Referên cia Bibliográ fica 15 7 PRESSMAN, R. S. 6RIWZDUH (QJLQHHULQJ $ 3UDFWLWLRQHUV $SSURDFK )LIWK (GLWLRQ McGraw-Hill Higher Education QUATRANI, T. 9LVXDO0RGHOLQJZLWK5DLRQDO5RVHDQG80/. Addion-Weley QUINAIA, M. A.; SANCHES, R. 5HHQJHQKDULD GH 6RIWZDUH. Relatório Técnico n 84, ICMC-USP São Carlo RATIONAL CORPORATION. 8QLILHG0RGHOLQJ/DQJXDJH Aceado em 01/05/2001. RECCHIA, E. L. (QJHQKDULD 5HYHUVD H 5HHQJHQKDULD %DVHDGDV HP 3DGU}HV. Diertação (Metrado em Ciência da Computação). Programa de Pó-Graduação em Ciência da Computação, Univeridade Federal de São Carlo São Carlo/SP. Junho RECCHIA, E. L.; PENTEADO, R. A. D. )D35(22 8PD )DPtOLD GH 3DGU}HV SDUD 5HHQJHQKDULD 2ULHQWDGD D 2EMHWRV GH 6LVWHPDV /HJDGRV 3URFHGLPHQWDLV. SugarloafPLoP2002 The Second Latin American Conference on Pattern Language of Programming. Itaipava, Rio de Janeiro. Agoto, REKOFF, M. G. Jr. 2Q 5HYHUVH (QJLQHHULQJ. IEEE Tran. Sytem, Man, and Cybernetic. Volume março-abril, página ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K.C. Qualidade de Software Teoria e Prática. 1ª Edição Prentice Hall. São Paulo ROUT, T. P. (YROYLQJ63,&(±7KH)XWXUHRI,62. 1º International Conference on Software Proce Improvement and Capability Determination. Limerick, Irlanda. Junho, ROUT, T. P. 63,&(DQGWKH&00LVWKH&00&RPSDWLEOH:LWK,62,(&" AquIS 98. Veneza, Itália RUMBAUGH, J. HWDO. 2EMHFW2ULHQWHG0RGHOLQJDQG'HVLJQ. Englewood Cliff, Prentice Hall International SCHILDT, H.; GUNTLE, G. %RUODQG&%XLOGHU7KH&RPSOHWH5HIHUHQFH. McGraw-Hill Profeional Publihing. Abril, 2001.

171 Referên cia Bibliográ fica 15 8 SOMMERVILLE, I. 6RIWZDUH (QJLQHHULQJ International Computer Science Serie. 5ª Edição. Addion Weley Publihing Co SONNINO, B..\OL[±'HOSKLSDUD/LQX[*XLD3UiWLFRGH3URJUDPDomRMakron Book SPICE.,62,(& 6RIWZDUH 3URFHVV $VVHVVPHQW, 3DUWV. Technical Report - Type STEVENS, P.; POOLEY, R. 6\VWHPV 5HHQJLQHHULQJ 3DWWHUQV. In Proceeding of 6 th International Sympoium on the Foundation of Software Engineering. Página November TILLEY, S. $ 5HYHUVH (QJLQHHULQJ (QYLURQPHQW )UDPHZRUN. Software Engineering Intitute, CMU/SEI-98-TR WONG, K.; TILLEY, S. R.; STOREY, M.; SMITH, D. B.; JAHNKE, J. H.; MÜLLER, H. A. 5HYHUVH (QJLQHHULQJ $ 5RDGPDS. In Anthony Finkeltein, ed. The Future of Software Engineering. Limerick, Ireland. ACM Pre, Página Página