Manutenção de Software Técnicas de Gestão da Manutenção de ...rosangela/ES/aulas-2006/manutencao-06.pdf · • Engenharia Reversa – Recuperação de software existente com

1

Técnicas de Gestão daManutenção de Software

Rosângela PenteadoParte do material preparado em conjunto

com Nicolas Anquetil- UCB

Manutenção de Software• Modificação de software – inevitável

– Surgem novos requisitos – O ambiente do negócio muda – Erros devem ser reparados – Novo equipamento deve ser

incorporado – O desempenho do software pode ser

melhorado

Manutenção

•Quem poderáme ajudar ????

•O quê fazer ???

•Cadê o programador ????

•O quê será que ele quisfazer aqui?????

Sistemas legados• Problema chave para as organizações é

implementar e gerir modificações em seus sistemas legados

• Preconceitos– Desenvolver é mais atraente do que manter!– Estagiário corrige erros!– Por que já não fizeram correto da primeira

vez?– Esse sistema nunca precisará de

manutenção – está perfeito!!!

2

Manutenção de Software: conceitos

• Modificar um programa depois que ele foi colocado em uso (após a entrega)

• As modificações são implementadas modificando os componentes existentes e adicionando novos componentes ao sistema

Como fazer Manutenção

• Amanhã começaremos a manter um sistema desenvolvido há 10 anos, com x KLOC ?!?!?!?

• NÃO FUNCIONA!!!

Como deve ser feito

• Planejada• Preparada• Organizada

• A partir do desenvolvimento

- Documentação do sistema

- Utilização de ferramentaspara entendimento do sistema.

Como?

Tipos de Manutenção• Corretiva : erros que aparecem, mesmo com

desenvolvimento de qualidade.

• Adaptativa: modificação de SO, regra de negócio

• Perfectiva ou de melhoria: novos requisitos.

• Preventiva ou reengenharia: prevenirproblemas antes que eles ocorram.

3

Quanto consome?

25%Adaptativa

50% Evolutiva

21%Corretiva

4%Preventiva

Gastos com manutenção

• Aproximadamente 20% de todo trabalho de manutenção é corrigir erros

• 80% são gastos adaptando sistemas existentes a modificações no seu ambiente externo; fazendo melhorias solicitadas pelo usuário e submetendo uma aplicação a reengenharia, para uso futuro.

Processo de manutenção

• Esforço durante o processo não é repartidoda mesma maneira na manutenção e no desenvolvimento

• Um processo de manutenção deve privilegiaras atividades iniciais (análise do problema e do sistema)

Ciclo de vida

Esfo

rço

Análise Especificação Projeto Implementação Teste Operação

Manutenção

Desenvolvimento


• Até processo de desenvolvimento iterativo moderno (RUP/USDP) não é completamente adaptado à manutenção– RUP/USDP tem uma visão essencialmente de

software, a manutenção necessita de uma visão mais sistêmica (inclui dados, hardware, operações manuais, etc

4


• RUP/USDP como processo de manutenção (cont.)– Não considera análise do pedido de modificação e

verificação de problema– Não considera atividade de garantia de qualidade

(ex: Revisão/Aceitação da manutenção)– Não prevê o caso de um software legado não estar

documentado

ISO 12207

• Framework para processos de ciclo de vidacom terminologia bem definida

• Contém– processos, – atividades e

– tarefas

Estrutura de processo - ISO 12207

Processo

Atividade n

Tarefa 1

...

Tarefa k Tarefa 1 ... Tarefa k

Atividade 1

...

Características da ISO 12207

• Não especifica o como implementar ouexecutar as atividades e tarefas

• Não determina um modelo de ciclo de vida oumétodo de desenvolvimento

• Deve ser adaptada de acordo com o organização e projetos específicos

5

Estrutura da ISO 12207PROCESSOS FUNDAMENTAIS

Aquisição

PROCESSOS DE APOIO

PROCESSOS ORGANIZACIONAIS

Fornecimento

Desenvolvimento

Operação

Manutenção

Documentação

Gerência de Configuração

Garantia de Qualidade

Verificação

Validação

Revisão junta

Auditoria

Resolução de Problemas

Gerência Infra-estrutura Melhoria Treinamento

Manutenção

Processos na Norma ISO 12207

• Processos Fundamentais– Atendem as partes fundamentais durante o ciclo

de vida de um software– Envolve a contratação entre o adquirente e o

fornecedor, a execução do desenvolvimento daoperação e da manutenção

– Exemplo: Desenvolvimento, Manutenção, Acquisição, ...


• Processos de Apoio– Auxiliam um outro processo como uma parte

integrante– É empregado e executado quando necessário por

outro processo– Exemplo: Verificação, Validação, Documentação, ...


• Processos Organizacionais– Empregados por uma organização para estabelecer

uma estrutura subjacente constituída de processosde ciclo de vida e de pessoal associados, para melhorar continuamente estrutura e os processos.

– Exemplo: Treinamento, Gerência, ...

6

Processo de Manutenção - ISO 12207

• Implementação do processo• Análise do problema e da modificação• Implementação da modificação• Revisão/Aceitação da manutenção• Migração• Descontinuação do software

ISO 14764• Norma internacional de manutenção• Define um processo de manutenção idêntico ao

da ISO 12207, mas mais detalhado• Define outros procedimentos relacionados à

manutenção– Definição e a estrutura de um plano de manutenção

ISO 14764

Implementaçãodo processo

Análise do problema e damodificação

Implementaçãoda modificação

Revisão/Aceitaçãoda manutenção

MigraçãoDescontinuação do

software

ISO 14764






software

• Atividade com dois objetivos

– Preparação da manutenção no início do ciclo de vida de um software (inclusive definição dos processos a serem seguidos)

– Customização do processo padrão para um projeto de manutenção dado

7

ISO 14764






software

• “Primeira” atividade num projeto de manutenção• Tem por objetivo analisar a solicitação de modificação para

verificar sua validade, definir sua prioridade e decidir dasua realização

ISO 14764






software

• Realização efetiva da modificação• Para manutenção evolutiva será aplicado um processo de

desenvolvimento “tradicional” (especificação de requisitos, análise, projeto, implementação, ...)

ISO 14764






software

• “Última” atividade de um projeto de manutenção• Atividade de garantia de qualidade

ISO 14764






software

• Atividade a realizar quando o software precisa ser migradopara um novo ambiente

• Pode ser adaptado no caso de migração de uma nova versãodo software após uma manutenção

8

ISO 14764






software

• Atividade a realizar quando o software precisa ser descontinuado (abandonado)

ISO 14764






software

ISO 14764 -Implementação processo• Tarefas:

– Desenvolver o plano e o processo de manutenção (Criado junto com o plano de desenvolvimento; Define quem fará a manutenção, que tipo de manutenção será feito, estima os custos (e outros recursos), define como se fará a transição entre desenvolvedor e mantenedor, define o processo de manutenção a ser usado)

– Desenvolver os procedimentos de solicitação de modificação (Criar um esquema de numeração, categorização, priorização, acompanhamento e atualização dos pedidos de manutenção; Definir o processo de submissão de um pedido e como será dado o retorno (inicial e de acompanhamento) aos usuários (inclusive solução temporaria de contorno de problemas))

– Implementar a gerência da configuração (Definir e implementar um processo de gestão de configuração para gerenciar as modificações ao sistema. Esse processo é usado também no desenvolvimento do software; Exemplo: processo da ISO 12207)

– Produtos

ISO 14764 -Implementação processo

Produtos– Plano de manutenção– Processo de manutenção– Procedimentos de resolução de problemas– Planejamento de comunicação com os

usuários/clientes– Plano de transição– Plano de gestão de configuração

9

ISO 14764






software

ISO 14764 – Análise do Pedido• Tarefas

– Análise do pedido de manutenção (Classificar a manutenção, Avaliar o impacto de fazer ou não a manutenção (custos, benefícios, impactos operacionais, de segurança, etc.); Análise da viabilidade de fazer a manutenção (recursos))

– Verificação do problema (manutenção corretiva)– Definição de alternativas de solução (pelo menos 3 alternativas de

realização da manutenção; Realizar uma análise de riscos das alternativas e uma análise do impacto de cada uma)

– Documentação (do pedido, sua análise e as alternativas de realização; Atualizar a documentação do sistema e se não existir, criar essa documentação)

– Aprovação formal da realização da modificação (cliente, usuários)– Produtos

ISO 14764 – Análise do Pedido

• Produtos– Análise de impacto– Especificação da alternativa de solução

recomendada– Aprovação formal da realização da modificação– Documentação atualizada

ISO 14764






software

10

ISO 14764 – Implementação• Tarefas:

– Identificação dos itens a ser modificado

– Processo de desenvolvimento (adaptado à manutenção específica a realizar; realizar testes das partes modificadas e não modificadas (teste de regressão); verificar que os requisitos que não mudaram não foram afetados)

– Produtos• Plano de teste atualizado

• Documentação atualizada

• Software modificado

• Relatório de teste

ISO 14764






software

ISO 14764 - Revisão/Aceitação• Tarefas:

– Revisão da manutenção (Verificação dos padrões de programação, de testabilidade do código, da atualização da documentação, que apenas o previsto foi realizado, da rastreabilidade do pedido de manutenção aos requisitos e o código)

– Aprovação da realização satisfatória da manutenção pela equipe de garantia de qualidade

– Produtos

ISO 14764 - Revisão/Aceitação

• Produtos:– Relatórios de auditoria e de revisão– Manutenção rejeitada (se for o caso)– Relatório de aceitação (se for o caso)– Relatório de Teste– Novo baseline do sistema na gerência de

configuração

11

ISO 14764






software

ISO 14764 - Migração• Tarefas:

– Verificar padrões (migrar segundo normas de qualidade)– Planejar migração (definir os requisitos da migração e seu impacto;

Identificar necessidades de ferramentas de conversão (do código ou dos dados); Definir cronograma e prioridades)

– Notificação do planejamento aos usuários (descrever as razões,cronograma; descrever alternativas de suporte para o ambiente antigo)

– Implantação em paralelo nos 2 ambientes (antigo e novo) e treinamento

– Notificação da migração (Avisar aos interessados realização da migração, Documentar (relatório) a migração; Arquivar o sistema antigo)

– Análise do impacto após a migração (Lições aprendidas)– Preservação dos dados– Produtos

ISO 14764 - Migração

• Produtos:– Plano de migração– Ferramentas de migração– Notificação da migração– Sistema migrado– Relatório de migração– Dados arquivados

ISO 14764






software

12

ISO 14764 - Descontinuação• Tarefas:

– Planejar a descontinuação (Documentar o prazo de continuação do suporte ao sistema descontinuado, as responsabilidades para ocorrências futuras, o acesso aos dados arquivados; Definir a transição entre sistema descontinuado e sistema de substituição)

– Notificação do planejamento aos usuários– Implantação em paralelo (caso tenha um sistema de

substituição) e treinamento– Notificação da descontinuação– Preservação dos dados– Produtos

ISO 14764 - Descontinuação

• Produtos:– Plano de descontinuação– Notificação da descontinuação– Relatório de descontinuação– Pessoal treinado– Systema descontinuado (baseline arquivado)– Dados arquivados

Processo de Manutenção

• Primeira de todas ações a tomar: Definir um processo de manutenção

• O processo deve ser documentado, conhecido de todos e implementado por todos


• O processo da ISO 14764 é bem completo e extenso, prevê várias situações diferentes para grandes projetos

• Na prática, um processo pode não ser tão complexo, nem precisa usar tudo em todos os casos

13







software


• 1a atividade (Implementação de processo) pode ser replicada de projeto em projeto

• 2 últimas atividades (Migração e Descontinuação) podem ser simplificadas e replicadas de projeto em projeto

• Outras 3 atividades podem ser adaptadas segundo o tamanho dos projetos

Estratégias de manutenção• Manutenção de software

– Modificações são feitas em resposta a requisitos modificados, mas a estrutura fundamental do SW é estável

• Engenharia Reversa– Recuperação de software existente com uma documentação

em um nível de abstração mais alto.• Reengenharia de software

– Nenhuma funcionalidade é adicionada ao sistema, mas ele ére-estruturado e re-organizado para facilitar mudanças futuras

• Redocumentação de software– Redocumentar o software de modo que seja mais fácil de ser

mantido.

Sistemas legados

• São os mais difíceis de manter– Desenvolvidos sem processo bem definido, ou

desenvolvidos com processos antigos– Pessoal de desenvolvimento não está mais na

empresa– Tecnologias obsoletas– Manutenção – “patchwork” – sem critério e

documentação– Regras de negócio embutidas no código fonte

14

Sistemas legados

• Importância– São antigos , mas são úteis para a empresa– Investimento substancial– Guardam informação preciosa para a empresa que é difícil de

“redescobrir”

• Precisam evoluir– Correção de bugs (por ex, ano 2000)– Mais funcionalidade (acompanhar a concorrência)– Tecnologia atual (por ex, Web, Java)– Novos ambientes computacionais– Novas regras (por ex, moeda Euro)

Reengenharia

• Leva tempo• Tem custo significativo• Absorve recursos

– Toda organização deve ter uma estratégiapragmática de reengenharia

Analogia

• Você compra uma casa por um preço razoavelmente baixo, em outro estado, sem ver a casa, sabendo que precisa de reformas

• Como proceder?– Conhecer a casa– Listar de critérios para avaliação– Antes de demolir e construir outra, verificar se a estrutura

está fraca• Estrutura ok – reconstrução• Estrutura não ok – demolição

Analogia (cont.)

• Reconstrução– Veja a fiação, estrutura interna

– Use materiais modernos e duradouros – custo mais alto no momento, mas evita problemas no futuro.

– Seja disciplinado

– Utilize práticas modernas

• Reengenharia de Software

15

Modelo de Processo de Reengenharia de Software (Pressman 2005, 6a edição)

Análise de Inventário

Reestruturaçãode documentos

EngenhariaReversaReestruturação

de código

Reestruturaçãode dados

Engenhariaavante

Análise de Inventário

• Toda empresa deve ter um inventário de todas as aplicações.

• Inventário = planilha contendo uma descriçãodetalhada (Nome da aplicação, Ano em que ela foi criada, Número de modificações significativas que foram feitas, Esforço total para fazer essas modificações, Data da ultima modificação significativa, Esforço gasto com a última modificação, Sistemas nos quais ela reside,Aplicações a que interfaces, ... )

• Analise e priorize para selecionar candidatos a reengenharia.

Reestruturação de documentos• Pouca documentação é marca registrada de muitos

sistemas herdados (legados)– A criação de documentação consome tempo demais. Se o

sistema funciona, vamos conviver com o que temos. Em alguns casos essa abordagem é correta.

– A documentação precisa ser atualizada, mas temos recursos limitados. Vamos usar a abordagem “documentar quando tocar”. Pode não ser necessário redocumentar completamente uma aplicação.

– O sistema é critico para o negócio e precisa ser totalmente redocumentado. Nesse caso, uma abordagem inteligente élimitar a documentação ao mínimo essencial.

Engenharia Reversa

• Origem do termo – hardware• Em software - similar• Definição de Engenharia Reversa:

– Processo de exame e compreensão do software existente, para recapturar ou recriar o projeto e decifrar os requisitosatualmente implementados pelo sistema, apresentando-os emum nível ou grau mais alto de abstração

• Três tópicos de engenharia reversa precisam ser tratados: nível de abstração, completeza e direcionalidade.

16

Engenharia Reversa para Entender • Ocorre em diferentes níveis de abstração

– De programa: as estruturas de dados internas do programa (esforço de reengenharia global)

– De sistema: as estruturas de dados globais (e.g.; arquivos, BD) são submetidos à reengenharia para acomodar novos paradigmas de gestão de BD (de relacional para OO, por exemplo)

• Estruturas de dados internas– Focalizam uma definição de classes de objetos (exame do código

fonte)

• Estrutura do banco de dados:– Construir um modelo de objetos inicial; determinar candidatos

importantes; refinar as classes provisórias; definir generalizações e descobrir associações.

Engenharia Reversa para Entender o Processamento

• Começa com uma tentativa de entender e depois extrair abstrações procedimentais representadas no código fonte.

• Análise em diversos níveis de abstração: sistema, programa, componente, padrão e declaração.

• Entender a funcionalidade global do sistema, antes de começar o trabalho de engenharia reversa. – Criar um diagrama de blocos, representando a interação entre essas

abstrações funcionais.– Determinar a função de cada componente que representa uma

abstração procedimental definida– Criar uma narrativa de processamento para cada componente.– Uso de ferramentas computadorizadas.

Engenharia Reversa das Interfaces com o Usuário

• IGUs sofisticadas tornaram-se uma exigência de produtos e sistemas. Antes da reengenharia de uma nova interface a engenharia reversa deve ser realizada.– Quais são as ações básicas (e.g.; pressões de teclas e cliques

de mouse) que a interface deve processar?– Qual a descrição compacta da resposta comportamental do

sistema a essas ações?– O que quer dizer “substituição” ou, mais precisamente, que

conceito de equivalência de interfaces é relevante aqui?• A interface substituída não pode espelhar exatamente a antiga

(pode ser radicalmente diferente). Desenvolver novas metáforas de interação, reduzir ou ampliar uma imagem gráfica, usar barra de rolagem, mouse para conseguir a mesma função, etc..

Quais os documentos utilizados pararealizar engenharia reversa ?

• Código fonte• Informação existente• documentação existente (manual de usuário, • manual de sistema, DFDs, fluxogramas, etc.)

17

Processo de ER (Pressman,2005)

dirty source code

restructurecode

extractabstractions

refine&

simplify

clean source code

initial specification

final specification

processing

interface

database

Código fonte sujo

Reestruturar código

Extrair abstrações

Refinar & simplificar

Processamento

Interface

Banco de Dados

Código fonte limpo

Especificação inicial

Especificação final

Propósitos da Engenharia Reversa1- Manutenção e Engenharia Revesa

• As atividades de manutenção fornecem a motivação para muitasferramentas de engenharia reversa – elevada proporção de tempo e custos despendida no entendimento e exame do software a ser mantido.

• Nas manutenções adaptativas (adequar o software a novo ambiente) e evolutivas (adicionar novas funcionalidades aosoftware), as técnicas de engenharia reversa são usadasindiretamente, através do fornecimento de visões do software, para localizar os componentes onde serão realizadas as mudanças e adições necessárias, e para auxiliar no controle da estrutura global do sistema modificado, através da produção de documentação.

Propósitos da Engenharia Reversa(manutenção e engenharia reversa)

• Nas manutenções corretivas (correção de erros), as técnicas de engenharia reversa não servem para detectar, remover ou corrigirerros, porém auxiliam indiretamente o programador na localização do componente defeituoso, através de melhorias da compreensibilidade do software

• Para mudanças preventivas (redução de esforços em futuras mudanças), ferramentas de engenharia reversa podem fornecer um discernimento de onde e como realizar mudanças apropriadas, através da produção de visões do software

• Os maiores benefícios de engenharia reversa serão mais reconhecidos quando manutenções futuras tiverem como apoio a documentação produzida numa manutenção anterior

Ferramentas de ER• Imagix 4D, desenvolvida por Imagix (www.imagix.com), “ajuda

desenvolvedores de software a entender um software complexoou legado C e C++” pela engenharia reversa e documentação do código fonte.

• Understand, desenvolvida por Scientific Toolworks, Inc. (www.scitools.com), tem analisadores sintáticos Ada, Fortran, C, C++ e Java “para fazer engenharia reversa, documentarautomaticamente, calcular métricas de código e ajudá-lo a entender, navegar e manter código fonte.”

• Uma lista abrangente de ferramentas de engenharia reversapode ser encontrada emhttp://scgwiki.iam.unibe.ch:8080/SCG/370.

18

Reestruturação de código

• Usada para executar um projeto que produz a mesma função que o programa original, com mais qualidade. – Modela a lógica do programa

• Reestruturação de dados + re-estruturação da arquitetura

• O código reestruturado resultante é revisto e testado para garantir que nenhuma anomalia foi introduzida.

• A documentação interna do código é atualizada.

Reestruturação de dados

1) Análise de código fonte

2) Avaliar: definições de dados, descrições de arquivos, entradas e saídas e descrições de interfaces.– Objetivo: extrair dados e objetos obter informação sobre

o fluxo de dados e entender as estruturas de dados existentes.

3) Re-projeto de dados: padronização de registros de dados, racionalização dos nomes dos dados

Ferramentas de Reestruturação de Código

• DMS Software Reengineering Toolkit, desenvolvida por Semantic Design (www.semdesigns.com), fornece uma variedade de capacidades de reestruturação para COBOL, C/C++, Java, FORTRAN 90 e VHDL.

• FORESYS, desenvolvida por Simulog (www.simulog.fr), analisa e transforma programas escritos em FORTRAN.

• Function Encapsulation Tool, desenvolvida por Wayne State University (www.cs.wayne.edu/_vip/RefactoringTools/), refabrica programas antigos C em C++.

• plusFORT, desenvolvida por Polyhedron (www.polyhedron.com), éum conjunto de ferramentas FORTRAN que contém capacidadespara reestruturar programas FORTRAN pobremente projetadosem normas modernas de FORTRAN ou C.

Engenharia Avante• 1. O custo de manter uma linha de código fonte pode ser de 20 a 40

vezes o custo dessa linha na fase inicial de desenvolvimento. • 2. Re-projeto da arquitetura do código fonte (programa e/ou

estrutura de dados), usando conceitos atuais de projeto, podem facilitar muito a manutenção futura.

• 3. Devido à existência de um protótipo já existente, a produtividade de desenvolvimento deve ser maior do que a média.

• 4. O usuário agora tem experiência com o software.Assim, novos requisitos e a direção da modificações pode ser determinada com maior facilidade.

• 5. Ferramentas CASE para reengenharia devem automatizar algumas partes do trabalho.

• 6. Uma configuração de software completa (documentos, programas e dados) deve existir para completar a manutenção preventiva.

19

Reengenharia

• Preservando o paradigma– Mudança de linguagem de programação

• Processo de Engenharia Reversa– Documentação – Manutenção Preventiva

• Projeto– Documentação Essencial

• Implementação– Escolha da Linguagem de Programação

Reengenharia

• Mudança de paradigma– Procedimental para OO

• Engenharia Reversa– Documentação – abstração – modelo de análise

• Projeto– Escolha de tecnologias

• Implementação– Escolha da linguagem de programação

A Economia da Reegenharia - I

• Um modelo de custo/benefício para reengenharia foi proposto por Sneed [SNE95]. Nove parâmetros são definidos:

• P1 = custo de manutenção anual atual para uma apliação.• P2 = custo de operação anual atual para uma aplicação.• P3 = valor de negócio anual atual de uma aplicação.• P4 = custo de manutenção anual previsto após a reengenharia.• P5 = custo de operação anual previsto após a reengenharia.• P6 = custo de negócio anual previsto após a reengenharia.• P7 = custo estimado de reengenharia.• P8 = período estimado para reengenharia.• P9 = fator de risco de reengenharia (P9 = 1.0 é nominal).• L = esperança de vida do sistema.

A Economia da Reegenharia - II• O custo associado com a manutenção continuada de uma aplicação

candidata (i.é., não é realizada reengenharia) pode ser definido como:

• Cmanut = [P3 - (P1 + P2)] x L

• Os custos associados com a reegneharia são definidos usando a seguinte relação:

• Creeng = [P6 - (P4 + P5) x (L - P8) - (P7 x P9)]

• Usando os custos apresentados nas equações acima, o benefício total da reengenharia pode ser calculado como:

• custo/benefício = Creeng - Cmanut

20

Relacionamento entre os termosRequisitos(restrições, objetivos,regras do negócio)

Projeto Implementação

EngenhariaAvante

EngenhariaAvante

EngenhariaReversa

EngenhariaReversa

ProjetoRecuperado

ProjetoRecuperado

Reengenharia(Renovação) ReestruturaçãoReestruturação Reestruturação

Reengenharia(Renovação)

Algumas experiências com ER

• Um ambiente para edição e simulação de statecharts – StatSim (StatechartsSimulator) [ICMC/USP-1989-1994]– Fusion/RE (Penteado, 1996), modelo de processo

seqüencial linear

• Aplicação do Fusion/RE em sistemas legados Cobol– Utilização dos modelos do Fusion, modelo de

processo iterativo.

Algumas experiências com ER (cont.)

• Sistemas legados Clipper– Desenvolvidos para atender oficina eletro-mecânica– Desenvolvidos para auxiliar no orçamento de construção civil.

• Sistemas legados Delphi– Desenvolvido para atender às necessidades de uma loja de

venda de roupas. (produto-caseiro)• SW-CMM• Padrões de processo e modelo de processo evolutivo

• Sistemas Java– Reconhecimento de padrões de projeto (Gamma et al)

Algumas experiências com Reengenharia

• C++ para Java (StatSim)– Utilização do padrão Persistence Layer– Fusion/RE, modelos UML, modelo de processo

seqüencial linear.

• Cobol para Java – Web (2 experiências)– Reuso do padrão Persistence Layer– Fusion/RE, modelos UML, modelo de processo

seqüencial linear.

21

Algumas experiências com Reengenharia (cont.)

• Clipper para Java (2 experiências)– Fusion/RE, modelo de processo seqüencial linear– Transformador Draco

• Clipper para Delphi– Criação de uma família de padrões que auxiliam no

processo de ER e Reengenharia (padrões de Demeyer)


• Delphi para Delphi OO– Utilização de padrões– KPA nível 2 CMM adaptadas para o processo de

reengenharia, descrita em forma de padrões de processo

– Modelos UML– Modelo de processo evolutivo


• Sistemas Java– Identificação de aspectos – Abordagem Aspecting– Modelos UML, Linguagens Java e Aspect J


• Apoios automatizados– FAROOL– ACRA

Documents

Manutenção de Software Técnicas de Gestão da Manutenção de ...rosangela/ES/aulas-2006/manutencao-06.pdf · • Engenharia Reversa – Recuperação de software existente com