leitura: cap26 - 27 - 28: sommerville; cap20: pressmanmaria/arqan/2011-1/cap8-manut.pdf ·...

Auxiliadora Freire Fonte: Engenharia de Software 6º Edição / ©Ian Sommerville 2000 Slide 1/47Engenharia de Software 3º Edição / Roger PressmanEngenharia de Software 1º Edição / Ariadne Carvalho

��

Leitura:Cap26 - 27 - 28: Sommerville; cap20: Pressman


� É modificar um programa depois que ele foi colocado em uso.

� A manutenção normalmente não envolve grandes mudanças na arquitetura do sistema

� As mudanças são implementadas modificando os componentes existentes e adicionando novos componentes ao sistema

Manutenção de software


� Manutenção Corretiva - Identificar e corrigir erros.

� Manutenção Adaptativa - Adaptar o software ao ambiente.

� Manutenção Perfectiva - Atender pedidos do usuário para modificar funções existentes ou incluir novas funções.

� Manutenção Preventiva - Melhorar a manutenibilidade ou confiabilidade futuras.

Tipos de Manutenção de Software


Mudança de Software


Estratégias de mudança de software

� Manutenção de software• Mudanças são feitas em resposta a requisitos

modificados, mas a estrutura fundamental do SW permanece estável.

� Transformação de arquitetura• A arquitetura do sistema é modificada geralmente de

uma centralizada p/ uma distribuída

� Reengenharia de software• Nenhuma funcionalidade é adicionada ao sistema,

mas ele é re-estruturado e re-organizado p/ facilitar mudanças futuras


� A dinâmica de evolução de programas é o estudo da mudança do sistema

� As leis de Lehman são aplicadas a todos os sistemas enquanto eles evoluem.

� As leis são derivadas das observações aplicadas a sistemas de larga escala desenvolvidos por grandes organizações

Dinâmica de evolução de programas –Leis de Lehman


5 Leis de Lehman� Mudança contínua – um programa num ambiente real

necessariamente muda ou torna-se progressivamente menos útil nesse ambiente.

� Aumento da complexidade – com a evolução do programa sua estrutura tende a ficar mais complexa.

� Evolução de programas de larga escala – a evolução de um programa é um processo auto-regulador.

� Estabilidade organizacional – mudanças de

staff/recursos tem poucos efeitos na evolução do sistema.

� Conservação da familiaridade - a mudança incremental é constante.


Distribuição do esforço de manutenção

Adição ou modificação de funcionalidade

(65%)

Reparação de Falhas (17%)

Adaptação deSW (18%)


Modelo espiral p/ manutenção

especificação

Release 1

Release 2

Release 3operação

implementação

validação


Custos de manutenção

0 50 100 150 200 250 300 350 400 450 500 $

Sistema1

Sistema2

Custos de desenvolvimento Custos de manutenção


� Estabilidade da equipe - Custos de manutenção são menores se a mesma equipe está envolvido com o sistema.

� Responsabilidade contratual – Se os engenheiros de SW não tem nenhuma responsabilidade contratual p/ a manutenção, não há incentivo em documentar o SW p/ garantir mudança futura.

� Habilidades da equipe - A equipe de manutenção éinexperiente e tem conhecimento limitado do domínio.

� Idade e estrutura do programa - Enquanto o programa envelhece, sua estrutura se degrada tornando-o mais difícil de compreender e mudar.

Manutenção - Fatores de custos


O processo de manutenção

Planejamento de release

Pedidos de alterações

Análise de impacto

Implementação de mudança

Release do sistema

Reparo de defeitos

Adaptação da

plataforma

Incrementode sistema


Pedidos de mudança

� São feitos pelos utilizadores, clientes ou gerentes.

� Na prática, alguns pedidos devem ser implementados urgentemente:• Reparar falhas • Mudanças no ambiente • Mudanças urgentes do negócio


Implementação de mudança

Validaçãode requisitos

Mudançaspropostas

Análise de requisitos

Desenvolvimento do Software


Reparação de emergência

Modifique o código-fonte

Pedido de alteração

Análise o código-fonte

Libere o sistema modificado


Previsão de mudança� A previsão de mudança preocupa-se em avaliar

as partes do sistema que podem causar problemas e ter custos de manutenção altos• A aceitação da mudança depende da facilidade de manutenção

dos componentes afetados pela mudança.

• Implementar mudanças degrada o sistema e reduz sua a facilidade de manuteção.

• Custos de manutenção dependem do número de mudanças e os custos de implementação das mudanças dependem da facilidade de manuteção dos componentes do sistema.


Previsão de mudança

Previsão de facilidade demanutenção

Previsão de custo de

manutenção

Previsão de mudança de

sistema

Que partes serão afetadas pelos pedidos de mudança?Quantos pedidos de mudança podem ser esperados?

Que partes do sistema serão mais dispendiosas para se manter?

• Quais serão os custosmanutenção durante o tempo de vida útil desse sistema?

• Quais os custos demanutenção desse sistema no próximo ano?


Evolução da arquitetura

� Há uma necessidade de converter muitos sistemas legados de uma arquitetura centralizada p/ uma cliente-servidor

� Razões • Custos de HW. • Expectativas quanto à interface com o usuário• Acesso distribuído aos sistemas


Evolução da arquitetura

� Fatores de distribuição• A importância do negócio

• A idade do sistema (quanto mais velho mais difícil)

• Estrutura do sistema (quanto mais modularizado, mais fácil)

• Política de suprimento de HW (substituição dos mainframes por servidores)


Sistemas Legados� Antigos sistemas que ainda são essenciais

para a empresa.

� Todos os sistemas de software úteis inevitavelmente são modificados quando as empresas passam por mudanças.


Risco de substituir um Sistemas Legados

� Sistemas de legado, raramente, têm uma especificação completa.

� Os processos corporativos e o modo como os sistemas legados operam estão sempre entrelaçados.

� O sistema pode embutir regras corporativas que não estão documentadas formalmente em outro lugar.

� Desenvolvimento de software novo é arriscado e pode não ter êxito.


Mudanças em um Sistemas Legados

� Partes diferentes implementadas por diferentes equipes.

� Linguagem de programação obsoleto. � A documentação de sistema está desatualizada. � A estrutura de sistema corrompida por muitos

anos de manutenção (utilização de técnicas para economizar espaço ou aumentar a velocidade).

� Estruturas de arquivo usadas podem ser incompatíveis.


Sistemas Legados de Aplicação


Sistemas Centrados em Bancos de Dados

Programa 1

Programa 2

Programa 3

Programa 4

Sistema de Gerenciamento

de banco de dados

Modelos de dados lógicos

e físicosdescreve


Avaliação dos Sistemas Legados• Descartar completamente o sistema.

• escolhida quando o sistema não estiver prestando uma contribuição efetiva aos processos.

• Continuar a manter o sistema.• sistema é necessário e sem grande número de modificações.

• Transformar o sistema de alguma maneira para melhorar sua facilidade de manutenção.• qualidade do sistema foi degradada por modificações regulares.


Avaliação dos Sistemas Legados

Qualidade de sistema

Val

or d

e ne

góci

os

12

3

910

6

78

45


Estrutura de Sistemas Legados

Interface com ousuário

serviços

Banco de dados

Modelo ideal Sistema legados reais

Banco de dados

serviços

Interface com ousuário


Distribuição de Sistemas Legados

BD

Sistema legado

middlewareServiço de aplicação

IU

Sistema legado

Terminais a caractere

Aplicação em operação em clientes PC


Modelo de Distribuição em Camadas

Apresentação

Validação de dados

Controle de interação

Serviços da aplicação

Base de dados

Organização de tela p/ usuário final

Verificar entrada/saída de dados

Gerencia seqüência de operação/telas

Fornece cálculos básicos

Fornece gerenciamento eArmazenamento de dados


Opções de distribuição

� O modelo de distribuição mais simples é a distribuição da interface do utilizador onde somente a interface é implementada no servidor

� A opção mais complexa é onde o servidor provê gestão dos dados e os serviços são implementados no cliente


Spectrum de opções de distribuição Servidor:

1- Controle de interaçãoValidação de dadosServiçosBanco de dados

2- ServiçosBanco de dados

3- Banco de dados

Cliente:1- Apresentação 2- Apresentação

Controle de interaçãoValidação de dados

3- ApresentaçãoControle de interaçãoValidação de dadosServiços

Custo e esforço crescente


Distribuição da interface com o usuário

� A distribuição da interface com o usuário tira vantagem da capacidade de processamento local dos PCs p/ implementar interfaces gráficas

� Onde há uma separação clara entre a interface e a aplicação então o sistema legado pode ser modificado para distribuir a interface

� Caso contrário um middleware p/ gerenciamento de tela pode traduzir interfaces textuais p/ gráficas


Distribuição da interface do utilizador

BD Middlewarede gerenciamento de tela

Serviço de aplicação

IU

Sistema legado

Cliente desktop PC com interface GUI


Manutenção de Código Alienígena

� Programas com muitos fluxos de controle. � Módulos muito grandes.� Poucos linhas de comentários significativos.� Não existe nenhum outro elemento da

configuração de software, além do código.� Nenhum membro do pessoal atual de

manutenção trabalhou no desenvolvimento do programa.

� Nenhuma metodologia de desenvolvimento foi aplicada.


Solução

Engenharia Reversa e Reengenharia

Manutenção de Código Alienígena


� ENGENHARIA REVERSA• processo de análise de um software,

partindo-se inicialmente da implementação para um nível mais alto de abstração

� REENGENHARIA• implica no exame e na alteração do software

para reconstruí-lo em uma nova forma.




requisito projeto implementação

Eng. progressiva Eng. progressiva

Eng. reversa Eng. reversa

Reengenharia Reengenharia


� Re-estruturar ou re-escrever parte ou todo um sistema legado, sem alterar a sua funcionalidade.

� Aplicável quando alguns subsistemas de um sistema mais amplo requerem uma manutenção freqüente.

� A re-engenharia envolve a adição de esforço de modo a tornar esses sistemas mais fáceis de manter. Os sistemas poderão ser re-estruturados e re-documentados.

Reengenharia


� Risco reduzido: Re-desenvolvimento de software essencial constitui um risco elevado, devido ao papel crítico do software na organização

� Custo reduzido: Algumas estimativas sugerem que o custo de re-engenharia ésignificativamente inferior ao custo de re-desenvolvimento do sistema, provavelmente 4 vezes inferior

Vantagens da Reengenharia


Distinção entre Reengenharia e o Novo Desenvolvimento de Software

Sistema de Softexistente

SistemaAlterado

(reengenheirado)

Compreensãoe transformação

Reengenharia de software

Especificação do sistema

Novo sistema

Projeto eimplementação

Novo sistema


Processo de ReengenhariaPrograma

original

Tradução deCódigo-fonte

Document.de programa

Programamodularizado

Dadosoriginais

Programaestruturado

Dadosreengenheirados

Engenhariareversa

Melhoria de estrutura do prog

Modularizaçãode programa

Reengenharia de dados


� A qualidade do software que deve passar pelo processo de reengenharia

� Ferramentas disponíveis ao processo de reengenharia

� A extensão de conversão de dados requerida

� A disponibilidade de pessoal habilitado.

Fatores de Custo de Reengenharia


� Analisar o software com o objetivo de recuperar o seu projeto e a sua especificação a partir de seu código-fonte.

Engenharia Reversa


O processo da Engenharia Reversa

Análiseautomatizada

Diagrama deestrutura de programa

Geração dedocumentos

Anotaçãomanual

Diagrama deestrutura de

dados

Matrizes derastreamento

Sistema a serreengenheirado

Repositóriode

Informaçõesdo

Sistema


� Perda de comentários / Perda de documentação.

� A reestruturação não ajuda na presença de uma modularização pobre, onde componentes relacionados estão dispersos pelo código

� A compreensão de programas orientados a dados poderá não ser melhorada através da reestruturação

Problemas com a Re-estruturação


� É o processo de reorganizar um programa, de modo que as partes relacionadas sejam coletadas e consideradas um único módulo.

� Tipos de módulos:• Abstrações de dados;• Módulos de hardware;• Módulos funcionais; • Módulo de apoio ao processo.

Modularização de programa


� Envolve a análise e a reorganização das estruturas de dados (e, por vezes, dos valores dos dados) num programa.

� Razões para usar a reengenharia de dados:• Limpeza de dados;• Extensão de dados;• Migração de dados.

Reengenharia de Dados

leitura: cap26 - 27 - 28: sommerville; cap20: pressmanmaria/arqan/2011-1/cap8-manut.pdf ·...

Documents