3. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 3Análise Estática de Código
1. Introdução (1/2)
§ Construção de software não é uma tarefa simples
§ pode se tornar bastante complexa
§ Sujeita a diversos tipos de problemas
§ leva à obtenção de um produto diferente daquele que se
esperava
§ Vários fatores são causas desses problemas
§ contudo a maioria deles tem origem no erro humano
4. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 4Análise Estática de Código
1. Introdução (2/2)
§ A construção do software depende principalmente das pessoas
que o constroem
§ por isto, erros acabam surgindo mesmo com a utilização de
métodos e ferramentas de engenharia de software
§ Estes erros podem ser encontrados antes de o software entrar
em produção
§ uma série de atividades, em conjunto conhecidas como
"Verificação e Validação" ou "V&V" possuem esse objetivo
5. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 5Análise Estática de Código
2. Verificação e Validação (1/5)
§ Verificação e validação, segundo Boehm, podem parecer a
mesma coisa, mas não são
§ Verificação – estamos construindo o produto corretamente?
§ o projeto do software atende à sua especificação?
§ Validação – estamos construindo o produto correto?
§ o software realiza exatamente o que o usuário espera
que ele faça?
§ Confiança no software é o objetivo principal do processo de V&V
6. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 6Análise Estática de Código
2. Verificação e Validação (2/5)
§ Segundo Sommerville, existem duas abordagens
complementares para a verificação e validação do sistema:
§ Inspeções de software
§ analisam e verificam representações de sistema como
documentos de requisitos, diagramas e código fonte do
programa
§ revisões de código, análises automatizadas e verificação
formal são técnicas de V&V estáticas
§ Testes de software
§ envolvem executar uma implementação do software com
dados de teste para examinar as saídas e o
comportamento operacional
§ teste é uma técnica de V&V dinâmica
7. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 7Análise Estática de Código
2. Verificação e Validação (3/5)
§ Inspeções de software
§ Revisão de código
§ examinar o programa, em buscas de erros, omissões ou
anomalias, sem executá-lo
§ geralmente dirigidas por checklists de erros e heurísticas
§ Análises automatizadas
§ processo de revisão de código automatizado para alguns
erros e heurísticas
§ Verificação formal
§ verificar a correção dos algoritmos subjacentes a um
sistema com relação a uma certa propriedade ou
especificação formal, utilizando métodos formais
8. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 8Análise Estática de Código
2. Verificação e Validação (4/5)
§ Testes de software
§ Teste de defeitos
§ encontrar inconsistências entre um programa e sua
especificação, isto é, revelar defeitos
§ Teste de validação
§ tem a finalidade de mostrar que o software é o que o
cliente deseja
§ Contudo, conforme Dijkstra, o teste pode mostrar a presença de
erros, mas não demonstrar que não existam erros
remanescentes
9. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 9Análise Estática de Código
2. Verificação e Validação (5/5)
§ As técnicas de inspeções de software podem somente verificar
a correspondência entre um programa e sua especificação
§ Os testes podem verificar a correspondência entre um programa
e sua especificação e:
§ validar se a funcionalidade é a que o seu proprietário
realmente deseja
§ verificar propriedades emergentes como desempenho e
confiabilidade
§ Portanto, inspeções e testes não são abordagens concorrentes,
mas sim, complementares
§ cada uma tem vantagens e desvantagens sobre a outra
§ devem ser usadas em conjunto no processo de V&V
10. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 10Análise Estática de Código
3. Análise Estática de Código (AEC) (1/9)
§ AEC se refere à análise automatizada
§ que é uma das técnicas de inspeção de software no
processo de V&V
§ seu objetivo é reduzir o número de erros de um programa
§ faz isto chamando a atenção para anomalias do programa
§ geralmente erros de programação ou omissões
§ possíveis erros quando o programa fosse executado
§ exemplos comuns de anomalias:
§ bloco catch vazio
§ conexão ou fluxo não encerrado
§ perda de referência nula
§ comparação de objetos com '=='
11. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 11Análise Estática de Código
3. Análise Estática de Código (AEC) (2/9)
§ Verificação estática de código
§ é verificação realizada por uma ferramenta automatizada
(verificador) seguida de uma análise humana sobre os
resultados
§ não é necessário passar informações ao verificador
§ as informações necessárias são dedutíveis do código
fonte ou mesmo do código objeto
§ algumas ferramentas adotam anotações em código para
passar mais informações ao verificador
§ as anomalias encontradas podem não ser defeitos o que
justifica:
§ a análise humana
§ adoção de anotações
12. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 12Análise Estática de Código
3. Análise Estática de Código (AEC) (3/9)
§ Benefícios da utilização de um verificador estático:
1. encontra erros e códigos de risco
2. fornece um retorno objetivo aos programadores para ajudá-los
a reconhecer onde eles foram precisos e onde eles foram
desatentos
3. fornece a um líder de projeto uma oportunidade para estudar o
código, o projeto e a equipe sob uma perspectiva diferente
4. retira certas classes de defeitos, o que possibilita que a equipe
concentre-se mais em outras deficiências do projeto
13. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 13Análise Estática de Código
3.1. AEC: Linhas de Atuação (4/9)
§ Os verificadores estáticos de código podem verificar:
§ regras de estilo
§ erros
§ ambos
14. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 14Análise Estática de Código
3.1. AEC: Linhas de Atuação (5/9)
§ Verificador de regras de estilo (style checker, em inglês)
§ verifica a conformação de um código fonte à sua definição de
estilo de programação, por exemplo:
§ abertura de chaves
§ ordem de declaração
§ javadoc
§ atribuições em subexpressões
§ uso da referência this
§ visibilidade não explicitada
§ difere-se de um programa Beautifier
§ podem ajudar a prevenir certos tipos de erros e a melhorar a
qualidade do software
§ mas violações em regras de estilo não são
necessariamente erros
15. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 15Análise Estática de Código
3.1. AEC: Linhas de Atuação (6/9)
§ Verificador de erro (bug checker, em inglês)
§ uma ferramenta voltada para a detecção automática de erro,
por exemplo:
§ comparação de objetos sem utilizar equals
§ concatenação de strings em laços de repetição
§ fluxo não encerrado
§ com base nas tendências comuns dos desenvolvedores em
atrair defeitos que, em sua maioria, não são visíveis aos
compiladores
§ nem sempre os resultados são defeitos reais
§ mas podem ser vistos como um alerta
16. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 16Análise Estática de Código
3.1. AEC: Linhas de Atuação (7/9)
§ Existe algum problema em se utilizar, em um mesmo projeto, um
verificador de erro e um verificador de regras de estilo?
17. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 17Análise Estática de Código
3.2. AEC: Comparativo com outras técnicas de V&V (8/9)
§ Revisão de código
§ encontrou todos os tipos de defeitos encontrados por um
verificador de erro
§ disparidade em alguns tipos de erros, por exemplo:
§ "variáveis inicializadas, mas não utilizadas"
§ "claúsula if não necessária"
§ mostrou-se mais bem sucedida
§ pois detecta mais tipos de defeitos
§ logo, recomenda-se utilizar uma ferramenta de verificação de
erros antes de revisar o código
18. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 18Análise Estática de Código
3.2. AEC: Comparativo com outras técnicas de V&V (9/9)
§ Teste de software
§ técnica dinâmica, o que já faz com que espere tipos de erros
diferentes
§ defeitos lógicos
§ não houve um mesmo defeito que tenha sido encontrado por
testes e por uma ferramenta de verificação de erros
§ logo, recomenda-se a utilização de ambas as técnicas
19. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 19Análise Estática de Código
4. Ferramentas (1/9)
§ A idéia de ferramentas de análise estática não é nova
§ Em 1970, Stephen Johnson escreveu Lint
§ examinar programas C compilados sem erros
§ verificava erros que tenham escapado ao compilador
§ forçava as regras de tipos e várias restrições de
portabilidade
§ ferramentas descendentes de abordagem diferente, pois:
§ as linguagens atuais apresentam tipagem forte,
portabilidade e não utilizam várias características
propensas a erros
20. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 20Análise Estática de Código
4. Ferramentas: Características (2/9)
§ Existem importantes atributos que uma ferramenta de análise
estática deve ter:
§ Consistência (soundness, em inglês)
§ todo erro real é reportado pela análise
§ Integridade (completeness, em inglês)
§ todo erro reportado é um erro real, isto é, nenhum erro
reportado é um falso positivo
§ Utilidade (usefulness, em inglês)
§ se reporta erros que são relevantes
§ Uma ferramenta de análise estática é consistente, íntegra e útil?
§ não é consistente nem íntegra, assim como as demais
técnicas de V&V
§ ainda assim, esses atributos são cada vez mais visados
21. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 21Análise Estática de Código
4. Ferramentas: Técnicas (3/9)
§ A análise estática em aplicações Java podem atuar sobre o
código fonte e/ou bytecode
§ cada uma das versões tem suas vantagens
§ atuar sobre as duas versões, tirando proveito das vantagens
particulares de cada uma, apresenta-se como a melhor
solução
22. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 22Análise Estática de Código
4. Ferramentas: Principais ferramentas (4/9)
§ As ferramentas em negrito são abordadas nesta palestra:
§ Por que não Jlint, QJ-PRO e ESC/Java2?
23. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 23Análise Estática de Código
4. Ferramentas: Principais ferramentas (5/9)
§ Checkstyle
§ é uma ferramenta voltada à verificação de regras de estilo
§ ordem de declaração
§ padrão de nomenclatura
§ posição da claúsula default em instruções switch
§ atualmente, provê algumas funcionalidades de um
verificador de erro
§ é configurável permitindo customizar as regras por projeto
24. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 24Análise Estática de Código
4. Ferramentas: Principais ferramentas (6/9)
§ FindBugs
§ uma popular ferramenta voltada à verificação de erros
desenvolvida pela University of Maryland
§ provê suporte a mais de 250 padrões de erros
§ valor de retorno ignorado
§ comparação com nulo redundante
§ não utilização de operador de curto-circuito
§ mais de uma centena deles classificados como erros de
correção
§ permite que programadores escrevam seus próprios padrões
de erros
25. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 25Análise Estática de Código
4. Ferramentas: Principais ferramentas (7/9)
§ Klocwork Developer
§ é uma ferramenta voltada exclusivamente à verificação de
erros
§ além de encontrar defeitos
§ também procura por vulnerabilidades de segurança
§ executa métricas e análises arquiteturais
26. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 26Análise Estática de Código
4. Ferramentas: Principais ferramentas (8/9)
§ PMD
§ é uma ferramenta mista
§ começou como um simples verificador de regras de estilo
§ atualmente, já permite que programadores escrevam seus
próprios padrões de erros, assim como ocorre no FindBugs
27. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 27Análise Estática de Código
4. Ferramentas: Principais ferramentas (9/9)
§ Módulos de extensão para a versão mais atual da IDE Eclipse:
28. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 28Análise Estática de Código
5. Avaliação (1/5)
§ As tabelas a seguir apresentam uma breve descrição do defeito
e os resultados da aplicação de cada ferramenta
§ √ indica que alertou
§ - indica que não alertou
29. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 29Análise Estática de Código
5. Avaliação (2/5)
30. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 30Análise Estática de Código
5. Avaliação (3/5)
31. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 31Análise Estática de Código
5. Avaliação (4/5)
§ Falso positivo
§ ocorre quando se adota uma implementação pouco
convencional
§ ocorreu um único falso positivo em um único estudo de caso
§ uma excelente taxa de integridade
§ Se os alertas referem-se a erros reais, mas que os
desenvolvedores não o consideram importante
§ basta a ferramenta prover um filtro de quais problemas
devem ser verificados
§ Contudo, se os alertas referem-se a falso positivos, o problema
está na própria ferramenta
§ uma possível solução seria o uso de anotações
32. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 32Análise Estática de Código
5. Avaliação (5/5)
§ Um único estudo de caso não foi alertado por nenhuma
ferramenta
§ reforça que a ausência de alertas não implica na ausência
de erros
§ A existência de um erro real não alertado e um falso positivo,
somente nos remete ao conceito de que nenhum verificador
estático de código é consistente e íntegro
§ nenhum verificador pode nos assegurar que um programa
está correto - tal garantia não é possível
33. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 33Análise Estática de Código
6. Considerações Finais (1/5)
§ A análise de código-fonte automatizada é uma das técnicas de
inspeções de software
§ automatização de parte do checklist de uma revisão de
código manual
§ A revisão de código encontra todos os defeitos encontrados por
um verificador estático de código
§ disparidade de alertas em alguns tipos de defeitos
§ As ferramentas de análise estática automatizada são eficazes
em encontrar defeitos relacionados aos princípios de
programação estruturada e à manutenibilidade
§ uma excelente prática de programação defensiva
§ Por outro lado, os testes de software detectam defeitos
diferentes
34. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 34Análise Estática de Código
6. Considerações Finais (2/5)
§ Metodologia proposta para a qualidade de um projeto de
software:
1. ferramenta de verificação estática sempre após a compilação
e antes de uma revisão de código manual
2. assim o programa obtém uma indicação inicial de correção
adequada para a realização de testes
35. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 35Análise Estática de Código
6. Considerações Finais (3/5)
§ A ferramenta Checkstyle apresentou-se como a melhor
ferramenta de verificação de regras de estilo
§ A ferramenta Klocwork Developer foi a melhor ferramenta de
verificação de erros alertando sobre todos os erros
§ contudo proprietária, o que faz o FindBugs ser uma
excelente alternativa
36. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 36Análise Estática de Código
6. Considerações Finais (4/5)
§ As ferramentas verificadoras de regras de estilo tendem a
incorporar verificadores para outros propósitos
§ PMD e Checkstyle
§ Isso pode ser bom, por se tornarem mais abrangentes
§ evitar que acabe por não fazer nenhuma das funções
corretamente
§ Por outro lado, as ferramentas verificadoras de erros mantêm
seu foco
37. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 37Análise Estática de Código
6. Considerações Finais (5/5)
§ Nenhuma máquina pode substituir o bom senso, o sólido
conhecimento dos fundamentos, o pensamento claro e a
disciplina
§ Contudo, ferramentas de verificação estática de código podem
efetivamente ajudar os desenvolvedores e, a sua mais ampla
adoção, pode aumentar significativamente a qualidade do
software
38. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008 38Análise Estática de Código
Dúvidas?
???