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

UNIVERSIDADE ESTADUAL DO CEARÁ

ERIVAN DE SENA RAMOS

UM MAPEAMENTO SISTEMÁTICO SOBRE PADRÕES DE SOFTWARE PARA REENGENHARIA DE SISTEMAS

FORTALEZA – CEARÁ 2011

ERIVAN DE SENA RAMOS

UM 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

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.

Aos meus pais, responsáveis pelos meus fundamentos éticos e morais.

AGRADECIMENTOS Ao meu irmão Erivanio de Sena Ramos, pelo companheirismo.

Aos colegas André Luis Araújo Paiva, Mateus Ribeiro Lima e Pedro Henrique Pereira, pela parceria constituída durante o curso.

A minha orientadora Profa. Ma. Márcia Maria Albuquerque Brasil, pela confiança depositada no projeto de pesquisa e o apoio durante a execução do mesmo.

Aos professores que lecionaram durante o curso, na pessoa do Coordenador Prof. Dr. Jerffeson Teixeira de Souza, pela imensa contribuição no meu crescimento acadêmico e profissional.

Aos funcionários e colaboradores do curso e do Centro de Ciências e Tecnologia, na pessoa do Sr. Wagner Souza da Silva, pela solicitude de sempre.

“Você não consegue ligar os pontos olhando pra frente; você só consegue ligá-los olhando pra trás. Então você tem que confiar que os pontos se ligarão algum dia no futuro. Você tem que confiar em algo – seu instinto, destino, vida, carma, o que for. Esta abordagem nunca me desapontou, e fez toda diferença na minha vida.”

Steve Jobs

RESUMO A utilização de sistemas legados é uma realidade em muitas organizações. Para acompanhar mudanças em suas regras de negócio, esses sistemas precisam passar por manutenções, para que possam evoluir de acordo com a necessidade das organizações. Uma série de fatores tais como documentação desatualizada ou inexistente, códigos complicados e projetos não extensíveis, pode tornar essas manutenções difíceis e de custo alto. Nestes casos comumente utiliza-se da reengenharia, um processo para análise de sistemas legados que visa aumentar a vida útil de tais sistemas e reduzir os custos de manutenção. Com a perspectiva de dirimir os problemas enfrentados durante um processo de reengenharia, os padrões de software surgem como uma alternativa viável. Nesse contexto, este trabalho teve como objetivo investigar, catalogar e classificar os padrões para reengenharia de sistemas publicados em conferências e workshops PLoP (Pattern Languages of Programs), por meio de um estudo de mapeamento sistemático. Além da catalogação bibliográfica, o estudo apresenta a totalização dos padrões quanto ao tipo de processo de reengenharia; o levantamento das linguagens de programação abordadas, as Conferências e Workshops onde os padrões foram publicados, bem como a evolução das publicações por ano. Quanto à classificação, os padrões de reengenharia foram categorizados de acordo com as disciplinas do RUP (Rational Unified Process). Palavras-chave: Sistemas Legados. Reengenharia. Padrões de Software. PLoP. RUP. Mapeamento Sistemático.

ABSTRACT Numerous organizations present use the legacy systems. These systems must undergo maintenance in order to evolve according to the need for organizations, following the changes of business rules. Some factors such as outdated documentation or no documentation, complicated source codes and not extensible projects can make maintenance difficult and expensive. In these cases is commonly used the reengineering process, that is a model for analysis of legacy systems. In view of solving the problems encountered in the process of reengineering, software patterns emerge as a viable alternative. Through a systematic mapping studies, this work aimed to investigate, catalog and classify the patterns for systems reengineering published in conferences and workshops PLoP (Pattern Languages of Programs). In addition to cataloging literature, the study presents the aggregation of standards regarding the type of process reengineering, the survey of programming languages discussed, as well as conferences and workshops and the development of publications per year. Regarding classification, patterns of re-engineering were categorized according to the disciplines of the RUP (Rational Unified Process). Keywords: Legacy Systems. Reengineering. Software Patterns. PLoP. RUP. Systematic Mapping Studies.

LISTA DE FIGURAS

FIGURA 1 - Visão do RUP ............................................................................... 17

FIGURA 2 - Componentes de um Sistema Legado .......................................... 18

FIGURA 3 - Modelo em Camadas de um sistema legado ................................ 19

FIGURA 4 - Engenharia Direta e Reengenharia .............................................. 21

FIGURA 5 - Relacionamento entre termos de reengenharia ............................ 23

FIGURA 6 - Uma abordagem das três etapas da Revisão Sistemática ........... 27

FIGURA 7 - Processo da Revisão Sistemática ................................................ 28

FIGURA 8 - Porcentagem de Padrões por Disciplina do RUP ......................... 39

FIGURA 9 - Percentual de Padrões por Processo de Reengenharia ............... 42

FIGURA 10 - Quantidade de Padrões por Linguagem de Programação .......... 43

FIGURA 11 - Estudos publicados por ano ....................................................... 44

FIGURA 12 - Padrões apresentados por ano................................................... 45

LISTA DE TABELAS

TABELA 1 - Critérios de Inclusão e Exclusão .................................................. 32

TABELA 2 - Critérios de Qualidade .................................................................. 33

TABELA 3 - Catalogação dos Padrões de Reengenharia de Sistemas ........... 36

TABELA 4 - Classificação dos Padrões de Reengenharia por Disciplina do RUP ...................................................................................................... 39

SUMÁRIO

1 INTRODUÇÃO ...................................................................................... 12

1.1 MOTIVAÇÃO ......................................................................................... 12

1.2 OBJETIVOS ........................................................................................... 13

1.2.1 Objetivos Gerais .................................................................................... 13

1.2.2 Objetivos Específicos............................................................................. 13

1.3 ESTRUTURA DO TRABALHO .............................................................. 13

2 FUNDAMENTAÇÃO TEÓRICA ............................................................ 15

2.1 PROCESSO DE ENGENHARIA DE SOFTWARE ................................. 15

2.2 SISTEMAS LEGADOS .......................................................................... 17

2.3 REENGENHARIA DE SISTEMAS ......................................................... 21

2.4 PADRÕES DE SOFTWARE .................................................................. 23

2.5 REVISÃO SISTEMÁTICA EM ENGENHARIA DE SOFTWARE ............ 26

2.5.1 Planejamento da Revisão ...................................................................... 27

2.5.2 Condução da Revisão............................................................................ 28

2.5.3 Publicação dos Resultados .................................................................... 29

2.6 MAPEAMENTO SISTEMÁTICO ............................................................ 29

3 MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE SOFTWARE PARA REENGENHARIA DE SISTEMAS ............................................. 30

3.1 PLANEJAMENTO – DEFINIÇÃO DO PROTOCOLO ............................ 30

3.1.1 Descrição do Problema.......................................................................... 30

3.1.2 Objetivo .................................................................................................. 30

3.1.3 Questões de Pesquisa ........................................................................... 30

3.1.4 Palavras-Chave ..................................................................................... 31

3.1.5 Método Utilizado para Pesquisa de Fontes Primárias ........................... 32

3.1.6 Critérios para Inclusão e Exclusão dos Estudos .................................... 32

3.1.7 Critério de Qualidade dos Estudos ........................................................ 33

3.1.8 Método de Avaliação dos Estudos ......................................................... 33

3.1.9 Método de Extração dos Dados ............................................................. 33

3.1.10 Método da Síntese dos Dados ............................................................... 34

3.2 CONDUÇÃO DA REVISÃO ................................................................... 34

3.3 APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS ..... 35

3.3.1 Resultados obtidos para a questão 1 (Q1) ............................................ 35





4 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

1 INTRODUÇÃO

1.1 MOTIVAÇÃO

As organizações têm um custo alto de dinheiro quando investem em

um 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ças

nas regras de negócio das organizações, necessidade de melhoria do processo

produtivo ou adequação do produto ou serviço que utiliza tecnologia da

informação (ZANCORENCI; BURNETT, 2003).

A esses softwares utilizados ao longo do tempo pelas organizações

dá-se o nome de sistemas legados. Tais sistemas normalmente não possuem

documentação, ou possuem documentação desatualizada. Esses, dentre

outros fatores, dificultam e aumentam o custo da manutenção dos mesmos;

incentivando os pesquisadores a buscarem soluções que facilitem a redução

dos custos com manutenção (PERES et al., 2003).

Quando um importante sistema legado não tem mais capacidade de

suportar as mudanças em seus requisitos, comumente, é submetido ao

processo de reengenharia (DUCASSE et al., 1998), que consiste em um

processo de análise de sistemas legados que identifica e representa seus

componentes em um nível mais alto de abstração (RECCHIA; PENTEADO,

2002).

A reengenharia de sistemas apresenta-se como um dos maiores

desafios para os engenheiros de software, pois, embora trate um problema

comum e persistente nas organizações, seus resultados interferem diretamente

na continuidade dos negócios das mesmas (RECCHIA et al., 2003).

Diante desse contexto, os padrões de software surgem como uma

ferramenta capaz de auxiliar o engenheiro de software em um processo de

reengenharia.

Larman (2005) mostra que os padrões de software são descrições

que aconselham soluções práticas para determinado problema; podendo ser

aplicados durante a modelagem e codificação de um software, de acordo com

o contexto e as circunstâncias apresentadas.

13

Os padrões de software aplicados na reengenharia visam registrar o

conhecimento sobre como modificar softwares legados, ajudam a diagnosticar

problemas, e identificam as soluções mais apropriadas aos novos requisitos

(LEMOS, 2002). Nesse sentido, uma catalogação bibliográfica, bem como uma

classificação desses padrões, pode ajudar o engenheiro de software a localizar

e identificar rapidamente o melhor padrão a ser utilizado em seu projeto de

reengenharia de software.

1.2 OBJETIVOS

1.2.1 Objetivos Gerais

A partir da motivação exposta, este trabalho apresenta um estudo de

mapeamento sistemático, o qual é um modo mais amplo de revisão

sistemática, realizado com o objetivo de investigar, catalogar e classificar os

padrões de software para reengenharia de sistemas, publicados em

conferê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ção

bibliográfica, a classificação dos padrões segundo as disciplinas do Rational

Unified Process (RUP), a identificação das linhas de pesquisa quanto aos

processos de reengenharia e linguagens de programação adotadas nos

padrões incluídos na pesquisa.

1.3 ESTRUTURA DO TRABALHO

Este trabalho encontra-se dividido em 4 capítulos, incluindo esta

introdução. O Capítulo 2 apresenta uma fundamentação teórica sobre os

principais 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ção

do mapeamento, bem como apresenta e discute os resultados obtidos.

14

Finalmente, o Capítulo 4 apresenta as considerações finais do trabalho. Os

formulários utilizados na condução do mapeamento são apresentados nos

Apêndices A, B e C. No Apêndice D, são apresentadas a descrição e a

classificação dos padrões selecionados na pesquisa.

15

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados alguns conceitos necessários para

um melhor entendimento deste trabalho. Inicialmente aborda o Processo de

Engenharia de Software. Em seguida, descreve o que são Sistemas Legados e

Reengenharia de Sistemas. Discorre também sobre Padrões de Software e sua

importância. Por fim, apresenta o processo de Revisão Sistemática em

Engenharia de Software e Mapeamento Sistemático.

2.1 PROCESSO DE ENGENHARIA DE SOFTWARE

Sommerville (2007) define o processo de engenharia de software

como um conjunto de atividades e resultados associados que derivam em um

produto 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 atualmente

na 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 Rational

Unified Process (RUP), pois combina todos os elementos dos demais

processos de engenharia de software (SOMMERVILLE, 2007). A IBM (2011),

empresa proprietária da plataforma, assegura que o RUP apresenta um

processo de desenvolvimento de software e uma arquitetura configurável, que

oferece as melhores práticas comprovadas.

Rezende (2005) fundamenta que o RUP é um processo de

engenharia de software dinâmico e iterativo, idealizado em três visões

fundamentais: as atividades de desenvolvimento são orientadas por casos de

16

uso; o processo é iterativo e incremental; e o processo é centrado na

arquitetura 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, desenvolver

plano de projeto e identificar riscos); Construção (Colocar em prática o projeto,

realizar o desenvolvimento e testes); e Transição (Disponibilizar o sistema para

o usuário).

As nove disciplinas do RUP são: Modelagem de Negócio (Modelar

os processos de negócio do sistema); Requisitos (Identificar os agentes e os

casos de uso do sistema); Análise e Projeto (Modelar o projeto quanto a sua

arquitetura); Implementação (Implementar e estruturar os componentes do

sistema); Testes (Realizar os testes de forma iterativa em conjunto com a

Implementação); Implantação (Distribuir e instalar uma nova versão do

sistema); Gerenciamento da Configuração e Mudança (Gerenciar as

mudanças do sistema); Gerenciamento do Projeto (Gerenciar o

desenvolvimento do sistema); e Ambiente (Disponibilizar as ferramentas

apropriadas para o desenvolvimento do sistema).

Embora os nomes das disciplinas remetam a fases

seqüenciais, deve-se ter em mente que as fases de um processo iterativo são

diferentes e que estes fluxos de trabalho podem ser ativados em qualquer fase

do processo de acordo com a iteração executada. O fluxo de trabalho do

projeto intercala essas nove disciplinas e repete este processo com ênfase e

intensidade 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 quais

artefatos precisam ser desenvolvidos em cada etapa e oferece critérios para

monitoramento das atividades.

17

FIGURA 1 - Visão do RUP

Fonte: Adaptado de Rational (1998).

Devido à importância da utilização de um processo de engenharia de

software e ao RUP apresentar-se como um processo maduro, reconhecido e

que se destaca perante os demais processos existentes, o mesmo foi utilizado

como 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 de

investimento de uma determinada organização, que depende dos serviços

fornecidos pelos mesmos, dá-se o nome de sistemas legados

(SOMMERVILLE, 2007). Para manter um sistema legado eficaz, o mesmo deve

ser um produto em constante evolução.

Sommerville (2007) apresenta os componentes de um sistema

legado 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

− 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 os

componentes de um sistema legado, por meio de uma representação em

camadas conforme ilustrado na Figura 3.

O sistema legado é composto por uma série de camadas (Processos

de negócios; Software de aplicação; Software de apoio; e Hardware), onde

cada camada depende da sua camada abaixo, bem como da sua interface.

Dessa forma, caso as interfaces fossem mantidas, seria possível realizar

alterações somente dentro de uma camada sem afetar as demais. Mas, na

prática, esse encapsulamento dificilmente funciona, pois as mudanças em uma

camada do sistema legado geralmente afetam outras camadas acima ou

abaixo (SOMMERVILLE, 2007).

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


Os sistemas legados podem vir a apresentar uma lista bem longa de

não-conformidades, tais como: projetos não-extensíveis; código complicado;

documentação pobre ou inexistente; casos de teste e resultados que nunca

foram arquivados; e um histórico de modificações mal gerido (PRESSMAN,

2006).

Segundo Cagnin (2000), a manutenção de um sistema legado

geralmente é realizada quando é necessário: adicionar funcionalidade; adaptar

o sistema às novas tecnologias emergentes; corrigir erros; e adicionar

melhorias no sistema para facilitar manutenções futuras e melhorar a

confiabilidade.

Estes fatores tornam as manutenções dos sistemas legados difíceis

e de alto custo, fazendo com que os desenvolvedores cheguem a abandonar

os projetos de software (PERES et al. 2003).

Entretanto, Araújo (2009) afirma que mudanças em um sistema são

importantes, pois é necessário que ele evolua, fique mais dinâmico, e

apresente um valor a mais para os negócios. Salienta ainda que novos

requisitos podem surgir a qualquer momento para um sistema, porém é

indispensável um planejamento por parte da organização, a qual deve sempre

avaliar os prós e os contras da troca ou atualização do sistema para manter os

seus negócios alinhados à tecnologia da informação.

Na concepção de Lemos (2002), diante deste cenário, são

disponibilizadas apenas três opções às organizações: manter os softwares

20

legados com a situação de desorganização e custos cada vez maiores; ou

redesenvolver os softwares; ou realizar a reengenharia tanto para aumentar

sua manutenibilidade quanto para implementá-los em um paradigma mais atual

com ou sem mudança de linguagem.

Para Sommerville (2007), as organizações com orçamento limitado

para manter e atualizar seus sistemas legados devem realizar uma análise

minuciosa para definir precisamente qual a melhor estratégia a ser adotada no

momento de realizar a evolução do sistema legado. Assim, devem escolher

entre as seguintes estratégias (as quais não são excludentes e podem ser

aplicadas em conjunto ou separadamente de acordo com o sistema legado a

ser evoluído): descartar o sistema completamente; deixar o sistema sem

alterações e continuar com a manutenção regular; realizar a reengenharia do

sistema para aprimorar sua facilidade de manutenção; e substituir todo ou parte

do sistema por um novo sistema.

Descartar o sistema completamente é uma opção escolhida quando

o sistema legado não consegue mais atender com eficiência aos processos de

negócio. Deixar o sistema sem alterações e continuar com a manutenção

regular é indicado quando o sistema legado ainda é necessário e ainda

apresenta estabilidade e poucas solicitações de mudanças por parte dos

usuários. Realizar a reengenharia do sistema para aprimorar sua facilidade de

manutenção é uma opção quando houver degradação na qualidade (ainda

necessária) do sistema legado, por conta de mudanças irregulares ocorridas ao

longo do tempo. Já a substituição de todo ou parte do sistema por um novo

sistema deve ser realizada quando outros fatores impossibilitem a continuidade

do sistema legado, ou quando um novo sistema comercial possa ser adotado a

um custo razoável.

Na avaliação de um sistema legado devem ser observados detalhes

do ponto de vista de mercado (necessidade da utilização do sistema pela

organização) e da perspectiva técnica (qualidade do software de aplicação, e

do software e hardware de apoio do sistema), para fundamentar de forma mais

precisa sobre o destino do sistema legado (SOMMERVILLE, 2007).

Lemos et al. (2003) indica que atualmente a reengenharia tem sido a

forma mais adotada pelas organizações para manter/refazer seus sistemas

21

legados, tendo sempre como objetivo livrar-se das manutenções difíceis e da

degeneração de suas estruturas.

2.3 REENGENHARIA DE SISTEMAS

A reengenharia de sistemas tem como objetivo aprimorar a estrutura

e a facilidade de compreensão dos sistemas, tornando mais fácil a sua

manutenção. A reengenharia pode envolver uma nova documentação,

organização e reestruturação do sistema, além da modernização da linguagem

e modificação e atualização dos valores dos dados do sistema. Geralmente,

não há alteração na funcionalidade do sistema legado e normalmente a

arquitetura do sistema é mantida (SOMMERVILLE, 2007).

A reengenharia recupera as informações de projeto do sistema

existente e ainda possibilita o uso de tais informações para a alteração e

reconstituição do mesmo, sempre com o intuito de melhorar a qualidade global

do sistema (PRESSMAN, 2006).

O processo de reengenharia é indicado para sistemas legados que

ainda apresentam grande utilidade para a organização, mas que possuem uma

manutenção difícil (LEMOS et al. 2003).

Sommerville (2007) fomenta que o processo de reengenharia se

sobressai 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


O que basicamente distingue o processo de reengenharia do

processo de engenharia direta (desenvolvimento de um novo sistema) é o

22

ponto de partida para o desenvolvimento, conforme apresentado na Figura 4.

Para a reengenharia, o sistema antigo serve como especificação e o processo

de desenvolvimento tem como base a compreensão e a transformação do

mesmo; e, para a engenharia direta, o desenvolvimento tem início a partir de

uma especificação escrita, envolvendo o projeto e a implementação do novo

sistema (SOMMERVILLE, 2007).

Chikofsky e Cross II (1990) indicam a terminologia empregada na

análise e entendimento dos sistemas legados, onde é empregada a

reengenharia de sistemas. Os termos, bem como suas relações, são definidos

a 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 forma

de engenharia reversa e engenharia avante ou ainda reestruturação e

23

documentação. Enquanto a engenharia reversa percorre do nível mais baixo da

aplicação até o nível mais alto (utilizando-se da recuperação do projeto para

aumentar o nível da abstração), a engenharia avante percorre o caminho

contrário, partindo dos requisitos, passando pelo projeto e concluindo na

implementaçã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 na

reengenharia: o aumento de custos; e indica quais os principais fatores que

podem influenciar nesse aumento: a qualidade do software que deve passar

pela 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 de

software, surgem soluções comprovadamente boas e possíveis de serem

reutilizadas. Os padrões de software tornam essas soluções mais acessíveis

para serem utilizadas nos problemas recorrentes dos mais diversos domínios,

seja organizacional, de análise, projeto ou implementação (OLIVEIRA, 2007).

24

Braga (1998) afirma que os padrões de software surgem como uma

ferramenta de preservação das soluções de especificação, análise, projeto e

implementação, o que pode possibilitar uma melhoria na produtividade, na

qualidade e, conseqüentemente, no custo do sistema.

Os estudos sobre padrões tiveram início com os trabalhos de

Alexander et. al. (1977), exemplificando e descrevendo seu método para

documentação de padrões em arquitetura, tornando-se uma fundamentação

básica que poderia ser abstraída para a área de software. Anos depois,

pesquisadores da área de tecnologia de informação, embasados nos estudos

de Alexander et. al. (1977), começaram a abordar padrões como soluções para

problemas que ocorriam freqüentemente no desenvolvimento de software. No

iní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, e

facilitando 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 um

software visando o reuso de soluções existentes sob os mais diferentes níveis

de abstração (GIMENES et al., 1999).

Larman (2005) assevera que um bom padrão é um par

problema/solução denominado e bem conhecido, documentado com indicações

que possibilitem a sua aplicação em novos contextos e situações similares; e

que apresenta detalhes sobre seus compromissos, implementações e

variaçõ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 ser

resolvido, o contexto, a solução, as conseqüências, um uso conhecido e os

padrões que são a ele relacionados (VERONESE et al., 2002).

Appleton (2002) indica que apesar dos padrões serem descritos em

diferentes formatos, existem alguns componentes que devem ser identificados

ao 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

− 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 um

projeto de software contribui para uma maior produtividade, diminuição do

tempo e do custo de desenvolvimento, o que deriva em uma maior satisfação

do cliente, proporcionado maior qualidade no gerenciamento, menos tempo e

menor esforço.

A utilização de padrões na reengenharia pode reforçar a qualidade e

a economia de tempo em projetos de manutenção de software legado. A

identificação e a categorização de padrões possíveis de uso com este fim se

apresentam como algo viável e importante, contribuindo para um processo de

desenvolvimento de software de qualidade.

Veronese (2002) conclui que um esquema de organização para os

padrões existentes é importante para tornar mínimo o esforço dos

desenvolvedores na busca dos mais adequados a sua necessidade, pois,

conforme Buschmann (1996), quanto maior o número de padrões em um

sistema de padrões, maior é a dificuldade de localizá-los, entendê-los e utilizá-

los.

26

2.5 REVISÃO SISTEMÁTICA EM ENGENHARIA DE SOFTWARE

De acordo com Kitchenham (2004), uma revisão sistemática é um

estudo secundário que se utiliza de estudos primários (individuais) para

identificar, avaliar e interpretar todas as pesquisas disponíveis relevantes para

uma questão de pesquisa específica. Uma revisão sistemática sintetiza os

trabalhos 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ões

sistemáticas na Engenharia de Software pode beneficiar os mais diferentes

stakeholders. Permite aos estudantes identificar diversas fontes de pesquisa,

além de auxiliar na manutenção do foco ou desvio de foco da pesquisa

conduzida. Propicia aos orientadores uma melhor monitoração da pesquisa

realizada, além de fornecer subsídios que permitam identificar os riscos

associados à pesquisa. Disponibiliza para a comunidade acadêmica, a

caracterização experimental de diversas tecnologias em uso. E por fim

contempla a indústria de software com os resultados experimentais e

informações obtidas que podem ser utilizadas como apoio à tomada de

decisão.

Ainda segundo Kitchenham (2004), dentre as principais razões para

a realização de uma revisão sistemática destacam-se: resumir as evidências

existentes; identificar as eventuais lacunas na pesquisa atual, a fim de sugerir

áreas de investigação mais aprofundada; e fornecer um quadro da posição das

novas atividades de investigação.

Uma revisão sistemática pode ainda ser realizada para examinar a

extensão e evidências das hipóteses teóricas ou auxiliar na geração de novas

hipóteses.

Para melhorar o entendimento da realização de uma revisão

sistemática, Biolchini et. al. (2005) descreveram as atividades de forma mais

ampla, conforme representado na Figura 6.

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 forma

explícita e formal, representa a descoberta do assunto em questão. A partir dos

conceitos derivam-se os estudos, os quais representam os materiais que

contê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 dos

mesmos, 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 atividades

do 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 e

guiar a realização da mesma. Os estágios associados ao Planejamento da

revisão são: identificação da necessidade de uma revisão e desenvolvimento

de um protocolo de revisão.

A identificação consiste na descoberta pelo pesquisador da real

necessidade da pesquisa.

O protocolo de revisão descreve e orienta como será realizada a

revisão sistemática, sendo constituído pelos seguintes elementos: descrição do

problema, objetivo, questões da pesquisa, palavras-chave, método utilizado

para pesquisa de fontes primárias, critérios para inclusão e exclusão dos

estudos, critérios de qualidade dos estudos, métodos de avaliação dos

estudos, 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 os

mé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

seleção de estudos individuais ou a análise seja impulsionada por expectativas

do pesquisador. Deve-se permitir ainda que a revisão seja passível de

auditagem (KITCHENHAM, 2004) e repetida por outros pesquisadores (MAFRA

e TRAVASSOS, 2006).

As questões levantadas na pesquisa são consideradas sob três

pontos 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 desenvolvidas

desde a etapa de execução da busca até a análise dos resultados.

Todos os métodos utilizados são documentados em formulários de

condução da revisão e de seleção dos estudos, com o objetivo de documentar

o processo de busca. Os dados extraídos são avaliados quanto a sua

qualidade, sintetizados e documentados em um formulário de extração de

dados.

Os estágios associados à condução da revisão são: realização da

busca; seleção dos estudos primários; avaliação da qualidade; extração de

dados e monitoramento; e síntese dos dados.

Biolchini et al. (2005) destacam, conforme indicado na Figura 7, que

o protocolo da revisão deve ser sempre avaliado e, se forem encontrados

problemas, o pesquisador deve retornar para a fase de planejamento para

rever o protocolo. Da mesma forma, se forem encontrados problemas na

análise dos resultados, a revisão sistemática deve ser re-executada. Salientam

ainda 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

2.5.3 Publicação dos Resultados

Kitchenham (2004) adverte sobre a importância de comunicar os

resultados de uma revisão sistemática de forma eficaz. A publicação dos

resultados é uma etapa única, que envolve a publicação dos resultados da

aná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, onde

se realiza uma revisão mais ampla dos estudos primários, em busca de

identificar quais evidências estão disponíveis, bem como identificar lacunas no

conjunto dos estudos primários onde seja direcionado o foco de revisões

sistemáticas futuras e identificar áreas onde mais estudos primários precisam

ser conduzidos (KITCHENHAM et. al., 2004).

O estudo de mapeamento sistemático fornece uma visão geral de

uma área de pesquisa, identificando a quantidade, tipo de pesquisas,

resultados disponíveis, além de freqüências de publicações ao longo do tempo

para 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 mesma

metodologia de base da revisão sistemática com a intenção de se obter uma

revisão rigorosa, confiável e passível de auditoria.

O capítulo a seguir apresenta o processo do mapeamento sobre os

padrões de reengenharia de sistemas conduzido neste trabalho, bem como

analisa os resultados de acordo com as questões de pesquisa previamente

definidas.

30

3 MAPEAMENTO SITEMÁTICO SOBRE PADRÕES DE SOFTWARE PARA

REENGENHARIA DE SISTEMAS

Este capítulo descreve todas as fases do mapeamento sistemático

realizado neste trabalho.

3.1 PLANEJAMENTO – DEFINIÇÃO DO PROTOCOLO

3.1.1 Descrição do Problema

Para que os sistemas legados se mantenham alinhados às

expectativas dos negócios das organizações, é necessário que haja

constantemente a manutenção e evolução dos mesmos. Devido à criticidade

existente em projetos que prevêem a manutenção ou evolução de um sistema

legado, a utilização de Padrões de Software apresenta-se como uma

alternativa 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 custos

financeiros do projeto à organização.

Para diminuir a dificuldade de entendimento e utilização, se faz

necessário um esquema de organização dos padrões existentes, que tratam de

reengenharia em sistemas legados.

3.1.2 Objetivo

O foco deste mapeamento sistemático é identificar, catalogar, e

classificar os Padrões de Software documentados para reengenharia, com o

intuito de contribuir de forma substancial no entendimento dos mesmos e torná-

los de fácil consulta para o engenheiro de software. Pretende realizar ainda um

levantamento dos padrões publicados por tipo de processo, linguagem de

programaçã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

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 listadas

abaixo: sistema legado; software legado; aplicação legada; padrão de

32

reengenharia; 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 realizar

buscas nos anais das conferências PLoP (Pattern Languages of Programs),

grupo de conferências anuais apoiadas pelo The Hillside Group1, com o

objetivo 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; Meta

EuroPLoP; Asian PLoP - Asian Conference On Pattern Languages Of Program;

ParaPLoP - Workshop on Parallel Programming Patterns; Scrum PLoP; Viking

PLoP - 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ão

apresentados a seguir na Tabela 1.

TABELA 1 - Critérios de Inclusão e Exclusão

1 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áticas de linguagens de padrões de software.

33

5 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ão

desconsiderados.

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 Qualidade

1 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ões

que apresentam a descrição completa do mesmo, garantindo dessa forma a

integridade 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 a

pesquisa de fontes primárias, é avaliado de acordo com os critérios para

inclusão e exclusão. Os estudos que se enquadram nesses critérios são

utilizados 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

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 dos

estudos. Os dados dos estudos selecionados são comparados, com a

finalidade de realçar as similaridades e diferenças entre os estudos de acordo

com as questões da pesquisa.

3.2 CONDUÇÃO DA REVISÃO

Dentre as fontes definidas inicialmente no protocolo somente não foi

possível obter acesso aos anais das Conferências ChiliPloP; KoalaPLoP; e

MensorePLoP. Desta forma, a busca foi realizada em 57 Anais de 9 tipos de

Conferências e Workshops especializadas em Padrões de Software, conforme

detalhado 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

− 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-chave

definidas (subseção 3.4) e seguindo o método de pesquisa de fontes primárias

do protocolo (subseção 3.5). O processo de busca está documentado no

Apê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 e

verificados através dos critérios de inclusão e exclusão estabelecidos. A

seleção dos estudos está documentada no Apêndice B.

Dos 16 artigos pré-selecionados, 12 estavam de acordo com todos

os critérios previstos no protocolo de revisão e tiveram seus dados extraídos e

analisados. Os 4 estudos excluídos não atendiam ao critério de inclusão e

exclusã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 no

planejamento da revisão. Nos 12 estudos selecionados, 67 padrões para

reengenharia foram identificados.

3.3.1 Resultados obtidos para a questão 1 (Q1)

Os resultados relacionados com a questão “Q1 - Quais os padrões

de reengenharia publicados nas Conferências e Workshops especializados em

padrões de software?”, são apresentados a seguir.

Foi realizada a catalogação bibliográfica dos 67 padrões

selecionados no mapeamento sistemático, a qual é apresentada na Tabela 3.

36

TABELA 3 - Catalogação dos Padrões de Reengenharia de Sistemas

Id Título Referência

1 Preparar o Processo de Reengenharia LEMOS et al., 2003

2 Planejar o Processo de Reengenharia

3 Acompanhar o Progresso de Reengenharia

4 Realizar Inspeção de Garantia de Qualidade

5 Controlar a Configuração

6 Elaborar Lista de Procedimentos e Funções

7 Elaborar Lista de "Chama/Chamado Por"

8 Modelar Dados do Software Legado

9 Criar Lista de Anomalias

10 Criar Visão OO de Dados

11 Criar Diagramas de Caso de Uso do MASA

12 Descrever Casos de Uso do MASA

13 Abstrair Diagrama de Pseudo-Classes

14 Criar Diagramas de Caso de Uso do MAS

15 Descrever Casos de Uso do MAS

16 Elaborar Diagrama de Classes de Projeto

17 Construir Diagramas de Sequência

18 Implementar as Classes

19 Implementar a Lógica de Armazenamento

20 Implementar a Lógica de Apresentação

21 Speculate about Domain Objects DEMEYER et al., 2000a

22 Reconstruct the Persistent Data

23 Identify the Largest

24 Recover the Refactorings

25 Tie Code and Questions DEMEYER et al., 2000b

26 Transform Self Conditional to Subclassing DEMEYER et al., 2000c

27 Transform Client Conditional to Polymorphism

28 Apply State

29 Apply Null Object

30 Type Check Elimination in a Provider DUCASSE et al., 1998

37

Hierarchy

31 Type Check Elimination in Clients

32 The Bridge to the New Town KELLER, 2000

33 Reengineering for Parallelism MASSINGILL, 2005

34 Mile-Wide, Inch Deep O’CALLAGHAN, 2000

35 Keeper of the Flame

36 Archetype

37 Iniciar Análise dos Dados RECCHIA E PENTEADO,

2002 38 Definir Chaves

39 Identificar Relacionamentos

40 Criar Visão OO dos Dados

41 Obter Cenários

42 Construir Diagramas de Use Cases

43 Elaborar a Descrição de Use Cases

44 Tratar Anomalias

45 Definir as Classes

46 Definir Atributos

47 Analisar Hierarquias

48 Definir Métodos

49 Construir Diagramas de Seqüência

50 Definir hierarquia Chama/Chamado PERES et al., 2003

51 Identificar Casos de Uso

52 Identificar Supostas Classes e Supostos

Atributos

53 Identificar Supostos Métodos


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

38

60 Criar Casos de Uso

61 Criar Diagrama de Seqüência

62 Criar Especificações dos Relacionamentos e

Cardinalidades

63 Definir Plataforma RECCHIA et al., 2003

64 Converter o Banco de Dados

65 Implementar Métodos

66 Realizar Melhorias de Interface

67 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 foram

desconsiderados para não afetarem as questões de pesquisa do mapeamento

sistemático.


Os resultados referentes a questão 2 “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?” são apresentados a seguir.

Os padrões foram classificados de acordo com as 9 disciplinas do

RUP, 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 a

classificação realizada.

Observa-se que a disciplina Análise e Projeto, com o percentual de

66%, abrange o maior número dos padrões de reengenharia, seguida da

disciplina Requisitos com 13%. Já as disciplinas Testes e Implantação não são

apresentadas no gráfico porque não envolvem nenhum padrão de

reengenharia selecionado durante o mapeamento sistemático.

39

FIGURA 8 - Porcentagem de Padrões por Disciplina do RUP

A classificação dos padrões por disciplina do RUP é apresentada na

Tabela 4. O número identificador (Id), corresponde a seqüência definida na

Tabela 3.

TABELA 4 - Classificação dos Padrões de Reengenharia por Disciplina do RUP

Disciplina Id Padrão

Modelagem de Negócios 1 Preparar o Processo de Reengenharia

Requisitos 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 Uso

Aná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

9 Criar Lista de Anomalias

10 Criar Visão OO de Dados

13 Abstrair Diagrama de Pseudo-Classes

16 Elaborar Diagrama de Classe do Projeto

17 Construir Diagramas de Sequência

21 Speculate about Domain Objects

22 Reconstruct the Persistent Data

23 Identify the Largest

24 Recover the Refactorings

26 Transform Self Conditional to Subclassing

27 Transform Client Conditional to

Polymorphism

28 Apply State

29 Apply Null Object

30 Type Check Elimination in a Provider

Hierarchy

31 Type Check Elimination in Clients

33 Reengineering for Parallelism

34 Mile-Wide, Inch Deep

35 Keeper of the Flame

36 Archetype

37 Iniciar Análise dos Dados

38 Definir Chaves


40 Criar Visão OO dos Dados

41 Obter Cenários

44 Tratar Anomalias

45 Definir as Classes

46 Definir Atributos

47 Analisar Hierarquias

48 Definir Métodos

49 Construir Diagramas de Seqüência

50 Definir hierarquia Chama/Chamado

41

52 Identificar Supostas Classes e Supostos

Atributos

53 Identificar Supostos Métodos


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 Engineering

Implementaçã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 Interface

Ambiente 63 Definir Plataforma

Configuração e Gerência de

Mudança

5 Controlar a Configuração

32 The Bridge to the New Town

Gerê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ão

selecionado para a pesquisa.

42


Os resultados obtidos para a questão 3 “Q3 - Os padrões publicados

apresentados abordam qual tipo de processo de reengenharia (Engenharia

Reversa, Engenharia Avante, Reestruturação)” são apresentados a seguir.

No que se refere ao processo de reengenharia, os padrões

apresentados 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 Engenharia

Reversa é o processo predominante abordado nas publicações, representando

73% dos padrões apresentados e incluídos na pesquisa, enquanto que a

Engenharia Avante representa 13% e a Reestruturação apenas 5% dos

padrões de reengenharia.

A publicação de Lemos et al.(2003) apresenta ainda 05 padrões que

não se enquadram nos três processos indicados. Os mesmos tratam da

aplicação de diretrizes de qualidade durante o projeto.

43


Os resultados em relação a questão 4 “Q4 - Os usos conhecidos dos

padrões publicados abordam qual tipo de linguagem de programação?” são

apresentados a seguir.

Foram analisadas nos estudos quais as linguagens de programação

que 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 usos

conhecidos do padrão. Verificou-se então que as linguagens de programação

abordadas nos estudos, de usos conhecidos na aplicabilidade dos padrões de

reengenharia, são: Java (02 padrões); Stalmak (07 padrões); C/C++ (11

padrõ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 ser

empregados por cada linguagem de programação. Enquanto a linguagem de

programação Delphi abrange uma maior quantidade de padrões de

reengenharia, totalizando 20 padrões, a linguagem Java apresenta a menor

abrangência com apenas 2 padrões. Em geral, nota-se uma predominância de

linguagens de programação procedurais.

FIGURA 10 - Quantidade de Padrões por Linguagem de Programação

44

Vale ressaltar que, embora alguns padrões apresentem como uso

conhecido uma linguagem de programação específica, nada impede que o

mesmo 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 originalmente

desenvolvidos para serem usados em um sistema desenvolvido na linguagem

Clipper e depois foram instanciados para softwares implementados em Delphi.


Os resultados em relação a questão 4 “Q4 - Quais Conferências e

Workshops têm apresentado publicações com padrões de reengenharia de

sistemas? Em quais anos? Quem se destaca em números de estudos e

padrões publicados?” são apresentados a seguir.

FIGURA 11 - Estudos publicados por ano

De acordo com os estudos selecionados, foi verificada a

periodicidade das publicações sobre o tema analisado, bem como, o ranking

dos padrões publicados, levando em conta a Conferência no qual o trabalho foi

defendido e o ano de sua publicação. Na Figura 11, pode-se verificar a

evolução do número de publicações com padrões de reengenharia. Pode-se

inferir que o número de publicações tem sido pequena, com exceção do ano de

2000 (um único trabalho foi o responsável, pois apresentou uma linguagem de

45

padrões) e 2003. Também é importante ressaltar que a EuroPLoP apresenta

um maior número publicações relacionadas ao tema pesquisado.

Quando se refere à quantidade de padrões apresentados nos artigos

selecionados, 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 de

reengenharia apresentados, o SugarLoafPLoP se destaca com o maior número

de publicações.

FIGURA 12 - Padrões apresentados por ano

Totalizando os anos de 2002 e 2003, o SugarLoafPLoP apresentou

50 padrões de reengenharia em 4 publicações. Enquanto o EuroPLoP

apresentou 16 padrões em 7 publicações (1998, 2000 e 2009) e o PLoP

apresentou apenas 1 padrão (2005) sobre o tema.

46

4 CONCLUSÃO

Este trabalho teve por objetivo avaliar os padrões de software para

reengenharia de sistemas através de um processo de mapeamento

sistemático, um modo mais amplo de se aplicar o mapeamento sistemático.

O mapeamento sistemático foi conduzida por meio de um protocolo

de revisão que especificou os métodos utilizados durante a condução do

trabalho. Os critérios definidos no protocolo foram necessários e suficientes

para se obter os estudos primários necessários para a realização da pesquisa.

A realização de um mapeamento sistemático se mostra uma

metodologia eficaz, embora dispendiosa de tempo, que envolve um trabalho

árduo de leitura e análise dos estudos primários para se obter respostas às

questõ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áfica

de 67 padrões relacionados à reengenharia de sistemas, bem como o

levantamento dos processos e linguagens de programação abordadas, além da

classificação dos padrões selecionados de acordo com as disciplinas do

processo de engenharia de software RUP. Acredita-se que a presente pesquisa

apresenta benefícios paras os seguimentos acadêmico e profissional.

No que diz respeito ao benefício acadêmico, os levantamentos

quanto à linguagem de programação e ao processo de reengenharia apontam

quais as áreas necessitam de mais pesquisas. No que se refere à linguagem

de programação (levando em consideração os padrões que identificaram as

linguagens de programação abordadas), verificou-se que há um menor número

de padrões que atendem à reengenharia de linguagens de programação

orientadas a objetos. Quanto ao processo de reengenharia, padrões para a

Engenharia 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ção

bibliográfica, bem como a classificação realizada, beneficiam o engenheiro de

software no momento da seleção dos padrões a serem utilizados em um

47

projeto de reengenharia. Deste modo, este trabalho apresenta-se como uma

fonte de consulta a padrões de reengenharia de sistemas, onde é possível

eleger os padrões mais adequados e de acordo com a disciplina do processo

de engenharia de software.

48

REFERÊNCIAS BIBLIOGRÁFICAS

ALEXANDER, Christopher. ISHIKAWA, Sara. SILVERSTEIN, Murray. LACOBSON, Max. FIKSDAHL-KING, Ingrid. ANGEL, Shlomo. A Pattern Language. New York: Oxford University Press, 1977.

APPLETON, Brad. Patterns and Software: Essential Concepts and Terminology. 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 por Parte das Empresas. 47f. Monografia (Tecnólogo em Informática com Ênfase em Gestão em Negócios) – FATEC ZL, São Paulo, 2009.

ASMAN, Paul. Legacy Wrapping. In: PLoP 2000 - 7th Conference On Pattern Languages Of Programs, Monticello, Illinois, USA, 2000.

BIOLCHINI, Jorge. MIAN, Paula Gomes. NATALI, Ana Cândida Cruz. TRAVASSOS, Guilherme Horta. Systematic Review in Software Engineering. 31f. Relatório Técnico (Programa de Engenharia de Sistemas e Computação) – COPPE/UFRJ, Rio de Janeiro, 2005.

BRAGA, Rosana Terezinha Vaccare. Padrões de Software a partir da Engenharia Reversa de Sistemas Legados. 132f. Dissertação (Mestrado em Ciê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 of Patterns. West Sussex- Ingraterra: John Wiley & Sons, 1996.

CAGNIN, Maria Istela. PARFAIT: uma contribuição para a reengenharia de Software 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 na Engenharia Reversa Orientada a Objetos de Sistemas Legados COBOL. In: Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagens de Padrões para Programação, Rio de Janeiro, 2002.

CHIKOFSKY, Elliot. CROSS II, James. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, v. 7, n. 1, 1990.

49

COPLIEN, James. C++ Idioms Patterns. In: Pattern Languages of Program Design 4, Massachusetts, USA, 2000.

DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. A Pattern Language for Reverse Engineering. In: EuroPLoP 2000 – 5th European Conference On Pattern Languages Of Programs, Irsee – Germany, 2000.

DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. Tie Code And Questions: a Reengineering Pattern. In: EuroPLoP 2000 – 5th European Conference On Pattern Languages Of Programs, Irsee – Germany, 2000.

DEMEYER, Serge. DUCASSE, Stéphane. NIERSTRASZ, Oscar. Transform Conditionals: a Reengineering Pattern Language. In: EuroPLoP 2000 – 5th European Conference On Pattern Languages Of Programs, Irsee – Germany, 2000.

DUCASSE, Stéphane. NEBBE, Robb. RICHNER, Tamar. Two Reengineering Patterns: Eliminating Type Checking. In: 4° EuroPLOP, Alemanha, 1998.

DUCASSE, Stéphane. NEBBE, Robb. RICHNER, Tamar. Type-Check Elimination: Two Reengineering Patterns. In: EuroPLoP 1998 – 3rd European Conference On Pattern Languages Of Programs, Bad Irsee, Germany, 1998.

FILHO, Antonio Mendes da Silva. Natureza do Software e a Necessidade de Princí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 Hatsue Moriya . Um Padrão para Definição de um Gerenciador de Processos de Software. In: II Workshop Iberoamericano de Requisitos e Ambientes de Software, 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 System Migration Pattern. In: EuroPLoP 2000 – 5th European Conference On Pattern Languages 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 PPIG 2008, Lancaster University, Inglaterra, 2008.

50

LARMAN, 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 de Software. In: Conferencia SugarLoafPLoP, Porto de Galinhas- PE, 2003.

LEMOS, Gizelle Sandrini. PRE/OO – Um Processo de Reengenahria Orientada a Objetos com Ênfase na Garantia da Qualidade. 171f. Dissertação (Mestre em Ciência da Computação) – Universidade Federal de São Carlos, São Carlos, 2002.

LEMOS, Gizelle; PENTEADO, Rosangela. PRE/OO - Um Processo de Reengenharia 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. Estudos Primários e Secundários apoiando a busca por Evidência em Engenharia de Software. Relatório Técnico (Programa de Engenharia de Sistemas e Computação – COOPPE/UFRJ) – Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2006.

MASSINGILL, Berna. MATTSON, Timothy. SANDERS, Beverly. Reengineering for Parallelism: An Entry Point into PLPP (Pattern Language for Parallel Programming) for Legacy Applications. In: PLoP 2005 – 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: Aplicando Padrõ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, Rosana Teresinha Vaccare. TB-REPP - Padrões de Processo para a Engenharia Reversa baseado em Transformações. In: Sugar Loaf PLoP 2003 – III Conferencia Latino-Americana em Linguagens de Padrões para Programação, Porto de Galinhas- PE, 2003.

PETERSEN, K. FELDT, R. MUJTABA, S. MATTSSON, M. Systematic Mapping Studies in Software Engineering. In: 12th International Conference on Evaluation and Assessment in Software Engineering, Australia, 2008.

51

PRESSMAN, Roger. Engenharia de Software. 5ª. ed., Rio de Janeiro: Mc Graw-Hill, 2006.

RATIONAL. Rational Unified Process: Best Practices for Software Development 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 na Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais. In: Sugar Loaf PLoP 2003 – III Conferencia Latino-Americana em Linguagens de Padrões para Programação Conferencia SugarloafPLoP, Porto de Galinhas-PE, 2003.

RECCHIA, Edson Luiz. PENTEADO, Rosangela. Avaliação da Aplicabilidade da Linguagem de Padrões de Engenharia Reversa de Demeyer a Sistemas Legados 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 de Padrões para Reengenharia Orientada aObjetos de Sistemas Legados Procedimentais. In: Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagens de Padrões para Programação, Rio de Janeiro, 2002.

REZENDE, Denis Alcides. Engenharia de Software e Sistema de Informação. 3ª. ed., Rio de Janeiro: Brasport, 2005.

SANTOS, Thiago. RAMOS, Rodrigo. KARLSSON, Börje. Usando Padrões para Reestruturacão de uma Aplicação Legada. In: Sugar Loaf PLoP 2004 – IV Conferencia Latino-Americana em Linguagens de Padrões para Programaçã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 de Software. In: XVI Simpósio Brasileiro de Engenharia de Software, Gramado-RS, 2002.

52

ZANLORENCI, Edna Pacheco. BURNETT, Robert Carlisle. Abordagem da Engenharia de Requisitos para Software Legado. In: VI Workshop em Engenharia de Requisitos, Piracicaba- SP, 2003.

53

APÊNDICE A – FORMULÁRIO DE CONDUÇÃO DA REVISÃO

Fonte de Busca PLoP – Conference On Pattern Languages

Of Programs

Endereç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 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



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/plop94

Data da Busca 13/08/2011

String 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 2010

Quantidade Encontrada 3

Quantidade Pré-selecionados 3

Fonte de Busca Sugar Loaf PLoP – Conferência Latino-

Americana em Linguagens de Padrões para

Programação

Endereç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

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/









Período dos Estudos 2001 a 2004 e 2007 a 2010



Fonte de Busca EuroPLoP – European Conference On

Pattern Languages Of Programs

Endereç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




56









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/europlop96










57



Fonte de Busca Meta PLoP

Endereço Virtual Meta PLoP 2011 – http://metaplop.org









Período dos Estudos 2011



Fonte de Busca AsianPLoP – Asian Conference On Pattern

Languages Of Programs

Endereço Virtual AsianPLoP – 1st Asian Conference On Pattern Languages Of Programs – http://patterns-wg.fuka.info.waseda.ac.jp/asianplop/result-2010.html









Período dos Estudos 2010



58

Fonte de Busca ParaPLoP – Workshop on Parallel

Programming Patterns

Endereço Virtual ParaPLoP 2011 – 3rd Workshop on Parallel Programming Patterns – http://www.upcrc.illinois.edu/workshops/paraplop11

ParaPLoP 2010 – 2nd Workshop on Parallel Programming Patterns – http://www.upcrc.illinois.edu/workshops/paraplop10

ParaPLoP 2009 – 1st Workshop on Parallel Programming Patterns – http://www.upcrc.illinois.edu/workshops/paraplop09












Fonte de Busca ScrumPLoP

Endereço Virtual ScrumPLoP 2011 – http://www.scrumplop.org/scrumplop-2011-helsingoer-denmark

ScrumPLoP 2010 – http://www.scrumplop.org/scrumplop-2011-helsingoer-denmark








59





Fonte de Busca VikingPLoP – Nordic Conference On Pattern

Languages Of Programs

Endereço Virtual VikingPLoP 2008 – 7th Nordic Conference On Pattern Languages Of Programs – http://www.hillside.net/vikingplop/vikingplop2008

VikingPLoP 2007 – 6th Nordic Conference On Pattern Languages Of Programs – http://www.hillside.net/vikingplop/vikingplop2007



VikingPLoP 2004 – 3rd Nordic Conference On Pattern Languages Of Programs – http://www.hillside.net/vikingplop/vikingplop2004

VikingPLoP 2003 – 2nd Nordic Conference On Pattern Languages Of Programs – http://www.hillside.net/vikingplop/vikingplop2003

VikingPLoP 2002 – 1st Nordic Conference On Pattern Languages Of Programs – http://www.hillside.net/vikingplop/vikingplop2002









60




Fonte de Busca PEAM – European Workshop on Patterns for

Enterprise Architecture Management

Endereço Virtual PEAM2009 – 1st European Workshop on Patterns for Enterprise Architecture Management – http://wwwmatthes.in.tum.de/wikis/sebis/peam-2009

PEAM2010 – 2nd European Workshop on Patterns for Enterprise Architecture Management – http://wwwmatthes.in.tum.de/wikis/sebis/peam2010












61

APÊNDICE B – FORMULÁRIO DE SELEÇÃO DOS ESTUDOS

Título Legacy Wrapping

Autores Paul Asman

Ano da Publicação 2000

Fonte PLoP 2000 – 7th Conference On Pattern Languages Of Programs

Situação (incluído/excluído) Excluído

Critérios de Seleção Atendidos 1; 2; 3; 4

Critérios de Seleção Não Atendidos 5

Critério de Qualidade Atendido? Não

Título Padrões de Reengenharia Auxiliados por

Diretrizes de Qualidade de Software Autores Gizelle Sandrini Lemos;

Edson Luiz Recchia;

Rosângela D. Peteado;

Rosana T.V. Braga.


Fonte Sugar Loaf PLoP 2003 – III Conferencia Latino-Americana em Linguagens de Padrões para Programação

Situação (incluído/excluído) Incluído

Critérios de Seleção Atendidos 1; 2; 3; 4; 5

Critérios de Seleção Não Atendidos -

Critério de Qualidade Atendido? Sim

Título A Pattern Language for Reverse

Engineering Autores Serge Demeyer;

Stéphane Ducasse;

Oscar Nierstrasz


Fonte EuroPLoP 2000 – 5th European Conference On Pattern Languages Of Programs




62


Título Tie Code And Questions: a Reengineering

Pattern

Autores Serge Demeyer;

Stéphane Ducasse;

Oscar Nierstrasz







Título Transform Conditionals: a Reengineering

Pattern Language

Autores Serge Demeyer;

Stéphane Ducasse;

Oscar Nierstrasz







Título Type-Check Elimination: Two

Reengineering Patterns

Autores Stéphane Ducasse;

Robb Nebbe;

Tamar Richner


Fonte EuroPLoP 1998 – 3rd European Conference On Pattern Languages Of Programs


63




Título The Bridge to the New Town -

A Legacy System Migration Pattern

Autores Wolfgang Keller







Título Reengineering for Parallelism:

An Entry Point into PLPP (Pattern Language for Parallel Programming) for Legacy Applications

Autores Berna L. Massingill;

Timothy G. Mattson;

Beverly A. Sanders.







Título Patterns for Architectural Praxis

Autores Alan O’Callaghan





64



Título Aplicabilidade da Família de Padrões de

Reengenharia FaPRE/OO na Engenharia Reversa Orientada a Objetos de Sistemas Legados COBOL

Autores Valter Vieira de Camargo;

Edson Luiz Recchia;

Rosângela Penteado.


Fonte Sugar Loaf PLoP 2002 – II Conferencia Latino-Americana em Linguagens de Padrões para Programação





Título Avaliação da Aplicabilidade da Linguagem

de Padrões de Engenharia Reversa de Demeyer a Sistemas Legados Procedimentais

Autores Edson Luiz Recchia;








Título FaPRE/OO: Uma Família de Padrões para

Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais



65







Título TB-REPP - Padrões de Processo para a

Engenharia Reversa baseado em Transformações

Autores Darley Rosa Peres;

Alexandre Álvaro;

Valdirene Fontanette;

Vinicius C. Garcia;

Antonio Francisco do Prado.







Título Padrões para o Processo de Engenharia

Avante na Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais.


Gizelle Sandrinu Lemos;

Rosângela Penteado;

Rosana T.V. Braga.




66




Título Usando Padrões para Reestruturacão de

uma Aplicação Legada

Autores Thiago L. V. L. Santos;

Rodrigo T. Ramos;

Börje F. F. Karlsson


Fonte Sugar Loaf PLoP 2004 – IV Conferencia Latino-Americana em Linguagens de Padrões para Programação





Título Reverse Variability Engineering

Autores Dietmar Schütz







67

APÊNDICE C – FORMULÁRIO DE EXTRAÇÃO DOS DADOS

Título Padrões de Reengenharia Auxiliados por Diretrizes

de Qualidade de Software

Autores Gizelle Sandrini Lemos; Edson Luiz Recchia; Rosângela D. Peteado; Rosana T.V. Braga.


Fonte Sugar Loaf PLoP 2003 – III Conferencia Latino-

Americana em Linguagens de Padrões para

Programação

Objetivo do Estudo Apresentar e documentar padrões para realizar a

reengenharia de sistemas legados implementados

em Delphi de forma procedimental para sistemas

orientados a objetos presentes na linguagem Object

Pascal, utilizada no ambiente Delphi.

Descrição do Estudo Foram elaborados vinte padrões que se encontram

organizados em grupos relacionados às etapas de

engenharia reversa e engenharia avante e, ainda, à

qualidade de processo.

Comentários Processo de Reengenharia abordado:

• Engenharia Reversa: 10 padrões;

• Engenharia Avante: 05 padrões

O Estudo apresenta ainda 05 padrões que

tratam do processo de qualidade na

Reengenharia.

Linguagem de Programação abordada:

• Delphi;

Categorização por Disciplina (RUP):

• Modelagem de Negócios: 01 padrão;

• Requisitos: 04 padrões;

• Análise e Projeto: 08 padrões;

• Implementação: 03 padrões;

• Configuração e Gerência de Mudança: 01

padrão.

• Gerência de Projeto: 03 padrões.

68

Título A Pattern Language for Reverse Engineering

Autores Serge Demeyer; Stéphane Ducasse; Oscar Nierstrasz



Objetivo do Estudo Apresentar linguagem de padrões desenvolvidos para engenharia reversa de um sistema de software orientado a objetos e aplicados durante o projeto FAMOOS; um projeto com o objetivo explícito de produzir um conjunto de re-engenharia técnicas e ferramentas para apoiar o desenvolvimento de frameworks orientados a objetos.

Descrição do Estudo A linguagem de padrões é apresentada dividida em clusters, onde cada cluster tem um número de padrões que abordam uma situação semelhante de engenharia reversa. Os clusters correspondem aproximadamente às diferentes fases da engenharia reversa de um sistema de software de grande porte.




• C++ e Ada;


• Análise e Projeto: 04 padrões.

Título Tie Code And Questions: a Reengineering Pattern




Objetivo do Estudo Apresentar padrão de reengenharia para apoiar a compreensão durante a reengenharia do sistema do projeto Famoos Esprit.

Descrição do Estudo O estudo apresenta o padrão de engenharia reversa que indica como extrair informações dos sistemas legados a partir do código que podem auxiliar na reengenharia do código para suportar as novas exigências, para ser mais flexível.

69


• Engenharia Reversa: 01 padrão;


• C++, Ada e Smaltalk.


• Implementação: 01 padrão.

Título Transform Conditionals: a Reengineering Pattern

Language




Objetivo do Estudo Apresentar linguagem de padrões do projeto Famoos Esprit, que melhora a flexibilidade na reengenharia de aplicação orientada a objetos por meio da transformação das instruções switchs.

Descrição do Estudo A linguagem de padrões apresentada descreve como instruções switch são transformadas em código, para tornar a reengenharia mais flexível e apresentar menos acoplamento entre classes.




• C/C++; Ada; Smaltalk.



Título Type-Check Elimination: Two Reengineering

Patterns

Autores Stéphane Ducasse; Robb Nebbe; Tamar Richner


Fonte EuroPLoP 1998 – 3rd European Conference On Pattern Languages Of Programs

Objetivo do Estudo Discutir o papel dos padrões de reengenharia e contrastá-los com padrões de design e antipadrões; apresentando dois padrões simples

70

para reengenharia.

Descrição do Estudo O artigo apresenta discussão sobre a detecção, solução e evolução de sistemas legados, além de questões específicas de linguagens de programação na reengenharia para cada padrão.


• Reestruturação: 02 padrões;


• C/C++; Ada; Smaltalk; Java.



Título The Bridge to the New Town -

A Legacy System Migration Pattern

Autores Wolfgang Keller



Objetivo do Estudo Definir padrão que apresenta estratégia de migração incremental para permitir substituir aplicativos de sistemas legados por componentes mais novos.

Descrição do Estudo O estudo apresenta padrão de estratégia de migração incremental que permite substituir um legado existente com componentes mais novos.


• Reestruturação: 01


• Não especificado.


• Configuração e Gerencia de Mudança: 01

padrão.

Título Reengineering for Parallelism: An Entry Point into PLPP (Pattern Language for Parallel Programming) for Legacy Applications

Autores Berna L. Massingill; Timothy G. Mattson; Beverly A. Sanders.

71



Objetivo do Estudo Descrever a padrão integrante da PLPP (Pattern Language for Parallel Programming), uma linguagem para programação paralela.

Descrição do Estudo O padrão neste trabalho aborda as preocupações especiais introduzida quando o ponto de partida é uma aplicação complexa existente.






• Análise e Projeto: 01 padrão.

Título Patterns for Architectural Praxis

Autores Alan O’Callaghan



Objetivo do Estudo Apresentar os padrões padrões que estendem a ADAPTOR (Architectural and Patterns-based Techniques for Object Re-engineering), padrões de migração de sistemas legados em larga escala baseada em componentes arquiteturas.

Descrição do Estudo Cada padrão selecionado para o estudo é exemplo de categorias diferentes dos padrões que compõem a linguagem.







Título FaPRE/OO: Uma Família de Padrões para Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais

72

Autores Edson Luiz Recchia; Rosângela Penteado.



Objetivo do Estudo Apresentar a FaPRE/OO,uma Família de Padrões para Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais

Descrição do Estudo O estudo apresenta uma Família de Padrões de Reengenharia, denominada FaPRE/OO, contendo um conjunto de três clusters de padrões para o Processo de Engenharia Reversa.




• Clipper, COBOL, RPGII;




Título TB-REPP - Padrões de Processo para a Engenharia Reversa baseado em Transformações

Autores Darley Rosa Peres; Alexandre Álvaro; Valdirene Fontanette; Vinicius C. Garcia; Antonio Francisco do Prado.



Objetivo do Estudo Apresentar o grupo de Padrões de Processo para a Engenharia Reversa Baseada em Transformações (TB-REPP).

Descrição do Estudo O estudo propõe um grupo de padrões para obter o projeto do sistema em um alto nível de abstração, assegurando a sua evolução e manutenção, tornando-o mais expressivo e de fácil compreensão.






73


• Análise e Projeto: 11 padrões;

Título Padrões para o Processo de Engenharia Avante na Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais.

Autores Edson Luiz Recchia; Gizelle Sandrinu Lemos; Rosângela Penteado; Rosana T.V. Braga.



Objetivo do Estudo Apresentar os padrões para o processo de engenharia avante da Família de Padrões de Reengenahria – FaPRE/OO – para a Reengenharia Orientada a Objetos de Sistemas Legados Procedimentais

Descrição do Estudo O estudo apresenta os padrões e como os padrões para o processo de engenharia avante foram elaborados a partir do sistema legado. Os padrões descritos:


• Engenharia Avante: 04 padrões;


• Clipper; COBOL; RPGII.


• Ambiente: 01 padrão.

Definir Plataforma; • Implementação: 03 padrões.

Título Reverse Variability Engineering

Autores Dietmar Schütz



Objetivo do Estudo Apresentar padrão que oferece uma abordagem para extrair as informações ocultas e não documentadas em um sistema legado.

Descrição do Estudo O estudo apresenta o padrão demonstrando a sua aplicabilidade.

74




• Não Especificado.


• Análise e Projeto: 01 padrão.

75

APÊNDICE D – CLASSIFICAÇÃO DOS PADRÕES DE REENGENHARIA POR DISCIPLINA DO RUP

Padrões de Modelagem de Negócios

Preparar o Processo de Reengenharia Obter quais atividades serão realizadas durante o processo de

reengenharia e quais produtos serão elaborados.

Padrões de Requisitos

Criar Diagramas de Caso de Uso do MASA Modelar as funcionalidades e o comportamento do software legado.

Descrever Casos de Uso do MASA Detalhar a documentação dos casos de uso do sofwtare legado.

Criar Diagramas de Caso de Uso do MAS Completar visão orientada a objetos do software legado.

Descrever Casos de Uso do MAS Re-especificar as descrições dos casos de uso alterados durante a

abstração dos modelos elaborados.

Construir Diagramas de Use Cases Construir todos os Diagramas de Use Cases do sistema a partir da

Tabela Cenários do Sistema elaborada pelo padrão Obter Cenários.

Elaborar a Descrição de Use Cases

Elaborar a Descrição correspondente a cada Use Case obtido pelo

padrão Construir Diagramasde Use Cases.

Identificar Casos de Uso Identificar casos de uso do código legado, e armazená-los como fatos

na base de conhecimento.

Criar Casos de Uso Gerar as especificações dos Casos de Uso na linguagem de

modelagem.

Padrões de Análise e Projeto

Elaborar Lista de Procedimentos e Funções Identificar todos os procedimentos e funções, definidos pelo

programador, que serão transformados pelo processo de reegenharia.

76

Elaborar Lista de "Chama/Chamado Por" Obter entendimento da funcionalidade implementada em cada

procedimentos e função do software legado.

Modelar Dados do Software Legado Construir Modelo de Entidade Relacionamento correspondente à

implementação atual dos dados do software legado a partir dos dados

contidos no banco de dados relacional.

Criar Visão OO de Dados Obter a visão orientada a objetos dos dados a partir do sistema legado

procedimental

Criar Lista de Anomalias Obter, a partir do código-fonte, todas as anomalias relacionadas aos

procedimentos que acessam as Tabelas de dados identificadas.

Abstrair Diagrama de Pseudo-Classes Criar visão orientada a objetos do software legado.

Elaborar Diagrama de Classe do Projeto Modularizar a funcionalidade do software, de forma a separá-la do

acesso aos dados.

Construir Diagramas de Sequência Documentar a lógica de negócio do sistema legado.

Speculate about Domain Objects

Refinar progressivamente um modelo de domínio contra código-

fonte, através da definição de hipóteses.

Reconstruct the Persistent Data Recuperar objetos valiosos armazenados em um sistema de banco de

dados.

Identify the Largest Identificar código importante usando uma ferramenta de métricas

e inspecionar as maiores alterações.

Recover the Refactorings Reconstruir o processo de design interativo, comparando releases.

Transform Self Conditional to Subclassing Fazer uma classe mais extensível, transformando código

condicional complexo em uma única chamada a um

método polimórfico.

77

Transform Client Conditional to Polymorphism Transformar código condicional que testa o tipo de um objeto de

provedor em uma chamada ao método polimórfico.

Apply State Delegar cada caso de condicional para um objeto Estado separado.

Apply Null Object Transferir a responsabilidade para decidir o que fazer com a

hierarquia através da introdução de um objeto nulo.

Type Check Elimination in a Provider Hierarchy Transformar uma classe de provedor único em uma hierarquia

de classes.

Type Check Elimination in Clients.Apply Null Object Transformar as classes de clientes que dependem de polimorfismo.

Reengineering for Parallelism Melhorar o desempenho fazendo uso de hardware paralelo.

Mile-Wide, Inch Deep Desenvolver uma visão arquitetônica de um sistema que possui

um conjunto de requisitos funcionais e não funcionais que podem

mudar.

Keeper of the Flame Manter a integridade conceitual de um sistema diante da

exigências mudança ao longo do tempo.

Archetype Construir um modelo para capturar as principais abstrações.

Iniciar Análise dos Dados Iniciar a construção do MER, Modelo Entidade Relacionamento,

utilizando uma Tabela que relaciona todos os programas/módulos que

fazem parte do sistema, com seus respectivos arquivos de dados.

Definir Chaves Identificar os relacionamentos entre as entidades do MER.

Identificar Relacionamentos Identificar os relacionamentos entre as entidades do MER.

Criar Visão OO dos Dados Criar uma visão orientada a objetos dos dados.

Obter Cenários Obter os Cenários do Sistema através da análise das interfaces do

sistema em operação.

78

Tratar Anomalias Analisar as Descrições de Use Cases para tratar as anomalias,

definindo, assim, os possíveis métodos das pseudo-classes

(candidatas a classe) do sistema, obtidas pelo padrão Criar Visão OO

dos Dados.

Definir as Classes Iniciar a construção do Diagrama de Classes do sistema.

Definir Atributos Definir os atributos das classes pertencentes ao Diagrama de Classes

em construção.

Analisar Hierarquias Fornecer um mecanismo para descobrir possíveis papéis (mais de

uma função) e hierarquias de herança que possam estar contidas nos

arquivos de dados do sistema legado.

Definir Métodos Definir os métodos das classes pertencentes ao Diagrama de Classes

em construção.

Construir Diagramas de Seqüência Documentar as Regras de Negócio do sistema legado para facilitar a

sua futura reengenharia.

Definir hierarquia Chama/Chamado Identificar no código legado a hierarquia de chamadas das unidades

de programas.

Identificar Supostas Classes e Supostos Atributos Identificar no código legado, supostas classes e supostos atributos que

darão origem a classes e atributos no projeto final.

Identificar Supostos Métodos Identificar fatos sobre supostos métodos e armazená-los na base de

conhecimento.

Identificar Relacionamentos Identificar os supostos relacionamentos e seus tipos e armazená-los

na base de conhecimentos.

Identificar Cardinalidades Identificar as cardinalidades dos relacionamentos e armazená-las

79

como fatos na base de conhecimento.

Criar Supostas Classes e Supostos Atributos Através dos fatos armazenados na base de conhecimento criar

arquivos contendo as supostas classes e supostos atributos.

Alocar Supostos Métodos nas Supostas Classes Alocar os supostos métodos que estão armazenados como fatos na

base de conhecimento em suas supostas classes.

Criar Especificações das Classes e dos Atributos Criar as especificações na linguagem de modelagem para as classes e

seus atributos.

Criar Especificações dos Métodos Criar as especificações dos métodos na linguagem de modelagem em

suas respectivas classes.

Criar Diagrama de Seqüência Criar as especificações em linguagem de modelagem para o diagrama

de seqüência, seguindo o fluxo de controle do código legado

organizado e dos casos de uso.

Criar Especificações dos Relacionamentos e Cardinalidades Gerar as especificações dos relacionamentos e suas cardinalidades na

linguagem de modelagem, de acordo com os fatos identificados.

Reverse Variability Engineering Extrair o conhecimento escondido, e transformá-lo em modelo.

Padrões de Implementação

Implementar as Classes Codificar a lógica de negócio do sistema, previamente modelada

durante a aplicação dos padrões anteriores.

Implementar a Lógica de Armazenamento Definir a lógica de armazenamento do software.

Implementar a Lógica de Apresentação Definir a lógica de armazenamento do software.

Tie Code and Questions Manter todas as perguntas e respostas sobre o código, armazenando-

os diretamente nos arquivos de origem.

Converter o Banco de Dados Criar as estruturas do sistema, fisicamente, de acordo como Diagrama

80

de Classes

Implementar Métodos Escrever os métodos obtidos pela engenharia reversa na linguagem

de programação escolhida para o processo de engenharia avante.

Realizar Melhorias de Interface Conceber sistemas que atendam, cada vez, melhor, às necessidades

dos usuários em relação não apenas a critérios de funcionalidade

(conjunto de tarefas desempenhadas pelo sistema) mas também à

usabilidade.

Padrões de Ambiente

Definir Plataforma Definir a plataforma de desenvolvimento do novo sistema conforme as

exigências do Negócio e dos Objetivos Estratégicos da organização

empresarial.

Padrões de Configuração e Gerência de Mudança

Controlar a Configuração Estabelecer e manter a integridade dos produtos de trabalho

elaborados ao longo do processo de reengenharia.

The Bridge to the New Town Substituir uma parte de um sistema existente por um novo

componente.

Padrões de Gerência de Projeto

Planejar o Processo de Reengenharia Obter quais atividades serão realizadas durante o processo de

reengenharia e quais produtos serão elaborados.

Acompanhar o Progresso de Reengenharia Manter sempre atualizado o plano do processo de reengenharia.

Realizar Inspeção de Garantia de Qualidade Garantir a qualidade dos produtos gerados durantes o processo de

reengenharia.

Technology

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