Alguns estudos foram realizados com objetivo de extrair dados a partir de relatórios de falhas e utilizá-los para diversos propósitos. Dentre eles, os que são mais relevantes a este trabalho, são os que utilizaram os dados para encontrar bug patterns (COELHO et al., 2015), classificar os tipos de falhas (KIM; ZIMMERMANN; NAGAPPAN, 2011) (DHALIWAL; KHOMH; ZOU, 2011) e auxiliar em sua localização (SINHA et al., 2009) (WANG; KHOMH; ZOU, 2013) (WU et al., 2014).
Coelho et al (COELHO et al., 2015) desenvolveu uma pesquisa que realizou uma mine- ração em cima dos issues reportados em projetos Android hospedados nos repositórios GitHub e Google Code. Através de uma análise automatizada em stack traces, mostrou que as exceções relacionadas às stack traces podem revelar riscos de defeitos (do inglês,
bug hazards) nos códigos de tratamento de exceção.
Kim et al (KIM; ZIMMERMANN; NAGAPPAN, 2011) utilizou como base o Windows Error Reporting (WER, crash reporter da Microsoft) e propôs uma forma de classificar as falhas, propondo uma visão agregada de múltiplos crashes (chamada de crash graphs). O WER agrega os crashes semelhantes em repositórios utilizando uma heurística que analisa os
era uma tarefa que demandava esforço. O crahs graph tem por objetivo facilitar a tarefa de triagem, fornecendo uma visão de mais alto nível nos repositórios de crashes.
Dhaliwal et al (DHALIWAL; KHOMH; ZOU, 2011) também propôs uma melhor classi- ficação de falhas, através de uma análise de similiaridade de stack traces, e avaliou se o agrupamento de falhas pode reduzir o esforço de suas correções.
Programadores podem perder um certo tempo localizando falhas reportadas. Por este motivo, alguns trabalhos também foram propostos para auxiliar nesta localização. Sinha et al (SINHA et al., 2009) apresentou uma abordagem para localização de falhas de runtime, como null pointers e falhas aritméticas (e.g., ArithmeticException). A abordagem consiste em duas fases: a primeira na localização do ponto no código-fonte onde a exceção foi lançada. A segunda fase consiste na correção da falha, provendo informações de outras instruções no código que estão relacionada a esta exceção e também podem causar erros de runtime. Wang et al (WANG; KHOMH; ZOU, 2013) propôs cinco regras para agrupamento de falhas, que foram aplicadas para identificar duplicações de bugs no relatório e falhas correlacionadas. Além disso, foi criado um método para localização e ranqueamento de bugs. Ainda no contexto de localização de falhas, Wu (WU et al., 2014) conduziu um estudo com base na mineração de stack traces presentes em relatórios de falhas. Uma ferramenta – chamada CrashLocator – foi desenvolvida e avaliada em cima do Mozilla Crash Reporter (MOZILLA, 2012). Seus resultados mostraram uma eficiência de
aproximadamente 50% de sucesso na localização precisa da falha e em até 67% no caso de analisar as top 10 possíveis localizações.
Fernandes (FERNANDES, 2017) propôs um estudo que realizou uma mineração de dados alimentados ao longo dos anos no site de perguntas e respostas StackOverflow (SOF)1. Os objetivos do estudo foram minerar informações sobre as interfaces excepcionais
de métodos de APIs de terceiros a partir de stack traces postadas no SOF e investigar como estas informações podem ser usadas para prevenir uncaught exceptions durante o desenvolvimento. Foi implementado um plug-in integrado à IDE Eclipse que fornece estas informações quando se fazia utilização de métodos de APIs.
Em nosso trabalho realizamos um estudo em cima de um crash reporter local, diferente- mente do trabalho anterior que investigou postagens do SOF. Buscamos identificar padrões de erros no repositório de falhas através de uma análise manual. Nossa pesquisa não propôs nenhum mecanismo de localização de falhas, mas tentamos aproximar o ambiente de desenvolvimento do programador ao crash reporter o que pode auxiliar, em tempo de
codificação, a identificação de classes associadas à falhas recentes.
6.2
Ferramentas de detecção de padrões de bugs
Diversas ferramentas de análise estática foram propostas com função de detectar padrões de bugs no código fonte a partir de regras pré-definidas. Estes padrões são categorizados em vários tipos, como corretude, code smells, vulnerabilidade, segurança, desempenho, etc. Nesta seção vamos falar um pouco de algumas ferramentas existentes como também alguns trabalhos que realizaram avaliação destas ferramentas.
A PMD (PMD, 2018) é uma aplicação open-source e se baseia em bug patterns para localizar erros no código-fonte Java. Ela permite que novos padrões possam ser escritos em Java ou em XPath. Outra ferramenta proposta foi a FindBugs (HOVEMEYER; PUGH, 2004) que também examina o código fonte e o byte-code de programas Java. Neste trabalho foram descritos um subconjunto das regras da FindBugs e foi feita uma comparação com a PMD com relação ao número de alertas gerados, mostrando que o número de alertas da FindBugs é menor em todos os experimentos feitos. Em 2016 a FindBugs foi descontinuada e sucedida pela SpotBugs, que utilizamos neste trabalho. Outra ferramenta de análise estática importante atualmente é a SonarQube (CAMPBELL; PAPAPETROU, 2013) que apresentou uma proposta de análise feita juntamente com a integração contínua de sistema. Utilizamos neste trabalho uma versão dela para o Eclipse, a SonarLint.
Alguns trabalhos foram realizados em cima destes softwares de análise de bugs, a fim de avaliar sua real eficácia. Rutar et al (RUTAR; ALMAZAN; FOSTER, 2004) avaliou cinco delas e analisou a saída (output) de cada uma. Em sua conclusão, o autor citou a grande quantidade de warnings reportado pelas ferramentas além da existência de muitos falsos positivos. Wagner (WAGNER et al., 2005) também realizou um estudo comparativo entre aplicações de detecção de bugs. Seus resultados mostraram que tais ferramentas são mais eficientes quando os padrões de bugs são programados para propósitos específicos. Além disso, também concluiu-se que o número de falsos positivos gerados é muito elevado. Araújo (ARAUJO; SOUZA; VALENTE, 2011) realizou uma avaliação da relevância dos warnings reportados pelas ferramentas FindBugs e PMD. Para isto, foi medida uma taxa de correlação entre a quantidade de warnings reportados com os erros gerados de fato.
A CrashAwareDev possui uma funcionalidade de análise estática, assim como as ferramentas citadas. Porém, buscamos as regras com base em crashes reais, buscando evitar os falsos positivos que existem nas ferramentas existentes, reduzindo o escopo
da busca por padrões a apenas características do código que podem levar a uncaught