Análise Estática de Código

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008
Análise Estática de Código
Ricardo Terra
rterrabh [at] gmail.com
Análise Estática de Código 1

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2008
CV
2Análise Estática de Código
Nome: Ricardo Terra
Email: rterrabh [at] gmail.com
www: ricardoterra.com.br
Twitter: rterrabh
Lattes: lattes.cnpq.br/ 0162081093970868
Ph.D. (UFMG/UWaterloo),
Post-Ph.D. (INRIA/Université Lille 1)
Background
Acadêmico: UFLA (desde 2014), UFSJ (1 ano), FUMEC (3 anos), UNIPAC (1 ano), FAMINAS (3 anos)
Profissional: DBA Eng. (1 ano), Synos (2 anos), Stefanini (1 ano)

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

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

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

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

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

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

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

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

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

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

3.1. AEC: Linhas de Atuação (4/9)
§  Os verificadores estáticos de código podem verificar:
§  regras de estilo
§  erros
§  ambos

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

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

§  Existe algum problema em se utilizar, em um mesmo projeto, um
verificador de erro e um verificador de regras de estilo?

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

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

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

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

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

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?

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

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

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

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

§  Módulos de extensão para a versão mais atual da IDE Eclipse:

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

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

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

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

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

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

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

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

Dúvidas?
???

Análise Estática de Código

Mais conteúdo relacionado

Mais procurados

Semelhante a Análise Estática de Código

Mais de Ricardo Terra

Último

Análise Estática de Código