Padrões de 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,
38 Definir Chaves 2002
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 5 Controlar a Configuração
Mudança 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_T
P026B.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
http://www.hillside.net/plop/plop2k
http://www.hillside.net/plop/plop99

54

PLoP 1996 – 3rd Conference On Pattern
PLoP 1995 – 2nd Conference On Pattern
PLoP 1994 – 1st Conference On Pattern
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
http://sugarloafplop.comp.uece.br/
Sugar Loaf PLoP 2007 – VII Conferencia
http://sugarloafplop.dsc.upe.br/
Sugar Loaf PLoP 2004 – IV Conferencia
http://sugarloafplop2004.ufc.br/
Sugar Loaf PLoP 2003 – III Conferencia

55

http://www.cin.ufpe.br/~sugarloafplop/
Sugar Loaf PLoP 2002 – II Conferencia
Padrões para Programação -
http://lens.cos.ufrj.br/sugarloafplop/exibe.php
Sugar Loaf PLoP 2001 – I Conferencia
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
Programs –
Programs –
Programs –
Programs –

56

Programs –
Programs –
EuroPLoP 2004 – 9th European Conference
On Pattern Languages Of Programs –
EuroPLoP 1998 – 3rd European Conference
EuroPLoP 1997 – 2nd European Conference
EuroPLoP 1996 – 1st European Conference

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/para
plop11
ParaPLoP 2010 – 2nd Workshop on Parallel
plop10
ParaPLoP 2009 – 1st Workshop on Parallel
plop09

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

Padrões de Reengenharia de Sistemas

Padrões de Reengenharia de Sistemas

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (6)

Destaque

Destaque (20)

Semelhante a Padrões de Reengenharia de Sistemas

Semelhante a Padrões de Reengenharia de Sistemas (20)

Padrões de Reengenharia de Sistemas