Professora: Aline Vasconcelos

Apresentação em tema: "Professora: Aline Vasconcelos"— Transcrição da apresentação:

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

2 Definição 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 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 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) Acréscimo de funcionalidade Migração para uma Tecnologia Atual (Web, Componentes) Novas Regras ou Regras de Negócio modificadas Etc.

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

8 Características da ER Três tópicos de engenharia reversa precisam ser tratados: Nível de Abstração: 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. 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. Dois sentidos: Reengenharia!

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 Requisitos Projeto Detalhado
Arquitetura de Software Projeto Detalhado Código Legado

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. Técnicas de clustering e pattern matching costumam ser empregadas.

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 Visão Lógica e de Processo da Arquitetura

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 Visão Física e de Desenvolvimento da Arquitetura

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 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.

18 Análise Estática Geralmente, representa a análise do Código fonte feita com o uso de um parser para a linguagem de programação. 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: para Diagrama de Classes a partir de código OO, mapeamento quase direto. Volume de Informação gerenciável. Desvantagens: não soluciona referências polimórficas.

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

20 Ferramenta Ares https://javacc.dev.java.net/
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. Integrada ao ambiente Odyssey:

21 Problemas na Recuperação de Modelos
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. 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 Análise Dinâmica Se baseia na instrumentação do software e monitoramento da sua execução para extração de modelos. Extrai modelos dinâmicos/comportamentais, como Diagramas de Seqüência e de Estado. Etapas: Definição de Cenários de Uso do Software Instrumentação Execução Extração de Diagramas

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

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

25 Recuperação de Arquitetura
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. 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 Engenharia Reversa – Questões de Pesquisa
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 Reestruturação (ou Refactoring)
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. 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 Reestruturação (ou Refactoring)
Benefícios: Programas com maior qualidade, seguindo boas práticas de programação e princípios da Engenharia de Software. Curva de aprendizado dos programas é menor em função de um projeto e código mais “limpos”. Programas mais manuteníveis! IMPORTANTE: Não se esqueça dos Testes de Regressão sobre a partes reestruturadas!!!

31 Reestruturação (ou Refactoring)
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 Refactoring: Improving the Design of Existing Code (Fowler at al
Bad Smells in Code: 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 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 Refactoring: Improving the Design of Existing Code (Fowler at al
Bad Smells in Code: 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. 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 Refactoring: Improving the Design of Existing Code (Fowler at al
Bad Smells in Code: 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.

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

36 Algumas Opções de Refactoring no Eclipse (IDE) – extraídas de Fowler (2002)
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: 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: substitui todas as referências a um campo por métodos get e set, criando os novos métodos.

37 Algumas Opções de Refactoring no Eclipse (IDE) – extraídas de Fowler (2002)
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: 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 Solucionando Bad Smells com Refactorings
Duplicated Code: A mesma expresão em dois métodos da mesma Classe: EXTRACT METHOD A mesma expresão em duas subclasses vizinhas: EXTRACT METHOD em todas as Classes PULL UP FIELD etc.

39 Solucionando Bad Smells com Refactorings
Long Method: 99% dos casos: EXTRACT METHOD encontre partes do método que possam formar um novo método Long Parameter List 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.

40 Solucionando Bad Smells com Refactorings
Large Class: EXTRACT CLASS

41 Solucionando Bad Smells com Refactorings
Large Class: Extract Class: crie uma nova Classe e mova os campos e métodos relevantes da Classe antiga para esta nova. 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 etc.

42 Solucionando Bad Smells com Refactorings
Refused Bequest: 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 Replace Inheritance with Delegation para reuso de comportamento apenas. etc.

43 QUESTÕES DE PESQUISA

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 Questões de Pesquisa Publicação de artigo em conferência ou periódico qualificado pelo Qualis CC da Capes substitui a monografia final.