Evolução e
Manutenção do
Software
Nov/2009
Eliane Martins - Instituto de Computação - UNICAMP
Tópicos
• Evolução ou manutenção
• Manutenção de Software
• Tipos de manutenção
• Dificuldades
• Manutenibilidade
Eliane Martins - Instituto de Computação - UNICAMP
2
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”. McGrawHill, 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, pp303-310.
K.Bennett. “Sw Evolution: Past, Present and Future”. Information and
Software Technology, nº38, 1996, pp673-680.
Eliane Martins - Instituto de Computação - UNICAMP
3
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
Eliane Martins - Instituto de Computação - UNICAMP
4
Sobre o valor do software
• Sw tem valor quando
 atende aos requisitos
Eliane Martins - Instituto de Computação - UNICAMP
5
Sobre o valor do software
• Sw tem valor quando
 atende aos requisitos
• Valor do sw  devido a
 falhas
 mudanças nos requisitos
tempo
Eliane Martins - Instituto de Computação - UNICAMP
6
Sobre o valor do software
• Sw tem valor quando
 atende aos requisitos
 é fácil de entender e de usar
Eliane Martins - Instituto de Computação - UNICAMP
7
Sobre o valor do software
• Sw tem valor quando
• Valor do sw  devido a
 atende aos requisitos
 falhas
 mudanças nos requisitos
 é fácil de entender e de usar
 complexidade
tempo
Eliane Martins - Instituto de Computação - UNICAMP
8
Sobre o valor do software
• Sw tem valor quando
 atende aos requisitos
 é fácil de entender e de usar
 é eficiente
Eliane Martins - Instituto de Computação - UNICAMP
9
Sobre o valor do software
• Sw tem valor quando
• Valor do sw  devido a
 atende aos requisitos
 falhas
 mudanças nos requisitos
 é fácil de entender e de usar
 complexidade
 é eficiente
 ineficiência
tempo
Eliane Martins - Instituto de Computação - UNICAMP
10
Sobre o valor do software
• Sw tem valor quando
 atende aos requisitos
 é fácil de entender e de usar
 é eficiente
 usa tecnologia atual
Eliane Martins - Instituto de Computação - UNICAMP
11
Sobre o valor do software
• Sw tem valor quando
• Valor do sw  devido a
 atende aos requisitos
 falhas
 mudanças nos requisitos
 é fácil de entender e de usar
 complexidade
 é eficiente
 ineficiência
 usa tecnologia atual
 tecnologia obsoleta
tempo
Eliane Martins - Instituto de Computação - UNICAMP
12
Sobre o valor do software
• Valor do sw  devido a
• Sw tem valor quando
 atende aos requisitos
 falhas
 mudanças nos requisitos
 complexidade
alterações
 é fácil de entender e de usar
 ineficiência
 é eficiente
 tecnologia obsoleta
 usa tecnologia atual
tempo
Eliane Martins - Instituto de Computação - UNICAMP
13
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
Eliane Martins - Instituto de Computação - UNICAMP
14
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 
taxa de falhas
hw
mortalidade
infantil
desgaste
tempo
Eliane Martins - Instituto de Computação - UNICAMP
15
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 
sw
mortalidade
infantil
desgaste
taxa de falhas
taxa de falhas
hw
ideal
tempo
Eliane Martins - Instituto de Computação - UNICAMP
tempo
16
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 
sw
mortalidade
infantil
desgaste
alteração
taxa de falhas
taxa de falhas
hw
real
ideal
tempo
Eliane Martins - Instituto de Computação - UNICAMP
tempo
17
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
Eliane Martins - Instituto de Computação - UNICAMP
18
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
Eliane Martins - Instituto de Computação - UNICAMP
19
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)
Eliane Martins - Instituto de Computação - UNICAMP
20
Tópicos
• Evolução ou manutenção
• Manutenção de Software
• Tipos de manutenção
• Dificuldades
• Manutenibilidade
Eliane Martins - Instituto de Computação - UNICAMP
21
Manutenção
• Definição
– é o processo de modificação de um produto após a
entrega
• Tipos
– corretiva
– adaptativa
– perfectiva
Eliane Martins - Instituto de Computação - UNICAMP
22
Custos com manutenção
90
80
70
60
50
40
30
20
10
0
90
75
55
40
início anos início anos final anos início anos
90
80
80
70
Eliane Martins - Instituto de Computação - UNICAMP
Dados de 1990
23
Distribuição dos custos de manutenção
melhorias doc
6%
melhorias
código outras
3%
4%
melhorias
usuários
43%
emergenciais
12%
rotineiras
9%
adaptação
dos dados
17%
mudanças hw,
S.Op.
6%
Internet, maio/2002
Eliane Martins - Instituto de Computação - UNICAMP
24
Distribuição dos custos por categoria
corretiva
17%
perfectiva
65%
adaptativa
18%
Dados de 1990
Eliane Martins - Instituto de Computação - UNICAMP
25
Tópicos
• Evolução ou manutenção
• Manutenção de Software
• Tipos de manutenção
• Dificuldades
• Manutenibilidade
Eliane Martins - Instituto de Computação - UNICAMP
26
Porquê os custos são altos?
• Fatores:
– usuário
– contrato
– equipe de desenvolvimento
– sistema
– produto
Eliane Martins - Instituto de Computação - UNICAMP
27
Porquê os custos são altos?
• Fatores:
– usuário
– contrato
Pouco treinamento
Mudança de objetivos:
necessidades do usuário evoluem;
novos usuários
– equipe de desenvolvimento
– sistema
– produto
Eliane Martins - Instituto de Computação - UNICAMP
28
Porquê os custos são altos?
• Fatores:
Contrato manutenção separado do
contrato de desenvolvimento, podendo
inclusive ser dado a outra empresa
– contrato

pouco incentivo para produção de sw
– equipe de desenvolvimento
fácil de manter
– sistema
– usuário
– produto
Eliane Martins - Instituto de Computação - UNICAMP
29
Porquê os custos são altos?
• Fatores:
– usuário
– contrato
ausência dos desenvolvedores
falta de tempo
falta de motivação
falta de experiência
– equipe de desenvolvimento
– sistema
– produto
Eliane Martins - Instituto de Computação - UNICAMP
30
Porquê os custos são altos?
• Fatores:
– usuário
domínio da aplicação
dependência do ambiente externo
– contrato
instabilidade do hw
alterações sem controle
– equipe de desenvolvimento
– sistema
– produto
Eliane Martins - Instituto de Computação - UNICAMP
31
Porquê os custos são altos?
• Fatores:
– usuário
– contrato
idade
qualidade da documentação
– equipe de desenvolvimento
estilo de programação
acoplamento entre os módulos
– sistema
linguagem de programação
V&V deficiente
– produto
Eliane Martins - Instituto de Computação - UNICAMP
32
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
Eliane Martins - Instituto de Computação - UNICAMP
33
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]
Eliane Martins - Instituto de Computação - UNICAMP
34
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]
Eliane Martins - Instituto de Computação - UNICAMP
35
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]
Eliane Martins - Instituto de Computação - UNICAMP
36
Tópicos
• Evolução ou manutenção
• Manutenção de Software
• Tipos de manutenção
• Dificuldades
• Manutenibilidade
Eliane Martins - Instituto de Computação - UNICAMP
37
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
610.12, 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 8402 1986)
Eliane Martins - Instituto de Computação - UNICAMP
38
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 ?
Eliane Martins - Instituto de Computação - UNICAMP
39
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
Eliane Martins - Instituto de Computação - UNICAMP
40
O que afeta a manutenibilidade
•
•
•
•
•
•
Processo de desenvolvimento
Documentação
Manutenibilidade deve ser considerada
Qualidade do sw
ao longo de todo desenvolvimento.
Disponibilidade
testes
Pb.:dos
como
convencer gerentes de que
manutenibilidade  ganhos
Disponibilidade
das ferramentas de desenvolvimento
Controle de alterações
Eliane Martins - Instituto de Computação - UNICAMP
41
O que afeta a manutenibilidade
•
•
•
•
•
•
Processo de desenvolvimento
Documentação
Qualidade do sw
Disponibilidade dos testes
documentação desatualizada, incompleta ou
Disponibilidade
das ferramentas
de manutenção
desenvolvimento
inexistente
 custo com

(47% - 62% tempo para compreensão de
Controle de alterações
programas e documentos)
Eliane Martins - Instituto de Computação - UNICAMP
[Pigosrki 1996]
42
O que afeta a manutenibilidade
•
•
•
•
•
•
Processo de desenvolvimento
Documentação
Qualidade do sw
Disponibilidade dos testes
qualidade   custo com manutenção 
Disponibilidade
das ferramentas
Aspectos
de qualidade:de desenvolvimento
- estrutura do sw
Controle de alterações
- estilo de programação
- sistemática de V&V
Eliane Martins - Instituto de Computação - UNICAMP
43
O que afeta a manutenibilidade
•
•
•
•
•
•
Processo de desenvolvimento
Documentação
Qualidade do sw
Disponibilidade dos testes
Disponibilidade das ferramentas de desenvolvimento
Facilita realização de testes, em
Controle de alterações
especial os de regressão
Eliane Martins - Instituto de Computação - UNICAMP
44
O que afeta a manutenibilidade
•
•
•
•
•
•
Processo de desenvolvimento
Documentação
Qualidade do sw
Disponibilidade dos testes
Disponibilidade das ferramentas de desenvolvimento
Controle deFacilita
alterações
realização modificações, permitindo atualizar:
- modelos de análise e projeto; documentação
- código fonte (existência do compilador)
- testes, entre outros
Eliane Martins - Instituto de Computação - UNICAMP
45
Como estimar manutenibilidade
• Manutenibilidade pode ser medida
• Diversas métricas propostas:
– padrão IEEE
– outras
Eliane Martins - Instituto de Computação - UNICAMP
46
Métricas
• Permitem determinar quão fácil é manter um sw
• manutenibilidade pode ser caracterizada pelos seguintes
sub-fatores (IEEE 1061 1992):
– 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
Eliane Martins - Instituto de Computação - UNICAMP
48
Métricas
Subfator
tipo de métrica
• corrigibilidade Contagem
de falhas
esforço
métrica
•
•
•
•
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
Eliane Martins - Instituto de Computação - UNICAMP
49
Métricas
Subfator
• testabilidade
tipo de métrica
métrica
cobertura
•
•
•
cobertura do código
cobertura dos requisitos
grau de completeza do plano de
testes
esforço
•
•
•
previsão de recursos
previsão de esforço
produtividade
Eliane Martins - Instituto de Computação - UNICAMP
50
Métricas
Subfator
tipo de métrica
• expansibilidade modificações
esforço
métrica
•
•
•
•
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
Eliane Martins - Instituto de Computação - UNICAMP
51
Outras métricas
• Diversos autores (academia e indústria):
– Schneidewind 1987
– Lewis e Henry 1989
– Oman 1991
entre outros
Eliane Martins - Instituto de Computação - UNICAMP
52
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
Eliane Martins - Instituto de Computação - UNICAMP
58
Modularidade para sistemas
procedimentais
nº de procedimentos
Mproc =
Exemplo:
Programa
ProgA
ProgB
KLOCS
LOC
1000
1000
nº funções M
2
0,002
12
0,012
[Peters e Pedrycz 2001]
Eliane Martins - Instituto de Computação - UNICAMP
59
Modularidade para sistemas OO
nº de métodos da classe
Mclasse =
Msist =
KLOCS
nº médio de métodos por classe
nº médio de KLOCS por classe
[Peters e Pedrycz 2001]
Eliane Martins - Instituto de Computação - UNICAMP
60
Legibilidade
• Legibilidade:
– de documentos:
FOG = 0,4 
nº de palavras
nº de sentenças
+ % de palavras com ( 3+) sílabas
– de código:
L = | 0,295 id - 0,499 LOC + 0,13 c 
complexidade ciclomática
comprimento médio dos identificadores
[Peters e Pedrycz 2001]
Eliane Martins - Instituto de Computação - UNICAMP
61
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
• ...
Eliane Martins - Instituto de Computação - UNICAMP
63
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
Eliane Martins - Instituto de Computação - UNICAMP
64
Reengenharia do Software
Eliane Martins - Instituto de Computação - UNICAMP
65
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.
Eliane Martins - Instituto de Computação - UNICAMP
66
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
Eliane Martins - Instituto de Computação - UNICAMP
67
Engenharia Progressiva e Reengenharia
Engenharia Progressiva
Especificação
do Sistema
Projeto e
Implementação
Novo
sistema
Reengenharia
Sistema
Antigo
Compreensão e
Transformação
Eliane Martins - Instituto de Computação - UNICAMP
Sistema
Melhorado
68
Atividades
•
•
•
•
•
Engenharia reversa
Conversão de código
Reestruturação dos dados
Reestruturação do código
Remodularização do código
Eliane Martins - Instituto de Computação - UNICAMP
Refatoração
69
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) ...
Eliane Martins - Instituto de Computação - UNICAMP
70
Engenharia reversa de código - exemplo
program X;
var
…
function F1(
.): tipo;
F1(..):
…
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:
Eliane Martins - Instituto de Computação - UNICAMP
71
Engenharia reversa de código - exemplo
program X;
var
…
function F1(
.): tipo;
F1(..):
…
procedure P2(…);
begin
…
= … F1(…) …;
end;
procedure P1(…);
begin
…
P2(…);
…
end;
Eliane Martins - Instituto de Computação - UNICAMP
X
…
P1
P2
F1
72
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


Biblioteca de
dados XML
Transformação
XML  UML
(XMI)

Diagramas
UML
Eliane Martins - Instituto de Computação - UNICAMP
73
Conversão de código
Código original
Código original
Identificar
diferenças
entre as
linguagens
Projetar
um tradutor
Converter
automaticamente
Eliane Martins - Instituto de Computação - UNICAMP
Código convertido
Ajustar
manualmente
74
Exemplo
Processo de conversão com XML
Código
fonte
original
Código
fonte
convertido

Transformação
Código  XML

Biblioteca de
dados XML

Transformação
XML  Código

Eliane Martins - Instituto de Computação - UNICAMP
75
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
Eliane Martins - Instituto de Computação - UNICAMP
76
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
Eliane Martins - Instituto de Computação - UNICAMP
77
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
Eliane Martins - Instituto de Computação - UNICAMP
78
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
Eliane Martins - Instituto de Computação - UNICAMP
79
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
Eliane Martins - Instituto de Computação - UNICAMP
80
Código espaguete
Start:
Off:
On:
Cntrld:
get (time_on, time_off, time, setting, temp, switch)
if switch = off goto Off
if switch = on goto On
goto Cntrld
if heating_status = on goto Sw_off
goto Loop
if heating_status = off goto Sw_on
goto Loop
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
Eliane Martins - Instituto de Computação - UNICAMP
Sw_off:
Sw_on:
Switch:
Loop:
heating_status := off
goto Switch
heating_status := on
Switch_heating ( )
goto Start
81
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_if;
end_case;
end loop;
Eliane Martins - Instituto de Computação - UNICAMP
82
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)...
Eliane Martins - Instituto de Computação - UNICAMP
83
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
Eliane Martins - Instituto de Computação - UNICAMP
84
Refatoração
Ver slides
Eliane Martins - Instituto de Computação - UNICAMP
85
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?
Eliane Martins - Instituto de Computação - UNICAMP
86
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;
Eliane Martins - Instituto de Computação - UNICAMP
87
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;
Eliane Martins - Instituto de Computação - UNICAMP
88