Escolar Documentos
Profissional Documentos
Cultura Documentos
FERRAMENTAS PARA
ANLISE ESTTICA DE CDIGOS JAVA
Belo Horizonte
Fevereiro de 2008
FERRAMENTAS PARA
ANLISE ESTTICA DE CDIGOS JAVA
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.
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.
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.
Lista de Figuras
1.1
Processo de depurao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1
3.2
3.3
3.4
3.5
Lista de Tabelas
2.1
2.2
2.3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
41
42
42
43
3.8
. . . . . . . .
da verificao
. . . . . . . .
da verificao
. . . . . . . .
. . . . . . . . . . . . . . . 50
que objetos iguais tm o
. . . . . . . . . . . . . . . 51
da utilizao de == ao
. . . . . . . . . . . . . . . 52
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 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
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.
1. Correo do software
14
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.
1. Correo do software
15
1.2
Inspees de software
1. Correo do software
16
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. Correo do software
1.2.1
17
Verificao formal
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.
1. Correo do software
18
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)
1. Correo do software
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
1. Correo do software
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)
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
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
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
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
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
Categoria
Descrio
Atribuio em subexpresses
Comparao
constante
Instruo vazia
Ordem de declarao
Padro de nomenclatura
Posio da clusula
default em instrues
switch
Uso de chaves
com
26
Categoria
Descrio
Perda de referncia
nula (null dereference,
em ingls)
Concatenao
de
strings em laos de
repetio
No utilizao de
operador booleano de
curto-circuito
Objetos iguais tm o
mesmo cdigo de disperso (hashcode, em
ingls)
Utilizao de == ao
invs de equals
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
2.3
28
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)
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)
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%
100%
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.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.
34
3.2
Tcnicas
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
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
Fonte: Arquivo pessoal.
Livre
Livre
37
XPath ou XML Path " um conjunto de regras de sintaxe (linguagem) para definir partes de um
documento XML." (GLOSSARY, 2008, traduo nossa)
38
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.
39
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
try {
System . i n . r e a d ( b ) ;
} catch ( IOException e ) {
X
Fonte: Arquivo pessoal.
3.4.1.2
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.
int i ;
while ( ( i = i n . r e a d ( ) ) != 1){
System . out . p r i n t l n ( i ) ;
in . close ( ) ;
40
X
X
X
Fonte: Arquivo pessoal.
3.4.1.3
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
2
3
4
5
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.
Um resultado sintetizado pode ser observado na tabela abaixo.
Tabela 3.4: Resultado sintetizado sobre a eficcia
da verificao de uma comparao com constante
Checkstyle FindBugs Klocwork Developer PMD
X
3.4.1.4
X
X
Fonte: Arquivo pessoal.
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 ++;
};
42
X
X
Fonte: Arquivo pessoal.
3.4.1.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
t h i s . nome = nome ;
8
9
private S t r i n g nome ;
10
11
X
X
X
Fonte: Arquivo pessoal.
43
X
X
X
Fonte: Arquivo pessoal.
3.4.1.7
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 ) {
44
X
X
Fonte: Arquivo pessoal.
3.4.1.8
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
X
X
X
Fonte: Arquivo pessoal.
45
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 " ;
X
X
Fonte: Arquivo pessoal.
3.4.2
Erros
Statement s t = null ;
try {
46
conn = DriverManager . g e t C o n n e c t i o n (
5
6
7
s t = conn . c r e a t e S t a t e m e n t ( ) ;
conn . commit ( ) ;
10
11
} catch ( SQLException e ) {
12
13
// R e a l i z a o
do
rollback
X
*
Fonte: Arquivo pessoal.
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.
47
O trecho de cdigo da Listagem 3.11 trata-se de uma falha que ocorre principalmente entre
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 ;
X
X
Fonte: Arquivo pessoal.
3.4.2.3
Control c = getControl ( ) ;
i f ( c == null && c . i s D i s p o s e d ( ) ) {
return ;
3
4
48
X
Fonte: Arquivo pessoal.
3.4.2.4
O trecho de cdigo da Listagem 3.13 trata-se de uma falha que ocorre principalmente entre
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 = "" ;
3
4
return a l f a b e t o ;
X
X
Fonte: Arquivo pessoal.
49
X
X
Fonte: Arquivo pessoal.
3.4.2.6
O trecho de cdigo da Listagem 3.15 trata-se de uma falha que ocorre principalmente entre
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 ( ) ;
3
4
"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
X
X
Fonte: Arquivo pessoal.
3.4.2.7
51
public c l a s s C l a s s e {
2
3
@Override
// 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
// 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
Ao aplicarmos as ferramentas, pde-se constatar:
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.
Um resultado sintetizado pode ser observado na tabela abaixo.
Tabela 3.17: Resultado sintetizado sobre a eficcia da verificao que objetos iguais tm o mesmo
cdigo de disperso
Checkstyle FindBugs Klocwork Developer PMD
*
Fonte: Arquivo pessoal.
52
O trecho de cdigo da Listagem 3.18 trata-se de uma falha que ocorre principalmente entre
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
2
3
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
5
6
instrues
53
X
X
Fonte: Arquivo pessoal.
3.5
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)
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 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
10/18 (56%)
56
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
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.
Referncias Bibliogrficas
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
Referncias Bibliogrficas
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.
Referncias Bibliogrficas
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.