reengenharia de software: benefícios, dificuldades, técnicas e abordagens aline vasconcelos d.sc....

Reengenharia de Software: Benefícios, Dificuldades, Técnicas

e Abordagens

Aline Vasconcelos

D.Sc. em Sistemas e Computação/COPPE UFRJ

2

Sumário

Conceitos, Motivações, Processo de Reengenharia

Benefícios e Dificuldades

Engenharia Reversa

Abordagens/Ferramentas

3

Reengenharia: conceitos e motivações

A Reengenharia de Software se constitui no exame e alteração de um sistema existentesistema existente para reconstituí-loreconstituí-lo em uma nova formauma nova forma, com a conseqüente implementação desta nova forma (CHIKOFSKY e CROSS, 1990; IEEE, 2004).

Motivações: renovaçãoMotivações: renovação/migração/migração de sistemas legados para plataformas atuais; reutilização de reutilização de software; melhoria da estrutura do software para software; melhoria da estrutura do software para futuras manutençõesfuturas manutenções.

A empresa não deseja perder todo o conhecimento conhecimento sobre o negócionegócio, disponibilidade de serviçodisponibilidade de serviço e esforçoesforço investido.

4

O Processo de Reengenharia de Software

5

Etapas do Processo de Reengenharia

Engenharia Reversa: visa à obtenção de uma documentação atualizada dos sistemas de software existentes em um nível de abstração mais alto que o código.

Reestruturação: melhoria da estrutura do sistema sem alterar seu comportamento. Mesmo nível de abstração.

Engenharia Progressiva: processo tradicional de se mover a partir de abstrações e lógica de alto nível, i.e. modelos independentes de implementação, para a implementação física de um sistema.

6

Reengenharia: benefícios

REENGENHARIA DE SOFTWARE

Reutilização de Reutilização de conhecimento, modelosconhecimento, modelos

Reutilização de códigoReutilização de código

Reaproveitamento de Reaproveitamento de esforço investidoesforço investido

Melhoria da estrutura Melhoria da estrutura do softwaredo software

Migração para Migração para plataforma atualplataforma atual

Maior sobrevidaMaior sobrevidado softwaredo software

Melhor base para Melhor base para futuras manutençõesfuturas manutenções

Maior satisfação dos clientes, Maior satisfação dos clientes, manutenção de serviçosmanutenção de serviços

7

Reengenharia de Software: dificuldades

Sistemas existentes - em alguns casos conhecidos como “sistemas legados” - costumam apresentar documentação defasada em relação ao código.

Documentação não é atualizada durante as manutenções.

Ferramental de suporte para apoiar o processo de engenharia reversa ou reestruturação para

sistemas legados nem sempre está disponível. Tamanho e complexidade dos sistemas legados.

Engenharia Reversa: compreensão de

programas

Atividade-chave em um Atividade-chave em um Processo de ReengenhariaProcesso de Reengenharia

9

Engenharia Reversa: conceitos, técnicas

Processo de análise de um sistemaanálise de um sistema, a fim de identificar os componentes desse sistema e seus componentes desse sistema e seus relacionamentosrelacionamentos, criando representaçõesrepresentações em uma outra forma ou em um nível mais alto de abstraçãonível mais alto de abstração (CHIKOFSKY e CROSS, 1990).

Principais Técnicas: Análise Estática: análise do código fonte para a

extração de informações, como acesso a variáveis e chamadas de procedimento, sendo normalmente realizada com o uso de um analisador sintático (parser).

Análise Dinâmica: execução de um programa e monitoramento dos valores das variáveis, funções chamadas etc.

10

Análise Estática x Análise Dinâmica

Análise EstáticaAnálise Estática

VantagensVantagens//DesvantagensDesvantagensAnálise DinâmicaAnálise Dinâmica

VantagensVantagens//DesvantagensDesvantagens

Detectar possíveis chamadas de funções. Não suporta polimorfismo da OO.

Descobrir funções de fato invocadas. Suporte a “late binding” e polimorfismo.

Identifica possíveis caminhos percorridos a partir de uma chamada de procedimento.

Detectar um caminho de fato percorrido para a execução de uma funcionalidade.

Mais exaustiva que a análise dinâmica. Pode não detectar caminhos reais de execução.

Não é exaustiva, dependendo de dados de entrada e opções escolhidas pelo usuário.

Menor volume de dados para análise.

Grande volume de dados.

11

Engenharia Reversa: conceitos, técnicas

Outras Técnicas: Clustering: descoberta de " melhores "

projetos do sistema ou extração de conceitos significativos a partir do código (ANQUETIL et al., 1999).

Remodularização: a decomposição de um conjunto de componentes em sub-partes (i.e. os módulos) (ANQUETIL, 2000).

Ambas as técnicas acabam inferindo alguma forma de reestruturação.

12

Engenharia Reversa: Abordagem ArchMine (Vasconcelos,

2007)

Abordagem de engenharia reversa para a engenharia reversa para a recuperação de um modelo arquiteturalrecuperação de um modelo arquitetural de software, utilizando as seguintes técnicas: Análise estáticaAnálise estática – ferramenta Ares Análise dinâmicaAnálise dinâmica – ferramentas Tracer, Phoenix Mineração de dados, Mineração de dados, clusteringclustering – ferramenta

TraceMining

Resultados integrados ao ambiente de reutilização OdysseyOdyssey (Odyssey, 2010).

13

ArchMine: Análise Estática

Código FonteCódigo Fonte

ExtraçãoExtração

Ferramenta Ferramenta ARES ARES integrada ao integrada ao OdysseyOdyssey

Modelo estático da UML: Modelo estático da UML: classes, pacotes e seus classes, pacotes e seus relacionamentos.relacionamentos.

14

ArchMine: Análise Dinâmica

<?xml version="1.0" encoding="UTF-8" ?><trace><Label name="Caso de Uso 1">

<Method class="pkg1.A" method="m1" instance="@a7552" thread="T-1" timestamp="01/04/200512:00:01">

<Method class="pkg2.B" method="m2" instance="@14db8d" thread="T-1" imestamp="01/04/200512:00:01"/>

</Method> …

Rastros de Execuçãoem XMLTracer:

AspectJ

Modelos Dinâmicos Reconstruídos com a ferramenta Phoenix no Odyssey

PhoenixPhoenixIntegradaIntegradaAo OdysseyAo Odyssey

Tela de Mineração da TraceMining

H1 H2

H3

H4

H6

17

<label name=“Informar Notas de Estudantes de Graduação"> <execution class=“Estudante"> <execution class=“EstudanteGraduação">

<label name=“Informar Notas de Estudantes de Pós-Graduação"> <execution class=“Estudante"> <execution class=“EstudantePosGraduação">

<label name=“Imprimir Grade de Notas de Estudantes"> <execution class=“Estudante"> <execution class=“EstudanteGraduação"> <execution class=“EstudantePosGraduação"> <execution class=“ImpressoraUtils"> <execution class=“ImpressoraConfig">

<label name=“Inscrever Estudantes de Graduação em Turmas"> <execution class=“Estudante"> <execution class=“EstudanteGraduação"> <execution class=“Classes"> <execution class=“Turmas"> <execution class=“Inscrições">

<label name=“Inscrever Estudantes de Pós-Graduação em Turmas"> <execution class=“Estudante"> <execution class=“EstudantePosGraduação"> <execution class=“Classes"> <execution class=“Turmas"> <execution class=“Inscrições">

<label name=“Imprimir Inscrições de Estudantes"> <execution class=“Estudante"> <execution class = “EstudanteGraduação, EstudantePosGraduação”> <execution class=“Classes, Turmas, Inscrições"> <execution class=“ImpressoraUtils, ImpressoraConfig"> <execution class=“RelatUtils">

Estudante (sup. 100%)EstudanteGraduação

EstudantePósGraduação(confiança 66,7%)

H2 e H3

Turmas (sup. 50%)Classes

Inscrições(confiança 66,7%)H2, H3, H4 e H5

ImpressoraUtils (sup. 33,3%)ImpressoraConfig

(confiança 100%)H2, H3, H4

H6

19

Engenharia Reversa: outros exemplos de abordagens

Princípios de Projeto/clustering (Mitchell e Mancoridis, 2006): utiliza estratégia de utiliza estratégia de clusteringclustering com base em com base em princípios de baixo acoplamento e alta coesão, princípios de baixo acoplamento e alta coesão, extraindo um grafo do código e buscando as extraindo um grafo do código e buscando as melhores partições neste grafo. Utilizam a melhores partições neste grafo. Utilizam a ferramenta Bunch.ferramenta Bunch.

Similaridade de Nome (Anquetil e Lethbridge, 1999): recuperação de modelo arquitetural com base no recuperação de modelo arquitetural com base no agrupamento de classes por similaridade de nomes agrupamento de classes por similaridade de nomes ((substringssubstrings) nos nomes de arquivos) nos nomes de arquivos, , que encapsulam que encapsulam conceitos do domínio, serviços utilitários etc.conceitos do domínio, serviços utilitários etc.

20


Fatos/Regras em Prolog (Riva e Rodriguez, 2002): análise estática e dinâmica geram fatos em uma análise estática e dinâmica geram fatos em uma base Prolog e elementos agrupados através da base Prolog e elementos agrupados através da definição de regras. Modelos representados como definição de regras. Modelos representados como grafos na ferramenta Rigi grafos na ferramenta Rigi (Wong et al., 2004). (Wong et al., 2004). Regras Regras específicas de domínio.específicas de domínio.

Padrões de codificação/Estilos Arquiteturais (Schmerl et al., 2006): utiliza análise dinâmica para utiliza análise dinâmica para detectar conjuntos de eventos, i.e. protocolos de detectar conjuntos de eventos, i.e. protocolos de comunicação ou padrões de implementação, que comunicação ou padrões de implementação, que indicam estilos arquiteturais. Identifica arquitetura indicam estilos arquiteturais. Identifica arquitetura cliente-servidor.cliente-servidor.

21


Padrões de Codificação/Estilos arquiteturais (Harris et al., 1997): análise de padrões de análise de padrões de programação a partir da Árvore Sintática Abstrata programação a partir da Árvore Sintática Abstrata (AST) extraída do código fonte para o (AST) extraída do código fonte para o reconhecimento de estilos arquiteturais na reconhecimento de estilos arquiteturais na linguagem de programação C.linguagem de programação C.

Regras/Clichés/ArchPattern (Carvalho et al., 2008): composição de base de regras para a identificação base de regras para a identificação do estilo arquitetural MVC em sistemas escritos do estilo arquitetural MVC em sistemas escritos em Java a partir das análises estática e dinâmica. em Java a partir das análises estática e dinâmica. Extensível para outros estilos.Extensível para outros estilos.

22

Questões de Pesquisa

Estender abordagens existentes para detecção de novos padrões arquiteturais ou para outras tecnologias.

Tornar abordagens mais genéricas através da geração de uma base de fatos e regras mais completa.

Recuperação de rastros de execução para casos de uso ou funcionalidades do sistema de forma mais automatizada.

Utilização de modelos de ontologia de domínio para apoiar a recuperação de modelos arquiteturais.

etc.

Reengenharia:

exemplos de abordagens

24

Reengenharia: abordagem ROOSC (Moura, 2009)

Reengenharia de Sistemas Orientados a Objetos Sistemas Orientados a Objetos para Componentespara Componentes apoiada por Métricas em nível de modelo.

Objetivos: encontrar os pontos do modelo OO que precisam ser

melhorados para que se possa derivar o modelo de componentes nas etapas seguintes;

esses pontos do modelo a serem reestruturados são descobertos com o uso de métricas, como: acoplamento entre classes em diferentes pacotes, heranças em pacotes distintos, número de filhos por classes em diferentes pacotes etc.

para cada resultado de métrica, onde esse resultado possa indicar um “problema” no modelo, é sugerida uma reestruturação.

ROOSC: o processo de Reengenharia

Avaliação do modelo baseada em métricas

Reestruturação ou refatoração do modelo

Geração de interfaces e modelo de componentes

Modelo OO c/ Agrupamentos recuperado do código – Engenharia Reversa

Agrupamentos Reestruturados

Modelo de Componentes

Modelo podeModelo podeser reimplementado em ser reimplementado em

uma tecnologia componentesuma tecnologia componentes

26


Geração de interfaces e modelo de componentes: Objetivo: derivar as interfaces dos

componentes e definir os modelos de projeto de componentes;

Funcionamento: são derivadas as interfaces que os componentes necessitam (interfaces requeridas) e as as interfaces que eles fornecem (interfaces providas). São gerados os modelos de projeto de componentes de acordo com algum método de DBC.

27


Exemplos de Passos para a geração de componentes: selecionar o nível na hierarquianível na hierarquia de pacotes do

modelo OO onde derivar os componentes; derivar um componente para cada pacote um componente para cada pacote

encontradoencontrado; para cada par de componentespar de componentes que possuam classes classes

que se comunicamque se comunicam (i.e. associação e dependência) deve-se derivar uma interface provida no interface provida no componente requeridocomponente requerido para atender o componente requerente;

as interfaces geradas devem possuir todas as interfaces geradas devem possuir todas as operações, de visibilidade públicaoperações, de visibilidade pública, pertencentes às classes requisitadas pelo componente requerente.

28

Abordagem ROOSC (Moura, 2009): apoio ferramental

Ares – ferramenta de engenharia reversa/análise estática – plugin do ambiente OdysseyOdyssey (Odyssey, 2010)(Odyssey, 2010)

Tracer – análise dinâmica/ geração de rastros de execução

ORC – extração de métricas e reestruturação do modelo OO – plugin do Odyssey

GenComp – geração dos componentes e suas interfaces – plugin do Odyssey

29

Abordagem ROOSC (Moura, 2009): trabalhos futuros

Geração de código a partir do modelo de componentes gerado: a ênfase neste trabalho está no projeto dos componentes. Apesar desta ênfase, há a necessidade de gerar código, reutilizando código do sistema original, em uma tecnologia de componentes.

30

Abordagem ROOSC (Moura, 2009): trabalhos futuros

Acompanhamento da evolução do sistema: a abordagem ROOSC poderia ser utilizada para o acompanhamento da evolução do sistema, através de um mecanismo de armazenamento histórico das métricas. Dessa forma, de tempos em tempos poderia se verificar se a estrutura do sistema está se degradando.

31

Reengenharia: um outro exemplo de abordagem

Prado (2005):Prado (2005): a reengenharia é realizada a partir de um software legado procedural para um software baseado em componentes. O processo é dividido nas atividades: organizar o código, recuperar o projeto do sistema atual, re-especificar, re-projetar e re-implementar. A organização do código legado é um passo preparatório para facilitar a transformação de um código procedural para OO, para, a partir daí, serem gerados os componentes.

32

Reengenharia: outros exemplos de ferramentas

Ferramentas CASE – engenharia reversa do modelo de classes e pacotes: ArgoUML, Jude, Enterprise Architect, Rational Rose, OMondo Eclipse UML, ArgoUML-PHP, BoUML etc.

Engenharia Reversa de Arquitetura – ferramentas acadêmicas.

Extração de modelo dinâmico com análise dinâmica – desafios (identificação da funcionalidade/volume de informação): MaintainJ – Eclipse plugin, Tracer/Phoenix (Vasconcelos, 2007), JProfiler (monitoramento do código).

33

Reengenharia: questões de pesquisa

Manter a consistência dos modelos durante as manutenções após a realização de um processo de Reengenharia (round-trip engineering).

Combinar abordagens de MDA (Model Driven Architecture) com abordagens de Engenharia Reversa/Reestruturação em um ciclo de Reengenharia.

etc.

34

Referências

CHIKOFSKY, E. J. e CROSS, J. H. I., 1990, Reverse Engineering and Design Recovery: a Taxonomy. IEEE Software, v. 7, n. 1. pp. 13-17.

IEEE, C.-T., 2004, Reengineering & Reverse Engineering Terminology. Washington.

ANQUETIL, N., FOURRIER, C., LETHBRIDGE, T.C., 1999, "Experiments with Hierarchical Clustering Algorithms as Software Remodularization Methods". In: Working Conference on Reverse Egineering, pp. 235-255, Pittsburgh, PA, USA, October.

ANQUETIL, N., 2000, Curso de Engenharia Reversa, notas de aula, COPPE/UFRJ.

ANQUETIL, N., LETHBRIDGE, T.C., 2003, "Comparative Study of Clustering Algortihms and Abstract Representations for Software Remodularization", IEE Software, v. 150, n. 3 (June), pp. 185-201.

ODYSSEY, 2010, "Odyssey: Infra-Estrutura de Reutilização baseada em Modelos de Domínio". In: http://reuse.cos.ufrj.br/odyssey, acessado em 18/03/2010.

35

Referências

MITCHELL, B.S., MANCORIDIS, S., 2006, "On the Automatic Modularization of Software Systems Using the Bunch Tool", IEEE Transactions on Software Engineering, v. 32, n. 3 (March), pp. 193-208.

RIVA, C., RODRIGUEZ, J.V., 2002, "Combining Static and Dynamic Views for Architecture Reconstruction". In: Sixth European Conference on Software Maintenance and Reengineering (CSMR’02), pp. 47-56, Budapeste, Hungary, March.

SCHMERL, B., ALDRICH, J., GARLAN, D., et al., 2006, "Discovering Architectures from Running Systems", IEEE Transactions on Software Engineering, v. 32, n. 7 (July), pp. 454-466.

HARRIS, D.R., YEH, A., CHASE, M.P., 1997a, "Manipulating Recovered Software Architecture Views". In: 19th International Conference on Software Engineering, pp. 184-194, Massachusets, USA, May.

HARRIS, D.R., YEH, A., REUBENSTEIN, H.B., 1997b, "Extracting Architectural Features from Source Code", The Mitre Journal.

HARRIS, D.R., YEH, A., REUBENSTEIN, H.B., et al., 1995, "Reverse Engineering to the Architectural Level". In: 17th International Conference on Software Engineering, pp. 186-195, Scattle, Washington, USA, April.

36

Referências

Moura, A. M. M., ROOSC: Uma Abordagem de Reengenharia de Sistemas Orientados a Objetos para Componentes baseada em Métricas, Dissertação de M.Sc., COPPE, UFRJ, Rio de Janeiro, Brasil, março, 2009.

PRADO, A. F., 2005, "Reengenharia de Software Baseado em Componentes". In: Desenvolvimento Baseado em Componentes: Conceitos e Técnicas,Ciência Moderna.

CARVALHO, F., BARROSO, L., SEUFITELES, V., VASCONCELOS, A. P. V. Reconhecimento de Padrões Arquiteturais em Sistemas Java. INFOCOMP (UFLA. Impresso). , v.1, p.41 - 50, 2008.

BARROSO, L., CARVALHO, F., SEUFITELES, V., VASCONCELOS, A. P. V. ArchJava: Reconhecimento de Padrões Arquiteturais em Sistemas Java In: WMSWM 2008 - V Workshop de Manutenção de Software Moderna, 2008, Florianópolis. VII Simpósio Brasileiro de Qualidade de Software - WMSWM. Sociedade Brasileira de Computação - SBC, 2008.

37

Dúvidas

reengenharia de software: benefícios, dificuldades, técnicas e abordagens aline vasconcelos d.sc....

Documents