A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia Reversa Engenharia Reversa Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação Professora: Aline Vasconcelos

Apresentações semelhantes


Apresentação em tema: "Engenharia Reversa Engenharia Reversa Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação Professora: Aline Vasconcelos"— Transcrição da apresentação:

1 Engenharia Reversa Engenharia Reversa Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação Professora: Aline Vasconcelos

2 2 Definição Engenharia Reversa: Engenharia Reversa: processo de análise dos componentes do sistema e dos seus relacionamentos, a fim de descrever este sistema em um nível de abstração mais alto do que o código fonte original (GANNOD, 1999).

3 3 Sistema Legado Sistema Legado : Segundo (PRESSMAN, 2001), o termo sistemas legados é um eufemismo para sistemas, geralmente antigos, mal documentados e mal projetados que devem ser mantidos por muitos anos, por serem críticos para o negócio de uma organização. A Engenharia Reversa atua no auxílio à recuperação da documentação e ao entendimento desses sistemas, possibilitando que a sua manutenção seja realizada de forma menos árdua.

4 4 Sistemas Legados: Importância Alto investimento feito pelas empresas. Embutem conhecimento do negócio e regras de negócio. Precisam ser Mantidos: Correção de bugs (ex: ano 2000) Correção de bugs (ex: ano 2000) Acréscimo de funcionalidade Acréscimo de funcionalidade Migração para uma Tecnologia Atual (Web, Componentes) Migração para uma Tecnologia Atual (Web, Componentes) Novas Regras ou Regras de Negócio modificadas Novas Regras ou Regras de Negócio modificadas Etc. Etc.

5 5 Engenharia Reversa: Motivações Sistemas Legados, em geral, não apresentam documentação de apoio ou a documentação está desatualizada. Pessoas que desenvolveram o software não trabalham mais na empresa. Código fonte se encontra em baixo nível de abstração e é de difícil compreensão. Algumas vezes somente o binário ou executável está disponível. Sistemas Legados representam alto esforço e custo de desenvolvimento investidos. Embutem conhecimento sobre o negócio que muitas vezes não se encontra mais disponível.

6 6 Objetivos da Engenharia Reversa (ER) Recuperar documentação para apoiar a Compreensão de Programas. Recuperar documentação para apoiar a reutilização ou renovação de programas (reengenharia). Recuperar documentação que represente Visões complementares do sistema.

7 7 Fontes de Informação da ER estilos arquiteturais especialista humano documentação do software modelos e conhecimento do domínio padrões código fonte, código binário ou executável repositório de GCS Make file banco de dados; metadados

8 8 Características da ER Três tópicos de engenharia reversa precisam ser tratados: Nível de Abstração: Quanto mais alto, melhor. Quanto mais alto, melhor. Porém, quanto mais alto, a probabilidade é de que uma maior intervenção humana seja requerida no processo. Completeza : Refere-se ao nível de detalhe que é fornecido em um nível de abstração. Refere-se ao nível de detalhe que é fornecido em um nível de abstração. Na maioria dos casos, diminui à medida que o nível de abstração aumenta. Quanto maior a interação humana, maior probabilidade de se aumentar a completeza. Direcionalidade: Um único sentido: Compreensão de Programa. Um único sentido: Compreensão de Programa. Dois sentidos: Reengenharia! Dois sentidos: Reengenharia!

9 9 Níveis de Abstração dos Modelos Recuperados Projeto Detalhado: diagramas de classes, grafos, árvores sintáticas, diagramas de estrutura, diagramas de seqüência etc. Projeto Arquitetural: diagramas de pacotes e de classes, diagramas de componentes, diagramas de caixas e linhas, ADLs (Architectural Description Languages) etc. Requisitos: casos de uso, regras de negócio, diagramas de estado etc.

10 Níveis de Abstração Código Legado Arquitetura de Software Projeto Detalhado Requisitos

11 11 Recuperação da Arquitetura de Software Recuperação de uma documentação arquitetural para um sistema existente. Diversas abordagens vêm sendo propostas na literatura. Normalmente, o processo é semi-automatizado. clustering e pattern matching Técnicas de clustering e pattern matching costumam ser empregadas.

12 12 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995) Visão Lógica: descreve a perspectiva estática do sistema, demonstrando seus componentes e conectores. Reflete abstrações-chave do domínio do problema. Visão de Processo: perspectiva dinâmica, demonstrando os diferentes processos do sistema e descrevendo aspectos de concorrência e de sincronização do projeto.

13 13 Visão Lógica e de Processo da Arquitetura

14 14 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995) Visão Física: descreve o mapeamento do software (componentes, processos) para o hardware e reflete a natureza distribuída do sistema. Visão de Desenvolvimento: descreve o software no seu ambiente de implementação. Mostra a utilização de COTS (Commercial off-the- shelf Software Components), bibliotecas etc.

15 15 Visão Física e de Desenvolvimento da Arquitetura

16 16 Modelo de Visões Arquiteturais 4+1 (Kruchten, 1995) Visão de Cenários: ou de casos de uso, utilizada para ilustrar o comportamento do sistema em sua arquitetura, conforme descrita pelas outras quatro visões. Para tal ilustração, alguns cenários de casos de uso devem ser selecionados.

17 17 Técnicas para a Engenharia Reversa (Vasconcelos, 2004) Análise Estática Análise Dinâmica Clustering (agrupamento de elementos) Program Slicing (recorte de programas) Programação Orientada a Aspectos Pattern Matching (reconhecimento de padrões) Data Mining (mineração de dados) etc. etc.

18 18 Análise Estática análise do Código fonte parser Geralmente, representa a análise do Código fonte feita com o uso de um parser para a linguagem de programação. Análise Estática Diagramas de Classes Diagramas de Seqüência Através da Análise Estática, podem ser recuperados modelos estáticos, como Diagramas de Classes ou modelos dinâmicos, como Diagramas de Seqüência, gerados com base em uma chamada de método no código. Vantagens Vantagens: para Diagrama de Classes a partir de código OO, mapeamento quase direto. Volume de Informação gerenciável. Desvantagens Desvantagens: não soluciona referências polimórficas.

19 19 Exemplo de Ferramenta de Análise Estática Source Code UML static model: classes, packages and their relationships. GOAL: Represent Source Code Elements in a Higher Level of Abstraction. Facilitates System Analysis. Extract ARES Tool

20 20 Ferramenta Ares Recupera um maior número de dependências do que ferramentas de Engenharia Reversa tradicionais: Analisa tipos de parâmetros, variáveis locais, retornos de métodos. Utiliza o JAVACC para gerar o parser. https://javacc.dev.java.net/ Integrada ao ambiente Odyssey:

21 21 Problemas na Recuperação de Modelos Agregação Composição Recuperação de conceitos como Agregação e Composição não é trivial. Uma mesma especificação pode ser implementada de diversas formas por diferentes programadores. Concept Assignment Problem Durante a análise do código para a extração de conceitos do projeto, nos deparamos com situações onde a origem real do conceito implementado não é possível de ser atingida. Este é um problema conhecido como Problema da Associação de Conceitos (Concept Assignment Problem)(BIGGERSTAFF et al., 1994).

22 22 Análise Dinâmica instrumentação do software monitoramento da sua execução Se baseia na instrumentação do software e monitoramento da sua execução para extração de modelos. Diagramas de Seqüência Extrai modelos dinâmicos/comportamentais, como Diagramas de Seqüência e de Estado. Etapas: Cenários de Uso Definição de Cenários de Uso do Software Instrumentação Instrumentação Execução Execução Extração de Diagramas Extração de Diagramas

23 23 Análise Dinâmica Algumas Técnicas de Instrumentação para Java: Aspecto de Tracing Aspecto de Tracing Java Logging API Java Logging API Extensão/Instrumentação da Máquina Virtual Extensão/Instrumentação da Máquina Virtual API SUN/JAVA debugging API SUN/JAVA debugging etc. etc. Vantagens: resolve referências polimórficas na extração de modelos comportamentais. Vantagens: resolve referências polimórficas na extração de modelos comportamentais. Desvantagens: volume de informação recuperado. Desvantagens: volume de informação recuperado.

24 24 Exemplo de Ferramentas de Análise Dinâmica – Tracer + PhoenixExtract Tracer Tool (Aspects)/SequenceDiagramExtractor(Phoenix) Traces (XML) and UML Dynamic Model. Application

25 25 Recuperação de Arquitetura Análise Estática e Dinâmicatécnicas Clustering, Queries, Pattern Matching, Program Slicing Análise Estática e Dinâmica é complementada com técnicas como Clustering, Queries, Pattern Matching, Program Slicing etc., a fim de elevar o nível de abstração dos modelos. Concept Assignment Recai novamente no problema de Concept Assignment....como uma Camada está implementada no código??? Através de um Pacote??? Que Classes compõem que Camadas???? Algumas abordagens e ferramentas vêm sendo propostas

26 QUESTÕES DE PESQUISA

27 27 Engenharia Reversa – Questões de Pesquisa Engenharia Reversa para Requisitos. Engenharia Reversa para Requisitos. Concept Assignment Problem: ER recuperando agregações, composições e outros conceitos. Recuperação de padrões arquiteturais como MVC e Camadas.

28 Reestruturação

29 29 Reestruturação (ou Refactoring) Engenharia Reversaelevanível de abstração Reestruturação mesmo nível de abstração. Enquanto a Engenharia Reversa eleva o nível de abstração da representação do software, a Reestruturação altera o software, mantendo-o no mesmo nível de abstração. melhorá-lo para futuras manutençõesnão modifica funcionalidade Modifica o software a fim de melhorá-lo para futuras manutenções, mas não modifica a sua funcionalidade. Pode ser realizada em nível de projeto ou de código fonte. Não deve modificar a arquitetura do software, mas detalhes de módulos individuais.

30 30 Reestruturação (ou Refactoring) Benefícios: Benefícios: boas práticas de programaçãoprincípios Engenharia de Software Programas com maior qualidade, seguindo boas práticas de programação e princípios da Engenharia de Software. Curva de aprendizadomenor Curva de aprendizado dos programas é menor em função de um projeto e código mais limpos. manuteníveis Programas mais manuteníveis! IMPORTANTE: Não se esqueça dos Testes de Regressão sobre a partes reestruturadas!!!

31 31 Reestruturação (ou Refactoring) By Martin Fowler (2002): By Martin Fowler (2002): Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes. Thus I need solid tests.

32 32 Refactoring: Improving the Design of Existing Code (Fowler at al., 2002) Bad Smells in Code: Duplicated Code: retrabalho na manutenção, vai contra os princípios da reutilização de software. Duplicated Code: retrabalho na manutenção, vai contra os princípios da reutilização de software. Long Method: falta de coesão e objetividade. Complexidade. Dificuldade nas manutenções. Long Method: falta de coesão e objetividade. Complexidade. Dificuldade nas manutenções. Long Parameter List: em orientação a objetos você pode solicitar dados necessários aos respectivos objetos. Além disso, o ideal é que a maior parte da informação necessária para um método, faça parte da sua própria Classe. Longas listas são difíceis de compreender e dar manutenção. Long Parameter List: em orientação a objetos você pode solicitar dados necessários aos respectivos objetos. Além disso, o ideal é que a maior parte da informação necessária para um método, faça parte da sua própria Classe. Longas listas são difíceis de compreender e dar manutenção.

33 33 Refactoring: Improving the Design of Existing Code (Fowler at al., 2002) Bad Smells in Code: Feature Envy: o método utiliza mais atributos (variáveis) de outras Classes do que da sua própria. Feature Envy: o método utiliza mais atributos (variáveis) de outras Classes do que da sua própria. Temporary Field: objetos que possuem uma variável de instância que é atualizada somente em certas circunstâncias. Geralmente, esperamos que um objeto precise de todas as suas variáveis. Temporary Field: objetos que possuem uma variável de instância que é atualizada somente em certas circunstâncias. Geralmente, esperamos que um objeto precise de todas as suas variáveis. Data Classes: classes que só possuem variáveis e métodos get e set. Certamente devem estar sendo manipuladas em um alto nível de detalhe por outras classes. Classes devem representar um agrupamento de dados e responsabilidades (comportamentos). Data Classes: classes que só possuem variáveis e métodos get e set. Certamente devem estar sendo manipuladas em um alto nível de detalhe por outras classes. Classes devem representar um agrupamento de dados e responsabilidades (comportamentos).

34 34 Refactoring: Improving the Design of Existing Code (Fowler at al., 2002) Bad Smells in Code: Refused Bequest: subclasses não utilizam todos os métodos e atributos herdados das superclasses. A hierarquia pode estar equivocada. Refused Bequest: subclasses não utilizam todos os métodos e atributos herdados das superclasses. A hierarquia pode estar equivocada. Large Class ou God Class e Divergent Change: falta de coesão e dificuldades na manutenção. Diferentes modificações aplicadas à mesma Classe. Large Class ou God Class e Divergent Change: falta de coesão e dificuldades na manutenção. Diferentes modificações aplicadas à mesma Classe.

35 BAD SMELLS..... Como resolvê-los?????

36 36 Algumas Opções de Refactoring no Eclipse (IDE) – extraídas de Fowler (2002) Extract Interface Extract Interface: cria uma nova interface com um conjunto de métodos e faz com que a classe selecionada implemente a interface. Opcionalmente, modifica referências à Classe para referências à Interface, quando possível. Extract Method Extract Method: cria um novo método contendo os comandos ou expressão selecionados e substitui a seleção por uma invocação ao novo método. Encapsulate Field Encapsulate Field: substitui todas as referências a um campo por métodos get e set, criando os novos métodos.

37 37 Algumas Opções de Refactoring no Eclipse (IDE) – extraídas de Fowler (2002) Push Down Push Down: move um conjunto de métodos e/ou campos de uma classe para suas subclasses. Deve ser usado quando um comportamento ou estrutura é requerido apenas em algumas subclasses. Pull Up Pull Up: move um conjunto de métodos e/ou campos de uma subclasse para a sua superclasse. Deve ser usado quando métodos de mais de uma subclasse oferecem o mesmo comportamento e resultado ou quando duas ou mais subclasses têm o mesmo campo.

38 38 Solucionando Bad Smells com Refactorings Duplicated Code: Duplicated Code: A mesma expresão em dois métodos da mesma Classe: A mesma expresão em dois métodos da mesma Classe: EXTRACT METHOD EXTRACT METHOD A mesma expresão em duas subclasses vizinhas: A mesma expresão em duas subclasses vizinhas: EXTRACT METHOD EXTRACT METHOD em todas as Classes PULL UP FIELD PULL UP FIELD etc. etc.

39 39 Solucionando Bad Smells com Refactorings Long Method: Long Method: 99% dos casos: 99% dos casos: EXTRACT METHOD EXTRACT METHOD encontre partes do método que possam formar um novo método Long Parameter List Long Parameter List INTRODUCE PARAMETER OBJECT INTRODUCE PARAMETER OBJECT se você tem um grupo de parâmetros que freqüentemente é passado em conjunto, substitua-os por um objeto. Neste caso, a nova classe provavelmente também terá comportamento resultante da análise de manipulações feitas sobre os dados. etc. etc.

40 40 Solucionando Bad Smells com Refactorings Large Class: Large Class: EXTRACT CLASS EXTRACT CLASS

41 41 Solucionando Bad Smells com Refactorings Large Class: Large Class: Extract Class: Extract Class: crie uma nova Classe e mova os campos e métodos relevantes da Classe antiga para esta nova. Extract SubClass: Extract SubClass: uma classe tem características que só são usadas por algumas instâncias. Crie uma SubClasse para este subconjunto de características. Extract Interface Extract Interface etc. etc.

42 42 Solucionando Bad Smells com Refactorings Refused Bequest: Refused Bequest: Crie uma nova Subclasse e aplique Push Down Method e Push Down Field Refactorings. Crie uma nova Subclasse e aplique Push Down Method e Push Down Field Refactorings. Se a SubClasse não pretende suportar a interface da SuperClasse..... então aplique o Se a SubClasse não pretende suportar a interface da SuperClasse..... então aplique o Replace Inheritance with Delegation para reuso de comportamento apenas. Replace Inheritance with Delegation para reuso de comportamento apenas. etc.

43 QUESTÕES DE PESQUISA

44 44 Questões de Pesquisa Ferramenta para automatizar refatorações em diferentes tipos de linguagem. Outro exemplo de refatoração: classes com atributos em comum e/ou métodos em comum transformadas em uma hierarquia.

45 45 Questões de Pesquisa Publicação de artigo em conferência ou periódico qualificado pelo Qualis CC da Capes substitui a monografia final.


Carregar ppt "Engenharia Reversa Engenharia Reversa Pós-Graduação em Análise, Projeto e Gerência de Sistemas de Informação Professora: Aline Vasconcelos"

Apresentações semelhantes


Anúncios Google