1) O documento discute a utilização de ferramentas de análise estática para melhorar a qualidade do código e padrões de codificação. 2) A análise estática pode detectar problemas no código sem executá-lo, fornecendo feedback rápido aos desenvolvedores. 3) Algumas ferramentas de análise estática são comparadas, incluindo SonarQube Community, FindBugs e PMD Source Code Analyzer.

1. Melhoria da qualidade e padrões de código fonte
utilizando ferramentas de análise estática
Leandro Antunes Ugioni1
Cristiano Ávila Salomão2
Resumo
A demanda pela qualidade de software cresce a cada dia por ser um fator de competitividade
entre as empresas de software. Uma das formas de aumentar a qualidade de software e
detectar possíveis problemas com rápido feedback é a análise estática. A análise estática
comumente é realizada por ferramentas que possuem dashboards, API’s, plugins e integrado
a pipelines. Desta forma o objetivo deste artigo é demonstrar os conceitos envolvidos na
análise estática e de que forma isso impacta na qualidade do código fonte dos projetos de
desenvolvimento de software. Serão demonstradas algumas ferramentas de análise estática,
suas principais características e funcionalidades bem como um comparativo entre elas
considerando alguns aspectos principais.
Palavras-chave: Análise Estática. Qualidade. Padrões de Código Fonte.
1 INTRODUÇÃO
Com a crescente demanda por softwares que atendam a altos padrões de qualidade,
visando diversos benefícios aos usuários e a própria empresa de desenvolvimento, os
processos de melhoria da qualidade aplicados ao código fonte, são uma das formas de realizar
testes utilizando técnicas de análise estática, através de ferramentas que podem facilitar esse
processo e melhoram o software como um todo.
As ferramentas de análise estática validam o software através de padrões de
qualidade e métricas de codificação, sem que o mesmo necessite ser executado de forma
dinâmica, aumentando a qualidade do software em geral e prevenindo possíveis erros que
poderiam ser encontrados em fases posteriores do desenvolvimento. Seu uso pode ocorrer
desde as fases iniciais da concepção do código fonte, podendo possibilitar custo baixo nos
ajustes a serem realizados e feedback rápido ao time de desenvolvimento.
Considerando os aspectos descritos, como utilizar as ferramentas de análise estática
para padronização de código fonte e melhoria da qualidade do software?
Os objetivos desse artigo são a pesquisa de ferramentas de análise estática que
podem ser aplicadas ao código fonte, o comparativo entre as ferramentas com pontos fortes e
pontos fracos e as formas em que as mesmas podem ser utilizadas.
1
Bacharel em Sistemas de Informação. E-mail: leandro_ugioni@hotmail.com
2
Orientador. Especialista em Gerenciamento de Projetos em Tecnologia da Informação. E-mail:
salomao.cristiano@gmail.com

2. 2
2 FUNDAMENTAÇÃO TEÓRICA
Segundo Pressman (2006), a qualidade de um software desenvolvido
profissionalmente, geralmente é a conformidade com os requisitos funcionais e de
desempenho, satisfação de normas de desenvolvimento do software e características
implícitas que são esperadas pelos usuários, formando uma complexa mistura de fatores
dependendo da necessidade que o software atende e do perfil do usuário final.
Segundo Pressman (1995), na medida em que o desenvolvimento de softwares
cresceu em larga escala e popularidade, os projetos desenvolvidos pelas empresas começaram
a produzir milhares de novas linhas de código, que quando apresentavam falhas deveriam
passar por manutenção, exigindo esforço por parte dos recursos envolvidos.
Conforme Bastos, et al. (2012), em paralelo ao processo de codificação do software
deve existir um processo e um projeto de testes de software, contando com técnicos
especializados, buscando resultados imediatos no que tange a qualidade do software entregue.
Visto isso, dentro dos diferentes testes que podem ser executados em um software,
destacam-se as técnicas de testes estruturados.
2.1 Testes estruturados
“O teste de caixa branca é um método de projeto de casos de teste que usa a estrutura
de controle do projeto procedimental para derivar casos de teste” (PRESSMAN, 1995, p.793).
Bartié (2002) afirma que as empresas podem optar por realizar um processo formal
de verificação do código fonte de forma manual, onde um testador avalia as linhas de código e
busca de situações que necessitam ser ajustadas de forma detalhada, produzindo um processo
qualitativo de verificação ou optar por um processo mais informal, onde os desenvolvedores
avaliam o código de outro desenvolvedor em busca de falhas.
Segundo Bastos et al (2012), testes estruturais buscam a garantia de que o sistema
seja estruturalmente robusto, funcionando corretamente e de maneira sólida, utilizando os
recursos tecnológicos de maneira adequada e criando componentes de unidade de código com
a devida coesão.
Defeitos podem ser encontrados no código antes que o mesmo necessite ser enviado
aos testes funcionais, sendo que os defeitos encontrados em etapas posteriores sempre terão
um custo mais alto para serem corrigidos (SOFTWARE TESTING HELP, 2018).
Conforme Bartié (2002) a garantia da qualidade do código fonte implementado é
atribuída às normas e padrões seguidos pelas empresas no desenvolvimento do software,
utilizando comparações na arquitetura, ferramentas de análise estática, volume de código,
padrões de nomenclatura e legibilidade do código.
Para Pressman (1995) o uso de ferramentas de testes automatizados pode reduzir um
tempo valioso nos testes estruturais, sendo que a primeira geração das ferramentas
automatizadas continha analisadores estáticos, auditores de código e processadores de

3. 3
asserção, utilizados para analisar a parte estrutural do código fonte, verificar padrões de
código e qualidade de código e asserções do comportamento do código.
Segundo Bartié (2002), para a realização de alguns tipos de análise de código, pode-
se empregar o uso de ferramentas de análise estática, que farão isso de forma automática
resultando em uma lista de não conformidades, que será analisada pelos desenvolvedores a
fim de realizar os devidos ajustes conforme os critérios da ferramenta.
2.1 Ferramentas de análise estática
Bartié (2002) explana que as ferramentas podem ser parametrizadas dentro de
determinados padrões de codificação e normas a fim de melhorar o código fonte como um
todo, conduzindo uma padronização no código fonte, facilitando o entendimento,
manutenibilidade e facilidade para aderir às normas de codificação.
A ferramenta de análise estática permite realizar uma revisão de código, sem a
necessidade de que seja executado o software, sendo que os arquivos não necessitam ser
examinados em um ambiente que suporte sua execução, permitindo flexibilidade no que diz
respeito a plataformas desktop e web, contando com análise para arquivos binários
compilados e código fonte (VERACODE, 2017).
A análise estática utiliza técnicas para analisar o código fonte sem a necessidade de
executá-lo, fazendo com que seja executado um processo de teste estrutural durante o ciclo de
vida de desenvolvimento do software, seu objetivo principal é destacar vulnerabilidades e
auxiliar a equipe a focar em determinados trechos de código que necessitem de ajustes,
algumas ferramentas de análise estática podem ser executadas atualmente dentro de uma IDE
(Integrated Development Environment), para que o desenvolvedor possa detectar problemas
de forma antecipada e tenha feedback imediato no ciclo de vida de seu código fonte (OWASP,
2017).
Conforme Wysopal (2013), a técnica de testes de análise estática examina o software
em todos os caminhos do código e fluxos de dados que serão executados, sem que seja
preciso executar o software, isso faz com que não seja necessário um ambiente complexo e de
alto custo para executar e analisar o software em busca de defeitos de qualidade e segurança,
inclusive não havendo a necessidade de o software estar completamente desenvolvido para
que se possa realizar a análise.
Alguns fatores devem ser considerados para selecionar uma ferramenta de análise
estática, como as linguagens de programação suportadas, os tipos de vulnerabilidades que
podem ser detectados, possibilidade de integração com uma IDE, custos com uso e licença,
possibilidade de análise em arquivos binários e a possiblidade de executar análises durante o
desenvolvimento do software desde seu início (OWASP, 2017).
2.2 Complexidade ciclomática
Desenvolvida por Thomas J. McCabe em 1976, a complexidade ciclomática é uma
representação do fluxo de controle do software, ela pode ser calculada em funções, módulos,
métodos e classes, onde são medidos os caminhos independentes que tenha pelo menos uma
aresta que não tenha sido percorrida por nenhum outro caminho (GURU99, 2018).

4. 4
Segundo Bartié (2002), a complexidade de código fonte é inspecionada pela
ferramenta de análise, buscando identificar quais rotinas possuem complexidade acima do
padrão definido pela organização, onde a ferramenta se utiliza das métricas de McCabe para
poder determinar o nível de complexidade e probabilidade.
A métrica de complexidade ciclomática pode auxiliar a determinar os níveis de testes
que serão executados nas etapas posteriores, isso ocorre após o resultado de uma análise onde
a equipe de qualidade avalia o resultado da complexidade e quanto maior for o resultado para
cada funcionalidade maior será o esforço e detalhamento dos testes funcionais, se o resultado
for menor para determinada funcionalidade isso significa que se podem realizar testes menos
detalhados e de menor complexidade na funcionalidade (SOFTWARE TESTING HELP,
2018b).
2.2 Code smells
Segundo Fowler (2006), o termo code smell criado por Kent Beck, é um indicativo
superficial que alguma situação no código fonte deve ser verificada, pois pode corresponder a
um problema mais profundo no software, geralmente os code smell são rápidos de detectar e
em alguns casos não indicam o problema em si, mas a causa de um problema.
Uma das facilidades dos code smells é que mesmo os desenvolvedores que são
inexperientes tem facilidade para lidar com eles, mesmo que não saibam chegar a uma
solução para o problema, fazendo também com que isso sirva para ensinar algumas situações
aos desenvolvedores de forma gradual, muitos code smells simples de detectar e analisar
levam a problemas realmente interessantes e didáticos para os desenvolvedores (FOWLER,
2006).
Alves (2015), afirma que os code smells são uma realidade em muitos softwares,
onde muitas vezes os curtos prazos não permitem as devidas refatorações, quando os code
smells são detectados deve-se identificar onde se pode aplicar a devida refatoração, incluindo
métricas de complexidade ciclomática, número de linhas de código, código duplicado, código
morto, comentários, acoplamento de classes e nível de manutenibilidade.
Os code smells podem ser tratados como sintomas, onde se pode diagnosticar a
necessidade de possíveis refatorações para uma melhor adequação aos design patterns, sendo
que nem todo code smell deve ser algo fixo, o contexto é muito importante pois cada software
possui suas particularidades (DEVIQ, 2018).
A Figura 1 apresenta um exemplo de ferramenta de análise estática demonstrando
como são exibidos os code smells encontrados no código fonte de forma detalhada.
Figura 1: Exemplo de code smell em uma ferramenta de análise estática

5. 5
Fonte: Minkowski (2017)
3 PROCEDIMENTOS METODOLÓGICOS
Foi realizado um estudo de análise e comparação, coletando informações de três
ferramentas de análise estática diretamente dos sites dos criadores das ferramentas, foram
analisadas as características de cada uma delas individualmente pelo autor e realizado um
comparativo entre elas considerando sete itens, para que posteriormente seja apresentada uma
conclusão sobre qual a melhor opção de ferramenta a ser utilizada.
3.1 Ferramentas de análise estática
Atualmente no mercado existem diversas ferramentas de análise estática, muitas delas
são específicas para uma linguagem, outras são dedicadas a apenas uma linguagem de
programação, possuindo uma grande variedade de ferramentas gratuitas e que podem ser
configuradas com regras específicas de uma empresa ou projeto além das definições que são
padrão, a seguir serão demonstradas algumas ferramentas e posteriormente será feito um
comparativo com as características de cada uma delas.
3.2 Integração contínua
Para empresas ou mesmo projetos que utilizam servidores de integração contínua,
pode-se incluir na pipeline uma etapa onde o código será submetido à análise estática e
posteriormente será gerado o resultado da análise em um relatório que também pode estar
integrado ao servidor de CI, em casos onde o projeto é focado em sistemas considerados de
missão crítica essa etapa da pipeline pode ser impeditiva para a continuidade dessa iteração.
Idealmente a etapa de análise estática já deve estar sendo executada desde a etapa de
concepção do software, fazendo com que possíveis code smells inseridos no código sejam
detectados e corrigidos a cada execução da pipeline, impedindo assim que se propaguem por
mais locais no código fonte e que sejam causados bugs relacionados a um ou mais code
smells.
3.3 Plugins no ambiente de desenvolvimento
Uma das formas mais simples e práticas de se utilizar análise estática no dia a dia é
adotando a utilização de plugins de análise estática, que podem ser integrados a IDE e
fornecer uma análise em tempo real, evitando a propagação de code smells e promovendo o

6. 6
aprendizado de como proceder nos casos em que são detectados.
Quando o plugin é utilizado em conjunto com a integração contínua a eficácia da
ferramenta de análise estática aumenta, pois a análise ocorre em tempo real e com o feedback
dentro da própria IDE o desenvolvedor realiza os ajustes antes mesmo de executar um build
completo de seu software e executar toda a pipeline para obter a análise completa da
ferramenta, com o plugin o desenvolvedor vai ajustando cada linha de código e evita a
propagação dos code smells dentro do código fonte do software.
3.4 Regras usadas nas ferramentas (Rules)
As ferramentas de análise estática utilizam uma série de regras específicas para cada
linguagem analisada, essas regras são confrontadas durante a análise com o código fonte e
dessa forma são encontrados os code smells e categorizados para demonstrar no relatório.
As ferramentas possuem uma série de regras como padrão, considerando as melhores
práticas a padrões de código atuais, contando ainda com a possibilidade de personalização
dessas regras, permitindo que o administrador da ferramenta possa ativar ou desativar regras
específicas ou adicionar novas regras próprias de sua organização.
3.5 Análise das principais ferramentas
A seguir serão analisadas de forma simplificada as ferramentas SonarQube
Community, Findbugs e PMD Source Code Analyzer, demonstrando informações específicas
e características de cada uma das ferramentas:
3.5.1 SonarQube Community
A ferramenta SonarQube Community é uma das mais populares e seu uso é
simplificado, a ferramenta possui uma vasta quantidade de verificações que são validadas no
código fonte analisado e identificadas para que posteriormente esses dados sejam
consolidados e apresentados em um relatório, que apresenta as informações detalhadamente
identificando quais code smells foram detectados, em qual linha do código se encontra,
quantidades de code smells, e informações que auxiliam o desenvolvedor a refatorar seu
código fonte, também são apresentadas informações de cobertura de código e testes unitários
(SONARQUBE, 2018).
A Figura 2 apresenta um exemplo do dashboard da ferramenta SonarQube
Community demonstrando bugs, code smells e code coverage do projeto.
Figura 2: Dashboard da ferramenta SonarQube Community

7. 7
Fonte: SonarSource (2019)
3.5.2 FindBugs
A ferramenta FindBugs foi criada em uma iniciativa totalmente open source e com
foco em encontrar possíveis bugs em códigos fonte que utilizam a linguagem Java,
categorizando os mesmos e podendo ser usada de forma individual ou como plugin nas IDE’s
mais utilizadas no mercado de desenvolvimento de software (FINDBUGS, 2018).
Pode-se considerar a ferramenta Findbugs uma das primeiras criadas para o segmento
de análise estática para a linguagem Java, possuindo milhões de downloads desde sua criação
segundo seu site e atualmente tendo sua marca vinculada a universidade de Maryland nos
Estados Unidos (FINDBUGS, 2018).
A Figura 3 apresenta um exemplo da página principal da ferramenta Findbugs,
contendo informações detalhadas da análise estática realizada no código fonte.
Figura 3: Módulo principal da ferramenta FindBugs

8. 8
Fonte: Geoserver (2019)
3.5.3 PMD Source Code Analyzer
A ferramenta PMD Source Code Analyzer foi criada para identificar pequenas falhas
no código fonte através de análise estática, inicialmente suportando apenas Java e Apex e
depois sua compatibilidade foi expandida para uma gama maior de linguagens, atualmente a
ferramenta permite inclusive que através de sua API sejam criadas regras específicas pelo
próprio desenvolvedor ou pela empresa, comumente utilizado dentro de pipelines de
integração contínua, mantendo uma linha base de código respeitando os Quality Gates que
determinam os níveis de qualidade que o código fonte está atendendo (PMD, 2018).
A Figura 4 apresenta um exemplo de como são demonstrados os code smells
encontrados pela ferramenta PMD Source Code Analyzer.
Figura 4: Code smells encontrados pela ferramenta PMD Source Code Analyzer
Fonte: EclipseZone (2019)
3.6 Comparativos entre as ferramentas
Abaixo segue um quadro demonstrando o comparativo entre as ferramentas
SonarQube Community, Findbugs e PMD Source Code Analyzer, considerando sete itens:
Quadro 1: Comparativo entre as ferramentas de análise estática
SonarQube
Community
FindBugs PMD
Linguagens 9 1 7
Custo Free Free Free
Rules Java 450+ 420+ 300+
Licença Open Source Open Source Open Source
Integração Contínua Suporta Suporta Suporta
Plugins para IDE Sim Sim Sim
Documentação Sim Sim Sim
Fonte: Do Autor
4 RESULTADOS DA PESQUISA

9. 9
Conforme apresentado anteriormente, foram demonstradas informações sobre cada
uma das ferramentas de análise estática e realizado um comparativo considerando sete
importantes itens, a informações utilizadas foram provenientes dos sites dos desenvolvedores
de cada uma delas.
Iniciando a análise de resultados pela ferramenta FindBugs, a mesma destacasse pela
inovação de ser umas das primeiras a ser desenvolvida para análise estática, tendo como seu
berço de criação a notável universidade americana de Maryland, que se intitula uma das
principais instituições de pesquisa do mundo, a ferramenta é open source e possui mais de
400 rules para a linguagem Java, por ser uma das pioneiras nessa área a ferramenta ainda é
bastante utilizada nas empresas.
O ponto fraco da ferramenta FindBugs é que a ferramenta da suporte a apenas uma
linguagem que é o Java, esse fato dificulta um pouco seu uso em organizações que atuam em
diversos projetos utilizando outras linguagens além do Java em seu dia-a-dia.
Seguindo a análise pela ferramenta PMD Source Code Analyzer, ela se destaca por
estar expandindo sua compatibilidade com linguagens de programação, que inicialmente eram
apenas duas e agora já são sete linguagens, outro ponto de destaque é sua API que permite
total acesso a ferramenta e muitas possibilidades de personalização, principalmente o uso de
rules criadas ou personalizadas pelos usuários.
Um dos pontos fracos da ferramenta PMD Source Code Analyzer são suas rules
padrões utilizadas para a linguagem Java, a ferramenta conta apenas com trezentas rules, isso
pode fazer com que mesmo após uma análise com PMD Source Code Analyzer, se for
utilizada outra ferramenta a mesma ainda encontre novos code smells, devido outras
ferramentas analisarem aproximadamente mais de cem rules não existentes no PMD Source
Code Analyzer.
Por fim a ferramenta SonarQube Community se mostrou a mais completa e com mais
recursos, com suporte a nove linguagens de programação, a ferramenta é totalmente gratuita e
conta com mais que quatrocentas e cinquenta rules para a linguagem Java e possui plugins
para a maioria das IDE’s atuais.
Em relação às outras ferramentas apresentadas o SonarQube Community se destacou
por ser a mais completa, suportando mais linguagens e possuindo mais rules como padrão,
sendo que a ferramenta também oferece recursos adicionais para controle dos testes unitários
e cobertura de código de cada projeto, contando ainda com um dashboard completo para
acompanhamento dos projetos de software.
5 CONSIDERAÇÕES FINAIS
Conforme demonstrado às ferramentas de análise estática auxiliam consideravelmente
o trabalho dos desenvolvedores, fazendo com que os code smells encontrados durante a
análise pela ferramenta sejam ajustados logo após serem criados, os ajustes visam erradicar
pequenas falhas que podem vir a causar problemas maiores dentro do software.
Durante o uso das ferramentas no dia-a-dia, utilizando dashboards, plugins nas IDE’s

10. 10
e também o uso da análise dentro as pipelines, o desenvolvedor absorve conhecimento e com
isso devido às ferramentas serem didáticas demonstrando formas de ajustar os code smells, o
trabalho desses desenvolvedores começa a ser otimizado e com o passar do tempo à qualidade
de código aumenta de forma geral.
Em relação às ferramentas, as três que foram demonstradas atendem bem o objetivo de
realizar uma análise estática de forma consistente, tendo opções de ferramentas mais básicas
como é o caso do FindBugs ou a opção de uma ferramenta mais completa como o SonarQube
Community, sendo que essas ferramentas também podem ser usadas dentro de uma pipeline
de integração contínua, facilitando o uso no dia-a-dia dentro das organizações.
REFERÊNCIAS
ALVES, Robson. Refatoração – fugindo do code smell. 2015. Disponível em: <
http://netcoders.com.br/refatoracao-fugindo-do-code-smell/>. Acesso em: 21 mar. 2018.
BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002.
BASTOS, Aderson. et al. Base de conhecimento em teste de software. ed. 3. São Paulo:
Martins Fontes, selo Martins, 2012.
DEVIQ. Code smells. 2018. Disponível em: < http://deviq.com/code-smells/>. Acesso em: 22
mar. 2018.
ECLIPSEZONE. Improving code quality with pmd and eclipse. 2019. Disponível em:
<https:/www.eclipsezone.com//articles/pmd/>. Acesso em: 16 jan. 2019.
FINDBUGS. Find bugs in java programs. 2018. Disponível em:
<http://findbugs.sourceforge.net/>. Acesso em: 13 dez. 2018.
FOWLER, Martin. Codesmell. 2006. Disponível em:
<https://martinfowler.com/bliki/CodeSmell.html>. Acesso em: 21 mar. 2018.
GEOSERVER. Findbugs guide. 2019. Disponível em:
<https://docs.geoserver.org/latest/en/developer/findbugs-guide/index.html>. Acesso em: 16
jan. 2019.
GURU99. Learn mccabe’s cyclomatic complexity with example. 2018. Disponível em:
<https://www.guru99.com/cyclomatic-complexity.html>. Acesso em: 21 mar. 2018.
MINKOWSKI, Piotr. Code quality with sonarqube. 2017. Disponível em:
<https://piotrminkowski.wordpress.com/2017/07/20/code-quality-with-sonarqube/ >. Acesso
em: 22 mar. 2018.
OWASP. Static code analysis. 2017. Disponível em:
<https://www.owasp.org/index.php/Static_Code_Analysis >. Acesso em: 21 mar. 2018.

11. 11
PMD. An extensible cross-language static code analyzer. 2018. Disponível em:
<https://pmd.github.io/>. Acesso em: 13 dez. 2018.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.
PRESSMAN, Roger S. Engenharia de software. ed. 6. São Paulo: McGraw-Hill, 2006.
SOFTWARE TESTING HELP. Top 40 static code analysis tools. 2018. Disponível em:
<http://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools/>. Acesso em:
21 mar. 2018.
SOFTWARE TESTING HELP. What is cyclomatic complexity – learn with an example.
2018b. Disponível em: < http://www.softwaretestinghelp.com/cyclomatic-complexity/>.
Acesso em: 21 mar. 2018.
SONARQUBE. The leading product for continuous code quality. 2018. Disponível em:
<https://www.sonarqube.org/>. Acesso em: 13 dez. 2018.
SONARSOURCE. Best in class products. 2019. Disponível em:
<https://www.sonarsource.com/plans-and-pricing/community/>. Acesso em: 16 jan. 2019.
VERACODE. Static analysis: static analysis tools and platforms. 2017. Disponível em:
<https://www.veracode.com/products/static-analysis-sast/static-analysis-tool >. Acesso em:
21 mar. 2018.
WYSOPAL, Chris. What is static analysis. 2013. Disponível em:
<https://www.ministryoftesting.com/2013/07/what-is-static-analysis/>. Acesso em: 21 mar.
2018.