Ferramentas de crash report são softwares utilizados por organizações para armazenar dados de falhas que ocorrem em seus sistemas. Um relatório de falha contém informações dos crashes e são utilizados geralmente para tarefas de depuração, priorização de correções ou na compreensão do impacto das falhas no sistema.
Neste trabalho, apresentamos uma forma de utilização destes dados dos relatórios para apoiar os programadores durante o desenvolvimento de software. Para promover este apoio, desenvolvemos uma ferramenta em forma de plug-in da IDE Eclipse, a CrashAwareDev.
Antes de propor a ferramenta, realizamos um estudo detalhado de crashes armazenados em um crash reporter real, a fim de analisar informações de um subconjunto de defeitos que levaram um sistema ao estado de crash, em um período específico. Nesta análise, documentamos causas de erros de agrupadas pelos tipos de exceções mais comuns e identificamos alguns padrões de bugs que poderiam ser incluídos em uma análise estática automatizada.
Os padrões identificados na análise, foram implementados na CrashAwareDev a fim de exibi-los aos desenvolvedores em tempo de codificação. Também foram implementadas no
plug-in funções para consumir serviços (REST) do servidor de dados do crash report. Esta
integração foi feita para permitir que os programadores possam ser alertados sobre classes associadas a falhas recentes e fazer consultas no relatório de falhas diretamente em sua IDE, exibindo suas informações de forma resumida. Porém, para auxiliar os desenvolvedores durante a correção de falhas, inserimos um link associado ao crash que leva diretamente à ferramenta de crash report, onde pode-se acessar suas informações completas. Construí- mos também uma funcionalidade colaborativa que permite desenvolvedores adicionarem informações sobre tipos de exceções ou falhas específicas.
Por fim, fizemos um estudo de caso em um ambiente real de desenvolvimento e ouvimos opiniões dos programadores participantes, na fase de avaliação da CrashAwareDev. Destacamos como pontos positivos da ferramenta os alertas de bug patterns específicos da
aplicação e a consulta de crashes. Estas funcionalidades se mostraram úteis na tarefa de apoiar os programadores durante a codificação. Cerca de 58% das classes alteradas pelos participantes continham algum alerta de bug pattern. Observamos que apenas um dos alertas exibidos foi resolvido por um programador. Neste caso, o padrão de bug detectado foi inserido pelo próprio programador durante o desenvolvimento e, após a exibição do alerta, ele seguiu a recomendação da ferramenta e realizou o ajuste.
Porém, o padrão definido de que métodos privados dos controladores devem possuir métodos get e set gerou um excesso de falsos positivos, segundo alguns desenvolvedores. Apesar de a ausência destes métodos poder gerar falhas durante a renderização da página
Web, nem todo atributo privado é acessado pelas JSPs. A análise na forma inversa
provavelmente geraria menos falsos positivos, isto é, analisando o arquivo JSP em busca de referências à atributos do controlador que não possuem métodos get e/ou set. Porém, nosso trabalho se restringiu a análise de classes Java.
Duas funcionalidades da ferramenta não foram utilizadas durante o estudo por parte dos programadores. Concluímos que a funcionalidade colaborativa de exceções não foi utilizada devido ao pouco tempo de aplicação do estudo (apenas 4 dias) e a base de dados com informações não não havia dados o suficiente. Já a função de exibir os principais tipos de exceções, acreditamos ser de interesse maior por parte dos responsáveis pelas equipes de desenvolvimento e seria utilizada de forma esporádica. Algumas melhorias podem ser feitas, como descreveremos na seção de trabalhos futuros.
7.1
Limitações da Pesquisa
A principal limitação desta pesquisa com relação à abordagem utilizada, é o fato de a análise de crashes ter sido realizada de forma manual. Tentamos extrair padrões de bugs apenas a partir de uma inspeção no relatório de falhas e no código-fonte. Determinamos os padrões de acordo com nossa análise em falhas ocorridas em apenas um mês e em um subconjunto relativamente pequeno de falhas. Para medir a relevância dos padrões implementados na ferramenta, precisaríamos aplica-la em um período maior de tempo e avaliar de forma mais precisa se os desenvolvedores de fato tiraram proveito dos alertas exibidos.
Com relação à CrashAwareDev, uma das limitações que podemos citar é com relação à ausência de mecanismos de análise de fluxo de dados. A análise estática se restringiu apenas ao corpo do método sob análise, mas potenciais falhas podem estar presentes em
outros métodos chamados neste. Esta limitação pode gerar falsos negativos na análise. Além disto, os alertas emitidos não fornecem informações suficientes ao desenvolvedor de como corrigir o problema. Poderíamos pensar em uma integração entre a ferramenta colaborativa da CrashAwareDev com os alertas, onde os próprios desenvolvedores poderiam contribuir com estas informações.
7.2
Trabalhos Futuros
Identificamos alguns problemas e aprimoramentos durante o estudo de caso realizados e listamos alguns trabalhos futuros que podem melhorar nossa pesquisa.
∙ Melhorar desempenho da ferramenta: uma crítica comum entre os participantes foi uma lentidão durante a compilação em alguns momentos. Pelo fato de ser feita uma consulta diretamente ao servidor de crashes durante a compilação, em alguns momentos a consulta demorava mais que o esperado e interrompia a finalização da compilação. Para resolver isto, podemos realizar esta tarefa de forma assíncrona, para que a compilação seja prioridade e depois os alertas do plug-in sejam exibidos.
∙ Aprimorar funcionalidade colaborativa: A funcionalidade colaborativa também não despertou interesse dos desenvolvedores. Acreditamos que a ideia em compartilhar informações de falhas comuns entre os programadores pode ser de grande valia, porém a interface da ferramenta não proporcionou que ela fosse utilizada durante a aplicação. A funcionalidade foi pouco explorada neste trabalho, mas com algumas melhorias de usabilidade e incentivo para sua utilização poderíamos avaliá-la em um novo trabalho. Outra melhoria proposta, seria que pudéssemos exibir informações de exceções sob um determinado contexto, ao invés de apresentar informações genéricas sobre tipo de exceções.
∙ Incluir novos padrões: tentamos identificar padrões de erros no período de um mês, porém poucos foram identificados. Uma análise mais completa em um período maior pode ser feita, incluindo coletar informações de programadores experientes que podem detectar padrões de erros que percebem no dia a dia.
∙ Permitir execução em batch: Uma alternativa para melhoria da CrashAwareDev seria a possibilidade de a análise estática ser executada em batch. Isto é, um pré- processamento da análise poderia ser feito com objetivos de (1) resolver o problema
de desempenho apontado e (2) gerar um relatório completo com todos os problemas do sistema.
Referências
AN, L.; KHOMH, F. Challenges and issues of mining crash reports. In: 2015 IEEE 1st
International Workshop on Software Analytics (SWAN). [S.l.: s.n.], 2015. p. 5–8.
APACHE. Class JspException. 2012. Disponível em: <https://tomcat.apache.org/ tomcat-5.5-doc/jspapi/javax/servlet/jsp/JspException.html, Acesso em Janeiro, 2019.
APACHE. Apache Struts. 2018. Disponível em: <https://struts.apache.org/, Acesso em Janeiro, 2019.
APPLE. Technical Note TN2123: CrashReporter. 2010. Disponível em: <https: //developer.apple.com/library/archive/technotes/tn2004/tn2123.html>, Acesso em Junho, 2018.
ARAUJO, J. E. M.; SOUZA, S.; VALENTE, M. T. Study on the relevance of the warnings reported by java bug-finding tools. IET Software, v. 5, n. 4, p. 366–374, August 2011. ISSN 1751-8806.
BASILI, V. R.; CALDIERA, G.; ROMBACH, D. The goal question metric approach.
Encyclopedia of Software Engineering, v. 1, 01 1994.
BESERRA, L. D. Gerenciador de Falhas: Uma Ferramenta para Análise de Fluxos de
Exceções nos Sistemas SIG. 2012. Monografia (Bacharel em Ciência da Computação),
UFRN (Universidade Federal do Rio Grande do Norte), Natal, Brazil.
CAMPBELL, G. A.; PAPAPETROU, P. P. SonarQube in Action. 1st. ed. Greenwich, CT, USA: Manning Publications Co., 2013. ISBN 1617290955, 9781617290954.
COELHO, R. et al. Unveiling exception handling bug hazards in android based on github and google code issues. In: Proceedings of the 12th Working Conference on Mining Software
Repositories. Piscataway, NJ, USA: IEEE Press, 2015. (MSR ’15), p. 134–145. ISBN 978-0-
7695-5594-2. Disponível em: <http://dl.acm.org/citation.cfm?id=2820518.2820536>. DEITEL HARVEY M.; DEITEL, P. J. Java como Programar. 6th. ed. São Paulo,BR: Prentice Hall, 2007.
DHALIWAL, T.; KHOMH, F.; ZOU, Y. Classifying field crash reports for fixing bugs: A case study of mozilla firefox. In: Proceedings of the 2011 27th IEEE International
Conference on Software Maintenance. Washington, DC, USA: IEEE Computer
Society, 2011. (ICSM ’11), p. 333–342. ISBN 978-1-4577-0663-9. Disponível em:
<https://doi.org/10.1109/ICSM.2011.6080800>.
ECLIPSE. Eclipse Java development tools (JDT). 2019. Disponível em: <https: //www.eclipse.org/jdt/, Acesso em Janeiro, 2019.
ELASTIC. Beats. 2018. Disponível em: <https://www.elastic.co/products/beats>, Acesso em Junho, 2018.
ELASTIC. Elasticsearch. 2018. Disponível em: <https://www.elastic.co/products/ elasticsearch>, Acesso em Junho, 2018.
ELASTIC. Kibana. 2018. Disponível em: <https://www.elastic.co/products/kibana>, Acesso em Junho, 2018.
ELASTIC. Logstash. 2018. Disponível em: <https://www.elastic.co/products/ logstash>, Acesso em Junho, 2018.
ELASTIC. Query DSL. 2019. Disponível em: <https://www.elastic.co/guide/en/ elasticsearch/reference/current/query-dsl.html, Acesso em Janeiro, 2019.
Farchi, E.; Nir, Y.; Ur, S. Concurrent bug patterns and how to test them. In: Proceedings
International Parallel and Distributed Processing Symposium. [S.l.: s.n.], 2003. p. 7 pp.–.
ISSN 1530-2075.
FERNANDES, T. do C. B. Trabalho de Conclusão de Curso, ExMinerSOF: Minerando
Informações Excepcionais do StackOverflow. Natal, RN, Brasil: [s.n.], Junho 2017.
GARCIA, A. F. et al. A comparative study of exception handling mechanisms for building dependable object-oriented software. Journal of Systems and
Software, v. 59, n. 2, p. 197 – 222, 2001. ISSN 0164-1212. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0164121201000620>.
GLERUM, K. et al. Debugging in the (very) large: Ten years of implementation and experience. In: Proceedings of the ACM SIGOPS 22Nd Symposium on Operating
Systems Principles. New York, NY, USA: ACM, 2009. (SOSP ’09), p. 103–116. ISBN
978-1-60558-752-3. Disponível em: <http://doi.acm.org/10.1145/1629575.1629586>.
GOODENOUGH, J. B. Exception handling: Issues and a proposed notation. Commun.
ACM, ACM, New York, NY, USA, v. 18, n. 12, p. 683–696, dez. 1975. ISSN 0001-0782.
Disponível em: <http://doi.acm.org/10.1145/361227.361230>.
HALL, T. et al. Some code smells have a significant but small effect on faults. ACM
Trans. Softw. Eng. Methodol., ACM, New York, NY, USA, v. 23, n. 4, p. 33:1–33:39, set.
2014. ISSN 1049-331X. Disponível em: <http://doi.acm.org/10.1145/2629648>. HOVEMEYER, D.; PUGH, W. Finding bugs is easy. SIGPLAN Not., ACM, New York, NY, USA, v. 39, n. 12, p. 92–106, dez. 2004. ISSN 0362-1340. Disponível em:
<http://doi.acm.org/10.1145/1052883.1052895>.
JO, J.-W. et al. An uncaught exception analysis for java. Journal of Systems
and Software, v. 72, n. 1, p. 59 – 69, 2004. ISSN 0164-1212. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0164121203000578>.
JOSHI, B. Patterns of enterprise application architecture: Repository, unit of work, lazy load, and service layer. In: . Beginning SOLID Principles and Design Patterns for
KIM, S.; ZIMMERMANN, T.; NAGAPPAN, N. Crash graphs: An aggregated view of multiple crashes to improve crash triage. In: Proceedings of the 2011 IEEE/IFIP 41st
International Conference on Dependable Systems&Networks. Washington, DC, USA: IEEE
Computer Society, 2011. (DSN ’11), p. 486–493. ISBN 978-1-4244-9232-9. Disponível em:
<http://dx.doi.org/10.1109/DSN.2011.5958261>.
MCCLUSKEY, G. Using Java Reflection. 1998. Disponível em: <https://www.oracle. com/technetwork/articles/java/javareflection-1536171.html, Acesso em Janeiro, 2019.
MENG, N. et al. An approach to merge results of multiple static analysis tools (short paper). In: 2008 The Eighth International Conference on Quality Software. [S.l.: s.n.], 2008. p. 169–174. ISSN 1550-6002.
MONTENEGRO, T. R. Trabalho de Conclusão de Curso, ExceptionPolicyExpert: Uma
Ferramenta para Auxiliar no Desenvolvimento do Tratamento de Exceções. Natal, RN,
Brasil: [s.n.], Fevereiro 2017.
MOZILLA. Mozilla Crash Reports. 2012. Disponível em: <http://crashstats.mozilla. com>, Acesso em Junho, 2018.
ORACLE. Advantages of Exceptions. 2017. Disponível em: <https://docs.oracle.com/ javase/tutorial/essential/exceptions/advantages.html>. Acesso em junho, 2018. ORACLE. Class IllegalArgumentException. 2018. Disponível em: <https://docs.oracle. com/javase/7/docs/api/java/lang/IllegalArgumentException.html, Acesso em Janeiro, 2019.
ORACLE. Class SQLException. 2018. Disponível em: <https://docs.oracle.com/ javase/7/docs/api/java/sql/SQLException.html, Acesso em Janeiro, 2019.
PMD. PMD: An extensible cross-language static code analyzer. 2018. Disponível em: <https://pmd.github.io/>. Acesso em junho, 2018.
POSTGRESQL. PostgreSQL. 2019. Disponível em: <https://www.postgresql.org/, Acesso em Janeiro, 2019.
RUTAR, N.; ALMAZAN, C. B.; FOSTER, J. S. A comparison of bug finding tools for java. In: 15th International Symposium on Software Reliability Engineering. [S.l.: s.n.], 2004. p. 245–256. ISSN 1071-9458.
SAWADPONG, P.; ALLEN, E. B. Software defect prediction using exception handling call graphs: A case study. In: 2016 IEEE 17th International Symposium on High Assurance
Systems Engineering (HASE). [S.l.: s.n.], 2016. p. 55–62. ISSN 1530-2059.
SCHROTER, A. et al. Do stack traces help developers fix bugs? In: 2010 7th IEEE
Working Conference on Mining Software Repositories (MSR 2010). [S.l.: s.n.], 2010. p.
118–121. ISSN 2160-1852.
SINFO. Superintendência de Informática - UFRN. 2016. Disponível em: <https: //www.info.ufrn.br/>. Acesso em junho, 2018.
SINHA, S. et al. Fault localization and repair for java runtime exceptions. In: Proceedings
of the Eighteenth International Symposium on Software Testing and Analysis. New York,
NY, USA: ACM, 2009. (ISSTA ’09), p. 153–164. ISBN 978-1-60558-338-9. Disponível em:
<http://doi.acm.org/10.1145/1572272.1572291>.
SONARSOURCE. SonarLint. 2019. Disponível em: <https://www.sonarlint.org/, Acesso em Janeiro, 2019.
SPOTBUGS. SpotBugs. 2019. Disponível em: <https://spotbugs.github.io/, Acesso em Janeiro, 2019.
WADIA, Z. e. a. MyFaces and Facelets. 1st. ed. New York,NY: Apress, 2008.
WAGNER, S. et al. Comparing bug finding tools with reviews and tests. In: KHENDEK, F.; DSSOULI, R. (Ed.). Testing of Communicating Systems. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005. p. 40–55. ISBN 978-3-540-32076-0.
WANG, S.; KHOMH, F.; ZOU, Y. Improving bug localization using correlations in crash reports. In: 2013 10th Working Conference on Mining Software Repositories (MSR). [S.l.: s.n.], 2013. p. 247–256. ISSN 2160-1852.
WU, R. et al. Crashlocator: Locating crashing faults based on crash stacks. In: Proceedings
of the 2014 International Symposium on Software Testing and Analysis. New York, NY,
USA: ACM, 2014. (ISSTA 2014), p. 204–214. ISBN 978-1-4503-2645-2. Disponível em: