2008 Monografia Ufmg

UNIVERSIDADE FEDERAL DE MINAS GERAIS
INSTITUTO DE CINCIAS EXATAS

DEPARTAMENTO DE CINCIAS DA COMPUTAO
RICARDO TERRA NUNES BUENO VILLELA
FERRAMENTAS PARA
ANLISE ESTTICA DE CDIGOS JAVA
Belo Horizonte
Fevereiro de 2008
UNIVERSIDADE FEDERAL DE MINAS GERAIS

INSTITUTO DE CINCIAS EXATAS
DEPARTAMENTO DE CINCIAS DA COMPUTAO
ESPECIALIZAO EM INFORMTICA: NFASE: ANLISE DE SISTEMAS
RICARDO TERRA NUNES BUENO VILLELA
FERRAMENTAS PARA
ANLISE ESTTICA DE CDIGOS JAVA
Monografia apresentada Curso de Especializao em Informtica do Departamento de

Cincias Exatas da Universidade Federal de
Minas Gerais, como requisito parcial para a
obteno do certificado de Especialista em
Informtica.
rea de Concentrao:
temas
Orientador: Prof.
Bigonha
Belo Horizonte
Fevereiro de 2008
Dr.
Anlise de Sis-
Roberto da Silva
Dedico esta monografia a meu pai por sempre me apoiar nos estudos e ao meu av
Jos Bueno Vilela por ser um exemplo de dedicao, respeito, amizade, amor, enfim, de
vida a todos ns.
Agradecimentos
Em primeiro lugar, gostaria de agradecer aos meus pais todo apoio e carinho que me
foram dados em todas as fases de minha vida.
Agradeo a todos os professores do curso de ps-graduao, principalmente ao Roberto
da S. Bigonha todo o conhecimento transmitido e a orientao neste estudo.
Agradeo ao professor Marco Tlio de Oliveira Valente suas colaboraes ao estudo,
inclusive pelo sugesto do tema.
Agradeo minha prima, Rafaela Terra, a reviso gramatical e ao meu grande amigo,
Alexander Flvio, a reviso do contedo. Agradeo tambm ao Lucas Amaral as suas
colaboraes germnicas.
Agradeo a minha av, Zita Villela, por me hospedar em sua casa por quase todo
desenvolvimento desta monografia.
Agradeo ao Danny Baldwin da equipe Klocwork a prestatividade e as informaes
fornecidas.
Finalmente, agradeo a Deus por sempre estar ao meu lado e por ter me dado todas
as ferramentas e oportunidades para que eu chegasse onde estou.
"Nunca se fizeram programas contendo to

poucos erros como quando nenhuma ferramenta de depurao existia."
Niklaus Wirth
Resumo
Atualmente, uma grande parcela de sistemas que entram em produo apresenta erros.
Para a minimizao deste problema, as atividades de Verificao e Validao (V & V) se
tornam indispensveis.
Vrias tcnicas tm sido desenvolvidas para automaticamente encontrar erros nos sistemas. A Anlise Esttica de Cdigo um dos instrumentos conhecidos pela Engenharia
de Software para a mitigao de erros, seja por sua utilizao para a verificao de estilos,
para a verificao de erros ou ambos.
Checkstyle, FindBugs, PMD, Klocwork Developer so algumas das diversas ferramentas automticas para a linguagem Java que ajudam a reduzir o nmero de erros utilizando
Anlise Esttica de Cdigo.
O estudo tem como objetivo realizar a comparao dessas ferramentas, avaliando-as e
mensurando a eficcia e eficincia a partir da aplicao de diversos estudos de caso.
Palavras-chave: Engenharia de software, validao, verificao, inspeo, testes, erros,

regras de estilo, anlise esttica de cdigo, Java.
Abstract
Nowadays, a large portion of the systems which have come into production presents errors.
To minimise this problem, the activities of Verification and Validation (V & V) become
indispensables.
Many techniques have been developed to automatically find errors in systems. The
Static Code Analysis is one of the instruments known by Software Engineering for mitigation of errors, either because its use for style checkers, for bugs checkers or both.
Checkstyle, FindBugs, PMD, Klocwork Developer are some of the various automatic
tools for the Java language which help to reduce the number of errors using Static Code
Analysis.
The objetive of the study is to make a comparison of these tools, evaluating them and
measuring the effectiveness and efficiency by the application of several case studies.
Keywords: Software engineering, validation, verification, inspection, test, bugs, style

rules, static code analysis, Java.
Lista de Figuras
1.1
Processo de depurao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1
3.2
Verificadores estticos em relao cobertura e ao esforo . . . . . . . . . . . 33

Mdulo de extenso do Checkstyle para IDE Eclipse . . . . . . . . . . . . . . . 36
3.3
3.4
3.5
Mdulo de extenso do FindBugs para IDE Eclipse . . . . . . . . . . . . . . . 37

Mdulo de extenso do Klocwork Developer para IDE Eclipse . . . . . . . . . 37
Mdulo de extenso do PMD para IDE Eclipse . . . . . . . . . . . . . . . . . 38
Lista de Tabelas
2.1
2.2
2.3
Alguns exemplos de regras de estilo . . . . . . . . . . . . . . . . . . . . . . . . 25

Alguns exemplos de erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A eficincia de remoo de defeitos por tcnica de deteco de erro . . . . . . 31
3.1
3.2
3.3
Principais ferramentas para anlise esttica de cdigo Java . . . . . . . . . . . 35

Resultado sintetizado sobre a eficcia da verificao de um bloco catch vazio . 39
Resultado sintetizado sobre a eficcia da verificao de uma atribuio em
subexpresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4
Resultado sintetizado sobre a eficcia da verificao de uma comparao com

constante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultado sintetizado sobre a eficcia da verificao de uma instruo vazia .
Resultado sintetizado sobre a eficcia da verificao da ordem de declarao .
Resultado sintetizado sobre a eficcia da verificao do padro de nomenclatura
3.5
3.6
3.7
41
42
42
43
3.8
Resultado sintetizado sobre a eficcia da verificao da posio da clusula

default em instrues switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.9 Resultado sintetizado sobre a eficcia da verificao do uso da referncia this
44
3.10 Resultado sintetizado sobre a eficcia da verificao do uso de chaves . . . . . 45
3.11 Resultado sintetizado sobre a eficcia da verificao de conexo com banco de
dados no encerrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.12 Resultado sintetizado sobre a eficcia da verificao de um valor de retorno
ignorado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 Resultado sintetizado sobre a eficcia da verificao de perda de referncia nula 48
3.14 Resultado sintetizado sobre a eficcia da verificao de concatenao de strings
em laos de repetio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.15 Resultado sintetizado sobre a eficcia da verificao de fluxo no encerrado . 49
3.16 Resultado sintetizado sobre a eficcia da verificao da no utilizao de operador booleano de curto-circuito . .
3.17 Resultado sintetizado sobre a eficcia
mesmo cdigo de disperso . . . . .
3.18 Resultado sintetizado sobre a eficcia
invs de equals . . . . . . . . . . .
. . . . . . . .
da verificao
. . . . . . . .
da verificao
. . . . . . . .
. . . . . . . . . . . . . . . 50
que objetos iguais tm o
. . . . . . . . . . . . . . . 51
da utilizao de == ao
. . . . . . . . . . . . . . . 52
3.19 Resultado sintetizado sobre a eficcia da verificao de comparao com nulo

redundante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.20 Resultado sintetizado sobre a eficcia das ferramentas . . . . . . . . . . . . . 55
Lista de Siglas
API Application Programming Interface, traduzido por Interface de Programao de
Aplicativo
AST Abstract Syntax Tree, traduzido por rvore de Sintaxe Abstrata
BCEL Bytecode Engineering Library, traduzido por Biblioteca de Engenharia de
Bytecode
IDE Integrated Development Environment, traduzido por Ambiente Integrado de
Desenvolvimento
SQL Structured Query Language, traduzido por Linguagem de Consulta Estruturada
V & V Verificao e Validao
VM Virtual Machine, traduzido por Mquina Virtual
XML Extensible Markup Language, traduzido por Linguagem de Marcao Extensvel
Sumrio
1 Correo do software
1.1 Verificao e validao .
1.1.1 Depurao . . . .
1.2 Inspees de software . .
1.2.1 Verificao formal
1.3 Testes de software . . . .
1.4 Consideraes finais . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Anlise Esttica de Cdigo

2.1 Categorizao dos defeitos . . . . . . . .
2.2 Linhas de atuao . . . . . . . . . . . . .
2.2.1 Verificadores de estilo . . . . . . .
2.2.2 Verificadores de erro . . . . . . .
2.2.3 Diferenas . . . . . . . . . . . . .
2.2.4 Aplicaes . . . . . . . . . . . . .
2.3 Comparativo com outras tcnicas de V &
2.3.1 Inspeo de cdigo . . . . . . . .
2.3.2 Teste de software . . . . . . . . .
2.4 Consideraes finais . . . . . . . . . . . .
3 Ferramentas de Anlise Esttica
3.1 Caractersticas . . . . . . . . .
3.2 Tcnicas . . . . . . . . . . . . .
3.3 Principais ferramentas . . . . .
3.4 Estudos de caso . . . . . . . . .
3.4.1 Regras de estilo . . . . .
3.4.2 Erros . . . . . . . . . . .
3.5 Problemas e solues propostas
3.6 Consideraes finais . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
V
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
14
15
17
18
19
.
.
.
.
.
.
.
.
.
.
21
22
23
23
24
26
27
28
28
29
29
.
.
.
.
.
.
.
.
32
33
34
35
38
38
45
53
54
4 Concluso
57
Referncias Bibliogrficas
60
1 Correo do software
Qualidade de software uma rea de grande enfoque na engenharia de software. Nos dias
atuais, cada vez mais estudos so realizados para garantir a maior correo do cdigo,
porm existe uma grande parcela de usurios ou desenvolvedores de sistemas que ainda
no esto convencidos de que erro um problema srio.
Definitivamente, a construo de software no uma tarefa simples. Pelo
contrrio, pode se tornar bastante complexa, dependendo das caractersticas e dimenses do sistema a ser criado. Por isto, est sujeita a diversos
tipos de problemas que acabam na obteno de um produto diferente
daquele que se esperava. (MALDONADO; DELAMARO; JINO, 2007, p. 1,
grifo nosso)
Vrios fatores podem ser identificados como causas destes problemas, mas a maioria
deles tem uma nica origem: erro humano. Ainda segundo Maldonado, Delamaro e Jino
(2007), a construo de software depende principalmente da habilidade, da interpretao
e da execuo das pessoas que o constroem e, por isto, erros acabam surgindo, mesmo
com a utilizao de mtodos e ferramentas de engenharia de software.
Para que estes erros no perdurem, isto , para que sejam descobertos antes de o
software entrar em produo, existem uma srie de atividades que, em conjunto so
conhecidas como "Verificao e Validao" ou "V & V" , possuem a finalidade de garantir
que tanto o modo pelo qual o software est sendo construdo quanto o produto em si
estejam em conformidade com o especificado.
Segundo Parekh (2005), Maldonado, Delamaro e Jino (2007) e Sommerville (2007), as
atividades de V & V devem ser conduzidas durante todo o processo de desenvolvimento
do software, durante e depois do processo de implementao para certificar se ele atende
a sua especificao e se entregue a funcionalidade esperada pelo cliente.
Nas prximas sees deste captulo ser abordada uma introduo s tcnicas de V & V
que so muito importantes para o contextualizao do estudo. No Captulo 2 so abordadas a Anlise Esttica de Cdigo, suas linhas de atuao e um comparativo com outras
tcnicas de V & V largamente utilizadas.
No Captulo 3 sero abordadas as origens, caractersticas e tcnicas das ferramentas
de anlise esttica que so analisadas, avaliadas e comparadas a partir da aplicao de
diversos estudos de caso que mensuram sua eficcia e eficincia. Por fim, no captulo 4
so expostas as consideraes finais e descries de possveis trabalhos futuros.
12
1. Correo do software
1.1
13
Verificao e validao
A princpio, verificao e validao podem parecer ser a mesma coisa, porm Boehm (1979,
apud SOMMERVILLE, 2007) expressou sucintamente a diferena entre elas:
Verificao: Estamos construindo o produto corretamente?
Validao: Estamos construindo o produto correto?
A partir desta definio, pode-se entender verificao como o ato de verificar se o projeto
do software est de acordo com suas especificaes, isto , se uma fase do projeto do
software reflete exatamentes as intenes da fase anterior. Validao, no entanto, possui
a finalidade de assegurar que o software atenda s expectativas do cliente, vai alm da
verificao de conformao do sistema com sua especificao, mas sim, mostra que o
software realiza o que o cliente espera que ele faa.
Sommerville (2007) diz que objetivo principal do processo de V & V estabelecer
confiana de que o sistema de software est "adequado ao seu propsito". Isto significa
que o sistema deve ser bom o suficiente para o uso pretendido. O nvel de confiabilidade
exigido depende de vrios fatores:
Funo do software: O nvel de confiabilidade depende de quo crtico for o software
para uma organizao. Por exemplo, se o software for um prottipo ou piloto, o
nvel de confiabilidade bem inferior a um software de controle de segurana de um
banco.
Expectativas do usurio: Infelizmente muitos usurios tm baixas expectativas quanto
ao software e no se surpreendem quando o mesmo falha durante o uso. Eles tendem
a aceitar essas falhas de sistema quando os benefcios do uso ultrapassam as desvantagens. Contudo, esta tolerncia tem decrescido desde a dcada de 1990, fazendo
com que agora fique cada vez menos aceitvel a entrega de sistemas no confiveis, o
que resulta em mais esforo para as atividades de V & V nas empresas de software.
Ambiente e mercado: Quando um sistema comercializado, os fornecedores do
sistema devem levar em considerao os programas dos concorrentes, o preo que
os clientes esto dispostos a pagar e o prazo de entrega deste sistema. Quando uma
empresa tem poucos concorrentes, ela pode decidir liberar um programa antes que
ele tenha sido inteiramente testado e depurado visando ser os pioneiros no mercado.
Quando os clientes no esto dispostos a pagar altos preos pelo software, podem
estar dispostos a tolerar uma maior taxa de defeitos.
Todos os fatores acima devem ser considerados na deciso de quanto esforo deve ser
empregado no processo de V & V.
14
Ainda na mesma linha de raciocnio de Sommerville (2007), dentro do processo de

V & V, existem duas abordagens complementares para a verificao e anlise do sistema:
Inspees de software ou revises por pares analisam e verificam representaes de
sistemas como documento de requisitos, diagramas de projeto e cdigo-fonte de
programa. Voc pode usar inspees em todos os estgios do processo. Inspees
podem ser suplementadas por alguma anlise automtica de cdigo-fonte de um
sistema ou de documentos associados. Inspees de software, anlises automatizadas
e verificao formal so tcnicas de V & V estticas.
Segundo Maldonado, Delamaro e Jino (2007), tcnicas estticas so aquelas que no
requerem a execuo ou mesmo a existncia de um programa ou modelo executvel
para serem conduzidas.
Testes de software envolvem executar uma implementao do software com dados
de teste. Voc examina as sadas do software e seu comportamento operacional
para verificar se seu desempenho est conforme necessrio. O teste uma tcnica
de V & V dinmica.
Segundo Maldonado, Delamaro e Jino (2007), tcnicas dinmicas so aquelas que
se baseiam na execuo de um programa ou de um modelo.
Tcnicas de inspeo incluem inspees de programa, anlise de cdigo-fonte automatizada e verificao formal. Entretanto, segundo Sommerville (2007), as tcnicas estticas
podem somente verificar a correspondncia entre um programa e sua especificao, isto
indica que elas no podem demonstrar que o software til operacionalmente. Voc tambm no pode utiliz-las para a verificao de propriedades emergentes do software como
desempenho e confiabilidade.
Segundo Sommerville (2007), mesmo que as inspees de software sejam, atualmente,
usadas amplamente, o teste de programa ser sempre a tcnica principal de verificao e
validao de software.
1.1.1
Depurao
Os processos de V & V e de depurao (debugging, em ingls) normalmente so intercalados. Segundo Sommerville (2007), medida que se descobrem defeitos no programa que
est sendo testado, voc deve alterar seu programa para corrigir esses defeitos. Entretanto,
V & V e depurao tm finalidades diferentes:
Processos de V & V so dedicados a estabelecer a existncia de defeitos em um
sistema de software.
Depurao um processo, como pode ser visto na Figura 1.1, que localiza e corrige
esses defeitos.
15
Figura 1.1: Processo de depurao

Fonte: SOMMERVILLE, 2007, p. 343.
Localizar defeitos no sempre um processo simples, j que o defeito pode no estar
perto do ponto em que o programa falhou. Atualmente, as ferramentas de depurao
coletam informaes sobre a execuo do programa o que pode ajudar a localizar a origem
de um problema.
Segundo Sommerville (2007), aps um defeito ter sido descoberto, voc precisa corrigilo e revalidar o sistema. Isso pode envolver uma nova inspeo do programa ou um teste de
regresso nos quais os testes existentes so executados novamente. O teste de regresso
usado para verificar se as mudanas feitas em um programa no introduziram novos
defeitos. Estudos tm mostrado que um alto ndice de reparos de defeitos incompleto
ou introduz novos defeitos no programa.
1.2
Inspees de software
Segundo Sommerville (2007), inspees de software um processo de V & V esttico,

no qual um sistema de software revisto para se encontrar erros, omisses e anomalias.
Geralmente estas inspees enfocam o cdigo-fonte, mas qualquer representao legvel
do software, como seus requisitos ou um modelo de projeto, pode ser inspecionado. Em
algumas linguagens, a inspeo pode ocorrer de algum modo sobre o cdigo objeto, no
caso da linguagem de programao Java, sobre o bytecode.
Segundo Sommerville (2007), existem trs principais vantagens da inspeo sobre o
teste:
Durante os testes, erros podem mascarar (ocultar) outros erros. Uma vez que um
erro descoberto, voc nunca pode ter certeza se outras anomalias de sada so
devidas a um novo erro ou se so efeitos colaterais do erro original. Pelo fato de
a inspeo ser um processo esttico, voc no precisa se preocupar com interaes
entre os erros. Conseqentemente, uma nica sesso de inspeo pode descobrir
muitos erros de um sistema.
16
Verses incompletas de um sistema podem ser inspecionadas sem custos adicionais.

Se um programa est incompleto, voc precisa desenvolver conjuntos de testes especializados para as partes disponveis. Isso, obviamente, acrescenta custos adicionais
ao sistema.
Assim como procurar defeitos de programas, uma inspeo pode tambm considerar atributos de qualidade mais amplos de um programa como conformidade com
padres, portabilidade e facilidade de manuteno. Voc pode procurar ineficincias, algoritmos inapropriados e estilo de programao "pobre" que poderiam tornar
difceis a manuteno e a atualizao de um sistema.
Inspees so uma idia antiga. Tem havido vrios estudos e experimentos que tm demostrado que as inspees so mais eficientes para
descobrir defeitos do que teste de programas. [...] Eles constataram
que a reviso esttica de cdigo era mais eficiente e menos dispendiosa
do que teste de defeitos no descobrimento de defeitos de programas.
(SOMMERVILLE, 2007, p. 345)
O teste de defeitos abordado com detalhes na Seo 1.3, mas o teste destinado a
revelar defeitos no sistema ao invs de simular o seu uso operacional.
Engenheiros de software, algumas vezes, relutam em aceitar que as inspees podem
ser mais eficientes para detectar defeitos do que os testes. Estudos de Gilb e Graham
(1993, apud SOMMERVILLE, 2007) revelam a existncia de organizaes que abandonaram
o teste de componente em favor de inspees. Eles constataram que as inspees de
programa so mais eficientes para encontrar erros e que os custos de teste de componente
no so justificveis. Essas organizaes constataram que as inspees de componentes,
combinadas com teste de sistema, eram a estratgia de V & V de custo mais adequado.
A inspeo revela erros individuais que so, inevitavelmente, revelados para toda a
equipe de programao. Cabe aos lderes da equipe de inspeo serem treinados para
gerenciar o processo cuidadosamente a fim de obter o apoio da equipe e evitar qualquer
recriminao quando erros so descobertos.
Inspees so uma forma de anlise esttica na qual voc examina o programa sem
execut-lo. Geralmente so dirigidas por checklists de erros e heursticas que identificam
erros comuns em diferentes linguagens de programao. Para alguns erros e heursticas,
possvel automatizar o processo de verificao de programas em relao a esta lista, o
que resultou no desenvolvimento de analisadores estticos automatizados para diferentes
linguagens de programao os quais so abordados em detalhes no Captulo 2.
Alm da inspeo de programa e da anlise de cdigo-fonte automatizada, a verificao
formal pode ser vista como a ltima tcnica esttica de inspeo a qual ser abordada na
subseo seguinte.
1.2.1
17
Verificao formal
Verificao formal o ato de validar ou invalidar a correo dos algoritmos subjacentes

a um sistema com relao a uma certa propriedade ou especificao formal, utilizando
mtodos formais da matemtica segundo Wikipedia (2008c).
Mtodos formais de desenvolvimento de software so baseados em representaes
matemticas de software, geralmente como uma especificao formal. "Esses mtodos
formais esto principalmente relacionados a uma anlise matemtica da especificao;
com uma transformao da especificao para uma representao equivalente ou a uma
verificao formal de que uma representao do sistema semanticamente equivalente a
uma outra representao". (SOMMERVILLE, 2007, p. 350)
O processo de verificao formal exige anlises muito detalhadas da especificao de
um sistema o que consome tempo e custo. Em decorrncia disto seu uso est, na maioria
das vezes, restrito aos processos de desenvolvimento de software com segurana e proteo
crticas.
O mtodos formais, segundo Sommerville (2007), podem ser usados em diferentes
estgios no processo de V & V:
Uma especificao formal de sistema pode ser desenvolvida e analisada matematicamente para verificar inconsistncias. Esta tcnica eficiente para descobrir erros
de especificao, omisses e inconsistncias.
Voc pode verificar formalmente, por meio de argumentos matemticos, se o cdigo
de um software est consistente com sua especificao. Isto requer uma especificao
formal e eficiente para descobrir erros de programao e de projeto.
A verificao de um sistema de software no trivial demanda grande
quantidade de tempo e requer ferramentas especializadas, como
provadores de teorema e habilidades matemticas. , portanto, um processo extremamente dispendioso e, medida que o tamanho do sistema
aumenta, os custos de verificao formal aumentam desproporcionalmente. Muitas pessoas, portanto, constatam que a verificao formal
no apresentam custos adequados. O mesmo nvel de confiabilidade no
sistema pode ser alcanado de maneira menos dispendiosa por meio do
uso de outras tcnicas de validao, como inspees e teste de sistema.
(SOMMERVILLE, 2007, p. 351, grifo nosso)
Algumas vezes se afirma que o uso de mtodos formais para desenvolvimento de sistema
conduz a sistemas mais confiveis e mais seguros, porm, segundo Sommerville (2007), a
especificao e a prova formal no garantem que o software ser confivel no uso prtico.
As razes para isto so:
A especificao pode no refletir os requisitos reais dos usurios do sistema.
18
A prova pode conter erros. As provas so amplas e complexas, o que as torna

susceptveis erros.
A prova pode assumir um padro de erro incorreto. Se o sistema no usado
conforme previsto, a prova pode ser invlida.
Mesmo com suas desvantagens, a verificao formal tem um papel importante a desempenhar no desenvolvimento de sistemas de software crticos, pois leva a um maior
entendimento do sistema e aumenta a confiabilidade da maioria dos componentes crticos
destes sistemas.
1.3
Testes de software
Testar envolve exercitar o programa usando dados reais a serem processados pelo programa. Descobre-se defeitos ou inadequaes por meio do exame das sadas do programa
e ao observar anomalias. Segundo Sommerville (2007), existem dois tipos distintos de
teste que podem ser usados em estgios diferentes no processo de software:
Teste de validao tem a finalidade de mostrar que o software o que o cliente
deseja, ou seja, se ele atende aos seus requisitos. Como parte do teste de validao,
voc pode usar testes estatsticos para testar o desempenho e a confiabilidade do
programa e para verificar como ele funciona sob condies operacionais.
Para software sob encomenda, isto significa que deve haver pelo menos um teste para
cada requisito contido nos documentos de usurio e de sistema. Para produtos de
software genricos, isto significa que deve haver testes para todas as caractersticas
de um sistema que sero incorporadas ao release do produto. Alguns sistemas
podem ter uma fase explcita de aceitao, na qual o cliente verifica formalmente
que o sistema entregue est em conformidade com sua especificao.
Teste de defeitos destinado a revelar defeitos no sistema ao invs de simular o seu
uso operacional. O objetivo do teste de defeitos encontrar inconsistncias entre
um programa e sua especificao. Ele est est relacionado remoo de todos
os tipos de comportamentos indesejveis, como travamentos, interaes indesejveis
com outros sistemas, clculos incorretos e corrompimento de dados.
A primeira meta conduz ao teste de validao, no qual voc espera que o
sistema seja executado corretamente em um dado conjunto de casos de
teste que refletem o uso esperado do sistema. A segunda meta conduz
ao teste de defeitos, no qual so projetados casos de teste para expor
defeitos. [...] Para o teste de validao, um teste bem-sucedido aquele
em que o sistema funciona corretamente. Para o teste de defeitos, um
teste bem-sucedido o que expe um defeito que causa o funcionamento
incorreto do sistema. (SOMMERVILLE, 2007, p. 356)
19
Sabendo que o teste de software uma das abordagens do processo de V & V, o teste
de defeitos voltado verificao, enquanto que o teste de validao, como o prprio
nome diz, voltado validao.
O teste uma fase dispendiosa e trabalhosa no processo de V & V. Sendo assim,
existem ferramentas de teste que oferecem uma variedade de recursos e seu uso pode
reduzir significativamente os custos de testes. O JUnit um arcabouo (framework, em
ingls) de testes utilizado para testes de regresso, conforme pode ser visto em JUNIT
(2008). Ele um conjunto de classes em Java que o desenvolvedor estende para criar um
ambiente de testes automatizados.
Pode-se entender que o propsito dos testes, segundo Maldonado, Delamaro e Jino
(2007), executar o programa ou modelo utilizando algumas entradas em particular e
verificar se seu comportamento est de acordo com o esperado. Sommerville (2007) complementa dizendo que a sua meta, portanto, convencer os desenvolvedores e clientes
do sistema de que o software bom o suficiente para o uso operacional. O teste um
processo voltado a atingir a confiabilidade do software.
Os testes no podem demostrar que um software livre de defeitos ou que ele se comportar conforme especificado em todas as circustncias. sempre possvel que um teste
ignorado, ou melhor, um teste no realizado estivesse apto a descobrir mais problemas
no sistema. Segundo Dijkstra et al. (1972, apud SOMMERVILLE, 2007), "os testes podem
somente mostrar a presena de erros, no sua ausncia."
1.4
Consideraes finais
Verificao e validao no so a mesma coisa. Verificao se destina a mostrar que o

projeto do software atende a sua especificao, enquanto que a validao se destina a
mostrar que o software realiza exatamente o que o usurio espera que ele faa.
Inspeo de programa, anlise automatizada e verificao formal so tcnicas de V & V
estticas.
A inspeo de programa, geralmente dirigidas por checklist, tem o objetivo de localizar
defeitos e so eficientes para isto. To eficientes que a anlise automatizada surgiu da
possibilidade de automatizar o processo de verificao em relao a certos itens do checklists. Atualmente, a inspeo um mtodo de verificao de programa amplamente usado,
especialmente em engenharia de sistemas crticos.
A verificao formal tem vrias desvantagens, porm tem um papel importante no
desenvolvimento de sistemas crticos, pois ela aumenta a confiabilidade dos componentes
crticos destes sistemas. Tanto importante que o seu uso foi considerado obrigatrio nos
padres de defesa do Reino Unido (UK) para sistemas de segurana crtica.
Embora as inspees de cdigo sejam amplamente utilizadas, o teste de programa, que
uma tcnica dinmica, ser sempre a principal tcnica de V & V. O teste se resume ao
20
ato de exercitar o programa usando dados como dados reais para serem processados pelo
programa e descobre defeitos ou inadequaes por meio do exame das sadas do programa
e ao observar anomalias.
Existem dois tipos de testes: o teste de defeitos que tem a finalidade de encontrar
inconsistncias entre um programa e sua especificao, isto , revelar defeitos e o teste
de validao que tem a finalidade de mostrar que o software o que o cliente deseja.
Contudo, o teste pode mostrar a presena de erros, mas no demonstrar que no existam
erros remanescentes.
Inspees e testes tm, cada um, vantagens e desvantagens que devem ser utilizadas em
conjunto no processo de V & V. Segundo Sommerville (2007), pode-se comear o processo
de V & V do sistema com inspees no incio do projeto de desenvolvimento, mas, uma
vez que um sistema esteja integrado, preciso test-lo para verificar as propriedades
emergentes e se a funcionalidade do sistema a que seu proprietrio realmente deseja.
No h dvida de que as inspees incorrem no incio os custos de V & V
do software e resultam em economias de custo somente depois que as
equipes de desenvolvimento se tornam experientes em seu uso. Alm
disso, h os problemas prticos relacionados organizao de inspees:
inspees levam tempo para serem organizadas e parecem diminuir a velocidade do processo de desenvolvimento. muito difcil convencer um
gerente extremamente pressionado de que esse tempo pode ser recuperado mais tarde pelo fato de que menos tempo ser gasto no debugging
do programa. (SOMMERVILLE, 2007, p. 346, grifo nosso)
Os custos de teste variam muito e dependem do nmero de defeitos no programa.

Contudo, o esforo exigido pela inspeo do programa provavelmente menos da metade
do esforo que seria necessrio para o teste de defeitos equivalentes.
2 Anlise Esttica de Cdigo

Anlise Esttica de Cdigo a anlise de um sistema de computador que realizada
sem a execuo dos programas daquele sistema. Como j visto, a anlise realizada com a
execuo dos programas conhecida como anlise dinmica.
Popularmente, o termo Anlise Esttica de Cdigo se refere a anlise automatizada,
que uma das tcnicas estticas de inspeo de software no processo de V & V. O termo
verificador esttico de cdigo ou analisador esttico de cdigo " usualmente aplicado
verificao realizada por uma ferramenta automatizada seguida de uma anlise humana conhecida como compreenso ou entendimento do programa." (WIKIPEDIA, 2008e,
traduo nossa)
Analisadores estticos so ferramentas de software que varrem o textofonte de um programa e detectam possveis defeitos e anomalias.
Eles analisam o texto de programa e, assim, reconhecem os tipos de
declaraes no programa. Podem portanto detectar se as declaraes
esto bem formuladas, fazer inferncias sobre o fluxo de controle do programa e, em muitos casos, computam o conjunto de todos os valores possveis para os dados de programa. Eles complementam os recursos de deteco de erros providos pelo compilador da linguagem. (SOMMERVILLE,
2007, p. 348, grifo nosso)
Sommerville (2007) diz que analisadores estticos so ferramentas de software que

varrem o texto-fonte, entretanto os verificadores estticos de cdigo podem trabalhar
diretamente sobre o cdigo-fonte do programa, assim como podem trabalhar de alguma
forma sobre o cdigo objeto, no caso da linguagem Java, sobre o bytecode.
Cada verso tem suas prprias vantagens. Quando voc trabalha diretamente sobre o fonte do programa, suas verificaes refletem exatamente
o cdigo escrito pelo programador. Compiladores otimizam o cdigo e
o bytecode resultante pode no refletir o fonte. Por outro lado, trabalhar em bytecode consideravelmente mais rpido, o que importante
em projetos contendo mais de algumas dezenas de milhares de linhas de
cdigo. (LOURIDAS, 2006, p. 60, traduo e grifo nosso)
A inteno da anlise esttica automatizada chamar a ateno para anomalias do

programa, como variveis usadas sem serem iniciadas, variveis no usadas ou dados cujos
valores poderiam ficar fora de seus limites. Segundo Sommerville (2007), as anomalias
so freqentemente um resultado de erros de programao ou omisses, de modo que eles
21
2. Anlise Esttica de Cdigo
22
enfatizam coisas que poderiam sair erradas quando o programa fosse executado. Contudo,
estas anomalias no so, necessariamente, defeitos de programa.
Analisadores estticos so particularmente valiosos quando uma linguagem de programao, como C, for usada. A linguagem C no possui
regras de tipagem estritas e a verificao que o compilador C pode executar limitada. Portanto, fcil para programadores cometerem erros e
a ferramenta de anlise esttica pode descobrir automaticamente alguns
dos defeitos de programas resultantes. Isso particularmente importante
quando C (e, em menor extenso C++) for usada para o desenvolvimento
de sistemas crticos. Neste caso, a anlise esttica pode descobrir um
grande nmero de erros potenciais e reduzir significativamente os custos
de teste. (SOMMERVILLE, 2007, p. 349)
No h dvida de que, para uma linguagem como C, a anlise esttica uma tcnica
eficiente para descobrir erros de programa, uma vez que compensa as fraquezas no projeto
da linguagem de programao. Porm, projetistas de linguagens de programao modernas, como Java, tm removido vrias caractersticas propensas a erro, tais como: variveis
no inicializadas, uso de instrues goto e instrues de gerenciamento de memria. Essa
abordagem de preveno de erros em vez de deteco de erros mais eficiente no aprimoramento da confiabilidade de programa.
Jelliffe (2004) destacou quatro benefcios da utilizao de analisadores estticos:
Encontra erros e cdigos de risco;
Fornece um retorno objetivo aos programadores para ajud-los a reconhecer onde
eles foram precisos ou desatentos;
Fornece a um lder de projeto uma oportunidade para estudar o cdigo, o projeto e
a equipe de uma perspectiva diferente;
Retira certas classes de defeitos, o que possibilita que a equipe concentre-se mais
nas deficincias do projeto.
Na seo seguinte ser abordada uma categorizao de defeitos que ser largamente
referenciada no decorrer do estudo e, nas sees conseguintes, sero abordadas as linhas
de atuao dos verificadores estticos de cdigo e um comparativo entre a anlise automatizada de cdigo com outras tcnicas de V & V largamente utilizadas.
2.1
Categorizao dos defeitos
Em uma publicao recente, Wagner et al. (2005) realizou uma categorizao de defeitos
baseando-se em suas severidades. Porm, esta categorizao baseada nos efeitos dos
defeitos, e no nas causas ou nos tipos da ocorrncia no cdigo. As categorias so:
23
1. Defeitos que ocasionam uma pane da aplicao. Esta categoria engloba os mais
severos defeitos que param toda a aplicao pela reao de alguma entrada do
usurio.
2. Defeitos que causam uma falha lgica. Esta categoria engloba todos os defeitos
que causem uma falha lgica da aplicao, porm no ocasionam uma pane, por
exemplo, um valor resultante errado.
3. Defeitos com tratamento de erro insuficiente. Esta categoria engloba os pequenos
defeitos que no ocasionam uma pane da aplicao nem resultam em falhas lgicas,
mas que no possuem um tratamento apropriado.
4. Defeitos que violam os princpios da programao estruturada. Esta categoria engloba os defeitos que normalmente no impactam o software, mas podem ocasionar
problemas de performance, segurana, entre outros.
5. Defeitos que diminuem a manutenibilidade do cdigo. Esta categoria engloba todos
os defeitos que somente afetam a legibilidade ou a mutabilidade do software.
Claramente, pode-se constatar que os defeitos na categoria 1 possuem maior severidade
e os da categoria 5 possuem menor severidade.
Esta categorizao importante para o estudo, pois servir como referncia para a
abordagem das linhas de atuao e para o comparativo com outras tcnicas de V & V.
2.2
Linhas de atuao
Os verificadores estticos de cdigo, que so ferramentas automticas para a verificao

de cdigo, podem verificar estilos de programao, erros ou ambos.
Um verificador de erro utiliza a anlise esttica para encontrar cdigo
que viola uma propriedade de correo especfica e que pode causar um
comportamento anormal do programa em tempo de execuo. Um verificador de estilo examina cdigo para determinar se ele contm violaes
de regras de estilo de cdigo particulares. (HOVEMEYER; PUGH, 2004, p.
93, traduo nossa)
2.2.1
Verificadores de estilo
Segundo Wikipedia (2008f), um verificador de estilo (style checker, em ingls) um programa de computador que prova a conformao de um cdigo-fonte a sua definio de
estilo de programao. Verificadores de estilo atuais no verificam apenas o formato
do cdigo-fonte e a existncia de smbolos da estrutura sinttica, mas tambm podem,
mesmo que apenas de forma muito limitada, realizar anlise semntica do cdigo fonte e
24
at mesmo refatorar o cdigo. Ao contrrio de um programa Beautifier 1 , um verificador

de estilo realiza apenas uma validao do contedo, no alterando a formatao original
do documento.
Algumas regras de estilo, tais como "sempre colocar constantes no lado
esquerdo de comparaes" e "no utilizar instrues de atribuio na
condio de instrues if ", podem ajudar a prevenir certos tipos de
erros. Entretanto, violaes destas orientaes de estilo no so particularmente susceptveis de serem erros. (HOVEMEYER; PUGH, 2004, p. 93,
traduo e grifo nosso)
Para deixar mais claro o papel de um verificador de estilo, a Tabela 2.1 cita algumas
das principais regras de estilo as quais sero detalhadas e exemplificadas na seo 3.4.1
do prximo captulo.
Baseando-se na classificao das regras de estilo da Tabela 2.1, pode-se afirmar que
um verificador de estilo engloba os defeitos da categoria Tratamento de erro insuficiente
(categoria 3) e da categoria Manutenibilidade do cdigo (categoria 5).
Conclui-se que um verificador de estilo uma ferramenta de anlise esttica que verifica
se um determinado cdigo-fonte est de acordo com as orientaes de estilo previamente
declaradas.
2.2.2
Verificadores de erro
Ao contrrio de um verificador de estilo, verificador de erro (bug checker, em ingls)

uma ferramenta voltada para a deteco automtica de erros que desenvolvida, segundo
Louridas (2006), tomando como base as tendncias comuns dos desenvolvedores em atrair
defeitos que, em sua maioria, no so visveis aos compiladores.
Ferramentas de verificao de erro so uma classe de programas que
visam detectar defeitos no cdigo por uma anlise esttica similar a
de um compilador. Os resultados de tal ferramenta so, contudo, nem
sempre defeitos reais, mas podem ser vistos como um alerta de que um
pedao de cdigo crtico de alguma forma. (WAGNER et al., 2005, p.
42, traduo nossa)
Para deixar mais claro o papel de um verificador de erro, a Tabela 2.2 cita alguns dos
principais erros que sero detalhados e exemplificados na seo 3.4.2 do prximo captulo.
Baseando-se na classificao dos erros da Tabela 2.2, pode-se afirmar que um verificador de erro engloba os defeitos de todas as categorias, contudo a categoria Princpios da
programao estruturada (categoria 4) possui um maior destaque com relao s demais.
Hovemeyer e Pugh (2004) oferecem algumas observaes em porqu os erros ocorrem
e em que um verificador de erro poderia auxili-lo:
1
Um programa Beautifier, traduzido por Formatador de Cdigo Fonte, "diz respeito a um sistema
que, a partir do cdigo-fonte de um programa de computador, gera o cdigo formatado seguindo certas
regras, sem ocorrer alterao da semntica do programa." (WIKIPEDIA, 2008d, traduo nossa)
25
Tabela 2.1: Alguns exemplos de regras de estilo

Nome
Categoria
Descrio
Bloco catch vazio
Verifica a presena de blocos catch sem nenhuma

instruo.
Atribuio em subexpresses
Verifica a presena de atribuies em subexpresses.
Comparao
constante
Verifica a presena de comparaes com constante

na qual esta no se encontra no lado esquerdo da
comparao.
Instruo vazia
Verifica a presena de instrues vazias, isto , apenas o ponto-e-vrgula (;).
Ordem de declarao
Verifica a presena de desordem na declarao das

partes de classes ou interfaces de acordo com as
convenes de cdigo para a linguagem Java.
Padro de nomenclatura
Verifica a presena de nomes de atributos, mtodos

e classes que estejam fora das convenes de cdigo
para a linguagem Java.
Posio da clusula
default em instrues
switch
Verifica a presena de instrues switch na qual a

clusula default no vem aps todas as clasulas
case.
Uso da referncia this
Verifica a presena de acesso a algum atributo ou

invocao de algum mtodo da prpria classe sem
a utilizao da referncia this.
Uso de chaves
Verifica a presena de algum bloco condicional ou

de repetio sem chaves de abertura e fechamento.
Fonte: Arquivo pessoal.
com
Todos cometem erros tolos. Nem mesmos os melhores programadores so perfeitos

100% do tempo. Um verificador de erro capaz de encontrar erros que um compilador ignora.
Linguagens oferecem oportunidades para erros latentes. So erros que no afetam a
correo de um programa at que um tipo particular de comportamento em tempo
de execuo ocorra. Um verificador de erro pode aumentar a visibilidade de alguns
desses erros latentes.
Programao com segmentos (threads, em ingls) mais difcil dos que as pessoas
pensam. Um verificador de erro pode ajudar a prevenir erros de concorrncia antes
que eles, efetivamente, ocorram.
26
Tabela 2.2: Alguns exemplos de erros

Nome
Categoria
Descrio
Conexo com banco

de dados no encerrada
Verifica a presena de abertura de conexo ao

banco de dados sem posterior fechamento.
Valor de retorno ignorado
Verifica a presena de algum retorno de funo que

foi ignorado.
Perda de referncia
nula (null dereference,
em ingls)
Verifica a presena de acesso a um atributo ou

chamada a um mtodo a partir de uma referncia
que ainda est nula, o que ocasiona uma exceo
que no ser tratada.
Concatenao
de
strings em laos de
repetio
Verifica a presena de concatenao de strings utilizando o operador + em laos de repetio.
Fluxo (stream, em ingls) no encerrado
Verifica a presena de abertura de fluxos sem posterior fechamento.
No utilizao de
operador booleano de
curto-circuito
Verifica a presena de possibilidade de lanamento

de exceo na utilizao de operadores booleanos
que no so de curto-circuito, mas que deveriam
ser.
Objetos iguais tm o
mesmo cdigo de disperso (hashcode, em
ingls)
Verifica a presena de objetos que redefinem o

mtodo equals, mas no redefinem o mtodo
hashcode ou o inverso.
Utilizao de == ao
invs de equals
Verifica a presena de comparaes de objetos

utilizando o operador == ao invs do mtodo
equals.
Comparao com nulo

redundante
Verifica a presena de comparao com nulo que

est redundante.
2.2.3
Diferenas
Existem ferramentas conhecidas como verificadores de estilo que tm como objetivo verificar a conformao do sistema s regras de estilo de programao que foram previamente
declaradas. Estas ferramentas claramente melhoram a qualidade do cdigo por seguirem
diversos padres e diretivas, porm no so focadas verificao de erro.
Como possvel complemento a uma ferramenta verificadora de estilo, existem os verificadores de erro que automaticamente encontram erros. Estes erros geralmente eram, e
27
ainda so, descobertos atravs de inspeo de cdigo, mas possuem um certo padro de
reconhecimento que o habilita a ser computvel.
Uma outra maneira de pensar sobre a distino entre um verificador de
estilo e um verificador de erro que violaes em orientaes de estilo
somente causam problemas para os desenvolvedores que trabalham no
sistema. Advertncias produzidas por um verificador de erro podem
representar erros que causaro problemas para os usurios do sistema.
(HOVEMEYER; PUGH, 2004, p. 93, traduo nossa)
Portanto, no existem impedimentos de se utilizar, em um mesmo projeto, uma ferramenta de verificao de erro em conjunto com uma ferramenta de verificao de estilo.
Tanto possvel, que existe ferramenta de integrao de verificadores estticos de cdigo
que ser abordada com detalhes na seo 3.5 do prximo captulo.
2.2.4
Aplicaes
Verificadores de estilo so largamente utilizados. Entretanto verificadores de erro no so

to amplamente utilizados, mesmo sendo mais propensos a direcionar os desenvolvedores
a especificar erros reais no cdigo.
Ns acreditamos que a razo para esta disparidade que mais trabalho
necessrio para utilizar o resultado de verificadores de erro. Verificadores
de estilo podem ser extremamente rigorosos em determinar se o cdigo
adere ou no a um determinado conjunto de regras de estilo. Assim,
pouco ou nenhum julgamento necessrio para interpretar o seu resultado e alterando o cdigo para aderir as orientaes de estilo tem um
efeito concreto sobre a melhoria do entendimento do cdigo. Em contrapartida, verificadores de erro [...] podem produzir advertncias que
so imprecisas ou difceis de interpretar. Alm do mais, corrigir erros relatados por um verificador de erro requer julgamento a fim de entender a
causa do erro e para corrig-lo sem introduzir novos erros. (HOVEMEYER;
PUGH, 2004, p. 93, traduo nossa)
Segundo Sommerville (2007), os analisadores estticos no so amplamente utilizados,

pois ainda no est claro se o nmero de erros justifica o tempo necessrio para analisar
as sadas. Em uma publicao mais recente Ayewah et al. (2007) contradiz Hovemeyer e
Pugh (2004) e Sommerville (2007) no momento em que diz que as ferramentas de anlise
esttica para deteco de erros em software esto tornando-se largamente utilizadas na
prtica. Contudo, ressalta que existe pouca informao experimental disponvel no que se
refere avaliao da preciso e do valor das advertncias dos relatrios gerados por estas
ferramentas.
Segundo Wikipedia (2008e), um crescimento comercial do uso de anlise esttica se
encontra na verificao de propriedades de software usados em sistemas computadores de
segurana crtica e na localizao de potenciais cdigos vulnerveis.
2.3
28
Comparativo com outras tcnicas de V & V
Muitas pesquisas tm sido realizadas na procura de defeitos em cdigo utilizando anlise

esttica automatizada, porm poucos estudos tm sido realizados sobre o comparativo
destes verificadores de erro com outras tcnicas estabilizadas de deteco de defeitos, tais
como inspeo de cdigo ou teste de software.
As subsees seguintes iro fazer um breve comparativo da anlise esttica automatizada com inspeo de cdigo e teste de software, tomando como base um estudo realizado
por Wagner et al. (2005) que aplicou cada uma destas tcnicas a cinco sistemas de software. Algumas consideraes de Sommerville (2007) tambm foram utilizadas.
2.3.1
Inspeo de cdigo
A tcnica de inspeo de cdigo uma das tcnicas de inspees de software, assim como
a anlise esttica automatizada. Porm, segundo Sommerville (2007), a anlise esttica
automatizada pode ser usada como parte do processo de inspeo ou como uma atividade
separada do processo de V & V.
O estudo de Wagner et al. (2005) constatou que a inspeo de cdigo (ou reviso de
cdigo) encontrou todos os tipos de defeitos encontrados por um verificador de erro, porm
houve uma dissiparidade no nmero de erros encontrados em alguns tipos de defeitos.
O motivo dessa dissiparidade pode ser facilmente explicado tomando como exemplo
dois tipos de erros bem simples: "variveis inicializadas, mas no utilizadas" e "clasula
if no necessria". Um erro do tipo "variveis inicializadas, mas no utilizadas" um
problema facilmente computvel, isto indica que um verificador de erro bem mais eficaz
bastando apenas possuir uma rotina que verifica se todas as variveis inicializadas foram
utilizadas. Em contrapartida, um erro do tipo "clasula if no necessria" um problema
resolvido a partir do entendimento da lgica de um programa o que o torna mais propcio
de ser encontrado por um processo de inspeo de cdigo.
Outros defeitos como falhas lgicas ou resultados invlidos de uma funo
no podem ser detectados por ferramentas de verificao de erro. Estes
defeitos podem ser encontrados durante uma reviso que acompanhe os
casos de teste atravs do cdigo. (WAGNER et al., 2005, p. 49, traduo
nossa)
Em sntese, a inspeo de cdigo mostrou-se mais bem-sucedida do que as ferramentas

de verificao de erro, pois ela capaz de detectar muito mais tipos de defeitos. "Entretanto, parece ser benfico primeiramente utilizar de uma ferramenta de verificao de erro
antes de inspecionar o cdigo, o que faz com que os defeitos que so encontrados por ambos j estejam removidos. Isso acontece porque a automao os faz de forma mais barata
e mais minuciosa do que uma reviso manual." (WAGNER et al., 2005, p. 49, traduo
nossa)
2.3.2
29
Teste de software
O teste de software uma tcnica dinmica, o que j faz com que se espere que os erros
encontrados sejam diferente daqueles encontrados por tcnicas estticas.
O estudo de Wagner et al. (2005) constatou que os defeitos encontrados por teste
de software esto nas categorias Pane da aplicao (categoria 1), Falha lgica (categoria
2) e Tratamento de erro insuficiente (categoria 3). As ferramentas de anlise esttica
automatizada, tanto verificadores de estilo quanto verificadores de erro, encontram predominantemente defeitos nas categorias Princpios da programao estruturada (categoria
4) e Manutenibilidade do cdigo (categoria 5). Logo, tcnicas dinmicas encontram defeitos completamente diferentes.
Para os sistemas de software para o qual foram revelados defeitos, no
houve um mesmo defeito que tenha sido encontrado com testes e com
ferramentas de verificao de erro. Alm disso, as ferramentas revelaram
vrios defeitos nos sistemas para os quais os testes no foram capazes de
encontrar. Estes so defeitos que somente podem ser encontrados por
testes extensos de estresse, tal como uma conexo ao banco de dados
no encerrada. Isto somente pode resultar em problema de performance
ou mesmo em uma falha da aplicao; se o sistema est em uma alta
taxa de utilizao e h uma enorme quantidade de conexes ao banco de
dados que no esto encerradas. A maioria dos defeitos, entretanto, esto
realmente relacionados a manutenibilidade e so conseqentemente no
detectveis por testes dinmicos. (WAGNER et al., 2005, p. 51, traduo
e grifo nosso)
Em sntese, os testes de software e as ferramentas de verificao de erro detectam

defeitos diferentes. Testes de software so eficazes em encontrar defeitos lgicos que so
melhor visualizados quando o software est em execuo, enquanto que as ferramentas de
anlise esttica automatizada so eficazes em encontrar defeitos relacionados aos princpios de programao estruturada e manutenibilidade. Portanto, para um bom projeto
seria altamente recomendvel a utilizao de ambas as tcnicas.
2.4
Consideraes finais
Anlise Esttica de Cdigo se refere a anlise automatizada, que uma das tcnicas
estticas de inspeo de software no processo de V & V. O termo verificao esttica de
cdigo ou anlise esttica de cdigo " usualmente aplicado verificao realizada por uma
ferramenta automatizada seguida de uma anlise humana conhecida como compreenso
ou entendimento do programa."(WIKIPEDIA, 2008e, traduo nossa)
Segundo Rutar, Almazan e Foster (2004), muitas tcnicas e ferramentas tm sido desenvolvidas para automaticamente encontrar defeitos analisando estaticamente o cdigofonte ou cdigo intermedirio que, no caso da linguagem Java, seria o bytecode. Cada
verso tem suas prprias vantagens.
30
Wagner et al. (2005) classificou os defeitos, baseados em seus efeitos, em cinco categorias:
1. Pane da aplicao
2. Falha lgica
3. Tratamento de erro insuficiente
4. Princpios da programao estruturada
5. Manutenibilidade do cdigo
Os verificadores estticos de cdigo, que so ferramentas automticas para a verificao
de cdigo, podem verificar estilos de programao, erros ou ambos.
Um verificador de estilo uma ferramenta de anlise esttica que verifica se um determinado cdigo-fonte est de acordo com as orientaes de estilo previamente declaradas.
Engloba os defeitos da categoria Tratamento de erro insuficiente (categoria 3) e da categoria Manutenibilidade do cdigo (categoria 5).
Um verificador de erro uma ferramenta de anlise esttica que verifica se um determinado cdigo-fonte no viola uma propriedade de correo especfica que pode causar
um comportamento anormal do programa em tempo de execuo. Engloba os defeitos de
todas as categorias, contudo a categoria Princpios da programao estruturada (categoria
4) possui um maior destaque com relao s demais. Segundo Flanagam et al. (2002) e
Louridas (2006), se o verificador de erro no est apto a encontrar mais erros potenciais,
no necessariamente o programa est sem erros, ou melhor, eliminar erros no garante a
alta qualidade do programa.
As ferramentas de anlise esttica para deteco de erros em software esto tornandose largamente utilizadas na prtica, porm ainda no est claro se o nmero de erros
justifica o tempo necessrio para anlise das sadas. Tambm no existem impedimentos
de se utilizar uma ferramenta de verificao de erro em conjunto com uma ferramenta de
verificao de estilo, ou seja, so ferramentas complementares.
A inspeo de cdigo detecta muito mais tipos de defeitos do que as ferramentas de
verificao de erro, porm, como as ferramentas de verificao de erro so mais baratas e
mais minuciosas, uma boa prtica a aplicao de uma ferramenta de verificao de erro
antes de inspecionar o cdigo. Em contrapartida, os defeitos encontrados pelos testes de
software so completamente diferentes daqueles encontrados pelas ferramentas de anlise
esttica automatizada, o que as torna tcnicas de V & V perfeitamente complementares,
em contrapartida isto faz com que no seja possvel reduzir os custos com esforos em
testes.
31
H muitos possveis caminhos para encontrar erros em software. Inspees de cdigo podem ser muito eficazes em encontrar erros, mas possuem
a clara desvantagem de requerer esforo manual para aplic-las. Alm do
mais, observadores humanos so vulnerveis a serem influenciados pelo
o que o pedao de cdigo intencionado a fazer. Tcnicas automticas
tem a vantagem de relativa objetividade. (HOVEMEYER; PUGH, 2004, p.
92, traduo e grifo nosso)
Wagner et al. (2005) aplicou mtricas em projetos para verificar a eficincia na remoo
dos defeitos encontrados por inspeo de cdigo, anlise automatizada e teste de software.
A mtrica sugeriu que a anlise automatizada a tcnica mais eficiente e o teste de
software a menos eficiente conforme pode ser observado na Tabela 2.3, contudo " bvio
que os testes de software e as inspees de cdigo so muito mais eficientes em encontrar
defeitos nas categorias 1 e 2 do que a anlise automatizada, que so os mais severos
defeitos." (WAGNER et al., 2005, p. 51, traduo e grifo nosso)
Tabela 2.3: A eficincia de remoo de defeitos por tcnica de deteco de erro
Tcnica
Ferramentas de verificao de erro
Inspees de cdigo
Testes de software
Nmero de Defeitos
Eficincia
585
152
32
81%
21%
4%
Total sem duplicados

719
Fonte: WAGNER et al., 2005, p. 51.
100%
Projetistas de linguagens de programao modernas tm retirado vrias caractersticas

que so propensas erros. Essa abordagem de preveno de erros em vez de deteco de
erros mais eficiente no aprimoramento da confiabilidade de programa. Porm, segundo
Louridas (2006), existe uma limitao clara e consciente de que nenhum verificador de
cdigo pode nos assegurar que um programa est correto - tal garantia no possvel.
3 Ferramentas de Anlise Esttica

A idia de ferramentas de anlise esttica no nova. "Em 1970, Stephen Johnson,
naquele tempo na Bell Laboratories, escreveu Lint, uma ferramenta para examinar cdigofonte de programas C que tenham compilado sem erros e verificar erros que tenham
escapado da deteco." (LOURIDAS, 2006, p. 58, traduo e grifo nosso)
A separao de funes entre Lint e compiladores C tem tanto uma base histrica
quanto prtica. Segundo Johnson (1977), os compiladores tornavam programas C em
arquivos executveis rapidamente e eficientemente, pois os compiladores no realizam
verificao sofisticada de tipo, especialmente entre programas compilados separadamente.
Lint toma uma viso mais global e ponderada do programa, procurando mais atentamente
s compatibilidades.
Lint um comando que examina cdigo-fonte de programas C, detectando um nmero de erros e incertezas. Ele fora as regras de tipos
de C mais restritamente do que os compiladores C. Ele tambm pode ser
utilizado para forar um nmero de restries de portabilidade envolvidas na movimentao de programas entre diferentes mquinas e sistemas
operacionais. (JOHNSON, 1977, p. 1, traduo nossa)
O sucesso de Lint, segundo Louridas (2006), deu aos programadores de hoje vrias
ferramentas descendentes, tanto de cdigo aberto quanto proprietrias, que englobam
diferentes linguagens e sistemas operacionais.
Porm, segundo Sommerville (2007), a abordagem destas ferramentas em linguagens
modernas diferente. O Lint fornece verificao esttica equivalente quelas fornecidas
pelo compilador em uma linguagem forte como Java e o fato de ser utilizado para restries
de portabilidade no se faz mais necessrio devido ao uso de mquinas virtuais1 .
Nas sees seguintes sero abordadas as caractersticas e as tcnicas das ferramentas
de anlise esttica. Nas sees conseguintes, sero abordadas as principais ferramentas
para cdigo Java, uma srie de estudos de caso, os problemas encontrados e as possveis
solues.
1
"Mquina virtual uma implementao em software de uma mquina (computador) que executa
programas como uma mquina real." (WIKIPEDIA, 2008g, traduo e grifo nosso)
32
3. Ferramentas de Anlise Esttica
3.1
33
Caractersticas
Segundo Ball e Rajamani (2002), Flanagam et al. (2002), Hovemeyer e Pugh (2004) e
Louridas (2006) existem importantes atributos que uma ferramenta de anlise esttica
deve ter:
Consistente (soundness, em ingls). Todo erro real (true error, em ingls) reportado pela anlise, isto , nenhum erro real deixar de ser reportado.
Completo. (completeness, em ingls) Todo erro reportado um erro real, isto ,
nenhum erro reportado um alarme falso (false positive, em ingls).
til. (usefulness, em ingls) Se reporta erros com que algum se preocupa.
Com a exceo de ser til, Flanagam et al. (2002) no toma os atributos consistente
e completo como requisitos para uma ferramenta de anlise esttica. Afinal, as tcnicas
de V & V concorrentes, tal como inspees e testes de software, no so nem consistentes
nem completas.
Ainda assim, estes atributos so cada vez mais visados e considerados to importantes
que "a percentagem de alarme falso para cada erro real um indicador importante da
conformidade para os nossos programas - faz sentido examinar o comportamento de um
verificador em nosso trabalho antes de submet-lo a todo o projeto." (LOURIDAS, 2006,
p. 60, traduo nossa)
Uma outra caracterstica importante citada por Flanagam et al. (2002) o ponto em
que uma ferramenta de anlise esttica se encontra em duas importantes dimenses: no
grau de cobertura de erros obtido na execuo da ferramenta e no custo de se executar a
ferramenta, conforme pode ser visto na Figura 3.1.
Figura 3.1: Verificadores estticos em relao cobertura e ao esforo

Fonte: FLANAGAM et al., 2002, p. 234, traduo nossa.
Analisando a Figura 3.1, no canto superior direito encontra-se a verificao funcional
completa do programa que, teoricamente, captura todos os erros, mas extremamente
34
cara. No canto inferior esquerdo encontram-se as tcnicas de verificao esttica que so

largamente utilizadas, que requerem somente um modesto esforo, mas capturam somente
uma classe limitada de erros como a verificao de tipo, assim como o Lint faz.
Flanagam et al. (2002) diz que as duas abordagens so fascinantes para os pesquisadores,
porm sugere que o meio do diagrama promissor, que seria produzir uma ferramenta de
custo aceitvel que capturaria mais erros que um simples verificador de tipo, a um custo
muito inferior a uma verificao funcional completa do programa. Isto seria conhecido
como verificao esttica estendida.
Certamente, uma ferramenta consistente, completa e til que realizasse uma verificao funcional completa do programa seria a mais eficaz ferramenta de anlise esttica
automatizada, porm existem dificuldades claras de computao, esforo e custo para que
isto se realizasse.
3.2
Tcnicas
Conforme j abordado no Captulo 2 e reforado por SAP AG (2006), a anlise esttica

em aplicaes Java pode ser aplicada sobre o cdigo-fonte e/ou bytecode da aplicao e,
cada uma destas verses, tem suas vantagens. Um amplo analisador esttico de cdigo
deveria atuar sobre as duas verses para tirar proveito das vantagens particulares de cada
uma.
A maioria das ferramentas avaliadas utilizam a Biblioteca de Engenharia de Bytecode (BCEL) do projeto Apache Jakarta para operaes de
bytecode e tambm para a engenharia reversa de aplicaes com base no
bytecode existente. Ns gostarimos de enfatizar que BCEL no prov
um mtodo de anlise de fluxo de dados, simplesmente por ela no ter
este foco. Se uma ferramenta apta a desempenhar anlise de fluxo de
dados e usa BCEL, a prpria ferramenta prov metdos para anlise de
fluxo de dados. (SAP AG, 2006, p. 7, traduo e grifo nosso)
Geralmente, um verificador de erro utiliza tcnicas de anlise esttica para a procura

de erros baseados na noo de padres de erro, que " uma estrutura de cdigo que
susceptvel de ser um erro." (HOVEMEYER; PUGH, 2004, p. 92, traduo nossa) Ele
tambm realiza anlise de fluxo de dados tentando procurar certas entradas que podero
ocasionar erros.
Embora cada verificador de cdigo trabalhe de seu prprio modo, a maioria deles compartilham algumas caractersticas bsicas. Eles lem o
programa e constroem algum modelo dele, um tipo de representao
abstrata que eles podero utilizar para bater com os padres de erro
que eles reconhecem. Eles tambm desenvolvem algum tipo de anlise
de fluxo de dados, tentando inferir os valores possveis que as variveis
possam ter em certos pontos do programa. (LOURIDAS, 2006, p. 60,
traduo nossa)
35
Um exemplo desta representao abstrata supracitada por Louridas (2006) exemplificada por SAP AG (2006) quando diz que algumas ferramentas constroem uma rvore
de Sintaxe Abstrata, do ingls Abstract Syntax Tree (AST), a partir da leitura do cdigo
fonte e, em seguida, efetuam uma anlise individual do sistema atravs da aplicao de
algoritmos especficos.
Ainda segundo SAP AG (2006), anlise de fluxo de dados um elemento-chave para a
realizao de testes de segurana estticos para aplicaes Java. O acompanhamento do
fluxo de dados de certas variveis que poderiam ser entradas de dados de usurios permite
a deteco de certas construes de cdigo inseguro que poderiam levar a vulnerabilidades,
como injeo de SQL, entre outros.
Anlise de fluxo de dados especialmente importante para verificao
de vulnerabilidade - uma crescente importante rea para verificadores de
cdigo. Uma vez que um programa aceita uma entrada de um usurio,
existe a possibilidade (mesmo que remota) que um cracker possa utilizar
a entrada para subverter o sistema. Estouro de buffer foi a tcnica de invaso favorita para a explorao de falhas dos crackers at recentemente,
quando a injeo de SQL parece t-la ultrapassado. Em ambos os casos, ela importante para poder traar o fluxo de entrada dos usurios
atravs do programa. (LOURIDAS, 2006, p. 60, traduo e grifo nosso)
Alm das tcnicas de padres de erro e de anlise de fluxo de dados, tcnicas como
sistemas de tipo, verificao de modelo e prova de teorema tambm so utilizadas para a
busca de erros segundo Rutar, Almazan e Foster (2004).
3.3
Principais ferramentas
A Tabela 3.1 mostra um breve sumrio das principais ferramentas para cdigo Java que
foram alvo de estudos nos ltimos anos. As ferramentas destacadas em negrito sero
avaliadas em nosso estudo.
Tabela 3.1: Principais ferramentas para anlise esttica de cdigo Java
Nome
Verso
Data de liberao
Checkstyle
4.4.0
19/dez/2007
ESC/Java2
2.0.4
17/jan/2008
FindBugs
1.3.1
23/dez/2007
3.1
13/out/2006
Jlint
Stio
Licena
http://checkstyle.sourceforge.net
Livre
http://kind.ucd.ie/products/opensource/
ESCJava2
Livre
http://findbugs.cs.umd.edu
Livre
http://jlint.sourceforge.net
Livre

Klocwork
Developer
7.6.0.7
../fev/2007
36
http://www.klocwork.com/
Proprietria
products/developerJava.asp
PMD
4.1
QJ-Pro
2.2.0
17/nov/2007
http://pmd.sf.net
22/mar/2005 http://qjpro.sourceforge.net
Livre
Livre
As quatro ferramentas que sero avaliadas no estudo so brevemente descritas a seguir:

Checkstyle. Segundo CHECKSTYLE (2008), uma ferramenta que ajuda os desenvolvedores a escrever cdigo Java que adere a um padro de cdigo. Ela automatiza
o processo de verificao de cdigo Java dispensando que pessoas realizem esta chata,
mas importante, tarefa. ideal para projetos que querem forar os desenvolvedores
a seguir um estilo de programao.
, ainda, altamente configurvel e pode suportar quase qualquer padro de cdigo
que a permite verificar muitos aspectos de seu cdigo-fonte. Historicamente, esta
foi a funcionalidade principal, mas desde que arquitetura foi alterada na verso 3,
mais e mais verificadores para outros propsitos foram adicionados. Atualmente, ela
prov verificaes de problemas de projeto de classes, cdigo duplicado e padres
de erros.
Figura 3.2: Mdulo de extenso do Checkstyle para IDE Eclipse

Fonte: Arquivo pessoal
FindBugs. Segundo Louridas (2006), um popular verificador esttico de cdigo
para a linguagem Java, desenvolvida pela University of Maryland. FINDBUGS
(2008) considera a ferramenta como um patrocinador na fortificao da qualidade
do software. Atualmente, ela pode analisar programas compilados em qualquer
verso da linguagem Java.
Rutar, Almazan e Foster (2004) dizem ainda que o FindBugs reporta mais de 250
padres de erros diferentes sendo mais de uma centena deles classificados como erros
de correo. A ferramenta ainda permite que o programador defina suas prprias
regras para verificao.
37
Figura 3.3: Mdulo de extenso do FindBugs para IDE Eclipse

Klocwork Developer . Segundo KLOCWORK (2008), um pacote para desenvolvedores Java que abrange a tecnologia de anlise esttica provada e utilizada profissionalmente. Louridas (2006) complementa dizendo que a ferramenta trabalha no
bytecode para encontrar defeitos e vulnerabilidades de segurana e, no cdigo-fonte,
para executar mtricas e anlises arquiteturais sem que seja necessrio gerar ou
executar casos de teste.
Figura 3.4: Mdulo de extenso do Klocwork Developer para IDE Eclipse

PMD. Segundo PMD (2008), um analisador de cdigo Java que procura por
variveis no utilizadas, blocos catch vazios, criao desnecessria de objetos e assim
por diante. Hovemeyer e Pugh (2004) complementa dizendo que uma ferramenta
de extrema valia em forar os desenvolvedores a seguir um estilo de programao e
em tornar o cdigo mais fcil para ser entendido pelo desenvolvedores.
Assim como o Checkstyle, o PMD evoluiu e, atualmente, foram adicionados verificadores para outros propsitos. Segundo Rutar, Almazan e Foster (2004), a ferramenta
facilmente expansvel pelos programadores que podem escrever novos detectores
de padres de erro usando tanto Java quando XPath 2 .
2
XPath ou XML Path " um conjunto de regras de sintaxe (linguagem) para definir partes de um
documento XML." (GLOSSARY, 2008, traduo nossa)
38
Figura 3.5: Mdulo de extenso do PMD para IDE Eclipse

Com exceo do Klocwork Developer , todas as demais ferramentas so de cdigo
aberto. O Checkstyle e o PMD trabalham sobre o cdigo-fonte, FindBugs sobre o bytecode
e o Klocwork Developer sobre ambos o que o faz mais abrangente.
Todas as ferramentas acima possuem mdulo de extenso (plug-in, em ingls) para a
verso mais atual da IDE Eclipse conforme pode ser observado nas Figuras 3.2, 3.3, 3.4
e 3.5.
A ferramenta ESC/Java2 foi descartada da avaliao, pois necessita de anotaes em
cdigo que faz com que tenha caractersticas diferentes. Ainda foram descartadas as ferramentas Jlint e QJ-Pro, pois tiveram seu desenvolvimento interrompido como observado
em JLINT (2008) e QJ-PRO (2008).
3.4
Estudos de caso
Nas subsees 2.2.1 e 2.2.2 do Captulo 2, foram citadas, respectivamente, algumas das
principais regras de estilo e alguns dos principais erros. Esta seo tem como objetivo
fornecer uma exemplificao de cada um destes defeitos tornando-os estudos de caso para
a avaliao das ferramentas para anlise esttica de cdigo Java.
No final de cada subseo seguinte, ser exibida um tabela demonstrando a eficcia
de cada uma destas ferramentas. O smbolo indica que a ferramenta alertou sobre
o defeito, o smbolo * indica que a ferramenta alertou sobre o defeito, porm com
algumas ressalvas, e o smbolo X indica que a ferramenta no alertou sobre o defeito.
Todas as ferramentas foram configuradas para verificar praticamente todos os defeitos.
3.4.1
Regras de estilo
As subsees seguintes possuem o nome de cada regra de estilo abordada na subseo 2.2.1
do Captulo 2 e o nmero da categoria em que ela se encontra segundo a categorizao de
defeitos abordada na seo 2.1 do Captulo 2.

3.4.1.1
39
Bloco catch vazio (categoria 3)
O trecho de cdigo da Listagem 3.1 trata-se de uma leitura pela entrada padro. Na
maioria dos casos, esta leitura no gera uma exceo, porm, se ocorrer, isto dever ser
tratado.
1
byte [ ] b = new byte [ 1 2 8 ] ;
try {
System . i n . r e a d ( b ) ;
} catch ( IOException e ) {
Listagem 3.1: Exemplificao de um bloco catch vazio

Ao aplicarmos as ferramentas, pde-se constatar:
Checkstyle alertou sobre o problema e ainda complementou dizendo o que o numeral
128 um nmero mgico, isto , deveria ser uma constante.
FindBugs no alertou sobre o problema, mas indicou que o valor de retorno do
System.in.read(b), que o nmero total de bytes lidos no buffer, foi ignorado, o
que no necessariamente um erro. Se o desenvolvedor no quiser mesmo esta
informao, isto pode ser caracterizado como um alarme falso.
Klocwork Developer alertou precisamente sobre o problema.
PMD alertou sobre o problema e ainda complementou dizendo para evitar variveis
com nome curto (varivel b, no caso).
Um resultado sintetizado pode ser observado na tabela abaixo.
Tabela 3.2: Resultado sintetizado sobre a eficcia
da verificao de um bloco catch vazio
Checkstyle FindBugs Klocwork Developer PMD
X
3.4.1.2
Atribuio em subexpresses (categoria 5)
O trecho de cdigo da Listagem 3.2 trata-se de uma leitura de um arquivo binrio. Cada
byte lido atribudo varivel i e depois comparado com o numeral -1 , tudo isto dentro
da condio do bloco while.
InputStream i n = new F i l e I n p u t S t r e a m ( " a r q u i v o . b i n " ) ;
int i ;
while ( ( i = i n . r e a d ( ) ) != 1){
System . out . p r i n t l n ( i ) ;
in . close ( ) ;
40
Listagem 3.2: Exemplificao de uma atribuio em subexpresso

Checkstyle, FindBugs e Klocwork Developer no alertaram sobre o problema.
com nome curto (varivel i , no caso).
da verificao de uma atribuio em subexpresso
X
X
X
3.4.1.3
Comparao com constante (categoria 5)
O trecho de cdigo da Listagem 3.3 trata-se de uma simples comparao com constante.
Programadores experientes, quando vo comparar uma varivel com uma constante, comparam a constante com a varivel, pois assim se garante que no ocorrer uma exceo
de varivel nula.
1
private s t a t i c f i n a l S t r i n g CONSTANTE = " Java " ;
2
3
public s t a t i c boolean i s J a v a ( S t r i n g linguagem ) {

return linguagem . e q u a l s (CONSTANTE) ;
4
5
Listagem 3.3: Exemplificao de uma comparao com constante

Checkstyle no alertou sobre o problema e ainda foi equivocada em dizer que a
varivel CONSTANTE deveria utilizar a referncia this. Isto no est correto,
41
pois a varivel esttica cujo acesso se faz pela classe, e no por uma instncia
da classe o que justificaria o uso da referncia this. Isto, certamente, classificado
como um alarme falso.
FindBugs, Klocwork Developer e PMD tambm no alertaram sobre o problema.
da verificao de uma comparao com constante
X
3.4.1.4
X
X
Instruo vazia (categoria 5)
O trecho de cdigo da Listagem 3.4 trata-se de uma falha que ocorre principalmente entre
programadores inexperientes. Eles tendem a colocar um ponto-e-vrgula (;) no final do
bloco while o que no necessrio e que significa uma instruo vazia.
1
int i = 0 ;
while ( i < 1 0 ) {
System . out . p r i n t l n ( i ) ;
i ++;
};
Listagem 3.4: Exemplificao de uma instruo vazia

Checkstyle alertou sobre o problema e ainda complementou dizendo o que o numeral
10 um nmero mgico.
FindBugs e Klocwork Developer no alertaram sobre o problema.
PMD alertou precisamente sobre o problema dizendo que o ponto-e-vrgula no faz
parte do lao de repetio e ainda complementou dizendo para evitar variveis com
nome curto (varivel i , no caso).
42

da verificao de uma instruo vazia
X
X
3.4.1.5
Ordem de declarao (categoria 5)
O trecho de cdigo da Listagem 3.5 trata-se de uma classe que no segue a ordem usual
de declarao de atributos, construtores e mtodos. Isto geralmente ocorre entre programadores inexperientes.
1
public c l a s s Pessoa {
public S t r i n g getNome ( ) {
return nome ;
4
5
public Pessoa ( S t r i n g nome ) {
t h i s . nome = nome ;
8
9
private S t r i n g nome ;
10
11
Listagem 3.5: Exemplificao da ordem de declarao

Checkstyle alertou sobre o problema.
FindBugs, Klocwork Developer e PMD no alertaram sobre o problema.
da verificao da ordem de declarao
X
X
X

3.4.1.6
43
Padro de nomenclatura (categoria 5)
O trecho de cdigo da Listagem 3.6 trata-se de uma declarao de um atributo esttico

imutvel o que seria uma constante. O padro de nomenclatura seguido pela linguagem
Java estipula que as constantes devem ter seu nome em caixa alta separando cada palavra
por uma sub-linha (underscore, em ingls).
1
public s t a t i c f i n a l S t r i n g nomeBanco = "BB" ;
Listagem 3.6: Exemplificao do padro de nomenclatura

Checkstyle alertou precisamente sobre o problema e ainda indicou qual o padro que
o nome da varivel deveria estar.
da verificao do padro de nomenclatura
X
X
X
3.4.1.7
Posio da clusula default em instrues switch (categoria 5)
O trecho de cdigo da Listagem 3.7 trata-se de uma instruo switch simples na qual
a clusula default no vem aps todas as clasulas case, o que facilitaria a leitura e o
entendimento do cdigo.
1
switch ( s e x o ) {
default : return " Anjo " ;
case M : return " Masculino " ;
case F : return " Feminino " ;
Listagem 3.7: Exemplificao da posio da clusula default em instrues switch

Checkstyle alertou sobre o problema e tambm alertou sobre o nmero de instrues
return, que seriam duas no mximo.
44

PMD alertou sobre o problema e tambm alertou que um mtodo deveria possuir
um nico ponto de sada (instruo return) que seria a ltima instruo do mtodo.
da verificao da posio da clusula default em
instrues switch
X
X
3.4.1.8
Uso da referncia this (categoria 5)
O trecho de cdigo da Listagem 3.8 trata-se de um mtodo que retorna um atributo de

uma instncia sem utilizar a referncia this. Ao utilizar a referncia this fica claro que
estamos acessando atributos ou invocando mtodos da prpria instncia da classe, o que
facilita o entendimento do cdigo.
1
private f i n a l S t r i n g c h a s s i ;
2
3
public S t r i n g g e t C h a s s i ( ) {
return c h a s s i ;
4
5
Listagem 3.8: Exemplificao do uso da referncia this

Checkstyle alertou precisamente sobre o problema.
da verificao do uso da referncia this
X
X
X

3.4.1.9
45
Uso de chaves (categoria 5)
O trecho de cdigo da Listagem 3.9 trata-se de instrues if-else encadeadas, porm sem
a utilizao de chaves. A utilizao de chaves extremamente indicada para facilitar a
leitura, o entendimento e a manutenibilidade do cdigo.
1
i f ( s e x o==M )
return " Masculino " ;
2
3
e l s e i f ( s e x o==F )
return " Feminino " ;
4
5
6
else
return " Anjo " ;
Listagem 3.9: Exemplificao de uso de chaves

Checkstyle alertou sobre o problema e tambm alertou sobre o nmero de instrues
return, que seriam duas no mximo.
PMD alertou sobre o problema e tambm alertou que um mtodo deveria possuir
um nico ponto de sada (instruo return) que seria a ltima instruo do mtodo.
da verificao do uso de chaves
X
X
3.4.2
Erros
As subsees seguintes possuem o nome de cada erro abordado na subseo 2.2.2 do

Captulo 2 e o nmero da categoria em que ele se encontra segundo a categorizao de
defeitos abordada na seo 2.1 do Captulo 2.
3.4.2.1
Conexo com banco de dados no encerrada (categoria 1)
O trecho de cdigo da Listagem 3.10 trata-se de um acesso ao banco de dados para a

atualizao de uma tabela. O cdigo realiza o rollback da transao em caso de erro,
porm no fecha a instruo (statement, em ingls) nem tampouco a conexo.
Connection conn = null ;
Statement s t = null ;
try {
46
conn = DriverManager . g e t C o n n e c t i o n (
" j d b c : mysql : / / s e r v e r : 3 3 0 6 / d a t a b a s e " ) ;
5
6
7
s t = conn . c r e a t e S t a t e m e n t ( ) ;
s t . executeUpdate ( " update TB s e t COL=COL 1 . 1 " ) ;
conn . commit ( ) ;
10
11
} catch ( SQLException e ) {
12
13
// R e a l i z a o
do
rollback
Listagem 3.10: Exemplificao de uma conexo com banco de dados no encerrada

Checkstyle no alertou sobre o problema.
FindBugs alertou sobre o problema e ainda complementou dizendo sobre o no
fechamento da instruo.
Klocwork Developer alertou precisamente sobre o problema.
com nome curto (varivel st, no caso).
da verificao de conexo com banco de dados no
encerrada
X
*
Durante este estudo de caso, foi feita uma moficao colocando o encerramento da
instruo e da conexo em um mtodo separado. As ferramentas FindBugs e Klocwork
Developer observaram este comportamento e, precisamente, nada alertaram. Entretanto,
a ferramenta PMD no foi capaz de observar este comportamento emitindo um alarme
falso.

3.4.2.2
47
Valor de retorno ignorado (categoria 2)
programadores inexperientes que certamente ocasionar um comportamento inesperado.
Uma string imutvel, portanto sempre retornada uma nova string na invocao de
qualquer mtodo que a modificaria.
1
s t r . r e p l a c e ( A , @ ) ;
return s t r ;
Listagem 3.11: Exemplificao de um valor de retorno ignorado

Checkstyle e PMD no alertaram sobre o problema.
FindBugs e Klocwork Developer alertaram precisamente sobre o problema.
da verificao de um valor de retorno ignorado
X
X
3.4.2.3
Perda de referncia nula (null dereference, em ingls) (categoria 3)
O trecho de cdigo da Listagem 3.12 foi citado em um estudo de Hovemeyer e Pugh

(2004). uma falha to importante que, um ano depois, Hovemeyer, Spacco e Pugh
(2005) publicaram um artigo apenas sobre esta falha. Trata-se de uma falha que permite
a invocao de um mtodo a partir de uma referncia que pode estar nula. Isto far com
que seja lanada uma exceo em tempo de execuo.
1
Control c = getControl ( ) ;
i f ( c == null && c . i s D i s p o s e d ( ) ) {
return ;
3
4
Listagem 3.12: Exemplificao de uma perda de referncia nula

Checkstyle no alertou sobre o problema.
48

com nome curto (varivel c, no caso).
da verificao de perda de referncia nula
X
3.4.2.4
Concatenao de strings em laos de repetio (categoria 4)
programadores inexperientes. Como j visto no estudo de caso da subseo 3.4.2.2, uma
string imutvel. Portanto, a cada contatenao gerada uma nova string o que ocasiona
um uso abusivo de memria que poderia ser facilmente solucionado pela utilizao da
classe StringBuffer ou StringBuilder.
1
S t r i n g a l f a b e t o = "" ;
for ( int i = 6 5 ; i <=90; i ++){

a l f a b e t o += ( char ) i ;
3
4
return a l f a b e t o ;
Listagem 3.13: Exemplificao de uma concatenao de strings em laos de repetio

Checkstyle e FindBugs no alertaram sobre o problema.
Klocwork Developer e PMD alertaram precisamente sobre o problema.
da verificao de concatenao de strings em laos
de repetio
X
X

3.4.2.5
49
Fluxo (stream, em ingls) no encerrado (categoria 4)
O trecho de cdigo da Listagem 3.14 trata-se de uma escrita em um arquivo, contudo o

fluxo de sada no est sendo encerrado, o que possivelmente far com que a escrita no
ocorra conforme esperado, pois a chamada ao mtodo close de um fluxo de sada faz
com que o buffer 3 seja esvaziado.
1
OutputStream out = new FileOutputStream ( " arq . t x t " ) ;
out . w r i t e ( " Texto Qualquer " . g e t B y t e s ( ) ) ;
Listagem 3.14: Exemplificao de um fluxo no encerrado

da verificao de fluxo no encerrado
X
X
3.4.2.6
No utilizao de operador booleano de curto-circuito (categoria 4)
programadores inexperientes. Na linguagem Java, em avaliaes de expresses lgicas
utilizando os operadores lgicos (& e |), todas as expresses sero avaliadas. Por
outro lado, quando utilizamos operadores de curto-circuito (&& e ||), as expresses so
avaliadas at que o resultado possa ser previsto, isto , um valor falso em condies E e
um valor verdadeiro em condies OU .
1
Pessoa p = g e t P e s s o a ( ) ;
i f ( p != null & p . getNome ( ) != null ) {

return p . getNome ( ) ;
3
4
Listagem 3.15: Exemplificao da no utilizao de operador booleano de curto-circuito

3
"Buffer uma regio de memria utilizada para temporariamente manter os dados enquanto eles
esto sendo movidos de um lugar para outro." (WIKIPEDIA, 2008b, traduo e grifo nosso)
50

FindBugs e Klocwork Developer alertaram precisamente sobre o problema e ainda
complementaram dizendo que poderia haver uma problema de perda de referncia
nula.
Tabela 3.16: Resultado sintetizado sobre a eficcia da verificao da no utilizao de operador
booleano de curto-circuito
X
X
3.4.2.7
Objetos iguais tm o mesmo cdigo de disperso (hashcode, em

ingls) (categoria 4)
Para a sobreposio do mtodo equals e do mtodo hashcode, existem contratos que

devem ser seguidos.
Contrato do mtodo equals:
Reflexiva: um objeto igual a ele mesmo em todos os casos;
Simtrica: a igual a b implica em b igual a;
Transitiva: Se a igual a b e b igual a c, a igual a c.
Contrato do mtodo hashcode:
Objetos iguais devem ter o mesmo cdigo de disperso;
Cdigos de disperso diferentes implicam em objetos diferentes;
Objetos diferentes podem ter, apesar de no recomendvel, o mesmo cdigo de
disperso.
Caso o contrato no seja seguido, o comportamento destes objetos em mapas ou conjuntos de disperso podem apresentar um comportamento no esperado.
A Listagem 3.16 trata-se de uma classe que sobrepe o mtodo equals sem sobrepor
o mtodo hashcode.
51
public c l a s s C l a s s e {
2
3
@Override
public boolean e q u a l s ( Object o b j ) {
// I m p l e m e n t a o
6
7
8
Listagem 3.16: Exemplificao de uma classe que redefine o mtodo equals, porm no
redefine o mtodo hashcode
De uma outra forma, a Listagem 3.17 trata-se de uma classe que sobrepe o mtodo
hashcode sem sobrepor o mtodo equals.
1
public c l a s s C l a s s e {
2
3
@Override
public int hashCode ( ) {
// I m p l e m e n t a o
6
7
8
Listagem 3.17: Exemplificao de uma classe que redefine o mtodo hashcode, porm
no redefine o mtodo equals
Checkstyle alertou em parte sobre o problema. Ele alertou a sobreposio do mtodo
equals sem sobrepor o mtodo hashcode, contudo o inverso no foi alertado.
FindBugs, Klocwork Developer e PMD alertaram precisamente sobre o problema
em todos os casos analisados.
Tabela 3.17: Resultado sintetizado sobre a eficcia da verificao que objetos iguais tm o mesmo
cdigo de disperso
*

3.4.2.8
52
Utilizao de == ao invs de equals (categoria 4)
programadores inexperientes. Eles tendem a comparar objetos utilizando o operador ==
que utilizado para comparao de tipos primitivos e, em objetos, compara a posio de
memria ocupada. Geralmente, a comparao de objetos, na linguagem Java, realizada
pelo mtodo equals que, na maioria dos casos, verifica a equalidade pelos valores dos
atributos.
1
i f ( s t r == " Java " ) {

return "ALINGUAGEM" ;
2
3
Listagem 3.18: Exemplificao da utilizao de == ao invs de equals

Ao aplicarmos as ferramentas, pde-se constatar que todas as ferramentas alertaram
precisamente sobre o problema.
da verificao da utilizao de == ao invs de
equals

3.4.2.9
Comparao com nulo redundante (categoria 5)
O trecho de cdigo da Listagem 3.19 trata-se de uma falha que ocorre com freqncia.
Em alguns casos, os programadores so to atentos em evitar que ocorram excees que
realizam testes redundantes. Estes testes no prejudicam a correo do aplicativo, porm
nada justifica sua utilizao.
1
i f ( p != null ) {
// Algumas
i f ( p != null && p . getNome ( ) != null ) {

return p . getNome ( ) ;
5
6
instrues
Listagem 3.19: Exemplificao de uma comparao com nulo redundante

53

da verificao de comparao com nulo redundante
X
X
3.5
Problemas e solues propostas
Segundo Johnson (1977), at mesmo no Lint havia problemas, pois havia ocasies em que
o programador era mais inteligente, isto , podia existir razes vlidas para converses
de tipos "ilegais", funes com um nmero varivel de argumentos, etc. Assim, alguma
forma de comunicao com o Lint, tipicamente para deslig-lo, era desejada.
Logo, todas as ocasies em que o programador era mais inteligente resultava em um
alarme falso. Isto somente fazia com a quantidade de sada das ferramentas fosse cada
vez maior o que dificultaria, cada vez mais, a sua utilizao. Uma possvel soluo para
este problema pode ser vista abaixo:
A maior dificuldade em utilizar as ferramentas simplesmente a quantidade de sada. Em nossa opinio, o programador deveria poder adicionar
uma anotao ou um comentrio especial no cdigo para suprimir alertas que so falsos. (RUTAR; ALMAZAN; FOSTER, 2004, p. 255, traduo
nossa)
A forma de comunicao do programa com o verificador esttico de cdigo, para

suprimir alertas falsos, seria atravs de diretivas ou anotaes. Uma prtica que poderia
ser utilizada, na linguagem Java, o uso da prpria anotao padro da linguagem que
suprime alertas (@SuppressW arnings).
Wagner et al. (2005) diz que as anotaes permitem ferramenta entender o cdigo at
uma certa extenso e, por isto, permite algumas verificaes da lgica. Este conhecimento
profundo do cdigo pode reduzir a taxa de alertas falsos. Entretanto, a insero de
anotaes requer um esforo adicional pelos programadores. Deve ser analisado se este
esforo lucrativo, mas j existem ferramentas, como a ESC/Java2, que complementam
a anlise esttica com o uso de anotaes formais conforme pode ser visto em Flanagam
et al. (2002) e KINDSOFTWARE (2008).
54
Um outro problema que se pode constatar nos estudos de caso da seo 3.4 que
nenhuma ferramenta foi eficaz em todos os estudos de caso, porm, se todas fossem integradas, a anlise teria uma abragncia significativa.
Pela necessidade da utilizao de vrias ferramentas de anlise esttica, Rutar, Almazan
e Foster (2004) propuseram a criao de uma metaferramenta de verificao de erro (bug
f inding meta-tool, em ingls) que automaticamente combina e correlaciona as sadas de
todas as ferramentas de anlise esttica.
Ainda segundo Rutar, Almazan e Foster (2004), a metaferramenta pode prover uma
capacidade de verificao de defeitos muito superior s ferramentas isoladas. Utilizar
desta metaferramenta significa que o programador no precisa confiar na sada de uma
nica ferramenta. Em particular, a metaferramenta pode classificar classes, mtodos e
linhas pelo nmero de alertas gerados por todas as ferramentas.
Possivelmente, a situao ideal seria uma nica ferramenta com uma grande variedade de anlises e que estas anlises pudessem ser combinadas e correlacionadas de
maneira apropriada. Porm, na prtica, as ferramentas tendem a ser desenvolvidas por
uma enorme variedade de desenvolvedores e, por isto, a utilizao de uma ferramenta que
combine os resultados parece ser necessria.
3.6
Consideraes finais
A idia de anlise esttica comeou com o Lint. Segundo Johnson (1977), o compilador
concentrava em tornar, rapidamente e exatamente, o cdigo-fonte em um arquivo executvel, enquanto que o Lint concentrava nas caractersticas de portabilidade, estilo e
eficincia.
O programador poderia concentrar nos algoritmos, estruturas de dados e correo do
programa e, depois inseria, com o auxlio do Lint, as propriedades desejadas de universalidade e portabilidade.
O Lint foi to importante que serviu de base para outros verificadores de anlise
esttica para C, como o SLAM Toolkit, que, segundo Ball e Rajamani (2002), aplicado
nos drivers de dispositivos para o Windows XP tanto para validar o comportamento
quanto para encontrar defeitos no uso do ncleo da API4 (API Kernel, em ingls).
Nenhuma ferramenta de anlise esttica consistente ou completa, porm, segundo
Wagner et al. (2005), podem ser consideradas teis j que principalmente detectam defeitos que so relacionados manutenibilidade do cdigo, o que corresponde a expectativa
que um desenvolvedor experiente teria.
4
"API uma interface de cdigo-fonte que um sistema operacional ou que uma biblioteca fornece
para apoiar requisies de servios a serem feitos pelos programas de computador." (WIKIPEDIA, 2008a,
traduo nossa)
55
Existem vrias tcnicas para identificar tais pedaos de cdigo crtico. A

mais comum definir padres de erros tpicos que so derivados a partir
da experincia e de deslizes comuns publicados em uma certa linguagem
de programao. Alm disso, padres e diretivas de cdigo podem ser
verificados para permitir uma melhor leitura. Tambm, mais tcnicas de
anlise sofisticadas baseadas em fluxo de dados e fluxo de controle so
utilizadas. Finalmente, anotaes adicionais no cdigo so introduzidas
por algumas ferramentas para permitir uma verificao esttica extendida e uma combinao com verificao de modelo. (WAGNER et al., 2005,
p. 42, traduo nossa)
Existem diversas ferramentas para anlise esttica de cdigos Java. Neste estudo
foram avaliadas as ferramentas Checkstyle, FindBugs, Klocwork Developer e PMD. A
ferramenta ESC/Java2 s no foi avaliada, pois necessita de anotaes em cdigo que faz
com que tenha caractersticas diferentes.
Todas as ferramentas acima possuem mdulo de extenso (plug-in, em ingls) para
a verso mais atual da IDE Eclipse e so de cdigo aberto, com a exceo do Klocwork
Developer cuja licena proprietria.
Foram aplicados diversos estudos de caso s ferramentas, cujo resultado sintetizado
pode ser observado na tabela 3.20.
Tabela 3.20: Resultado sintetizado sobre a eficcia das ferramentas
Tipo
Checkstyle
FindBugs
Klocwork Developer
PMD
Regras de estilo
7/9 (78%)
0/9 (0%)
1/9 (11%)
5/9 (56%)
Erros
2/9 (22%)
8/9 (89%)
9/9 (100%)
5/9 (56%)
Total
9/18 (50%) 8/18 (44%)

10/18 (56%)
10/18 (56%)
Em relao s regras de estilo, a ferramenta Checkstyle apresentou o melhor resultado,

seguida da ferramenta PMD. As ferramentas FindBugs e Klocwork Developer praticamente no alertaram sobre as regras de estilo, o que era esperado j que ambas possuem
o propsito de verificao de erros, no de regras de estilo.
Em relao aos erros, a ferramenta Klocwork Developer apresentou um resultado perfeito, tendo encontrado erros em todos os estudos de caso. Logo em seguida, encontra-se
a ferramenta FindBugs que somente no foi capaz de encontrar erro em um dos estudos de caso. A ferramenta PMD apresentou um resultado satisfatrio, enquanto que a
ferramenta Checkstyle apresentou um resultado muito pouco satisfatrio.
Assim como no estudo de Rutar, Almazan e Foster (2004), no fcil dizer qual a
melhor ferramenta de anlise esttica, porm algumas concluses podem ser tiradas:
Checkstyle a melhor ferramenta de verificao de regras de estilo.
56
Klocwork Developer , sem dvida, a melhor ferramenta de verificao de erros,

porm possui a desvantagem de ser uma ferramenta proprietria. Isto faz com o
FindBugs, que gratuito e quase to eficaz, seja uma excelente opo.
PMD uma ferramenta que obteve um resultado satisfatrio tanto na verificao
de regras de estilo quanto na verificao de erros.
Todas as ferramentas de anlise esttica avaliadas permitem o filtro de quais problemas
devem ser verificados. Segundo Louridas (2006), esta caracterstica importante, pois
alertas falsos podem ser um grande problema e necessita-se de um modo de reduzir a
abundncia de alertas produzidos.
Em alguns casos, o programador mais inteligente que a ferramenta de anlise esttica
o que resulta em um alarme falso. Isto somente faz com a quantidade de sada da ferramenta seja cada vez maior o que dificulta, cada vez mais, a sua utilizao. Uma possvel
soluo para este problema encontra-se no uso de anotaes, porm a sua insero requer
um esforo adicional por parte dos programadores.
Um outro problema que se pode constatar nos estudos de caso da seo 3.4 que
nenhuma ferramenta foi eficaz em todos os estudos de caso, porm Rutar, Almazan e
Foster (2004) propuseram a criao de uma metaferramenta de verificao de erro (bug
f inding meta-tool, em ingls) que automaticamente combina e correlaciona as sadas de
todas as ferramentas de anlise esttica.
4 Concluso
Verificao e validao no so a mesma coisa. Verificao se destina a mostrar que um
programa atende a sua especificao, enquanto que a validao se destina a mostrar que
o programa realiza o que o usurio necessita.
O processo de V & V possui duas abordagens complementares para a verificao e
anlise do sistema que so os testes de software e as inspees de software. O teste de
software, que uma tcnica dinmica, a principal e mais utilizada tcnica de V & V.
Contudo, a inspeo de software vem sendo largamente utilizada pelo simples fato de as
pesquisas demonstrarem que os defeitos encontrados por ela so completamente diferentes
daqueles encontrados pelo teste de software. Logo, recomendada a utilizao destas
tcnicas em conjunto no processo de V & V.
A anlise de cdigo-fonte automatizada uma das tcnicas de inspees de software.
Ela surgiu da possibilidade de automatizar o processo de verificao em relao a certos
itens do checklist de uma inspeo de cdigo manual. A maioria destes itens facilmente
implementvel com o uso de tcnicas simples de anlise esttica.
Programadores geralmente empregam verificadores estticos aps a compilao e antes dos testes. Deste modo, eles trabalham com um programa
que tem uma indicao inicial de correo (pois ele compila) e tenta
evitar deslizes e perigos bem conhecidos antes de bat-lo contra sua especificao (quando ele testado). (LOURIDAS, 2006, p. 58, traduo
nossa)
Complementando a citao de Louridas (2006), Wagner et al. (2005) diz que se tambm empregada a inspeo de cdigo, benfico empregar verificadores estticos antes
mesmo da inspeo de cdigo manual, pois eles removeriam, de forma mais barata e mais
minuciosa, os defeitos que seriam encontrados por ambos.
Segundo Wagner et al. (2005), a anlise automatizada a tcnica mais eficiente na
remoo de defeitos, seguida pelas inspees de cdigo e testes de software, nesta ordem.
Isto se deve ao fato da anlise automatizada encontrar erros menos severos (categorias 3,
4 e 5), enquanto que as inspees de cdigo e testes de software encontram erros mais
severos (categorias 1 e 2).
Os projetistas de linguagens de programao modernas tm retirado vrias caractersticas que so propensas a erros. Essa abordagem de preveno de erros em vez de deteco
57
4. Concluso
58
de erros mais eficiente no aprimoramento da confiabilidade de programa.

As ferramentas verificadoras de estilo tendem, cada vez mais, a incorporar verificadores para outros prpositos. Um exemplo disto so as ferramentas Checkstyle e PMD que
tinham o foco de verificao de estilo, porm, hoje em dia, incorporaram tantos verificadores que pode-se dizer que so ferramentas mistas. Isto por um lado pode ser bom por
serem cada vez mais abrangentes, porm cuidado deve ser tomado para evitar que acabe
no fazendo nenhuma das funes corretamente. Contudo, as ferramentas verificadores
de erros mantm seu foco e no esto incorporando verificadores para outros propsitos.
O Lint foi a base para todos os outros verificadores de anlise esttica. Contudo, o
contexto de uso foi expandido. Segundo Ayewah et al. (2007), existem vrios contextos
para a utilizao de anlise esttica. Um contexto quando executamos uma inspeo de
cdigo de um novo mdulo, o que seria comparado a execuo do Lint aps a compilao.
Um outro contexto quando se deseja procurar por defeitos em uma larga base de cdigo
existente.
Com exceo de um nico estudo de caso, todos os outros foram alertados por pelo
menos uma das ferramentas avaliadas. O fato de existir um problema que no foi alertado
por nenhuma ferramenta, refora o fato da ausncia de alertas de uma ferramenta no
implicar na ausncia de erros do programa.
A ferramenta Checkstyle apresentou o melhor resultado na verificao de regras de
estilo, porm o pior na verificao de erros. Por outro lado, a ferramenta Klocwork
Developer foi, sem dvida, a melhor ferramenta de verificao de erros alertando 100%
dos erros, porm possui a desvantagem de ser uma ferramenta proprietria. Isto faz com
que o FindBugs, que gratuito e quase to eficaz, seja uma excelente opo.
As ferramentas buscam encontrar o mximo de erros possveis. Isto faz com que um
dos maiores problemas esteja na quantidade de alertas reportados. Se estes alertas so
referentes a erros reais, mas so defeitos com que os desenvolvedores no se preocupam ou
no querem se preocupar, basta a ferramenta prover um filtro de quais problemas devem
ser verificados, o que foi encontrado em todas as ferramentas avaliadas neste estudo.
Por outro lado, se os alertas so referentes a alarmes falsos, o problema no est mais na
configurao da ferramenta, mas sim, na prpria ferramenta. Uma soluo simples, porm
pouco usual devido questo de tempo, seria reportar o erro ao fornecedor da ferramenta
e aguardar pela verso corrigida, isto se o erro puder ser corrigido. Uma outra soluo
estaria em prover um mecanismo de comunicao do cdigo-fonte com a ferramenta, como
anotaes ou diretivas, que permitiriam suprimir alertas, mas que requerem um esforo
adicional dos programadores. O ESC/Java2 um exemplo de uma ferramenta que utiliza
de anotaes.
Se existe o interesse em utilizar mais de uma ferramenta de anlise esttica em um
mesmo projeto, visando abranger praticamente todos os defeitos, recomendvel o uso
de uma metaferramenta de verificao de erro, conforme a proposta de Rutar, Almazan
4. Concluso
59
e Foster (2004), que automaticamente combina e correlaciona as sadas de todas as ferramentas de anlise esttica.
Nenhum verificador esttico de cdigo consistente e completo, que faz com que exista
uma limitao clara e consciente de que "nenhum verificador de cdigo pode nos assegurar
que um programa est correto - tal garantia no possvel." (LOURIDAS, 2006, p. 60,
traduo nossa)
Enfim, segundo Hovemeyer e Pugh (2004) e Louridas (2006), nenhuma mquina pode
substituir o bom senso, o slido conhecimento dos fundamentos, o pensamento claro e a
disciplina, entretanto ferramentas de verificao de erros podem efetivamente ajudar os
desenvolvedores e, a sua mais ampla adoo, pode significamente aumentar a qualidade
do software.
AYEWAH, N. et al. Evaluating static analysis defect warnings on production software.
ACM, jun. 2007.
BALL, T.; RAJAMANI, S. K. The slam project: Debugging system software via static
analysis. In: Proceedings of 29th ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages. Vancouver: ACM, 2002. p. 13.
BOEHM, B. W. Software engineering; r & d trends and defense needs. In: Research
directions in software technology. Cambridge: MIT Press, 1979. p. 19.
CHECKSTYLE. Checkstyle. 2008. Disponvel em: <http://checkstyle.sourceforge.net>.
Acesso em: 10 jan. 2008.
DIJKSTRA, E. W. et al. Structured Programming. Londres: Academic Press, 1972.
FINDBUGS. FindBugs - Find Bugs in Java Programs. 2008. Disponvel em:
<http://findbugs.sourceforge.net>. Acesso em: 10 jan. 2008.
FLANAGAM, C. et al. Extended static checking for java. In: Proceedings of the 2002
ACM SIGPLAN Conference on Programming Language Design and Implementation.
Berlim: ACM, 2002. p. 234245.
GILB, T.; GRAHAM, D. Software inspection. Wokingham: Addison Wesley, 1993.
GLOSSARY. EGGHEAD DESIGN, 2008. Disponvel em: <http://www.eggheaddesign.co.uk/ glossary.aspx>. Acesso em: 04 fev. 2008.
HOVEMEYER, D.; PUGH, W. Finding bugs is easy. ACM SIGPLAN Notices, v. 39,
n. 12, p. 92106, dez. 2004.
HOVEMEYER, D.; SPACCO, J.; PUGH, W. Evaluating and tuning a static analysis to
find null pointer bugs. In: Proceedings of the 6th ACM SIGPLAN-SIGSOFT Workshop
on Program Analysis For Software Tools and Engineering. Lisboa: ACM, 2005. p. 1319.
JELLIFFE, R. Mini-review of java bug finders. OReilly Developer Weblogs, OReilly,
mar. 2004. Disponvel em: <http://www.oreillynet.com/pub/wlg/4481>. Acesso em: 23
jan. 2008.
60
61
JLINT. Jlint - Find Bugs in Java Programs. 2008. Disponvel em: <http://jlint.sourceforge.net/>. Acesso em: 26 jan. 2008.
JUNIT. JUnit.org Resources for Test Driven Development. 2008. Disponvel em:
<http://www.junit.org/>. Acesso em: 13 fev. 2008.
JOHNSON, S. C. Lint, a c program checker. Bell Laboratories, p. 111, dez. 1977.
KINDSOFTWARE. ESC/Java2. 2008. Disponvel em: <http://kind.ucd.ie/products/opensource/ESCJava2>. Acesso em: 06 fev. 2008.
KLOCWORK. Klocwork Developer for Java. 2008. Disponvel em: <http://www.klocwork.com/products/developerJava.asp>. Acesso em: 10 jan. 2008.
LOURIDAS, P. Static code analysis. IEEE Software, v. 23, n. 4, p. 5861, jul. 2006.
MALDONADO, J. C.; DELAMARO, M. E.; JINO, M. Conceitos bsicos. In:
Introduo ao Teste de Software. Rio de Janeiro: Elsevier, 2007. cap. 1, p. 17.
OCALLAHAN, R. Static analysis and scary headlines. MozillaZine Hosted Weblogs,

set. 2006. Disponvel em: <http://weblogs.mozillazine.org/roc/archives/2006/09/static analysis and scary head.html>. Acesso em: 23 jan. 2008.
PAREKH, N. Software Verification & Validation Model - An Introduction. 2005.
Disponvel em: <http://www.buzzle.com/editorials/4-5-2005-68117.asp>. Acesso em:
14 jan. 2008.
PMD. PMD. 2008. Disponvel em: <http://pmd.sourceforge.net/>. Acesso em: 10 jan.
2008.
QJ-PRO. QJ-PRO Code Analyzer for Java. 2008. Disponvel em: <http://qjpro.sourceforge.net/>. Acesso em: 26 jan. 2008.
RUTAR, N.; ALMAZAN, C. B.; FOSTER, J. S. A comparison of bug finding tools
for java. In: Proceedings of the 15th International Symposium on Software Reliability
Engineering (ISSRE04). Washington: IEEE Computer Society, 2004. p. 245256.
SAP AG. Open Source Static Analysis Tools for Security Testing of Java Web
Applications. Alemanha, dez. 2006. Disponvel em: <http://www.secologic.de/downloads/testing /061219 TestToolAnalyseV1.pdf>. Acesso em: 16 jan. 2008.
SOMMERVILLE, I. Engenharia de Software. 8. ed. So Paulo: Pearson Addison-Wesley,
2007. Caps. 2223, p. 341373.
62
WAGNER, S. et al. Comparing bug finding tools with reviews and tests. In: Proc.
17th International Conference on Testing of Communicating Systems (TestCom05).
Springer: ACM, 2005. v. 3502, p. 4055. Disponvel em: <http://citeseer.ist.psu.edu/wagner05comparing.html>.
WIKIPEDIA. Application programming interface. 2008a. Disponvel em: <http://en.wikipedia.org/wiki/Application programming interface>. Acesso em: 06 fev.
2008.
WIKIPEDIA. Data buffer. 2008b. Disponvel em: <http://en.wikipedia.org/wiki/Buffer
(computer science)>. Acesso em: 05 fev. 2008.
WIKIPEDIA. Formal verification. 2008c. Disponvel em: <http://en.wikipedia.org/wiki/Formal verification>. Acesso em: 28 jan. 2008.
WIKIPEDIA. Quelltextformatierung. 2008d. Disponvel em: <http://de.wikipedia.org/wiki/Beautifier>. Acesso em: 03 fev. 2008.
WIKIPEDIA. Static code analysis. 2008e. Disponvel em: <http://en.wikipedia.org/wiki/Static code analysis>. Acesso em: 15 jan. 2008.
WIKIPEDIA. Style Checker. 2008f. Disponvel em: <http://de.wikipedia.org/wiki/Style
Checker>. Acesso em: 16 jan. 2008.
WIKIPEDIA. Virtual machine. 2008g. Disponvel em: <http://en.wikipedia.org/wiki/Virtualmachine>. Acesso em: 05 fev. 2008.

2008 Monografia Ufmg

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

2008 Monografia Ufmg

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE FEDERAL DE MINAS GERAIS

INSTITUTO DE CINCIAS EXATAS

RICARDO TERRA NUNES BUENO VILLELA

UNIVERSIDADE FEDERAL DE MINAS GERAIS

RICARDO TERRA NUNES BUENO VILLELA

Monografia apresentada Curso de Especializao em Informtica do Departamento de

"Nunca se fizeram programas contendo to

Palavras-chave: Engenharia de software, validao, verificao, inspeo, testes, erros,

Keywords: Software engineering, validation, verification, inspection, test, bugs, style

Verificadores estticos em relao cobertura e ao esforo . . . . . . . . . . . 33

Mdulo de extenso do FindBugs para IDE Eclipse . . . . . . . . . . . . . . . 37

Alguns exemplos de regras de estilo . . . . . . . . . . . . . . . . . . . . . . . . 25

Principais ferramentas para anlise esttica de cdigo Java . . . . . . . . . . . 35

Resultado sintetizado sobre a eficcia da verificao de uma comparao com

Resultado sintetizado sobre a eficcia da verificao da posio da clusula

3.19 Resultado sintetizado sobre a eficcia da verificao de comparao com nulo

2 Anlise Esttica de Cdigo

Ainda na mesma linha de raciocnio de Sommerville (2007), dentro do processo de

Figura 1.1: Processo de depurao

Segundo Sommerville (2007), inspees de software um processo de V & V esttico,

Verses incompletas de um sistema podem ser inspecionadas sem custos adicionais.

Verificao formal o ato de validar ou invalidar a correo dos algoritmos subjacentes

A prova pode conter erros. As provas so amplas e complexas, o que as torna

Verificao e validao no so a mesma coisa. Verificao se destina a mostrar que o

Os custos de teste variam muito e dependem do nmero de defeitos no programa.

2 Anlise Esttica de Cdigo

Sommerville (2007) diz que analisadores estticos so ferramentas de software que

A inteno da anlise esttica automatizada chamar a ateno para anomalias do

2. Anlise Esttica de Cdigo

Categorizao dos defeitos

2. Anlise Esttica de Cdigo

Os verificadores estticos de cdigo, que so ferramentas automticas para a verificao

2. Anlise Esttica de Cdigo

at mesmo refatorar o cdigo. Ao contrrio de um programa Beautifier 1 , um verificador

Ao contrrio de um verificador de estilo, verificador de erro (bug checker, em ingls)

2. Anlise Esttica de Cdigo

Tabela 2.1: Alguns exemplos de regras de estilo

Bloco catch vazio

Verifica a presena de blocos catch sem nenhuma

Verifica a presena de atribuies em subexpresses.

Verifica a presena de comparaes com constante

Verifica a presena de instrues vazias, isto , apenas o ponto-e-vrgula (;).

Verifica a presena de desordem na declarao das

Verifica a presena de nomes de atributos, mtodos

Verifica a presena de instrues switch na qual a

Uso da referncia this

Verifica a presena de acesso a algum atributo ou

Verifica a presena de algum bloco condicional ou

Todos cometem erros tolos. Nem mesmos os melhores programadores so perfeitos

2. Anlise Esttica de Cdigo

Tabela 2.2: Alguns exemplos de erros

Conexo com banco

Verifica a presena de abertura de conexo ao

Valor de retorno ignorado

Verifica a presena de algum retorno de funo que

Verifica a presena de acesso a um atributo ou

Verifica a presena de concatenao de strings utilizando o operador + em laos de repetio.

Fluxo (stream, em ingls) no encerrado

Verifica a presena de abertura de fluxos sem posterior fechamento.

Verifica a presena de possibilidade de lanamento

Verifica a presena de objetos que redefinem o

Verifica a presena de comparaes de objetos

Comparao com nulo