Os Defeitos Detectados pela Ferramenta de An´alise Est´atica
FindBugs s˜ao Relevantes?
Jo˜ao Eduardo de Ara ´ujo Filho1, S´ılvio Jos´e de Souza1, Marco T ´ulio Valente2 1Instituto de Inform´atica, PUC Minas
2Departamento de Ciˆencia da Computac¸˜ao, UFMG
[email protected], [email protected], [email protected] Resumo. Neste artigo relata-se um experimento elaborado com o objetivo de avaliar se defeitos detectados pela ferramenta de an´alise est´atica FindBugs s˜ao relevantes. O experimento envolveu uma an´alise retrospectiva de cinco vers˜oes da plataforma Eclipse. A ferramenta de an´alise est´atica avaliada foi o Find-Bugs. Os resultados obtidos mostraram que taxas elevadas de relevˆancia – superiores a 40% – somente s˜ao obtidas caso os desenvolvedores adaptem as prioridades dos defeitos reportados por ferramentas de an´alise est´atica ao perfil do sistema que est´a sendo analisado.
Abstract. In this paper, we describe an experiment designed to evaluate whether the defects detected by FindBugs – a static analysis tool – are relevant. In this experiment, we have retrospectively evaluated five versions of the Eclipse platform, using the FindBugs static analysis tool. Our results indicate that high relevant defects rate – superior to 40% – are only achieved after customizing the priorities of the defects detected by such tools in order to consider particular characteristics of the system under evaluation.
1 Introduc¸˜ao
Ferramentas de an´alise est´atica – tais como PREfix/PREfast [5], FindBugs [3] e PMD [2] – est˜ao sendo cada vez mais usadas para ajudar na detecc¸˜ao de defeitos em sistemas de software. Essas ferramentas procuram encontrar estaticamente – isto ´e, sem requerer a execuc¸˜ao do sistema – diversos tipos de defeitos que s˜ao recorrentes em sistemas de software. Como exemplo , podemos citar acesso a referˆencias null, uso inapropriado de APIs, overflow em vetores, divis˜ao por zero etc. No entanto, ainda n˜ao existe um um n´umero significativo de trabalhos que permitam a gerentes de qualidade de software obter respostas claras para a seguinte quest˜ao: os defeitos detectados por ferramentas de an´alise est´atica s˜ao relevantes?
A fim de contribuir com uma resposta objetiva para essa pergunta, assume-se como hip´otese neste artigo que um defeito introduzido em uma vers˜ao i de um sistema ´e relevante quando ele ´e removido em uma vers˜ao j liberada no m´aximo t unidades de tempo ap´os a vers˜ao i. Em outras palavras, o pressuposto ´e que se o tempo de vida de um defeito ´e maior que t, ent˜ao ele n˜ao ´e relevante. Provavelmente, defeitos n˜ao-relevantes n˜ao s˜ao removidos rapidamente porque eles n˜ao originam falhas, n˜ao impactam requisitos n˜ao-funcionais, n˜ao comprometem atributos de qualidade interna etc. Por outro lado, se um defeito ´e removido rapidamente, isso indica que ele ´e relevante.
Baseado nessa definic¸˜ao de relevˆancia, relata-se neste artigo uma experiˆencia en-volvendo a aplicac¸˜ao retrospectiva de uma ferramenta de an´alise est´atica em diversas vers˜oes de um sistema real. A ferramenta escolhida foi o sistema FindBugs [3], que ´e uma das ferramentas mais usadas atualmente para an´alise est´atica de programas Java. Mais es-pecificamente, a experiˆencia teve como objetivo determinar o tempo de vida dos defeitos apontados por essa ferramenta quando aplicada retrospectivamente ao c´odigo fonte de cinco vers˜oes da plataforma de desenvolvimento Eclipse. Al´em de largamente utilizado como ambiente de desenvolvimento, o Eclipse ´e um projeto complexo e de grande porte. Por exemplo, todas as vers˜oes analisadas no estudo possuem pelo menos um milh˜ao de linhas de c´odigo.
O restante deste artigo est´a organizado conforme descrito a seguir. Na Sec¸˜ao 2, descreve-se a metodologia adotada no experimento descrito no trabalho. Na Sec¸˜ao 3, procura-se responder `a quest˜ao central proposta no artigo, analisando para isso os resul-tados do experimento realizado. Na Sec¸˜ao 4, s˜ao feitas considerac¸˜oes sobre a validade desses resultados. A Sec¸˜ao 5 discute trabalhos relacionados e a Sec¸˜ao 6 descreve as con-clus˜oes da pesquisa.
2 Metodologia
Nesta sec¸˜ao, s˜ao fornecidas informac¸˜oes sobre a ferramenta FindBugs, as vers˜oes anali-sadas do Eclipse e a estrat´egia usada para estimativa do tempo de vida de defeitos.
Ferramenta de An´alise Est´atica: A experiˆencia utilizou a vers˜ao 1.3.6 da ferramenta FindBugs. O FindBugs foi sempre executado em modo texto com a opc¸˜ao -high ligada. Essa opc¸˜ao indica que apenas bugs de alta prioridade devem ser reportados.
Vers˜oes do Eclipse: Foram analisadas cinco vers˜oes da plataforma Eclipse, todas elas com identificador principal igual a 3.x. Essas vers˜oes, incluindo informac¸˜oes sobre a data de liberac¸˜ao e tamanho do c´odigo fonte, s˜ao descritas na Tabela 1. A primeira vers˜ao ana-lisada foi disponibilizada em junho de 2004 e a ´ultima vers˜ao em setembro de 2008. A primeira vers˜ao analisada possui pouco mais de um milh˜ao de linhas de c´odigo (MLOC); j´a a ´ultima vers˜ao possui mais de 1.7 milh˜oes de linhas de c´odigo. Na Tabela 1, mostra-se tamb´em o tempo que o FindBugs levou para analisar e apontar os defeitos de cada uma das vers˜oes. Esse tempo variou entre 28 minutos (vers˜ao 3.0) e 48 minutos (ves˜ao 3.4)1.
C´alculo do Tempo de Vida: Para execuc¸˜ao do FindBugs e c´alculo do tempo de vida dos defeitos reportados por essa ferramenta, foi implementado um script em Perl. Basica-mente, esse script recebe como entrada um arquivo texto com o diret´orio onde encontra-se cada uma das vers˜oes a serem analisadas. Ele ent˜ao executa o FindBugs sobre cada uma dessas vers˜oes. Em seguida, o arquivo de sa´ıda gerado pelo FindBugs – contendo os defeitos reportados pela ferramenta – ´e processado a fim de gerar um novo arquivo com uma assinatura ´unica para cada defeito. Essa assinatura cont´em as seguintes informac¸˜oes: identificador do defeito e sua localizac¸˜ao no c´odigo, incluindo pacote, classe e m´etodo.
1O experimento foi executado em uma m´aquina com processador AMD Turion x2 64, 2.0 Ghz, com 2
Vers˜ao Data MLOC Tempo 3.0 junho 2004 1.004 28 3.1 junho 2005 1.210 31 3.2 junho 2006 1.440 39 3.3 junho 2007 1.585 42 3.4 junho 2008 1.771 48
Tabela 1. Vers ˜oes do Eclipse, incluindo tamanho (MLOC= milh ˜oes de LOC) e tempo de execuc¸ ˜ao do FindBugs (em minutos)
Em seguida, os arquivos de assinatura s˜ao processados, a fim de estimar o inter-valo de vida dos defeitos reportados. O interinter-valo de vida de um defeito ´e definido pelo par (vp, vq), onde vp designa a vers˜ao onde o defeito foi detectado pela primeira vez e vq designa a vers˜ao onde o defeito foi corrigido. Se o defeito ainda n˜ao foi corrigido, ent˜ao vq = ∞. Por fim, supondo vq 6= ∞, o tempo de vida de um defeito ´e dado pela seguinte diferenc¸a: date(vq) − date(vp), onde date(v) ´e a data de liberac¸˜ao da vers˜ao v.
Defeitos Analisados: Dentre os defeitos reportados pelo FindBugs, foram analisados no trabalho apenas aqueles que atendem `as seguintes condic¸˜oes:
• Defeitos que ocorrem em pacotes internos da plataforma Eclipse (isto ´e, pacotes org.eclipse.*). Como o FindBugs analisa bytecodes, ele tamb´em ´e capaz de detectar defeitos que ocorrem, por exemplo, em bibliotecas externas (arquivos .jar). No entanto, tais defeitos foram desconsiderados, devido `a inexistˆencia do c´odigo fonte dos m´odulos onde eles ocorreram.
• Defeitos que ocorreram em m´etodos, classes e pacotes que n˜ao foram renomeados em uma das vers˜oes analisadas. Conforme afirmado, a assinatura de um defeito inclui o m´etodo, classe e pacote de sua ocorrˆencia. Assim, caso um desses itens tenha sido renomeado, o algoritmo utilizado para processamento do tempo de vida iria considerar que o mesmo foi corrigido e que um novo defeito surgiu no m´etodo, classe e/ou pacote resultantes da renomeac¸˜ao. Portanto, para evitar essa distorc¸˜ao, o estudo se concentrou em defeitos detectados em m´etodos, classes e pacotes presentes em todas as cinco vers˜oes analisadas da plataforma Eclipse. Para cada vers˜ao do Eclipse, a Tabela 2 apresenta o total de defeitos reportados pelo FindBugs e o total de defeitos considerados no estudo. Como pode ser observado nesta tabela, a amostra de defeitos considerada cobre de 59% a 87% do universo de de-feitos reportados pelo FindBugs. Al´em disso, dentre os dede-feitos desconsiderados, a maior parte ´e sempre relativa a defeitos em bibliotecas externas (Coluna B) do que em entidades renomeadas (Coluna C).
3 Resultados
A Tabela 3 resume a aplicac¸˜ao do FindBugs em cada uma das cinco vers˜oes consideradas no estudo. Para cada vers˜ao i do Eclipse, a tabela mostra o n´umero total de defeitos apon-tados pelo FindBugs nesta vers˜ao (na ´ultima linha). Dentre tais defeitos, a tabela detalha ainda quantos s˜ao defeitos novos e quantos s˜ao defeitos inseridos em vers˜oes anteriores.
Vers˜ao Total (A) Externos (B) Rename (C) D=A-B-C D/A 3.0 848 234 111 503 59% 3.1 887 231 59 597 67% 3.2 1043 276 53 714 68% 3.3 1162 336 24 802 69% 3.4 1111 142 0 969 87%
Tabela 2. Total de defeitos reportados pelo FindBugs (Coluna A), total de defeitos em bibliotecas externas (Coluna B), total de defeitos em entidades que foram renomeadas (Coluna C) e total de defeitos avaliados no estudo (Coluna D)
Por exemplo, na vers˜ao 3.2, a execuc¸˜ao do FindBugs reportou um total de 714 defeitos, sendo que 376 foram inseridos pela primeira vez na vers˜ao 3.0, 184 defeitos foram inse-ridos na vers˜ao 3.1 e 154 defeitos s˜ao novos, isto ´e, foram inseinse-ridos pela primeira vez na pr´opria vers˜ao 3.2.
Vers˜ao N ´umero de defeitos 3.0 3.1 3.2 3.3 3.4 3.0 503 394 376 355 350 3.1 - 203 184 175 177 3.2 - - 154 142 130 3.3 - - - 130 122 3.4 - - - - 190 Total 503 597 714 802 969
Tabela 3. Rastreamento dos defeitos
Analisando-se as linhas da Tabela 3, pode-se rastrear o tempo de vida dos defeitos existentes em uma vers˜ao. Por exemplo, dos 503 defeitos apontados pela primeira vez na vers˜ao 3.0, 394 continuavam presentes na vers˜ao 3.1, 376 defeitos continuavam presentes na vers˜ao 3.2 e assim sucessivamente at´e a vers˜ao 3.4, quando restavam 350 dos 503 de-feitos detectados originalmente (isto ´e, cerca de 70%).
Defeitos Relevantes: No estudo realizado, um defeito ´e considerado relevante quando o seu tempo de vida ´e menor que um determinado limiar t. Na Tabela 4, para as vers˜oes 3.x, mostra-se o percentual de defeitos relevantes, considerando os seguintes intervalos de tempo: 12 meses, 24 meses e 36 meses. Para a vers˜ao 3.2, o limite de 36 meses ultrapassa os limites de tempo considerados no estudo (e por isso n˜ao foi considerado). Fato semelhante ocorreu na vers˜ao 3.3 para os limites de 24 e 36 meses.
Conforme pode ser observado na Tabela 4, o percentual de defeitos relevantes va-riou de 6.2% (vers˜ao 3.3, t= 12 meses) a 29.4% (vers˜ao 3.0, t= 36 meses). Em resumo, no melhor caso, os desenvolvedores do Eclipse ap´os 36 meses n˜ao removeram cerca de 70% dos supostos defeitos apontados pelo FindBugs.
Defeitos mais Comuns: A fim de entender as raz˜oes pelas quais os desenvolvedores – ap´os trˆes anos – n˜ao removeram a maioria dos defeitos, a Tabela 5 mostra os tipos de
Vers˜ao Limiar de tempo t 12 meses 24 meses 36 meses
3.0 21.7 25.3 29.4
3.1 9.4 13.8 12.8
3.2 7.8 15.6
-3.3 6.2 -
-Tabela 4. Percentual de defeitos relevantes
defeitos mais comuns apontados pelo FindBugs quando aplicado `a vers˜ao 3.0 do Eclipse, junto com o total de ocorrˆencias dos mesmos. Mostra-se tamb´em o percentual dessas ocorrˆencias em relac¸˜ao ao total de defeitos apontados pelo FindBugs.
Defeito Ocorr. %
MS SHOULD BE FINAL 191 38.0
ST WRITE TO STATIC FROM INSTANCE METHOD 95 18.9
HE EQUALS USE HASHCODE 38 7.5
MS MUTABLE ARRAY 35 7.0
Total 359 71.4
Tabela 5. Tipos de defeitos mais comuns (Eclipse, vers ˜ao 3.0)
Conforme mostra a Tabela 5, os quatro tipos de defeitos mais comuns representam 71.4% do total de 503 ocorrˆencias de defeitos. A seguir descreve-se brevemente esses quatro defeitos:
• MS SHOULD BE FINAL: Esse tipo de defeito – que representa 38% do total de ocorrˆencias – ´e reportado pelo FindBugs quando encontra campos est´aticos n˜ao declarados como final. A justificativa descrita na documentac¸˜ao do FindBugs ´e que tais campos podem ser modificados a partir de outros pacotes, possivelmente contendo c´odigo malicioso. Logo, ´e um tipo de defeito relevante apenas em sis-temas que acessam dados que requerem algum grau de sigilo e integridade. No entanto, esse n˜ao ´e o caso de uma plataforma de desenvolvimento, como o Eclipse.
• ST WRITE TO STATIC FROM INSTANCE METHOD: Esse tipo de defeito – respons´avel por 18.9% das ocorrˆencias de defeitos – ´e reportado quando um m´e-todo n˜ao-est´atico faz acesso a um atributo est´atico. Esse tipo de acesso pode dar origem a defeitos dif´ıceis de serem detectados quando m´ultiplos objetos chamam tais m´etodos. No entanto, em vez de um defeito de alta prioridade, ele deveria ser classificado como uma pr´atica n˜ao recomend´avel de programac¸˜ao.
• HE EQUALS USE HASHCODE: Esse aviso – respons´avel por 7% das ocorrˆen-cias totais dos defeitos – ´e reportado quando uma classe sobrescreve o m´etodo equals(Object)mas n˜ao sobrescreve o m´etodo hashCode(). Esta pr´atica, portanto, viola o contrato que diz que objetos iguais devem possuir o mesmo valor de hashcode. Este aviso foi classificado como uma bad practice.
• MS MUTABLE ARRAY: Esse defeito ´e reportado quando um campo est´atico e final referencia um vetor mut´avel. Nesses casos, alterac¸˜oes no valor do vetor, pos-sivelmente por um c´odigo malicioso, ir˜ao se refletir nesse campo. Logo, trata-se tamb´em de um defeito potencialmente importante apenas em sistemas que en-volvem acesso a bancos de dados e/ou sistemas com requisitos importantes de seguranc¸a.
Em resumo, os quatro tipos de defeitos mais comuns reportados pelo FindBugs denotam, na verdade, estilos de programac¸˜ao n˜ao recomendados ou, no m´aximo, defeitos relevantes apenas em sistemas que envolvem acesso a dados sigilosos.
An´alise dos Resultados: Com base nos resultados apresentados na Tabela 4, nossa pri-meira resposta para a pergunta proposta na introduc¸˜ao ´e a seguinte: em geral, os defeitos detectados por ferramentas de an´alise est´atica n˜ao s˜ao relevantes. Essa resposta baseou-se em resultados obtidos mesmo quando configurou-baseou-se a ferramenta FindBugs para re-portar apenas defeitos considerados como de alta prioridade (opc¸˜ao -high).
No entanto, os resultados apresentados na Tabela 5 tamb´em permitem concluir que a ferramenta FindBugs considera como de alta prioridade diversos defeitos que, na verdade, denotam diretrizes de programac¸˜ao e/ou defeitos que s˜ao relevantes em apenas alguns contextos de sistemas, como bancos de dados ou sistemas concorrentes.
A fim de melhor comprovar essa segunda conclus˜ao, foi proposta uma reclassi-ficac¸˜ao dos defeitos de alta prioridade reportados pelo FindBugs. Basicamente, a lista de defeitos da ferramenta foi analisada a fim de eliminar aqueles defeitos que na verdade constituem diretrizes de programac¸˜ao. Ap´os essa an´alise, dos 53 tipos de defeitos detec-tados pela ferramenta na ´ultima vers˜ao analisada no estudo (vers˜ao 3.4), apenas 14 foram considerados como defeitos com grande probabilidade de levar a um funcionamento in-correto de um programa. A Tabela 6 lista os identificadores desses defeitos.
NP NULL ON SOME PATH EQ ALWAYS FALSE
NP NULL PARAM DEREF HE USE OF UNHASHABLE CLASS
EC UNRELATED TYPES IL INFINITE RECURSIVE LOOP
NP NULL PARAM DEREF NONVIRTUAL BC IMPOSSIBLE CAST
EC UNRELATED CLASS AND INTERFACE EQ ALWAYS TRUE
NP ALWAYS NULL EC ARRAY AND NONARRAY
RV EXCEPTION NOT THROWN NP GUARANTEED DEREF
Tabela 6. Nova lista de defeitos priorit ´arios
Considerando-se apenas os defeitos inclu´ıdos nessa nova classificac¸˜ao de defeitos priorit´arios, mostra-se na Tabela 7 o novo percentual de defeitos relevantes detectados pelo FindBugs. Conforme pode ser verificado nessa Tabela, o percentual de defeitos relevantes sofreu um importante incremento. No pior caso (vers˜ao 3.3, t=12 meses), ele aumentou de 6.2% – conforme mostrado na Tabela 4 – para 25%, ou seja, um aumento de 303%. J´a no melhor caso (vers˜ao 3.0, t= 36 meses), o percentual de defeitos considerados relevantes aumentou de 29.4% para 59%, isto ´e, um incremento de 100%.
Em resumo, ao adotar ferramentas de an´alise est´atica, ´e fundamental que os de-senvolvedores configurem e adaptem os tipos de defeitos reportados por tais
ferramen-Vers˜ao Limiar de tempo t 12 meses 24 meses 36 meses
3.0 43.6 51.3 59.0
3.1 33.3 40.0 40.0
3.2 38.5 46.2
-3.3 25.0 -
-Tabela 7. Percentual de defeitos relevantes (utilizando nova classificac¸ ˜ao de de-feitos priorit ´arios)
tas ao perfil do sistema que est´a sendo analisado. Dessa forma, o n´umero de defeitos n˜ao-relevantes – ou falso positivos – reportados por tais ferramentas ´e substancialmente reduzido, chegando a ser inferior a 60% na maioria dos casos.
4 Riscos `a Validade do Estudo de Caso
Nesta sec¸˜ao, os resultados e as conclus˜oes do estudo descrito no artigo s˜ao avaliados se-gundo sua validade interna, externa e de construc¸˜ao.
Validade Externa: Essa forma de validade se refere ao grau de aplicabilidade das con-clus˜oes de um estudo a uma populac¸˜ao mais ampla. O estudo descrito neste trabalho envolveu um ´unico sistema (Eclipse) e uma ´unica ferramenta de an´alise est´atica (Find-Bugs), o que a princ´ıpio poderia comprometer a generalizac¸˜ao de suas conclus˜oes. No entanto, esse risco ´e atenuado pelos seguintes motivos: (a) o Eclipse ´e um sistema com-plexo e de grande porte; (b) o FindBugs ´e uma das ferramentas de an´alise est´atica mais completas e populares em se tratando de sistemas implementados em Java.
Validade Interna: Essa forma de validade avalia se as conclus˜oes obtidas n˜ao s˜ao re-sultantes de fatores que n˜ao foram controlados ou medidos. No planejamento do estudo, uma grande preocupac¸˜ao foi confirmar se a ferramenta FindBugs j´a n˜ao teria sido usada pelos pr´oprios desenvolvedores das vers˜oes analisadas do Eclipse. Para esclarecer essa d´uvida, uma mensagem foi enviada ao f´orum oficial de desenvolvedores do Eclipse, os quais confirmaram que o FindBugs n˜ao ´e usado durante o processo de building do sistema.
Validade de Construc¸˜ao: Essa forma de validade procura avaliar se as conclus˜oes obti-das n˜ao s˜ao resultantes de uma conduc¸˜ao incorreta do experimento. Conforme afirmado na Sec¸˜ao 2, no experimento realizado, a assinatura de um defeito ´e definida pelo identi-ficador do defeito e pela sua localizac¸˜ao no c´odigo (incluindo pacote, classe e m´etodo). Por esse motivo, foram considerados apenas defeitos que ocorreram em m´etodos, classes e pacotes presentes nas cinco vers˜oes do Eclipse avaliadas.
5 Trabalhos Relacionados
Ayewah et al. investigaram os defeitos reportados pela ferramenta FindBugs em trˆes sis-temas: Sun JDK, Glassfish e Google Java Code base [1]. O foco foi avaliar a qualidade dos defeitos reportados por essa ferramenta e tamb´em discutir os motivos pelos quais ferramentas de an´alise est´atica reportam muitos defeitos triviais e falsos positivos. Bugs
da categoria corretude de m´edia e alta prioridade reportados pelo FindBugs s˜ao por eles classificados em erros de an´alise, erros triviais, erros com impacto e erros s´erios. Dentre os erros reportados no JDK ,10% s˜ao s´erios, 46% possuem algum impacto e 44% s˜ao erros triviais. ´E interessante observar que, no presente estudo, envolvendo a plataforma Eclipse, alcanc¸ou-se tamb´em taxas de relevˆancia na faixa de 40% quando foi realizada uma reclassificac¸˜ao dos defeitos priorit´arios reportados pelo FindBugs.
Kim et al. apresentam os resultados de um estudo de caso com as ferramentas FindBugs, JLint e PMD [4]. Nesse estudo, em vez de analisarem vers˜oes est´aveis de um sistema, eles se concentraram em vers˜oes que representam fix changes, isto ´e, vers˜oes que corrigem um bug reportado por um usu´ario final. Al´em disso, s˜ao comparadas as vers˜oes antes e depois de um fix change, a fim de determinar as linhas de c´odigo que sofreram alterac¸˜oes para correc¸˜ao do bug reportado. Essas linhas s˜ao marcadas como bug-related lines. Um defeito reportado pelas ferramentas de an´alise est´atica consideradas no estudo ´e classificado como falso positivo caso ele ocorra em uma linha que n˜ao foi marcada como bug-related. Dentre os trˆes sistemas analisados, no melhor caso, apenas cerca de 20% dos defeitos reportados foi corrigido em vers˜oes futuras. Em linhas gerais, esse percentual ´e da mesma ordem daqueles mostrados na Tabela 4. Os autores concluem ent˜ao que existe uma baixa correlac¸˜ao entre as categorias de defeitos efetivamente removidos e a escala de prioridades de defeitos utilizada por ferramentas de an´alise est´atica (ou seja, chegam a uma conclus˜ao parecida com aquela descrita no final da Sec¸˜ao 3).
6 Conclus˜oes
A experiˆencia descrita no trabalho mostrou que o percentual de defeitos relevantes re-portados por ferramentas de an´alise est´atica ´e bastante baixo. Ou seja, essas ferramentas – quando executadas com sua configurac¸˜ao padr˜ao – reportam um n´umero excessivo de falsos positivos. No experimento realizado, no melhor caso, a taxa de defeitos relevantes foi de cerca de 29% (ver Tabela 4). No entanto, a taxa de defeitos relevantes reportados por essas ferramentas pode ser substancialmente incrementada caso seja realizada uma filtragem pr´evia dos tipos de defeitos que devem ser considerados, tendo em vista as ca-racter´ısticas do sistema analisado. Por exemplo, em um sistema como Eclipse, defeitos relativos a brechas de seguranc¸a n˜ao s˜ao, em geral, relevantes. No experimento realizado, ap´os essa reclassificac¸˜ao de prioridades de defeitos ter sido aplicada, a taxa de defeitos relevantes, no melhor caso, subiu para quase 60% (ver Tabela 7).
Referˆencias
[1] Nathaniel Ayewah et al. Evaluating static analysis defect warnings on production software. In 7th Workshop on Program Analysis for Software Tools and Engineering (PASTE), pages 1–8, 2007.
[2] Tom Copeland. PMD Applied. Centennial Books, 2005.
[3] David Hovemeyer and William Pugh. Finding bugs is easy. SIGPLAN Notices, 39(12):92–106, 2004.
[4] Sunghun Kim and Michael D. Ernst. Which warnings should I fix first? In 15th International Symposium on Foundations of Software Engineering (FSE), pages 45–54, 2007.