Reengenharia de Software

4,963 views
4,810 views

Published on

Trabalho acadêmico sobre Reengenharia de Software para a cadeira de Engenharia de Software do Unilasalle Canoas

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,963
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
199
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Reengenharia de Software

  1. 1. Reengenharia<br />de Software<br />
  2. 2. APRESENTAÇÃO<br />Participantes<br />Daniele Ortiz<br />MaurícioSpolavori<br />Peterson Basso<br />Rafael Berto<br />
  3. 3. REENGENHARIA<br />Conceito<br />A Reengenharia consiste em repensar e redesenhar radicalmente os processos de negócio com o objetivo de conseguir grandes melhoras de desempenho, seja nos custos, na qualidade, no serviço ou no tempo.<br />"Encarar o amanhã pensando em usar métodos de ontem é ver a vida estagnada"<br />James Bell<br />
  4. 4. REENGENHARIA<br />Origem<br />O conceito de reengenharia surgiu no início da década de 1990 em um artigo escrito por Michael Hammer para a Harvard Business Review.<br />" Está na hora de parar de seguir as trilhas das vacas. Em vez de acrescentar processos ultrapassados em hardware e software, devemos rejeitá-los e começar de novo. Devemos fazer uma "reengenharia" em nossos negócios. "<br />Michael Hammer<br />
  5. 5. REENGENHARIA<br />Motivações<br />O sistema não atende mais as necessidades (requisitos)<br />Sistema sem documentação<br />Modernização de sistemas legados<br />Custo muito alto para manter o sistema legado<br />Código muito bagunçado e com muitos erros<br />Processos de negócio ultrapassados<br />
  6. 6. REENGENHARIA<br />Introdução<br />A Reengenharia ocorre em dois níveis:<br /> <br />Reengenharia de processo de negócio, concentra-se nos processos de negócio para melhorar a competitividade em alguma área.<br />Reengenharia de Software, examina os sistemas de informação com a finalidade de reestruturá-los para que tenham uma melhor qualidade.<br />
  7. 7. A reengenharia de processos de negócio (BPR) muitas vezes resulta em nova funcionalidade de software, enquanto a reengenharia de software trabalha para substituir funcionalidades existentes por um software melhor, mais fácil de manter.<br />
  8. 8. REENGENHARIA<br />Modelo de BPR<br />Assim como a maioria das atividades<br />de engenharia, a reengenhariados processos de negócioé iterativa. <br />
  9. 9. REENGENHARIA<br />Ciclo<br />Abrange uma sériede atividades.<br />
  10. 10. REESTRUTURAÇÃO<br />De Documentos<br />Pouca documentação é a marca registrada de muitos sistemas herdados.<br />O que fazer?<br />Se o sistema funciona, não documenta-se nada<br />A documentação precisa ser atualizada, mas os recursos são limitados- Documenta-se apenas as partes que estão sofrendo modificações<br />É necessário redocumentar por completo- Limita-se a documentação ao mínimo essencial<br />
  11. 11. ENGENHARIA REVERSA<br />Conceito<br />Consiste em analisar o sistema ou a ferramenta para criar uma representação dela. Objetivo é derivar o projeto ou a especificação de um sistema a partir de seu código-fonte; um novo sistema, com manutenção mais fácil.<br /> <br />A Engenharia Reversa faz parte do processo de reengenharia, mas não é o mesmo que a Reengenharia visto que esta analisa oprojeto e cria uma representação do mesmo quefuncione exatamente como a primeira, mas quenão seja meramente uma cópia dela.<br />
  12. 12.
  13. 13. ENGENHARIA REVERSA<br />Primórdios<br />Bombardeiro B-29 (Enola Gay)<br />Processador Intel 8080<br />Tupolev TU-4<br />
  14. 14. ENGENHARIA REVERSA<br />Porqueutilizar?<br />Sistema  iniciado a muitos anos, com pouca documentação e sem atualização.<br />Desenvolvedores não fazem mais parte da empresa<br />Trechos de código criados sem nenhum padrão.<br />Sistema implementado numa linguagem antiga (Cobol, Fortran, APL).<br />Quando o suporte de hardware ou software se torna obsoleto.<br />Disponibilizar novas funcionalidades.<br />Correção de bugs.<br />
  15. 15. ENGENHARIA REVERSA<br />Elementos<br />1. Nível de Abstração: caracterizado pelo nível de detalhes durante o processo de desenvolvimento do projeto. <br />Nível de abstração e grau de abstração são grandezas distintas. O nível de abstração diferencia os estágios do projeto e o grau de abstração está intrínseco no projeto. <br />Quanto mais detalhado o projeto (baixo grau de abstração) e quanto mais sucinto (alto grau de abstração).<br /> <br />2. Completeza: refere-se ao nível de detalhes que é fornecido em cada nível de abstração e indica o quão abrangente é o processo de engenharia reversa. Quanto mais abrangente ele for, mais difícil será manter um nível de abstração alto, pois isso demandará muito trabalho.<br />
  16. 16. ENGENHARIA REVERSA<br />Elementos<br />3. Interatividade: refere-se ao grau de participação do ser humano no processo de engenharia reversa. Conforme o nível de abstração aumenta, a interatividade deve aumentar ou a completitude será prejudicada. <br /> <br />4. Direcionalidade: sentido único, informação extraída do código fonte é usada durante as atividades de manutenção. Sentido duplo, a informação é usada para "alimentar" uma ferramenta de reengenharia que tentará regenerar o programa antigo.<br />
  17. 17. Códigofontesujo<br />Códigoreestruturado<br />Processamento<br />Códigofontelimpo<br />Extração de abstrações<br />Interface<br />Especificação Final<br />Base de dados<br />Refinar e simplificar<br />Especificação Final<br />
  18. 18. ENGENHARIA REVERSA<br />Entendimento<br />Determinar quais são os componentes básicos do sistema, como arquivos, rotinas, variáveis, diretório de determinado arquivo, onde se encontram determinadas variáveis, etc.<br />Qual arquivo depende de outro, qual rotina depende de outra, etc.<br />Realizar uma análise dinâmica, que consiste em executar o programa e monitorar os valores das variáveis, quais funções são chamadas, etc.<br />Realizar análise estática para saber quais funções uma função pode chamar. Mas para saber quais ela realmente chama, precisamos da análise dinâmica, etc. <br />
  19. 19. ENGENHARIA REVERSA<br />Aplicações<br />SambaPermite que sistemas que não estão rodando o Microsoft Windows compartilhem arquivos com sistemas que estão utilizando esta plataforma.<br />WinePermite executar aplicativos desenvolvidos para Windows no GNU/Linux. <br />OpenOffice.orgÉ um conjunto de aplicativos OpenSource. Disponível para diferentes plataformas: incluindo Microsoft Windows, Unix, Solaris, Linux e Mac OS. Compatível com o Microsoft Office.<br />
  20. 20. ENGENHARIA REVERSA<br />AspectosLegais<br />Nos Estados Unidos, a lei “Digital Millenium Copyright Act” aprovada em 1998, protege os direitos autorais na informática e faz restrições em relação à engenharia reversa. Só é permitido analisar para fins de compatibilidade com outros softwares e/ou hardware. <br />Na União Européia, o “EU Copyright Directive”, de 2001, é similar ao “Digital Millenium Copyright Acts”. Não é tão restritiva.<br />No Brasil, não existe uma lei específica sobre Engenharia Reversa, mas quando ocorre verifica-se se o objetivo. Constatado crime, a Lei de Software e de Direitos Autorais protege seus autores.<br />
  21. 21. REESTRUTURAÇÃO<br />Conceito<br />A reestruturação de software modifica o código-fonte e/ou dados com o objetivo de torná-los mais amenos a futuras modificações.<br /> <br />Tende a se focar nos detalhes de projeto de módulos individuais e nas estruturas de dados locais definidas nesses módulos.<br /> <br />Se a reestruturação abrange a arquitetura de software, a reestruturação se transforma em Engenharia Avante.<br />Etapas de Reestruturação:<br />Reestruturação do Código<br />Reestruturação dos Dados<br />
  22. 22. REESTRUTURAÇÃO<br />De Código<br />É realizada para executar um projeto que produz a mesma função que o programa original, porém com mais qualidade.<br />Benefícios:<br />Aumento da qualidade, devido ao código construído seguir boas práticas de design. <br />Deixa o código mais “limpo”, facilitando o entendimento deste.<br />Facilita as manutenções no código.<br />Apesar de poderaliviarproblemasimediatos, relacionados com depuraçãooupequenasmodificações, nãoconstituireengenharia.<br />
  23. 23.
  24. 24. REESTRUTURAÇÃO<br />De Dados<br />Antes de ser realizada a reestruturação de dados é feita a análise do código-fonte, também chamada de análise de dados.<br />Quando a estrutura de dados é fraca, os dados passam por reengenharia, começa então o reprojeto dos dados.<br />As modificaçõesnos dados resultarãotantoemmodificaçõesarquiteturaisquanto de código.<br />
  25. 25. REESTRUTURAÇÃO<br />Formas de Reprojeto<br /> Padronização de registro de dados<br />Esclarece definições de dados para obter consistência entre os nomes dos itens de dados, ou entre os formatos de registro físico dentro da estrutura de dados existentes.<br /> Racionalização dos nomes dos dados<br />Garante que todas as convenções de denominação de dados atendam aos padrões locais e que os sinônimos sejam eliminados a medida que os dados fluam através do sistema.<br />
  26. 26. REESTRUTURAÇÃO<br />Ferramentas<br />DMS Software ReengineeringToolkitReestruturação para COBOL,C/C++, Java, FORTRAN 90 e VHDL.<br />FORESYSReestruturação para FORTRAN.<br />FunctionEncapsulationToolReestruturação de programas antigos em C para C++. <br />plusFORTReestruturação para FORTRAN e de FORTRAN para C.<br />
  27. 27. ENGENHARIA AVANTE<br />Melhorias<br />Como acomodar alterações exigidas pelo usuário com milhares de linhas de código fonte sem nenhuma documentação?<br />Podemos batalhar modificação por modificação<br />Podemos tentar entender o funcionamento interno paratornar as modificações mais eficazes<br />Podemos reprojetar, recodificar e testar a funcionalidadeque exige modificação<br />Podemos reprojetar, recodificar e testar o softwareinteiro, afim de facilitar melhorias futuras<br />Normalmente é usada a primeira opção, mas isso não querdizer que seja a melhor opção.<br />
  28. 28.
  29. 29. ENGENHARIA AVANTE<br />Manter x Redesenvolver<br />Devemos considerar os seguintes pontos:<br />Custo para manter o código-fonte atual é de 20 a 40 vezes do que desenvolver um novo código<br />Reprojetar a arquitetura do software pode facilitar manutenções futuras<br />O fato de existir um protótipo do software, pode aumentar a produtividade do desenvolvimento<br />Usuário tem mais experiência, e pode sugerir melhorias em funcionalidades<br />Ferramentas automatizadas podem facilitar o processo<br />Documentação passará a existir<br />
  30. 30. ENGENHARIA AVANTE<br />O que é issoafinal?<br />O processo de engenharia avante aplica conceitos e métodos de engenharia de software para recriar uma aplicação existente. Na maioria dos casos, a engenharia avante não cria simplesmente um equivalente moderno de um programa antigo.<br />A idéia principal é que o programa redesenvolvido amplie a capacidade da aplicação antiga.<br />
  31. 31. ENGENHARIA AVANTE<br />Para…<br />ArquiteturaCliente / Servidor<br />ArquiteturaOrientada a Objetos<br />Interface com o Usuário<br />
  32. 32. ENGENHARIA AVANTE<br />ArquiteturaCliente / Servidor<br />É importante notar que a migração de um computador de grande porte para cliente/servidor exige reengenharia, tanto do negócio quanto de software.<br />Em alguns casos, a migração para uma arquitetura cliente/servidor deve ser abordada não como reengenharia, mas como um esforço de desenvolvimento novo. A reengenharia entra em cena apenas quando a funcionalidade específica do sistema antigo precisa ser integrada na nova arquitetura.<br />Passos da engenharia para arquiteturas Cliente/Servidor:<br />Engenharia reversa<br />Preparação/Adaptação da infra-estrutura<br />Migração do Banco de Dados para o servidor<br />Adaptação do software para rodar no cliente<br />
  33. 33. ENGENHARIA AVANTE<br />ArquiteturaOrientada a Objetos<br />Podemos afirmar que é uma das arquiteturas mais utilizadas atualmente.<br />Na maioria dos casos, migrar para essa arquitetura ocasiona a reescrita de muito código, quando não todo.<br />Passos da engenharia para arquiteturas Orientadas a Objetos:<br />Engenharia reversa<br />Criação de modelos de dados, funcionais e comportamentais<br />Criação de casos de uso<br />Modelagem de Classes<br />
  34. 34. ENGENHARIA AVANTE<br />Interfaces com o Usuário<br />Passos da engenharia para Interfaces com o Usuário:<br />Entender as tarefas realizadas e os dados importantes apresentados<br />Remodelar o comportamento, sem ser radical<br />Aplicar melhorias<br />
  35. 35.
  36. 36. ENGENHARIA AVANTE<br />Custox Benefício<br />Análise custo/benefício por Sneed:<br />P1 = custo de manutenção anual corrente de uma aplicação<br />P2 = custo de operação anual corrente para uma aplicação<br />P3 = valor de negócio anual corrente de uma aplicação<br />P4 = custo de manutenção anual previsto após reengenharia<br />P5 = custo de operação anual previsto após reengenharia<br />P6 = valor de negócio anual previsto após reengenharia<br />P7 = custo estimado de reengenharia<br />P8 = período estimado para reengenharia<br />P9 = fator de risco de reengenharia ( P9 = 1,0 é nominal)<br />L = esperança de vida do sistema<br />
  37. 37. ENGENHARIA AVANTE<br />Custox Benefício<br />Custo com aplicação atual:<br />Cmanut = [P3 – (P1 + P2)]xL<br />Custo com reengenharia:<br />Creeng = [P6 – (P4 + P5)X(L – P8) – (P7 x P9)]<br /> <br />Custo/Benefício = Creeng - Cmanut<br />
  38. 38.
  39. 39. REENGENHARIA<br />Referências<br />Engenharia de Software 6ª Edição – Roger S Pressman<br />http://isosoftware.blogspot.com/2009/10/engenharia-reversa-de-software.html <br />Engenharia Reversa – www.youtube.com.br<br />Engenharia Reversa - Proj. Assis. por Comp.  - www.youtube.com.br<br />http://dinamico.orgfree.com/softwares/desafios.html<br />http://www.dcc.ufrj.br/~schneide/es/2001/1/g18/Engenharia%20Reversa.htm<br />http://www.slideshare.net/adorepump/engenharia-reversa-e-reengenharia-software-presentation<br />http://www.dcc.ufrj.br/~schneide/es/2002/1/g13/trabalho.htm<br />http://www.dcc.ufrj.br/~schneide/es/2001/1/g19/atividades.html<br />http://projetos.inf.ufsc.br/arquivos_projetos/projeto_218/TCC-PauloCesarAllebrandt.pdf<br />

×