An\'alise Est\'atica de C\'odigo-Fonte

TL;DR

This paper provides a comprehensive theoretical overview of static source code analysis, including its definitions, techniques, representations, and available tools, primarily aimed at researchers and practitioners.

Contribution

It offers a detailed summary of static analysis concepts, models, techniques, and a curated list of free tools, filling a gap in Brazilian Portuguese literature.

Findings

Summarizes key static analysis techniques and models.

Lists and describes free static analysis tools.

Highlights applications and research developments in static analysis.

Abstract

This article presents a theoretical summary of the source code static analysis, its definition, uses and applications, how static analysis is performed, their intermediate representation formats, models and most common analysis techniques, ends up presenting a set of free and freely available downloadable static analysis tools, academic software tools developed by scientists during their research work (The paper is written in Brazillian Portuguese).

Tables

Table 1. Tabela 1: Ferramentas de análise estática [ 6 ]

Nome	Descrição
2LS	Análise de terminação para programas C usando resumo interprocedural
AccessAnalysis	Cálculo de métricas IGAT e IGAM (plugin Eclipse)
CIVL	Framework para verificação de programas concorrentes
CodeBoost	Transformação source-to-source para otimização de programas C++
CSL	Verificação de modelos
CSeq	Transformação source-to-source para programas C concorrentes
Derailer	Localização de falhas de segurança em aplicações web
DOMPLETION	Sugestão de código javascript
EJB	(EJB Interceptor Analyzer) Criação de diagramas de sequência
e-munity	Verificação de segurança
Error Prone	Localização de bugs em código Java construído com o javac
FaultBuster	Refatoração de code smells
Flowgen	Criação automática de grafos UML
GUIZMO	Inferência de layout
GumTree	Comparação de mudanças
HUSACCT	verificação de conformidade arquitetural
Indus	Biblioteca de program slicing
JastAdd	Análise de código-fonte através da descrição de atributos via gramática
JFlow	Transformação source-to-source
Bogor/Kiasan	Verificação de modelos
Loopfrog	Verificação de modelos
Lotrack	Análise estática de configuração
MPAnalyzer	Análise de padrões disponível
mygcc	Verificação de programas C
PHP AiR	Um framework para análise de código PHP escrito em Rascal
protopurity	Análise de impacto
Pseudogen	Transformação de código-fonte em pseudo-código
PtYasm	Verificação de modelos
ReAssert	Localização de falhas em testes e refatoração
Sonar Qube Plug-in	Extensão do SourceMeter para análise de código Java com o SonarQube
SPARTA	Segurança pra detecção de malware
srcML	Transformação source-to-source
TACLE	Análise de tipo, construção e visualizaçao de grafos de chamada
TEBA	Transformação source-to-source
WALA	Análise estática de bytecode Java
Wrangler	Refatoração de código Erlang
SQL-CSD	A Static Code Smell Detector for SQL Queries Embedded in Java Code
ETA	Extract Timed Automata from Java programs
Jtratch	Captura de fluxos de excessão para projetos Java usando Exlipse JDT
MQCA	Identificação de padrões de querys SQL em códigos PHP
PropagationAnalysis	Software graphs, mutation testing and propagation estimer tools
PyReco	Type discovery for Python
Scala-AM	Abstract Machine Experiments using Scala
SID	A Statically-Informed Dynamic (SID) analysis toolbox

Full text

Análise Estática de Código-Fonte

Joenio Marques da Costa

joenio@joenio.me

1 Introdução

Este artigo apresenta um resumo teórico sobre análise estática de código-fonte, passando por definição, principais usos e aplicações, detalhes de como análise estática é realizada, seus formatos de representação intermediário, modelos e técnicas de análise mais comuns, finaliza apresentando um conjunto de ferramentas de análise estática de livre acesso e disponíveis livremente para download, ferramentas de software acadêmico desenvolvidas por cientistas durante seus trabalhos de pesquisa e que ainda possuem baixo reconhecimento entre seus pares [6], portanto, sendo necessária sua divulgação.

Este trabalho está licenciado sob a Licença Atribuição-CompartilhaIgual 4.0 Internacional Creative Commons. Para visualizar uma cópia desta licença, visite http://creativecommons.org/licenses/by-sa/4.0/ ou mande uma carta para Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

O código-fonte deste artigo escrito em LaTeXestá disponível em http://gitlab.com/joenio/analise-estatica.

2 Análise estática de código-fonte

A análise estática de código-fonte é o primeiro passo para coletar informações necessárias em diversas atividades de verificação, medição e melhoria da qualidade de produtos de software [7, 16]. Ela é realizada com base no código-fonte de um programa ou sistema de software, e a partir daí descobre problemas e propriedades de sua qualidade estrutural [5].

Ferramentas de análise estática estão disponíveis há décadas, em especial, para programadores. A ferramenta Lint [15], considerada a primeira ferramenta de análise estática [9], foi criada para examinar programas escritos em linguagem C e aplicar regras de tipagem mais estritas do que as regras dos próprios compiladores da linguagem.

Análise estática de código-fonte tem como objetivo prover informações acerca de um programa a partir do seu código-fonte sem necessidade de execução, e sem requerer qualquer outro artefato do programa além do próprio código.

É um ramo que possui muitas das suas abordagens em comum com os estudos da área de análise de programas (program analysis), especialmente na área de compiladores, onde atua especialmente nas primeiras etapas do processo de compilação.

A análise estática de código-fonte é considerada uma atividade meio com objetivo de suportar uma variedade de tarefas comuns da engenharia de software; muitas dessas tarefas são substancialmente úteis em atividades de manutenção. [4] define uma extensa lista dessas atividades, incluindo:

• •

Análise de performance

• •

Compreensão de programas

• •

Desenvolvimento baseado em modelos

• •

Detecção de clones

• •

Evolução de software

• •

Garantia de qualidade

• •

Localizaçao de falhas

• •

Manutenção de software

• •

Recuperação arquitetural

• •

Testes

Seja em qual atividade for, a análise estática possui uma importância significativa, pois ao ser capaz de extrair informações diretamente do código-fonte de um programa, pode auxiliar a responder perguntas necessárias para as diversas atividades de desenvolvimento e evolução de software. Esta importância se torna ainda mais aparente diante da “lei” da tendência para execução [12] que indica que todos os tipos de notação tem a tendência de se tornar executáveis.

3 Usos da análise estática de código-fonte

A análise de programas trata, de modo geral, da descoberta de problemas e fatos sobre programas, ela pode ser realizada sem a necessidade de executar o programa (análise estática) ou com informações provenientes de sua execução (análise dinâmica).

A idéia de que programas de computador podem ser utilizados para analisar código-fonte de outros programas tem uma história de mais de 40 anos. O programa PFORT [23] foi projetado para localizar potenciais problemas na portabilidade de código Fortran; em função da diversidade de dialetos de Fortran, uma compilação sem erros não indicava que o programa estava correto segundo os padrões da linguagem [25].

Desde então, ferramentas de análise estática de código-fonte têm surgido para os mais diversos fins – muitas delas a partir das pesquisas e desenvolvimentos da área de compiladores. O parser utilizado nessas ferramentas têm funcionalidades análogas aos analisadores usados em compiladores [2].

O uso de tais ferramentas tem se tornado mais e mais comum no ciclo de desenvolvimento de software, sendo aplicadas em uma infinidade de atividades distintas visto que o campo de aplicação destas ferramentas é bastante variado, cobrindo diferentes objetivos e atividades [5].

3.1 Verificação de tipos

A forma mais amplamente utilizada de análise estática, e uma das quais os programadores estão mais familiarizados, é a checagem de tipo. Programadores dão pouca atenção a isto, visto que as regras são definidas pela linguagem de programação e executadas pelo próprio compilador, de forma que não se torna necessário entender como a análise acontece. No entanto, esta atividade de verificação é análise estática e elimina toda uma categoria de erros de programação. Por exemplo, previne que programadores acidentalmente atribuam valores de forma incorreta a variáveis. Ainda, ao capturar erros em tempo de compilação, esta checagem de tipo previne erros em tempo de execução.

3.2 Verificação de estilo

Os verificadores de estilo são um tipo de análise estática que aplicam regras de forma mais superficial do que os verificadores de tipo. São regras relacionadas a espaços em branco, nomes, funções depreciadas, comentários, estrutura do programa, entre outros. A maioria dos verificadores de estilo costumam ser bem flexíveis quanto ao conjunto de regras que aplicam uma vez que os programadores costumam ser bastante apegados aos seus próprios estilos de programação. Os erros reportados por verificadores de estilo são aqueles que afetam a leitura e a manutenabilidade do código-fonte, não indicando potenciais erros em tempo de execução como fariam os verificadores de tipo.

3.3 Compreensão de programas

Ferramentas de compreensão de programa ajudam programadores a terem uma visão clara frente a grandes programas de computador, ou seja, programas com alto volume de código-fonte. Ambientes de desenvolvimento integrados (IDE) geralmente incluem funcionalidade de compreensão, por exemplo, “encontrar todos os usos de um certo método” ou “encontrar a declaração de uma variável global”. Análises mais avançadas chegam a incluir, por exemplo, refatoração automática. Estas ferramentas de compreensão também são úteis para programadores interessados em entender código-fonte escrito por outros programadores.

3.4 Verificação de programas

Ferramentas de verificação de programa aceitam como entrada uma especificação e um conjunto de código-fonte e tenta provar que o código está deacordo com a especificação. Quando a especificação é uma descrição completa de todo o programa, a ferramenta de verificação poderá realizar uma checagem de equivalência para garantir que o código-fonte e a especificação combinam de forma exata. Programadores raramente têm acesso a uma especificação detalhada suficientemente para ser usada numa checagem de equivalência, o trabalho de criar esta especificação pode ser maior do que o trabalho de escrever o próprio código-fonte do programa, desta forma este tipo de verificação formal raramente acontece. Sendo mais comum a verificação em relação a uma especificação parcial que detalha apenas parte do comportamento do programa. Isto costuma ser chamado de verificação de propriedade, grande parte das ferramentas de verificação de propriedade funcionam aplicando inferências lógicas ou verificação de modelos.

3.5 Localização de bugs

O propósito de uma ferramenta de localização de bugs não está em questões de formatação, como é a verificação de estilo, nem em realizar uma exaustiva e completa comparação contra uma especificação, como uma ferramenta de verificacao de programa. Ao invés disso, um localizador de bugs está preocupado em apontar locais onde o programa, possivelmente, irá se comportar de forma inesperada. A maioria das ferramentas de localização de bugs são fáceis de usar porque costumam vir com um conjunto de regras (bug idioms) para descrição de padrões de código que indicam bugs. Algumas destas ferramentas costumam usar os mesmos algoritmos utilizados por ferramentas de verificação de propriedade.

3.6 Avaliação de segurança

Ferramentas de análise estática para segurança usam as mesmas técnicas encontradas nas outras ferramentas, mas por ter um propósito diferente, identificar problemas de segurança, aplicam estas técnicas de forma diferente. As primeiras ferramentas de segurança (ITS4, RATS, Flawfinder) eram pouco mais do que um “grep” melhorado; na maior parte, elas escaneavam o código procurando por funções como por exemplo “strcpy()” que são facilmente usadas de forma inadequada e devem ser inspecionadas manualmente no processo de revisão de código-fonte. A evolução deste tipo de ferramenta de segurança levou a técnicas híbridas de verificação de propriedade e de localização de bugs, de forma que muitas propriedades de segurança podem ser suscintamente expressas como propriedades de programas.

4 Anatomia da análise de código-fonte

Ferramentas de análise estática de código-fonte estão organizadas em partes ou componentes, responsáveis por implementar três funções básicas [7, 4]: a) extração de dados, b) geração de representação intermediária, e c) análise. A ferramenta de análise de código-fonte CodeSonar111https://www.grammatech.com/products/codesonar, por exemplo, segue tal organização e realiza cada uma das 3 funções em etapas distintas, conforme mostra a Figura 1.

4.1 Extração de dados

O processo de recuperar dados para futuro processamento ou armazenamento é chamado de extração de dados, é o primeiro componente da análise de código-fonte e é responsável por ler o código-fonte do programa e gerar uma ou mais representações intermediárias. Em essência, este componente converte a sintaxe de um programa em uma outra sintaxe abstrata e mais adequada para análise posterior. Este componente é usualmente chamado de analisador sintático (ou parser) e apesar de teoricamente não ser uma tarefa difícil, apresenta enormes desafios diante da complexidade das linguagens de programação modernas.

4.2 Representação intermediária

Exportar os dados extraídos para uma representação intermediária é uma estratégia comum para facilitar análise e transformação de dados e possivelmente adição de metadados.

Os dados obtidos na extração precisam ser representados em um formato mais abstrato. Esta é a responsabilidade do segundo componente da análise de código-fonte: armazenar os dados coletados usando uma representação intermediária em formato mais adequado para análise automática, abstraindo aspectos particulares do programa e da linguagem de programação.

Alguns tipos de representação intermediária têm sua origem na área de compiladores; algumas delas são produzidas diretamente pelo parser enquanto outras requerem uma análise específica. Os formatos mais comuns são geralmente baseados em grafos. Alguns formatos comumente utilizados são:

• •

Árvore sintática abstrata

• •

Grafo de fluxo de controle

• •

Árvore sintática abstrata decorada

• •

Grafo de dependência de módulos

• •

Atribuição estática única

• •

Grafo de dependência de valores

Estas representações podem ser utilizadas tanto na análise estática quanto na análise dinâmica. O uso de um ou outro formato depende do tipo de análise e seu propósito. Pode-se combinar diferentes tipos no sentido de enriquecer e estruturar a informação extraída.

4.3 Análise

Este componente é responsável por realizar inferências a partir dos dados representados internamente. O processo requer que as informações armazenadas estejam interconectadas e também interrelacionadas com conhecimento anterior. Esta análise pode gerar conhecimento quantitativo ou qualitativo, como, por exemplo, métricas de software ou mineração de dados, respectivamente. Técnicas de visualização podem ser usadas para apoiar este processo.

Diversas técnicas foram desenvolvidas ao longo do tempo para realizar análise, algumas delas são brevemente descritas na seção 6.

5 Formatos de representação intermediária

Essencialmente, um formato de representação intermediária é uma abstração precisa das propriedades de um programa representado em um domínio menor. Os compiladores normalmente constroem esta representação a fim de possuir um modelo do programa sendo compilado, é comum que compiladores utilizem diversos formatos durante o curso da compilação.

Em ferramentas de análise estática estes formatos são utilizados durante a fase de análise para cumprir diversos objetivos, como por exemplo, calcular métricas de código-fonte. A métrica de complexidade ciclomática de McCabe [19], por exemplo, é definida com base no grafo de fluxo de controle (Control Flow Graph - CFG) do programa com o seguinte cálculo $CC=e-n+2p$. Onde: e é o número de arestas; n é o número de nós; e p é o número de componentes fortemente conectados no grafo.

Assim, percebe-se que cada formato de representação intermediária [20, 24, 7, 22] pode ter fins e objetivos bastante distintos.

5.1 Árvore sintática abstrata

A árvore sintática abstrata (AST - Abstract Syntax Tree) representa um programa tratando os elementos do código-fonte como operadores e operandos organizados em nós numa árvore, este formato de representação é muito popular em tradutores source-to-source222http://en.wikipedia.org/wiki/Source-to-source_compiler.

5.2 Grafo de fluxo de controle

O grafo de fluxo de controle (CFG - Control Flow Graph ou Call Graph) é um grafo direcionado representando a estrutura de controle de um programa e sua sequência de instruções, onde as arestas mostram os possíveis caminhos de execução. Este formato é amplamente utilizado em métodos formais para otimização de código-fonte.

5.3 Grafo de fluxo de dados

O grafo de fluxo de dados (DFG - Data Flow Graph) é também um grafo direcionado onde as arestas representam o fluxo de dados entre as operações do programa, este formato pode ser visto como um companheiro do grafo de fluxo de controle (CFG) e pode ser gerado ao longo de uma mesma análise.

5.4 Árvore sintática abstrata decorada

Árvore sintática abstrata decorada (DAST - Decorated Abstract Syntax Tree) é uma árvore sintática abstrata (AST) melhorada através de um processo de definiçao de atributos para os símbolos do programa de forma declarativa com uso de uma Gramática de Atributos333https://en.wikipedia.org/wiki/Attribute_grammar.

5.5 Grafo de dependência de módulos

O grafo de dependência de módulos (MDG - Module Dependence Graph) é um grafo onde os módulos são representados como nós e as arestas representam as relacões entre eles, indicando dependência entre os mesmos.

5.6 Atribuição estática única

Atribuição estática única (SSA - Static Single Assignment) pode ser vista como uma variação ou uma propriedade de outros formatos de representação intermediária, é um método que faz cada variável ser atribuída apenas uma única vez, facilitando a descoberta de informaçoes sobre os dados representados.

5.7 Grafo de dependência de valores

O grafo de dependência de valores (VDG - Value Dependence Graph) é uma variação que melhora (ao menos para algumas análises) os resultados obtidos a partir da atribuição estática única (SSA). Ele representa tanto o fluxo de controle quanto o fluxo de dados e assim simplifica a análise.

[26] enumera e descreve uma quantidade significativa de grafos de representação interna para programação funcional.

6 Técnicas de análise

Inúmeras técnicas e métodos distintos podem ser utilizados pelas ferramentas de análise estática, seja com o objetivo de verificação de tipos, localização de bugs, compreensão de programas, avaliação de segurança, ou outra finalidade qualquer. Segundo [8, 17, 13] as técnicas e métodos mais comumente encontrados nas ferramentas atuais são apresentados a seguir.

Análise léxica. A análise léxica é responsável por quebrar o programa em pequenos fragmentos (ou tokens) e verificar se estes fragmentos são palavras válidas para uma dada linguagem. A análise léxica não leva em consideração a sintaxe do programa, sua semântica ou a interação entre módulos.

Combinação de padrões de texto. A combinação de padrões de texto (Text-based Pattern Matching) é a maneira mais simples e rápida de procurar vulnerabilidades num código-fonte.

Inferência de tipos. A inferência de tipos (Type inference) refere-se a identificar o tipo de variáveis e funções e avaliar se o acesso a elas está em conformidade com as regras da linguagem. Linguagens de programação com sistema de tipagem incluem mecanismos deste tipo de análise.

Análise de fluxo de dados. A análise de fluxo de dados (Data flow analysis) resume-se a coletar informação semântica do código-fonte do programa, e com métodos algébricos deduzir a definição e uso das variáveis em tempo de compilação. O objetivo é mostrar que nenhum caminho de execução do programa acessa uma variável sem definição ou atribuição prévia.

Verificação de regra. A verificação de regra (Rule checking) consiste em checar a segurança do programa através de um conjunto de regras pré-estabelecidas.

Análise de restrição. A análise de restrição (Constraint analysis) consiste em gerar e resolver restrições no processo de análise de um programa.

Comparação de caminho. Comparação de caminho (Patch comparison) inclui comparação de caminho de código-fonte e de código-binário e é usada principalmente para encontrar brechas de vulnerabilidade já “conhecidas” e previamente divulgadas por fornecedores e praticantes da indústria de software.

Execução simbólica. A execução simbólica (Symbolic execution) é usada para representar as entradas de um programa através do uso de valores simbólicos ao invés de dados reais, produz expressões algébricas sobre a entrada dos símbolos do programa durante o processo de implementação e pode detectar possibilidade de erros.

Interpretação abstrata. Interpretação abstrata (Abstract interpretation) é uma descrição formal da análise do programa. Pelo fato de apenas controlar atributos de programa de preocupaçao dos usuários, a interpretação da análise semântica é similar ao seu significado semântico real.

Prova de teoremas. Prova de teoremas (Theorem proving) é baseada na análise semântica do programa. Converte o programa em fórmulas lógicas e então tenta provar que o programa é um teorema válido usando regras e axiomas.

Verificação de modelo. O processo de verificação de modelos (Model checking) primeiro constrói um modelo formal do programa tal como uma máquina de estados ou um grafo direcionado, então examina e compara o modelo para verificar se o sistema cumpre as características pré-definidas. Esta técnica requer a definição e descrição das propriedades que devem ser verificados por um pedaço de software.

Verificação formal. Verificação formal (Formal Checking ou Compliance Analysis) é o processo de provar de forma automatizada que o código do programa está correto em relação a uma especificação formal dos seus requisitos.

Análise de fluxo da informação. Análise de fluxo da informação (Information Flow Analysis) identifica como a execução de uma unidade de código cria dependência entre entradas e saídas.

Verificação de sintaxe. Verificação de sintaxe (Syntax Checks) tem o objetivo de encontrar violação de regras tais como expressões mal-formadas ou fora do padrão.

Verificação de intervalo. A análise de verificação de intervalo (Range Checking) tem o objetivo de verificar que os valores dos dados permanecem dentro de intervalos especificados, bem como manter a precisão especificada.

Diante a variedade e a constante evolução da área de análise estática [21] fez um estudo propondo uma taxonomia e um conjunto de dimensões para caracterização de ferramentas de análise estática, lá é possível obter uma visão ampla e abrangente dos conteitos e temas da área.

7 Ferramentas de análise estática

A variedade de aplicação e a constante evolução da área de análise estática, tanto na indústria quando na academia, resulta em estudos teóricos e práticos, novas ferramentas, modelos e algoritmos de análise estática. Ferramentas de análise estática têm sido continuamente desenvolvidas e seu uso se tornado comum no ciclo de desenvolvimento de software.

Análise estática é a técnica mais amplamente utilizada para análise automatizada de programas devido a sua eficiência, boa cobertura e automação. Estudos mostram que analise estática tem grande adoção em projetos de software livre [3]. Entretanto, técnicas de análise estática amplamente adotadas na comunidade de software, por exemplo, para localização de bugs e verificação de programas ainda sofrem um alto índice de falso-positivos [10].

Apesar da ampla adoção de ferramentas de análise estática em estudos acadêmicos e da crescente atenção que as técnicas de análise estática de código tem recebido em pesquisas, nota-se ainda uma enorme distância entre a atenção dada na academia e sua adoção na indústria, identificando um gap entre estes dois contextos [14].

Mesmo diante das dificuldades, pesquisadores e cientistas continuam contribuindo com ferramentas de análise estática, o seu reconhecimento, apesar de tímido, vem crescendo, a Tabela 1 apresenta um conjunto dessas ferramentas com informação para download e breve descrição de suas principais funções. Estas ferramentas precisam ser divulgadas, avaliadas e acima de tudo apropriadas pela comunidade científica, evoluídas e tratadas como um bem comum para um avanço geral da qualidade, maturidade e confiabilidade dessas ferramentas tão importantes para pesquisas nas diversas áreas da Engenharia de Software.

8 Conclusão

Análise estática é uma área de estudo da Engenharia de Software com um largo histórico e em constante evolução, possui uma grande contribuição da academia na construção de ferramentas de software, mas ainda carece de colaboração entre seus pares num esforço para reduzir as limitações e inconsistências ainda existentes [1], essas limitações possuem relevância e devem chamar a atenção de todos aqueles que trabalham com análise estática, visto que podem levar pesquisadores a obter resultados inconsistentes [18], isto inclui pesquisas sobre métricas, qualidade, visualização, arquitetura, testes, manutenção e diversas outras áreas que tenham como objeto de estudo o software e o seu principal artefato, o código-fonte.

Assim, reforço a importância divulgar, avaliar e colaborar com as ferramentas de análise estática apresentadas na Tabela 1, projetos de software acadêmico, desenvolvidos por cientistas durante suas pesquisas, disponibilizados livremente, e que ainda possuem baixo ou nenhum reconhecimento.

Referências

• [1]

Khalid Alemerien and Magel Kenneth.

Experimental Evaluation of Static Source Code Analysis Tools.

Th e11th Internaitonal Conference on Software Engineering Research and Practice, July 2013.

• [2]

Paul Anderson.

The use and limitations of static-analysis tools to improve software quality.

CrossTalk: The Journal of Defense Software Engineering, 21(6):18–21, 2008.

• [3]

Moritz Beller, Radjino Bholanath, Shane McIntosh, and Andy Zaidman.

Analyzing the state of static analysis: A large-scale evaluation in open source software.

In Software Analysis, Evolution, and Reengineering (SANER), 2016 IEEE 23rd International Conference on, volume 1, pages 470–481, 2016.

• [4]

David Binkley.

Source code analysis: A road map.

In 2007 Future of Software Engineering, pages 104–119. IEEE Computer Society, 2007.

• [5]

Brian Chess and Jacob West.

Secure programming with static analysis.

Pearson Education, 2007.

• [6]

Joenio Costa, Paulo Meirelles, and Christina Chavez.

On the sustainability of academic software: the case of static analysis tools.

In Proceedings of the XXXII Brazilian Symposium on Software Engineering, pages 202–207. ACM, 2018.

• [7]

Daniela da Cruz, Pedro Rangel Henriques, and Jorge Sousa Pinto.

Code analysis: Past and present.

• [8]

Andy German.

Software static code analysis lessons learned.

Crosstalk, 16(11):19–22, 2003.

• [9]

Anjana Gosain and Ganga Sharma.

Static analysis: A survey of techniques and tools.

In Intelligent Computing and Applications, pages 581–591. Springer, 2015.

• [10]

Anjana Gosain and Ganga Sharma.

Static analysis: A survey of techniques and tools.

In Intelligent Computing and Applications, pages 581–591. Springer, 2015.

• [11]

GrammaTech.

Source code analysis with codesonar.

online, 06 2016.

[online; acessado em 27 Julho 2016].

• [12]

Mark Harman.

Why source code analysis and manipulation will always be important.

In Source Code Analysis and Manipulation (SCAM), 2010 10th IEEE Working Conference on, pages 7–19, 2010.

• [13]

Thomas Hofer.

Evaluating Static Source Code Analysis Tools.

PhD thesis, Citeseer, 2010.

• [14]

Bilal Ilyas and Islam Elkhalifa.

Static code analysis: A systematic literature review and an industrial survey, 2016.

• [15]

S. C. Johnson.

Lint, a c program checker.

In COMP. SCI. TECH. REP, pages 78–1273, 1978.

• [16]

Radoslav Kirkov and Gennady Agre.

Source code analysis - an overview.

Cybernetics and Information Technologies, 10(2):60–77, 2010.

• [17]

Peng Li and Baojiang Cui.

A comparative study on software vulnerability static analysis techniques and tools.

In Information Theory and Information Security (ICITIS), 2010 IEEE International Conference on, pages 521–524, 2010.

• [18]

Rüdiger Lincke, Jonas Lundberg, and Welf Löwe.

Comparing Software Metrics Tools.

In Proceedings of the 2008 International Symposium on Software Testing and Analysis, ISSTA ’08, pages 131–142, New York, NY, USA, 2008. ACM.

• [19]

Thomas J. McCabe.

A complexity measure.

Software Engineering, IEEE Transactions on, (4):308–320, 1976.

• [20]

Flemming Nielson, Hanne R. Nielson, and Chris Hankin.

Principles of program analysis.

Springer, 2015.

• [21]

Jernej Novak, Andrej Krajnc, et al.

Taxonomy of static code analysis tools.

In MIPRO, 2010 Proceedings of the 33rd International Convention, pages 418–422. IEEE, 2010.

• [22]

José Carlos Ramalho, Jose Joao Almeida, and Pedro Rangel Henriques.

Document semantics: two approaches.

• [23]

Barbara G. Ryder.

The pfort verifier.

Software: Practice and Experience, 4(4):359–377, 1974.

• [24]

James Stanier and Des Watson.

Intermediate representations in imperative compilers: A survey.

ACM Computing Surveys (CSUR), 45(3):26, 2013.

• [25]

BA Wichmann, AA Canning, DL Clutterbuck, LA Winsborrow, NJ Ward, and DWR Marsh.

Industrial perspective on static analysis.

Software Engineering Journal, 10(2):69, 1995.

• [26]

Vadim Zaytsev.

Using dependence graphs for slicing functional programs.