ENGENHARIA REVERSA E REENGENHARIA Manutenção de Software Profa. Cynthia Pinheiro Problemas na Manutenção Código fonte mal elaborado e documentação imprecisa, ultrapassada ou inexistente Falta de compreensão do sistema e suas funcionalidades. Muitas vezes, a tecnologia se tornou obsoleta Necessidade de mudar o paradigma de construção de software para melhorar o processo de Engenharia de Software. 1
Motivação Recuperar as informações de projetos existentes. Objetivo: esforço para melhorar a qualidade do sistema. Motivação Como fazer? através do exame e compreensão do software existente, em um caminho oposto ao desenvolvimento Recriar o projeto e recuperar os requisitos atualmente implementados, apresentando-os em um grau mais alto de abstração. 2
A partir do conhecimento em diversos níveis de abstração, um novo produto poderia ser desenvolvido. Níveis de Abstração: Código, Projeto, Requisitos. Funções antigas poderiam ser refeitas segundo novas técnicas e tendências. Engenharia Progressiva Processo tradicional de Engenharia de Software Características: atividades progressivas do ciclo de vida Partem de um nível de abstração mais alto para um nível de abstração mais baixo. Processo inverso ao da Engenharia Progressiva Características: atividades retroativas ao Ciclo de Vida Partem de um nível de abstração mais baixo para um nível de abstração mais alto. 3
Engenharia Progressiva x Engenharia Progressiva x Engenharia Progressiva 4
em Hardware Decifrar projetos de produtos acabados, para duplicá-los ou obter um entendimento de sua arquitetura. em Software Processo de exame e compreensão do software existente Recapturar ou recriar o projeto e decifrar os requisitos implementados em um nível de abstração mais alto. Baseadas nos níveis de abstração, as visões para a são classificadas em quatro tipos: Visão em nível implementacional Visão em nível estrutural Visão em nível funcional Visão em nível de domínio 5
Software visualizado de diferentes maneiras: Visão em nível implementacional: Características da linguagem Visão em nível estrutural: Detalhes da linguagem Visão em nível funcional: Função de um componente Visão em nível de domínio: Contexto de operação do sistema. Visões de Software 6
Etapas da Núcleo da : Ler o código sem ou com pouca documentação em diferentes níveis de abstração: sistema, programa, componente, padrão etc.) Entradas: Código fonte Dicionário de dados DDL (Linguagem de definição de dados) Saídas: Desenho do Banco de Dados Estrutura física dos dados Diagrama Entidade-Relacionamento Modelo de dados normalizado Especificações do Projeto 7
Etapas da : Etapa 1: Visualização do Código Fase de Redocumentação Representação a partir do código fonte Intenção de recuperar a documentação Visualização do código: não transcende a visão em nível estrutural Etapas da : Etapa 2: Entendimento do Programa Recuperação do Projeto A partir de uma combinação entre: Código Documentação existente Experiências pessoais e conhecimentos gerais sobre o problema e o domínio da aplicação 8
Etapas da : x Ética e Direitos Autorais Dúvida: Aplicar técnicas de em código de terceiros constitui um infração da Legislação de Propriedade Industrial ou Intelectual de Software? 9
x Ética e Direitos Autorais A prática será legal se: O desenvolvedor encerrou as atividades legais e não existe empresa sucessora Para estudos sem finalidade comercial, a menos que o proprietário declare expressamente o contrário. Quando tratar-se de Software Livre e sejam atendidas as quatro liberdades da GPL (General Public Licence) x Ética e Direitos Autorais Liberdades da General Public Licence (GPL): Liberdade 1: Executar o programa para qualquer propósito Liberdade 2: Estudar como o programa funciona e adaptálo a suas necessidades: Liberdade 3: Redistribuir cópias do programa Liberdade 4: Modificar o programa e distribuir suas melhorias para o público em geral, para que todos possam se beneficiar 10
Conceito Compreende uma série de atividades como: Inventário das aplicações Reestruturação da Documentação Reestruturação de Código e Dados Ponto de partida: Projeto ou versão executável caixa preta. Intenção: criar novas versões dos produtos mais críticos, com alta qualidade e melhor manutenibilidade. Algumas definições: Chiskofsky (1990): alteração de um sistema de software. Wander (1992): melhoramento do sistema, sem alteração de suas funções. Premerlani e Blaha (1994): reduzir custos de manutenção e melhoria na flexibilidade do software. Pressman (1995): reconstrução do sistema preservando as funções existentes, ao mesmo tempo que se adiciona novas funções. 11
Objetivos: Construir um sistema novo com maior facilidade de manutenção. Engenharia reversa é usada como parte do processo de Reengenharia. + Reengenharia 12
Por que a Reengenharia? Surgiu a necessidade de melhoria nos serviços e produtos oferecidos Houve uma compressão na margem de lucro das empresas Há redução do ciclo de vida dos produtos Explosão tecnológica Desgaste natural do software Usos da Reengenharia Migrar software de plataformas centralizadas para ambientes distribuídos Mudança de paradigma: a Programação Orientada a Objetos tem mais vantagens já que com ela os sistemas são mais flexíveis, adaptáveis e extensíveis (classes, objetos, herança e polimorfismo) No entanto, consome tempo e dinheiro, podendo durar alguns meses ou anos. 13
Como realizar a Reengenharia Duas fases distintas: Desmontado : visando o entendimento do programa Reconstruído : para ficar na forma desejada Reengenharia = + Engenharia Progressiva Como realizar a Reengenharia 14
Bibliografia Esta aula foi retirada dos seguintes livros/artigos: Software Maintenance: Concepts and Practice. PENNY GRUBB and ARMSTRONG A. TAKANG. Material de Engenharia de Software do Prof. Dr. José Oscar F. de Carvalho. 15