A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Eliane Martins - Instituto de Computação - UNICAMP Evolução e Manutenção do Software Nov/2009.

Apresentações semelhantes


Apresentação em tema: "Eliane Martins - Instituto de Computação - UNICAMP Evolução e Manutenção do Software Nov/2009."— Transcrição da apresentação:

1

2 Eliane Martins - Instituto de Computação - UNICAMP Evolução e Manutenção do Software Nov/2009

3 Eliane Martins - Instituto de Computação - UNICAMP2 Tópicos Evolução ou manutenção Manutenção de Software Tipos de manutenção Dificuldades Manutenibilidade

4 Eliane Martins - Instituto de Computação - UNICAMP3 Referências E.Martins. Manutenção e Ferramentas CASE, notas de curso, 1998 I.Sommerville. Sw Engineering, 6ª ed, 2001, cap27 R.S.Pressman. Sw Engineering: a Practitioners Approach. McGraw- Hill, 3ª ed, T.Pigoski. Practical Software Maintenance, 1997, John Wiley. W.P.Paula Fº. Engenharia de Software: Fundamentos, Métodos e Padrões. Livros Técnicos e Científicos Editora, N.F.Schneidewind. The State of Sw Maintenance. IEEE Trans on Sw Eng, SE-13, nº3, mar/87, pp K.Bennett. Sw Evolution: Past, Present and Future. Information and Software Technology, nº38, 1996, pp

5 Eliane Martins - Instituto de Computação - UNICAMP4 Evolução ou Manutenção? Grandes sistemas de software nunca são completados; eles simplesmente continuam evoluindo [Lehman] –Porquê ? para preservar o valor do software

6 Eliane Martins - Instituto de Computação - UNICAMP5 Sobre o valor do software Sw tem valor quando atende aos requisitos

7 Eliane Martins - Instituto de Computação - UNICAMP6 Sobre o valor do software Sw tem valor quando atende aos requisitos Valor do sw devido a falhas mudanças nos requisitos tempo

8 Eliane Martins - Instituto de Computação - UNICAMP7 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar

9 Eliane Martins - Instituto de Computação - UNICAMP8 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar Valor do sw devido a falhas mudanças nos requisitos complexidade tempo

10 Eliane Martins - Instituto de Computação - UNICAMP9 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente

11 Eliane Martins - Instituto de Computação - UNICAMP10 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente Valor do sw devido a falhas mudanças nos requisitos complexidade ineficiência tempo

12 Eliane Martins - Instituto de Computação - UNICAMP11 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente usa tecnologia atual

13 Eliane Martins - Instituto de Computação - UNICAMP12 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente usa tecnologia atual Valor do sw devido a falhas mudanças nos requisitos complexidade ineficiência tecnologia obsoleta tempo

14 Eliane Martins - Instituto de Computação - UNICAMP13 Sobre o valor do software Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente usa tecnologia atual Valor do sw devido a falhas mudanças nos requisitos complexidade ineficiência tecnologia obsoleta tempo alterações

15 Eliane Martins - Instituto de Computação - UNICAMP14 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas modificações são inevitáveis para que um sw continue útil

16 Eliane Martins - Instituto de Computação - UNICAMP15 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade nº falhas tempo taxa de falhas hw mortalidade infantil desgaste

17 Eliane Martins - Instituto de Computação - UNICAMP16 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade nº falhas tempo taxa de falhas ideal sw tempo taxa de falhas hw mortalidade infantil desgaste

18 Eliane Martins - Instituto de Computação - UNICAMP17 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade nº falhas tempo taxa de falhas hw mortalidade infantil desgaste tempo taxa de falhas ideal real sw alteração

19 Eliane Martins - Instituto de Computação - UNICAMP18 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw atributos tais como tamanho, tempo entre versões e nº falhas variam pouco de uma versão para outra

20 Eliane Martins - Instituto de Computação - UNICAMP19 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) Estabilidade organizacional (saturação) modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw atributos tais como tamanho, tempo entre versões e nº defeitos variam pouco de uma versão para outra taxa de desenvolvimento é constante e independe dos recursos alocados

21 Eliane Martins - Instituto de Computação - UNICAMP20 Dinâmica da evolução do sw (Leis de Lehman) Modificações contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) Estabilidade organizacional (saturação) Conservação da familiaridade modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw atributos tais como tamanho, tempo entre versões e nº defeitos variam pouco de uma versão para outra taxa de desenvolvimento é constante e independe dos recursos alocados modificações a cada versão são praticamente constantes (modificações incrementais)

22 Eliane Martins - Instituto de Computação - UNICAMP21 Tópicos Evolução ou manutenção Manutenção de Software Tipos de manutenção Dificuldades Manutenibilidade

23 Eliane Martins - Instituto de Computação - UNICAMP22 Manutenção Definição –é o processo de modificação de um produto após a entrega Tipos –corretiva –adaptativa –perfectiva

24 Eliane Martins - Instituto de Computação - UNICAMP23 Custos com manutenção Dados de 1990

25 Eliane Martins - Instituto de Computação - UNICAMP24 Distribuição dos custos de manutenção Internet, maio/2002

26 Eliane Martins - Instituto de Computação - UNICAMP25 Distribuição dos custos por categoria Dados de 1990

27 Eliane Martins - Instituto de Computação - UNICAMP26 Tópicos Evolução ou manutenção Manutenção de Software Tipos de manutenção Dificuldades Manutenibilidade

28 Eliane Martins - Instituto de Computação - UNICAMP27 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto

29 Eliane Martins - Instituto de Computação - UNICAMP28 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto Pouco treinamento Mudança de objetivos: necessidades do usuário evoluem; novos usuários

30 Eliane Martins - Instituto de Computação - UNICAMP29 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto Contrato manutenção separado do contrato de desenvolvimento, podendo inclusive ser dado a outra empresa pouco incentivo para produção de sw fácil de manter

31 Eliane Martins - Instituto de Computação - UNICAMP30 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto ausência dos desenvolvedores falta de tempo falta de motivação falta de experiência

32 Eliane Martins - Instituto de Computação - UNICAMP31 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto domínio da aplicação dependência do ambiente externo instabilidade do hw alterações sem controle

33 Eliane Martins - Instituto de Computação - UNICAMP32 Porquê os custos são altos? Fatores: –usuário –contrato –equipe de desenvolvimento –sistema –produto idade qualidade da documentação estilo de programação acoplamento entre os módulos linguagem de programação V&V deficiente

34 Eliane Martins - Instituto de Computação - UNICAMP33 Como reduzir custos Diretrizes gerenciais –como planejar a manutenção –como motivar a equipe Diretrizes técnicas: –melhorar a manutenibilidade durante o desenvolvimento: processo visando manutenibilidade durante a manutenção: manutenção preventiva (reengenharia) –definir processo de manutenção

35 Eliane Martins - Instituto de Computação - UNICAMP34 Diretrizes gerenciais (1) Envolver a equipe de manutenção no desenvolvimento Usar padrões tanto no desenvolvimento quanto na manutenção Fazer rodízio do pessoal entre desenvolvimento e manutenção Ter acesso à documentação ainda durante o desenvolvimento Dispor das ferramentas CASE usadas durante desenvolvimento Manter contato entre usuários e equipe de manutenção Fazer controle de configuração Padronizar pedidos de alterações [McClure]

36 Eliane Martins - Instituto de Computação - UNICAMP35 Diretrizes gerenciais (2) Associar objetivos do software com metas da empresa Associar ganhos de manutenção com o desempenho da empresa Integrar as equipes de desenvolvimento e manutenção Alocar verba para manutenção preventiva (reengenharia) Envolver equipe de manutenção na criação de padrões de desenvolvimento, revisões, preparação de testes Mudar imagem negativa associada à manutenção [Boehm]

37 Eliane Martins - Instituto de Computação - UNICAMP36 Diretrizes gerenciais (3) Escolher equipe qualificada Garantir boa qualidade do sistema: –bem estruturado –fácil de entender Usar linguagens de programação padronizadas Usar sistemas operacionais padronizados Padronizar a documentação Disponibilizar casos de teste Tornar possível o rastreamento de requisitos [Pressman]

38 Eliane Martins - Instituto de Computação - UNICAMP37 Tópicos Evolução ou manutenção Manutenção de Software Tipos de manutenção Dificuldades Manutenibilidade

39 Eliane Martins - Instituto de Computação - UNICAMP38 Manutenibilidade Algumas definições –Facilidade com que um sistema ou componente de software pode ser modificado para se corrigir falhas, melhorar desempenho (ou outros atributos), ou ser adaptado a mudanças no ambiente ; (IEEE , 1990) –Facilidade para corrigir um sw, quando possui falhas ou deficiências, e também para expandir ou contrair o sw para satisfazer a novos requisitos (Martin e McClure 1983) –Conjunto de atributos relativos ao esforço necessário para se realizar modificações em um sw (ISO/IEC )

40 Eliane Martins - Instituto de Computação - UNICAMP39 Considerações Todos os sistemas são igualmente fáceis de manter ? Porque não ? –Sistemas não são desenvolvidos visando manutenibilidade –manutenibilidade deve ser uma das metas do desenvolvimento Que critérios usar para determinar se um sw é fácil de manter ou não ? É possível estimar o grau de manutenibilidade de um sw ?

41 Eliane Martins - Instituto de Computação - UNICAMP40 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações

42 Eliane Martins - Instituto de Computação - UNICAMP41 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações Manutenibilidade deve ser considerada ao longo de todo desenvolvimento. Pb.: como convencer gerentes de que manutenibilidade ganhos

43 Eliane Martins - Instituto de Computação - UNICAMP42 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações documentação desatualizada, incompleta ou inexistente custo com manutenção (47% - 62% tempo para compreensão de programas e documentos) [Pigosrki 1996]

44 Eliane Martins - Instituto de Computação - UNICAMP43 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações qualidade custo com manutenção Aspectos de qualidade: - estrutura do sw - estilo de programação - sistemática de V&V

45 Eliane Martins - Instituto de Computação - UNICAMP44 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações Facilita realização de testes, em especial os de regressão

46 Eliane Martins - Instituto de Computação - UNICAMP45 O que afeta a manutenibilidade Processo de desenvolvimento Documentação Qualidade do sw Disponibilidade dos testes Disponibilidade das ferramentas de desenvolvimento Controle de alterações Facilita realização modificações, permitindo atualizar: - modelos de análise e projeto; documentação - código fonte (existência do compilador) - testes, entre outros

47 Eliane Martins - Instituto de Computação - UNICAMP46 Como estimar manutenibilidade Manutenibilidade pode ser medida Diversas métricas propostas: –padrão IEEE –outras

48 Eliane Martins - Instituto de Computação - UNICAMP47 Padrão IEEE 1061/1992 Ajuda a estabelecer metodologia para obtenção de métricas de qualidade de sw Como usar o padrão: –para aquisição ou gerência de desenvolvimento: identificar, definir e priorizar os requisitos de qualidade de um sistema –para o desenvolvimento do sistema: identificar características que o sw deve possuir para atender aos requisitos de qualidade –para o controle de qualidade: avaliar se os requisitos de qualidade estão sendo atendidos –para a manutenção: auxiliar na gerência de modificações –para o usuáro: ajudar a especificar os requisitos de qualidade de um sistema

49 Eliane Martins - Instituto de Computação - UNICAMP48 Métricas Permitem determinar quão fácil é manter um sw manutenibilidade pode ser caracterizada pelos seguintes sub-fatores (IEEE ): –corrigibilidade : medida do esforço necessário para corrigir erros e lidar com as reclamações dos usuários –expansibilidade : medida do esforço necessário para melhorar ou modificar as funções do sw –testabilidade : medida do esforço necessário para testar o sw

50 Eliane Martins - Instituto de Computação - UNICAMP49 Métricas corrigibilidade tempo de fechamento tempo para isolar/corrigir a falha tamanho da interface taxa de falhas previsão de recursos previsão de esforço produtividade Contagem de falhas esforço Subfator tipo de métricamétrica

51 Eliane Martins - Instituto de Computação - UNICAMP50 Métricas testabilidade cobertura do código cobertura dos requisitos grau de completeza do plano de testes previsão de recursos previsão de esforço produtividade cobertura esforço Subfator tipo de métricamétrica

52 Eliane Martins - Instituto de Computação - UNICAMP51 Métricas expansibilidade esforço para modificação tamanho da modificação taxa de modificação contagem de modificações previsão de recursos previsão de esforço produtividade modificações esforço Subfator tipo de métricamétrica

53 Eliane Martins - Instituto de Computação - UNICAMP52 Outras métricas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros

54 Eliane Martins - Instituto de Computação - UNICAMP53 Outras medidas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros Manutenibilidade pode ser medida: –pelo tempo gasto durante a manutenção –pela complexidade do projeto –pela estabilidade do projeto

55 Eliane Martins - Instituto de Computação - UNICAMP54 Outras medidas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros Manutenibilidade pode ser medida: –pelo tempo gasto durante a manutenção: tempo gasto no reconhecimento do problema tempo de retardo administrativo tempo de seleção de ferramentas tempo para análise do problema tempo para especificação das modificações tempo para correções tempo para os testes

56 Eliane Martins - Instituto de Computação - UNICAMP55 Outras medidas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros Manutenibilidade pode ser medida: –pela complexidade do projeto: complexidade ciclomática métrica de Halstead...

57 Eliane Martins - Instituto de Computação - UNICAMP56 Outras medidas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros Manutenibilidade pode ser medida: –pela estabilidade do projeto: estabilidade do programa: grau de resistência a efeitos colaterais estabilidade do módulo: grau de resistência a causar efeitos colaterais em outros módulos (acoplamento) propagação intra-módulo (fluxo de modificações internas ao módulo) e inter-módulos

58 Eliane Martins - Instituto de Computação - UNICAMP57 Outras medidas Diversos autores (academia e indústria): –Schneidewind 1987 –Lewis e Henry 1989 –Oman 1991 entre outros Manutenibilidade pode ser medida: –ao longo do ciclo de vida através de métricas de qualidade: do código fonte de estrutura do sw entre outras incorporação da manutenibilidade ao longo do desenvolvimento do sw

59 Eliane Martins - Instituto de Computação - UNICAMP58 Métrica baseada na estrutura Proposta por Lewis e Henry 1989 Permite avaliar a manutenibilidade ao longo do ciclo de vida Medida varia conforme o tipo de sistema: –Procedimental –OO

60 Eliane Martins - Instituto de Computação - UNICAMP59 Modularidade para sistemas procedimentais nº de procedimentos M proc = KLOCS [Peters e Pedrycz 2001] Programa LOC nº funções M ProgA ,002 ProgB ,012 Exemplo:

61 Eliane Martins - Instituto de Computação - UNICAMP60 Modularidade para sistemas OO nº de métodos da classe M classe = KLOCS nº médio de métodos por classe M sist = nº médio de KLOCS por classe [Peters e Pedrycz 2001]

62 Eliane Martins - Instituto de Computação - UNICAMP61 Legibilidade Legibilidade: –de documentos: –de código: L = | 0,295 id - 0,499 LOC + 0,13 c nº de palavras FOG = 0,4 + % de palavras com ( 3+) sílabas nº de sentenças complexidade ciclomática comprimento médio dos identificadores [Peters e Pedrycz 2001]

63 Eliane Martins - Instituto de Computação - UNICAMP62 Revisão da manutenibilidade Análise Projeto Codificação Testes quais as partes passíveis de melhorias ? quais as partes passíveis de adaptações? As interfaces estão bem definidas? A estrutura do sistema é complexa? Os módulos do sistema são complexos? Práticas recomendadas de programação foram utilizadas? O código é bem documentado? Existe associação entre os testes e partes passíveis de alterações?

64 Eliane Martins - Instituto de Computação - UNICAMP63 Ferramentas de Auxílio - Exemplos RSM –Resource Standard Metrics (C, C++, Java) –obtenção de métricas: LOCs, complexidade cilcomática, nº de parâmetros em função,... –Análise estática do código: linhas muito longas, nomes de variáveis, constantes, construções dependentes do compilador,... Aristotle –análise estática do programa: análise de dependências de controle análise de fluxo de dados, entre outras...

65 Eliane Martins - Instituto de Computação - UNICAMP64 Recomendações finais Quais as recomendações para se obter uma boa manutenibilidade? –Revisões –Uso de princípios da engenharia de sw (ex.: abstração de dados, ocultação da informação,...) –Comentários no programa contendo informações úteis –Evitar práticas nocivas de programação –Aplicar convenções de codificação –Reengenharia do sw

66 Eliane Martins - Instituto de Computação - UNICAMP65 Reengenharia do Software

67 Eliane Martins - Instituto de Computação - UNICAMP66 Reengenharia de Software Reorganização e modificação do sw com o objetivo de melhorar sua manutenibilidade Atividade denominada também de manutenção preventiva ou ainda, rejuvenescimento do sw.

68 Eliane Martins - Instituto de Computação - UNICAMP67 Re-engenharia: porquê? Para aumentar a sobrevida de sistemas legados: –Em 1990 foi estimada a existência de 120 milhões de LOCs, a maioria em Cobol e Fortran a estruturação dos programas é muito baixa a documentação dos sistemas é pouca ou inexistente –Apesar de muitos desses programas já terem sido substituídos, ainda restam muitos em uso... Em 2005: por volta de 200 bilhões de LOC em Cobol, com uma redução da ordem de dezenas de milhares por ano –... e novos programas são desenvolvidos, usando processos ágeis de desenvolvimento, nos quais estruturação e documentação não são a principal preocupação

69 Eliane Martins - Instituto de Computação - UNICAMP68 Engenharia Progressiva e Reengenharia Especificação do Sistema Projeto e Implementação Novo sistema Engenharia Progressiva Sistema Antigo Compreensão e Transformação Sistema Melhorado Reengenharia

70 Eliane Martins - Instituto de Computação - UNICAMP69 Atividades Engenharia reversa Conversão de código Reestruturação dos dados Reestruturação do código Remodularização do código Refatoração

71 Eliane Martins - Instituto de Computação - UNICAMP70 Engenharia Reversa Consiste em analisar o código com o objetivo de obter o projeto e especificação do sistema –para obter a especificação é necessária intervenção manual Cria banco de dados com informações sobre o sistema É mais eficaz quando feita com auxílio de ferramentas: engenharia reversa, análise estática, referências cruzadas, navegadores de programas (program browsers)...

72 Eliane Martins - Instituto de Computação - UNICAMP71 Engenharia reversa de código - exemplo program X; var … function F1(..): tipo; … procedure P2(…); begin … = … F1(…) …; end; procedure P1(…); begin … P2(…); … end; Descrição da função F1(…): Parâmetros de entrada: Parâmetros de saída: Valor de retorno: O quê faz a função: function F1(.): tipo;

73 Eliane Martins - Instituto de Computação - UNICAMP72 Engenharia reversa de código - exemplo program X; var … function F1(..): tipo; … procedure P2(…); begin … = … F1(…) …; end; procedure P1(…); begin … P2(…); … end; X P2 P1 F1 … function F1(.): tipo;

74 Eliane Martins - Instituto de Computação - UNICAMP73 Procedimento (exemplo) Código fonte original Transformação Código XML Biblioteca de dados XML Transformação XML UML (XMI) Baseia-se em conjunto de regras para o mapeamento de elementos da linguagem A (representados em XML) para elementos da UML Diagramas UML

75 Eliane Martins - Instituto de Computação - UNICAMP74 Conversão de código Código original Identificar diferenças entre as linguagens Projetar um tradutor Converter automaticamente Ajustar manualmente Código original Código convertido

76 Eliane Martins - Instituto de Computação - UNICAMP75 Exemplo Processo de conversão com XML Código fonte original Transformação Código XML Biblioteca de dados XML Transformação XML Código Código fonte convertido

77 Eliane Martins - Instituto de Computação - UNICAMP76 Re-estruturação dos dados O que é –processo de analisar e reorganizar estruturas de dados (eventualmente, os valores dos dados) de um programa Objetivo –melhorar compreensão dos dados usados pelo programa –facilitar o controle dos dados

78 Eliane Martins - Instituto de Computação - UNICAMP77 Problemas com dados legados Nomeação dos dados –dados têm nomes difíceis de entender –dados podem ter nomes diferentes em ao longo das diferentes partes do sistema Tamanho de campos –o mesmo item pode ter tamanhos diferentes em diferentes partes do sistema Organização dos registros –registros que representam a mesma entidade podem ter formatos diferentes ao longo do sistema Constantes embutidas Inexistência de um dicionário de dados Inconsistência dos dados

79 Eliane Martins - Instituto de Computação - UNICAMP78 Inconsistência dos Dados (1) Valores default inconsistentes –programas diferentes atribuem valores diferentes ao mesmo item de dados Unidades inconsistentes –a mesma informação é representada usando unidades diferentes (ex.: peso em libras ou kg) Regras de validação inconsistentes –regras de validação diferentes podem fazer com que dados aceitos por um programa sejam rejeitados por outros

80 Eliane Martins - Instituto de Computação - UNICAMP79 Inconsistência dos Dados (2) Convenções de representação inconsistente –diferenças na convenção usada para representar os dados (ex.: alguns programas podem assumir que dados iniciados com maiúsculas representam endereço) Uso inconsistente de valores negativos: –alguns programas podem rejeitar tais valores, outros aceitá-los como válidos e outros ainda podem não reconhecê-los como sendo negativos e convertê-los errôneamente para positivo

81 Eliane Martins - Instituto de Computação - UNICAMP80 Reestruturação de código Com a manutenção a estrutura do código vai sendo corrompida, o que dificulta o entendimento e futuras alterações. O código pode ser reestruturado, automaticamente, para eliminar desvios incondicionais (goto): –Bohm e Jacopini mostraram, em 1966, que programas podem ser escritos usando-se somente construções do tipo seqüência, seleção (if-the-else, case) e repetição (while-repeat-for) Condições também podem ser simplificadas, o que facilita o seu entendimento

82 Eliane Martins - Instituto de Computação - UNICAMP81 Código espaguete Start:get (time_on, time_off, time, setting, temp, switch) if switch = off goto Off if switch = on goto On goto Cntrld Off:if heating_status = on goto Sw_off goto Loop On:if heating_status = off goto Sw_on goto Loop Cntrld:if time = time_on goto On if time = time_off goto Off if time < time_on goto Start if time > time_off goto Start if temp > setting goto Off if temp < setting goto On Sw_off:heating_status := off goto Switch Sw_on: heating_status := on Switch:Switch_heating ( ) Loop:goto Start

83 Eliane Martins - Instituto de Computação - UNICAMP82 Código estruturado loop -- get: atribui valores para variáveis conforme -- o ambiente do sistema get (time_on, time_off, time, setting, temp, switch) case switch of when On if heating_status = off then Switch_Heating ( ); heating_status := On; end_if; when Controlled if time time_on and time time_off then if temp > setting and heating_status = On then Switch_heating ( ); heating_status := Off; elsif temp < setting and heating_status = Off then Switch_heating ( ); heating_status := On; end_if; end_case; end loop;

84 Eliane Martins - Instituto de Computação - UNICAMP83 Simplificação de condições -- Condição complexa: if not (A > B and (C F) ) ) Condição simplificada: if (A = D or E > F)...

85 Eliane Martins - Instituto de Computação - UNICAMP84 Re-modularização de código O que é: –Processo de reorganização de um programa de forma que partes relacionadas sejam colocadas em um mesmo módulo Porquê? –Componentes relacionados ficam dispersos pelo programa Como? –Geralmente é manual: inspeção e re-edição do código, mas já existem ferramentas que apoiam partes do processo –Refatoração

86 Eliane Martins - Instituto de Computação - UNICAMP85 Refatoração Ver slides

87 Eliane Martins - Instituto de Computação - UNICAMP86 Exercícios Para os programas dados a seguir, responda: –O que fazem os programas? –Quanto tempo levou para entendê-los? –Qual o grau de modularidade dos programas? –Qual a legibilidade? –Que sugestões voce daria para melhorar a manutenibilidade deles?

88 Eliane Martins - Instituto de Computação - UNICAMP87 Programa 1 Entradas: t, i, c Saídas: ac, loc cm := 1; f := Tam; ac := falso; while cm f and not ac do m := (cm + f) / 2; if c > t [m] then cm := m + 1 else if c = t [m] then ac := verdade; loc := m else f := m - 1 end while;

89 Eliane Martins - Instituto de Computação - UNICAMP88 Programa 2 Entradas: x1, x2, x3: inteiros; x4: char Saídas: w, x1 if x1 > x2 then w := 100 else w := 10; while x1 > x3 do x3 := x3 * w end while; case x4 A - J: w := 10 K - T: w := 20 U - Z: w := 30 end case; if x2 > x1 and x2 < x3 and x4 = S then w := 10 else w := 20; if x1 < w or x2 < w then write w else write x1;


Carregar ppt "Eliane Martins - Instituto de Computação - UNICAMP Evolução e Manutenção do Software Nov/2009."

Apresentações semelhantes


Anúncios Google