Evolução e Manutenção do Software

Evolução e Manutenção do Software
Nov/2009

Tópicos Evolução ou manutenção Manutenção de Software
Tipos de manutenção Dificuldades Manutenibilidade

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 Practitioner’s Approach”. McGraw-Hill, 3ª ed, 1992. 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, 2001. 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

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

Sobre o valor do software
Sw tem valor quando atende aos requisitos

Sw tem valor quando atende aos requisitos Valor do sw  devido a falhas mudanças nos requisitos tempo

Sw tem valor quando atende aos requisitos é fácil de entender e de usar

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

Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente

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

Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente usa tecnologia atual

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

Valor do sw  devido a falhas mudanças nos requisitos complexidade ineficiência tecnologia obsoleta Sw tem valor quando atende aos requisitos é fácil de entender e de usar é eficiente usa tecnologia atual alterações tempo

Dinâmica da evolução do sw (Leis de Lehman)
modificações são inevitáveis para que um sw continue útil Modificações contínuas Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade   nº falhas  Modificações contínuas Complexidade crescente tempo taxa de falhas hw mortalidade infantil desgaste Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade   nº falhas  Modificações contínuas Complexidade crescente tempo taxa de falhas ideal sw tempo taxa de falhas hw mortalidade infantil desgaste Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

modificações são inevitáveis para que um sw continue útil modificações aumentam a complexidade do sw complexidade   nº falhas  Modificações contínuas Complexidade crescente tempo taxa de falhas ideal real sw alteração tempo taxa de falhas hw mortalidade infantil desgaste Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

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 Modificações contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

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 contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) Estabilidade organizacional (saturação) Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

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) Modificações contínuas Complexidade crescente Evolução de programas grandes (processo auto-regulador) Estabilidade organizacional (saturação) Conservação da familiaridade Lehman e Belady estudaram a dinâmica da evolução de sistemas e propuseram algumas leis sobre a forma como os sistemas evoluem. Essas leis ficaram conhecidas como leis de Lehman: - modificações contínuas: já visto que alterações são inevitáveis - complexidade crescente: alterações degradam a estrutura do sw=> necessário investir em manutenção preventiva (re-engenharia) - evolução de programas grandes: sistemas grandes têm uma dinâmica própria que é estabelecida desde cedo no seu ciclo de vida. Tal determina as tendências no processo de manutenção e limitam o nº de modific. possíveis. Qdo um sistema excede um certo tamanho ele age como uma massa inercial: seu tamanho inibe grandes alterações pois estas introduziriam um tal nº de falhas que anularia a utilidade da nova versão. (é uma das hipóteses mais discutíveis) - estabilidade organizacional: grandes sistemas são geralmente produzidos por grandes empresas que têm uma certa burocracia interna. Grandes modif => tomada de decisão por parte da empresa e prováveis mudanças no orçamento alocado para o projeto, o q toma tempo => grandes mudanças são “freadas” pela burocracia interna da empresa. Afora isso, sist grandes em geral são produzidos em estado de saturação: alterações nos recursos ou pessoal têm pouco efeito sobre o progresso do sistema. - conservação da familiaridade: c.f 2a. lei: alterações em sistemas grandes ocorrem em ppqs incrementos, pois grandes mudanças => nº falhas alto.

Manutenção Definição Tipos
é o processo de modificação de um produto após a entrega Tipos corretiva adaptativa perfectiva

Custos com manutenção Dados de 1990
Esses dados continuam válidos: em Painel com indústria apresentado no SBES’2008, foi levantado que 86% do tempo é gasto com manut de legado. Dados de 1990

Distribuição dos custos de manutenção
Comparar com resultados de estudo feito por Lientz e Swanson em 1980 ao avaliar custos com manut em mais de 400 empresas. Contrariamente ao que se pensa, grande parte do esforço com manut não é devotado a correções emergenciais! Internet, maio/2002

Distribuição dos custos por categoria
Comparar com resultados de estudo feito por Lientz e Swanson em 1980 ao avaliar custos com manut. em mais de 400 empresas: corretiva -20%, adaptativa - 25% e perfectiva - 55% => mudança nos requisitos é a maior causa de manutenção! Ex.: Patriot era para ser um sistema defensivo e foi alterado para oferecer tb capacidade ofensiva Porque é importante saber isso? Alocar recursos para manutenção desde o início do desenvolvimento. T.Pigorski recomenda um extra de 10-15% dos custos anuais de desenvolvimento para cobrir manut. Dados de 1990

Porquê os custos são altos?
Fatores: usuário contrato equipe de desenvolvimento sistema produto

Fatores: usuário contrato equipe de desenvolvimento sistema produto Pouco treinamento Mudança de objetivos: necessidades do usuário evoluem; novos usuários

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

Fatores: usuário contrato equipe de desenvolvimento sistema produto ausência dos desenvolvedores falta de tempo falta de motivação falta de experiência

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

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

Como reduzir custos Diretrizes gerenciais Diretrizes técnicas:
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

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]

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]

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]

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 )

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 ?

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

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

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]

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

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

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

Como estimar manutenibilidade
Manutenibilidade pode ser medida Diversas métricas propostas: padrão IEEE outras

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

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

Métricas Subfator tipo de métrica métrica corrigibilidade Contagem
de falhas 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 esforço

Métricas Subfator tipo de métrica métrica testabilidade cobertura
cobertura do código cobertura dos requisitos grau de completeza do plano de testes previsão de recursos previsão de esforço produtividade esforço

Métricas Subfator tipo de métrica métrica expansibilidade modificações
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 esforço

Outras métricas Diversos autores (academia e indústria):
Schneidewind 1987 Lewis e Henry 1989 Oman 1991 entre outros

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

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

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 ...

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

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

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

Modularidade para sistemas procedimentais
nº de procedimentos Mproc = KLOCS Exemplo: Programa LOC nº funções M ProgA ,002 ProgB ,012 [Peters e Pedrycz 2001] Engenharia de Software. Teoria e prática. Editora Campus, 2001. [Peters e Pedrycz 2001]

Modularidade para sistemas OO
nº de métodos da classe Mclasse = KLOCS nº médio de métodos por classe Msist = nº médio de KLOCS por classe [Peters e Pedrycz 2001] Engenharia de Software. Teoria e prática. Editora Campus, 2001. [Peters e Pedrycz 2001]

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

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?

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 ...

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

Reengenharia do Software

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.

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

Engenharia Progressiva e Reengenharia
Especificação do Sistema Projeto e Implementação Novo sistema Reengenharia Sistema Antigo Compreensão e Transformação Melhorado

Atividades Engenharia reversa Conversão de código
Reestruturação dos dados Reestruturação do código Remodularização do código Refatoração

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) ...

Engenharia reversa de código - exemplo
program X; var … function F1(..): tipo; procedure P2(…); begin = … F1(…) …; end; procedure P1(…); P2(…); 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; Engenharia reversa de função

Engenharia reversa de código - exemplo
program X; var … function F1(..): tipo; procedure P2(…); begin = … F1(…) …; end; procedure P1(…); P2(…); function F1( .): tipo; X P2 P1 F1 … Engenharia reversa da estrutura do programa

Procedimento (exemplo)
Baseia-se em conjunto de regras para o mapeamento de elementos da linguagem A (representados em XML) para elementos da UML Transformação Código  XML  Código fonte original  Transformação XML  UML (XMI)  Biblioteca de dados XML  Diagramas UML

Conversão de código Código original Código original Código convertido
Identificar diferenças entre as linguagens Projetar um tradutor Converter automaticamente Ajustar manualmente

Exemplo Processo de conversão com XML  Transformação Código  XML 
fonte original  Transformação Código  XML  Biblioteca de dados XML Código fonte convertido  Transformação XML  Código 

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

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

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

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

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

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 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

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_case; end loop;

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

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

Refatoração Ver slides

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?

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;

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;

Evolução e Manutenção do Software

Apresentações semelhantes

Apresentação em tema: "Evolução e Manutenção do Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Evolução e Manutenção do Software

Apresentações semelhantes

Apresentação em tema: "Evolução e Manutenção do Software"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback