UNIVERSIDADE ESTADUAL DO CEARÁ            ERIVAN DE SENA RAMOS UM MAPEAMENTO SISTEMÁTICO SOBRE PADRÕESDE SOFTWARE PARA REE...
ERIVAN DE SENA RAMOSUM MAPEAMENTO SISTEMÁTICO SOBRE PADRÕES DE SOFTWARE           PARA REENGENHARIA DE SISTEMAS           ...
R175m    Ramos, Erivan de Sena            Um mapeamento sistemático sobre padrões de        software para reengenharia de ...
Aos meus pais, responsáveis pelos meusfundamentos éticos e morais.
AGRADECIMENTOSAo meu irmão Erivanio de Sena Ramos, pelo companheirismo.Aos colegas André Luis Araújo Paiva, Mateus Ribeiro...
“Você não consegue ligar os pontos olhandopra frente; você só consegue ligá-los olhandopra trás. Então você tem que confia...
RESUMOA utilização de sistemas legados é uma realidade em muitas organizações.Para acompanhar mudanças em suas regras de n...
ABSTRACTNumerous organizations present use the legacy systems. These systems mustundergo maintenance in order to evolve ac...
LISTA DE FIGURASFIGURA 1 - Visão do RUP ............................................................................... 17...
LISTA DE TABELASTABELA 1 - Critérios de Inclusão e Exclusão .................................................. 32TABELA 2 ...
SUMÁRIO1        INTRODUÇÃO ...................................................................................... 121.1   ...
121 INTRODUÇÃO1.1 MOTIVAÇÃO          As organizações têm um custo alto de dinheiro quando investem emum software e, para q...
13          Os padrões de software aplicados na reengenharia visam registrar oconhecimento sobre como modificar softwares ...
14Finalmente, o Capítulo 4 apresenta as considerações finais do trabalho. Osformulários utilizados na condução do mapeamen...
152 FUNDAMENTAÇÃO TEÓRICA          Neste capítulo são apresentados alguns conceitos necessários paraum melhor entendimento...
16uso; o processo é iterativo e incremental; e o processo é centrado naarquitetura que engloba aspectos estáticos e dinâmi...
17                              FIGURA 1 - Visão do RUP                          Fonte: Adaptado de Rational (1998).      ...
18         − Software de aplicação: Geralmente, serviços de negócios por            meio de programas desenvolvidos e aces...
19                  FIGURA 3 - Modelo em Camadas de um sistema legado                                Sistema sociotécnico ...
20legados com a situação de desorganização e custos cada vez maiores; ouredesenvolver os softwares; ou realizar a reengenh...
21legados, tendo sempre como objetivo livrar-se das manutenções difíceis e dadegeneração de suas estruturas.2.3 REENGENHAR...
22ponto de partida para o desenvolvimento, conforme apresentado na Figura 4.Para a reengenharia, o sistema antigo serve co...
23documentação. Enquanto a engenharia reversa percorre do nível mais baixo daaplicação até o nível mais alto (utilizando-s...
24             Braga (1998) afirma que os padrões de software surgem como umaferramenta de preservação das soluções de esp...
25          − Forças: Impactos, influências e restrições relevantes para o             problema.          − Solução:     R...
262.5 REVISÃO SISTEMÁTICA EM ENGENHARIA DE SOFTWARE             De acordo com Kitchenham (2004), uma revisão sistemática é...
27          FIGURA 6 - Uma abordagem das três etapas da Revisão Sistemática                      Fonte: Adaptado de Biolch...
28seleção de estudos individuais ou a análise seja impulsionada por expectativasdo pesquisador. Deve-se permitir ainda que...
292.5.3 Publicação dos Resultados             Kitchenham (2004) adverte sobre a importância de comunicar osresultados de u...
303 MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE SOFTWARE PARAREENGENHARIA DE SISTEMAS          Este capítulo descreve todas as ...
31            Q1. Quais   os     padrões   de    reengenharia    publicados   nas                Conferências e Workshops ...
32reengenharia;        engenharia        reversa;      engenharia         avante;      reestruturação;reengenharia; legacy...
335   Os estudos devem apresentar a proposta de um ou mais padrões de    reengenharia em sistemas.           Os estudos qu...
34          b) O conjunto de estudos é selecionado a partir da verificação dos             critérios de inclusão e exclusã...
35          − ParaPLoP: 03 edições, entre 2009 e 2011          − Scrum PLoP: 02 edições, entre 2010 e 2011;          − Vik...
36           TABELA 3 - Catalogação dos Padrões de Reengenharia de SistemasId                        Título               ...
37    Hierarchy31 Type Check Elimination in Clients32 The Bridge to the New Town                    KELLER, 200033 Reengin...
3860 Criar Casos de Uso61 Criar Diagrama de Seqüência62 Criar Especificações dos Relacionamentos e    Cardinalidades63 Def...
39                FIGURA 8 - Porcentagem de Padrões por Disciplina do RUP             A classificação dos padrões por disc...
409    Criar Lista de Anomalias10   Criar Visão OO de Dados13   Abstrair Diagrama de Pseudo-Classes16   Elaborar Diagrama ...
41                               52   Identificar Supostas Classes e Supostos                                    Atributos...
423.3.3 Resultados obtidos para a questão 3 (Q3)          Os resultados obtidos para a questão 3 “Q3 - Os padrões publicad...
433.3.4 Resultados obtidos para a questão 4 (Q4)          Os resultados em relação a questão 4 “Q4 - Os usos conhecidos do...
44          Vale ressaltar que, embora alguns padrões apresentem como usoconhecido uma linguagem de programação específica...
45padrões) e 2003. Também é importante ressaltar que a EuroPLoP apresentaum maior número publicações relacionadas ao tema ...
464 CONCLUSÃO          Este trabalho teve por objetivo avaliar os padrões de software parareengenharia de sistemas através...
47projeto de reengenharia. Deste modo, este trabalho apresenta-se como umafonte de consulta a padrões de reengenharia de s...
48REFERÊNCIAS BIBLIOGRÁFICASALEXANDER, Christopher. ISHIKAWA, Sara. SILVERSTEIN, Murray.LACOBSON, Max. FIKSDAHL-KING, Ingr...
49COPLIEN, James. C++ Idioms Patterns. In: Pattern Languages of ProgramDesign 4, Massachusetts, USA, 2000.DEMEYER, Serge. ...
50LARMAN, Craig. Utilizando UML e Padrões. 3ª ed., São Paulo: Bookman,2005.LEMOS, Gizelle RECCHIA, Edson. PENTEADO, Rosang...
51PRESSMAN, Roger. Engenharia de Software. 5ª. ed., Rio de Janeiro: McGraw-Hill, 2006.RATIONAL. Rational Unified Process: ...
52ZANLORENCI, Edna Pacheco. BURNETT, Robert Carlisle. Abordagem daEngenharia de Requisitos para Software Legado. In: VI Wo...
53APÊNDICE A – FORMULÁRIO DE CONDUÇÃO DA REVISÃOFonte de Busca             PLoP – Conference On Pattern Languages         ...
54                              PLoP 1996 – 3rd Conference On Pattern                              Languages Of Programs –...
55                              http://www.cin.ufpe.br/~sugarloafplop/                              Sugar Loaf PLoP 2002 –...
56                      EuroPLoP 2006 – 11th European                      Conference On Pattern Languages Of             ...
57Quantidade Encontrada         7Quantidade Pré-selecionados   7Fonte de Busca                Meta PLoPEndereço Virtual   ...
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas
Próximos SlideShares
Carregando em…5
×

Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas

1.300 visualizações

Publicada em

Apresentação Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.300
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
26
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Pesquisa Um Mapeamento Sistemático sobre Padrões de Software para Reengenharia de Sistemas

  1. 1. UNIVERSIDADE ESTADUAL DO CEARÁ ERIVAN DE SENA RAMOS UM MAPEAMENTO SISTEMÁTICO SOBRE PADRÕESDE SOFTWARE PARA REENGENHARIA DE SISTEMAS FORTALEZA – CEARÁ 2011
  2. 2. ERIVAN DE SENA RAMOSUM MAPEAMENTO SISTEMÁTICO SOBRE PADRÕES DE SOFTWARE PARA REENGENHARIA DE SISTEMAS Monografia submetida à Coordenação do Curso de Especialização em Engenharia de Software com Ênfase em Padrões de Software da Universidade Estadual do Ceará, como requisito parcial para a obtenção do grau de Especialista em Engenharia de Software. Orientadora: Profa. Ma. Márcia Maria Albuquerque Brasil. FORTALEZA – CEARÁ 2011
  3. 3. R175m Ramos, Erivan de Sena Um mapeamento sistemático sobre padrões de software para reengenharia de sistemas / Erivan de Sena Ramos. — Fortaleza, 2011. 80 f. : il. ; 30cm. Orientadora: Profa. M.S. Márcia Maria Albuquerque Brasil. Monografia (Especialização em Engenharia de Software com Ênfase em Padrões de Software) – Universidade Estadual do Ceará, Centro de Ciências e Tecnologia. 1. Sistemas legados. 2. Reengenharia. 3. Padrões de software. 4. Mapeamento sistemático. 5. PLOP. 6. RUP. I. Título.
  4. 4. Aos meus pais, responsáveis pelos meusfundamentos éticos e morais.
  5. 5. AGRADECIMENTOSAo meu irmão Erivanio de Sena Ramos, pelo companheirismo.Aos colegas André Luis Araújo Paiva, Mateus Ribeiro Lima e Pedro HenriquePereira, pela parceria constituída durante o curso.A minha orientadora Profa. Ma. Márcia Maria Albuquerque Brasil, pelaconfiança depositada no projeto de pesquisa e o apoio durante a execução domesmo.Aos professores que lecionaram durante o curso, na pessoa do CoordenadorProf. Dr. Jerffeson Teixeira de Souza, pela imensa contribuição no meucrescimento acadêmico e profissional.Aos funcionários e colaboradores do curso e do Centro de Ciências eTecnologia, na pessoa do Sr. Wagner Souza da Silva, pela solicitude desempre.
  6. 6. “Você não consegue ligar os pontos olhandopra frente; você só consegue ligá-los olhandopra trás. Então você tem que confiar que ospontos se ligarão algum dia no futuro. Você temque confiar em algo – seu instinto, destino,vida, carma, o que for. Esta abordagem nuncame desapontou, e fez toda diferença na minhavida.” Steve Jobs
  7. 7. RESUMOA utilização de sistemas legados é uma realidade em muitas organizações.Para acompanhar mudanças em suas regras de negócio, esses sistemasprecisam passar por manutenções, para que possam evoluir de acordo com anecessidade das organizações. Uma série de fatores tais como documentaçãodesatualizada ou inexistente, códigos complicados e projetos não extensíveis,pode tornar essas manutenções difíceis e de custo alto. Nestes casoscomumente utiliza-se da reengenharia, um processo para análise de sistemaslegados que visa aumentar a vida útil de tais sistemas e reduzir os custos demanutenção. Com a perspectiva de dirimir os problemas enfrentados duranteum processo de reengenharia, os padrões de software surgem como umaalternativa viável. Nesse contexto, este trabalho teve como objetivo investigar,catalogar e classificar os padrões para reengenharia de sistemas publicadosem conferências e workshops PLoP (Pattern Languages of Programs), pormeio de um estudo de mapeamento sistemático. Além da catalogaçãobibliográfica, o estudo apresenta a totalização dos padrões quanto ao tipo deprocesso de reengenharia; o levantamento das linguagens de programaçãoabordadas, as Conferências e Workshops onde os padrões foram publicados,bem como a evolução das publicações por ano. Quanto à classificação, ospadrões de reengenharia foram categorizados de acordo com as disciplinas doRUP (Rational Unified Process).Palavras-chave: Sistemas Legados. Reengenharia. Padrões de Software.PLoP. RUP. Mapeamento Sistemático.
  8. 8. ABSTRACTNumerous organizations present use the legacy systems. These systems mustundergo maintenance in order to evolve according to the need fororganizations, following the changes of business rules. Some factors such asoutdated documentation or no documentation, complicated source codes andnot extensible projects can make maintenance difficult and expensive. In thesecases is commonly used the reengineering process, that is a model for analysisof legacy systems. In view of solving the problems encountered in the processof reengineering, software patterns emerge as a viable alternative. Througha systematic mapping studies, this work aimed to investigate, catalog andclassify the patterns for systems reengineering published in conferences andworkshops PLoP (Pattern Languages of Programs). In addition to catalogingliterature, the study presents the aggregation of standards regarding the typeof process reengineering, the survey of programming languages discussed, aswell as conferences and workshops and the development of publications peryear. Regarding classification, patterns of re-engineering were categorizedaccording to the disciplines of the RUP (Rational Unified Process).Keywords: Legacy Systems. Reengineering. Software Patterns. PLoP. RUP.Systematic Mapping Studies.
  9. 9. LISTA DE FIGURASFIGURA 1 - Visão do RUP ............................................................................... 17FIGURA 2 - Componentes de um Sistema Legado.......................................... 18FIGURA 3 - Modelo em Camadas de um sistema legado................................ 19FIGURA 4 - Engenharia Direta e Reengenharia .............................................. 21FIGURA 5 - Relacionamento entre termos de reengenharia ............................ 23FIGURA 6 - Uma abordagem das três etapas da Revisão Sistemática ........... 27FIGURA 7 - Processo da Revisão Sistemática ................................................ 28FIGURA 8 - Porcentagem de Padrões por Disciplina do RUP ......................... 39FIGURA 9 - Percentual de Padrões por Processo de Reengenharia ............... 42FIGURA 10 - Quantidade de Padrões por Linguagem de Programação.......... 43FIGURA 11 - Estudos publicados por ano ....................................................... 44FIGURA 12 - Padrões apresentados por ano................................................... 45
  10. 10. LISTA DE TABELASTABELA 1 - Critérios de Inclusão e Exclusão .................................................. 32TABELA 2 - Critérios de Qualidade .................................................................. 33TABELA 3 - Catalogação dos Padrões de Reengenharia de Sistemas ........... 36TABELA 4 - Classificação dos Padrões de Reengenharia por Disciplina do RUP ...................................................................................................... 39
  11. 11. SUMÁRIO1 INTRODUÇÃO ...................................................................................... 121.1 MOTIVAÇÃO ......................................................................................... 121.2 OBJETIVOS........................................................................................... 131.2.1 Objetivos Gerais .................................................................................... 131.2.2 Objetivos Específicos............................................................................. 131.3 ESTRUTURA DO TRABALHO .............................................................. 132 FUNDAMENTAÇÃO TEÓRICA ............................................................ 152.1 PROCESSO DE ENGENHARIA DE SOFTWARE ................................. 152.2 SISTEMAS LEGADOS .......................................................................... 172.3 REENGENHARIA DE SISTEMAS ......................................................... 212.4 PADRÕES DE SOFTWARE .................................................................. 232.5 REVISÃO SISTEMÁTICA EM ENGENHARIA DE SOFTWARE ............ 262.5.1 Planejamento da Revisão ...................................................................... 272.5.2 Condução da Revisão............................................................................ 282.5.3 Publicação dos Resultados.................................................................... 292.6 MAPEAMENTO SISTEMÁTICO ............................................................ 293 MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE SOFTWARE PARA REENGENHARIA DE SISTEMAS ............................................. 303.1 PLANEJAMENTO – DEFINIÇÃO DO PROTOCOLO ............................ 303.1.1 Descrição do Problema.......................................................................... 303.1.2 Objetivo.................................................................................................. 303.1.3 Questões de Pesquisa ........................................................................... 303.1.4 Palavras-Chave ..................................................................................... 313.1.5 Método Utilizado para Pesquisa de Fontes Primárias ........................... 323.1.6 Critérios para Inclusão e Exclusão dos Estudos .................................... 323.1.7 Critério de Qualidade dos Estudos ........................................................ 333.1.8 Método de Avaliação dos Estudos ......................................................... 333.1.9 Método de Extração dos Dados ............................................................. 333.1.10 Método da Síntese dos Dados............................................................... 343.2 CONDUÇÃO DA REVISÃO ................................................................... 343.3 APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS ..... 353.3.1 Resultados obtidos para a questão 1 (Q1) ............................................ 353.3.2 Resultados obtidos para a questão 2 (Q2) ............................................ 383.3.3 Resultados obtidos para a questão 3 (Q3) ............................................ 423.3.4 Resultados obtidos para a questão 4 (Q4) ............................................ 433.3.5 Resultados obtidos para a questão 5 (Q5) ............................................ 444 CONCLUSÃO ........................................................................................ 46 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................... 48 APÊNDICE A – FORMULÁRIO DE CONDUÇÃO DA REVISÃO .......... 53 APÊNDICE B – FORMULÁRIO DE SELEÇÃO DOS ESTUDOS .......... 61 APÊNDICE C – FORMULÁRIO DE EXTRAÇÃO DOS DADOS ............ 67 APÊNDICE D – CLASSIFICAÇÃO DOS PADRÕES DE REENGENHARIA POR DISCIPLINA DO RUP ..................................... 75
  12. 12. 121 INTRODUÇÃO1.1 MOTIVAÇÃO As organizações têm um custo alto de dinheiro quando investem emum software e, para que haja um retorno financeiro satisfatório, este software éutilizado por muitos anos (SOMMERVILLE, 2007). Em contrapartida, o softwareé um produto que deve estar em constante evolução de acordo com mudançasnas regras de negócio das organizações, necessidade de melhoria do processoprodutivo ou adequação do produto ou serviço que utiliza tecnologia dainformação (ZANCORENCI; BURNETT, 2003). A esses softwares utilizados ao longo do tempo pelas organizaçõesdá-se o nome de sistemas legados. Tais sistemas normalmente não possuemdocumentação, ou possuem documentação desatualizada. Esses, dentreoutros fatores, dificultam e aumentam o custo da manutenção dos mesmos;incentivando os pesquisadores a buscarem soluções que facilitem a reduçãodos custos com manutenção (PERES et al., 2003). Quando um importante sistema legado não tem mais capacidade desuportar as mudanças em seus requisitos, comumente, é submetido aoprocesso de reengenharia (DUCASSE et al., 1998), que consiste em umprocesso de análise de sistemas legados que identifica e representa seuscomponentes em um nível mais alto de abstração (RECCHIA; PENTEADO,2002). A reengenharia de sistemas apresenta-se como um dos maioresdesafios para os engenheiros de software, pois, embora trate um problemacomum e persistente nas organizações, seus resultados interferem diretamentena continuidade dos negócios das mesmas (RECCHIA et al., 2003). Diante desse contexto, os padrões de software surgem como umaferramenta capaz de auxiliar o engenheiro de software em um processo dereengenharia. Larman (2005) mostra que os padrões de software são descriçõesque aconselham soluções práticas para determinado problema; podendo seraplicados durante a modelagem e codificação de um software, de acordo como contexto e as circunstâncias apresentadas.
  13. 13. 13 Os padrões de software aplicados na reengenharia visam registrar oconhecimento sobre como modificar softwares legados, ajudam a diagnosticarproblemas, e identificam as soluções mais apropriadas aos novos requisitos(LEMOS, 2002). Nesse sentido, uma catalogação bibliográfica, bem como umaclassificação desses padrões, pode ajudar o engenheiro de software a localizare identificar rapidamente o melhor padrão a ser utilizado em seu projeto dereengenharia de software.1.2 OBJETIVOS1.2.1 Objetivos Gerais A partir da motivação exposta, este trabalho apresenta um estudo demapeamento sistemático, o qual é um modo mais amplo de revisãosistemática, realizado com o objetivo de investigar, catalogar e classificar ospadrões de software para reengenharia de sistemas, publicados emconferências e workshops especializados em padrões de software.1.2.2 Objetivos Específicos Os objetivos específicos do trabalho são: uma catalogaçãobibliográfica, a classificação dos padrões segundo as disciplinas do RationalUnified Process (RUP), a identificação das linhas de pesquisa quanto aosprocessos de reengenharia e linguagens de programação adotadas nospadrões incluídos na pesquisa.1.3 ESTRUTURA DO TRABALHO Este trabalho encontra-se dividido em 4 capítulos, incluindo estaintrodução. O Capítulo 2 apresenta uma fundamentação teórica sobre osprincipais conceitos que envolvem o Processo de Engenharia de Software,Sistemas Legados, a Reengenharia de Sistemas, Padrões de Software,Revisão Sistemática em Engenharia de Software e Mapeamento Sistemático.O Capítulo 3 descreve detalhadamente as fases de planejamento e conduçãodo mapeamento, bem como apresenta e discute os resultados obtidos.
  14. 14. 14Finalmente, o Capítulo 4 apresenta as considerações finais do trabalho. Osformulários utilizados na condução do mapeamento são apresentados nosApêndices A, B e C. No Apêndice D, são apresentadas a descrição e aclassificação dos padrões selecionados na pesquisa.
  15. 15. 152 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentados alguns conceitos necessários paraum melhor entendimento deste trabalho. Inicialmente aborda o Processo deEngenharia de Software. Em seguida, descreve o que são Sistemas Legados eReengenharia de Sistemas. Discorre também sobre Padrões de Software e suaimportância. Por fim, apresenta o processo de Revisão Sistemática emEngenharia de Software e Mapeamento Sistemático.2.1 PROCESSO DE ENGENHARIA DE SOFTWARE Sommerville (2007) define o processo de engenharia de softwarecomo um conjunto de atividades e resultados associados que derivam em umproduto de software. Cada vez mais o desenvolvimento dessas atividades édecorrente da ampliação e modificação de sistemas existentes. Sommerville(2007) indica ainda que os processos de software mais utilizados atualmentena engenharia de software são: − Modelo em Cascata: As atividades são separadas em fases. − Desenvolvimento Evolucionário: A execução das atividades realizada de forma incremental. − Engenharia baseada em componentes: Aplica-se o reuso de componentes. − Entrega Incremental e Desenvolvimento Espiral: Priorizam a iteração do processo. Outro processo bastante utilizado que merece destaque é o RationalUnified Process (RUP), pois combina todos os elementos dos demaisprocessos de engenharia de software (SOMMERVILLE, 2007). A IBM (2011),empresa proprietária da plataforma, assegura que o RUP apresenta umprocesso de desenvolvimento de software e uma arquitetura configurável, queoferece as melhores práticas comprovadas. Rezende (2005) fundamenta que o RUP é um processo deengenharia de software dinâmico e iterativo, idealizado em três visõesfundamentais: as atividades de desenvolvimento são orientadas por casos de
  16. 16. 16uso; o processo é iterativo e incremental; e o processo é centrado naarquitetura que engloba aspectos estáticos e dinâmicos do software. O RUP organiza as suas atividades e iterações em quatro fases,constituídas por 9 workflows (disciplinas). As quatro fases do RUP são: Concepção (Identificar as entidades,suas interações e avaliar a contribuição do sistema com o negócio); Elaboração(Entender o problema, estabelecer framework de arquitetura, desenvolverplano de projeto e identificar riscos); Construção (Colocar em prática o projeto,realizar o desenvolvimento e testes); e Transição (Disponibilizar o sistema parao usuário). As nove disciplinas do RUP são: Modelagem de Negócio (Modelaros processos de negócio do sistema); Requisitos (Identificar os agentes e oscasos de uso do sistema); Análise e Projeto (Modelar o projeto quanto a suaarquitetura); Implementação (Implementar e estruturar os componentes dosistema); Testes (Realizar os testes de forma iterativa em conjunto com aImplementação); Implantação (Distribuir e instalar uma nova versão dosistema); Gerenciamento da Configuração e Mudança (Gerenciar asmudanças do sistema); Gerenciamento do Projeto (Gerenciar odesenvolvimento do sistema); e Ambiente (Disponibilizar as ferramentasapropriadas para o desenvolvimento do sistema). Embora os nomes das disciplinas remetam a fasesseqüenciais, deve-se ter em mente que as fases de um processo iterativo sãodiferentes e que estes fluxos de trabalho podem ser ativados em qualquer fasedo processo de acordo com a iteração executada. O fluxo de trabalho doprojeto intercala essas nove disciplinas e repete este processo com ênfase eintensidade diferentes em cada iteração, conforme mostrado na Figura 1(RATIONAL, 1998). Filho [20--] indica que um processo de engenharia de software énecessário porque permite controlar as atividades de desenvolvimento,possibilita alocar tarefas para desenvolvedores específicos, especifica quaisartefatos precisam ser desenvolvidos em cada etapa e oferece critérios paramonitoramento das atividades.
  17. 17. 17 FIGURA 1 - Visão do RUP Fonte: Adaptado de Rational (1998). Devido à importância da utilização de um processo de engenharia desoftware e ao RUP apresentar-se como um processo maduro, reconhecido eque se destaca perante os demais processos existentes, o mesmo foi utilizadocomo meio de classificação para os padrões incluídos neste estudo.2.2 SISTEMAS LEGADOS Aos sistemas de software utilizados por vários anos, objeto deinvestimento de uma determinada organização, que depende dos serviçosfornecidos pelos mesmos, dá-se o nome de sistemas legados(SOMMERVILLE, 2007). Para manter um sistema legado eficaz, o mesmo deveser um produto em constante evolução. Sommerville (2007) apresenta os componentes de um sistemalegado conforme descrito a seguir e representado na Figura 2: − Hardware do sistema: Os sistemas legados podem estar codificados para hardwares que já não são mais disponíveis, causando onerosidade na manutenção e incompatibilidade com as atuais normas de compra da organização; − Software de apoio: Em muitos casos, os sistemas legados contam com softwares de apoio obsoletos e que não possuem mais suporte do fornecedor;
  18. 18. 18 − Software de aplicação: Geralmente, serviços de negócios por meio de programas desenvolvidos e acessados separadamente; − Dados de aplicação: Processados pelo sistema de aplicação. Podem ser inconsistentes e duplicados; − Processos de negócio: Utilizados para atingir os objetivos de negócios. Podem ser restringidos pela funcionalidade fornecida pelo sistema legado; − Políticas e regras de negócio: Definem a condução e restrição do negócio. Podem estar estritamente correlacionadas às definições do uso do Software de aplicação. FIGURA 2 - Componentes de um Sistema Legado Fonte: Sommerville (2007). Sommervillle (2007) indica ainda outra forma de apresentar oscomponentes de um sistema legado, por meio de uma representação emcamadas conforme ilustrado na Figura 3. O sistema legado é composto por uma série de camadas (Processosde negócios; Software de aplicação; Software de apoio; e Hardware), ondecada camada depende da sua camada abaixo, bem como da sua interface.Dessa forma, caso as interfaces fossem mantidas, seria possível realizaralterações somente dentro de uma camada sem afetar as demais. Mas, naprática, esse encapsulamento dificilmente funciona, pois as mudanças em umacamada do sistema legado geralmente afetam outras camadas acima ouabaixo (SOMMERVILLE, 2007).
  19. 19. 19 FIGURA 3 - Modelo em Camadas de um sistema legado Sistema sociotécnico Processos de negócios Software de aplicação Software de apoio Hardware Fonte: Sommerville (2007). Os sistemas legados podem vir a apresentar uma lista bem longa denão-conformidades, tais como: projetos não-extensíveis; código complicado;documentação pobre ou inexistente; casos de teste e resultados que nuncaforam arquivados; e um histórico de modificações mal gerido (PRESSMAN,2006). Segundo Cagnin (2000), a manutenção de um sistema legadogeralmente é realizada quando é necessário: adicionar funcionalidade; adaptaro sistema às novas tecnologias emergentes; corrigir erros; e adicionarmelhorias no sistema para facilitar manutenções futuras e melhorar aconfiabilidade. Estes fatores tornam as manutenções dos sistemas legados difíceise de alto custo, fazendo com que os desenvolvedores cheguem a abandonaros projetos de software (PERES et al. 2003). Entretanto, Araújo (2009) afirma que mudanças em um sistema sãoimportantes, pois é necessário que ele evolua, fique mais dinâmico, eapresente um valor a mais para os negócios. Salienta ainda que novosrequisitos podem surgir a qualquer momento para um sistema, porém éindispensável um planejamento por parte da organização, a qual deve sempreavaliar os prós e os contras da troca ou atualização do sistema para manter osseus negócios alinhados à tecnologia da informação. Na concepção de Lemos (2002), diante deste cenário, sãodisponibilizadas apenas três opções às organizações: manter os softwares
  20. 20. 20legados com a situação de desorganização e custos cada vez maiores; ouredesenvolver os softwares; ou realizar a reengenharia tanto para aumentarsua manutenibilidade quanto para implementá-los em um paradigma mais atualcom ou sem mudança de linguagem. Para Sommerville (2007), as organizações com orçamento limitadopara manter e atualizar seus sistemas legados devem realizar uma análiseminuciosa para definir precisamente qual a melhor estratégia a ser adotada nomomento de realizar a evolução do sistema legado. Assim, devem escolherentre as seguintes estratégias (as quais não são excludentes e podem seraplicadas em conjunto ou separadamente de acordo com o sistema legado aser evoluído): descartar o sistema completamente; deixar o sistema semalterações e continuar com a manutenção regular; realizar a reengenharia dosistema para aprimorar sua facilidade de manutenção; e substituir todo ou partedo sistema por um novo sistema. Descartar o sistema completamente é uma opção escolhida quandoo sistema legado não consegue mais atender com eficiência aos processos denegócio. Deixar o sistema sem alterações e continuar com a manutençãoregular é indicado quando o sistema legado ainda é necessário e aindaapresenta estabilidade e poucas solicitações de mudanças por parte dosusuários. Realizar a reengenharia do sistema para aprimorar sua facilidade demanutenção é uma opção quando houver degradação na qualidade (aindanecessária) do sistema legado, por conta de mudanças irregulares ocorridas aolongo do tempo. Já a substituição de todo ou parte do sistema por um novosistema deve ser realizada quando outros fatores impossibilitem a continuidadedo sistema legado, ou quando um novo sistema comercial possa ser adotado aum custo razoável. Na avaliação de um sistema legado devem ser observados detalhesdo ponto de vista de mercado (necessidade da utilização do sistema pelaorganização) e da perspectiva técnica (qualidade do software de aplicação, edo software e hardware de apoio do sistema), para fundamentar de forma maisprecisa sobre o destino do sistema legado (SOMMERVILLE, 2007). Lemos et al. (2003) indica que atualmente a reengenharia tem sido aforma mais adotada pelas organizações para manter/refazer seus sistemas
  21. 21. 21legados, tendo sempre como objetivo livrar-se das manutenções difíceis e dadegeneração de suas estruturas.2.3 REENGENHARIA DE SISTEMAS A reengenharia de sistemas tem como objetivo aprimorar a estruturae a facilidade de compreensão dos sistemas, tornando mais fácil a suamanutenção. A reengenharia pode envolver uma nova documentação,organização e reestruturação do sistema, além da modernização da linguageme modificação e atualização dos valores dos dados do sistema. Geralmente,não há alteração na funcionalidade do sistema legado e normalmente aarquitetura do sistema é mantida (SOMMERVILLE, 2007). A reengenharia recupera as informações de projeto do sistemaexistente e ainda possibilita o uso de tais informações para a alteração ereconstituição do mesmo, sempre com o intuito de melhorar a qualidade globaldo sistema (PRESSMAN, 2006). O processo de reengenharia é indicado para sistemas legados queainda apresentam grande utilidade para a organização, mas que possuem umamanutenção difícil (LEMOS et al. 2003). Sommerville (2007) fomenta que o processo de reengenharia sesobressai sobre as demais abordagens mais radicais de evolução de software,devido às seguintes vantagens: redução do risco e redução do custo. FIGURA 4 - Engenharia Direta e Reengenharia Fonte: Sommerville (2007). O que basicamente distingue o processo de reengenharia doprocesso de engenharia direta (desenvolvimento de um novo sistema) é o
  22. 22. 22ponto de partida para o desenvolvimento, conforme apresentado na Figura 4.Para a reengenharia, o sistema antigo serve como especificação e o processode desenvolvimento tem como base a compreensão e a transformação domesmo; e, para a engenharia direta, o desenvolvimento tem início a partir deuma especificação escrita, envolvendo o projeto e a implementação do novosistema (SOMMERVILLE, 2007). Chikofsky e Cross II (1990) indicam a terminologia empregada naanálise e entendimento dos sistemas legados, onde é empregada areengenharia de sistemas. Os termos, bem como suas relações, são definidosa seguir e apresentados na Figura 5: − Reengenharia: Apreciação e alteração do sistema de software, para reconstituí-lo em uma nova forma. Realiza a Engenharia Reversa seguida pela Engenharia Avante ou Reestruturação. − Engenharia Reversa: Processo de análise que tem por finalidade criar a representação do sistema em um nível mais alto de abstração. Identifica os componentes do sistema e suas relações. Cria a representação lógica do sistema. − Redocumentação: Criação ou revisão da documentação, utilizada para possibilitar melhor compreensão humana do sistema analisado. − Recuperação do Projeto: Identificação e registro de informações com maior nível de abstração sobre o conhecimento do domínio da aplicação e informações externas ao sistema. − Engenharia Avante: Processo de desenvolvimento de software que visa partir de um nível de abstração alto e chegar ao nível mais baixo. Realiza a implementação física a partir dos modelos lógicos e projeto do sistema. − Reestruturação: Transformação de uma forma de representação para outra no mesmo nível de abstração, preservando a funcionalidade e semântica do sistema. Nesse fluxo, a reengenharia é responsável por incluir alguma formade engenharia reversa e engenharia avante ou ainda reestruturação e
  23. 23. 23documentação. Enquanto a engenharia reversa percorre do nível mais baixo daaplicação até o nível mais alto (utilizando-se da recuperação do projeto paraaumentar o nível da abstração), a engenharia avante percorre o caminhocontrário, partindo dos requisitos, passando pelo projeto e concluindo naimplementação. FIGURA 5 - Relacionamento entre termos de reengenharia Fonte: Adaptado de Chikofsky e Cross II (1990). Sommerville (2007) ressalta um ponto primordial a ser observado nareengenharia: o aumento de custos; e indica quais os principais fatores quepodem influenciar nesse aumento: a qualidade do software que deve passarpela reengenharia; o apoio de ferramentas disponíveis para a reengenharia;extensão da conversão de dados; e a disponibilidade do pessoal especializado.2.4 PADRÕES DE SOFTWARE Diante dos problemas enfrentados pelos profissionais da indústria desoftware, surgem soluções comprovadamente boas e possíveis de seremreutilizadas. Os padrões de software tornam essas soluções mais acessíveispara serem utilizadas nos problemas recorrentes dos mais diversos domínios,seja organizacional, de análise, projeto ou implementação (OLIVEIRA, 2007).
  24. 24. 24 Braga (1998) afirma que os padrões de software surgem como umaferramenta de preservação das soluções de especificação, análise, projeto eimplementação, o que pode possibilitar uma melhoria na produtividade, naqualidade e, conseqüentemente, no custo do sistema. Os estudos sobre padrões tiveram início com os trabalhos deAlexander et. al. (1977), exemplificando e descrevendo seu método paradocumentação de padrões em arquitetura, tornando-se uma fundamentaçãobásica que poderia ser abstraída para a área de software. Anos depois,pesquisadores da área de tecnologia de informação, embasados nos estudosde Alexander et. al. (1977), começaram a abordar padrões como soluções paraproblemas que ocorriam freqüentemente no desenvolvimento de software. Noinício da década de 90, estabeleceu-se uma padronização quanto ao estilo e àforma de apresentação dessas soluções, permitindo a evolução e divulgação, efacilitando a comunicação entre os desenvolvedores (CAGNIN, 2000). Atualmente, os padrões de software já têm aplicação em váriasáreas na engenharia de software e são utilizados no desenvolvimento de umsoftware visando o reuso de soluções existentes sob os mais diferentes níveisde abstração (GIMENES et al., 1999). Larman (2005) assevera que um bom padrão é um parproblema/solução denominado e bem conhecido, documentado com indicaçõesque possibilitem a sua aplicação em novos contextos e situações similares; eque apresenta detalhes sobre seus compromissos, implementações evariações. Os padrões são descritos de forma explícita e organizada contendo,em geral, as seguintes informações: Nome do padrão, o problema a serresolvido, o contexto, a solução, as conseqüências, um uso conhecido e ospadrões que são a ele relacionados (VERONESE et al., 2002). Appleton (2002) indica que apesar dos padrões serem descritos emdiferentes formatos, existem alguns componentes que devem ser identificadosao se ler um padrão: − Nome: Todo padrão deve ter um nome significativo. − Problema: Indica o problema a ser resolvido pelo padrão. − Contexto: Pré-condições do problema para utilização da solução.
  25. 25. 25 − Forças: Impactos, influências e restrições relevantes para o problema. − Solução: Relacionamentos estáticos e regras dinâmicas descrevendo como obter o resultado desejado. − Exemplos: Aplicações do padrão que ilustram como o padrão é aplicado. − Resultados Esperados: O estado ou configuração do sistema após a aplicação do padrão. − Racional: Explicação das regras ou passos do padrão que explicam como e porque ele é aplicado. − Padrões Relacionados: Os relacionamentos do padrão com outros dentro da mesma linguagem ou sistema de padrões. − Usos Conhecidos: Ocorrências conhecidas do padrão e sua aplicação em sistemas existentes. No entendimento de Coplien (2000), a utilização de padrões em umprojeto de software contribui para uma maior produtividade, diminuição dotempo e do custo de desenvolvimento, o que deriva em uma maior satisfaçãodo cliente, proporcionado maior qualidade no gerenciamento, menos tempo emenor esforço. A utilização de padrões na reengenharia pode reforçar a qualidade ea economia de tempo em projetos de manutenção de software legado. Aidentificação e a categorização de padrões possíveis de uso com este fim seapresentam como algo viável e importante, contribuindo para um processo dedesenvolvimento de software de qualidade. Veronese (2002) conclui que um esquema de organização para ospadrões existentes é importante para tornar mínimo o esforço dosdesenvolvedores na busca dos mais adequados a sua necessidade, pois,conforme Buschmann (1996), quanto maior o número de padrões em umsistema de padrões, maior é a dificuldade de localizá-los, entendê-los e utilizá-los.
  26. 26. 262.5 REVISÃO SISTEMÁTICA EM ENGENHARIA DE SOFTWARE De acordo com Kitchenham (2004), uma revisão sistemática é umestudo secundário que se utiliza de estudos primários (individuais) paraidentificar, avaliar e interpretar todas as pesquisas disponíveis relevantes parauma questão de pesquisa específica. Uma revisão sistemática sintetiza ostrabalhos existentes em conformidade com uma estratégia de busca pré-definida, garantindo a integridade da revisão. Mafra e Travassos (2006) indicam que a condução de revisõessistemáticas na Engenharia de Software pode beneficiar os mais diferentesstakeholders. Permite aos estudantes identificar diversas fontes de pesquisa,além de auxiliar na manutenção do foco ou desvio de foco da pesquisaconduzida. Propicia aos orientadores uma melhor monitoração da pesquisarealizada, além de fornecer subsídios que permitam identificar os riscosassociados à pesquisa. Disponibiliza para a comunidade acadêmica, acaracterização experimental de diversas tecnologias em uso. E por fimcontempla a indústria de software com os resultados experimentais einformações obtidas que podem ser utilizadas como apoio à tomada dedecisão. Ainda segundo Kitchenham (2004), dentre as principais razões paraa realização de uma revisão sistemática destacam-se: resumir as evidênciasexistentes; identificar as eventuais lacunas na pesquisa atual, a fim de sugeriráreas de investigação mais aprofundada; e fornecer um quadro da posição dasnovas atividades de investigação. Uma revisão sistemática pode ainda ser realizada para examinar aextensão e evidências das hipóteses teóricas ou auxiliar na geração de novashipóteses. Para melhorar o entendimento da realização de uma revisãosistemática, Biolchini et. al. (2005) descreveram as atividades de forma maisampla, conforme representado na Figura 6.
  27. 27. 27 FIGURA 6 - Uma abordagem das três etapas da Revisão Sistemática Fonte: Adaptado de Biolchini et al. (2005) A revisão sistemática se inicia com os conceitos onde, de formaexplícita e formal, representa a descoberta do assunto em questão. A partir dosconceitos derivam-se os estudos, os quais representam os materiais quecontêm as informações e podem fornecer evidências sobre o tema do estudo.A partir destes estudos, são examinados e comparados os conteúdos dosmesmos, gerando resultados. Os resultados são analisados e sintetizados,para enfim se obter uma conclusão sobre o tema pesquisado. De forma mais completa, Kitchenham (2004) organizou as atividadesdo processo de revisão sistemática em três fases, que podem interagir entre si:Planejamento da Revisão, Condução da Revisão e Publicação dos Resultados.Estas fases são detalhadas a seguir e serão adotadas nesta pesquisa.2.5.1 Planejamento da Revisão O Planejamento da Revisão permite definir os objetivos da revisão eguiar a realização da mesma. Os estágios associados ao Planejamento darevisão são: identificação da necessidade de uma revisão e desenvolvimentode um protocolo de revisão. A identificação consiste na descoberta pelo pesquisador da realnecessidade da pesquisa. O protocolo de revisão descreve e orienta como será realizada arevisão sistemática, sendo constituído pelos seguintes elementos: descrição doproblema, objetivo, questões da pesquisa, palavras-chave, método utilizadopara pesquisa de fontes primárias, critérios para inclusão e exclusão dosestudos, critérios de qualidade dos estudos, métodos de avaliação dosestudos, método de extração dos dados e método da síntese dos dados. O protocolo da revisão sistemática tem como objetivo especificar osmétodos que serão utilizados. A utilização de um protocolo pré-definido énecessária para evitar a possibilidade de uma pesquisa tendenciosa, onde a
  28. 28. 28seleção de estudos individuais ou a análise seja impulsionada por expectativasdo pesquisador. Deve-se permitir ainda que a revisão seja passível deauditagem (KITCHENHAM, 2004) e repetida por outros pesquisadores (MAFRAe TRAVASSOS, 2006). As questões levantadas na pesquisa são consideradas sob trêspontos de vista: população (experimentos afetados pela intervenção);intervenções (tecnologias que abordam temas específicos); e resultados(fatores relevantes para a pesquisa).2.5.2 Condução da Revisão A condução da revisão abrange todas as atividades desenvolvidasdesde a etapa de execução da busca até a análise dos resultados. Todos os métodos utilizados são documentados em formulários decondução da revisão e de seleção dos estudos, com o objetivo de documentaro processo de busca. Os dados extraídos são avaliados quanto a suaqualidade, sintetizados e documentados em um formulário de extração dedados. Os estágios associados à condução da revisão são: realização dabusca; seleção dos estudos primários; avaliação da qualidade; extração dedados e monitoramento; e síntese dos dados. Biolchini et al. (2005) destacam, conforme indicado na Figura 7, queo protocolo da revisão deve ser sempre avaliado e, se forem encontradosproblemas, o pesquisador deve retornar para a fase de planejamento pararever o protocolo. Da mesma forma, se forem encontrados problemas naanálise dos resultados, a revisão sistemática deve ser re-executada. Salientamainda que todos os dados obtidos durante o processo devem ser armazenados. FIGURA 7 - Processo da Revisão Sistemática Fonte: Adaptado de Biolchini et al. (2005)
  29. 29. 292.5.3 Publicação dos Resultados Kitchenham (2004) adverte sobre a importância de comunicar osresultados de uma revisão sistemática de forma eficaz. A publicação dosresultados é uma etapa única, que envolve a publicação dos resultados daanálise e a divulgação junto aos potenciais interessados.2.6 MAPEAMENTO SISTEMÁTICO O mapeamento sistemático é um tipo de revisão sistemática, ondese realiza uma revisão mais ampla dos estudos primários, em busca deidentificar quais evidências estão disponíveis, bem como identificar lacunas noconjunto dos estudos primários onde seja direcionado o foco de revisõessistemáticas futuras e identificar áreas onde mais estudos primários precisamser conduzidos (KITCHENHAM et. al., 2004). O estudo de mapeamento sistemático fornece uma visão geral deuma área de pesquisa, identificando a quantidade, tipo de pesquisas,resultados disponíveis, além de freqüências de publicações ao longo do tempopara identificar tendências (PETERSEN et. al., 2008). Para a presente pesquisa foi realizado um mapeamento sistemático,por ser mais adequado ao escopo da mesma, utilizando-se da mesmametodologia de base da revisão sistemática com a intenção de se obter umarevisão rigorosa, confiável e passível de auditoria. O capítulo a seguir apresenta o processo do mapeamento sobre ospadrões de reengenharia de sistemas conduzido neste trabalho, bem comoanalisa os resultados de acordo com as questões de pesquisa previamentedefinidas.
  30. 30. 303 MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE SOFTWARE PARAREENGENHARIA DE SISTEMAS Este capítulo descreve todas as fases do mapeamento sistemáticorealizado neste trabalho.3.1 PLANEJAMENTO – DEFINIÇÃO DO PROTOCOLO3.1.1 Descrição do Problema Para que os sistemas legados se mantenham alinhados àsexpectativas dos negócios das organizações, é necessário que hajaconstantemente a manutenção e evolução dos mesmos. Devido à criticidadeexistente em projetos que prevêem a manutenção ou evolução de um sistemalegado, a utilização de Padrões de Software apresenta-se como umaalternativa viável no sentido de minimizar o consumo de tempo e de esforço,melhorar a qualidade do produto final e, por conseguinte, diminuir os custosfinanceiros do projeto à organização. Para diminuir a dificuldade de entendimento e utilização, se faznecessário um esquema de organização dos padrões existentes, que tratam dereengenharia em sistemas legados.3.1.2 Objetivo O foco deste mapeamento sistemático é identificar, catalogar, eclassificar os Padrões de Software documentados para reengenharia, com ointuito de contribuir de forma substancial no entendimento dos mesmos e torná-los de fácil consulta para o engenheiro de software. Pretende realizar ainda umlevantamento dos padrões publicados por tipo de processo, linguagem deprogramação, conferências/workshops e ano de publicação.3.1.3 Questões de Pesquisa As questões a serem respondidas ao final desta pesquisa são:
  31. 31. 31 Q1. Quais os padrões de reengenharia publicados nas Conferências e Workshops especializados em padrões de software? Q2. Como se classificam os padrões de reengenharia, publicados nas Conferências e Workshops especializados em padrões de software, quanto às disciplinas do processo de engenharia de software RUP? Q3. Os padrões publicados apresentados abordam qual tipo de processo de reengenharia: Engenharia Reversa, Engenharia Avante ou Reestruturação? Q4. Os usos conhecidos dos padrões publicados abordam quais linguagens de programação? Q5. Quais Conferências e Workshops têm apresentado em seus anais padrões para reengenharia de sistemas? Em quais anos? Quem se destaca em números de estudos e padrões publicados? População: − Publicações contendo Padrões de Software. Intervenção: − Padrões de Software para Reengenharia de Sistema. Resultados: − Catalogação Bibliográfica dos padrões de reengenharia; − Classificação dos padrões de reengenharia; − Totalização dos padrões quanto ao tipo de processo de reengenharia; − Levantamento das linguagens de programação abordadas em padrões de reengenharia; − Levantamento da evolução das publicações de padrões de reengenharia.3.1.4 Palavras-Chave As palavras-chave utilizadas como strings de busca são listadasabaixo: sistema legado; software legado; aplicação legada; padrão de
  32. 32. 32reengenharia; engenharia reversa; engenharia avante; reestruturação;reengenharia; legacy system; reengineering pattern; reverse engineering;forward engineering; restructuring; e reengineering.3.1.5 Método Utilizado para Pesquisa de Fontes Primárias O método utilizado para a pesquisa de fontes primárias foi realizarbuscas nos anais das conferências PLoP (Pattern Languages of Programs),grupo de conferências anuais apoiadas pelo The Hillside Group1, com oobjetivo de desenvolver e aperfeiçoar a arte de padrões de projeto de software:PLoP – Conference On Pattern Languages Of Programs; Sugarloaf PLoP –Conferência Latino-Americana em Linguagens de Padrões para Programação;EuroPLoP - European Conference On Pattern Languages Of Programs; MetaEuroPLoP; Asian PLoP - Asian Conference On Pattern Languages Of Program;ParaPLoP - Workshop on Parallel Programming Patterns; Scrum PLoP; VikingPLoP - Nordic Conference On Pattern Languages Of Programs; PEAM -European Workshop on Patterns for Enterprise Architecture Management;ChiliPloP; KoalaPLoP e MensorePLoP. A busca está documentada e apresentada no Apêndice A.3.1.6 Critérios para Inclusão e Exclusão dos Estudos Os critérios definidos para inclusão e exclusão dos estudos sãoapresentados a seguir na Tabela 1. TABELA 1 - Critérios de Inclusão e Exclusão1 Os estudos devem ter sido publicados nas Conferências e Workshops listados no item 3.1.5.2 Os estudos devem estar escritos em inglês ou português;3 Os estudos devem estar disponíveis na web;4 Os estudos que apresentem alguma das strings de busca em seu título, resumo/abstract ou palavras-chaves;1 O The Hillside Group (http://hillside.net/) promove o uso, registro, análise e suporte às novas práticasde linguagens de padrões de software.
  33. 33. 335 Os estudos devem apresentar a proposta de um ou mais padrões de reengenharia em sistemas. Os estudos que não atenderam aos critérios acima descritos forãodesconsiderados.3.1.7 Critério de Qualidade dos Estudos A única questão considerada para a qualidade dos estudos éapresentada a seguir na Tabela 2. TABELA 2 – Critérios de Qualidade1 Os estudos apresentam padrões de reengenharia documentados em um formato de escrita de padrões, descritos de forma explícita e organizada. Após a seleção dos estudos, somente são considerados os padrõesque apresentam a descrição completa do mesmo, garantindo dessa forma aintegridade do resultado da revisão.3.1.8 Método de Avaliação dos Estudos Cada estudo, realizado de acordo com o método estabelecido para apesquisa de fontes primárias, é avaliado de acordo com os critérios parainclusão e exclusão. Os estudos que se enquadram nesses critérios sãoutilizados para a finalidade da revisão sistemática.3.1.9 Método de Extração dos Dados A extração dos dados é realizada como descrito abaixo: a) O pesquisador aplica a estratégia de pesquisa para identificar os potenciais estudos primários. A identificação dos estudos primários é realizada por meio da leitura do título, resumo/abstract e palavras–chave em busca das strings de busca. A busca é registrada por meio de um Formulário de Condução da Revisão (Conforme Apêndice A);
  34. 34. 34 b) O conjunto de estudos é selecionado a partir da verificação dos critérios de inclusão e exclusão. A seleção (inclusão/exclusão) dos estudos é feita por meio de uma leitura superficial dos estudos primários, tendo como foco identificar os critérios estabelecidos. A etapa de seleção é documentada em um Formulário de Seleção dos Estudos (Conforme Apêndice B); c) Todos os estudos incluídos como resultados da pesquisa inicial são revisados, inteira e minuciosamente, por outro pesquisador. d) Os resultados são revisados por todos os pesquisadores envolvidos e quaisquer desacordos são discutidos e resolvidos. e) Os resultados da revisão, que conta com os detalhes das pesquisas realizadas nos estudos primários selecionados, são registrados em um Formulário de Extração dos Dados (Conforme Apêndice C).3.1.10 Método da Síntese dos Dados Foi realizada uma meta-análise sobre os dados quantitativos dosestudos. Os dados dos estudos selecionados são comparados, com afinalidade de realçar as similaridades e diferenças entre os estudos de acordocom as questões da pesquisa.3.2 CONDUÇÃO DA REVISÃO Dentre as fontes definidas inicialmente no protocolo somente não foipossível obter acesso aos anais das Conferências ChiliPloP; KoalaPLoP; eMensorePLoP. Desta forma, a busca foi realizada em 57 Anais de 9 tipos deConferências e Workshops especializadas em Padrões de Software, conformedetalhado a seguir: − PLoP: 17 edições, entre 1994 e 2004; − Sugarloaf PLoP: 08 edições, entre 2001 e 2010; − EuroPLoP: 16 edições, entre 1996 e 2011; − Meta EuroPLoP: 01 edição em 2011; − Asian PLoP: 01 edição em 2010;
  35. 35. 35 − ParaPLoP: 03 edições, entre 2009 e 2011 − Scrum PLoP: 02 edições, entre 2010 e 2011; − Viking PLoP: 07 edições, entre 2002 e 2008; e − PEAM: 02 edições, em 2009 e 2010. O processo de busca foi executado utilizando as palavras-chavedefinidas (subseção 3.4) e seguindo o método de pesquisa de fontes primáriasdo protocolo (subseção 3.5). O processo de busca está documentado noApêndice A. A consulta obteve êxito somente nas seguintes fontes: − PLoP: 3 estudos encontrados e pré-selecionados. − Sugar Loaf PLoP : 6 encontrados e pré-selecionados. − EuroPLoP: 7 encontrados e pré-selecionados. Desta forma, 16 estudos foram contabilizados, os quais foram lidos everificados através dos critérios de inclusão e exclusão estabelecidos. Aseleção dos estudos está documentada no Apêndice B. Dos 16 artigos pré-selecionados, 12 estavam de acordo com todosos critérios previstos no protocolo de revisão e tiveram seus dados extraídos eanalisados. Os 4 estudos excluídos não atendiam ao critério de inclusão eexclusão. A extração dos dados está documentada no Apêndice C.3.3 APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS Aqui são respondidas as questões de pesquisa delineadas noplanejamento da revisão. Nos 12 estudos selecionados, 67 padrões parareengenharia foram identificados.3.3.1 Resultados obtidos para a questão 1 (Q1) Os resultados relacionados com a questão “Q1 - Quais os padrõesde reengenharia publicados nas Conferências e Workshops especializados empadrões de software?”, são apresentados a seguir. Foi realizada a catalogação bibliográfica dos 67 padrõesselecionados no mapeamento sistemático, a qual é apresentada na Tabela 3.
  36. 36. 36 TABELA 3 - Catalogação dos Padrões de Reengenharia de SistemasId Título Referência1 Preparar o Processo de Reengenharia LEMOS et al., 20032 Planejar o Processo de Reengenharia3 Acompanhar o Progresso de Reengenharia4 Realizar Inspeção de Garantia de Qualidade5 Controlar a Configuração6 Elaborar Lista de Procedimentos e Funções7 Elaborar Lista de "Chama/Chamado Por"8 Modelar Dados do Software Legado9 Criar Lista de Anomalias10 Criar Visão OO de Dados11 Criar Diagramas de Caso de Uso do MASA12 Descrever Casos de Uso do MASA13 Abstrair Diagrama de Pseudo-Classes14 Criar Diagramas de Caso de Uso do MAS15 Descrever Casos de Uso do MAS16 Elaborar Diagrama de Classes de Projeto17 Construir Diagramas de Sequência18 Implementar as Classes19 Implementar a Lógica de Armazenamento20 Implementar a Lógica de Apresentação21 Speculate about Domain Objects DEMEYER et al., 2000a22 Reconstruct the Persistent Data23 Identify the Largest24 Recover the Refactorings25 Tie Code and Questions DEMEYER et al., 2000b26 Transform Self Conditional to Subclassing DEMEYER et al., 2000c27 Transform Client Conditional to Polymorphism28 Apply State29 Apply Null Object30 Type Check Elimination in a Provider DUCASSE et al., 1998
  37. 37. 37 Hierarchy31 Type Check Elimination in Clients32 The Bridge to the New Town KELLER, 200033 Reengineering for Parallelism MASSINGILL, 200534 Mile-Wide, Inch Deep O’CALLAGHAN, 200035 Keeper of the Flame36 Archetype37 Iniciar Análise dos Dados RECCHIA E PENTEADO,38 Definir Chaves 200239 Identificar Relacionamentos40 Criar Visão OO dos Dados41 Obter Cenários42 Construir Diagramas de Use Cases43 Elaborar a Descrição de Use Cases44 Tratar Anomalias45 Definir as Classes46 Definir Atributos47 Analisar Hierarquias48 Definir Métodos49 Construir Diagramas de Seqüência50 Definir hierarquia Chama/Chamado PERES et al., 200351 Identificar Casos de Uso52 Identificar Supostas Classes e Supostos Atributos53 Identificar Supostos Métodos54 Identificar Relacionamentos55 Identificar Cardinalidades56 Criar Supostas Classes e Supostos Atributos57 Alocar Supostos Métodos nas Supostas Classes58 Criar Especificações das Classes e dos Atributos59 Criar Especificações dos Métodos
  38. 38. 3860 Criar Casos de Uso61 Criar Diagrama de Seqüência62 Criar Especificações dos Relacionamentos e Cardinalidades63 Definir Plataforma RECCHIA et al., 200364 Converter o Banco de Dados65 Implementar Métodos66 Realizar Melhorias de Interface67 Reverse Variability Engineering SCHÜTZ, 2009 Alguns estudos (DEMEYER et al., 2000a; O’CALLAGHAN, 2000)ainda citavam padrões com suas descrições incompletas, os quais foramdesconsiderados para não afetarem as questões de pesquisa do mapeamentosistemático.3.3.2 Resultados obtidos para a questão 2 (Q2) Os resultados referentes a questão 2 “Q2 - Como se classificam ospadrões de reengenharia, publicados nas Conferências e Workshopsespecializados em padrões de software, quanto às disciplinas do processo deengenharia de software RUP?” são apresentados a seguir. Os padrões foram classificados de acordo com as 9 disciplinas doRUP, observando as características e propostas de cada padrão apresentado,relacionado-os com os propósitos e atividades realizadas em cada disciplina.Não foram levadas em consideração as linguagens ou grupos dos padrões,somente suas características individuais. A Figura 8 mostra graficamente a distribuição dos padrões após aclassificação realizada. Observa-se que a disciplina Análise e Projeto, com o percentual de66%, abrange o maior número dos padrões de reengenharia, seguida dadisciplina Requisitos com 13%. Já as disciplinas Testes e Implantação não sãoapresentadas no gráfico porque não envolvem nenhum padrão dereengenharia selecionado durante o mapeamento sistemático.
  39. 39. 39 FIGURA 8 - Porcentagem de Padrões por Disciplina do RUP A classificação dos padrões por disciplina do RUP é apresentada naTabela 4. O número identificador (Id), corresponde a seqüência definida naTabela 3. TABELA 4 - Classificação dos Padrões de Reengenharia por Disciplina do RUP Disciplina Id PadrãoModelagem de Negócios 1 Preparar o Processo de ReengenhariaRequisitos 11 Criar Diagramas de Caso de Uso do MASA 12 Descrever Casos de Uso do MASA 14 Criar Diagramas de Caso de Uso do MAS 15 Descrever Casos de Uso do MAS 41 Obter Cenários 42 Construir Diagramas de Use Cases 43 Elaborar a Descrição de Use Cases 51 Identificar Casos de Uso 60 Criar Casos de UsoAnálise e Projeto 6 Elaborar Lista de Procedimentos e Funções 7 Elaborar Lista de "Chama/Chamado Por" 8 Modelar Dados do Software Legado
  40. 40. 409 Criar Lista de Anomalias10 Criar Visão OO de Dados13 Abstrair Diagrama de Pseudo-Classes16 Elaborar Diagrama de Classe do Projeto17 Construir Diagramas de Sequência21 Speculate about Domain Objects22 Reconstruct the Persistent Data23 Identify the Largest24 Recover the Refactorings26 Transform Self Conditional to Subclassing27 Transform Client Conditional to Polymorphism28 Apply State29 Apply Null Object30 Type Check Elimination in a Provider Hierarchy31 Type Check Elimination in Clients33 Reengineering for Parallelism34 Mile-Wide, Inch Deep35 Keeper of the Flame36 Archetype37 Iniciar Análise dos Dados38 Definir Chaves39 Identificar Relacionamentos40 Criar Visão OO dos Dados41 Obter Cenários44 Tratar Anomalias45 Definir as Classes46 Definir Atributos47 Analisar Hierarquias48 Definir Métodos49 Construir Diagramas de Seqüência50 Definir hierarquia Chama/Chamado
  41. 41. 41 52 Identificar Supostas Classes e Supostos Atributos 53 Identificar Supostos Métodos 54 Identificar Relacionamentos 55 Identificar Cardinalidades 56 Criar Supostas Classes e Supostos Atributos 57 Alocar Supostos Métodos nas Supostas Classes 58 Criar Especificações das Classes e dos Atributos 59 Criar Especificações dos Métodos 61 Criar Diagrama de Seqüência 62 Criar Especificações dos Relacionamentos e Cardinalidades 67 Reverse Variability EngineeringImplementação 18 Implementar as Classes 19 Implementar a Lógica de Armazenamento 20 Implementar a Lógica de Apresentação 25 Tie Code and Questions 64 Converter o Banco de Dados 65 Implementar Métodos 66 Realizar Melhorias de InterfaceAmbiente 63 Definir PlataformaConfiguração e Gerência de 5 Controlar a ConfiguraçãoMudança 32 The Bridge to the New TownGerência de Projeto 2 Planejar o Processo de Reengenharia 3 Acompanhar o Progresso de Reengenharia 4 Realizar Inspeção de Garantia de Qualidade No Apêndice D, são apresentadas as descrições de cada padrãoselecionado para a pesquisa.
  42. 42. 423.3.3 Resultados obtidos para a questão 3 (Q3) Os resultados obtidos para a questão 3 “Q3 - Os padrões publicadosapresentados abordam qual tipo de processo de reengenharia (EngenhariaReversa, Engenharia Avante, Reestruturação)” são apresentados a seguir. No que se refere ao processo de reengenharia, os padrõesapresentados apresentam o seguinte panorama: • Total de Padrões de Engenharia Reversa: 49; • Total de Padrões de Engenharia Avante: 10; • Total de Padrões de Reestruturação: 3. FIGURA 9 - Percentual de Padrões por Processo de Reengenharia A Figura 9 representa de forma clara o quanto a EngenhariaReversa é o processo predominante abordado nas publicações, representando73% dos padrões apresentados e incluídos na pesquisa, enquanto que aEngenharia Avante representa 13% e a Reestruturação apenas 5% dospadrões de reengenharia. A publicação de Lemos et al.(2003) apresenta ainda 05 padrões quenão se enquadram nos três processos indicados. Os mesmos tratam daaplicação de diretrizes de qualidade durante o projeto.
  43. 43. 433.3.4 Resultados obtidos para a questão 4 (Q4) Os resultados em relação a questão 4 “Q4 - Os usos conhecidos dospadrões publicados abordam qual tipo de linguagem de programação?” sãoapresentados a seguir. Foram analisadas nos estudos quais as linguagens de programaçãoque podem utilizar-se dos padrões de reengenharia. Dos 67 padrões selecionados durante o mapeamento sistemático,28% não citam ou não especificam uma linguagem de programação nos usosconhecidos do padrão. Verificou-se então que as linguagens de programaçãoabordadas nos estudos, de usos conhecidos na aplicabilidade dos padrões dereengenharia, são: Java (02 padrões); Stalmak (07 padrões); C/C++ (11padrões); Ada (11 padrões); Clipper (17 padrões); COBOL (17 padrões); RPGII(17 padrões); e Delphi (20 padrões) A Figura 10 apresenta a quantidade de padrões que podem serempregados por cada linguagem de programação. Enquanto a linguagem deprogramação Delphi abrange uma maior quantidade de padrões dereengenharia, totalizando 20 padrões, a linguagem Java apresenta a menorabrangência com apenas 2 padrões. Em geral, nota-se uma predominância delinguagens de programação procedurais. FIGURA 10 - Quantidade de Padrões por Linguagem de Programação
  44. 44. 44 Vale ressaltar que, embora alguns padrões apresentem como usoconhecido uma linguagem de programação específica, nada impede que omesmo padrão seja adaptado para ser utilizado por outra linguagem. O estudo de Lemos et al. (2003) apresenta um bom exemplo disso,no qual os 20 padrões de reengenharia apresentados foram originalmentedesenvolvidos para serem usados em um sistema desenvolvido na linguagemClipper e depois foram instanciados para softwares implementados em Delphi.3.3.5 Resultados obtidos para a questão 5 (Q5) Os resultados em relação a questão 4 “Q4 - Quais Conferências eWorkshops têm apresentado publicações com padrões de reengenharia desistemas? Em quais anos? Quem se destaca em números de estudos epadrões publicados?” são apresentados a seguir. FIGURA 11 - Estudos publicados por ano De acordo com os estudos selecionados, foi verificada aperiodicidade das publicações sobre o tema analisado, bem como, o rankingdos padrões publicados, levando em conta a Conferência no qual o trabalho foidefendido e o ano de sua publicação. Na Figura 11, pode-se verificar aevolução do número de publicações com padrões de reengenharia. Pode-seinferir que o número de publicações tem sido pequena, com exceção do ano de2000 (um único trabalho foi o responsável, pois apresentou uma linguagem de
  45. 45. 45padrões) e 2003. Também é importante ressaltar que a EuroPLoP apresentaum maior número publicações relacionadas ao tema pesquisado. Quando se refere à quantidade de padrões apresentados nos artigosselecionados, a Figura 12 mostra que o ano de 2003 apresentou maior número.Conclui-se ainda que em se tratando de quantidade de padrões dereengenharia apresentados, o SugarLoafPLoP se destaca com o maior númerode publicações. FIGURA 12 - Padrões apresentados por ano Totalizando os anos de 2002 e 2003, o SugarLoafPLoP apresentou50 padrões de reengenharia em 4 publicações. Enquanto o EuroPLoPapresentou 16 padrões em 7 publicações (1998, 2000 e 2009) e o PLoPapresentou apenas 1 padrão (2005) sobre o tema.
  46. 46. 464 CONCLUSÃO Este trabalho teve por objetivo avaliar os padrões de software parareengenharia de sistemas através de um processo de mapeamentosistemático, um modo mais amplo de se aplicar o mapeamento sistemático. O mapeamento sistemático foi conduzida por meio de um protocolode revisão que especificou os métodos utilizados durante a condução dotrabalho. Os critérios definidos no protocolo foram necessários e suficientespara se obter os estudos primários necessários para a realização da pesquisa. A realização de um mapeamento sistemático se mostra umametodologia eficaz, embora dispendiosa de tempo, que envolve um trabalhoárduo de leitura e análise dos estudos primários para se obter respostas àsquestões levantadas para a pesquisa. A partir dos resultados obtidos na pesquisa, foi possível responderàs questões levantadas. Assim, foi possível realizar a catalogação bibliográficade 67 padrões relacionados à reengenharia de sistemas, bem como olevantamento dos processos e linguagens de programação abordadas, além daclassificação dos padrões selecionados de acordo com as disciplinas doprocesso de engenharia de software RUP. Acredita-se que a presente pesquisaapresenta benefícios paras os seguimentos acadêmico e profissional. No que diz respeito ao benefício acadêmico, os levantamentosquanto à linguagem de programação e ao processo de reengenharia apontamquais as áreas necessitam de mais pesquisas. No que se refere à linguagemde programação (levando em consideração os padrões que identificaram aslinguagens de programação abordadas), verificou-se que há um menor númerode padrões que atendem à reengenharia de linguagens de programaçãoorientadas a objetos. Quanto ao processo de reengenharia, padrões para aEngenharia Avante e para a Reestruturação estão em menor número(necessitando talvez de uma maior atenção por parte dos pesquisadores),enquanto que padrões que tratam de Engenharia Reversa são a maioria. No que diz respeito ao benefício profissional, a catalogaçãobibliográfica, bem como a classificação realizada, beneficiam o engenheiro desoftware no momento da seleção dos padrões a serem utilizados em um
  47. 47. 47projeto de reengenharia. Deste modo, este trabalho apresenta-se como umafonte de consulta a padrões de reengenharia de sistemas, onde é possíveleleger os padrões mais adequados e de acordo com a disciplina do processode engenharia de software.
  48. 48. 48REFERÊNCIAS BIBLIOGRÁFICASALEXANDER, Christopher. ISHIKAWA, Sara. SILVERSTEIN, Murray.LACOBSON, Max. FIKSDAHL-KING, Ingrid. ANGEL, Shlomo. A PatternLanguage. New York: Oxford University Press, 1977.APPLETON, Brad. Patterns and Software: Essential Concepts andTerminology. 2002. Disponível em: <http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html>. Acessado em: 01/08/2011.ARAÚJO, Érica Ciola de. Sistemas Legados: Uma Abordagem de Uso porParte das Empresas. 47f. Monografia (Tecnólogo em Informática com Ênfaseem Gestão em Negócios) – FATEC ZL, São Paulo, 2009.ASMAN, Paul. Legacy Wrapping. In: PLoP 2000 - 7th Conference On PatternLanguages Of Programs, Monticello, Illinois, USA, 2000.BIOLCHINI, Jorge. MIAN, Paula Gomes. NATALI, Ana Cândida Cruz.TRAVASSOS, Guilherme Horta. Systematic Review in SoftwareEngineering. 31f. Relatório Técnico (Programa de Engenharia de Sistemas eComputação) – COPPE/UFRJ, Rio de Janeiro, 2005.BRAGA, Rosana Terezinha Vaccare. Padrões de Software a partir daEngenharia Reversa de Sistemas Legados. 132f. Dissertação (Mestrado emCiências da Computação e Matemática Computacional) – USP, São Carlos,1998. (referência não utilizada no texto)BUSCHMANN, Frank. MEUNIER Regine. ROHNERT, Hans. SOMMERLAD,Petter. STAL, Michael. Pattern-Oriented Software Architecture, A System ofPatterns. West Sussex- Ingraterra: John Wiley & Sons, 1996.CAGNIN, Maria Istela. PARFAIT: uma contribuição para a reengenharia deSoftware baseada em linguagens de padrões e frameworks. 241f. Tese(Doutorado em Ciências da Computação e Matemática Computacional) –ICMC/USP, São Carlos, 2000.CAMARGO, Valter Vieira de. RECCHIA, Edson Luiz. PENTEADO, Rosângela.Aplicabilidade da Família de Padrões de Reengenharia FaPRE/OO naEngenharia Reversa Orientada a Objetos de Sistemas Legados COBOL.In: Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagensde Padrões para Programação, Rio de Janeiro, 2002.CHIKOFSKY, Elliot. CROSS II, James. Reverse Engineering and DesignRecovery: A Taxonomy. IEEE Software, v. 7, n. 1, 1990.
  49. 49. 49COPLIEN, James. C++ Idioms Patterns. In: Pattern Languages of ProgramDesign 4, Massachusetts, USA, 2000.DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. A PatternLanguage for Reverse Engineering. In: EuroPLoP 2000 – 5th EuropeanConference On Pattern Languages Of Programs, Irsee – Germany, 2000.DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. Tie CodeAnd Questions: a Reengineering Pattern. In: EuroPLoP 2000 – 5th EuropeanConference On Pattern Languages Of Programs, Irsee – Germany, 2000.DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. TransformConditionals: a Reengineering Pattern Language. In: EuroPLoP 2000 – 5thEuropean Conference On Pattern Languages Of Programs, Irsee – Germany,2000.DUCASSE, Stéphane. NEBBE, Robb. RICHNER, Tamar. Two ReengineeringPatterns: Eliminating Type Checking. In: 4° EuroPLOP, Alemanha, 1998.DUCASSE, Stéphane. NEBBE, Robb. RICHNER, Tamar. Type-CheckElimination: Two Reengineering Patterns. In: EuroPLoP 1998 – 3rdEuropean Conference On Pattern Languages Of Programs, Bad Irsee,Germany, 1998.FILHO, Antonio Mendes da Silva. Natureza do Software e a Necessidade dePrincípios e Processos. Engenharia de Software, n.25, ano 3, p. 13-35, [20--].Disponível em: <http://www.devmedia.com.br>. Acessado em: 28/08/2011.GIMENES, Itana Maria de Souza; WEISS, Gerson; HUZITA, Elisa HatsueMoriya . Um Padrão para Definição de um Gerenciador de Processos deSoftware. In: II Workshop Iberoamericano de Requisitos e Ambientes deSoftware, San Jose, Costa Rica, 1999.IBM. Rational Unified Process. Disponível em <http://www-01.ibm.com/software/br/rational/rup.shtml>. Acessado em: 01/08/2011.KELLER, Wolfgang. The Bridge to the New Town - A Legacy SystemMigration Pattern. In: EuroPLoP 2000 – 5th European Conference On PatternLanguages Of Programs, Irsee-Germany, 2000.KITCHENHAM, Barbara. Procedures for Performing Systematic Reviews.Technical Report Software Engineering Group, Keele University, Australia,2004.KITCHENHAM, Barbara. BRERETON, Pearl. TUNER, Mark. BUDGEN, David.Using Mapping Studies in Software Engineering. In: Proceedings of PPIG2008, Lancaster University, Inglaterra, 2008.
  50. 50. 50LARMAN, Craig. Utilizando UML e Padrões. 3ª ed., São Paulo: Bookman,2005.LEMOS, Gizelle RECCHIA, Edson. PENTEADO, Rosangela. BRAGA, Rosana.Padrões de Reengenharia auxiliados por Diretrizes de Qualidade deSoftware. In: Conferencia SugarLoafPLoP, Porto de Galinhas- PE, 2003.LEMOS, Gizelle Sandrini. PRE/OO – Um Processo de ReengenahriaOrientada a Objetos com Ênfase na Garantia da Qualidade. 171f.Dissertação (Mestre em Ciência da Computação) – Universidade Federal deSão Carlos, São Carlos, 2002.LEMOS, Gizelle; PENTEADO, Rosangela. PRE/OO - Um Processo deReengenharia Orientada a Objetos com Ênfase na Garantia da Qualidade.In: XVI Workshop de Teses e Dissertações. Rio de Janeiro- RJ, 2003.MAFRA, Sômulo Nogueira. TRAVASSOS, Guilherme Horta. EstudosPrimários e Secundários apoiando a busca por Evidência em Engenhariade Software. Relatório Técnico (Programa de Engenharia de Sistemas eComputação – COOPPE/UFRJ) – Universidade Federal do Rio de Janeiro, Riode Janeiro, 2006.MASSINGILL, Berna. MATTSON, Timothy. SANDERS, Beverly.Reengineering for Parallelism: An Entry Point into PLPP (PatternLanguage for Parallel Programming) for Legacy Applications. In: PLoP2005 – 12th Conference On Pattern Languages Of Programs, Monticello,Illinois, USA, 2005.O’CALLAGHAN, Alan. Patterns for Architectural Praxis. In: EuroPLoP 2000 –5th European Conference On Pattern Languages Of Programs, Irsee,NYrmany, 2000.OLIVEIRA, Rafael Braga de Oliveira. Framework Functest: AplicandoPadrões de Software na Automação de Testes Funcionais. 109f.Dissertação (Mestrado em Informática Aplicada) – Universidade de Fortaleza,Fortaleza, 2007.PERES, Darley Rosa. ALVARO, Alexandre. FONTANETTE, Valdirene.GARCIA, Vinicius Cardoso. PRADO, Antonio Francisco. BRAGA, RosanaTeresinha Vaccare. TB-REPP - Padrões de Processo para a EngenhariaReversa baseado em Transformações. In: Sugar Loaf PLoP 2003 – IIIConferencia Latino-Americana em Linguagens de Padrões para Programação,Porto de Galinhas- PE, 2003.PETERSEN, K. FELDT, R. MUJTABA, S. MATTSSON, M. SystematicMapping Studies in Software Engineering. In: 12th International Conferenceon Evaluation and Assessment in Software Engineering, Australia, 2008.
  51. 51. 51PRESSMAN, Roger. Engenharia de Software. 5ª. ed., Rio de Janeiro: McGraw-Hill, 2006.RATIONAL. Rational Unified Process: Best Practices for SoftwareDevelopment Teams. 1998. Disponível em <http://www.ibm.com/developerworks/rational/library/content/03July/1000/125/1251_bestpractices_TP026B.pdf>. Acessado em: 01/08/2011.RECCHIA, Edson Luiz. LEMOS, Gizelle Sandrini. PENTEADO, Rosângela.BRAGA, Rosana T.V. Padões para o Processo de Engenharia Avante naReengenharia Orientada a Objetos de Sistemas Legados Procedimentais.In: Sugar Loaf PLoP 2003 – III Conferencia Latino-Americana em Linguagensde Padrões para Programação Conferencia SugarloafPLoP, Porto de Galinhas-PE, 2003.RECCHIA, Edson Luiz. PENTEADO, Rosangela. Avaliação da Aplicabilidadeda Linguagem de Padrões de Engenharia Reversa de Demeyer a SistemasLegados Procedimentais. In: Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagens de Padrões para Programação, Rio de Janeiro,2002.RECCHIA, Edson Luiz. PENTEADO, Rosangela. FaPRE/OO: Uma Família dePadrões para Reengenharia Orientada aObjetos de Sistemas LegadosProcedimentais. In: Sugar Loaf PLoP 2002 – II Conferencia Latino-Americanaem Linguagens de Padrões para Programação, Rio de Janeiro, 2002.REZENDE, Denis Alcides. Engenharia de Software e Sistema deInformação. 3ª. ed., Rio de Janeiro: Brasport, 2005.SANTOS, Thiago. RAMOS, Rodrigo. KARLSSON, Börje. Usando Padrõespara Reestruturacão de uma Aplicação Legada. In: Sugar Loaf PLoP 2004– IV Conferencia Latino-Americana em Linguagens de Padrões paraProgramação, Ceará, 2004.SCHÜTZ, Dietmar. Reverse Variability Engineering. In: EuroPLoP 2009 –14th European Conference On Pattern Languages Of Programs, Bavaria-Germany, 2009.SOMMERVILLE, Ian. Engenharia de Software. 8ª. ed., São Paulo: Addison-Wesley, 2007.VERONESE Gustavo. DANTAS, Alexandre. CORREA, Alexandre. XAVIER,José Ricardo. WERNER, Cláudia. Suporte a Padrões no Projeto deSoftware. In: XVI Simpósio Brasileiro de Engenharia de Software, Gramado-RS, 2002.
  52. 52. 52ZANLORENCI, Edna Pacheco. BURNETT, Robert Carlisle. Abordagem daEngenharia de Requisitos para Software Legado. In: VI Workshop emEngenharia de Requisitos, Piracicaba- SP, 2003.
  53. 53. 53APÊNDICE A – FORMULÁRIO DE CONDUÇÃO DA REVISÃOFonte de Busca PLoP – Conference On Pattern Languages Of ProgramsEndereço Virtual PLoP 2010 – 17th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2010 PLoP 2009 – 16th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2009 PLoP 2008 – 15th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2008 PLoP 2007 – 14th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2007 PLoP 2006 – 13th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2006 PLoP 2005 – 12th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2005 PLoP 2004 – 11th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2004 PLoP 2003 – 10th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2003 PLoP 2002 – 9th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2002 PLoP 2001 – 8th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/2001 PLoP 2000 – 7th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop2k PLoP 1999 – 6th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop99 PLoP 1998 – 5th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop98 PLoP 1997 – 4th Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop97
  54. 54. 54 PLoP 1996 – 3rd Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop96 PLoP 1995 – 2nd Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop95 PLoP 1994 – 1st Conference On Pattern Languages Of Programs – http://www.hillside.net/plop/plop94Data da Busca 13/08/2011String de Busca “Sistema Legado”; “Software Legado”; “Aplicação Legada”; “Padrão de Reengenharia”; “Engenharia Reversa”; “Engenharia Avante”; “Reengenharia”; “Legacy System”; “Reengineering Pattern”; “Reverse Engineering”; “Forward Engineering”; “Reengineering”Período dos Estudos 1994 a 2010Quantidade Encontrada 3Quantidade Pré-selecionados 3Fonte de Busca Sugar Loaf PLoP – Conferência Latino- Americana em Linguagens de Padrões para ProgramaçãoEndereço Virtual Sugar Loaf PLoP 2010 – VIII Conferencia Latino-Americana em Linguagens de Padrões para Programação – http://wiki.dcc.ufba.br/SugarLoafPlop Sugar Loaf PLoP 2008 – VII Conferencia Latino-Americana em Linguagens de Padrões para Programação – http://sugarloafplop.comp.uece.br/ Sugar Loaf PLoP 2007 – VII Conferencia Latino-Americana em Linguagens de Padrões para Programação – http://sugarloafplop.dsc.upe.br/ Sugar Loaf PLoP 2004 – IV Conferencia Latino-Americana em Linguagens de Padrões para Programação – http://sugarloafplop2004.ufc.br/ Sugar Loaf PLoP 2003 – III Conferencia Latino-Americana em Linguagens de Padrões para Programação –
  55. 55. 55 http://www.cin.ufpe.br/~sugarloafplop/ Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagens de Padrões para Programação - http://lens.cos.ufrj.br/sugarloafplop/exibe.php Sugar Loaf PLoP 2001 – I Conferencia Latino-Americana em Linguagens de Padrões para Programação - http://lens.cos.ufrj.br/sugarloafplop/2001/Data da Busca 13/08/2011String de Busca “Sistema Legado”; “Software Legado”; “Aplicação Legada”; “Padrão de Reengenharia”; “Engenharia Reversa”; “Engenharia Avante”; “Reengenharia”; “Legacy System”; “Reengineering Pattern”; “Reverse Engineering”; “Forward Engineering”; “Reengineering”Período dos Estudos 2001 a 2004 e 2007 a 2010Quantidade Encontrada 6Quantidade Pré-selecionados 6Fonte de Busca EuroPLoP – European Conference On Pattern Languages Of ProgramsEndereço Virtual EuroPLoP 2011 – 16th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2011 EuroPLoP 2010 – 15th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2010 EuroPLoP 2009 – 14th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2009 EuroPLoP 2008 – 13th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2008 EuroPLoP 2007 – 12th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2007
  56. 56. 56 EuroPLoP 2006 – 11th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2006 EuroPLoP 2005 – 10th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2005 EuroPLoP 2004 – 9th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2004 EuroPLoP 2003 – 8th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2003 EuroPLoP 2002 – 7th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2002 EuroPLoP 2001 – 6th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2001 EuroPLoP 2000 – 5th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop2000 EuroPLoP 1999 – 4th European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop99 EuroPLoP 1998 – 3rd European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop98 EuroPLoP 1997 – 2nd European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop97 EuroPLoP 1996 – 1st European Conference On Pattern Languages Of Programs – http://hillside.net/europlop/europlop96Data da Busca 13/08/2011String de Busca “Sistema Legado”; “Software Legado”; “Aplicação Legada”; “Padrão de Reengenharia”; “Engenharia Reversa”; “Engenharia Avante”; “Reengenharia”; “Legacy System”; “Reengineering Pattern”; “Reverse Engineering”; “Forward Engineering”; “Reengineering”Período dos Estudos 1996 a 2011
  57. 57. 57Quantidade Encontrada 7Quantidade Pré-selecionados 7Fonte de Busca Meta PLoPEndereço Virtual Meta PLoP 2011 – http://metaplop.orgData da Busca 13/08/2011String de Busca “Sistema Legado”; “Software Legado”; “Aplicação Legada”; “Padrão de Reengenharia”; “Engenharia Reversa”; “Engenharia Avante”; “Reengenharia”; “Legacy System”; “Reengineering Pattern”; “Reverse Engineering”; “Forward Engineering”; “Reengineering”Período dos Estudos 2011Quantidade Encontrada 0Quantidade Pré-selecionados 0Fonte de Busca AsianPLoP – Asian Conference On Pattern Languages Of ProgramsEndereço Virtual AsianPLoP – 1st Asian Conference On Pattern Languages Of Programs – http://patterns- wg.fuka.info.waseda.ac.jp/asianplop/result- 2010.htmlData da Busca 13/08/2011String de Busca “Sistema Legado”; “Software Legado”; “Aplicação Legada”; “Padrão de Reengenharia”; “Engenharia Reversa”; “Engenharia Avante”; “Reengenharia”; “Legacy System”; “Reengineering Pattern”; “Reverse Engineering”; “Forward Engineering”; “Reengineering”Período dos Estudos 2010Quantidade Encontrada 0Quantidade Pré-selecionados 0

×