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

2 Aná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)

The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again.

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

§  Bacharel em Ciência da Computação – FUMEC §  Pós-graduado em Análise de Sistemas – UFMG §  Mestrando em Informática – PUC Minas

§  Especializado em Java §  SCJP §  SCWCD

§  Professor §  FAMINAS-BH §  UNIPAC-CONTAGEM

Ricardo Terra


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 Sommerv i l l e , ex i s tem duas abo rdagens 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 v io lações em reg ras de es t i l o 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

Education