REENGENHARIA E ENGENHARIA REVERSA

Transcrição

1 REENGENHARIA E ENGENHARIA REVERSA Manutenção de Software Profa. Cynthia Pinheiro Definição: É o exame, análise e/ou reestruturação de um sistema de software para reconstruí-lo em uma nova forma. Objetivos: Entender os artefatos do sistema existente: especificação, projeto, implementação e documentação. Melhorar as funcionalidades e os atributos de qualidade do sistema como evolutividade, performance, reusabilidade etc. Em síntese: converter um sistema ruim, que já existe, em um bom sistema. 1

2 Riscos envolvidos: O novo sistema pode não ter as mesmas funcionalidades do sistema existente; O novo sistema pode ser de qualidade inferior em relação ao sistema original; Os benefícios com a migração podem não ser perceptíveis no espaço de tempo desejado. Objetivos gerais: Melhorar a manutenibilidade; Migrar para uma nova tecnologia; Melhorar a qualidade; Preparar para uma melhoria funcional (das funcionalidades). Objetivo: Melhorar a Manutenibilidade À medida que o sistema cresce e evolui, o custo da manutenção também cresce porque as mudanças tornam-se mais difíceis e demandam mais tempo para serem feitas (2ª Lei de Lehman). Neste caso, não há como evitar a : O sistema é reprojetado com interfaces mais específicas e módulos funcionais mais relevantes. A documentação externa e interna é atualizada. Isso leva a uma melhor manutenibilidade do sistema. 2

3 Objetivo: Migrar para uma nova tecnologia Sistemas devem ser continuamente adaptados, caso contrários, eles se tornam cada vez menos satisfatórios (1ª Lei de Lehman). Fornecedores de software sentem-se cada vez menos motivados a dar suporte a sistemas antigos que tornam-se incompatíveis ou mais caros que os novos. A medida que o sistema evolui o expertise do pessoal de manutenção se concentra em novas tecnologias, com menos pessoas necessárias para manter o sistema antigo. Tendência: migrar para plataformas de execução mais modernas que incluem novos hardware, SO e/ou linguagem de programação. Objetivo: Melhorar a Qualidade Stakeholders perceberão o declínio da qualidade de um sistema a menos que ele seja rigorosamente mantido e adaptado a seu ambiente. (7ª Lei de Lehman) A medida que o tempo passa, os usuários solicitam mais e mais mudanças e cada mudança pode causar efeitos colaterais, ou seja, originar mais problemas a serem consertados. Tendência: nível de confiabilidade do sistema gradualmente decresce até chegar a um nível inaceitável. Neste caso, o sistema deve passar por uma para voltar a tornar-se confiável. 3

4 Objetivo: Preparar para uma melhoria funcional A funcionalidade de um programa deve ser continuamente aumentada para manter a satisfação do usuário ao longo do ciclo de vida do sistema. (6ª Lei de Lehman) Programas, sendo finitos, limitam suas funcionalidades através de uma seleção finita em um conjunto infinito de possibilidades. No decorrer do tempo, estas limitações passam a ser fonte de insatisfação e erros. Consequência: novas funcionalidades devem ser implementadas ou melhoradas para satisfazer os stakeholders. Geralmente, a não traz novas funcionalidades ao sistema, mas prepara para o passo seguinte, a melhoria das funcionalidades existentes. Princípio da Abstração: O nível de abstração da representação de um sistema pode crescer gradualmente através da substituição de detalhes por informações abstratas. Através da abstração pode-se focar em certas características selecionadas do sistema através da ocultação de informações de outras características que não são relevantes. 4

5 Princípio do Refinamento: O nível de abstração da representação de um sistema é diminuído gradualmente através de substituições sucessivas de partes do sistema por informações mais detalhadas. Engenharia Avante: Este é o movimento de cima para baixo, da formulação de conceitos até a implementação. Engenharia Reversa: É o movimento de baixo para cima, através dos níveis de abstração. 5

6 Engenharia Reversa: Processo que compreende os seguintes passos: Analisar o software para determinar seus componentes e o relacionamento entre eles. Representar o sistema em um nível mais alto de abstração ou em outra forma. Exemplos: decompilação, extração de arquitetura, geração de documentação, visualização de software. Tipos de Engenharia Reversa Decompilação: código-objeto é traduzido para uma linguagem de mais alto nível; Extração de arquitetura: o projeto do software é determinado; Geração de documentação: informação é extraída do código fonte, para um melhor entendimento do programa; Visualização de software: algum aspecto do programa é retratado em uma forma específica. 6

7 Significado dos quatro níveis de abstração: Por que o sistema existe? O que o sistema faz? Quais são as características necessárias ao sistema e como ele as obtém? Como o sistema é implementado? Princípio da Alteração: É o processo de realizar mudanças na representação de um sistema; Ocorre em apenas um nível de abstração (não passa de um nível a outro); Não envolve modificação, exclusão ou adição de informação. 7

8 Princípio da Alteração: A Alteração não é essencial para a mas, geralmente, o caminho da Abstração ao Refinamento é feito através dela. Pode ser conhecida também como Reestruturação, que é um tipo de Manutenção Preventiva. Possíveis objetivos de um Modelo Geral para : Traduzir o código de um sistema existente em outra linguagem; Encontrar os requisitos do sistema existente; Comparar os requisitos que já existiam com os novos que foram encontrados; Remover os requisitos que não são mais necessários; Fazer um novo projeto de software para o sistema-alvo; Codificar o novo sistema. 8

9 Passos de um modelo geral para : Engenharia Reversa (Abstração) Redesign (Alteração) Engenharia Avante (Refinamento) = Engenharia Reversa + + Engenharia Avante Passos de um modelo geral para : Tipos de alterações 9

10 Tipos de Alterações: Recodificar (Recode): Reformulação ou Tradução de código. Tradução de Código (para outra linguagem): Compilação: transformar um programa em uma linguagem de alto nível para uma linguagem de montagem ou código de máquina. Decompilação: transformação onde um código em uma linguagem de alto nível é descoberto a partir de um programa executável. Migração: um programa é transformado em outro, em uma linguagem diferente da do programa original; o mesmo nível de abstração é mantido. Tipos de Alterações: Recodificar (Recode): Reformulação ou Tradução de código. Reformulação de Código: Normalização: Reduz o programa a outro em uma sub-linguagem (subconjunto da original) para reduzir a complexidade sintática. Ex: eliminação de GOTO e achatamento de código. Otimização: transformação que melhora o tempo de execução ou otimiza o gerenciamento de espaço em memória de um programa. Refatoração: reestruturação de um programa para que fique mais fácil de entende-lo. 10

11 Tipos de Alterações: Reprojetar (Redesign): Algumas características de projeto são modificadas. Mudanças comuns: Reestruturar a Arquitetura Modificar o Modelo de Dados do sistema Substituir um procedimento ou algoritmo por um mais eficiente. Tipos de Alterações: Reespecificar (Respecify): Mudar algumas características dos requisitos através de: Mudança na forma dos requisitos. Exemplo: transformar requisitos escritos em Linguagem Natural para uma especificação mais formal, como diagramas da UML. Mudança no escopo dos requisitos. Exemplo: incluir, excluir ou alterar requisitos existentes. 11

12 Tipos de Alterações: Repensar (Rethink): Manipular as características conceituais de um software em operação para criar um novo sistema que operará em um domínio diferente. Exemplo: Mudar do desenvolvimento de um telefone celular normal para o desenvolvimento de um sistema para smartphones. Processos para : Abordagem Big Bang : Substitui o sistema inteiramente e de uma vez só: tarefa monolítica. Consome muitos recursos humanos e leva tempo para que o novo sistema seja visível. Usado para o caso em que a reengenharia não pode ser feita por partes, por exemplo, quando há a necessidade de mudar a arquitetura do sistema. 12

13 Processos para : Abordagem Incremental: O sistema é refeito gradualmente, através do release de sucessivos incrementos. Vantagens: É fácil localizar os erros (está dentro do que foi entregue no incremento) Riscos podem ser mais facilmente acompanhados. Usuários acompanham o progresso do novo software. Desvantagens: Leva mais tempo para finalizar (múltiplos incrementos, controle de versão) Neste caso, não pode incluir a alteração da arquitetura do sistema. Processos para : Abordagem Parcial Apenas uma parte do sistema passa pelo processo de ; após a transformação, é reintegrado à parte que permaneceu original. Para a parte a ser alterada, pode-se usar a abordagem Big Bang, a Incremental ou qualquer outra que se adeque. A parte a ser modificada é apenas aquela que precisa urgentemente de. Vantagens: Leva menos tempo e custa menos também. 13

14 Processos para : Abordagem Iterativa Altera poucas funcionalidades por vez, mantendo a familiaridade do sistema. Cada operação de dura pouco tempo. O Processo é repetido continuamente em diferentes componentes que estão em diferentes estágios: Código antigo que ainda não passou pela reengenharia, Código que atualmente passa pelo processo de reengenharia, Códigos já alterados através da reengenharia e Novos componentes adicionados. Processos para : Abordagem Incremental x Abordagem Iterativa 14

15 Processos para : Abordagem Evolucionária Semelhante à abordagem Incremental: componentes do sistema original são substituídos por componentes modificados através de. Mas aqui, os componentes existentes são agrupados por funções e transformados em novos componentes. Foco: identificar objetos funcionais, independentemente de onde se localizam, para criar componentes mais coesos e de menor escopo. Bibliografia Esta aula foi retirada dos seguintes livros/artigos: Software Evolution and Maintenance. Priyadarshi Tripathy and Kshirasagar Naik. 15