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

Apresentação em tema: "Aline Vasconcelos D.Sc. em Sistemas e Computação/COPPE UFRJ"— Transcrição da apresentação:

1 Aline Vasconcelos D.Sc. em Sistemas e Computação/COPPE UFRJ
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 existente para reconstituí-lo em uma nova forma, com a conseqüente implementação desta nova forma (CHIKOFSKY e CROSS, 1990; IEEE, 2004). Motivações: renovação/migração de sistemas legados para plataformas atuais; reutilização de software; melhoria da estrutura do software para futuras manutenções. A empresa não deseja perder todo o conhecimento sobre o negócio, disponibilidade de serviço e esforç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
Maior satisfação dos clientes, manutenção de serviços REENGENHARIA DE SOFTWARE Melhor base para futuras manutenções Reutilização de conhecimento, modelos Maior sobrevida do software Reutilização de código Reaproveitamento de esforço investido Migração para plataforma atual Melhoria da estrutura do software

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.

8 Engenharia Reversa: compreensão de programas
Atividade-chave em um Processo de Reengenharia

9 Engenharia Reversa: conceitos, técnicas
Processo de análise de um sistema, a fim de identificar os componentes desse sistema e seus relacionamentos, criando representações em uma outra forma ou em um ní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
Vantagens/Desvantagens Análise Dinâmica 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 recuperação de um modelo arquitetural de software, utilizando as seguintes técnicas: Análise estática – ferramenta Ares Análise dinâmica – ferramentas Tracer, Phoenix Mineração de dados, clustering – ferramenta TraceMining Resultados integrados ao ambiente de reutilização Odyssey (Odyssey, 2010).

13 ArchMine: Análise Estática
Modelo estático da UML: classes, pacotes e seus relacionamentos. Extração Ferramenta ARES integrada ao Odyssey Código Fonte

14 ArchMine: Análise Dinâmica
Rastros de Execução em XML Tracer: AspectJ <?xml version="1.0" encoding="UTF-8" ?> <trace> <Label name="Caso de Uso 1"> <Method class="pkg1.A" method="m1" thread="T-1" timestamp="01/04/200512:00:01"> <Method class="pkg2.B" method="m2" thread="T-1" imestamp="01/04/200512:00:01"/> </Method> …

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

16 Tela de Mineração da TraceMining
H1 H2 H3 H4 H6

17 EstudantePósGraduação (confiança 66,7%) H2 e H3
<label name=“Informar Notas de Estudantes de Graduação"> <execution class=“Estudante"> <execution class=“EstudanteGraduação"> Estudante (sup. 100%) EstudanteGraduação EstudantePósGraduação (confiança 66,7%) H2 e H3 <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"> 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 <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"> H6

18

19 Engenharia Reversa: outros exemplos de abordagens
Princípios de Projeto/clustering (Mitchell e Mancoridis, 2006): utiliza estratégia de clustering com base em princípios de baixo acoplamento e alta coesão, extraindo um grafo do código e buscando as melhores partições neste grafo. Utilizam a ferramenta Bunch. Similaridade de Nome (Anquetil e Lethbridge, 1999): recuperação de modelo arquitetural com base no agrupamento de classes por similaridade de nomes (substrings) nos nomes de arquivos, que encapsulam conceitos do domínio, serviços utilitários etc.

20 Engenharia Reversa: outros exemplos de abordagens
Fatos/Regras em Prolog (Riva e Rodriguez, 2002): análise estática e dinâmica geram fatos em uma base Prolog e elementos agrupados através da definição de regras. Modelos representados como grafos na ferramenta Rigi (Wong et al., 2004). Regras específicas de domínio. Padrões de codificação/Estilos Arquiteturais (Schmerl et al., 2006): utiliza análise dinâmica para detectar conjuntos de eventos, i.e. protocolos de comunicação ou padrões de implementação, que indicam estilos arquiteturais. Identifica arquitetura cliente-servidor.

21 Engenharia Reversa: outros exemplos de abordagens
Padrões de Codificação/Estilos arquiteturais (Harris et al., 1997): análise de padrões de programação a partir da Árvore Sintática Abstrata (AST) extraída do código fonte para o reconhecimento de estilos arquiteturais na linguagem de programação C. Regras/Clichés/ArchPattern (Carvalho et al., 2008): composição de base de regras para a identificação do estilo arquitetural MVC em sistemas escritos em Java a partir das análises estática e dinâmica. 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.

23 exemplos de abordagens
Reengenharia: exemplos de abordagens

24 Reengenharia: abordagem ROOSC (Moura, 2009)
Reengenharia de Sistemas Orientados a Objetos para 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.

25 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 pode ser reimplementado em uma tecnologia componentes

26 Reengenharia: abordagem ROOSC (Moura, 2009)
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 Reengenharia: abordagem ROOSC (Moura, 2009)
Exemplos de Passos para a geração de componentes: selecionar o nível na hierarquia de pacotes do modelo OO onde derivar os componentes; derivar um componente para cada pacote encontrado; para cada par de componentes que possuam classes que se comunicam (i.e. associação e dependência) deve-se derivar uma interface provida no componente requerido para atender o componente requerente; as interfaces geradas devem possuir todas as operaçõ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 Odyssey (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): 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 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 , 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 ODYSSEY, 2010, "Odyssey: Infra-Estrutura de Reutilização baseada em Modelos de Domínio". In: 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 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 , 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 HARRIS, D.R., YEH, A., CHASE, M.P., 1997a, "Manipulating Recovered Software Architecture Views". In: 19th International Conference on Software Engineering, pp , 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 , 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 , 2008. BARROSO, L., CARVALHO, F., SEUFITELES, V., VASCONCELOS, A. P. V. ArchJava: Reconhecimento de Padrões Arquiteturais em Sistemas Java In: WMSWM 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